Re: Fwd: Question about inequality semantics

Thanks to careful explanation from Rob Vesse (@RobVesse, dotNetRDF and 
Jena), it seems there is just one small editorial issue.

Section 17.3 (Operator Mapping) lays out the mapping table.

Section 17.3.1 (Operator Extensibility) then describes how and when a 
system can extend the core datatypes and operations.

Only places where a type error occurs can be replaced by a new mapping 
in the table.

The definition of RDFterm-equal also includes a place where type errors 
occur.  It's not just failure to match in the operator table.

RDFterm-equal('1',2) is a type error and can be extended.

The editorial issue is that the text in 17.3.1 says

[[
No additional operator may yield a result that replaces any result other 
than a type error in the semantics defined *above*.
]]
but the definition of RDFterm-equal is below in 17.4.1.7.

Fix :

Either remove " in the semantics defined above"
or change to:

" in the semantics defined above or in RDFterm-equal."

Both stop the evaluation error 1/0 being changed to be "boo!" as an 
extension.

	Andy


On 23/07/13 11:39, Andy Seaborne wrote:
> http://www.w3.org/TR/sparql11-query/#OperatorMapping
>
> The last block in the table should be removed:
>
> ---------------
> SPARQL Tests
> A = B    RDF term    RDF term    RDFterm-equal(A, B)
> A != B    RDF term    RDF term    fn:not(RDFterm-equal(A, B))
> ---------------
>
> It is not right to map unknown datatype comparison by value to sameTerm.
>
> The example Evrin gives below is ('1' != 2) which should either be an
> error (no operator mapping) or false.
>
> An engine can know that the value spaces of xsd:string and xsd:integer
> are disjoint so evaluate the expression to false.
>
> As currently defined, here !=
>
>     fn:not(sameTerm('1',2))
>
> which evaluates to true and is wrong.
>
>      Andy
>
>
> -------- Original Message --------
> Subject: Question about inequality semantics
> Date: Mon, 22 Jul 2013 14:55:03 -0400
> From: Evren Sirin <evren@clarkparsia.com>
> Reply-To: users@jena.apache.org
> To: users@jena.apache.org
>
> I'm getting the following result with Jena 2.10.1 against an empty ttl file
> (0 bytes):
>
> $ bin/sparql --data empty.ttl "ASK { FILTER ('1' != 2) }"
> Ask => Yes
>
> This result seems correct intuitively but if I'm reading the SPARQL spec
> right the answer should be false.
>
> According to Section 17.4 operator mapping [1], when we have a simple
> literal and a numeric literal the != will be mapped to
> fn:not(RDFterm-equal(A, B)). The definition of RDFterm-equal [2] says it
> "produces a type error if the arguments are both literal but are not the
> same RDF term" which is the case here. Section 17.4 also says "Note that
> per the XPath definitions, fn:not and op:numeric-equal produce an error if
> their argument is an error." Then fn:not(RDFterm-equal('1', 2)) would
> produce a type error. If there is a type error, the filter would return
> false and the above query should return false too.
>
> I was looking at the DAWG test suite to check if my understanding is
> correct but the only relevant test I found (:eq-2-2 in expr-equals manifest
> [3]) had a typo and was pointing to the wrong query file (eq-2-1 instead of
> eq-2-2).
>
> Is this a bug in ARQ? Or am I misinterpreting the spec?
>
> Thanks,
> Evren
>
> [1] http://www.w3.org/TR/2012/PR-sparql11-query-20121108/#OperatorMapping
> [2]
> http://www.w3.org/TR/2012/PR-sparql11-query-20121108/#func-RDFterm-equal
> [3]
> http://www.w3.org/2001/sw/DataAccess/tests/data-r2/expr-equals/manifest.ttl
>
>
>

Received on Thursday, 25 July 2013 21:26:00 UTC