$Id: collections-5.html,v 1.1 2005/10/19 18:08:34 ajm65 Exp $
This is a draft document describing options for resolving the issue 'collections-5' written up under the SKOS Core proposals list, see http://www.w3.org/2004/02/skos/core/proposals#collections-5. See also http://isegserv.itd.rl.ac.uk/cvs-public/skos/drafts/collections-5.html for revisions of this document.
This document describes three options for solving the issue collections-5.
The background to this issue is the requirement from a number of thesauri (e.g. AAT), and from thesaurus standards (e.g. BS8723) to support 'node labels', which are terms that appear in a hierarchy, such as ...
chairs .<chairs by form> ..armchairs ..easy chairs
In the example above, 'chairs by back form' is the node label. There is
consensus in the thesaurus community that node labels are not labels for
concepts, but labels for 'arrays' i.e. labels for some sort of grouping
construct. To model this type of grouping construct SKOS Core has the classes
skos:Collection and skos:OrderedCollection.
Therefore, it is not proper to model node labels as labels for resources of
type skos:Concept. We want to be able to formally support this
consensus and improve clarity by stating disjoint(skos:Concept,
skos:Collection).
However, node labels do appear in generalisation hierarchies, therefore SKOS Core must be able to capture that information somehow, in order to generate a hierarchical display such as the above.
The current solution is presented in the section Meaningful Collections of Concepts in the SKOS Core Guide.
However, the current solution leads to contradictory conclusions, as described at collections-5. We need a solution that allows us to support the above, and infer the underlying network of concept-to-concept relationships, without being self contradictory.
This is an extension of the solution proposed by DanC. We coin a new
property skos:narrowerCollection to be used as in e.g.:
@prefix eg: <http://www.example.com/eg#>.
@prefix skos: <http://www.w3.org/2004/02/skos/core#>.
eg:concept1 a skos:Concept;
skos:prefLabel 'chairs';
skos:narrowerCollection [
a skos:Collection;
rdfs:label 'chairs by form';
skos:member eg:concept2;
skos:member eg:concept3;
];
.
In order to infer the underlying network of concept-to-concept relationships:
eg:concept1 skos:narrower eg:concept2, eg:concept3.
... we need an inference rule such as:
{
?x skos:narrowerCollection [ skos:member ?y].
}
=>
{
?x skos:narrower ?y.
}
This solution would allow us to assert
disjoint(skos:Concept,skos:Collection) without having to change
anything else in the current RDF description of SKOS Core. I.e. it's the
simplest fix. It also avoids the mess of complex ranges for semantic relation
properties.
However, there is a question over extensibility. Currently I know of no
thesaurus that uses anything other than the semantic relation
skos:narrower to relate a concept to a collection. However, if a
thesaurus wanted to e.g. use skos:related with collections, they
would have to declare a corresponding property
eg:relatedCollection and a rule such as the above to infer the
underlying semantic relation. I.e. for each semantic relation property you
want to use with collections, you need a corresponding 'shadow' property to
use with collections, and an inference rule. This adds to the overhead of
creating a semantic relation property extension.
There is a potential way around some of the overhead described above. This
would require the coining of a new property e.g.
skos:collectableEquivalent with a domain and range of
rdf:Property. Such a property could be used to write a single
generic rule for inferring semantic relations from SKOS collections:
{
?p skos:collectableEquivalent ?mp.
?x ?mp [ skos:member ?y].
}
=>
{
?x ?p ?y.
}
An initial use of the property would be to state {skos:narrower
skos:collectableEquivalent skos:narrowerCollection.}
What are the consequences here regarding OWL? I'm guessing this takes SKOS Core well outside OWL DL?
As an immediate fix the skos:narrowerCollection property
could at least be coined, at relatively little cost in terms of change to
current documentation and schemas, reserving the option to implement the
generic mechanism described above at a later date if necessary.
The current recommended practice in the SKOS Core Guide is to allow e.g.:
@prefix eg: <http://www.example.com/eg#>.
@prefix skos: <http://www.w3.org/2004/02/skos/core#>.
eg:concept1 a skos:Concept;
skos:prefLabel 'chairs';
skos:narrower [
a skos:Collection;
rdfs:label 'chairs by form';
skos:member eg:concept2;
skos:member eg:concept3;
];
.
... and then to use the 'Collectable Properties Rule':
{
?p a skos:CollectableProperty.
?x ?p [ skos:member ?y].
}
=>
{
?x ?p ?y.
}
... plus the fact that skos:narrower has been declared as
type skos:CollectableProperty, to infer the underlying semantic
relations ...
eg:concept1 skos:narrower eg:concept2, eg:concept3.
In fact, skos:related and skos:broader have also
been declared as type skos:CollectableProperty, in principle
allowing their use with collections as in the above.
In order to be able to keep this solution, assert
disjoint(skos:Concept, skos:Collection) and not be inconsistent
we would have to modify the range of the property
skos:semanticRelation. Specifically, we would have to change its
range from skos:Concept, to a new class
skos:ConceptOrCollection which is a union of
skos:Concept and skos:Collection. To be accurate,
we would also have to change the defininition of skos:semanticRelation
from:
'A concept related by meaning.'
... to something like.:
'A concept related by meaning, or a collection of such concepts.'
We would have to change the definition in a similar way for at least
skos:narrower, and also for skos:broader and
skos:related if we want to continue to allow their use as
'collectable properties'.
As noted, to keep this solution and be consistent, we would have to modify
the range of skos:semanticRelation to a union of two classes.
DanC has pointed out the confusion that a complex range like this has caused
for vocabularies such as Dublin Core.
There is a generic mechanism by which third parties can coin new semantic
relation properties and declare them to be 'collectable' (via the class
skos:CollectableProperty) and a single generic rule to use to
infer the true network of concept-to-concept relationships. However, if a
third part was to disallow the use of a semantic relation property with SKOS
collections by declaring the range of that property to be
skos:Concept, then all refinements thereof would also not be
usable with SKOS collections.
We coin new properties skos:collected and
skos:collectionFunction, to use as in:
eg:concept1 a skos:Concept;
skos:prefLabel 'chairs';
skos:collected [
rdfs:label 'chairs
skos:collectionFunction skos:narrower;
skos:member eg:concept2;
skos:member eg:concept3;
];
.
The generic rule to infer a network of semantic relations between concepts becomes:
{
?x skos:collected [
skos:collectionFunction ?p;
skos:member ?y;
].
}
=>
{
?x ?p ?y.
}
Allows potentially any semantic relation property to be used with collections, without having to make any declarations about that property a priori. Avoids the need for complex ranges, or for 'shadow' properties.
Way outside OWL DL?