Re: !=

Richard Newman wrote:
> DAWG,
> 
>    I have a scenario I'd like to present, and an associated  
> suggestion. (Alternatively, please correct whatever misunderstand  
> becomes evident in the following email.)
> 
>    Consider a simple FILTER:
> 
>      FILTER ( ?x != ?y )
> 
>    Imagine ?x bound to "car"@en-us, and ?y bound to "auto"@en-us, and  
> evaluate the expression.
> 
> 
>    Sec. 11.3 defines != on two RDFterms -- these literals put us into  
> RDFterm territory, as they aren't 'simple' -- as
> 
>      fn:not(RDFterm-equal(A, B))
> 
>    RDFterm-equal "produces a type error if the arguments are both  
> literal but are not the same RDF term".

That's correct.  It works with:


"""
11.3.1 Operator Extensibility

SPARQL language extensions may provide additional associations between 
operators and operator functions; this amounts to adding rows to the table 
above. No additional operator may yield a result that replaces any result 
other than a type error in the semantics defined above.
"""

to allow an implementation to add handling of types not required by core SPARQL.

> 
>    We know that "Any expression other than logical-or (||) or logical- 
> and (&&) that encounters an error will produce that error.". fn:not  
> satisfies this requirement.
> 
> 
>    So, let's compare these two values. The two arguments are both  
> literal, but are not the same term, so RDFterm-equal produces a type  
> error. fn:not propagates this type error. Finally, the FILTER fails,  
> even though ?x is not intuitively equal to ?y.

!= is a value test.

Strictly, reading it as "is not positively known to be unequal" is better. If 
an implementation does not handle language tags in filters, then

> 
>    What we have here is a FILTER that only passes if RDFterm-equal  
> returns precisely "false"^^xsd:boolean. When called with two  
> literals, this is never the case, despite it *not* being true that ?x  
> = ?y.
> 
>    My suggestion is either:
> 
>    * that != is defined in terms of sameTerm (which never returns a  
> type error), not RDFterm-equal, or

!= is a value test, not a term test.

SameTerm is provided so you can write an explicit term test if you want to 
using !sameTerm(?x, ?y).

Errors in != (and =) allow an implementation to extend the range of datatypes 
supported.  I think of language tags as a value space.

I agree that just looking at "car"@en-us and "auto"@en-us we can tell what 
they are.  But what about "car"@en-us and "car"@EN-us?

>    * that fn:not is replaced by a SPARQL operator that masks SPARQL  
> type errors, treating them as false, but otherwise behaving as fn:not.

This would lead to a problem with fn:not(fn:not(error)) which is now true.

	Andy

> 
>    The current specification defines extremely unintuitive behavior  
> that baffles even experienced users, and should be changed.

The example is specific to language tags which are not required to be 
supported in FILTERs.  They can be, with full handling of @EN vs @en, because 
it's an error and not true or false.  Otherwise, an extension leaves the 
potential for a query to end up with less solutions than before.

	Andy

> 
>    I look forward to the DAWG's response!
> 
>    Thanks,
> 
> -R
> 

-- 
Hewlett-Packard Limited
Registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Tuesday, 10 July 2007 16:13:45 UTC