107 Add `SystemKind` class and its subclasses

[alexrobin]

Closes #107

Adds the SystemKind class to describe types of systems, as well as the corresponding subclasses :

• SensorKind
• ActuatorKind
• SamplerKind
• PlatformKind

Also adds the hasSystemKind property to reference the SystemKind from the System instance.

See updated documentation at: https://raw.githack.com/w3c/sdw-sosa-ssn/107-add-systemkind-classes/ssn/index.html

[alexrobin]

@dr-shorthair I have updated the documentation. You can see it here: https://raw.githack.com/w3c/sdw-sosa-ssn/107-add-systemkind-classes/ssn/index.html

[alexrobin]

I'm not sure the MIN 1 cardinality on implements is justified now that we also have hasSystemKind. There can be systems that have no attached procedures I think.

[alexrobin]

There is also this note that I think is misleading now that we have introduced SensorKind:

Note: The observing procedure cannot describe a sensor instance, but it can describe the sensor type.

The Sensor type would be better described by SensorKind, and not by ObservingProcedure anymore:

[KathiSchleidt]

Platform is not a System, so if you need PlatformKind, you'd need to add it to Platform itself. See #46 and #203

[alexrobin]

@KathiSchleidt The property is only defined on System because it's called hasSystemKind. So the intent was to use the property on a Platform only if the platform is also a System.

Not sure if it's still ok to have these axioms in that case: https://github.com/w3c/sdw-sosa-ssn/blob/e82264cc70f47be46d8050d032caf63119a1a724/ssn/rdf/ontology/core/ssn-common.ttl#L188-L190

I suppose we could generalize this property and call it hasEntityKind or just hasKind so it also works on Platform directly, I dont know...

IMO, it would certainly make things easier if Platform was also a subclass of System...

Note that I'm interested in using the "system capabilities module" properties on PlatformKind so one can define the platform "operating range", "survivable range", etc... So it seems that at some point there is going to be a terminology conflict if platforms are not systems...

Another (perhaps cleaner) alternative would be to add a class that's called PlatformSystem...

[dr-shorthair]

Since Platform and System are not disjoint, you can make an individual both sosa:Platform and sosa:System (or one of its subclasses). But sosa:Platform rdfs:subClassOf sosa:System . implies that every Platform is a system. I don't think we want that.

In general the key functions of members of the two classes are:

• Platforms host Systems
• Systems implement Procedures

Some but not all Platforms are also Systems. These are distinct functions, and I don't think they should be conflated.

[dr-shorthair]

I'm not sure the MIN 1 cardinality on implements is justified now that we also have hasSystemKind. There can be systems that have no attached procedures I think.

Where is this?

[kjano]

Hi, some comments on this PR and the underlying discussion in issue 107; please feel free to ignore:

1. The success of SOSA was/is largely based not on what is there but what isn't. It took a lot of discipline to keep the core small and I would rather see additions to SSN instead of nearly doubling the number of classes in SOSA.
2. If I understand the issue, this is a generic pattern that appears everywhere in modeling. E.g., we can have an event and an event kind and so on. This has been documented all the years back to Natasha Noy's work. There are many well-established modeling (patterns) and technical solutions such as punning. We can also use typecasting etc. I would prefer to be very careful here, otherwise we may need to add FeatureOfInterestKind etc next. This is a dangerous path to take for a standard.
3. Classes are kinds and thus the naming is unfortunate. In fact, a common ontology modeling recommendation is to avoid type, kind, etc in labels. For instance, we may have a Tornado class that is an Event (subclass of) but should avoid naming classes TornadoEvent. There are certainly cases where this is hard to avoid, e.g., we struggle with this in KnowWhereGraph, but for a core ontology I would rather like to avoid this.
4. As discussed, this moves us closer to datasheet info.

Thanks for reading. Jano

[alexrobin]

@dr-shorthair

I'm not sure the MIN 1 cardinality on implements is justified now that we also have hasSystemKind. There can be systems that have no attached procedures I think.

Where is this?

