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

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

From: Neubert Joachim <J.Neubert@zbw.eu>
Date: Wed, 12 Jan 2011 15:57:20 +0100
Message-ID: <3A59BB6451C972429019B12996F92DAD02E4D7F0@frodo.zbw-nett.zbw-kiel.de>
To: "Jakob Voss" <jakob.voss@gbv.de>, <public-esw-thes@w3.org>
Hi Jakob,

unique and non-unique skos:prefLabel subproperties seem a little bit counter-intuitive to me, since SKOS generally recommends unique use of skos:prefLabel "Following common practice in KOS design, the preferred label of a concept may also be used to unambiguously represent this concept within a KOS and its applications. So even though the SKOS data model does not formally enforce it, it is recommended that no two concepts in the same KOS be given the same preferred lexical label for any given language tag." (http://www.w3.org/TR/skos-primer/#secpref)

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.

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.


    rdfs:label "Development Policy"@en, "Entwicklungspolitik"@de ;
    skos:notation "V.08.02"^^xsd:string ;
    skos:prefLabel "V.08.02  Development Policy"@en, "V.08.02  Entwicklungspolitik"@de .

Since the skos:prefLabel is a subproperty of rdfs:label, this looked sufficiently consistent for me. 

An application can make use of either the concatination (in a standard display), or of the seperate parts, where this is necessary.

I'd be happy if this helps - 

Cheers, Joachim

> -----Ursprüngliche Nachricht-----
> Von: public-esw-thes-request@w3.org 
> [mailto:public-esw-thes-request@w3.org] Im Auftrag von Jakob Voss
> Gesendet: Mittwoch, 12. Januar 2011 14:48
> An: public-esw-thes@w3.org
> Betreff: How to distinguish unique and non-unique prefLabels?
> Hi,
> Mapping a classification (not a thesaurus) to SKOS, I 
> stumbled upon the problem of distinguishing unique and 
> non-unique preferred labels. The concepts in our classification have
> 1. a unique notation (unique)
> 2. a main label (not unique, as it's no thesaurus)
> 3. an extendend main label (unique by adding a qualifier)
> 3. possibly alternative labels
> Here is a simple example with the non-existing property 
> "skos:uniquePrefLabel" for the extended, unique label:
> <15.00>
>    skos:notation "15.80" ;
>    skos:prefLabel "history"@en ;
>    skos:narrower <15.87> .
> <15.87>
>    skos:notation "15.87" ;
>    skos:prefLabel "USA"@en ;
>    skos:uniquePrefLabel "History (USA)"@en ;
>    skos:altLabel "United States"@en .
> I am searching for a best practice to encode both types of preferred
> labels: the non-unique but short label, best used in 
> combination with a notation and/or in a hierarchical view if 
> the KOS is used as classification, and the artificial but 
> unique label, best used if the KOS is used as thesaurus.
> The best solution that I found so far, is creating
> skos:nonUniquePrefLabel rdfs:subPropertyOf skos:prefLabel ;
>    skos:scopeNote "a preferred label, that is not unique for 
> some concept scheme" .
> skos:uniquePrefLabel    rdfs:subPropertyOf skos:prefLabel ;
>    skos:scopeNote "a preferred label, that is unique for some 
> concept scheme" .
> but I hesitate to create just another RDF property that 
> nobody else uses. Any suggestions?
> Jakob
> P.S: The same can be applied to notations, but non-unique 
> notations are probably less common than non-unique preferred labels.
> --
> 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 15:01:21 UTC

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