• SkosDesign
• GroupingConstructs
• ProposalThree

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

This is a proposal for resolution of SKOS [http://www.w3.org/2006/07/SWD/track/issues/33 ISSUE-33: GroupingConstructs].

0. Summary

Motivations:

• the grouping issue comes from the contradiction between two axioms:
  • concepts and groupings are disjoint
  • the range of skos:semanticRelationship (and specializations) is skos:Concept, which implies that e.g. groupings that are objects of skos:narrower statements would also be instances of skos:Concept

• the [http://www.w3.org/2006/07/SWD/wiki/SkosDesign/GroupingConstructs/ProposalOne MinimalFix] and [http://www.w3.org/2006/07/SWD/wiki/SkosDesign/GroupingConstructs/ProposalTwo Bundles] proposals are ok from this point of view, but they do prevent using semantic relations to include groupings explicitly in skos:broader/skos:narrower hierarchies, which makes obsolete almost all examples of grouping practices found in SKOS documents. It is also quite counter-intuitive: all grouping examples in thesaurus cases are involved in some hierarchical relation.

The solution proposed here does not deprecate all current features of SKOS relating to "collections" http://www.w3.org/TR/2005/WD-swbp-skos-core-guide-20051102/#seccollections 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:

NIL

2. Axiomatic Triples

The following triples are axiomatic for this proposal:

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

(plus

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

As from http://www.w3.org/2006/07/SWD/wiki/SkosDesign/RdfsSemanticExtension SKOS-RDFS-SEMANTIC-EXTENSION or http://www.w3.org/TR/swbp-skos-core-spec SKOS-CORE-VOC-SPEC

The following triples are deprecated for this proposal:

(plus

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. http://www.w3.org/TR/2005/WD-swbp-skos-core-guide-20051102/#seccollections 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 http://www.w3.org/2006/07/SWD/wiki/SkosDesign/GroupingConstructs/ProposalOne MinimalFix and http://www.w3.org/2006/07/SWD/wiki/SkosDesign/GroupingConstructs/ProposalTwo 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 http://www.w3.org/TR/skos-ucr/#R-IndexingAndNonIndexingConcepts 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)

• non-indexing concepts would be disjoint from concepts, e.g. to prevent them to be used as objects of skos:subject statements: a non-indexing concept cannot be used alone to describe a document.

• non-indexing concepts are involved in semantic relations statements. They come in hierarchies of their own ((+31) Head is narrower than (+3) head) or might be skos:related to 'normal' concepts.

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.

CategoryTemplate