Re: How to extend the interaction model to support queries?

On Mon, Jul 28, 2014 at 1:18 PM, Alexandre Bertails <alexandre@bertails.org>
wrote:

> All,
>
> The last thread on the interaction model reminded me of a question we
> have at work.
>
> At Pellucid, we retrieve data from containers using a custom language.
> For now, it does filtering, ordering, inlining, and grouping. No
> SPARQL. No paging at the HTTP level like in LDP. It's RDF data all the
> way.
>
> Here is the way that works at the protocol level: the container
> _itself_ supports the filtering API, and we POST the query to it. As
> you can see, we violate the semantics of an LDPC, as we are not adding
> the query to the container. We don't really want to have a separate
> endpoint for each container. We would be happy to use HTTP SEARCH or
> QUERY, if they were available or not overloaded.
>
Alexandrei (aka Alexandre and Andrei),

Instead of a new HTTP verb, would using POST + query parameter be worse:
POST <container URL>?<search param>   ?
I understand that this another resource on the web, different URI, but
would be the same endpoint (ie entry point in your server impl).  You'd
need a way anyway for your "LDP on steroids" client to know it can safely
send these to execute a query vs create a resource with this content.  In
other words, I would think you'd want a discover mechanism wish would
expose a URI to the endpoint for search, which could just be getting back
some header values or data from the container itself, URL-template, etc.

Curious to hear how you do discover and sharing of the endpoint.

Cheers,
Steve


>
> Is there a good way to do that while being fully compliant with the
> spec, *and* ?  This is the same question for people who wants to add
> SPARQL query capabilities to an LDPC.
>
> Alexandre
>
>