Should Observer and Host classes be equivalent to or superclass of Sensor and Platform?

[alexrobin]

In PR w3c/sdw#1402, Observer and Host are super classes of their Sensor and Platform counterparts. They are also kept more abstract because they are not sub-classes of System.

Link to specific commit

Alternatively, we could have Observer sameAs Sensor, and Host sameAs Platform.

[KathiSchleidt]

related to #48, we need to decide if these are moved into SOSA, or remain in SSN

In addition, I think we should also discuss Deployment here, as tightly linked to Observer and Host.

Based on the definition of System as "a unit of abstraction for pieces of infrastructure that implement Procedures", I fail to see the rational for having Sensor as a sub-class of System but not the more abstract Observer (even a human Observer follows a Procedure)

Platform isn't a System anyway, only hosts Systems.

Deployment is in SSN, would need to be shifted to SOSA

[alexrobin]

@KathiSchleidt FYI, all of these classes (Observer, Host, Sensor, Platform) are already in the SOSA namespace. Deployment is the one that is not.

Please see my other comment regarding making Platform a System.

[KathiSchleidt]

@alexrobin thanks for confirming that only Deployment would need to be shifted to SOSA

Coming back to the question of the rational for having Sensor as a sub-class of System but not the more abstract Observer (even a human Observer follows a Procedure), could you please clarify?

[alexrobin]

@KathiSchleidt You are right. I go confused because the usedProcedure association between Observation and Procedure is defined in SOSA but the implements association between Sensor and Procedure actually comes from SSN (inherited from System). The interleaving of the two namespaces is definitely confusing...

So I see what you mean now... If Observer is not a subclass of System, it doesn't get the association to Procedure automatically. However, the way I defined it (see here), it still gets the implements property whether or not it inherits from System. Also note that the range of implements was not limited to System in the existing ontology.

So I guess things can still be made to work even if Observer is kept independent from System but it is definitely a point of discussion.

[KathiSchleidt]

@alexrobin Turning this discussion around, what is your rational for keeping Observer independent from System?

In addition, whatever we decide for Platform, the same should apply for Host

[dr-shorthair]

Remember:

1. set theory is not single-inheritance. Intersection allows you to get properties from two parent classes.
2. we deliberately kept most of the axiomatization (especially domain/range and restrictions) in the SSN graph, even where it involved SOSA entities. The goal was to have a simple core with just the names of the classes and main properties presented, and with very little axiomatization which just confuses non-ontologists (i.e. 99.9% of developers).

In #48 it is proposed to move all classes and properties into a single NS. That wouldn't undermine the idea of reserving the axiomatization into a separate graph, but might make it easier on developers. @kjano doesn't want to clutter the SOSA namespace, so suggests that the fringe classes and properties should still be modularized in a separate graph. So maybe that should be SSN (to avoid disruption), so it is the axiomatization that perhaps should be moved to a separate (third) graph?

[dr-shorthair]

In #29 it is proposed to reconcile the absence of a SOSA class with the name Observer by just adding documentation to indicate that Sensor is the SOSA implementation of the OMS class Observer.

In #56 it has been agreed that SOSA Platform implements OMS Host.

If both of these are resolved as proposed, then this issue goes away.

[alexrobin]

I'm fine with this decision although the intent of my initial PR was to bring OMS concepts into the ontology in order to formally map them to SOSA concepts.

Are there any plans to create a separate OMS tree that records semantics used in OMS, such as oms:Observer, oms:Host, etc. so these terms can also be referenced whenever needed (and the mapping to SOSA formally recorded rather than just a comment)?

[rob-metalinkage]

I think the discussion needs to be whether SOSA is a canonical implementation of OMS. To an extent this is about OMS conformance classes being satisfied and OMS SWG recognising and advertising this.

What are your drivers here.. is it because you need to demonstrate the connected systems work is an implementation of a model that uses OMS?

If so I think we need to fully commit to a shared intent here and use it to guide design and testing.

[dr-shorthair]

Are there any plans to create a separate OMS tree that records semantics used in OMS, such as oms:Observer, oms:Host, etc. so these terms can also be referenced whenever needed (and the mapping to SOSA formally recorded rather than just a comment)?

Is the need for a canonical URI to denote each OMS term? Could we use the OGC URI that denotes the corresponding requirement? @rob-metalinkage also addressed this question .

[alexrobin]

@rob-metalinkage We initially picked SOSA/SSN as our conceptual model for Connected Systems because it provided many of the pieces we needed, that is observations, actuations and system view, while O&M/OMS only provides the observation side of things. I have then been asked if we will implement OMS. I thought a good way to implement both SOSA/SSN and OMS cleanly is if they are formally mapped to one another, at least at the semantic level. That's why I started modifying the ontology in that sense. When we first suggested an update of SOSA/SSN, it sounded like everybody agreed to map SOSA and OMS concepts one way or another.

That said, I understand that we would want to keep the SOSA namespace/tree clean, so perhaps a better way to do it is via a mapping ontology? I'm not sure what's the best method but it surely seems valuable to formally record these mappings somewhere.

Mapping to the OMS modspec URIs could be one way to do it I suppose.

[rob-metalinkage]

The issue for me is how many identifiers for the same things. We potentially also have iso19156 generating identifiers.

IMHO we should explore declaring sosa as the canonical ontology expressing oms and link to the modspec uris.

This is complicated by w3c namespace and transition to an ongoing governance regime from the W3c scoped wg lifetimes. .

[rob-metalinkage]

Ps @alexrobin I believe your approach is the correct one but your use case highlights a need to better formalize interoperability contracts between different levels of abstraction and different encoding expressions. Making the ontology the normative conceptual reference seems the only realistic approach. The Building Block approach to link to JSON schemas and logical models expressed (for example) in SHACL has been hard work but we think we can provide a robust solution for modularity of design and inheritance of constraints.

It will all require testing and eventually a policy to achieve commonality and convenience of approach.

[sgrellet]

" We potentially also have iso19156 generating identifiers."

That's a discussion we had several times while working on OMS.
Unless I missed something, the 'identifiers' in the specs are those of the requirement classes (normative artefacts) not of the semantic concepts contained in it as the ISO standard is the document (not the model in it).

"canonical ontology expressing oms"

+1
Provided we have enough room to include evolutions.
Being realistic, we all know that the evolution cycle on SOSA and OGC spec sides may en up being faster than the ISO document.
Applying OMS in various systems and OGC Interoperability Experiments we already identified places where we should adjust the models.

[lvdbrink]

declaring sosa as the canonical ontology expressing oms
That was also my intent when contributing to the OMS SWG.

[rob-metalinkage]

This I think is an OMS decision required we should be able to reference.

[sgrellet]

"we should be able to reference."

want a pointer to the minutes of some OMS meeting ?
The topic was raised several times in OMS webcon. Each time Linda & I advocated for sosa to be the canonical ontology expressing oms
Just need to do some digging to find the relevant meeting(s)

[dr-shorthair]

Would this imply that the URIs in SOSA denote the OMS concepts?

Would this imply #57 is not an issue?

[sgrellet]

I guess that will be easier to discuss this in our next webconf to be sure all the implicit consequences are on the table

[rob-metalinkage]

I think it requires a joint telecon with OMS to register such a decision.. and/or provision of a citation and explanation foreword that can be embedded as annotations in sosa.ttl and exposed in documents