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

[Philip Van Hoof]

On Sun, 2009-05-03 at 03:08 +0300, Evgeny Egorochkin wrote:
> On 24 апреля 2009 23:49:20 Arun Raghavan wrote:

> > Why not get the 1.0 implementations out there,
> 
> They are basically already out. It's not like Nokia's involvement in Tracker 
> scared away any core devs or something.

Definitely not, no. Xesam 1.0's ontology is just not what we picked.
Xesam 1.0's DBus API is not what we'd like to use for reasons we
explained that the hackfest in Berlin and for/which are the reasons I
listed here before (a. SPARQL as query language, b. Nepomuk as ontology,
c. reduce the amount of state the DBus API requires).

If Xesam 2.0 provides that, then Tracker is still looking for a good
DBus API itself. 

Please note that full SPARQL with Live-search capability is something
most projects wont succeed in implementing quickly. It gets pretty
complex to efficiently detect whether or not a update matches any of the
SPARQL queries (which can get pretty complex to solve) involved in a
live-search. Which is why we recently introduced our class-signals
feature.

http://live.gnome.org/Tracker/Documentation/SignalsOnChanges


> > and then work towards
> > getting 2.0 along in a way that converges towards the goals Philip
> > listed, in a shorter timeframe than 1.0 took?
> 
> Unfortunately the developement process is rarely this linear.
> 
> Actually as soon as you start implementing 2.0 you find yourself facing some 
> pretty hard problems such as which ontology should data extractors use etc 
> etc. So 1.0<->2.0  mapper here is almost inevitable.

We're pretty much definitely not going to store using Xesam 1.0's
ontology. Which means that if a Xesam 1.0 app wants to receive metadata
based using Xesam 1.0 ontology, that a mapper will have to be developed.

I hope that this mapper will be a reusable project, rather than every
project having to implement this themselves.

Just make a little proxy dbus service that listens for Xesam 1.0
requests, receives Xesam 2.0 replies from another service, and converts
the answers to Xesam 1.0 as good as possible.

This means that the dbus overhead is doubled, but I'll prefer that over
having to store both Nepomuk-bleedingedge and Xesam 1.0 as ontologies.


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