- From: Stella Dextre Clarke <sdclarke@lukehouse.demon.co.uk>
- Date: Tue, 30 May 2006 17:00:34 +0100
- To: "'Alistair Miles'" <a.j.miles@rl.ac.uk>, "'SKOS'" <public-esw-thes@w3.org>
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