W3C home > Mailing lists > Public > public-esw-thes@w3.org > May 2006

Re: question concerning collections

From: Alistair Miles <a.j.miles@rl.ac.uk>
Date: Tue, 30 May 2006 15:58:17 +0100
Message-ID: <447C5D89.4080803@rl.ac.uk>
To: SKOS <public-esw-thes@w3.org>

Hi all,

Yes, this is the "collections-5" issue - there is a major issue with 
the usage of the skos:Collection class as currently described in the 
SKOS Core Guide - as Bernard notes, we have managed to design a system 
that entails the exact opposite of what we intended!

I realised recently there is another, very simple solution to the 
collections-5 problem. To represent the following extract from a 
thesaurus ...

people
.<people by age>
..children
..adults
..elderly

... just do this (and nothing more) ...

@prefix eg: <http://example.com/eg#>.

eg:A skos:prefLabel "people"@en;
   skos:narrower eg:B, eg:C, eg:D.

eg:B skos:prefLabel "children"@en.
eg:C skos:prefLabel "adults"@en.
eg:D skos:prefLabel "elderly"@en.

[] rdfs:label "people by age";
   skos:memberList (eg:B eg:C eg:D).

... now, when generating a tree representation, apply the following 
algorithm: if *all* the members of a collection have a skos:broader 
link to the same concept, then the collection can be rendered as a 
child of the broader concept in the tree.

I.e. the RDF above is *sufficient* to regenerate the initial tree 
representation. I.e. there is actually no necessity to link the 
collection and the parent concept *at all*.

P.S. I never liked "collection" either, best alternative I've come up 
with so far is "concept group" - I would go for "array" but for the 
ambiguity with it's use in computer programming.

Cheers,

Al.

[1] http://www.w3.org/2004/02/skos/core/proposals#collections-5


