Compare the classes and their definitions from SOSA, SSN, O&M and om-lite and sam-lite.

TODO: Need to add 'annotations' from dc:source in SSN Ontology.

Classes

Generic	SOSA	SSN	O&M	om-lite sam-lite
An Actuation puts in motion or activates an entity to change its state.	sosa:Actuation An Actuation carries out an (Actuation) Procedure to change the state of the world using an Actuator.	-	-	-
An Observation is an activity to estimate or calculate a value of a property of a real world phenomena.	sosa:Observation Activity of carrying out an (Observation) Procedure to estimate or calculate a value of a Property of a FeatureOfInterest. Links to a Platform or Sensor to describe what made the Observation and how; links to an ObservableProperty to describe what the result is an estimate of, and to a FeatureOfInterest to detail what that property was associated with. The Result is the output.	ssn:Observation An Observation is a Situation in which a Sensing method has been used to estimate or calculate a value of a Property of a FeatureOfInterest. Links to Sensing and Sensor describe what made the Observation and how; links to Property and Feature detail what was sensed; the result is the output of a Sensor; other metadata details times etc. Also see: ssnx:ActivityOfSensing (from SSN-PROV alignment paper) NB This is NOT an ssn term (Kerry) The prov:Activity of a ssn:Sensor performing the sensing. An ActivityOfSensing prov:generated the ssn:SensorOutput, was influenced by (prov:wasInfluencedBy) the ssn:Stimulus and, through SensorPerformedSensing (a prov:Association), prov:wasAssociatedWith the sensor.	OM_Observation An observation is an act associated with a discrete time instant or period through which a number, term or other symbol is assigned to a phenomenon. It involves application of a specified procedure, such as a sensor, instrument, algorithm or process chain. The procedure may be applied in-situ, remotely, or ex-situ with respect to the sampling location. The result of an observation is an estimate of the value of a property of some feature.	oml:Observation An observation is an act associated with a discrete time instant or period through which a number, term or other symbol is assigned to a phenomenon. It involves application of a specified procedure, such as a sensor, instrument, algorithm or process chain. The procedure may be applied in-situ, remotely, or ex-situ with respect to the sampling location. The procedure may take inputs from the environment (as stimuli) or from the results of prior observations or processes. The result of an observation is an estimate of the value of a property of some feature. Use of a common model allows observation data using different procedures to be combined unambiguously. The observation itself is also a feature, since it has properties and identity. Observation details are important for data discovery and for data quality estimation. The observation could be considered to carry metadata about an instance of a property (of the feature of interest). This property-value metadata complements the dataset and feature metadata that have been conventionally considered (e.g. ISO 19115). The values for the properties 'procedure', 'featureOfInterest', 'observedProperty', 'phenomenonTime', 'resultTime' may be inherited from a container resource.
An Actuator is an entity that is used by, or implements a process that changes the state of the world.	sosa:Actuator A device that is used by, or implements, an (Actuation) Procedure that changes the state of the world.	-	-	-
A Sensor is an entity that responds to a stimulus (change in the environment) to generate a result.	sosa:Sensor Device, agent (including humans), or software (simulation) involved in, or implementing, a (Sensing) Procedure. Sensors responds to a stimulus, e.g., a change in the environment, and generate a Result. Sensors can be mounted on Platforms, e.g., a modern smart phone hosts multiple sensors.	ssn:Sensor A sensor can do (implements) sensing: that is, a sensor is any entity that can follow a sensing method and thus observe some Property of a FeatureOfInterest. Sensors may be physical devices, computational methods, a laboratory setup with a person following a method, or any other thing that can follow a Sensing Method to observe a Property.	[ subclassOf OM_Process ]	[ subclassOf oml:Process ] .
A process is a workflow, protocol, plan, algorithm, or computational method specifying how to make an observation or how to perform an actuation.	sosa:Procedure A workflow, protocol, plan, algorithm, or computational method specifying how to make an Observation, create a Sample, or make a change to the state of the world (via an Actuator). A Procedure is re-usable, and might be involved in many observations, samplings, or actuations. It explains the steps to be carried out to arrive at reproducible results. Many observations may be created via the same Procedure the same way as many tables are assembled using the same instructions (as information objects, not their concrete realization).	ssn:Sensing Sensing is a process that results in the estimation, or calculation, of the value of a phenomenon. subclassof ssn:Process ssn:Process A process has an output and possibly inputs and, for a composite process, describes the temporal and dataflow dependencies and relationships amongst its parts. [SSN XG]  ;	OM_Process The purpose of an observation process is to generate an observation result. An instance of OM_Process is often an instrument or sensor, but may be a human observer, a simulator, or a process or algorithm applied to more primitive results used as inputs. NOTE ISO 19115-2 provides MI_Instrument, LE_Processing and LE_Algorithm, which could all be modelled as specializations of OM_Process. OGC SensorML [16] provides a model which is suitable for many observation procedures.	oml:Process Agent, device, sensor, software, protocol, computational method, algorithm or plan responsible for generating an observation result. Input may be a sensor stimulus, or the output from a previous process. An oml:Process is re-usable, and might be involved in many observations. This terminology is consistent with SensorML, which defines Process as the super-class of all sensors and sensor systems. But this usage is different to the use of the term "Process" in BCO and OBOE, where it denotes an observation occurrence.
A platform is an entity that carries other entities, in particular sensors, actuators or other platforms. Please see alternative proposal with justification posted on the list. An entity to which other entities can be Attached, particularly Sensors, Actuators, Sampling Devices and other Platforms. (Kerry) https://lists.w3.org/Archives/Public/public-sdw-wg/2017Jan/0153.html	sosa:Platform A device, (computational) system, or agent (including humans). A platform carries at least one Sensor, Actuator, or Sampling Device to produce observations, actuations, or samples, by following a Procedure. In case of virtual sensors, a platform can be a computing system which hosts software implementations, e.g., simulations	ssn:Platform An Entity to which other Entities can be attached - particuarly Sensors and other Platforms. For example, a post might act as the Platform, a bouy might act as a Platform, or a fish might act as a Platform for an attached sensor.	-	-
A FeatureOfInterest is an abstraction of a real world phenomena (thing, person, event, etc.) that is being observed. Don't really understand why in this case only we refer to 'an abstraction of' the thing in the world. We don't insert this qualification for Sensor or Platform. Yes, it is true that in a dataset it is only represented by an identifier and perhaps a partial description, but I feel that 'abstraction of' is unneccessary fog here. - SC	sosa:FeatureOfInterest The feature whose ObservableProperty is being observed by a Sensor to arrive at a Result For example, when measuring the height of a tree, the height is the ObservedProperty, 20m may be the Result of the Observation, and the tree is the FeatureOfInterest.	ssn:FeatureOfInterest A feature is an abstraction of real world phenomena (thing, person, event, etc). skos:exactMatch 'feature' [O&M]	GFI_Feature In an implementation, this abstract class shall be substituted by a concrete class representing a feature type from an application schema associated with a domain of discourse in accordance with ISO 19109:2005 and ISO 19101:2002.	[ subclassOf owl:Class ] .
A Sample is a representation of a real world phenomena that is not accessible to be observed in its entirety.	sosa:Sample Feature on which Observations may be made, which is intended to be representative of a FeatureOfInterest that is not fully accessible. Samples are artifacts of an observational strategy, and have no significant function outside of their role in the observation process. The characteristics of the samples themselves are of little interest, except perhaps to the manager of a sampling campaign. A Sample is intended to sample some FeatureOfInterest in an application domain, so there is an expectation of at least one sampledFeature property. However, in some cases the identity, and even the exact type, of the sampled feature may not be known when observations are made using the Sample. NOTE A transient sample, such as a ships-track or flight-line, might be identified and described, but is unlikely to be revisited exactly. EXAMPLE A “station” is essentially an identifiable locality where a sensor system or Process may be deployed and an observation made. In the context of the observation model, it connotes the “world in the vicinity of the station”, so the observed properties relate to the physical medium at the station, and not to any physical artifact such as a mooring, buoy, benchmark, monument, well, etc.	-	SF_SamplingFeature Sampling features are artefacts of an observational strategy, and have no significant function outside of their role in the observation process. The physical characteristics of the features themselves are of little interest, except perhaps to the manager of a sampling campaign. EXAMPLE A “station” is essentially an identifiable locality where a sensor system or procedure may be deployed and an observation made. In the context of the observation model, it connotes the “world in the vicinity of the station”, so the observed properties relate to the physical medium at the station, and not to any physical artefact such as a mooring, buoy, benchmark, monument, well, etc. NOTE A transient sampling feature, such as a ships-track or flight-line, might be identified and described, but is unlikely to be revisited exactly. A sampling feature is intended to sample some feature-of-interest in an application domain. However, in some cases the identity, and even the exact type, of the sampled feature may not be known when observations are made using the sampling features. A small number of sampling patterns are common across disciplines in observational science. These provide a basis for processing and portrayal tools which are similar across domains, and depend particularly on the geometry of the sample design. Common names for sampling features include specimen, station, profile, transect, path, swath and scene. Spatial sampling is classified primarily by the topological dimension.	saml:SamplingFeature Sampling features are artefacts of an observational strategy, and have no significant function outside of their role in the observation process. The physical characteristics of the features themselves are of little interest, except perhaps to the manager of a sampling campaign. EXAMPLE A “station” is essentially an identifiable locality where a sensor system or procedure may be deployed and an observation made. In the context of the observation model, it connotes the “world in the vicinity of the station”, so the observed properties relate to the physical medium at the station, and not to any physical artefact such as a mooring, buoy, benchmark, monument, well, etc. NOTE A transient sampling feature, such as a ships-track or flight-line, might be identified and described, but is unlikely to be revisited exactly. A sampling feature is intended to sample some feature-of-interest in an application domain, so there is an expectation of at least one sampledFeature property. However, in some cases the identity, and even the exact type, of the sampled feature may not be known when observations are made using the sampling features.
An ObservableProperty is an observable quality of a real world phenomena (thing, person, event, etc.) that is being observed.	sosa:ObservableProperty An observable Quality of a Thing; typically a FeatureOfInterest.	ssn:Property An observable Quality of an Event or Object. That is, not a quality of an abstract entity as is also allowed by DUL's Quality, but rather an aspect of an entity that is intrinsic to and cannot exist without the entity and is observable by a sensor.	GF_PropertyType The observed property shall be a phenomenon associated with the feature-of-interest. An instance of GF_PropertyType shall describe a property that is either assignable or observable (7.1.2), such as “temperature”, “height”, “colour”, “material”. A property type may be an operation or function such as a spatiotemporal coverage.	[ subclassOf owl:Class ] .
A Result is the value that has been obtained through the observation of a real world phenomena or the change of state of an entity through an actuation.	sosa:Result The Result of an Observation, Actuation, or Sampling, e.g., the value for an ObservedProperty of some FeatureOfInterest such as 20m for the height of a tree.	ssn:SensorOutput and ssn:ObservationValue [Respectively] A sensor outputs a piece of information (an observed value), the value itself being represented by an ObservationValue.[and] The value of the result of an Observation. An Observation has a result which is the output of some sensor, the result is an information object that encodes some value for a Feature.	Any the value generated by the procedure. The value has the role result with respect to the observation. The type of the result is shown as Any, since it may represent the value of any feature property. The type of the observation result shall be consistent with the observed property, and the scale or scope for the value shall be consistent with the quantity or category type.	rdfs:Resource

