W3C home > Mailing lists > Public > public-hydra@w3.org > November 2015

Re: Moving forward with hydra:filter (ISSUE-45)

From: Maik Riechert <maik.riechert@arcor.de>
Date: Thu, 19 Nov 2015 09:27:36 +0000
To: Ruben Verborgh <ruben.verborgh@ugent.be>, Markus Lanthaler <markus.lanthaler@gmx.net>
Cc: Hydra <public-hydra@w3.org>
Message-ID: <564D9608.30201@arcor.de>

Am 19.11.2015 um 08:29 schrieb Ruben Verborgh:
>> An option to make this more flexible would be to explicitly describe that.
>> Maybe something along these lines:
>>    </collection> :filter [
>>      rdf:type :IriTemplate, :Filter ;
>>      :filterSpecification [
>>        rdf:type :AndFilter ;
>>        :input [ :variable "first" ] ;
>>        :input [ :variable "last" ] .
>>      ] ;
>>      :template "/collection{?first,last}" ;
>>      :mapping [ :variable "first"; :property schema:givenName ] ;
>>      :mapping [ :variable "last"; :property schema:familyName ] .
>>    ] .
> Looks good to me.
> We might not strictly need filterSpecification as a separate entity,
> i.e., we could also attach these properties to :Filter directly.
> However, in the case of nested filters,
> it might be nice to only have 1 "top" :Filter that is also an :IriTemplate,
> whereas :FilterSpecifications would then never be :IriTemplates.

I think a separate entity could actually be useful when you think 
further. In my case I'm creating an API which simulatenously offers 
filtering a collection and transforming/mapping the collection items. So 
I would not use :filter myself, but something more generic like:

   </collection> :api [
     rdf:type :IriTemplate, :Filter, :Transformer ;
     :filterSpecification [
       rdf:type :AndFilter ;
       :input [ :variable "creationDateStart" ] ;
       :input [ :variable "creationDateEnd" ] .
     ] ;
     :transformSpecification [
       rdf:type :SpatioTemporalSubsetTransform ;
       :input [ :variable "subsetBbox" ] .
     ] ;

     :template "/collection{?timeStart,timeEnd,subsetBoundingBox}" ;
     :mapping [ :variable "creationDateStart"; :property opensearchtime:start ] ;
     :mapping [ :variable "creationDateEnd"; :property opensearchtime:end ] ;
     :mapping [ :variable "subsetBbox"; :property geo:bbox ] .
   ] .

Imagine in the above fictional example that the collection items are 
GeoJSON layers (=a GeoJSON feature collection resource) and what you 
want are only those layers created within the given time range, and then 
you want to get a transformed version of each layer which is a cut out 
to the given bounding box (it would not be a simple filtering of geojson 
geometries, it would actually transform and split geometries at the 

Collapsing the two *Specification's into the root would become 
ambiguous, but maybe there's another way to model such thing as well. 
Any idea? Or is the above good as it is?

By the way, I'm still not sure how to model the properties correctly. In 
the example above, you could easily add a filter by bounding box as well 
("give me all GeoJSON layers that contain stuff in the given bounding 
box"), making it:

     :mapping [ :variable "bbox"; :property geo:bbox ] ;
     :mapping [ :variable "subsetBbox"; :property geo:bbox ] .

Now the client would see two variables with the geo:bbox property and 
would at first be confused. Is that what the above :*Specifications are 
for? To give further information about what the variables mean?

Received on Thursday, 19 November 2015 09:28:05 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 19 November 2015 09:28:05 UTC