- From: Mark van Assem <mark@cs.vu.nl>
- Date: Tue, 23 Aug 2005 15:05:18 +0200
- 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). 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. 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. Regards, Mark. 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