This is in the docs and the rdf: https://github.com/w3c/sdw-sosa-ssn/blob/107-add-systemkind-classes/ssn/rdf/ontology/core/ssn-observation.ttl#L49 https://github.com/w3c/sdw-sosa-ssn/blob/107-add-systemkind-classes/ssn/rdf/ontology/core/ssn-actuation.ttl#L48 https://github.com/w3c/sdw-sosa-ssn/blob/107-add-systemkind-classes/ssn/rdf/ontology/core/ssn-sampling.ttl#L85

[alexrobin]

@kjano I agree that the 'kind' pattern is very general, but several people have agreed that being able to describe types/kinds of systems in addition to system instances is something that was particularly missing from SOSA/SSN.

You're right that a cleaner approach would be to use classes to describe specific "system types" (e.g. the DHT22 sensor model), making them a subclass of either Sensor, Actuator or Sampler. However, if we do that, then all "system instances" (e.g. a specific instance of the DHT22 sensor that is used to produce measurements) would have to be individuals so we can clearly differentiate between the two.

I am OK with this if this is a pattern that we are willing to document and enforce. If we don't, then there will always be ambiguity as to which classes or individuals define a "system type" and which ones define an "system instance". This was the original complaint behind issue #107.

So I think what @kjano reminds us of is true and using the pure OWL class vs. individual pattern is definitely a cleaner approach. It solves my use case personally, but I don't have enough background to decide if it works for other users of SOSA/SSN or not.

In any case, I'm OK just cancelling this whole PR if we agree to do this.

[alexrobin]

@kjano I think one thing that the class vs. individual pattern makes harder is to set specific values for the type (like datasheet level info on the DHT22 sensor model). I think what's why the SystemKind approach was selected by @maximelefrancois86 at the first place.

Perhaps SystemKind is not the right name? Perhaps we should just call it SystemSpecifications or SystemSpecs to make it clear that it is not the same as a type/class in the RDF sense.

[maximelefrancois86]

Indeed, although the canonical approach to distinguish types vs individuals in ontologies is to use classes vs instances, it is well acknowledged that different SOSA/SSN users have used classes sosa:Sensor, sosa:Property, etc. , sometimes to represent things that are generic (a sensor kind like <dht22>, a property kind like <temperature>), and sometimes to represent things that are specific (a specific sensor like <the_dht22_on_my_desk>, the actual property that is specific to a feature of interest like <the_temperature_of_my_office>). It's not a good option to force those that want to model generic things to use classes and rely on OWL restrictions or annotations to further describe these classes. For example, most SOSA users prefer to have <temperature> modeled as an individual rather than a class. As for sensors, there may be an equal share of users wanting to use sosa:Sensor to actually model sensors kinds, and users wanting to use sosa:Sensor to actually model sensor instances. By introducing PropertyOfInterest, we solved the first issue. And by introducing SensorKind, we solve the second.

It would be now very convenient for both sensor catalog editors to expose datasheets in RDF:

<dht22> a sosa:SensorKind ;
  sosa:observes <temperature> , <humidity> ;
  sosa:hasPropertyValue [  sosa:hasValue "-40-80Celsius" ; sosa:isValueOfProperty <temperature_operating_range> ] ;
  sosa:hasPropertyValue [  sosa:hasValue "0-100%RH" ; sosa:isValueOfProperty <humidity_operating_range> ]  ;

and for application developers:

<the_dht22_on_my_desk> a sosa:Sensor ;
  sosa:observes <temperature> ,  <humidity> ; # if using sosa:Property
  sosa:observes <the_temperature_in_my_office> , <the_humidity_in_my_office> ; # if using sosa:PropertyOfInterest
  sosa:madeObservation [ a sosa:Observation ; sosa:hasSimpleResult 22.0 ; sosa:observedProperty <temperature> ] ;
  sosa:madeObservation [ a sosa:Observation ; sosa:hasSimpleResult 50 ; sosa:observedProperty <humidity> ] .

[alexrobin]

@KathiSchleidt @dr-shorthair Based on your comments, are you OK to keep PlatformKind as a subclass of SystemKind then, as it is currently the case in the PR? I guess not but I'm asking just in case.

If we remove this relationship, then do you see it working the same as Platform + System, that is, somebody can create a class that is both SystemKind and PlatformKind if needed?

What about the hasSystemKind property? Do we reuse it on Platform? Do we give the property a more generic name?

