- From: Steve Harris <steve.harris@garlik.com>
- Date: Tue, 22 Dec 2009 09:41:37 +0000
- To: Andy Seaborne <andy.seaborne@talis.com>
- Cc: "public-rdf-dawg@w3.org Group" <public-rdf-dawg@w3.org>
On 22 Dec 2009, at 08:52, Andy Seaborne wrote: ... >>> [[ >>> Definition: GroupConcat >>> >>> The multiset of values passed as an argument is converted to a >>> sequence S. >>> >>> GroupConcat(S) = fn:string-join(S, " ") >>> >>> @@ do we want space as the seperator? It's annoying in names for >>> example. Other reasonable choices include ",", "\n", or "\t". >>> ]] >>> >>> All reasonable, none always right. I suggest that GroupConcat take >>> an >>> optional separator defaulting to a single space. >>> >>> If the elements are "a" "b" "c" >>> >>> CONCAT(?x) -> "a b c" >>> CONCAT(?x, "/") -> "a/b/c" >>> >>> If the elements are integers 1 2 3 >>> >>> CONCAT(str(?x)+1) -> "2 3 4" >>> CONCAT(str(?x)+1, "+") -> "2+3+4" >> >> I did consider that, but it conflicts with the semantics of >> aggregates >> (both in SQL, and what's currently in the SPARQL draft). >> >> One option would be a keyword, like GROUP_CONCAT(str(?x) SEPARATOR >> "+"), >> this is what MySQL does, but it means some special case syntax. > > I don't see it does necessarily. The "str(?x)+1" is an expression, > which is passed, as an expression, to the aggregation operation. > The aggregator applies it to each partition so it's not being > evaluated where used, which I agree would be confusing. > > We already have count(*). I'm not sure if that's an argument in favour or against. If there's general feeling in favour of GROUP_CONCAT([DISTINCT] e, ... [SEPARATOR s]) then I'm more than happy to add it. I was in two minds anyway when writing that section. MySQL has some ORDER BY options as well, and I don't want to start a precedent saying that you should pre-process by popping the last argument to get a separator value, and treat the rest as the expression list. - Steve
Received on Tuesday, 22 December 2009 09:42:06 UTC