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

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.

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.

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;
3.2/ Thomasz's views on non-collection resources consider the queries
resource itself to be the subject;
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).

4/ I can't help but think there is already a language capturing the full
range of examples we have been giving, and that is SPARQL... So there could
be something like:

"template": "/laptops{?minPrice,maxPrice,color,lang,page}",
"sparqlMapping": """
  SELECT * {
  <> hydra:member [
    schema:price ?p ;
    schema:color ?c ;
    ?prop ?lit ;
  ]
  FILTER (?minPrice <= ?p && ?p <= ?maxPrice && CONTAINS(?c, ?color)
&& (!isLiteral(?lit) || LANG(?lit)=?lang))
}
LIMIT 10 OFFSET 10*(?page-1)
"""

I'm not at all saying that we should go down that path, especially because
it would be hugely complex for the client to parse an arbitrary SPARQL
query to understand the semantics of a filter. What I'm pointing out is
that this complexity is linked to the expressiveness of the filter. If we
want that kind of expressiveness, we have to face that complexity (and then
we'd rather reuse an existing language such as SPARQL rather than inventing
a new one). If we want a less complex language (which I think we do), then
we have to chose what part we leave aside...