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

Hi Ruben

Continuing the discussion...

>>> 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.
Well, I disagree with that. When you fill in an HTML form actually server 
exactly told the client what and how can be sent back. Input fields are 
telling the client that some values needs to be taken directly from user, 
hiddens are values enforced by the server and optionally Javascript behavior 
(again, given by the server) supply other use cases.

>>> </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.
It's clear now. My understanding was incorrect.

>> 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.
I'd change the hydra:filter to something else. Other, more generic 
implementations could fit better to the word "filter". Something like 
"matchAll" would be more suitable.

>>>>>> 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 "".
Ok, what does it mean "empty"? In RDF if no statement exist in a given set 
it means it's not there. It's more like Javascript's "undefined". Null is 
somehow "defined" - it's nothing but a versy special "nothing". Empty string 
"" is a value as good as any other.

I enjoy it event more :). Regards

Karol

Received on Saturday, 31 October 2015 12:49:06 UTC