IRC log of sparql on 2012-01-10

Timestamps are in UTC.

14:58:54 [RRSAgent]
RRSAgent has joined #sparql
14:58:54 [RRSAgent]
logging to http://www.w3.org/2012/01/10-sparql-irc
14:58:56 [trackbot]
RRSAgent, make logs world
14:58:56 [Zakim]
Zakim has joined #sparql
14:58:57 [MattPerry]
MattPerry has joined #sparql
14:58:58 [trackbot]
Zakim, this will be 77277
14:58:58 [Zakim]
ok, trackbot; I see SW_(SPARQL)10:00AM scheduled to start in 2 minutes
14:58:59 [trackbot]
Meeting: SPARQL Working Group Teleconference
14:58:59 [trackbot]
Date: 10 January 2012
14:59:07 [Zakim]
SW_(SPARQL)10:00AM has now started
14:59:14 [Zakim]
+kasei
14:59:27 [LeeF]
Agenda: http://lists.w3.org/Archives/Public/public-rdf-dawg/2012JanMar/0042.html
14:59:31 [LeeF]
Chair: LeeF
14:59:38 [LeeF]
Regrets: SeveH, Carlos, Olivier, Axel
15:00:00 [LeeF]
kasei, mind scribing?
15:00:08 [Zakim]
+ +1.617.553.aaaa
15:00:09 [kasei]
sure
15:00:12 [LeeF]
zakim, aaaa is me
15:00:12 [Zakim]
+LeeF; got it
15:00:25 [Zakim]
+sandro
15:00:31 [Zakim]
+ +1.917.522.aabb
15:00:58 [Zakim]
+ +1.603.897.aacc
15:01:12 [MattPerry]
zakim, aacc is me
15:01:12 [AndyS]
zakim, IPCaller is me
15:01:12 [Zakim]
+MattPerry; got it
15:01:13 [Zakim]
sorry, AndyS, I do not recognize a party named 'IPCaller'
15:01:13 [Zakim]
+pgearon
15:01:22 [AndyS]
zakim, who is on the phone?
15:01:22 [Zakim]
On the phone I see kasei, LeeF, sandro, +1.917.522.aabb, MattPerry, pgearon
15:01:50 [LeeF]
41#
15:02:22 [LeeF]
zakim, who's speaking?
15:02:34 [Zakim]
LeeF, listening for 11 seconds I heard sound from the following: MattPerry (46%), LeeF (43%), +1.917.522.aabb (81%)
15:02:39 [Zakim]
+Eric
15:02:52 [AndyS]
zakim, aabb is me
15:02:54 [Zakim]
+AndyS; got it
15:02:57 [AndyS]
(not)
15:03:00 [kasei]
AndyS channeling NYC
15:04:18 [kasei]
scribenick: kasei
15:04:34 [LeeF]
PROPOSED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2012-01-03
15:05:08 [LeeF]
RESOLVED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2012-01-03
15:06:22 [kasei]
topic: Graph Store Protocol
15:06:39 [kasei]
LeeF: starting with sandro's email
15:06:44 [LeeF]
http://lists.w3.org/Archives/Public/public-rdf-dawg/2012JanMar/0030.html
15:07:39 [kasei]
sandro: my concerns were with the scope of the document
15:07:50 [kasei]
... I udnerstood the scope to be 'this is how you do RESTful RDF'
15:08:04 [kasei]
... I don't think it's OK to constrain all POSTs of RDF to mean merge.
15:08:09 [kasei]
... which is what the draft says.
15:08:33 [kasei]
... I don't believe it's OK to have normative language in a section labeled non-normative/informative.
15:08:41 [kasei]
... which happens in the PATCH section.
15:08:53 [LeeF]
http://www.w3.org/TR/sparql11-http-rdf-update/#http-patch
15:09:18 [kasei]
... I don't think it's OK to say that servers SHOULD accept RDF update requests for PATCH.
15:09:29 [kasei]
... charter says this is an alternative to SPARQL Update.
15:09:33 [kasei]
s/RDF update/SPARQL update/
15:09:56 [kasei]
... I believe there was agreement in the GS telecon to change SHOULD to a MAY
15:10:24 [AndyS]
"SPARQL 1.1 Update can be used as a patch document. "
15:10:52 [kasei]
... I understood that Greg raised some concern about this document and service descriptions.
15:11:02 [kasei]
... he didn't want to make changes to SD as its moved to LC.
15:11:20 [kasei]
... not my concern, but came up during the GS meeting.
15:11:59 [LeeF]
kasei: i feel it's too late to make big changes to service description. i don't think we should be publishing these two documents where the graph store document points to SD and says to use it, and then SD says nothing about the graph store protocol
15:12:21 [sandro]
kasei: I don't think we should publishing two documents where GS points to SD, but SD says nothing about GS. I'd much rather leave it for consensus the future.
15:12:58 [kasei]
sandro: section 5.5 references the service description.
15:13:23 [bglimm]
bglimm has joined #sparql
15:13:29 [LeeF]
http://www.w3.org/2009/sparql/docs/http-rdf-update/#http-post
15:14:10 [kasei]
sandro: when you POST/PUT RDF content, and the content uses relative URIs, what should you understand as the base URI?
15:14:19 [Zakim]
+??P25
15:14:21 [kasei]
... document is silent on this issue.
15:14:29 [bglimm]
Zakim, ??P25 is me
15:14:29 [Zakim]
+bglimm; got it
15:14:33 [bglimm]
Zakim, mute me
15:14:33 [Zakim]
bglimm should now be muted
15:15:10 [kasei]
sandro: reading Andy's message, we have a different understanding on scope of document.
15:15:28 [kasei]
... Andy and Steve understand it as applying only to this type of graphstore.
15:15:42 [kasei]
... if we add langauge to clarify that scope, I don't have the same concerns.
15:15:59 [kasei]
LeeF: you wouldn't be concerned if we did that that it opens the door to confusion?
15:16:27 [kasei]
... "this is how you deal with RDF in a Graph Store"
15:16:51 [kasei]
sandro: I think we have that problem any way we slice it.
15:17:08 [kasei]
... we have to leave some opening.
15:17:23 [kasei]
... we don't know enough yet how it will work.
15:17:41 [kasei]
ericP: most of the document is intuitively how RDF works using HTTP.
15:17:54 [kasei]
... best practice for RDF graphs on the web.
15:18:06 [kasei]
sandro: that's why I proposed text for the abstract.
15:18:11 [LeeF]
zakim, who's on the phone?
15:18:11 [Zakim]
On the phone I see kasei, LeeF, sandro, AndyS, MattPerry, pgearon, Eric, bglimm (muted)
15:18:49 [kasei]
ericP: I don't think your text is going to do the job explaining about how rdf graphs are manipulated on the web.
15:19:09 [kasei]
sandro: 90% of this document is redundant. it already comes from existing specs. small bits that aren't redundant.
15:19:36 [kasei]
LeeF: if the scope of this document is doing REST operations when you have a Graph Store, are people happy with that?
15:20:08 [LeeF]
straw poll: Would you be happy with explicitly scoping the Graph Store Protocol specification such that it applies only to SPARQL 1.1 Graph Stores?
15:20:15 [ericP]
-.5
15:20:30 [ericP]
that is, i don't want to be a total pain
15:20:37 [sandro]
+0 (not thrilled, but I think it's the best path forward today)
15:20:45 [AndyS]
+1
15:20:51 [AndyS]
(caveat)
15:20:53 [kasei]
+.5
15:20:54 [bglimm]
+0
15:20:57 [MattPerry]
+1
15:21:06 [pgearon]
+1
15:21:11 [LeeF]
LeeF: SteveH is pretty clearly +1 from email
15:22:02 [kasei]
LeeF: (inaudible)
15:22:05 [bglimm]
I'm just not totally swapped in on this, so I don't want to take a strong position on it, but it sounds ok to me
15:22:39 [kasei]
LeeF: recommend there's concensus around Chime.
15:23:06 [sandro]
LeeF: I'd like to get consensus on the call, whch hopefully Chime will agree with.
15:23:17 [kasei]
ericP: there's going to be a set of best practices on using HTTP to manage RDF.
15:23:25 [kasei]
... most of that data will be accessible via SPARQL.
15:23:33 [kasei]
... arbitrary decisions on what POST does.
15:23:42 [AndyS]
We have a non-SPARQL implementation as well.
15:24:07 [kasei]
LeeF: some of this is speculative. we don't know which direction the world is going to move in.
15:24:25 [kasei]
... want to give people an out.
15:24:53 [kasei]
... options are SHOULD instead of MUST, removing normative language, defining set of resources which act differently, ...
15:25:35 [kasei]
... if we took the out on saying it applies only to SPARQL 1.1 graph stores, can be a second document which says how to do it with certain classes of resources.
15:26:07 [kasei]
... or we may find the problems don't crop up
15:26:12 [sandro]
q+
15:26:13 [kasei]
ericP: I don't see those as all the same.
15:26:43 [kasei]
... if I'm doing something else where I've got a set of things acting like graph stores, and a set that act like other things,
15:27:03 [LeeF]
ack sandro
15:27:04 [sandro]
eric: Is the scope related to SPARQL
15:27:12 [kasei]
ericP, scribe assist?
15:27:25 [LeeF]
ericP: is the scope of this document the things that act the way the document says or any graphs that are in a store that are SPARQL 1.1'able?
15:27:34 [sandro]
eric: Is the scope definition based on SPARQL or self-standing.
15:28:08 [AndyS]
q+
15:28:12 [kasei]
sandro: I think distinction between choice that most matters is that there's some way the client can tell.
15:28:22 [kasei]
... to know what they can do with the resource.
15:28:36 [kasei]
... not doing that with any of the solutions except for defining a class of resources that act in a certain way.
15:29:00 [LeeF]
ack AndyS
15:29:24 [kasei]
AndyS: wondering how much weight to give to existing systems.
15:29:58 [kasei]
LeeF: think there are at least 2 existing systems that we know about.
15:30:19 [kasei]
AndyS: 4store, 5store do. quite a lot of users of 4store.
15:30:48 [kasei]
sandro: are there clients that rely on this behaviour? (assuming POST=merge)
15:31:30 [kasei]
ericP: if we say SHOULD, we're encouraging clients to optimistically try something.
15:31:49 [kasei]
... looking for clients that are doing what this spec specifies, and without out of band knowledge, assuming they can do POST=merge.
15:32:09 [kasei]
Zakim, who is talking?
15:32:21 [Zakim]
kasei, listening for 11 seconds I heard sound from the following: sandro (22%), AndyS (13%), Eric (68%)
15:32:30 [LeeF]
zakim, mute ericP
15:32:30 [Zakim]
sorry, LeeF, I do not know which phone connection belongs to ericP
15:32:34 [LeeF]
zakim, mute eric
15:32:34 [Zakim]
Eric should now be muted
15:32:39 [kasei]
sandro: we're not ready to set a standard to define how you know what POST does.
15:33:07 [kasei]
... implementations that behave a specific way don't speak to what clients can expect.
15:33:24 [kasei]
... if you do a GET and get metadata or data that tells you how to POST...
15:34:18 [kasei]
sandro: g-box can be self describing, doesn't need data/metadata distinction.
15:35:09 [kasei]
LeeF: I agree the different outs have different implications in terms of longevity, consensus...
15:35:37 [kasei]
... my take is that people in SW world aware of SPARQL will not be deterred by narrow scope.
15:35:52 [AndyS]
http://lists.w3.org/Archives/Public/public-rdf-dawg/2011OctDec/0405.html
15:36:09 [kasei]
... main worry is whether the narrow scoping curtails implementations, reduces feedback on wider use.
15:36:14 [ericP]
me Zakim, mute me
15:36:35 [kasei]
... I think we can overcome that risk by noting the scope, let people decide how to do REST outside of Graph Stores.
15:36:37 [sandro]
lee; This is how you do REST with RDF that's in a SPARQL Graph Store.
15:36:46 [sandro]
s/;/:/
15:36:51 [ericP]
ack me
15:37:00 [AndyS]
q+
15:37:04 [LeeF]
ack AndyS
15:37:15 [kasei]
AndyS: I don't want to see speculation in the document. Think that's harmful.
15:37:22 [kasei]
LeeF: this proposal wouldn't involve speculation.
15:37:44 [kasei]
AndyS: when we had the GS telecon, we had agreed on text.
15:37:52 [ericP]
q+ to say that this sounds like a note in that it's proposing some ideas with unknown scope and conformance
15:37:56 [LeeF]
ack ericP
15:37:56 [Zakim]
ericP, you wanted to say that this sounds like a note in that it's proposing some ideas with unknown scope and conformance
15:38:01 [ericP]
ack eric
15:38:42 [kasei]
ericP: sounds like a great note. "we think this has some applicability, not sure what it is. would like the world to see how it works for them..."
15:38:54 [kasei]
LeeF: we know what we want it to do in the context of SPARQL Graph Stores.
15:39:01 [kasei]
... people happy with that design.
15:39:17 [kasei]
... from a perspective broader than this WG, we hope that's what happens.
15:39:50 [kasei]
... for people who aren't doing SPARQL Graph Stores, hope the text acts as a guide to them
15:39:55 [sandro]
Lee: So this will seem like a WG NOTE to people not doing SPARQL Graph Stores.
15:40:26 [kasei]
ericP: does this discourage me from adding SPARQL 1.1 to something that had a different behaviour on POST?
15:40:59 [kasei]
LeeF: if you have a 1.1 Graph Store and you wilfully disobey the spec, you'll lose interop, but the world won't explode and you'll come to the next WG with valuable feedback.
15:41:26 [kasei]
... similar to intentional mis-use of RDF w.r.t. RDF WG.
15:41:55 [sandro]
I'm losing Lee
15:41:57 [kasei]
... balancing tradeoff between getting things done and not precluding future work.
15:41:58 [sandro]
Others?
15:42:31 [kasei]
ericP: annotea had two classes of resources. POST to create annotations. GET/PUT on those annotations.
15:42:44 [kasei]
... if a client expected POST to append, and it created something new, is that "exploding"?
15:42:57 [kasei]
LeeF: isn't that covered by the spec if you're POSTing to a Graph Store?
15:43:13 [kasei]
ericP: it affects two graphs. the "all annotations" and the new annotation.
15:43:21 [kasei]
LeeF: do you think that violates the spec?
15:43:48 [kasei]
AndyS: it's only merge when you're POSTing to a graph container.
15:44:47 [kasei]
... if you POST to a graph store, doesn't specify the operation has to be append.
15:44:58 [LeeF]
zakim, eric is ericp
15:44:58 [Zakim]
+ericp; got it
15:45:10 [kasei]
... I think it says it creates 'a subsidiary resource'
15:45:25 [kasei]
... which is what ATOM protocol does as well
15:46:27 [kasei]
ericP: issue arises when I GET a resource after POSTing to it, and the GET isn't returning the merge of the previous POST.
15:46:35 [kasei]
... I guess the document doesn't specify that case.
15:46:56 [AndyS]
The language is "RDF graph content identified by the request or encoded IRI"
15:47:01 [kasei]
LeeF: unless the client has out of band knowledge, it can't make assumptions anyway.
15:47:19 [kasei]
ericP: so what's the use case for this document. are there clients that make this assumption?
15:47:44 [sandro]
zakim, who is making noise?
15:47:53 [kasei]
LeeF: I don't know if there are clients that do that.
15:47:54 [Zakim]
sandro, listening for 10 seconds I heard sound from the following: LeeF (29%), sandro (46%), AndyS (14%)
15:47:57 [LeeF]
PROPOSED: The Graph Store Protocol explicitly applies only to SPARQL 1.1 Graph Stores
15:48:00 [kasei]
sandro: can we move forward with the compromise?
15:48:18 [sandro]
+1
15:48:39 [kasei]
AndyS: I think this is the right way forward.
15:49:12 [kasei]
... I don't like the "RDF content" wording
15:49:23 [kasei]
sandro: I think that's an editorial matter we can deal with later.
15:49:32 [kasei]
AndyS: it's been important to Chime
15:49:56 [ericP]
abstain
15:50:13 [LeeF]
RESOLVED: The Graph Store Protocol explicitly applies only to SPARQL 1.1 Graph Stores, AndyS and EricP abstaining
15:51:08 [LeeF]
AndyS: Abstaining because we had an agreement previously and I feel that this is taking things backwards by inroducing things that are of a speculative nature for a future WG
15:51:56 [AndyS]
I would like to leave that future WG as free to work as possible and not speculate on it now.
15:51:58 [kasei]
sandro: resolution takes care of points 1 and 5 in my email.
15:52:10 [AndyS]
q+
15:52:11 [kasei]
LeeF: points 2 and 3 address the PATCH section.
15:52:33 [kasei]
... group feels there's not enough experience in using PATCH to make normative recommendations.
15:53:15 [kasei]
... propose that RFC2119 text be removed from 5.7, and that the english text be adjusted to indicate that SPARQL Update requets are an option for PATCH, but not the only option.
15:53:33 [kasei]
sandro: why not MAY for using SPARQL for PATCH, and make the section normative?
15:53:52 [kasei]
LeeF: we weren't comfortable recommending with normative text because of lack of experience.
15:54:03 [LeeF]
ack AndyS
15:54:26 [kasei]
AndyS: request 4.5 (about base URI) be regarded as a technical point, not a decision of the WG.
15:54:41 [kasei]
LeeF: does the right answer affect the document?
15:54:56 [kasei]
AndyS: it might, yes.
15:55:08 [kasei]
... it isn't a question about designing a system. question about what is already defined.
15:55:46 [kasei]
LeeF: feels like something we could omit, or change after LC without affecting conformance requirements.
15:55:57 [kasei]
AndyS: is that approach acceptable to everybody?
15:56:26 [kasei]
sandro: I believe the specs are silent on this matter.
15:56:49 [kasei]
AndyS: we had a discussion a long time ago in which we decided the specs weren't silent on the issue.
15:56:56 [kasei]
sandro: this spec doesn't say anything about it, right?
15:56:59 [kasei]
LeeF: correct
15:57:09 [kasei]
sandro: I don't feel that we need to say anything about it here.
15:57:32 [LeeF]
PROPOSED: Remove RFC2119 text from section 5.7 HTTP PATCH and make it clear that SPARQL 1.1 Update requests are an advised option for using PATCH but not the only possibility
15:57:54 [kasei]
+1
15:58:05 [sandro]
"advised" ?
15:58:10 [kasei]
AndyS: there are 2 things you can send a PATCH to. Graph Store, or the graph content.
15:58:19 [kasei]
... I think it's meaningless to send it to graph content.
15:58:37 [kasei]
... in your wording, are you meaning all uses of PATCH? Or just to the graph content?
15:58:54 [kasei]
LeeF: wasn't proposing changing the section beyond this.
15:59:18 [kasei]
sandro: currently about graph content. would be reasonable to put in text about graph stores, but not there currently.
15:59:36 [kasei]
LeeF: can we take that as a separate point to email?
15:59:57 [kasei]
sandro: don't think it makes a lot of sense to use SPARQL Update with PATCH.
16:00:09 [kasei]
AndyS: does protocol talk about PATCH?
16:00:11 [kasei]
LeeF: no.
16:00:24 [Zakim]
-ericp
16:00:32 [kasei]
LeeF: any objections?
16:00:45 [AndyS]
+1
16:00:47 [LeeF]
PROPOSED: Remove RFC2119 text from section 5.7 HTTP PATCH and make it clear that SPARQL 1.1 Update requests are an option for using PATCH but not the only possibility
16:00:50 [kasei]
sandro: "advice" is a normative thing.
16:01:05 [sandro]
+1
16:01:19 [bglimm]
+1
16:01:23 [LeeF]
RESOLVED: Remove RFC2119 text from section 5.7 HTTP PATCH and make it clear that SPARQL 1.1 Update requests are an option for using PATCH but not the only possibility
16:01:57 [bglimm]
Bye
16:02:01 [MattPerry]
bye
16:02:11 [Zakim]
-LeeF
16:02:14 [AndyS]
Regrets for next time
16:02:17 [Zakim]
-sandro
16:02:20 [Zakim]
-MattPerry
16:02:22 [Zakim]
-pgearon
16:02:25 [Zakim]
-bglimm
16:02:47 [Zakim]
-AndyS
16:02:51 [Zakim]
-kasei
16:02:55 [Zakim]
SW_(SPARQL)10:00AM has ended
16:02:57 [Zakim]
Attendees were kasei, +1.617.553.aaaa, LeeF, sandro, +1.917.522.aabb, +1.603.897.aacc, MattPerry, pgearon, AndyS, bglimm, ericp
16:03:15 [kasei]
sandro, thanks. it felt like one of the worst! always scrambling... :)
16:03:55 [kasei]
I'm having trouble logging in to the wiki to generate the minutes. any known auth issues going on?
16:04:09 [kasei]
s/wiki/commonscribe/
16:05:31 [kasei]
ah. got it sorted.
16:17:47 [sandro]
(good)
16:18:19 [kasei]
AndyS: still around? got a testsuite question for you.
16:18:28 [ouvasam]
ouvasam has joined #sparql
16:20:28 [AndyS]
kasei: licencing per chance? (Need a W3C authoritive statement on that [ping Sandro]) but I can say what we have done for Jena if that helps.
16:21:56 [kasei]
no, something else :)
16:22:01 [AndyS]
:-)
16:22:11 [kasei]
do you still maintain the query syntax tests in your own setup?
16:22:39 [kasei]
I've got two prefixname escaping tests to add, but remembered that my committing new ones had caused some trouble in the past.
16:25:32 [AndyS]
There was an area for new ones not autogenerated ... one moment ...
16:31:34 [AndyS]
.. that was for Update. I suggest either (1) you create a new directory or (2) we define the CVS to be the master and I won'yt overwrite it again (i.e. we manage tests manually) or (3) you send the test to me and I hack them into the test builder (it's open source in ARQ) or (4) other.
16:36:30 [kasei]
I'd prefer 2 or 3. Do you have a preference?
16:37:24 [kasei]
I think 2 makes the most sense moving forward. Otherwise there are a handful of subtrees in the testsuite that are "special", without any visible indication.
16:41:22 [ouvasam]
ouvasam has joined #sparql
16:50:03 [AndyS]
(2) is fine and has to happen.
16:54:40 [kasei]
ok. I'll commit my tests to CVS, then.
16:54:40 [kasei]
thanks
17:03:43 [kasei]
committed syntax-query/manifest#test_52 and syntax-query/manifest#test_53 for testing backslash escapes and percent encoding in prefixnames.
17:04:07 [kasei]
I hope I got them right...
17:12:57 [AndyS]
ARQ passes the tests.
18:04:50 [Zakim]
Zakim has left #sparql
18:31:33 [LeeF]
LeeF has joined #sparql