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

SKOS ISSUE-39 ConceptualMappingLinks: "Minimal extension" Proposal

Warning: this proposal has been rebuffed in [ discussion on the SKOS list]

This is a proposal for resolution of [ SKOS ISSUE-39]. See also IssuesProcess.

Resolution of this issue should enable SKOS to meet requirement [ R-ConceptualMappingLinks] (see the [ SKOS Use Cases and Requirements] document).

0. Summary

NOTE (from Antoine): this proposal has been written following an informal discussion during a teleconf, involving Guus, Alistair and me (I really cannot find the minutes on the mailing list!). It tries to mirror it as my memories and notes make it possible, but some proposals may reflect my own personal views on the matter.

The main point of this was that SKOS mapping links were very close to the SKOS core one from a semantic point of view. This can be confirmed by a first analysis of the use case where conceptual mapping is involved (see /SkosDesign/ConceptualMapping).

The proposal extends SKOS with the possibility to define conceptual mapping links between SKOS concept coming from different vocabularies. It tries to take into account most of the features of the current SKOS mapping vocabulary [#SWBP-SKOS-MAPPING [SWBP-SKOS-MAPPING]]. This proposal tries to amend the existing SKOS core vocabulary in a minimal way. Whenever it is possible, existing SKOS construct are chosen to represent semantic mapping links. For instance allowing skos:broader statements to hold between concepts from different concept schemes, makes the skosm:broadMatch link redundant.

Also, in a first move, the inclusion of some elements that appear to be less well-defined and raising representation problems is left to discussion.

In the following, the namespace prefix skosm: is used to denote the SKOS mapping namespace

1. Vocabulary

The proposal introduces the following new vocabulary:



No vocabulary from core SKOS namespace is deprecated by this proposal.

The following properties from SKOS mapping namespace are considered 'moved' to SKOS core because they have a 'semantic counterpart' (in brackets) in current SKOS core vocabulary. But in practice, they are deprecated:

skosm:mappingRelation (skos:semanticRelation)

skosm:exactMatch (skos:equivalentConcept)

skosm:broadMatch (skos:broader)

skosm:narrowMatch (skos:narrower)

The following properties from SKOS mapping namespace are 'moved' to SKOS core by anticipating that the solution to [ ISSUE-40 ConceptCoordination] will bring classes similar to the fictive ones presented here in brackets (cf. discussion). But in practice, they are deprecated:

skosm:AND (skos:Intersection)

skosm:OR (skos:Union)

skosm:NOT (skos:Negation)

The following properties are deprecated (see discussion):



2. Axiomatic Triples

RDFS statements:

  skos:equivalentConcept rdfs:subPropertyOf skos:semanticRelationship.
  skos:overlappingConcept rdfs:subPropertyOf skos:semanticRelationship.

NOTE: this implies according to RDFS semantics that they are both instance of rdf:Property, with domain and ranges set as the ones asserted for skos:semanticRelationship

OWL statements:

  skos:equivalentConcept rdf:type owl:TransitiveProperty.
  skos:equivalentConcept rdf:type owl:SymmetricProperty.
  skos:overlappingConcept rdf:type owl:SymmetricProperty.

NOTE: by virtue of RDFS semantics and triples above, these properties should be also asserted as instances of owl:ObjectProperty, if skos:semanticRelationship is such a property.

NOTE: if we allow in the context of [ ISSUE-44 BroaderNarrowerSemantics] skos:broader and skos:narrower to be reflexive, then we can assert the axiomatic triples

  skos:equivalentConcept rdfs:subPropertyOf skos:broader.
  skos:equivalentConcept rdfs:subPropertyOf skos:narrower.

3. Semantic Conditions

@@TODO, left to ISSUE-40 and ISSUE-44? @@

For the moment no semantic condition. Depending on the choices made regarding semantics and coordination constructs, we could have here consistency check of the form: a concept cannot be declared a narrower/equivalent/overlapping concept of another which is a negation of it. But this should first be discussed in the scope of [ ISSUE-40 ConceptCoordination] and [ ISSUE-44 BroaderNarrowerSemantics] (conditions on equivalent/overlappingConcept can be derived from conditions on broader/narrower)

4. Consistent Examples


The example below shows conceptual mapping links between simple concepts.

 ex1:platypus rdf:type skos:Concept;
   skos:prefLabel "platypus"@en;
   skos:inScheme ex:allAnimalsScheme.
 ex1:mammals rdf:type skos:Concept;
   skos:prefLabel "mammals"@en;
   skos:inScheme ex:allAnimalsScheme.
 ex1:animals rdf:type skos:Concept;
   skos:prefLabel "animals"@en;
   skos:inScheme ex:allAnimalsScheme.
 ex1:allAnimalsScheme rdf:type skos:ConceptScheme;
   dc:title "Extensive list of animals"@en.
 ex2:eggLayingAnimals rdf:type skos:Concept;
   skos:prefLabel "animals that lay eggs"@en;
   skos:inScheme ex2:eggSellerScheme.
 ex2:animals rdf:type skos:Concept;
   skos:prefLabel "animals"@en;
   skos:inScheme ex2:eggSellerScheme.
 ex2:eggSellerScheme rdf:type skos:ConceptScheme;
   dc:title "Egg-seller view on animals"@en;
 ex1:platypus skos:broader ex2:eggLayingAnimals.
 ex1:mammals skos:overlappingConcept ex2:eggLayingAnimals.
 ex1:animals skos:equivalentConcept ex2:animals.

@@TODO: example with compound concepts (e.g. from when ISSUE-40 is solved @@

5. Inconsistent Examples

@@TODO: left to ISSUE-40 and ISSUE-44? @@

6. Entailment Rules

@@TODO: partly left to ISSUE-40 and ISSUE-44?@@

Many of the entailment rules concern the combination of mapping links with coordination construct [ ISSUE-40 ConceptCoordination]. In this section we might apply to skos:overlappingConcept and skos:equivalentConcept rules adapted from the entailments there.

A is equivalent to concept B, which is the intersection of C and D


A is narrower than C and narrower than D

A is equivalent to concept B, which is the union of C and D


C is narrower than A and D is narrower than A

Depending on the decision regarding [ ISSUE-44 BroaderNarrowerSemantics] regarding transitivity of hierarchical semantic links we could have:

A is equivalent to concept B, B is narrower than C


A is narrower than C

A is equivalent to concept B, C is narrower than A


C is narrower than B

NOTE: if we allow in the context of [ ISSUE-44 BroaderNarrowerSemantics] skos:broader and skos:narrower to be reflexive, then we can skip this kind of rules here, by relying on ConceptCoordination-rules and the axiomatic triple skos:equivalentConcept rdfs:subPropertyOf skos:broader.

7. Syntactic Constraints


8. Discussion

8.1 Conceptual mapping issue and other issues

The point of this proposal is minimum change to the current SKOS vocabulary. Indeed it delegates to many other issues some of the problems that occur when considering conceptual mappings.

Mapping concept combinations and general concept coordination issue

The proposed list of concept combination construct (Union, Intersection, Negation) has been proposed here to maintain direct compatibility with current SKOS mappging feature. Generally, however, these constructs may be redundant with the ones proposed as a solution to [ ISSUE-40 ConceptCoordination]. Both proposals would have to be coordinated, but I expect that generally conceptual mapping links can stand between any kind of compound concepts built in the context of the problems ISSUE-40 deals with.


A first possible interpretation of conceptual links in mapping is in terms of the set of documents annotated/indexed by the concept involved in the mapping link or in the combination, as it is stated in [#SWBP-SKOS-MAPPING [SWBP-SKOS-MAPPING]]:

If we try to transfer this interpretation for the new proposal, we end up making semantic assumptions on skos:broader and skos:narrower. Which in my opinion is not a problem. I don't see why mapping would address cases in which a specific semantic interpretations should be made, as opposed to the general SKOS case. But this issue shall be therefore dealt with in the other issues regarding SKOS semantics, like [ ISSUE-44 BroaderNarrowerSemantics] and [ ISSUE-54 ConceptSemantics]

NOTE for discussion on semantics and coordination: an issue occurs regarding the motivation and interpretation for skos:Negation:

Mapping links between non-conceptual entities

Covered by [ ISSUE-49 LexicalMappingLinks]

Provenance of a mapping

Covered by [ ISSUE-47 MappingProvenanceInformation]

8.2 Other discussion points

These are more specific to the conceptual mapping case.

The majorMatch/minorMatch case, and motivation for skos:overlappingConcept

The current specification introduces an arbitrary threshold of 50% overlap for distinguishing between a major and a minor match. It is unclear to me whether this threshold has some legitimacy. What if someone wants to introduce a finer-grained characterization, having links for matches corresponding the 0-30%, 30-60% and 60-100% overlap ranges? If people want to create specific weighted links they should create them, as a specialization of skos:overlappingConcept.

NOTE: skos:overlappingConcept has indeed no very precise semantic meaning: it denotes 'some semantic overlap', eventually according to the semantic interpretation above. But its main motivation is to provide the 'anchor' for all the possible partial mapping links future applications may need. As something like minorMatch is not a subProperty of skos:equivalentConcept, nor skos:broader nor skos:narrower...

NOTE: overlappingConcept is an option that is offered to the user if he cannot/doesn't want to create the boolean combination of concepts which could express the proper mapping situation @@ TODO:Example, once ISSUE-40 is solved @@

Related mappings

The current proposal lets it open whether skos:related can be used to create mapping between concepts from different scheme. From the use cases there is no clear motivation for such links, but there is no apriori reason for preventing users to create and use them.

Representing rationale for a mapping

Some use cases (e.g. [ HILT]) bring the motivation for introducing types of mapping links mirroring the way conceptual similarity is obtained or based on, like lexical match based on plural/singular pair.

This however can be considered orthogonal to the specification of conceptual links: the lexical matching criterion mentioned here can apply both equivalentConcept, broader or overlappingConcept links. In fact this kind of mapping links, focused more on the conceptual mapping process than the essence of the conceptual mapping result, are probably out of SKOS core scope.

Furthermore, it is unsure wether we can provide a list of such kinds of mapping rationale, even at the top level. Survey of research field like ontology matching can give some hints at general families of techniques, but it is unclear whether we can produce an exhaustive list that would over all needs, even at the level of general families.

It is therefore proposed here to leave to specific SKOS applications the task of specializing the semantic relation link (broader, narrower, related, equivalentConcept, overlappingConcept) or even to choose another solution (e.g. reification of maping statement) in order to represent such mapping rationales

Conceptual Mapping links between conceptual entities that are not of type skos:Concept

Some situations may imply to release the domain and range assumptions for the semantic relations used for mapping:

If these are allowed, then we face again the problem behind [ ISSUE-33 GroupingsInConceptHierarchies]. And the different options proposed for this issue shall be considered again:

To make the situation more difficult, we might have cross-category mapping links, something like a non-indexing concept in one scheme mapped to a concept that is used to index documents in another scheme.

SkosDesign/ConceptualMapping/ProposalOne (last edited 2007-11-27 17:03:30 by AntoineIsaac)