Re: Filters as views (ISSUE-45)

>> - In general, we need definitions of:
>>   - collection
>>   - view
>>   - viewtemplate
>>   It's important to know what exactly we are talking about.
>>   In particular, we need to know whether a view is a collection,
>>   and from the reuse of properties, this seems to be the case here.
> 
> No, IMO a view wouldn't be a collection. I would define a collection as a
> set of resources that somehow belong together.

Fair enough.

> A view is a specific
> representation of a resource (in our discussion here of a collection).

…containing a set of resources that somehow belong together
(because they are together in one view).

I know it sounds like nitpicking, but it's really important
that we nail unambiguously what a view is,
and if it should not be a collection,
that this directly follows from that definition.

>> - Maybe the examples can be enhanced a bit with plaintext,
>>   to understand what exactly the intended semantics are.
> 
> Sure. Any suggestions on what to add?

The meaning of the new predicates introduced.
What does "view" etc. mean.
(Because see below: it both points to a subset of a collection
 and a control to achieve such a subset.)
>> - In GET /markus/friends, I don't understand view/ViewTemplate.
>>   What is this supposed to express?
>>   "The friends have a view that is a template that."?
>>   I see conceptually what is going on,
>>   but I have trouble linking this with the view predicate.
> 
> The resource /markus/friends has various views. Some of them might be
> referenced via a direct link, other via more complex, parameterizable
> hypermedia-controls.

I think we then conflate a view and a control to generate such a view;
we are conflating controls and the resources their instantiations point to.

>> - What is the domain of filterSpecification?
>>   Is it something like "Expression"?
> 
> Yes, perhaps a BooleanExpression.
> 
> 
>>   If so, does "operands" also take an expression?
>>   (I.e., can we compose recursively?)
> 
> Yes, I would suggest to allow that.

Note that the operands are not boolean expressions.
(In the example, they evaluate to variable values.)

>> - Will the operators receive IRIs?
>>   I.e., can I assume that "AND" is hydra:AND,
>>   or was it intended as the string "AND"?
> 
> I'm fine either way. If we make it a BooleanExpression, the value space will
> be closed and strings might be simpler in practice.

No no, they are two different things.

This is an expression (that evaluates to a boolean value):

{
        "operator": "AND",
        "operands": [ 
          { "variable": "first" }, 
          { "variable": "last" }
        ]
}

"AND" / hydra:AND would be an operator.


Note that the above is slightly underspecified:
the notion of "equality" is not expressed.

I.e., the above is meant to say
“this expression evaluates to TRUE for a given item iff either
1) both first and last are not specified
2) first is specified and equal to item.first
3) last is specified and equal to item.last
4) both 2 and 3”

>> - Is there a default semantics for viewtemplate? (AND?)
> 
> No. I don't think that buys us much in this design. 

I disagree.
Nobody will botter to specify filterSpecification all the time,
and if that's a requirement, I see ViewTemplate not being used altogether.

In absence of other indicators, the semantics should IMHO be
– AND
– exact equality (if parameter specified, always TRUE otherwise)

>> - With regard to naming, we still seem to have a "filter" concept.
>>   We could/should get rid of this by renaming "filterSpecification".
> 
> Where do you see the "filter" concept? Or do you mean the filter in
> *filter*Specification?

Yes.

> If that's the case, what would you renaming it to?

No strong opinion; just an opportunity to ged rid of a concept we don't use.
Could be "expression" or "matcher" or "condition".

>> - In GET /markus/friends?first=Ruben,
>>   I think the view flaw really becomes apparent.
>>   The thing seems to have two views. That's not right.
> 
> Why is that not right?

Conflation of "view" and "control to generate a view".

>> - GET /markus/friends?first=Ruben does not explicitly say
>>   that Ruben is part of the view.
>>   This might or might not be necessary.
>>   I would argue it is necessary for transparency:
>>   if the thing is attached to the view,
>>   clients can just read its elements,
>>   without having to care whether something is a collection or a view.
> 
> Not sure I follow... are you saying the response should say
> 
>   /markus/friends?first=Ruben hydra:member /ruben
> 
> instead?

Yes.

> I think that would defeat the purpose of the view concept.

Not really.
A view gives access to a specific part of a collection.

(Closely related to my question if it is at all possible
 to define a view such that it is not a collection.
 If this is not possible, views are subcollections.)

> The
> server doesn't return any new data, it just gives a client a different
> perspective on a resource.

There's no requirement for data to be new.

> I don't want views to be tied to certain classes like collections.

Try to define it as such then ;-)
I think it will be really hard _not_ to make a view a collection.

> he only way for a
> client to get the number of items on a specific page would be to count them.
> Is everyone fine with that?

I'm not. Let's just define a predicate for items per page, like we had before.
It's very common on pagination anywhere else on the Web.

Best,

Ruben

Received on Thursday, 11 February 2016 20:12:21 UTC