Re: question concerning collections

tis 2006-05-30 klockan 15:58 +0100 skrev Alistair Miles:
> 
> 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.

This is a kind of "out-of-line" representation - i.e. the grouping is
added outside of and independently of the main RDF construct.

It should be noted that a similar solution will be needed for properties
like dc:creator once dc:creator gets a range of "Agent" - no Bags of
authors will be allowed, but the Bag can be added externally. 

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 :-)

/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
> >>>>>
> >>>>
> >>>
> >>>
> >>
> > 
> > 
>

Received on Tuesday, 30 May 2006 15:35:57 UTC