RE : Use case : issues with unicity of skos:prefLabel

Dear Bernard and Jakob,

That's funny, I encountered a very similar problem last week, trying to represent http://www.kb.nl/vak/basis/bc04.pdf

In this classification, a concept has as main label a term that can be ambiguous, and a 'context-free' label which is unambiguous. It also has a notation, like 17.35, which is unambiguous and used as the main entry point. So I had no trouble for finding an 'artificial language' prefLabel, in the way Jakob proposed to model these things for classifications [1]. However, when deciding for a prefLabel *for Dutch*, I went for the 'context-dependent' label. This is contrary to SKOS specs, but in accordance to what seemed preferred or not. Indeed in the 'official release' the context-free label is never mentioned...

I agree that this is a situation quite different from yours. But I will try to ask the experts of my vocabulary what they would like to keep or create as prefLabels in your situation.

By the way I got some information that could be useful for you while actually searching for the above web reference. On http://www.kb.nl/dutchess.ned/nbc_main.html , they did try to deal with this context dependency problem in a way quite similar to what you did for the content of your own prefLabel. "Communicatiewetenschap: onderwijs, beroepsuitoefening, organisaties" was coined for "onderwijs, beroepsuitoefening, organisaties" under "Communicatiewetenschap" (sorry for the Dutch ;-) )
Notice that this is neither a recent and official choice, nor what was chosen for the context-free label in my version ("onderwijs, beroepsuitoefening en organisaties van de communicatiewetenschap"). Personnally I think I would have used brackets, as it happens quite a lot of times in vocabularies when disambiguation is needed by some qualification, like "processes (industry)". But this is less convenient in your case since you need 2 levels of context!


Now, to answer Jakob's proposals (sorry I was writing when you sent this one), I would say that I quite disagree on important points:
- although SKOS OWL ontology does not say formally that prefLabel is InverseFunctional, the SKOS core specification says that each concept is identified by its prefLabel [1]. So you cannot just say "But you can still use skos:prefLabel as described above.", that is having ambiguous prefLabels. I did it myself only because I had a 'language' for which the prefLabels were unambiguous, but I'm still not sure I were right.
- Bernard has not said he had classification schemes notations in his hierarchy, so the complex label he builds might be the *only identifying* one, contrary to your "So you build another unique identifying label - what is the purpose?"
- Bernard cannot use skos:notation simply because it's not in today's SKOS namespace. Of course we might fight for having it in a further recommendation, but for the moment you have to deal with SKOS as it is. Otherwise the benefits of standardisation are not granted. Perhaps what Bernard could do is to introduce some bernard:caption, declare it as a subproperty of skos:prefLabel or altLabel depending on his final choice, and only change this subproperty information when a new SKOS (or SKOS extension) comes into play.
By the way I suppose that whenever you use skos:notation you actually refer to skos:caption (the first being for artificial codes and the second natural language labels)

Best,

Antoine

PS: That being said, Jakob, I think your ideas about classifications are really good, and I even apply some of them as I said ;-). What I object to is their immediate application to Bernard's case.


[1] http://esw.w3.org/topic/SkosDev/ClassificationPubGuide
[2] http://www.w3.org/TR/2005/WD-swbp-skos-core-spec-20051102/#prefLabel


-------- Message d'origine--------
De: public-esw-thes-request@w3.org de la part de Jakob Voss
Date: jeu. 19/10/2006 15:49
À: public-esw-thes@w3.org
Objet : Re: Use case : issues with unicity of skos:prefLabel
 

Hi Bernard!

Thanks for pointing us to another special controlled vocabulary we have
to deal with! You wrote:

> the same term can be used several times with different semantics, the 
> disambiguation being made by its position in the broader-narrower
> hierarchy - which is always displayed in any index publication,
> so the term is never used "out of context".

This sound similar to a classification where same class names may occur
at different positions for different classes. But in a classification
there are normally notation to identify a class.

I talked with Alistair about the need of captions and notations in SKOS.
There is definitely the need for a new property skos:notation. For
captions he suggested to weaken the uniqueness requirement of
skos:prefLabel. Is your concept scheme a strict thesaurus? If this is
not the case then prefLabel does not have to uniquely identify a concept.

> For example you will have that kind of hierarchy in the index (the
> actual terms are in french ...)
> 
> Civil procedure
>    General principles
>        Procedure action
>            Notification
> 
> It's clear that "Notification" is likely to be not unique in the index.

But you can still use skos:prefLabel as described above.

> So if we want a unique identifying name for each index entry, the
> context has to be included. The solution we have come up to, is to mark
> as "context terms" the terms which disambiguate their descendants . In
> this case "Civil procedure" and "Procedure action" are declared as
> context terms, but "General principles" is not (it's useless for
> disambiguation). Hence the identifying string of Notification should be
> something like : "Civil procedure: Procedure action: Notification". 

So you build another unique identifying label - what is the purpose?

1.) Do you want this label for prefered display? Then use skos:prefLabel
and "Notification" is just an skos:altLabel.

2.) Do you want this label only to use when you need to uniquely
identify concepts? Then use skos:notation like in a classification
scheme. By the way many notations in classification schemes also include
hierarchical information (if you know how to decode them).

> A kind of post-coordination based on hierarchy, if you like.

Well ....no.

> My question is : if we want to represent that in SKOS, what should be
> the practice?

We need a new property skos:notation or skos:notationLabel.

> Using "Civil procedure: Procedure action: Notification" as
> skos:prefLabel seems unavoidable if one wants unicity of prefLabel,

The unicity of prefLabel is only needed for thesauri. Because SKOS has
been mainly used for thesauri we thought that prefLabel always needs to
be unique in a ConceptScheme. But the uniqueness is only a property of a
ConceptScheme that needs to be fullfilled in order to use the
ConceptScheme as a thesaurus.

> In topic maps (and in Mondeca ITM too) we have the cool notion of 
> "display Name". Would not be skos:displayLabel a good idea in that case?
> I vaguely remember this property has been discussed at some point. Then
> we would have
> 
> skos:prefLabel              Civil procedure: Procedure action: Notification
> skos:displayLabel          Notification
> skos:altLabel                 Procedure notification

With skos:notation we would have:

skos:prefLabel  "Notification" .
skos:notation   "Civil procedure: Procedure action: Notification" .
skos:altLabel   "Procedure notification" .

Greetings,
Jakob