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

Re: Query Verb Proposal

From: <henry.story@bblfish.net>
Date: Fri, 27 Mar 2015 13:47:13 +0100
Cc: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
Message-Id: <CAF1C862-63E9-4084-A38A-F6E7FD344503@bblfish.net>
To: ashok malhotra <ashok.malhotra@oracle.com>

> 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

Social Web Architect
http://bblfish.net/

> -- 
> All the best, Ashok
> 
Received on Friday, 27 March 2015 12:47:43 UTC

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