Re: update= vs query= (was: Re: http://www.w3.org/2009/sparql/track/actions/78)

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.

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

> 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

-- 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 12:53:09 UTC