Hi Anders,
On Mon, 2008-06-16 at 18:02 +0200, Anders Feder wrote:
> Why would changing storage backends be a no-go for these applications?
> It may be the sentiment of developers if its presented to them just
> like that ("here is your new backend, now change"), but I don't see how
> it would be structurally impossible or impractical for these
> applications to rely on a different store?
You're right, it wouldn't be impossible. Migrating to a new backend is
something that is certainly non-trivial and possibly a whole lot of
work, however. You would need to have a very convincing argument to do
so (and probably contribute a lot of code).
> > Again, I was saying it would *seem* like overkill to the developers.
>
> Ok. I wonder, then, why it would be perceived as such.
I think it is because RDF's model is abstract enough that for the first
time developers, much learning and ground work has to be done to make it
useful.
> Personally, I would probably have used HTML in flat files with metadata
> annotations in the RDF store. I agree that RDF is not intended for
> document markup.
Ahh, this is how Yet Another blog engine I'm writing works. :)
> Isn't an RFC 822 message roughly just a list of key-value pairs?
> Wouldn't these pairs map directly into predicate-object pairs in RDF?
Yes, but then some header field values have additional structure that
should be represented, the ordering of the headers can be important so
you need to track that (maybe using a RDFS Seq) and messages with MIME
bodies should have that represented. As I said, it's just a hunch, I'll
check it out after my exams.
> Tracker would be a great candidate for a central RDF store. I don't know
> if its developers agree though :)
Aww, Jamie didn't think it would be suitable for my blog engine,
either. :) Wasn't the plan to use Tracker for Epiphany's bookmarks and
history? Is the problem that of storing arbitrary RDF?
> That is an interesting thesis because I think it summarize the sentiment
> in the past few mails here and I personally still miss any evidence for
> its truth.
It's about complexity, and people's tendency to try to minimise it.
Using the file system is at least an order of magnitude less complex
than a service for storing your data in terms of implementation, testing
and bugfixing. Using the native model for your data is similarly less
complex than converting it to something else, as is keeping your
metadata and data together vs splitting it up.
So to be successful, something to minimise this complexity is needed -
probably some code (he says, while providing none). How are the KDE guys
doing it? They're using Soprano, but how do apps get data into it, out
of it and keep it sync'ed? What programming interfaces are available for
K developers?
/Mike
--
✌ Michael Gratton. Geeknik since 1976.
✇ <http://web.vee.net/>
Attachment:
signature.asc
Description: This is a digitally signed message part