Chatlog 2009-11-17

See original RRSAgent log and preview nicely formatted version.

Please justify/explain all edits to this page, in your "edit summary" text.

<LeeF> Present: LeeF, Alex, Kjetil, Sandro, AndyS, SteveH, kasei, pgearon, tommik, dcharbon2, bglimm, john-l, Chimezie, ivanh, Orri, iv_an_ru, prateek
14:44:05 <trackbot> Meeting: SPARQL Working Group Teleconference
14:44:05 <trackbot>  Date: 17 November 2009
14:44:09 <LeeF> Chair: LeeF
14:44:17 <LeeF> Scribenick: pgearon
14:44:22 <LeeF> Regrets: AxelPolleres, LukeWM
14:44:30 <LeeF> Agenda: http://www.w3.org/2009/sparql/wiki/Agenda-2009-11-17
15:03:54 <pgearon> LeeF: threw about 3 meeting worth of stuff into this week's agenda, so we probably won't get through it all
15:03:55 <KjetilK> Zakim, who is on the phone?
15:04:05 <Zakim> On the phone I see AlexPassant, KjetilK (muted), LeeF, kasei (muted), AndyS, bglimm (muted), pgearon, ivanh, Orri, john-l, SteveH, tommik, dcharbon2
15:04:33 <pgearon> LeeF: Go through topics that don't require discussion first, then others
15:04:48 <LeeF> PROPOSED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2009-11-10 
15:04:49 <Zakim> +Chimezie_Ogbuji
15:05:08 <chimezie> chimezie has joined #sparql
15:05:12 <pgearon> LeeF: no minutes from F2F or from the 27th yet
15:05:19 <LeeF> RESOLVED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2009-11-10 
15:05:26 <Zakim> +Sandro
15:06:08 <kasei> I'm at risk for next week.
15:06:10 <pgearon> LeeF: On ivanh's suggestion, now removed OWL from liaison list
15:07:20 <sandro> http://lists.w3.org/Archives/Public/public-rdf-dawg/2009OctDec/0430.html
15:07:36 <pgearon> bglimm: providing summary of entailment call
15:07:48 <sandro> (the echo is probably bglimm, and will go away when she mutes again, I bet.)
15:07:49 <pgearon> bglimm: started on ISSUE-28, entailment update
15:08:17 <pgearon> bglimm: ISSUE-34 interaction with blank nodes, now closed
15:08:47 <pgearon> bglimm: ISSUE-42 RDFS entailment with inconsistency
15:09:04 <pgearon> bglimm: agreed with current implementations raising errors
15:09:09 <LeeF> bglimm: systems may/should raise an error for inconsistency
15:09:32 <pgearon> bglimm: ISSUE-47 (?) entailment on graphs or endpoints
15:10:18 <pgearon> bglimm: need more info to work with RIF
15:10:40 <Zakim> + +0383306aaaa
15:10:51 <sandro> (um, that's not how I recall the RIF issue.    The 'need another editor' was specifically about non-mon logics, which RIF includes.   But that doesn't apply for RIF core or rif BLD.)
15:11:05 <pgearon> bglimm: currently trying to come up with a proposal on entailment for annotations
15:11:07 <iv_an_ru> Zakim, +0383 is me
15:11:07 <Zakim> +iv_an_ru; got it
15:11:14 <bglimm> Zakim, mute me
15:11:14 <Zakim> bglimm should now be muted
15:11:28 <iv_an_ru> (finally connected :)
15:11:50 <kasei> pgearon, s/47/43/
15:11:55 <bglimm> Sandro, I always said, even before that telecon that I don't feel confident about RIF and either Axel helps me with that or we need another co-editor
15:11:57 <LeeF> topic: query issues from f2f
15:11:59 <LeeF> PROPOSED: Resolve ISSUE-11 by noting that it's invalid to project variables/functions on variables that are not included in the GROUP BY clause and also nothing that what this means in practice depends on ISSUE-41 
15:13:29 <LeeF> Orri: seconded
15:13:34 <SteveH_> included isn't enough
15:13:34 <bglimm> Axel wanted to help with RIF core, but I'm not sure whether he will find the time or not. 
15:14:02 <SteveH_> e.g. GROUP BY ?x+?Y
15:14:11 <LeeF> PROPOSED: Resolve ISSUE-11 by noting that it's invalid to project variables/functions on variables that are not exactly the GROUP BY clause and also nothing that what this means in practice depends on ISSUE-41 
15:14:41 <LeeF> RESOLVED: Resolve ISSUE-11 by noting that it's invalid to project variables/functions on variables that are not exactly the GROUP BY clause and also nothing that what this means in practice depends on ISSUE-41 
15:14:49 <LeeF> no abstentions or objections
15:14:51 <Prateek> Prateek has joined #sparql
15:14:55 <LeeF> trackbot, close ISSUE-11
15:14:56 <trackbot> ISSUE-11 Implicit vs explicit GROUPing closed
15:15:13 <Zakim> +Prateek
15:15:16 <LeeF> PROPOSED: Asterisk is a valid argument to COUNT, but not to other aggregate functions, and not to custom aggregates
15:15:20 <AndyS> I register agrement with Steve on the imprecise wording 
15:15:24 <AndyS> (prev point)
15:15:39 <KjetilK> +1
15:15:42 <pgearon> seconded
15:15:42 <SteveH_> +1
15:15:44 <ivanh> +1
15:15:49 <iv_an_ru> +1
15:15:51 <LeeF> RESOLVED: Asterisk is a valid argument to COUNT, but not to other aggregate functions, and not to custom aggregates, no abstentions or objections
15:15:52 <bglimm> +1
15:16:37 <LeeF> PROPOSED: SPARQL 1.1 does not inlude any subqueries other than sub-selects in graph patterns, noting that the question of an EXISTS FILTER form is still pending 
15:16:44 <pgearon> LeeF: holding off on third item, due to need for discussion on unbound variables
15:17:17 <SteveH_> +1
15:17:21 <AndyS> abstain
15:17:22 <pgearon> +1
15:17:29 <iv_an_ru> +0.001
15:17:31 <chimezie> abstain
15:17:35 <bglimm> +1
15:17:36 <john-l> abstain
15:17:36 <LeeF> RESOLVED: SPARQL 1.1 does not inlude any subqueries other than sub-selects in graph patterns, noting that the question of an EXISTS FILTER form is still pending, AndyS, chimezie, pgearon abstaining
15:17:37 <tommik> +1
15:17:40 <pgearon> actually, I'm going to change to an abstain (sorry)
15:18:28 <AndyS> q+
15:18:40 <pgearon> Orri: concern about not having an option for EXISTS
15:18:46 <iv_an_ru> Yes, exists can be rewritten as OPTIONAL
15:19:00 <LeeF> ack AndyS
15:19:11 <iv_an_ru> but existing SQL optimizers tend to disagree with me :)
15:19:27 <pgearon> AndyS: orri was describing a NOT EXISTS or EXISTS outside of a filter
15:19:37 <SteveH_> { EXISTS } UNION { EXISTS }
15:20:00 <AndyS> Not quite the same.
15:20:02 <LeeF> zakim, who's on the phone?
15:20:02 <Zakim> On the phone I see AlexPassant, KjetilK (muted), LeeF, kasei (muted), AndyS, bglimm (muted), pgearon, ivanh, Orri, john-l, SteveH, tommik, dcharbon2, Chimezie_Ogbuji, Sandro,
15:20:05 <Zakim> ... iv_an_ru, Prateek
15:20:05 <SteveH_> no, but similar
15:20:37 <pgearon> LeeF: asking abstainers what their concerns are
15:22:22 <chimezie> Basically, there is a use case where you want to capture an exclusion criteria (match X but not Y), where Y is a Group Graph Pattern itself
15:22:38 <chimezie> I'm not 100% if that scenario is covered by the EXISTS FILTER form alternative
15:23:45 <LeeF> subtopic: name for coalesce
15:24:10 <iv_an_ru> One of bad cases is an expression like (A or exists (X) or exists (Y) or exists (Z)) --- too much joins if turned into OPTIONALs.
15:24:26 <pgearon> LeeF: coalesce is an SQL term that returns the first value that evaluates as non-null
15:24:58 <pgearon> LeeF: in SPARQL we are looking at returning the first value that doesn't result in an unbound or a type error
15:25:22 <SteveH_> not just SQL it's used in general computer science
15:25:31 <pgearon> LeeF: proposed names: coalesce, first_bound, left_most, try, others....
15:25:41 <SteveH_> q+
15:25:45 <LeeF> ack SteveH_
15:25:51 <AndyS> TRY > FIRST > LEFTMOST > 0 > others
15:26:22 <iv_an_ru> Will I explain any other name as "X is an other name for COALESCE" ? :)
15:26:22 <KjetilK> q+
15:26:27 <AlexPassant> its however obscure for non english speakers / non-sql people
15:26:33 <LeeF> ack KjetilK
15:26:49 <SteveH_> AlexPassant, and people who don't know the computer science meaning
15:27:08 <chimezie> I would almost suggest REDUCE via abuse of notation, but I don't want to hamper progress
15:27:13 <pgearon> kjetil: aren't we using a different meaning to compsci and SQL?
15:27:21 <SteveH_> no, same meaning
15:27:31 <SteveH_> http://en.wikipedia.org/wiki/Null_coalescing_operator
15:27:33 <AndyS> Different to SQL(errors)
15:27:58 <LeeF> strawpoll: COALESCE 
15:28:02 <SteveH_> +1
15:28:04 <john-l> +1
15:28:06 <KjetilK> 0
15:28:06 <chimezie> +1
15:28:06 <ivanh> 0
15:28:07 <sandro> 0
15:28:08 <davidcharboneau_> 0
15:28:09 <AlexPassant> 0
15:28:09 <kasei> 0
15:28:10 <LeeF> +1
15:28:10 <bglimm> +1
15:28:10 <Prateek> 0
15:28:10 <iv_an_ru> +1
15:28:11 <tommik> 0
15:28:15 <AndyS> 0
15:28:15 <pgearon> 0
15:28:18 <LeeF> Orri: +1
15:28:26 <pgearon> I note that the title of that Wikipedia article is "Null" coalescing article
15:28:38 <LeeF> strawpoll: TRY
15:28:45 <tommik> 0
15:28:45 <SteveH_> 0
15:28:46 <KjetilK> +1
15:28:47 <john-l> 0
15:28:47 <pgearon> +1
15:28:48 <iv_an_ru> -1
15:28:48 <bglimm> 0
15:28:49 <sandro> 0
15:28:51 <AndyS> +1
15:28:51 <ivanh> 1
15:28:52 <chimezie> 0
15:28:52 <LeeF> 0
15:28:53 <AlexPassant> 0
15:28:53 <davidcharboneau_> 0
15:28:55 <kasei> -1
15:29:08 <LeeF> strawpoll: FIRST_BOUND
15:29:08 <Prateek> 0
15:29:11 <KjetilK> +1
15:29:12 <tommik> 0
15:29:12 <SteveH_> -1
15:29:12 <pgearon> -1
15:29:12 <john-l> +1
15:29:13 <AlexPassant> +1
15:29:14 <davidcharboneau_> +1
15:29:14 <bglimm> 0
15:29:15 <AndyS> -1
15:29:17 <chimezie> +1
15:29:19 <LeeF> +1
15:29:20 <sandro> 0
15:29:20 <ivanh> 1
15:29:22 <iv_an_ru> TRY without a CATCH will damage my C++ed brains.
15:29:30 <iv_an_ru> -1
15:29:50 <sandro> first_value?
15:30:07 <bglimm> yes
15:30:11 <ivanh> sorry...
15:30:12 <iv_an_ru> BTW, do we support '_' in other "words", like names?
15:30:19 <LeeF> strawpoll: leftmost
15:30:25 <SteveH_> -1
15:30:25 <pgearon> -1
15:30:27 <kasei> -1
15:30:27 <john-l> 0
15:30:27 <ivanh> 0
15:30:28 <tommik> 0
15:30:28 <AndyS> 0
15:30:28 <AlexPassant> 0
15:30:28 <chimezie> -1
15:30:29 <sandro> -1
15:30:31 <KjetilK> 0
15:30:32 <LeeF> 0
15:30:35 <Prateek> 0
15:30:39 <davidcharboneau_> -1
15:30:40 <iv_an_ru> -1, LEFTMOST is -Inf :)
15:30:41 <bglimm> 0
15:30:51 <sandro> (I like FIRSTVALUE, my self.)
15:31:24 <LeeF> Note general consensus around "COALESCE"
15:31:44 <pgearon> LeeF: Do projected expressions require an alias?
15:32:02 <LeeF> (?x+?y)
15:32:19 <pgearon> LeeF: F2F came to mild consensus that aliases would be required
15:32:26 <SteveH_> q+
15:32:29 <LeeF> ack SteveH_
15:32:38 <pgearon> LeeF: thinks AndyS mildly disagreed
15:32:45 <kasei> I'm with AndyS against it.
15:33:03 <SteveH_> SELECT (1+2)
15:33:12 <AndyS>  Example: SELECT count(*) { ... }
15:33:13 <pgearon> SteveH_: thinks that it might be better to put it off to the next SPARQL, rather than allowing it now and needing to remove it later
15:33:37 <chimezie> but don't you *have* to bind it to a variable to be in a solution set?
15:33:39 <pgearon> (referring to unaliased projections)
15:33:41 <chimezie> or am I missing something
15:33:47 <SteveH_> ?`(1+2)` is not going to be fun :)
15:34:10 <LeeF> strawpoll on requiring aliases for expressions - please vote "required", "not required", or "don't care"
15:34:15 <pgearon> many APIs allow column selection by index, not just by name
15:34:23 <davidcharboneau_> required
15:34:24 <SteveH_> required
15:34:25 <chimezie> required
15:34:25 <kasei> not required
15:34:25 <LeeF> Orri: required
15:34:26 <AndyS> not required
15:34:26 <iv_an_ru> required
15:34:28 <pgearon> required
15:34:31 <ivanh> required
15:34:32 <LeeF> don't care
15:34:35 <tommik> don't care
15:34:35 <bglimm> don't care
15:34:39 <john-l> don't care
15:34:39 <Prateek> don't care
15:34:48 <KjetilK> don't care
15:34:59 <iv_an_ru> BTW "AS" between expressions helps to localize syntax errors
15:35:09 <pgearon> I think it would be a valid extension to not require it, wouldn't it?
15:35:14 <LeeF> Notes definite preference for requiring aliases
15:35:29 <LeeF> subtopic: HAVING vs. FILTER
15:36:52 <pgearon> LeeF: in SPARQL HAVING must happen after the main query pattern, so we don't need a separate name like SQL needs
15:37:16 <pgearon> LeeF: so do we copy SQL and use SQL's HAVING, or re-use FILTER?
15:37:32 <SteveH_> WHERE { ... } GROUP BY ?x FILTER( SUM(?y) > 2)
15:37:37 <pgearon> AndyS: must appear after the GROUP BY
15:37:41 <chimezie> Re-using FILTER seems intuitive to me, especially since its use with aggregates clearly delineates the 2 use cases
15:37:45 <iv_an_ru> I've implemented HAVING yesterday in Virtuoso. Convenient...
15:37:51 <AndyS> {... } GROUP BY - HAVING } ...
15:38:28 <LeeF> strawpoll: HAVING vs. FILTER vs. don't care
15:38:29 <pgearon> HAVING
15:38:30 <AlexPassant> FILTER
15:38:31 <kasei> filter
15:38:33 <bglimm> HAVING
15:38:35 <iv_an_ru> HAVING
15:38:36 <chimezie> FILTER
15:38:37 <ivanh> don't care
15:38:37 <SteveH_> don't care
15:38:38 <davidcharboneau_> don't care
15:38:39 <tommik> don't care
15:38:39 <LeeF> don't care
15:38:45 <john-l> don't care
15:38:47 <KjetilK> don't care
15:38:48 <AndyS> HAVING but too early to decide (cutom aggregates)
15:38:49 <Prateek>  don't care
15:39:01 <pgearon> wow, close one
15:39:03 <AndyS> s/cutom/custom/
15:39:05 <iv_an_ru> One more keyword --- one less redundand flexibility fo making errors.
15:39:12 <SteveH_> leave it to editors?
15:39:49 <LeeF> Leave it up to the editors.
15:40:11 <pgearon> LeeF: commas in SELECT list?
15:40:15 <LeeF> (expr AS ?var)
15:41:20 <AndyS> Optional commas, please
15:41:26 <iv_an_ru> We have now optional commas in select lists
15:41:32 <SteveH_> Optional commas is the worst possible outcome
15:41:33 <pgearon> do we?
15:41:34 <SteveH_> IMHO
15:41:39 <LeeF> strawpoll: commas required, brackets required, either allowed, don't care
15:42:32 <iv_an_ru> we have required (...):  (expr) as ?var  but optional commas
15:42:49 <pgearon> AndyS: concern that commas and brackets are distinct and shouldn't be voted on as one vs the other
15:43:19 <iv_an_ru> It's easier to close compiler's eyes on extra commas than to explain the syntax to every SQL-minded developer
15:43:42 <AndyS> Agree with iv_an_ru
15:44:12 <SteveH_> letter them?
15:44:16 <iv_an_ru> Maybe it'ssafer to permit either a list without commas or a list with all commas but not a list with few optional commas.
15:44:22 <LeeF> strawpoll: 1. commas required, 2. (expr AS ?var) required, 3. (expr) AS ?var required. 2 + optional commas, 3 + optional commas
15:45:02 <kasei> 2
15:45:04 <ivanh> 2
15:45:04 <chimezie> 3
15:45:04 <SteveH_> 2
15:45:05 <AlexPassant> 3
15:45:07 <davidcharboneau_> 3
15:45:09 <AndyS> 2+opt commas or 2
15:45:12 <LeeF> Orri: 3 + optional commas
15:45:12 <iv_an_ru> 3+ optional commas
15:45:14 <LeeF> 2
15:45:17 <bglimm> 3+ optional commas (but no strong preference)
15:45:19 <john-l> 3
15:45:23 <KjetilK> 2
15:45:24 <pgearon> 2 + optional commas
15:45:25 <tommik> 2
15:45:32 <Prateek> 2
15:45:59 <LeeF> Notes overall group preference for 2. (expr AS ?var)
15:46:57 <pgearon> LeeF: should now discuss aggregates and mixed data types
15:47:22 <pgearon> LeeF: what to do with MIN with strings, integers, dates, etc
15:48:03 <pgearon> LeeF: F2F also discussed SUM, AVG, etc. Thought to use semantics of "+"
15:48:46 <pgearon> LeeF: this propagates errors. Casts and COALESCE could overcome some of this. But AndyS showed that it isn't quite the same behaviour
15:49:35 <SteveH_> SPARQL doesn't have a NULL technically speaking
15:49:56 <pgearon> orri: why not skip over nulls for sum (skip over errors and unbound)
15:50:47 <SteveH_> +1 to testcases and usecases
15:51:02 <pgearon> AndyS: want to check common cases. Complicated cases are good for testing, but not needed so much for designing
15:51:35 <SteveH_> we haven't looked at any complicated cases yet
15:52:33 <pgearon> AndyS: thinks the common case is a 1-level query and what ends up in the result set. Wants to get down to use cases to make sure the group is all on the same page
15:53:01 <pgearon> LeeF: need to define semantics
15:53:20 <pgearon> AndyS: want to define semantics, but don't let corner cases drive the semantics
15:54:24 <Zakim> -Sandro
15:54:34 <KjetilK> This is fixed, and hard to do, but perhaps relevant: http://lists.w3.org/Archives/Public/public-lod/2009Jun/0272.html ?
15:55:23 <pgearon> LeeF: thinks that this isn't an issue that we'll progress on in a teleconference
15:55:24 <KjetilK> q+
15:55:29 <KjetilK> ack me
15:55:57 <iv_an_ru> TPC-H is a good use case ;)
15:56:22 <SteveH_> -1 to TPC-H as a usecase :)
15:56:31 <AndyS> q+
15:56:36 <KjetilK> Zakim, mute me
15:56:36 <Zakim> KjetilK should now be muted
15:56:38 <LeeF> ack AndyS
15:57:18 <SteveH_> yes, agreed with Andy
15:57:26 <pgearon> AndyS: can we hear an example of problem?
15:57:27 <SteveH_> should look harder at what to do with errors
15:59:22 <kasei> i'll have some service description stuff. will send an email about it this week.
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00000429