ConfigurationManagement

From W3C Wiki

Configuration Management for RDFS/OWL Ontologies

Principles:

  • All configuration information should be statements about statements.
  • Version an ontology or a graph, but never version a named class, property or individual.
  • Use modularisation to define granularity of configuration management.

Standard prefixes are used. temp: is used to indicated proposals for useful terms, as yet with no home.

Configuration Management for a Monolithic Ontology

By 'monolothic ontology' I mean an ontology with no modules.

All configuration management (except deprecation and replacement of classes/properties) is done at the level of the ontology.

Basic configuration information (Turtle):


<http://www.example.com/ExampleOntology> a owl:Ontology;
  dc:title 'The Example Ontology';
  dc:description 'An ontology to use as an example for doing configuration management.';
  dc:creator 'Alistair Miles';
  dc:rights <http://creativecommons.org/licenses/by/1.0/>;
  foaf:maker
  [
    a foaf:Person;
    foaf:name 'Alistair Miles';
    foaf:mbox <a.j.miles@rl.ac.uk>;
  ];
  temp:editor
  [
    a foaf:Person;
    foaf:name 'Alistair Miles';
    foaf:mbox <a.j.miles@rl.ac.uk>;
  ];
  dcterms:issued '2005-06-06';
  dcterms:modified '2005-07-03';
  temp:documentation <http://www.example.com/documents/ExampleOntology/guide>;
.


Basic versioning information (Turtle):


<http://www.example.com/ExampleOntology>
  dcterms:hasVersion <http://www.example.com/ExampleOntology-1>;
  dcterms:hasVersion <http://www.example.com/ExampleOntology-2>;
  temp:currentVersion <http://www.example.com/ExampleOntology-2>;
.

<http://www.example.com/ExampleOntology-1>
  dcterms:isVersionOf <http://www.example.com/ExampleOntology>;
.

<http://www.example.com/ExampleOntology-2>
  dcterms:isVersionOf <http://www.example.com/ExampleOntology>;
  owl:priorVersion <http://www.example.com/ExampleOntology-1>;
.


Each ontology version is a static (unchanging) resource. The ontology itself is a dynamic (changeable) resource. Ontology versions are snapshots of an ontology. An ontology version is a named graph.

