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

Re: RE : Issue : unicity of prefLabel per language per concept scheme

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Tue, 11 Dec 2007 18:52:38 +0100
Message-ID: <475ECE66.3060500@few.vu.nl>
To: "Sini, Margherita (KCEW)" <Margherita.Sini@fao.org>
CC: Stella Dextre Clarke <sdclarke@lukehouse.demon.co.uk>, Alasdair Gray <agray@dcs.gla.ac.uk>, SKOS <public-esw-thes@w3.org>, public-swd-wg@w3.org

Hi all,

- although I prefer 1 and 3, I think the current SKOS labelling 
semantics do not formally prohibit 2. Alistair, could you confirm that 
they say that concept scheme should have unambiguous labels, and that 
they don't say that concept scheme must have unambiguous labels?
- I think the argument about burro/burro and bank/bank is not exact: we 
have burro@it/burro@es on the one side, and bank@en/bank@en on the other 
side. There is a crucial difference in terms of RDF literal equality!
- actually I buy your point about merging the two canyon concepts in 
this specific case, which someone already hinted at on the list before ;-)

There are indeed some good reasons for introducing something like a 
"notation" property. But I don't know if we want to add this in the SKOS 
recommendation, and encourage all SKOS implementations to deal with one 
property which even if often enountered might not be so frequent. The 
reason for which I'm uncomfortable this specific notation stuff 
problematic, is that its presence interfere with the way other labelling 
statements should be dealt with.
Perhaps we could just provide the pattern, and update the semantics as 
you suggest: "preferred labels should be unambiguous, unless an 
alternate property provides an unambiguous token for the concept". But 
in that case the concept scheme might be not so well managed by other 
standard SKOS tools.



