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

> I'm reading through your examples and I've come to appreciate the idea where filter mappings relate to properties though I still have some reservations :).

That's good, I think, because then we can switch to a discussion of a
representation for the use cases with the birthDate/age and
geocoordinates/geoshapes, since they can't be covered by "filter
mappings relate to properties".

> 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:
>
> {
>  "@id": "/article",
>  "view": {
>    "@type": "ViewTemplate",
>    "template": "/article{?maxLength}",
>    "mapping": [
>      {
>        "variable": "maxLength",
>        "??": "??"
>      }
>    ]
>  }
> }
>
> 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.

What sense do mapping and variable properties make then without other
properties? Without them we define only placeholders which are not
ambiguous enough for an autonomous client.

The property and comparator properties, I think, are needed to
communicate to the client the relatedness of the view (which
hydra:supportedProperties are involved) and expected result (how the
given value is applied to the value of the hydra:supportedProperties).

An example, the view which represents articles with some minimal
length (in characters or pages), how a autonomous client should
distinguish the maxLength view and minLength one?

>1. Under direct mapping you write "Such mapping type doesn't allow to use property which is not defined for the given instances." I guess you
> mean hydra:Class and not instance?

Yes, maybe this one will be more accurate "for the classes
(hydra:Class) which the members instantiate"?

> Also we currently don't specify the member type for collection members?

Yes, current there is no way to specify members of which classes are
in a given collection. Even if there won't a way to do that, the
members in the own representation will have statement of the class
which they instantiate.

> 2. I would not advise any particular default for the mapping type in general, should we go down that path. As I stated above, collection
>mapping is a specialized case of view. I also assume reuse of mappings for views and templated links. For the latter direct/indirect mappings
> do not apply, do they? That said I pretty much like the concept.

Ahh, I actually forgot about templated links :( Can a templated link
outside of a collection have a direct mapping?

> 3. Lastly I'm a little confused with the Indirect mapping examples. They seem needlessly complex.

Yes, an IndirectMapping has a embedded mapping property to support
grouping of variables, e.g like in the last snippet.

Now I understood this design doesn't suite well the
filterSpecification proposed in
https://www.w3.org/community/hydra/wiki/Collection_Interaction_Flow.

> In the last snippet I understand that you wrap the three parameters inside a single mapping?

Yes, because they're attached to a single comparator.

> And does age variable really map to the birthDate? Otherwise in what way is that information significant for the client?

The maxAge and minAge variables map to foaf:age property which is
somehow derived or related to the birthDate. It shows to the client a
connection to the birthDate property. May the last example is more
representative here.

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:10:45 UTC