W3C home > Mailing lists > Public > public-esw-thes@w3.org > March 2007

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

From: Miles, AJ \(Alistair\) <A.J.Miles@rl.ac.uk>
Date: Mon, 19 Mar 2007 14:27:06 -0000
Message-ID: <677CE4DD24B12C4B9FA138534E29FB1D0285A1C7@exchange11.fed.cclrc.ac.uk>
To: "Antoine Isaac" <aisaac@few.vu.nl>
Cc: <public-swd-wg@w3.org>, <public-esw-thes@w3.org>

Hi Antoine,

Whenever I say "semantics" I mean formal semantics specified using model
theory, see:

[1] http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#prelim

I think you have slightly misunderstood my intention. Let me try to
explain a different way, raising some issues in the issue tracker at the
same time ...

 - Issue: "BasicLexicalLabelSemantics"

Can a resource have two "preferred lexical labels"? Can a lexical label
be both
"preferred" and "alternative" for the same resource? If a lexical label
is
"hidden", can it also be "preferred" or "alternative" for the same
resource?

See:

 [2]
<http://www.w3.org/2006/07/SWD/wiki/SkosDesign/BasicLexicalLabelSemantic
s>
 [3] <http://www.w3.org/2006/07/SWD/track/issues/31>

 - Issue: "ConceptSchemeLabellingInteractions"

Can two different concepts in the same concept scheme have any lexical
labels in common?

I.e. can two different concepts in the same concept scheme both have the
same preferred lexical label? Can two different concepts in the same
concept scheme both have the same alternative lexical label? Can a
lexical label be preferred for one concept and alternative for a
different concept in the same concept scheme? Can a lexical label be
hidden for one concept and either preferred or alternative for a
different concept in the same concept scheme?

See:

 [4]
<http://www.w3.org/2006/07/SWD/wiki/SkosDesign/ConceptSchemeLabellingInt
eractions>
 [5] <http://www.w3.org/2006/07/SWD/track/issues/32>

Does that clarify?

Cheers,

Al.

--
Alistair Miles
Research Associate
CCLRC - Rutherford Appleton Laboratory
Building R1 Room 1.60
Fermi Avenue
Chilton
Didcot
Oxfordshire OX11 0QX
United Kingdom
Web: http://purl.org/net/aliman
Email: a.j.miles@rl.ac.uk
Tel: +44 (0)1235 445440  

> -----Original Message-----
> From: public-swd-wg-request@w3.org 
> [mailto:public-swd-wg-request@w3.org] On Behalf Of Antoine Isaac
> Sent: 02 March 2007 10:47
> To: Miles, AJ (Alistair)
> Cc: public-swd-wg@w3.org; public-esw-thes@w3.org
> Subject: 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 Monday, 19 March 2007 14:27:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:38:55 GMT