An HTTP GET request to the URI of an ontology version (e.g. <http://www.example.com/ExampleOntology-1>) should return a 200 response code and a representation of the set of RDF statements comprising that ontology version, serialised using an RDF syntax with a registered MIME type.

An HTTP GET request to the URI of an ontology (e.g. <http://www.example.com/ExampleOntology>) should return a redirect (303?) to the URI of the current version (e.g. <http://www.example.com/ExampleOntology-2>).

This prevents ambiguous provenance information.

(Or is it OK for a GET against the URI of the ontology to return the same response as a GET against the URI of the current ontology version?)

Representing status (stability) of an ontology (Turtle):


<http://www.example.com/ExampleOntology>
  temp:stability temp:unstable;
.


For each defined stability level, it should be clearly defined what types of changes are allowed.

Deprecation of classes and properties (Turtle):


ex:someProp a owl:DeprecatedProperty;
  dcterms:isReplacedBy ex:anotherProp;
.

ex:anotherProp a rdf:Property;
  dcterms:replaces ex:someProp;
.
 
ex:someClass a owl:DeprecatedClass;
  dcterms:isReplacedBy ex:anotherClass;
.

ex:anotherClass a rdfs:Class;
  dcterms:replaces ex:someClass;
. 


No other configuration statements should be made at the level of the class/property.

Representing and documenting changes (Turtle):


<http://www.example.com/ExampleOntology>
  temp:change
  [
    rdfs:comment 'Initial version';
    foaf:maker
    [
      foaf:name 'Alistair Miles';
      foaf:mbox <a.j.miles@rl.ac.uk>;
    ]
    temp:from rdf:nil;
    temp:to <http://www.example.com/ExampleOntology-1>;
    dc:date '2005-06-16T19:20+01:00';
  ];
  temp:change
  [
    rdfs:comment 'Deprecated classes xyz, changed domain of property p ...';
    foaf:maker
    [
      foaf:name 'Alistair Miles';
      foaf:mbox <a.j.miles@rl.ac.uk>;
    ]
    temp:from <http://www.example.com/ExampleOntology-1>;
    temp:to <http://www.example.com/ExampleOntology-2>;
    dc:date '2005-07-03T19:20+01:00';
  ];
.


Representing the relationship between a class/property and the authoritative description of a class/property (Turtle):


ex:someProp rdfs:isDefinedBy <http://www.example.com/ExampleOntology> .
 
ex:someClass rdfs:isDefinedBy <http://www.example.com/ExampleOntology> .


An HTTP GET request to the URI of a class or property should return a redirect (303 see other) to the URI as specified by the rdfs:isDefinedBy statement.

Finer-Grained Configuration Management Using Modules

For some vocabularies you want to represent configuration information at a finer level. To do this, factor an ontology as a set of modules, and record configuration management information for each module.

This allows different parts of an ontology to evolve at different rates, and under different editors.

Modularising an ontology (Turtle):


<http://www.example.com/ModularOntology/moduleA> a owl:Ontology .

<http://www.example.com/ModularOntology/moduleB> a owl:Ontology .

<http://www.example.com/ModularOntology> a owl:Ontology;
  owl:imports <http://www.example.com/ModularOntology/moduleA>;
  owl:imports <http://www.example.com/ModularOntology/moduleB>;
.


Representing the relationship between a class/property and the authoritative description of a class/property (Turtle):


ex:fooProp rdfs:isDefinedBy <http://www.example.com/ModularOntology/moduleA> .
 
ex:FooClass rdfs:isDefinedBy <http://www.example.com/ModularOntology/moduleB> .


All configuration information should be represented as statements about the relevant module. E.g. (Turtle):


<http://www.example.com/ModularOntology/moduleA>
  # Basic metadata
  dc:title 'The Example Modular Ontology: Module A';
  dc:description 'A module of an ontology to use as an example for doing configuration management for modular ontologies.';
  dc:creator 'Alistair Miles';
  dc:rights <http://creativecommons.org/licenses/by/1.0/>;
  foaf:maker
  [
    a foaf:Person;
    foaf:name 'Alistair Miles';
    foaf:mbox <a.j.miles@rl.ac.uk>;
  ];
  temp:editor
  [
    a foaf:Person;
    foaf:name 'Alistair Miles';
    foaf:mbox <a.j.miles@rl.ac.uk>;
  ];
  dcterms:issued '2005-06-06';
  dcterms:modified '2005-07-03';
  temp:documentation <http://www.example.com/documents/ModularOntology/moduleA/guide>;
  temp:stability temp:stable;
  # Versioning information
  dcterms:hasVersion <http://www.example.com/ModularOntology/moduleA-1>;
  dcterms:hasVersion <http://www.example.com/ModularOntology/moduleA-2>;
  temp:currentVersion <http://www.example.com/ModularOntology/moduleA-2>;
  temp:change
  [
    rdfs:comment 'Initial version';
    foaf:maker
    [
      foaf:name 'Alistair Miles';
      foaf:mbox <a.j.miles@rl.ac.uk>;
    ]
    temp:from rdf:nil;
    temp:to <http://www.example.com/ModularOntology/moduleA-1>;
    dc:date '2005-06-16T19:20+01:00';
  ];
  temp:change
  [
    rdfs:comment 'Deprecated classes xyz, changed domain of property p ...';
    foaf:maker
    [
      foaf:name 'Alistair Miles';
      foaf:mbox <a.j.miles@rl.ac.uk>;
    ]
    temp:from <http://www.example.com/ModularOntology/moduleA-1>;
    temp:to <http://www.example.com/ModularOntology/moduleA-2>;
    dc:date '2005-07-03T19:20+01:00';
  ].

<http://www.example.com/ModularOntology/moduleA-1>
  dcterms:isVersionOf <http://www.example.com/ModularOntology/moduleA>;
.

<http://www.example.com/ModularOntology/moduleA-2>
  dcterms:isVersionOf <http://www.example.com/ModularOntology/moduleA>;
  owl:priorVersion <http://www.example.com/ModularOntology/moduleA-1>;
.


The HTTP behaviour of ontology modules should be the same as for ontologies. (An ontology module is an ontology).

For a modular ontology, the root module (i.e. the ontology itself) only changes when a new module is imported, or an existing import is removed.

Finest-Grained Configuration Management Using Per-Term Modules

To represent configuration information at the finest level, modularise the ontology so that there is a module for each individual class or property. This allows you to track changes to the description of an individual class or property.

Using a Named Graph Syntax for Configuration Management

As an alternative to doing redirects from ontology URIs to ontology version URIs, what if an HTTP GET request to the ontology URI returned something like (TriG) ...


#
# default graph
{
<http://www.example.com/ExampleOntology> a owl:Ontology;
  dc:title 'The Example Ontology';
  dc:description 'An ontology to use as an example for doing configuration management.';
  dc:creator 'Alistair Miles';
  dc:rights <http://creativecommons.org/licenses/by/1.0/>;
  foaf:maker
  [
    a foaf:Person;
    foaf:name 'Alistair Miles';
    foaf:mbox <a.j.miles@rl.ac.uk>;
  ];
  temp:editor
  [
    a foaf:Person;
    foaf:name 'Alistair Miles';
    foaf:mbox <a.j.miles@rl.ac.uk>;
  ];
  dcterms:issued '2005-06-06';
  dcterms:modified '2005-07-03';
  temp:documentation <http://www.example.com/documents/ExampleOntology/guide>;
  dcterms:hasVersion <http://www.example.com/ExampleOntology-1>;
  dcterms:hasVersion <http://www.example.com/ExampleOntology-2>;
  temp:currentVersion <http://www.example.com/ExampleOntology-2>;
  temp:change
  [
    rdfs:comment 'Initial version';
    foaf:maker
    [
      foaf:name 'Alistair Miles';
      foaf:mbox <a.j.miles@rl.ac.uk>;
    ]
    temp:from rdf:nil;
    temp:to <http://www.example.com/ExampleOntology-1>;
    dc:date '2005-06-16T19:20+01:00';
  ];
  temp:change
  [
    rdfs:comment 'Deprecated classes xyz, changed domain of property p ...';
    foaf:maker
    [
      foaf:name 'Alistair Miles';
      foaf:mbox <a.j.miles@rl.ac.uk>;
    ]
    temp:from <http://www.example.com/ExampleOntology-1>;
    temp:to <http://www.example.com/ExampleOntology-2>;
    dc:date '2005-07-03T19:20+01:00';
  ]
.

<http://www.example.com/ExampleOntology-1>
  dcterms:isVersionOf <http://www.example.com/ExampleOntology>;
.

<http://www.example.com/ExampleOntology-2>
  dcterms:isVersionOf <http://www.example.com/ExampleOntology>;
  owl:priorVersion <http://www.example.com/ExampleOntology-1>;
.
}

#
# version 1 graph
<http://www.example.com/ExampleOntology-1>
{
  #All statements about classes, properties etc.
}

# version 2 graph
<http://www.example.com/ExampleOntology-2>
{
  #All statements about classes, properties etc.
}


... ?

... or the URI of an ontology could dereference to a SPARQL service that had the equivalent provenance information already loaded ...?