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

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 17:56:20 UTC