Bernard Vatant wrote:
> 
> Mark
> 
> Thanks for the links ... "déjà vu", indeed! Honest, I had missed the 
> threads, and I did not copy Dan's post [1], although it really looks 
> like it.
> So let me sum up the pragmatic position we can take so far.
> 
>    * Keep collections distinct from concepts in *declarations*, e.g.
>      even when allocating a URI to a collection (which I agree with you
>      is not really a good idea), don't use this same URI for a concept.
>    * Even if a reasoner could infer that some skos:Collection is a
>      skos:Concept, applications should not me aware of such a
>      conclusion :-) , so keep them distinct in processing, display,
>      forbid indexing on collections etc.
> 
> Side question maybe Leonard will have clues : should collections / label 
> nodes be used in full text search, IOW if I pass the SKOS structure to a 
> full text engine, should I include the label nodes? In the example given 
> by Paul, seems it would not make much sense, but I know he has other 
> examples in the back of his mind, namely AAT he mentioned before. We 
> have there nested collections such as :
> 
>  > French Medieval styles
>  >> French Medieval architecture styles
>       Angevin Gothic
>       Rayonnant
>       Flamboyant
> 
> Seems to me those are borderline cases ...
> 
> [1] http://lists.w3.org/Archives/Public/public-esw-thes/2005Oct/0059.html
> 
> *
> Bernard Vatant*
> 
> Knowledge Engineering
> 
> *Mondeca **
> *3, cité Nollez 75018 Paris France
> 
> Tel. +33 (0) 871 488 459
> Mail: bernard.vatant@mondeca.com <mailto:bernard.vatant@mondeca.com>
> 
> Web: www.mondeca.com <http://www.mondeca.com>
> 
> Blog : universimmedia.blogspot.com <http://universimmedia.blogspot.com>
> 
> 
> 
> Mark van Assem a écrit :
>> Hi Bernard,
>>
>> Hmmmm I had a strong sense of deja vu on this one... and indeed, this 
>> problem was flagged before, see [1]. Alistair wrote up solutions in 
>> [2] but we seem not to have come to a conclusion.
>>
>> So yes, the current spec results in wrong triples, but there is no 
>> solution as yet.
>>
>> The practical way for people to go forward now is either (a) use one 
>> of the solutions in [2] as if it already existed, or (b) ignore the 
>> problem and just use narrower on skos:Collections.
>>
>> I personally would choose solution b _and_ not give those collections 
>> a URI. The most important thing is to prevent them being used in 
>> annotations. As they are collections anyway that fact can be used in 
>> displays independent if it was inferred to be a concept also. Of 
>> course more care is required in code that processes any skos:Concept; 
>> it should ignore the skos:Collections.
>>
>> Later then the correct solution from [2] can be implemented by 
>> changing the existing RDF.
>>
>> Cheers,
>> Mark.
>>
>>
>> [1]http://www.w3.org/2004/02/skos/core/proposals#collections-5
>> [2]http://isegserv.itd.rl.ac.uk/cvs-public/~checkout~/skos/drafts/collections-5.html?rev=1.2 
>>
>>
>> Bernard Vatant wrote:
>>>
>>> Mark
>>>
>>> This exchange drives me a little confused about the status of 
>>> skos:Collection vs skos:Concept
>>>
>>> What you write, and with which I basically tend to agree, seems to 
>>> assume that a skos:Collection is not a skos:Concept. Although this is 
>>> nowhere written explicitly in SKOS specification (correct me if I am 
>>> wrong), it seems indeed correct to assume that those two classes 
>>> should be in practice disjoint.
>>>
>>> But if you allow, like in the example quoted by Paul, a collection, 
>>> even as a blank node, to be the value of a narrower property, like in 
>>> example quoted by Paul
>>>
>>> (1)        ex:milk           skos:narrower            _:b0
>>> (2)        _:b0               rdf:type                      
>>> skos:Collection
>>>
>>> ... put that along with the declaration of skos:narrower range in the 
>>> specification
>>>
>>> (3)         skos:narrower                  
>>> rdfs:subPropertyOf          skos:semanticRelation
>>> (4)         skos:semanticRelation      
>>> rdfs:range                        skos:Concept
>>>
>>> It's quite easy to entail
>>>
>>> (5)      _:b0               rdf:type                      
>>> skos:Concept            And this is independent of the fact that the 
>>> collection has a URI or not. Replacing _:b0 above  by  
>>> ex:milkbyanimal does not change anything to this entailment.
>>> A side effect in that case is that if the distinction between 
>>> skos:Collection and skos:Concept is blurred, so is the distinction 
>>> between skos:member and skos:narrower.
>>>
>>> My hunch is that there is something wrong with the above reasoning, 
>>> since I'm not happy with the conclusion.
>>>
>>> Thoughts?
>>>
>>> Bottom line : maybecurrent specification is a bit unclear about 
>>> collections, the core issue being not to know if they should be blank 
>>> nodes or not, but to make clear if and why skos:Collection and 
>>> skos:Concept are disjoint classes, if they indeed should be (of which 
>>> I remain to be fully convinced), and what the notion of "collectable 
>>> property" actually means.
>>>
>>> Bernard
>>>
>>>
>>> *Bernard Vatant*
>>>
>>> Knowledge Engineering
>>>
>>> *Mondeca **
>>> *3, cité Nollez 75018 Paris France
>>>
>>> Tel. +33 (0) 871 488 459
>>> Mail: bernard.vatant@mondeca.com <mailto:bernard.vatant@mondeca.com>
>>>
>>> Web: www.mondeca.com <http://www.mondeca.com>
>>>
>>> Blog : universimmedia.blogspot.com <http://universimmedia.blogspot.com>
>>>
>>>
>>>
>>> Mark van Assem wrote
>>>>
>>>> Hi Paul,
>>>>
>>>> The SKOS Core Guide [1] says:
>>>>
>>>> "Note that in the example above the collection was defined as a 
>>>> blank node, i.e. no URI was allocated. URIs may be allocated to 
>>>> collections, but usually this is not necessary."
>>>>
>>>> So the first answer to your question is 'yes, it is possible and it 
>>>> is allowed'.
>>>>
>>>> However, I think the wording above should be stronger, stating that 
>>>> it is recommended NOT to give a URI for a collection. Collections 
>>>> are used to represent node labels, and node labels should not be 
>>>> used for indexing. Therefore annotators should not be tempted to use 
>>>> them anyway, simply because a URI is available for them.
>>>>
>>>> Again quoting [1]:
>>>>
>>>> 'There is consensus that a 'node label' does not represent a label 
>>>> for a concept in its own right, and therefore correctly modelling 
>>>> this kind of structure in RDF requires careful consideration.'
>>>>
>>>> Cheers,
>>>> Mark.
>>>>
>>>> [1]http://www.w3.org/TR/swbp-skos-core-guide/#seccollections
>>>>
>>>> <http://universimmedia.blogspot.com>
>>>
>>>
>>>> Paul Hermans wrote:
>>>>> In the SKOS core guide I do find following example :
>>>>>
>>>>> <rdf:RDF
>>>>>   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>>>>>   xmlns:skos="http://www.w3.org/2004/02/skos/core#"
>>>>>   xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#">
>>>>>     <skos:Concept rdf:about="http://www.example.com/concepts#milk">
>>>>>     <skos:prefLabel>milk</skos:prefLabel>
>>>>>     <skos:narrower>
>>>>>       <skos:Collection>
>>>>>         <rdfs:label>milk by source animal</rdfs:label>
>>>>>         <skos:member 
>>>>> rdf:resource="http://www.example.com/concepts#buffalomilk"/>
>>>>>         <skos:member 
>>>>> rdf:resource="http://www.example.com/concepts#cowmilk"/>
>>>>>         <skos:member 
>>>>> rdf:resource="http://www.example.com/concepts#goatmilk"/>
>>>>>         <skos:member 
>>>>> rdf:resource="http://www.example.com/concepts#sheepmilk"/>
>>>>>       </skos:Collection>
>>>>>     </skos:narrower>
>>>>>   </skos:Concept>
>>>>> </rdf:RDF>
>>>>>
>>>>> Where in this case Collection is within the narrower element as a 
>>>>> blank node.
>>>>>
>>>>> I suppose I can do the same using a node with a URI as follows.
>>>>>
>>>>> <rdf:RDF
>>>>>   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>>>>>   xmlns:skos="http://www.w3.org/2004/02/skos/core#"
>>>>>   xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#">
>>>>>     <skos:Concept rdf:about="http://www.example.com/concepts#milk">
>>>>>     <skos:prefLabel>milk</skos:prefLabel>
>>>>>     <skos:narrower 
>>>>> rdf:resource="http://www.example.com/collections#milkbyanimal"/>
>>>>>   </skos:Concept>
>>>>>     <skos:Collection 
>>>>> rdf:about="http://www.example.com/collections#milkbyanimal">
>>>>>         <rdfs:label>milk by source animal</rdfs:label>
>>>>>         <skos:member 
>>>>> rdf:resource="http://www.example.com/concepts#buffalomilk"/>
>>>>>         <skos:member 
>>>>> rdf:resource="http://www.example.com/concepts#cowmilk"/>
>>>>>         <skos:member 
>>>>> rdf:resource="http://www.example.com/concepts#goatmilk"/>
>>>>>         <skos:member 
>>>>> rdf:resource="http://www.example.com/concepts#sheepmilk"/>
>>>>>  </skos:Collection>
>>>>>
>>>>> </rdf:RDF>
>>>>>
>>>>>
>>>>> I just want to check since someone told me this can and may not be 
>>>>> done according to the SKOS spec.
>>>>>
>>>>> Regards,
>>>>>
>>>>>
>>>>> Paul
>>>>>
>>>>
>>>
>>>
>>
> 
> 

-- 
Alistair Miles
Research Associate
CCLRC - Rutherford Appleton Laboratory
Building R1 Room 1.60
Fermi Avenue
Chilton
Didcot
Oxfordshire OX11 0QX
United Kingdom
Web: http://purl.org/net/aliman
Email: a.j.miles@rl.ac.uk
Tel: +44 (0)1235 445440
Received on Tuesday, 30 May 2006 14:58:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:38:54 GMT