- From: Bijan Parsia <bparsia@cs.man.ac.uk>
- Date: Tue, 12 Sep 2006 15:27:50 +0100
- To: andy.seaborne@hp.com
- Cc: Kendall Clark <kendall@monkeyfist.com>, dawg mailing list <public-rdf-dawg@w3.org>
On Sep 12, 2006, at 3:09 PM, Seaborne, Andy wrote: > Hopefully a report will speed the telecon up (sorry - it's a bit > rushed) > > ARQ implementation reports and current HP position statements: > > (Positions subject to change) > >> 3. nonLiteral Value Testing >> http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/ >> 0199.html >> http://www.w3.org/2001/sw/DataAccess/issues#nonliteralValueTesting > > >>>> ILLFORMED LITERAL TESTING > > ARQ implements: > > datatype("-5"^^xsd:positiveInteger) = xsd:positiveInteger > > xsd:positiveInteger("-5") => error > > datatype is an accessor (like str() and lang()) > > datatype("<"^^rdf:xmlLiteral) => rdf:xmlLiteral > > [[ Discussion: > Arguably that's wrong, but rdf:xmlLiteral is not required datatype > in SPARQL. As rdf:xmlLiteral must be exclusively canonicalized > (http://www.w3.org/TR/rdf-concepts/#section-XMLLiteral) > they require an XML parser. > ]] I'm confused as to why rdf:xmlLiteral is wrong in the light of datatype("-5"^^xsd:positiveInteger) = xsd:positiveInteger. In both cases the datatype function is extracting the datatype uri from the literal form, *not* returning the type of the value. I'm not sure I prefer that, and it needs to be documented clearly, but it is consistent. But maybe I'm mmissing something? > ARQ treats "-5"^^xsd:positiveInteger is an RDF literal (informally, > think of RDF literal as the super type of all literals). It *is* an RDF literal, just illformed (just adding extra clarification because I confused this up earlier). > Position: No change to the design of datatype. > > >>>> NON LITERAL VALUE testing > > Postion: > >>>> 1) Restrict value testing to data values with literal form > > is fine if the reading for "value testing" applies to value > comparison operations "<" and ">". "=" works as sameTerm on non- > literal forms. > > "abc"^^xsd:integer = "abc"^^xsd:integer ==> true Hmmm. I find that a bit surprising. Perhaps we need an illFormed operator? It's strange that the coercion is to integers for "<" (thus getting an error) and to term for "=". I don't have a good solution though :( Is abc"^^xsd:integer = "abc"^^xsd:positiveInteger ==> true? abc"^^xsd:integer = "abc"^^xsd:negativeInteger ==> true? (I presume not by sameTerm, but this gets surprising: abc"^^ xsd:negativeInteger = "abc"^^xsd:positiveInteger ==> false abc"^^ xsd:negativeInteger < "abc"^^xsd:positiveInteger ==> error) > FILTERs and non-value functions still apply to non-literals (like > IRIs) and literals which are invalid by datatype entailment. > > http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/ > 0139.html > """ > I suspect most people expect that > if I put ^^xsd:integer in there that i get an object that is an > integer! > """ To give the whole quote: """In fact, I wish illformed literals directly produced contradictions. That's way easier to understand, I think, than the current behavior. I suspect most people expect that if I put ^^xsd:integer in there that i get an object that is an integer! Not some other object altogether if I've typoed. If there *is* no such integer, then it's an error/contradiction, because I've said that a non-integer is "of type" integer."""" My wish is *not* how rdf currently is. > In ARQ, "abc"^^xsd:integer is an RDF literal which does not have an > integer value. This is in accordance with RDF. Not sure what the point is of pointing to the above message. >> 4. contradictoryKB >> http://www.w3.org/2001/sw/DataAccess/issues#contradictoryKB >> http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/ >> 0119.html > > Proposal: > Entailment regimes define what is (in)consistent. Agreed. > SPARQL does not define what happens to query on an inconsistent > graph Is this to be implementation dependent? (That was one of the options.) > Rational: It would ideal to define what happens but the case of > wanting to find illegal literals in a graph compared with allowing > extensibility to reasoner-backed datasets means that one design > will not cover all cases. I'm not clear. If I can query the same graph under multiple semantics, then I can query an inconsistent graph under simple entailment and find the contradiction. But that still leaves open what the answers are in the datatyped case. Since the original query and the query to find the contradiction are different, I'm confused as to what the problem is. >> 5. formsOfDistinct >> http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/ >> 0200.html >> http://www.w3.org/2001/sw/DataAccess/issues#formsOfDistinct > > HP position: > > Two different solutions in a DISTINCT result set differ by one or > more bindings. One binding is different from another if they refer > to different variables or the values are RDFterm-different. > DISTINCT is term-DISTINCT as defined for SPARQL (simple entailment). [snip] Just to be clear, HP doesn't require graph leaning then? So it is pairwise distinctness with answerset scoped bnodes. Cheers, Bijan.
Received on Tuesday, 12 September 2006 14:31:31 UTC