Re: Filters as views (ISSUE-45)

Hi Markus,

>> Negative points (for me):
>> - filter as a boolean on parameters just won't cut it.
> 
> I agree and mentioned that in my initial mail:
> 
>  On 10 Jan 2016 at 18:13, Markus Lanthaler wrote:
>> This is easily expandable. We can either allow more complex values for
>> hydra:filter or introduce additional properties.

Okay, but what is the meaning then of:
– hydra:filter?
– a boolean as value of hydra:filter?
I just don't understand how to interpret this.

>>   This is not apparent from the above example,
>>   because there is only one property.
>>   With multiple properties, the desired default semantics is "AND",
>>   but this cannot be realized with a property attached to individual parameters.
> 
> We have a whole lot of proposals [1] on how those descriptions might look
> like but we didn't make much progress. I would thus like to try to reach
> consensus on the basic design and ignore more sophisticated use cases

But AND is supposed to be the default case,
and it seems we are not even realizing that.
Example:

 {
   "@id": /collection",
   "@type": "Collection",
   "view": {
     "@type": "ViewTemplate",
     "template": "/collection{?f,l}",
     "mapping": [{
       "variable": "f"
       "property": "firstName"
       "filter": true
     }, {
       "variable": "l"
       "property": "lastName"
       "filter": true
     }]
   }
 }

Does this mean anything more than the equivalent with hydra:search?
If not, what are we gaining?

My primary interest in this discussion is to be able to say
"use this hypermedia control to only see the elements
 of the collection that have values equal to those you supply”.

>> BTW, would your proposal mean that hydra:search becomes extinct?
> 
> Possibly, but that's a different discussion :-)

I don't know if it's a different discussion, it seems very related.
We shouldn't keep the old line of thought if this new one replaces it.

> You are right, that would need to be changed. Switching from
> rdfs:range/rdfs:domain toschema:rangeIncludesis high
> on my to do list. Using RDFS has been a mistake. But that, again, is a
> different discussions.

Since it's mentioned here: I'm very strongly opposed to that,
as schema:*Includes barely has more meaning than rdfs:seeAlso.

>> Both ideas might be reconciled if views _are_ collections.
>> 
>> My open questions for your proposal are:
>> - precise definitions of collection and view
> 
> Did the answers I provided at the beginning of the mail help? I'd need some
> time and probably a couple of iterations to come up with 2-3 sentence definitions.

Not sufficiently yet. Please take your time, but
we really need a precise definition of collection and view.
Personally, I would define them such that views are also collections,
as I see a lot of similarities, and we could reuse things.


Please forgive me for skipping many questions/arguments;
I just think I help the list more by focusing on the new proposal.
I care more about having a solution to filtering soon
than having a solution I like, so I'll settle for this one
if my concerns about definitions and AND are solved.

Best,

Ruben

Received on Wednesday, 13 January 2016 22:23:37 UTC