RE: Ambiguity for Literal order in SPARQL

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


-----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 1:34 PM
To: Stephane Fellah
Cc: public-rdf-dawg-comments@w3.org
Subject: Re: Ambiguity for Literal order in SPARQL


 From an implementer's perspective, I agree that this section is  
ambiguous.

The only reason I can see for 5 is that plain literals are implicitly  
xsd:strings, but they appear differently and so need an imposed order.

Here's the rule I've come up with for handling literals:

- all literals are sorted by lexical form.
- a tie (where the lexical form is the same) is resolved as follows:
   - sort by lexical form of datatype URI, with plain literals as  
xsd:string. Plain literals compare before literals explicitly typed  
as xsd:string.
   - only plain literals can have language tags, so language tagged  
literals can only tie with a plain literal of the same lexical form.  
In this case, sort by the lexical form of the language tag to break  
the tie, with simple literals (no language tag or datatype literal)  
having an implicit language of "".
   - two plain literals with the same language tag, or no language  
tag, are the same literal, so no ordering is needed.

A sorted order would look like this:

"abc"                  < plain literal, sorted by lexical form
"horse"                < plain literal, no language
"horse"@en             < plain literal, "en" > nil
"horse"@fr             < plain literal, "fr" > "en"
"horse"^^xsd:string    < xsd:string wins out over plain literal's  
implicit xsd:string
"horse"^^xsd:xstring   < sorting by type URI: "xstring" > "string"
"xyz"                  < lexical form wins out again.

I'd love to get the WG's feedback on this. Is this what the document  
intends?

-R


On  21 Feb 2007, at 5:50 AM, Stephane Fellah wrote:

> Hi,
>
> The SPARQL specification is quite ambiguous on the sorting for  
> literals.  The specification mentioned in section 10.1.1. ORDER  
> BY,  the following order criteria.
>
> (Lowest) no value assigned to the variable or expression in this  
> solution.
> Blank nodes
> IRIs
> RDF literals
> A plain literal is lower than an RDF literal with type xsd:string  
> of the same lexical form.
> I like to get more clarification about the order of plain literal  
> with language as well as typed literal. I know that ARQ is handling  
> this case, but I like to see this formalized in the specs to ensure  
> that ordering remains consistent between implementations.  Thanks  
> in advance
>
> Best regards
>
> Stephane Fellah
>
> KnowledgeSmarts Architect
>
> Image Matters LLC

-- 
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 19:27:00 UTC