Re: (Un)equality of literals

Arjohn Kampman wrote:
> Hi all,
> 
> Although the working group probably has seized to exist now that
> SPARQL has reached the Recommendation status, I hope someone can answer
> the following question:
> 
> When comparing two literals with supported but unequal datatypes, should
> these literals be considered to be unequal?
> 
> The following cases are clear to me:
> 
> * "2001-01-01"^^xsd:date = "2002-02-02"^^xsd:date --> false
>    assuming that xsd:date comparisons are supported.
> 
> * "2001-01-01"^^xsd:date = "2001-01-02"^^ex:myDate --> type error
>    since ex:myDate is an unknown/unsupported datatype.
> 
> But what would be the result of this comparison?:
> "2001-01-01"^^xsd:date = "2001-01-01T00:00:00+00:00"^^xsd:dateTime
> 
> Should this:
> a) return false since both datatypes are known and the values are
>     considered to be uncomparable/unequal, or
> b) produce a type error since the datatypes are incompatible?
> 
> Hope someone can clear this up for me.
> 
> Regards,
> 
> Arjohn Kampman
> 

Hi Arjohn,

"2001-01-01"^^xsd:date = "2001-01-01T00:00:00+00:00"^^xsd:dateTime

evaluates to false but possibly for a slightly different reason to the one you 
mention

Extensions to additional types happens as if new rows are added to the 
operator table in sec 11 (11.3 Operator Mapping).  That defines the dispatch 
to the appropriate kind of operation.

There is no row for "A = B", xsd:date, xsd:dateTime so it drops through to

A = B  RDF term  RDF term

which is false.

If an implementation adds support for xsd:date, then it would add the row for:

"A = B", xsd:date, xsd:date

and still the example above does not match because the dispatch is not on a 
pair of xsd:dates but on (xsd:date, xsd:dateTime)

Also: xsd:date and xsd:dateTime are not comparable by XSD F&O - they are 
different and disjoin value spaces in the data model.  xsd:dates are compared 
by their starting instance but that does not mean xsd:date and xsd:dateTime 
are comparable.  Their only common datatype is xsd:anyAtomicType.

In the case of xsd:double/xsd:float and xsd:decimal, which also do share a 
common datatype except xsd:anyAtomixType, there is special rules for the 
concept of "numeric".

	Andy

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

Received on Friday, 15 February 2008 11:55:12 UTC