W3C home > Mailing lists > Public > public-ldp-wg@w3.org > March 2015

Re: Query Verb Proposal

From: ashok malhotra <ashok.malhotra@oracle.com>
Date: Fri, 27 Mar 2015 11:15:10 -0400
Message-ID: <551573FE.9080901@oracle.com>
To: Henry Story <henry.story@co-operating.systems>
CC: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
Henry:
Re, cacheing.
A HTTP cache is a collection of key-value pairs where the key is the resource URL
and the value is the collection.  If we were to try and cache the results
of queries, the key would need to be the resourceURL+Query and the value
would be the result of running the query.  This is doable but different from the
standard HTTP cache and would need additional tooling.

Your other comments on the difficulty of cacheing are also valid.
All the best, Ashok

On 3/27/2015 8:46 AM, Henry Story wrote:
>
>> On 25 Mar 2015, at 23:52, ashok malhotra <ashok.malhotra@oracle.com> wrote:
>>
>> Please review the first draft of the Query Verb Proposal at:
>> https://github.com/jasnell/specs/blob/master/httpbis/draft-snell-search-method-00.txt
>>
>> This is a minimalistic proposal since it was felt that a smaller proposal had a better
>> chance of being accepted than a more complex proposal.
>>
>> Many different query syntaxes can be supported.  Each with its own media type.
>
> Looks very good.
>
> Here are some questions:
>
> • section 2: "The response to a SEARCH request is not cacheable.  "
>
> I suppose that is because a search may go beyond the limit of the resource requested,
> e.g. I suppose you could do a SEARCH on an LDPC that queries the LDPC but also the
> content. In that case the LDPC state may not change, but the results would differ.
>
> I suppose there could be cases where it was cacheable: e.g. when querying an LDP Graph.
> I wonder if there is a way to distinguish those two cases... Perhaps it would require
> a weak container etag, so that any change to the contained resources would change that
> etag.
>
> • section 4.1
>
> I think if one is to start with an example one really should start with a really good
> and simple one.  But this one has exactly the wrong feel
>
> ```
>     SEARCH /query HTTP/1.1
>     Host: example.org
>     Content-Type: application/sparql-query
>     Accept: application/ld+json
>
>     PREFIX foaf:  <http://xmlns.com/foaf/0.1/>
>     SELECT ?name ?email
>     FROM <http://www.w3.org/People/Berners-Lee/card>
>     WHERE {
>         ?person foaf:name ?name .
>         OPTIONAL { ?person foaf:mbox ?email }
>     } ORDER BY ?name LIMIT 10 OFFSET 10
>
> ```
>
> This feels wrong because you are sending a query onto a specialised query
> resource, where the point of the SEARCH verb ( "QUERY" would make this a bit
> clearer  here ) would be to query the resource directly. That is the
> prototypical query should be
>
> ```
>     SEARCH /People/Berners-Lee/card HTTP/1.1
>     Host: www.w3.org
>     Content-Type: application/sparql-query
>     Accept: application/ld+json
>
>     PREFIX foaf:  <http://xmlns.com/foaf/0.1/>
>     SELECT ?name ?email
>     WHERE {
>         ?person foaf:name ?name .
>         OPTIONAL { ?person foaf:mbox ?email }
>     } ORDER BY ?name LIMIT 10 OFFSET 10
> ```
>
> This allows you to give an extra reason for the QUERY verb:
> that you are not going through a third party resource, which may
> be out of sync with the resource itself. Querying one resource about
> another is a very special case of a very special type of resource.
>
> It also makes for a better RESTful story, and would allow some
> better integration with the caching layer. It would also tie
> in much more nicely with LDP. It would allow you to argue that
> SEARCH is to GET what PATCH is to PUT.
>
> Hope this helps,
>
>
> 	Henry
>
>
>
>> --
>> All the best, Ashok
>>
>
Received on Friday, 27 March 2015 15:15:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:17:53 UTC