Platform

Option 1: From Kerry

In this section, 'I' refers to Kerry.

The Platform concept is used to exemplify the suggested approach in Proposals_for_rewriting_SSN#Compromise_Proposal_6_made_by_Kerry_January_2017

Here is an example based on the much discussed (but, note, still very much unresolved) concept of Platform (issue-88), and also partially proposed in this email https://lists.w3.org/Archives/Public/public-sdw-wg/2017Jan/0153.html. I have changed both the axiomatic definitions of extended ssn and (much less so here) the use of terms in sosa to make this work. I have had to make a lot of assumptions about unresolved issues to develop this example. Please bear with me. In particular I am NOT suggesting that sosa:Platform exists at all. On the contrary, it should always be ssn:Platform. See above for detail. Nor do I intend to comment on the use of skos:definition here.

sosa fragment

 sosa:Platform
 rdf:type rdfs:Class ;
 rdf:type owl:Class ;
 rdfs:comment "An entity to which other entities can be attached, particularly Sensors, Actuators, Sampling Devices and other Platforms"@en ;
 rdfs:label "Platform"@en ;
 skos:example "A post, a buoy or a fish might be a Platform.  Where a Sensor is virtual, such as a software simulation, a Platform might be a computer system that executes the software.    A Platform may be a person when the person is wearing or carrying a Sensor.”;

.

 sosa:onPlatform 
 rdf:type owl:ObjectProperty ;
 meta:domainIncludes sosa:Actuator ;
 meta:domainIncludes sosa:Sensor ;
 meta:rangeIncludes sosa:Platform ;
 rdfs:comment "Relation between a Sensor or Actuator and the Platform to which it is attached or which hosts it."@en ;
 skos:example "blah blah”@en;
 rdfs:label "on platform"@en ;
 owl:inverseOf sosa:attachedSystem ;

.

 sosa:attachedSystem
 rdf:type owl:ObjectProperty ;
 meta:domainIncludes sosa:Platform ;
 meta:rangeIncludes sosa:Actuator ;
 meta:rangeIncludes sosa:Sensor ;
 skos:example "blah blah”@en;
 rdfs:comment "Relation between a Platform and a Sensor or Actuator hosted on or attached to it."@en ;
 rdfs:label "attached system"@en ;
 owl:inverseOf sosa:onPlatform ;

.

