Re: ldp wishlist for crosscloud - QUERY HTTP verb

On 11/10/14 5:52 PM, henry.story@bblfish.net wrote:
>> 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 )

Yes, I agree with these point. My concern, from experience, is that 
Link: based relations are the path-of-least-resistance, in regards to 
HTTP tweaks.

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

Yes, we are in agreement.

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

Yes. SPARQL 1.1 added a Read-Write aspect that was missing from SPARQL 
1.0. This enhancement works wonderfully well.

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

We've always know that :)

>
> In fact once you look at the pair PATCH/PUT QUERY/GET
>
>     PATCH   <-> PUT
>     QUERY   <-> GET
>
> you can see the very strong similarity.

Yes.

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

Yes, for sure. The Query verb is important. My only concern is 
resistance to new HTTP verbs by those who aren't that interested (for 
mostly non technical reasons) in these data interaction related matters.

>   Not much changes, nothing big,
> just the last tweaks one needs to make the thing work as designed.

+1000...


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


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