Should Platform be a subclass of System?

[alexrobin]

I made the Platform class a subclass of System in PR w3c/sdw#1402 because I think it makes sense to provide characteristics and capabilities of platforms (especially mobile ones), just like SSN does for Sensor and Actuator.

The Platform class is already pretty much aligned with System anyway since it can carry any System and even other Platforms (i.e. full composite pattern).

Link to change in RDF

[KathiSchleidt]

This seems contradictory to the Systems definition on implementing a Procedure. While a Platform groups such Systems, this would be like saying an ObservationCollection isA Observation

[alexrobin]

I think viewing Platform as just a group of Systems is very limiting. It may be suited for simple fixed platforms but is not sufficient for describing mobile platforms. Making Platform a fully fledged System is a simple change that could enable this.

Our experience in many domains shows that we usually need to describe platforms as more than just a collection of Systems. In particular, Platforms also have characteristics and capabilities (just like SSN Systems), and at least some of them implement complex Procedures on their own (e.g. a drone platform, or a person acting as a platform, implements a mission plan to go collect observations at different locations).

Again, this can all be resolved by making Platform a particular type of System, just like Sensor and Actuator. I don't see the proposal as contradictory to the System definition. IMO saying that a Platform can implement a Procedure is a valid statement.

Do you see any drawback in doing this?

[KathiSchleidt]

I'd like to see concrete examples before we make such a modification. Looking at the ones you provided

• a drone platform ... at least some of them implement complex Procedures on their own: Looks like you're subtly hiding some on-board Sensorson your drone platforms, shouldn't these be explicitly exposed?

• a person acting as a platform, implements a mission plan to go collect observations at different locations In the case of human Observers, to our experience, there's usually some sort of organized activity, e.g., survey campaign, that can serve as a Host. With your approach, the human is both Observer and Platform of the Observer?

[sgrellet]

+1 on @KathiSchleidt I may just be me but I feel this would be basically be a major change in Platform definition. A Platform is by definition created to host subtypes of System which have a different semantic purpose

[alexrobin]

@KathiSchleidt

• Regarding drone platforms: No we don't hide on-board sensors. Sensors are sub-components of the platform system in any case. But Platforms (not only drone platforms by the way) also have datasheets (or more generally, characteristics, capabilities, etc.) on their own. As per our discussions, datasheets are modeled using the Procedure class in the case of Sensors, hence the idea that Platforms can also implement Procedures. Datasheets are just one example of procedures, but I can also see more abstract procedures like types of missions, etc. being applicable to platforms.

• Regarding persons acting as platforms: IMO Persons can act as observers or as platforms and we model both differently. If the person is holding a phone to take pictures, the person is the Platform and the phone the Sensor/Observer. If the person is making observations directly (e.g. writing what bird he/she observed in a certain area), then the person is really the Observer. Wouldn't a survey campaign be better modeled as a Deployment?

That said, I understand that the desire in OMS may be that a Host is purely "carrying" Observers. That's why I also suggested to keep Host more general and make Platform a specific kind of Host. In the current proposal, this leads to Platform being both a Host and a System.

Does it make sense?

[alexrobin]

@sgrellet IMO this is not really a major change in Platform semantic definition. The main objective of a Platform would still be to host other Systems, but it would also be able to implement Procedures.

We would probably have to adapt the definition of Procedure slightly, but the introduction of concrete procedure subclasses and the addition of PreparationProcedure from OMS means that we would have to revisit the SOSA definition anyway.

By the way Platform can already host other Platforms so the composite pattern already exists, just like System.

[KathiSchleidt]

@alexrobin IMO, if a drone (or other platform) has integrated sensors, at a semantic level, this should be disaggregated, with the integrated sensors exposed. Especially as you keep mentioning sensorS as plural, at the platform level you'd then have to lump these. If you need such an integrated concept within your applications, I believe you should derive this there.

On human observers, in the case where the observation is being made by a device held by the human, then the human could be the platform, the device the Sensor or Observer (no need to make the human a platform with integrated device). On your suggestion of modelling a survey campaign as a Deployment, this seems to break both the SOSA and OMS definitions of deployment.

It could make sense to allow for Platforms to nest additional Platforms. Strange is that this link is not in the diagram for Platform, maybe this should be fixed.

I'm still missing the concrete examples on why this modification is of general use.

[KathiSchleidt]

@alexrobin on merging the System requirements into Platform as not really a major change in Platform semantic definition, looking at the current definitions:

• 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 don't really see a clean merge option that doesn't just muddy the waters

[alexrobin]

@KathiSchleidt I am not saying platforms and sensors should be aggregated in a single entity. Sensors have their datasheets and platforms have their own separate datasheets. They are two different things. If I want to describe the range or the battery life of my drone platform, it belongs to the platform datasheet, not with any of its subcomponents or payloads. So yes, platforms have their own procedures. The current model just doesn't have a place to provide it.

