Re: Filters as views (ISSUE-45)

January 14 2016 10:49 PM, "Ruben Verborgh" <ruben.verborgh@ugent.be> wrote:

>> 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.)

Ruben,

please tell me why are we mostly confined to collections in this discussion? I've expressed before that in my opinion, we should be considering views and filters a tool suitable for deriving from any resource, not only collections. Markus and Karol seem to support this view, yet the emails inevitably drift in the other direction.

With the view facility I would like to be able to filter no only collection members but also simply instruct the client how to retrieve derived resources. Consider a fictional-life example, where there is a resource with many properties (think lengthy dbpedia page?). The server could advertise a view, which filters by those properties' labels. Let it be, by the starting letter. I would like to write sth like

{
"@id": /my/resource/id,
"view": {
@type: ViewTemplate, IriTemplate
template: /my/resource/id{?labelStartsWith}
mapping: {
variable: label
}
}

And so when I GET /my/resource/id?labelStartsWith=a the server will return this resource with only those properties which have labels matching /a.*/. 

Is that a sound example? Is that something the proposed syntax should be able to define? 

If so I think that a view has virtually no relation to an abstract collection at all. In my eyes a view should be defined as derived from any resource, collection or otherwise.

Regards,
Tom

Received on Friday, 15 January 2016 08:18:35 UTC