Supplement the OMS Extension with missing terms

[dr-shorthair]

Some terms/concepts from OMS are still not present in the OMS Extension chapter - e.g. ObservingCapability.

Can the OMS team please take another look at https://w3c.github.io/sdw-sosa-ssn/ssn/#OMS to identify the gaps and propose solutions.

[dr-shorthair]

I've added a note here as a placeholder while this task is underway

• https://raw.githack.com/w3c/sdw-sosa-ssn/337-update-front-matter/ssn/index.html#OMS-req

i.e. in the branch for general editorial work ahead of releasing a FPWD.

[KathiSchleidt]

Here the diagrams from today's discussion. Issues we see:

• The relations in SOSA are all described in the active tense, "usedProcedure" in place of "observingProcedure"
  • Outcome from call 19.9.25: naming is not relevant, only definitions. If we update the definitions to a more passive voice (as done in OMS), it doesn't matter what names we have
• If we want to claim that SOSA is the semantic representation of OMS, we'd need to be able to reference the concepts we have in OMS (e.g. for use in JSON-LD). The way SOSA is currently set up, we don't have an equivalence for ObservingCapability
  • I'm concerned that the semantics of Observation have been badly degraded, as now can mean
    • an actual Observation that was performed (original semantics)
    • Systems Capabilities, while derived from actual lab Observations, are actually just statements of the system capabilities, nicely packed into an Observation, but different meaning
    • Observing Capability, the potential Observations that could be taken at a Platform. If we also use Observation for this, we add a third meaning
• In ex-situ Observations, where we have no control of the actual device being used, it seems strange for non semantic experts to have to create 2 empty nodes for this purpose

Basic Use Case from WQ IE:

Problems with the current approach:

Proposal from OMS:

[KathiSchleidt]

