Re: [SKOS] RE: ISSUE-33: GroupingConstructs

Miles, AJ (Alistair) wrote:

> Guus asked me to suggest an issue to open at the next telecon. I
> suggest:
>
> http://www.w3.org/2006/07/SWD/track/issues/33

In my opinion the discussion of this issue once again is too much
focused on thesauri instead of general indexing systems. I currently
stumbled upon another incosistency in the current SKOS core draft, let
me start with this:


skos:Concept is associated to a skos:ConceptScheme with the
skos:inScheme property. skos:Concept schemes may be labeled with
dc:title. There is no explicit way to nest skos:ConceptSchemes

skos:Concept is associated to a skos:Collection with the skos:member
property. skos:Collection may be labeled with rdfs:label.
skos:Collections may be nested.


What's the semantic difference? A skos:ConceptScheme is probably
published as an idependent vocabulary and has more metadata connected to
it while a skos:Collection does only appear in the context of a larger
set of Concepts. But nesting of ConceptSchemes also makes sense if you
compile multiple concept schmes to a larger set. In summary the idea is
the same: Concepts are grouped under a resource that itself is not a
concept but has label.


Now to ISSUE 33: It does not matter if collections are used as "node
labels", "factet indicators", "bundles", "guide terms" or whatsover - in
many cases it does not even matter if you deal with a collection or with
a concept scheme. The only relevant principles are:

1. a skos:Concept can be associated to a skos:Collection (skos:member)
2. a skos:Collection can be associated to another skos:Collection (nesting)
3. in general skos:collection have a label (we could use standard
skos-label proberies or dc:title, but should explicitely define what
property to use).
4. the skos:member property has no semantic in indexing

Now find a way to encode sorted collections, make skos:ConceptScheme a
subclass of skos:Collection and drop skos:inScheme in favor to
skso:member and that's all :-)

Do not put too many previous knowledge into SKOS - keep it simple!



Let me refer to the section on [BS 8723-2:2005] at
http://www.w3.org/2006/07/SWD/wiki/SkosDesign/GroupingConstructs :

> [BS 8723-2:2005] also allows the use of node labels to introduce
> "facets". For example:
>
> agricultural industries
>  (people)
>  farm managers
>  dairy personnel
>  shepherds
>  (products)
>  cereal products
>  dairy products
>
> This is similar (if not identical?) to the second kind of usage
> allowed in [ISO 2788-1986]. Note especially that: "... where the label
> introduces a new facet, the terms that follow are typically not
> narrower terms of the preceding term: farm managers and cereal
> products, etc., are not narrower terms of agricultural industries
> ...". Unfortunately, [BS 8723-2:2005] does not indicate whether the
> following alphabetical display would be correct for the example shown
> above
>
> agricultural industries
>  RT farm managers
>  RT dairy personnel
>  RT shepherds
>  RT cereal products
>  RT dairy products

If you do not explicitely specify "farm managers" skos:narrower
"agricultural industries" then ther display with "RT" is wrong. The
collections "(people)" and "(products)" are irrelevant - they may be
used for nice display depending on the application but the do not
construct any skos:broader/skos:narrower relations.

Greetings,
Jakob

P.S: Here is another use case: The DDC class of the history of Canada in
the main schedule is as follows:

900:     History & geography
930-990: History of ancient world; of specific continents, countries,
localities; of extraterrestrial worlds
940-990: History of modern world, of extraterrestrial worlds
970:     History of North America
971-979: Countries and localities
971:     Canada

In most displays you won't see "930-990", "940-990", and "971-979" but
their are in DDC and you would encode them with skos:Collection.


-- 
Jakob Voß <jakob.voss@gbv.de>, skype: nichtich
Verbundzentrale des GBV (VZG) / Common Library Network
Platz der Goettinger Sieben 1, 37073 Göttingen, Germany
+49 (0)551 39-10242, http://www.gbv.de

Received on Friday, 30 March 2007 18:00:10 UTC