- From: Axel Polleres <axel.polleres@deri.org>
- Date: Tue, 28 Apr 2009 16:57:52 +0100
- To: "Seaborne, Andy" <andy.seaborne@hp.com>
- CC: Bijan Parsia <bparsia@cs.man.ac.uk>, 'RDF Data Access Working Group' <public-rdf-dawg@w3.org>
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 Tuesday, 28 April 2009 15:58:33 UTC