Both the definition of Platform and System still hold true with my proposed change. It's just that, in addition, the Platform is also a System. I don´t see why it's incompatible with the current definitions. Note, in particular, that the definition of System doesn't say it has to be a Sensor or Actuator. It's a generic concept for anything that implements a procedure and I'm arguing platforms also implement procedures.

[alexrobin]

@KathiSchleidt By the way, battery lifetime is a system characteristics that is defined by SSN http://www.w3.org/ns/ssn/systems/BatteryLifetime so I'm not making things up.

Why would battery lifetime not apply to an electrically powered platform?

[alexrobin]

@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.

[rob-metalinkage]

This may be naive.. but can a platform be a system of actuators that implements procedures such as changing position of sensors?

[KathiSchleidt]

Definitely! But I'd still see the Actuators as Systems hosted by the Platform (just like the Sensor), if nothing else so one can differentiate between these various onboard capabilities. Just because information is provided on one datasheet doesn't imply that this should all be part of the same semantic class.

[alexrobin]

@rob-metalinkage you said can a platform be a system of actuators? (and sensors). Yes, that's how most people look at it and that's exactly what I'm advocating for. But in the current version, a Platform is NOT a System unfortunately. I'm not sure what's the rational behind that. It seems like a very artificial distinction to me from the SSN viewpoint (especially since SSN already allows for hierarchical systems, for which platforms with payloads are typical use cases).

@KathiSchleidt Again, I don't necessarily want to put things in the Platform class that are Sensor or Actuator characteristics, but there are also (many) things that are related to the platform itself.

Let's think again of the "battery capacity" example. For 99% of the moving platforms, it is the platform that provides power to all on-board sensors and actuators. In what sensor or actuator would you put this information? IMO the battery characteristics cannot be described by any of these sub-components because most likely they don't even have their own battery, so it has to be described at the platform level.

More generally, mobile platforms have a bunch of characteristics on their own that are already defined by SSN:

• http://www.w3.org/ns/ssn/systems/OperatingRange
• http://www.w3.org/ns/ssn/systems/OperatingProperty
• http://www.w3.org/ns/ssn/systems/SurvivalRange
• http://www.w3.org/ns/ssn/systems/SurvivalProperty

You can of course describe these for the sensors and actuators that the platform carries, but the platform (w/o payload) typically has these too. I find it too bad, that with the current model, we cannot explicitly use these properties on the Platform class.

[KathiSchleidt]

@alexrobin I'm starting to wonder if what you need isn't more a new Battery subtype of System, that can also be deployed to a Platform.

[alexrobin]

@KathiSchleidt The battery is just an example I used to illustrate the problem. Sure you could do that for the power subsystem, the comm subsystem, etc. I'm definitely interested in adding new subsystem types to the SSN ontology. It's fine to allow this if one wishes to do so but I'm not sure forcing everybody to brake things out at that level of granularity (just so you can provide simple properties like battery capacity) is going to help adoption. Plus, if we did that, would you also need to create a separate battery subsystem if one wants to describe the battery inside a sensor?

