Re: [Tracker] Zeitgeist ontology and Tracker

[Mikkel Kamstrup Erlandsen <mikkel kamstrup gmail com>]

On 23 March 2011 00:12, Philip Van Hoof <philip codeminded be> wrote:
> On Tue, 2011-03-22 at 21:15 +0100, Mikkel Kamstrup Erlandsen wrote:
> > Hi all,
> >
> > There's been some back and forth about Zeitgeist/Tracker integration.
> > The key point in getting anything started in this direction is
> > figuring out the ontology business.
> >
> > There has already been some work towards a solution[1]. We've already
> > fixed a few issues reported by Rob a while back, but the changes in
> > [1] were never discussed (see original ZG ontology in [2]). The
> > problem is that Rob's work contains some changes that are incompatible
> > with the original ontology, so it's not something we can adopt without
> > justifying it (will break our API and bring some troublesome data
> > migration work).
> >
> > So, let's get that discussion we never had :-) If we *theoretically*
> > proposed the ZG ontology (as in [2], not [1]) for inclusion in
> > Tracker, what issues would you see?


Thanks a bunch for the review Philip! :-)

> While comparing the two, here are some examples:
>
> o. zg: {} : In Tracker we don't allow brand specific namespaces. NEO is
>   the namespace that we chose for this (New Event Ontology).

Ok... Although I guess what you call "branding" is really just the
essence of namespacing to me: Choosing some vendor specific prefix for
your types. The Dublin Core, Nepomuk, and Maemo ontologies Tracker
ships, all does it as well.

With this policy you basically force any project with a project
specific ontology to break their API if they want to integrate with
Tracker; changing the namespace to be Tracker branded (ala NMM). How
is a volunteer driven OS project guaranteeing ontology compatibility
not as good as some non-profit entity? (not that Maemo is that)

> o. Those "Please do no instantiate directly, but use one of the sub
>   classes." - like rules are not ok for us

Right. I am not sure we need to impose these restrictions anymore. So
these strings can be removed.

> o. zg:eventId : We don't allow such IDs in the ontology. And ID means
>   that it's referring to something. A "something" is a rdfs:Resource.
>
>   ps. If you want to use integral IDs in your framework, you can use
>       tracker:id() on the resource

Ok, how do you want domain specific ids expressed then; like ISBN etc?

> o. zg:timestamp rdfs:range xsd:long: xsd:integer is int64 in Tracker, I
>   think we don't even support xsd:long as type atm

That's clearly a bug/quirk in Tracker. xsd:integer can have arbitrary
length. I don't think it would do us any harm to work around it
though; so no biggie.

> o. zg:hasSubject: must be nie:InformationElement as range

Hmmm, right. Seems to make sense, although I think the reason it is
like this is because some of the items in the Nepomuk ontologies are
not always subclasses of nie:InformationElement, and we wanted to
accomodate that. I can't recall the details off hand.

> o. zg:hasActor: I think it should also be a nie:InformationElement as
>   range, but in NEO we apparently didn't fix that. No idea why.

Makes sense.

> o. zg:hasEventManifestation: rdfs:type? What is that? rdf:type? In our
>   fixed version we just removed this.

Ok, this is a little deeper. I am handling this on IRC with frade.

-- 
Cheers,
Mikkel