Re: Moving forward with hydra:filter (ISSUE-45)

Dear all,

> I think Ruben was simply a bit too enthusiastic as we were finally able to solve an issue he raised more than half a year ago.

Yes, blame my enthusiasm. Sorry, folks!

> Our (and basically any standardization effort's) process is to first have a discussion. When there seems to be consensus the chair sends out a Call for Consensus to give people that didn't participate in the discussion that far a last chance to raise their objections before an official decision is being made. This process works quite well, so let's try to stick to it. If you have ideas on how to improve the process, please let me know. I'm always open to change things to the better.

Thanks for spelling this out, I fully agree with this process.
My mistake was in a) thinking that the discussion had already happened
b) misinterpreting the purpose and sender of a Call for Consensus.

Maybe something else that's relevant: as far as the "rushing" part is concerned:
I guess my fear is that, with several independent TPF implementations existing
based on an earlier version of the Hydra Core Vocabulary,
we would become limited in the changes we can still do.
I.e., in the future, if the TPF specification uses something that Core want to change,
it might be difficult because many different implementations already chose the old way.
For instance, the change from hydra:nextPage to hydra:next
will already involve getting 13 implementations to change,
the majority of which I do not control.
It's not hard to imagine that this might create pressure in the future
if TPF relies on features that have not been fully decided.
(Just a background note here—not an excuse for me going too fast.)


Back to the issue:


>> The client is informed that the variables first and last will match on the 
>> server side properties schema:givenName and schema:familyName respectively.

Yes, and I think this is the *only* thing the server should do.
It's not up to the server to say where the client should get the value from.

>> </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. 

I disagree. The meaning of hydra:freetextQuery as I understood it is:
"the server says that the search parameter is used as a free-text field search;
e.g., if it contains 'Hilton', it will match a resource with name "Paris Hilton''.

It does not say "the user should type in a free text query".

In any case, we should not forget that hydra:freetextQuery is a very special case,
that does not work like any of the other cases (and is maybe problematic).


In other words, I think that Karol's

>>>> 2. Property from which we want to take a value into the IriTemplate 


never applies. Please correct if I'm wrong.


> The same is true with hydra:filter. One thing that we need to clarify is whether we always want those conditions to be combined by a logical AND or whether we want to allow other functions (OR, NOT) as well. This quickly brings us into complex territory though.

This would be my suggested semantics for hydra:filter:
it's the specific case in which we combine conditions with AND.
Other predicates can be implemented differently;
they all can derive from hydra:search.

>> 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.
> 
> No, I think you misunderstood this. We are not trying to parse components of a URL here but try to tell the client how to construct URLs that enable filtering of the collection the hydra:filter property is attached to.

+1

>> 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.
> 
> I think what is being proposed expresses exactly the same but allows a terser serialization.

More or less +1… I'd say that hydra:search does not leave the "power"
to subsequent properties to say how they want to be interpreted.

>>>>> 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)
> 
> How will we be able to express that then?

This would require ExplicitRepresentation and "".

> Are we sure that is all we need? How would we extend the model if we find out later that we need more operators?

By not using hydra:filter, but something else.
I.e., hydra:filter is a very precise variant of hydra:search,
for a common, but simple, case.

Best,

Ruben

Received on Thursday, 29 October 2015 22:34:42 UTC