W3C home > Mailing lists > Public > public-esw-thes@w3.org > August 2005

Re: Issue with collections

From: Mark van Assem <mark@cs.vu.nl>
Date: Tue, 23 Aug 2005 15:05:18 +0200
Message-ID: <430B1F0E.1040600@cs.vu.nl>
To: "Miles, AJ \(Alistair\)" <A.J.Miles@rl.ac.uk>
CC: public-esw-thes@w3.org

Hi Alistair,

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

The problem is one of points of view. The collections/node labels are 
not part of the concept hierarchy, but we want to render them on the 
screen as part of the hierarchy anyway. In a way this information is 
separate from the hierarchy itself.

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.

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.

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

	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.

There is no loss of information, only the inclusion of the node labels 
in the hierarchy is less straightforward.

I like the second solution better as it does not require using rules.


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/#seccollections
> [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 13:05:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:45:22 UTC