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

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

Filters. Then the output of a filter can be anything.

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

I'd be very careful with modeling application-state changes as operations.
Fine with resource-state changes.

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

But the question is then just: can this be added using the hydra:filter?
Just settling that predicate doesn't stop us from doing that later.

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

Alright, I'll wait a bit then.

>  * introduce hydra:filter as a specialization of hydra:search

Check.

>  * the value of hydra:filter is an IriTemplate whose variables together
> define a filter

I thought the range of hydra:filter would be a filter?

>  * whether we should introduce a new class like Filter AndFilter, or
> FilteredView

My take: yes to Filter, no to others.

>  * whether we want to allow clients to select which "fields" a server
> should return

+0 (but not a showstopper to introduce hydra:filter itself,
these can always be added later on the object of hydra:filter)

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

Only explicitly listed items are part of the filter?

Best,

Ruben

Received on Sunday, 20 December 2015 17:03:33 UTC