Page name: SKOS / Skos2Owl2

SKOS in OWL 2

SKOS in OWL (Full)

SKOS in OWL (DL)

Unexpressed Semantic Conditions:

S12: The rdfs:range of each of skos:prefLabel, skos:altLabel and skos:hiddenLabel is the class of RDF plain literals.

  • In the SKOS data model skos:prefLabel, skos:altLabel and skos:hiddenLabel are defined as sub-properties of rdfs:label. rdfs:label is in turn defined (here) as having rdfs:Literal as its range. The inability to express this semantic condition probably stems from the fact that, in OWL, it is not possible to express that a property P is a sub-property of property T, unless P and T are object- or datatype- properties. skos:prefLabel and the rest are neither. These are in fact annotation properties and in the OWL 2 spec rdfs:Label is identified as such. Most importantly, OWL 2 allows to specify sub-properties of annotation properties using the SubAnnotationPropertyOf axiom. Therefore, sub-annotation-properties would inherit the range of their parent property (which, in the case of rdfs:Label is rdfs:Literal) and the S12 condition is resolved.

S13: skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise disjoint properties.

  • OWL 2 does not seem to provide for disjoint annotation properties. However it allows for DisjointObjectProperties as well as DisjointDataProperties. It could be worth trying defining these properties as DisjointDataProperties in a pairwise fashion, regardless of the fact that they are annotations. Alternatively they could be defined as datatype properties, but this could cause problems with their hierarchy.

S14: A resource has no more than one value of skos:prefLabel per language tag.

  • This could have been resolved had it been possible to declare an annotation as a functional property. Again, it is possible to define functionality and/or cardinality restrictions on datatype properties in OWL 2 (link).
    {i} This is not quite true, since separate literals per language tag are essentially different literals. We need a way to relate a resource directly with the language tag of its prefLabel. -- DimitriosKoutsomitropoulos 09-07-2009 10:07:53

In summary, all 3 of these semantic conditions can be resolved, by defining the corresponding properties as datatype- ones. However, the sub-property relation to rdfs:Label could be hard to be maintained, if at all.

S27: skos:related is disjoint with the property skos:broaderTransitive.

S36: For any resource, every item in the list given as the value of the skos:memberList property is also a value of the skos:member property.

  • skos:memberList connects an object, say A, with an instance of rdf:List. This means that A is related to all the members of this list at once, in an ordered fashion. Suppose that this list contains three members, X,Y and Z. The relation can be graphically depicted as follows:
    • list.png

    Due to this semantic condition, it should be entailed that A is related to every member of the list separately, through the skos:member property. First, we define a new property, memberList2, as a super-property of skos:memberList. This means that every memberList relation also holds for memberList2. However, memberList does not need to be functional, i.e. it can relate an object to many different values at the same time. Since rdf:first and rdf:rest are properties, let also:

     memberList2 \equiv memberList2 \circ rest
    This achieves to relate A to every blank node (an instance of rdf:List) through memberList2, in an recursive fashion. In addition we define:

     member \equiv memberList2 \circ first
    The role chain above suggests that member relates A to every first element of any list it is related to (since memberList2 is a subproperty of memberList), including the blank nodes-lists. In our example, this means that A is related to X, Y and Z separately, through the member property, and the semantic condition is resolved.

The above method should be tested first though, since it involves built-in RDF properties, such as first and rest, and it is uncertain if such properties can be used inside role-chains. Also, the role-chains above is uncertain whether they violate the partial ordering restriction posed by the correspoding tableau algorithm.
{i} Works with Protege 4 -- DimitriosKoutsomitropoulos 08-07-2009 12:14:56

S46: skos:exactMatch is disjoint with each of the properties skos:broadMatch and skos:relatedMatch.

  • Same as for S27.

Why Full?

SKOS in OWL 1.0 is generally considered to produce OWL Full ontologies. Therefore a subset of the original OWL vocabulary has been proposed (SKOS in OWL DL) that omits the expression of certain semantic conditions (namely S11, S17, S34). Moreover, the SKOS Primer mentions that it is possible within SKOS to treat individuals as concepts or other types of resources, for metamodeling purposes. Next, we see how these issues can be circumvented or resolved in the OWL 2 context.

S11: skos:prefLabel, skos:altLabel and skos:hiddenLabel are each sub-properties of rdfs:label.

SKOS notes and labels are in fact annotation properties, although they can't be defined as such using OWL 1.0. Relating them to rdfs:label, a "bult-in" rdf:Property, is not allowed in OWL DL. However, as seen in the discussion of the S12 condition above, OWL 2 nicely provides for annotation properties and hierarchies within them, resolving this issue.

S17: skos:changeNote, skos:definition, skos:editorialNote, skos:example, skos:historyNote and skos:scopeNote are each sub-properties of skos:note.

skos:note is defined in S16 as an owl:AnnotationProperty, hence the inability to express hierarchies. It can be resolved as in S11, S12 above.

S34: The rdfs:range of skos:memberList is the class rdf:List.

Perhaps this is raised because rdf:List is an instance of rdfs:Class not owl:Class. Strictly speaking, this is not allowed in OWL DL, but usually implementations can do reasoning all the same.

Metamodeling

OWL 2 allows for metamodeling paradigms, such as treating instances as classes or properties as instances and so on. This is usually known as punning.

Redundant Conditions

(Due to OWL Semantics)

See Also

HPCLab Wiki 2010