Even then, there are still properties that only apply to the platform as a whole. Among the other examples I provided, the operating range of a platform (e.g. think maximum temperature and wind speed that a drone can operate with) is not necessarily the intersection of the operating range of its subsystems. If I really wanted to do it this way, I would also have to create a subsystem for the airframe of the drone, for example, because it also contributes to the capabilities of the overall platform. At some point, this is madness, IMHO it just makes much more sense to treat the platform as a system itself (i.e. the airframe IS the platform, it's not "hosted" by the platform!).

I still don't really understand the push back. What is the fundamental problem with the platform also being a system? (again this is only in SSN, not in pure SOSA).

[rob-metalinkage]

Here's a thought.. a distributed array of sensors in a drone swarm used as a single antenna with a long baseline.. we have platforms as a subcomponent of a virtual sensor? Does this force a resolution? Perhaps a test case with a swarm of two we is worth developing.

[alexrobin]

@rob-metalinkage Yes, good use case. Platforms are also part of larger observing systems sometimes. It would also justify making them fit better in the system hierarchy.

[KathiSchleidt]

@alexrobin I still get the feeling that you're mixing conceptual models (e.g. SOSA, OMS Conceptual) with implementation models. I'd like to keep SOSA on the conceptual edge, clear meanings for Sensor and Platform.

If an implementation model has a reason to mix Sensor and Platform, there's nothing hindering this, define your specialized Drone type as subclass of both Sensor and Platform (and thus, System).

In addition, from what I've been reading, the Drone ends up having multiple System bits attached, whereby these bits can be of quite different nature (battery, drive, antenna....). Do you also lump al your Sensors into one general Sensor?

[alexrobin]

@KathiSchleidt That's what I have been trying to explain. SOSA is a conceptual model so, in SOSA, Platform and Sensor are clearly separate. Like I said before, I agree to keep it like this.

However, SOSA doesn't have the System class at all. SSN does, and SSN is closer to an implementation model as it defines more specific properties of systems. I feel that in SSN it makes sense that Platform is also a System. SSN currently lives in a separate ontology tree (and I heard others agree that we should keep it like that) so it's possible to make this change w/o impacting users that are only interested in pure SOSA.

[alexrobin]

@KathiSchleidt And again, even in SSN, nobody is talking about mixing Platform and Sensor. Making them both inherit from System doesn't "mix things".

Take Sensor, Actuator and Sampler. They are all separate concepts in SOSA, and yet they all inherit from System in SSN.

So, all I'm doing is reusing the same pattern for Platform, that I think deserves to be treated as a System as well.

[KathiSchleidt]

@alexrobin could it be that your issue is actually the restriction on Platform, that these can only apply hosts towards Systems, not other Platforms. That should definitely be softened to allow Platforms to host other Platforms

My issue with making all Platforms into Systems is that most Platforms are not Systems based on the core definition of pieces of infrastructure that implement [Procedures](https://www.w3.org/TR/vocab-ssn/#SOSAProcedure). Redefining Platform based only on one subtype of Platform only creates confusion. If you need Drone in your implementation, create Drone there as such an amalgam.

On your statements that SSN and SOSA are totally separate, I've seen contradictory statements, quite a few voices for merging.

[alexrobin]

@KathiSchleidt Actually, in SOSA, Platforms can already host other Platforms so that's not the issue.

If this is really a blocking point for you and others, I'm happy to drop this as long as we agree that, conceptually, certain kind of Platforms can also be Systems. That's essentially what we do in Connected Systems at the moment so that's good enough for me (what we do is create a System resource that is further tagged as a sosa:Platform).

Regarding the separation of SOSA and SSN, I think what was proposed is to merge the namespaces but I heard Simon (@dr-shorthair) advocate for keeping them in separate trees (i.e. separate files), so that users can still import SOSA alone, without the additional SSN classes and restrictions,

[rob-metalinkage]

I thought the plan was to make SOSA standalone for the concepts - and declare equivalences to SSN - so we'd copy the few missing classes from SSN into SOSA, declare equivalence and leave detailed axioms for the SSN context.

From the perspective of implementations, if we have the same logical models then re-using schemas is preferable - and a common subClass heritage means we dont need to document out-of-band implementation conventions and choices.

Again - I think working an example or two to see if works OK or to prove we need to keep separate will help.

[sgrellet]

I agree with @rob-metalinkage.

We need :

• to have couple examples to reach common understanding on this specific one
• do a clean semantic comparison between bothin the current version of SOSA/SSN : definition of those 2 classes but also also of their object properties (for example do we feel that SystemCapability, OperatingRange, ... do apply semantically to all potential instances of a Platform ?)

And work this out in a webconf. I've been willing to contribute to this issue in between meetings. But too many pings & pongs, thus I need to revisit my draft answers each time before pasting :(

[KathiSchleidt]

@sgrellet @rob-metalinkage shouldn't we discuss merging or splitting SOSA/SSN in w3c/sdw-sosa-ssn#48

@alexrobin I'd be most thankful if we could keep the base definitions for Platform and System (and the System subtypes Sensor, Actuator, Sampler, in the extension also Observer) cleanly defined. I don't see anything hindering the creation of types that are both Platform and System (e.g., Drone), either in your application model, alternatively within whatever aspect of SOSA/SSN is best suited. Additionally, I think we may want to investigate additional System types, e.g., Battery

[dr-shorthair]

conceptually, certain kind of Platforms can also be Systems

a strength of RDFS/OWL is that, being set-based, an individual can be a member of more than one class, and the classes do not necessarily have sub-class relationships. (The ISO UML heritage makes this more difficult.)

[alexrobin]

@dr-shorthair Yes, I agree. And I'm happy to do it this way as long as nobody comes and tell me later that a Platform CANNOT be a System :-). I definitely want to be able to do that in Connected Systems API.

[KathiSchleidt]

@alexrobin this is what I've been proposing all along! Keep SOSA/SSN as clean discrete concepts, then mix and match in your application (same approach as we've taken in OMS).

[dr-shorthair]

Also see #61

[KathiSchleidt]

I just noticed that sosa:Platform is now a subclass of ssn:System:

sosa:Platform 
  rdfs:subClassOf ssn:System ;
  rdfs:subClassOf [ a owl:Restriction ; owl:onProperty sosa:hosts ; owl:allValuesFrom sosa:System ]  ;
  rdfs:isDefinedBy sosa-common: .

I'd thought we'd agreed against that in the thread above. Or did we just agree that ssn:System is not a subclass of sosa:System, sosa:System and ssn: System subtly diverging in their meaning?

[dr-shorthair]

@KathiSchleidt - my mistake. We did not have agreement on this. I will remove it.

What is the key property of System: it implements a Procedure What is the key property of Platform: it hosts a System

Some entity might be both a System and a Platform, but under the criteria above not all Platforms are Systems. So I vote against the sub-class relationship.