W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2010

Re: Changes to Query 1.1 doc

From: Steve Harris <steve.harris@garlik.com>
Date: Mon, 29 Nov 2010 22:34:43 +0000
Message-Id: <0264D07C-28BF-4024-8DDD-A8709F5C38C9@garlik.com>
Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
To: Andy Seaborne <andy.seaborne@epimorphics.com>
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?

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. 

> 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.

- Steve
Received on Monday, 29 November 2010 22:36:10 GMT

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