Re: rdf:text review

I put the draft comment on the wiki:

http://www.w3.org/2009/sparql/wiki/Rdf_text_LC_WG_comment

I did not yet change the suggestion Andy made for the SPARQL XML Results 
Format, but I have the impression that -- if we resolve to rdf:text only 
referring to D-entailment and not simple graph entailment -- actually 
rdf:text in graph or result serializations is not a problem any more and 
this comment would thus be likewise addressed by the suggested change to 
resort to D-entailment.

So, I suggest to replace:
======================================================================

"This is not "graph exchange" so the prohibition use of rdf:text in a 
serialization does not apply. It could be applied, but might not help 
systems that do want to see rdf:text literals, for example, SPARQL/OWL2.

For compatibility, I suggest that rdf:text is changed to add a 
prohibition of the use of rdf:text in SPARQL Query Result XML Format 
(and the JSON form as well) because this is inline with the approach to 
graph exchange (which does apply to CONSTRUCT and DESCRIBE). Any 
rdf:text processor is required to convert RDF style literals into the 
rdf:text form."

with

"This is not "graph exchange" so the prohibition use of rdf:text in a 
serialization does not apply. It could be applied, but might not help 
systems that do want to see rdf:text literals, for example, SPARQL/OWL2.

The problem here, again, is that the semantic implications of rdf:text 
are not forward-compatible with existing RDF. This concern would again 
be remedied by defining the semantic implications of rdf:text in terms 
of D-entailment only. In fact, we think that this fix makes the 
restrictions of the usage of rdf:text in RDF graphs redundant."

======================================================================

What I want to say with the last sentence is:

If we only talk about D-entailment in rdf:text, the restricitions on 
using or not using rdf:text on exchanging RDF graphs, seem no longer be 
justified to me. Do you agree? If so, I would also likle to add this to 
the suggestion, i.e. the following paragraph could be dropped or MUST 
could at least be replaced by SHOULD in it in the current rdf-text spec:

"Despite the semantic equivalence between typed rdf:text literals and 
plain literals, the presence of typed rdf:text literals in an RDF graph 
might cause interoperability problems between RDF tools, as not all RDF 
tools will support rdf:text. Therefore, before exchanging an RDF graph 
with other RDF tools, an RDF tool that suports rdf:text MUST replace in 
the graph each typed rdf:text literal with the corresponding plain 
literal. The notion of graph exchange includes, but is not limited to, 
the process of serializing an RDF graph using any (normative or 
nonnormative) RDF syntax."

Opinions welcome
Axel

