- From: Alistair Miles <a.j.miles@rl.ac.uk>
- Date: Tue, 30 May 2006 15:58:17 +0100
- 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 UTC