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

SKOS ISSUE-33: "Loosening domain and ranges" Proposal

This is a proposal for resolution of SKOS [ ISSUE-33: GroupingConstructs].

0. Summary


The solution proposed here does not deprecate all current features of SKOS relating to "collections" SKOS-GUIDE-SEC-COLLECTIONS. One can use the original construct the original way.

Instead, it deprecates some SKOS axioms involving semantic relations, making them looser by introducing a new superconcept for skos:Concept and skos:Collection, which denotes a conceptual entity in general.

1. Vocabulary

The following vocabulary is required by this proposal:


(name of course can be discussed)

The following vocabulary is deprecated by this proposal:


2. Axiomatic Triples

The following triples are axiomatic for this proposal:

skos:semanticRelation rdfs:domain skos:ConceptualEntity.BRskos:semanticRelation rdfs:range skos:ConceptualEntity.BRskos:Concept rdfs:subClassOf skos:ConceptualEntity. BRskos:Collection rdfs:subClassOf skos:ConceptualEntity.

(plus all axioms involving the specialization of skos:semanticRelation, that it skos:broader/skos:narrower and skos:related. But this would be quite redundant since domain/range axioms are "inherited" down the property hierarchy)


skos:prefLabel rdfs:domain skos:ConceptualEntity.

skos:altLabel rdfs:domain skos:ConceptualEntity.

skos:hiddenLabel rdfs:domain skos:ConceptualEntity.

if one wants to say that this properties apply to general SKOS conceptual entities, which I would find quite OK for the moment)

2. Deprecated axiomatic Triples


The following triples are deprecated for this proposal:

skos:semanticRelation rdfs:domain skos:Concept.

skos:semanticRelation rdfs:range skos:Concept.

skos:broader rdfs:domain skos:Concept.

skos:broader rdfs:range skos:Concept.

skos:narrower rdfs:domain skos:Concept.

skos:narrower rdfs:range skos:Concept.

skos:related rdfs:domain skos:Concept.

skos:related rdfs:range skos:Concept.


skos:prefLabel rdfs:domain rdfs:Resource.

skos:altLabel rdfs:domain rdfs:Resource.

skos:hiddenLabel rdfs:domain rdfs:Resource.

if one wants to say that this properties apply to general SKOS conceptual entities, which I would find quite OK for the moment)

3. Semantic Conditions

There are no further semantic conditions.

4. Consistent Examples

cf. SKOS-GUIDE-SEC-COLLECTIONS which is still valid

5. Inconsistent Examples

The only way to have inconsistency now would be to assert explicitly that an instance of skos:Collection is also an instance of skos:Concept.

6. Entailment Rules

There are no additional entailment rules.

7. Syntactic Constraints

There are no syntactic constraints.

8. Discussion

As said, this solution is pretty minimal regarding the changes it makes for SKOS. Only axioms are changed in a non-monotonous way. All previous representation constructs and practices are still valid.

A very nice feature is that there is no need to turn to specific algorithms to "generate" a conceptual hierarchy from the info on groups and their members, contrary to MinimalFix and Bundles proposals.

It would however require some work if one wants to adapt the solutions regarding collection ordering that are introduced in the two previous proposals. But this is a problem pretty orthogonal to the core inconsistency one. [And by the way do we have a lot of cases for these ordered collections?]

Annex motivation: there might be a similar issue about non-indexing concepts (these are used to create compound concepts like when 25F animal is composed with (+31) Head to make 25F (+3) denoting the head of an animal)

The solution proposed here would be nicely compatible with such future issues needing to consider in a SKOS semantic network all kind of conceptual entities that are not full-fledged concepts.

Final Notice: this trick of introducing a new superconcept to solve inconsistency is pretty common in ontology modeling. If you've got domain/range axioms that produce unwanted consequences regarding the categorization of a property's subjects/objects, then it is because this property has been defined at a semantic level which is not proper. The practice is to "move" domain/range one step higher/lower in the hierarchy, or to create this new appropriate level. And usually the need for generalization correspond to a right modeling need: if we want skos:Concept and skos:Collection to be involved in the same kind of semantic relationship statements, well they must have something in common, and this thing is precisely what helps defining the higher-level concept.


SkosDesign/GroupingConstructs/ProposalThree (last edited 2007-05-17 09:47:04 by AntoineIsaac)