# Re: skos:prefLabel without language tag

From: Christophe Dupriez <christophe.dupriez@destin.be>
Date: Mon, 27 Jun 2011 10:16:19 +0200
Message-ID: <4E083C53.1080101@destin.be>

Hi!

I would like to support Antoine answer: in my opinion, SKOS is a
"cross-boundary" tool, it links machine encoded information to users
terminological abilities. To see SKOS as pure RDF used for machine
reasoning may fit some applications but may be not those of "vocabulary
managers" who want to link data and humans. Often they are under heavy
pressure and cannot gather immediately all requested translations.

For instance, prefLabel without language is (for us) a "catch all" in
case we (still) do not have a better term in a given language.
It is unique (no need for two catch-all) and it is redundant for a given
concept if all languages, required by the applications, already have
their prefLabel specified (so, for OPOCE, it would be forbidden in a
published EUROVOC version).

I would like to signal another need we had to fulfill: to distinguish
between scientific name (latin) and vernacular names for some domains
(plants, animals). In those cases, latin is indicated to be "supra
language", stronger than the user language.

So our prefLabel choice for a given user is (in disminishing priority):
* prefLabel in a supraLanguage defined for the current ConceptScheme
* prefLabel in the user language (may be added to the supraLanguage one
if desired by user/application)
* prefLabel without language
* prefLabel in english
* prefLabel in any language
But this is more related to how you use prefLabel than to how you define
them...

Have a nice day!

Christophe

