This is an archive of an inactive wiki and cannot be modified.

This page provides some discussion guide on giving OWL semantics to skos:concept, and bridging SKOS modelling with OWL one, for Amsterdam F2F meeting. It relates to ISSUE-54: ConceptSemantics.

1. The Issue

Issue 54 ConceptSemantics [1] reads:

This raises a first problem:

Also, because of discussions on the SWD and ESW-Thes mailing list, a second problem emerged, linked to the wish to use SKOS features at the same time as standard RDFS or OWL ontology features [2]:

2. Giving semantics to skos:Concept


Existing (informal) semantics of SKOS concept:

Semantics of RDFS/OWL Classes:

Towards OWL semantics for skos:Concept

Can we say skos:Concept rdf:type rdfs:Class? According to RDFS semantics, yes: it actually naturally comes from any statement that links a specific SKOS concept to skos:Concept via rdf:type

Can we say skos:Concept rdf:type owl:Class? According to OWL definition for a class, yes. The class skos:Concept is the group of individuals that belong together because they are units of thought forming the elements knowledge organization schemes as modelled in SKOS.

Can we compare the set of OWL classes with the set of SKOS concepts?

The SKOS guide example previously mentioned gives a first answer on how to link some individuals to OWL class. It avoids committing however to the special cases where one wants to “bridge” (eventually by identity) standard OWL modelling of ontologies and knowledge bases (especially OWL classes) with SKOS modelling of general knowledge organization systems.

Actually it brings additional ambiguity: according to SKOS guide [5], a resource of type skos:Concept is a “conceptualization” of a real thing, while, according to common ontology definitions, an ontology is a “ specification of conceptualization”. The notion of “concept” may sound quite close to the one of “class”…

OWL classes are strongly linked to an “extension” : the set of their instances. Formally, an instance of skos:Concept (ex:Car) is not defined to have such instances in SKOS: a SKOS concept is supposed to be an individual element. Yet it can be linked to two types of “extensions”:

But none of these “extensions” can define a SKOS concept the way an OWL class is defined: books are not instances of a subject in the sense of rdf:type, and a “reference” is not easy to determine for all SKOS concepts, e.g. abstract things like “freedom” - as opposed to tangible ones as “cars”.

So generally we cannot say that all SKOS concepts are OWL classes. In terms of formal semantics we would not have skos:Concept rdfs:subClassOf owl:Class. Now, do we have skos:Concept owl:disjointWith owl:Class, i.e. can we allow some OWL classes to be considered as SKOS concepts and vice versa, or not?

3. Bridging SKOS modelling with OWL modelling


There is no formal requirement for it in SKOS use cases [10], but some mails on the SWD and SKOS list hint at potential requirements:

  1. A general strategic requirement, as expressed by Daniel [11]. "I thought the goal of SKOS is to "provide a standard way to represent knowledge organization systems." Ontologies certainly fall under that umbrella. Some of the SKOS model is certainly very relevant to people building ontologies."

  2. Daniel and the RadLex use case "In the RadLex use case, for example, "terms" are entities in reality, such as blood vessels. These are linked together via relations such as "part-of" and "continuous-with"." [12] "To me, "term" is the name for something. "Concept" is something that is someone's head. "Entity" is something that exists in reality. There are certainly communities who need to describe things, names of things, and both (in the case of RadLex). Ideally, SKOS should be able to be useful to these communities." [11]

  3. Kjetil and myOpera/POWDER cases. "My idea is to use SKOS for tags, but add a mapping to something else, like a foaf:Person." [13] The discussion on POWDER use case is available at [14,15]; a similar case was raised by Richard Cyganiak on the SKOS list [16]

  4. Informal discussions on interest for SKOS. "I presented SKOS to a biomedical workshop this week, and it seems that some people wished to use SKOS, but on 'real' ontologies they were developing." [Antoine, 2] Also: "While OWL statements are always domain 'object' specific and not always about disambiguating natural language 'terms' .. when the object of a OWL declaration is ALSO a term in a Common Vocabulary .. SKOS helps explain how a set of specific national language terms / symbols are used in that community of practice." [Carl Mattocks, 17]

