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

Comments in-line.

On 26/09/2014 08:43, Antoine Zimmermann wrote:
> Aidan,
>
>
> Le 26/09/2014 00:30, Aidan Hogan a écrit :
>> 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.
>> »
>
> In fact, this is not quite true in RDF 1.1. For instance, the empty
> graph RDFS-entails:
>
> <http://www.example.com/>  rdf:type  rdfs:Resource .
>
> which would not appear as a result of applying the rules to the empty
> graph (note: this is new in RDF 1.1, wasn't true in RDF 1.0).

True. It would also seem necessary to add a

x rdf:type rdfs:Resource

triple for each resource in E to the materialised graph in a similar 
manner to how the CMPs are handled.

> Also, the empty graph RDF-entails:
>
> []  a  xsd:string .
> []  a  rdf:langString .
>
> Again, not the result of rule application.

True.

> Note that the following sentence is therefore not correct:
>
> "Every RDF(S) closure, even starting with the empty graph, will contain
> all RDF(S) tautologies which can be expressed using the vocabulary of
> the original graph plus the RDF and RDFS vocabularies."
>
>
> Fortunately, section "A. Entailment Rules" is non-normative.
>
>
> (Funnily, I've read RDF 1.1 Semantics half a dozen times very carefully
> during its development and I did not spot this before)
>
>
>> But I'm not sure what part of the entailment procedure deals with the
>> case insensitivity of language tags or optionality of xsd:string.
>
> There is no optionality of xsd:string. In RDF 1.1, all literals are
> typed, no exception. Serialisation syntaxes allow shortcuts in writing
> literals to the effect that you don't see the datatype, e.g., "abc"@en
> in Turtle or NTriples has the type rdf:langString; 10 in Turtle is the
> literal "10"^^xsd:integer; "xyz" in Turtle is typed with xsd:string; etc.

This I (now) understand.

> Language-tagged literals are interpreted as pairs where the second
> element is the lower-cased version of the language tag of the literal.
> Cf. the following in Section 7.1 of RDF 1.1 Semantics:
>
> "If rdf:langString is in D, then for every language-tagged string E with
> lexical form sss and language tag ttt, IL(E)= < sss, ttt' >, where ttt'
> is ttt converted to lower case using US-ASCII rules"

Yep. But Section 7.1 refers to D-interpretations which are not relevant 
to the entailment checking procedure of Appendix A. The entailment check 
applies the (G)RDF(S) rules and then checks simple entailment ... in so 
doing it skips D entailment, which seems to be the place where the case 
insensitivity of language-tags is formalised. See my last mail for more 
details. Hence I still think the procedure in Appendix A will miss 
entailments involving lang-tag case variants.

Best,
Aidan


>>
>> 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.
>>
>>
>> Likewise what happens if S is:
>>
>>      ex:a ex:b "c"^^xsd:string .
>>
>> and E is something like:
>>
>>      _:a ex:b "c" .
>>
>> 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?
>>
>>
>> Best,
>> Aidan
>>
>>
>
>

Received on Friday, 26 September 2014 18:25:26 UTC