RE: question concerning collections

Alistair's response sounds like progress, especially welcome if it makes
things simpler. But can we just think it through one step further...

Adding to Alistair's example, suppose we have an additional array, as
in:

people
.<people by age>
..children
..adults
..elderly
.<people by profession>
..doctors
..lawyers
..teachers

How do all of these get rendered into the right relative locations in
the tree? Presumably there has to be another sorting device that says
the age subdivision comes before the profession subdivision? And we
needed that device in any case, so that we could have systematic rather
than alphabetical sequence for the age groups? I think SKOS already has
a provision for this, and the main thing to check would be that it can
be applied to the sibling node labels as well as to the sibling
concepts.

Cheers
Stella

*****************************************************
Stella Dextre Clarke
Information Consultant
Luke House, West Hendred, Wantage, Oxon, OX12 8RR, UK
Tel: 01235-833-298
Fax: 01235-863-298
SDClarke@LukeHouse.demon.co.uk
*****************************************************



-----Original Message-----
From: public-esw-thes-request@w3.org
[mailto:public-esw-thes-request@w3.org] On Behalf Of Alistair Miles
Sent: 30 May 2006 15:58
To: SKOS
Subject: Re: question concerning collections



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/col
>> lections-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 16:00:54 UTC