ssn fragment, assuming ssn imports sosa

 ###  http://www.w3.org/ns/sosa/Platform
 sosa:Platform rdf:type owl:Class ;
            rdfs:subClassOf [ rdf:type owl:Restriction ;
                              owl:onProperty sosa:attachedSystem ;
                              owl:allValuesFrom ssn:System
                            ] ,
                            [ rdf:type owl:Restriction ;
                              owl:onProperty ssn:inDeployment ;
                              owl:allValuesFrom ssn:Deployment
                            ] ;
            dc:source """skos:exactMatch 'platform' [SensorML OGC-0700]
                                 http://www.opengeospatial.org/standards/sensorml""" ;
            rdfs:comment "A physical object to which Systems may be attached (using attachedSystem) and to which a Deployment may be associated (using inDeployment)"@en ;
            rdfs:isDefinedBy "http://www.w3.org/ns/sosa" ;
            rdfs:seeAlso "http://www.w3.org/2005/Incubator/ssn/wiki/SSN_Deploy#PlatformSite" .

 ###  http://www.w3.org/ns/ssn/System
 ssn:System rdf:type owl:Class ;
          rdfs:subClassOf [ rdf:type owl:Restriction ;
                            owl:onProperty ssn:hasSubSystem ;
                            owl:allValuesFrom ssn:System
                          ] ,
                          [ rdf:type owl:Restriction ;
                            owl:onProperty ssn:hasDeployment ;
                            owl:allValuesFrom ssn:Deployment
                          ] ,
                          [ rdf:type owl:Restriction ;
                            owl:onProperty ssn:hasOperatingRange ;
                            owl:allValuesFrom ssn:OperatingRange
                          ] ,
                          [ rdf:type owl:Restriction ;
                            owl:onProperty ssn:hasSubSystem ;
                            owl:allValuesFrom ssn:System
                          ] ,
                          [ rdf:type owl:Restriction ;
                            owl:onProperty ssn:hasSurvivalRange ;
                            owl:allValuesFrom ssn:SurvivalRange
                          ] 
                          ;
          dc:source "http://www.w3.org/2005/Incubator/ssn/" ;
          rdfs:comment "System is a unit of abstraction for pieces of infrastructure for sensing. A system has components, its subsystems, which are other systems. blah blah more here to describe properties blah blah " ;
          rdfs:isDefinedBy "http://www.w3.org/ns/ssn" ;
          rdfs:label "System" ;
          rdfs:seeAlso "http://www.w3.org/2005/Incubator/ssn/wiki/SSN_Model#System" .

 ###  http://www.w3.org/ns/sosa/Sensor
 sosa:Sensor rdf:type owl:Class ;
          rdfs:subClassOf blah blah  snip  as before ;
          rdfs:subClassOf ssn:System;
          blah, blah as before .

 ### ###  http://www.w3.org/ns/sosa/Actuator
 sosa:Actuator rdf:type owl:Class ;
          rdfs:subClassOf ssn:System;
          blah, blah as whatever would be the appopriate ssn extended properties.

 ###  http://www.w3.org/ns/ssn/Deployment
 # stuff about ssn:Deployment class that uses ssn:System skipped here

 ###  http://www.w3.org/ns/sosa/attachedSystem
 sosa:attachedSystem rdf:type owl:Class ;
                  rdfs:comment "Relation between a Platform and any Systems (e.g., Sensors) that are attached to the Platform." ;
                  rdfs:isDefinedBy "http://www.w3.org/ns/sosa" ;
                  rdfs:label "attached system" ;
                  rdfs:seeAlso "http://www.w3.org/2005/Incubator/ssn/wiki/SSN_Deploy#PlatformSite" .

 ###  http://www.w3.org/ns/ssn/deployedOnPlatform
 # stuff about ssn:deployedOnPlatform property skipped here
 

 ###  http://www.w3.org/ns/ssn/inDeployment
 # stuff about inDeployment  property skipped here 

 ###  http://www.w3.org/ns/sosa/onPlatform
 sosa:onPlatform rdf:type owl:ObjectProperty ;
              rdfs:comment "Relation between a System (e.g., a Sensor) and a Platform.  The relation locates the Sensor relative to other described entities: i.e., the Sensor's  location is assumed to be the location of the Platform.  More precise locations for Sensors in space (relative to other entities, where attached to another entity, or in 3D space) are made using DOLCE's Regions (SpaceRegion)." ;
              rdfs:isDefinedBy "http://www.w3.org/ns/sosa" ;
              rdfs:seeAlso "http://www.w3.org/2005/Incubator/ssn/wiki/SSN_Deploy#PlatformSite" .

Notes on example

Note: Here I have extended the old ssn to assert that both Sensors and Actuators are Systems, and this enables the same attachment properties to be used to associate sensors with platforms in both the core and extended ssn. This assumes also that the dul alignment for system is changed to allow systems to be virtual objects, or a similar change for the same purpose, as I proposed earlier. This is necessary to allow Systems to include Sensors, and including virtual Sensors (which was not the case in old ssn).

Comment from Simon: if we follow this pattern, then notional:SamplingDevice would also be a subclass of ssn:System, OK? And the comment on ssn:System must be generalized - currently it says "System is a unit of abstraction for pieces of infrastructure for sensing. " Needs to say "System is a unit of abstraction for pieces of infrastructure for observation, actuation or sampling."

Response from Kerry: yes, notional:SamplingDevice should also be a subclass of ssn:System if it needs to be attached to a platform, which I undertand it does. And I agree the System comment should be generalised but as a sensor is now a system in this example I have to wonder why it is being removed from the comment in your suggestion?

Response from Simon: 'Observation' is essentially synonymous with 'Sensing' so I was using the more vernacular term. No big deal either way.

Note: This is a tiny change to ssn that, subject to also aligning comments in the way that Armin is working on right now, is entirely backward compatible. Yet it also allows the core to model the relationship between sensors (and actuators) and platforms exactly as the core wanted to --ie without the conplexity of composable systems. What is not to like?

