Re: [sdw] Should Platform be a subclass of System? (#1411)

@KathiSchleidt I think we don´t understand each other because we are thinking of things at different level of abstractions, or maybe because we think of it from different viewpoints. The good thing is that SOSA/SSN was designed to reconcile these two viewpoints in a way: the "observation centric viewpoint" and the "system viewpoint".

SOSA brings in the "observation centric viewpoint" and from that standpoint is very closely aligned with O&M and OMS. We definitely need to keep this consistency.

SSN brings in the "system viewpoint" which I'm also very interested in, so I don't want to break it, and would even like to improve it (many SSN concepts are more the domain of OGC SensorML by the way).

As Simon Cox pointed out, even if we decide to merge everything into a single namespace, we can still keep these two trees separate so that users can choose to use only SOSA or the full SOSA/SSN model.

Now, more specifically regarding my proposal of making `Platform` a `System`. I would like to point out that this inheritance only happens in the SSN tree. SOSA alone doesn't know anything about `System` so `Sensor`, `Actuator` and `Sampler` are not subclass of `System` if you only import SOSA. In my PR, it is the same for `Platform` and `Host` that stay "pure" in SOSA. This makes sense to me because SOSA is meant to be more abstract, just like OMS.

I think we should see `System` as a different "aspect" that is added to certain core classes in SOSA. This "aspect" doesn't change the fundamental definition of these classes but it brings in the ability to define characteristics and capabilities, and hierarchical systems (all of which I find very useful for my use cases). I don´t know why `Platform` was left out from the `System` hierarchy in the current version of SSN and I would be interested to hear from the ones who contributed to it.

What I know is that in the world of mobile platforms (e.g. ground vehicles, seaborne, airborne or space-borne, etc.), platforms are considered systems on their own. Sure, from a certain viewpoint, their main goal is to carry (or host) sensors and actuators (often called payloads) but they also have a characteristics and provide capabilities on their own (they typically provide, mobility, power and communications to the sensors they carry after all). So I don't think there is a very valid reason to not treat them as systems, just like sensors and actuators. People who need to deploy sensors on these platforms care about the system view of the whole platform and I don't think we can accept the restriction that a platform just "carries things".

You also said `I don't really see a clean merge option that doesn't just muddy the waters` between the definitions of `Platform` and `System`, which are, as you recalled:

* Platform - A Platform is an entity that hosts other entities, particularly Sensors, Actuators, Samplers, and other Platforms.

* System - System is a unit of abstraction for pieces of infrastructure that implement Procedures. A System may have components, its subsystems, which are other Systems.

I actually see a clear parallel/overlap between these two definitions. Did you notice that both `Platform` and `System` can have subsystems, recursively? In OMS, a `Host` is essentially a group of `Observers`. Well, that's also what a `System` with only sensor subsystems is in SSN. In fact, using SSN, you can already model a mobile platform using the `System` class so, in a way, what I'm trying to do here is just reconcile an overlap that already exists.



-- 
GitHub Notification of comment by alexrobin
Please view or discuss this issue at https://github.com/w3c/sdw/issues/1411#issuecomment-1553273138 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 18 May 2023 15:59:59 UTC