Add relation between FeatureofInterest and ObservedProperty

[lieberjosh]

Presently there is no direct way to get a list of ObservedProperties for a given FeatureofInterest. It is necessary to fetch all Observations for that FoI, then all the Datastreams for those Observations, and then all of the ObservedProperties for those Datastreams. In SOSA there is not a direct connection, but only because the superclass of ObservedProperty, SSN:Property, is not in the SOSA ontology itself (at present). SOSA:ObservedProperty inherits the direct connection in the SSN context. I propose that these hasProperty / isPropertyOf links be added to SensorThings to provide a FoI-centric as well as Observation-centric mode of service interaction.

[hylkevds]

You can get the ObservedProperties for a FeatureOfInterest by doing the query: v1.0/ObservedProperties?$filter=Datastreams/Observations/FeatureOfInterest/id eq <foi id>

[lieberjosh]

I don't see how that would work, as there is no FeatureOfInterest/id in the request path to filter on. Something as in Example 24 of the STA spec might work: http://example.org/v1.0/ObservedProperty?$expand= Datastreams/Observations/FeatureOfInterest&$filter=Datastreams/Observations/FeatureOfInterest/id eq ‘FOI_1’ The response, however, would then include not only the Observed Properties, but also nest all of the Datastreams and Observations for that FeatureOfInterest, a potentially overwhelming answer to a simple question.

[hylkevds]

It works just fine: https://heracles-kb.server.de/SensorThingsService/v1.0/ObservedProperties?$filter=Datastreams/Observations/FeatureOfInterest/id%20eq%201

You don't need to expand linked properties to filter on them. See Example Request 2 from 9.3.3.5 $filter:

In addition, clients can choose to use the properties of linked entities in the $filter predicate. The following are examples of the possible uses of the $filter in the data model of the SensorThings service.

Example Request 2: http://example.org/v1.0/Observations?$filter=Datastream/id eq 1 returns all Observations whose Datastream’s id is 1.

You should see it as a Database select statement on the request path entity table, with the filtered path being added as joins. In SQL you can filter on joined columns even if they are not in the select list. The columns needed for the filter, and the columns that are actually returned can be different.

[lieberjosh]

Thanks. It isn't clear from the examples that a filter resource path conformant with the spec can extend that far beyond the immediate links of the request resource path. Perhaps such an example or a qualification should be added. Also, this syntax isn't just SQL "Select .." but Select * from ... where ..." and anything in the "where" clause does need to be included in the "from" clause for valid SQL. It seems that STA is implicitly adding any elements of the $filter resource path in this way.

In any case, it would still be useful to harmonize somewhat the relations in STA with those in O&M +/- SOSA/SSN for consistency with the SWE framework.