Semantics (was: Re: desktop-devel-list Digest, Vol 50, Issue 26)

[Anders Feder <lists anders feder dk>]

Sorry Michael, must have missed your e-mail among the digests last week.

tor, 19 06 2008 kl. 12:14 +1000, skrev Michael Gratton:
> Ahh, right. Can something be constructed to translate SPARQL (or some
> useful subset) into Tracker's query format?

A subset, yes, but as Wouter points out Tracker is XESAM-based which
'only' cover simple query cases, so certain advanced SPARQL queries (in
particular 'join'-like operations) would map rather poorly into XESAM.

How such queries would be handled by a translator is undefined. In
theory, one could do something like constructing the actual graph
resulting from i.e. a join operation in memory, but that is really quite
a hack that doesn't scale well for big data sets.

I've communicated with both Tracker and XESAM maintainers and they
appear quite skeptical about RDF/SPARQL support in the short- to
mid-term.

I would suggest that we hack together an interim adapter for XESAM as a
proof-of-concept. Once that works, it should be easier to persuade
everyone to reconsider native RDF support.

> Do you know how applications typically use those interfaces? The W3C
> case study states that users can tag files in Dolphin. When a user does
> so, does Dolphin save the tag as well as pushing it to Soprano, or just
> the latter? I assume it doesn't save a copy, but that means when
> displaying files, it needs to query Soprano for every one? If the
> performance doesn't suck, this might be a reasonable model, but you'd
> want to ensure Soprano is always well behaved. :)

I believe Dolphin pushes the tag triple into Soprano, yes. This should
be quite like a social networking site storing tags in a relational
database.

However, I imagine the other model could also be supported: Dolphin
stores tags in a store of its own and this store is exposed as a Soprano
backend. Dolphin can access its own store directly, but other
applications will go through the SPARQL layer.

Currently, this would be done with Sopranos backend classes. In our
case, this would be where the D-Bus interface you suggested would come
into the picture and I'm almost certain Sebastian would be happy to
support such an interface in Soprano as well.

> I dunno, maybe having a common service is the way to go, but something
> will need to be done to make it easy for developers to implement.

Yes, I agree. Something like a library that makes it trivial to
implement the RDF backend D-Bus interface should be available.

-- 
Anders Feder <lists anders feder dk>