Re: Future of GNOME: Semantics



On Sat, 2008-06-14 at 19:11 +0200, Anders Feder wrote:
> Now, the idea is that if we model all of the aforementioned abstractions
> (applications, mental models, smart devices etc.) in RDF, GNOME can take
> advantage of the same features in a single unified framework

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

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.

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. 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.

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. 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.

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 RDF.

Another example would be desktop-wide searching. A front-end search tool
would be able to scan the session bus for objects supporting this
interface and query each in turn for applicable results, presenting them
as such - "10 matching emails in Evolution, 20 matching notes in Tomboy"
etc. This would mean that the existing engines (Tracker, Beagle)
wouldn't need to write duplicate indexers for every application like
Evolution, they can concentrate on the file system and full-text
indexing. It also cuts down on data duplication - there isn't a copy of
my email metadata in both Evo and Tracker and so it never needs to get
crawled and cannot get out of sync.

Applications that do want to store data in RDF can of course choose to
do so, it would certainly make this sort of desktop integration easier.

/Mike

(apologies for the essay, it just kept coming)

-- 
✌ Michael Gratton. Geeknik since 1976.
✇ <http://web.vee.net/>

Attachment: signature.asc
Description: This is a digitally signed message part



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]