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

Hi Pierre-Antoine

I'll reply partially here and share more thoughts in reply to Ruben

Thanks,
Tom

February 15 2016 12:03 PM, "Pierre-Antoine Champin" <pierre-antoine.champin@liris.cnrs.fr> wrote:
> Hi all, I've been following this thread and did only find time to reply now, so here are a few
> thoughts;
> 
> 1/ about relating filters to properties: I disagree with Thomasz that it is tying the filter
> definition to the implementation. The JSON-LD *representation* of a resource states that this
> resource has some properties, regardless of how the state of that resource is internally
> represented (RDF, XML, JSON, SQL...). The properties related to filters are those abstract
> properties in the representation, not the internal ones.

Okay actually you are right. But we must remember that resources are representations nonetheless.

> 2/ in a similar line of thought, I am not sure there is a need to distinguish direct mappings and
> indirect mappings. Even if the representation of a person only exposes the schema:birthDate
> property, it is not semantically incorrect to assume that this person also has a foaf:age (even if
> implicit). If a client "understands" the notions of schema:birthDate and foaf:age, then it should
> also "understand" the relations between the two, and having a filter on the implicit property
> foaf:age should not be much different, for that client, than on the explicit property
> schema:birthDate.
> 
> The same goes for Thomasz's example of the article length; any article may be understood to have an
> implicit ns:length property, and constraining this property with a maxLength variable is the same
> as constraining items with a maxPrice variable.
> 

But AFAICT mapped properties are meant to be looked up in SupportedProperties of a hydra:Class. With you line of though I'm getting the impression of requiring out-of-band information: implicit properties or properties implicitly derived from other properties.

> 3/ we have been focusing on the object (value) of the properties (and how they should be compared
> to the variables in the templated link), but not on the subjects of those properties. I see
> distinct cases in the examples we have been working on:
> 3.1/ views on collections usually consider that *members* of the collections to be the subjects of
> the filtering properties;

That is usually true, but view's parameters don't necessarily have to be filters. hydra:page is exactly such example.
 
> 3.2/ Thomasz's views on non-collection resources consider the queries resource itself to be the
> subject;

This will not always be true.

> 3.3/ the language=en parameter is tricky, as it is not an RDF property of anything, but rather an
> attribute of the litterals contained in the requested view;
> 3.4/ the hydra:page parameter mentionned by Karol is also tricky, as it applies to the page
> resource (rather than to the requested resource or its members).
> 

Bottom line is template parameters don't always have to map to any part of the representation itself but be required by the server for other reason. Another example: an image, which can be compressed on demand:

{
  "@id": "/some/image",
  "@type": "schema:ImageObject",
  "schema:contentUrl": {
     "template": "/some/image/bytes/{compressRatio}"
  }
}

The compressRatio is arguably not a property of the resource itself but rather a parameter for the server defining how the representation is produced.

Received on Tuesday, 16 February 2016 09:19:31 UTC