the modular ssn ontology: a joint w3c and ogc standard ... · situ observation scenarios alongside...
TRANSCRIPT
-
0 Semantic Web - (2018) 0–24IOS Press
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
25 25
26 26
27 27
28 28
29 29
30 30
31 31
32 32
33 33
34 34
35 35
36 36
37 37
38 38
39 39
40 40
41 41
42 42
43 43
44 44
45 45
46 46
47 47
48 48
49 49
50 50
51 51
The Modular SSN Ontology: A Joint W3Cand OGC Standard Specifying the Semanticsof Sensors, Observations, Sampling, andActuationArmin Haller a,*, Krzysztof Janowicz b, Simon J D Cox c, Maxime Lefrançois d, Kerry Taylor a,Danh Le Phuoc e, Joshua Lieberman f, Raúl García-Castro g, Rob Atkinson h, and Claus Stadler ia Research School of Computer Science, Australian National University, Canberra, AustraliaE-mails: [email protected], [email protected] Geography Department, University of California, Santa Barbara, CA, USAE-mail: [email protected] Land and Water, CSIRO, Melbourne, AustraliaE-mail: [email protected] Univ Lyon, MINES Saint-Étienne, CNRS, Laboratoire Hubert Curien UMR 5516, Saint-Étienne, FranceE-mail: [email protected] Open Distributed Systems, Technische Universität Berlin, GermanyE-mail: [email protected] Center for Geographic Analysis, Harvard University, Boston, MA, USAE-mail: [email protected] Ontology Engineering Group, Universidad Politécnica de Madrid, Madrid, SpainE-mail: [email protected] Metalinkage, Wollongong, AustraliaE-mail: [email protected] Institut für Informatik, Universität Leipzig, Leipzig, GermanyE-mail: [email protected]
Editor: Pascal Hitzler, Wright State University, USASolicited reviews: Eva Blomqvist, Linköping University, Sweden; Alessandro Oltramari, Bosch Research and Technology Center, USA;Freddy Lecue, Accenture Tech Labs Ireland, and INRIA, France
Abstract. The joint W3C (World Wide Web Consortium) and OGC (Open Geospatial Consortium) Spatial Data on the Web(SDW) Working Group developed a set of ontologies to describe sensors, actuators, samplers as well as their observations,actuation, and sampling activities. The ontologies have been published both as a W3C recommendation and as an OGC im-plementation standard. The set includes a lightweight core module called SOSA (Sensor, Observation, Sampler, and Actuator)available at: http://www.w3.org/ns/sosa/, and a more expressive extension module called SSN (Semantic Sensor Network) avail-able at: http://www.w3.org/ns/ssn/. Together they describe systems of sensors and actuators, observations, the used procedures,the subjects and their properties being observed or acted upon, samples and the process of sampling, and so forth. The set ofontologies adopts a modular architecture with SOSA as a self-contained core that is extended by SSN and other modules toadd expressivity and breadth. The SOSA/SSN ontologies are able to support a wide range of applications and use cases, includ-ing satellite imagery, large-scale scientific monitoring, industrial and household infrastructures, social sensing, citizen science,observation-driven ontology engineering, and the Internet of Things. In this paper we give an overview of the ontologies anddiscuss the rationale behind key design decisions, reporting on the differences between the new SSN ontology presented here andits predecessor [9] developed by the W3C Semantic Sensor Network Incubator group (the SSN-XG). We present usage examplesand describe alignment modules that foster interoperability with other ontologies.
Keywords: Ontology, Sensor, Actuator, Observation, Actuation, Sampling, Linked Data, Web of Things, Internet of Things
1570-0844/18/$35.00 c© 2018 – IOS Press and the authors. All rights reserved
mailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]://www.w3.org/ns/sosa/http://www.w3.org/ns/ssn/
-
A. Haller et al. / The Modular SSN Ontology: A Joint W3C and OGC Standard 1
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
25 25
26 26
27 27
28 28
29 29
30 30
31 31
32 32
33 33
34 34
35 35
36 36
37 37
38 38
39 39
40 40
41 41
42 42
43 43
44 44
45 45
46 46
47 47
48 48
49 49
50 50
51 51
1. Introduction
Sensors are a major source of data available on theWeb today. The trend towards making cities, offices,and homes ‘smarter’ by turning them into sensor-richenvironments [31] drives the demand for specificationsthat describe how to model and publish sensor and ac-tuator data as well as how to foster interoperabilityacross platforms on the Web or other data infrastruc-tures.
Sensor readings are often provided only as raw nu-meric values, but any searching, reusing, integrating,or interpreting of these data requires more than just theobservation results. Of equal importance for the properinterpretation of these values is contextual informationabout the studied feature of interest, such as a river,the observed property, such as flow velocity, the uti-lized sampling strategy, such as the specific locationsor sampling stations and times at which the velocitywas measured, the procedures followed to produce aresult, and a variety of other information.
The Open Geospatial Consortium’s (OGC) SensorWeb Enablement (SWE) standards [6, 26, 49] providea framework for describing sensors and observations,as well as encodings for their data and service inter-faces for interacting with them. SWE implementationsfollowed the style of other OGC standards, relying onweb-hosted service calls and XML payloads, whichhave limited compatibility with the more recent andwidely used web platforms.
A W3C Incubator Group was created in 2009 withthe goal, among others, of defining an OWL ontol-ogy that would, to some degree, reflect the SWE stan-dards. That group produced the original Semantic Sen-sor Network ontology (SSNX1) [9, 36]. SSNX was de-signed to be consistent with W3C endorsed best prac-tices on publishing data on the Web, which recommenda Linked Data approach, allowing sensor data, for ex-ample, to be published as part of a global and denselyinterconnected graph of data [42]. The SSNX ontologyhas been the basis for many subsequent research ini-tiatives and some operational deployments. However,users of the original ontology have identified a num-ber of potential points of improvement, inconsistencieswith related vocabularies such as the Ontology of unitsof Measure (O&M) [12, 49], as well as extensions to
*Corresponding author. E-mail: [email protected] this paper SSNX will denote the 2011 version of the ontology
produced by the W3C Incubator, with SSN used for the new versionstandardized through W3C/OGC and described here.
cover new aspects of sensing that have become morerelevant, such as actuation, a key element of the Inter-net of Things (IoT).
Four years after the publication of the first version,work started on an update and formal standardizationof the SSNX ontology, this time jointly led by the W3Cand the OGC, to address the feedback gathered on theusage of the ontology and lessons learned. This ac-tivity resulted in the publication of the new SemanticSensor Network (SSN) modular ontology, designed toprovide a flexible but coherent perspective for repre-senting the entities, relations, and activities involved insensing, sampling, and actuation [22]. The main inno-vation of this formal standard version of SSN is theseparation of SSN into ontology modules, the centralof which is the Sensor, Observation, Sample, and Ac-tuator (SOSA) ontology, providing a lightweight corefor SSN. SOSA aims to broaden the target audienceand application areas that can make use of SemanticWeb ontologies. Other SSN modules add additionalterms, introduce additional ontological commitments,and/or clarify and support the alignment of SSN withother ontologies.
This paper does not aim at providing an exhaus-tive description of the SSN ontology, since that can befound in the specification [22], but to motivate the de-velopment decisions and the design patterns followedwhile indicating the most substantial changes madesince the initial release of the ontology. Throughoutthis paper we will introduce concepts from SSN (andSOSA) in detail, supported by examples of its use ina smart home case study. As will be detailed below,SOSA [30] is a self-contained pattern designed forreuse and to meet the demands of a larger, schema.org-style target audience. Hence, SOSA is only introducedhere to a degree necessary to understand its relationto SSN and because SSN imports and extends SOSAclasses and relations.
The remainder of the paper is structured as follows.Sec. 2 briefly reviews the origins of the SSN ontol-ogy. Sec. 3 explains the rationale behind the mainchanges to the core of SSN, with observations mod-eled as events alongside the related sampling and actu-ation activities which are introduced as well. The over-all modular structure of the SSN ontology is describedin Sec. 4. A general description of the new, simplifiedSSN ontology is provided in Sec. 5, along with ex-amples and explanations for the changes from SSNX.Sec. 6 and 7 describe the horizontal and vertical on-tology modules that SSN imports or that are importedby SSN, respectively. We provide an overview of what
mailto:[email protected]
-
2 A. Haller et al. / The Modular SSN Ontology: A Joint W3C and OGC Standard
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
25 25
26 26
27 27
28 28
29 29
30 30
31 31
32 32
33 33
34 34
35 35
36 36
37 37
38 38
39 39
40 40
41 41
42 42
43 43
44 44
45 45
46 46
47 47
48 48
49 49
50 50
51 51
SSN is not intended to model in Sec. 8, and reportin Sec. 9 on implementation evidence for SSN, whichwas crucial for it to become an OGC/W3C standard.
2. Original SSN and Antecedents
The development of SSN and SOSA has beenstrongly influenced by the SSNX ontology [36] andmodels from the OGC’s Sensor Web Enablement ini-tiative (SWE) [5].
Starting in 2002 SWE developed a generic frame-work for delivering sensor data. The Sensor Observa-tion Service defines a HTTP query interface for sen-sor and observation data [8], following the pattern suc-cessfully established by OGC starting with the WebMap Service [16]. Returned data conforms with theSensor Model Language (SensorML) [6] and with theXML implementation of O&M [12, 49]. SensorMLand O&M provide complementary viewpoints. Sen-sorML is ‘provider-centric’ and encodes details of thesensor along with a stream of (typically) raw observa-tion data. In contrast, O&M was designed to be more‘user-centric’, with the target of the observation andthe observed property as first-class objects.
A key aspect of the O&M model is that it separatelydefined classes for the description of the observationevent, the real world feature of interest being observed,and the platform, procedure and/or system responsi-ble for the observation. Geometries or other spatiallocation properties can be attached separately to fea-tures of interest, observations, platforms, and sensors,so the model can accommodate remote sensing and ex-situ observation scenarios alongside in-situ monitoring[32, §5.16][13, 26]. O&M also includes a model forsampling, since most practical observations are madeon a subset of, or proxy for, the ultimate feature of in-terest.
O&M is only one of several similar conceptualmodels for observations and their results. A selectionof these, also including OBOE [43], Sensei [2] andSeronto [55], were reviewed by the W3C SemanticSensor Network Incubator Group, and guided the de-velopment of the SSNX ontology [36].
The SSNX ontology was ultimately built around afundamental conceptual model implemented as an on-tology design pattern called the Stimulus Sensor Ob-servation (SSO) pattern [29] that was aligned to theDolce-Ultralite upper ontology (DUL) [45]. SSO wasintended to provide a minimal common ground for on-tologies for the use on the Semantic Sensor Web.
Drawing on considerable implementation and appli-cation experience with SSNX, as well as with sensorand observation models and ontologies more broadly,the new SSN ontology presented here is set out to ad-dress changes in scope and audience, new technical de-velopments and shortcomings of the initial work.
One such significant change in the extent of the au-dience of SSN has been the emergence of lightweightvocabularies such as schema.org and their increasinguse on the Web [20] since SSNX had been published. Itled to a requirement to provide a lightweight ontologywith minimal ontological commitment [32, §5.22], theSOSA core, that can be used by Web developers to an-notate their IoT APIs using simple serialization for-mats such as JSON-LD, Microdata or RDFa 1.1 with-out the need to import any other ontology, includingupper level ontologies (as required by SSNX).
New technical developments included particularlythe emergence of complex actuation devices on theWeb of Things, such as home automation devices likeGoogle Nest, personal assistants like Amazon Echo,Apple Siri or Microsoft Cortana and personal cameradrones. To be able to model the smart instrumentationof these devices and the environments they operate inmore generally, the actuator and actuation perspectivehas been added to SSN.
The sections below highlights these significantchanges and some of the other changes in the newSOSA/SSN ontology.
3. Observation, Sampling and Actuation events
Following the working group’s Use Cases and Re-quirements analysis [32], the scope of the revised on-tology has first been reduced by removing the con-cepts for stimulus, systems, measurement and systemcapabilities from the core (either for reasons of lack ofimplementation evidence or in response to a require-ment [32, §5.47]), then expanded beyond sensors andtheir observations by including classes and propertiesfor the closely linked concepts of actuation [32, §5.16]and sampling [32, §5.16].
Figure 1 provides an overview of the classes andproperties in the core of the SSN ontology, showinghow the three applications use the same pattern.
3.1. Sensors and Observations
The core of the SSNX ontology placed the sensorstimulus as the critical ’event’ in the observation pro-
-
A. Haller et al. / The Modular SSN Ontology: A Joint W3C and OGC Standard 3
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
25 25
26 26
27 27
28 28
29 29
30 30
31 31
32 32
33 33
34 34
35 35
36 36
37 37
38 38
39 39
40 40
41 41
42 42
43 43
44 44
45 45
46 46
47 47
48 48
49 49
50 50
51 51
Procedure
observesforProperty
madeBySensormadeBySamplermadeByActuator
hasFeatureOfInterest
observedPropertyactsOnPropoerty
usedProcedure
FeatureOfInterest
Figure 1
time:TemporalEntityphenomenonTime
xsd:dateTimeresultTime isFeatureOfInterestOf
madeObservationmadeSamplingmadeActuation
isObservedBy
hasResulthasSimpleResult
rdfs:Literal
isResultOf
implements implementedBy ActuatorSampler
Sensor
ActuatablePropertyObservableProperty
ActuationSampling
Observation
Result
Sample
isSampleOf
hasSample
hasProperty
isPropertyOf
Fig. 1. Overview of the core structure of the SSN ontology, emphasizing the common patterns used by the three activities with classes stackedwhere they play a similar role. The elements shown are from both SOSA and SSN modules, with classes and types from external vocabulariesindicated with a namespace prefix and uncolored. Classes and properties in blue relate to observations, red to sampling, and green to actuation,and classes in yellow are used across all three applications. A full set of inverse properties are defined in the ontology, but only a subset areshown in this figure.
cess. Observations have therefore been modelled as asocial construct (oldssn:Observation v dul:Situation),i.e. observations were contexts for interpreting incom-ing stimuli and fixing parameters such as time andlocation. While this is sound conceptual modeling,in practice the stimulus class was rarely instantiated.This is because a stimulus triggers the sensor to per-form an observation, and, thus, resides outside thescope of typical sensor and observation applicationsand use cases. In subsequent work focusing on thealignment of SSNX with the W3C Provenance ontol-ogy [34] the absence of a class representing an ob-servation as an ’act of sensing’ was noted [10, 14].The revised model focuses on the complete observa-tion as an event (sosa:Observation v dul:Event), com-pleted when the result is available, i.e. acts of carry-ing out an (observation) procedure in order to esti-mate or calculate a value of a sosa:ObservablePropertyof a sosa:FeatureOfInterest or a sosa:Sample thereof.This modelling is aligned with other standardontologies such as the OGC Observations andMeasurements [13, 26] (i.e. sosa:Observation ≡so19156-om:OM_Observation) and the PROVOntology (i.e. sosa:Observationv prov:Activity) whereentities (i.e. sosa:Sensors in SSN) perform activities(i.e. sosa:Observations in SSN). The new model isalso in line with the view of most practitioners, e.g.,
the event-oriented O&M pattern used in INSPIRE im-plementations2. Furthermore, it provides a pattern andterminology that can be used analogically for samplingand actuation activities.
In the process of separating SSN from DUL, alsothe semantics of the sosa:Sensor class has been recon-sidered. SSNX has been criticized for its partially in-consistent handling of virtual sensors (including soft-ware and simulations) and related classes and proper-ties. In particular, the comment in the oldssn:Sensorclass suggested that a sensor can also be “computa-tional methods, a laboratory setup with a person fol-lowing a method, or any other thing that can followa Sensing Method to observe a Property”. However,the oldssn:Sensor class was defined as a subclcassof dul:PhysicalObject, making the comment inconsis-tent with the class definition. SOSA/SSN addressesthis issue (and requirement §5.19 [32]) by allowingall major classes to be virtual, allowing humans andother animals as agents that perform observations, ac-tuation, or sampling activities. In the optional align-ment to DUL, sosa:Sensors, but also sosa:Platforms,and ssn:Systems are now defined as a subclass of thehigher-level dul:Object class rather than the more spe-cific dul:PhysicalObject class.
2https://inspire.ec.europa.eu/id/document/tg/d2.9-o%26m-swe
http://purl.oclc.org/NET/ssnx/ssn#Observationhttp://www.ontologydesignpatterns.org/ont/dul/DUL.owl#Situationhttp://www.w3.org/ns/sosa/Observationhttp://www.ontologydesignpatterns.org/ont/dul/DUL.owl#Eventhttp://www.w3.org/ns/sosa/ObservablePropertyhttp://www.w3.org/ns/sosa/FeatureOfInteresthttp://www.w3.org/ns/sosa/Samplehttp://www.w3.org/ns/sosa/Observationhttp://www.w3.org/ns/sosa/Observationhttp://www.w3.org/ns/prov#Activityhttp://www.w3.org/ns/sosa/Sensorshttp://www.w3.org/ns/sosa/Observationshttp://www.w3.org/ns/sosa/Sensorhttp://purl.oclc.org/NET/ssnx/ssn#Sensorhttp://purl.oclc.org/NET/ssnx/ssn#Sensorhttp://www.ontologydesignpatterns.org/ont/dul/DUL.owl#PhysicalObjecthttp://www.w3.org/ns/sosa/Sensorshttp://www.w3.org/ns/sosa/Platformshttp://www.w3.org/ns/ssn/Systemshttp://www.ontologydesignpatterns.org/ont/dul/DUL.owl#Objecthttp://www.ontologydesignpatterns.org/ont/dul/DUL.owl#PhysicalObjecthttps://inspire.ec.europa.eu/id/document/tg/d2.9-o%26m-swe
-
4 A. Haller et al. / The Modular SSN Ontology: A Joint W3C and OGC Standard
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
25 25
26 26
27 27
28 28
29 29
30 30
31 31
32 32
33 33
34 34
35 35
36 36
37 37
38 38
39 39
40 40
41 41
42 42
43 43
44 44
45 45
46 46
47 47
48 48
49 49
50 50
51 51
The SOSA pattern models sosa:Sensors as en-tities that make sosa:Observations about somesosa:ObservableProperty of a sosa:FeatureOfInterest.From the viewpoint of foundational ontologies suchas DOLCE [18], endurants participate in perdurants.Consequently, the sensors, features of interest, sam-ples, and so forth participate in the observation event indifferent roles. For instance, a sensor (typically) trans-forms a stimulus into a result thereby also setting thetemporal bounds (start and end) of an observation. Thefeature of interest is the bearer of the property un-der consideration, and so on. To improve readabilityand to stay in line with the literature about sensorsand observations we will say that a sensor triggered,initiated, performed, or took, an observation about aproperty of some feature instead of speaking about en-durants and their participation in perdurants. Finally, itis also important to differentiate between the concep-tual model of an observation as an event and the datamodels and data structures used to represent such anobservation as a record in a database, e.g., as servedby a semantically-enabled Sensor Observation Service(SOS) [24, 28].
Throughout the paper we will use an exemplarysmart house that has been modelled using the SSN on-tology. Fig. 2 gives an overview of the SOSA/SSN in-stances3 that we will refer to in the listings throughoutthe paper.
Listing 3.1 uses SOSA/SSN to describe an observa-tion of the electric consumption in the kitchen of ourexemplary smart house #134 made by sensor #927.
Listing 3.1: Observation Modelling
@prefix cdt: .
BASE a sosa:Observation ;sosa:hasFeatureOfInterest ;sosa:observedProperty ;sosa:madeBySensor ;sosa:hasSimpleResult "22.4 kWh"^^cdt:ucum .
As a result of replacing the SSO pattern from SSNXby SOSA in SSN, the oldssn:Sensing4 class has beenreplaced by the sosa:Procedure class, which has a
3The complete ontology file for the example is avail-able at: https://github.com/w3c/sdw/blob/gh-pages/ssn/integrated/examples/house134.ttl
4The following prefixes are used in the text - sosa: for SOSA;ssn: for SSN; and oldssn: for the old SSNX ontology which de-fined resources in the namespace http://purl.oclc.org/NET/ssnx/ssn#
more generic definition that allows it to be used for actsof observation, sampling or actuation (see Sec. 5.3).
3.2. Samplers and Sampling
Almost all observations make use of samplingstrategies to connect an observation event with its ul-timate feature of interest, even if the sample and sam-pling event are not explicitly described. Nevertheless,support for explicit modelling of samples and sam-pling is sometimes a design requirement, particularlyin scientific applications. The SOSA ontology includessosa:Sampler that makes a sosa:Sampling of somesosa:FeatureOfInterest to produce a sosa:Sample. Asosa:Sample is both a sosa:FeatureOfInterest and asosa:Result of sosa:Sampling.
For example, Listing 3.2 describes an act of sam-pling using a spade to obtain a soil sample from thegarden of our example house #134.
Listing 3.2: Sampling Modelling
@prefix geow3c: .
a sosa:Sampling ;geow3c:lat "-37.9076" ;geow3c:long "145.0294" ;sosa:madeBySampler ;sosa:hasFeatureOfInterest ;sosa:resultTime"2017-12-04T08:14:00:00+10:00"^^xsd:dateTime ;
sosa:hasResult .
The result of this act of sampling is a sosa:Sampleas exemplified in Listing 3.3.
Listing 3.3: Result Sample Modelling
a sosa:Sample ;sosa:isSampleOf ;sosa:isResultOf .
The relationship sosa:isSampleOf (inverse:sosa:hasSample) defines the link between a sampleand the feature of interest that it represents, and is theessential property of a sample that allows observationof a sample to lead in turn to an observed property ofthe feature of interest.
For example, Listing 3.4 asserts that the kitchen andthe bedroom, which are both features of interest intheir own right, serve also as samples of our home.They might be used in observations to approximatesome global property of the house, such as its temper-ature.
http://www.w3.org/ns/sosa/Sensorshttp://www.w3.org/ns/sosa/Observationshttp://www.w3.org/ns/sosa/ObservablePropertyhttp://www.w3.org/ns/sosa/FeatureOfInteresthttp://purl.oclc.org/NET/ssnx/ssn#Sensinghttp://www.w3.org/ns/sosa/Procedurehttps://github.com/w3c/sdw/blob/gh-pages/ssn/integrated/examples/house134.ttlhttps://github.com/w3c/sdw/blob/gh-pages/ssn/integrated/examples/house134.ttlhttp://purl.oclc.org/NET/ssnx/ssn##http://www.w3.org/ns/sosa/Samplerhttp://www.w3.org/ns/sosa/Samplinghttp://www.w3.org/ns/sosa/FeatureOfInteresthttp://www.w3.org/ns/sosa/Samplehttp://www.w3.org/ns/sosa/Samplehttp://www.w3.org/ns/sosa/FeatureOfInteresthttp://www.w3.org/ns/sosa/Resulthttp://www.w3.org/ns/sosa/Samplinghttp://www.w3.org/ns/sosa/Samplehttp://www.w3.org/ns/sosa/isSampleOfhttp://www.w3.org/ns/sosa/hasSample
-
A. Haller et al. / The Modular SSN Ontology: A Joint W3C and OGC Standard 5
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
25 25
26 26
27 27
28 28
29 29
30 30
31 31
32 32
33 33
34 34
35 35
36 36
37 37
38 38
39 39
40 40
41 41
42 42
43 43
44 44
45 45
46 46
47 47
48 48
49 49
50 50
51 51
sampling/4650
sosa:FeatureOfInterest
house/134
sosa:Sample
sosa:Platform
house/134/bedroom
house/134/kitchen
ssn:System
PCBBoard2
PCBBoard1
sosa:hosts
ssn:Deployment
house/134/deployment
ssn:deployedSystem
ssn:deployedOnPlatformsosa:Sensor
DHT22/2
DHT22/1
sosa:hosts
floralCouch
roofInsulation
window/104#state sosa:ActuatableProperty
actuation/188
sosa:isActedOnBy
window/104
ssn:hasPropertynest/D1AA22A8211
sosa:hosts
airTemperature
sosa:Observation
ssn:forProperty
sensor/926
summingHourlyConsumptionProcedure
ssn:implements
electricityConsumption
sosa:Procedure
ssn:hasOutput
sosa:hasFeatureOfInterest
2017-04-16T00:00:12+00:00
sosa:resultTime
_:b1
sosa:phenomenonTime
2017-11-15T14:35:13Z
sosa:resultTime
23.9 DEG
sosa:hasSimpleResult
_:b2
sosa:hasResult
sosa:hasFeatureOfInterest
electricConsumption
sosa:observedProperty
22.4 kWh
Observation/235727/result
sosa:madeBySensor
sosa:hasResult
sosa:hasSimpleResult
sosa:madeBySensor
sosa:observedProperty
sosa:observessensor/927
sosa:observesobservation/235728
observation/235716
observation/235715
observation/235714
sosa:observes
observation/235727
sosa:isSampleOf
sosa:hosts
sosa:hosts
sosa:Observation
observation/s1/5
sample/134g1
soil-pHsosa:Observation
sosa:observedProperty
sampling/4578
sosa:Sampling
trowel
sosa:madeBySampler
house/134/garden
sosa:isSampleOf
sosa:hasResult
sosa:hasFeatureOfInterest
sosa:isSampleOf
sosa:hasFeatureOfInterest
procedure/soil-organic-fraction/78
sosa:Procedure
sosa:usedProcedure
sosa:Actuator
windowCloser/987
sosa:madeActuation
ssn:forProperty
sosa:hasFeatureOfInterest
ssn:deployedSystem
Fig. 2. Example smart house modelled using SOSA/SSN. Black boxes indicate SOSA/SSN classes, dashed boxes indicate class instances, solidlines represent rdf:type relations and dashed lines instances of properties.
Listing 3.4: Sample Modelling
a sosa:FeatureOfInterest ;
a sosa:FeatureOfInterest ,sosa:Sample ;
sosa:isSampleOf .
a sosa:FeatureOfInterest ,sosa:Sample ;
sosa:isSampleOf .
3.3. Actuators and Actuations
As outlined above, there is an increasing im-portance of the Web of Things and smart instru-mentation and environments more generally. Re-quirements for SSN included one to model ac-tuations (“It should be possible to model actu-ation functions of sensing devices” [32, §5.27]).An actuation denotes a devices’ ability to changesomething in its environment upon receiving asignal. The SOSA ontology pattern is thereforeextended to model sosa:Actuators, making some
sosa:Actuations on some sosa:ActuatableProperty of asosa:FeatureOfInterest.
For example, Listing 3.5 describes how actuation#188 has been made by actuator windowCloser #987to act on the state of window #104.
Listing 3.5: Actuation Modelling
a sosa:Actuation ;sosa:actsOnProperty ;sosa:actuationMadeBy ;sosa:resultTime"2017-04-18T17:24:00+02:00"^^xsd:dateTimeStamp.
3.4. Spatial aspects
Spatial aspects of an observation, act of sam-pling or actuation can be associated with thesosa:FeatureOfInterest, the ssn:System (i.e. thesosa:Sensor, sosa:Sampler or sosa:Actuator) and/orthe sosa:Platform on which they are mounted. Loca-tion may also constitute a sosa:ObservablePropertyof an observation, for example using a GPS sensor.
http://www.w3.org/ns/sosa/Actuatorshttp://www.w3.org/ns/sosa/Actuationshttp://www.w3.org/ns/sosa/ActuatablePropertyhttp://www.w3.org/ns/sosa/FeatureOfInteresthttp://www.w3.org/ns/sosa/FeatureOfInteresthttp://www.w3.org/ns/ssn/Systemhttp://www.w3.org/ns/sosa/Sensorhttp://www.w3.org/ns/sosa/Samplerhttp://www.w3.org/ns/sosa/Actuatorhttp://www.w3.org/ns/sosa/Platformhttp://www.w3.org/ns/sosa/ObservableProperty
-
6 A. Haller et al. / The Modular SSN Ontology: A Joint W3C and OGC Standard
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
25 25
26 26
27 27
28 28
29 29
30 30
31 31
32 32
33 33
34 34
35 35
36 36
37 37
38 38
39 39
40 40
41 41
42 42
43 43
44 44
45 45
46 46
47 47
48 48
49 49
50 50
51 51
Location and other spatial properties of these entitiesmay also be defined according to application- orcommunity-specific models, which in turn makeuse of appropriate geospatial ontologies such asGeoSPARQL [47].
4. Modularization
Practitioners using the SSNX ontology have identi-fied the complexity of both the ontology and its doc-umentation as a significant usability issue. For exam-ple, SSNX imported the Dolce-Ultralite upper ontol-ogy (DUL) [45] and many SSNX terms inherited se-mantics from their parent DUL terms. The DUL align-ment contributed a level of complexity and abstractionwhich affected adoption in some communities. Moregenerally, the monolithic ontology design of SSNXthat introduces all terms within one ontology whilealso relying on the import of the Dolce-UltraLite on-tology, makes it difficult for users to focus on just thoseentities needed for a particular implementation. In re-sponse to this, the new SSN ontology is factored intoseveral ontology subsets or modules that are similar intheir domain of discourse and directly import one an-other as needed but differ in their ontological commit-ments and/or scope of coverage in order to suit differ-ent use cases and target audiences. The core module inparticular, SOSA, is intended for data repositories andwebsites managed by web or data managers who needneither extensive axiomitization nor more specializedentities.
Modularization has been accomplished by way oftwo types or directions of ontology segmentation asshown in Fig. 3.
4.1. Vertical Segmentation
Vertically segmented SSN modules add higher lev-els of ontological commitment by directly import-ing lower modules and defining new axioms. Thelower level modules are independent of the higherlevel modules, and logically consistent by them-selves. The core SOSA module defines the keyclasses and properties but axiomatization is delib-erately limited. In particular, SOSA uses no ob-ject property rdfs:domain or rdfs:range axioms. Inplace of these, schema.org schema:domainIncludesand schema:rangeIncludes annotations provide infor-
Fig. 3. SOSA/SSN ontologies "vertical" and "horizontal" modular-ization. Horizontal breadth of coverage is shown by arcuate mod-ules at the same radius. Vertical height of expressivity is shown bymodules at a larger radius
mal semantics to SOSA properties.5 SOSA also avoidsany subclass and subproperty axioms. The motivationfor these choices is to make SOSA simple enough to beincorporated as is in the schema.org extension for IoT.6
SOSA as the core, does not import any other ontolo-gies, so is truly independent of vertical modules thatadd more terms, expressivity, and further ontologicalcommitments to the lightweight semantics of SOSA.
The SSN module imports SOSA, and adds fullaxiomatization to the SOSA classes and proper-ties, including rdfs:subClassOf, rdfs:subPropertyOf,owl:disjointWith and OWL cardinality and guarded ex-istential restrictions on a class-level, along with somefurther classes and properties to complete the basicconceptual model corresponding approximately to thescope offered by SSNX.
In line with the changes implemented for the newSSN, alignment between SSN terms and DUL termswas reconsidered and externalized to an optional verti-cal module called the Dolce-Ultralite Alignment mod-ule (SSN-DUL) that is available at http://www.w3.org/ns/ssn/dul. Those axioms in SSN that include DULterms have been separated into the SSN-DUL mod-
5See https://www.w3.org/2015/spatial/wiki/Domain,_Range,_InverseOf for pointers to the group discussions on this topic.
6The Spatial Data on the Web group endorses SOSA being takenup by schema.org, see thread https://lists.w3.org/Archives/Public/public-sdw-wg/2017Jun/0067.html
http://www.w3.org/2000/01/rdf-schema#domainhttp://www.w3.org/2000/01/rdf-schema#rangehttp://schema.org/domainIncludeshttp://schema.org/rangeIncludeshttp://www.w3.org/2000/01/rdf-schema#subClassOfhttp://www.w3.org/2000/01/rdf-schema#subPropertyOfhttp://www.w3.org/2002/07/owl#disjointWithhttp://www.w3.org/ns/ssn/dulhttp://www.w3.org/ns/ssn/dulhttps://www.w3.org/2015/spatial/wiki/Domain,_Range,_InverseOfhttps://www.w3.org/2015/spatial/wiki/Domain,_Range,_InverseOfhttps://lists.w3.org/Archives/Public/public-sdw-wg/2017Jun/0067.htmlhttps://lists.w3.org/Archives/Public/public-sdw-wg/2017Jun/0067.html
-
A. Haller et al. / The Modular SSN Ontology: A Joint W3C and OGC Standard 7
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
25 25
26 26
27 27
28 28
29 29
30 30
31 31
32 32
33 33
34 34
35 35
36 36
37 37
38 38
39 39
40 40
41 41
42 42
43 43
44 44
45 45
46 46
47 47
48 48
49 49
50 50
51 51
ule. The Dolce-UltraLite Alignment Module importsthe Dolce-UltraLite Ontology and the Sample rela-tions module, which in turn imports the SSN On-tology, and thereby transitively the SOSA Ontol-ogy. However, neither SOSA nor SSN import theDolce-UltraLite Alignment Module in reverse. TheSSN-DUL alignment module has been defined forbackwards-compatibility reasons only and SSN (andSOSA) can now be used entirely independently ofDUL. In fact, we are not anticipating the use of thisalignment in applications other than the one’s that aremigrated from the old ontology.
Additional vertical modules (see Sec. 7 axioma-tize alignments with other related ontologies, includ-ing O&M [13, 26], OBOE [43] and PROV-O [34].
4.2. Horizontal Segmentation
Modules that are horizontally layered may dependon each other, i.e., they may rely on the import ofanother horizontal module, but only extend scope byadding classes and properties, and do not otherwise en-rich the semantics of existing terms. Two horizontalmodules are defined in SSN (see Sec. 6.1): the SampleRelations Module and the System Capabilities Mod-ule.
5. The New SSN Ontology and its Core
SSNX was developed with ontology engineers asthe primary audience in mind. Due to the widespreadadoption of SSNX, the increasing role of citizen sci-ence, the strong focus on lightweight vocabularies bythe Linked Data community, and the rising importanceof simple vocabularies such as Schema.org, the SSNXontology needed streamlining. The new SSN has beenmodularized so that the core ontology module, SOSA,can be used as a standalone ontology or even a sim-ple vocabulary targeting web developers, citizen sci-ence, lightweight Linked Data publishing, resource-constrained IoT devices, and data intensive applica-tions.
SOSA consists of 13 classes, 21 object proper-ties and 2 datatype properties, and includes very lit-tle axiomatization. The SSN ontology is available athttp://www.w3.org/ns/ssn/. It imports the SOSA on-tology, adds additional axioms and 6 classes and 15object properties. The DL expressivity of the newlightweight SOSA core module is ALI(D) which isefficiently supported by modern DL or RDFS+ rea-
soners [33, 46, 51], while that of the new SSN isALRIN (D). In contrast, the expressivity of SSNX isSRIQ. Table 1 provides some key facts to compareSOSA and SSN to SSNX.
Ontology SOSA SSN SSNX
Classes 13 6 41Object properties 21 15 39Datatype properties 2 0 0Tot. logical axioms 13 127 10117
DL expressivity ALI(D) ALRIN (D) SRIQTable 1
Number of classes, object properties, and datatype properties, de-fined in SOSA, SSN, and SSNX (for comparison); DL expressivityof these ontologies.
Terms defined by the core SOSA ontology are iden-tified by URIs under the namespace http://www.w3.org/ns/sosa/, while those defined by the SSN ontol-ogy are identified by URIs under the namespace http://www.w3.org/ns/ssn/. In the rest of this article, weshorten these namespaces with the following prefixes(that are registered at http://prefix.cc).
@prefix sosa: .@prefix ssn: .
SSN (with its imported SOSA core) is organized,conceptually, but not physically, into eight perspec-tives. The core component with its three conceptualperspectives (Observations, Sampling, Actuation) hasalready been described in Sec. 3. In the rest of thissection we describe the other conceptual components,how they evolved from SSNX and the main rationalefor this evolution. Table 2 in Appendix A lists all ofthe terms defined in SOSA and SSN, and the terms inthe old SSN that they supersede, if they exist.
5.1. Feature of Interest and Sample
In an ontology that aims to describe interactions be-tween the physical and digital world, the target ob-ject in the physical world is of primary concern. Eventhough it is quite common in practice to report mea-surements of, and actions on, the physical world with-out explicit reference to a specific target object, the ob-ject is still necessarily there, cognitively completingthe act of observation. In SSN the target object is called
http://www.w3.org/ns/ssn/http://www.w3.org/ns/sosa/http://www.w3.org/ns/sosa/http://www.w3.org/ns/ssn/http://www.w3.org/ns/ssn/http://prefix.cc
-
8 A. Haller et al. / The Modular SSN Ontology: A Joint W3C and OGC Standard
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
25 25
26 26
27 27
28 28
29 29
30 30
31 31
32 32
33 33
34 34
35 35
36 36
37 37
38 38
39 39
40 40
41 41
42 42
43 43
44 44
45 45
46 46
47 47
48 48
49 49
50 50
51 51
a sosa:FeatureOfInterest, which reflects a terminologyheritage from OGC8.
The property sosa:hasFeatureOfInterest isused to link between a sosa:Observation andits associated sosa:FeatureOfInterest. This re-places oldssn:featureOfInterest, since the con-cept oldssn:FeatureOfInterest and the propertyoldssn:featureOfInterest were distinguished only bycase. The new SSN avoids this to make it easier to beused in languages without case distinction.
In the broader context of Spatial Data onthe Web, any Spatial Thing could also be asosa:FeatureOfInterest [52] of an observation, sam-pling or actuation, as Listing 5.1 exemplifies.
Listing 5.1: Spatial Features of Interest Modelling
a sosa:FeatureOfInterest ;rdfs:comment "House #134."@en .
a sosa:FeatureOfInterest ;rdfs:comment "The lumpy 2-seater couch with the
floral pattern."@en .
a sosa:FeatureOfInterest ;rdfs:comment "The insulation material in the roof
of house #134."@en .
SSN defines sosa:Sample as a subclass ofsosa:FeatureOfInterest, because, when used for an ob-servation, the sample is the (proximate) feature of in-terest, as Listing 5.2 shows.
Listing 5.2: Proximate Feature of Interest Modelling
a sosa:Observation ;sosa:hasFeatureOfInterest ;sosa:observedProperty ;sosa:phenomenonTime [a time:Instant ;time:inXSDDateTimeStamp"2017-12-04T08:14:00+10:00"^^xsd:dateTimeStamp ;] ;sosa:resultTime"2017-12-12T10:24:00+10:00"^^xsd:dateTime ;sosa:hasSimpleResult "6.1"^^cdt:pH .
In most circumstances the sample is only of inter-est in the context of observations, because it repre-sents the (ultimate) feature of interest that is the ob-ject of real world or scientific interest within the in-vestigation. In any observation we can query the prop-erty path9 sosa:hasFeatureOfInterest/sosa:isSampleOf*
8The geospatial community uses the term ’feature’ primarily torefer to discernable, identifiable objects in the landscape and theirdigital representations.
9See https://www.w3.org/TR/sparql11-query/#propertypaths forthe definition of SPARQL property paths
to find the ultimate feature of interest for the ob-servation. In Listing 5.2, which continues the exam-ple introduced in Sec. 3, we can infer that the ulti-mate feature of interest is in fact the garden denoted.
A sosa:FeatureOfInterest and sosa:Sample will of-ten have a specified location or other spatial proper-ties, but this is not required. Observations can be madeand samples taken from features for which the locationis of no direct interest. For example, a material sam-ple may represent a substance; an individual organismmay be representative of a taxon; a statistical samplemay represent a particular community that is not char-acterized by location, etc.
5.2. Properties
An observation targets a feature of interest butinteracts with it only through estimating the valueof a characteristic or property of that feature. Thegeneral class of feature properties, ssn:Property,is defined in the SSN module, complementing itssubclasses in SOSA, sosa:ObservableProperty andsosa:ActuatableProperty. The ssn:hasProperty, and itsinverse ssn:isPropertyOf, relate a feature of interest tossn:Property. We can state, as shown in Listing 5.3,that air temperature is a property of each room in thehouse.
Listing 5.3: Property Modelling
a ssn:Property ;sosa:isPropertyOf , .
Some properties of a feature may not be observ-able or actuatable characteristics, such as ‘name’.SOSA/SSN focus on those feature properties that havea triple connection to observation or actuation events:as an ssn:Property of the sosa:FeatureOfInterest of asosa:Observation or sosa:Actuation, as the propertybeing observed or actuated, and as the property usu-ally observed or actuated by the sensor or actuator usedin the observation or actuation. Any of these propertypaths should be able to be inferred from the others,whether or not all are explicitly stated.
5.2.1. Observable PropertiesThe multiplicity of property paths in which
sosa:observedProperty is involved can lead to sig-nificant modeling and representation choices. Onthe one hand, as an inherent characteristic, asosa:observedProperty is specific to a feature. On the
http://www.w3.org/ns/sosa/FeatureOfInteresthttp://www.w3.org/ns/sosa/hasFeatureOfInteresthttp://www.w3.org/ns/sosa/Observationhttp://www.w3.org/ns/sosa/FeatureOfInteresthttp://purl.oclc.org/NET/ssnx/ssn#featureOfInteresthttp://purl.oclc.org/NET/ssnx/ssn#FeatureOfInteresthttp://purl.oclc.org/NET/ssnx/ssn#featureOfInteresthttp://www.w3.org/ns/sosa/FeatureOfInteresthttp://www.w3.org/ns/sosa/Samplehttp://www.w3.org/ns/sosa/FeatureOfInteresthttps://www.w3.org/TR/sparql11-query/##propertypathshttp://www.w3.org/ns/sosa/FeatureOfInteresthttp://www.w3.org/ns/sosa/Samplehttp://www.w3.org/ns/ssn/Propertyhttp://www.w3.org/ns/sosa/ObservablePropertyhttp://www.w3.org/ns/sosa/ActuatablePropertyhttp://www.w3.org/ns/ssn/hasPropertyhttp://www.w3.org/ns/ssn/isPropertyOfhttp://www.w3.org/ns/ssn/Propertyhttp://www.w3.org/ns/ssn/Propertyhttp://www.w3.org/ns/sosa/FeatureOfInteresthttp://www.w3.org/ns/sosa/Observationhttp://www.w3.org/ns/sosa/Actuationhttp://www.w3.org/ns/sosa/observedPropertyhttp://www.w3.org/ns/sosa/observedProperty
-
A. Haller et al. / The Modular SSN Ontology: A Joint W3C and OGC Standard 9
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
25 25
26 26
27 27
28 28
29 29
30 30
31 31
32 32
33 33
34 34
35 35
36 36
37 37
38 38
39 39
40 40
41 41
42 42
43 43
44 44
45 45
46 46
47 47
48 48
49 49
50 50
51 51
other hand, we consider that multiple observationsacross different features of interest or by different sen-sors or both can measure the same generic property,e.g., air temperature. Thus, the air temperature in dif-ferent rooms of a smart home might be observed asshown in Listing 5.4.
Listing 5.4: Generic Observable Property Modelling
a sosa:Observation ;sosa:hasFeatureOfInterest ;sosa:observedProperty ;sosa:madeBySensor .
a sosa:Observation ;sosa:hasFeatureOfInterest ;sosa:observedProperty ;sosa:madeBySensor .
It might even be that the same digital portable ther-mometer is being used to measure both air and watertemperature (considered as an even more generic Am-bientTemperature) alternately in both rooms.
The link from a sensor to the property that it ob-serves, is made using the sosa:observes property, im-plying that every observation involving this sensor isabout the same property. In Listing 5.5, sensor #926is deployed only to observe the air temperature in thebedroom of our home, and we know that it made someobservations.
Listing 5.5: Observable Property Modelling
a sosa:Sensor ;sosa:observes ;sosa:madeObservation ,, .
Since is a generic Property andnot specific to the bedroom, we cannot just fol-low the sensor property path and infer whichroom’s air temperature was being observed: we needto know the sosa:hasFeatureOfInterest as well. Aspecific Property could instead be used, such as, but it would thenbe more difficult either to express the capabilities ofa portable sensor or to represent the generalization.
One approach to modeling generalization relation-ships between individual properties might be to usethe qudt:specialization and qudt:generalization proper-ties from the Quantities, Units, Dimensions and DataTypes vocabulary [25]. For example, various temper-atures around the home may be modeled as in List-ing 5.6.
Listing 5.6: Generalised Property Modelling
@prefix qudt: .
a sosa:ObservableProperty,qudt:QuantityKind ;
rdfs:label "Thermodynamic Temperature"@en .
a sosa:ObservableProperty,qudt:QuantityKind ;
qudt:generalization .
a sosa:ObservableProperty,qudt:QuantityKind ;
qudt:generalization .
a sosa:ObservableProperty,qudt:QuantityKind ;
qudt:generalization .
a sosa:ObservableProperty,qudt:QuantityKind ;
qudt:generalization .
a sosa:ObservableProperty,qudt:QuantityKind ;
qudt:generalization .
Some ontology engineers (and some controlled vo-cabularies for quantity kinds) prefer to model suchgeneralization-specialization relations using sub-classrelations between observable property classes. InSSNX, for example, the class of observable prop-erties was a subclass of dul:Quality and types ofproperties were usually modeled as subclasses ofoldssn:ObservedProperty rather than as individuals.10
Using either approach in SSN, it is still necessary tocreate an individual of whatever observed propertyclass(es) is appropriate, whether that individual is stilla generic property or is specific to an individual featureof interest as shown in Listing 5.7 or Listing 5.8.
Listing 5.7: Specific Property Modelling
rdfs:subClassOfsosa:ObservableProperty .
rdfs:subClassOf .
10In SSNX, the class of observable properties was defined as asubclass of dul:Quality and as the class of “observable Quality ofan Event or Object. That is, not a quality of an abstract entityas is also allowed by DUL’s Quality, but rather an aspect of anentity that is intrinsic to and cannot exist without the entity andis observable by a sensor.” Section 5.3.1.3.4 in [36] further addsthat types of properties, such as temperature or pressure should beadded as subclasses of oldssn:ObservedProperty instead of individ-uals. Yet, usage reports [19] of SSNX revealed that most datasetswere using observable properties as applicable to many featuresof interest. See https://www.w3.org/2015/spatial/wiki/What_is_an_instance_of_ssn:Property for more details on this point.
http://www.w3.org/ns/sosa/observeshttp://www.w3.org/ns/sosa/hasFeatureOfInteresthttp://qudt.org/1.1/schema/qudt#specializationhttp://qudt.org/1.1/schema/qudt#generalizationhttp://www.ontologydesignpatterns.org/ont/dul/DUL.owl#Qualityhttp://purl.oclc.org/NET/ssnx/ssn#ObservedPropertyhttp://www.ontologydesignpatterns.org/ont/dul/DUL.owl#Qualityhttp://purl.oclc.org/NET/ssnx/ssn#ObservedPropertyhttps://www.w3.org/2015/spatial/wiki/What_is_an_instance_of_ssn:Propertyhttps://www.w3.org/2015/spatial/wiki/What_is_an_instance_of_ssn:Property
-
10 A. Haller et al. / The Modular SSN Ontology: A Joint W3C and OGC Standard
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
25 25
26 26
27 27
28 28
29 29
30 30
31 31
32 32
33 33
34 34
35 35
36 36
37 37
38 38
39 39
40 40
41 41
42 42
43 43
44 44
45 45
46 46
47 47
48 48
49 49
50 50
51 51
a .
Listing 5.8: Specific Property Modelling using sub-classing
rdfs:subClassOfsosa:ObservableProperty .
rdfs:subClassOf .
rdfs:subClassOf .
a .
The subclass approach shown in Listing 5.8 avoidsintroducing an additional vocabulary to support thespecialization/generalization relationships, but poten-tially at the cost of decreased flexibility in describingrelations between defined properties.
We expect different communities and applicationsto develop their own approaches to building cataloguesof observable properties and choosing appropriate lev-els of specificity and selecting one of the modeling ap-proaches shown above.
5.2.2. Stimulus as Proxies for Observing PropertiesSensors respond to stimuli, e.g., changes in the
environment, or input data composed from the re-sults of prior observations, to generate the result. Theclass ssn:Stimulus is unchanged from SSNX and isa proxy (i.e. ssn:isProxyfor) for an observable prop-erty, or a number of observable properties. For ex-ample, the amount of dynamic acceleration in an ac-celerometer as a proxy for the tilt angle of a smartphone. Properties themselves are observable character-istics of (i.e. ssn:isPropertyOf) real-world entities (i.e.ssn:FeatureOfInterests).
5.2.3. Actuatable PropertiesThe class of properties that can be acted on
by actuators is sosa:ActuatableProperty. Instances ofsosa:ActuatableProperty are usually generic to manyfeatures of interest (e.g., ), but theymay be defined as specific to a single feature of interest(e.g., ).
For example, using a feature of interest -genericmodeling choice for the previous example introducedin Listing 3.5, one may model the open or close statusof the window as a first-class citizen as described inListing 5.9.
Listing 5.9: Generic Feature of Interest Modelling
a sosa:Actuation ;sosa:hasFeatureOfInterest ;sosa:actsOnProperty ;sosa:hasSimpleResult true ;sosa:resultTime"2017-04-18T17:24:00+02:00"^^xsd:dateTimeStamp .
SOSA does not define a specific property to link anactuator to the property it acts on, but the SSN propertyssn:forProperty can be used for this purpose.
5.3. Procedures and their Specification
Conceptually, an observation, sampling, or actua-tion, can be thought of acts that use(d) (parts) of aprocedure. A sosa:Procedure is a reusable workflow,protocol, plan, algorithm, or computational methodthat can be used to specify how to make an obser-vation, create a sample, or make a change to thestate of the world (i.e. perform an actuation). Thisrepresents a significant departure from the semanticsof the oldssn:Process class, defined as a subclass ofdul:Process, and which described the real-world pro-cess, rather than a description of it. In the optionalDUL alignment, a sosa:Procedure is now defined assubclass of dul:Method to describe a workflow thatspecifies how to make an observation, create a sample,or make a change to the state of the world via an ac-tuator (see Sec. 5.3). The oldssn:Sensing class, whichwas defined as a sub-class of a oldssn:Process has seenvery little implementation evidence and has been dep-recated in SSN.
This change addressed several requirements (e.g.[32, §5.25] and [32, §5.40]) and is the resultof extensive discussions within the group11. Thesosa:Procedure class now allows users to describethe protocol of Web services which themselves mayrepresent ways on how to interact with, for exam-ple, sosa:Actuators. In particular, a sosa:Procedurecan be linked to some description of the ssn:Inputand ssn:Output of these procedures. For exam-ple, Listing 5.10 states that the output of the procedure is theelectricity consumption.
Listing 5.10: Output Modelling
asosa:Procedure ;
ssn:hasOutput .
11See https://www.w3.org/2015/spatial/track/issues/89 and https://www.w3.org/2015/spatial/wiki/Procedure_Process for a summaryof the discussion and decision made on this topic.
http://www.w3.org/ns/ssn/Stimulushttp://www.w3.org/ns/ssn/isProxyforhttp://www.w3.org/ns/ssn/isPropertyOfhttp://www.w3.org/ns/ssn/FeatureOfInterestshttp://www.w3.org/ns/sosa/ActuatablePropertyhttp://www.w3.org/ns/sosa/ActuatablePropertyhttp://www.w3.org/ns/ssn/forPropertyhttp://www.w3.org/ns/sosa/Procedurehttp://purl.oclc.org/NET/ssnx/ssn#Processhttp://www.ontologydesignpatterns.org/ont/dul/DUL.owl#Processhttp://www.w3.org/ns/sosa/Procedurehttp://www.ontologydesignpatterns.org/ont/dul/DUL.owl#Methodhttp://purl.oclc.org/NET/ssnx/ssn#Sensinghttp://purl.oclc.org/NET/ssnx/ssn#Processhttp://www.w3.org/ns/sosa/Procedurehttp://www.w3.org/ns/sosa/Actuatorshttp://www.w3.org/ns/sosa/Procedurehttp://www.w3.org/ns/ssn/Inputhttp://www.w3.org/ns/ssn/Outputhttps://www.w3.org/2015/spatial/wiki/Procedure_Processhttps://www.w3.org/2015/spatial/wiki/Procedure_Process
-
A. Haller et al. / The Modular SSN Ontology: A Joint W3C and OGC Standard 11
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
25 25
26 26
27 27
28 28
29 29
30 30
31 31
32 32
33 33
34 34
35 35
36 36
37 37
38 38
39 39
40 40
41 41
42 42
43 43
44 44
45 45
46 46
47 47
48 48
49 49
50 50
51 51
If the result of an observation is a web documenthaving some representation (e.g., in JSON or XML)other ontologies such as the RDF Presentation ontol-ogy12 [37] or RaUL [23] can be used to model the re-sult using the ssn:hasOutput relation of SSN. It linksthe output of an observation to a description of howa result document can be validated (e.g., using someJSON Schema), or how an RDF description can be ob-tained from it (using some RDF lifting rule such as[39, 48] as shown in Listing 5.11).
Listing 5.11: Validation Rule Modelling
@prefix rdfp: .
asosa:Procedure ;
ssn:hasOutput [rdfp:presentedBy [rdfp:validationRule ;rdfp:liftingRule ] ] .
a sosa:Observation ;sosa:hasResult .
Procedures linked to observation and sampling ac-tivities, beyond the description of the presentation ofthe output, are typically a record of how these activitiesare performed (a log), and are linked to a sosa:Sensoror sosa:Sampler with the ssn:implements relation asdescribed in Listing 5.12.
Listing 5.12: Procedure Modelling
a sosa:Sensor ;ssn:implements
.
Procedures linked to actuation activities, however,can be either a record of how the actuation has beenperformed or a description of how to interact with anactuator (i.e., the recipe for performing actuations).The ssn:System concept and its relations to activi-ties through ssn:implementedBy/implements in com-bination with the inputs and outputs of a procedurecan define the interface of how to interact with asosa:Actuator. How much detail is provided to modelinputs and outputs of the actuation procedure as wellas the orchestration of multiple actuators is beyond thescope of SSN. Existing ontologies such as OWL-S [44]and execution protocols such as WSMX [21] can beused together with lower-level specifications such asthe W3C Thing Description13 to model these details.
12https://w3id.org/rdfp/13https://w3c.github.io/wot-thing-description/
5.4. Results
SSN offers two ways of attaching properties to ac-tivities that observe, actuate or sample them. For sim-ple (though frequent) cases that merely require a lit-eral typed with an appropriate datatype, one may usethe sosa:hasSimpleResult datatype property. Alterna-tively, observation results can be modeled as individu-als and linked to the observation using the object prop-erty sosa:hasResult. In cases where the observed prop-erty is a physical quantity, one may then use one of theseveral existing ontologies to model the result.
5.4.1. hasSimpleResult and hasResultListing 5.13 shows how to attach a literal value to
our previous . It also uses a cus-tom datatype (i.e. cdt:temperature) whose value spaceis some set of quantity values. However, such customdatatypes are not compatible with the OWL specifi-cations, which restricts the set of datatypes that canbe used and may consequently lead to an error in theOWL reasoner.
Listing 5.13: Simple Result Modelling
a sosa:Observation ;sosa:resultTime
"2017-11-15T14:35:13Z"^^xsd:dateTime ;sosa:hasSimpleResult "23.9 DEG"^^cdt:temperature .
The ssn:hasResult object property allows us tomake statements about the ssn:Result object (as shownin Listing 5.14) by explicitly stating the unit of mea-surement for the value of the observation. Althoughit was not in the scope of the SSN specification torecommend any particular way of modeling results asquantity values, there exist several external vocabular-ies that are specifically designed for modeling quan-tity values as OWL individuals. Examples include theQUDT ontology ( [25]) used in this listing, or the On-tology of Units of Measure (OM [49]). With QUDT, asosa:Result would be a qudt:QuantityValue. With OM,a sosa:Result would be an om:Measure.
Listing 5.14: Qualified Result Modelling
a sosa:Observation ;sosa:hasResult [a qudt-1-1:QuantityValue ;qudt-1-1:unit qudt-unit-1-1:DegreeCelsius ;qudt-1-1:numericValue "22.9"^^xsd:double ] .
The two alternative patterns reduce the com-plexity of the path to link an observation to theactual literal that encodes some value for the
http://www.w3.org/ns/ssn/hasOutputhttp://www.w3.org/ns/sosa/Sensorhttp://www.w3.org/ns/sosa/Samplerhttp://www.w3.org/ns/ssn/implementshttp://www.w3.org/ns/ssn/Systemhttp://www.w3.org/ns/ssn/implementedBy/implementshttp://www.w3.org/ns/sosa/Actuatorhttps://w3id.org/rdfp/http://www.w3.org/ns/sosa/hasSimpleResulthttp://www.w3.org/ns/sosa/hasResulthttp://w3id.org/lindt/custom_datatypes#temperaturehttp://www.w3.org/ns/ssn/hasResulthttp://www.w3.org/ns/ssn/Resulthttp://www.w3.org/ns/sosa/Resulthttp://qudt.org/1.1/schema/qudt#QuantityValuehttp://www.w3.org/ns/sosa/Resulthttp://www.wurvoc.org/vocabularies/om-1.8/Measure
-
12 A. Haller et al. / The Modular SSN Ontology: A Joint W3C and OGC Standard
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
25 25
26 26
27 27
28 28
29 29
30 30
31 31
32 32
33 33
34 34
35 35
36 36
37 37
38 38
39 39
40 40
41 41
42 42
43 43
44 44
45 45
46 46
47 47
48 48
49 49
50 50
51 51
result of this observation that was required inSSNX14. Compatibility with SSNX (see Sec. 7.4)is obtained through both oldssn:SensorOutput andoldssn:ObservationValue being subclasses of the newsosa:Result, and oldssn:observationResult being asubproperty of ssn:hasResult.
There have been discussions in the working groupon potential actuation commands15, but their inclusionhas been deemed out of scope for the current versionof SSN.
5.4.2. Result of a Sampling activitysosa:Sample is a subclass of sosa:Result be-
cause a sample is the result of a sosa:Sampling ac-tivity. This is in addition to being a subclass ofsosa:FeatureOfInterest so that it can serve as the targetof a sosa:Observation.
5.4.3. Result Time and Phenomenon TimeSOSA distinguishes between the
sosa:phenomenonTime and sosa:resultTime, theformer being the time that the result of an observa-tion, actuation, or sampling applies to the feature ofinterest, while the latter specifies the instant of timewhen an act, such as an observation, was completed.The sosa:resultTime is a datatype property withrdfs:range xsd:dateTime to capture the time instantthat the activity completed and the result obtained.The sosa:phenomenonTime is an object property withrange time:TemporalEntity [15], since it may be eitheran instant or interval, or even a temporal complex.
For example, Listing 5.15 describes that the temper-ature was observed through April 15th 2017, and thatthe result was available 12 seconds after the end of thisperiod.
Listing 5.15: Phenomenon Time Modelling
@prefix time: .@prefix xsd: .
sosa:resultTime"2017-04-16T00:00:12+00:00"^^xsd:dateTimeStamp ;
sosa:phenomenonTime [a time:Interval ;time:hasBeginning [a time:Instant ;time:inXSDDateTimeStamp"2017-04-15T00:00:00+00:00"^^xsd:dateTimeStamp
14Wiki page https://www.w3.org/2015/spatial/wiki/Storing_Observation_Value lists pros and cons on the options that wereconsidered, and excerpts of the discussion within the group.
15See https://www.w3.org/2015/spatial/wiki/Result_and_Command for a summary of the discussion on this topic.
] ;time:hasEnd [a time:Instant ;time:inXSDDateTimeStamp"2017-04-16T00:00:00+00:00"^^xsd:dateTimeStamp
]] .
The distinction between sosa:resultTime andsosa:phenomenonTime is important where the endof the observation, actuation, or sampling, activity issignificantly different from that of the phenomenonthat is observed or acted on. The separation coverscases involving observations over a long period oftime, late results due to long-lasting procedures,delays due to lengthy information travel (e.g., in-formation traveling long distances), cases where theresult describes the state in the distant past (e.g.observations that described the pressure and tem-perature of a mineral at its time of formation), andpredictions and forecasts - which may be definedas observations with a sosa:resultTime before thesosa:phenomenonTime [13, 22, 26, §7.2]. In bothof the last two cases, it is common to have multipleobservations relating to the same feature of interest,observed property and phenomenon time, but withdifferent result times. For example, different proce-dures might be used in different geology labs. Andthe results of forecasts obtained using computationalprocedures might later be subject to validation byinstrumental observations. The outcome of the latterwould be encoded as sosa:Observations with the samesosa:hasFeatureOfInterest, sosa:observedProperty,and sosa:phenomenonTime, as the forecast, but witha different sosa:usedProcedure, sosa:madeBySensorand sosa:resultTime.
5.5. Systems and their deployments
The modelling of a sensor as a physical pieceof technology and the way multiple sensors are at-tached to other such entities has been greatly simpli-fied in SSN. Whereas SSNX distinguished betweenan oldssn:Sensor that could be any entity that per-formed oldssn:Sensing and an oldssn:SensingDevicethat was a subclass of an oldssn:Device, i.e. a phys-ical piece of technology, the new SSN drops the no-tion of an oldssn:Device as well as the notion of anoldssn:SensingDevice. The ssn:System class that al-ready existed in SSNX takes the place of those twoclasses, i.e. it can be used if someone wants to ex-plicitly model that a sosa:Sensor, sosa:Actuator orsosa:Sampler is a physical piece of technology. For
http://purl.oclc.org/NET/ssnx/ssn#SensorOutputhttp://purl.oclc.org/NET/ssnx/ssn#ObservationValuehttp://www.w3.org/ns/sosa/Resulthttp://purl.oclc.org/NET/ssnx/ssn#observationResulthttp://www.w3.org/ns/ssn/hasResulthttp://www.w3.org/ns/sosa/Samplehttp://www.w3.org/ns/sosa/Resulthttp://www.w3.org/ns/sosa/Samplinghttp://www.w3.org/ns/sosa/FeatureOfInteresthttp://www.w3.org/ns/sosa/Observationhttp://www.w3.org/ns/sosa/phenomenonTimehttp://www.w3.org/ns/sosa/resultTimehttp://www.w3.org/ns/sosa/resultTimehttp://www.w3.org/2000/01/rdf-schema#rangehttp://www.w3.org/2001/XMLSchema#dateTimehttp://www.w3.org/ns/sosa/phenomenonTimehttp://www.w3.org/2006/time#TemporalEntityhttps://www.w3.org/2015/spatial/wiki/Storing_Observation_Valuehttps://www.w3.org/2015/spatial/wiki/Storing_Observation_Valuehttps://www.w3.org/2015/spatial/wiki/Result_and_Commandhttps://www.w3.org/2015/spatial/wiki/Result_and_Commandhttp://www.w3.org/ns/sosa/resultTimehttp://www.w3.org/ns/sosa/phenomenonTimehttp://www.w3.org/ns/sosa/resultTimehttp://www.w3.org/ns/sosa/phenomenonTimehttp://www.w3.org/ns/sosa/Observationshttp://www.w3.org/ns/sosa/hasFeatureOfInteresthttp://www.w3.org/ns/sosa/observedPropertyhttp://www.w3.org/ns/sosa/phenomenonTimehttp://www.w3.org/ns/sosa/usedProcedurehttp://www.w3.org/ns/sosa/madeBySensorhttp://www.w3.org/ns/sosa/resultTimehttp://purl.oclc.org/NET/ssnx/ssn#Sensorhttp://purl.oclc.org/NET/ssnx/ssn#Sensinghttp://purl.oclc.org/NET/ssnx/ssn#SensingDevicehttp://purl.oclc.org/NET/ssnx/ssn#Devicehttp://purl.oclc.org/NET/ssnx/ssn#Devicehttp://purl.oclc.org/NET/ssnx/ssn#SensingDevicehttp://www.w3.org/ns/ssn/Systemhttp://www.w3.org/ns/sosa/Sensorhttp://www.w3.org/ns/sosa/Actuatorhttp://www.w3.org/ns/sosa/Sampler
-
A. Haller et al. / The Modular SSN Ontology: A Joint W3C and OGC Standard 13
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
25 25
26 26
27 27
28 28
29 29
30 30
31 31
32 32
33 33
34 34
35 35
36 36
37 37
38 38
39 39
40 40
41 41
42 42
43 43
44 44
45 45
46 46
47 47
48 48
49 49
50 50
51 51
similar reasons, the notion of a sampling device hasbeen dropped16.
5.5.1. Platforms and hostsOne or more sensors (as well as actuators and sam-
plers) can be hosted or mounted on a sosa:Platform.Such platforms can also define the geometric prop-erties, i.e., placement, of sensors in relation toone another. sosa:Platforms can also host othersosa:Platforms.
The properties oldssn:attachedSystem andoldssn:onPlatform have been renamed to sosa:hostsand sosa:isHostedBy, respectively, and they cannow be used on both, the sosa:Platform and thesosa:System class to define that they host sensors,actuators or samplers.17
Temperature observations can be defined to bemade, for example, by a temperature sensor that isbuilt-in/hosted by a Nest thermostat. Listing 5.16shows how to model this relation in our smart homeuse case. In this example, is in-ferred to be an ssn:System, as only ssn:Systems canbe hosted by sosa:Platforms.
Listing 5.16: Platform Modelling
a sosa:Platform ;rdfs:label "3rd gen Nest Learning Thermostat
D1AA22A8211"@en ;rdfs:comment "Nest Thermostat in bedroom of house
#134"@en ;sosa:hosts .
a sosa:Sensor ;rdfs:label "Nest temperature sensor #1"@en ;sosa:observes .
5.5.2. Systems and Sub-systemsThe system class has remained unchanged from
SSNX apart from its relation to DUL (see Sec. 3.1) as aunit of abstraction for pieces of infrastructure that im-plement procedures and that are hosted by platforms.A system can have components (ssn:hasSubSystem)which are also systems. Classes and relationships re-lated to system capabilities, operating ranges, and sur-vival ranges, under given conditions have been rele-gated to a separate horizontal module (see Sec. 6.1).
16See https://www.w3.org/2015/spatial/wiki/Link_between_platform_and_device for a summary of the discussion and decisionmade on this topic.
17Wiki page https://www.w3.org/2015/spatial/wiki/Terms pro-vides an overview of how each term in SSNX has been dealt with,potentially renamed or simply deprecated in the new SSN.
5.5.3. DeploymentAn ssn:Deployment is an activity or a set of activi-
ties that encompass all phases in the lifecycle of a de-ployed system, such as, the installation, maintenanceand decommissioning of the platform, sensors, actu-ators or samplers attached to that system. The classof ssn:Deployment describes the deployment of oneor more systems (ssn:deployedSystem) or platforms(ssn:deployedOnPlatform) for a particular purpose. Forexample, a temperature sensor deployed on a wall, or awhole network of sensors deployed for an observationcampaign.
Listing 5.17 shows an example of how to model adeployment (i.e. ) of two sys-tems , that are deployed in thekitchen of our example house #134.
Listing 5.17: Deployment Modelling
a sosa:Platform ;rdfs:label "House #134 Kitchen."@en ;rdfs:comment "House #134 Kitchen that hosts
PCBoard1 and PCBoard2."@en ;sosa:hosts , .
a ssn:System ;rdfs:label "PCB Board 1"@en ;rdfs:comment "PCB Board 1 hosts DHT22 temperature
sensor #1."@en ;sosa:hosts .
a ssn:System ;rdfs:label "PCB Board 2"@en ;rdfs:comment "PCB Board 2 hosts DHT22 temperature
sensor #2."@en ;sosa:hosts .
a ssn:Deployment ;rdfs:comment "Deployment of PCB Board 1 and 2 in
the kitchen for the purpose of observing thetemperature."@en ;
ssn:deployedOnPlatform ;ssn:deployedSystem , ;ssn:forProperty .
The oldssn:DeploymentRelatedProcess andoldssn:deploymentProcessPart have been deprecatedas no usage of these terms has been reported.
6. Horizontal Extension Modules
Horizontal extension modules are ontologies that in-troduce new classes and relations on top of SSN.
6.1. The System Capabilities Module
The System Capabilities module, a.k.a. SSN-System, gathers classes and properties used to model
http://www.w3.org/ns/sosa/Platformhttp://www.w3.org/ns/sosa/Platformshttp://www.w3.org/ns/sosa/Platformshttp://purl.oclc.org/NET/ssnx/ssn#attachedSystemhttp://purl.oclc.org/NET/ssnx/ssn#onPlatformhttp://www.w3.org/ns/sosa/hostshttp://www.w3.org/ns/sosa/isHostedByhttp://www.w3.org/ns/sosa/Platformhttp://www.w3.org/ns/sosa/Systemhttp://www.w3.org/ns/ssn/Systemhttp://www.w3.org/ns/ssn/Systemshttp://www.w3.org/ns/sosa/Platformshttp://www.w3.org/ns/ssn/hasSubSystemhttps://www.w3.org/2015/spatial/wiki/Link_between_platform_and_devicehttps://www.w3.org/2015/spatial/wiki/Link_between_platform_and_devicehttps://www.w3.org/2015/spatial/wiki/Termshttp://www.w3.org/ns/ssn/Deploymenthttp://www.w3.org/ns/ssn/Deploymenthttp://www.w3.org/ns/ssn/deployedSystemhttp://www.w3.org/ns/ssn/deployedOnPlatformhttp://purl.oclc.org/NET/ssnx/ssn#DeploymentRelatedProcesshttp://purl.oclc.org/NET/ssnx/ssn#deploymentProcessPart
-
14 A. Haller et al. / The Modular SSN Ontology: A Joint W3C and OGC Standard
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
25 25
26 26
27 27
28 28
29 29
30 30
31 31
32 32
33 33
34 34
35 35
36 36
37 37
38 38
39 39
40 40
41 41
42 42
43 43
44 44
45 45
46 46
47 47
48 48
49 49
50 50
51 51
system capabilities, operating range, and survivalrange. This part of SSNX was rarely used in im-plementations, hence specific effort has been madeto clarify and simplify its documentation, along withproviding illustrative examples. Terms defined by theSSN-System ontology are identified by URIs un-der the namespace http://www.w3.org/ns/ssn/systems/.We shorten this namespace with prefix ssn-system:.
@prefix ssn-system: .
Table 3 in Appendix B lists all of the terms definedin SSN-System, and the terms in the old SSN that theysupersede, if they exist.
6.1.1. System CapabilitiesAn ssn:System may be linked to some ssn-
system:SystemCapability, which in turn is linked tosome ssn-system:SystemProperty: measurement, ac-tuation, or sampling properties that describe the capa-bilities of the ssn:System such as its accuracy, latency,precision, etc. An ssn-system:SystemCapability canfurthermore be linked to some ssn-system:Conditionthat define its validity context such as a tempera-ture range. For example, Listing 6.1 specifies that theDHT22 temperature sensor sensitivity is 0.1◦C in nor-mal temperature conditions.
Listing 6.1: System Capability Modelling
@prefix schema: .@prefix qudt-unit-1-1:
.
a sosa:Sensor ;rdfs:comment "The DHT22 #4578 embedded
temperature sensor."@en ;ssn-system:hasSystemCapability
.
a ssn:Property ,ssn-system:SystemCapability ;
rdfs:comment "The capabilities of the temperaturesensor in normal temperature conditions."@en;
ssn-system:inCondition ;ssn-system:hasSystemProperty
.
a ssn-system:Condition ,schema:PropertyValue ;
rdfs:comment "A temperature range of -40 to 80Celsius."@en ;
schema:minValue -40.0 ;schema:maxValue 80.0 ;schema:unitCode qudt-unit-1-1:DegreeCelsius .
a ssn:Property ,ssn-system:Sensitivity ,ssn-system:Resolution , schema:PropertyValue ;
rdfs:comment "The sensitivity and resolution ofthe temperature sensor is 0.1 $^{\circ}$C in
normal temperature and humidityconditions."@en ;
schema:value 0.1 ;schema:unitCode qudt-unit-1-1:DegreeCelsius .
The Terms ssn-system:SystemCapability and ssn-system:SystemProperty are named after the SSNXoldssn:SensorCapability and oldssn:SensorPropertyterms, that were generalized so that the new onesapply to the more general concept of ssn:Systeminstead of just sosa:Sensor.18 Several sub-classesof ssn-system:SystemProperty are pre-defined aslisted in Table 3. Most of these were already de-fined in SSNX but their definition was harmo-nized, simplified, and sometimes generalized whenthe term can be applied equally to a sosa:Sensor,sosa:Actuator or sosa:Sampler. A system propertyssn-system:ActuationRange has been introduced as itwas considered of high interest for actuators.
6.1.2. Operating Range and Survival RangeThe pattern used to describe a system capability
in terms of some of its property values under certainconditions is replicated to describe its operating rangeand survival range. An ssn-system:OperatingRange(resp. ssn-system:SurvivalRange) describes somenormal ssn-system:OperatingProperty (resp. ssn-system:SurvivalProperty) of an ssn:System undersome specified ssn-system:Conditions. For example,the power requirement or maintenance scheduleof an ssn:System (resp. the system or its batterylifetime) under a specified temperature range. In theabsence of an ssn-system:OperatingProperty (an ssn-system:SurvivalProperty), it simply describes the ssn-system:Conditions in which a System is expected tooperate (under which the ssn:System can be exposedto without damage). The ssn:System continues tooperate as defined by its ssn-system:SystemCapability.If, however, the ssn-system:OperatingProperty(resp. ssn-system:SurvivalProperty) is violated, thessn:System is operating ’out of operating range’ (resp.is ’damaged’) and its ssn-system:SystemCapabilityspecification may no longer hold. Some sub-classes of ssn-system:OperatingProperty and ssn-system:SurvivalProperty are also pre-defined, andlisted in Table 3.
18See https://www.w3.org/2015/spatial/wiki/Measurement_and_Operating_properties_for_actuators and https://lists.w3.org/Archives/Public/public-sdw-wg/2017Mar/0233.html for moredetails on the discussions.
http://www.w3.org/ns/ssn/systems/http://www.w3.org/ns/ssn/Systemhttp://www.w3.org/ns/ssn/systems/SystemCapabilityhttp://www.w3.org/ns/ssn/systems/SystemCapabilityhttp://www.w3.org/ns/ssn/systems/SystemPropertyhttp://www.w3.org/ns/ssn/Systemhttp://www.w3.org/ns/ssn/systems/SystemCapabilityhttp://www.w3.org/ns/ssn/systems/Conditionhttp://www.w3.org/ns/ssn/systems/SystemCapabilityhttp://www.w3.org/ns/ssn/systems/SystemPropertyhttp://www.w3.org/ns/ssn/systems/SystemPropertyhttp://purl.oclc.org/NET/ssnx/ssn#SensorCapabilityhttp://purl.oclc.org/NET/ssnx/ssn#SensorPropertyhttp://www.w3.org/ns/ssn/Systemhttp://www.w3.org/ns/sosa/Sensorhttp://www.w3.org/ns/ssn/systems/SystemPropertyhttp://www.w3.org/ns/sosa/Sensorhttp://www.w3.org/ns/sosa/Actuatorhttp://www.w3.org/ns/sosa/Samplerhttp://www.w3.org/ns/ssn/systems/ActuationRangehttp://www.w3.org/ns/ssn/systems/OperatingRangehttp://www.w3.org/ns/ssn/systems/SurvivalRangehttp://www.w3.org/ns/ssn/systems/OperatingPropertyhttp://www.w3.org/ns/ssn/systems/SurvivalPropertyhttp://www.w3.org/ns/ssn/systems/SurvivalPropertyhttp://www.w3.org/ns/ssn/Systemhttp://www.w3.org/ns/ssn/systems/Conditionshttp://www.w3.org/ns/ssn/Systemhttp://www.w3.org/ns/ssn/systems/OperatingPropertyhttp://www.w3.org/ns/ssn/systems/SurvivalPropertyhttp://www.w3.org/ns/ssn/systems/SurvivalPropertyhttp://www.w3.org/ns/ssn/systems/Conditionshttp://www.w3.org/ns/ssn/systems/Conditionshttp://www.w3.org/ns/ssn/Systemhttp://www.w3.org/ns/ssn/Systemhttp://www.w3.org/ns/ssn/systems/SystemCapabilityhttp://www.w3.org/ns/ssn/systems/OperatingPropertyhttp://www.w3.org/ns/ssn/systems/SurvivalPropertyhttp://www.w3.org/ns/ssn/Systemhttp://www.w3.org/ns/ssn/systems/SystemCapabilityhttp://www.w3.org/ns/ssn/systems/OperatingPropertyhttp://www.w3.org/ns/ssn/systems/SurvivalPropertyhttp://www.w3.org/ns/ssn/systems/SurvivalPropertyhttps://www.w3.org/2015/spatial/wiki/Measurement_and_Operating_properties_for_actuatorshttps://www.w3.org/2015/spatial/wiki/Measurement_and_Operating_properties_for_actuatorshttps://lists.w3.org/Archives/Public/public-sdw-wg/2017Mar/0233.htmlhttps://lists.w3.org/Archives/Public/public-sdw-wg/2017Mar/0233.html
-
A. Haller et al. / The Modular SSN Ontology: A Joint W3C and OGC Standard 15
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
25 25
26 26
27 27
28 28
29 29
30 30
31 31
32 32
33 33
34 34
35 35
36 36
37 37
38 38
39 39
40 40
41 41
42 42
43 43
44 44
45 45
46 46
47 47
48 48
49 49
50 50
51 51
6.1.3. Extensibility of the System Capabilities ModuleAs a matter of fact, the SSN System Capabilities
module contains a predefined list of capabilities, op-erating ranges, and survival ranges, that were consid-ered of high relevance for SOSA/SSN users. Externalontologies may propose new such terms in their ownnamespace, or even reuse the design pattern to describeother characteristics of other kinds of systems (for ex-ample, the maximal bandwidth or payload of a com-municating device in some conditions).
6.2. The Sample Relations Module
Support for samples and sampling is one of the ma-jor enhancements in SOSA/SSN. The defining prop-erty of a sosa:Sample is the sosa:isSampleOf relation-ship with the thing that it is intended to represent.
However, in many cases a sample also has a rela-tionship with another sample or samples as part of astudy or deployment [26, 49][32, §5.38]. The nature ofthe relationship is typically quite specific, for example:
– spatial, such as pixels within a remote-sensedscene, stations along a traverse, or specimens col-lected along a borehole
– specific fractions of a mixture, such as plateletsfrom a blood sample
– specific ("biased") fractions of an assay sample,such as the fraction of a powder that passes a spe-cific sieve grating, the fraction that is magneti-cally susceptible, or the fraction whose density ishigher than a specified value
– non-specific ("un-biased") fractions of a sample("splits")
– parts of a specimen, such as the leg of an insect,which in turn represents a taxon
The design of sub-sampling strategies is a key ele-ment of scientific investigations, and is a critical sourceof innovation. Therefore, generic relationships such as‘parent-child’, or ‘subset’ are insufficient.
The Sample Relations module provides a scalablepattern for linking samples which also allows relation-ship details to be captured. This is accomplished by in-troducing an intermediate class in the relationship be-tween samples, so that the nature of the relationshipcan be recorded as an annotation on the association.
In Listing 6.2, the nature of the relationship betweena sub-sample of our soil and the sample within whichit is found is described in an rdfs:comment within ablank-node.
Listing 6.2: Sub-Sample Modelling
a sosa:Sample ;rdfs:label "Soil sample 134g1 organic fraction" ;sampling:hasSampleRelationship [a sampling:SampleRelationship ;sampling:natureOfRelationship [a sampling:RelationshipNature ;rdfs:comment "organic fraction of material" ;
] ;sampling:relatedSample ;
] ;sosa:isResultOf .
a sosa:Sampling ;sosa:featureOfInterest ;sosa:usedProcedure
.
asosa:Procedure ;
rdfs:comment "... details of procedure toseparate the organic fraction of a soilsample ..." .
If there is a set of ’standard’ relationships usedwithin a particular discipline or community, thesecould be registered and assigned URIs. A reference tothe standard relationship can then be used instead ofthe blank-node, as described in a modified version ofthe example above in Listing 6.3.
Listing 6.3: Sample Blank Node Modelling
a sosa:Sample ;rdfs:label "Soil sample 134g1 organic fraction" ;sampling:hasSampleRelationship [
a sampling:SampleRelationship ;sampling:natureOfRelationship
;
sampling:relatedSample ;] ;sosa:isResultOf .
The Sample Relations module is included in SSN/-SOSA as a non-normative horizontal extension.
7. Vertical Extension Modules
Vertical extension modules are ontologies that intro-duce additional expressivity or axiomatic constraintson top of SSN.
7.1. Alignment to OGC O&M
The observation and sample aspects of SSN areclosely aligned to the OGC O&M model precedent[13, 26]. However, (a) OGC O&M is defined usingUML and (b) some of the class and property nameshave been adjusted. Therefore, a formal (axiomatized)
http://www.w3.org/ns/sosa/Samplehttp://www.w3.org/ns/sosa/isSampleOfhttp://www.w3.org/2000/01/rdf-schema#comment
-
16 A. Haller et al. / The Modular SSN Ontology: A Joint W3C and OGC Standard
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
25 25
26 26
27 27
28 28
29 29
30 30
31 31
32 32
33 33
34 34
35 35
36 36
37 37
38 38
39 39
40 40
41 41
42 42
43 43
44 44
45 45
46 46
47 47
48 48
49 49
50 50
51 51
alignment to OGC O&M is provided as a vertical mod-ule which owl:imports SOSA, and uses the URI schemedefined by ISO 19150-2 to denote the O&M classesand properties [27].
The main conceptual difference between SSN andO&M is that the latter conflates both Proceduresand Systems into a pair of classes: OM_Processand SF_Process. Alignment is achieved by way ofthe following axiom: iso19156-om:OM_Process ≡sosa:Sensor t sosa-om:ObservationProcedure wheresosa-om:ObservationProcedure v sosa:Procedure.Some other entities and properties of O&M, such asvalidTime, are not presently mapped to any terms ofSOSA/SSN.
7.2. Al