12:01:44 <RRSAgent> logging to http://www.w3.org/2010/03/26-sparql-irc
RRSAgent IRC Bot: logging to http://www.w3.org/2010/03/26-sparql-irc ←
12:01:46 <trackbot> RRSAgent, make logs world
Trackbot IRC Bot: RRSAgent, make logs world ←
12:01:48 <trackbot> Zakim, this will be 77277
Trackbot IRC Bot: Zakim, this will be 77277 ←
12:01:48 <Zakim> ok, trackbot; I see SW_(SPARQLF2F)8:00AM scheduled to start now
Zakim IRC Bot: 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
Lee Feigenbaum: zakim, this will be SPARQL ←
12:01:49 <Zakim> ok, LeeF; I see SW_(SPARQLF2F)8:00AM scheduled to start now
Zakim IRC Bot: ok, LeeF; I see SW_(SPARQLF2F)8:00AM scheduled to start now ←
12:07:38 <LeeF> topic: SPARQL 1.1 Query
(No events recorded for 5 minutes)
12:07:43 <LeeF> subtopic: Aggregates
12:08:12 <kasei> scribenick: kasei
(Scribe set to Gregory Williams)
12:08:13 <AxelPolleres> http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JanMar/0499.html
Axel Polleres: http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JanMar/0499.html ←
12:08:38 <kasei> AxelPolleres: multiset proposal from AndyS
Axel Polleres: multiset proposal from AndyS ←
12:08:50 <kasei> ... examples in email.
... examples in email. ←
12:09:25 <kasei> SteveH: scribenick: LeeF
Steve Harris: scribenick: LeeF ←
12:09:28 <kasei> oops
oops ←
12:09:28 <LeeF> scribenick: LeeF
(Scribe set to Lee Feigenbaum)
12:10:02 <LeeF> SteveH: there are some things in the mail that needs discussion
Steve Harris: 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
...ignroe mail because it's out of line with the current spec ←
12:10:44 <LeeF> ...currently: aggregates take a list of expressions
...currently: aggregates take a list of expressions ←
12:10:48 <LeeF> ...evaluated with respect to the binding table
...evaluated with respect to the binding table ←
12:13:36 <LeeF> ...end up with an NxM list of values
...end up with an NxM list of values ←
12:13:41 <LeeF> ...gets passed to the aggregate value
...gets passed to the aggregate value ←
12:13:46 <LeeF> ...which returns scalar results
...which returns scalar results ←
12:14:00 <LeeF> ...doesn't usefully let you deal with multi-argument aggregates
...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
...Andy's proposal is that instead of producing a big multiset ←
12:14:17 <LeeF> ...you'd have a multiset of lists
...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
...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
Steve Harris: ?x = 1,2 ?y = 3, 4 ←
12:16:02 <SteveH> and AGG(?x, ?y)
Steve Harris: and AGG(?x, ?y) ←
12:16:02 <SteveH> gives AGG({(1, 3), (2, 4)})
Steve Harris: gives AGG({(1, 3), (2, 4)}) ←
12:17:07 <LeeF> LeeF: what's the alternative?
Lee Feigenbaum: what's the alternative? ←
12:17:12 <SteveH> {1, 3, 2, 4}
Steve Harris: {1, 3, 2, 4} ←
12:17:35 <LeeF> LeeF: definitely prefer Andy's proposal
Lee Feigenbaum: definitely prefer Andy's proposal ←
12:17:43 <SteveH> SteveH: me too
Steve Harris: me too [ Scribe Assist by Steve Harris ] ←
12:17:45 <LeeF> AndyS: works well for geospatial examples
Andy Seaborne: works well for geospatial examples ←
12:18:12 <LeeF> SteveH: complicates the definition of the set functions a bit
Steve Harris: complicates the definition of the set functions a bit ←
12:18:22 <LeeF> Axel: Seems to be consensus aorund this
Axel Polleres: Seems to be consensus aorund this ←
12:19:34 <LeeF> AxelPolleres: referring to ISSUE-3, how are errors and unbounds handled?
Axel Polleres: referring to ISSUE-3, how are errors and unbounds handled? ←
12:19:44 <LeeF> AxelPolleres: we need to decide per aggregate, right?
Axel Polleres: we need to decide per aggregate, right? ←
12:19:47 <LeeF> SteveH: not necessarily
Steve Harris: not necessarily ←
12:20:14 <LeeF> AxelPolleres: should we go through the list of aggregates?
Axel Polleres: 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
Steve Harris: 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
...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
...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?)
Andy Seaborne: 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.
Axel Polleres: evaluation of unbound leaves an error, so hard/impossible to distinguish. ←
12:22:31 <SteveH> ?x = 1, e ?y = 3, 4
Steve Harris: ?x = 1, e ?y = 3, 4 ←
12:22:31 <SteveH> and AGG(?x, ?y)
Steve Harris: and AGG(?x, ?y) ←
12:22:31 <SteveH> gives AGG({(1, e), (2, 4)})
Steve Harris: gives AGG({(1, e), (2, 4)}) ←
12:22:31 <SteveH> or AGG({(2, 4)}) + 1 error
Steve Harris: or AGG({(2, 4)}) + 1 error ←
12:23:03 <LeeF> SteveH: pretend e is something that evaluates to an error
Steve Harris: 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
...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
...or (e, e) as a value passed to the aggregate ←
12:23:33 <SteveH> or (e,e), (2,4)
Steve Harris: 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
Steve Harris: 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)
Birte Glimm: example should really be (1, 3) and (e, 4) ←
12:25:00 <AndyS> Correction : AGG({(1, 3), (e, 4)})
Andy Seaborne: Correction : AGG({(1, 3), (e, 4)}) ←
12:25:02 <LeeF> AxelPolleres: why is the number of errors important?
Axel Polleres: 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]
Andy Seaborne: 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
...lets you do COUNT(*) like things ←
12:26:05 <LeeF> AxelPolleres: is this helpful for extending aggregates?
Axel Polleres: is this helpful for extending aggregates? ←
12:26:06 <LeeF> AndyS: yes
Andy Seaborne: yes ←
12:26:17 <LeeF> AxelPolleres: multiset with errors in place conveys more information
Axel Polleres: 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
...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
Steve Harris: yes ←
12:26:55 <LeeF> AndyS: yes, but gives you uniform treatment of errors
Andy Seaborne: 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?
Axel Polleres: 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
Steve Harris: idea is to make all aggs behave in the same way ←
12:27:51 <LeeF> ...can alter behavior with, e.g., COALESCE
...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
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
Axel Polleres: would suggest different aggregates for different behavior ←
12:28:47 <LeeF> ack me
ack me ←
12:28:47 <Zakim> LeeF, you wanted to ask if Axel has a use case for needing the other behavior
Zakim IRC Bot: 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
Lee Feigenbaum: asks if Axel has a use case for the other behavior ←
12:29:35 <LeeF> AxelPolleres: No
Axel Polleres: No ←
12:29:45 <LeeF> LeeF: happy with the design that passes errors separately from the multiset of lists
Lee Feigenbaum: 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
Axel Polleres: 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?
Souripriya Das: do you have a concrete example? ←
12:32:21 <AxelPolleres> COUNT ( ?X ?Y )
Axel Polleres: COUNT ( ?X ?Y ) ←
12:32:21 <LeeF> ... perhaps COUNT with 2 columns
... perhaps COUNT with 2 columns ←
12:32:44 <LeeF> MattPerry: how does this effect the results of aggregates?
Matthew Perry: 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
Lee Feigenbaum: 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)
(way back up high) ←
12:34:01 <SteveH> ?a ?b
Steve Harris: ?a ?b ←
12:34:01 <SteveH> 1 2
Steve Harris: 1 2 ←
12:34:01 <SteveH> 3 A
Steve Harris: 3 A ←
12:34:01 <SteveH> COUNT(xsd:integer(?a), xsd:integer(?b))
Steve Harris: COUNT(xsd:integer(?a), xsd:integer(?b)) ←
12:34:02 <SteveH> COUNT({(1, 2)}, errors = 1
Steve Harris: COUNT({(1, 2)}, errors = 1 ←
12:34:25 <SteveH> answer : 2
Steve Harris: answer : 2 ←
12:34:41 <LeeF> IvanH: why would the answer be 2?
Ivan Herman: why would the answer be 2? ←
12:34:45 <LeeF> SteveH: the answer would be 1
Steve Harris: the answer would be 1 ←
12:34:59 <LeeF> s/SteveH: the answer would be 1/SteveH: because there are 2 elements
s/SteveH: the answer would be 1/SteveH: because there are 2 elements ←
12:35:04 <AxelPolleres> COUNT ( * ) here would be 2, yes?
Axel Polleres: COUNT ( * ) here would be 2, yes? ←
12:35:08 <LeeF> AndyS: I would expect the answer to be 1
Andy Seaborne: I would expect the answer to be 1 ←
12:35:16 <LeeF> bglimm: 1 results + 1 error row = 2 results
Birte Glimm: 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
Andy Seaborne: 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
Steve Harris: COUNT(*) is a completely special case ←
12:35:45 <AndyS> In SQL, it seems agg(any error) is error. agg of nulls is skipped.
Andy Seaborne: 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?
Matthew Perry: 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
Steve Harris: 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))
Andy Seaborne: 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
Lee Feigenbaum: 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?
Axel Polleres: would a row (e,e) be counted? ←
12:36:34 <LeeF> AndyS, yes, that's basically what I do :)
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
Andy Seaborne: 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)}
Steve Harris: COUNT({(1, 2)} ←
12:39:14 <AndyS> and the error count?
Andy Seaborne: and the error count? ←
12:39:16 <SteveH> + errors = 1
Steve Harris: + errors = 1 ←
12:39:43 <AxelPolleres> ?a ?b
Axel Polleres: ?a ?b ←
12:39:43 <AxelPolleres> 1 2
Axel Polleres: 1 2 ←
12:39:44 <AxelPolleres> 3 A
Axel Polleres: 3 A ←
12:39:44 <AxelPolleres> B C
Axel Polleres: B C ←
12:40:27 <LeeF> q+ to ask about relation to what happens to errors in solution set
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
Steve Harris: counting tuples seems to be what people expect ←
12:40:36 <SteveH> COUNT() will count the number of tuples
Steve Harris: COUNT() will count the number of tuples ←
12:40:45 <LeeF> AxelPolleres: COUNT only counts tuples without errors
Axel Polleres: COUNT only counts tuples without errors ←
12:40:54 <LeeF> AxelPolleres: special case is COUNT(*) which counts ...
Axel Polleres: special case is COUNT(*) which counts ... ←
12:40:57 <AndyS> COUNT(*) is special
Andy Seaborne: COUNT(*) is special ←
12:41:03 <LeeF> SteveH: it's defined as counting the number of rows in the solution set
Steve Harris: it's defined as counting the number of rows in the solution set ←
12:41:08 <AxelPolleres> q?
Axel Polleres: q? ←
12:41:12 <LeeF> ack me
ack me ←
12:41:12 <Zakim> LeeF, you wanted to ask about relation to what happens to errors in solution set
Zakim IRC Bot: 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
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
Lee Feigenbaum: 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
Andy Seaborne: we can define SELECT (1/0 AS ?X) differently - it's an independent decision - can go either way ←
12:44:58 <LeeF> ?a ?b
?a ?b ←
12:44:58 <LeeF> 1 2
1 2 ←
12:44:58 <LeeF> 3 A
3 A ←
12:44:59 <AxelPolleres> Do I get that right?
Axel Polleres: Do I get that right? ←
12:44:59 <AxelPolleres> ?a ?b
Axel Polleres: ?a ?b ←
12:45:00 <AxelPolleres> 1 2
Axel Polleres: 1 2 ←
12:45:00 <AxelPolleres> 3 A
Axel Polleres: 3 A ←
12:45:00 <AxelPolleres> B C
Axel Polleres: B C ←
12:45:00 <AxelPolleres> COUNT_Steve(?a ?b) -> 3
Axel Polleres: COUNT_Steve(?a ?b) -> 3 ←
12:45:02 <AxelPolleres> COUNT_Lee(?a ?b) -> 2
Axel Polleres: COUNT_Lee(?a ?b) -> 2 ←
12:45:04 <AxelPolleres> COUNT_Andy(?a ?b) -> 1
Axel Polleres: COUNT_Andy(?a ?b) -> 1 ←
12:45:24 <LeeF> q+ to work through my opinion over Axel's case
q+ to work through my opinion over Axel's case ←
12:45:48 <AxelPolleres> should be COUNT(xsd:integer(?a), xsd:integer(?b))
Axel Polleres: should be COUNT(xsd:integer(?a), xsd:integer(?b)) ←
12:45:49 <AndyS> q+
Andy Seaborne: q+ ←
12:46:05 <LeeF> SELECT (xsd:integer(?a) AS ?a_int) (xsd:integer(?b) AS ?b_int)
SELECT (xsd:integer(?a) AS ?a_int) (xsd:integer(?b) AS ?b_int) ←
12:46:35 <MattPerry> count(*) = 2, count(?x, ?y) = 1, right?
Matthew Perry: count(*) = 2, count(?x, ?y) = 1, right? ←
12:46:43 <LeeF> SELECT (COUNT(xsd:integer(?a), xsd:integer(?b)) ?count)
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
Lee Feigenbaum: would expect to COUNT to give me the number of rows from the former case that have at least one OK value ←
12:47:17 <LeeF> s/to COUNT/COUNT
s/to COUNT/COUNT ←
12:47:33 <LeeF> ack AndyS
ack AndyS ←
12:47:36 <LeeF> ack me
ack me ←
12:47:36 <Zakim> LeeF, you wanted to work through my opinion over Axel's case
Zakim IRC Bot: LeeF, you wanted to work through my opinion over Axel's case ←
12:47:44 <AxelPolleres> q?
Axel Polleres: q? ←
12:47:45 <LeeF> AndyS: we can decide either way what an error in the select expression does
Andy Seaborne: 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
... i thought the preference was to keep it unbound ←
12:48:01 <LeeF> ... so SELECT is not acting like a FILTER
... 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
Axel Polleres: 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
Axel Polleres: q+ to ask on what's the status of errors in SELECT expressions ←
12:48:32 <SteveH> q+
Steve Harris: q+ ←
12:48:38 <LeeF> AndyS: I don't see the need to align the two behaviors
Andy Seaborne: I don't see the need to align the two behaviors ←
12:49:11 <LeeF> ack SteveH
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
Steve Harris: 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
Andy Seaborne: ??example; SELECT ... HAVING COUNT(xsd:integer(?a), xsd:integer(?b)) > 0 ←
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
Lee Feigenbaum: 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)
... (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
Andy Seaborne: 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 :)
AndyS, yes, I can, it's not what my impl (or intuition) does though :) ←
12:52:07 <AxelPolleres> q?
Axel Polleres: q? ←
12:52:09 <LeeF> ack AxelPolleres
ack AxelPolleres ←
12:52:10 <Zakim> AxelPolleres, you wanted to ask on what's the status of errors in SELECT expressions
Zakim IRC Bot: AxelPolleres, you wanted to ask on what's the status of errors in SELECT expressions ←
12:52:11 <AxelPolleres> ack Axel
Axel Polleres: ack Axel ←
12:52:54 <LeeF> For me, the semantics of COUNT involve COUNTing rows that have _something_ in it
For me, the semantics of COUNT involve COUNTing rows that have _something_ in it ←
12:53:00 <LeeF> s/For me/LeeF: For me/
s/For me/LeeF: For me/ ←
12:53:05 <LeeF> Souri: that is like in SQL
Souripriya Das: that is like in SQL ←
12:53:36 <LeeF> ... it's like doing a COUNT(*) limited to the sliced multiset
... 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
... 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
Andy Seaborne: We coudl define COUNT(?x) as single arg only ←
12:53:54 <LeeF> LeeF: that's where my intuition comes from
Lee Feigenbaum: that's where my intuition comes from ←
12:53:58 <dcharbon2> q+
David Charboneau: q+ ←
12:54:22 <AxelPolleres> OPTION 1 : FILTER view, result = 1
Axel Polleres: OPTION 1 : FILTER view, result = 1 ←
12:54:23 <AxelPolleres> OPTION 2 : projection view, result = 3 (always the same as COUNT(*))
Axel Polleres: 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
Axel Polleres: OPTION 3 : count rows with at least one unbound, result =2 ←
12:54:31 <AxelPolleres> q?
Axel Polleres: q? ←
12:54:38 <LeeF> ack dcharbon
ack dcharbon ←
12:54:48 <LeeF> dcharbon2: tried to figure out what i thought the meaning of some of these results is
David Charboneau: 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(*) ??
Andy Seaborne: 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
... 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
... 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
Birte Glimm: 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:
Steve Harris: I think you can think of them options as: ←
12:55:57 <SteveH> COUNT(xsd:integer(?a) + xsd:integer(?b))
Steve Harris: COUNT(xsd:integer(?a) + xsd:integer(?b)) ←
12:55:57 <SteveH> COUNT(COALESCE(xsd:integer(?a), xsd:integer(?b)))
Steve Harris: COUNT(COALESCE(xsd:integer(?a), xsd:integer(?b))) ←
12:55:57 <SteveH> COUNT(1)
Steve Harris: COUNT(1) ←
12:56:03 <SteveH> not (1)...
Steve Harris: not (1)... ←
12:56:06 <SteveH> that's wrong
Steve Harris: 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
David Charboneau: 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
Lee Feigenbaum: that doesn't match my intuition, but I find dcharbon2's reasoning compelling ←
12:58:19 <kasei> q+
Gregory Williams: q+ ←
12:58:38 <LeeF> ack kasei
ack kasei ←
12:58:56 <LeeF> kasei: OPTION 1 does not count any row with an error anywhere in the tuple
Gregory Williams: 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?
Lee Feigenbaum: is this just errors, not unbounds? ←
12:59:24 <LeeF> SteveH: no it's the same, because eval(unbound) = error
Steve Harris: no it's the same, because eval(unbound) = error ←
12:59:34 <LeeF> LeeF: that's kind of weird to me
Lee Feigenbaum: that's kind of weird to me ←
12:59:42 <LeeF> SteveH: also not happy, but would be difficult to change
Steve Harris: 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
Andy Seaborne: 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
Birte Glimm: 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>
Lee Feigenbaum: <convinces himself that this is OK> ←
13:00:59 <AxelPolleres> PROPOSED: go for Option 1 on COUNT and allow multi-argument counts.
PROPOSED: go for Option 1 on COUNT and allow multi-argument counts. ←
13:01:04 <SteveH> +1
Steve Harris: +1 ←
13:01:20 <dcharbon2> +1
David Charboneau: +1 ←
13:01:22 <bglimm> +1
Birte Glimm: +1 ←
13:01:23 <ivan> +1
Ivan Herman: +1 ←
13:01:28 <Souri> 0
Souripriya Das: 0 ←
13:01:50 <pgearon> 0
Paul Gearon: 0 ←
13:01:57 <LeeF> AxelPolleres: With this approach, we don't need to introduce errors into our value system
Axel Polleres: 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
Andy Seaborne: OPTION 1 : error anywhere in tuple -> tupe not passed down (~whole tuple an error) ==> result = 1 ←
13:02:47 <MattPerry> q+
Matthew Perry: 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.
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
Birte Glimm: +1 ←
13:03:20 <SteveH> +1
Steve Harris: +1 ←
13:03:21 <dcharbon2> +1
David Charboneau: +1 ←
13:03:22 <AndyS> +1
Andy Seaborne: +1 ←
13:03:27 <LeeF> MattPerry: does this mean that for the purpose of aggregates, unbound and error are the same thing?
Matthew Perry: does this mean that for the purpose of aggregates, unbound and error are the same thing? ←
13:03:30 <LeeF> AxelPolleres: yes
Axel Polleres: yes ←
13:03:33 <MattPerry> +1
Matthew Perry: +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.
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
Souri abstaining ←
13:05:14 <LeeF> AxelPolleres: other aggregates?
Axel Polleres: 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
Steve Harris: 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 ?
Axel Polleres: 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
Andy Seaborne: 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/???/
s/with errors/???/ ←
13:06:13 <AxelPolleres> rermaining aggregates SUM, MIN, MAX, AVG, GROUP_CONCAT, and SAMPLE
Axel Polleres: rermaining aggregates SUM, MIN, MAX, AVG, GROUP_CONCAT, and SAMPLE ←
13:06:46 <SteveH> Definition : Sum
Steve Harris: Definition : Sum ←
13:06:47 <SteveH> The Sum aggregate function is used by the SUM function in the syntax.
Steve Harris: 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:
Steve Harris: 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
Steve Harris: Sum(S) = op:numeric-add(S0, Sum(S1..n)) when |S| > 1 ←
13:06:47 <SteveH> Sum(S) = S0 when |S| = 1
Steve Harris: Sum(S) = S0 when |S| = 1 ←
13:06:47 <SteveH> Sum(S) = 0 when |S| = 0
Steve Harris: 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)).
Steve Harris: 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
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
Matthew Perry: ack me ←
13:07:55 <LeeF> ack me
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
Zakim IRC Bot: 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?
Gregory Williams: so you can Sum over a single bnode? ←
13:07:59 <Zakim> ... count of such excluded errors is passed to the aggregate function
Zakim IRC Bot: ... count of such excluded errors is passed to the aggregate function ←
13:08:20 <SteveH> kasei, good point
Steve Harris: 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
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
SUM(_:haha) = _:haha ←
13:09:37 <AxelPolleres> +
Axel Polleres: + ←
13:09:38 <sandro> maybe SUM(X) is X-X+X :-)
Sandro Hawke: maybe SUM(X) is X-X+X :-) ←
13:09:38 <AxelPolleres> +1
Axel Polleres: +1 ←
13:09:47 <kasei> Sum(S) = op:numeric-add(S0, 0) when |S| = 1
Gregory Williams: 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
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)
Steve Harris: 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
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
Axel Polleres: close ISSUE-53 ←
13:11:04 <trackbot> ISSUE-53 How are unbounds and errors treated in aggregate evaluation? closed
Trackbot IRC Bot: 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
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
Trackbot IRC Bot: 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
Axel Polleres: (1) any non-numeric value in SUM is not considered ←
13:12:00 <LeeF> ... (2) do we allow multi-argument SUM?
... (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
Steve Harris: my temptation is to sum over the tuple and then sum the sums ←
13:12:30 <LeeF> LeeF: that's what I do
Lee Feigenbaum: that's what I do ←
13:13:03 <Souri> q+
Souripriya Das: q+ ←
13:13:04 <AxelPolleres> multi-argument SUM to be defined in the straightforward way, i.e. sum arguments
Axel Polleres: multi-argument SUM to be defined in the straightforward way, i.e. sum arguments ←
13:13:19 <AxelPolleres> ?
Axel Polleres: ? ←
13:13:34 <LeeF> ack Souri
ack Souri ←
13:13:51 <AxelPolleres> q+ to ask whether we need that at all
Axel Polleres: 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
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.
Axel Polleres: SUM ( ?X ?Y ) = SUM (?X+?Y ... same amount of characters. ←
13:14:38 <SteveH> ?a ?b
Steve Harris: ?a ?b ←
13:14:38 <SteveH> 1 2
Steve Harris: 1 2 ←
13:14:38 <SteveH> 3 A
Steve Harris: 3 A ←
13:14:38 <SteveH> SUM(?a, ?b) = 3
Steve Harris: SUM(?a, ?b) = 3 ←
13:14:50 <kasei> q+
Gregory Williams: q+ ←
13:15:06 <Souri> sum(?a+?b) vs sum(?a,?b) ?
Souripriya Das: 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?
Gregory Williams: 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...?
Gregory Williams: dropping a pair vs. dropping a single element...? ←
13:16:20 <Souri> do we need multi-arg sum ?
Souripriya Das: do we need multi-arg sum ? ←
13:16:26 <kasei> ignore me. LeeF caught me up, but it brings up another issue.
Gregory Williams: ignore me. LeeF caught me up, but it brings up another issue. ←
13:16:26 <kasei> q-
Gregory Williams: q- ←
13:17:07 <AxelPolleres> ack Axel
Axel Polleres: ack Axel ←
13:17:07 <Zakim> AxelPolleres, you wanted to ask whether we need that at all
Zakim IRC Bot: AxelPolleres, you wanted to ask whether we need that at all ←
13:17:19 <kasei> +1 Souri
Gregory Williams: +1 Souri ←
13:17:45 <SteveH> happy to have SUM() syntactically limited to a single argument
Steve Harris: happy to have SUM() syntactically limited to a single argument ←
13:18:03 <MattPerry> +1 single argument SUM() only
Matthew Perry: +1 single argument SUM() only ←
13:18:08 <LeeF> SELECT (SUM(?fingerLength, ?toeLength) AS ?sum) {
SELECT (SUM(?fingerLength, ?toeLength) AS ?sum) { ←
13:18:08 <LeeF> { ?person :fingerLength ?fingerLength }
{ ?person :fingerLength ?fingerLength } ←
13:18:08 <LeeF> UNION
UNION ←
13:18:08 <LeeF> { ?person :toeLength ?toeLength}
{ ?person :toeLength ?toeLength} ←
13:18:08 <LeeF> }
} ←
13:18:30 <LeeF> LeeF: the above use case ends up passing nothing at all to SUM
Lee Feigenbaum: the above use case ends up passing nothing at all to SUM ←
13:18:37 <LeeF> ... because every tuple has an unbound variable
... because every tuple has an unbound variable ←
13:18:38 <kasei> LeeF, I was just thinking of summing on OPTIONAL ?age.
Gregory Williams: LeeF, I was just thinking of summing on OPTIONAL ?age. ←
13:18:39 <LeeF> ... which turns into an error
... which turns into an error ←
13:19:27 <kasei> SELECT (SUM(COALESCE(?fingerLength,0), COALESCE(?toeLength,0)) AS ?sum) ...
Gregory Williams: SELECT (SUM(COALESCE(?fingerLength,0), COALESCE(?toeLength,0)) AS ?sum) ... ←
13:19:51 <AxelPolleres> q?
Axel Polleres: q? ←
13:19:56 <AxelPolleres> ack LeeF
Axel Polleres: ack LeeF ←
13:19:56 <Zakim> LeeF, you wanted to wonder if our resolution to ISSUE-53 makes multi-argument SUM act weird
Zakim IRC Bot: LeeF, you wanted to wonder if our resolution to ISSUE-53 makes multi-argument SUM act weird ←
13:21:07 <AndyS> q+
Andy Seaborne: q+ ←
13:21:52 <LeeF> ack AndyS
ack AndyS ←
13:22:00 <LeeF> AndyS: you can also do it by passing the sum into the union
Andy Seaborne: you can also do it by passing the sum into the union ←
13:22:11 <LeeF> ...by using the same variable
...by using the same variable ←
13:22:32 <Souri> +1
Souripriya Das: +1 ←
13:22:36 <LeeF> AxelPolleres: can we just keep SUM as a single argument aggregate?
Axel Polleres: 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
Steve Harris: don't see a reason to, but won't object ←
13:22:56 <AndyS> +0
Andy Seaborne: +0 ←
13:23:01 <LeeF> AxelPolleres: would anyone object to multi-argument SUM?
Axel Polleres: would anyone object to multi-argument SUM? ←
13:23:03 <LeeF> Souri: I would.
Souripriya Das: I would. ←
13:23:04 <SteveH> +0
Steve Harris: +0 ←
13:23:19 <LeeF> AxelPolleres: Suggest based on this we keep SUM as single argument.
Axel Polleres: Suggest based on this we keep SUM as single argument. ←
13:23:40 <AxelPolleres> PROPOSED: keep SUM as a single argument aggregate, no SUM(*)
PROPOSED: keep SUM as a single argument aggregate, no SUM(*) ←
13:23:44 <pgearon> +1
Paul Gearon: +1 ←
13:23:47 <MattPerry> +1
Matthew Perry: +1 ←
13:23:50 <AndyS> 0
Andy Seaborne: 0 ←
13:23:53 <AlexPassant> +1
Alexandre Passant: +1 ←
13:23:54 <SteveH> 0
Steve Harris: 0 ←
13:23:56 <LeeF> abstain
abstain ←
13:24:01 <Souri> +1
Souripriya Das: +1 ←
13:24:52 <AxelPolleres> RESOLVED: keep SUM as a single argument aggregate, no SUM(*), 3 abstain, no objections
RESOLVED: keep SUM as a single argument aggregate, no SUM(*), 3 abstain, no objections ←
13:25:12 <SteveH> Definition : Min
Steve Harris: 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.
Steve Harris: 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
Steve Harris: Min(S) = S0 ←
13:25:40 <LeeF> SteveH: believe this came out of difficulty coming up with something at F2F2
Steve Harris: 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
Lee Feigenbaum: 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
Steve Harris: can meet most use cases with casting and coalesce ←
13:27:59 <SteveH> so, MIN({(1, 2), (3, 4)} = MIN({1, 2, 3, 4})
Steve Harris: 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() ?
Gregory Williams: 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.
Gregory Williams: I support multi-arg, but want to understand the options. ←
13:30:17 <SteveH> MIN(?x, COALESCE(?y, ?x))
Steve Harris: 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
Lee Feigenbaum: Notes that passing in tuples with error in val slot allows each aggregate to decide [ Scribe Assist by Andy Seaborne ] ←
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
Lee Feigenbaum: 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))
Axel Polleres: MIN(COALESCE(?x,?y, ?z), COALESCE(?y, ?z, ?x) COALESCE(?z, ?x ?y)) ←
13:31:38 <kasei> q+ to get clarification from SteveH
Gregory Williams: q+ to get clarification from SteveH ←
13:32:21 <SteveH> MIN(min(?x, ?y)) also works when ?x and ?y are numbers
Steve Harris: 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
Andy Seaborne: 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/
Steve Harris: s/min/fn:min/ ←
13:32:53 <kasei> is fn:min a thing?
Gregory Williams: is fn:min a thing? ←
13:33:01 <pgearon> it is for me
Paul Gearon: 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
Steve Harris: I believe that multiargument MIN inwhich one of the variables is sometimes unbound is a corner case ←
13:33:05 <LeeF> LeeF: Granted
Lee Feigenbaum: Granted ←
13:33:06 <AndyS> function fn:min comes from F&O
Andy Seaborne: function fn:min comes from F&O ←
13:33:14 <LeeF> s/inwhich/in which/
s/inwhich/in which/ ←
13:33:15 <AndyS> IIRC
Andy Seaborne: IIRC ←
13:33:23 <kasei> right, but it's not a standard yet...?
Gregory Williams: right, but it's not a standard yet...? ←
13:33:32 <pgearon> +q
Paul Gearon: +q ←
13:33:40 <AndyS> (actually it takes sequence? - rat hole)
Andy Seaborne: (actually it takes sequence? - rat hole) ←
13:34:09 <LeeF> AxelPolleres: (1) only allow single arugment MIN (2) reconsider resolution to ISSUE-53
Axel Polleres: (1) only allow single arugment MIN (2) reconsider resolution to ISSUE-53 ←
13:34:15 <AxelPolleres> q?
Axel Polleres: q? ←
13:34:18 <LeeF> ack kasei
ack kasei ←
13:34:18 <Zakim> kasei, you wanted to get clarification from SteveH
Zakim IRC Bot: 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?
Gregory Williams: 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
Steve Harris: my use cases involve not knowing the type of the values involved ←
13:35:44 <AxelPolleres> greg says, you can use "<" + IF?
Axel Polleres: greg says, you can use "<" + IF? ←
13:36:04 <AxelPolleres> leeF: ORDER BY is more powerful than "<"
Lee Feigenbaum: ORDER BY is more powerful than "<" [ Scribe Assist by Axel Polleres ] ←
13:36:16 <SteveH> _:b < "foo"
Steve Harris: _:b < "foo" ←
13:36:51 <AndyS> _:b < "foo" is an error : ORDER will give _:b before "foo"
Andy Seaborne: _:b < "foo" is an error : ORDER will give _:b before "foo" ←
13:37:00 <LeeF> ack pgearon
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?
Paul Gearon: 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
Andy Seaborne: 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
... 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?
Axel Polleres: how would people feel about re-opening ISSUE-53 to pass errors to the aggregates? ←
13:41:39 <LeeF> q?
q? ←
13:41:41 <LeeF> q+
q+ ←
13:41:51 <LeeF> ... COUNT would be defined to exclude thoes
... COUNT would be defined to exclude thoes ←
13:41:56 <LeeF> ... MIN and MAX would exclude just those values
... MIN and MAX would exclude just those values ←
13:43:03 <LeeF> ack me
ack me ←
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
Lee Feigenbaum: 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?
Gregory Williams: 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
Andy Seaborne: 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
Steve Harris: we'd also need a token for the unbound variable ←
13:44:53 <AxelPolleres> -.05 on introducing NULL in SPARQL
Axel Polleres: -.05 on introducing NULL in SPARQL ←
13:45:58 <AndyS> ?x and ?x+0 (?x always a number or unbound) are then different
Andy Seaborne: ?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
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?
Axel Polleres: 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
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
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
Axel Polleres: notes conensus around multiargument MIN and MAX ←
13:50:26 <SteveH> SUM() will flatten the tuples, and apply ORDER BY semantics over the list
Steve Harris: SUM() will flatten the tuples, and apply ORDER BY semantics over the list ←
13:50:43 <LeeF> s/SUM/MIN
s/SUM/MIN ←
13:50:48 <SteveH> s/SUM/MIN and MAX()/
Steve Harris: s/SUM/MIN and MAX()/ ←
13:51:07 <AxelPolleres> AVG, GROUP_CONCAT, and SAMPLE
Axel Polleres: AVG, GROUP_CONCAT, and SAMPLE ←
13:51:08 <SteveH> Definition : Avg
Steve Harris: Definition : Avg ←
13:51:09 <SteveH> Avg(M) = Sum(M) / Count(M)
Steve Harris: Avg(M) = Sum(M) / Count(M) ←
13:51:27 <LeeF> OK with me
OK with me ←
13:51:59 <LeeF> AxelPolleres: this would limit us to single argument AVG
Axel Polleres: this would limit us to single argument AVG ←
13:52:07 <LeeF> SteveH: potentially a reason for multiargument SUM
Steve Harris: potentially a reason for multiargument SUM ←
13:52:16 <SteveH> implies that AVG() is single argument too
Steve Harris: implies that AVG() is single argument too ←
13:52:20 <LeeF> bglimm: or an argument for all single argument aggregates!
Birte Glimm: or an argument for all single argument aggregates! ←
13:52:27 <LeeF> AndyS: what about lots of zeroes?
Andy Seaborne: what about lots of zeroes? ←
13:52:27 <SteveH> need special case for |M| = 0
Steve Harris: need special case for |M| = 0 ←
13:53:02 <AxelPolleres> div by 0 is just an error, no special case needed.
Axel Polleres: div by 0 is just an error, no special case needed. ←
13:53:12 <SteveH> Definition : GroupConcat
Steve Harris: Definition : GroupConcat ←
13:53:12 <SteveH> The multiset of values passed as an argument is converted to a sequence S.
Steve Harris: 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)
Steve Harris: GroupConcat(S) = fn:string-join(S, sep) ←
13:53:44 <SteveH> sep is currently suggested as " ", but ", " is better
Steve Harris: sep is currently suggested as " ", but ", " is better ←
13:54:15 <SteveH> we have a proposal for more syntax: GROUP_CONCAT["|"](?x)
Steve Harris: we have a proposal for more syntax: GROUP_CONCAT["|"](?x) ←
13:54:20 <kasei> AndyS, do you want GROUPCONCAT or something else?
Gregory Williams: 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
Andy Seaborne: kasei, yes - I'd write a GroupConcat as I write isIRI but case insensitive keywords ←
13:55:25 <sandro> ☃
Sandro Hawke: ☃ ←
13:56:30 <SteveH> 2nd alt. GROUP_CONCAT[seperator="|"](?x)
Steve Harris: 2nd alt. GROUP_CONCAT[seperator="|"](?x) ←
13:57:17 <dcharbon2> SEPARATOR("|",GROUP_CONCAT(?x))
David Charboneau: SEPARATOR("|",GROUP_CONCAT(?x)) ←
13:57:24 <SteveH> 2nd alt. GROUP_CONCAT[seperator="|", order_by="desc"](?x)
Steve Harris: 2nd alt. GROUP_CONCAT[seperator="|", order_by="desc"](?x) ←
13:57:49 <kasei> on consideration, I think I like Andy's GroupConcat
Gregory Williams: on consideration, I think I like Andy's GroupConcat ←
13:58:04 <bglimm> Why not GROUP_CONCAT(?s, "|")
Birte Glimm: Why not GROUP_CONCAT(?s, "|") ←
13:58:07 <dcharbon2> scratch mine, I don't like it
David Charboneau: scratch mine, I don't like it ←
13:58:16 <AxelPolleres> GROUP_CONCAT("|")[?x]
Axel Polleres: GROUP_CONCAT("|")[?x] ←
13:58:25 <AxelPolleres> MIN[?X] ...
Axel Polleres: MIN[?X] ... ←
13:58:31 <dcharbon2> require the separator and place it as the first arg
David Charboneau: require the separator and place it as the first arg ←
13:58:32 <AxelPolleres> SUM[?X] ....
Axel Polleres: SUM[?X] .... ←
13:58:33 <AndyS> Custom agg example?
Andy Seaborne: Custom agg example? ←
13:58:42 <SteveH> custom:agg[?x]
Steve Harris: custom:agg[?x] ←
14:00:10 <AndyS> q+
Andy Seaborne: q+ ←
14:00:18 <kasei> SUM«?x» :)
Gregory Williams: SUM«?x» :) ←
14:01:05 <LeeF> AxelPolleres: what about square brackets for all aggregates?
Axel Polleres: what about square brackets for all aggregates? ←
14:02:13 <AxelPolleres> ivan, steveH: people expect to see '(' ')' for aggregates.
Axel Polleres: ivan, steveH: people expect to see '(' ')' for aggregates. ←
14:02:26 <SteveH> custom:agg[](?x)
Steve Harris: custom:agg[](?x) ←
14:02:56 <AndyS> or custom:agg[?x]
Andy Seaborne: or custom:agg[?x] ←
14:03:03 <ivan> group_concate[","](asfasfa)
Ivan Herman: group_concate[","](asfasfa) ←
14:03:07 <kasei> i like the idea of supporting order_by, also, though.
Gregory Williams: i like the idea of supporting order_by, also, though. ←
14:03:43 <LeeF> GROUP_CONCAT(x SEPARATOR ",")
GROUP_CONCAT(x SEPARATOR ",") ←
14:03:49 <kasei> q+
Gregory Williams: q+ ←
14:03:57 <AxelPolleres> q+ to claim that GROUP_CONCAT(?x "|") would work
Axel Polleres: q+ to claim that GROUP_CONCAT(?x "|") would work ←
14:04:03 <ivan> sandro's idea: group_concat(a,b,c,separator=",')
Ivan Herman: sandro's idea: group_concat(a,b,c,separator=",') ←
14:04:24 <dcharbon2> +1 to group_concat(a,b,c,separator=",")
David Charboneau: +1 to group_concat(a,b,c,separator=",") ←
14:04:26 <sandro> I like the keyword better than the square brackets.
Sandro Hawke: I like the keyword better than the square brackets. ←
14:04:26 <LeeF> ack AndyS
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
Andy Seaborne: 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
David Charboneau: 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), ",")
Sandro Hawke: group_concat(list(a,b,c), ",") ←
14:05:30 <SteveH> group_concat(a,b,c separator=",") is nicer IMHO
Steve Harris: group_concat(a,b,c separator=",") is nicer IMHO ←
14:05:48 <AxelPolleres> q?
Axel Polleres: q? ←
14:06:03 <LeeF> ack kasei
ack kasei ←
14:06:17 <AndyS> GroupConcat(?a,?b,?c [",",true]) # true is order desc
Andy Seaborne: 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
Gregory Williams: 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?
Axel Polleres: q? ←
14:06:53 <AxelPolleres> GROUP_CONCAT(?x "|")
Axel Polleres: GROUP_CONCAT(?x "|") ←
14:07:17 <AndyS> q+
Andy Seaborne: q+ ←
14:07:34 <AndyS> ack AxelPolleres
Andy Seaborne: ack AxelPolleres ←
14:07:34 <Zakim> AxelPolleres, you wanted to claim that GROUP_CONCAT(?x "|") would work
Zakim IRC Bot: 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.)
Sandro Hawke: (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.
Gregory Williams: 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)
Steve Harris: GROUP_CONCAT[seperator="|", order_by="desc"](?x) ←
14:08:40 <SteveH> or GROUP_CONCAT["|", "desc"](?x)
Steve Harris: or GROUP_CONCAT["|", "desc"](?x) ←
14:09:06 <MattPerry> can't you just do ORDER BY on a subquery and then GROUP_CONCAT that
Matthew Perry: can't you just do ORDER BY on a subquery and then GROUP_CONCAT that ←
14:09:16 <SteveH> MattPerry, yeah, you can
Steve Harris: MattPerry, yeah, you can ←
14:09:22 <sandro> I'm very happy with named arguments, but maybe that's because I use python.
Sandro Hawke: 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
Steve Harris: 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
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
Steve Harris: LeeF, +1 ←
14:10:12 <AxelPolleres> GROUP_CONCAT["|" "desc"](?x)
Axel Polleres: 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 :)
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.)
Sandro Hawke: 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
Andy Seaborne: q+ to speak about names ←
14:11:28 <AxelPolleres> I like sandros GROUP_CONCAT(a,b,c;d,e,f) ;
Axel Polleres: I like sandros GROUP_CONCAT(a,b,c;d,e,f) ; ←
14:11:39 <LeeF> ack AndyS
ack AndyS ←
14:11:39 <Zakim> AndyS, you wanted to speak about names
Zakim IRC Bot: AndyS, you wanted to speak about names ←
14:11:44 <AxelPolleres> q?
Axel Polleres: q? ←
14:12:13 <kasei> q+
Gregory Williams: q+ ←
14:12:51 <LeeF> q+ to add propose that we not include GROUP_CONCAT in SPARQL 1.1 Query
q+ to add propose that we not include GROUP_CONCAT in SPARQL 1.1 Query ←
14:13:06 <AxelPolleres> break
Axel Polleres: break ←
14:13:11 <AndyS> Arbitrary keywords make tokenizing hard :: select= ...
Andy Seaborne: 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.
Sandro Hawke: 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
(No events recorded for 12 minutes)
I'm not sure if it's on our agenda, but I think we ought to discuss the semantics of grouping by expressions ←
14:44:56 <AndyS> Nice trick: use query string to URIs for custom aggs <http://foo/agg?sep=,>(?x, ?y)
(No events recorded for 15 minutes)
Andy Seaborne: 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)
Axel Polleres: OPTION 1: agree on separation between two argument lists (Agg, Func) ←
14:45:15 <AxelPolleres> OPTION 1.1: agg[Func](Agg) - steveH1
Axel Polleres: OPTION 1.1: agg[Func](Agg) - steveH1 ←
14:45:15 <AxelPolleres> OPTION 1.2: agg(Agg; Func) - sandro1
Axel Polleres: 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)
Axel Polleres: 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
Axel Polleres: OPTION 1.3: agg(Agg FuncNamed) - sandro2 ←
14:45:16 <AxelPolleres> OPTION 2: drop functionally parametrises Aggs at all
Axel Polleres: 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)
Axel Polleres: 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.
Andy Seaborne: 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
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/
Axel Polleres: s/OPTION 1.3: agg(Agg FuncNamed) - sandro2/OPTION 1.4: agg(Agg FuncNamed) - sandro2/ ←
14:49:03 <LeeF> scribenick: AlexPassant
(Scribe set to Alexandre Passant)
14:50:38 <AxelPolleres> OPTION2.3: GROUP Concat with fixed separator
Axel Polleres: OPTION2.3: GROUP Concat with fixed separator ←
14:52:12 <AxelPolleres> once again all options...
Axel Polleres: once again all options... ←
14:52:13 <AxelPolleres> OPTION 1: agree on separation between two argument lists (Agg, Func)
Axel Polleres: OPTION 1: agree on separation between two argument lists (Agg, Func) ←
14:52:14 <AxelPolleres> OPTION 1.1: agg[Func](Agg) - steveH1
Axel Polleres: OPTION 1.1: agg[Func](Agg) - steveH1 ←
14:52:14 <AxelPolleres> OPTION 1.2: agg(Agg; Func) - sandro1
Axel Polleres: 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)
Axel Polleres: 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
Axel Polleres: OPTION 1.4: agg(Agg FuncNamed) - sandro2 ←
14:52:16 <AxelPolleres> OPTION 2: drop functionally parametrises Aggs at all
Axel Polleres: 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 )
Axel Polleres: 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
Axel Polleres: OPTION 2.2: omit GROUP_CONCAT from SPARQL 1.1 Query ←
14:52:23 <AxelPolleres> OPTION 2.3: GROUP_CONCAT with fixed separator
Axel Polleres: OPTION 2.3: GROUP_CONCAT with fixed separator ←
14:55:05 <AxelPolleres> Andy, steveH discussing parsing/grammar of FuncNamed
Axel Polleres: Andy, steveH discussing parsing/grammar of FuncNamed ←
14:55:26 <AlexPassant> AxelPolleres: Summary of options
Axel Polleres: Summary of options ←
14:55:46 <AlexPassant> ... overall design decision
... overall design decision ←
14:55:55 <AlexPassant> ... allow or not extra functional arguments
... allow or not extra functional arguments ←
14:55:59 <AlexPassant> ... option 1 and 2
... option 1 and 2 ←
14:56:02 <AlexPassant> ... + suboptions
... + suboptions ←
14:56:25 <AlexPassant> ... any objection re. we need the fonctional parameter
... any objection re. we need the fonctional parameter ←
14:56:37 <AlexPassant> ivan: we need it
Ivan Herman: we need it ←
14:56:37 <pgearon> I object to option 2
Paul Gearon: I object to option 2 ←
14:56:47 <LeeF> pgearon, why?
Lee Feigenbaum: pgearon, why? ←
14:56:49 <AlexPassant> ... limites use if we dont have it
... limites use if we dont have it ←
14:56:58 <LeeF> 2.2!
Lee Feigenbaum: 2.2! ←
14:57:07 <AlexPassant> ... option 2 only if 2.2
... option 2 only if 2.2 ←
14:57:26 <AxelPolleres> q?
Axel Polleres: q? ←
14:57:29 <LeeF> ack kasei
Lee Feigenbaum: ack kasei ←
14:57:30 <AlexPassant> AxelPolleres: agreement on the suboptions ?
Axel Polleres: agreement on the suboptions ? ←
14:57:33 <sandro> q?
Sandro Hawke: 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
Paul Gearon: 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
Lee Feigenbaum: ack LeeF ←
14:57:34 <Zakim> LeeF, you wanted to add propose that we not include GROUP_CONCAT in SPARQL 1.1 Query
Zakim IRC Bot: 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
Lee Feigenbaum: designing new stuff that we have not done yet ←
14:57:55 <SteveH> q+
Steve Harris: q+ ←
14:58:02 <kasei> q+
Gregory Williams: q+ ←
14:58:02 <AlexPassant> ... group_contact extremely useful but dont know the degree of extensibility
... group_contact extremely useful but dont know the degree of extensibility ←
14:58:12 <AlexPassant> ... maybe should not do it
... maybe should not do it ←
14:58:23 <AlexPassant> SteveH: disagree with LeeF and ivan
Steve Harris: disagree with LeeF and ivan ←
14:58:31 <AlexPassant> ... useful and stupid not to have it
... useful and stupid not to have it ←
14:58:47 <AlexPassant> ... would lead to lots of incompatible implementation if not standardised
... would lead to lots of incompatible implementation if not standardised ←
14:59:07 <AxelPolleres> q?
Axel Polleres: q? ←
14:59:13 <AxelPolleres> ack SteveH
Axel Polleres: ack SteveH ←
14:59:22 <AlexPassant> LeeF: fixed sep not a good idea
Lee Feigenbaum: 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.
Sandro Hawke: q+ to argue that named arguments are extensible, and just put them at the end. ←
14:59:34 <AlexPassant> ... ', ' if fixed separater
... ', ' if fixed separater ←
14:59:47 <AlexPassant> ... but still get implementations changing it to make it useful
... but still get implementations changing it to make it useful ←
15:00:19 <AlexPassant> kasei: extensions will have this need
Gregory Williams: extensions will have this need ←
15:00:32 <AlexPassant> ... encouraging implementations to pursue on their own
... encouraging implementations to pursue on their own ←
15:00:44 <AlexPassant> LeeF: different approaches, but will learn from it for next time
Lee Feigenbaum: different approaches, but will learn from it for next time ←
15:01:00 <AlexPassant> ivan: not talking about something really complex
Ivan Herman: not talking about something really complex ←
15:01:08 <AlexPassant> ... all prog. languages have it
... all prog. languages have it ←
15:01:10 <AxelPolleres> objections to OPTION 2.3 Lee, Greg ? objection to OPTION 2.2 Steveh?
Axel Polleres: objections to OPTION 2.3 Lee, Greg ? objection to OPTION 2.2 Steveh? ←
15:01:11 <AlexPassant> ... trivial detail
... trivial detail ←
15:01:24 <AxelPolleres> q?
Axel Polleres: q? ←
15:01:26 <AlexPassant> ... would generally be happy with any suboption
... would generally be happy with any suboption ←
15:01:33 <AlexPassant> LeeF: disagree - not trivial
Lee Feigenbaum: disagree - not trivial ←
15:01:38 <AxelPolleres> q?
Axel Polleres: q? ←
15:01:57 <AxelPolleres> ack kasei
Axel Polleres: ack kasei ←
15:01:58 <AlexPassant> kasei: ivan summarised my point
Gregory Williams: ivan summarised my point ←
15:02:17 <AlexPassant> ... clearly needed, fairly simple thing
... clearly needed, fairly simple thing ←
15:02:23 <AlexPassant> ... issue is syntax based
... issue is syntax based ←
15:02:25 <ivan> ack kasei
Ivan Herman: ack kasei ←
15:02:57 <SteveH> q+
Steve Harris: q+ ←
15:03:08 <AlexPassant> pgearon: semantics is straightforward
Paul Gearon: semantics is straightforward ←
15:03:11 <ivan> ack sandro
Ivan Herman: ack sandro ←
15:03:11 <Zakim> sandro, you wanted to argue that named arguments are extensible, and just put them at the end.
Zakim IRC Bot: 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
... concern is the syntax ←
15:03:28 <AlexPassant> sandro: keyword argument is straightforward
Sandro Hawke: keyword argument is straightforward ←
15:03:31 <AlexPassant> ... cf python
... cf python ←
15:03:37 <AlexPassant> ... extensibility: dont need to be URI
... extensibility: dont need to be URI ←
15:03:49 <AlexPassant> ... the function specifies how you interpret the keywords
... the function specifies how you interpret the keywords ←
15:04:04 <AlexPassant> AxelPolleres: arguing for 1.1 ?
Axel Polleres: arguing for 1.1 ? ←
15:04:08 <AlexPassant> ivan: yes
Ivan Herman: yes ←
15:04:12 <AndyS> If sandro arguing to chnage all function in SPARQL?
Andy Seaborne: If sandro arguing to chnage all function in SPARQL? ←
15:04:26 <AlexPassant> sandro: not sure of punctiation between arguments, but yes
Sandro Hawke: not sure of punctiation between arguments, but yes ←
15:04:37 <AxelPolleres> sandro arguing for OPTION 1.4
Axel Polleres: sandro arguing for OPTION 1.4 ←
15:04:39 <AlexPassant> AxelPolleres: arguments should be named ?
Axel Polleres: arguments should be named ? ←
15:04:41 <AlexPassant> sandro: yes
Sandro Hawke: yes ←
15:04:42 <AxelPolleres> q?
Axel Polleres: q? ←
15:05:04 <AlexPassant> SteveH: they're not functions, they're aggregates
Steve Harris: they're not functions, they're aggregates ←
15:05:16 <AlexPassant> ... nervous about combining function syntax and aggregated syntax
... nervous about combining function syntax and aggregated syntax ←
15:05:17 <LeeF> ack SteveH
Lee Feigenbaum: ack SteveH ←
15:05:34 <AxelPolleres> steveH "foo=bar" looks lot like an Expression ?
Axel Polleres: steveH "foo=bar" looks lot like an Expression ? ←
15:05:57 <AlexPassant> SteveH: not evaluated as functions
Steve Harris: not evaluated as functions ←
15:06:03 <pgearon> +q
Paul Gearon: +q ←
15:06:16 <AlexPassant> ... execution model is different
... execution model is different ←
15:06:22 <dcharbon2> q+ to compare FuncNamed option 1.4 to Ruby map arguments
David Charboneau: q+ to compare FuncNamed option 1.4 to Ruby map arguments ←
15:06:23 <AlexPassant> ... helps if we're clear about that
... helps if we're clear about that ←
15:06:24 <AxelPolleres> q+ to ask about foo=bar really different from Expressions?
Axel Polleres: q+ to ask about foo=bar really different from Expressions? ←
15:06:26 <AxelPolleres> q?
Axel Polleres: q? ←
15:06:35 <ivan> ack pgearon
Ivan Herman: ack pgearon ←
15:06:53 <AlexPassant> pgearon: already understand what the evaluation is supposed to be
Paul Gearon: already understand what the evaluation is supposed to be ←
15:07:00 <AlexPassant> ... matter of syntax for expressing what we want
... matter of syntax for expressing what we want ←
15:07:08 <AlexPassant> ... fine w./ having a fixed separator
... fine w./ having a fixed separator ←
15:07:16 <AlexPassant> ... can be syntactically clear about what we want
... can be syntactically clear about what we want ←
15:07:22 <AlexPassant> ... fine with sandro proposal
... fine with sandro proposal ←
15:07:22 <ivan> group_concat(a,b,c,d ; separator=",')
Ivan Herman: group_concat(a,b,c,d ; separator=",') ←
15:07:32 <sandro> s/fixed separator/argument separator
Sandro Hawke: s/fixed separator/argument separator ←
15:07:34 <AlexPassant> s/fixed separator/fixed argument separator
s/fixed separator/fixed argument separator ←
15:07:46 <AxelPolleres> paul fine with separator character, e.g. Option 1.2?
Axel Polleres: 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
Axel Polleres: 2 things: functional arguments shoud be named or not + separator ←
15:08:21 <SteveH> q+ to ask about ; specifically
Steve Harris: q+ to ask about ; specifically ←
15:08:41 <AxelPolleres> OPTION 1.5 = OPTION1.2+OPTION 1.4
Axel Polleres: 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
David Charboneau: 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) ????
Andy Seaborne: 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
Lee Feigenbaum: q+ to wonder why we wouldn't do this same thing for scalar functions if we really do this ←
15:09:41 <AxelPolleres> q?
Axel Polleres: q? ←
15:09:51 <dcharbon2> q-
David Charboneau: q- ←
15:09:52 <AlexPassant> dcharbon2: not familiar w/ python but sounds good
David Charboneau: not familiar w/ python but sounds good ←
15:10:01 <AxelPolleres> ack Axel
Axel Polleres: ack Axel ←
15:10:01 <Zakim> AxelPolleres, you wanted to ask about foo=bar really different from Expressions?
Zakim IRC Bot: AxelPolleres, you wanted to ask about foo=bar really different from Expressions? ←
15:11:32 <AlexPassant> AxelPolleres: looks like expressions
Axel Polleres: looks like expressions ←
15:11:53 <AlexPassant> ... personally not in favor of the " keywords = "
... personally not in favor of the " keywords = " ←
15:12:03 <AlexPassant> ... objections re. existing opsions ?
... objections re. existing opsions ? ←
15:12:26 <ivan> group_concat(a,b ; separator -> ",") to make it look like rif ?
Ivan Herman: group_concat(a,b ; separator -> ",") to make it look like rif ? ←
15:12:52 <AlexPassant> ... LeeF objects fixed separator
... LeeF objects fixed separator ←
15:12:59 <AlexPassant> ... sandro objects with []
... sandro objects with [] ←
15:13:01 <LeeF> s/LeeF/LeeF and kasei/
Lee Feigenbaum: s/LeeF/LeeF and kasei/ ←
15:13:08 <AlexPassant> ... left are: 1.2
... left are: 1.2 ←
15:13:17 <AndyS> ivan ,What does that mean in RIF (/me behind the times)?
Andy Seaborne: ivan ,What does that mean in RIF (/me behind the times)? ←
15:13:23 <AlexPassant> ... 1.4 + 1.5
... 1.4 + 1.5 ←
15:13:36 <AlexPassant> ... 2.1
... 2.1 ←
15:13:47 <AlexPassant> ... group concat without separator
... group concat without separator ←
15:14:13 <AxelPolleres> OPTION 1.2: agg(Agg; Func) - sandro1
Axel Polleres: 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 )
Axel Polleres: 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
... 1.2 -> last option w/out objections ←
15:14:48 <LeeF> q?
Lee Feigenbaum: q? ←
15:15:12 <AlexPassant> AndyS: 1.2. is confusing
Andy Seaborne: 1.2. is confusing ←
15:15:16 <AlexPassant> ... style-wise
... style-wise ←
15:15:19 <AlexPassant> SteveH: agrees
Steve Harris: agrees ←
15:15:59 <ivan> group_concat(a,b ; separator -> ",")
Ivan Herman: group_concat(a,b ; separator -> ",") ←
15:16:15 <ivan> group_concat(a,b ; separator = ",")
Ivan Herman: group_concat(a,b ; separator = ",") ←
15:16:42 <ivan> group_concat(a,b | separator -> ",")
Ivan Herman: group_concat(a,b | separator -> ",") ←
15:16:59 <AlexPassant> SteveH: is ; an arbitrary choice ?
Steve Harris: is ; an arbitrary choice ? ←
15:17:02 <ivan> group_concat(a,b | separator = ",")
Ivan Herman: group_concat(a,b | separator = ",") ←
15:17:15 <kasei> group_concat(a, b, separator = ",")
Gregory Williams: group_concat(a, b, separator = ",") ←
15:17:32 <Souri> ';' would be confusing
Souripriya Das: ';' would be confusing ←
15:17:32 <AlexPassant> ... asking if there's a particular reason
... asking if there's a particular reason ←
15:17:39 <AxelPolleres> q?
Axel Polleres: q? ←
15:17:47 <ivan> ack SteveH
Ivan Herman: ack SteveH ←
15:17:47 <Zakim> SteveH, you wanted to ask about ; specifically
Zakim IRC Bot: SteveH, you wanted to ask about ; specifically ←
15:17:47 <AxelPolleres> ack SteveH
Axel Polleres: ack SteveH ←
15:17:50 <LeeF> ack me
Lee Feigenbaum: 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
Zakim IRC Bot: 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
Axel Polleres: why the second one needs to be named, not the first one ←
15:19:22 <AlexPassant> ... would have been happy with ; without names
... would have been happy with ; without names ←
15:19:30 <AlexPassant> SteveH: names make more obvious there are different
Steve Harris: names make more obvious there are different ←
15:19:32 <sandro> All in favor of group_concat(a, b, separator = ",") ?
Sandro Hawke: All in favor of group_concat(a, b, separator = ",") ? ←
15:19:46 <Souri> q+
Souripriya Das: q+ ←
15:20:04 <AlexPassant> Souri: 2 kind of arguments
Souripriya Das: 2 kind of arguments ←
15:20:12 <sandro> All in favor of group_concat(a, b; separator = ",") ?
Sandro Hawke: All in favor of group_concat(a, b; separator = ",") ? ←
15:20:12 <AlexPassant> ... different kind of parameters
... different kind of parameters ←
15:20:20 <AlexPassant> ... why they cant have differnet ways of specifying ?
... why they cant have differnet ways of specifying ? ←
15:20:49 <SteveH> there's only expressions, and parameters, not two kinds of parameters
Steve Harris: 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 = ",")
Axel Polleres: 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
Steve Harris: either is OK for me ←
15:21:18 <ivan> +1 +1
Ivan Herman: +1 +1 ←
15:21:19 <AndyS> Pref ;
Andy Seaborne: Pref ; ←
15:21:19 <Souri> 2nd one
Souripriya Das: 2nd one ←
15:21:28 <sandro> +1 "|"
Sandro Hawke: +1 "|" ←
15:21:32 <bglimm> either is ok
Birte Glimm: either is ok ←
15:21:36 <kasei> +1 +0.5
Gregory Williams: +1 +0.5 ←
15:21:42 <MattPerry> +1 "|"
Matthew Perry: +1 "|" ←
15:21:43 <AxelPolleres> pref ;
Axel Polleres: pref ; ←
15:21:50 <AlexPassant> ok for both
ok for both ←
15:21:52 <pgearon> aesthetically, I like ; but I appreciate SteveH's concern and am happy with |
Paul Gearon: aesthetically, I like ; but I appreciate SteveH's concern and am happy with | ←
15:21:53 <dcharbon2> no pref
David Charboneau: no pref ←
15:21:57 <Souri> q+ to allow a default
Souripriya Das: q+ to allow a default ←
15:21:59 <ivan> group_concat(a, b | separator = ",") seems to have the majority
Ivan Herman: group_concat(a, b | separator = ",") seems to have the majority ←
15:22:00 <AndyS> Isn't | list tail in some languages isn't it?
Andy Seaborne: Isn't | list tail in some languages isn't it? ←
15:22:04 <LeeF> no pref on separator, uncomfortable with the whole lot
Lee Feigenbaum: no pref on separator, uncomfortable with the whole lot ←
15:22:08 <SteveH> prefer |, but not strongly
Steve Harris: prefer |, but not strongly ←
15:22:12 <AlexPassant> yes AndyS
yes AndyS ←
15:22:46 <sandro> !
Sandro Hawke: ! ←
15:22:48 <AndyS> f(a, 1|2, 3)
Andy Seaborne: f(a, 1|2, 3) ←
15:23:00 <kasei> I thought it was ||
Gregory Williams: I thought it was || ←
15:23:01 <sandro> how about "--" as the separator
Sandro Hawke: how about "--" as the separator ←
15:23:10 <AlexPassant> AndyS: dont have | at the moment, but...
Andy Seaborne: dont have | at the moment, but... ←
15:23:55 <AxelPolleres> PROPOSED: GROUP_CONCAT syntax shall be GROUP_CONCAT(a, b; separator = ",")
PROPOSED: GROUP_CONCAT syntax shall be GROUP_CONCAT(a, b; separator = ",") ←
15:24:08 <sandro> +1
Sandro Hawke: +1 ←
15:24:08 <bglimm> +1
Birte Glimm: +1 ←
15:24:12 <AxelPolleres> +1
Axel Polleres: +1 ←
15:24:13 <SteveH> +1
Steve Harris: +1 ←
15:24:14 <kasei> +1
Gregory Williams: +1 ←
15:24:15 <AlexPassant> +1
+1 ←
15:24:16 <pgearon> +1
Paul Gearon: +1 ←
15:24:18 <ivan> amen = 1
Ivan Herman: amen = 1 ←
15:24:24 <dcharbon2> +1
David Charboneau: +1 ←
15:24:38 <LeeF> 0
Lee Feigenbaum: 0 ←
15:24:38 <Souri> q?
Souripriya Das: q? ←
15:24:39 <AxelPolleres> RESOLVED: GROUP_CONCAT syntax shall be GROUP_CONCAT(a, b; separator = ",")
RESOLVED: GROUP_CONCAT syntax shall be GROUP_CONCAT(a, b; separator = ",") ←
15:24:42 <LeeF> I abstain.
Lee Feigenbaum: I abstain. ←
15:24:43 <AlexPassant> AxelPolleres: also general mechanism for any parameterised function
Axel Polleres: also general mechanism for any parameterised function ←
15:24:56 <AlexPassant> Souri: wanted to mention the typical case
Souripriya Das: wanted to mention the typical case ←
15:25:01 <AlexPassant> ... chose one character to be default
... chose one character to be default ←
15:25:08 <AlexPassant> ... so 2nd part can be optional
... so 2nd part can be optional ←
15:25:13 <SteveH> +1 to a default
Steve Harris: +1 to a default ←
15:25:15 <AlexPassant> ... comma or space make sense
... comma or space make sense ←
15:25:21 <AlexPassant> LeeF: comma is good
Lee Feigenbaum: comma is good ←
15:25:32 <AndyS> space
Andy Seaborne: space ←
15:25:54 <AlexPassant> AxelPolleres: can we leave it to the editors ?
Axel Polleres: can we leave it to the editors ? ←
15:26:01 <AxelPolleres> dafault separator is currently " "
Axel Polleres: dafault separator is currently " " ←
15:26:06 <AxelPolleres> q?
Axel Polleres: q? ←
15:26:09 <LeeF> ack Souri
Lee Feigenbaum: ack Souri ←
15:26:09 <Zakim> Souri, you wanted to allow a default
Zakim IRC Bot: Souri, you wanted to allow a default ←
15:26:11 <Souri> q-
Souripriya Das: q- ←
15:26:13 <AxelPolleres> ack Souri
Axel Polleres: ack Souri ←
15:26:31 <AlexPassant> AxelPolleres: last aggregate - SAMPLE
Axel Polleres: last aggregate - SAMPLE ←
15:26:42 <AlexPassant> ... multiparameter in group_concat ?
... multiparameter in group_concat ? ←
15:27:06 <Souri> no
Souripriya Das: no ←
15:27:19 <AlexPassant> btw, should we discuss AndyS's comment regarding _ in group_concat ?
btw, should we discuss AndyS's comment regarding _ in group_concat ? ←
15:27:35 <kasei> do we have a scalar CONCAT function?
Gregory Williams: do we have a scalar CONCAT function? ←
15:27:42 <SteveH> kasei, not at the moment
Steve Harris: kasei, not at the moment ←
15:27:48 <AxelPolleres> PROPOSED: to keep GROUP_CONCAT single expression
PROPOSED: to keep GROUP_CONCAT single expression ←
15:27:56 <SteveH> abstain
Steve Harris: abstain ←
15:27:57 <kasei> then I think multi-expression is desirable
Gregory Williams: then I think multi-expression is desirable ←
15:28:08 <Souri> group_concat(c1||c2||c3)
Souripriya Das: group_concat(c1||c2||c3) ←
15:28:20 <AxelPolleres> +1
Axel Polleres: +1 ←
15:28:46 <AlexPassant> Souri: dont have a syntax
Souripriya Das: dont have a syntax ←
15:28:51 <AlexPassant> LeeF: part of the function library
Lee Feigenbaum: part of the function library ←
15:28:56 <kasei> what I'd want is GROUP_CONCAT(CONCAT(" ", ?latitude, ?longitude))
Gregory Williams: 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
Lee Feigenbaum: 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
Steve Harris: kasei, GROUP_CONCAT(CONCAT(?key, "=", ?val)) is a good example of that ←
15:29:41 <SteveH> we do that a lot
Steve Harris: we do that a lot ←
15:29:45 <AndyS> function fn:string-join is two arg string concat
Andy Seaborne: function fn:string-join is two arg string concat ←
15:29:46 <kasei> yeah
Gregory Williams: yeah ←
15:29:46 <Souri> +1
Souripriya Das: +1 ←
15:29:54 <kasei> so let's just remember that we want a scalar CONCAT
Gregory Williams: so let's just remember that we want a scalar CONCAT ←
15:29:58 <AlexPassant> AxelPolleres: can we resolve the single expression GROUP CONCAT ?
Axel Polleres: can we resolve the single expression GROUP CONCAT ? ←
15:30:09 <AxelPolleres> RESOLVED: to keep GROUP_CONCAT single expression, one abstain, no objections
RESOLVED: to keep GROUP_CONCAT single expression, one abstain, no objections ←
15:30:11 <AndyS> Sorry - I'm wrong - fn:concat N-ary
Andy Seaborne: Sorry - I'm wrong - fn:concat N-ary ←
15:30:12 <AlexPassant> s/GROUP CONCAT/GROUP_CONCAT
s/GROUP CONCAT/GROUP_CONCAT ←
15:30:21 <AlexPassant> AxelPolleres: next: SAMPLE
Axel Polleres: next: SAMPLE ←
15:30:27 <AlexPassant> ... should be pretty clear
... should be pretty clear ←
15:30:35 <AlexPassant> ... just need to figure out if that's multi expression
... just need to figure out if that's multi expression ←
15:31:10 <LeeF> SteveH, pgearon abstaining to above resolution
Lee Feigenbaum: SteveH, pgearon abstaining to above resolution ←
15:31:35 <AxelPolleres> agreement to keep SAMPLE single expression
Axel Polleres: agreement to keep SAMPLE single expression ←
15:31:39 <AxelPolleres> ?
Axel Polleres: ? ←
15:31:42 <kasei> +1
Gregory Williams: +1 ←
15:31:49 <Souri> q+
Souripriya Das: q+ ←
15:32:13 <kasei> COALESCE(SAMPLE(?name), SAMPLE(?fullname))
Gregory Williams: COALESCE(SAMPLE(?name), SAMPLE(?fullname)) ←
15:32:15 <AlexPassant> SteveH: e.g. want to pick some random names
Steve Harris: e.g. want to pick some random names ←
15:32:33 <AlexPassant> ... not sure that's a strong enough usecase
... not sure that's a strong enough usecase ←
15:33:01 <AxelPolleres> could be done with a UNION, it seems.
Axel Polleres: could be done with a UNION, it seems. ←
15:33:21 <pgearon> kasei - I don't understand the nested aggregates
Paul Gearon: kasei - I don't understand the nested aggregates ←
15:33:24 <MattPerry> CONCAT(SAMPLE(?name), SAMPLE(?fullname)) ?
Matthew Perry: CONCAT(SAMPLE(?name), SAMPLE(?fullname)) ? ←
15:33:40 <Souri> sample(coalesce(?name,?fullname))
Souripriya Das: sample(coalesce(?name,?fullname)) ←
15:34:39 <Souri> q?
Souripriya Das: q? ←
15:35:10 <AlexPassant> Souri: taking a sample with 4 values - some are NULL, can he SAMPLE select NULL as well ?
Souripriya Das: taking a sample with 4 values - some are NULL, can he SAMPLE select NULL as well ? ←
15:35:17 <Souri> q-
Souripriya Das: q- ←
15:35:41 <AlexPassant> AxelPolleres: done with aggregates
Axel Polleres: done with aggregates ←
15:35:48 <Souri> so did we agree on only single-arg sample?
Souripriya Das: so did we agree on only single-arg sample? ←
15:35:55 <SteveH> yes
Steve Harris: yes ←
15:36:03 <AlexPassant> ... next: addressing extensibility in the spect
... next: addressing extensibility in the spect ←
15:36:09 <AlexPassant> ... would like to leave this to the editors
... would like to leave this to the editors ←
15:36:19 <AlexPassant> ... "agregated extensibility" section
... "agregated extensibility" section ←
15:36:30 <AlexPassant> s/agregated/aggregates/
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
Axel Polleres: 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
... what do we allow in GROUP BY ←
15:38:17 <AlexPassant> SteveH: expressions are complicated
Steve Harris: expressions are complicated ←
15:38:22 <AlexPassant> ... discussed in f2f2
... discussed in f2f2 ←
15:38:50 <AlexPassant> kasei: used expressions in GROUP BY
Gregory Williams: used expressions in GROUP BY ←
15:38:52 <AlexPassant> ... was useful
... was useful ←
15:39:19 <AlexPassant> ... pulled in out in the projection
... pulled in out in the projection ←
15:39:51 <AlexPassant> AxelPolleres: use-case of Emmanuelle
Axel Polleres: use-case of Emmanuelle ←
15:39:54 <AlexPassant> ... related to the topic
... related to the topic ←
15:40:00 <AndyS> Can do it with an assignment ^h^h^h^h^h^h^h subSELECT with expression
Andy Seaborne: 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?
Matthew Perry: 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)
Gregory Williams: is this dumb? and/or would it solve this problem? GROUP BY (?a+?b AS ?c) ←
15:40:20 <AndyS> ... but a bit ugly
Andy Seaborne: ... but a bit ugly ←
15:41:20 <SteveH> { SELECT (?a + ?b AS ?c), * ... }
Steve Harris: { 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
Andy Seaborne: 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
Axel Polleres: 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
Gregory Williams: 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
... 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)
Andy Seaborne: 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
... 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;
Souripriya Das: 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
... propose to have only variables in GROUP BY ←
15:45:29 <AxelPolleres> Is the following currently possible?
Axel Polleres: Is the following currently possible? ←
15:45:33 <AxelPolleres> PREFIX : <http://books.example/>
Axel Polleres: PREFIX : <http://books.example/> ←
15:45:33 <AxelPolleres> SELECT ?auth ?name (AVG(?numberOfBooks) AS ?averageNumberOfBooks)
Axel Polleres: SELECT ?auth ?name (AVG(?numberOfBooks) AS ?averageNumberOfBooks) ←
15:45:33 <AxelPolleres> WHERE { ?auth :name ?name
Axel Polleres: WHERE { ?auth :name ?name ←
15:45:33 <AxelPolleres> {
Axel Polleres: { ←
15:45:34 <AxelPolleres> SELECT ?auth (COUNT(?book) AS ?numberOfBooks)
Axel Polleres: SELECT ?auth (COUNT(?book) AS ?numberOfBooks) ←
15:45:34 <AxelPolleres> WHERE {
Axel Polleres: WHERE { ←
15:45:36 <AxelPolleres> ?auth :wrote ?book .
Axel Polleres: ?auth :wrote ?book . ←
15:45:38 <AxelPolleres> }
Axel Polleres: } ←
15:45:40 <AxelPolleres> GROUP BY ?auth
Axel Polleres: GROUP BY ?auth ←
15:45:42 <AxelPolleres> HAVING (?numberOfBooks > 5)
Axel Polleres: HAVING (?numberOfBooks > 5) ←
15:45:44 <AxelPolleres> }
Axel Polleres: } ←
15:45:53 <AxelPolleres> admittedly somewhat orthogonal
Axel Polleres: admittedly somewhat orthogonal ←
15:47:59 <AndyS> Currently: [20] GroupCondition ::= ( BuiltInCall | FunctionCall | '(' Expression ( 'AS' Var )? ')' | Var )
Andy Seaborne: Currently: [20] GroupCondition ::= ( BuiltInCall | FunctionCall | '(' Expression ( 'AS' Var )? ')' | Var ) ←
15:49:38 <AlexPassant> AxelPolleres: re. emmanuelle comment - author and name are projected
Axel Polleres: re. emmanuelle comment - author and name are projected ←
15:49:44 <AlexPassant> ... would not be allowed ?
... would not be allowed ? ←
15:49:49 <AndyS> and [19] GroupClause ::= 'GROUP' 'BY' GroupCondition+
Andy Seaborne: and [19] GroupClause ::= 'GROUP' 'BY' GroupCondition+ ←
15:49:54 <AlexPassant> LeeF: cant do that
Lee Feigenbaum: cant do that ←
15:50:33 <AlexPassant> SteveH: legal in SQL
Steve Harris: legal in SQL ←
15:51:00 <AndyS> In SPARQL -- SELECT ?auth SAMPLE(?name) (AVG(?numberOfBooks) AS ?averageNumberOfBooks)
Andy Seaborne: In SPARQL -- SELECT ?auth SAMPLE(?name) (AVG(?numberOfBooks) AS ?averageNumberOfBooks) ←
15:51:52 <AndyS> because outer is a GROUP BY implicitly to get AVG
Andy Seaborne: 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
Axel Polleres: 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)
Axel Polleres: 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)
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
Lee Feigenbaum: +1 ←
15:56:49 <kasei> so long as "renames" means expressions with optional renaming.
Gregory Williams: so long as "renames" means expressions with optional renaming. ←
15:56:50 <AxelPolleres> +1
Axel Polleres: +1 ←
15:57:04 <AndyS> +1 -- as per kasei
Andy Seaborne: +1 -- as per kasei ←
15:57:39 <AndyS> Is GROUP BY (?a+?b) legal? Yes.
Andy Seaborne: 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
PROPOSED: Close ISSUE-41 with the agreemen to go forward with what's in the current grammar ←
15:57:49 <AxelPolleres> +1
Axel Polleres: +1 ←
15:57:54 <bglimm> +1
Birte Glimm: +1 ←
15:57:58 <Souri> +1
Souripriya Das: +1 ←
15:57:59 <AlexPassant> +1
+1 ←
15:58:03 <dcharbon2> +1
David Charboneau: +1 ←
15:58:09 <pgearon> +1
Paul Gearon: +1 ←
15:58:12 <MattPerry> +1
Matthew Perry: +1 ←
15:58:16 <AxelPolleres> RESOLVED: Close ISSUE-41 with the agreemen to go forward with what's in the current grammar
RESOLVED: Close ISSUE-41 with the agreemen to go forward with what's in the current grammar ←
15:58:21 <AxelPolleres> close ISSUE-41
Axel Polleres: close ISSUE-41 ←
15:58:21 <trackbot> ISSUE-41 Does GROUP BY allow variables or expressions, and does it allow mutiple expressions? closed
Trackbot IRC Bot: ISSUE-41 Does GROUP BY allow variables or expressions, and does it allow mutiple expressions? closed ←
15:58:38 <AlexPassant> AndyS: question about HAVING
Andy Seaborne: question about HAVING ←
15:58:47 <LeeF> ISSUE-41: resolved with the agreement to go forward with what's in the current grammar
Lee Feigenbaum: 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
Trackbot IRC Bot: 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
Andy Seaborne: 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
... Is that allowed ? think so ←
16:00:12 <AlexPassant> SteveH: lots of complications
Steve Harris: lots of complications ←
16:00:22 <SteveH> question about complications actually
Steve Harris: question about complications actually ←
16:00:35 <Souri> it becomes one group
Souripriya Das: it becomes one group ←
16:01:16 <AxelPolleres> q?
Axel Polleres: q? ←
16:01:46 <AlexPassant> AxelPolleres: is there an issue on that ?
Axel Polleres: is there an issue on that ? ←
16:01:50 <AlexPassant> AndyS: just checking if that works
Andy Seaborne: just checking if that works ←
16:01:59 <AxelPolleres> should we have a test case along these lines?
Axel Polleres: should we have a test case along these lines? ←
16:02:04 <AndyS> SELECT (COUNT(*) AS ?C) .... HAVING (?C > 0 )
Andy Seaborne: 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
Andy Seaborne: 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
Gregory Williams: 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?
Axel Polleres: main question is: Do we do HAVING before or after projection? ←
16:03:50 <AndyS> Agreement that not the second not allowed.
Andy Seaborne: Agreement that not the second not allowed. ←
16:03:51 <Souri> HAVING (?C > 0 ) would not work in SQL
Souripriya Das: HAVING (?C > 0 ) would not work in SQL ←
16:03:52 <AlexPassant> AxelPolleres: agreement to allow the frst one, not sure about the 2nd
Axel Polleres: 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.
Gregory Williams: 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
Lee Feigenbaum: fine ←
16:04:30 <AxelPolleres> agreement to disallow projected variables being reused in HAVING
Axel Polleres: agreement to disallow projected variables being reused in HAVING ←
16:04:33 <AlexPassant> AxelPolleres: disallow projected variables in having
Axel Polleres: disallow projected variables in having ←
16:04:46 <AlexPassant> ... will be reflected in the spec
... will be reflected in the spec ←
16:05:01 <AxelPolleres> ACTION: steveH to disallow projected variables being reused in HAVING in the spec
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].
Trackbot IRC Bot: 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
... looks like aggregates are done ←
16:05:35 <AxelPolleres> topic: NOT EXISTS vs. MINUS
16:05:54 <AlexPassant> ... next: NOT EXISTS / MINUS
... next: NOT EXISTS / MINUS ←
16:06:33 <AlexPassant> SteveH: preference for the MINUS
Steve Harris: preference for the MINUS ←
16:06:37 <AxelPolleres> ACTION: Axel to draft a testcase for SELECT (COUNT(*) AS ?C) .... HAVING (COUNT(*) > 0 )
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].
Trackbot IRC Bot: 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
... much easier to optimise ←
16:08:02 <AndyS> (5Store example - other engines differ)
Andy Seaborne: (5Store example - other engines differ) ←
16:08:11 <AlexPassant> ... OPTIONAL in NOT EXISTS
... OPTIONAL in NOT EXISTS ←
16:09:03 <AlexPassant> pgearon: also already implemented the MINUS semantics
Paul Gearon: also already implemented the MINUS semantics ←
16:09:56 <AlexPassant> SteveH: what happen in NOT EXISTS semantics if introducing a new variable ?
Steve Harris: what happen in NOT EXISTS semantics if introducing a new variable ? ←
16:10:28 <SteveH> WHERE { <x> <p> ?o . NOT EXISTS { <a> ?p ?o } }
Steve Harris: 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
Eric Prud'hommeaux: MINUS in the spec seems comparable to the one I have ←
16:12:07 <AlexPassant> ... right side has correspondence with the left side
... right side has correspondence with the left side ←
16:12:16 <AlexPassant> ... substrct an empty set -> not eliminating anything
... substrct an empty set -> not eliminating anything ←
16:12:26 <AlexPassant> s/substrct/substract
s/substrct/substract ←
16:14:39 <AlexPassant> .. cardinality for any particular solution is 0
.. cardinality for any particular solution is 0 ←
16:16:27 <AlexPassant> SteveH: objection if NOT EXISTS only takes BGP + FILTER ?
Steve Harris: objection if NOT EXISTS only takes BGP + FILTER ? ←
16:16:39 <AlexPassant> kasei: can imagine also scoping to a Named Graph
Gregory Williams: can imagine also scoping to a Named Graph ←
16:17:30 <AndyS> NG with special case of GRAPH { ...} - several new grammar rules.
Andy Seaborne: NG with special case of GRAPH { ...} - several new grammar rules. ←
16:18:32 <AlexPassant> ericP: downside of using MINUS ?
Eric Prud'hommeaux: downside of using MINUS ? ←
16:18:42 <AlexPassant> AndyS: closest to the OPTIONAL NOT BOUND
Andy Seaborne: closest to the OPTIONAL NOT BOUND ←
16:18:43 <pgearon> q+
Paul Gearon: q+ ←
16:19:24 <kasei> yeah, def. would need new grammar rules. it's something like (GraphGraphPattern* + TriplesBlock* + Filter?)*
Gregory Williams: 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
Paul Gearon: 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
Andy Seaborne: GraphGraphPattern needs to restrict to a TripleBlock not a general pattern ←
16:20:12 <AlexPassant> ... if different people implement diferently - it will not impact
... if different people implement diferently - it will not impact ←
16:20:24 <kasei> AndyS, yes, that too.
Gregory Williams: AndyS, yes, that too. ←
16:20:29 <kasei> very messy
Gregory Williams: very messy ←
16:20:50 <kasei> but simpler after you finish with parsing.
Gregory Williams: but simpler after you finish with parsing. ←
16:21:09 <pgearon> ack pgearon
Paul Gearon: ack pgearon ←
16:21:46 <AlexPassant> ericP: does NOT EXISTS rely on compability f?
Eric Prud'hommeaux: does NOT EXISTS rely on compability f? ←
16:22:01 <AlexPassant> AndyS: no, like having a FILTER + sub-ask in it
Andy Seaborne: no, like having a FILTER + sub-ask in it ←
16:22:12 <AlexPassant> ericP: algebra available?
Eric Prud'hommeaux: algebra available? ←
16:22:44 <AndyS> http://www.w3.org/2009/sparql/docs/query-1.1/rq25.xml#defn_exists
Andy Seaborne: 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
Axel Polleres: feeling that won't get an agreement ←
16:24:00 <AlexPassant> sandro: can we just provide both semantics
Sandro Hawke: can we just provide both semantics ←
16:24:09 <AlexPassant> ... people coule implement either one and be correct
... people coule implement either one and be correct ←
16:24:20 <AlexPassant> ... talking about the semantics not the syntax
... 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 }
Eric Prud'hommeaux: { 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
Eric Prud'hommeaux: 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 }
Eric Prud'hommeaux: { 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> !!!
Eric Prud'hommeaux: !!! ←
16:26:23 <ericP> { a b c { a b c { a b c
Eric Prud'hommeaux: { a b c { a b c { a b c ←
16:26:30 <ericP> 7 7 7 7 8 8
Eric Prud'hommeaux: 7 7 7 7 8 8 ←
16:26:38 <ericP> 8 8 MINUS 7 7 7 } = 8 8 8 }
Eric Prud'hommeaux: 8 8 MINUS 7 7 7 } = 8 8 8 } ←
16:26:47 <ericP> 7 7 7
Eric Prud'hommeaux: 7 7 7 ←
16:26:53 <ericP> 8 8 8 }
Eric Prud'hommeaux: 8 8 8 } ←
16:27:16 <ericP> what does NOT EXISTS do?
Eric Prud'hommeaux: 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
Lee Feigenbaum: 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
Lee Feigenbaum: 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)
Lee Feigenbaum: 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)
Lee Feigenbaum: (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.
Gregory Williams: 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 ?
Sandro Hawke: both semantics and then editorial change if we can get both simpler ? ←
16:28:42 <LeeF> kasei, right, i agree
Lee Feigenbaum: kasei, right, i agree ←
16:28:47 <sandro> (with the NOT EXISTS syntax)
Sandro Hawke: (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.
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.
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.
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
Axel Polleres: 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.
Gregory Williams: 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
Andy Seaborne: 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
Lee Feigenbaum: 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)
Paul Gearon: 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 ?
Andy Seaborne: NOT EXISTS and restricted syntax ? ←
16:34:16 <AlexPassant> ericP: take advantage of existing implementaion of understanding ?
Eric Prud'hommeaux: take advantage of existing implementaion of understanding ? ←
16:34:32 <AlexPassant> ivan: more interested in people's understanding
Ivan Herman: more interested in people's understanding ←
16:34:35 <AxelPolleres> proposals on the table...
Axel Polleres: proposals on the table... ←
16:34:39 <AxelPolleres> - agree on syntax NOT EXISTS, try to unify semantics (sandro)
Axel Polleres: - agree on syntax NOT EXISTS, try to unify semantics (sandro) ←
16:34:39 <AxelPolleres> - agree on syntax MINUS, try to unify semantics (paul)
Axel Polleres: - agree on syntax MINUS, try to unify semantics (paul) ←
16:34:39 <AxelPolleres> - NOT EXISTS with restricted syntax (andy)
Axel Polleres: - NOT EXISTS with restricted syntax (andy) ←
16:34:40 <AxelPolleres> ?
Axel Polleres: ? ←
16:34:55 <pgearon> +q
Paul Gearon: +q ←
16:34:56 <AlexPassant> SteveH: given none of us can distinguish NOT EXISTS and MINUS
Steve Harris: given none of us can distinguish NOT EXISTS and MINUS ←
16:35:03 <AlexPassant> ... issue re. how users would do it
... issue re. how users would do it ←
16:35:18 <AlexPassant> ivan: how to explain without 'algebra', 'joint', etc.
Ivan Herman: how to explain without 'algebra', 'joint', etc. ←
16:35:36 <Souri> q+
Souripriya Das: q+ ←
16:35:38 <AlexPassant> SteveH: everything on the right is removed from the lest
Steve Harris: everything on the right is removed from the lest ←
16:35:43 <AlexPassant> s/lest/left
s/lest/left ←
16:35:43 <AxelPolleres> {Left} MINUS {�Right}
Axel Polleres: {Left} MINUS {�Right} ←
16:35:54 <AlexPassant> ... my point is that there's no different
... 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.
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)
Sandro Hawke: (I don't care which syntax, myself) ←
16:36:34 <AlexPassant> kasei: differnet implementers will find what's the easiest way to implement
Gregory Williams: differnet implementers will find what's the easiest way to implement ←
16:36:45 <AlexPassant> ericP: concenred about the transformation challenge
Eric Prud'hommeaux: concenred about the transformation challenge ←
16:37:05 <AlexPassant> ... easy in SQL semantics
... easy in SQL semantics ←
16:37:11 <AlexPassant> ... need to get clear and simple semantics
... need to get clear and simple semantics ←
16:37:28 <AlexPassant> AxelPolleres: 3 proposals
Axel Polleres: 3 proposals ←
16:38:15 <AlexPassant> ... sandro ; pgearon -> sandro + s/NOT EXISTS/MINUS ; AndyS -> restrict the syntax
... 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.
Sandro Hawke: 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
Andy Seaborne: 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?
Souripriya Das: what are the diffs between SQL MINUS and proposed SPARQL1.1 MINUS? ←
16:43:44 <AlexPassant> ... set difference between the 2 cols
... set difference between the 2 cols ←
16:44:04 <AlexPassant> ericP: difference between SQL and SPARQL both in the joint and the minus
Eric Prud'hommeaux: difference between SQL and SPARQL both in the joint and the minus ←
16:45:21 <AlexPassant> AxelPolleres: no convergence of the WG
Axel Polleres: no convergence of the WG ←
16:45:31 <AlexPassant> ivan: same issue for the lst 6 months
Ivan Herman: same issue for the lst 6 months ←
16:45:40 <AlexPassant> ... will be in the same situation in 6 months
... will be in the same situation in 6 months ←
16:45:50 <AlexPassant> ... sandro's proposal makes sense
... sandro's proposal makes sense ←
16:46:04 <AlexPassant> AxelPolleres: agree on the syntax ? what about the semantics ?
Axel Polleres: agree on the syntax ? what about the semantics ? ←
16:46:23 <AlexPassant> sandro: 2 proposals: (1) which syntax and (2) using "merge semantics"
Sandro Hawke: 2 proposals: (1) which syntax and (2) using "merge semantics" ←
16:47:21 <AlexPassant> AxelPolleres: conditions would be contextual ?
Axel Polleres: conditions would be contextual ? ←
16:47:32 <AlexPassant> sandro: resolving syntax first ?
Sandro Hawke: resolving syntax first ? ←
16:48:31 <AlexPassant> ericP: what about NOT FOUND insteand of NOT EXISTS ?
Eric Prud'hommeaux: what about NOT FOUND insteand of NOT EXISTS ? ←
16:48:35 <AlexPassant> ... open world issue
... open world issue ←
16:48:52 <AxelPolleres> how about just NOT
Axel Polleres: how about just NOT ←
16:48:54 <sandro> eric: "NOT EXISTS" is blood in the water to Open World folks.
Eric Prud'hommeaux: "NOT EXISTS" is blood in the water to Open World folks. [ Scribe Assist by Sandro Hawke ] ←
16:49:16 <AlexPassant> AndyS: NOT EXISTS is negation by failure
Andy Seaborne: NOT EXISTS is negation by failure ←
16:49:30 <AxelPolleres> NAF
Axel Polleres: NAF ←
16:49:36 <LeeF> straw poll: what are your thoguhts on the syntax choice NOT EXISTS?
Lee Feigenbaum: straw poll: what are your thoguhts on the syntax choice NOT EXISTS? ←
16:49:39 <pgearon> -1
Paul Gearon: -1 ←
16:49:40 <SteveH> 0
Steve Harris: 0 ←
16:49:43 <dcharbon2> 0
16:49:44 <AndyS> +1
Andy Seaborne: +1 ←
16:49:45 <LeeF> +1
Lee Feigenbaum: +1 ←
16:49:46 <ivan> 1
Ivan Herman: 1 ←
16:49:47 <MattPerry> +1
Matthew Perry: +1 ←
16:49:47 <AxelPolleres> +!
Axel Polleres: +! ←
16:49:47 <Souri> +1
Souripriya Das: +1 ←
16:49:47 <ericP> -1
Eric Prud'hommeaux: -1 ←
16:49:48 <kasei> +1
Gregory Williams: +1 ←
16:49:50 <AxelPolleres> +1
Axel Polleres: +1 ←
16:49:51 <sandro> -1
Sandro Hawke: -1 ←
16:49:53 <bglimm> 0
Birte Glimm: 0 ←
16:49:54 <AlexPassant> 0
0 ←
16:50:14 <LeeF> +8 / 4 / -3
Lee Feigenbaum: +8 / 4 / -3 ←
16:50:40 <LeeF> straw poll: what are your thoughts on the syntax choice MINUS?
Lee Feigenbaum: straw poll: what are your thoughts on the syntax choice MINUS? ←
16:50:41 <kasei> 0
16:50:43 <pgearon> +1
Paul Gearon: +1 ←
16:50:47 <AxelPolleres> 0
Axel Polleres: 0 ←
16:50:47 <AndyS> -1
Andy Seaborne: -1 ←
16:50:48 <SteveH> +0.5
Steve Harris: +0.5 ←
16:50:48 <ivan> 0
Ivan Herman: 0 ←
16:50:49 <LeeF> 0
Lee Feigenbaum: 0 ←
16:50:49 <ericP> +1
Eric Prud'hommeaux: +1 ←
16:50:51 <MattPerry> -1
Matthew Perry: -1 ←
16:50:53 <Souri> -1
Souripriya Das: -1 ←
16:50:54 <sandro> +1
Sandro Hawke: +1 ←
16:50:56 <dcharbon2> 0
16:51:00 <bglimm> +1
Birte Glimm: +1 ←
16:51:07 <AlexPassant> +1
+1 ←
16:51:27 <LeeF> +6 / 5 / -3
Lee Feigenbaum: +6 / 5 / -3 ←
16:52:03 <LeeF> PROPOSED: Negation syntax is via the "NOT EXISTS" keywords
PROPOSED: Negation syntax is via the "NOT EXISTS" keywords ←
16:52:10 <SteveH> +1
Steve Harris: +1 ←
16:52:13 <AxelPolleres> +1
Axel Polleres: +1 ←
16:52:13 <ivan> +1
Ivan Herman: +1 ←
16:52:20 <bglimm> 0
Birte Glimm: 0 ←
16:52:22 <sandro> +0
Sandro Hawke: +0 ←
16:52:23 <Souri> +1
Souripriya Das: +1 ←
16:52:31 <pgearon> +1 if someone can clearly specify the difference between the two semantics
Paul Gearon: +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
RESOLVED: Negation syntax is via the "NOT EXISTS" keywords, bglimm and sandro abstaining ←
16:53:25 <ericP> +χ
Eric Prud'hommeaux: +χ ←
16:56:06 <kasei> q+
Gregory Williams: 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
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
Lee Feigenbaum: ack pgearon ←
16:57:47 <AlexPassant> AxelPolleres: 2 semanitcs that are both informative
Axel Polleres: 2 semanitcs that are both informative ←
16:58:02 <AlexPassant> pgearon: ivan mentioned users / implementers difference
Paul Gearon: ivan mentioned users / implementers difference ←
16:58:12 <AlexPassant> ... implementers doing it because of a use-case
... implementers doing it because of a use-case ←
16:58:27 <AlexPassant> ... asked by users to go that way
... asked by users to go that way ←
16:58:36 <AlexPassant> ... each implementation come from user requirements
... each implementation come from user requirements ←
16:58:41 <AxelPolleres> can we say "Normative only of OPTIONAL is not used in rhs"?
Axel Polleres: 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
Ivan Herman: feeling is thqt 99% of use-cases will work with both semantics ←
16:59:03 <AlexPassant> pgearon: 100% will
Paul Gearon: 100% will ←
16:59:06 <AxelPolleres> Can we say "Normative only if OPTIONAL is not used in rhs"?
Axel Polleres: Can we say "Normative only if OPTIONAL is not used in rhs"? ←
16:59:09 <LeeF> ack Souri
Lee Feigenbaum: ack Souri ←
17:00:52 <LeeF> ack kasei
Lee Feigenbaum: ack kasei ←
17:01:22 <AlexPassant> Souri: diffeent from the MINUS in SQL based on what goes in both sides
Souripriya Das: diffeent from the MINUS in SQL based on what goes in both sides ←
17:01:28 <AlexPassant> ... simlar way to UNION differences
... simlar way to UNION differences ←
17:03:06 <AxelPolleres> Is that a reasonable way to go (rephrasing sandro)?
Axel Polleres: Is that a reasonable way to go (rephrasing sandro)? ←
17:03:06 <AxelPolleres> - put both semantics in
Axel Polleres: - put both semantics in ←
17:03:06 <AxelPolleres> - put a *normative* restriction in that OPTIONAL is not allowed in rhs
Axel Polleres: - 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
Axel Polleres: - put an *informative* section that describes the differences of the ←
17:03:07 <AxelPolleres> semantics when the restriction is dropped
Axel Polleres: semantics when the restriction is dropped ←
17:03:51 <LeeF> { ?person a foaf:Person } NOT EXISTS { ?airplane a ex:Airplane }
Lee Feigenbaum: { ?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
Ivan Herman: MINUS can have - in some cases - the effect of not returning anything ←
17:04:05 <AlexPassant> ... 'patch' that backfires in kasei's case
... 'patch' that backfires in kasei's case ←
17:04:10 <AndyS> Problem case was { ?s ?p ?o } MINUS {} => nothing
Andy Seaborne: Problem case was { ?s ?p ?o } MINUS {} => nothing ←
17:04:14 <AlexPassant> kasei: ading it to MINUS is irrelevant
Gregory Williams: ading it to MINUS is irrelevant ←
17:05:11 <ericP> { ?s ?p ?o } MINUS { ?x ?y ?z } => nothing
Eric Prud'hommeaux: { ?s ?p ?o } MINUS { ?x ?y ?z } => nothing ←
17:05:14 <ericP> (as well)
Eric Prud'hommeaux: (as well) ←
17:05:30 <Souri> +1
Souripriya Das: +1 ←
17:05:47 <AxelPolleres> break?
Axel Polleres: break? ←
17:05:56 <AndyS> ericp: depends on data
Eric Prud'hommeaux: depends on data [ Scribe Assist by Andy Seaborne ] ←
17:05:57 <AxelPolleres> q?
Axel Polleres: q? ←
17:06:01 <LeeF> ericP, is that how it is now? i thought the patch prevented that? or the patch ensures that?
Lee Feigenbaum: 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
Andy Seaborne: sorry - see the point now ←
17:06:40 <AlexPassant> ericP: no intersecting domain -> nothing substracted
Eric Prud'hommeaux: no intersecting domain -> nothing substracted ←
17:06:56 <LeeF> ericP, then wouldn't { ?s ?p ?o } MINUS { ?x ?y ?z } => everything ?
Lee Feigenbaum: ericP, then wouldn't { ?s ?p ?o } MINUS { ?x ?y ?z } => everything ? ←
17:07:16 <pgearon> LeeF, yes
Paul Gearon: LeeF, yes ←
17:07:52 <LeeF> { ?person a foaf:Person } NOT EXISTS { ?airplane a ex:Airplane }
Lee Feigenbaum: { ?person a foaf:Person } NOT EXISTS { ?airplane a ex:Airplane } ←
17:07:58 <Souri> {?s ?p ?o} NOT EXISTS {?x ?y ?z} => nothing
Souripriya Das: {?s ?p ?o} NOT EXISTS {?x ?y ?z} => nothing ←
17:08:06 <AlexPassant> kasei: LeeF's pattern gives everyghin and NOT EXISTS gives nothing
Gregory Williams: 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
... ok with dropping optional in the right side but will affect implementations ←
17:08:51 <AndyS> "or dom(μ) and dom(μ') are disjoint"
Andy Seaborne: "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 }
Axel Polleres: don't really see the use case for { ?s ?p ?o } MINUS { ?x ?y ?z } ←
17:09:07 <AndyS> Minus(Ω1, Ω2) =
Andy Seaborne: Minus(Ω1, Ω2) = ←
17:09:07 <AndyS> { μ | μ in Ω1 such that for all μ' in Ω2,
Andy Seaborne: { μ | μ in Ω1 such that for all μ' in Ω2, ←
17:09:07 <AndyS> either μ and μ' are not compatible or dom(μ) and dom(μ') are disjoint }
Andy Seaborne: 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
Lee Feigenbaum: 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
Paul Gearon: 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
Lee Feigenbaum: 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
David Charboneau: Is this the email AndyS http://lists.w3.org/Archives/Public/public-rdf-dawg/2009JulSep/0137.html ←
17:11:32 <AndyS> Yes - thanks
Andy Seaborne: Yes - thanks ←
17:12:43 <bglimm> http://lists.w3.org/Archives/Public/public-rdf-dawg/2009JulSep/0030.html
Birte Glimm: 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,
(No events recorded for 41 minutes)
Andy Seaborne: Diff: { μ | μ in Ω1 such that for all μ′ in Ω2, ←
17:54:09 <AndyS> either μ and μ′ are not compatible or μ and μ'
Andy Seaborne: either μ and μ′ are not compatible or μ and μ' ←
17:54:09 <AndyS> are compatible and expr(merge(μ, μ')) has an effective boolean value
Andy Seaborne: are compatible and expr(merge(μ, μ')) has an effective boolean value ←
17:54:09 <AndyS> of false }
Andy Seaborne: of false } ←
17:54:26 <AndyS> (current 1.0 spec - diff is not exposed directly)
Andy Seaborne: (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.
Sandro Hawke: it's probably a typo if there is no overlap in variables. ←
17:56:11 <AxelPolleres> ! EXISTS
Axel Polleres: ! EXISTS ←
17:56:15 <AxelPolleres> NOT EXISTS
Axel Polleres: NOT EXISTS ←
17:56:18 <AxelPolleres> ?
Axel Polleres: ? ←
17:56:40 <Souri> I like NOT EXISTS
Souripriya Das: I like NOT EXISTS ←
17:57:19 <sandro> lee: why NOT EXISTS outside of FILTER?
Lee Feigenbaum: why NOT EXISTS outside of FILTER? [ Scribe Assist by Sandro Hawke ] ←
17:57:29 <sandro> andy: It's just a nice shorter form.
Andy Seaborne: It's just a nice shorter form. [ Scribe Assist by Sandro Hawke ] ←
17:57:40 <sandro> scribe: AxelPolleres
(Scribe set to Axel Polleres)
17:57:44 <sandro> :-)
Sandro Hawke: :-) ←
17:58:15 <AxelPolleres> Andy: I would like NOT EXISTS as shortcut for the FILTER ! EXISTS
Andy Seaborne: 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
Lee Feigenbaum: I like to keep the mental models more clear [ Scribe Assist by Sandro Hawke ] ←
17:58:40 <AxelPolleres> andy: why not put in a pure form of MINUS then?
Andy Seaborne: why not put in a pure form of MINUS then? ←
17:59:33 <LeeF> { ?person a ex:Person } MINUS { ?airplane a ex:Airplane }
Lee Feigenbaum: { ?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
Lee Feigenbaum: 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
Andy Seaborne: happy with that, allows optimisation ←
18:00:40 <AxelPolleres> sandro: shouldn't that be a syntax error?
Sandro Hawke: shouldn't that be a syntax error? ←
18:01:13 <AxelPolleres> LeeF: proposal ...
Lee Feigenbaum: proposal ... ←
18:01:42 <LeeF> PROPOSED: Include MINUS as a binary graph pattern operator and include EXISTS and NOT/! EXISTS as FILTER functions/constructs
PROPOSED: Include MINUS as a binary graph pattern operator and include EXISTS and NOT/! EXISTS as FILTER functions/constructs ←
18:01:44 <ericP> +1
Eric Prud'hommeaux: +1 ←
18:01:46 <AxelPolleres> ... include MINUS as binary graph pattern OP and include EXISTS as FILTER...
... include MINUS as binary graph pattern OP and include EXISTS as FILTER... ←
18:01:48 <SteveH> +1
Steve Harris: +1 ←
18:02:03 <AxelPolleres> +.99
+.99 ←
18:02:07 <AxelPolleres> +1
+1 ←
18:02:08 <MattPerry> +1
Matthew Perry: +1 ←
18:02:20 <ivan> +1
Ivan Herman: +1 ←
18:02:21 <AlexPassant> +1
Alexandre Passant: +1 ←
18:02:27 <AndyS> +0
Andy Seaborne: +0 ←
18:02:31 <sandro> +1
Sandro Hawke: +1 ←
18:02:44 <bglimm> +1
Birte Glimm: +1 ←
18:02:48 <Souri> +1
Souripriya Das: +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
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
Steve Harris: marginal preference for !, dont dont care ←
18:03:44 <kasei> if we require FILTER keyword, I support !, not NOT
Gregory Williams: if we require FILTER keyword, I support !, not NOT ←
18:03:46 <AxelPolleres> Andy: ! Exists not possible outside the filter
Andy Seaborne: ! Exists not possible outside the filter ←
18:04:08 <AxelPolleres> ... but ! EXISTS not really clear.
... but ! EXISTS not really clear. ←
18:04:34 <AxelPolleres> Andy: why not just make NOT synonymous to !?
Andy Seaborne: why not just make NOT synonymous to !? ←
18:04:51 <AxelPolleres> EricP: don't want to dilute the grammar
Eric Prud'hommeaux: don't want to dilute the grammar ←
18:05:49 <bglimm> s/Any/Andy/
Birte Glimm: s/Any/Andy/ ←
18:06:00 <SteveH> q+
Steve Harris: q+ ←
18:06:05 <LeeF> ack SteveH
Lee Feigenbaum: ack SteveH ←
18:06:05 <AxelPolleres> LeeF: preference in Boston on ! EXISTS
Lee Feigenbaum: preference in Boston on ! EXISTS ←
18:06:27 <SteveH> q-
Steve Harris: q- ←
18:06:39 <AxelPolleres> steve: if only in the FILTER then ASK could be reused instead of a new keyword.
Steve Harris: 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
Andy Seaborne: that's not what I had agreed on ←
18:07:25 <ericP> s/on/to/
Eric Prud'hommeaux: s/on/to/ ←
18:07:35 <LeeF> PROPOSED: The EXISTS filter function is negated with a !
PROPOSED: The EXISTS filter function is negated with a ! ←
18:07:38 <SteveH> +1
Steve Harris: +1 ←
18:07:39 <kasei> q+
Gregory Williams: q+ ←
18:07:44 <LeeF> ack kasei
Lee Feigenbaum: ack kasei ←
18:07:44 <AndyS> -1
Andy Seaborne: -1 ←
18:08:21 <ericP> +1
Eric Prud'hommeaux: +1 ←
18:08:34 <Souri> +1
Souripriya Das: +1 ←
18:08:43 <AndyS> q+
Andy Seaborne: q+ ←
18:08:46 <AxelPolleres> greg: inside a FILTER it seems that '(' ')' enclosing the pattern would seem reasonable
Gregory Williams: inside a FILTER it seems that '(' ')' enclosing the pattern would seem reasonable ←
18:09:01 <LeeF> ack AndyS
Lee Feigenbaum: 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
Lee Feigenbaum: 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
Andy Seaborne: 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
Lee Feigenbaum: 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
Lee Feigenbaum: 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.
Lee Feigenbaum: ... 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
Axel Polleres: 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
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
Ivan Herman: +1 ←
18:13:09 <bglimm> +1
Birte Glimm: +1 ←
18:13:11 <sandro> +0
Sandro Hawke: +0 ←
18:13:14 <SteveH> +0
Steve Harris: +0 ←
18:13:14 <AndyS> +1
Andy Seaborne: +1 ←
18:13:18 <AxelPolleres> 0
0 ←
18:13:22 <AxelPolleres> q+
q+ ←
18:13:26 <ericP> ~0
Eric Prud'hommeaux: ~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
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
Lee Feigenbaum: s/abstraining/ab straining ←
18:13:58 <LeeF> s/ab straining/abstaining
Lee Feigenbaum: 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 ...
Axel Polleres: There would be a solution, to say for entailment we take the scoping graph for matching, then for update we use the ... [ Scribe Assist by Sandro Hawke ] ←
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
Lee Feigenbaum: 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
Trackbot IRC Bot: 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
Lee Feigenbaum: 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
Trackbot IRC Bot: 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
Lee Feigenbaum: 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
Trackbot IRC Bot: 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
Axel Polleres: So you couldn;'t remove inferred triples [ Scribe Assist by Sandro Hawke ] ←
18:14:35 <LeeF> trackbot, close ISSUE-28
Lee Feigenbaum: trackbot, close ISSUE-28 ←
18:14:35 <trackbot> ISSUE-28 Entailment regimes vs. update? closed
Trackbot IRC Bot: ISSUE-28 Entailment regimes vs. update? closed ←
18:14:39 <LeeF> trackbot, close ISSUE-40
Lee Feigenbaum: trackbot, close ISSUE-40 ←
18:14:39 <trackbot> ISSUE-40 How can other entailment regimes plug in their semantics to SPARQL/Update? closed
Trackbot IRC Bot: 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.
Sandro Hawke: +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
Lee Feigenbaum: 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
Birte Glimm: 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 ...
Birte Glimm: on the nexty ISSUE-34 ... ←
18:16:29 <AxelPolleres> ... we treat bnodes as blank nodes as skolem constants and so there's no issue.
... we treat bnodes as blank nodes as skolem constants and so there's no issue. ←
18:16:42 <AxelPolleres> s/bnodes as//
s/bnodes as// ←
18:17:11 <LeeF> PROPOSED: Close ISSUE-34 by accepting the current clearly defined semantics of blank nodes
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.
... proposes to close the issue since the behavior of bnodes is clearly defined by that. ←
18:17:23 <bglimm> +1
Birte Glimm: +1 ←
18:17:24 <AxelPolleres> +
+ ←
18:17:25 <AxelPolleres> +1
+1 ←
18:17:38 <LeeF> RESOLVED: Close ISSUE-34 by accepting the current clearly defined semantics of blank nodes, no objections or abstentions
RESOLVED: Close ISSUE-34 by accepting the current clearly defined semantics of blank nodes, no objections or abstentions ←
18:17:43 <AndyS> +1
Andy Seaborne: +1 ←
18:17:46 <LeeF> trackbot, close ISSUE-34
Lee Feigenbaum: 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
Trackbot IRC Bot: 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
no one objects/abstain ←
18:17:56 <LeeF> http://www.w3.org/2009/sparql/track/issues/42
Lee Feigenbaum: http://www.w3.org/2009/sparql/track/issues/42 ←
18:18:16 <AxelPolleres> LeeF: RDFS and inconsistencies...
Lee Feigenbaum: 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
Birte Glimm: 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.
... 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.
... MAY in the RFC sense. ←
18:19:35 <Souri> q+
Souripriya Das: q+ ←
18:19:40 <LeeF> ack AxelPolleres
Lee Feigenbaum: ack AxelPolleres ←
18:19:42 <LeeF> ack Souri
Lee Feigenbaum: ack Souri ←
18:20:05 <AndyS> q+
Andy Seaborne: q+ ←
18:20:21 <AxelPolleres> souri: we do actually point out if we find inconsistencies in OWL (at loading)
Souripriya Das: we do actually point out if we find inconsistencies in OWL (at loading) ←
18:20:30 <LeeF> ack AndyS
Lee Feigenbaum: 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
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
Andy Seaborne: ack AndyS ←
18:20:45 <AxelPolleres> ... we could just answer with pointing out the inconsistencies
... we could just answer with pointing out the inconsistencies ←
18:20:55 <sandro> +1
Sandro Hawke: +1 ←
18:20:59 <AxelPolleres> Andy: if you have loaded correct data then it is not an issue.
Andy Seaborne: if you have loaded correct data then it is not an issue. ←
18:21:00 <AndyS> +1
Andy Seaborne: +1 ←
18:21:02 <bglimm> +1
Birte Glimm: +1 ←
18:21:03 <AxelPolleres> +1
+1 ←
18:21:04 <Souri> +1
Souripriya Das: +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
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...)
Ivan Herman: 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
Trackbot IRC Bot: 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
Ivan Herman: trackbot, close ISSUE-42 ←
18:21:49 <trackbot> ISSUE-42 TF-ENT What should happen for RDFS entailment in the face of inconsistencies? closed
Trackbot IRC Bot: ISSUE-42 TF-ENT What should happen for RDFS entailment in the face of inconsistencies? closed ←
18:21:51 <AxelPolleres> Birte: current state ...
Birte Glimm: current state ... ←
18:22:08 <AxelPolleres> ... for RDF RDFS the main issues are infinite axiomatic triples.
... for RDF RDFS the main issues are infinite axiomatic triples. ←
18:22:45 <Souri> q+
Souripriya Das: 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.
... 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.
... 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.
... strongly safe fragment of RIF Core is fine. ←
18:24:04 <AxelPolleres> ... sandro asked whether finiteness criterion is really useful.
... sandro asked whether finiteness criterion is really useful. ←
18:24:06 <Souri> q+ to ask about OWL 2 RL profile
Souripriya Das: q+ to ask about OWL 2 RL profile ←
18:24:54 <AxelPolleres> sandro: can't see practical reasons for finiteness criterion.
Sandro Hawke: can't see practical reasons for finiteness criterion. ←
18:25:16 <AxelPolleres> ... think that's only from throeretical concerns.
... think that's only from throeretical concerns. ←
18:25:41 <LeeF> ack Souri
Lee Feigenbaum: ack Souri ←
18:25:41 <Zakim> Souri, you wanted to ask about OWL 2 RL profile
Zakim IRC Bot: 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?
Lee Feigenbaum: sandro, you think that we should not satisfy the finiteness criterion for RIF Core? ←
18:25:54 <LeeF> q?
Lee Feigenbaum: q? ←
18:26:09 <AxelPolleres> Souri: there's a separate issue for OWL2RL?
Souripriya Das: there's a separate issue for OWL2RL? ←
18:26:21 <AxelPolleres> Birte: OWL2RL is fine.
Birte Glimm: 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
Ivan Herman: 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
Lee Feigenbaum: extension mechanism says that we need to guarantee finiteness of answers ←
18:27:38 <AxelPolleres> q+
q+ ←
18:27:42 <LeeF> ack AxelPolleres
Lee Feigenbaum: ack AxelPolleres ←
18:28:51 <sandro> ivan: weaken finiteness restriction from MUST to SHOULD
Ivan Herman: weaken finiteness restriction from MUST to SHOULD [ Scribe Assist by Sandro Hawke ] ←
18:29:06 <AxelPolleres> Axel: I think we have to change the extension mechanism conditions in order to lift the restriction to finiteness.
Axel Polleres: 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
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+
Gregory Williams: q+ ←
18:29:28 <sandro> +1
Sandro Hawke: +1 ←
18:30:48 <LeeF> ack kasei
Lee Feigenbaum: ack kasei ←
18:31:26 <AxelPolleres> Axel: just asking whether there is a way to stream (infinite) results
Axel Polleres: 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?
Gregory Williams: 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
Birte Glimm: We can take the graph + query vocabulary into account ←
18:33:15 <AxelPolleres> ... that shouldn't be a problem.
... 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
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?
Ivan Herman: q? ←
18:33:29 <ivan> +1
Ivan Herman: +1 ←
18:33:34 <sandro> +1
Sandro Hawke: +1 ←
18:33:34 <AxelPolleres> Axel: was thinking of that for D-entailment as well... taking the query vocab into account should solve that.
Axel Polleres: 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
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...:-)
Ivan Herman: 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
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].
Trackbot IRC Bot: 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.
Andy Seaborne: make sure that it's carefully worded. ←
18:34:57 <LeeF> http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JanMar/0468.html
Lee Feigenbaum: 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...
Birte Glimm: 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.
Andy Seaborne: is uniquely specified and is E-equivalent to AG. ←
18:37:24 <AxelPolleres> ... should be rephrased
... should be rephrased ←
18:37:51 <AxelPolleres> Birte: I suggest to send a rephrasing proposal for that one as well
Birte Glimm: 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
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].
Trackbot IRC Bot: 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 ?)
(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
Lee Feigenbaum: http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JanMar/0468.html ←
18:38:17 <AxelPolleres> q+
q+ ←
18:38:21 <LeeF> ack AxelPolleres
Lee Feigenbaum: 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)
Axel Polleres: 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) [ Scribe Assist by Lee Feigenbaum ] ←
18:39:13 <LeeF> ... (2) what these stores do is convert literals with data types to an internal canonical form
Lee Feigenbaum: ... (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
Birte Glimm: "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
Lee Feigenbaum: ... 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
Lee Feigenbaum: ... two questions ←
18:39:37 <LeeF> ... Q1: does this influence the destination of D-entailment?
Lee Feigenbaum: ... Q1: does this influence the destination of D-entailment? ←
18:39:41 <LeeF> ... Birte convinced me "no"
Lee Feigenbaum: ... Birte convinced me "no" ←
18:39:44 <LeeF> ... so Q1 is fine
Lee Feigenbaum: ... 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?
Lee Feigenbaum: ... 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
G: :s :p 1 ←
18:42:12 <AxelPolleres> Q: ASK { :s :p "1.000"^^xs:decimal }
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"
according to the current SPARQL document, I understand that this would return "NO" ←
18:43:02 <AxelPolleres> (on simple entailment)
(on simple entailment) ←
18:44:12 <AxelPolleres> sandro: I would like to support something like D^-.
Sandro Hawke: I would like to support something like D^-. ←
18:44:34 <AxelPolleres> Andy: I wouldn't be implementing corner cases, probably.
Andy Seaborne: 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.
Sandro Hawke: 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. [ Scribe Assist by Sandro Hawke ] ←
18:44:58 <AxelPolleres> Paul: I store as much as I can of the original structure.
Paul Gearon: I store as much as I can of the original structure. ←
18:45:01 <AxelPolleres> q+
q+ ←
18:45:34 <AxelPolleres> Paul: i internally convert a number to union of all the internal representations of that number.
Paul Gearon: 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)
Andy Seaborne: my stores store value for convenient ranges (e.g. +- 56 bits of precision for an integer) [ Scribe Assist by Andy Seaborne ] ←
18:45:47 <AxelPolleres> sandro: isn't that expensive
Sandro Hawke: isn't that expensive ←
18:46:03 <AxelPolleres> paul: not that expensive.
Paul Gearon: not that expensive. ←
18:46:09 <AndyS> and just store lexicial form style otherwise (out of range, bad lexical)
Andy Seaborne: and just store lexicial form style otherwise (out of range, bad lexical) ←
18:46:28 <AndyS> "3"^^xsd:byte
Andy Seaborne: "3"^^xsd:byte ←
18:46:30 <AxelPolleres> greg: how do you ask for 3 as a number?
Gregory Williams: 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?
Sandro Hawke: If I put in 3.0000000....000000 you store all that? ←
18:47:40 <AxelPolleres> paul: yes, because I got complaints
Paul Gearon: yes, because I got complaints ←
18:47:42 <AndyS> Value stores vs derived datatypes
Andy Seaborne: Value stores vs derived datatypes ←
18:47:50 <AxelPolleres> q?
q? ←
18:48:09 <AndyS> Also, currently because of NaN and Inf, TDB does not do xsd:double or xsd:float.
Andy Seaborne: Also, currently because of NaN and Inf, TDB does not do xsd:double or xsd:float. ←
18:48:10 <Souri> q+
Souripriya Das: q+ ←
18:48:15 <LeeF> ack AxelPolleres
Lee Feigenbaum: ack AxelPolleres ←
18:49:09 <LeeF> ack Souri
Lee Feigenbaum: ack Souri ←
18:50:28 <AxelPolleres> Andy: how does D-entailment require RDFS?
Andy Seaborne: how does D-entailment require RDFS? ←
18:50:38 <AndyS> (found it)
Andy Seaborne: (found it) ←
18:50:57 <AndyS> Except for XMLLiterals.
Andy Seaborne: Except for XMLLiterals. ←
18:51:01 <AxelPolleres> Axel: D-interpretat�ions are rdfs-interpretations
Axel Polleres: D-interpretat�ions 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
Souripriya Das: if you have a join of "0.3000000" and "0.3000" , do they match, and which do you return [ Scribe Assist by Sandro Hawke ] ←
18:51:19 <AxelPolleres> Souri: we do canonical value based matching in Oracle
Souripriya Das: we do canonical value based matching in Oracle ←
18:51:26 <sandro> lee: in SPARQL 1.0 they don't match.
Lee Feigenbaum: in SPARQL 1.0 they don't match. [ Scribe Assist by Sandro Hawke ] ←
18:51:32 <AxelPolleres> ... so D^- would be welcome
... so D^- would be welcome ←
18:52:02 <AxelPolleres> sandro: any reasonable implementaiton would do that.
Sandro Hawke: any reasonable implementaiton would do that. ←
18:52:51 <sandro> lee: "Value Entailment" ?
Lee Feigenbaum: "Value Entailment" ? [ Scribe Assist by Sandro Hawke ] ←
18:52:54 <AxelPolleres> ... maybe we need a better name.
... maybe we need a better name. ←
18:53:22 <ivan> s/lee/Andy/
Ivan Herman: s/lee/Andy/ ←
18:53:24 <sandro> +1 value entailment
Sandro Hawke: +1 value entailment ←
18:53:26 <AxelPolleres> LeeF: seems we need no resolution, but consensus that we should go forward with that.
Lee Feigenbaum: 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.
.... i would prefer not to discuss rif:imports now. ←
18:54:02 <AxelPolleres> Birte/Axel: ok to move that to the entailment-TF
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.)
Sandro Hawke: (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)
Lee Feigenbaum: 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
Sandro Hawke: 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.
Gregory Williams: 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.
Sandro Hawke: 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.
... we also will add mediatypes in the service description. ←
18:56:38 <AxelPolleres> ... i.e. we will go format with both resultformats and mediatypes.
... i.e. we will go format with both resultformats and mediatypes. ←
18:56:51 <AxelPolleres> LeeF: more questions on that?
Lee Feigenbaum: more questions on that? ←
18:57:16 <AxelPolleres> Ivan/sandro: discussing namespace reservation...
Ivan/sandro: discussing namespace reservation... ←
18:57:35 <AxelPolleres> sandro: we need a resolution for that
Sandro Hawke: 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
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.
Ivan Herman: 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
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.
Andy Seaborne: 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 ...
Eric Prud'hommeaux: 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)
(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
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
Ivan Herman: +1 ←
19:01:11 <AlexPassant> +1
Alexandre Passant: +1 ←
19:01:17 <AxelPolleres> +1
+1 ←
19:01:30 <sandro> +1
Sandro Hawke: +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
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
Ivan Herman: 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
... 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/
Ivan Herman: got it thanks - http://www.w3.org/TeamSubmission/n3/ [ Scribe Assist by Alexandre Passant ] ←
19:03:09 <AxelPolleres> sandro: as long as there's a stable spec for it, we're fine, practically.
Sandro Hawke: 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
Gregory Williams: http://www.w3.org/2009/sparql/docs/service-description-1.1/xmlspec.xml ←
19:04:06 <AxelPolleres> greg: look at example in Section 4
Gregory Williams: look at example in Section 4 ←
19:04:26 <LeeF> http://www.w3.org/2009/sparql/docs/service-description-1.1/xmlspec.xml#id0x106c0320
Lee Feigenbaum: 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
Gregory Williams: 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
http://www.w3.org/2009/sparql/docs/service-description-1.1/xmlspec.xml#id0x1f954840 ←
19:05:35 <AxelPolleres> greg: explains the example.
Gregory Williams: explains the example. ←
19:06:45 <AxelPolleres> sandro: you're saying here that the name is the graph
Sandro Hawke: 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
Gregory Williams: 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"/>
Sandro Hawke: <sd:named rdf:resource="http://www.example/named-graph"/> ←
19:07:45 <AxelPolleres> greg: seems strange to me to put name in a string
Gregory Williams: seems strange to me to put name in a string ←
19:08:03 <ivan> q+
Ivan Herman: q+ ←
19:08:18 <AxelPolleres> ... some pushback from people since these descriptions can get long.
... some pushback from people since these descriptions can get long. ←
19:08:33 <LeeF> q?
Lee Feigenbaum: q? ←
19:08:50 <LeeF> ack ivan
Lee Feigenbaum: ack ivan ←
19:09:13 <sandro> sandro: I have a problem with something have a "named" which is itself.
Sandro Hawke: I have a problem with something have a "named" which is itself. [ Scribe Assist by Sandro Hawke ] ←
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?
Ivan Herman: 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
Eric Prud'hommeaux: 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.
Gregory Williams: 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/"
Sandro Hawke: 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.
Ivan Herman: 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.
Gregory Williams: 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.
Sandro Hawke: you're providing the name of the thing, not the thing itself. [ Scribe Assist by Sandro Hawke ] ←
19:12:25 <LeeF> sdLnamed <foo> vs. sd:named "foo"^^xsd:anyUri
Lee Feigenbaum: sdLnamed <foo> vs. sd:named "foo"^^xsd:anyUri ←
19:12:26 <LeeF> ?
Lee Feigenbaum: ? ←
19:13:34 <AxelPolleres> 0 (string representation conceptually better, but needs conversion from string to resource if you want to use it?)
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.
Sandro Hawke: 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
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].
Trackbot IRC Bot: 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.
Ivan Herman: 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.
Ivan Herman: 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?
Lee Feigenbaum: 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.
Ivan Herman: we could put some text in the document. ←
19:17:42 <ivan> s/some text/some informative text/
Ivan Herman: s/some text/some informative text/ ←
19:17:55 <sandro> sandro: just use sparql to query the vast sparql service description.
Sandro Hawke: just use sparql to query the vast sparql service description. [ Scribe Assist by Sandro Hawke ] ←
19:18:03 <AxelPolleres> LeeF: so the answer is we could use POWDER for a lot of things, but it's not the default.
Lee Feigenbaum: 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
Lee Feigenbaum: 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.
Gregory Williams: 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.
... if we collapse the description, we loose that feature. ←
19:21:15 <AxelPolleres> ivan: fine, I just asked why two different types of graphs.
Ivan Herman: 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.
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.
Gregory Williams: 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.
Gregory Williams: 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
... one entailment per graph ←
19:26:23 <AxelPolleres> ivan: why? seems unnatural to me.
Ivan Herman: why? seems unnatural to me. ←
19:26:57 <AxelPolleres> souri: we support parametric inference, i.e. you can ask that graph with that entailment...
Souripriya Das: we support parametric inference, i.e. you can ask that graph with that entailment... ←
19:27:18 <AxelPolleres> q+
q+ ←
19:27:24 <bglimm> q+ to say that you could have different endpoints per entailment regime
Birte Glimm: q+ to say that you could have different endpoints per entailment regime ←
19:27:40 <sandro> G1 |= G2
Sandro Hawke: G1 |= G2 ←
19:27:52 <sandro> query G1 or G2 as you like
Sandro Hawke: query G1 or G2 as you like ←
19:28:01 <LeeF> ack AxelPolleres
Lee Feigenbaum: ack AxelPolleres ←
19:28:10 <sandro> G1 |=owl G2 G1 |=rdfs G3
Sandro Hawke: G1 |=owl G2 G1 |=rdfs G3 ←
19:29:03 <SteveH> ...or http://foo.example/graph?entailment=owl
Steve Harris: ...or http://foo.example/graph?entailment=owl ←
19:29:14 <AxelPolleres> what you could do is allow FROM <g,simple> or FROM <g,rdfs> ...
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.
Sandro Hawke: 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.
Sandro Hawke: I want to be able to write down "|=" in the service description. ←
19:30:23 <Souri> q?
Souripriya Das: q? ←
19:30:29 <sandro> q+
Sandro Hawke: q+ ←
19:30:35 <AxelPolleres> greg: we agreed not to describe how to reauest entailment
Gregory Williams: we agreed not to describe how to reauest entailment ←
19:30:41 <LeeF> ack bglimm
Lee Feigenbaum: ack bglimm ←
19:30:41 <Zakim> bglimm, you wanted to say that you could have different endpoints per entailment regime
Zakim IRC Bot: 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
Ivan Herman: 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 ]
Gregory Williams: [ 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
Birte Glimm: 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)
(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.
Andy Seaborne: 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+
Souripriya Das: q+ ←
19:33:37 <AxelPolleres> birte: we only allow OWL, no parameterisation
Birte Glimm: we only allow OWL, no parameterisation ←
19:33:38 <LeeF> ack sandro
Lee Feigenbaum: ack sandro ←
19:33:40 <sandro> q-
Sandro Hawke: q- ←
19:33:44 <LeeF> ack souri
Lee Feigenbaum: ack souri ←
19:33:54 <AxelPolleres> steveH: we only support RDFS in threestore
Steve Harris: we only support RDFS in threestore ←
19:34:10 <AxelPolleres> souri: what about user defined rules.
Souripriya Das: what about user defined rules. ←
19:35:03 <AxelPolleres> axel: that should be possible with rif:imports
Axel Polleres: that should be possible with rif:imports ←
19:35:25 <AxelPolleres> LeeF: so, do we want advertisement of entailmentregime per graph?
Lee Feigenbaum: 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
Gregory Williams: 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?
Birte Glimm: what if a graph has several entailment regimes? ←
19:36:23 <AxelPolleres> andy: cardinality 1 makes sense
Andy Seaborne: cardinality 1 makes sense ←
19:37:00 <LeeF> q?
Lee Feigenbaum: q? ←
19:37:03 <AlexPassant> what about sd:defaultEntailment ent:xx ; sd:entailementRegime ent:YY
Alexandre Passant: what about sd:defaultEntailment ent:xx ; sd:entailementRegime ent:YY ←
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.
Axel Polleres: 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
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].
Trackbot IRC Bot: 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?
q? ←
19:40:03 <AxelPolleres> q?
q? ←
19:40:05 <AxelPolleres> q+
q+ ←
19:41:00 <AxelPolleres> q+ to ask whether we will have time to discuss further planning/publication (we need to)
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
Lee Feigenbaum: 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
Lee Feigenbaum: 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.
... 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
Andy Seaborne: Update: {?x foaf:knows{2} ?y} as triple pattern rewrite may not be so easy ←
19:42:15 <AxelPolleres> davidC: not filled in enough
David Charboneau: not filled in enough ←
19:42:21 <AxelPolleres> ivan: same
Ivan Herman: 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.
Lee Feigenbaum: 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.
.... fine with negated properties, etc., N3 syntax, etc. ←
19:43:41 <AxelPolleres> Alex: agree with allow duplicates, not up to dates with cycles.
Alexandre Passant: 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
Paul Gearon: 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.
Souripriya Das: no duplicates is not a concern, allow duplicates also fine. ←
19:45:39 <AxelPolleres> matt: repition of nodes difficult.
Matthew Perry: repition of nodes difficult. ←
19:45:50 <AxelPolleres> sandro: not followed.
Sandro Hawke: not followed. ←
19:46:06 <AxelPolleres> greg: 0-length paths scare me.
Gregory Williams: 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)
Andy Seaborne: with no duplicates, SELECT COUNT(*) WHERE {?x foaf:knows{2} ?y} return 1, right ? (in the 1st example) [ Scribe Assist by Alexandre Passant ] ←
19:46:40 <AndyS> yes - think so
Andy Seaborne: yes - think so ←
19:46:57 <AlexPassant> ok so Im definitely for allowing duplicate, seems more coherent in that count use case
Alexandre Passant: ok so Im definitely for allowing duplicate, seems more coherent in that count use case ←
19:47:09 <LeeF> distinct!
Lee Feigenbaum: distinct! ←
19:48:01 <AxelPolleres> ?s :p? ?o
?s :p? ?o ←
19:49:56 <AxelPolleres> Axel: duplicates worry me
Axel Polleres: duplicates worry me ←
19:50:19 <AxelPolleres> (see sixDegrees eaxample in my mail, that would blow up tremendously if we have duplicates)
(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.
Steve Harris: I am fine with Andy's proposal so far. ←
19:51:09 <AxelPolleres> andy: can't think about anyting else important at the moment.
Andy Seaborne: 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.
Lee Feigenbaum: eric is 98% done with the basic federated query spec. ←
19:51:51 <AndyS> cool
Andy Seaborne: cool ←
19:51:53 <AxelPolleres> Andy: are there implications on protocol?
Andy Seaborne: are there implications on protocol? ←
19:52:05 <sandro> RRSAgent, make logs public
Sandro Hawke: RRSAgent, make logs public ←
19:52:09 <sandro> RRSAgent, pointer?
Sandro Hawke: RRSAgent, pointer? ←
19:52:09 <RRSAgent> See http://www.w3.org/2010/03/26-sparql-irc#T19-52-09
RRSAgent IRC Bot: 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,
Lee Feigenbaum: 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.
... 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
Lee Feigenbaum: thanks all, thanks hosts, thanks scribes!!! talk on on Tuesday ←
19:54:31 <AxelPolleres> adjourned
adjourned ←
19:54:51 <AxelPolleres> rrsagent, make records public
rrsagent, make records public ←
20:01:23 <kasei> SELECT * WHERE { ?s :* ?o }
(No events recorded for 6 minutes)
Gregory Williams: SELECT * WHERE { ?s :* ?o } ←
Formatted by CommonScribe
This revision (#1) generated 2010-03-29 17:59:58 UTC by 'apollere2', comments: None