General coment for classess and properties (Kerry): I would much prefer that these "generic" descriptions were not so "generic". They can be more helpful and specifically refer to other terms subject only to a sensible modularity/integration architecture discussed elsewhere. So that they remain true in in the context of both modules but are also more helpful in the context of sosa.

Properties

SOSA	SSN	O&M	om-lite
sosa:hasFeatureOfInterest (inverse: sosa:isFeatureOfInterestOf) A relation between an Observation and the entity whose quality was observed. For example, in an Observation of the weight of a person, the FeatureOfInterest is the person and the quality is weight.	ssn:featureOfInterest A relation between an observation and the entity whose quality was observed. For example, in an observation of the weight of a person, the feature of interest is the person and the quality is weight.	featureOfInterest	oml:featureOfInterest Links the Observation to the Feature that is the ultimate subject of the observation and carries the observed property. This feature is the real-world object whose properties are under observation. An observation instance serves as a propertyValueProvider for its feature-of-interest.
sosa:hasResult (inverse: sosa:isResultOf) Relation linking an Observation and a Sensor or Actuator and a Result, which contains a value representing the value associated with the observed Property.	ssn:observationResult Relation linking an Observation (i.e., a description of the context, the Situation, in which the observatioin was made) and a Result, which contains a value representing the value associated with the observed Property.	result	oml:result estimate of the value of the observed property
sosa:observes (inverse: sosa:isObservedBy) Relation between a Sensor and an ObservableProperty.	ssn:observes Relation between a Sensor and a Property that the sensor can observe. Note that, given the DUL modelling of Qualities, a sensor defined with 'observes only Windspeed' technically links the sensor to particular instances of Windspeed, not to the concept itself - OWL can't express concept-concept relations, only individual-individual. The property composition ensures that if an observation is made of a particular quality then one can infer that the sensor observes that quality.	-	-
sosa:observedProperty Relation linking an Observation to the Property that was observed. The observedProperty should be a Property (hasProperty) of the FeatureOfInterest (linked by featureOfInterest) of this observation.	ssn:observedProperty Relation linking an Observation to the Property that was observed. The observedProperty should be a Property (hasProperty) of the FeatureOfInterest (linked by featureOfInterest) of this observation.	observedProperty	oml:observedProperty property whose value is the result of the observation Link from the Observation to the PropertyType for which the Observation:result provides an estimate of its value. The observed property shall be a phenomenon associated with the feature-of-interest.
sosa:usedProcedure Relation to link to a re-usable Procedure used in making an Observation or Actuation. Typically a sensor or sensor-system, algorithm, computational Process.	ssn:sensingMethodUsed A (measurement) procedure is a detailed description of a measurement according to one or more measurement principles and to a given measurement method, based on a measurement model and including any calculation to obtain a measurement result	procedure	oml:procedure re-usable procedure used in making observation. Typically a sensor or sensor-system, algorithm, computational procedure.
sosa:madeObservation Relation between a Sensor and an Observations it has made.	ssn:madeObservation (inverse: ssn:observedBy) Relation between a Sensor and Observations it has made.	-	-
sosa:hostedBy (inverse: sosa:hosts) Relation between a Sensor or Actuator and the Platform that it is mounted on or hosted by.	ssn:onPlatform (inverse: sosa:attachedSystem) Relation between a System (e.g., a Sensor) and a Platform. The relation locates the sensor relative to other described entities entities: i.e., the Sensor s1's location is Platform p1. 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).	hostedProcedure	(inverse) samfl:hostedProcedure the association links a SpatialSamplingFeature to an Observation procedure (instrument, sensor, observer or software process) deployed at it
sosa:invokes (inverse: sosa:invokedBy) Relation between an Actuator and the Actuation it has made.	-	-	-
sosa:isSampleOf (inverse: sosa:hasSample) Relation from a Sample to the FeatureOfInterest that it is intended to be representative of.	-	sampledFeature	samfl:sampledFeature A sampling feature is established in order to make observations concerning some domain feature. The relation from the SamplingFeature to the feature which the sampling feature was designed to sample. EXAMPLE A profile typically samples a water- or atmospheric-column; a well samples the water in an aquifer; a tissue specimen samples a part of an organism.
sosa:phenomenonTime The time that the Result of an Observation/Actuation applies to the FeatureOfInterest. Not necessarily the same as the result-time. May be an interval or an instant, or some other compound temporal entity.	ssn:observationSamplingTime The sampling time is the time that the result applies to the feature-of-interest. This is the time usually required for geospatial analysis of the result.	phenomenonTime	oml:phenomenonTime time at which the estimate of the property that is the result of the observation is associated with the feature of interest
sosa:resultTime The result time is the time when the Observation or Actuation act was completed.	ssn:observationResultTime The result time is the time when the procedure associated with the observation act was applied.	resultTime	oml:resultTime time at which the result became available, after all processing steps were completed samfl:samplingTime time when the specimen was retrieved from the sampled feature
sosa:hasValue The value of a Result, e.g., 23 or true.	ssn:observationResult o ssn:hasValue	-	-

