Re: ldp wishlist for crosscloud - QUERY HTTP verb

> On 10 Nov 2014, at 15:05, ashok malhotra <ashok.malhotra@oracle.com> wrote:
> 
> Re. Query, why isn't a query string sufficient to express (simple) queries?
> Trying to get a new verb approved seems like a long, hard road.
> Ashok

Hi Ashok,

  thanks for giving me the opportunity to gather the different arguments I put
forward in this thread, that were perhaps dispersed over the place.

Syntax and Content-Negotiation
========================

For one the HTTP QUERY verb does of course not remove the need for a
query syntax. On the other hand the advantage of the HTTP verb is that
it is syntax agnostic, due to HTTP supporting Content Negotiation.
So one could use SPARQL as the Query language, XPath, some JSON
query syntax such as  perhaps jaql or whetever is widely adopted there [1].

For our interest let us take SPARQL as the appropriate syntax.

Usually  you would query and LDPR Source perhaps with a query such as

QUERY /henry/foaf HTTP/1.0
Content-Type: application/sparql-query
Content-Length: 78

CONSTRUCT { ?p ?rel ?o . }
WHERE {
   <#hjs> foaf:knows ?p .
   ?p ?rel ?o .
}

Or if you were to query an LDPC you could run a query 
such as the following to get just to what you needed in
the LDPC:

QUERY /ldpc HTTP/1.0
Content-Type: application/sparql-query
Content-Length: 78

SELECT ?ldpr 
WHERE {
   <> ldp:contains ?ldpr .
    ?ldpr dc:author <http://example.org/joe#me> .
   GRAPH ?ldpr { 
      ?ldpr a ping:Notification .
   }
}


Why the HTTP QUERY verb?
======================

So that leaves the question why not have every resource link to another resource 
on which one can then send the query. Of coures the same question can be asked
as to why not have a link to a resource where one can PATCH, DELETE, or PUT
And that should of course give you the reason as to why a verb can be interesting.

Here are the arguments I put forward to answer that question, and that fall under a few
groups: epistemological ones ( how do I know that a resource is going to do what I ask it
to? ), pragmatic ( how do I avoid the resource being out of sync? ), and caching ones.

The advantage of a verb is that you reduce the number of resources down to a 
minimum, and it reduces epistemological dissonance.

So if I want to query a particular resource I don't have to worry that one resource 
is pointing me to another one that is out of sync, that now for some reason does 
something very different from what I thought it was going to do: perhaps POSTing 
a QUERY there now archives it. How does one do conditional QUERY on another resource?
    ( of course there is some way one can do it, but how much more complicated
     is it over just doing the right thing )  
This would also be a nice way to make SPARQL fully RESTful.

The HTTP verbs form part of what in philosophy of language were called Speech acts.
And in those one usuall found a few general types:
  - declarative expression of something ( similar to GET )
  - the making of something something, eg. a marriage "You are now man and wife" (POST)
  - asking a question ( QUERY )
  - ordering something to happen 
  - taking something back ( PATCH ? )

Anyway it feels like this is the right level to do something, and I'd say that
given that it was considered very early on in HTTP may give it a lot more weight
than other methods. That's why I pointed here:
   
http://www.w3.org/Protocols/HTTP/Methods.html

So how does QUERY relate to the other verbs?
===================================


consider that SPARQL UPDATE naturally falls under the HTTP PATCH verb,
whereas a SPARQL Query naturally falls under the HTTP QUERY verb.

They have very different HTTP caching effects.

- A PATCH with SPARQL Update that succeeds naturally invalidates all caches 
  along the way but a QUERY that succeeds naturally does not. ( something 
  that won’t  be expressible in the link scenarios )

- a series of QUERIES on graphs resources could end up leading a cache to 
  the full version of the graph. One could imagine the cache keeping answers 
  to the queries and appending them ( as long as the etag does not change ) 
  calculating a strong graph hash for the results it had cached. At some point 
  that hash could match the remote hash and the cache would know it had all 
  the information. Ie a series of QUERIES at the limit is equivalent to a GET.

- POST is really about creating new resoures, but when you do a QUERY you
  are not really creating a new resource, you are getting a version of the existing
  resource. So using POST for QUERIES as for PATCHes is not good HTTP.

I think one could add to the list of arguments starting from first principles
to explain why QUERY was in the initial HTTP specs.


How difficult is it to deploy
====================

I answered James Snell’ question


>> The key challenge for pushing new http methods through is implementer support.
>> Some popular platforms (like node.js for instance) do not have great support
>> for extension methods.
> 
> That sounds like a lesser problem. Node.js is open source and can be changed,
> if developers are enthusiastic about it. For example to get node.js people
> enthusiastic one could get them to consider that QUERY could work with their
> favorite JSON query language - perhaps https://code.google.com/p/jaql/ <https://code.google.com/p/jaql/> ( not sure
> what is hot there at present )
> 
> The more difficult problems would be the caching infrastructure, though that is less
> important as it used to be with HTTPS everywhere gaining ground.
> 
> Also I am not against creating a standard link relations that do the job where 
> the methods cannot be  used, as a transition solution. It is just that I think one
> should be clear about what the correct web architectural solution would be, and
> let that guide one. It helps one think much more clearly about what is going on.
> For example here about what SPARQL is doing and perhaps how LDP can
> simplify SPARQL. ( eg: remove DELETE GRAPH from SPARQL specs and move
> it to HTTP ).

That’s about as much as I can think of for the moment. I hope it helps.

[1]  https://code.google.com/p/jaql/ <https://code.google.com/p/jaql/> 


Social Web Architect
http://bblfish.net/