SkosDesign/ConceptSemantics - W3C Semantic Web Deployment Wiki

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.

Contents

1. The Issue
2. Giving semantics to skos:Concept
1. Preliminaries
2. Towards OWL semantics for skos:Concept
3. Bridging SKOS modelling with OWL modelling
References

1. The Issue

Issue 54 ConceptSemantics [1] reads:

"What are the semantics of skos:Concept? skos:Concept is currently declared as { skos:Concept rdf:type rdfs:Class . } Is this ok? Is this enough? What about the OWL universe?"

This raises a first problem:

Problem 1: how to give a formal definition of the skos:Concept primitive using RDFS/OWL?

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

Problem 2: what are the possible articulations between objects that are defined in SKOS world (“concept schemes” gathering “concepts”) and objects that are defined in OWL world (“ontologies” gathering “classes”, “properties” and “individuals”)

2. Giving semantics to skos:Concept

Preliminaries

Existing (informal) semantics of SKOS concept:

SKOS specification [3] gives the definition "An abstract idea or notion; a unit of thought." following [4], for which a concept is a "unit of thought. The semantic content of a concept can be re-expressed by a combination of other and different concepts, which may vary from one language or culture to another. Concepts exist in the mind as abstract entities which are independent of the terms used to label them".
SKOS guide gives a clarification [5]: "SKOS Core allows you to model a set of concepts (essentially a set of meanings) as an RDF graph. Other RDF applications, such as FOAF, allow you to model things like people, organisations, places etc. as an RDF graph. Technically, SKOS Core introduces a layer of indirection into the modelling…So, for a resource of type skos:Concept, any properties of that resource (such as creator, date of modification, source etc.) should be interpreted as properties of a concept, and not as properties of some 'real world thing' that that resource may be a conceptualisation of." There is an example, where an instance of foaf:Person (which is an instance of owl:Class, as defined in [6]) is the dc:creator of an instance of skos:Concept.

Semantics of RDFS/OWL Classes:

In RDFS Semantics [7] a class is a "resource which represents a set of things in the universe which all have that class as the value of their rdf:type property"
In OWL Overview [8] "A class defines a group of individuals that belong together because they share some properties." Classes have OWL individuals as members (in OWL-Full, these members can be classes as well).

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

Proposal 1: skos:Concept rdf:type rdfs:Class. shall be added to the SKOS semantics

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.

Proposal 2: skos:Concept rdf:type owl:Class shall be added to the SKOS semantics. As RDFS class membership is trivial and every OWL class is an RDFS class (OWL Reference, [9]) this statement can replace the one of proposal 1

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”:

the documents that have this concept as subjects (as defined e.g. by the “literary warrant” in library science) by means of skos:subject in SKOS
the “real things” that can constitute the reference of the concept, e.g. all cars constitute the reference of ex:Car.

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

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 as extra labelling properties for instance.
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
Ontological commitment as standard: SKOS users can rely on work done by the SWD WG to frame such a mixing of OWL and SKOS

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

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]

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]

attachment:solution2-variant1.png

Pros:

No properties linking SKOS objects to other ojects “outside of SKOS”
User benefits from semantic clarification work done by WG on the link and this new skos:Entity class (e.g. it is disjoint from skos:Concept, etc.)

Cons:

We have to do this additional semantic clarification work (only name and vague semantics are present in mails)
We re-introduce messing SKOS and OWL missions: some SKOS entities will be OWL classes

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]

attachment:solution2-variant2.png

Pros:

No strong meta-level commitment: there is just "something out there" that is common the the skos:Concept and the owl:Class being defined
Compatible with knowledge primitives other than skos:Concept and owl:Class

Cons:

One additional step in the RDF graphs involved
Complexity of modelling: use of blank node and resource without explicit semantic type is not really trivial. And hubjects are just a part of Bernard’s proposal, which goes beyond

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.

attachment:solution3.png

Pros:

Keeps simplicity for one very important part of the anticipated use cases (SKOS definitions of OWL classes)

Cons:

Forces user to make different modelling choices, depending on the resource he wants to define with both OWL and SKOS features

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.

attachment:solution4.png

Pros:

Keeps simplicity for one very important part of the anticipated use cases (labelling properties)
We can keep the original SKOS semantics for properties and introduce a disjointness axiom between owl:Class and skos:Concept

Cons:

Forces user to make different modelling choices, depending on the modelling aspect he wants to use
Could force users that wants to use a quite complete set of SKOS constructs for their OWL-defined objects to turn to different choices for a same application, unless we make both solution 1 and 2 usable for the case of SKOS properties that do not have skos:Concept as rdfs:domain