Re: [SKOS] Possible issue: Uniqueness of skos:prefLabel [was Re: [SKOS] inconsistency between Guide and Specification

Hi Alistair

Thanks for the long mail. I think I got the idea, but the naming of the 
issues is confusing (perhaps because of the many different 
interpretation of "semantics"), and the use of examples too. To me the 
'content' of the conditions mentioned in issue 1 should be discussed in 
issue 2, while (correct me if I'm wrong) issue 1 is just about the 
question of formally encoding these axioms in a specific language or 
not, and decide (or not) to use them as a basis for quality checking 
procedures.

Shortly, I want to make three remarks on what in my eyes should be in 
issue 2, that is the 'content' of the conditions

>The first of these is that, intuitively, only one label (per language
>per script) can be "preferred". In other words, it does not make sense
>for two things to both be "preferred".
>
>The second of these is that, intuitively, it does not make sense for a
>label to be both "preferred" and "alternative"; or both "preferred" and
>"hidden"; or both "alternative" and "hidden".
>  
>
I completely agree with the beginning, less with the conditions on 
"hidden". What if a typo on a term for a concept (which could be encoded 
as hidden, if I understood well this property) corresponds to the 
preferred term of another concept? I agree this is borderline, but if 
someone has met this situation it is time to say it before we register 
the condition as valid!

>
>In some types of controlled vocabulary, it may be entirely reasonable
>for two concepts in the same scheme to have the same preferred lexical
>label (in some language/script). This is the case, for example, in some
>classification schemes (where two "classes" may have the same "caption")
>and corporate taxonomies (where two "nodes" may have the same "label"),
>in which case either the notation or the context is used to disambiguate
>meaning.
>  
>
True. It might also be the case in multilingual thesauri having one 
'reference' language, in which the prefLabels are unambiguous, and 
'translations' which are less constrained.
Notice then that it does not remove completely the constraint, which 
should read like "there is at least one language in which the prefLabel 
is unambiguous" (which is btw the case is many classification schemes, 
in which the 'artificial' notation language plays this role)

><snip> For this reason, I agree with Guus that these two sentences be dropped
>from all future SKOS specifications, and that no formal conditions
>should be placed on the use of the SKOS lexical labeling properties in
>conjunction with the SKOS concept scheme constructs (currently
>skos:inScheme and skos:ConceptScheme).
>
>However, for a SKOS concept scheme to be *usable* as a thesaurus (i.e.
>compatible with software following the ISO2788 standard) some
>restrictions must be observed on the use of these properties in
>conjunction.
>
>
>
>Because of the importance of being able to identify compatibility with
>existing thesaurus software and standards, I would like to argue that we
>specify, informally, a set of restrictions which may be *optionally*
>applied in order to detect thesaurus incompatibility. I.e. these
>restrictions *would not* be part of the formal semantics of SKOS. 
>  
>
I agree with the fact that even my "adapted" condition above could be 
restricted so such a 'best practice for thesauri' informal and optional 
approach.
I would however say that I think this condition apply to a very wide 
range of concept schemes, if not an overwhelming majority. The only one 
I can think of at the moment are perhaps the web taxonomies such as 
Yahoo. And I think none of the use cases gathered for SKOS has this 
ambiguity case. Once again, this is a call for (counter-)examples!

>These restrictions can be stated informally, with examples of SPARQL
>queries that could be used to detect incompatibilities. Expressing these
>restrictions formally is complicated and unnecessary. 
>  
>
Of course if no constraint is kept in the end (that is, Guus' proposal) 
I fully agree with this policy.

Cheers,

Antoine

>  
>
>>-----Original Message-----
>>From: public-swd-wg-request@w3.org
>>    
>>
>[mailto:public-swd-wg-request@w3.org]
>  
>
>>On Behalf Of Guus Schreiber
>>Sent: 27 February 2007 12:01
>>To: public-swd-wg@w3.org
>>Cc: SWD WG
>>Subject: [SKOS] Possible issue: Uniqueness of skos:prefLabel [was Re:
>>[SKOS] inconsistency between Guide and Specification
>>
>>
>>
>>
>>Guus Schreiber wrote:
>>    
>>
>>>While trying to write down a resolution for the relationship between
>>>labels I found:
>>>
>>>in the Core Guide, section on Multilingual La belling [1]
>>>
>>>[[
>>>  It is recommended that no two concepts in the same concept scheme
>>>      
>>>
>be
>  
>
>>>given the same
>>>  preferred lexical label in any given language.
>>>]]
>>>
>>>in the Core Specification, table of prefLabel [2]
>>>
>>>[[
>>>  No two concepts in the same concept scheme may have the same value
>>>      
>>>
>for
>  
>
>>>skos:prefLabel
>>>  in a given language.
>>>]]
>>>      
>>>
>>I see no need for placing a constraint on the
>>uniqueness of skos:prefLabel. While some/many
>>vocabularies will actually abide to this, the URI
>>of the concept the label is related already
>>ensures uniqueness of the concept being identified
>>(which I assume was the reason for including this
>>constraint in the ISO spec). I also suggest that
>>there is no need to place cardinality constraints
>>on skos:prefLabel.
>>
>>The underlying rationale is that we should refrain
>>from overcommiting the SKOS specification when
>>there is no clear need.
>>
>>I want to raise this as an issue and propose the
>>above as a resolution.
>>
>>    
>>
>>>The weaker constraint in the Guide makes sense to me. I will most
>>>      
>>>
>likely
>  
>
>>>propose an even weaker version in my resolution.
>>>
>>>Guus
>>>
>>>
>>>
>>>[1]
>>>      
>>>
>http://www.w3.org/TR/2005/WD-swbp-skos-core-guide-20051102/#secmulti
>  
>
>>>[2] http://www.w3.org/TR/swbp-skos-core-spec/#prefLabel
>>>      
>>>
>>--
>>Vrije Universiteit Amsterdam, Computer Science
>>De Boelelaan 1081a, 1081 HV Amsterdam, The Netherlands
>>T: +31 20 598 7739/7718; F: +31 84 712 1446
>>Home page: http://www.cs.vu.nl/~guus/
>>    
>>
>
>
>
>  
>

Received on Friday, 2 March 2007 10:51:10 UTC