Re: rdf:text review

Andy,

we seem to be almost there from my side. I just was tempted to 
relativize 1/ as well, since I believe it is likewise remedied by 
resorting to D-entailment effects only.
Do you agree?

As for 2/ and 3/, I am fine. We have to revisse the current response 
text accordingly, only started with that so far.

Axel

Seaborne, Andy wrote:
> 
>> -----Original Message-----
>> From: Axel Polleres [mailto:axel.polleres@deri.org]
>> Sent: 28 April 2009 16:58
>> To: Seaborne, Andy
>> Cc: Bijan Parsia; 'RDF Data Access Working Group'
>> Subject: Re: rdf:text review
> ...
> 
> 
>> 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:
> 
> Reading through these, I tried to extract the principle being used to decide the value of a function.  Am I right to see you treating DATATYPE/LANG/STR as stressing their role as accessing the syntactic?  This seems like a good model we can work through with the entailment regime.
> 
> So we have for the reply:
> 
> 1/ rdf:text MUST NOT appear is SPARQL XML results.
> 
> Generalises the RDF graph exchange to include SPARQL results.
> 
> 2/ rdf:text is a D-entailment and is accessed by SPARQL a BGP entailment regime.
> 
> 3/ Functions STR/DATATYPE/LANG act strictly on the lexical forms.
> 
> Do we need to says at (2) that matches coming out of the rdf:text entailment matching must be treated in their RDF forms?  That would maximize compatibility.
> 
> 
> 
> ----
> Discussion below.
> 
>>> == 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
> 
> One point - it's assuming the that the entailment is exposing both forms, or the RDF form, to retain compatibility with simple-entailment.  To put it another way, results under simple-entailment remain true and new possibilities now occur.
> 
> Modulo cardinality of results, this nearly works.  Lang tags disappear if the rdf:text form is exposed.  Maybe there will need to be a condition on the rdf:text-enatilments to expose the RDF form.  Not sure of the long term effects of that (c.f. SPARQL/OWL, SPARQL/RIF).
> 
> One particular example which is in value-space, not in the lexical form:
> 
> FILTER("") is false 
> 
> (Effective Boolean Value of the empty string is false in XSD - it's a special case SPARQL inherits from F&O).
> 
> But FILTER("@"^^rdf:text) is error (and hence false but further combining is messed up).
> 
> Seems liveable with but EricP is the expert here.  The rdf:text-entailment can also say how it modified the operator table in sec 11.3 (it's got to anyway).
> 
> 
>>> == 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
> 
> This one will depend on whether rdf:text-entailment exposes the "...@"^^rdf:text or ".." forms when DATATYPE is treated as a syntactic accessor.
> 
> Same point for LANG and STR
> 
> 	Andy
> 
>>> 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/


-- 
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:51:44 UTC