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

Hi Ruben

While I'm somehow unhappy to rush with hydra changes to cover particular 
needs in any other specification, TPF in this case, please find find few of 
my questions below:

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

I'm not sure which fuzziness of the hydra:search you refer to. This 
templated link is pretty straigh forward with a well defined range, which is 
an IriTemplate, which exactly fits your example. Indeed, hydra:freetextQuery 
is fuzzy as it takes in theory an user's input, but doesn't bind that input 
with any particular property thus it might be not suitable in many 
situations.

</collection> hydra:search [
     hydra:template "/collection?first={?first}&last={?last}",
     hydra:mapping [ hydra:variable "first"; hydra:property 
schema:givenName ],
     hydra:mapping [ hydra:variable "last"; hydra:property 
schema:familyName ]] .

The only case I acknowledge to have something special would be a situation 
when the property's desired value is from user input, but that would bind 
whole template and it's mapping to that logic, which I believe would do more 
harm than good. I'd go with either mapping modification or special 
predicates in the variable mapping.

Please note that we're talking about two properties here:
1. Property of which value we want to filter on - from your example I assume 
that this is a case
2. Property from which we want to take a value into the IriTemplate - I 
think this logic is reflected in the hydra:IriTemplateMapping as in the 
freetextQuery example; property defines an input for the template variables, 
not on which property to filter on (or how I understand the spec).

Please feel free to deliberate on this as I'm deeply involved in similar 
concerns with my experiences with Hydra.

Best

Karol Szczepański

Received on Thursday, 29 October 2015 19:40:53 UTC