Re: Changes to Query 1.1 doc

On 2010-11-30, at 09:16, Andy Seaborne wrote:
> 
> On 29/11/10 22:34, Steve Harris wrote:
>> On 29 Nov 2010, at 21:40, Andy Seaborne<andy.seaborne@epimorphics.com>  wrote:
>> 
>>> 
>>> 
>>> On 29/11/10 16:23, Steve Harris wrote:
>>> ...
>>>> Editorial
>>> ...
>>> 
>>>> * Allow GROUP_CONCAT to work on values other than xsd:string
>>> 
>>> This is more than editorial :-).
>>> 
>>> GROUP_CONCAT({<http://example/>,2,3}) is now "http://example/23" whereas previously it was an error.
>> 
>> That's still an error, xsd:string(<uri>) is an error, isn't it?
> 
> 'fraid not.
> 
> See the table in SPARQL 1.0:
> http://www.w3.org/TR/rdf-sparql-query/#FunctionMapping
> 
> str() and xsd:string() are much the same except that one results in simple literals and one result in ^^xsd:string.

Huh. Well there you go. I would have sworn that xsd:string(<URI>) was an error.

>> You're right that it's a substantive change though, I misunderstood the definition in f&o, and thought it cast to xsd:string implicitly.
>> 
>> The situation in Sum() is a little different, but it's a good point about the commonality.
>> 
>>> SUM does not cast.  We decided that the mixed types in SPARQL meant it was better to have a non-casting SUM because the application writer can always add SUM(xsd:double(?x)).
>> 
>> Yeah, but the alternative is a precision losing, or error masking cast of some kind. Using the lexical form of e.g. numeric types is pretty obvious however.
>> 
>> I believe GROUP_CONCAT in MySQL implicitly casts to string, but I'm not sure offhand.
> 
> MySQL certainly casts in SUM()

That's true. I wasn't aware of that.

>>> I think we need to be consistent because all it requires is:
>>> 
>>>  GROUP_CONCAT(xsd:string(?x))
>>>  GROUP_CONCAT(STR(?x))
>>> 
>>> An alternative is that GROUP_CONCAT uses CONCAT (including lang tag handling) and we can make it dependent on what we decide for CONCAT.
>> 
>> That's also an option. Would actually need a common parent of some kind - CONCAT is variadic, but Aggregates use sequences.
> 
> At the moment you already have hasd to include xsd:string(S) specially but to work consistently with CONCAT, approach it in the style of SUM, CONCAT applying at each step:
> 
> GroupConcat(S, scalar) = "" where |S| = 0
> GroupConcat(S, scalar) = CONCAT("", S0) where |S| = 1
> GroupConcat(S, scalar) =
>    CONCAT(GroupConcat(S(N-1), scalar), scalar, SN)
> where |S| > 1
> 
> The |S|=1 step includes CONCAT so that lang tags, what casting we decide upon, etc work out.

Sure, that seems like a rational design. I've made a note of it, to revisit once we have a decision on CONCAT(). For now I've put a note in the doc that the GroupConcat def'n is likely to change.

- Steve

-- 
Steve Harris, CTO, Garlik Limited
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD

Received on Wednesday, 1 December 2010 12:44:49 UTC