107 Add `SystemKind` class and its subclasses #209

alexrobin · 2024-03-18T22:22:11Z

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

dr-shorthair

RDF looks good and clean.
Can you also add documentation in

Common.html
Actuation.html
Observation.html
Sampling.html

alexrobin · 2024-03-19T14:10:51Z

@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 · 2024-03-19T14:13:36Z

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 · 2024-03-19T14:16:46Z

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:

…commits)

# Conflicts: # ssn/chapters/Common.html # ssn/chapters/Sampling.html

KathiSchleidt · 2024-03-21T20:07:23Z

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

alexrobin · 2024-03-21T22:34:28Z

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

sdw-sosa-ssn/ssn/rdf/ontology/core/ssn-common.ttl

Lines 188 to 190 in e82264c

    
           sosa:Platform  
        
             rdfs:subClassOf [ a owl:Restriction ; owl:onProperty sosa:hasSystemKind ; owl:allValuesFrom sosa:PlatformKind ]  ; 
        
             rdfs:subClassOf [ a owl:Restriction ; owl:onProperty sosa:hasSystemKind ; owl:maxCardinality "1"^^xsd:nonNegativeInteger ] ;

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 · 2024-03-22T01:36:48Z

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.

maximelefrancois86 · 2024-03-22T10:17:33Z

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 · 2024-03-25T09:02:04Z

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

sdw-sosa-ssn/ssn/rdf/ontology/core/ssn-common.ttl

Lines 188 to 190 in e82264c

    
           sosa:Platform  
        
             rdfs:subClassOf [ a owl:Restriction ; owl:onProperty sosa:hasSystemKind ; owl:allValuesFrom sosa:PlatformKind ]  ; 
        
             rdfs:subClassOf [ a owl:Restriction ; owl:onProperty sosa:hasSystemKind ; owl:maxCardinality "1"^^xsd:nonNegativeInteger ] ;

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 · 2024-03-25T09:18:54Z

@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 · 2024-03-25T09:46:09Z

@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 · 2024-03-25T09:48:23Z

@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 · 2024-03-25T10:00:33Z

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 · 2024-03-25T10:07:05Z

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 · 2024-04-24T09:40:39Z

ssn/rdf/ontology/core/ssn-actuation.ttl

@@ -43,12 +43,18 @@ sosa:ActuatingProcedure

 sosa:Actuator 
  rdfs:subClassOf sosa:System ;
+  rdfs:subClassOf [ a owl:Restriction ; owl:onProperty sosa:hasSystemKind ; owl:allValuesFrom sosa:ActuatorKind ]  ;
+  rdfs:subClassOf [ a owl:Restriction ; owl:onProperty sosa:hasSystemKind ; owl:maxCardinality "1"^^xsd:nonNegativeInteger ] ;


Should this be minCardinality?

dr-shorthair · 2024-04-24T09:41:48Z

ssn/rdf/ontology/core/ssn-observation.ttl

@@ -43,6 +43,8 @@ sosa:ObservingProcedure

 sosa:Sensor 
  rdfs:subClassOf sosa:System ;
+  rdfs:subClassOf [ a owl:Restriction ; owl:onProperty sosa:hasSystemKind ; owl:allValuesFrom sosa:SensorKind ]  ;
+  rdfs:subClassOf [ a owl:Restriction ; owl:onProperty sosa:hasSystemKind ; owl:maxCardinality "1"^^xsd:nonNegativeInteger ] ;


Should this be minCardinality?

dr-shorthair · 2024-04-24T09:41:50Z

ssn/rdf/ontology/core/ssn-common.ttl

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

+sosa:PlatformKind
+  rdfs:subClassOf sosa:SystemKind ;


Hmm. Not comfortable mixing Platform and System.

dr-shorthair · 2024-04-24T09:42:03Z

ssn/rdf/ontology/core/ssn-sampling.ttl

@@ -80,11 +80,17 @@ sosa:SamplingProcedure

 sosa:Sampler 
  rdfs:subClassOf sosa:System ;
+  rdfs:subClassOf [ a owl:Restriction ; owl:onProperty sosa:hasSystemKind ; owl:allValuesFrom sosa:SamplerKind ]  ;
+  rdfs:subClassOf [ a owl:Restriction ; owl:onProperty sosa:hasSystemKind ; owl:maxCardinality "1"^^xsd:nonNegativeInteger ] ;