Simon Cox (talk) 07:08, 16 November 2016 (UTC)

Visualisation of mappings

- NEED TO DOUBLE CLICK TO ENLARGE THE IMAGES (SVG) -

Credits: owl2diagram originally developed by David Ratcliffe https://github.com/dratc/owl2diagram, modified and integrated into ontology documentation tool by Laurent Lefort (including repairing stratgeies similar to what is presented in the paper by N. Matentzoglu and B. Parsia OWL Full/DL gap in the field http://ceur-ws.org/Vol-1265/owled2014_submission_9.pdf

Visualisation of mappings using the subClassOf mappings supplied by Simon (SOSA, SSN, SSNX, OML, SAMFL, DUL)

SOSA (with meta properties ported into RDFS/OWL

SSN and tentative SSN-SOSA alignment by Simon https://lists.w3.org/Archives/Public/public-sdw-wg/2017Jan/0112.html

Also added the other alignment to facilitate the comparison between the two options.

SSNX OML OM-Lite SAMFL-Lite

- not including samfl:samplingTime alignment added by Simon after (or at the same time) I did the new version.

Visualisation of mappings using the owl:equivalentClass and owl:equivalentProperty mappings (SOSA - SSN - SSNX - DUL - OML - SAMFL)

Note: this is subject to change as we cannot discuss without knowing what what is currently proposed looks like and identify what's different / new New version with corrections to SOSA (rdfs:domain and rdfs:range axioms using owl:unionOf for the "meta" properties)

File:Mappings.ttl

SSN

SOSA (with meta properties ported into RDFS/OWL) and equivalence mapping

SSNX OML OM-Lite SAMFL-Lite DUL

--Laurent Lefort (talk) 09:55, 24 January 2017 (UTC)