RE: rdf:text review



> -----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/

Received on Wednesday, 29 April 2009 12:30:56 UTC