Re: Future of GNOME: Semantics

On Sun, 2008-06-15 at 18:19 +0200, Anders Feder wrote:
> Which are these existing applications? Can you give a few examples?

Sorry, I thought I did - Evolution, Conduit, Tomboy - in passing.

> Adopting an RDF storage model in favor of a dedicated data store would
> be a long-term investment with several benefits.

Yes, I don't doubt that for a moment but it's also a very hard sell to

> Also, how is RDF overkill for new applications?

Again, I was saying it would *seem* like overkill to the developers.
Take Tomboy as an example. When starting out, had the developer had the
choice, do you think he would have chosen an RDF store or still have
used HTML in flat files?

> RDF is in fact a very light framework.

Yep, I am familiar with it after having used it in a few projects.
Still, it's that same simplicity that puts developers off RDF. When you
have an API which is basically just put_statement(s, p, o) and
get_statement(s, p, o) and a similarly abstract starting point for a
model, it can be quite bewildering and inconvenient.

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

Because you're encoding more information, explicitly. For example, much
of the semantics of an RFC 833 message is implicit its syntax, an RDF
representation of that would include the semantics explicitly as well.

It's just a hunch, I don't have any data to back this up but would be
willing to test it out. Maybe I could use the Enron email archive...

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

Cool! Are you suggesting Tracker as store? If not, why not? :)

> > One way would be to define a D-Bus
> In fact this is exactly the approach I am discussing with Sebastian Trüg
> at the moment :)


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

I see where you're coming from, but that has the same problem as the
desktop search engines do at the moment - needing to write a parser for
every format it needs to understand. Obviously, if Evo used RDF
and Soprano directly then this won't be needed, but the problem with
that is my whole thesis: RDF is too hard/inconvenient to be used as the
primary storage model.

A decent helper library to assist implementing a D-Bus RDF interface
that could be "bolted on", if possible, seems to be like a better way
forward to my mind. I'd be willing to help implement such a thing, if
that helps.

Having pervasive RDF in the desktop would be awesome, the hard part is
getting it there. :)


✌ Michael Gratton. Geeknik since 1976.
✇ <>

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]