[Xesam] Nepomuk/Xesam future (was Re: condition of 1.0 ?)

[Mikkel Kamstrup Erlandsen]

2009/4/24 Philip Van Hoof <spam at pvanhoof.be>:
> On Fri, 2009-04-24 at 14:19 +0200, Roberto Guido wrote:
>> On Friday 24 April 2009 10:54:24 you wrote:
>> > I am working on tracker, and
>> > we are using nepomuk.
>
>> I cannot understand how a project listed in the Freedesktop directory may not
>> only support a de-facto imposed specification but also drop support for the
>> language (Xesam) expressely aiming at interoperability and easy of use.
>> Probably (surely) Xesam 1.0 ontology is actually more steps back the Nepomuk
>> one, but also (as you suggested) has his own pros, such as a more confortable
>> query mechanism: I'm looking for a re-introduction of the Xesam support in
>> Tracker, ASAP.
>
> Wohow. If you say ASAP, you write patches. Otherwise nothing will happen
> on your demand. Period.

Let me just say that I am fine with Tracker dropping Xesam from their
current source tree. With so many big changes floating around in the
Tracker sources, one has to make decisions, and I fully respect that.

However, it has been my plan (for a very long while) to add Xesam 1.0
support to Tracker by leveraging xesam-glib. Needless to say this will
require some level of cooperation, because I need to hook into the
Tracker daemon in some way.

The steps that one (where one=me I expect) would need to make this
viable are something like:

 * Allow one to hook into Tracker at some well defined points. I am
thinking about using something like the GIOExtensionPoint API...
Alternatively simply implement a proxying process to begin with, like
Arun's xesam-adaptor does for Beagle.

 * Write a query cross compiler Xesam -> Tracker. I don't know
new-Tracker's internal query representation at all... Is there some
form of AST or is it simply directly mapping Sparql to SQL? Xesam-glib
contains a lot of useful code for doing this.

 * Write the actual Xesam session manager. I started writing a generic
one in Xesam GLib (and I have it fully spec'ed down at
http://xesam.org/main/XesamGLib/ServerDraft).

 - As a note I might add that I talked a bit with Fabrice Colin about
doing something similar for Pinot and he was quite positive.

> Tracker will most likely implement Xesam 2.0 after the issues that we
> discussed at the Hackfest in Berlin are addressed (simplified DBus API)
> and after Xesam fully adopts and switches to Nepomuk (with which the
> current author of the Xesam ontology apparently agrees).
>
> We would also very much like Xesam 2.0 to use SPARQL as query language
> instead of an archaic RDFQuery-like language.
>
> These three changes mean that Xesam 2.0 will be significantly different
> than Xesam current. Which means I don't think Tracker will have support
> for this Xesam 2.0 soon. Meaning that your "as soon as possible" might
> take some time.

A realistic guess is probably 1 year, maybe more. That is assuming
that we can get momentum behind something in the first place...

> - SPARQL: many teams are migrating 100% away from XML-ish RDFQuery
>  towards SPARQL. W3 is recommending SPARQL as w3's official RDF query
>  language. People who are still into the XML-ish RDFQuery need to start
>  waking up and smell the fresh air of reality.

Let me say that I am not in any way anti-Sparql, but saying that
"...many teams are migrating 100% away from XML-ish RDFQuery towards
SPARQL." seems like out of touch with reality from my POV. I have been
to several conferences with a heavy emphasis on semantic technologies,
and not one single project used Sparql. It has been MQL, ITQL, or some
proprietary language.

This is not to be read as an objection to using Sparql in Xesam 2.0
though! I am fine with that.

> - Nepomuk ontology: Both strigi and Tracker have together agreed that
>  Nepomuk will be the shared ontology. Making the two major RDF metadata
>  projects of GNOME and KDE use this in near future
>
> - Simplified DBus API: Strigi prefers less state in the API and the
>  Tracker team (that's us) want to someday have a proto that basically
>  proxies this API over UDP (so we want to reduce the amount of state
>  drastically too). We thoroughly discussed this during the Hackfest in
>  Berlin and we were almost in tears when we finally started agreeing on
>  the new direction. Let's not undo that.
>
> Seriously.

Right :-) That cost us a lot of sword fighting, but the agreement is
still there.

But from my perspective that doesn't leave Xesam 1.0 as irrelevant.
But as I've hinted elsewhere I don't want to impose that one anyone.

-- 
Cheers,
Mikkel