13:53:34 <RRSAgent> RRSAgent has joined #sparql
13:53:34 <RRSAgent> logging to http://www.w3.org/2010/11/02-sparql-irc
13:53:36 <trackbot> RRSAgent, make logs world
13:53:38 <trackbot> Zakim, this will be 77277
13:53:38 <Zakim> ok, trackbot; I see SW_(SPARQL)10:00AM scheduled to start in 7 minutes
13:53:39 <trackbot> Meeting: SPARQL Working Group Teleconference
13:53:39 <trackbot> Date: 02 November 2010
13:53:41 <LeeF> zakim, this will be SPARQL 
13:53:41 <Zakim> ok, LeeF; I see SW_(SPARQL)10:00AM scheduled to start in 7 minutes
13:58:06 <Zakim> SW_(SPARQL)10:00AM has now started
13:58:13 <Zakim> + +1.617.245.aaaa
13:58:20 <LeeF> AlexPassant, AndyS, AxelPolleres, bglimm, ivan, NicoM -- the call starts in 5 minutes today :)
13:58:26 <LeeF> zakim, aaaa is me
13:58:26 <Zakim> +LeeF; got it
13:58:36 <LeeF> Chair: Lee Feigenbaum
13:58:38 <Zakim> +??P17
13:58:45 <AndyS> zakim, ??P17 is me
13:58:45 <Zakim> +AndyS; got it
13:59:01 <ivan> zakim, dial ivan-voip
13:59:01 <Zakim> ok, ivan; the call is being made
13:59:02 <Zakim> +Ivan
13:59:07 <LeeF> Regrets: Carlos, Souri, Sandro
13:59:10 <Zakim> +NicoM
13:59:23 <LeeF> Agenda: http://www.w3.org/2009/sparql/wiki/Agenda-2010-11-02
13:59:43 <Zakim> +bglimm
13:59:59 <kasei> hrm. cambridge zakim just dropped my call.
14:00:11 <LeeF> zakim, please be nicer to kasei
14:00:11 <Zakim> I don't understand 'please be nicer to kasei', LeeF
14:00:24 <bglimm> Zakim, mute me
14:00:24 <Zakim> bglimm should now be muted
14:00:27 <Zakim> + +1.310.729.aabb
14:00:37 <kasei> Zakim, aabb is me
14:00:37 <Zakim> +kasei; got it
14:00:38 <LeeF> zakim, thanks
14:00:38 <Zakim> you are very welcome, LeeF
14:01:35 <kasei> Zakim, mute me
14:01:35 <Zakim> kasei should now be muted
14:01:40 <Zakim> +MattPerry
14:02:42 <LeeF> zakim, who's on the phone?
14:02:42 <Zakim> On the phone I see LeeF, AndyS, Ivan, NicoM, bglimm (muted), kasei (muted), MattPerry
14:03:07 <LeeF> topic: Admin
14:03:16 <LeeF> PROPOSED: Approve minutes from http://www.w3.org/2009/sparql/meeting/2010-10-26
14:03:23 <Zakim> + +3539149aacc
14:03:39 <AlexPassant> Zakim, +3539149aacc is me
14:03:39 <Zakim> +AlexPassant; got it
14:04:15 <LeeF> Scribenick: AlexPassant
14:04:22 <Zakim> +pgearon
14:05:45 <Zakim> +[IPcaller]
14:06:17 <MattPerry> MattPerry has joined #sparql
14:06:57 <pgearon> Hi Lee
14:07:34 <LeeF> zakim, IPcaller is SteveH
14:07:34 <Zakim> +SteveH; got it
14:07:43 <LeeF> zakim, who's on the phone?
14:07:43 <Zakim> On the phone I see LeeF, AndyS, Ivan, NicoM, bglimm (muted), kasei (muted), MattPerry, AlexPassant, pgearon, SteveH
14:07:56 <SteveH> SteveH has joined #sparql
14:08:11 <LeeF> RESOLVED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2010-10-26
14:08:25 <LeeF> Next regular meeting: 2010-11-09 @ 15:00 UK / 10:00 EST (scribe: Chime Ogbuji) 
14:08:30 <SteveH> Zakim, who's on the phone?
14:08:30 <Zakim> On the phone I see LeeF, AndyS, Ivan, NicoM, bglimm (muted), kasei (muted), MattPerry, AlexPassant, pgearon, SteveH
14:08:37 <AlexPassant> LeeF: Any changes on last week minutes ?
14:08:39 <bglimm> Next week is ISWC
14:08:50 <AlexPassant> ... some people at ISWC next week
14:08:54 <ivan> I will be at iswc
14:08:55 <SteveH> will be at ISWC
14:08:56 <bglimm> I'll be there
14:08:58 <AlexPassant> ... but meeting back at normal time
14:09:00 <AlexPassant> I'll be at ISWC
14:09:39 <AlexPassant> ... ISWC attendees will probably won't join
14:10:02 <AlexPassant> ... but regular call with people that can attend
14:11:04 <AlexPassant> ... agenda for next week: shortcuts for updates
14:11:17 <AlexPassant> ... one of the full remaining thing to formalise grammar in update / query
14:11:29 <AndyS> yes - getting the grammar sorted would help me.
14:12:54 <NicoM> LeeF, got a glass roof?
14:13:13 <AlexPassant> topic: SELECT * behavior
14:14:01 <AlexPassant> LeeF: need to agree on the select * behavior
14:14:20 <AlexPassant> ... in-scope variables (bound variables)
14:14:25 <AlexPassant> ... consensus around that
14:14:43 <AlexPassant> ... shouldn't select variables inside the subquery
14:14:58 <LeeF> seems that SELECT * { { SELECT ?x { ... ?x ?y ... } } } just means ?x
14:15:19 <AndyS> agree
14:15:20 <pgearon> +1 absolutely
14:15:22 <bglimm> +1 
14:15:31 <NicoM> +1
14:15:31 <ivan> 1
14:16:15 <AlexPassant> ... what about variables that are hidden as being part of aggregate query but not in a GROUP BY
14:16:22 <LeeF> SELECT * { ... ?x ?y ... } GROUP BY ?x
14:16:43 <SteveH> that's the same as SELECT DISTINCT ?x { ... ?x ?y ... }
14:17:21 <LeeF> 1/ * stands for ?x and ?y, so this query is an error because you can't select ?y
14:17:42 <LeeF> 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 <SteveH> ... if you limit it to just "bindable" ones
14:18:28 <SteveH> I think we're in a position to descide
14:18:32 <AlexPassant> ...  is there any option besides these 2 ones ?
14:18:32 <AlexPassant> ... if not, can we decide between both ?
14:18:41 <SteveH> q+
14:19:21 <LeeF> ack SteveH
14:19:31 <pgearon> AndyS: not in my case, but it wouldn't be too hard to use that machinery instead
14:20:08 <Zakim> +AxelPolleres
14:20:30 <AndyS> I find that it is useful
14:20:47 <SteveH> where?
14:20:49 <kasei> I think it's quite useful
14:21:16 <SteveH> what about the semantic conflict with COUNT(*)
14:21:19 <bglimm> Are we discussing whther star is useful at all? Yes, but sound is quite bad
14:21:34 <kasei> 2
14:21:51 <SteveH> in 4store it's all
14:21:56 <SteveH> 1) I think
14:21:58 <AlexPassant> LeeF: any implementation doing * and aggregate ?
14:22:25 <kasei> 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 <AxelPolleres> Zakim, who is on the phone?
14:22:28 <Zakim> On the phone I see LeeF, AndyS, Ivan, NicoM, bglimm (muted), kasei (muted), MattPerry, AlexPassant, pgearon, SteveH, AxelPolleres
14:22:44 <SteveH> kasei, well SQL works that way, it's never bothered me
14:23:30 <AlexPassant> ... strawpoll
14:23:35 <LeeF> straw poll: 1 "all", 2 "legal", 0 "don't really care too much"
14:23:39 <bglimm> 1
14:23:39 <SteveH> 1
14:23:40 <kasei> 2
14:23:42 <ivan> 0
14:23:43 <AndyS> 2
14:23:44 <LeeF> 0
14:23:44 <MattPerry> 1
14:23:46 <pgearon> 0
14:23:46 <AlexPassant> 0
14:23:47 <NicoM> 0
14:23:48 <AxelPolleres> 2 (mildly)
14:24:48 <AlexPassant> LeeF: which decision will be easier to change if we've done the wrong one
14:24:55 <AlexPassant> ... or if people implementing the other way
14:24:58 <OlivierCorby> OlivierCorby has joined #sparql
14:25:01 <AlexPassant> ... any thoughts ?
14:25:03 <NicoM> legal can be extended later :-9
14:25:16 <SteveH> AndyS, I just meant the dramatically different meanings
14:25:34 <pgearon> 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 <AxelPolleres> I would find different meaning of * in COUNT and SELECT weird... that's one point for 2
14:25:48 <AxelPolleres> or no?
14:25:50 <AlexPassant> ... slight personal preference for 1
14:26:06 <SteveH> AxelPolleres, no, because then COUNT(*) and SLEECT(*) would bare no resemblance
14:26:19 <SteveH> er, SELECT *
14:26:35 <AndyS> SteveH, are you proposing no SELECT * at all?
14:26:39 <AlexPassant> ... if no new suggestion, tempted to say that we'll do 1
14:26:44 <AlexPassant> ... but happy to hear additional suggestions
14:26:49 <SteveH> AndyS, no, just that it would mean all in-scope variables
14:27:04 <SteveH> no just the ones that can legally be used in scalar expressions
14:27:08 <SteveH> *not...
14:27:46 <SteveH> I can write SELECT COUNT(?a) WHERE { ... } GROUP BY ?b, so ?a is in scopew
14:28:58 <SteveH> I can write SELECT (COUNT(?a) AS ?ca) WHERE { ... } GROUP BY ?b, so ?a is in scopew
14:29:02 <kasei> this is where the "potentially bound" terminology might have been slightly clearer than "in scope"
14:29:06 <MattPerry> what about: SELECT * WHERE { ... } GROUP BY (?a + ?b / 2)
14:29:15 <Zakim> + +34.92.38.aadd
14:29:41 <OlivierCorby> Zakim, aadd is me
14:29:41 <Zakim> +OlivierCorby; got it
14:29:52 <OlivierCorby> A little bit late ...
14:30:11 <AxelPolleres> matt, according to 1) that would be forbidden, yes?
14:30:23 <SteveH> AxelPolleres, no, it would just be an error
14:30:30 <AxelPolleres> according to 2) that would be like ASK?
14:30:57 <AlexPassant> AndyS: problem of semantic equivalence of the 2 expressions
14:31:06 <AxelPolleres> steveH, what's the diff between "an error" and "forbidden" for you here? ;-)
14:31:27 <AlexPassant> LeeF: anyone change his mind ?
14:31:40 <SteveH> would consider objecting
14:31:50 <bglimm> I really prefer 1, but wouldn't formally object
14:31:51 <AlexPassant> ... anybody feels strongly about this and would raise objection ?
14:31:51 <kasei> I'm going to be very unhappy, but probably won't object.
14:32:05 <SteveH> I might be less upset if anyone had a real use?
14:32:20 <SteveH> just seems like pointless syntax messing
14:32:25 <LeeF> No consensus.
14:32:35 <kasei> SteveH, same as SELECT * in 1.0 -- it's a really useful shortcut.
14:32:54 <SteveH> kasei, but it's not useful in this case, it's  just longhand for SELECT DISTINCT
14:32:59 <pgearon> 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 <LeeF> 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 <kasei> oh, I was under the impression that it could be combined with project exprs also...
14:34:01 <SteveH> option 1 also gives us to possibility of MAX(*) etc. in the future
14:34:06 <AndyS> I object.
14:34:43 <AlexPassant> AndyS: is there any list of objections ?
14:34:48 <AlexPassant> LeeF: no formal objections so far
14:35:43 <LeeF> 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 <AxelPolleres> 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 <LeeF> topic: BIND and FILTER order execution
14:36:15 <AlexPassant> topic: BIND + FILTER
14:36:21 <LeeF> http://lists.w3.org/Archives/Public/public-rdf-dawg/2010OctDec/0154.html
14:36:33 <AxelPolleres> q+ to mention still open issue on prev. topic
14:36:42 <LeeF> ack AxelPolleres
14:36:42 <Zakim> AxelPolleres, you wanted to mention still open issue on prev. topic
14:37:24 <AndyS> What is the issue number?
14:38:43 <AxelPolleres> 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 <LeeF> PREFIX : <http://example.org/>
14:38:53 <LeeF> SELECT ?s ?p ?o ?z
14:38:53 <LeeF> {
14:38:53 <LeeF>    ?s ?p ?o .
14:38:53 <LeeF>    FILTER(?z = 3 )
14:38:53 <LeeF>    BIND(?o+1 AS ?z)
14:38:55 <LeeF> }
14:40:01 <AlexPassant> AndyS: implementaion acts differently
14:40:24 <AlexPassant> ... BIND does not have the semantics of LET
14:40:34 <AlexPassant> ... so it will not act as a filter
14:40:43 <AlexPassant> ... no error if you assign to an existing variable
14:41:51 <kasei> LeeF, do you preserve the lexical ordering amongst the BINDs when you "shove" them to the end of the BGP?
14:42:54 <kasei> q+
14:43:39 <pgearon> I have a mild preference for lexical ordering.
14:44:35 <LeeF> ack kasei
14:44:37 <kasei> Zakim, unmute me
14:44:37 <Zakim> kasei was not muted, kasei
14:45:03 <LeeF> kasei: lexical order is much more intuitive when reading a query
14:45:12 <LeeF> kasei: but would filter floating mean that this is floating order?
14:45:58 <AxelPolleres> { ?s ?p ?o . FILTER(?z = 3 )
14:45:59 <AxelPolleres>   BIND(?o+1 AS ?z)
14:45:59 <AxelPolleres> }
14:45:59 <AxelPolleres> shouldn't that  mean the same as
14:45:59 <AxelPolleres> { {  ?s ?p ?o . FILTER(?z = 3 ) }
14:46:01 <AxelPolleres>   BIND(?o+1 AS ?z)
14:46:02 <AxelPolleres> }
14:46:04 <AxelPolleres> ?
14:46:22 <AlexPassant> LeeF: support from Axel, paul and greg that FILTER will fail in that case
14:46:22 <AxelPolleres> at least that's how I understood the earlier resolution
14:46:27 <AlexPassant> ... any different POV ?
14:47:23 <LeeF> 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 <LeeF> topic: + for fn:concat ?
14:47:58 <kasei> Zakim, mute me
14:47:58 <Zakim> kasei should now be muted
14:48:22 <SteveH> STRONG preference for not overloading
14:48:40 <AlexPassant> LeeF: question about the + operator
14:48:44 <AlexPassant> ... overloaed for string operation
14:48:50 <AlexPassant> ... most reponses where against that
14:49:04 <AlexPassant> ... but need for operator for string concatenation
14:49:24 <MattPerry> How would that work for SELECT (?a + ?b) AS ?c WHERE ...
14:49:47 <AlexPassant> AndyS: naturally wrote that in the query
14:49:51 <AndyS> ARQ implements -- it's a legal extension to expression evaluation anyway.
14:50:18 <kasei> I think "1" + "2" (plain literals) is going to produce unexpected results for people.
14:50:47 <LeeF> q?
14:51:16 <pgearon> +q
14:51:29 <AlexPassant> LeeF: strawpoll for + in string concatenation
14:51:37 <LeeF> straw poll: Using + operator for string concatenation 
14:52:12 <LeeF> straw poll: Using + operator for string concatenation (no implicit casting)
14:52:17 <SteveH> -1
14:52:20 <LeeF> +1 in favor / 0 don't care / -1 against
14:52:23 <kasei> -1
14:52:26 <AndyS> +1
14:52:27 <LeeF> 0
14:52:27 <MattPerry> -1
14:52:29 <ivan> 0
14:52:30 <AxelPolleres> 0 
14:52:31 <pgearon> +1
14:52:32 <NicoM> +1
14:52:34 <AlexPassant> +1
14:52:35 <OlivierCorby> +1
14:52:44 <AxelPolleres>  meaning 0 + "str" wouldn't work, but "0"+" str" would ?
14:52:52 <bglimm> 0
14:53:01 <LeeF> 5 / 3 / 3
14:54:20 <SteveH> no xs:string?
14:54:37 <AxelPolleres> ... by example was meant just to clarify that no casting implicit
14:54:44 <AlexPassant> LeeF: preference to include this
14:55:06 <AxelPolleres> ?x + "str" worries me a bit still
14:55:39 <AxelPolleres> but str(?x) + str" would work "
14:55:56 <AndyS> 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 <SteveH> AndyS, erg!
14:56:12 <LeeF> ACTION: AxelPolleres to come up with test cases around + for string concatenation
14:56:12 <trackbot> Sorry, couldn't find user - AxelPolleres
14:56:21 <LeeF> ACTION: Axel to come up with test cases around + for string concatenation
14:56:21 <trackbot> Created ACTION-330 - Come up with test cases around + for string concatenation [on Axel Polleres - due 2010-11-09].
14:56:22 <AndyS> Why? namesapce + local name!
14:56:29 <SteveH> the difference between plain literals and xsd:strings is already odd enough
14:56:55 <pgearon> -q
14:57:00 <AndyS> That is not a SPARQL matter - blame RDF-MT xsd1(a|b)
14:58:04 <MattPerry> with comparison return type is always boolean
14:58:06 <NickH> NickH has joined #sparql
14:58:22 <SteveH> AndyS, sure, not SPARQL's fault, but we don't have to make it worse than it is
14:58:29 <MattPerry> with overloaded + can be string or number
14:58:40 <LeeF> "1" * 4
14:58:45 <LeeF> "aaaa" * 4
14:58:55 <AndyS> always the case of for   ?x * ?y
14:59:46 <AxelPolleres> q+ to ask about http://www.w3.org/2009/sparql/docs/query-1.1/rq25.xml#selectExpressions ... "The new variable is introduced using the keyword AS; it must not already be potentially bound." is still open, raise an ISSUE?
15:00:22 <Zakim> +??P21
15:00:45 <NickH> Zakim, ??P21 is me
15:00:45 <Zakim> +NickH; got it
15:00:49 <SteveH> q+
15:01:19 <LeeF> SteveH: fn:concat casts its arguments to a string, so we'll need to be careful
15:01:52 <SteveH> q-
15:02:21 <LeeF> ACTION: Andy to clarify the meaning of "potentially bound" vis a vis what can go on the right hand side of an AS in a SELECT list
15:02:21 <trackbot> Created ACTION-331 - Clarify the meaning of "potentially bound" vis a vis what can go on the right hand side of an AS in a SELECT list [on Andy Seaborne - due 2010-11-09].
15:02:24 <AxelPolleres> ack AxelPolleres
15:02:24 <Zakim> AxelPolleres, you wanted to ask about http://www.w3.org/2009/sparql/docs/query-1.1/rq25.xml#selectExpressions ... "The new variable is introduced using the keyword AS; it must not
15:02:27 <Zakim> ... already be potentially bound." is still open, raise an ISSUE?
15:02:46 <AlexPassant> topic: Aggregate over mixed datatypes
15:02:58 <AlexPassant> ... discuss next week, with status of test cases
15:03:30 <SteveH> bye all
15:03:31 <ivan> zakim, drop me
15:03:31 <Zakim> Ivan is being disconnected
15:03:32 <AxelPolleres> regrets for next week most likely... will probably collide with poster session at ISWC
15:03:33 <Zakim> -Ivan
15:03:40 <bglimm> bye 
15:03:42 <Zakim> -AlexPassant
15:03:44 <Zakim> -SteveH
15:03:45 <MattPerry> bye
15:03:49 <NickH> ARGH to timezones!
15:03:53 <Zakim> -bglimm
15:04:02 <AxelPolleres> rrsagent, make records public
15:04:11 <Zakim> -NicoM
15:04:25 <NicoM> bye
15:04:33 <Zakim> -NickH
15:04:40 <Zakim> -OlivierCorby
15:06:06 <Zakim> -MattPerry
15:10:49 <kasei> AndyS?
15:10:51 <Zakim> -pgearon
15:10:53 <Zakim> -LeeF
15:10:53 <Zakim> -AndyS
15:10:55 <Zakim> -AxelPolleres
15:11:01 <AxelPolleres> AxelPolleres has left #sparql
15:11:01 <Zakim> -kasei
15:11:03 <Zakim> SW_(SPARQL)10:00AM has ended
15:11:05 <Zakim> Attendees were +1.617.245.aaaa, LeeF, AndyS, Ivan, NicoM, bglimm, +1.310.729.aabb, kasei, MattPerry, AlexPassant, pgearon, SteveH, AxelPolleres, +34.92.38.aadd, OlivierCorby, NickH
15:11:07 <AndyS> kasei - just finished talking ... test case Q?
15:11:17 <kasei> bind04 - I think you wrote it?
15:11:25 <kasei> it has this:
15:11:26 <kasei> { BIND(?o+1 AS ?z) } UNION { BIND(?o+2 AS ?z) }
15:11:44 <kasei> but has expected answers
15:11:48 <kasei> and I can't sort out why
15:12:38 <AndyS> :-)
15:12:44 <AndyS> Bottom up we have:
15:13:17 <AndyS> Eval  BIND(?o+1 AS ?z)  (one table row) and Eval  BIND(?o+2 AS ?z)  as another table row from the UNION.
15:13:41 <kasei> right, but ?o isn't bound there is it? I expect zero results out of the union.
15:13:43 <AndyS> Ah - OK - I see the Q now.  Let me think a bit - looks wrong to me ...
15:14:29 <kasei> I think it produces the expected answers if the triple pattern is distributed into the union.
15:15:05 <AndyS> Yes - looks like a bug to me.  
15:15:23 <kasei> ok. good to know i'm not going crazy.
15:15:35 <AndyS> One of the pain points of SPARQL is the need to duplicate patterns sometimes.
15:16:14 <kasei> yeah
15:17:38 <AndyS> LET ($$table := SELECT * { ?s ?p ?o } ) and have table variables.
15:26:06 <kasei> hahaha
15:26:08 <kasei> oh god
15:26:33 <kasei> AndyS, if you're still around. I know selecting * in addition to projexps has been talked about, but do you recall if a decision was ever made?
15:30:10 <AndyS> Formal DECISION?  Don't think so.
15:30:26 <AndyS> I don't recall one anyway.
15:40:29 <kasei> ok
15:40:40 <AndyS> What is your opinion?
15:40:50 <kasei> it occurred to me just a bit too late that that was the big reason I wanted SELECT * to work with the GROUP BY stuff.
15:41:00 <kasei> I think it's useful
15:42:28 <kasei> feel like SELECT * (?qty*?price AS ?total) is a valid thing to want to do.
15:44:40 <AndyS> I agree - and if you don't like a feature, don't use it.
15:45:35 <kasei> if we do support it, i fell as if that undermines Steve's point that SELECT * with GROUP BY is just shorthand for DISTINCT
16:01:41 <OlivierCorby> OlivierCorby has left #sparql
16:23:37 <SteveH> longhand for DISTINCT, it's more characters
17:59:08 <SteveH> SteveH has joined #sparql
18:41:50 <kasei> SteveH, yes, fair enough.
19:08:28 <LeeF> LeeF has joined #sparql
20:33:19 <LeeF> trackbot, close ACTION-257
20:33:19 <trackbot> ACTION-257 Craft a test case for SELECT * ... GROUP BY and solicit implementor, WG, and community feedback closed
20:33:26 <LeeF> (I suppose today obviates that to a large extent...)
20:51:54 <LeeF> trackbot, close ACTION-280
20:51:54 <trackbot> ACTION-280 Mark subquery tests 5-10 approved closed
21:04:11 <SteveH> SteveH has joined #sparql
21:07:01 <LeeF> trackbot, close ACTION-317
21:07:01 <trackbot> ACTION-317 Review entailment closed
21:08:20 <LeeF> trackbot, close ACTION-308
21:08:20 <trackbot> ACTION-308 Mark group_concat and projexp tests as approved closed
21:12:40 <AndyS> AndyS has joined #sparql
21:16:15 <bglimm> bglimm has joined #sparql
21:16:53 <LeeF> trackbot, close ACTION-305
21:16:53 <trackbot> ACTION-305 Start discussion on mailing list about set of functions to include in SPARQL closed