W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > July 2006

RE: ORDER BY and booleans

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Mon, 10 Jul 2006 13:28:23 +0100
Message-ID: <DF5E364A470421429AE6DC96979A4F6FB6A4FC@sdcexc04.emea.cpqcorp.net>
To: "Richard Newman" <rnewman@tellme.com>, <public-rdf-dawg-comments@w3.org>

-------- Original Message --------
> From: Richard Newman <>
> Date: 8 July 2006 08:27
> As far as I can tell from my parser and the spec, it's perfectly
> reasonable to have an ORDER BY condition which evaluates to a boolean,
> e.g.:  
> ORDER BY (REGEX('[A-Z].*', ?x))
> to order the results based on whether the initial letter of ?x is a
> capital. 
> Looking at the spec:
> > The "<" operator (see the Operator Mapping) defines the relative
> > of pairs of numerics, xsd:dateTimes and xsd:strings. Does not apply
> > to booleans. 
> > IRIs are ordered by comparing the character strings making up each
> > IRI using the "<" operator.
> Does not apply to booleans, which are simple data types.
> > SPARQL also defines a fixed, arbitrary order between some kinds of
> > RDF terms that would not otherwise be ordered. This arbitrary order
> > is necessary to provide slicing of query solutions by use of LIMIT
> > and OFFSET.
> These only apply an ordering between the different categories -- so a
> boolean, as a typed RDF literal, ranks above an IRI, but it's unclear
> whether 'true' comes before 'false'.

"<" for booleans has been added to the operator list.

> What should happen in the case of values that are not in the above
> categories, particularly booleans? Intuitively, boolean values will
> be partitioned into true/false, but I'm not clear of how that chain
> of reasoning applies according to the spec. I'd like to see this
> clarified in the ORDER BY section -- and I'd quite like to know!

There are still categories of values (e.g. where the processor knows
about datatypes outside the core set) where ordering is not defined by
the spec.


> Thanks,
> -Richard
Received on Monday, 10 July 2006 12:28:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:07 UTC