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 <[EMAIL PROTECTED]> _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