> Hi all,
> I also like this topic as I had to deal with it a lot of times... 
> working with AGROVOC in 18 languages....
> My suggestions:
> 1) disambiguate the label inside the vocabulary itself:
>     example "canyon (planet)" and "canyon (satellite)"
> Not very elegant and this may be complicated for searching, mappings, etc.
> 2) just leave the possibility of duplicating strings.... and leave the 
> applications to disambiguate by asking the user to disambiguate....
> I know this may be revolutionary, maybe also is going agains the ISO 
> rules..., but i think that this depends on the use we want to make of 
> the thesauri: if the future is to make URI or concept 
> indexing/searching and not anymore string-indexing, then this solution 
> may be acceptable...
> The applications can tell the user, when he enter  "canyon", "do you 
> mean planet canyon or satellite canyon?" and this can be done by 
> taking in consideration the broad concept....
> Is possible in SKOS to have this duplications on the labels? I think 
> depends only on the applications that manage the SKOS data.... In any 
> case there is no ambiguities as far as the definition of a 
> concept(term) is given with BT, NT, RT and alternativeLabels... 
> 3) add as Stella was mentioning an element or attribute or something 
> that helps on identifying the context... although i think the BT may 
> be enough...
> In any case I do not think that within a language or across languages 
> is a problem... Because if we can allow duplications between languages 
> (e.g. Burro in Spanish, and Burro in Italian), why we cannot also 
> allow duplications within a language (e.g. "bank" and "bank" -of the 
> river- in English) ?
> By the way, to solve the canyon problem I have also an idea: although 
> I know that multiple BT are not to be preferred... would anyway be 
> possible to make a unique term (or concept) "canyon" be related 
> (whatever the relations is BT, RT...) to both planet and also 
> satellite? I mean, do not have 2 prefLabels, but have only 1 as there 
> will be a unique concept...
> Just a though...
> Regards
> Margherita
>     -----Original Message-----
>     *From:* public-swd-wg-request@w3.org
>     [mailto:public-swd-wg-request@w3.org] *On Behalf Of *Stella Dextre
>     Clarke
>     *Sent:* 07 December 2007 18:20
>     *To:* 'Antoine Isaac'; 'Alasdair Gray'; 'SKOS'
>     *Cc:* public-swd-wg@w3.org
>     *Subject:* RE: RE : Issue : unicity of prefLabel per language per
>     concept scheme
>     Antoine/Alasdair,
>     Just a brief comment on the proposal below. I have a lot of
>     sympathy with the general sentiment, but some doubts about simply
>     treating the notation as another language version. Why not
>     introduce it straightforwardly as notation, another (optional)
>     element of SKOS? Some thesauri (especially multilingual ones) have
>     a notation as well as terms, so would sometimes use it.
>     Classification schemes would almost all use it. Some taxonomies
>     would use it. Of course, the different vocabulary types may each
>     use it in slightly different ways! (For example, in MeSH, a
>     given term may have more than one notation.)
>     The general guideline would be something like: "Each concept
>     should have either a prefLabel which is unique within any one
>     language, or a unique notation." There would need to be an
>     explanation somewhere of whether the notation or the prefLabel was
>     to be used for purposes of conveying uniqueness.
>     All the best
>     Stella
>     *****************************************************
>     Stella Dextre Clarke
>     Information Consultant
>     Luke House, West Hendred, Wantage, Oxon, OX12 8RR, UK
>     Tel: 01235-833-298
>     Fax: 01235-863-298
>     SDClarke@LukeHouse.demon.co.uk
>     *****************************************************
>         -----Original Message-----
>         *From:* public-esw-thes-request@w3.org
>         [mailto:public-esw-thes-request@w3.org] *On Behalf Of *Antoine
>         Isaac
>         *Sent:* 03 December 2007 11:19
>         *To:* Alasdair Gray; SKOS
>         *Cc:* public-swd-wg@w3.org
>         *Subject:* RE : Issue : unicity of prefLabel per language per
>         concept scheme
>         Hi,
>         I bumped into the same problem as well with a classification
>         scheme. But it had actually context-independent labels in
>         addition to the context-dependent ones, so I could deal with
>         it, even though in a not-that-satisfactory way.
>         Notice however that the sentence Bernard quotes is only about
>         recommendation:
>         "It is recommended that no two concepts in the same concept
>         scheme be
>         given the same preferred lexical label in any given language."
>         My guess is that a SKOS validator would just issue warnings
>         when the situation occurs.
>         Also, an important point: the sentence is not even in the SKOS
>         current reference draft [1]!
>         Perhaps we could change the sentence, wherever it appears in
>         the end, to fit the usual classification scheme situation as
>         Stella presents it. I would propose something like
>         "It is recommended that there is one language for which no two
>         concepts in the same concept scheme be
>         given the same preferred lexical label."
>         assuming that the notation language is this language, for
>         classification schemes (btw I always use the zxx language tag
>         for notations)
>         Now, for vocabularies that do not have unique prefLabels, even
>         taking into account notations, my first reaction would be
>         similar to  Alasdair's: are such "canyon" and "canyon"
>         concepts really distinct in the end? ;-)
>         Cheers,
>         Antoine
>         [1]
>         http://www.w3.org/2006/07/SWD/wiki/SKOS/Reference#head-1c19f19602cc0ce6e7c77c86c170c95e8e16873b
>         -------- Message d'origine--------
>         De: public-esw-thes-request@w3.org de la part de Alasdair Gray
>         Date: lun. 03/12/2007 11:39
>         └: SKOS
>         Objet : RE: Issue : unicity of prefLabel per language per
>         concept scheme
>         Hi,
>         I have come across the same issue in the astronomy
>         vocabularies that I have been working on. As yet, I have not
>         come up with a good solution either.
>         I did try using preferred label with no context path
>         information, but this proved to be very confusing in the user
>         interface that I am preparing (where currently just a list of
>         preferred labels is shown): there was no way to distinguish
>         between a Canyon on the surface of a planet and a Canyon on
>         the surface of a satellite. However, I agree that including
>         the context in the preferred label is cumbersome.
>         One thing that I have not completely cleared up in my own mind
>         yet is whether the concepts are really disjoint. After all, in
>         the astronomy situation, a canyon is a canyon whether it is on
>         a planet or a satellite. In this situation, would some sort of
>         compound label which uses both canyon and planet/satellite
>         make sense (this hopefully can be easily translated into the
>         child custody example or are your concepts actually disjoint?).
>         Cheers,
>         Alasdair
>         Alasdair J G Gray
>         Research Associate: Explicator Project
>         http://explicator.dcs.gla.ac.uk
>         Computer Science, University of Glasgow
>         0141 330 6292
>         -----Original Message-----
>         From: public-esw-thes-request@w3.org
>         [mailto:public-esw-thes-request@w3.org] On Behalf Of Bernard
>         Vatant
>         Sent: 3 December 2007 09:54
>         To: SKOS
>         Subject: Issue : unicity of prefLabel per language per concept
>         scheme
>         I've several current SKOS use cases making me wondering about this
>         recommendation in
>         http://www.w3.org/TR/2005/WD-swbp-skos-core-guide-20051102/#secmulti
>         "It is recommended that no two concepts in the same concept
>         scheme be
>         given the same preferred lexical label in any given language."
>         This recommendation follows the thesaurus standard practice,
>         but other
>         types of structured vocabularies which seem to be in the scope
>         of SKOS
>         don't follow this practice. I've in mind controlled
>         vocabularies in law,
>         where the same term is used in different contexts to label
>         different
>         concepts, the disambiguation being by context. The context
>         itself is
>         usually formally represented by a path to the concept in the
>         broader-narrower tree, e.g., the following are four distinct
>         concepts
>         all using the term "Children custody" in different contexts,
>         but in the
>         same Concept Scheme "Divorce".
>         Contentious divorce: Temporary arrangements: Children custody
>         Contentious divorce: Definitive arrangements: Children custody
>         Non-contentious divorce: Temporary arrangements: Children custody
>         Non-contentious divorce: Definitive arrangements: Children custody
>         In such cases, encapsulating the context in the prefLabel
>         string is
>         rapidly cumbersome in interfaces, the context chain can become
>         arbitrarily long in such matters.
>         How would one SKOS-ify such a vocabulary? If "Children
>         custody" is used
>         as prefLabel, the recommendation of unicity is obviously
>         broken, if not,
>         what should be the recommended value of prefLabel?
>         Bernard
>         --
>         *Bernard Vatant
>         *Knowledge Engineering
>         ----------------------------------------------------
>         *Mondeca**
>         *3, citÚ Nollez 75018 Paris France
>         Web:    www.mondeca.com <http://www.mondeca.com>
>         ----------------------------------------------------
>         Tel:       +33 (0) 871 488 459
>         Mail:     bernard.vatant@mondeca.com
>         <mailto:bernard.vatant@mondeca.com>
>         Blog:    Lešons de Choses <http://mondeca.wordpress.com/>
Received on Tuesday, 11 December 2007 18:46:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:45:45 UTC