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

Dear Antoine and Bernard!

You wrote:

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

Good to know! My starting point to deal with SKOS was the need to
multiple classifications and thesauri for browsing access in
PICA-systems - the Nederlandse basisclassificatie is one of them :-)

> 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. 

I have not noticed that there are also 'context-free' labels. What's
their purose (for indexing, display, ...?). Can you give an example?
Propbaly in your case they are best described as skos:altLabel, aren't they?

> So I had no trouble for finding an 'artificial
> language' prefLabel, in the way Jakob proposed to model these things
> for classifications [1]. 

This is a controversial workaround (language code 'alt' or 'zxx' no
language code at all) - the cleanest solution is to introduce a new
property skos:notation or skos:notationLabel.

> 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...

Sorry, I don't understand what you did. Can you give an example in your
SKOS encoding please?


> 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.

In my opinion there are two different purposes for labels that are not
just additional labels:

A) Beeing presented for display of the concept

B) Uniquely identify a concept


In the current SKOS standard [2] both are mixed together. This needs to
be fixed. There are three possibilities:

1.) Modify the meaning of skos:prefLabel to A) only and create a new
property skos:notation for meaning B)

2.) Modify the meaning of skos:prefLabel to B) only and create a new
property skos:caption for meaning A)

3.) Create two new properties skos:caption for meaning A) and
skos:notation for meaning B) and use skos:prefLabel if both meanings apply

I propose the first solution but the third is also possible.


> 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!

The general concept for this "brackets" in information science is a
"qualifier" that is added to a term for disambiguation. I thought about
whether to encode this mechanism in next version of SKOS but maybe this
is beyond the scope of SKOS. You can think of too many ways to create
unique labels out ambiguous labels. How about putting all of them in
skos:notation ?


> 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 [2].

It's only a comment and we could drop it.


> 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.

Sometimes there is more than wrong and right - it always depends on what
standard/authority/moral... you refer to ;-) But you are right according
to the current SKOS specification.[2] Using another language code like
"alt" or "zxx" for notations as I proposed in [1] is also right
according to the current SKOS specification.


> 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?" -

If he artifically builds complex labels then I would call this
"notations". My questions "what is the purpose?" refers to

A) Beeing presented for display of the concept
B) Uniquely identify a concept
C) Both
D) Something else

> 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.

I like fighting ;-)

> 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.

Yes, Bernard needs a new property unless we treat skos:prefLabel as
both A and C (Uniquely identify *and* beeing presented for display).

So the example can be encoded:

 skos:prefLabel  "Civil procedure: Procedure action: Notification"@alt
 my:caption       "Notification"@en
 skos:altLabel    "Procedure notification"@en

In my opnion this is ugly because I prefer to interprete the meaning of
skos:prefLabel to only indicate the prefered Label for display. With my
interpretation the example can be encoded:

 skos:prefLabel   "Civil procedure: Procedure action: Notification"@alt
 skos:prefLabel   "Notification"@en
 skos:altLabel    "Procedure notification"@en


> 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)

By the way "Civil procedure: Procedure action: Notification" is not
natural language anymore but pretty artificial because of the ":".


> 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.

Thanks for you fruitful feedback - a good discussion always helps to
clarify your point of view :-)

Greetings,
Jakob

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

Received on Thursday, 19 October 2006 16:26:23 UTC