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

Hi Tomasz,

> I'm not sure I understand correctly, but I'd point out that the filter doesn't necessarily have to directly correspond to you underlying data.

So it means that a client need to be guided by a human (who creates
business logic of a client) to select an appropriate filter. Though
probably this is how it show work.

> Also remember that you may store your data as RDF, which seems natural when using Hydra.

Yes, in my app I store data in Triplestore and generate JSON-LD
payload using JSON-LD Frames.

Maxim

On Wed, Feb 10, 2016 at 4:03 PM, Tomasz Pluskiewicz <tomasz@t-code.pl> wrote:
> Hi Maxim
>
> I'm not sure I understand correctly, but I'd point out that the filter doesn't necessarily have to directly correspond to you underlying data. In other words, even if you introduce an additional geo:location property/node, the filtering doesn't have to change.
>
> Thus you /sensors resource could advertise its filter (view) equally regardless of how you store your Sensors' data:
>
> GET /sensors
>
> {
> "@id": "/sensors",
> "member": [],
> "view: {
>     "@type": "ViewTemplate",
>     "template": "/sensors{?lat,lon,rad}",
>     "mapping": [
>       { "variable": "lat", "property": "geo:lat" },
>       { "variable": "lon", "property": "geo:long" },
>       { "variable": "rad", "property": "schema:geoRadius" }
>     ]
>   }
> }
>
> Also remember that you may store your data as RDF, which seems natural when using Hydra. But that is not a requirement. You could actually work with relational data on server side, translate filters to SQL WHERE clauses and convert SELECTed data into RDF. This is why REST talks about uniform interface and representations. Client should make no assumptions about data structures and storage used on the server side. Some data transformations may be required, which is a necessary trade-off.
>
> I hope I helped :)
>
> Best,
> Tom
>
> February 10 2016 1:16 PM, "Maxim Kolchin" <kolchinmax@gmail.com> wrote:
>> Hi all,
>>
>> I have a question about the way properties are (or will be) selected
>> for a filter, such as schema:givenName or schema:familyName from the
>> examples [0], [1].
>>
>> schema:givenName and schema:familyName are datatype properties (in
>> OWL's sense), therefore it's quite easy to use them for filters, but
>> what about more complex properties, how should they be represented in
>> such filters, and should they be used in filters at all?
>>
>> In example, the location of a sensor, in the simplest case I can have
>> geo:lat and geo:long attached directly to a sensor's resource, but
>> what if I have the following use case:
>>
>> <> a apidoc:Sensor ;
>> geo:location [
>> a geo:Point ;
>> geo:lat "..." ;
>> geo:long "..."
>> ] .
>>
>> and in the api documentation I define apidoc:Sensor resources as follows:
>>
>> apidoc:Sensor a hydra:Class ;
>> hydra:supportedProperty [
>> hydra:property geo:location
>> ] .
>>
>> I now I want to have a filter which should return apidoc:Sensor
>> instances if they fall in a circle defined by the coordinates of the
>> center and the length of its radius. As I understand such filter
>> should consist of 3 properties, e.g. schema:geoRadius, schema:latitude
>> and schema:longitude.
>>
>> Did you have a similar use case? Or maybe you have a better idea, how
>> to create such filter?
>>
>> And should a client know that he or she can filter the instances by
>> the given hydra:supportedProperty using a particular filter?
>>
>> P.S. I know that the filtering concept is still under discussion, but
>> maybe this use case at least could help to clarify how such cases
>> should be covered the filtering concept or maybe it shouldn't be
>> covered.
>>
>> [0]: https://www.w3.org/community/hydra/wiki/Filtering
>> [1]: https://www.w3.org/community/hydra/wiki/Collection_Interaction_Flow
>>
>> Thanks in advance!
>> Maxim
>>
>

Received on Wednesday, 10 February 2016 15:42:20 UTC