Re: Filters as views (ISSUE-45)

Also grouping multiple mails:

> Could you precisely define what is a "member"?

I'd simply say: a resource that is part of a collection.

> - a member of a collection is a resource linked to it by the hydra:member property

=> agree

> - a member of a collection is a resource whose representation is included in the collection's representation

=> not necessarily

> 1/ it contradicts your implication that views are collections (indeed, a page has no member according to this definitions, as the items are not linked to the page)

It's not because the link is not listed in a representation, that it does not exist.

> 2/ it contradicts the TPF specification, in which hydra:member i not used  (in fact, the word "member" is never used once in this spec ;-)

Idem.

(TPF has the complication that the items we filter on are triples;
 we filter on the "reified versions", but return the triples themselves.)




>> 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.
> 
> Interpret it as "this parameter acts as a filter, multiple filters are
> combined with AND".

The "AND" interpretation is not possible,
because the hydra:filter property is attached to individual mappings.
The AND-ness should be decided on the level of all mappings.
(in other words: you cannot AND a single mapping,
 you need at least two).

Plus, I'm still not in favor of this boolean.
Just "this acts as a filter" is not too interesting.

> I'm fine with those (modulo some minor wordsmithing to avoid that views are
> collections, Pierre-Antoine's tweaks fix that).

Curious to see the definition that describes
exactly what separates a view from a collection :-)
(That's what I'm after in this whole thread.)

>> I'm okay with following Markus' new proposal,
>> but I additionally suggest making view a subclass of collection
>> (unless somebody can make a definition that allows distinguishing either).
> 
> That would probably mean that we would need to change pagination again to
> have a uniform design (it would also mean that views only work for
> collections, but we can avoid that by just making PartialCollectionView a
> subclass of collection).

+1 to making PartialCollectionView a subclass of collection

(and while we're at it, the name is hideous;
 just View or CollectionView will do)

>  {
>    "@context": "http://www.w3.org/ns/hydra/context.jsonld",
>    "@id": "http://api.example.com/an-issue/comments",
>    "@type": "Collection",
>    "totalItems": "4980",
>    "member": [
>      ... a subset of the members of the Collection ...
>    ],
>    "view": {
>      "@id": "http://api.example.com/an-issue/comments?page=3",
>      "@type": "PartialCollectionView",
>      "first": "/an-issue/comments?page=1",
>      "previous": "/an-issue/comments?page=2",
>      "next": "/an-issue/comments?page=4",
>      "last": "/an-issue/comments?page=498"
>    }
>  }
> 
> So the members are associated to the collection, not the view. How would you
> envision that to work look like when PartialCollectionView is a subclass of
> Collection?

Exactly the same.

> Where would you put the first/previous/next/last links?

Same place.

> Where the totalItems count (of both the page and the entire collection)?

I'd put 4980 where it is; and 100 (assuming this as the page size) on the view.

Best,

Ruben

Received on Thursday, 14 January 2016 21:48:20 UTC