- From: Steve Harris <steve.harris@garlik.com>
- Date: Mon, 29 Nov 2010 22:34:43 +0000
- To: Andy Seaborne <andy.seaborne@epimorphics.com>
- Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
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 UTC