Practical needs

  1. use of SKOS to define ontology classes (or instances of classes) by means of SKOS features.
    • to benefit from SKOS rich labelling properties, as mentioned in “OWL-DL Compatibility” wiki page [18] about the possibility to make skos:prefLabel a specialization of rdfs:label: ex:Foo rdf:type owl:Class; skos:prefLabel "Foo".

    • to insert existing owl:Class (e.g. exOnt:Planet) and instances (exOnt:Venus) into a thesaurus-like thematic structure (exOntVenus skos:broader exOnt:Planet, exOnt:Planet skos:broader exTh:Astronomy), which could be very useful to develop browsers more useful for humans [2]

  2. link instances of skos:Concept with instances of owl:Class that seems to be “semantically related” (e.g. a skos:Concept henryVIIIConcept with a foaf:Person henryVIIIPerson)

In some of these cases, the direct application of SKOS primitives to instances of owl:Class could cause these instances of owl:Class to be also classified as instances of skos:Concept according to the semantics of SKOS [19].

Possible solutions

Solution 1: instances of owl:Class (or rdf:Property or owl:Individual) are allowed to be instances of skos:Concept. There is no disjointness between owl:Class and skos:Concept, and skos:prefLabel and all others SKOS properties can be attached to classes defined in OWL ontologies.

"if there is a modeling distinction, there is no [formal] exclusion. You can have skos:Concepts (my:Car rdf:type skos:Concept) that are also RDFS/OWL classes (ex:Car rdf:type rdfs:Class) so that you can create 'objects' which are classified under it (ex:danielsCar rdf:type ex:car)." [Antoine,20]



Solution 2: instances of owl:Class/rdf:Property/owl:Individual and instances of skos:Concept are “bridged” via a dedicated property.

Proposed by Dan Brickley, [24]



Problem: what are the semantics and proper name for such a link? It corresponds to something like “reference”: a link from a concept to a “real” thing (or set of “real” things) it denotes.

"one of the property names Alistair and I were throwing around for this was "skos:as" (inverse: skos:it). This would link between inviduals ("dan") and classes ("Person") and corresponding topics in a SKOS scheme:" [Dan, 24]

<owl:Class rdf:ID="Person"> 
  <skos:as skos:prefLabel="Person" skos:altLabel="Guy"/>

(SKOS list has previous discussions on the topic of skos:it/skos:as [25, 26]; skos:denotes, skos:represents and skos:intends were refused)

There are actually objections to a link with such “denotation” interpretation: "So I think that the word "denotes" to connect a thesaurus-theoretic and a ontology-theoretic point of view is dangerous - as in logic and mathematics this usually signifies semantics - we are not (should not) be saying that the class provides a semantics for the concept." [Brian Matthews, one mail in [25,26] threads]

Variant 1 for Solution 2: Same pattern, but introducing skos:Entity as a sibling of skos:Concept to type the “real things” that are denoted by SKOS concepts. SKOS properties (especially the labelling ones) can be applied to both concepts and entities. Proposed by Daniel [27,28]



Variant 2 for Solution 2: Different pattern: the skos:Concept and the owl:Class both refer to a same blank node that is interpreted as an abstract subject (treated as a blank node) they are both representation of. Introduced in many posts on the SKOS lists by Bernard Vatant, also at [29]



Solution 3, mixing 1 and 2 depending on the “nature” of the object considered in the OWL world. Only the OWL-defined resources that are of type owl:Class can be SKOS-defined according to solution 1, the others must be SKOS-defined according to solution 2.

It is easier to keep the line blurred when we have things defined as “concepts” and “sets”. Cf. "dc:creator test": the dc:creator of an owl:Class can also be the dc:creator of a “corresponding” skos:Concept.



Solution 4, mixing 1 and 2 depending on the SKOS constructs that are used for the SKOS-definition of the OWL-object. Only the SKOS properties that do not have skos:Concept as rdfs:domain can be directly applied to OWL-defined objects. For the others, the pattern of solution 2 must be chosen.