- From: Lee Feigenbaum <lee@thefigtrees.net>
- Date: Mon, 03 Jan 2011 10:13:39 -0500
- To: Andy Seaborne <andy.seaborne@epimorphics.com>
- CC: SPARQL Working Group <public-rdf-dawg@w3.org>
On 12/29/2010 5:22 AM, Andy Seaborne wrote: > > > On 24/12/10 19:21, Lee Feigenbaum wrote: >> The first topic we discussed on the protocol teleconference was the >> content of an HTTP request for the SPARQL Update Protocol. The consensus >> was as listed at >> http://www.w3.org/2009/sparql/wiki/Protocol#What_do_you_send_for_a_SPARQL_update_request.3F >> >> : >> >> """ >> PROPOSED: SPARQL Update requests can be POSTed as either >> application/x-www-form-urlencoded or application/sparql-update, pending >> discovery of how to do the latter in WSDL 2 >> """ >> >> The first half is the analog to SPARQL query. In that case, you send an >> HTTP request like >> >> POST /foo/bar/sparql HTTP/1.1 >> ... >> Content-type: application/x-www-form-urlencoded >> >> default-graph-uri=...&named-graph-uri=...&named-graph-uri=...&update=<URL >> encoded >> update request string> > > I'm not sure what &default-graph-uri= and &named-graph-uri= mean for an > SPARQL Update request. On the protocol teleconference, we discussed that they would define the RDF dataset against which graph patterns are evaluated -- a la USING and USING NAMED, as you say below. > The target of the operation is a graph store, unlike query where it can > be a dynamicly created dataset just for the purposes of the query. A > graph store is something with state that exists before and after the > request. > > For example, if there is &named-graph-uri= .., does that mean you can't > create another named graph? > > I can see this applying to the pattern part only (c.f. USING) for > Anzo/Glitter -- is that the intent? Yes. >> There was a significant feeling that we'd like to also encourage direct >> POSTing of SPARQL Update strings: >> >> POST /foo/bar/sparql HTTP/1.1 >> ... >> Content-type: application/sparql-update >> >> <unencoded content of SPARQL Update string goes here> >> >> >> We also observed that this 2nd form doesn't give anyway to specify the >> equivalent of the default-graph-uri and named-graph-uri parameters, so >> it was suggested that perhaps those could be encoded in the URI query >> string: >> >> POST /foo/bar/sparql?default-graph-uri=...&named-graph-uri=... HTTP/1.1 >> ... >> Content-type: application/sparql-update >> >> <unencoded content of SPARQL Update string goes here> > > If we need them, that's OK by me. > >> The SPARQL Protocol is currently normatively defined using WSDL 2.0. As >> no one on the group is a WSDL expert, I took ACTION-341 >> (http://www.w3.org/2009/sparql/track/actions/341) to investigate whether >> we could specify the above behavior(s) in WSDL. > > Thank you for taking this action on. > > ... > > One note - the query protocol SPARQL 1.0 does not currently allow JSON > results (nor CSV, TSV or plain text nor even HTML all of which I've seen > used on the web). I'd consider all of these to be (healthy) extensions to the SPARQL 1.0 protocol. >> But anyway, I see two main options given this, neither of which is >> totally satisfying: >> >> Option 1: >> >> Rewrite the SPARQL protocol to be defined normatively without using WSDL >> 2.0. >> Pros: We can specify the exact behavior that we want. The protocols are >> simple enough that this is not overly complex. >> Cons: This is a large editing job, and we already have scheduling and >> resource issues with getting protocol to Last Call. Also, I'm sure there >> are many specification details of "the right way to use HTTP" that are >> taken care of us automatically by leaning on WSDL that we might have to >> be explicit about in this case. > > If there are such details, then there is use for WSDL for us. Can we > enumerate what they might be? I can't :-) I'm thinking of basic things like the fact that the key/value pairs within the query string can occur in any order without changing the semantics of the request. Again, I don't know if this should be a serious concern, or how much of that sort of thing we'd need to spell out explicitly if we re-do the protocol document. > As an implementer of the HTTP protocol, I didn't use the WSDL for any > details and had to go outside WSDL for normal HTTP details such as other > return codes. > >> Option 2: >> >> Only support the application/x-www-form-urlencoded scenario in the >> SPARQL 1.1 Protocol. SPARQL Update request strings can be used directly >> as per the informative text in the Uniform HTTP Protocol - >> http://www.w3.org/2009/sparql/docs/http-rdf-update/#http-patch . >> However, this use is limited to modifying a single graph that is >> identified by the request. >> Pros: Easiest path forward. >> Cons: Does not give a well-defined, interoperable way to directly POST >> SPARQL Update request strings. >> >> thoughts? > > I support Option 1. I asked on twitter and the response unanimously supported moving to an HTTP-only protocol. What do other members of the WG think? > I agree that it's a large editing job which is as much start again and > repurpose old content where possible. > > We can reuse the examples (2.2.1.3), text from 2.1.1.1.1 - 2.1.1.1.3, > 2.1.1.3.1-2.1.1.3.2) but on the plus side, I think it needs to define > the parameters by replacing the XML in 2.1.1.1 with a table. > > 2.1.1.1:: > http://www.w3.org/2009/sparql/docs/protocol-1.1/#query-In-Message Thanks for this. Lee > I believe we can lean heavily on HTTP for the details. > > > Andy >
Received on Monday, 3 January 2011 15:14:15 UTC