14:53:12 <RRSAgent> RRSAgent has joined #sparql
14:53:12 <RRSAgent> logging to http://www.w3.org/2012/02/14-sparql-irc
14:53:14 <trackbot> RRSAgent, make logs world
14:53:14 <Zakim> Zakim has joined #sparql
14:53:16 <trackbot> Zakim, this will be 77277
14:53:16 <Zakim> ok, trackbot; I see SW_(SPARQL)10:00AM scheduled to start in 7 minutes
14:53:17 <trackbot> Meeting: SPARQL Working Group Teleconference
14:53:17 <trackbot> Date: 14 February 2012
14:55:00 <AndyS> AndyS has joined #sparql
14:55:21 <AxelPolleres> hmmm, it seems my agenda mail didn't make it through.
14:55:43 <AndyS> trackbot, start meeting
14:55:45 <trackbot> RRSAgent, make logs world
14:55:47 <trackbot> Zakim, this will be 77277
14:55:48 <Zakim> ok, trackbot; I see SW_(SPARQL)10:00AM scheduled to start in 5 minutes
14:55:48 <trackbot> Meeting: SPARQL Working Group Teleconference
14:55:49 <trackbot> Date: 14 February 2012
14:55:53 <AxelPolleres> anyways, we'll ocntinue at last week's agenda, apologies.
14:56:00 <AndyS> zakim, this is 77277
14:56:00 <Zakim> AndyS, I see SW_(SPARQL)10:00AM in the schedule but not yet started.  Perhaps you mean "this will be 77277".
14:56:07 <AxelPolleres> agenda: http://www.w3.org/2009/sparql/wiki/Agenda-2012-02-07 (cont'd)
14:56:19 <AxelPolleres> chair: axel polleres
14:57:00 <AxelPolleres> regrets: carlos, lovier, lee
14:58:42 <AxelPolleres> s/lovier/olivier/
14:58:47 <Zakim> SW_(SPARQL)10:00AM has now started
14:58:55 <Zakim> + +49.897.aaaa - is perhaps AxelPolleres?
14:59:10 <AxelPolleres> Zakim, aaaa is me
14:59:10 <Zakim> sorry, AxelPolleres, I do not recognize a party named 'aaaa'
14:59:31 <AxelPolleres> Zakim, who is on the phone?
14:59:31 <Zakim> On the phone I see AxelPolleres?
14:59:53 <MattPerry> MattPerry has joined #sparql
15:00:23 <Zakim> +Sandro
15:00:36 <SteveH> Sorry, I can't make it today, last minute clashing meeting :(
15:00:43 <Zakim> +MattPerry
15:01:00 <Zakim> +kasei
15:01:23 <SteveH> AxelPolleres, are you chairing today? [re. Sorry, I can't make it today, last minute clashing meeting :(]
15:01:24 <Zakim> +??P16
15:01:41 <AndyS> zakim, ??P16 is me
15:01:41 <Zakim> +AndyS; got it
15:01:50 <AxelPolleres> steve, yes, we'll find someone.
15:02:08 <ericP> AxelPolleres, I inadvertently responded to DBooth's SPARQL LC comment while responding to the portion of it directed at the RDF WG
15:02:16 <ericP> need any follow-up from me on that?
15:02:40 <AxelPolleres> hmmm, eric good question, can you point me to the response?
15:02:43 <AxelPolleres> (link)
15:02:56 <AxelPolleres> Zakim, who is on the phone?
15:02:56 <Zakim> On the phone I see AxelPolleres?, Sandro, MattPerry, kasei, AndyS
15:03:14 <AxelPolleres> agendum: JP-4 how to proceed
15:03:46 <AxelPolleres> agendum: MOVE/COPY test cases
15:03:55 <AxelPolleres> agendum: GSP status
15:04:18 <AxelPolleres> agendum: TSV/CSV status
15:04:34 <AxelPolleres> agendum: further comments & ACTIONS
15:04:43 <AxelPolleres> Zakim, who is on the phone?
15:04:43 <Zakim> On the phone I see AxelPolleres?, Sandro, MattPerry, kasei, AndyS
15:05:13 <AxelPolleres> anybody could scribe?
15:05:16 <AndyS> I can't scribe (bad keyboard)
15:05:40 <kasei> I can
15:05:47 <kasei> scribenick: kasei
15:05:56 <Zakim> +pgearon
15:05:57 <AxelPolleres> scribe: Greg
15:06:15 <AxelPolleres> topic: admin
15:06:22 <Zakim> +chimezie
15:06:39 <AxelPolleres> PROPOSED: approve minutes at http://www.w3.org/2009/sparql/meeting/2012-02-07
15:07:01 <AxelPolleres> RESOLVED: approve minutes at http://www.w3.org/2009/sparql/meeting/2012-02-07
15:07:23 <kasei> AxelPolleres: any news from the RDF WG?
15:07:31 <AndyS> No news from RDF WG.
15:07:37 <kasei> AndyS: No news.
15:07:47 <AxelPolleres> topic: comment JP-4
15:08:08 <AxelPolleres> http://lists.w3.org/Archives/Public/public-rdf-dawg/2012JanMar/0153.html
15:08:18 <kasei> AxelPolleres: 3 options on how to proceed
15:08:26 <kasei> ... several opinions on the mailing list.
15:08:36 <kasei> ... to summarize:
15:08:52 <kasei> ... option 1: keeping grammar as is and try to explain which DISTINCT path subqueries can be optimized
15:09:18 <kasei> ... trying to find some equivalence between our current semantics and the proposed semantics in the cited paper
15:09:31 <kasei> ... option 2: adding DISTINCT() around path expressions
15:09:40 <AxelPolleres> DISTINCT(:p*)
15:09:59 <kasei> ... would require adding to the grammar and another LC round
15:10:10 <kasei> ... not sure how difficult it would be to define the semantics for this.
15:10:24 <kasei> ... AndyS wrote a mail about possible design choices for this option.
15:10:49 <kasei> ... option 3: leave things as they are and point out possible complexities of DISTINCT, optimizations.
15:11:11 <kasei> ... orthogonal issue is whether we should mark property paths as informative.
15:11:28 <kasei> ... Birte suggested making it optional. I think this would also require another LC.
15:11:34 <ericP> AxelPolleres, re: multi-line comments my response <http://www.w3.org/mid/20120213170048.GD20875@w3.org> begat DBooth's conditional satisfaction <http://www.w3.org/mid/1329157325.2250.129901.camel@dbooth-laptop>
15:11:38 <AxelPolleres> q?
15:12:11 <kasei> ... strawpoll?
15:12:17 <kasei> 3
15:12:25 <AxelPolleres> strawpoll 1/2/3 for any of these options?
15:12:39 <AxelPolleres> 2, if feasible
15:12:42 <MattPerry> 2
15:12:51 <AndyS> 2.1 then 3 -- expect 3 as the outcome due to time.
15:12:57 <kasei> sandro: afraid we don't have a quorum.
15:13:09 <kasei> AxelPolleres: perhaps we can reach concensus among those on the call today.
15:13:21 <pgearon> I haven't had time to properly consider… but I think 2
15:14:06 <AxelPolleres> 4 x Option 2, 1 x Option 3, nobody for Option 1.
15:14:11 <AndyS> Where are we regarding timescale for WG? (Sandro? Axel?)
15:14:18 <kasei> AxelPolleres: I think that probably rules out option 1.
15:14:38 <kasei> ... we should discuss if we go for option 2, can we afford the new timeline?
15:14:46 <kasei> ... we still have some documents which need to go to LC.
15:15:00 <kasei> ... graph store protocol and TSV/CSV documents.
15:15:20 <kasei> ... we could put the query document along with those for another LC.
15:15:31 <kasei> ... we definitly have to go fast.
15:15:38 <bglimm> bglimm has joined #sparql
15:16:05 <kasei> AxelPolleres: for option 2, can you summarize the design choices?
15:16:21 <Zakim> +??P24
15:16:30 <bglimm> Zakim, ??P24 is me
15:16:30 <Zakim> +bglimm; got it
15:16:34 <AndyS> ?? it will delay being about to LC GSP and TSV
15:16:34 <AndyS> http://lists.w3.org/Archives/Public/public-rdf-dawg/2012JanMar/0141.html
15:16:40 <bglimm> Zakim, mute me
15:16:40 <Zakim> bglimm should now be muted
15:17:08 <kasei> AndyS: allowing modifier on any part of path to indicate DISTINCT
15:17:19 <kasei> ... or only allowing DISTINCT on the whole path.
15:17:42 <kasei> ... or DISTINCT just modifying the behaviour of +/* operators
15:18:09 <kasei> ... or only applying to iri* or iri+, not any other path expression
15:18:20 <kasei> AxelPolleres: are any of those choices perferrable? simpler to implement?
15:18:43 <kasei> q+
15:19:01 <kasei> AndyS: in my implementation, i'm not targetting things like cliques. more real world data.
15:19:08 <kasei> ... I don't think SPARQL is the right choice for problems like that.
15:19:30 <kasei> ... in terms of spec changes, there's a list of consequences.
15:19:56 <kasei> ... probably will mean lots of extra material because as soon as we start applying DISTINCT, transformation operators won't apply (re: cardinality)
15:20:42 <kasei> ... If I was implementing it, I'd choose option 2.1
15:20:45 <kasei> q-
15:20:49 <pgearon> +q
15:21:28 <kasei> pgearon: is all the complexity around cardinality?
15:21:43 <kasei> AndyS: the multiple results are important in relation to aggregates.
15:22:06 <kasei> ... if you want connectivity, distinctness is probably more convenient.
15:22:19 <kasei> ... not in the same position as xpath: unique over nodes, multiple over values
15:22:26 <kasei> ... in RDF, we don't have that distinction.
15:22:47 <kasei> pgearon: what's the use of cardinality? loops are the only case I can see (?)
15:22:53 <AxelPolleres> we had a use case for cardinality in the reply to JP-3, right?
15:22:58 <kasei> AndyS: it's not loops per se. it's different route to the same node.
15:23:22 <kasei> ... that's where the complexity cost comes in. the algorithm stops if you go around a loop.
15:23:40 <kasei> ... if you have a DAG that crosses itself, you'll get cardinality increases.
15:24:14 <kasei> AxelPolleres: other implementors? would you adopt 2.1 or 2.2?
15:24:14 <MattPerry> I would lean towards 2.1
15:24:26 <AndyS> :x :p :a1 . :x :p :a2 . :a1 :p :y . :a2 :p :y .    { :x :p{2} ?y } => 2 rows.
15:24:26 <AxelPolleres> other implementers, would you be willing to adopt 2.1 or 2.2?
15:25:23 <kasei> AxelPolleres: what can we answer to the comment?
15:25:41 <kasei> ... we may be risking an objection.
15:26:01 <kasei> ... the paper which caused the comment will have lots of visibility.
15:26:46 <kasei> ... quite a provocative title.
15:26:58 <kasei> AndyS: I don't think the paper's visibility should be a factor in our decision.
15:27:27 <kasei> ... I think it's disappointing in that it doesn't reflect the previous conversation.
15:27:43 <kasei> ... from that point of view, it will be difficult to continue a conversation.
15:28:11 <kasei> AxelPolleres: we could try to get towards option 2, but there might be a time problem.
15:28:33 <kasei> ... there is still the open question about how much time it will take for the spec.
15:28:54 <swh> swh has joined #sparql
15:29:30 <kasei> AndyS: it will take a while to spec. then we'll need a good reviewer as well.
15:29:51 <kasei> ... possible by end of February.
15:30:16 <kasei> AxelPolleres: if we can do it by the end of February, I think we should try it. otherwise option 3.
15:30:30 <kasei> AndyS: I'm not prepared to make time for spec work if it's a "maybe".
15:30:50 <kasei> ... if people's existing concerns won't be addressed by spec work.
15:31:06 <kasei> AxelPolleres: Greg wasn't in support of option 2. Lee had expressed preference for option 3 on the list.
15:31:28 <kasei> chime: my inclination is to go with option 3.
15:32:12 <AndyS> zakim, who is on the phone?
15:32:12 <Zakim> On the phone I see AxelPolleres?, Sandro, MattPerry, kasei, AndyS, pgearon, chimezie, bglimm (muted)
15:32:33 <kasei> AxelPolleres: if we can't do it by the end of the month, we'll probably have to drop it.
15:33:09 <kasei> AndyS: we've been hearing "hints" that we should get around to finishing. what's the current timescale from the team perspective?
15:33:22 <kasei> sandro: we're chartered through the end of June.
15:33:30 <AxelPolleres> from before... 4 x Option 2, 1 x Option 3, nobody for Option 1... (... additionally: chime and Lee also for  Option3. adding two more voices for Option 3)
15:33:38 <kasei> ... I don't think it would be great to go too much past that.
15:33:51 <kasei> ... as long as we're not needing much staff time, I don't think there's that much argument.
15:33:57 <kasei> ... the strong argument is the group itself.
15:34:11 <kasei> ... staff perspective is that as long as WG is excited to keep working on it, it's probably OK.
15:34:15 <kasei> ... my sense is that's not the case.
15:34:27 <kasei> ... want to make sure we get to rec before people go home.
15:34:59 <kasei> AxelPolleres: option 2/3 could go with marking PP non-normative which would somewhat put them out of the line of fire of criticism.
15:35:06 <kasei> ... is that something people would consider?
15:35:13 <bglimm> +1
15:35:20 <AxelPolleres> strawpoll on making property paths non-normative?
15:35:21 <kasei> -1
15:35:24 <AxelPolleres> 0
15:35:27 <MattPerry> -1
15:35:32 <kasei> chime: I prefer option 3 over making it non-normative.
15:35:44 <kasei> ... (keeping it normative)
15:35:48 <pgearon> -1
15:35:57 <AndyS> -1
15:36:27 <AndyS> ... lists alone suggest keeping it
15:36:48 <AxelPolleres> 5 people for keeping PP normative, 1 for non-normative, 
15:37:16 <kasei> AxelPolleres: we'll fall back to option 3 unless we can make progress by next week.
15:37:27 <AxelPolleres> topic: MOVE/COPY test cases
15:37:45 <kasei> AxelPolleres: any updates on the Update spec regarding the copy/move issues?
15:38:02 <kasei> pgearon: I haven't had an opportunity to address the test cases.
15:38:17 <kasei> ... the main thing is atomicity.
15:38:23 <kasei> ...  I've done part of it, but haven't checked it in.
15:38:47 <kasei> ... atomicity mentioned twice in document. once regarding copy/move, the other regarding abstract definition of operations.
15:39:02 <kasei> ... I've made change in first.
15:39:22 <kasei> ... not happy with deleting "atomic" from second case.
15:40:13 <kasei> ... removing "atomic" doesn't seem appropriate in second case, but the ACTION mentions that section.
15:40:58 <kasei> AxelPolleres: I see "atomic" appearing in section 2.2. "A request should be treated atomically."
15:41:06 <kasei> pgearon: that's the section I've already changed.
15:41:08 <AndyS> q+
15:41:16 <kasei> ... the ACTION specifically has a link to another part of the document.
15:41:28 <kasei> AxelPolleres: the definition of "abstract update operation"?
15:41:30 <pgearon> The link in question is: http://www.w3.org/TR/sparql11-update/#def_updateoperation
15:41:31 <kasei> pgearon: yes.
15:42:30 <kasei> AxelPolleres: I thought we had agreed to remove "atomic" from the update operation definition.
15:42:41 <kasei> pgearon: I didn't realize "atomic" was being used here when we made this decision.
15:42:45 <kasei> q+
15:42:56 <pgearon> q-
15:43:12 <kasei> AndyS: I'm worried that section 2.2 has been changed.
15:43:23 <kasei> ... re: multiple requests should be treated atomically.
15:43:38 <kasei> ... surprised that's been changed.
15:43:59 <kasei> pgearon: it was never a requirement in the first place, because it was "SHOULD".
15:44:33 <kasei> pgearon: I've changed "SHOULD" to "MAY".
15:45:28 <kasei> AndyS: you said "atomic" is important in the definitions. In the sense of indivisible, but there's no sense of time in the operations.
15:45:35 <kasei> ... what is "atomic" adding for you?
15:45:52 <kasei> pgearon: I didn't write this section.
15:46:07 <kasei> ... 'either makes the chaange completely, or leaves the graph store unchanged.'
15:46:16 <AndyS> ack me
15:46:48 <kasei> AxelPolleres: my recollection is that we'd remove 'atomic' from the definition "SHOULD be performed atomically".
15:47:00 <kasei> ... could add what we mean by "atomic" there in the informal section.
15:47:35 <kasei> ... for the sections on copy/move, some wording would be in order that says that certain copy/move operations are not equivalent to the drop/update operations.
15:48:07 <AxelPolleres> q?
15:48:52 <AndyS> kasei: for the equivalences, worried we will not capture all the details
15:49:02 <AndyS> ... e.g. DROP+Update 
15:49:09 <AndyS> ack kasei
15:49:39 <kasei> AxelPolleres: we only had the informal definition for these operations, right? no formal definition.
15:50:10 <kasei> ... if we drop the equivalences, it's even worse because there's simply no definition.
15:50:10 <pgearon> +q
15:50:27 <kasei> AndyS: would you be interested in working to frame up some text to replace the formal definitions?
15:50:30 <kasei> kasei: sure
15:50:40 <kasei> AxelPolleres: you mean the equivalences?
15:50:43 <kasei> AndyS: yes
15:51:12 <AndyS> ack pgearon
15:51:30 <kasei> pgearon: what I was trying to do for copy/move was take out "is equivalent to", and change to "has a similar effect as", explaining that they act as single operations.
15:51:45 <kasei> ... so :g -> :g has the expected no-op effect.
15:51:49 <AxelPolleres> Greg, Andy would offer to suggest a replacement for the current definitions of COPY, MOVE, ADD in terms of equivalences.
15:52:57 <kasei> AndyS: I'm not clear on where we're at in section 2.2.
15:53:06 <kasei> pgearon: I've left "atomic" in, and changed "SHOULD" to "MAY".
15:53:31 <kasei> ... explained that "atomic" in this case means that operations may be grouped together.
15:54:14 <kasei> AxelPolleres: I think "SHOULD" is preferable here.
15:54:29 <kasei> pgearon: 2.2 talks about an atomic request, but the definition talks about an atomic operation.
15:55:22 <kasei> ... I do think of operations as being atomic.
15:55:53 <kasei> ... I don't know if we can consider ops to be truly atomic, but from the perspective of what "operation" means, I think you want them to either have their effect, or not.
15:56:11 <kasei> q+ to ask about the outstanding copy/move tests before we leave this topic
15:57:33 <AndyS> pgearon, could ping me when the text is checked in?  Thx.
15:57:50 <AndyS> s/could/could you/
15:58:04 <kasei> AxelPolleres: general agreement was to drop copy05/move05.
15:59:02 <kasei> AxelPolleres: we would drop those tests conditional on email?
15:59:04 <kasei> pgearon: I don't know.
15:59:15 <kasei> AxelPolleres: Can you take a look?
15:59:18 <kasei> pgearon: ok.
15:59:28 <AxelPolleres> ACTION: paul to confirm removal of test cases move05 and copy05 per email
15:59:28 <trackbot> Created ACTION-590 - Confirm removal of test cases move05 and copy05 per email [on Paul Gearon - due 2012-02-21].
15:59:49 <AndyS> bye all
15:59:52 <Zakim> -Sandro
15:59:52 <bglimm> bye
15:59:53 <AxelPolleres> adjourned.
15:59:53 <Zakim> -chimezie
15:59:55 <MattPerry> bye
15:59:57 <Zakim> -bglimm
15:59:58 <Zakim> -kasei
16:00:04 <Zakim> -AndyS
16:00:08 <Zakim> -MattPerry
16:00:20 <Zakim> -pgearon
16:00:21 <Zakim> -AxelPolleres?
16:00:22 <Zakim> SW_(SPARQL)10:00AM has ended
16:00:22 <Zakim> Attendees were +49.897.aaaa, Sandro, MattPerry, kasei, AndyS, pgearon, chimezie, bglimm
16:00:32 <AxelPolleres> rrsagent, make records public
16:00:35 <pgearon> kasei?
16:00:43 <kasei> yeah?
16:01:23 <pgearon> do you know what the issue is that we want to drop copy-05 and move-05?
16:01:45 <kasei> yeah. give me just a second.
16:02:06 <AxelPolleres> those were the ones which were ambiguous, IIRC, right?
16:02:22 <kasei> it's that they run afoul of our historical acceptance of both proper graph stores and of simple quadstores.
16:02:40 <kasei> there's no way to tell in a quadstore if the graph exists and is empty, or just that it doesn't exist.
16:02:57 <kasei> but these tests are assuming that it doesn't exist, and the operation fails as a result, without modifying anything.
16:03:29 <kasei> this was related to the text that one of copy/move said it SHOULD error if the input graph didn't exist, and the other said it MAY error.
16:03:47 <kasei> I think we had agreed that they both should be MAY
16:03:59 <kasei> but we can't test for MAY conformance :)
16:04:06 <pgearon> so in both tests :g4 doesn't exist?
16:04:16 <kasei> yeah
16:04:29 <pgearon> ah, OK. I'm fine with dropping them then
16:04:37 <kasei> they are identical tests, just with s/COPY/MOVE/
16:04:57 <kasei> ok.
16:05:19 <kasei> I think maybe the best/easiest thing ot do is just drop them from the manifest list?
16:05:24 <kasei> AxelPolleres?
16:05:31 <AxelPolleres> yup
16:05:50 <AxelPolleres> yes, that should be fine.
16:05:57 <kasei> the commonscribe/minutes thing has a problem with "agendum:". do you happen to know a fix for that?
16:06:57 <AxelPolleres> simplest trick is to just add a space before "angendum:" in the wiki, then commonscribe won't try to recognize it as a name.
16:07:05 <AxelPolleres> HTH
16:07:18 <kasei> but there's no way to get it to recognize them? or does that not matter?
16:07:29 <kasei> I guess it can see the "topic:" stuff...
16:07:56 <AxelPolleres> I'd say it does not matter, yes we have it on the topics.
16:09:47 <kasei> do we know who the .aaaa caller was?
16:13:45 <kasei> oh. i see. it was Axel, but Zakim was playing dumb.
16:51:04 <swh> swh has joined #sparql
17:55:29 <AndyS> AndyS has joined #sparql
17:59:14 <AndyS> AndyS has joined #sparql
18:10:45 <AxelPolleres> AxelPolleres has joined #sparql
18:11:34 <Zakim> Zakim has left #sparql
18:23:57 <AxelPolleres> AxelPolleres has joined #sparql
18:37:13 <AxelPolleres> AxelPolleres has joined #sparql
18:50:25 <AxelPolleres> AxelPolleres has joined #sparql
19:03:39 <AxelPolleres> AxelPolleres has joined #sparql
19:16:49 <AxelPolleres> AxelPolleres has joined #sparql
19:30:54 <AxelPolleres> AxelPolleres has joined #sparql
19:34:36 <AxelPolleres> AxelPolleres has joined #sparql
19:39:03 <AxelPolleres> AxelPolleres has joined #sparql
19:53:19 <AxelPolleres> AxelPolleres has joined #sparql
19:57:03 <AxelPolleres> AxelPolleres has joined #sparql
20:10:23 <AxelPolleres> AxelPolleres has joined #sparql
20:14:19 <AxelPolleres> AxelPolleres has joined #sparql
20:18:03 <AxelPolleres> AxelPolleres has joined #sparql
20:21:51 <AxelPolleres> AxelPolleres has joined #sparql
20:25:45 <AxelPolleres> AxelPolleres has joined #sparql
20:29:20 <AxelPolleres> AxelPolleres has joined #sparql
20:32:56 <AxelPolleres> AxelPolleres has joined #sparql
20:36:31 <AxelPolleres> AxelPolleres has joined #sparql
20:38:45 <swh> swh has joined #sparql
20:40:07 <AxelPolleres> AxelPolleres has joined #sparql
20:43:42 <AxelPolleres> AxelPolleres has joined #sparql
20:56:54 <AxelPolleres> AxelPolleres has joined #sparql
21:07:31 <AxelPolleres> AxelPolleres has joined #sparql
21:11:06 <AxelPolleres> AxelPolleres has joined #sparql
21:14:42 <AxelPolleres> AxelPolleres has joined #sparql
21:18:17 <AxelPolleres> AxelPolleres has joined #sparql
21:22:01 <AxelPolleres> AxelPolleres has joined #sparql
21:25:37 <AxelPolleres> AxelPolleres has joined #sparql
21:29:26 <AxelPolleres> AxelPolleres has joined #sparql
21:33:01 <AxelPolleres> AxelPolleres has joined #sparql
21:37:31 <AxelPolleres> AxelPolleres has joined #sparql
21:41:15 <AxelPolleres> AxelPolleres has joined #sparql