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

Am 26.11.2015 14:22 schrieb Markus Lanthaler <markus.lanthaler@gmx.net>:
>

>
> To summarize, the things that still need to be discussed/decided are 
>   - do we need to make the filter function explicit or can we safely default 
> to AND 
>   - should we focus on describing Filters or FilteredViews (or similar) 
>   - if it's the former, can a IriTemplate be a Filter itself at the same 
> time 
>   - if it's the latter, how do we connect the filter, the FilteredView and 
> the IriTemplate 
>   - assuming that the same property needs to be used multiple times in a 
> IriTemplate, how we model that 
>   - assuming we need "transformations" or also just simply the equivalent of 
> the SELECT part of a SQL/SPARQL query how do we possibly model that 
>
> We don't need answers to all of these questions to move on but I'd like to 
> get at least a basic understanding of them and the community group's 
> sentiment about them. 

UriTemplate has many more ways to expand query parameters than name-value. Some examples:
* Param names can be repeated if they have an explode (*) modifier and a list is used to expand them. What does it mean when I query firstname=Ruben&firstname=Markus? Is that an OR query? My first impulse is to say yes, but... 
* Param values can be comma-separated when they were expanded from a list. What does that mean? 
* Param values can be truncated with a prefix modifier like {?var:3}.  Is that a startsWith query? Or is that not allowed in a :filter? 
* Param names with * can also be applied to associative arrays so that one param name can 'explode' to a list of attribute-value pairs. What is the relationship between the exploded params - AND?
* Does :filter only work with query params or can we also use other expansions like path-style aka matrix parameters?

We either have to restrict :filter to the exact param expansions it supports or think through the possibilities of Level 4 UriTemplate queries.

Best, 
Dietrich