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

On 19 Dez 2015 at 17:28, Ruben Verborgh wrote:
> I've waited a bit for comments on hydra:filter,

Same here


> but given that things are calm now,
> we might want to think about concrete steps to proceed.

+1


>> +1. I think we are getting close to a solution and consensus.
>> 
>> 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
> 
> Seems like a safe default to me.

Yeah, we just need to make sure that we have a way to support different
filters in the future.

 
>>  - should we focus on describing Filters or FilteredViews (or similar)
> 
> Not in Hydra Core as far as i'm concerned.

The question was whether we should focus on filters or whether we should
look at them as parametrized views (FilteredViews)

 
>>  - if it's the former, can a IriTemplate be a Filter itself at the same
time
> 
> I don't see any objection to this,
> given that templates also can be used
> as the object of hydra:search currently.
> Templates _are_ filters, but there can be others.

Agree. One variation I have been tinkering is whether we should rather model
this as an operation. I still struggle to come up with a rule of what should
be an operation and what should be modeled differently (things like "changes
state" are not always as clear cut as they seem). I don't think we should
defer the decision about hydra:filter any further due to that though.


>>  - assuming that the same property needs to be used multiple times in a
>> IriTemplate, how we model that
> 
> Not an issue for Hydra Core I think.
> (But in any case, it's not a showstopper for the hydra:filter property.)

At least not for simple AND filters.


>>  - 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
> 
> Not issues for Hydra Core I think.
> (But in any case, it's not a showstopper for the hydra:filter property.)

Not sure I agree about that.. at least being able to select which fields to
return has been requested quite a few times by now.


>> 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. 
> 
> How would you feel about me writing a pull request for hydra:filter,
> based on the bits that we seems to agree on so far?
> It might be easier to judge based on a concrete proposal;
> the PR could then be used for a future call for consensus.

Sure, go ahead. I think just writing it down in an email might be more
efficient though and would allow us to discuss the right formulations etc.
separately.

Things I believe we have consensus on:
  * introduce hydra:filter as a specialization of hydra:search
  * the value of hydra:filter is an IriTemplate whose variables together
define a filter
  * the components are joined with AND
  * no value/empty string means ignore this component when using
     BasicRepresentation, and filters on empty strings on
ExplicitRepresentation

Things I'm not sure we have consensus on yet:
  * whether we should introduce a new class like Filter AndFilter, or
FilteredView
  * whether we want to allow clients to select which "fields" a server
should return
     (think the SELECT part of a SQL query)
  * the above and things like offset-based pagination might make it
necessary to 
     explicitly define which IRI template variables make up the filter and
which serve
     some other purpose



--
Markus Lanthaler
@markuslanthaler

Received on Sunday, 20 December 2015 15:50:23 UTC