Re: Filters as views (ISSUE-45)

Hi,

Am 07.02.2016 um 17:51 schrieb Markus Lanthaler:
> Hi,
> 
> I think there might have been some confusion and misunderstanding regarding
> the proposal I sent out a while ago. I slightly refined it and wrote down an
> exemplary interaction flow at
> 
>    https://www.w3.org/community/hydra/wiki/Collection_Interaction_Flow
> 

Is this going to be a full-blown query language with OR, parentheses,
grouping, functions, FROM equivalent etc.? If not, where do you draw the
line?

I still feel it would be better not to add a general-purpose URL syntax
description language to Hydra, but rather have a way to say that the
client may formulate requests following a well-known, publicly specified
query syntax:

{
"@type": "ViewTemplate",
"template": "/markus/friends{?first,last}",
"mapping": [
{ "variable": "first", "property": "schema:givenName" },
{ "variable": "last", "property": "schema:familyName" }
],
"urlSyntax": ... one of TPF, opensearch, odata ...
}

Clients may be programmed to support a certain URL syntax and merely
detect its availability. That way, we do not have to explain the URL
syntax to the machine on a case-by-case basis, and the URL syntax may be
arbitrarily complex.
TPF could in prose describe the kind of query a TPF client should support.

We could concentrate on the view aspect here and "factor out" the
intricacies of query languages, allowing us to close ISSUE-45 soon. I
fear that we get lost in the details of query languages here.

We would also have the advantage that we cannot forget certain important
aspects in hydra:

> Am 11.02.2016 um 22:12 schrieb Markus Lanthaler:

> > On 11 Feb 2016 at 10:07, Maxim Kolchin wrote:

> > I can't use geo:lat and geo:long as filter properties, because I'll
> > have to provide exact values, e.g. 60.000001 and 50.000001, a filter
> > with these values won't return a sensor at 60.000000 and 50.000000,

> That's a very good point actually. We kind of instinctively assumed
> equality checks. I guess we need to make this a bit more flexible to
> allow other comparisons as well.


One more thing. Some prior statements also seem to imply that a URI
template is (mainly) a query.

I'd like to remind us that a URI Template is not a query at all. It is a
way to describe a URI space. Even if we come up with a full-blown query
language, we still aren't able to describe all aspects of a URI
template. It not only has query variables {?query}, but also matrix
variables {;key1,key2}, path variables {/productcategory} and more.

Best regards,
Dietrich

Received on Monday, 15 February 2016 08:55:52 UTC