W3C home > Mailing lists > Public > public-esw-thes@w3.org > January 2011

Re: AW: How to distinguish unique and non-unique prefLabels?

From: Jakob Voss <jakob.voss@gbv.de>
Date: Wed, 12 Jan 2011 17:13:09 +0100
Message-ID: <4D2DD315.20609@gbv.de>
To: public-esw-thes@w3.org
Hi Joachim,

Thanks for the feedback. I'd like to stress that my use-case is a 
classification, but not a thesaurus. You wrote:

> unique and non-unique skos:prefLabel subproperties seem a little bit
> counter-intuitive to me, since SKOS generally recommends unique use
> of skos:prefLabel.

I think the SKOS primer aims at thesauri and flat authority files with 
this recommendation. A classification generally has unique notation but 
in many cases the labels are not unique, and applications that deal with 
classifications, don't expect labels to be unique. If skos:prefLabel is 
not the right property for non-unique labels, then we'd need another 
property to distinguish alternative labels and the "preferred" 
alternative label. By the way http://dewey.info/ also uses 
skos:prefLabel. If you go down the whole DDC, there are non-unique 
labels too.

> This makes the skos:prefLabel property really valuable, far beyond
> the scope of thesauri, classifications and the like, because
> applications can assume uniqueness of skos:prefLabel for e.g. sorting
> or one-line display purposes of given resources.

Many use cases only need the guaranteed assumption, that each concept 
has only one preferred label by language. The assumption that each 
preferred label is unique in a given concept scheme, is not guaranteed 
by SKOS, so it should be validated by applications, that require it.

> In the systematic part of STW Thesaurus for Economics
> (http://zbw.eu/stw), I had to deal with the very same problem. There,
> I used rdfs:label as non-unique labeling property for the class name,
> and a concatination of notation and class name for skos:prefLabel.

You wrote:

<http://zbw.eu/stw/thsys/71085>
   rdfs:label "Development Policy"@en ;
   skos:prefLabel "V.08.02  Development Policy"@en  ;
   skos:notation "V.08.02"^^xsd:string .

Looks like a similar problem. But for general SKOS applications, 
rdfs:label is of even less use than skos:hiddenLabel, and it infers from 
*all* labeling properties, so you end up with many labels and no clue, 
which is the main label to use, if uniqueness is not relevant.

If concatenate notation and "real label", an application must have 
additional knowledge like "if the prefLabel starts with the notation, 
don't prepend the notation in displays, but look for rdfs:label for a 
label that does not contain the notation and that is intended to be used 
as preferred label, if uniqueness is not relevant". This is too much 
application-specific semantic in my point of view.

I need to distinguish between a label, that should be used, if 
uniqueness per scheme is not required, and a label, that should be used, 
if uniqueness per scheme is required. Both are given and there can be 
notations and alternative labels independent from that.

The case may be easier to solve, if the unique label has been created by 
adding a qualifier to the non-unique label, such as "V.08.02 
Development Policy" or "Development Policy (Economics)". Maybe SKOS-XL
can belp? Another solution would be using dc:title instead of rdfs:label:

<http://zbw.eu/stw/thsys/71085>
   dc:title "Development Policy"@en ;
   skos:notation "V.08.02"^^xsd:string .

The additional best-practice rule, that we should propagate for all SKOS 
applications, would be to use dc:title instead of skos:prefLabel, if 
uniqueness of labels is not relevant, or if no skos:prefLabel is given. 
If there are no unique labels, we should not lie and artificially create 
them in the data, but in the application that needs them (for instance 
by prepending the notation).

In short: if the concept's main labels in a concept scheme is not unique 
in this scheme (this is the fact in many classifications!), we either

A) have to use skos:prefLabel non-unique, or

B) let some concepts not have any skos:prefLabel property at all

Both does not contradict the SKOS specification. I am looking for the 
best practice to apply either A or B.

Jakob

-- 
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 Wednesday, 12 January 2011 16:14:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:46:06 UTC