A little note on the topic: I've summarized the stack we're approaching between my talks with Sebastian and the discussion here, at: http://live.gnome.org/RDFStack
man, 23 06 2008 kl. 21:01 +0200, skrev Anders Feder: > 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 <[EMAIL PROTECTED]> > > _______________________________________________ > desktop-devel-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Anders Feder <[EMAIL PROTECTED]> _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
