RE: Ambiguity for Literal order in SPARQL

Richard,

Thanks for the clarification. There are still some ambiguities for typed
literals I'd like to clarify. I can distinguish two cases:

1) 2 literals with the same value space.

If both literals have the same datatype uri, thus they share the same value
space. It is also possible that both literals with different datatypes share
the same value space (For example: xsd:int,xsd:float,xsd:double datatypes
maps to value space of Numbers).

If the implementation provides a comparator for the value space, then it
should return the result of this comparison, otherwise delegate the
comparison to the lexical form if not supported or equals value returned. 

2) 2 literals with different value spaces (and by inference different
datatypes). 

An example would be for custom temporal datatypes to be compared with
xsd:dateTime or datatypes for unit of measure. 

If the implementation provides an "adapter" from one value space to another
and a comparator for these "compatible" values, then it should return the
result of this comparison, otherwise delegate the comparison to the lexical
form if not adapter or comparator supported or equals value returned.

That means the comparison in value space would be implementation specific.

Does the WG agree with this approach? Let me know if I was not clear.

Best regards

Stephane Fellah
KnowledgeSmarts Architect and Product Manager
http://www.imagematterllc.com



-----Original Message-----
From: public-rdf-dawg-comments-request@w3.org
[mailto:public-rdf-dawg-comments-request@w3.org] On Behalf Of Richard Newman
Sent: Wednesday, February 21, 2007 2:38 PM
To: Stephane Fellah
Cc: public-rdf-dawg-comments@w3.org
Subject: Re: Ambiguity for Literal order in SPARQL


Sorry for omitting that; that's already described in the SPARQL  
operator selection, which defines < for dateTimes, numeric values,  
booleans, and simple literals (strings).

The additional ordering constraints are only necessary when the more  
specific ordering rules do not kick in.  When two xsd:booleans are  
compared, the comparison never reaches the literal comparison stage,  
because op:boolean-less-than(A, B) is used instead. SPARQL defines  
additional ordering constraints for when these do not apply, e.g.,  
for unknown datatypes, or for comparing an xsd:boolean to a URI.

See <http://www.w3.org/2001/sw/DataAccess/rq23/rq25.html#modOrderBy>
and <http://www.w3.org/2001/sw/DataAccess/rq23/ 
rq25.html#OperatorMapping>

-R

On  21 Feb 2007, at 11:26 AM, Stephane Fellah wrote:

>
> Richard,
>
> I agree with the order you suggest however I think prior doing the
> comparison on the lexical form, we need to do a comparison on the  
> value
> space (date, numbers, boolean). If the value space comparison returns
> equality, then a lexical form comparison needs to be done.
> In this case we ensure we have a "semantic"/mathematical ordering  
> of literal
> value, not only syntactic.
>
> Stephane

-- 
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.412 / Virus Database: 268.18.3/694 - Release Date: 2/20/2007
 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.412 / Virus Database: 268.18.3/694 - Release Date: 2/20/2007

Received on Wednesday, 21 February 2007 20:13:26 UTC