(Un)equality of literals

[Arjohn Kampman-2]

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

--
Arjohn Kampman, Senior Software Engineer
Aduna - Guided Exploration
www.aduna-software.com

[Seaborne, Andy]

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

[Arjohn Kampman-2]

Hi Andy,

Thanks for you prompt reply. Some further comments/questions inline:


Seaborne, Andy wrote:

> "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.

Reading through [1], I would conclude that the result depends on whether
the implementation "supports" the xsd:date datatype. If it doesn't, the
result is a type error; if it does, the result is false. Is that
correct?

Arjohn

[1] http://www.w3.org/TR/rdf-sparql-query/#func-RDFterm-equal-foot1