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

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

From: Alistair Miles <alimanfoo@googlemail.com>
Date: Thu, 13 Jan 2011 11:58:24 +0000
To: Neubert Joachim <J.Neubert@zbw.eu>
Cc: Jakob Voss <jakob.voss@gbv.de>, public-esw-thes@w3.org
Message-ID: <20110113115824.GA3843@aliman-desktop>
Hi all,

Very interesting discussion.

I don't want to sound like an authoritarian, and a certainly don't want
to discourage this type of discussion, but can I ask that when discussing
possible extensions to the SKOS classes and properties, we stick to the
practice of defining extensions *outside* the SKOS and SKOS-XL namespaces.

I.e., if you have an idea for a new class or property extending SKOS,
but you don't yet have a namespace, please use "ex:myProperty" or
"ex:myClass" in emails to this list. Please do not use "skos:myProperty"
or "skosxl:myProperty". Even if you think your idea should be considered
for the next version of SKOS, please do not use "skos:myProperty" at this
stage - use "ex:myProperty", or if you have published your schema,
"whatever:myProperty" ... if your extension gains any critical mass, a
possible future WG could then discuss whether to bring your extension into
the SKOS namespace.

The only reason I say this is because I'm concerned that there might be folks
on this list who are just learning about SKOS, and if they see emails with
skos:foo and skos:bar they could easily get confused about whether these are
official SKOS properties. They could also get the impression that it's OK
to start inventing new properties in the SKOS namespace, which is strongly
discouraged - extensions should always go in your own namespace, so others
can always find their way from the property or class URI it's definition in
your schema.

The same goes for anyone who publishes SKOS data. If your data uses properties
or classes in the SKOS namespace that are not currently defined in the SKOS
Reference [1] then please change to using a URI in your own namespace,
and publish your schema so other's can find a definition of what your
extension means.

</end-authoritative-rant>

I'm still conscious that there isn't a really good way to find out about what
extensions and design patterns have been proposed and discussed within this
community, and that makes it harder to build consensus and avoid re-inventing
the wheel. The wiki could work, but takes some editorial work to keep updated,
and it's hard to guage consensus. I've been thinking recently that a website
that works a bit like stack overflow, but where you can post a design pattern
or extension to SKOS and have others vote for/against and comment, would be
a lovely tool ... anyone feel like making it happen? :)

Cheers,

Alistair

[1] http://www.w3.org/TR/skos-reference/

On Thu, Jan 13, 2011 at 10:27:03AM +0100, Neubert Joachim wrote:
> Hi Jakob,
> 
> Thanks for pointing this out, I didn't get you fully in the first step.
> 
> dc:title surely is a valid modeling solution for distinguishing preferred from non-preferred non-unique labels, and its use looks quite intuitive also. (So I'll probably add it in the next STW version for the plain labels.) An application however will need this piece of special knowledge as well.
> 
> My arguing for the uniqueness asumption of skos:prefLabel had in mind more general applications, which deal with data (not necessarily SKOS concepts) of different structure. I like the idea to have a (mostly) unique label for every piece of data, to use it as a heading in a "record-like" display, for a generic way of sorting result sets, for creating a generic one-line result list entry, etc. For such use cases, it doesn't hurt much that skos:prefLabel is not *guaranteed* to be unique. (And I think it is wise that guaranteed uniqueness is not required here.)
> 
> By generating 
> 
>    skos:uniquePrefLabel "History (USA)"@en ;
> 
> in your example, you achieve the same ends. I think *how* to generate such unique labels depends heavily on the underlying data and the use cases you think about - and finally is a matter of taste, too. Of cause, no application should depend on the semantics of such generated labels, but get the needed information from more specific properties. So, in my point of view, there is no need to argue about "real" and "false" labels here ;)
> 
> Thanks for rising this discussion!
> 
> 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 17:13
> An: public-esw-thes@w3.org
> Betreff: Re: AW: How to distinguish unique and non-unique prefLabels?
> 
> 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
> 
> 

-- 
Alistair Miles
Head of Epidemiological Informatics
Centre for Genomics and Global Health <http://cggh.org>
The Wellcome Trust Centre for Human Genetics
Roosevelt Drive
Oxford
OX3 7BN
United Kingdom
Web: http://purl.org/net/aliman
Email: alimanfoo@gmail.com
Tel: +44 (0)1865 287669
Received on Thursday, 13 January 2011 11:59:01 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 13:32:14 UTC