Re: agenda, 12 Sept, 14:30 UTC

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