Events Ontology

Registered by Seif Lotfy

We need to set up an ontology for describing events and have a documented set of event URIs for interpretation and manifestations in the DB.

The ontology should be then proposed to Tracker and Nepomuk so that we can have a unified way of playing with each other.

We need this in as early as possible as it affects the events we have stored - it might change the URLs of interpretations and manifestations.

Blueprint information

Mikkel Kamstrup Erlandsen
Mikkel Kamstrup Erlandsen
Needs approval
Markus Korn
Series goal:
Accepted for 0.3
Milestone target:
Started by
Mikkel Kamstrup Erlandsen
Completed by
Seif Lotfy

Related branches



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 [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 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 that hints on my idea, but I have not been good enough to communicate this, sorry.

We should not model, it should be the other way around really. 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 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...


Work Items

This blueprint contains Public information 
Everyone can see this information.