Re: update= vs query=

Chimezie Ogbuji wrote:
> Comments below inline.
> 
> On 9/23/09 3:58 AM, "Lee Feigenbaum" <lee@thefigtrees.net> wrote:
>> When we discussed SPARQL/Update over SPARQL/Protocol, there seemed to be
>> agreement that it must be the case that a URI can be a SPARQL endpoint
>> without needing to support SPARQL/Update over the protocol. i.e. there
>> can be read only endpoints.
>>
>> it was less clear whether there's a case for write-only endpoints.
> 
> Yes.
>  
>> in either case, it was suggested that a natural way to extend the
>> protocol would be to have update statements over HTTP be indicated with
>> update= rather than query=. Chimezie wondered on the telecon and below
>> whether that was necessary.
> 
> I was concerned about if it is necessary but my motivation was also about
> avoiding the practice of embedding an operation as a query string /
> parameter to a URI request.  It bypasses the use the 'natural' operations
> (GET/POST/etc..) to determine what action is taken and it also violates the
> opaqueness of URI principle since a server has to parse the request to
> determine what operation to take.

I'm not clear on how doing everything with query= is better in this 
regard. Or are you proposing that we'd require a separate URI to handle 
SPARQL/Update vs. SPARQL/Query strings?

Maybe an example would help?

>> ...which has child elements query, default-graph-uri, named-graph-uri,
>> which is why that's what SPARQL over HTTP looks like.
>>
>> All of which is to say, surprisingly to me, that the operation name
>> isn't encoded into HTTP bindings at all.
> 
> Well, my WS* mojo is lacking so I'm not sure I follow the meaning of the
> WSDL above, but I guess I'm also not sure why this is surprising.  The way I
> think of it, there is one interface (an interface for receiving queries)
> that is bound to two HTTP operations (or services):
> 
> - Service URI + 'POST'
> - Service URI + 'GET'
> 
> So the operation name is already determined at the HTTP protocol level
> *before* the server even gets to matching up the arguments (query,
> default-graph-uri, etc..) and parsing the SPARQL query/

Hmm, I'm not sure about that. As I understand it (not too well, 
admittedly), a WSDL interface is composed (potentially) of many WSDL 
operations. The interface then gets bound to HTTP via the WSDL binding 
mechanism. Within that binding, each operation gets bound to a 
particular HTTP method, with particular faults, content encodings, 
parameter separators, etc. (the syntax summary in 6.2 at 
http://www.w3.org/TR/wsdl20-adjuncts/#http-binding is helpful here).

Then someone comes along and deploys an endpoint, and describes the 
endpoint in WSDL and gives a URI for the interface (i.e., for all of the 
operations). But the thing I was surprised about is, message 
serialization is only based on the contents of an operation's input 
message, and there's no place at which the operation's name comes into 
play. So if my endpoint is /service and I have 3 operations, they all 
get invoked as some variant of /service?param1=...&param2=... and the 
only thing that my server has to distinguish between the operations is 
the parameters to each.

(Now, the binding for each operation can explicitly specify a 
whttp:location property which I believe is relative to the endpoint's 
URI, so you _could_ epxlicitly include the operation in the URI, but 
that's not what the default HTTP bindings do.)

Anyway, I'm not sure this really matters.

>> Anyway, practically speaking, the benefit of always doing query= seems
>> to be the same benefit as we have right now for having the same
>> operation for all SPARQL query types (select, construct, ask, describe)
>> -- a generic client can easily take a query string from a user and pass
>> it to a SPARQL endpoint, without needing to parse it at all.
> 
> Yes, to the client, the URI is opaque (it doesn't need to interpret the part
> of the URI that is the address of the service and it doesn't need to parse
> the query), it just sends it along.  Ofcourse, it needs to know apriori that
> the user is requesting a SPARQL query in order to know to use the GET or
> POST HTTP methods since SPARQL query is *bound* to HTTP in this way.
>  
>> The benefit to having update= is - I think - that it's easier for a
>> read-only endpoint to reject SPARQL/Update queries without needing to
>> parse the query.
> 
> But it does so by parsing at least part of the URI, which I don't think is a
> good practice.  If only the SPARQL/Query interface was bound to to an HTTP
> 'service', then the server would simply not know how to handle a
> SPARQL/Update request

In the case where it's all query=, it needs to parse a level deeper, 
right? Unless you're suggesting that we require that SPARQL/Update and 
SPARQL/Query never be both available at the same endpoint URI?

Lee

> -- Chimezie
> 
>> What do people prefer?
>>
>> Lee
>>
>> PS I learned that the WSDL HTTP serialization rules are order specific -
>> so in SPARQL Protocol you must do the query parameter followed by the
>> default-graph-uri parameter followed by the named-graph-uri parameter in
>> your HTTP query strings. Intended or unintended consequence?
>>
>> PPS I think we might use WSDL's "IRI Style" incorrectly because the
>> local name of our input message's XML root element (query-request) is
>> not the same as the operation name (query). Is there anyone in the world
>> who possibly cares about this?
>>
>> Chimezie Ogbuji wrote:
>>> Per my ACTION-78,
>>> Continue discussion of update= vs. query= on the mailing list
>>>
>>> What I was suggesting during the telcon this tuesday was: whether or not an
>>> endpoint is providing either read (GET/POST) or write (POST) services or
>>> both should be implementation-specific and not triggered by query parameters
>>> in the resource URI.
>>>
>>> ----------------------
>>> Chimezie
>>> Heart and Vascular Institute (Clinical Investigations)
>>> Cleveland Clinic (ogbujic@ccf.org)
>>> Ph.D. Student Case Western Reserve University
>>> (chimezie.thomas-ogbuji@case.edu)
>>>
>>>
>>> ===================================
>>>
>>> P Please consider the environment before printing this e-mail
>>>
>>> Cleveland Clinic is ranked one of the top hospitals
>>> in America by U.S. News & World Report (2008).
>>> Visit us online at http://www.clevelandclinic.org for
>>> a complete listing of our services, staff and
>>> locations.
>>>
>>>
>>> Confidentiality Note:  This message is intended for use
>>> only by the individual or entity to which it is addressed
>>> and may contain information that is privileged,
>>> confidential, and exempt from disclosure under applicable
>>> law.  If the reader of this message is not the intended
>>> recipient or the employee or agent responsible for
>>> delivering the message to the intended recipient, you are
>>> hereby notified that any dissemination, distribution or
>>> copying of this communication is strictly prohibited.  If
>>> you have received this communication in error,  please
>>> contact the sender immediately and destroy the material in
>>> its entirety, whether electronic or hard copy.  Thank you.
>>>
>>>
>>>
> 
> 
> ===================================
> 
> P Please consider the environment before printing this e-mail
> 
> Cleveland Clinic is ranked one of the top hospitals
> in America by U.S. News & World Report (2008).  
> Visit us online at http://www.clevelandclinic.org for
> a complete listing of our services, staff and
> locations.
> 
> 
> Confidentiality Note:  This message is intended for use
> only by the individual or entity to which it is addressed
> and may contain information that is privileged,
> confidential, and exempt from disclosure under applicable
> law.  If the reader of this message is not the intended
> recipient or the employee or agent responsible for
> delivering the message to the intended recipient, you are
> hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited.  If
> you have received this communication in error,  please
> contact the sender immediately and destroy the material in
> its entirety, whether electronic or hard copy.  Thank you.
> 
>

Received on Wednesday, 23 September 2009 13:35:00 UTC