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

Dear all,

I've waited a bit for comments on hydra:filter,
but given that things are calm now,
we might want to think about concrete steps to proceed.

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

>  - should we focus on describing Filters or FilteredViews (or similar)

Not in Hydra Core as far as i'm concerned.

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

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

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

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

Best,

Ruben

Received on Saturday, 19 December 2015 16:28:54 UTC