W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2005

Re: ACTION: EricP to extend < and relational ops to string, get review by Andy

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Mon, 26 Sep 2005 17:13:11 +0100
Message-ID: <43381E17.9010403@hp.com>
To: Eric Prud'hommeaux <eric@w3.org>
CC: public-rdf-dawg@w3.org



Eric Prud'hommeaux wrote:
> I've updated the sorting order section to reflect that < is
> responsible for all literals:

Err - all literals?

Surely you just can't compare some combination, say integers and strings?
What about literals typed with types the processor does not understand?

I thought the step was to add < etc for xsd:strings, which enables the URI 
comparions by deferring to "<" on the URI string.  This seems to be aimed much 
more widely than that.

> [[ http://www.w3.org/2001/sw/DataAccess/rq23/#defn_Ordered
> RDF Literals are compared with the "<" operator (see the Operator
> Mapping Table).
> ...
>    1.  (Lowest) no value assigned to the variable or expression in
>    this solution.
>    2. Blank nodes
>    3. IRIs
>    4. RDF literals
> ]]

What I intended was that ordering may force certain comparisons to make the 
result sequence more predictable but these tests would be type errors in a 
FILTER.  Hence the rules above.

"""
5. A plain literal before an RDF literal with type xsd:string of  the same 
lexical form.
"""

This would be still be needed as they are the same value (we could just not 
worry and leave rule 5 out).

> 
> clarified the selection of operator definitions:
> [[
> When selecting the operator definition for a given set of parameters,
> the definition with the most specific parameters applies. For
> instance, when evaluating xs:integer = xs:signedInt, the definition
> for = with two numeric parameters applies, rather than the one with
> two RDF terms. The table is arranged so that upper-most viable
> candiate is the most specific.
> ]]
> 
> Added four Operator Table Entries like:
>   A < B		literal	literal	sop:literal-less-than(A, B)	xsd:boolean
> 
> Created sections for sop:literal-{less,greater}-than:
> [[
> 11.2.3.0 sop:literal-less-than
> 
> Returns TRUE if the first argument sorts earlier than the second
> argument according to this earliest rule in the sorting rules:

This seems circular - the ordering text defers to "<" where possible but the 
"<" operator may defer to the sort order (which isn't a total ordering anyway).

> 
>    1. Numerics sort before xs:dateTimes.
>    2. xs:dateTimes sort before typed literals that are neither numeric
>    nor an xs:dateTime.
>    3. The remaining datatypes are compared with fn:compare. If the
>    result is -1, the first argument sorts before the second
>    argument. If the result is 1, the second argument sorts before the
>    first argument. If the result is 0, the order is determined by the
>    order of the lexical value of the datatypes. If fn:compare returns
>    -1, the first argument sorts before the second argument. If it
>    returns 1, the second argument sorts before the first argument. If
>    it returns 0, the two arguments are equivelent.
> 
> 11.2.3.0.5 sop:literal-greater-than
> 
> Returns FALSE if the first argument sorts earlier than the second
> argument according to this earliest rule in the above sorting rules.
> ]]
> 
> and simplified sop:RDFterm-equal
> [[
> Returns TRUE if the two arguments are the same RDF term.
> ]]
> 
> I submit this to Andy's (and anyone else's) review.

	Andy
Received on Monday, 26 September 2005 16:13:32 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:24 GMT