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

Hi all,

Coming back to the issue of hydra:filter,
let's see if we can find something to all agree on.

>>>> 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 don't think having different predicates for different logical operators
> scales. Especially not if you consider that the number of parameters varies.
> So we should come up with something else.

So, it would then always be hydra:filter for any boolean conditions,
but could the default meaning then be the commonly used AND?

> IMO, hydra:filter describes the purpose of the referenced IRI templated very
> well. I would thus propose to stick to it for the time being and explore
> design that allow to make the IriTemplate at the other end more expressive.

+1

>>> How will we be able to express [an empty value]?
>> 
>> This would require ExplicitRepresentation and "".
> 
> Why should an ExplicitRepresentation be interpreted differently? Or are you
> saying that *no value* (instead of an empty string) of a property with
> ExplicitRepresentation represents a wildcard (match-all) then?

The problem is that, with BasicRepresentation, we cannot explicitly say "empty string".
We can leave a value empty, but does that mean "no value given" or "empty string"?

Given an IRI template like /{?firstName,lastName},
we can serialize this as /?lastName=Hilton
if we don't want to provide a first name with BasicRepresentation.
However, this is not possible with /?first={firstName}&last={lastName}.
Furthermore, it is not compatible with HTML forms,
which always serialize all contents, even if fields are empty.
Also, in HTML search forms, the convention is that "empty = not specified",
not that "empty = the value should have 0 characters".

>   ?property=&otherProperty=1  vs.  ?property=""&otherProperty=1 

Given ExplicitRepresentation, the first would mean
that there are no constraints set on the field property,
whereas the second means that only collection items
with a zero-length property field should match.

This is the behavior also implemented in the TPF server,
an important reason being the compatibility with HTML forms.

For example, this fragment:
    http://fragments.dbpedia.org/2015/en?subject=http%3A%2F%2Fdbpedia.org%2Fresource%2FParis_Hilton&predicate=&object=
gives items where:
– the subject is Paris Hilton
– the predicate is anything
– the object is anything

Since an IRI need to identify the same resource,
regardless of whether the representation is HTML, JSON-LD, or Turtle,
the JSON-LD and Turtle representations necessarily
have the exact same interpretation of parameters.

> An option to make this more flexible would be to explicitly describe that.
> Maybe something along these lines:
> 
>   </collection> :filter [
>     rdf:type :IriTemplate, :Filter ;
>     :filterSpecification [
>       rdf:type :AndFilter ;
>       :input [ :variable "first" ] ;
>       :input [ :variable "last" ] .
>     ] ;
>     :template "/collection{?first,last}" ;
>     :mapping [ :variable "first"; :property schema:givenName ] ;
>     :mapping [ :variable "last"; :property schema:familyName ] .
>   ] .

Looks good to me.
We might not strictly need filterSpecification as a separate entity,
i.e., we could also attach these properties to :Filter directly.
However, in the case of nested filters,
it might be nice to only have 1 "top" :Filter that is also an :IriTemplate,
whereas :FilterSpecifications would then never be :IriTemplates.

Could it be possible to have the AND interpretation as default,
since this would seem a common case?

> While this is quite
> straightforward I think, it puts quite a burden on the client. Assume that
> the client wants to filter a collection in a specific way. It would need to
> be able to check whether his query can be accepted directly by the server or
> whether it needs to rewrite the query into simpler subqueries or generalize
> the query and complement it with some additional client side querying.

That's true. However:
– We don't need to specify very specific filters in Hydra Core;
   just knowing that such extensions are possible, is good for :filter.
– We can specify multiple filter mechanisms;
   a precise but complex one as the above, and a simpler one.
   These might or might not be defined in different specifications;
   and even if we specify only one, others can be added later.
In other words: the important thing is the extensibility of :filter,
which I think we have.
So if this discussion is about :filter itself, I think it is a good candidate.

Best,

Ruben

Received on Thursday, 19 November 2015 08:30:21 UTC