Re: Call for consensus on hydra:filter (ISSUE-45)

Hi Ruben,

I think your proposal is straight forward and I think it would be a plus 
to have such a generic filtering mechanism in hydra
because it addresses real issues people are facing when they want to 
describe typical REST APIs.

__But__ I think be should take a step back and first decide whether it 
is a design goal of hydra to address querying and filtering in general.
That's exactly the issue I mentioned earlier when discussing with 
Dietrich about a filtering predicate [1].
If we continue to add more balconies and bays to hydra for this concern, 
we slowly but steadily end up with a fully fledged vocab.
Why? Because one thing leads to the next. Example: The first question that
popped in my head when I read your proposal is: "fine, and what about 
sorting?".

The thing is that the whole problem is complex and there are subtle bus 
nasty details to take car of:
How to reflect data types like boolean (is "1", 1 true?) or how to deal 
with date-time formats?
What about boolean concationation of filters? etc. etc.
There are efforst that already dealt with these issues or at least oarts 
of if, like OData [2]

BG, Thomas

[1] https://lists.w3.org/Archives/Public/public-hydra/2015Oct/0184.html
[2] 
http://docs.oasis-open.org/odata/odata/v4.0/errata02/os/complete/part2-url-conventions/odata-v4.0-errata02-os-part2-url-conventions-complete.html#_Toc406398129


Am 29.10.2015 um 14:24 schrieb Ruben Verborgh:
> Dear all,
>
> In order to finalize the TPF spec and start work on the test suite, there is one more issue for which we need consensus.
>
> The hydra:search property is deliberately fuzzy to not restrict its usage unnecessarily and thus not always suitable. Sometimes it is necessary to filter a collection's members based on the value of their properties (not properties of their properties or similar things). To enable such use cases, a specialized subproperty of hydra:search named hydra:filter would be introduced. The semantics would be that a template
>      </collection> hydra:filter [
>        hydra:template "/collection{?first,last}",
>        hydra:mapping [ hydra:variable "first"; hydra:property schema:givenName ],
>        hydra:mapping [ hydra:variable "last"; hydra:property schema:familyName ],
>      ]
> that is expanded to
>      /collection?first=Markus
> would return a collection in which all members correspond to the following graph pattern
>      ?member schema:givenName "Markus"
>
> Additional clarifications:
> – if a parameter value is empty, it is ignored (i.e., an empty value does not mean the property needs to be empty)
> – if a filter contains multiple conditions, each of the result items must match *all* of the conditions
> Examples:
> – /collection?first=Markus&last= returns a collection of items with first name "Markus"
> – /collection?first=Markus&last=Lanthaler returns a collection of items with first name "Markus" and last name "Lanthaler". Items that only meet one of these conditions are not returned.
>
> Proposed changes to the spec:
> – addition of hydra:filter as a subproperty of hydra:search
> – define hydra:filter using the semantics above
>
> This serves as a call for consensus. Before we proceed with marking ISSUE-45 [1] as resolved and implementing the changes in the spec, I would like to ask if anyone has any concerns or objections against this proposal.
>
> Please submit your comments by Thursday, November 5th.
>
> Best,
>
> Ruben
>
> [1] https://github.com/HydraCG/Specifications/issues/45
>
> PS Markus, I hope you don't mind me launching a call for consensus.
> If this is only a chair's job, I sincerely apologize.

Received on Friday, 30 October 2015 09:18:38 UTC