Re: Future of GNOME: Semantics

[Anders Feder <lists anders feder dk>]

Michael,

Thanks for your reply. 

> This is perhaps the biggest problem with selling and implementing
> system-wide metadata for any existing system, including GNOME.

That's constructive criticism.

> There are a large number of applications that have existing, more than
> reasonable models and mechanisms for data storage, for which converting
> to use RDF and a central store for storage will be a no-go. For new
> applications, using RDF may well seem overkill.

Which are these existing applications? Can you give a few examples?
Adopting an RDF storage model in favor of a dedicated data store would
be a long-term investment with several benefits.

Also, how is RDF overkill for new applications? If they opt to design a
dedicated data store, they are likely to reinvent many of the same
primitives as RDF use anyway and much of the coding they would have to
do would already be done, in the form of system services. 

RDF is in fact a very light framework. A simple associative array is
sufficient to represent a basic RDF resource. On top of that, RDF then
specifies how groups of such arrays can be combined and related to each
other in various ways, but that is advanced use, which can be handled by
dedicated tools.

> RDF, while an excellent model in general, it is arguably less efficient
> then say RFC-822 for email or vCard for contacts. I have several GB of
> email, I'd be worried about that ballooning out if an RDF store was used
> instead.

I actually don't see how RDF would increase the size of your data by any
significant size?

RDF itself does not specify a storage format and as such your current
e-mail database could easily be exposed as RDF, just as it is. The
central RDF store would be meant as an convenience for developers and in
particular for search: you can do some quite fascinating things once you
are able to combine metadata from several otherwise seperate sources,
such as "all e-mail from people who are listed in the 'Work' group in
Pidgin".

Perhaps you are thinking of RDF/XML which admittedly is a little odd -
but that is just one RDF serialization among many and nothing would
prevent us from serializing just the way that would be practical for us.

> Relatedly, there are some cases where RDF and a store really
> should not be used as the storage model, word processors and image
> editing programs, for example.

Oh, definitely. RDF primarily does _metadata_. But it does that
exceptionally well - so well that I think it would really be a shame to
miss out on for most applications.

> The key to a better approach is in the definition you gave for RDF: Use
> it for interchange instead. I.e. provide some way for GNOME applications
> to provide access to their data for interchange, but let them store it
> however they want.

Sure, using central store wouldn't be mandatory. It would be one of a
few offerings in the larger RDF strategy.

> One way would be to define a D-Bus
> interface /org/freedesktop/RdfSource and provide some supporting
> libraries to make it straight-forward to provide access to GObjects as
> RDF.

In fact this is exactly the approach I am discussing with Sebastian Trüg
at the moment :)

http://live.gnome.org/AndersFeder/SemanticSpace
http://live.gnome.org/AndersFeder/libsemantic

Sebastian's RDF store, Soprano, supports backend plugins which for
instance could retrieve data from an application-specific store.

> 
> As an example, the one you gave Olav: Conduit needs to sync contacts
> from my N95 with Evo, so it invokes Evolution using D-Bus, queries the
> contact database using the RdfSource interface, gets the data it needs
> as RDF that way. ?The amount of effort to support RDF itself in
> Evolution here is the same, but the overall effort is less as it won't
> have to also be converted store contacts, mail, etc in 

In Sebastian's architecture, Conduit would invoke Soprano, which would
then access Evolutions database through a backend. This way, Evolution
(and other applications) doesn't have to implement a SPARQL query
parser.

-- 
Anders Feder <lists anders feder dk>