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 developers. > 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 [snip] > In fact this is exactly the approach I am discussing with Sebastian Trüg > at the moment :) Excellent! > 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. :) /Mike -- ✌ Michael Gratton. Geeknik since 1976. ✇ <http://web.vee.net/>
Attachment:
signature.asc
Description: This is a digitally signed message part