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

Hi Karol,

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

That's not the case really.
The input fields help constrain the input (text / number / list),
but it does not say where that input should come from not who should supply this.
Counterexample: my browser's autocompletion fills some <input>s for me.

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

Another name might be helpful indeed.

To have a better idea of naming, it's best to look at the context in which it will be used.
Perhaps going back to the example might help:

   </collection>  <PROPERTY>  <#template>.
   <#template> a hydra:IriTemplate.
     hydra:template "/collection{?first,last}";
     hydra:mapping [ hydra:variable "first"; hydra:property schema:givenName ];
     hydra:mapping [ hydra:variable "last"; hydra:property schema:familyName ].

So <PROPERTY> here is a relation between a collection and a template.
In that sense, we might be looking for something that says "is searchable by" / "can be filtered by"
or perhaps "has filter" or "has selector".

While I like the suggestion "matchAll" because of its close relationship to the functionality,
it might be hard to express it as a relation between a collection and a template.
I.e., we cannot say "a collection _matches all_ of the template";
it is more "when using this template, items that match all conditions will be returned".

I'll give a few suggestions, not all of which I like, but they might help brainstorming:
– hasFilter
– hasMatcher
– hasPropertyMatcher
– propertyMatcher
– allowsMatchingAll
– affordsMatching
– affordsMatchingAll
– affordsFilter


A second possibility is that we additionally give a type to the template.
Example:

   </collection>  :filter  <#template>.
   <#template> a hydra:IriTemplate, :ExactMatcher, :AndMatcher.   # or :ExactFilter, :AndFilter
     hydra:template "/collection{?first,last}";
     hydra:mapping [ hydra:variable "first"; hydra:property schema:givenName ];
     hydra:mapping [ hydra:variable "last"; hydra:property schema:familyName ].

So then the semantics are not in the property but in the type.
We might then even just keep hydra:search.

However, I think this typing option adds a lot of complexity for few gains:
for example, it doesn't allow us to express conditions for one field only.


A third possibility is a hybrid: we still settle on hydra:filter
and have "match All" as default semantics (first option),
but can change the semantics with types later on (second option).


All in all, I'm still mostly in favor of simply option 1 with either hydra:filter,
or something like "matchAll" (but adapted to fit as a property between collection and template).
I think that exact matching of all properties is so common, that a short option is justified.

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

I meant, the value for the property is the empty string, so that fits.
Non-existing triples are indeed harder, I wouldn't go there.

> Agreed with sticking to browser's behavior, but I'm somehow disagree with your conclusion on zero-length value.
> If server provides a form field it assumes that value always exists - either an empty string or other value. That value is then used, without focusing on the fact whether it's an empty string or not.

Yes.

> I'd be really careful with deciding on what's an "empty value". Consider a typed literal value:
> 
> ""^^xsd:int
> 
> According to RDF 1.1 this is a subject for storing in an RDF graph, but it is so called ill-typed as it doesn't fit to the lexical space of xsd:int.

Note that with ExplicitRepresentation, the following values are different:
– ""
– ""^^http://www.w3.org/2001/XMLSchema#int
Only the first is equal to ""^^http://www.w3.org/2001/XMLSchema#string

> Maybe it's worth of considering a default value predicate for mappings?

That seems like a good idea!

Best,

Ruben

Received on Saturday, 31 October 2015 13:19:40 UTC