Re: Relationship between filter properties and hydra:supportedProperty (was Re: Filters as views (ISSUE-45))

> The comparator itself may be not very precise - I think Tom already throw few more examples, i.e. for strings it can be "equals", but it may also be "startsWith", "endsWith", "matches", etc. W may end up with quite a dictionary here.

I agree, it's not very precise, but I don't see an alternative right
now. Some limited number of comparators could be included in the core
spec which would represent 80% of use cases. The rest could be define
in a separate vocabulary for example.

> As for multiple mapping - we're entering a swampy turf here - how client is supposed to concatenate these multiple properties? While indeed it might be useful (as I'm also seeking for a way of telling the client how to build i.e. a display name from various properties), but this poses quite a challange on it's own.

The multiple mapping means that the mapping will be applied to each of
the properties independently and the results will be joined. A
resource is included in a result set if at least one of the properties
match the given variable's value.

Thank you!
Maxim

On Mon, Feb 15, 2016 at 12:01 AM, Karol Szczepański
<karol.szczepanski@gmail.com> wrote:
> Hi Tom, Maxim
>
> Regarding Maxim's ideas, I've got few mor concerns.
>
> The comparator itself may be not very precise - I think Tom already throw
> few more examples, i.e. for strings it can be "equals", but it may also be
> "startsWith", "endsWith", "matches", etc. W may end up with quite a
> dictionary here.
>
>> Generally I see that most people associate views with collections.
>> After all there are still templated links though views can also express a
>> hierarchy of resources.
>> Consider a resource, which is essentially a long text document (an article
>> etc).
>> Say I wanted to define a view, which generates an automated summary and
>> takes maximum length parameter:
>> ...
>> What sense do the other properties of mapping make?
>> Neither property nor comparator seems right in such context.
>> I feel like we are pushing the design of template mappings for views (and
>> by extension templated links) in a very specialized direction without fully
>> analyzing a bigger picture.
>
> I believe few more situations like this could be imagined. I.e. sorting
> doesn't require a comparator (but it needs a mapping though).
>
> As for multiple mapping - we're entering a swampy turf here - how client is
> supposed to concatenate these multiple properties? While indeed it might be
> useful (as I'm also seeking for a way of telling the client how to build
> i.e. a display name from various properties), but this poses quite a
> challange on it's own.
>
> Best
>
> Karol

Received on Monday, 15 February 2016 10:23:29 UTC