Re: ldp wishlist for crosscloud - QUERY HTTP verb

> On 10 Nov 2014, at 22:51, Kingsley Idehen <kidehen@openlinksw.com> wrote:
> 
> On 11/10/14 4:02 PM, Ashok Malhotra wrote:
>> Hi Kingsley:
>> Could you give an example of how a query using a Link header
>> would look like?
>> All the best, Ashok
> 
> Ashok,
> 
> Henry has covered this already, all I am hinting here is that a "Link:" request header route is going to be more feasible than getting a new verb added to HTTP. Basically, via a Link: headers in the request, one can indicate the nature of the request using RDF Language i.e., look at Link: as just another notation for representing relations using RDF Language (which is distinct for any specific notation).

The same argument could be made for PATCH, DELETE and PUT, 
and they were in fact made on this list in the first 6 months
of this groups life. 

The question is why was PATCH added as a verb. And this in my view 
has to do with the caching  architecture of the web. That
is there are certain things that are not quite correct when
you don't use those verbs to try to do the same thing.

Here is the introduction to the PATCH RFC
http://tools.ietf.org/html/rfc5789

[[
   A new method is necessary to improve interoperability and prevent
   errors.  The PUT method is already defined to overwrite a resource
   with a complete new body, and cannot be reused to do partial changes.
   Otherwise, proxies and caches, and even clients and servers, may get
   confused as to the result of the operation.  POST is already used but
   without broad interoperability (for one, there is no standard way to
   discover patch format support).  PATCH was mentioned in earlier HTTP
   specifications, but not completely defined.
]]

The same types of arguments could be made for QUERY. ( see below for why )


> 
> Ultimately, all I see is a slot for SPARQL payloads, everything else (in my eyes) is a SPARQL redo adventure, for all the wrong reasons.
> 
> SPARQL is extremely powerful and useful, especially the SPARQL 1.1 edition. Combine that with WebID-TLS and ACLs and you have everything we need ++.

So we are in agreement here, because I was not arguing for changing SPARQL, which would
clearly be the default query language for RDF Sources ( and perhaps even beyond ). 

I did mention that perhaps in the context of LDP and with closer attention to
Web Architecture, a subset of SPARQL could be found that was simpler to implement,
and without some of the features that are better done at the HTTP layer. But
that would be to the good.

Notice also that SPARQL Update fits with PATCH where Sparql Queries don't. They
do very different things, and in fact it is not surprising when one notices
that a QUERY is like GET - it does not change the resource - whereas a PATCH is like 
PUT - it does change the resource.

In fact once you look at the pair PATCH/PUT QUERY/GET 

   PATCH   <-> PUT 
   QUERY   <-> GET

you can see the very strong similarity. PATCH reduces the 
bandwidth needed when doing a PUT, whereas QUERY reduces
the bandwidth needed when doing a GET. They act as inverses
of one another.

So my guess is that by arguing along those lines, one could
write an RFC, by nearly copy pasting rfc5789 .

I think QUERY could just help align SPARQL much more closely
with the web, and that is kind of what I think this group
is in an ideal position to do. Not much changes, nothing big,
just the last tweaks one needs to make the thing work as designed.



> 
> Kingsley
>> 
>> On 11/10/2014 2:04 PM, Kingsley Idehen wrote:
>>> On 11/10/14 1:43 PM, Ashok Malhotra wrote:
>>>> So, yes, a QUERY verb would be preferable.
>>>> How difficult would this to get through?
>>>> We could ask Mark Nottingham.
>>>> All the best, Ashok
>>> 
>>> He will more than likely direct you back to a Link: relation.
>>> 
>>> Note, you can use Link: headers  in HTTP requests too :)
>>> 
>>> 
>>> [1] http://lists.w3.org/Archives/Public/public-webpayments/2014Jul/0112.html .
>>> [2] https://github.com/mnot/I-D/issues/61 .
>>> 
>> 
>> 
>> 
>> 
> 
> 
> -- 
> Regards,
> 
> Kingsley Idehen	
> Founder & CEO
> OpenLink Software
> Company Web: http://www.openlinksw.com
> Personal Weblog 1: http://kidehen.blogspot.com
> Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
> Twitter Profile: https://twitter.com/kidehen
> Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
> LinkedIn Profile: http://www.linkedin.com/in/kidehen
> Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this

Social Web Architect
http://bblfish.net/

Received on Monday, 10 November 2014 22:53:04 UTC