00:19:47 <LeeF> LeeF has joined #sparql
00:33:09 <AndyS> AndyS has joined #sparql
00:45:07 <SteveH> SteveH has joined #sparql
00:52:24 <Zakim> Zakim has left #sparql
05:01:22 <AxelPolleres> AxelPolleres has joined #sparql
05:13:29 <AxelPolleres> AxelPolleres has left #sparql
12:01:44 <RRSAgent> RRSAgent has joined #sparql
12:01:44 <RRSAgent> logging to http://www.w3.org/2010/03/26-sparql-irc
12:01:46 <trackbot> RRSAgent, make logs world
12:01:46 <Zakim> Zakim has joined #sparql
12:01:48 <trackbot> Zakim, this will be 77277
12:01:48 <Zakim> ok, trackbot; I see SW_(SPARQLF2F)8:00AM scheduled to start now
12:01:49 <trackbot> Meeting: SPARQL Working Group Teleconference
12:01:49 <trackbot> Date: 26 March 2010
12:01:49 <LeeF> zakim, this will be SPARQL
12:01:49 <Zakim> ok, LeeF; I see SW_(SPARQLF2F)8:00AM scheduled to start now
12:03:32 <Souri> Souri has joined #sparql
12:07:38 <LeeF> topic: SPARQL 1.1 Query
12:07:43 <LeeF> subtopic: Aggregates
12:08:02 <dcharbon2> dcharbon2 has joined #sparql
12:08:12 <kasei> scribenick: kasei
12:08:13 <AxelPolleres> http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JanMar/0499.html
12:08:38 <kasei> AxelPolleres: multiset proposal from AndyS
12:08:50 <kasei> ... examples in email.
12:08:52 <MattPerry> MattPerry has joined #sparql
12:09:25 <kasei> SteveH: scribenick: LeeF
12:09:28 <kasei> oops
12:09:28 <LeeF> scribenick: LeeF
12:10:02 <LeeF> SteveH: there are some things in the mail that needs discussion
12:10:37 <LeeF> ...ignroe mail because it's out of line with the current spec
12:10:44 <LeeF> ...currently: aggregates take a list of expressions
12:10:48 <LeeF> ...evaluated with respect to the binding table
12:12:44 <pgearon> pgearon has joined #sparql
12:13:36 <LeeF> ...end up with an NxM list of values
12:13:41 <LeeF> ...gets passed to the aggregate value
12:13:46 <LeeF> ...which returns scalar results
12:14:00 <LeeF> ...doesn't usefully let you deal with multi-argument aggregates
12:14:10 <LeeF> ...Andy's proposal is that instead of producing a big multiset
12:14:17 <LeeF> ...you'd have a multiset of lists
12:14:30 <LeeF> ...where each list is the evaluation of the expressions in the aggregate with respect to the binding table
12:16:02 <SteveH> ?x = 1,2   ?y = 3, 4
12:16:02 <SteveH> and AGG(?x, ?y)
12:16:02 <SteveH> gives AGG({(1, 3), (2, 4)})
12:17:07 <LeeF> LeeF: what's the alternative?
12:17:12 <SteveH> {1, 3, 2, 4}
12:17:35 <LeeF> LeeF: definitely prefer Andy's proposal
12:17:43 <SteveH> SteveH: me too
12:17:45 <LeeF> AndyS: works well for geospatial examples
12:18:12 <LeeF> SteveH: complicates the definition of the set functions a bit
12:18:22 <LeeF> Axel: Seems to be consensus aorund this
12:19:34 <LeeF> AxelPolleres: referring to ISSUE-3, how are errors and unbounds handled?
12:19:44 <LeeF> AxelPolleres: we need to decide per aggregate, right?
12:19:47 <LeeF> SteveH: not necessarily
12:20:14 <LeeF> AxelPolleres: should we go through the list of aggregates?
12:20:25 <LeeF> SteveH: I think it depends on what we decide happens with error values 
12:20:38 <LeeF> ...I like Andy's proposal for minting a unique symbol, but don't like passing them into the aggregate
12:20:45 <LeeF> ...would rather pass a flag or a count of evaluation errors
12:21:01 <AndyS> Builin aggregates in grammar currently: http://www.w3.org/2009/sparql/docs/sparql-grammar-11.html#rAggregate (any missing?)
12:21:42 <AxelPolleres> evaluation of unbound leaves an error, so hard/impossible to distinguish.
12:22:31 <SteveH> ?x = 1, e  ?y = 3, 4
12:22:31 <SteveH> and AGG(?x, ?y)
12:22:31 <SteveH> gives AGG({(1, e), (2, 4)})
12:22:31 <SteveH> or    AGG({(2, 4)}) + 1 error
12:23:03 <LeeF> SteveH: pretend e is something that evaluates to an error
12:23:16 <LeeF> ...choices are a list with the error value in it, or else a list of the OK ones + an indication of the error
12:23:28 <LeeF> ...or (e, e) as a value passed to the aggregate
12:23:33 <SteveH> or (e,e), (2,4)
12:24:37 <LeeF> SteveH: this would mean that the aggregate would take a multiset of lists and a count of errors
12:24:54 <LeeF> bglimm: example should really be (1, 3) and (e, 4) 
12:25:00 <AndyS> Correction: AGG({(1, 3), (e, 4)})
12:25:02 <LeeF> AxelPolleres: why is the number of errors important?
12:25:20 <LeeF> AndyS: tells you the difference between the number of items in the partition and [too quiet for scribe to hear]
12:25:39 <LeeF> ...lets you do COUNT(*) like things
12:26:05 <LeeF> AxelPolleres: is this helpful for extending aggregates?
12:26:06 <LeeF> AndyS: yes
12:26:17 <LeeF> AxelPolleres: multiset with errors in place conveys more information
12:26:40 <LeeF> ...if you throw that information away, then in the algebra you've already made a decision for someone else who wants to define a custom aggregate on which information you have access to
12:26:48 <LeeF> SteveH: yes
12:26:55 <LeeF> AndyS: yes, but gives you uniform treatment of errors
12:27:36 <LeeF> AxelPolleres:  but what if someone wants to define an aggregate where you want to act differently depending on if an error occurs in the first or second argument?
12:27:44 <LeeF> SteveH: idea is to make all aggs behave in the same way 
12:27:51 <LeeF> ...can alter behavior with, e.g., COALESCE
12:28:34 <LeeF> q+ to ask if Axel has a use case for needing the other behavior
12:28:46 <LeeF> AxelPolleres: would suggest different aggregates for different behavior
12:28:47 <LeeF> ack me
12:28:47 <Zakim> LeeF, you wanted to ask if Axel has a use case for needing the other behavior
12:29:33 <LeeF> LeeF: asks if Axel has a use case for the other behavior 
12:29:35 <LeeF> AxelPolleres: No
12:29:45 <LeeF> LeeF: happy with the design that passes errors separately from the multiset of lists
12:31:28 <LeeF> AxelPolleres: is everyone happy with the solution? you have a multiset of lists with no errors, and the number of rows where an error occurred
12:31:53 <LeeF> Souri: do you have a concrete example?
12:32:21 <AxelPolleres> COUNT ( ?X ?Y )
12:32:21 <LeeF> ... perhaps COUNT with 2 columns
12:32:44 <LeeF> MattPerry: how does this effect the results of aggregates?
12:33:15 <LeeF> LeeF: my guess is it doesn't affect the semantics of the built-in aggregates, rather it affects whta's available to extension aggregates
12:33:46 <LeeF> s/ISSUE-3/ISSUE-53
12:33:50 <LeeF> (way back up high)
12:34:01 <SteveH> ?a    ?b
12:34:01 <SteveH> 1      2
12:34:01 <SteveH> 3      A
12:34:01 <SteveH> COUNT(xsd:integer(?a), xsd:integer(?b))
12:34:02 <SteveH> COUNT({(1, 2)}, errors = 1
12:34:25 <SteveH> answer: 2
12:34:41 <LeeF> IvanH: why would the answer be 2?
12:34:45 <LeeF> SteveH: the answer would be 1
12:34:59 <LeeF> s/SteveH: the answer would be 1/SteveH: because there are 2 elements
12:35:04 <AxelPolleres> COUNT ( * ) here would be 2, yes?
12:35:08 <LeeF> AndyS: I would expect the answer to be 1
12:35:16 <LeeF> bglimm: 1 results + 1 error row = 2 results
12:35:22 <AndyS> We haven't completely decided if we allow multiple args to COUNT - a discussion for the specifics of COUNT later
12:35:24 <LeeF> SteveH: COUNT(*) is a completely special case
12:35:45 <AndyS> In SQL, it seems agg(any error) is error.  agg of nulls is skipped.
12:35:47 <MattPerry> count(*) = 2, count(?x, ?y) = 1, right?
12:35:49 <LeeF> SteveH: I would expect COUNT on multiple values to count the # of values, not the number of rows
12:36:14 <AndyS> COUNT(COALESCE(?x,?y))
12:36:19 <LeeF> LeeF: I implement COUNT on multiple values to be the number of rows with at least one bound value
12:36:23 <AxelPolleres> would a row (e,e) be counted?
12:36:34 <LeeF> AndyS, yes, that's basically what I do :)
12:37:20 <AndyS> That is how to get the other effect of count when one or more is defined/non-error
12:39:00 <SteveH> COUNT({(1, 2)}
12:39:14 <AndyS> and the error count?
12:39:16 <SteveH> + errors = 1
12:39:43 <AxelPolleres> ?a ?b
12:39:43 <AxelPolleres>  1  2
12:39:44 <AxelPolleres>  3  A
12:39:44 <AxelPolleres>  B  C
12:40:27 <LeeF> q+ to ask about relation to what happens to errors in solution set
12:40:34 <LeeF> SteveH: counting tuples seems to be what people expect
12:40:36 <SteveH> COUNT() will count the number of tuples
12:40:45 <LeeF> AxelPolleres: COUNT only counts tuples without errors
12:40:54 <LeeF> AxelPolleres: special case is COUNT(*) which counts ...
12:40:57 <AndyS> COUNT(*) is special
12:41:03 <LeeF> SteveH: it's defined as counting the number of rows in the solution set
12:41:08 <AxelPolleres> q?
12:41:12 <LeeF> ack me
12:41:12 <Zakim> LeeF, you wanted to ask about relation to what happens to errors in solution set
12:42:09 <LeeF> SELECT (1/0 AS ?X) --> get one row with no binding for ?X
12:42:38 <LeeF> LeeF: given that behavior, I would expect COUNT({(1, 2)}, errors = 1  to give a COUNT of 2
12:43:56 <AndyS> we can define SELECT (1/0 AS ?X) differently - it's an independent decision - can go either way
12:44:58 <LeeF> ?a   ?b 
12:44:58 <LeeF> 1    2
12:44:58 <LeeF> 3    A
12:44:59 <AxelPolleres> Do I get that right?
12:44:59 <AxelPolleres> ?a ?b
12:45:00 <AxelPolleres>  1  2
12:45:00 <AxelPolleres>  3  A
12:45:00 <AxelPolleres>  B  C
12:45:00 <AxelPolleres> COUNT_Steve(?a ?b) -> 3
12:45:02 <AxelPolleres> COUNT_Lee(?a ?b) -> 2
12:45:04 <AxelPolleres> COUNT_Andy(?a ?b) -> 1
12:45:24 <LeeF> q+ to work through my opinion over Axel's case
12:45:48 <AxelPolleres> should be COUNT(xsd:integer(?a), xsd:integer(?b))
12:45:49 <AndyS> q+
12:46:05 <LeeF> SELECT (xsd:integer(?a) AS ?a_int) (xsd:integer(?b) AS ?b_int)
12:46:35 <MattPerry> count(*) = 2, count(?x, ?y) = 1, right?
12:46:43 <LeeF> SELECT (COUNT(xsd:integer(?a), xsd:integer(?b)) ?count)
12:47:08 <LeeF> LeeF: would expect to COUNT to give me the number of rows from the former case that have at least one OK value
12:47:09 <MattPerry> MattPerry has joined #sparql
12:47:17 <LeeF> s/to COUNT/COUNT
12:47:33 <LeeF> ack AndyS
12:47:36 <LeeF> ack me
12:47:36 <Zakim> LeeF, you wanted to work through my opinion over Axel's case
12:47:44 <AxelPolleres> q?
12:47:45 <LeeF> AndyS: we can decide either way what an error in the select expression does
12:47:51 <LeeF> ... i thought the preference was to keep it unbound
12:48:01 <LeeF> ... so SELECT is not acting like a FILTER
12:48:16 <AxelPolleres> q+ ta ask on what's the status of errors in SELECT expressions
12:48:32 <AxelPolleres> q+ to ask on what's the status of errors in SELECT expressions
12:48:32 <SteveH> q+
12:48:38 <LeeF> AndyS: I don't see the need to align the two behaviors
12:49:11 <LeeF> ack SteveH
12:49:26 <LeeF> SteveH: I would expect COUNT to be more similar to FILTER with which you lose a row with an error
12:49:57 <AndyS> ??example; SELECT ... HAVING COUNT(xsd:integer(?a), xsd:integer(?b)) > 0
12:50:08 <Souri> Souri has joined #sparql
12:50:32 <LeeF> LeeF: I would want COUNT in Axel's example to be 2 because in the non-aggregate case you would have 2 rows that have at least one binding
12:50:43 <LeeF> ... (you have a 3rd row with no bindings)
12:51:29 <AndyS> LeeF, you can get it withj COUNT(COALESCE(int(?x),int(?y))  -- all answers are COALESCE
12:51:47 <LeeF> AndyS, yes, I can, it's not what my impl (or intuition) does though :)
12:52:07 <AxelPolleres> q?
12:52:09 <LeeF> ack AxelPolleres
12:52:10 <Zakim> AxelPolleres, you wanted to ask on what's the status of errors in SELECT expressions
12:52:11 <AxelPolleres> ack Axel
12:52:54 <LeeF> For me, the semantics of COUNT involve COUNTing rows that have _something_ in it
12:53:00 <LeeF> s/For me/LeeF: For me/
12:53:05 <LeeF> Souri: that is like in SQL 
12:53:36 <LeeF> ... it's like doing a COUNT(*) limited to the sliced multiset
12:53:50 <LeeF> ... if you do COUNT(X) in SQL and X has a null value, it's not counted
12:53:54 <AndyS> We coudl define COUNT(?x) as single arg only 
12:53:54 <LeeF> LeeF: that's where my intuition comes from
12:53:58 <dcharbon2> q+ 
12:54:22 <AxelPolleres> OPTION 1 : FILTER view, result = 1
12:54:23 <AxelPolleres> OPTION 2 : projection view, result = 3 (always the same as COUNT(*))
12:54:23 <AxelPolleres> OPTION 3 : count rows with at least one unbound, result =2 
12:54:31 <AxelPolleres> q?
12:54:38 <LeeF> ack dcharbon
12:54:48 <LeeF> dcharbon2: tried to figure out what i thought the meaning of some of these results is
12:54:56 <AndyS> Under option 2, COUNT(?x) == COUNT(*) ??
12:55:19 <LeeF> ... with OPTION 1: you're counting complete tuples - then you can use COALESCE to get the count of tuples with any content - you're still missing a way to get the COUNT of all tuples including empty ones
12:55:26 <LeeF> ... there are probably use cases for all 3
12:55:27 <bglimm> As I see it, the only difference is whether something like xsd:integer(nonInteger) inserts a null/unbound value or whether it takes the row out in which nonInteger occurred
12:55:56 <SteveH> I think you can think of them options as:
12:55:57 <SteveH> COUNT(xsd:integer(?a) + xsd:integer(?b))
12:55:57 <SteveH> COUNT(COALESCE(xsd:integer(?a), xsd:integer(?b)))
12:55:57 <SteveH> COUNT(1)
12:56:03 <SteveH> not (1)...
12:56:06 <SteveH> that's wrong
12:56:43 <LeeF> dcharbon2: I like OPTION 1 because I think it gives you the flexibility to do all of the approaches
12:57:05 <LeeF> LeeF: that doesn't match my intuition, but I find dcharbon2's reasoning compelling
12:58:19 <kasei> q+
12:58:38 <LeeF> ack kasei
12:58:56 <LeeF> kasei: OPTION 1 does not count any row with an error anywhere in the tuple
12:59:18 <LeeF> LeeF: is this just errors, not unbounds?
12:59:24 <LeeF> SteveH: no it's the same, because eval(unbound) = error
12:59:34 <LeeF> LeeF: that's kind of weird to me
12:59:42 <LeeF> SteveH: also not happy, but would be difficult to change
13:00:14 <LeeF> AndyS: you could change it by special casing aggregate arguments that just take a variable 
13:00:40 <bglimm> SELECT COUNT(xsd:integer(?x)) AS ?count with ?x/abc, ?x/efg gives ?count/0
13:00:57 <LeeF> LeeF: <convinces himself that this is OK>
13:00:59 <AxelPolleres> PROPOSED: go for Option 1 on COUNT and allow multi-argument counts.
13:01:04 <SteveH> +1
13:01:20 <dcharbon2> +1
13:01:22 <bglimm> +1
13:01:23 <ivan> +1
13:01:28 <Souri> 0
13:01:50 <pgearon> 0
13:01:57 <LeeF> AxelPolleres: With this approach, we don't need to introduce errors into our value system
13:02:10 <AndyS> OPTION 1 : error anywhere in tuple -> tupe not passed down (~whole tuple an error) ==> result = 1
13:02:47 <MattPerry> q+
13:02:53 <AxelPolleres> PROPOSED: go for Option 1 (error anywhere in tuple -> tupe not passed down (~whole tuple an error)) on COUNT and allow multi-argument counts.
13:03:14 <bglimm> +1
13:03:20 <SteveH> +1
13:03:21 <dcharbon2> +1
13:03:22 <AndyS> +1
13:03:27 <LeeF> MattPerry: does this mean that for the purpose of aggregates, unbound and error are the same thing?
13:03:30 <LeeF> AxelPolleres: yes
13:03:33 <MattPerry> +1
13:03:51 <AxelPolleres> RESOLVED: go for Option 1 (error anywhere in tuple -> tupe not passed down (~whole tuple an error)) on COUNT and allow multi-argument counts.
13:04:51 <LeeF> Souri abstaining
13:05:14 <LeeF> AxelPolleres: other aggregates?
13:05:36 <LeeF> SteveH: i think we need to agree which ones, then I can go reword the spec in terms of the discussion today, but don't think we should go through all of them today - most are obvious
13:05:59 <LeeF> AxelPolleres: should we go through them and discuss what happens with errors ?
13:06:08 <AndyS> SUM(?x,?y) = SUM(?x+?y) under this design : any error => error => no tuple regardless of cause.  Nice
13:06:09 <LeeF> s/with errors/???/
13:06:13 <AxelPolleres> rermaining aggregates SUM, MIN, MAX, AVG, GROUP_CONCAT, and SAMPLE
13:06:46 <SteveH> Definition: Sum
13:06:47 <SteveH> The Sum aggregate function is used by the SUM function in the syntax.
13:06:47 <SteveH> The Mutiset argument to Sum is regarded as a sequence of values, S, and Sum is defined such that:
13:06:47 <SteveH> Sum(S) = op:numeric-add(S0, Sum(S1..n)) when |S| > 1
13:06:47 <SteveH> Sum(S) = S0 when |S| = 1
13:06:47 <SteveH> Sum(S) = 0 when |S| = 0
13:06:49 <SteveH> In this way, Sum({1, 2, 3}) = op:numeric-add(1, op:numeric-add(2, 3)).
13:07:13 <LeeF> q+ to suggest that we PROPOSE to resolve ISSUE-53 noting that tuples with errors are excluded from the multiset of lists passed to aggregate functions, and that the count of such excluded errors is passed to the aggregate function
13:07:23 <MattPerry> ack me
13:07:55 <LeeF> ack me
13:07:55 <Zakim> LeeF, you wanted to suggest that we PROPOSE to resolve ISSUE-53 noting that tuples with errors are excluded from the multiset of lists passed to aggregate functions, and that the
13:07:56 <kasei> so you can Sum over a single bnode?
13:07:59 <Zakim> ... count of such excluded errors is passed to the aggregate function
13:08:20 <SteveH> kasei, good point
13:08:24 <LeeF> PROPOSED: resolve ISSUE-53 noting that tuples with errors are excluded from the multiset of lists passed to aggregate functions, and that the count of such excluded errors is passed to the aggregate function
13:09:14 <LeeF> SUM(_:haha) = _:haha
13:09:37 <AxelPolleres> +
13:09:38 <sandro> maybe SUM(X) is X-X+X  :-)
13:09:38 <AxelPolleres> +1
13:09:47 <kasei> Sum(S) = op:numeric-add(S0, 0) when |S| = 1
13:09:50 <LeeF> PROPOSED: resolve ISSUE-53 noting that tuples with errors are excluded from the multiset of lists passed to aggregate functions, and that the count of such excluded errors is passed to the aggregate function
13:09:58 <SteveH> SUM(x) = op:numeric-add(x, 0)
13:10:45 <LeeF> RESOLVED: resolve ISSUE-53 noting that tuples with errors are excluded from the multiset of lists passed to aggregate functions, and that the count of such excluded errors is passed to the aggregate function, no abstentions or objections
13:11:04 <AxelPolleres> close ISSUE-53
13:11:04 <trackbot> ISSUE-53 How are unbounds and errors treated in aggregate evaluation? closed
13:11:15 <LeeF> ISSUE-53: resolved that tuples with errors are excluded from the multiset of lists passed to aggregate functions, and that the count of such excluded errors is passed to the aggregate function, no abstentions or objections
13:11:15 <trackbot> ISSUE-53 How are unbounds and errors treated in aggregate evaluation? notes added
13:11:28 <LeeF> subsubtopic: SUM
13:11:48 <LeeF> AxelPolleres: (1) any non-numeric value in SUM is not considered
13:12:00 <LeeF> ... (2) do we allow multi-argument SUM?
13:12:07 <LeeF> SteveH: my temptation is to sum over the tuple and then sum the sums
13:12:30 <LeeF> LeeF: that's what I do
13:13:03 <Souri> q+
13:13:04 <AxelPolleres> multi-argument SUM to be defined in the straightforward way, i.e. sum arguments 
13:13:19 <AxelPolleres> ?
13:13:34 <LeeF> ack Souri
13:13:51 <AxelPolleres> q+ to ask whether we need that at all
13:14:14 <LeeF> q+ to wonder if our resolution to ISSUE-53 makes multi-argument SUM act weird
13:14:23 <AxelPolleres> SUM ( ?X ?Y )  = SUM (?X+?Y ... same amount of characters.
13:14:38 <SteveH> ?a    ?b
13:14:38 <SteveH> 1      2
13:14:38 <SteveH> 3      A
13:14:38 <SteveH> SUM(?a, ?b) = 3
13:14:50 <kasei> q+
13:15:06 <Souri> sum(?a+?b) vs sum(?a,?b) ?
13:15:15 <kasei> SUM(?x,?y) is different from SUM(?x+?y) in the case of error/unbound, right?
13:15:40 <kasei> dropping a pair vs. dropping a single element...?
13:16:20 <Souri> do we need multi-arg sum ?
13:16:26 <kasei> ignore me. LeeF caught me up, but it brings up another issue.
13:16:26 <kasei> q-
13:17:07 <AxelPolleres> ack Axel
13:17:07 <Zakim> AxelPolleres, you wanted to ask whether we need that at all
13:17:19 <kasei> +1 Souri
13:17:45 <SteveH> happy to have SUM() syntactically limited to a single argument
13:18:03 <MattPerry> +1 single argument SUM() only
13:18:08 <LeeF> SELECT (SUM(?fingerLength, ?toeLength) AS ?sum) {
13:18:08 <LeeF>   { ?person :fingerLength ?fingerLength }
13:18:08 <LeeF>   UNION
13:18:08 <LeeF>   { ?person :toeLength ?toeLength}
13:18:08 <LeeF> }
13:18:30 <LeeF> LeeF: the above use case ends up passing nothing at all to SUM 
13:18:37 <LeeF> ... because every tuple has an unbound variable
13:18:38 <kasei> LeeF, I was just thinking of summing on OPTIONAL ?age.
13:18:39 <LeeF> ... which turns into an error
13:18:56 <iv_an_ru> iv_an_ru has joined #sparql
13:19:27 <kasei> SELECT (SUM(COALESCE(?fingerLength,0), COALESCE(?toeLength,0)) AS ?sum) ...
13:19:51 <AxelPolleres> q?
13:19:56 <AxelPolleres> ack LeeF
13:19:56 <Zakim> LeeF, you wanted to wonder if our resolution to ISSUE-53 makes multi-argument SUM act weird
13:21:07 <AndyS> q+
13:21:52 <LeeF> ack AndyS
13:22:00 <LeeF> AndyS: you can also do it by passing the sum into the union
13:22:11 <LeeF> ...by using the same variable
13:22:32 <Souri> +1
13:22:36 <LeeF> AxelPolleres: can we just keep SUM as a single argument aggregate?
13:22:55 <LeeF> SteveH: don't see a reason to, but won't object
13:22:56 <AndyS> +0
13:23:01 <LeeF> AxelPolleres: would anyone object to multi-argument SUM?
13:23:03 <LeeF> Souri: I would.
13:23:04 <SteveH> +0
13:23:19 <LeeF> AxelPolleres: Suggest based on this we keep SUM as single argument.
13:23:40 <AxelPolleres> PROPOSED: keep SUM as a single argument aggregate, no SUM(*)
13:23:44 <pgearon> +1
13:23:47 <MattPerry> +1
13:23:50 <AndyS> 0
13:23:53 <AlexPassant> +1
13:23:54 <SteveH> 0
13:23:56 <LeeF> abstain
13:24:01 <Souri> +1
13:24:52 <AxelPolleres> RESOLVED: keep SUM as a single argument aggregate, no SUM(*), 3 abstain, no objections
13:25:12 <SteveH> Definition: Min
13:25:13 <SteveH> The multiset of values passed as an argument is converted to a sequence S, this sequence is ordered as per the ORDER BY ASC clause.
13:25:13 <SteveH> Min(S) = S0
13:25:40 <LeeF> SteveH: believe this came out of difficulty coming up with something at F2F2
13:26:09 <LeeF> LeeF: agree this was the emerging but not overwhelming consensus at the last F2F
13:26:20 <LeeF> SteveH: can meet most use cases with casting and coalesce
13:27:59 <SteveH> so, MIN({(1, 2), (3, 4)} = MIN({1, 2, 3, 4})
13:28:25 <kasei> SteveH, are there use cases that can't be met with single-arg MIN/MAX if we have IF() ?
13:28:43 <kasei> I support multi-arg, but want to understand the options.
13:30:17 <SteveH> MIN(?x, COALESCE(?y, ?x))
13:30:46 <AndyS> LeeF: Notes that passing in tuples with error in val slot allows each aggregate to decide 
13:31:26 <LeeF> LeeF: in particular, whereas errors failing the tuple feels somewhat natural, innocent unbound variables now also yank out other nice values along with them
13:31:28 <AxelPolleres> MIN(COALESCE(?x,?y, ?z), COALESCE(?y, ?z, ?x) COALESCE(?z, ?x ?y))
13:31:38 <kasei> q+ to get clarification from SteveH
13:31:40 <Souri> Souri has joined #sparql
13:32:21 <SteveH> MIN(min(?x, ?y)) also works when ?x and ?y are numbers
13:32:22 <AndyS> Sometimes MIN(?x,?y) -> fn:min(MIN(?x),MIN(?y)) and does a reasonable (not quite same) thing
13:32:29 <SteveH> s/min/fn:min/
13:32:53 <kasei> is fn:min a thing?
13:33:01 <pgearon> it is for me
13:33:02 <LeeF> SteveH: I believe that multiargument MIN inwhich one of the variables is sometimes unbound is a corner case
13:33:05 <LeeF> LeeF: Granted
13:33:06 <AndyS> fn:min comes from F&O
13:33:14 <LeeF> s/inwhich/in which/
13:33:15 <AndyS> IIRC
13:33:23 <kasei> right, but it's not a standard yet...?
13:33:32 <pgearon> +q
13:33:40 <AndyS> (actually it takes sequence? - rat hole)
13:34:09 <LeeF> AxelPolleres: (1) only allow single arugment MIN (2) reconsider resolution to ISSUE-53 
13:34:15 <AxelPolleres> q?
13:34:18 <LeeF> ack kasei
13:34:18 <Zakim> kasei, you wanted to get clarification from SteveH
13:34:39 <LeeF> kasei: re: use cases for multiargument MIN. Would an IF function address these use cases?
13:35:15 <LeeF> SteveH: my use cases involve not knowing the type of the values involved
13:35:44 <AxelPolleres>  greg says, you can use "<" + IF?
13:36:04 <AxelPolleres> leeF: ORDER BY is more powerful than "<"
13:36:16 <SteveH> _:b < "foo"
13:36:51 <AndyS> _:b < "foo" is an error : ORDER will give _:b before "foo"
13:37:00 <LeeF> ack pgearon
13:37:42 <LeeF> pgearon: fn:MIN(MIN(?a), MIN(?b)) - why is this not identical to MIN(?a, ?b)? because of ORDER BY semantics? errors? something else?
13:38:01 <LeeF> AndyS: fn:min is an aggregate function in F&O - it takes one argument - a sequece
13:38:06 <LeeF> ... we don't have sequence types in SPARQL
13:41:38 <LeeF> AxelPolleres: how would people feel about re-opening ISSUE-53 to pass errors to the aggregates?
13:41:39 <LeeF> q?
13:41:41 <LeeF> q+
13:41:51 <LeeF> ... COUNT would be defined to exclude thoes
13:41:56 <LeeF> ... MIN and MAX would exclude just those values
13:43:03 <LeeF> ack me
13:43:19 <AndyS1> AndyS1 has joined #sparql
13:43:51 <LeeF> LeeF: My concern is more that errors and unbounds are treated the same way - unbounds in SPARQL seem so natural and innocnet that I don't see why they should have such a strong negative effect on the rest of a tuple passed to an aggregate
13:43:58 <kasei> so this is AndyS' idea of using something other than Eval() in aggregate evaluation?
13:44:12 <LeeF> AndyS: we would need to change aggregate eval to special case an expression that was just a variable
13:44:22 <LeeF> SteveH: we'd also need a token for the unbound variable
13:44:53 <AxelPolleres> -.05 on introducing NULL in SPARQL
13:45:58 <AndyS> ?x and ?x+0 (?x always a number or unbound) are then different
13:46:10 <AxelPolleres> PROPOSED: reconsider the resolution on ISSUE-53 noting that tuples with errors passed to aggregate functions, and that the the aggregate function needs to define how tuples with errors are dealt with. COUNT excludes tuples with errors passed to the aggregate function
13:46:23 <AxelPolleres> for whom that wouldn't work?
13:47:24 <LeeF> I would prefer to continue as we are now rather than go with that proposal, AxelPolleres
13:47:53 <LeeF> I'm not too happy with having to introduce an unbound token, either
13:50:20 <LeeF> AxelPolleres: notes conensus around multiargument MIN and MAX
13:50:26 <SteveH> SUM() will flatten the tuples, and apply ORDER BY semantics over the list
13:50:43 <LeeF> s/SUM/MIN
13:50:48 <SteveH> s/SUM/MIN and MAX()/
13:51:07 <AxelPolleres>  AVG, GROUP_CONCAT, and SAMPLE
13:51:08 <SteveH> Definition: Avg
13:51:09 <SteveH> Avg(M) = Sum(M) / Count(M)
13:51:27 <LeeF> OK with me 
13:51:59 <LeeF> AxelPolleres: this would limit us to single argument AVG
13:52:07 <LeeF> SteveH: potentially a reason for multiargument SUM
13:52:16 <SteveH> implies that AVG() is single argument too
13:52:20 <LeeF> bglimm: or an argument for all single argument aggregates!
13:52:27 <LeeF> AndyS: what about lots of zeroes?
13:52:27 <SteveH> need special case for |M| = 0
13:53:02 <AxelPolleres> div by 0 is just an error, no special case needed.
13:53:12 <SteveH> Definition: GroupConcat
13:53:12 <SteveH> The multiset of values passed as an argument is converted to a sequence S.
13:53:12 <SteveH> GroupConcat(S) = fn:string-join(S, sep)
13:53:44 <SteveH> sep is currently suggested as " ", but ", " is better
13:54:15 <SteveH> we have a proposal for more syntax: GROUP_CONCAT["|"](?x)
13:54:20 <kasei> AndyS, do you want GROUPCONCAT or something else?
13:55:01 <AndyS> kasei, yes - I'd write a GroupConcat as I write isIRI but case insensitive keywords
13:55:25 <sandro> ☃
13:56:30 <SteveH> 2nd alt. GROUP_CONCAT[seperator="|"](?x)
13:57:17 <dcharbon2> SEPARATOR("|",GROUP_CONCAT(?x))
13:57:24 <SteveH> 2nd alt. GROUP_CONCAT[seperator="|", order_by="desc"](?x)
13:57:49 <kasei> on consideration, I think I like Andy's GroupConcat
13:58:04 <bglimm> Why not GROUP_CONCAT(?s, "|")
13:58:07 <dcharbon2> scratch mine, I don't like it
13:58:16 <AxelPolleres> GROUP_CONCAT("|")[?x]
13:58:25 <AxelPolleres> MIN[?X] ...
13:58:31 <dcharbon2> require the separator and place it as the first arg
13:58:32 <AxelPolleres> SUM[?X] ....
13:58:33 <AndyS> Custom agg example?
13:58:42 <SteveH> custom:agg[?x]
14:00:10 <AndyS> q+
14:00:18 <kasei> SUM«?x» :)
14:01:05 <LeeF> AxelPolleres: what about square brackets for all aggregates?
14:02:13 <AxelPolleres> ivan, steveH: people expect to see '(' ')' for aggregates.
14:02:26 <SteveH> custom:agg[](?x)
14:02:56 <AndyS> or custom:agg[?x]   
14:03:03 <ivan> group_concate[","](asfasfa)
14:03:07 <kasei> i like the idea of supporting order_by, also, though.
14:03:43 <LeeF> GROUP_CONCAT(x SEPARATOR ",")
14:03:49 <kasei> q+
14:03:57 <AxelPolleres> q+ to claim that GROUP_CONCAT(?x "|") would work
14:04:03 <ivan> sandro's idea: group_concat(a,b,c,separator=",')
14:04:24 <dcharbon2> +1 to group_concat(a,b,c,separator=",")
14:04:26 <sandro> I like the keyword better than the square brackets.
14:04:26 <LeeF> ack AndyS
14:04:51 <LeeF> AndyS: problem with the use of a keyword is we need to define the keywords... if group_concat is special, i find it odd that you can't write a custom function that could do the same thing as group_concat
14:05:28 <dcharbon2> back to liking group_concat(",",a,b,c) - separator is req'd and is first arg
14:05:28 <sandro> group_concat(list(a,b,c), ",")
14:05:30 <SteveH> group_concat(a,b,c separator=",") is nicer IMHO
14:05:48 <AxelPolleres> q?
14:06:03 <LeeF> ack kasei
14:06:17 <AndyS> GroupConcat(?a,?b,?c [",",true])   # true is order desc
14:06:25 <LeeF> kasei: i like the ability of providing ordering, or at least being flexible enough to do it in custom aggregate functions
14:06:33 <AxelPolleres> q?
14:06:53 <AxelPolleres> GROUP_CONCAT(?x "|") 
14:07:17 <AndyS> q+
14:07:34 <AndyS> ack AxelPolleres
14:07:34 <Zakim> AxelPolleres, you wanted to claim that GROUP_CONCAT(?x "|") would work
14:08:11 <sandro> (in RIF they don't need commas, much to my annoyance.)
14:08:12 <kasei> GROUP_CONCAT[ ex:seperator "|" ; ex:order_by ?x ]( ?x ) # has issues with order by expressions, but runs with the similarity to bnode syntax.
14:08:22 <SteveH> GROUP_CONCAT[seperator="|", order_by="desc"](?x)
14:08:40 <SteveH> or GROUP_CONCAT["|", "desc"](?x)
14:09:06 <MattPerry> can't you just do ORDER BY  on a subquery and then GROUP_CONCAT that
14:09:16 <SteveH> MattPerry, yeah, you can
14:09:22 <sandro> I'm very happy with named arguments, but maybe that's because I use python.
14:09:35 <SteveH> MattPerry, actually, no, aggregates can't preseve order
14:09:59 <LeeF> I think the most extensible thing is square bracket swith named params that affect the behavior of a function
14:10:11 <SteveH> LeeF, +1
14:10:12 <AxelPolleres> GROUP_CONCAT["|" "desc"](?x)
14:10:17 <LeeF> don't care too much where the square brackets go, mainly because I think it's somewhat hideous in all cases :)
14:10:19 <sandro> GROUP_CONCAT(a,b,c;d,e,f)     (one more option... note the semi.   I don't like it as much as names.)
14:10:46 <AndyS> q+ to speak about names
14:11:28 <AxelPolleres> I like sandros GROUP_CONCAT(a,b,c;d,e,f)  ; 
14:11:39 <LeeF> ack AndyS
14:11:39 <Zakim> AndyS, you wanted to speak about names
14:11:44 <AxelPolleres> q?
14:12:13 <kasei> q+
14:12:51 <LeeF> q+ to add propose that we not include GROUP_CONCAT in SPARQL 1.1 Query
14:13:06 <AxelPolleres> break
14:13:11 <AndyS> Arbitrary keywords make tokenizing hard :: select= ...
14:16:11 <sandro> There's no need for URIs or namespacing of argument names, decentralized extensibility, because they are scoped by the function name.
14:29:05 <LeeF> I'm not sure if it's on our agenda, but I think we ought to discuss the semantics of grouping by expressions
14:31:53 <pgearon> pgearon has joined #sparql
14:44:56 <AndyS> Nice trick:  use query string to URIs for custom aggs <http://foo/agg?sep=,>(?x, ?y)
14:45:14 <AxelPolleres> OPTION 1: agree on separation between two argument lists (Agg, Func) 
14:45:15 <AxelPolleres> OPTION 1.1:  agg[Func](Agg) - steveH1
14:45:15 <AxelPolleres> OPTION 1.2:  agg(Agg; Func) - sandro1
14:45:15 <AxelPolleres> OPTION 1.3:  agg[FuncNamed](Agg) - steveH2, here FuncNamed is a list of named functional arguments (e.g. f1=Func1, f2=Func2)
14:45:15 <AxelPolleres> OPTION 1.3:  agg(Agg FuncNamed) - sandro2 
14:45:16 <AxelPolleres> OPTION 2: drop functionally parametrises Aggs at all
14:45:18 <AxelPolleres> OPTION 2.1: we can still include GROUP_CONCAT without separator character (would still allow to solve Steve's use case, but without order)
14:46:02 <AndyS> While I like named arguments, I think there are practical difficulties.
14:47:29 <LeeF> OPTION 2.2: omit GROUP_CONCAT from SPARQL 1.1 Query
14:47:44 <AxelPolleres> s/OPTION 1.3:  agg(Agg FuncNamed) - sandro2/OPTION 1.4:  agg(Agg FuncNamed) - sandro2/
14:49:03 <LeeF> scribenick: AlexPassant
14:50:38 <AxelPolleres> OPTION2.3: GROUP Concat with fixed separator 
14:52:12 <AxelPolleres> once again all options...
14:52:13 <AxelPolleres> OPTION 1: agree on separation between two argument lists (Agg, Func) 
14:52:14 <AxelPolleres> OPTION 1.1:  agg[Func](Agg) - steveH1
14:52:14 <AxelPolleres> OPTION 1.2:  agg(Agg; Func) - sandro1
14:52:14 <AxelPolleres> OPTION 1.3:  agg[FuncNamed](Agg) - steveH2, here FuncNamed is a list of named functional arguments (e.g. f1=Func1, f2=Func2)
14:52:15 <AxelPolleres> OPTION 1.4:  agg(Agg FuncNamed) - sandro2 
14:52:16 <AxelPolleres> OPTION 2: drop functionally parametrises Aggs at all
14:52:18 <AxelPolleres> OPTION 2.1: we can still include GROUP_CONCAT without separator character (would still allow to solve Steve's use case with the multi-argument version and then removing the trailing separator, but without order )
14:52:21 <AxelPolleres> OPTION 2.2: omit GROUP_CONCAT from SPARQL 1.1 Query
14:52:23 <AxelPolleres> OPTION 2.3: GROUP_CONCAT with fixed separator
14:55:05 <AxelPolleres> Andy, steveH discussing parsing/grammar of FuncNamed
14:55:26 <AlexPassant> AxelPolleres: Summary of options
14:55:46 <AlexPassant> ... overall design decision
14:55:55 <AlexPassant> ... allow or not extra functional arguments
14:55:59 <AlexPassant> ... option 1 and 2
14:56:02 <AlexPassant> ... + suboptions
14:56:25 <AlexPassant> ... any objection re. we need the fonctional parameter
14:56:37 <AlexPassant> ivan: we need it
14:56:37 <pgearon> I object to option 2
14:56:47 <LeeF> pgearon, why?
14:56:49 <AlexPassant> ... limites use if we dont have it
14:56:58 <LeeF> 2.2!
14:57:07 <AlexPassant> ... option 2 only if 2.2
14:57:26 <AxelPolleres> q?
14:57:29 <LeeF> ack kasei
14:57:30 <AlexPassant> AxelPolleres: agreement on the suboptions ?
14:57:33 <sandro> q?
14:57:34 <pgearon> I agree with LeeF's use case. I also think that it's useless without being able to specify the separator
14:57:34 <LeeF> ack LeeF
14:57:34 <Zakim> LeeF, you wanted to add propose that we not include GROUP_CONCAT in SPARQL 1.1 Query
14:57:46 <AlexPassant> LeeF: designing new stuff that we have not done yet
14:57:55 <SteveH> q+
14:58:02 <kasei> q+
14:58:02 <AlexPassant> ... group_contact extremely useful but dont know the degree of extensibility
14:58:12 <AlexPassant> ... maybe should not do it 
14:58:23 <AlexPassant> SteveH: disagree with LeeF and ivan 
14:58:31 <AlexPassant> ... useful and stupid not to have it
14:58:47 <AlexPassant> ... would lead to lots of incompatible implementation if not standardised
14:59:07 <AxelPolleres> q?
14:59:13 <AxelPolleres> ack SteveH
14:59:22 <AlexPassant> LeeF: fixed sep not a good idea
14:59:23 <sandro> q+ to argue that named arguments are extensible, and just put them at the end.
14:59:34 <AlexPassant> ... ', ' if fixed separater
14:59:47 <AlexPassant> ... but still get implementations changing it to make it useful
15:00:19 <AlexPassant> kasei: extensions will have this need
15:00:32 <AlexPassant> ... encouraging implementations to pursue on their own
15:00:44 <AlexPassant> LeeF: different approaches, but will learn from it for next time
15:01:00 <AlexPassant> ivan: not talking about something really complex
15:01:08 <AlexPassant> ... all prog. languages have it
15:01:10 <AxelPolleres> objections to OPTION 2.3 Lee, Greg ? objection to OPTION 2.2 Steveh?
15:01:11 <AlexPassant> ... trivial detail
15:01:24 <AxelPolleres> q?
15:01:26 <AlexPassant> ... would generally be happy with any suboption
15:01:33 <AlexPassant> LeeF: disagree - not trivial
15:01:38 <AxelPolleres> q?
15:01:57 <AxelPolleres> ack kasei
15:01:58 <AlexPassant> kasei: ivan summarised my point
15:02:17 <AlexPassant> ... clearly needed, fairly simple thing
15:02:23 <AlexPassant> ... issue is syntax based
15:02:25 <ivan> ack kasei
15:02:57 <SteveH> q+
15:03:08 <AlexPassant> pgearon: semantics is straightforward
15:03:11 <ivan> ack sandro 
15:03:11 <Zakim> sandro, you wanted to argue that named arguments are extensible, and just put them at the end.
15:03:15 <AlexPassant> ... concern is the syntax
15:03:28 <AlexPassant> sandro: keyword argument is straightforward
15:03:31 <AlexPassant> ... cf python
15:03:37 <AlexPassant> ... extensibility: dont need to be URI
15:03:49 <AlexPassant> ... the function specifies how you interpret the keywords
15:04:04 <AlexPassant> AxelPolleres: arguing for 1.1 ?
15:04:08 <AlexPassant> ivan: yes
15:04:12 <AndyS> If sandro arguing to chnage all function in SPARQL?
15:04:26 <AlexPassant> sandro: not sure of punctiation between arguments, but yes
15:04:37 <AxelPolleres> sandro arguing for OPTION 1.4
15:04:39 <AlexPassant> AxelPolleres: arguments should be named ?
15:04:41 <AlexPassant> sandro: yes
15:04:42 <AxelPolleres> q?
15:05:04 <AlexPassant> SteveH: they're not functions, they're aggregates
15:05:16 <AlexPassant> ... nervous about combining function syntax and aggregated syntax
15:05:17 <LeeF> ack SteveH
15:05:34 <AxelPolleres> steveH "foo=bar" looks lot like an Expression ?
15:05:57 <AlexPassant> SteveH: not evaluated as functions
15:06:03 <pgearon> +q
15:06:16 <AlexPassant> ... execution model is different
15:06:22 <dcharbon2> q+ to compare FuncNamed option 1.4 to Ruby map arguments
15:06:23 <AlexPassant> ... helps if we're clear about that
15:06:24 <AxelPolleres> q+ to ask about  foo=bar really different from Expressions?
15:06:26 <AxelPolleres> q?
15:06:35 <ivan> ack pgearon 
15:06:53 <AlexPassant> pgearon: already understand what the evaluation is supposed to be
15:07:00 <AlexPassant> ... matter of syntax for expressing what we want
15:07:08 <AlexPassant> ... fine w./ having a fixed separator
15:07:16 <AlexPassant> ... can be syntactically clear about what we want
15:07:22 <AlexPassant> ... fine with sandro proposal
15:07:22 <ivan> group_concat(a,b,c,d ; separator=",')
15:07:32 <sandro> s/fixed separator/argument separator
15:07:34 <AlexPassant> s/fixed separator/fixed argument separator
15:07:46 <AxelPolleres> paul fine with separator character, e.g. Option 1.2?
15:08:13 <AlexPassant> AxelPolleres: 2 things: functional arguments shoud be named or not + separator
15:08:21 <SteveH> q+ to ask about ; specifically
15:08:41 <AxelPolleres> OPTION 1.5 = OPTION1.2+OPTION 1.4
15:08:51 <dcharbon2> doSomething(a,b, :foo => "bar", :fiz => "baz") in Ruby - keywords aren't fixed
15:08:52 <AndyS> group_concat(a,b,c,d ; separator=",", desc=true)  ????
15:09:24 <LeeF> q+ to wonder why we wouldn't do this same thing for scalar functions if we really do this
15:09:41 <AxelPolleres> q?
15:09:51 <dcharbon2> q-
15:09:52 <AlexPassant> dcharbon2: not familiar w/ python but sounds good
15:10:01 <AxelPolleres> ack Axel
15:10:01 <Zakim> AxelPolleres, you wanted to ask about  foo=bar really different from Expressions?
15:11:32 <AlexPassant> AxelPolleres: looks like expressions
15:11:53 <AlexPassant> ... personally not in favor of the " keywords = "
15:12:03 <AlexPassant> ... objections re. existing opsions ?
15:12:26 <ivan> group_concat(a,b ; separator -> ",") to make it look like rif ?
15:12:52 <AlexPassant> ... LeeF objects fixed separator
15:12:59 <AlexPassant> ... sandro objects with []
15:13:01 <LeeF> s/LeeF/LeeF and kasei/
15:13:08 <AlexPassant> ... left are: 1.2
15:13:17 <AndyS> ivan ,What does that mean in RIF (/me behind the times)?
15:13:23 <AlexPassant> ... 1.4 + 1.5
15:13:36 <AlexPassant> ... 2.1
15:13:47 <AlexPassant> ... group concat without separator
15:14:13 <AxelPolleres> OPTION 1.2:  agg(Agg; Func) - sandro1
15:14:23 <AxelPolleres> OPTION 2.1: we can still include GROUP_CONCAT without separator character (would still allow to solve Steve's use case with the multi-argument version and then removing the trailing separator, but without order )
15:14:48 <AlexPassant> ... 1.2 -> last option w/out objections
15:14:48 <LeeF> q?
15:15:12 <AlexPassant> AndyS: 1.2. is confusing
15:15:16 <AlexPassant> ... style-wise
15:15:19 <AlexPassant> SteveH: agrees
15:15:59 <ivan> group_concat(a,b ; separator -> ",")
15:16:15 <ivan> group_concat(a,b ; separator = ",")
15:16:42 <ivan> group_concat(a,b | separator -> ",")
15:16:59 <AlexPassant> SteveH: is ; an arbitrary choice ?
15:17:02 <ivan> group_concat(a,b | separator = ",")
15:17:15 <kasei> group_concat(a, b, separator = ",")
15:17:32 <Souri> ';' would be confusing
15:17:32 <AlexPassant> ... asking if there's a particular reason
15:17:39 <AxelPolleres> q?
15:17:47 <ivan> ack SteveH 
15:17:47 <Zakim> SteveH, you wanted to ask about ; specifically
15:17:47 <AxelPolleres> ack SteveH
15:17:50 <LeeF> ack me
15:17:50 <Zakim> LeeF, you wanted to wonder why we wouldn't do this same thing for scalar functions if we really do this
15:19:12 <AlexPassant> AxelPolleres: why the second one needs to be named, not the first one
15:19:22 <AlexPassant> ... would have been happy with ; without names
15:19:30 <AlexPassant> SteveH: names make more obvious there are different
15:19:32 <sandro> All in favor of group_concat(a, b, separator = ",")  ?
15:19:46 <Souri> q+
15:20:04 <AlexPassant> Souri: 2 kind of arguments
15:20:12 <sandro> All in favor of group_concat(a, b; separator = ",")  ?
15:20:12 <AlexPassant> ... different kind of parameters
15:20:20 <AlexPassant> ... why they cant have differnet ways of specifying ?
15:20:49 <SteveH> there's only expressions, and parameters, not two kinds of parameters
15:21:04 <AxelPolleres> Would anyone object against  either group_concat(a, b; separator = ",") or group_concat(a, b | separator = ",")
15:21:11 <SteveH> either is OK for me
15:21:18 <ivan> +1 +1
15:21:19 <AndyS> Pref ;
15:21:19 <Souri> 2nd one
15:21:28 <sandro> +1 "|"
15:21:32 <bglimm> either is ok
15:21:36 <kasei> +1 +0.5
15:21:42 <MattPerry> +1 "|"
15:21:43 <AxelPolleres> pref ;
15:21:50 <AlexPassant> ok for both
15:21:52 <pgearon> aesthetically, I like ; but I appreciate SteveH's concern and am happy with |
15:21:53 <dcharbon2> no pref
15:21:57 <Souri> q+ to allow a default
15:21:59 <ivan> group_concat(a, b | separator = ",") seems to have the majority
15:22:00 <AndyS> Isn't |  list tail in some languages isn't it?
15:22:04 <LeeF> no pref on separator, uncomfortable with the whole lot 
15:22:08 <SteveH> prefer |, but not strongly
15:22:12 <AlexPassant> yes AndyS 
15:22:46 <sandro> !    
15:22:48 <AndyS> f(a, 1|2, 3)
15:23:00 <kasei> I thought it was ||
15:23:01 <sandro> how about "--" as the separator
15:23:10 <AlexPassant> AndyS: dont have | at the moment, but...
15:23:55 <AxelPolleres> PROPOSED: GROUP_CONCAT syntax  shall be GROUP_CONCAT(a, b; separator = ",")
15:24:08 <sandro> +1
15:24:08 <bglimm> +1
15:24:12 <AxelPolleres> +1
15:24:13 <SteveH> +1
15:24:14 <kasei> +1
15:24:15 <AlexPassant> +1
15:24:16 <pgearon> +1
15:24:18 <ivan> amen = 1
15:24:24 <dcharbon2>  +1
15:24:38 <LeeF> 0
15:24:38 <Souri> q?
15:24:39 <AxelPolleres> RESOLVED: GROUP_CONCAT syntax  shall be GROUP_CONCAT(a, b; separator = ",")
15:24:42 <LeeF> I abstain.
15:24:43 <AlexPassant> AxelPolleres: also general mechanism for any parameterised function
15:24:56 <AlexPassant> Souri: wanted to mention the typical case
15:25:01 <AlexPassant> ... chose one character to be default
15:25:08 <AlexPassant> ... so 2nd part can be optional
15:25:13 <SteveH> +1 to a default
15:25:15 <AlexPassant> ... comma or space make sense
15:25:21 <AlexPassant> LeeF: comma is good
15:25:32 <AndyS> space
15:25:54 <AlexPassant> AxelPolleres: can we leave it to the editors ?
15:26:01 <AxelPolleres> dafault separator is currently " " 
15:26:06 <AxelPolleres> q?
15:26:09 <LeeF> ack Souri
15:26:09 <Zakim> Souri, you wanted to allow a default
15:26:11 <Souri> q-
15:26:13 <AxelPolleres> ack Souri
15:26:31 <AlexPassant> AxelPolleres: last aggregate - SAMPLE
15:26:42 <AlexPassant> ... multiparameter in group_concat ?
15:27:06 <Souri> no
15:27:19 <AlexPassant> btw, should we discuss AndyS's comment regarding _ in group_concat ?
15:27:35 <kasei> do we have a scalar CONCAT function?
15:27:42 <SteveH> kasei, not at the moment
15:27:48 <AxelPolleres> PROPOSED: to keep GROUP_CONCAT single expression
15:27:56 <SteveH> abstain
15:27:57 <kasei> then I think multi-expression is desirable
15:28:08 <Souri> group_concat(c1||c2||c3)
15:28:20 <AxelPolleres> +1
15:28:46 <AlexPassant> Souri: dont have a syntax
15:28:51 <AlexPassant> LeeF: part of the function library
15:28:56 <kasei> what I'd want is GROUP_CONCAT(CONCAT(" ", ?latitude, ?longitude))
15:29:30 <AlexPassant> LeeF: not decided but will probably be in the function library
15:29:31 <SteveH> kasei, GROUP_CONCAT(CONCAT(?key, "=", ?val)) is a good example of that
15:29:41 <SteveH> we do that a lot
15:29:45 <AndyS> fn:string-join is two arg string concat
15:29:46 <kasei> yeah
15:29:46 <Souri> +1
15:29:54 <kasei> so let's just remember that we want a scalar CONCAT
15:29:58 <AlexPassant> AxelPolleres: can we resolve the single expression GROUP CONCAT ?
15:30:09 <AxelPolleres> RESOLVED: to keep GROUP_CONCAT single expression, one abstain, no objections
15:30:11 <AndyS> Sorry - I'm wrong - fn:concat N-ary
15:30:12 <AlexPassant> s/GROUP CONCAT/GROUP_CONCAT
15:30:21 <AlexPassant> AxelPolleres: next: SAMPLE
15:30:27 <AlexPassant> ... should be pretty clear
15:30:35 <AlexPassant> ... just need to figure out if that's multi expression
15:31:10 <LeeF> SteveH, pgearon abstaining to above resolution
15:31:35 <AxelPolleres> agreement to keep SAMPLE single expression
15:31:39 <AxelPolleres> ?
15:31:42 <kasei> +1
15:31:49 <Souri> q+
15:32:13 <kasei> COALESCE(SAMPLE(?name), SAMPLE(?fullname))
15:32:15 <AlexPassant> SteveH: e.g. want to pick some random names
15:32:33 <AlexPassant> ... not sure that's a strong enough usecase
15:33:01 <AxelPolleres> could be done with a UNION, it seems.
15:33:21 <pgearon> kasei - I don't understand the nested aggregates
15:33:24 <MattPerry> CONCAT(SAMPLE(?name), SAMPLE(?fullname))  ?
15:33:40 <Souri> sample(coalesce(?name,?fullname))
15:34:39 <Souri> q?
15:35:10 <AlexPassant> Souri: taking a sample with 4 values - some are NULL, can he SAMPLE select NULL as well ?
15:35:17 <Souri> q-
15:35:41 <AlexPassant> AxelPolleres: done with aggregates
15:35:48 <Souri> so did we agree on only single-arg sample?
15:35:55 <SteveH> yes
15:36:03 <AlexPassant> ... next: addressing extensibility in the spect
15:36:09 <AlexPassant> ... would like to leave this to the editors
15:36:19 <AlexPassant> ... "agregated extensibility" section
15:36:30 <AlexPassant> s/agregated/aggregates/
15:36:43 <AxelPolleres> aggregator extensibility section should go into spec... http://www.w3.org/mid/1777E22E-928C-4F75-8623-606FC0042454@deri.org
15:37:02 <AlexPassant> ... next: ISSUE-41
15:37:12 <AlexPassant> ... what do we allow in GROUP BY
15:38:17 <AlexPassant> SteveH: expressions are complicated
15:38:22 <AlexPassant> ... discussed in f2f2
15:38:50 <AlexPassant> kasei: used expressions in GROUP BY
15:38:52 <AlexPassant> ... was useful
15:39:19 <AlexPassant> ... pulled in out in the projection
15:39:51 <AlexPassant> AxelPolleres: use-case of Emmanuelle
15:39:54 <AlexPassant> ... related to the topic
15:40:00 <AndyS> Can do it with an assignment ^h^h^h^h^h^h^h subSELECT with expression
15:40:07 <MattPerry> can you project out of a subquery and then group by that in the outer query?
15:40:09 <kasei> is this dumb? and/or would it solve this problem? GROUP BY (?a+?b AS ?c)
15:40:20 <AndyS> ... but a bit ugly
15:41:20 <SteveH> { SELECT (?a + ?b AS ?c), * ... }
15:41:33 <AndyS> kasei - more consistent with SELECT needing AS but problem seems more to be about ?a and ?b scope in key/parition
15:41:37 <AlexPassant> AxelPolleres: not a variable that is projected
15:42:01 <kasei> AndyS, i would think they disappear and only ?c is relevant in the key/partition
15:43:02 <AlexPassant> ... could be solved with subselect that projects the variable
15:43:05 <AndyS> kasei - yes - that;s the mechanism I'd expect. (ARQ introduces vars if needed so AS isn't required)
15:43:07 <AlexPassant> ... would not lose expressivity
15:43:16 <Souri> example of Matt's suggestion in SQL: select max(deptno) from (select deptno, (case deptno when 10 then 'TEN' else 'OTHER' end) z from scott.emp) group by z;
15:43:22 <AlexPassant> ... propose to have only variables in GROUP BY
15:45:29 <AxelPolleres> Is the following currently possible?
15:45:33 <AxelPolleres> PREFIX : <http://books.example/> 
15:45:33 <AxelPolleres> SELECT  ?auth ?name (AVG(?numberOfBooks) AS ?averageNumberOfBooks)
15:45:33 <AxelPolleres> WHERE { ?auth :name ?name
15:45:33 <AxelPolleres>     {
15:45:34 <AxelPolleres>             SELECT ?auth (COUNT(?book) AS ?numberOfBooks)
15:45:34 <AxelPolleres>             WHERE {
15:45:36 <AxelPolleres>                     ?auth :wrote ?book .
15:45:38 <AxelPolleres>    }
15:45:40 <AxelPolleres>             GROUP BY ?auth
15:45:42 <AxelPolleres>            HAVING (?numberOfBooks > 5)
15:45:44 <AxelPolleres> }
15:45:53 <AxelPolleres> admittedly somewhat orthogonal
15:47:59 <AndyS> Currently: [20]     GroupCondition     ::=     ( BuiltInCall  | FunctionCall  | '(' Expression  ( 'AS' Var  )? ')' | Var  )
15:49:38 <AlexPassant> AxelPolleres: re. emmanuelle comment - author and name are projected
15:49:44 <AlexPassant> ... would not be allowed ?
15:49:49 <AndyS> and [19]     GroupClause     ::=     'GROUP' 'BY' GroupCondition+
15:49:54 <AlexPassant> LeeF: cant do that
15:50:33 <AlexPassant> SteveH: legal in SQL
15:51:00 <AndyS> In SPARQL -- SELECT  ?auth SAMPLE(?name) (AVG(?numberOfBooks) AS ?averageNumberOfBooks)
15:51:52 <AndyS> because outer is a GROUP BY implicitly to get AVG 
15:52:38 <AxelPolleres> that query is allowed, but emanuele's intended behaviour could be achieved with a subquery 
15:55:34 <AxelPolleres> agreement to go forward with what's in the current grammar (variables and renames allowed in GROUP BY)
15:56:31 <AxelPolleres> PROPOSED: Close ISSUE-41 with the agreemen to go forward with what's in the current grammar (variables and renames allowed in GROUP BY)
15:56:41 <LeeF> +1
15:56:49 <kasei> so long as "renames" means expressions with optional renaming.
15:56:50 <AxelPolleres> +1
15:57:04 <AndyS> +1 -- as per kasei
15:57:39 <AndyS> Is GROUP BY (?a+?b) legal?  Yes.
15:57:46 <AxelPolleres> PROPOSED: Close ISSUE-41 with the agreemen to go forward with what's in the current grammar
15:57:49 <AxelPolleres> +1
15:57:54 <bglimm> +1
15:57:58 <Souri> +1
15:57:59 <AlexPassant> +1
15:58:03 <dcharbon2> +1
15:58:09 <pgearon> +1
15:58:12 <MattPerry> +1
15:58:16 <AxelPolleres> RESOLVED: Close ISSUE-41 with the agreemen to go forward with what's in the current grammar
15:58:21 <AxelPolleres> close ISSUE-41
15:58:21 <trackbot> ISSUE-41 Does GROUP BY allow variables or expressions, and does it allow mutiple expressions? closed
15:58:38 <AlexPassant> AndyS: question about HAVING
15:58:47 <LeeF> ISSUE-41: resolved with the agreement to go forward with what's in the current grammar
15:58:47 <trackbot> ISSUE-41 Does GROUP BY allow variables or expressions, and does it allow mutiple expressions? notes added
15:59:04 <AndyS> What about the following: SELECT (COUNT(*) AS ?C) .... HAVING (COUNT(*) > 0 ) legal? I.e. same agg in two places, one HAVING
16:00:00 <AlexPassant> ... Is that allowed ? think so
16:00:12 <AlexPassant> SteveH: lots of complications
16:00:22 <SteveH> question about complications actually
16:00:35 <Souri> it becomes one group
16:01:16 <AxelPolleres> q?
16:01:46 <AlexPassant> AxelPolleres: is there an issue on that ?
16:01:50 <AlexPassant> AndyS: just checking if that works
16:01:59 <AxelPolleres> should we have a test case along these lines?
16:02:04 <AndyS> SELECT (COUNT(*) AS ?C) .... HAVING (?C > 0 )
16:02:43 <AlexPassant> AndyS: want to group something if the count is >0 and want also to return the count value
16:02:51 <kasei> i want to say projection happens too late for that
16:03:12 <AxelPolleres> main question is: Do we do HAVING before or after projection?
16:03:50 <AndyS> Agreement that not the second  not allowed.
16:03:51 <Souri> HAVING (?C > 0 ) would not work in SQL
16:03:52 <AlexPassant> AxelPolleres: agreement to allow the frst one, not sure about the 2nd
16:04:01 <kasei> if the first one happens, but projection happens before HAVING, then the COUNT(*) leaks through if you're not selecting it.
16:04:08 <AlexPassant> LeeF: fine 
16:04:30 <AxelPolleres> agreement to disallow projected variables being reused in HAVING
16:04:33 <AlexPassant> AxelPolleres: disallow projected variables in having
16:04:46 <AlexPassant> ... will be reflected in the spec
16:05:01 <AxelPolleres> ACTION: steveH to disallow projected variables being reused in HAVING in the spec
16:05:01 <trackbot> Created ACTION-209 - Disallow projected variables being reused in HAVING in the spec [on Steve Harris - due 2010-04-02].
16:05:25 <AlexPassant> ... looks like aggregates are done
16:05:35 <AxelPolleres> topic: NOT EXISTS vs. MINUS
16:05:54 <AlexPassant> ... next: NOT EXISTS / MINUS
16:06:33 <AlexPassant> SteveH: preference for the MINUS
16:06:37 <AxelPolleres> ACTION: Axel to draft a testcase for SELECT (COUNT(*) AS ?C) .... HAVING (COUNT(*) > 0 )
16:06:37 <trackbot> Created ACTION-210 - Draft a testcase for SELECT (COUNT(*) AS ?C) .... HAVING (COUNT(*) > 0 ) [on Axel Polleres - due 2010-04-02].
16:06:39 <AlexPassant> ... much easier to optimise
16:08:02 <AndyS> (5Store example - other engines differ)
16:08:11 <AlexPassant> ... OPTIONAL in NOT EXISTS
16:09:03 <AlexPassant> pgearon: also already implemented the MINUS semantics
16:09:56 <AlexPassant> SteveH: what happen in NOT EXISTS semantics if introducing a new variable ?
16:10:28 <SteveH> WHERE { <x> <p> ?o . NOT EXISTS { <a> ?p ?o } }
16:11:56 <AlexPassant> ericP: MINUS in the spec seems comparable to the one I have
16:12:07 <AlexPassant> ... right side has correspondence with the left side
16:12:16 <AlexPassant> ... substrct an empty set -> not eliminating anything
16:12:26 <AlexPassant> s/substrct/substract
16:14:39 <AlexPassant> .. cardinality for any particular solution is 0
16:16:27 <AlexPassant> SteveH: objection if NOT EXISTS only takes BGP + FILTER ?
16:16:39 <AlexPassant> kasei: can imagine also scoping to a Named Graph
16:17:30 <AndyS> NG with special case of GRAPH { ...} - several new grammar rules.
16:18:32 <AlexPassant> ericP: downside of using MINUS ?
16:18:42 <AlexPassant> AndyS: closest to the OPTIONAL NOT BOUND
16:18:43 <pgearon> q+
16:19:24 <kasei> yeah, def. would need new grammar rules. it's something like (GraphGraphPattern* + TriplesBlock* + Filter?)*
16:19:49 <AlexPassant> pgearon: trying to make algrbraic sound for construct that have no practical purposes
16:19:59 <AndyS> GraphGraphPattern needs to restrict to a TripleBlock not a general pattern
16:20:12 <AlexPassant> ... if different people implement diferently - it will not impact
16:20:24 <kasei> AndyS, yes, that too.
16:20:29 <kasei> very messy
16:20:50 <kasei> but simpler after you finish with parsing.
16:21:09 <pgearon> ack pgearon
16:21:46 <AlexPassant> ericP: does NOT EXISTS rely on compability f?
16:22:01 <AlexPassant> AndyS: no, like having a FILTER + sub-ask in it
16:22:12 <AlexPassant> ericP: algebra available?
16:22:44 <AndyS> http://www.w3.org/2009/sparql/docs/query-1.1/rq25.xml#defn_exists
16:23:25 <AlexPassant> AxelPolleres: feeling that won't get an agreement
16:24:00 <AlexPassant> sandro: can we just provide both semantics 
16:24:09 <AlexPassant> ... people coule implement either one and be correct
16:24:20 <AlexPassant> ... talking about the semantics not the syntax
16:24:33 <ericP> { a b c          { a b c      { a b c   7 7		   7 7	        8 8	   8 8	  MINUS    7 7 7 } =    8 8 8 } 7 7 7 8 8 8 }
16:24:53 <ericP> stupid linefeed compressing
16:25:39 <ericP> { a b c          { a b c      { a b c   7 7              7 7          8 8 8 8     MINUS    7 7 7 } =    8 8 8 } 7 7 7 8 8 8 }
16:25:48 <ericP> !!!
16:26:23 <ericP> { a b c          { a b c      { a b c
16:26:30 <ericP>   7 7              7 7          8 8
16:26:38 <ericP>   8 8     MINUS    7 7 7 } =    8 8 8 }
16:26:47 <ericP>   7 7 7
16:26:53 <ericP>   8 8 8 }
16:27:16 <ericP> what does NOT EXISTS do?
16:27:58 <LeeF> ericP, I don't think you can capture the difference solely by looking at solution sets
16:28:02 <LeeF> I think you need the query & the data
16:28:24 <LeeF> because I think the difference lies in how the Diff() operator is universally quantified over compatible solutions (or something like that)
16:28:33 <LeeF> (but i am likely very confused)
16:28:35 <kasei> LeeF, you may be right, but I'd guess that it's the same in this example.
16:28:37 <AlexPassant> sandro: both semantics and then editorial change if we can get both simpler ?
16:28:42 <LeeF> kasei, right, i agree
16:28:47 <sandro> (with the NOT EXISTS syntax)
16:29:40 <sandro> PROPOSED: Use the NOT EXISTS, with semantics which defined ONLY when the not-exists and minus semantics are the same.    Hopefully we'll find a clear way to express that in the spec.
16:29:49 <sandro> PROPOSED: Use the NOT EXISTS syntax, with semantics which defined ONLY when the not-exists and minus semantics are the same.    Hopefully we'll find a clear way to express that in the spec.
16:29:59 <sandro> PROPOSED: Use the NOT EXISTS syntax, with semantics which are defined ONLY when the not-exists and minus semantics are the same.    Hopefully we'll find a clear way to express that in the spec.
16:30:04 <AxelPolleres>  0
16:30:16 <kasei> regardless of the query, if you var-substitute the 7s and 8s on the lhs into whatever rhs patter you have, I think you know it will match given the rhs resultset from above.
16:30:56 <AndyS> I think they are the same in Eric's example but need to see query to be sure
16:31:19 <AlexPassant> LeeF: difference can not be explained easily
16:31:19 <pgearon> I'm OK with what Sandro proposes, but I prefer the MINUS syntax (since it's implicitly a binary operator, and a single word)
16:32:16 <AndyS> NOT EXISTS and restricted syntax ?
16:34:16 <AlexPassant> ericP: take advantage of existing implementaion of understanding ?
16:34:32 <AlexPassant> ivan:  more interested in people's understanding
16:34:35 <AxelPolleres> proposals on the table... 
16:34:39 <AxelPolleres> - agree on syntax NOT EXISTS, try to unify semantics (sandro)
16:34:39 <AxelPolleres> - agree on syntax MINUS, try to unify semantics (paul)
16:34:39 <AxelPolleres> - NOT EXISTS with restricted syntax (andy)
16:34:40 <AxelPolleres> ?
16:34:55 <pgearon> +q
16:34:56 <AlexPassant> SteveH: given none of us can distinguish NOT EXISTS and MINUS
16:35:03 <AlexPassant> ... issue re. how users would do it
16:35:18 <AlexPassant> ivan: how to explain without 'algebra', 'joint', etc.
16:35:36 <Souri> q+
16:35:38 <AlexPassant> SteveH: everything on the right is removed from the lest
16:35:43 <AlexPassant> s/lest/left
16:35:43 <AxelPolleres> {Left}  MINUS {Right}
16:35:54 <AlexPassant> ... my point is that there's no different
16:35:59 <sandro> PROPOSED: Use the NOT EXISTS syntax, with semantics which are defined ONLY when the not-exists and minus semantics are the same.    Hopefully we'll find a clear way to express that in the spec.
16:36:13 <sandro> (I don't care which syntax, myself)
16:36:34 <AlexPassant> kasei: differnet implementers will find what's the easiest way to implement
16:36:45 <AlexPassant> ericP: concenred about the transformation challenge
16:37:05 <AlexPassant> ... easy in SQL semantics
16:37:11 <AlexPassant> ... need to get clear and simple semantics
16:37:28 <AlexPassant> AxelPolleres: 3 proposals
16:38:15 <AlexPassant> ... sandro ; pgearon -> sandro + s/NOT EXISTS/MINUS ; AndyS -> restrict the syntax
16:38:43 <sandro> Two question:   which syntax, and whether to restrict the syntax or just not specify the semantics where they conflict.
16:43:17 <AlexPassant> AndyS: SQL needs to get the same columns on left and right
16:43:22 <Souri> what are the diffs between SQL MINUS and proposed SPARQL1.1 MINUS?
16:43:44 <AlexPassant> ... set difference between the 2 cols
16:44:04 <AlexPassant> ericP: difference between SQL and SPARQL both in the joint and the minus
16:45:21 <AlexPassant> AxelPolleres: no convergence of the WG
16:45:31 <AlexPassant> ivan: same issue for the lst 6 months
16:45:40 <AlexPassant> ... will be in the same situation in 6 months
16:45:50 <AlexPassant> ... sandro's proposal makes sense
16:46:04 <AlexPassant> AxelPolleres: agree on the syntax ? what about the semantics ?
16:46:23 <AlexPassant> sandro: 2 proposals: (1) which syntax and (2) using "merge semantics"
16:47:21 <AlexPassant> AxelPolleres: conditions would be contextual ?
16:47:32 <AlexPassant> sandro: resolving syntax first ?
16:48:31 <AlexPassant> ericP: what about NOT FOUND insteand of NOT EXISTS ?
16:48:35 <AlexPassant> ... open world issue
16:48:52 <AxelPolleres> how about just NOT
16:48:54 <sandro> eric: "NOT EXISTS" is blood in the water to Open World folks.
16:49:16 <AlexPassant> AndyS: NOT EXISTS is negation by failure
16:49:30 <AxelPolleres> NAF
16:49:36 <LeeF> straw poll: what are your thoguhts on the syntax choice NOT EXISTS?
16:49:39 <pgearon> -1
16:49:40 <SteveH> 0
16:49:43 <dcharbon2> 0
16:49:44 <AndyS> +1
16:49:45 <LeeF> +1
16:49:46 <ivan> 1
16:49:47 <MattPerry> +1
16:49:47 <AxelPolleres> +!
16:49:47 <Souri> +1
16:49:47 <ericP> -1
16:49:48 <kasei> +1
16:49:50 <AxelPolleres> +1
16:49:51 <sandro> -1
16:49:53 <bglimm> 0
16:49:54 <AlexPassant> 0
16:50:14 <LeeF> +8 / 4 / -3
16:50:40 <LeeF> straw poll: what are your thoughts on the syntax choice MINUS?
16:50:41 <kasei> 0
16:50:43 <pgearon> +1
16:50:47 <AxelPolleres> 0
16:50:47 <AndyS> -1
16:50:48 <SteveH> +0.5
16:50:48 <ivan> 0
16:50:49 <LeeF> 0
16:50:49 <ericP> +1
16:50:51 <MattPerry> -1
16:50:53 <Souri> -1
16:50:54 <sandro> +1
16:50:56 <dcharbon2> 0
16:51:00 <bglimm> +1
16:51:07 <AlexPassant> +1
16:51:27 <LeeF> +6 / 5 / -3
16:52:03 <LeeF> PROPOSED: Negation syntax is via the "NOT EXISTS" keywords
16:52:10 <SteveH> +1
16:52:13 <AxelPolleres> +1
16:52:13 <ivan> +1
16:52:20 <bglimm> 0
16:52:22 <sandro> +0
16:52:23 <Souri> +1
16:52:31 <pgearon> +1 if someone can clearly specify the difference between the two semantics
16:52:52 <LeeF> RESOLVED: Negation syntax is via the "NOT EXISTS" keywords, bglimm and sandro abstaining
16:53:25 <ericP> +χ
16:56:06 <kasei> q+
16:56:32 <LeeF> PROPOSED: SPARQL 1.1 Query defines semantics of NOT EXISTS that give the same results for both algebraic and procedural approaches and leaves other cases undefined
16:57:38 <LeeF> ack pgearon
16:57:47 <AlexPassant> AxelPolleres: 2 semanitcs that are both informative
16:58:02 <AlexPassant> pgearon: ivan mentioned users / implementers difference
16:58:12 <AlexPassant> ... implementers doing it because of a use-case
16:58:27 <AlexPassant> ... asked by users to go that way
16:58:36 <AlexPassant> ... each implementation come from user requirements
16:58:41 <AxelPolleres> can we say "Normative only of OPTIONAL is not used in rhs"?
16:58:47 <AlexPassant> ivan: feeling is thqt 99% of use-cases will work with both semantics
16:59:03 <AlexPassant> pgearon: 100% will
16:59:06 <AxelPolleres> Can we say "Normative only if OPTIONAL is not used in rhs"?
16:59:09 <LeeF> ack Souri
17:00:52 <LeeF> ack kasei
17:01:22 <AlexPassant> Souri: diffeent from the MINUS in SQL based on what goes in both sides
17:01:28 <AlexPassant> ... simlar way to UNION differences
17:03:06 <AxelPolleres> Is that a reasonable way to go (rephrasing sandro)?
17:03:06 <AxelPolleres> - put both semantics in
17:03:06 <AxelPolleres> - put a *normative* restriction in that OPTIONAL is not allowed in rhs
17:03:07 <AxelPolleres> - put an *informative* section that describes the differences of the 
17:03:07 <AxelPolleres>   semantics when the restriction is dropped
17:03:51 <LeeF> { ?person a foaf:Person } NOT EXISTS { ?airplane a ex:Airplane } 
17:03:53 <AlexPassant> ivan: MINUS can have - in some cases - the effect of not returning anything
17:04:05 <AlexPassant> ... 'patch' that backfires in kasei's case
17:04:10 <AndyS> Problem case was { ?s ?p ?o } MINUS {} => nothing
17:04:14 <AlexPassant> kasei: ading it to MINUS is irrelevant
17:05:11 <ericP> { ?s ?p ?o } MINUS { ?x ?y ?z } => nothing
17:05:14 <ericP> (as well)
17:05:30 <Souri> +1
17:05:39 <Souri> Souri has joined #sparql
17:05:47 <AxelPolleres> break?
17:05:56 <AndyS> ericp: depends on data
17:05:57 <AxelPolleres> q?
17:06:01 <LeeF> ericP, is that how it is now? i thought the patch prevented that? or the patch ensures that?
17:06:06 <AndyS> sorry - see the point now
17:06:40 <AlexPassant> ericP: no intersecting domain -> nothing substracted
17:06:56 <LeeF> ericP, then wouldn't { ?s ?p ?o } MINUS { ?x ?y ?z } => everything ?
17:07:16 <pgearon> LeeF, yes
17:07:52 <LeeF>  { ?person a foaf:Person } NOT EXISTS { ?airplane a ex:Airplane } 
17:07:58 <Souri> {?s ?p ?o} NOT EXISTS {?x ?y ?z} => nothing
17:08:06 <AlexPassant> kasei: LeeF's pattern gives everyghin and NOT EXISTS gives nothing
17:08:24 <AlexPassant> ... ok with dropping optional in the right side but will affect implementations
17:08:51 <AndyS> "or dom(μ) and dom(μ') are disjoint"
17:08:53 <AxelPolleres> don't really see the use case for { ?s ?p ?o } MINUS { ?x ?y ?z }
17:09:07 <AndyS> Minus(Ω1, Ω2) =
17:09:07 <AndyS>     { μ | μ in Ω1 such that for all μ' in Ω2, 
17:09:07 <AndyS>     either μ and μ' are not compatible or dom(μ) and dom(μ') are disjoint }
17:09:35 <AlexPassant> LeeF: keep solutions on the left either not compatible not disjoint from the right
17:09:51 <pgearon> Axel, the only use-case I can think of is if a user defines the thing to take away from the LHS
17:11:04 <LeeF> reconvene at 10 to the next hour
17:11:06 <dcharbon2> Is this the email AndyS http://lists.w3.org/Archives/Public/public-rdf-dawg/2009JulSep/0137.html
17:11:32 <AndyS> Yes - thanks
17:12:43 <bglimm> http://lists.w3.org/Archives/Public/public-rdf-dawg/2009JulSep/0030.html
17:54:09 <AndyS> Diff:             { μ | μ in Ω1 such that for all μ′ in Ω2, 
17:54:09 <AndyS>     either μ and μ′ are not compatible or μ and μ'
17:54:09 <AndyS>     are compatible and expr(merge(μ, μ')) has an effective boolean value 
17:54:09 <AndyS> 	of false }
17:54:26 <AndyS> (current 1.0 spec - diff is not exposed directly)
17:54:45 <sandro> it's probably a typo if there is no overlap in variables.
17:56:11 <AxelPolleres> ! EXISTS
17:56:15 <AxelPolleres> NOT EXISTS
17:56:18 <AxelPolleres> ?
17:56:40 <Souri> I like NOT EXISTS
17:57:19 <sandro> lee: why NOT EXISTS outside of FILTER?
17:57:29 <sandro> andy: It's just a nice shorter form.
17:57:40 <sandro> scribe: AxelPolleres 
17:57:44 <sandro> :-)
17:58:15 <AxelPolleres> Andy: I would like NOT EXISTS as shortcut for the FILTER ! EXISTS
17:58:17 <sandro> lee: I like to keep the mental models more clear
17:58:40 <AxelPolleres> andy: why not put in a pure form of MINUS then?
17:59:33 <LeeF> { ?person a ex:Person } MINUS { ?airplane a ex:Airplane }
17:59:51 <AxelPolleres> LeeF: people interested using the mental model of set subtract feel that in my example no persons should be lost
18:00:19 <AxelPolleres> Andy: happy with that, allows optimisation
18:00:40 <AxelPolleres> sandro: shouldn't that be a syntax error?
18:01:13 <AxelPolleres> LeeF: proposal ...
18:01:42 <LeeF> PROPOSED: Include MINUS as a binary graph pattern operator and include EXISTS and NOT/! EXISTS as FILTER functions/constructs
18:01:44 <ericP> +1
18:01:46 <AxelPolleres> ... include MINUS as binary graph pattern OP and include EXISTS as FILTER... 
18:01:48 <SteveH> +1
18:02:03 <AxelPolleres> +.99
18:02:07 <AxelPolleres> +1
18:02:08 <MattPerry> +1
18:02:20 <ivan> +1
18:02:21 <AlexPassant> +1
18:02:27 <AndyS> +0
18:02:31 <sandro> +1
18:02:44 <bglimm> +1
18:02:48 <Souri> +1
18:02:52 <LeeF> RESOLVED: Include MINUS as a binary graph pattern operator and include EXISTS and NOT/! EXISTS as FILTER functions/constructs, AndyS abstaining
18:03:22 <SteveH> marginal preference for !, dont dont care
18:03:44 <kasei> if we require FILTER keyword, I support !, not NOT
18:03:46 <AxelPolleres> Andy: ! Exists not possible outside the filter
18:04:08 <AxelPolleres> ... but ! EXISTS not really clear.
18:04:34 <AxelPolleres> Any: why not just make NOT synonymous to !?
18:04:51 <AxelPolleres> EricP: don't want to dilute the grammar
18:05:49 <bglimm> s/Any/Andy/
18:06:00 <SteveH> q+
18:06:05 <LeeF> ack SteveH
18:06:05 <AxelPolleres> LeeF: preference in Boston on ! EXISTS
18:06:27 <SteveH> q-
18:06:39 <AxelPolleres> steve: if only in the FILTER then ASK could be reused instead of a new keyword.
18:07:18 <AxelPolleres> andy: that's not what I had agreed on
18:07:25 <ericP> s/on/to/
18:07:35 <LeeF> PROPOSED: The EXISTS filter function is negated with a ! 
18:07:38 <SteveH> +1
18:07:39 <kasei> q+
18:07:44 <LeeF> ack kasei
18:07:44 <AndyS> -1
18:08:21 <ericP> +1
18:08:34 <Souri> +1
18:08:43 <AndyS> q+
18:08:46 <AxelPolleres> greg: inside a FILTER it seems that '(' ')' enclosing the pattern would seem reasonable
18:09:01 <LeeF> ack AndyS
18:09:19 <AxelPolleres> LeeF: I suggest to ask the editors to come up with a proposal in the draft and move on to other issues
18:09:37 <AxelPolleres> Andy: curly braces because it is a pattern
18:10:47 <AxelPolleres> LeeF: maybe get to other issues than query for the moment to get a break
18:10:49 <LeeF> topic: Entailment Issues
18:11:12 <LeeF> http://www.w3.org/2009/sparql/track/issues/28
18:11:23 <AxelPolleres> Lee: ... talk about Entailment issues, we have a list of issues we probably can close.
18:12:44 <AxelPolleres> Axel: Birte suggests to not tackle entailment vs. updates for this time i.e. close ISSUE-28 and ISSUE-40 
18:12:58 <LeeF> PROPOSED: Close ISSUE-28 and ISSUE-40 by noting that our current work does not specify anything about the relationship between entailment regimes and SPARQL Update
18:13:03 <ivan> +1
18:13:09 <bglimm> +1
18:13:11 <sandro> +0
18:13:14 <SteveH> +0
18:13:14 <AndyS> +1
18:13:16 <Souri> Souri has joined #sparql
18:13:18 <AxelPolleres> 0
18:13:22 <AxelPolleres> q+
18:13:26 <ericP> ~0
18:13:42 <LeeF> RESOLVED: Close ISSUE-28 and ISSUE-40 by noting that our current work does not specify anything about the relationship between entailment regimes and SPARQL Update, sandro, steveh, axelpolleres abstraining
18:13:49 <LeeF> s/abstraining/ab straining
18:13:58 <LeeF> s/ab straining/abstaining
18:14:20 <sandro> axel: There would be a solution, to say for entailment we take the scoping graph for matching, then for update we use the ...
18:14:23 <LeeF> ISSUE-20: resolved by noting that our current work does not specify anything about the relationship between entailment regimes and SPARQL Update
18:14:23 <trackbot> ISSUE-20 Graphs aware stores vs. quad stores for SPARQL/update (empty graphs) notes added
18:14:27 <LeeF> ISSUE-28: by noting that our current work does not specify anything about the relationship between entailment regimes and SPARQL Update
18:14:27 <trackbot> ISSUE-28 Entailment regimes vs. update? notes added
18:14:30 <LeeF> ISSUE-40: by noting that our current work does not specify anything about the relationship between entailment regimes and SPARQL Update
18:14:30 <trackbot> ISSUE-40 How can other entailment regimes plug in their semantics to SPARQL/Update? notes added
18:14:30 <sandro> axel: So you couldn;'t remove inferred triples
18:14:35 <LeeF> trackbot, close ISSUE-28
18:14:35 <trackbot> ISSUE-28 Entailment regimes vs. update? closed
18:14:39 <LeeF> trackbot, close ISSUE-40
18:14:39 <trackbot> ISSUE-40 How can other entailment regimes plug in their semantics to SPARQL/Update? closed
18:14:52 <sandro> +1 yeah, something like that sounds nice, but okay we're not ready to spec that.
18:15:06 <LeeF> Next issue: http://www.w3.org/2009/sparql/track/issues/34
18:15:26 <AxelPolleres> birte: problem is that we don't have time to write all options down and have other issues to focus on... i.e. time doesn't allow 
18:15:43 <AxelPolleres> Birte: on the nexty issue 34 ...
18:16:29 <AxelPolleres> ... we treat bnodes as blank nodes as skolem constants and so there's no issue.
18:16:42 <AxelPolleres> s/bnodes as//
18:17:11 <LeeF> PROPOSED: Close ISSUE-34 by accepting the current clearly defined semantics of blank nodes 
18:17:15 <AxelPolleres> ... proposes to close the issue since the behavior of bnodes is clearly defined by that.
18:17:23 <bglimm> +1
18:17:24 <AxelPolleres> +
18:17:25 <AxelPolleres> +1
18:17:38 <LeeF> RESOLVED: Close ISSUE-34 by accepting the current clearly defined semantics of blank nodes, no objections or abstentions
18:17:43 <AndyS> +1
18:17:46 <LeeF> trackbot, close ISSUE-34
18:17:46 <trackbot> ISSUE-34 How do other entailment regimes interact with aggregate grouping vis a vis blank nodes? closed
18:17:50 <AxelPolleres> no one objects/abstain
18:17:56 <LeeF> http://www.w3.org/2009/sparql/track/issues/42
18:18:16 <AxelPolleres> LeeF: RDFS and inconsistencies...
18:18:50 <AxelPolleres> Birte: applies to other entailment regimes with inconsistencies as well, all these have the same solution at the moment
18:19:16 <AxelPolleres> ... we don't enforce consistency checks, but say that if inconsistencies are checked that should be returned to the user.
18:19:32 <AxelPolleres> ... MAY in the RFC sense.
18:19:35 <Souri> q+
18:19:40 <LeeF> ack AxelPolleres
18:19:42 <LeeF> ack Souri
18:20:05 <AndyS> q+
18:20:21 <AxelPolleres> souri: we do actually point out if we find inconsistencies in OWL (at loading) 
18:20:30 <LeeF> ack AndyS
18:20:39 <LeeF> PROPOSED: Close ISSUE-42 noting the current text that says implementations MAY check for inconsistencies and SHOULD raise an exception if they come across an inconsistency
18:20:41 <AndyS> ack AndyS
18:20:45 <AxelPolleres> ... we could just answer with pointing out the inconsistencies
18:20:55 <sandro> +1
18:20:59 <AxelPolleres> Andy: if you have loaded correct data then it is not an issue.
18:21:00 <AndyS> +1
18:21:02 <bglimm> +1
18:21:03 <AxelPolleres> +1
18:21:04 <Souri> +1
18:21:06 <LeeF> RESOLVED: Close ISSUE-42 noting the current text that says implementations MAY check for inconsistencies and SHOULD raise an exception if they come across an inconsistency, no objections or abstentions
18:21:28 <ivan> ISSUE-42: resolved by the current text in the document ( implementations MAY check for inconsistencies etc...)
18:21:28 <trackbot> ISSUE-42 TF-ENT What should happen for RDFS entailment in the face of inconsistencies? notes added
18:21:44 <AxelPolleres> subtopic: finite answer criteria
18:21:49 <ivan> trackbot, close ISSUE-42
18:21:49 <trackbot> ISSUE-42 TF-ENT What should happen for RDFS entailment in the face of inconsistencies? closed
18:21:51 <AxelPolleres> Birte: current state ...
18:22:08 <AxelPolleres> ... for RDF RDFS the main issues are infinite axiomatic triples.
18:22:45 <Souri> q+
18:22:51 <AxelPolleres> ... at the moment, we return graph vocabulary, RDF(S) vocabulary, but not those infinite rdf:_n properties unless they occur.
18:23:15 <AxelPolleres> ... RIF is more tricky, because infinity can occur through recursion over built-ins.
18:23:30 <AxelPolleres> ...  strongly safe fragment of RIF Core is fine.
18:24:04 <AxelPolleres> ... sandro asked whether finiteness criterion is really useful.
18:24:06 <Souri> q+ to ask about OWL 2 RL profile
18:24:54 <AxelPolleres> sandro: can't see practical reasons for finiteness criterion.
18:25:16 <AxelPolleres> ... think that's only from throeretical concerns.
18:25:41 <LeeF> ack Souri
18:25:41 <Zakim> Souri, you wanted to ask about OWL 2 RL profile
18:25:41 <AxelPolleres> LeeF: sandro, you think that we should not satisfy the finiteness criterion for RIF Core?
18:25:54 <LeeF> q?
18:26:09 <AxelPolleres> Souri: there's a separate issue for OWL2RL?
18:26:21 <AxelPolleres> Birte: OWL2RL is fine.
18:27:00 <AxelPolleres> Ivan: we felt in the Entailment-TF that we need the blessing of the group  to drop the finiteness restriction
18:27:29 <AxelPolleres> LeeF: extension mechanism says that we need to guarantee finiteness of answers
18:27:38 <AxelPolleres> q+
18:27:42 <LeeF> ack AxelPolleres
18:28:51 <sandro> ivan: weaken finiteness restriction from MUST to SHOULD
18:29:06 <AxelPolleres> Axel: I think we have to change the extension mechanism conditions in order to lift the restriction to finiteness.
18:29:17 <LeeF> PROPOSED: Update the SPARQL Query BGP entailment extension mechanism to weaken the requirement on finite answers to be a suggestion
18:29:22 <kasei> q+
18:29:28 <sandro> +1
18:30:48 <LeeF> ack kasei
18:31:26 <AxelPolleres> Axel: just asking whether there is a way to stream (infinite) results 
18:32:30 <AxelPolleres> Greg: for the RDF/RDFS case what if a term, that is entailed appears in the query but not in the queried graph, but is actually entailed?
18:32:54 <AxelPolleres> Birte: We can  take the graph + query vocabulary into account 
18:33:15 <AxelPolleres> ... that shouldn't be a problem.
18:33:17 <LeeF> PROPOSED: Update the SPARQL Query BGP entailment extension mechanism to weaken the requirement on finite answers to be a suggestion
18:33:21 <ivan> q?
18:33:29 <ivan> +1
18:33:34 <sandro> +1
18:33:34 <AxelPolleres> Axel: was thinking of that for D-entailment as well... taking the query vocab into account should solve that.
18:33:49 <LeeF> RESOLVED: Update the SPARQL Query BGP entailment extension mechanism to weaken the requirement on finite answers to be a suggestion, no objections or abstentions
18:34:03 <ivan> s/MUST/SHOULD/ is the proposed text for Andy, probably...:-)
18:34:24 <LeeF> ACTION: Birte to email out the text change needed to weaken the finite answer criteria in SPARQL Query
18:34:24 <trackbot> Created ACTION-211 - Email out the text change needed to weaken the finite answer criteria in SPARQL Query [on Birte Glimm - due 2010-04-02].
18:34:53 <AxelPolleres> Andy: make sure that it's carefully worded.
18:34:57 <LeeF> http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JanMar/0468.html
18:36:19 <AxelPolleres> Birte: please let's first discuss the other condition in the extension mechanism which says that the scoping graph needs to be uniquely defined...
18:37:07 <AndyS> is uniquely specified and is E-equivalent to AG.
18:37:24 <AxelPolleres> ... should be rephrased
18:37:51 <AxelPolleres> Birte: I suggest to send a rephrasing proposal for that one as well
18:37:58 <LeeF> ACTION: Birte to propose change to unique specified extension criteria
18:37:58 <trackbot> Created ACTION-212 - Propose change to unique specified extension criteria [on Birte Glimm - due 2010-04-02].
18:38:11 <AxelPolleres> (along the lines uniquely defined up to graph equivalence ?)
18:38:13 <LeeF> http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JanMar/0468.html
18:38:17 <AxelPolleres> q+
18:38:21 <LeeF> ack AxelPolleres
18:38:59 <LeeF> AxelPolleres: Since there are RDF stores that support datatype handline but not RDFS entailment... (1) this is not D-entailment (because that sits on top of RDFS entailment)
18:39:13 <LeeF> ... (2) what these stores do is convert literals with data types to an internal canonical form
18:39:20 <bglimm> "1.00"^^xsd:decimal is the same value as "1.0"^^xsd:decimal, but different lexical form
18:39:24 <LeeF> ... some of these would return the lexical forms of the original graphs and others would return only the canonical forms
18:39:29 <LeeF> ... two questions
18:39:37 <LeeF> ... Q1: does this influence the destination of D-entailment?
18:39:41 <LeeF> ... Birte convinced me "no"
18:39:44 <LeeF> ... so Q1 is fine
18:40:04 <LeeF> ... Q2: Should we also define a mini-entailment regime for these RDF stores that do datatype but not RDFS entailment?
18:41:39 <AxelPolleres> G: :s :p 1
18:42:12 <AxelPolleres> Q: ASK { :s :p "1.000"^^xs:decimal }
18:42:52 <AxelPolleres> according to the current SPARQL document, I understand that this would return "NO"
18:43:02 <AxelPolleres> (on simple entailment)
18:44:12 <AxelPolleres> sandro: I would like to support something like D^-.
18:44:34 <AxelPolleres> Andy: I wouldn't be implementing corner cases, probably.
18:44:37 <sandro> Sandro: I think its important the RDF stores be allowed to store only their internal form of the data values.       I don't want to force people to remember all the trailing zeros and whether it's xs:int vs xs:integer.
18:44:58 <AxelPolleres> Paul: I store as much as I can of the original structure.
18:45:01 <AxelPolleres> q+
18:45:34 <AxelPolleres> Paul: i internally convert a number to union of all the internal representations of that number.
18:45:36 <AndyS> AndyS: my stores store value for convenient ranges (e.g. +- 56 bits of precision for an integer)
18:45:47 <AxelPolleres> saandro: isn't that expensive
18:46:03 <AxelPolleres> paul: not that expensive.
18:46:09 <AndyS> and just store lexicial form style otherwise (out of range, bad lexical)
18:46:28 <AndyS> "3"^^xsd:byte
18:46:30 <AxelPolleres> greg: how do you ask for 3 as a number?
18:47:29 <AxelPolleres> sandro: If I put in 3.0000000....000000 you store all that?
18:47:40 <AxelPolleres> paul: yes, because I got complaints
18:47:42 <AndyS> Value stores vs derived datatypes
18:47:50 <AxelPolleres> q?
18:48:09 <AndyS> Also, currently because of NaN and Inf, TDB does not do xsd:double or xsd:float.
18:48:10 <Souri> q+
18:48:15 <LeeF> ack AxelPolleres
18:49:09 <LeeF> ack Souri
18:50:28 <AxelPolleres> Andy: how does D-entailment require RDFS?
18:50:38 <AndyS> (found it)
18:50:57 <AndyS> Except for XMLLiterals.
18:51:01 <AxelPolleres> Axel: D-interpretations are rdfs-interpretations 
18:51:17 <sandro> souri: if you have a join of "0.3000000" and "0.3000" , do they match, and which do you return
18:51:19 <AxelPolleres> Souri: we do canonical value based matching in Oracle
18:51:26 <sandro> lee: in SPARQL 1.0 they don't match.
18:51:32 <AxelPolleres> ... so D^- would be welcome
18:52:02 <AxelPolleres> sandro: any reasonable implementaiton would do that.
18:52:51 <sandro> lee: "Value Entailment" ?
18:52:54 <AxelPolleres> ... maybe we need a better name.
18:53:22 <ivan> s/lee/Andy/
18:53:24 <sandro> +1 value entailment
18:53:26 <AxelPolleres> LeeF: seems we need no resolution, but consensus that we should go forward with that.
18:53:46 <AxelPolleres> .... i would prefer not to discuss rif:imports now.
18:54:02 <AxelPolleres> Birte/Axel: ok to move that to the entailment-TF
18:54:03 <sandro> (My expectation is that many/most serious SPARQL systems will do value-entailment only, since it's much more efficient.)
18:54:22 <AxelPolleres> topic: service description
18:54:57 <AxelPolleres> LeeF: what about saddle's supported resultformats part (we were asked in a comment) 
18:55:11 <sandro> uris like http://www.w3.org/ns/formats/rdfxml
18:55:15 <AxelPolleres> greg: eric and sandro are working on some proposal for URIs for that.
18:55:37 <sandro> a uri space for all formats that W3C  knows/cares about, we can make a URI for them here.
18:56:07 <AxelPolleres> ... we also will add mediatypes in the service description.
18:56:38 <AxelPolleres> ... i.e. we will go format with both resultformats and mediatypes.
18:56:51 <AxelPolleres> LeeF: more questions on that?
18:57:16 <AxelPolleres> Ivan/sandro: discussing namespace reservation...
18:57:35 <AxelPolleres> sandro: we need a resolution for that
18:58:28 <LeeF> PROPOSED: Request URIs of the form http://www.w3.org/ns/format/<foo> to represent graph formats and SPARQL XML and JSON result formats
18:58:37 <AxelPolleres> ivan: on andy's question for extensibility of formats such as TriG or N-Quads, that's not that simple.
18:58:40 <LeeF> PROPOSED: The SPARQL WG requests URIs of the form http://www.w3.org/ns/format/<foo> to represent graph formats and SPARQL XML and JSON result formats
18:59:10 <AxelPolleres> Andy: I was not asking for getting that in now, but just not to preclude that now. 
19:00:02 <AxelPolleres> Eric: we can't really do anything about the fact that ...
19:00:24 <AxelPolleres> (eric can you type that in, can't really follow the argument)
19:00:50 <LeeF> PROPOSED: The SPARQL WG requests URIs of the form http://www.w3.org/ns/format/<foo> to represent graph formats and SPARQL XML and JSON result formats
19:01:03 <ivan> +1
19:01:11 <AlexPassant> +1
19:01:17 <AxelPolleres> +1
19:01:30 <sandro> +1
19:01:34 <LeeF> RESOLVED: The SPARQL WG requests URIs of the form http://www.w3.org/ns/format/<foo> to represent graph formats and SPARQL XML and JSON result formats, no objections or abstentions
19:02:08 <AxelPolleres> ivan: scheme will be such that we can use non-graph formats as well
19:02:30 <AxelPolleres> ... N3 e.g. is not a standard, but there is a submission document, that'd work
19:02:47 <AlexPassant> ivan: got it thanks - http://www.w3.org/TeamSubmission/n3/
19:03:09 <AxelPolleres> sandro: as long as there's a stable spec for it, we're fine, practically.
19:03:37 <AxelPolleres> subtopic: vocabulary to describe datasets
19:03:45 <kasei> http://www.w3.org/2009/sparql/docs/service-description-1.1/xmlspec.xml
19:04:06 <AxelPolleres> greg: look at example in Section 4
19:04:26 <LeeF> http://www.w3.org/2009/sparql/docs/service-description-1.1/xmlspec.xml#id0x106c0320
19:04:48 <kasei> http://kasei.us/2009/09/sparql/sd-example.ttl
19:04:54 <AxelPolleres> http://www.w3.org/2009/sparql/docs/service-description-1.1/xmlspec.xml#id0x1f954840
19:05:35 <AxelPolleres> grep: explains the example.
19:05:43 <AxelPolleres> s/grep/greg/
19:06:45 <AxelPolleres> sandro: you're saying here that the name is the graph
19:07:04 <AxelPolleres> greg: two endpoints could have different local names for the same loaded graph
19:07:07 <sandro>             <sd:named rdf:resource="http://www.example/named-graph"/>
19:07:45 <AxelPolleres> greg: seems strange to me to put name in a string
19:08:03 <ivan> q+
19:08:18 <AxelPolleres> ... some pushback from people since these descriptions can get long.
19:08:29 <matt> matt has joined #sparql
19:08:33 <LeeF> q?
19:08:50 <LeeF> ack ivan 
19:09:13 <sandro> sandro: I have a problem with something have a "named" which is itself.      
19:09:28 <AxelPolleres> ivan: I wonder why you need a separate type for namedgraph and not just have a graph which happens to have a name property?
19:10:12 <ericP> re: name as a literal: careful, this is area in which sandro has been painfully vigilant in the past
19:11:16 <AxelPolleres> greg: we need to derefernce by which name you can query the graph. 
19:11:42 <sandro> Instead of     			sd:named <http://xmlns.com/foaf/0.1/> ;        say:        sd:name "http://xmlns.com/foaf/0.1/"              
19:11:45 <AxelPolleres> ivan: i would be more comfortable on the statement about a string, not about the resource itself.
19:12:16 <AxelPolleres> greg: ok, if there's consensus on that, but strange to me.
19:12:18 <sandro> sandro: you're providing the name of the thing, not the thing itself.
19:12:25 <LeeF> sdLnamed <foo> vs. sd:named "foo"^^xsd:anyUri 
19:12:26 <LeeF> ?
19:13:34 <AxelPolleres> 0 (string representation conceptually better, but needs conversion from string to resource if you want to use it?)
19:14:11 <AxelPolleres> sandro: I think you need to put it in a literal to stop someone saying wrong things about the resource.
19:14:43 <LeeF> ACTION: Sandro to work with Greg on an example to investigate what happens when multiple descriptions of the same graph are merged together
19:14:43 <trackbot> Created ACTION-213 - Work with Greg on an example to investigate what happens when multiple descriptions of the same graph are merged together [on Sandro Hawke - due 2010-04-02].
19:14:45 <AxelPolleres> subtopic: powder
19:15:40 <AxelPolleres> ivan: powder can be used in a practical deployment, our description of a big dataset would be lenghy, in powder you could do it in a few lines.
19:16:33 <AxelPolleres> ivan: powder extends the RDF semantcis to bridge resources and their names.
19:17:11 <AxelPolleres> leeF: does that mean we don't say something about the practicality of that form of descriptions for larger graphs/datasets?
19:17:21 <AxelPolleres> ivan: we could put some text in the document.
19:17:42 <ivan> s/some text/some informative text/
19:17:55 <sandro> sandro: just use sparql to query the vast sparql service description.
19:18:03 <AxelPolleres> LeeF: so the answer is we could use POWDER for a lot of things, but it's not the default.
19:18:13 <LeeF> http://www.w3.org/2009/sparql/track/issues/43
19:18:23 <AxelPolleres> subtopic: ISSUE-43
19:19:17 <AxelPolleres> greg: the way this is modeled at the moment allows us to say in the context of this endpoint entailment X applies to that graph.
19:19:34 <AxelPolleres> ... if we collapse the description, we loose that feature.
19:21:15 <AxelPolleres> ivan: fine, I just asked why two different types of graphs.
19:23:37 <AxelPolleres> in the graph we have entailmentRegime (per graph) and defaultEntailmentregime (for named graph), but at the moment we can't model specific entailment regime only for the default graph.
19:24:05 <AxelPolleres> Greg: the vocabulary doesn't say you can request entailment, but that it is done on that graph.
19:26:06 <AxelPolleres> greg: the only way that entailment regime helps you is to know which entailment is already done on it.
19:26:13 <AxelPolleres> ... one entailment per graph
19:26:23 <AxelPolleres> ivan: why? seems unnatural to me.
19:26:57 <AxelPolleres> souri: we support parametric inference, i.e. you can ask that graph with that entailment...
19:27:18 <AxelPolleres> q+
19:27:24 <bglimm> q+ to say that you could have different endpoints per entailment regime
19:27:40 <sandro>    G1 |= G2
19:27:52 <sandro> query G1 or G2 as you like
19:28:01 <LeeF> ack AxelPolleres
19:28:10 <sandro>    G1 |=owl G2     G1 |=rdfs G3
19:29:03 <SteveH> ...or http://foo.example/graph?entailment=owl
19:29:14 <AxelPolleres> what you could do is  allow FROM <g,simple> or  FROM <g,rdfs> ...
19:29:21 <sandro>    G1 |=owl G4   AND   G1 |=rdfs G4         G4 has both owl and rdfs.
19:30:05 <sandro> I want to be able to write down   "|=" in the service description.
19:30:23 <Souri> q?
19:30:29 <sandro> q+
19:30:35 <AxelPolleres> greg: we agreed not to describe how to reauest entailment
19:30:41 <LeeF> ack bglimm
19:30:41 <Zakim> bglimm, you wanted to say that you could have different endpoints per entailment regime
19:30:57 <AxelPolleres> ivan: the information of how you can query a graph is valuable
19:31:22 <kasei> [ a sd:Graph ; sd:preEntailmentGraph <g1> ; sd:entailmentRegime ent:DL ]
19:31:23 <AxelPolleres> birte: another solution is that you can set up several endpoints, with several regimes, user chooses
19:32:02 <AxelPolleres> (remark.... that is orthogonal to the entailment specific uris mentioned before)
19:32:28 <AndyS> We currently do one graph (name) = one entailment regime.  Most commonly, entailment and base data. They actually share same base data but you can't tell.
19:32:59 <Souri> q+
19:33:37 <AxelPolleres> birte: we only allow OWL, no parameterisation
19:33:38 <LeeF> ack sandro
19:33:40 <sandro> q-
19:33:44 <LeeF> ack souri
19:33:54 <AxelPolleres> steveH: we only support RDFS in threestore
19:34:10 <AxelPolleres> souri: what about user defined rules.
19:35:03 <AxelPolleres> axel: that should be possible with rif:imports
19:35:25 <AxelPolleres> LeeF: so, do we want advertisement of entailmentregime per graph?
19:35:49 <AxelPolleres> greg: seems simple to me to do that, but other issues mentioned are not SD's job for the moment
19:36:12 <AxelPolleres> birte: what if a graph has several entailment regimes?
19:36:23 <AxelPolleres> andy: cardinality 1 makes sense 
19:37:00 <LeeF> q?
19:37:03 <AlexPassant> what about sd:defaultEntailment ent:xx ; sd:entailementRegime ent:YY 
19:37:29 <matt> matt has left #sparql
19:38:03 <AxelPolleres> axel: use case for multiple entailment regimes... you can always advertise additionally any "weaker entailments" than the strongest one you do, as long as the entailments strcitly subsume each other.
19:38:42 <LeeF> ACTION: greg to add ability to mark individual graphs with their entailment regime
19:38:42 <trackbot> Created ACTION-214 - Add ability to mark individual graphs with their entailment regime [on Gregory Williams - due 2010-04-02].
19:38:51 <AxelPolleres> q?
19:40:03 <AxelPolleres> q?
19:40:05 <AxelPolleres> q+
19:41:00 <AxelPolleres> q+ to ask whether we will have time to discuss further planning/publication (we need to)
19:41:21 <LeeF> http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JanMar/0566.html
19:41:50 <AxelPolleres> LeeF: let's talk about further planning/publications rather on Tue in the next TC
19:42:01 <AxelPolleres> ... let's go around the table now.
19:42:06 <AndyS> Update: {?x foaf:knows{2} ?y}  as triple pattern rewrite may not be so easy
19:42:15 <AxelPolleres> david: not filled in enough
19:42:21 <AxelPolleres> ivan: same
19:43:04 <AxelPolleres> leeF: restriction to retrieve duplicates might not be the right thing, e.g. following foaf:knows 8 times over several paths.
19:43:21 <AxelPolleres> .... fine with negated properties, etc., N3 syntax, etc.
19:43:41 <AxelPolleres> Alex: agree with allow duplicates, not up to dates with cycles.
19:44:54 <AxelPolleres> Paul: loop, I was thinking it did match, but not several times
19:45:11 <AxelPolleres> Souri: no duplicates is not a concern, allow duplicates also fine.
19:45:39 <AxelPolleres> matt: repition of nodes difficult.
19:45:50 <AxelPolleres> sandro: not followed.
19:46:06 <AxelPolleres> greg: 0-length paths scare me.
19:46:12 <AlexPassant> AndyS: with no duplicates, SELECT COUNT(*) WHERE {?x foaf:knows{2} ?y} return 1, right ? (in the 1st example)
19:46:40 <AndyS> yes - think so
19:46:57 <AlexPassant> ok so Im definitely for allowing duplicate, seems more coherent in that count use case
19:47:09 <LeeF> distinct!
19:48:01 <AxelPolleres> ?s :p? ?o
19:49:56 <AxelPolleres> Axel: duplicates worry me
19:50:19 <AxelPolleres> (see sixDegrees eaxample in my mail, that would blow up tremendously if we have duplicates)
19:50:33 <AxelPolleres> steve: I am fine with Andy's proposal so far.
19:51:09 <AxelPolleres> andy: can't think about anyting else important at the moment.
19:51:41 <AxelPolleres> LeeF: eric is 98% done with the basic federated query spec. 
19:51:51 <AndyS> cool
19:51:53 <AxelPolleres> Andy: are there implications on protocol?
19:52:05 <sandro> RRSAgent, make logs public
19:52:09 <sandro> RRSAgent, pointer?
19:52:09 <RRSAgent> See http://www.w3.org/2010/03/26-sparql-irc#T19-52-09
19:52:38 <AxelPolleres> LeeF: we want to go on Tue to ask editors for how documents are affected, how far we are from last call, 
19:53:02 <AxelPolleres> ... let's discuss all where we are in terms of schedule, not focus on technical issues.
19:54:20 <AxelPolleres> LeeF: thanks all, thanks hosts, thanks scribes!!! talk on on Tuesday
19:54:31 <AxelPolleres> adjourned
19:54:51 <AxelPolleres> rrsagent, make records public
19:57:44 <AndyS> AndyS has left #sparql
20:01:23 <kasei> SELECT * WHERE { ?s :* ?o }
21:32:48 <AndyS> AndyS has joined #sparql
22:34:37 <AndyS> AndyS has joined #sparql
22:34:52 <AndyS> AndyS has left #sparql
22:37:05 <SteveH> SteveH has joined #sparql
23:36:31 <LeeF> LeeF has joined #sparql