Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How do we indicate the FoI being Observed by a Sensor? #253

Open
KathiSchleidt opened this issue Oct 9, 2024 · 11 comments
Open

How do we indicate the FoI being Observed by a Sensor? #253

KathiSchleidt opened this issue Oct 9, 2024 · 11 comments

Comments

@KathiSchleidt
Copy link
Contributor

How do we indicate the FoI being Observed by a Sensor?

If we use an FoI-specific Property (PropertyOfInterest), we can state that the Sensor observes this PropertyOfInterest, that is in turn linked to the FoI.

However, if we use a neutral ObservableProperty, there is no direct way to indicate this link. The current workaround seems to be creating a specialization of Observation for this purpose. If this is a common use case, we may want to add this to SOSA, align with the ObservingCapability class from OMS

@maximelefrancois86
Copy link
Contributor

What about using sosa:observes to also link the Sensor to the FoI ? that is: including FoI to the range of sosa:observes.
That's what we decided to do with https://saref.etsi.org/core/observes

@sgrellet
Copy link
Contributor

sgrellet commented Oct 9, 2024

How do we indicate the FoI being Observed by a Sensor?

Especially when no observation is created yet ... => that's why we created ObservingCapability in OMS (actually in INSPIRE:EF and moving it to OMS)

sosa:observes

the point raised by Kathi is that we see many Environmental Monitoring Use Case in Europe where you need to know more : the uFoI, the ObsProperty, the procedure etc... thus the ObservingCapability in OMS (https://docs.ogc.org/as/20-082r4/20-082r4.html#_observingcapability)

@dr-shorthair
Copy link
Collaborator

Easy: sosa:hasFeatureOfInterest points to the FoI.
There is no restriction that prevents its domain including sosa:Sensor (or any sosa:System for that matter).
We can add schema:domainIncludes sosa:System to SOSA to resolve this issue I think.

sosa:hasFeatureOfInterest can sit alongside the sosa:observes property (sub-property of sosa:forProperty) to fully say what a specific sensor instance is looking at.

@dr-shorthair
Copy link
Collaborator

dr-shorthair commented Oct 16, 2024

Telecon discussion suggests that adding hasFeatureOfInterest to a Sensor instance would risk problems. The same sensor is likely to be used on multiple FoI.

The link from a Sensor to a FoI is a deployment related issue.
https://w3c.github.io/sdw-sosa-ssn/ssn/#Systems-and-their-Deployment-overview

More helpful might be to add
(i) hasFeatureOfInterest to Deployment (or something similar)
(ii) add timing to Deployment - startTime/endTime

We need stronger examples/patterns of deployments to show how to do this.

@dr-shorthair
Copy link
Collaborator

dr-shorthair commented Nov 6, 2024

What about using sosa:observes to also link the Sensor to the FoI ?

sosa:observes has the wrong range. See https://w3c.github.io/sdw-sosa-ssn/ssn/#SOSAobserves

@alexrobin
Copy link
Collaborator

@dr-shorthair I totally agree that associating an FoI to a sensor is a deployment related issue. The association can also be created via an Observation, but it is often useful to also associate an FoI at the deployment level because very often some kind of FoI is known ahead of time (i.e. before any obs are produced).

This is especially true for static in-situ sensors, but it can also be used to identify a larger FoI for mobile or remote sensors. For example, the sample/proximate FoI for a photo taken by a drone may be the exact image footprint (this would be associated to the observation), but often a less specific FoI can also be associated to the deployment (e.g. a specific area, building or other object such as a bridge, etc. that is of interest for a particular mission/deployment. This would often be the sampled feature / ultimate feature of interest, but it can also be a sample itself, e.g. a specific portion of a river that the drone is deployed over).

So what you propose (adding hasFeatureOfInterest and time to Deployment) aligns very well with what we have done in Connected Systems

@dr-shorthair
Copy link
Collaborator

Like this:

Image

@dr-shorthair
Copy link
Collaborator

2024-11-13 Telecon generally likes this approach, which expands domain of hasFeatureOfInterest

Deployment does not have to involve a Platform

@ldesousa notes that a Deployment always involves a System, so perhaps the forProperty property should not be associated with Deployment

@KathiSchleidt
Copy link
Contributor Author

Opens interesting options:

  • I can indicate that a System pertains to a specific FoI, don't need to provide a Platform
  • Alternatively, I could also indicate that all Systems on a Platform are concerned with a specific FoI without ever providing the actual Systems

@dr-shorthair
Copy link
Collaborator

dr-shorthair commented Nov 16, 2024

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants