SOSA Ontology

Following the suggestion Proposals_for_rewriting_SSN#Proposal_5_made_by_KJanowicz Armin, Simon and Jano have generated a proposal, called Sensor-Observation-Sampling-Actuator ontology or SOSA.

This was also inspired by some preliminary work Armin and Simon did called SANDA.

RDF files

The RDF files are in a GitHub.

There are six files as follows:

• sosa-core has base classes and properties, which can be used directly for lightweight applications, or provide the basis for additional specialization and axiomatization in vertical and horizontal extensions
• sosa-om adds the rest of om-lite with most of its semantics on top of sosa-core
• sosa-sam adds sam-lite semantics on top of sosa-core in similar fashion
• sosa-sn is a skeleton for the sensing devices, platforms, etc concerns of SSN, built on top of sosa-core. Very incomplete - a lot of work needed here to complete the SSN semantics
• sosa-prov is a preliminary alignment to PROV-O
• sosa-bfo is a preliminary alignment to BFO

Dependencies

The dependencies are approximately as shown here:

Compare with SSN, O&M, om-lite

See Mapping Table for a comparison of SOSA with the precedent models and ontologies.

Design choices

1. sosa-core has a lot of annotation but minimal formal semantics. The set of properties includes many of the relationships that can exist between the classes. The links to the classes are indicated using schema.org meta:domainIncludes, meta:rangeIncludes which are strictly only annotations i.e. with no entailments, but are expected to be useful for developers. Inverse properties are provided where they make sense, in order to enable various data representations using a common terminology, and owl:inverseOf properties are included to link these together - see discussion. Currently there are no sub-class relationships.
2. sosa-sn is very incomplete. I just moved some of the resources that were in SANDA core out of the sosa-core. I didn't do any more alignment with SSN
3. currently a new namespace is used for each file/graph. This may not be necessary or desirable.
4. sosa-prov and sosa-bfo have no new resources, just a few rdfs:subClassOf and rdfs:subPropertyOf axioms. Probably a lot more could be done here

Classes

See SOSA-core in Turtle

• Actuation - An Actuation carries out an (actuation) Procedure to change the state of the world via an Actuator
• Actuator - A device that is used by, or implements, an (actuating) Procedure. Actuators change the state of the world
• 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.
• Procedure - A workflow, protocol, plan, algorithm, or computational method specifying how to set up an Observation, take 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. Put differently, millions of observations may be created via the same Procedure the same way as millions of tables are assembled using the same instructions (as information objects, not their concrete realization).
• 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.
• 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 generates a Result. Sensors can be mounted on platforms, e.g., a modern smart phone hosts multiple sensors
• 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, said height is the ObservedProperty, 20m may be the Result of the Observation, and the tree is the FeatureOfInterest.
• ObservableProperty - An observable Quality of a thing; typically a FeatureOfInterest.
• 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 physical characteristics of the features themselves are usually of little interest, except perhaps to the manager of a sampling campaign.
• Result - The result of an observation, actuation, or sampling, e.g., the value for on observed property of some feature of interest such as 20m for the height of a tree.

Properties

See SOSA-core in Turtle

• hasFeatureOfInterest - 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.
• hasResult - Relation linking an Observation and a Sensor or Actuator and a Result, which contains a value representing the value associated with the observed Property.
• hasSample - Relation between a FeatureOfInterest and the Sample used to represent it.
• hasValue - The value of a Result, e.g., 23 or true.
• hostedBy - Relation between a Sensor or Actuator and the Platform that it is mounted on or hosted by.
• hosts - Relation between a Platform and a Sensor or Actuator (or SamplingDevice) hosted or mounted on it.
• isFeatureOfInterestOf - A relation between a FeatureOfInterest and an Observation about it.
• isObservedBy - Relation between an ObservableProperty and the Sensor able to observe it.
• isResultOf - Relation linking a Result to the Observation that created it.
• isSampleOf - Relation from a Sample to the FeatureOfInterest that it is intended to be representative of.
• madeObservation - Relation between a Sensor and an Observations it has made.
• 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.
• observes - Relation between a Sensor and an ObservableProperty.
• phenomenonTime - The time that the Result of an Observation/Actuation applies to the FeatureOfInterest - not necessarily the same as the result-time.
• resultTime - The result time is the time when the Observation/Actuation act was completed.
• usedProcedure - Link to a re-usable Procedure used in making Observation or Actuation. Typically a sensor or sensor-system, algorithm, computational procedure.

Why not WebProtege?

Because WP is very difficult to use. Armin and I struggled with various issues for a days, and decided to give up - sorry. The RDF files (Turtle format) are in GitHub so anyone who wants to work on this can get them there. I find that the Turtle serialization generated from TopBraid is very consistent, allowing changes to be tracked relatively easily.

Simon Cox (talk) 00:05, 5 July 2016 (UTC)

Simon Cox (talk) 23:57, 9 August 2016 (UTC)