Should this be minCardinality?

dr-shorthair · 2024-04-24T09:44:15Z

ssn/chapters/Sampling.html

+                        <span about="[_:SOSASampler2]" rel="owl:onProperty" resource="sosa:hasSystemKind"><a
+                                href="#SOSAhasSystemKind">sosa:hasSystemKind</a></span>
+                        <span about="[_:SOSASampler2]" property="owl:maxCardinality" content="1"
+                            datatype="xsd:nonNegativeInteger"><em><b>MAX 1</b></em> <a


Should this be minCardinality?

dr-shorthair · 2024-04-24T09:44:38Z

ssn/chapters/Observation.html

+                        <span about="[_:SOSASensor5]" rel="owl:onProperty" resource="sosa:hasSystemKind"><a
+                                href="#SOSAhasSystemKind">sosa:hasSystemKind</a></span>
+                        <span about="[_:SOSASensor5]" property="owl:maxCardinality" content="1"
+                            datatype="xsd:nonNegativeInteger"><em><b>MAX 1</b></em> <a


Should this be minCardinality?

dr-shorthair

Some cardinalities are MAX which should be MIN
System and Platform appear to be entangled in a way that has not been agreed.

dr-shorthair · 2024-05-08T05:05:11Z

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

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 · 2024-05-08T12:12:24Z

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

dr-shorthair

I'm now thinking that SystemKind and its specializations might be better added to the
System Capabilities extension module.

Also see detailed comments inline.

Maybe.

dr-shorthair · 2024-07-03T03:00:56Z

Update team agreed not to introduce a specific SystemKind class.

dr-shorthair · 2024-10-15T05:41:19Z

Superseded by #254

alexrobin requested review from dr-shorthair and maximelefrancois86 March 18, 2024 22:22

dr-shorthair requested changes Mar 19, 2024

View reviewed changes

dr-shorthair mentioned this pull request Mar 19, 2024

197 common modeling questions #201

Merged

alexrobin changed the title ~~Add SystemKind class and its subclasses~~ 107 Add SystemKind class and its subclasses Mar 19, 2024

Added Kind classes

280ece1

alexrobin force-pushed the 107-add-systemkind-classes branch 2 times, most recently from 99abb65 to 766c457 Compare March 19, 2024 09:59

maximelefrancois86 approved these changes Mar 19, 2024

View reviewed changes

alexrobin force-pushed the 107-add-systemkind-classes branch 2 times, most recently from 8d2109f to 9905503 Compare March 19, 2024 13:02

Updated documentation

162ce74

alexrobin force-pushed the 107-add-systemkind-classes branch from 9905503 to 162ce74 Compare March 19, 2024 13:15

Added hasSystemKind property cardinality

d69d25b

maximelefrancois86 mentioned this pull request Mar 19, 2024

Extend domains and ranges to "Kind" classes #211

Closed

alexrobin added 3 commits March 19, 2024 14:23

Small fixes in documentation

04d3840

Added capabilites properties to SystemKind

2c02da9

Add myself to contributor list

bb42880

dr-shorthair added 3 commits March 20, 2024 11:36

Add Alex to editor list (substantial contribution measured by GitHub …

1e5dc6f

…commits)

Add non-normative notes for new terms

3c30d66

Merge branch 'gh-pages' into 107-add-systemkind-classes

e82264c

# Conflicts: # ssn/chapters/Common.html # ssn/chapters/Sampling.html

dr-shorthair approved these changes Mar 21, 2024

View reviewed changes

dr-shorthair mentioned this pull request Mar 21, 2024

Remove OWL cardinality restrictions #216

Closed

type --> kind

69fee37

Changed hasSystemKind cardinality to MIN 1

765d8b4

alexrobin force-pushed the 107-add-systemkind-classes branch from 9fb929b to 765d8b4 Compare March 25, 2024 13:36

Merge branch 'gh-pages' into 107-add-systemkind-classes

1aae875

dr-shorthair reviewed Apr 24, 2024

View reviewed changes

dr-shorthair requested changes Apr 24, 2024

View reviewed changes