Looking at the planing examples, 44 and 45 look pretty good (whereby we don't have SamplingCapabilities in OMS, so nothing to align)

On example 46, we are missing the link to the Monitoring Facility (OMS:Host, SOSA:Platform), thus would have to add another empty node as placeholder for the deployment to the non-existent Sensor.

Further issue is not having anything we can use in JSON-LD to indicate ObservingCapabilities, can only claim it's an Observation, then try and explain elsewhere

[sgrellet]

we add a third meaning

and

can only claim it's an Observation, then try and explain elsewhere

isn't that one of the 2 cruxes of that issue ?

we seem to have 3 different UseCases for which we propose to point to Observation(Collection).
I know this could go to a hard VS soft typing issue but

• coming from the UML world I feel we are proposing to address those 3 different situations by proposing different UML:association roles (and proposing a slightly different semantic on the role name)

From today's webconf I get it that we should not propose different role names because the topology of the graph remains the same and these are the definitions that matters.

Building on this, what would be the best way to indicate to an algorithm that this graph is "an actual Observation that was performed" or "Systems Capabilities" or "Observing Capability" ?

=> Traversing the pointer (URI) to that Observation and look at the sosa-oms:observationType ?

Then will remain the question of the Platform could point to it (without creating a dummy sensor), the second crux.

[dr-shorthair]

The proposed solutions in Figures 44-46 were based on the BRGM hydro examples that you supplied.

I accept that the 'names' of the predicates appear to imply a retrospective view. This is because O&M (and thus the bulk of SSN) was developed originally to describe observations retrospectively. As we expand the scope to also include a prospective view, then we have some choices.

Firstly, please don't focus on the 'property name'. In RDF every 'term' is denoted by a URI, in which a 'name' like usedProcedure is just the tail end. In small t-box ontologies (i.e. ontologies that are like a 'schema') it is common to make this name mnemonic, but it might just as well have been an opaque string such as a UUID, which is common practice in large ontologies. The semantics are not defined by the name.

I suggest that we can understand the essential semantics of a property as implied by its domain and range. So if you want to describe a link from a planned Observation (or ObservationCollection) to an ObservingProcedure to be used, then we can use the property already present in the ontology that links an Observation (or ObservationCollection) to an ObservingProcedure. The textual definition and label of the property can be tweaked to allow for this.

The names of classes are actually much less important in RDF and JSON. Most of what you see in a data instance will be the properties from the ontology, and values of these applying in individuals. For that reason I am conservative about messing with properties when it is not necessary. Class names, if they appear at all in a dataset, are just the value of a property of part of the data-structure, having a special predicate rdf:type. But actually they are optional!

But my key contention is that if the classes and properties already in the ontology are competent to capture the use-case, then there is no need to add more. Only if there really is a gap or the solution is tortuous or otherwise not sufficiently expressive should we add new terms. The proposed solutions in Figures 44-46 were constructed to allow us to make this assessment. If you insist to have a separate class for ObservingCapability, then I suggest that it could be just a sub-class of ObservationCollection, since the goal is to capture the properties of a future set of observations.

You also object to the 'blank nodes' in the proposed solutions.

First, these do not need to be blank: they can have identity. More significantly, you don't like to see 'virtual' nodes in a graph representing things that don't exist, yet. My response to that is that these nodes represent things that definitely will exist in order to fulfil the use-case. For example, there will be a sensor for every observation, and the key thing we know about it is that it is required to implement the specified procedure. In order to say this, then we include a node to represent the undefined sensor. We don't ever need to record anything more about it than the fact that it implements the mandated procedure.

I think you don't like that the solution involves a SampleCollection as well as an ObservationCollection. But this is because the use case involves sampling as well as sensing. Even if you don't routinely recognise or identify the samples in the reported data, samples are an essential element in ex-situ observation. The overall procedure in your ex-situ use case necessarily involves sampling followed by sensing, and it is the sampling step which is tied to the platform. My proposal might look indirect, but I think that it is actually just explicit. I'm a little surprised, given the additional focus on Samples and their preparation that you all put into the O&M → OMS update that you are not embracing the role of Samples in this use case.

[oldskeptic]

Building on this, what would be the best way to indicate to an algorithm that this graph is "an actual Observation that was performed" or "Systems Capabilities" or "Observing Capability" ?

I am concerned that you are over-reliant on the UML part of OMS and trying to match one-to-one with an RDF/OWL ontology which works differently with respect to identifiers. There isn't always a single term to do one thing and here an algorithm needs to query a portion of the graph to get to "the thing".

You can't read too much in term names. Some definitions need sprucing up but at the end of the day, The thing and the name of the thing are two different things.

[dr-shorthair]

Building on this, what would be the best way to indicate to an algorithm that this graph is "an actual Observation that was performed" or "Systems Capabilities" or "Observing Capability" ?

An Observation (or ObservationCollection) without a result or resultTIme, or with a resultTime in the future, is a plan, e.g. a Capability.

An Observation (or ObservationCollection) with a result is a past Observation. If it is linked to a System through hasSystemCapability or hasOperatingConditions then it is part of the characterization of a capability.

The logic is all there. Your query must use it.

[dr-shorthair]

@KathiSchleidt wrote:

The way SOSA is currently set up, we don't have an equivalence for ObservingCapability

In several places in the other alignments, the mapping to external classes is not 1:1.

If you think a 1:1 correspondence is needed for OMS-SSN to be 'the' canonical RDF implementation of OMS, then this issue is the invitation: please build the missing pieces and make a PR.

semantics of Observation have been badly degraded, as now can mean
...
Systems Capabilities, while derived from actual lab Observations, are actually just statements of the system capabilities, nicely packed into an Observation, but different meaning

How does that degrade the semantics of Observation? The values of properties that are System Capabilities were measured, often by the provider. The (re-)use of Observations in the context of a System Capabilities description was an insight, not a corruption. (I was not involved in this design decision so no pride at stake here.)

potential Observations that could be taken at a Platform. If we also use Observation for this, we add a third meaning

I don't see this as a third meaning. It is an Observation or ObservationCollection with a date in the future, but with other properties fixed in advance (usedProcedure, hasFeatureOfInterest), which is normal in a planning scenario. There is no hasResult present, but in an RDF/OWL context that is quite normal - the absence just says 'we don't have a result yet, or it is not available in this graph'.

In ex-situ Observations, where we have no control of the actual device being used, it seems strange for non semantic experts to have to create 2 empty nodes for this purpose

There are no empty nodes - all nodes shown in the diagrams are connected into the graph, so they are connected by at least one object-property. Blank nodes in RDF are not empty. They just don't have a URI. As mentioned in my comment above, the scenarios in https://www.w3.org/TR/vocab-ssn-2023/#ModelPlan could easily be re-written giving the blank nodes IDs.

The blank node for the Sensor in Figure 46 is optional - https://www.w3.org/TR/vocab-ssn-2023/#Fig-PlannedObservationCollection

The scenario in Figure 44 has no blank nodes - https://www.w3.org/TR/vocab-ssn-2023/#Fig-PlannedDeployment because I chose to give the (unknown) Sampler an ID in this case.

In the scenario in Figure 45 the blank node links the planned SampleCollection to the Platform on which the Sampler is deployed - https://www.w3.org/TR/vocab-ssn-2023/#Fig-PlannedSampleCollection .
SSN has no way to tie a SampleCollection directly to a Platform except through a Sampler.
This does of course point to the competencies of the SSN model, and the extent to which they satisfy the requirements of OMS.

My goal in developing the scenarios in https://www.w3.org/TR/vocab-ssn-2023/#ModelPlan was to find if there is a way to satisfy the OMS requirements without any extensions.
I believe the graphs in Figures 44-46 accomplish this, and also perhaps expose an assumption that was not explicit in the OMS story as presented (the existence and role of samples in the workflow).
But if this is unsatisfactory to the OMS team, then this GitHub issue is an invitation to build the missing pieces and make a PR.

[sgrellet]

I had worked on polishing the following content over the week-end to try & clarify the lanscape. Just when pushing seeing your extra comment Simon right above. Let's hope I'll cover some of your extra elements (note: from a quick reading, it seems to contribute to several )

0°/ domain content starting place
Figure 44, 45, 46 are really good starting place for discussion, trying to formalize what I initially described here
opengeospatial/WaterQualityIE#53 (comment)

I think you don't like that the solution involves a SampleCollection as well as an ObservationCollection.

'au contraire' involving those are right on spot considering those is in my Water Quality IE issue

1°/ Context starting place
two comments from @oldskeptic and @dr-shorthair make me wonder the following

an algorithm needs to query a portion of the graph to get to "the thing".
Your query must use it.
Am I right assuming those two sentences imply you are running a SPARQL query (Re 'algorithm', 'query') on a system already containing everything ?

On our side with @KathiSchleidt, we are also trying to approach the use cases from a LinkedData perspective, so no TripleStore on which one runs SPARQL queries.

These different starting places could explain different understandings of each other statements

From OGC ELFIE/SELFIE Interoperability Experiments I thought we concluded that to achieve LinkedData using a JSON-LD payload we would need in it

• the URI, type, name/label of the thing we point to before derefencing the URI
• and after dereferencing, receive content both machine & human readable

2°/

The textual definition and label of the property can be tweaked to allow for this.

As said above, our issue is not about the naming but about the definition, the figures were just an illustration of that => So ok, can we adjust those definitions?

3°/ indeed observingCapability is a planned obsCollection and potentially SampleCollection

If you insist to have a separate class for ObservingCapability, then I suggest that it could be just a sub-class of ObservationCollection, since the goal is to capture the properties of a future set of observations.

That would be helpful indeed, thanks.
We feel that would avoid the user/client make (potentially wrong) assumptions when facing the absence of information in cases like those you mentionned and in an OWA context. Counting on missing information (observation result) as an indicator of the "potential" nature of the observation, seems sensitive considering the open world assumption of the semantic web ("missing a statement" is not an information)

For example, re, the sentence "An Observation (or ObservationCollection) without a result or resultTIme, or with a resultTime in the future"; 'with a resultTime in the future' it could also be a water level forecast generated by an hydromodelling process, so not a plan.

4°/ hasObservingCapability
we already have hasSystemCapability, hasOperatingConditions and hasValidityContext to reuse the Observation/ObservationCollection construct in another context => to express the capability of a system

we feel adding hasObservingCapability pointing to ObservingCapability (a sub-class of ObservingCapability as per 2°/) would be very useful if its domain include implicitly or explicitly sosa:Platform.
especially if we don't have the full knowledge about the whole chain of sampling/observation, thus avoid wrong assumptions (e.g. use case of reporting obligation for monitoring facilities/platforms).

5°/ Platform is still missing

Considering the above, still, a last step would remain to fulfil the UseCase we need to handle

=> We need to be able to express the observing capability of a Platform without having/knowing the detailed Observation execution
Ex : EU wants to know what stations are deployed in every EU country to monitor nitrates concentration in WaterBodies. EU is not asking for the detailed obs, nor for the detailed sensor used

from figure 46, it's clear we want to go the Observation > madebySensor > Sensor > isHostedBy > Platform route.

However, we'll never have access to the specific sensor used for 2 reasons

• that level of details is not asked in the UseCase we bring
• and Labs to which we send Samples never provide this back (standard minimum will be usedProcedure). Indeed, in the world a sensor exists and is instanciated. However, from a modelling point of view we need to draw a line between what is realistically implementable VS chasing the beauty of the conceptual act (kind of when we decide what abstraction level to be used in an ontology, to involve DOLCE or no etc...)