Chatlog 2012-01-10

See original RRSAgent log and preview nicely formatted version.

Please justify/explain all edits to this page, in your "edit summary" text.

<kasei> Present: kasei, LeeF, sandro, MattPerry, pgearon, AndyS, bglimm, ericp
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: SteveH, Carlos, Olivier, Axel
15:00:12 <Zakim> +LeeF; got it
15:00:25 <Zakim> +sandro
15:01:12 <Zakim> +MattPerry; got it
15:01:13 <Zakim> +pgearon
15:02:39 <Zakim> +Eric
15:02:54 <Zakim> +AndyS; got it
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 understood 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 SPARQL Update requests for PATCH.
15:09:29 <kasei> ... charter says this is an alternative to 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:21 <kasei> ... document is silent on this issue.
15:14:29 <Zakim> +bglimm; got it
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: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: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: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: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: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:53 <kasei> LeeF: I don't know if there are clients that do that.
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:02:14 <AndyS> Regrets for next time
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
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00000252