Re: Filters as views (ISSUE-45)

Sorry if I added confusion to the debate;
I must admit that I joined the group quite recently and have not followed
all the discussions.

Ruben, indeed, I didn't realize that you were abandonning your original
position, and chose to follow Markus' "views everywhere" path. Keeping that
in mind, I read again your definition:

– A collection is a set of members that somehow logically belong together.
– A view is a subset of those members of a collection that satisfy a
particular condition.
(...)

Could you precisely define what is a "member"?
Because I can see two ways of defining them, which I think are exclusive...

- a member of a collection is a resource linked to it by the hydra:member
property
- a member of a collection is a resource whose representation is included
in the collection's representation

The first definition seems very clear to me, but I suspect you won't agree
with it, as
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)
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 ;-)

The second definition is too sloppy. In this definition, how would you
*not* infer that the first page, mentionned in the representation of the
collection, is not one of its member (or, conversely, that the collection
is not a member of the page)??

Would you have a better definition of "member" to propose?


On Thu, Jan 14, 2016 at 9:20 PM, Karol Szczepański <
karol.szczepanski@gmail.com> wrote:

> HI Guys
>
> Just to shed some more light so we don't forget anything:
>
> >– A view is a subset of those members of a collection that satisfy a
> >particular condition.
> >would actually logically follow that a view _is_ a collection,
> >because a view satisfies the definition of a collection
> >(a view is a set of members, and the condition makes them logically belong
> >together).
> >So this is why we might as well directly define a view as such.
>
> While mostly we're talking about collections being sets of members where a
> member is 'just' an identifier, I believe there is still case (several
> times
> raised on this forum) of a SPARQL/SQL equivalent of SELECT clause. It would
> be possible to have a view that actually doesn't filter members, but their
> properties. I don't know if it has anything to do with the collection
> itself
> as I'm not fully sure if I understand correctly term "member" here.
>
> >So please challenge my original definitions:
> >can/should we define views in such a way that they are _not_ collections,
> >or is it more natural/easier to define them as such?
>
> Consider this:
> </collection> - root collection being a standalone, pure and detached from
> any other 'parent' collections
> </collection?name=n> - view/filter on a root collection above where members
> has their name starting with the letter 'n'
> </collection?name=n&surname=m> - what is it? is it a view/filter of the
> </collection?name=n> or another view/filter of the </collection>? If the
> former, view should be a collection in order to do this.
>
> > * Markus would like to have only basic collections (no notion of parent),
> > and unify all searches, filters and pages as views.
> > * Ruben would like to keep searches/filters as full-fledge collections
> > (while explicitly relating them to their parent collection), and keep the
> > notion of view for paging only -- thus renaming them "pages" instead of
> > "views".
>
> I'm somehow confused - we've dropped notions of a 'viewOf' and other
> 'parent
> collection pointers' as it caused troubles of members not being belonging
> to
> a single collection but to multiple overlapping/derivative collections. As
> I
> personally tend to the latter. but I fully understand Markuse's concerns in
> this matter.
>
> Regards
>
> Karol
>
>