Note: the rdfs:isdefinedBy property should be used in a helpful way (not necessarily as here)

Comment from Simon: the use of rdfs:isdefinedBy for ontology membership is common, but is not universally used or expected, and IMHO not to be trusted. This is a real hole in the ecosystem.

Note: the ssn habit for using rdfs:seeAlso to point to a graphic should be replicated in sosa.

Note: the ssn habit of using dc:source to declare the provenance of terms should be continued throughout.

Comment from Simon: OK - but seeing skos predicates nested in annotations is a bit distracting. I understand that you are intending to refine the semantics, yet still use a well-known vocabulary term. Where the alignment is with O&M you could use skos predicates directly and the URIs seen in https://github.com/ISO-TC211/GOM/blob/master/isotc211_GOM_harmonizedOntology/19156/2011/iso19156Observation.owl which match the rules in ISO 19150-2.

Response from Kerry: I agree on the distraction -- can you suggest a general way to remove the distraction? For this case, your suggestion makes sense but as it does not point to the standard I would not like to remove the reference to the standard anyway. Also, strictly skos is not owl-dl so we would have to do some trick like declaring them as annotation properties which I guess is ok

Response from Simon: (i) OK - no big deal, although it is distracting, it is pretty good as an annotation. (ii) regarding the URIs for ISO classes - we clearly have a practice clash here. ISO/TC 211 prefers to publish abstract models and then rules for implementation. Implementation artefacts are then made available in various places and providing they follow the rules its OK. In this case the rule in ISO 19150-2 spells out exactly what the URIs for the classes and properties look like, and the ones in the github repo follow those rules. So the URI for the official OWL implementation of 'OM_Observation' is exactly http://def.isotc211.org/iso19156/2011/Observation#OM_Observation . Unfortunately this URI is not directly resolvable, nevertheless it is a persistent identifier. The GitHub link above is one place you can find the implementation, there may be another in the future but the URIs will be the same.

Note: there should be standard conventions for labels style and case. I have adopted the ssn convention here because it is consistent and I prefer it to the sosa examples. There should be no need to repeat labels in sosa and the extended ssn, but I suspect we do need to due to tooling e.g. specgen.

Note: I have not been entirely consistent here about whether Platforms may be attached to Platforms. SensorML defines it that way -- and we should follow imo.

Note: this use of skos:example now in sosa should be applied throughout

Differences for ssn and sosa

Sosa

1. rdfs:comment on Platform changed to be more descriptive of the use of Platform in a sosa context. References to other sosa terms as proper nouns. Forget "at least one" part of comment (irrelevant). "e.g. simulations" is confusing (is example of what?) etc. NB sosa has changed this again after this was written -- needs revisiting.
2. Similar treatment of comment for onPlatform and attachedSystem
3. Changed hostedBy/hosts to onPlatform/attachedSystem respectively because these are rather strange terms and no reason has been given to change them from previous as in ssn, so default to compatibility

ssn

1. changed rdfs:comment for Platform to show how Platform is used in an SSN contenxt, referring to how properties are to be used
2. example removed from rdfs:comment for Platform in line with plan to move to skos:example, which is not needed right here as the example is already attached to the concept in sosa
3. System unchanged (universal restriction removed as per previous unrelated decision, one restriction duplicated in error, rdfs:comment should be clarified and mapped to new style that names relevant properties).
4. Sensor asserted to be a subclass of System --- this is entirely new --- so that Sensor can be attached to Platforms as required by SOSA.
5. Actuator added (as for SOSA)as a subclass of System so it can be attached to a Platform as required for sosa.
6. No other changes.

Summary of changes

Here I have extended the old ssn to assert that both Sensors and Actuators are Systems, and this enables the same attachment properties to be used to associate sensors with platforms in both the core and extended ssn. This assumes also that the dul alignment for system is changed to allow systems to be virtual objects, not shown here. This is necessary to allow Systems to include Sensors, and including virtual Sensors (which was not the case in old ssn where Sensors were not necessarily Systems). All ssn changes are generalisations, so is fully backwardly-compatible.

Option 2: any other option ?