- From: Alistair Miles <a.j.miles@rl.ac.uk>
- Date: Tue, 30 May 2006 16:40:11 +0100
- To: Mikael Nilsson <mini@nada.kth.se>, SKOS <public-esw-thes@w3.org>
> One thing this breaks is the assumption that all interesting information > about a URI can be reached through the anonymous closure in the > "forward" direction. Thus, to get the relevant subgraph for a URI, one > now has to take into account the possibility of backtracking to find > collections. I'm not sure that's a problem though - I rather like the > out-of-line solution - especially when compared to the alternatives :-) :) indeed! Breaking this assumption sounds reasonable to me. Cheers, Al. > > /Mikael > > >> 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 15:47:50 UTC