Le 24/06/2011 14:07, Antoine Isaac a écrit :
> Hi Armando, Bernard,
>
> SKOS indeed encourages the use of language-tagged labels. This is why
> almost all examples in the doc have language tags, and probably the
> reason for which we now have to make S14 clearer--cf. our other
> discussion now.
>
> But we also have to remain simple, and compatible with a wide range of
> data. For many vocabularies, publishing language info is technically
> difficult, or even impossible. This is especially the case for
> vocabularies that have been aggregating labels originating from
> different languages, but with data structures that do not allow (or
> make difficult) to track language provenance.
>
> Cheers,
>
> Antoine
>
>
>> Hi all,
>>
>> agree with Bernard.
>>
>> Even more, for how much it can seem restrictive (and possibly causing
>> huge panic for retrocompatibility with huge amount of existing data,
>> but every revolution has its heads chopped off…), I would think of a
>> revision of SKOS as **really** suggesting not to use (forbidding?)
>> prefLabels with no language tag. One of the SKOS objectives was to
>> give a decent coverage of the linguistic descriptions of concept
>> schemes (and ontologies in general, as prefLabel is now an
>> AnnotationProperty [S10] thus admitting any resource in its domain),
>> and thus a prefLabel with no language tag makes no sense to me. One
>> could say that plainLiterals could be used with no langtag to address
>> specific codes related to no natural language, but there are better
>> options for that (i.e. skos:notation).
>>
>> In my experience, I’ve always had to make-do somehow with missing
>> lang tags, because usually those values still are explained in some
>> language, so you have to know it in advance, or guess it…so, lot of
>> patches to any software ever written for natural language querying
>> over ontologies, to account for the language assumed to be used for
>> no-langtagged-literals. Collapsing indexes for no-lang-tags with
>> lang-tags of the same language etc…
>>
>> This is a dirty work to be done when dealing with rdfs:label, but an
>> highly specified (and specific) property as prefLabel could surely
>> better live without “no-lang-tagged” plainLiterals.
>>
>> Armando
>>
>> *From:* public-esw-thes-request@w3.org
>> [mailto:public-esw-thes-request@w3.org] *On Behalf Of *Bernard Vatant
>> *Sent:* Friday, June 24, 2011 11:12 AM
>> *To:* Antoine Isaac
>> *Cc:* public-esw-thes@w3.org
>> *Subject:* Re: skos:prefLabel without language tag
>>
>> Hello all
>>
>> Thinking further about it, beyond the formal issue we have the
>> question of the expected behaviour of applications when meeting
>> labels w/o language tags.
>>
>> In multilingual environments, the language tag is typically used to
>> present the concept to end users in their "user language". The
>> unicity of the prefLabel in the user language avoids clashes in the
>> interface. Note that some systems (e.g., Eurovoc and other OPOCE
>> vocabularies) even require that all concepts have a prefLabel in all
>> supported user languages (e.g., EU official languages), including
>> default value rules (such as take the English label if no label is
>> available in Slovenian or Swedish).
>>
>> In our (Mondeca ITM) system, a label (aka "name") has also a
>> mandatory and unique language tag, but one possible value is "no
>> language". The behaviour of the system regarding this tag is that
>> such names are displayed whatever the user language choice. Of course
>> if one wants unicity of the displayed name, it implies that if there
>> is a "no language" name, there is no (other) name tagged with a
>> language.
>>
>> Translated in SKOS, this rule would look like :
>>
>> *If a Concept has a prefLabel value with no language tag, it cannot
>> have a different prefLabel value with a language tag.*
>>
>> IOW the following is not conformant
>> ex:foo skos:prefLabel 'A'; prefLabel 'B'@en
>>
>> The following is conformant but somehow redundant
>> ex:foo skos:prefLabel 'A'; prefLabel 'A'@en
>>
>> Bernard
>>
>> 2011/6/23 Antoine Isaac <aisaac@few.vu.nl <mailto:aisaac@few.vu.nl>>
>>
>> On 6/23/11 8:40 PM, Alan Ruttenberg wrote:
>>
>> On Thu, Jun 23, 2011 at 1:52 PM, Houghton,Andrew<houghtoa@oclc.org
>> <mailto:houghtoa@oclc.org>> wrote:
>>
>> Given these two situations:
>>
>>
>>
>> <skos:prefLabel>Dog</skos:prefLabel>
>>
>> <skos:prefLabel xml:lang=””>Dog</skos:prefLabel>
>>
>> Does the inclusion of *both* prefLabel in a SKOS concept result in
>> breaking
>> the rule S14 that no two prefLabel should have the same lexical value
>> for
>> the same language tag?
>>
>>
>> My read is that S14 is not applicable. In both cases the lexical value
>> is the same - a plain literal without language tag. The RDFXML doesn't
>> state that the language tag is "". It is syntax for the absence of a
>> language tag. These two are different in the value space - without a
>> language tag it is a string, with a language tag it is a pair of
>> strings. The set of plain literals without language tags is *not* the
>> set of pairs (string , "").
>>
>> Since the rule as stated applies to literals *with* language tags
>> (they can't be the same unless they are there), S14 would not seem to
>> be applicable.
>>
>> That said, this looks like a hole in the spec. It was probably the
>> intention to also include the case that no two prefLabel without
>> language tag have the same lexical value.
>>
>> -Alan
>>
>> Yes, it certainly was.
>>
>> I have to admit I don't know if there is a hole. It may seem
>> reasonable that there exist some syntactic matching between literals
>> having an empty tag and literals having no tag, as Simon reports.
>>
>>
>>
>> I think section 6.12 of the rdf syntax spec does result in the
>> defaulting of language to at least "" in production 7.2.16- there
>> doesn't seem to be another literal production that passes the
>> language feature. I must admit that I am not certain how general this
>> assumption is- there are other specs that seem to distinguish between
>> <s> and <s,l>, but I think only <s> \equiv <s,""> is consistent?
>>
>> Simon
>>
>> However, this may be specific to one syntax.
>> The RDF abstract syntax and other specs are not mentioning that sort
>> of things. Especially, the way the identity conditions are spelled
>> out at [1,2] seem to argue against amalgamating absence of tag with
>> presence of any tag (including an empty one).
>>
>> Anyway, it could be that the simplest thing to do is to publish an
>> erratum to clarify the original intent, rather than go into a
>> discussion that is difficult, and would perhaps just be against a
>> moving target, as RDF is currently being worked on... I'll forward
>> the issue.
>>
>> Cheers,
>>
>> Antoine
>>
>> [1]http://www.w3.org/TR/rdf-concepts/#section-Literal-Equality
>> [2]
>> http://www.w3.org/TR/rdf-plain-literal/#The_Comparison_of_rdf:PlainLiteral_Data_Values
>>
>>
>>
>>
>> --
>> Bernard Vatant
>> Senior Consultant
>> Vocabulary & Data Integration
>> Tel: +33 (0) 971 488 459
>> Mail: bernard.vatant@mondeca.com <mailto:bernard.vatant@mondeca.com>
>> ----------------------------------------------------
>> Mondeca
>> 3, cité Nollez 75018 Paris France
>> Web: http://www.mondeca.com
>> Blog: http://mondeca.wordpress.com
>> ----------------------------------------------------
>>
>
>
>
>

Received on Monday, 27 June 2011 08:16:47 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 13:32:15 UTC