Re: WSDL and POSTing SPARQL Update requests directly

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.

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?

> 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).

> 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?

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 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

I believe we can lean heavily on HTTP for the details.


 Andy

Received on Wednesday, 29 December 2010 10:23:23 UTC