Merge branch 'gh-pages' into 107-add-systemkind-classes

43d5e65

dr-shorthair self-requested a review May 21, 2024 06:08

dr-shorthair requested changes May 21, 2024

View reviewed changes

Merge branch 'gh-pages' into 107-add-systemkind-classes

b8cda42

dr-shorthair marked this pull request as draft May 27, 2024 06:06

Full InkBird example using the subclassing pattern

6be71bf

Maybe.

oldskeptic self-requested a review June 28, 2024 15:30

dr-shorthair closed this Jul 3, 2024

dr-shorthair deleted the 107-add-systemkind-classes branch September 25, 2024 10:09

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

107 Add `SystemKind` class and its subclasses #209

107 Add `SystemKind` class and its subclasses #209

alexrobin commented Mar 18, 2024 •

edited

Loading

dr-shorthair left a comment

alexrobin commented Mar 19, 2024

alexrobin commented Mar 19, 2024

alexrobin commented Mar 19, 2024 •

edited

Loading

KathiSchleidt commented Mar 21, 2024

alexrobin commented Mar 21, 2024 •

edited

Loading

dr-shorthair commented Mar 22, 2024

maximelefrancois86 commented Mar 22, 2024 •

edited

Loading

alexrobin commented Mar 25, 2024 •

edited

Loading

dr-shorthair commented Mar 25, 2024

alexrobin commented Mar 25, 2024 •

edited

Loading

alexrobin commented Mar 25, 2024

maximelefrancois86 commented Mar 25, 2024

alexrobin commented Mar 25, 2024

dr-shorthair Apr 24, 2024

dr-shorthair Apr 24, 2024

dr-shorthair Apr 24, 2024

dr-shorthair Apr 24, 2024

dr-shorthair Apr 24, 2024

dr-shorthair Apr 24, 2024

dr-shorthair left a comment

dr-shorthair commented May 8, 2024

dr-shorthair commented May 8, 2024

dr-shorthair left a comment

dr-shorthair commented Jul 3, 2024

dr-shorthair commented Oct 15, 2024

107 Add SystemKind class and its subclasses #209

107 Add SystemKind class and its subclasses #209

Conversation

alexrobin commented Mar 18, 2024 • edited Loading

dr-shorthair left a comment

Choose a reason for hiding this comment

alexrobin commented Mar 19, 2024

alexrobin commented Mar 19, 2024

alexrobin commented Mar 19, 2024 • edited Loading

KathiSchleidt commented Mar 21, 2024

alexrobin commented Mar 21, 2024 • edited Loading

dr-shorthair commented Mar 22, 2024

maximelefrancois86 commented Mar 22, 2024 • edited Loading

alexrobin commented Mar 25, 2024 • edited Loading

dr-shorthair commented Mar 25, 2024

alexrobin commented Mar 25, 2024 • edited Loading

alexrobin commented Mar 25, 2024

maximelefrancois86 commented Mar 25, 2024

alexrobin commented Mar 25, 2024

dr-shorthair Apr 24, 2024

Choose a reason for hiding this comment

dr-shorthair Apr 24, 2024

Choose a reason for hiding this comment

dr-shorthair Apr 24, 2024

Choose a reason for hiding this comment

dr-shorthair Apr 24, 2024

Choose a reason for hiding this comment

dr-shorthair Apr 24, 2024

Choose a reason for hiding this comment

dr-shorthair Apr 24, 2024

Choose a reason for hiding this comment

dr-shorthair left a comment

Choose a reason for hiding this comment

dr-shorthair commented May 8, 2024

dr-shorthair commented May 8, 2024

dr-shorthair left a comment

Choose a reason for hiding this comment

dr-shorthair commented Jul 3, 2024

dr-shorthair commented Oct 15, 2024

107 Add `SystemKind` class and its subclasses #209

107 Add `SystemKind` class and its subclasses #209

alexrobin commented Mar 18, 2024 •

edited

Loading

alexrobin commented Mar 19, 2024 •

edited

Loading

alexrobin commented Mar 21, 2024 •

edited

Loading

maximelefrancois86 commented Mar 22, 2024 •

edited

Loading

alexrobin commented Mar 25, 2024 •

edited

Loading

alexrobin commented Mar 25, 2024 •

edited

Loading