SPARQL Working Group Teleconference

Minutes of 26 March 2010

Seen
Alexandre Passant, Andy Seaborne, Axel Polleres, Birte Glimm, David Charboneau, Eric Prud'hommeaux, Gregory Williams, Ivan Herman, Lee Feigenbaum, Matthew Perry, Paul Gearon, Sandro Hawke, Souripriya Das, Steve Harris
Scribe
Gregory Williams, Lee Feigenbaum, Alexandre Passant, Axel Polleres
IRC Log
Original and Editable Wiki Version
Resolutions
  1. go for Option 1 (error anywhere in tuple -> tupe not passed down (~whole tuple an error)) on COUNT and allow multi-argument counts. link
  2. 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 link
  3. keep SUM as a single argument aggregate, no SUM(*), 3 abstain, no objections link
  4. GROUP_CONCAT syntax shall be GROUP_CONCAT(a, b; separator = ",") link
  5. to keep GROUP_CONCAT single expression, one abstain, no objections link
  6. Close ISSUE-41 with the agreemen to go forward with what's in the current grammar link
  7. Negation syntax is via the "NOT EXISTS" keywords, bglimm and sandro abstaining link
  8. Include MINUS as a binary graph pattern operator and include EXISTS and NOT/! EXISTS as FILTER functions/constructs, AndyS abstaining link
  9. 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 link
  10. Close ISSUE-34 by accepting the current clearly defined semantics of blank nodes, no objections or abstentions link
  11. 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 link
  12. Update the SPARQL Query BGP entailment extension mechanism to weaken the requirement on finite answers to be a suggestion, no objections or abstentions link
  13. 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 link
Topics
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)

1. SPARQL 1.1 Query

12:07:43 <LeeF> subtopic: Aggregates

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

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

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

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

David Charboneau: 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

Gregory Williams: 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

David Charboneau: 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

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

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

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

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

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

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