Re: skos:prefLabel without language tag

This definitely either is or isn't an issue :-) The plain literal spec seems
to treat the absence of a value for language tag as having the empty string
as the language tag (rather than signalling an error). Since there doesn't
seem to be a function to test for the presence or absence of a language tag,
and since this behavior is consistent with xml:lang in RDF, this probably
either isn't an issue, or is an issue for clarification below  the SKOS
level (probably in the rdf-plain-literal specification?)

 http://www.w3.org/TR/rdf-**plain-literal<http://www.w3.org/TR/rdf-plain-literal/#The_Comparison_of_rdf:PlainLiteral_Data_Values>


5.1.3 plfn:lang-from-PlainLiteral
Summary: returns the language tag l if $arg is an rdf:PlainLiteral data
value of the form < s, l >, and returns the empty string if $arg is an
rdf:PlainLiteral data value of the form s. If $arg is not of type
rdf:PlainLiteral, this function raises type error
err:FORG0006<http://www.w3.org/TR/xpath-functions/#ERRFORG0006>
.



On Thu, Jun 23, 2011 at 4:46 PM, Antoine Isaac <aisaac@few.vu.nl> wrote:

> On 6/23/11 8:40 PM, Alan Ruttenberg wrote:
>
>> On Thu, Jun 23, 2011 at 1:52 PM, Houghton,Andrew<houghtoa@oclc.**org<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<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<http://www.w3.org/TR/rdf-plain-literal/#The_Comparison_of_rdf:PlainLiteral_Data_Values>
>
>

Received on Friday, 24 June 2011 01:28:34 UTC