Re: Filters as views (ISSUE-45)

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

Received on Thursday, 14 January 2016 20:20:36 UTC