This page provides a shortened version of the patterns presented in the context of skos:Concept semantics, http://www.w3.org/2006/07/SWD/wiki/SkosDesign/ConceptSemantics. It relates to ISSUE-54: ConceptSemantics. and Alistair's patterns as indicated in this mail

Bridging SKOS modelling with OWL modelling

Motivation

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:

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."
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]
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]
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

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]
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]

attachment:solution1.png

Pros:

It is compatible with current semantics of SKOS concept
Simplicity: the solution is the simplest to use for these who just want to use SKOS properties e.g. as extra labelling properties
Conciseness: there is no redundancy between what is defined for the “standard” ontological aspects and what is defined for the SKOS-oriented ones. No new object (RDF resource) is created to represent the class and the related SKOS information

Cons:

OWL-Full (not so important now that the issue is postponed, but still interesting to mention)
Additional commitment on the agenda SWD WG, indeed messing OWL and SKOS missions: OWL for logic-oriented modelling, SKOS for more informal (incl. linguistic) aspects of the semantics [21,22].
Re-usability and authority: there could be cases where the developers of the SKOS aspects and the OWL ones are not the same (typically when you want to link your work on a SKOS representation to an already existing OWL one). Mixing the different aspects eventually leads to disappearance of benefits of re-using the same objects.
This solution is especially hard to buy for instances of owl:Individuals that represent “tangible” things. "how can it be that a concept is also something tangible such as a car?" [Daniel, 23] Cf. also “dc:creator-test” in SKOS guide: the dc:creator of a car is likely to be different from the dc:creator of a “corresponding” car SKOS concept.

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

Proposed by Dan Brickley, [24]

attachment:solution2.png

Pros:

Not mixing OWL and SKOS missions, only bridging. SWD WG make a smaller commitment, in the boundaries of the WG’s scope.
Can be OWL-DL (not so important now the issue is postponed, but still interesting to mention)
Ease of modelling: Users can deal with separate object with simple interpretation, no unexpected logical consequences

Cons:

WG is to find names and (still) proper semantic foundation (is “link between a SKOS concept and its OWL reference” enough as a definition for the property??)
Less conciseness: duplication of “corresponding concept” RDF resources, users/developers have to deal with longer path in RDF graph queries
THIS SOLUTION IS RULED OUT IF WE DON'T WANT TO INTRODUCE NEW VOCABULARY: or as in Alisatir's basic "transform" pattern there is just no connection.

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"/>
</owl:Class>

(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]

Solution 3, 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

attachment:solution3.png

Pros:

Keeps simplicity for one very important part of the anticipated use cases (labelling properties)
We are in OWL-DL

Cons:

Forces user to make different modelling choices, depending on the modelling aspect he wants to use
Could force users that wants to use all SKOS constructs for their OWL-defined objects to make different choices inside a same application.

Solution 4, 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.

attachment:solution4.png