Re: [Tracker] Zeitgeist ontology and Tracker

On Wed, 2011-03-23 at 10:15 +0100, Mikkel Kamstrup Erlandsen wrote:
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.

Yes. That branding has to do with the ontology 'product'. Not with the
specific domain product. They are (like) consortiums.

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)

The maemo ontology is not installed unless you are using Harmattan.

The tracker ontology is the only exception on this rule that we have, it
contains tracker specific things (like tracker:modified, tracker:added,
etc) that are specific and unique to the storage product that you are
using (Tracker) for RDF and SPARQL.

Neither Maemo nor Tracker are ontologies specialized to one purpose,
domain or use-case (like location, multimedia, messaging or events).

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?

Usually in nie:url, but sometimes we allow certain kinds of domain
specific IDs, like ISBN.

For contactUID that's RFC 2426 Sec. 3.6.7, for imID that's ICQ UINs,
Jabber IDs, Skype names etc.

They are properties comparable to nco:phoneNumber: universally well
known, specified, etc.

ISBN is the same kind of property. We don't see zg:eventId that way.

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.

Not a bug, we just so far never needed xsd:long. That's all.

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.

Sound strange to me that you could have an event about something that
isn't a nie:InformationElement. Perhaps events about a nao:Tag?

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.

Sure ok


Philip Van Hoof
freelance software developer
Codeminded BVBA -

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]