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

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.

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.

 From the SPARQL/Protocol point of view, we seem to have a few choices 
for how to support SPARQL/Update:

   + It can be its own Interface (a la SparqlQuery)
   + It can be its own Operation (a la query)

...others?

In either case, the WSDL HTTP bindings seem to say ... if i'm reading 
them right ... that the only thing that determines how to construct a 
GET IRI or the qyuery string for the body of a POST is the local name of 
the sequence of child elements of the element that forms the input 
message element for the operation. right now it's:

<xs:element name="query-request">
   <xs:complexType>
     <xs:sequence>
       <xs:element minOccurs="1" maxOccurs="1" name="query" 
type="xs:string">
        <xs:annotation>
	      <xs:documentation>query is an xs:string constrained by the 
language definition,
          http://www.w3.org/TR/rdf-sparql-query/#grammar, as "a sequence 
of characters in
          the language defined by the [SPARQL] grammar, starting with 
the Query production".</xs:documentation>
        </xs:annotation>
       </xs:element>
       <xs:element minOccurs="0" maxOccurs="unbounded" 
name="default-graph-uri" type="xs:anyURI"/>
       <xs:element minOccurs="0" maxOccurs="unbounded" 
name="named-graph-uri" type="xs:anyURI"/>
     </xs:sequence>
   </xs:complexType>
</xs:element>

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

the main difference between making it a separate interface vs. a 
separate operation is...? I'm not sure yet, need to re-learn that. Maybe 
what faults can be returned?

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.

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.

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

Received on Wednesday, 23 September 2009 07:59:55 UTC