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

>>> 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".
Fully agree. Name of that relation should reflect what it actually does. 
Let's wait for new suggestions and leave the filter for now.

>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
I'd throw few more:
- membersMatches
- membersMatchesAll
- whereMatches
- whereMatchesAll
- whereMembersMatches
- whereMembersMatchesAll

>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.
I think deciding on how far we want go in this area would help. If we decide 
to have AND, OR, NOT then next step would be to have cominations, then LIKE 
and then HAVING etc. I'm not keen to proceed so far. Typing indeed adds 
complexity. Maybe additional mapping predicate? Maybe rdf:List in 
hydra:mapping? Just thinking...

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

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

>> Maybe it's worth of considering a default value predicate for mappings?
>That seems like a good idea!
Just thinking:
- hydra:hasDefaultValue
- hydra:defaultValue
- hydra:default
- hydra:fallbackValue
- hydra:fallback

I'd also think about a "null" or "nothing" value. Unfortunately, rdf:nil 
cannot be used here but actually it's function is what we might seek.
Best

Karol

Received on Saturday, 31 October 2015 16:00:22 UTC