Ontology Alignment Evaluation Initiative - OAEI-2011 Campaign

A note about handling SKOS

Ontology matchers tend to require ontologies to be matched (this is the least). Yet SKOS thesauri are not really ontologies. There are a few options for handling this.

Direct handling of SKOS

Since version 4.1 (or the current version under svn), the Alignment API is able to handle SKOS thesauri thanks to its Ontology wrapper and the SKOS API or our own Lite SKOS wrapper (advised).

Both wrappers allow for presenting a SKOS thesaurus as an ontology under the Ontowrap abstract API.

Using the Alignment API integrated SKOSAPI (SKOSLite)

In order to use the SKOS Lite wrapper, it is sufficient to set the default factory to the SKOSLite one, and ontowrap will use it. For this purpose, begin your code with:

fr.inrialpes.exmo.ontowrap.OntologyFactory.setDefaultFactory( "fr.inrialpes.exmo.ontowrap.skoslite.SKOSLiteOntologyFactory" );

Using the Manchester SKOS API (working but obsolete)

There are two reasons not to use this wrapper: it is four times slower than SKOSLite and it relies on an old version of the OWL API (at the time of writing). There is one reason to use it: it may be more complete than the SKOSLite interface. But in this case, it may be preferable to use it out of ontowrap.

The main problem for using the alignment API with the SKOS API is that the SKOS API is using an intermediate version of the OWL API (2.0), which is incompatible with the first one (1.0), instead of the last one (3.0).

To solve this:

• checkout the Alignment API from the source ()
• download this zip file in lib/
• remove the OWL API 1 from lib ($ rm -rf lib/owlapi1)
• In src/fr/inrialpes/exmo/ontowrap/OntologyFactory.java, replace

      private static String API_NAME="fr.inrialpes.exmo.ontowrap.owlapi30.OWLAPI3OntologyFactory";
  

  by

      private static String API_NAME="fr.inrialpes.exmo.ontowrap.skoslite.SKOSLiteOntologyFactory";
  

• Recompile

Translation from SKOS to OWL

People may want to translate SKOS thesauri into OWL ontologies. We are aware of at least two ways to achieve this.

Use the converted ontologies provided for the food, environment and library test sets. According to the description provided by Antoine Issac (older version here), they obey the following rules:

• instances of skos:Concept are converted into instances of owl:Class;
• skos:prefLabel, skos:altLabel and skos:hiddenLabel statements are converted to rdfs:label statements, which removes the subtle distinctions that exist between these different properties (for instance, altLabels are often not synonyms at all);
• various kind of skos:notes are converted to rdfs:comments;
• skos:broader statements are converted into rdfs:subClassOf statements;
• skos:related statements are converted into rdfs:seeAlso statements.

Use the tool developed by Miklos Nagy for the same purpose. It uses the following set of rules (see also Miklos provided short description):

• skos:Concept -> owl:Class
• skos:prefLabel -> rdfs:label
• skos:altLabel -> rdfs:label
• skos:broader -> rdfs:subClassOf
• skos:definition -> rdfs:comment
• skos:scopeNote -> rdfs:comment

Antoine also plans to evaluate alignments that use OWL properties as mapping links. The following interpretations will be made of OWL data sent back by participants:

• instances of owl:Class will be interpreted as instances of skos:Concept;
• owl:equivalentClass statements will be interpreted as skos:exactMatch statements;
• if participants match the original concepts (as instances of skos:Concept and not owl:Class) using owl:sameAs, these statements will also be interpreted as skos:exactMatchs;
• rdfs:subClassOf statements will be interpreted as skos:broaderMatch statements;
• rdfs:seeAlso statements will be interpreted as stitch:relatedMatch statements;