13:53:34 RRSAgent has joined #sparql
13:53:34 logging to http://www.w3.org/2010/11/02-sparql-irc
13:53:36 RRSAgent, make logs world
13:53:38 Zakim, this will be 77277
13:53:38 ok, trackbot; I see SW_(SPARQL)10:00AM scheduled to start in 7 minutes
13:53:39 Meeting: SPARQL Working Group Teleconference
13:53:39 Date: 02 November 2010
13:53:41 zakim, this will be SPARQL
13:53:41 ok, LeeF; I see SW_(SPARQL)10:00AM scheduled to start in 7 minutes
13:58:06 SW_(SPARQL)10:00AM has now started
13:58:13 + +1.617.245.aaaa
13:58:20 AlexPassant, AndyS, AxelPolleres, bglimm, ivan, NicoM -- the call starts in 5 minutes today :)
13:58:26 zakim, aaaa is me
13:58:26 +LeeF; got it
13:58:36 Chair: Lee Feigenbaum
13:58:38 +??P17
13:58:45 zakim, ??P17 is me
13:58:45 +AndyS; got it
13:59:01 zakim, dial ivan-voip
13:59:01 ok, ivan; the call is being made
13:59:02 +Ivan
13:59:07 Regrets: Carlos, Souri, Sandro
13:59:10 +NicoM
13:59:23 Agenda: http://www.w3.org/2009/sparql/wiki/Agenda-2010-11-02
13:59:43 +bglimm
13:59:59 hrm. cambridge zakim just dropped my call.
14:00:11 zakim, please be nicer to kasei
14:00:11 I don't understand 'please be nicer to kasei', LeeF
14:00:24 Zakim, mute me
14:00:24 bglimm should now be muted
14:00:27 + +1.310.729.aabb
14:00:37 Zakim, aabb is me
14:00:37 +kasei; got it
14:00:38 zakim, thanks
14:00:38 you are very welcome, LeeF
14:01:35 Zakim, mute me
14:01:35 kasei should now be muted
14:01:40 +MattPerry
14:02:42 zakim, who's on the phone?
14:02:42 On the phone I see LeeF, AndyS, Ivan, NicoM, bglimm (muted), kasei (muted), MattPerry
14:03:07 topic: Admin
14:03:16 PROPOSED: Approve minutes from http://www.w3.org/2009/sparql/meeting/2010-10-26
14:03:23 + +3539149aacc
14:03:39 Zakim, +3539149aacc is me
14:03:39 +AlexPassant; got it
14:04:15 Scribenick: AlexPassant
14:04:22 +pgearon
14:05:45 +[IPcaller]
14:06:17 MattPerry has joined #sparql
14:06:57 Hi Lee
14:07:34 zakim, IPcaller is SteveH
14:07:34 +SteveH; got it
14:07:43 zakim, who's on the phone?
14:07:43 On the phone I see LeeF, AndyS, Ivan, NicoM, bglimm (muted), kasei (muted), MattPerry, AlexPassant, pgearon, SteveH
14:07:56 SteveH has joined #sparql
14:08:11 RESOLVED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2010-10-26
14:08:25 Next regular meeting: 2010-11-09 @ 15:00 UK / 10:00 EST (scribe: Chime Ogbuji)
14:08:30 Zakim, who's on the phone?
14:08:30 On the phone I see LeeF, AndyS, Ivan, NicoM, bglimm (muted), kasei (muted), MattPerry, AlexPassant, pgearon, SteveH
14:08:37 LeeF: Any changes on last week minutes ?
14:08:39 Next week is ISWC
14:08:50 ... some people at ISWC next week
14:08:54 I will be at iswc
14:08:55 will be at ISWC
14:08:56 I'll be there
14:08:58 ... but meeting back at normal time
14:09:00 I'll be at ISWC
14:09:39 ... ISWC attendees will probably won't join
14:10:02 ... but regular call with people that can attend
14:11:04 ... agenda for next week: shortcuts for updates
14:11:17 ... one of the full remaining thing to formalise grammar in update / query
14:11:29 yes - getting the grammar sorted would help me.
14:12:54 LeeF, got a glass roof?
14:13:13 topic: SELECT * behavior
14:14:01 LeeF: need to agree on the select * behavior
14:14:20 ... in-scope variables (bound variables)
14:14:25 ... consensus around that
14:14:43 ... shouldn't select variables inside the subquery
14:14:58 seems that SELECT * { { SELECT ?x { ... ?x ?y ... } } } just means ?x
14:15:19 agree
14:15:20 +1 absolutely
14:15:22 +1
14:15:31 +1
14:15:31 1
14:16:15 ... what about variables that are hidden as being part of aggregate query but not in a GROUP BY
14:16:22 SELECT * { ... ?x ?y ... } GROUP BY ?x
14:16:43 that's the same as SELECT DISTINCT ?x { ... ?x ?y ... }
14:17:21 1/ * stands for ?x and ?y, so this query is an error because you can't select ?y
14:17:42 2/ * stands for only the variables that are legally select'able at this point - which means just ?x because of the aggregating
14:17:49 ... if you limit it to just "bindable" ones
14:18:28 I think we're in a position to descide
14:18:32 ... is there any option besides these 2 ones ?
14:18:32 ... if not, can we decide between both ?
14:18:41 q+
14:19:21 ack SteveH
14:19:31 AndyS: not in my case, but it wouldn't be too hard to use that machinery instead
14:20:08 +AxelPolleres
14:20:30 I find that it is useful
14:20:47 where?
14:20:49 I think it's quite useful
14:21:16 what about the semantic conflict with COUNT(*)
14:21:19 Are we discussing whther star is useful at all? Yes, but sound is quite bad
14:21:34 2
14:21:51 in 4store it's all
14:21:56 1) I think
14:21:58 LeeF: any implementation doing * and aggregate ?
14:22:25 I think it would be rather odd to design the language such that using * is guaranteed to produce an error in lots of queries.
14:22:28 Zakim, who is on the phone?
14:22:28 On the phone I see LeeF, AndyS, Ivan, NicoM, bglimm (muted), kasei (muted), MattPerry, AlexPassant, pgearon, SteveH, AxelPolleres
14:22:44 kasei, well SQL works that way, it's never bothered me
14:23:30 ... strawpoll
14:23:35 straw poll: 1 "all", 2 "legal", 0 "don't really care too much"
14:23:39 1
14:23:39 1
14:23:40 2
14:23:42 0
14:23:43 2
14:23:44 0
14:23:44 1
14:23:46 0
14:23:46 0
14:23:47 0
14:23:48 2 (mildly)
14:24:48 LeeF: which decision will be easier to change if we've done the wrong one
14:24:55 ... or if people implementing the other way
14:24:58 OlivierCorby has joined #sparql
14:25:01 ... any thoughts ?
14:25:03 legal can be extended later :-9
14:25:16 AndyS, I just meant the dramatically different meanings
14:25:34 2 makes more sense to me if I were a user. 1 will be easier as an implementor. I can live with either
14:25:45 I would find different meaning of * in COUNT and SELECT weird... that's one point for 2
14:25:48 or no?
14:25:50 ... slight personal preference for 1
14:26:06 AxelPolleres, no, because then COUNT(*) and SLEECT(*) would bare no resemblance
14:26:19 er, SELECT *
14:26:35 SteveH, are you proposing no SELECT * at all?
14:26:39 ... if no new suggestion, tempted to say that we'll do 1
14:26:44 ... but happy to hear additional suggestions
14:26:49 AndyS, no, just that it would mean all in-scope variables
14:27:04 no just the ones that can legally be used in scalar expressions
14:27:08 *not...
14:27:46 I can write SELECT COUNT(?a) WHERE { ... } GROUP BY ?b, so ?a is in scopew
14:28:58 I can write SELECT (COUNT(?a) AS ?ca) WHERE { ... } GROUP BY ?b, so ?a is in scopew
14:29:02 this is where the "potentially bound" terminology might have been slightly clearer than "in scope"
14:29:06 what about: SELECT * WHERE { ... } GROUP BY (?a + ?b / 2)
14:29:15 + +34.92.38.aadd
14:29:41 Zakim, aadd is me
14:29:41 +OlivierCorby; got it
14:29:52 A little bit late ...
14:30:11 matt, according to 1) that would be forbidden, yes?
14:30:23 AxelPolleres, no, it would just be an error
14:30:30 according to 2) that would be like ASK?
14:30:57 AndyS: problem of semantic equivalence of the 2 expressions
14:31:06 steveH, what's the diff between "an error" and "forbidden" for you here? ;-)
14:31:27 LeeF: anyone change his mind ?
14:31:40 would consider objecting
14:31:50 I really prefer 1, but wouldn't formally object
14:31:51 ... anybody feels strongly about this and would raise objection ?
14:31:51 I'm going to be very unhappy, but probably won't object.
14:32:05 I might be less upset if anyone had a real use?
14:32:20 just seems like pointless syntax messing
14:32:25 No consensus.
14:32:35 SteveH, same as SELECT * in 1.0 -- it's a really useful shortcut.
14:32:54 kasei, but it's not useful in this case, it's just longhand for SELECT DISTINCT
14:32:59 I'm happy with 1. As for using it to see what variables are in scope, then using 1 can give you errors to say what *isn't* in scope
14:33:46 Given the lack of consensus, the chair decides towards option 1 based on potential objections and the chair's belief that option 1 leaves more options open in the future and leads to more interoperability if all implementations do not implement this the same way.
14:33:47 oh, I was under the impression that it could be combined with project exprs also...
14:34:01 option 1 also gives us to possibility of MAX(*) etc. in the future
14:34:06 I object.
14:34:43 AndyS: is there any list of objections ?
14:34:48 LeeF: no formal objections so far
14:35:43 LeeF: Please mail any formal objections to the mailing list so that we have an official record and URI for them. Thanks.
14:35:52 We still have an open issue which is a bit related (that was the second place where we'd discussed about the definition of "inscope" or "potentially bound"... "The new variable is introduced using the keyword AS; it must not already be potentially bound."
14:36:10 topic: BIND and FILTER order execution
14:36:15 topic: BIND + FILTER
14:36:21 http://lists.w3.org/Archives/Public/public-rdf-dawg/2010OctDec/0154.html
14:36:33 q+ to mention still open issue on prev. topic
14:36:42 ack AxelPolleres
14:36:42 AxelPolleres, you wanted to mention still open issue on prev. topic
14:37:24 What is the issue number?
14:38:43 no issue number assigned yet, left open in disussion of last time... will ask again in the end whether we should open an issue.
14:38:53 PREFIX :
14:38:53 SELECT ?s ?p ?o ?z
14:38:53 {
14:38:53 ?s ?p ?o .
14:38:53 FILTER(?z = 3 )
14:38:53 BIND(?o+1 AS ?z)
14:38:55 }
14:40:01 AndyS: implementaion acts differently
14:40:24 ... BIND does not have the semantics of LET
14:40:34 ... so it will not act as a filter
14:40:43 ... no error if you assign to an existing variable
14:41:51 LeeF, do you preserve the lexical ordering amongst the BINDs when you "shove" them to the end of the BGP?
14:42:54 q+
14:43:39 I have a mild preference for lexical ordering.
14:44:35 ack kasei
14:44:37 Zakim, unmute me
14:44:37 kasei was not muted, kasei
14:45:03 kasei: lexical order is much more intuitive when reading a query
14:45:12 kasei: but would filter floating mean that this is floating order?
14:45:58 { ?s ?p ?o . FILTER(?z = 3 )
14:45:59 BIND(?o+1 AS ?z)
14:45:59 }
14:45:59 shouldn't that mean the same as
14:45:59 { { ?s ?p ?o . FILTER(?z = 3 ) }
14:46:01 BIND(?o+1 AS ?z)
14:46:02 }
14:46:04 ?
14:46:22 LeeF: support from Axel, paul and greg that FILTER will fail in that case
14:46:22 at least that's how I understood the earlier resolution
14:46:27 ... any different POV ?
14:47:23 Consensus around FILTERs and BINDs happening in lexical order a.k.a BIND is "just outside" a BGP, rather than at the end of it
14:47:46 topic: + for fn:concat ?
14:47:58 Zakim, mute me
14:47:58 kasei should now be muted
14:48:22 STRONG preference for not overloading
14:48:40 LeeF: question about the + operator
14:48:44 ... overloaed for string operation
14:48:50 ... most reponses where against that
14:49:04 ... but need for operator for string concatenation
14:49:24 How would that work for SELECT (?a + ?b) AS ?c WHERE ...
14:49:47 AndyS: naturally wrote that in the query
14:49:51 ARQ implements -- it's a legal extension to expression evaluation anyway.
14:50:18 I think "1" + "2" (plain literals) is going to produce unexpected results for people.
14:50:47 q?
14:51:16 +q
14:51:29 LeeF: strawpoll for + in string concatenation
14:51:37 straw poll: Using + operator for string concatenation
14:52:12 straw poll: Using + operator for string concatenation (no implicit casting)
14:52:17 -1
14:52:20 +1 in favor / 0 don't care / -1 against
14:52:23 -1
14:52:26 +1
14:52:27 0
14:52:27 -1
14:52:29 0
14:52:30 0
14:52:31 +1
14:52:32 +1
14:52:34 +1
14:52:35 +1
14:52:44 meaning 0 + "str" wouldn't work, but "0"+" str" would ?
14:52:52 0
14:53:01 5 / 3 / 3
14:54:20 no xs:string?
14:54:37 ... by example was meant just to clarify that no casting implicit
14:54:44 LeeF: preference to include this
14:55:06 ?x + "str" worries me a bit still
14:55:39 but str(?x) + str" would work "
14:55:56 SteveH, Doing more than the spec requires (e.g. xs:string) is legal as an extension. Can add URI+string if you want :-)
14:56:10 AndyS, erg!
14:56:12 ACTION: AxelPolleres to come up with test cases around + for string concatenation
14:56:12 Sorry, couldn't find user - AxelPolleres
14:56:21 ACTION: Axel to come up with test cases around + for string concatenation
14:56:21