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

[Philip Van Hoof]

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.

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. 

- 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.

- 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.

> I really like the proposal for an ontology sharing system, and it could be one 
> of the starting points for Xesam 2.0. Given that this may be considered 
> a "brainstorm thread", probably we can start detailed discussion in a more 
> specific thread.
> 
> But I also want to add my 2 cents to the "Xesam future" bag, not with a formal 
> proposal but just some thought, already partially mentioned in previous 
> mails. Please correct me in case of error.
> 
> In the real world semantic informations already exists in form of microformats 
> (vCard) of also proprietary formats (ID3), and mapping them 1:1 in a new 
> ontology may not be the solution, above all if the introduction of a new 
> format to harvest imply the update of the whole set.
> I think Xesam may be something more like the "Semantic Space" speculated in 
> Gnome's wiki (http://live.gnome.org/AndersFeder/SemanticSpace), 

SemanticSpace, is that a vaporware replacement for Tracker's Nepomuk
+SPARQL based storage? Never heard about it to be honest.

> reusing 
> existing ontologies also spreading the web or supposed to appear in near 
> future to provide a "unified APIs and specs for desktop search" (as described 
> in the homepage for the project). Nepomuk ontology is great, but just solves 
> a portion of the problem.
> That would means strip down most of work done in 1.0 and review the complete 
> project from beginning, but also will provide an effective tool for "Semantic 
> Desktop" as intended as (from Wikipedia) "data is more easily shared between 
> different applications or tasks".

-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be