RE: Issue with collections

Hi Mark,

> Good catch, this should be moved to the proposed changes (as soon as 
> we have a solution).

Agreed.

> The consequence of your observation on the range of SemanticRelation 
> seems to be that it is impossible to link the collections into the 
> hierarchy with narrower/broader.

Not necessarily ...

> I can think of two solutions now:
> 
> 1) special property
> 
> Use a special property e.g. "narrowerNodeLabel" to link a 
> skos:Concept 
> to a collection. This property shouldn't be a SemanticRelation to 
> avoid the problem you discovered. And add a rule
> 
> (?x skos:narrowerNodeLabel ?c) (?c skos:member ?m)
> ->
> (?x skos:narrower ?m)
> 
> so that each member of the collection is automatically narrower than 
> the concept to which the collection is linked with narrowerNodeLabel.
> 

This type of structure is worth considering as an option.

> 
> 2) outside of the hierarchy
> 
> Because the concepts in a node label/array are always narrower than 
> some other concept C, we can just construct the narrower/broader 
> hierarchy as usual, and store the information on their being a member 
> of a specific nodelabel elsewhere (outside the hierarchy).
> 
> Concept1
> 	ConceptA	-> memberOf  nodeLabel1
> 	ConceptB	-> memberOf  nodeLabel1
> 	ConceptC	-> memberOf  nodeLabel2
> 	ConceptD	-> memberOf  nodeLabel2
> 
> nodeLabel1 and nodeLabel2 are instances of a class NodeLabel on which 
> a property nodeLabelName with range string is defined.
> 

This doesn't work, because a concept may have more than one broader concept, in which case it becomes ambiguous where the node label should be displayed.  To work around this, you would have to have an additional property to explicitly state which concept the node label should be displayed under.  This was in fact of one of the originally suggested solutions to the problem of displaying node labels and guide terms at the correct place in the hierarchy, see the section 'Issue: nesting an array in the hierarchy of concepts' which is at the end of [1].  [1] was writted before we thought up the 'collectable property' idea, which was initially proposed at [2].

In fact, structurally your two solutions are identical, because your proposed 'narrowerNodeLabel' in option 1 would be the inverse of the additional property (e.g. 'displayUnder') required by option 2.

There is another option (call it 'option 3')...

---
Remove the following statement:
---

skos:semanticRelation rdfs:range skos:Concept .

---
Add the following statements:
---

skos:ConceptOrCollection a rdfs:Class;
  owl:unionOf (skos:Concept, skos:Collection) .

skos:Concept rdfs:subClassOf skos:ConceptOrCollection;
  owl:disjointWith skos:Collection .

skos:Collection rdfs:subClassOf skos:ConceptOrCollection;
  owl:disjointWith skos:Concept .

skos:semanticRelation rdfs:range skos:ConceptOrCollection .

---
... Then if someone was creating their own semantic relation property, but didn't want to allow use with collections, they could specify e.g.:
---

eg:mySemanticRelation a rdf:Property;
  rdfs:subPropertyOf skos:semanticRelation .

skos:Concept subClassOf [
  a owl:Restriction;
  owl:onProperty eg:mySemanticRelation;
  owl:allValuesFrom skos:Concept;
].

---

What do you think?

Cheers,

Al.


[1] http://esw.w3.org/topic/SkosDev/SkosCore/CollectionsAndArrays
[2] http://lists.w3.org/Archives/Public/public-esw-thes/2004Oct/0072.html



> 
> 
> Miles, AJ (Alistair) wrote:
> > Hi all,
> > 
> > I just realised we have an issue with current recommended 
> usage of the 'meaningful collections' bit of SKOS Core [1].  
> It goes like this:
> > 
> > The whole point of the skos:Collection class was so that we 
> could *avoid* representing a node label such as 'milk by 
> source animal' or 'people by age' as a label for a concept.  
> The current consensus is that node labels are *not* labels 
> for concepts, and should not be modelled as such.
> > 
> > However, to allow node labels to still be rendered as part 
> of a hierarchical display, we had to invent the extremely 
> cunning skos:CollectableProperty class, with the associated 
> 'collectable properties rule', see [2].
> > 
> > But, if we allow stuff like ...
> > 
> > @prefix ex: <http:///www.example.com/concepts#> .
> > # other namespaces as standard
> > 
> > ex:milk a skos:Concept;
> >   skos:narrower _:node1;
> > .
> > 
> > _:node1 a skos:Collection;
> >   rdfs:label 'Milk by source animal';
> >   skos:member ex:goatmilk;
> >   skos:member ex:cowmilk;
> >   skos:member ex:yakmilk;
> > . 
> > 
> > ... then because ...
> > 
> > skos:narrower rdfs:subPropertyOf skos:semanticRelation .
> > 
> > ... and ...
> > 
> > skos:semanticRelation rdfs:range skos:Concept .
> > 
> > ... we end up with the inference that ...
> > 
> > _:node1 a skos:Collection, skos:Concept .
> > 
> > ... which is the very thing we were trying to avoid - doh!
> > 
> > I'm not sure how best to fix this right now, I'll have a 
> think when I get back from hols.
> > 
> > Cheers,
> > 
> > Al. 
> > 
> > [1] 
> http://www.w3.org/TR/2005/WD-swbp-skos-core-guide-20050510/#se
ccollections
> [2] http://www.w3.org/TR/2005/WD-swbp-skos-core-guide-20050510/#seccollectable
> ---
> Alistair Miles
> Research Associate
> CCLRC - Rutherford Appleton Laboratory
> Building R1 Room 1.60
> Fermi Avenue
> Chilton
> Didcot
> Oxfordshire OX11 0QX
> United Kingdom
> Email:        a.j.miles@rl.ac.uk
> Tel: +44 (0)1235 445440
> 
> 

-- 
  Mark F.J. van Assem - Vrije Universiteit Amsterdam
        mark@cs.vu.nl - http://www.cs.vu.nl/~mark

Received on Tuesday, 23 August 2005 14:09:01 UTC