IRC log of sparql on 2012-02-14

Timestamps are in UTC.

14:53:12 [RRSAgent]
RRSAgent has joined #sparql
14:53:12 [RRSAgent]
logging to
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: (cont'd)
14:56:19 [AxelPolleres]
chair: axel polleres
14:57:00 [AxelPolleres]
regrets: carlos, lovier, lee
14:58:42 [AxelPolleres]
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]
15:00:36 [SteveH]
Sorry, I can't make it today, last minute clashing meeting :(
15:00:43 [Zakim]
15:01:00 [Zakim]
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]
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]
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]
15:05:57 [AxelPolleres]
scribe: Greg
15:06:15 [AxelPolleres]
topic: admin
15:06:22 [Zakim]
15:06:39 [AxelPolleres]
PROPOSED: approve minutes at
15:07:01 [AxelPolleres]
RESOLVED: approve minutes at
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]
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]
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 <> begat DBooth's conditional satisfaction <>
15:11:38 [AxelPolleres]
15:12:11 [kasei]
... strawpoll?
15:12:17 [kasei]
15:12:25 [AxelPolleres]
strawpoll 1/2/3 for any of these options?
15:12:39 [AxelPolleres]
2, if feasible
15:12:42 [MattPerry]
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]
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]
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]
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]
15:20:49 [pgearon]
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]
15:35:20 [AxelPolleres]
strawpoll on making property paths non-normative?
15:35:21 [kasei]
15:35:24 [AxelPolleres]
15:35:27 [MattPerry]
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]
15:35:57 [AndyS]
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]
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:
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]
15:42:56 [pgearon]
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]
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]
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]
15:59:52 [bglimm]
15:59:53 [AxelPolleres]
15:59:53 [Zakim]
15:59:55 [MattPerry]
15:59:57 [Zakim]
15:59:58 [Zakim]
16:00:04 [Zakim]
16:00:08 [Zakim]
16:00:20 [Zakim]
16:00:21 [Zakim]
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]
16:00:43 [kasei]
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]
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]
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]
16:05:31 [AxelPolleres]
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]
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