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

>> While I'm somehow unhappy to rush with hydra changes to cover particular 
>> needs in any other specification, TPF in this case
>Well, TPF is part of the Hydra family of specs, and the previous change to 
>the Core Vocabulary spec was breaking. TPF seems to be the most implemented 
>and thus most affected, so several implementers need to be notified. To 
>bundle all breaking changes, we need to prioritize this issue, which was 
>already on the list anyway. I hope this clarifies the timing.

OK. I expected this kind of answer. I'm trying to speed up my generic 
angularJS client to throw one more real life scenario to take into account 
:)


>> I'm not sure which fuzziness of the hydra:search you refer to.
>Note that these are Markus' words from the issue, not mine. But I agree: 
>hydra:search is defined as selecting items using the given attributes in 
>*some* way. It does not specify how to the server uses the attributes.
>Instead, hydra:filter states that members should be selected based on 
>whether they have properties that match all attributes. These are stronger 
>semantics than hydra:search.

As I said, this approach implies that all template variables should be 
treated that way. This disables a case when part of the variables should 
match property values on the server side and part of the variables should be 
filled with user input. Hypothetical hydra:filter somehow reverses the way 
the hydra:property is applied in the mapping but it doesn't solve the issue 
on how to fill the IriTemplate variables with values. Considering your 
example:
</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 ],
    ]
The client is informed that the variables first and last will match on the 
server side properties schema:givenName and schema:familyName respectively.
But he doesn't know on where to take the values from to craft the url! In 
case with hydra:search:
</collection> hydra:search [
      hydra:template "/collection?search={?search}",
      hydra:mapping [ hydra:variable "search"; hydra:property 
hydra:freetextQuery ]
    ]
my understanding is that client should take a value from the user input. 
Taking this by analogy:

</collection> my:customTemplatedLink [
      hydra:template "/container/{?name}",
      hydra:mapping [ hydra:variable "name"; hydra:property 
schema:givenName ]
    ]
name value that feeds the template is taken from the resource in context 
(i.e. PUT operation that updates the resource) or other user input based 
thingy.

Unless my understanding is incorrect, hydra:filter completely changes that 
logic but puts disturbance in the force - client doesn't know how to feed 
the template as the hydra:property doesn't point to the input but to the 
server side behavior.

I'd make it a standalone predicate disconnected from the hydra:search or 
present a new predicate applicable to the hydra:IriTemplateMapping, i.e.:
</collection> hydra:search [
      hydra:template "/collection?first={?first}&last={?last}",
      hydra:mapping [ hydra:variable "first"; hydra:property 
hydra:freetextQuery; hydra:filterOnProperty schema:givenName ],
      hydra:mapping [ hydra:variable "last"; hydra:property 
hydra:freetextQuery; hydra:filterOnProperty schema:familyName ],
    ]
This way you're consistent and fully express what you would like to express.


>> 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.
>That's a different kind of fuzzy (string matching).

Indeed.


> 1. Property of which value we want to filter on - from your example I 
> assume that this is a case

Clear

Best regards

Karol

Received on Thursday, 29 October 2015 21:04:01 UTC