Re: RDF 1.1 Semantics: completeness for lang-tag variants

Hmm, yes, I think I see what is going on here.

The semantics assumes that incoming language tags are in the value space, 
which is lower-case only, so that language tag equality is done in a manner 
consistent with BCP47.  In 1.0 this was part of the abstract syntax.  In 1.1. 
there is the statement that the value space of language tags is lower case 
only, but when this should happen and whether it affects literal term equality 
should have been better specified.

So, I think that a clarification should be issued, stating that language tag 
equality MUST be done in a case-insensitive manner, as per BCP47, if the 
language tags have not already been converted to lower case.

peter


On 09/26/2014 10:55 AM, Aidan Hogan wrote:
> Thanks for the clarifications. The part about xsd:string always being
> "assumed" in the case of plain literals is quite clear and unambiguous (i.e.,
> that plain literals are now a syntactic shortcut rather than existing as a
> separate term).
>
> However, the issue around language-tags remains confusing for me.
>
>
>
> With respect to the RDF 1.1 Concepts document, Section 3.3 states that:
>
> "Lexical representations of language tags MAY be converted to lower case. The
> value space of language tags is always in lower case."
>
> Likewise:
>
> "Literal term equality: Two literals are term-equal (the same RDF literal) if
> and only if the two lexical forms, the two datatype IRIs, and the two language
> tags (if any) compare equal, character by character. Thus, two literals can
> have the same value without being the same RDF term."
>
> Hence, it seems to me that "l"@en-US and "l"@en-us are not term-equals even if
> they hold the same value (much like "02"^^xsd:integer and "2"^^xsd:integer
> correspond on value but are not term-equals).
>
>  From this I read that the RDF graph:
>
> ex:a ex:b "l"@en-US .
>
> is not *equal* to:
>
> ex:a ex:b "l"@en-us .
>
> ... but rather they are D-equivalent (recognising rdf:langString) in much the
> same way that:
>
> ex:a ex:b "02"^^xsd:integer .
>
> is not *equal* to:
>
> ex:a ex:b "2"^^xsd:integer .
>
> ... but rather they are D-equivalent (recognising xsd:integer).
>
>
> With respect to RDF 1.1 Semantics, the existence of a semantic condition in D
> interpretations that normalises case in the value mapping seems to likewise
> suggest that "l"@en-US and "l"@en-us are not term-equals, but merely equal in
> value. As I read it, it is on the level of D interpretations that "l"@en-US
> and "l"@en-us become equivalent, not on the level of simple interpretation
> (otherwise the D semantic condition would be redundant).
>
> With respect to the entailment procedure outlined in Appendix A, it skips D
> entailment since it applies rules (which do not treat language-tagged
> literals) and then checks simple entailment (which does not recognise the
> equivalence of "l"@en-US and "l"@en-us).
>
>
> Put another way, my question then is given:
>
>      G1: ex:a ex:b "l"@en-US .
>
>      G2: ex:a ex:b "l"@en-us .
>
> What is the exact relationship between these two graphs? Are they equal,
> simply-equivalent, D-equivalent (recognising rdf:langString), or something else?
>
> My understanding is that they are D equivalent and that thus checking if G2 is
> RDFS-entailed by G1 will fail under the procedure outlined in Appendix A.
>
> Best,
> Aidan
>
> On 25/09/2014 19:57, Peter F. Patel-Schneider wrote:
>> This is an unofficial reply.
>>
>> In the RDF 1.1 semantics, language tags are always in lower case.  This
>> can be seen in Section 3.3 of RDF 1.1 Concepts,
>>    The value space of language tags is always in lower case.
>> Admittedly, this could have been stated better.
>>
>> peter
>>
>>
>> On 09/25/2014 03:30 PM, Aidan Hogan wrote:
>>> Hi,
>>>
>>> In the RDF 1.1 Semantics document, in "A. Entailment Rules", the
>>> following
>>> completeness result is given:
>>>
>>> «
>>> If S is RDF (RDFS) consistent, then S RDF entails (RDFS entails) E
>>> just when
>>> the generalized RDF (RDFS) closure of S towards E simply entails E.
>>> »
>>>
>>> But I'm not sure what part of the entailment procedure deals with the
>>> case
>>> insensitivity of language tags or optionality of xsd:string.
>>>
>>> For example, let S be:
>>>
>>>      ex:a ex:b "c"@en-US .
>>>
>>> and let E be:
>>>
>>>      _:a ex:b "c"@en-us .
>>>
>>> If I'm correct, S RDF(S) entails E. But I cannot see how either the
>>> generalized RDF(S) closure or simple entailment cover this.
>>
>> The value corresponding to the literal "c"@en-US is the same as the
>> value corresponding to the literal "c"en-us.
>>
>>>
>>> Likewise what happens if S is:
>>>
>>>      ex:a ex:b "c"^^xsd:string .
>>>
>>> and E is something like:
>>>
>>>      _:a ex:b "c" .
>>
>> Again, the values are the same.  See Section 3.3 of RDF 1.1 Concepts.
>>>
>>> I likewise cannot see how this case is covered?
>>>
>>>
>>> Is a canonicalisation step not needed somewhere to lower-case all
>>> language
>>> tags and add xsd:string to all "plain literals" in S and E?
>>
>> Well, not really.  The values are already in a form that does not
>> require further canonicalization.
>>
>>>
>>>
>>> Best,
>>> Aidan
>>>

Received on Friday, 26 September 2014 21:15:43 UTC