SKOS and OWL DL Compatibility
This page describes some of the choices, consequences and trade-offs for representing SKOS within OWL DL.
The formal definition of the SKOS Core vocabulary, as currently given by , makes some assertions using the OWL vocabulary.
For example, the following assertions are currently made (assume conventional namespace prefixes):
skos:broader rdf:type owl:TransitiveProperty; owl:inverseOf skos:narrower. skos:related rdf:type owl:SymmetricProperty.
However, the basic typing information is still given in RDF/S only, for example  asserts:
skos:Concept rdf:type rdfs:Class. skos:prefLabel rdf:type rdf:Property.
In order to use the SKOS Core vocabulary within an OWL DL context:
Each class or property would have to be given an explicit OWL type - one of owl:Class, owl:ObjectProperty, owl:DatatypeProperty, owl:AnnotationProperty etc.
- The assertions made would have to conform to the syntactic constraints imposed by OWL DL.
For SKOS classes (skos:Concept, skos:ConceptScheme etc.) adding the required extra assertion is uncontroversial, e.g.:
skos:Concept rdf:type owl:Class.
For SKOS properties (skos:prefLabel, skos:broader etc.) a choice would have to be made between alternative OWL property types, which is fairly straightforward in some cases but not in others.
For example, the following assertions should be fairly uncontroversial:
skos:broader rdf:type owl:ObjectProperty. skos:narrower rdf:type owl:ObjectProperty. skos:related rdf:type owl:ObjectProperty.
However, for the lexical labelling properties skos:prefLabel, skos:altLabel and skos:hiddenLabel, there is a choice between the owl:DatatypeProperty and owl:AnnotationProperty types.
Note that the following syntactic constraints apply for OWL DL:
Datatype properties can only be used to make assertions about individuals in an ontology, not classes or other properties.
- Annotation properties cannot be involved in property axioms (this includes sub-property declarations as well as domain and range constraints).
If the SKOS lexical labelling properties were typed as datatype properties, the first constraint means that, for example, the following graph would not be valid OWL DL:
ex:Foo rdf:type owl:Class; skos:prefLabel "Foo". ex:bar rdf:type owl:ObjectProperty; skos:altLabel "bar".
I.e. it would not be possible to use the SKOS labelling properties to label classes or properties in an OWL ontology.
However, it would be possible to involve SKOS lexical labelling properties in property axioms, for example:
ex:mySpecialLabel rdf:type owl:DatatypeProperty; rdfs:subPropertyOf skos:prefLabel.
It is expected that the declaration of sub-properties and sub-classes of SKOS properties and classes will be the primary means by which application-specific extensions of SKOS are defined - this technique is informally known as "extension by refinement".
If, on the other hand, the SKOS lexical labelling properties were typed as annotation properties, the first example above would become syntactically valid OWL DL. I.e. it would be possible to use the lexical labelling properties to "annotate" any type of ontology primitive.
Note that the property rdfs:label is assumed to be an annotation property in OWL, and therefore this choice would make the SKOS lexical labelling properties directly analogous with rdfs:label.
However,  currently asserts that:
skos:prefLabel rdfs:subPropertyOf rdfs:label. skos:altLabel rdfs:subPropertyOf rdfs:label. skos:hiddenLabel rdfs:subPropertyOf rdfs:label.
Because rdfs:label is assumed to be an annotation property, these assertions can never be valid OWL DL. Furthermore, if the SKOS lexical labelling properties were typed as annotation properties, it would not be possible to extend by refinement, as illustrated in the second example above.
To summarise, declaring the SKOS lexical labelling properties skos:prefLabel, skos:altLabel and skos:hiddenLabel to be datatype properties would allow extension by refinement in OWL DL, but would restrict their use to ontology individuals only. Declaring them to be annotation properties would allow their use for any ontology primitive in OWL DL, but would mean that any extension by refinement was not valid in OWL DL.
Similar considerations apply to any property in the SKOS Core vocabulary that might be modelled as an annotation property.
[AlistairMiles: I made an attempt to summarise these issues for the previous working group, and to describe one of the potential solutions - see http://isegserv.itd.rl.ac.uk/cvs-public/~checkout~/skos/drafts/owlImport-7.html?rev=1.1 - beware, the discussion is far from complete.]