1. Summary
  2. Files
  3. Support
  4. Report Spam
  5. Create account
  6. Log in

Ontology Maintenance

Each change, update, or new ontology goes the way of a trac ticket. This is where the change is discussed. A ticket should at some point contain a patch or a link to a git branch.


Ontology sources are maintained in a git repository. Each ontology has its own sub-folder which contains the serialized ontology and optional documentation files.


Patches do not have to be perfect but tell exactly what you want to say. We have an ontology language (RDFS, NRL and N3) for a reason: it gives us a clear langauge to speak. Such text is easy to write, but much more precise than prose. Something like this is enough:

I experienced that all people are bananas. Woody Allen also says so. Please change nco, add:

nco:PersonContact rdfs:subClassOf banana:Bananas.
nco:Contact rdfs:comment "All persons are bananas in their brains."

Deprecating Classes and Properties

In the case a class or property needs to be deprecated, use nao:deprecated to annotate it.

Publishing Ontologies

Once our maintenance process has generated a new ontology or a new version, Administrators will release the shared-desktop-ontologies tarball on the sourceforge files from time to time (roughly twice a year). Sebastian Trüg another project member with shell access to the web server will update http://oscaf.sourceforge.net.

Ontologies should be published at http://www.semanticdesktop.org/ontologies/ but haven't been since 2009. The same data as on http://oscaf.sourceforge.net should be there. Simon Scerri from DERI knows how to maintain that server and is working to merge the digi.me work with the OSCAF work (as of 2.10.2012). Once this is done, both versions will be the same again.

Ontology Namespaces

The ontology namespaces follow the scheme http://www.semanticdesktop.org/ontologies/YYYY/MM/DD/ONT#ID], which contains:

When ontologies are updated, the namespace does not change. This is the end of a longer OntologyNamespaceDiscussion and conforms to the best practice set forth by RDF, FOAF, and SKOS (afaik). See OntologyNamespaceDiscussion.

Publishing NRL ontologies consisting of multiple graphs

NRL ontologies can consist of multiple named RDF graphs. we

  • Provide a HTML serialization by default when browsers access the resource identified by the URI of the ontology.
  • Using content-negotiation, differen versions are returned.
  • Ontology data and metadata are available in two RDF/XML files. A TRIG serialization contains both.

The URI of the ontology serialization graph is