Axel Polleres wrote:
> Seaborne, Andy wrote:
>>
>>> -----Original Message----- From: Axel Polleres 
>>> [mailto:axel.polleres@deri.org] Sent: 28 April 2009 12:33 To: 
>>> Seaborne, Andy Cc: Bijan Parsia; 'RDF Data Access Working Group' 
>>> Subject: Re: rdf:text review
>> ...
>>> =====================================================================
>>>  == Suggested change ==
>>>
>>> Additional semantic equivalences implied by rdf:text should only 
>>> affect D-entailment (where rdf:text is part of the datatype map D 
>>> following [1]). Thus, the document should not talk about "semantic 
>>> equivalence" in general terms but just in terms of D-entailment. This 
>>> should fix the main problem raised and would only affect SPARQL 
>>> engines that follow a (yet to be defined - and thus not affecting 
>>> forward compatibility) D-entailment regime [2]. 
>>> =====================================================================
>>>
>>>
>>>
>>> In my optinion, this also would address the concern on the language
>>>  tag + datatype invariant,
>>
>> I don't see how that addresses the LANG/STR/DATATYPE issues.  There 
>> are concrete examples in the draft - could you say which answers you 
>> expect/propose for each case?
> 
> Essentially, I think STR/LANG/DATATYPE shall behave exactly the same for
> simple entailment as they do at the moment, and we don't want to
> redefine them
> To your examples:
> 
>> == DATATYPE of a literal with language tag
>>
>> SPARQL/2008: DATATYPE ("Padre de familia"@es) ==> error
> 
> with simple entailment that should indeed remain:
> 
>   DATATYPE("Padre de familia"@es) ==> error
> 
> with D-entailment entailment any triple with a literal
>   "Padre de familia"@es
> would also entail a triple with
>   "Padre de familia@es"^^rdf:text
> thus:
> 
>   DATATYPE("Padre de familia@es"^^rdf:text) ==> rdf:text
> 
>> == DATATYPE of a literal without language tag
>>
>> SPARQL/2008 defines: DATATYPE ("Padre de familia") ==> xs:string
> 
> This is actually intersting in the current speec, since it implies
> "some" datatype "reasoning" is done in SPARQL already for plain
> literals, but my personal suggestion would be (depends whether the
> others in the WG agree) we shouldn't mess around with that, i.e. keep it
> like that but not extend that towards rdf:text.
> 
>> I don't know what rdf:text says here: two possibilities:
>>
>> DATATYPE ("Padre de familia") ==> rdf:text ?? xs:string ??
> 
> Again, with D-entailment entailment any triple with a literal
>   "Padre de familia"
> would also entail a triple with
>   "Padre de familia@"^^rdf:text
> thus:
>   DATATYPE("Padre de familia@"^^rdf:text) ==> rdf:text
> 
>> because one value space is a subset of the other.
>>
>> The reason for rdf:text is the uniform treatment of literals so the
>> query to find all the untyped literals ("untyped" meaning as per the
>> current SPARQL REC - without type - simple literal or literal with
>> language tag) might be changed.
> 
> since both RIF and OWL respect datatypes, this uniform treatment is be 
> guaranteed, IMO.
> 
>> == LANG
>>
>> In RDF, a literal has either a language tag or a datatype but not
>> both.  So:
>>
>> SPARQL/2008: Lang("Padre de familia"@es) ==> "es" but Lang("Padre de
>> familia@es"^^rdf:text) ==> ""
>>
>> rdf:text: Lang("Padre de familia@es"^^rdf:text) ==> ??
>>
>> c.f. rtfn:lang-from-text(Padre de familia@es"^^rdf:text) ==> "es"
> 
> Same as before (note that Lang() is not the same as rtfn:lang-from-text()!)
> 
> So
> 
>   Lang("Padre de familia@es"^^rdf:text) ==> ""
> 
>   Lang("Padre de familia"@es) ==> "es"
> 
> However, again, with D-entailment entailment any triple with a literal
> 
>   "Padre de familia"@es"
> 
> would also entail a triple with
> 
>   "Padre de familia@es"^^rdf:text
> 
> and vice versa.
> 
> 
>> == STR
>>
>> rdf:text is a datatype with lexical space including the language tag
>>
>>
>> SPARQL/2008 defines: STR("Padre de familia@es"^^rdf:text) ==> "Padre
>> de familia@es" STR("Padre de familia"@es) ==> "Padre de familia"
>>
>> rdf:text: STR("Padre de familia@es"^^rdf:text) ==> "Padre de familia"
>> ??
>>
>> because STR returns the lexical form.
>>
>> The lexical space of literals with language tags is changed by
>> rdf:text.
> 
> 
>  STR should again behave like defined, i.e. it should extract the 
> lexical form, i.e.
> 
>   STR("Padre de familia@es"^^rdf:text) ==> "Padre de familia@es"
> 
> Note again that Str() is not the same as rtfn:string-from-text()!)
> 
> Summary: I think that, as long as datatype reasoning is not considered,
> the situation is quite clear, as soon as we say that the semantic 
> implications of rdf:text only affect D-entailment.
> 
> best,
> Axel
> 
> 


-- 
Dr. Axel Polleres
Digital Enterprise Research Institute, National University of Ireland, 
Galway
email: axel.polleres@deri.org  url: http://www.polleres.net/

Received on Wednesday, 29 April 2009 14:39:28 UTC