If we want to keep Platform and PlatformKind clean, I'm also not sure how to write these axioms: https://github.com/w3c/sdw-sosa-ssn/blob/e82264cc70f47be46d8050d032caf63119a1a724/ssn/rdf/ontology/core/ssn-common.ttl#L188-L190

The goal was just to ensure that a Platform always references a PlatformKind. This can work if the has***Kind is also allowed on Platform directly.

Do you have any suggestions?

[dr-shorthair]

@dr-shorthair

I'm not sure the MIN 1 cardinality on implements is justified now that we also have hasSystemKind. There can be systems that have no attached procedures I think.

Where is this?

This is in the docs and the rdf: https://github.com/w3c/sdw-sosa-ssn/blob/107-add-systemkind-classes/ssn/rdf/ontology/core/ssn-observation.ttl#L49 https://github.com/w3c/sdw-sosa-ssn/blob/107-add-systemkind-classes/ssn/rdf/ontology/core/ssn-actuation.ttl#L48 https://github.com/w3c/sdw-sosa-ssn/blob/107-add-systemkind-classes/ssn/rdf/ontology/core/ssn-sampling.ttl#L85

implements is the key property of a System. A System is pointless unless it implements a procedure.

Are you suggesting that this information is 'inherited' from the SystemKind, so doesn't need to be expressed on the System node? This depends a bit on how you understand the OWL axioms: the way I see it is that every System must have an implements property. Even if the value can be found on the 'parent' SystemKind, it could still be copied down to the System instance to satisfy the cardinality axiom. So even if it is not directly present in the data, it still logically exists and the cardinality axiom is correct.

Note: OWL expresses logical expectations. This is not the same as SHACL which expresses dataset validation expectations.

[alexrobin]

@dr-shorthair

Are you suggesting that this information is 'inherited' from the SystemKind, so doesn't need to be expressed on the System node?

Yes, exactly. In many cases the procedure would be described by the kind and not repeated on every instance (at least that's how we do it in connected systems). That's why @maximelefrancois86 requested in a separate issues that many properties should be modified to include the Kind classes in their domain or range.

If you think the logical relationship should still be expressed in OWL then I'm perfectly OK with it. I just wanted to make sure we don't break the SOSA/SSN model with what we do in the API.

[alexrobin]

@dr-shorthair Following the same reasoning, I think the cardinality of hasSystemKind should be changed to EXACTLY ONE then, because, logically, there is always a kind, even if it's not always provided.

What do you think?

[maximelefrancois86]

hasSystemKind may have cardinality MIN 1, but not EXACTLY 1 . We organise system kinds in a taxonomy, and a system may have more than one kind, and inherit the more generic kinds of his system kind

[alexrobin]

hasSystemKind may have cardinality MIN 1, but not EXACTLY 1 . We organise system kinds in a taxonomy, and a system may have more than one kind, and inherit the more generic kinds of his system kind

Ok, I was wondering about this too. I will change it to MIN 1.

[dr-shorthair]

Hi, some comments on this PR and the underlying discussion in issue 107; please feel free to ignore:

1. The success of SOSA was/is largely based not on what is there but what isn't. It took a lot of discipline to keep the core small and I would rather see additions to SSN instead of nearly doubling the number of classes in SOSA.

Yes - there has been a significant expansion of the number of terms in the sosa: namespace. This could be confusing or overwhelming for new users. However, I suggest that (i) the improvements in documentation and diagrams should help (ii) some of the additions are to make the structures more internally consistent, with more complete class- and property-hierarchies, better use of sosa:System and sosa:Execution etc. which also should make the whole thing less scattered.

A major change was to move all SSN terms into the SOSA namespace, justified by the fact that multiple namespaces are one of the things that confuse developers who are not already immersed in the semantic world. So a simplification on one axis (# namespaces) leads to a blowout on another (# terms in core).

Are there parts of the current draft that could sensibly be moved into extension modules? Maybe the SSO piece is of minor interest in practice, but that only covers four terms (Stimulus, detects, wasOriginatedBy, isProxyFor). Any others?

[dr-shorthair]

Should datasheets (*Kind classes) be moved to an extension module?

[dr-shorthair]

Update team agreed not to introduce a specific SystemKind class.