Re: WSDL and POSTing SPARQL Update requests directly

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