Events Ontology

kamstrup: I'll start drafting this on LGO. See full spec link above.

---

RainCT: Any progress on this? I'd be nice to have wiki pages or something where we can start discussing it.

---

kamstrup: Actually I have been thinking a great deal about this the last few days. I'll update the wiki page later today...

---

kamstrup: Spec updated on LGO

---

thekorn: okidoki, @kamstrup: has there been any (implementation) progress on this yet?
I think this should be one of the things we should work on for a 0.{4,5} release, and I'm wondering how much work we need to put into it in order to have a sane and powerful solution, which works for the python part of zeitgeist as well as for some sort of libzeitgeist.
So I've a few questions for now:
 * using this trig format seems to be a reasonable way, is there some kind of "write your own ontology 101"-tutorial somewhere, does a parser module for python (C/Java/etc.) exist for this format? Or do we need to work on this first?
 * as far as I understand there are only a few Definitions which are zeitgeist specific, we will inherit most of the stuff (like Images, MediaFiles, etc.) from existing ontologies, correct?
 * I think we should split this blueprint up into (at least) two parts,
   1.) the ontology
   2.) the implementation
   we can work on both parts in parallel, as long as we agree how we define our ontology. does this make sense?

----

kamstrup: @thekorn: You can look at http://sourceforge.net/apps/trac/oscaf/browser/trunk/ontologies/nmm/nmm.trig [1] for example, I don't think it's that hard to reverse engineer the format. I think the may be something along the lines of ontologies-101 on KDE techbase, but I am not sure...

About using existing parsers - I think that the current light/no-dependencies aspect of the core Zeitgeist package is a super important property to maintain, thus using third party libs should be a last resort. I am not sure Python ships with a trig parser, but implementing a parser that can understand the Nepomuk ontologies (and our own) shouldn't be that hard I think...

About 1) and 2) - I think it makes sense, but let's keep the full picture on http://live.gnome.org/Zeitgeist/Blueprint/EventOntology so we have a shared vision.

[1]: The OSCAF project on SF maintains all the Nepomuk ontologies

----

thekorn: I've linked this blueprint to a branch where I started a definition of our ontology in extras/zeitgeist.trig
@kamstrup: can you please check if I'm on the right path here?

----

kamstrup, @thekorn: It seems that you are mapping the Python structure from our datamodel directly to the ontology, that was not what I had in mind. There is a well hidden comment on http://zeitgeist-project.com/docs/0.3.2/dbus_api.html#index-0 that hints on my idea, but I have not been good enough to communicate this, sorry.

We should not model datamodel.py, it should be the other way around really. datamodel.py models the ontology and then adds some handy Python-stuff. The idea is that an interpretation generally map to a nie:InformationElement while a manifestation generally map to a nie:DataObject (see http://www.semanticdesktop.org/ontologies/nie/). So:

zg:Event a rdfs:Class .

zg:EventInterpretation a rdfs:Class
    rdfs:subclassof nie:InformationElement

zg:EventManifestation a rdfs:Class
    rdfs:subclassof nie:DataObject

zg:hasIntepretation a rdfs:Property
    rdfs:domain zg:Event ;
    rdfs:range zg:EventInterpretation ;
    rdfs:comment "docstring of this symbol" ;
    nrl:maxCardinality "1"^^xsd:nonNegativeInteger

...

zg:hasSubject a rdfs:Property
    rdfs:domain zg:Event ;
    rdfs:range rdfs:Resource

...

We don't need zg:SubjectInterpretation and zg:SubjectManifestation because we use nie:{InformationElement,DataObject} directly.

I may be able to put up my take on the whole thing later tonight...

----

kamstrup: I just pushed my own first shot to lp:~zeitgeist/zeitgeist/ontology_definition, look at extra/zeitgeist.trig... It's still not completely thought through and it probably requires some RDFS/Nepomuk background to get where I am coming from... I need to document this a bit more...