Re: Semantics (was: Re: desktop-devel-list Digest, Vol 50, Issue 26)
2008-06-24 klockan 00:53 skrev Mikkel Kamstrup Erlandsen: However insulted some people will feel by Wouter's comments I beg; can we please stop this thread here? Sorry, seems my comments were a bit harsh. I should watch my words more carefully when sending messages late at night... :) For clarification: I didn't intend to insult anyone. Though I don't use Tracker myself, most of the software seems of relatively high quality. It's just that some of the underlying design decisions wrt. metadata were, imho, not taken with the appropriate mindset. Again, sorry for the negative sound of my words... mvrgr, Wouter -- :wq mail [EMAIL PROTECTED] web http://uwstopia.nl did you want me to change? :: well i change for good -- coldplay signature.asc Description: Digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Semantics (was: Re: desktop-devel-list Digest, Vol 50, Issue 26)
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 desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Semantics (was: Re: desktop-devel-list Digest, Vol 50, Issue 26)
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 desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Anders Feder [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Semantics (was: Re: desktop-devel-list Digest, Vol 50, Issue 26)
2008-06-23 klockan 21:01 skrev Anders Feder: 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. The Tracker developers have shown to be particularly ignorant of any RDF/SPARQL related subjects in the past. See for example the messages I've sent to the Proposing Tracker for inclusion into GNOME 2.18 thread [1] on desktop-devel-list one and a half years ago: [2--7]. The messages linked to are all by me, but you may also find the comments by Ross Burton useful. The thread is quite large so don't even try to read all of it... :) mvrgr, Wouter [1] http://mail.gnome.org/archives/desktop-devel-list/2006-October/msg00175.html [2] http://markmail.org/message/nj6ecn42xda4sq6x [3] http://markmail.org/message/3hbuioopc5ib7uuq [4] http://markmail.org/message/brt26slkzbwew3dw [5] http://markmail.org/message/rl4ae2quaes6e5pd [6] http://markmail.org/message/roa6qjkhomi4cgpw [7] http://markmail.org/message/2jt5l2yz6wyxdqux -- :wq mail [EMAIL PROTECTED] web http://uwstopia.nl spread your love like a fever -- black rebel motorcycle club signature.asc Description: Digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Semantics (was: Re: desktop-devel-list Digest, Vol 50, Issue 26)
Ah, I have overheard late-night tales of this epic flamewar murmured in dark corners of many a seedy IRC channel during my inquest into the history of GNOMish metadata magicks, but had yet to peruse the transcription scrolls for myself. I bid you thanks for the links ;) man, 23 06 2008 kl. 23:56 +0200, skrev Wouter Bolsterlee: 2008-06-23 klockan 21:01 skrev Anders Feder: 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. The Tracker developers have shown to be particularly ignorant of any RDF/SPARQL related subjects in the past. See for example the messages I've sent to the Proposing Tracker for inclusion into GNOME 2.18 thread [1] on desktop-devel-list one and a half years ago: [2--7]. The messages linked to are all by me, but you may also find the comments by Ross Burton useful. The thread is quite large so don't even try to read all of it... :) mvrgr, Wouter [1] http://mail.gnome.org/archives/desktop-devel-list/2006-October/msg00175.html [2] http://markmail.org/message/nj6ecn42xda4sq6x [3] http://markmail.org/message/3hbuioopc5ib7uuq [4] http://markmail.org/message/brt26slkzbwew3dw [5] http://markmail.org/message/rl4ae2quaes6e5pd [6] http://markmail.org/message/roa6qjkhomi4cgpw [7] http://markmail.org/message/2jt5l2yz6wyxdqux -- Anders Feder [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Semantics (was: Re: desktop-devel-list Digest, Vol 50, Issue 26)
2008/6/23 Wouter Bolsterlee [EMAIL PROTECTED]: 2008-06-23 klockan 21:01 skrev Anders Feder: 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. The Tracker developers have shown to be particularly ignorant of any RDF/SPARQL related subjects in the past. See for example the messages I've sent to the Proposing Tracker for inclusion into GNOME 2.18 thread [1] on desktop-devel-list one and a half years ago: [2--7]. The messages linked to are all by me, but you may also find the comments by Ross Burton useful. The thread is quite large so don't even try to read all of it... :) mvrgr, Wouter [1] http://mail.gnome.org/archives/desktop-devel-list/2006-October/msg00175.html [2] http://markmail.org/message/nj6ecn42xda4sq6x [3] http://markmail.org/message/3hbuioopc5ib7uuq [4] http://markmail.org/message/brt26slkzbwew3dw [5] http://markmail.org/message/rl4ae2quaes6e5pd [6] http://markmail.org/message/roa6qjkhomi4cgpw [7] http://markmail.org/message/2jt5l2yz6wyxdqux However insulted some people will feel by Wouter's comments I beg; can we please stop this thread here? Cheers, Mikkel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
