0 Semantic Web - (2018) 0–24 IOS Press
1 1 2 2 3 3 4 The Modular SSN Ontology: A Joint W3C 4 5 5 6 and OGC Standard Specifying the Semantics 6 7 7 8 8 9 of Sensors, Observations, Sampling, and 9 10 10 11 Actuation 11 12 12 13 Armin Haller a,*, Krzysztof Janowicz b, Simon J D Cox c, Maxime Lefrançois d, Kerry Taylor a, 13 14 Danh Le Phuoc e, Joshua Lieberman f, Raúl García-Castro g, Rob Atkinson h, and Claus Stadler i 14 15 a Research School of Computer Science, Australian National University, Canberra, Australia 15 16 E-mails: [email protected], [email protected] 16 17 b Geography Department, University of California, Santa Barbara, CA, USA 17 18 E-mail: [email protected] 18 19 c Land and Water, CSIRO, Melbourne, Australia 19 20 E-mail: [email protected] 20 21 d Univ Lyon, MINES Saint-Étienne, CNRS, Laboratoire Hubert Curien UMR 5516, Saint-Étienne, France 21 22 E-mail: [email protected] 22 23 e Open Distributed Systems, Technische Universität Berlin, Germany 23 24 E-mail: [email protected] 24 25 f Center for Geographic Analysis, Harvard University, Boston, MA, USA 25 26 E-mail: [email protected] 26 27 g Ontology Engineering Group, Universidad Politécnica de Madrid, Madrid, Spain 27 28 E-mail: rgarcia@fi.upm.es 28 29 h Metalinkage, Wollongong, Australia 29 30 E-mail: [email protected] 30 31 i Institut für Informatik, Universität Leipzig, Leipzig, Germany 31 32 E-mail: [email protected] 32 33 33 34 34 Editor: Pascal Hitzler, Wright State University, USA 35 Solicited reviews: Eva Blomqvist, Linköping University, Sweden; Alessandro Oltramari, Bosch Research and Technology Center, USA; 35 36 Freddy Lecue, Accenture Tech Labs Ireland, and INRIA, France 36 37 37 38 38 39 39 40 40 41 Abstract. The joint W3C (World Wide Web Consortium) and OGC (Open Geospatial Consortium) Spatial Data on the Web 41 42 (SDW) Working Group developed a set of ontologies to describe sensors, actuators, samplers as well as their observations, 42 43 actuation, and sampling activities. The ontologies have been published both as a W3C recommendation and as an OGC im- 43 44 plementation standard. The set includes a lightweight core module called SOSA (Sensor, Observation, Sampler, and Actuator) 44 45 available at: http://www.w3.org/ns/sosa/, and a more expressive extension module called SSN (Semantic Sensor Network) avail- 45 46 able at: http://www.w3.org/ns/ssn/. Together they describe systems of sensors and actuators, observations, the used procedures, 46 47 the subjects and their properties being observed or acted upon, samples and the process of sampling, and so forth. The set of 47 ontologies adopts a modular architecture with SOSA as a self-contained core that is extended by SSN and other modules to 48 48 add expressivity and breadth. The SOSA/SSN ontologies are able to support a wide range of applications and use cases, includ- 49 49 ing satellite imagery, large-scale scientific monitoring, industrial and household infrastructures, social sensing, citizen science, 50 observation-driven ontology engineering, and the Internet of Things. In this paper we give an overview of the ontologies and 50 51 discuss the rationale behind key design decisions, reporting on the differences between the new SSN ontology presented here and 51 its predecessor [9] developed by the W3C Semantic Sensor Network Incubator group (the SSN-XG). We present usage examples and describe alignment modules that foster interoperability with other ontologies. 1570-0844/18/$35.00 c 2018 – IOS Press and the authors. All rights reserved Keywords: Ontology, Sensor, Actuator, Observation, Actuation, Sampling, Linked Data, Web of Things, Internet of Things A. Haller et al. / The Modular SSN Ontology: A Joint W3C and OGC Standard 1
1 1. Introduction cover new aspects of sensing that have become more 1 2 relevant, such as actuation, a key element of the Inter- 2 3 Sensors are a major source of data available on the net of Things (IoT). 3 4 Web today. The trend towards making cities, offices, Four years after the publication of the first version, 4 5 and homes ‘smarter’ by turning them into sensor-rich work started on an update and formal standardization 5 6 environments [31] drives the demand for specifications of the SSNX ontology, this time jointly led by the W3C 6 7 that describe how to model and publish sensor and ac- and the OGC, to address the feedback gathered on the 7 8 tuator data as well as how to foster interoperability usage of the ontology and lessons learned. This ac- 8 9 across platforms on the Web or other data infrastruc- tivity resulted in the publication of the new Semantic 9 10 tures. Sensor Network (SSN) modular ontology, designed to 10 11 Sensor readings are often provided only as raw nu- provide a flexible but coherent perspective for repre- 11 12 meric values, but any searching, reusing, integrating, senting the entities, relations, and activities involved in 12 13 or interpreting of these data requires more than just the sensing, sampling, and actuation [22]. The main inno- 13 14 observation results. Of equal importance for the proper vation of this formal standard version of SSN is the 14 15 interpretation of these values is contextual information separation of SSN into ontology modules, the central 15 16 about the studied feature of interest, such as a river, of which is the Sensor, Observation, Sample, and Ac- 16 17 the observed property, such as flow velocity, the uti- tuator (SOSA) ontology, providing a lightweight core 17 18 lized sampling strategy, such as the specific locations for SSN. SOSA aims to broaden the target audience 18 19 or sampling stations and times at which the velocity and application areas that can make use of Semantic 19 20 was measured, the procedures followed to produce a Web ontologies. Other SSN modules add additional 20 21 result, and a variety of other information. terms, introduce additional ontological commitments, 21 22 The Open Geospatial Consortium’s (OGC) Sensor and/or clarify and support the alignment of SSN with 22 23 Web Enablement (SWE) standards [6, 26, 49] provide other ontologies. 23 24 a framework for describing sensors and observations, This paper does not aim at providing an exhaus- 24 25 as well as encodings for their data and service inter- tive description of the SSN ontology, since that can be 25 26 faces for interacting with them. SWE implementations found in the specification [22], but to motivate the de- 26 27 followed the style of other OGC standards, relying on velopment decisions and the design patterns followed 27 28 web-hosted service calls and XML payloads, which while indicating the most substantial changes made 28 29 have limited compatibility with the more recent and since the initial release of the ontology. Throughout 29 30 widely used web platforms. this paper we will introduce concepts from SSN (and 30 31 A W3C Incubator Group was created in 2009 with SOSA) in detail, supported by examples of its use in 31 32 the goal, among others, of defining an OWL ontol- a smart home case study. As will be detailed below, 32 33 ogy that would, to some degree, reflect the SWE stan- SOSA [30] is a self-contained pattern designed for 33 34 dards. That group produced the original Semantic Sen- reuse and to meet the demands of a larger, schema.org- 34 35 sor Network ontology (SSNX1)[9, 36]. SSNX was de- style target audience. Hence, SOSA is only introduced 35 36 signed to be consistent with W3C endorsed best prac- here to a degree necessary to understand its relation 36 37 tices on publishing data on the Web, which recommend to SSN and because SSN imports and extends SOSA 37 38 a Linked Data approach, allowing sensor data, for ex- classes and relations. 38 39 ample, to be published as part of a global and densely The remainder of the paper is structured as follows. 39 40 interconnected graph of data [42]. The SSNX ontology Sec.2 briefly reviews the origins of the SSN ontol- 40 41 has been the basis for many subsequent research ini- ogy. Sec.3 explains the rationale behind the main 41 42 tiatives and some operational deployments. However, changes to the core of SSN, with observations mod- 42 43 users of the original ontology have identified a num- eled as events alongside the related sampling and actu- 43 44 ber of potential points of improvement, inconsistencies ation activities which are introduced as well. The over- 44 45 with related vocabularies such as the Ontology of units all modular structure of the SSN ontology is described 45 46 of Measure (O&M) [12, 49], as well as extensions to in Sec.4. A general description of the new, simplified 46 47 SSN ontology is provided in Sec.5, along with ex- 47 48 amples and explanations for the changes from SSNX. 48 *Corresponding author. E-mail: [email protected]. 49 49 1In this paper SSNX will denote the 2011 version of the ontology Sec.6 and7 describe the horizontal and vertical on- 50 produced by the W3C Incubator, with SSN used for the new version tology modules that SSN imports or that are imported 50 51 standardized through W3C/OGC and described here. by SSN, respectively. We provide an overview of what 51 2 A. Haller et al. / The Modular SSN Ontology: A Joint W3C and OGC Standard
1 SSN is not intended to model in Sec.8, and report Drawing on considerable implementation and appli- 1 2 in Sec.9 on implementation evidence for SSN, which cation experience with SSNX, as well as with sensor 2 3 was crucial for it to become an OGC/W3C standard. and observation models and ontologies more broadly, 3 4 the new SSN ontology presented here is set out to ad- 4 5 dress changes in scope and audience, new technical de- 5 6 2. Original SSN and Antecedents velopments and shortcomings of the initial work. 6 7 One such significant change in the extent of the au- 7 8 The development of SSN and SOSA has been dience of SSN has been the emergence of lightweight 8 9 strongly influenced by the SSNX ontology [36] and vocabularies such as schema.org and their increasing 9 10 models from the OGC’s Sensor Web Enablement ini- use on the Web [20] since SSNX had been published. It 10 11 tiative (SWE) [5]. led to a requirement to provide a lightweight ontology 11 12 Starting in 2002 SWE developed a generic frame- with minimal ontological commitment [32, §5.22], the 12 13 work for delivering sensor data. The Sensor Observa- SOSA core, that can be used by Web developers to an- 13 14 tion Service defines a HTTP query interface for sen- notate their IoT APIs using simple serialization for- 14 15 sor and observation data [8], following the pattern suc- mats such as JSON-LD, Microdata or RDFa 1.1 with- 15 16 cessfully established by OGC starting with the Web out the need to import any other ontology, including 16 17 Map Service [16]. Returned data conforms with the upper level ontologies (as required by SSNX). 17 18 Sensor Model Language (SensorML) [6] and with the New technical developments included particularly 18 19 XML implementation of O&M [12, 49]. SensorML the emergence of complex actuation devices on the 19 20 and O&M provide complementary viewpoints. Sen- Web of Things, such as home automation devices like 20 21 sorML is ‘provider-centric’ and encodes details of the Google Nest, personal assistants like Amazon Echo, 21 22 sensor along with a stream of (typically) raw observa- Apple Siri or Microsoft Cortana and personal camera 22 23 tion data. In contrast, O&M was designed to be more drones. To be able to model the smart instrumentation 23 24 ‘user-centric’, with the target of the observation and of these devices and the environments they operate in 24 25 the observed property as first-class objects. more generally, the actuator and actuation perspective 25 26 A key aspect of the O&M model is that it separately has been added to SSN. 26 27 defined classes for the description of the observation The sections below highlights these significant 27 28 event, the real world feature of interest being observed, changes and some of the other changes in the new 28 29 and the platform, procedure and/or system responsi- SOSA/SSN ontology. 29 30 ble for the observation. Geometries or other spatial 30 31 location properties can be attached separately to fea- 31 32 tures of interest, observations, platforms, and sensors, 3. Observation, Sampling and Actuation events 32 33 so the model can accommodate remote sensing and ex- 33 34 situ observation scenarios alongside in-situ monitoring Following the working group’s Use Cases and Re- 34 35 [32, §5.16][13, 26]. O&M also includes a model for quirements analysis [32], the scope of the revised on- 35 36 sampling, since most practical observations are made tology has first been reduced by removing the con- 36 37 on a subset of, or proxy for, the ultimate feature of in- cepts for stimulus, systems, measurement and system 37 38 terest. capabilities from the core (either for reasons of lack of 38 39 O&M is only one of several similar conceptual implementation evidence or in response to a require- 39 40 models for observations and their results. A selection ment [32, §5.47]), then expanded beyond sensors and 40 41 of these, also including OBOE [43], Sensei [2] and their observations by including classes and properties 41 42 Seronto [55], were reviewed by the W3C Semantic for the closely linked concepts of actuation [32, §5.16] 42 43 Sensor Network Incubator Group, and guided the de- and sampling [32, §5.16]. 43 44 velopment of the SSNX ontology [36]. Figure1 provides an overview of the classes and 44 45 The SSNX ontology was ultimately built around a properties in the core of the SSN ontology, showing 45 46 fundamental conceptual model implemented as an on- how the three applications use the same pattern. 46 47 tology design pattern called the Stimulus Sensor Ob- 47 48 servation (SSO) pattern [29] that was aligned to the 3.1. Sensors and Observations 48 49 Dolce-Ultralite upper ontology (DUL) [45]. SSO was 49 50 intended to provide a minimal common ground for on- The core of the SSNX ontology placed the sensor 50 51 tologies for the use on the Semantic Sensor Web. stimulus as the critical ’event’ in the observation pro- 51 Figure 1
A. Haller et al. / The Modular SSN Ontology: A Joint W3C and OGC Standard 3
1 observes 1 implements implementedBy Actuator 2 isObservedBy forProperty ActuatableProperty 2 Procedure Sampler 3 ObservableProperty 3 Sensor 4 usedProcedure 4 observedProperty hasProperty 5 madeBySensor 5 madeBySampler actsOnPropoerty 6 madeByActuator 6 7 7 madeObservation 8 madeSampling 8 9 madeActuation 9 isPropertyOf 10 Actuation 10 11 xsd:dateTime Sampling FeatureOfInterest 11 resultTime isFeatureOfInterestOf hasFeatureOfInterest 12 Observation 12 13 time:TemporalEntity isSampleOf 13 phenomenonTime isResultOf 14 Result 14 15 hasResult 15 16 hasSimpleResult 16 Sample 17 rdfs:Literal hasSample 17 18 18 19 Fig. 1. Overview of the core structure of the SSN ontology, emphasizing the common patterns used by the three activities with classes stacked 19 20 where they play a similar role. The elements shown are from both SOSA and SSN modules, with classes and types from external vocabularies 20 21 indicated with a namespace prefix and uncolored. Classes and properties in blue relate to observations, red to sampling, and green to actuation, 21 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 are 22 22 shown in this figure. 23 23 24 cess. Observations have therefore been modelled as a the event-oriented O&M pattern used in INSPIRE im- 24 25 social construct (oldssn:Observation v dul:Situation), plementations2. Furthermore, it provides a pattern and 25 26 i.e. observations were contexts for interpreting incom- terminology that can be used analogically for sampling 26 27 ing stimuli and fixing parameters such as time and and actuation activities. 27 28 location. While this is sound conceptual modeling, In the process of separating SSN from DUL, also 28 29 29 in practice the stimulus class was rarely instantiated. the semantics of the sosa:Sensor class has been recon- 30 30 This is because a stimulus triggers the sensor to per- sidered. SSNX has been criticized for its partially in- 31 31 form an observation, and, thus, resides outside the consistent handling of virtual sensors (including soft- 32 32 scope of typical sensor and observation applications ware and simulations) and related classes and proper- 33 33 and use cases. In subsequent work focusing on the ties. In particular, the comment in the oldssn:Sensor 34 34 alignment of SSNX with the W3C Provenance ontol- class suggested that a sensor can also be “computa- 35 35 tional methods, a laboratory setup with a person fol- 36 ogy [34] the absence of a class representing an ob- 36 lowing a method, or any other thing that can follow 37 servation as an ’act of sensing’ was noted [10, 14]. 37 a Sensing Method to observe a Property”. However, 38 The revised model focuses on the complete observa- 38 the oldssn:Sensor class was defined as a subclcass 39 tion as an event (sosa:Observation v dul:Event), com- 39 of dul:PhysicalObject, making the comment inconsis- 40 pleted when the result is available, i.e. acts of carry- 40 tent with the class definition. SOSA/SSN addresses 41 ing out an (observation) procedure in order to esti- 41 this issue (and requirement §5.19 [32]) by allowing 42 mate or calculate a value of a sosa:ObservableProperty 42 all major classes to be virtual, allowing humans and 43 of a sosa:FeatureOfInterest or a sosa:Sample thereof. 43 other animals as agents that perform observations, ac- 44 This modelling is aligned with other standard 44 tuation, or sampling activities. In the optional align- 45 ontologies such as the OGC Observations and 45 ment to DUL, sosa:Sensors, but also sosa:Platforms, 46 Measurements [13, 26] (i.e. sosa:Observation ≡ 46 and ssn:Systems are now defined as a subclass of the 47 so19156-om:OM_Observation) and the PROV 47 higher-level dul:Object class rather than the more spe- 48 Ontology (i.e. sosa:Observation v prov:Activity) where 48 cific dul:PhysicalObject class. 49 entities (i.e. sosa:Sensors in SSN) perform activities 49 50 (i.e. sosa:Observations in SSN). The new model is 50 51 also in line with the view of most practitioners, e.g., 2https://inspire.ec.europa.eu/id/document/tg/d2.9-o%26m-swe 51 4 A. Haller et al. / The Modular SSN Ontology: A Joint W3C and OGC Standard
1 The SOSA pattern models sosa:Sensors as en- more generic definition that allows it to be used for acts 1 2 tities that make sosa:Observations about some of observation, sampling or actuation (see Sec. 5.3). 2 3 sosa:ObservableProperty of a sosa:FeatureOfInterest. 3 4 From the viewpoint of foundational ontologies such 3.2. Samplers and Sampling 4 5 as DOLCE [18], endurants participate in perdurants. 5 6 Consequently, the sensors, features of interest, sam- Almost all observations make use of sampling 6 7 ples, and so forth participate in the observation event in strategies to connect an observation event with its ul- 7 8 different roles. For instance, a sensor (typically) trans- timate feature of interest, even if the sample and sam- 8 9 forms a stimulus into a result thereby also setting the pling event are not explicitly described. Nevertheless, 9 10 temporal bounds (start and end) of an observation. The support for explicit modelling of samples and sam- 10 11 feature of interest is the bearer of the property un- pling is sometimes a design requirement, particularly 11 12 der consideration, and so on. To improve readability in scientific applications. The SOSA ontology includes 12 13 13 and to stay in line with the literature about sensors sosa:Sampler that makes a sosa:Sampling of some 14 14 and observations we will say that a sensor triggered, sosa:FeatureOfInterest to produce a sosa:Sample.A 15 15 initiated, performed, or took, an observation about a sosa:Sample is both a sosa:FeatureOfInterest and a 16 16 property of some feature instead of speaking about en- sosa:Result of sosa:Sampling. 17 17 durants and their participation in perdurants. Finally, it For example, Listing 3.2 describes an act of sam- 18 18 is also important to differentiate between the concep- pling using a spade to obtain a soil sample from the 19 19 tual model of an observation as an event and the data garden of our example house #134. 20 20 models and data structures used to represent such an 21 21 22 observation as a record in a database, e.g., as served Listing 3.2: Sampling Modelling 22 by a semantically-enabled Sensor Observation Service 23 @prefix geow3c: 23 24 (SOS) [24, 28].
1 1 2017-11-15T14:35:13Z 23.9 DEG _:b2 electricityConsumption 2 2 sosa:Procedure _:b1 sosa:hasSimpleResult sosa:Observation 3 ssn:hasOutput 3
4 2017-04-16T00:00:12+00:00 sosa:phenomenonTime airTemperature 4 5 sosa:resultTime sosa:resultTime sosa:hasResult sosa:observedProperty summingHourlyConsumptionProcedure 5 sosa:madeActuation 6 sosa:observes 6 windowCloser/987 ssn:forProperty ssn:implements observation/235728 sosa:observes 7 actuation/188 observation/235716 7 observation/235715 sensor/926 8 ssn:forProperty observation/235714 sosa:observes 8 sensor/927 sosa:isActedOnBy sosa:Actuator 9 sosa:hosts electricConsumption 9 window/104#state sosa:ActuatableProperty sosa:madeBySensor 10 10 sosa:hasFeatureOfInterest sosa:observedProperty 11 sosa:Platform nest/D1AA22A8211 11 ssn:hasProperty sosa:madeBySensor 22.4 kWh 12 window/104 sosa:FeatureOfInterest sosa:hasFeatureOfInterest 12
house/134/bedroom 13 floralCouch observation/235727 sosa:hasSimpleResult 13 14 sosa:isSampleOf 14 roofInsulation DHT22/2 sosa:hasResult house/134 15 sosa:hasFeatureOfInterest 15 sosa:isSampleOf sosa:hosts sosa:Observation Observation/235727/result 16 house/134/kitchen 16
17 sample/134g1 sosa:hosts PCBBoard2 sosa:Sensor 17 ssn:deployedOnPlatform sosa:Sample 18 sosa:isSampleOf 18 ssn:deployedSystem house/134/deployment ssn:System 19 house/134/garden 19 sosa:Sampling DHT22/1 20 ssn:deployedSystem 20 sosa:hasFeatureOfInterest ssn:Deployment 21 sosa:hasFeatureOfInterest sosa:hosts 21 sosa:hasResult sampling/4650 sosa:hosts 22 observation/s1/5 sampling/4578 sosa:Procedure 22 PCBBoard1 23 sosa:usedProcedure 23 sosa:observedProperty sosa:madeBySampler 24 24 sosa:Observation soil-pH trowel 25 procedure/soil-organic-fraction/78 25 26 26 27 Fig. 2. Example smart house modelled using SOSA/SSN. Black boxes indicate SOSA/SSN classes, dashed boxes indicate class instances, solid 27 lines represent rdf:type relations and dashed lines instances of properties. 28 28 29 29 Listing 3.4: Sample Modelling sosa:Actuations on some sosa:ActuatableProperty of a 30 30 sosa:FeatureOfInterest. 31
1 Location and other spatial properties of these entities 1 2 may also be defined according to application- or 2 3 community-specific models, which in turn make 3 4 use of appropriate geospatial ontologies such as 4 5 GeoSPARQL [47]. 5 6 6 7 7 8 8 4. Modularization 9 9 10 10 11 Practitioners using the SSNX ontology have identi- 11 12 fied the complexity of both the ontology and its doc- 12 13 umentation as a significant usability issue. For exam- 13 14 ple, SSNX imported the Dolce-Ultralite upper ontol- 14 15 ogy (DUL) [45] and many SSNX terms inherited se- 15 16 mantics from their parent DUL terms. The DUL align- 16 17 ment contributed a level of complexity and abstraction 17 18 which affected adoption in some communities. More 18 19 generally, the monolithic ontology design of SSNX Fig. 3. SOSA/SSN ontologies "vertical" and "horizontal" modular- 19 20 that introduces all terms within one ontology while ization. Horizontal breadth of coverage is shown by arcuate mod- 20 ules at the same radius. Vertical height of expressivity is shown by 21 also relying on the import of the Dolce-UltraLite on- 21 modules at a larger radius 22 tology, makes it difficult for users to focus on just those 22 23 entities needed for a particular implementation. In re- mal semantics to SOSA properties.5 SOSA also avoids 23 24 sponse to this, the new SSN ontology is factored into any subclass and subproperty axioms. The motivation 24 25 several ontology subsets or modules that are similar in for these choices is to make SOSA simple enough to be 25 26 their domain of discourse and directly import one an- incorporated as is in the schema.org extension for IoT.6 26 27 other as needed but differ in their ontological commit- SOSA as the core, does not import any other ontolo- 27 28 ments and/or scope of coverage in order to suit differ- gies, so is truly independent of vertical modules that 28 29 ent use cases and target audiences. The core module in add more terms, expressivity, and further ontological 29 30 particular, SOSA, is intended for data repositories and commitments to the lightweight semantics of SOSA. 30 31 websites managed by web or data managers who need The SSN module imports SOSA, and adds full 31 32 neither extensive axiomitization nor more specialized axiomatization to the SOSA classes and proper- 32 33 33 entities. ties, including rdfs:subClassOf, rdfs:subPropertyOf, 34 34 Modularization has been accomplished by way of owl:disjointWith and OWL cardinality and guarded ex- 35 two types or directions of ontology segmentation as istential restrictions on a class-level, along with some 35 36 shown in Fig.3. further classes and properties to complete the basic 36 37 conceptual model corresponding approximately to the 37 38 38 4.1. Vertical Segmentation scope offered by SSNX. 39 In line with the changes implemented for the new 39 40 SSN, alignment between SSN terms and DUL terms 40 41 Vertically segmented SSN modules add higher lev- 41 els of ontological commitment by directly import- was reconsidered and externalized to an optional verti- 42 cal module called the Dolce-Ultralite Alignment mod- 42 43 ing lower modules and defining new axioms. The 43 lower level modules are independent of the higher ule (SSN-DUL) that is available at http://www.w3.org/ 44 ns/ssn/dul. Those axioms in SSN that include DUL 44 45 level modules, and logically consistent by them- 45 terms have been separated into the SSN-DUL mod- 46 selves. The core SOSA module defines the key 46 47 classes and properties but axiomatization is delib- 47 5 48 erately limited. In particular, SOSA uses no ob- See https://www.w3.org/2015/spatial/wiki/Domain,_Range, 48 _InverseOf for pointers to the group discussions on this topic. 49 ject property rdfs:domain or rdfs:range axioms. In 49 6The Spatial Data on the Web group endorses SOSA being taken 50 place of these, schema.org schema:domainIncludes up by schema.org, see thread https://lists.w3.org/Archives/Public/ 50 51 and schema:rangeIncludes annotations provide infor- public-sdw-wg/2017Jun/0067.html 51 A. Haller et al. / The Modular SSN Ontology: A Joint W3C and OGC Standard 7
1 ule. The Dolce-UltraLite Alignment Module imports soners [33, 46, 51], while that of the new SSN is 1 2 the Dolce-UltraLite Ontology and the Sample rela- ALRIN (D). In contrast, the expressivity of SSNX is 2 3 tions module, which in turn imports the SSN On- SRIQ. Table1 provides some key facts to compare 3 4 tology, and thereby transitively the SOSA Ontol- SOSA and SSN to SSNX. 4 5 ogy. However, neither SOSA nor SSN import the 5 6 Dolce-UltraLite Alignment Module in reverse. The 6 7 SSN-DUL alignment module has been defined for Ontology SOSA SSN SSNX 7 8 backwards-compatibility reasons only and SSN (and Classes 13 6 41 8 9 SOSA) can now be used entirely independently of Object properties 21 15 39 9 10 DUL. In fact, we are not anticipating the use of this Datatype properties 2 0 0 10 7 11 alignment in applications other than the one’s that are Tot. logical axioms 13 127 1011 11 12 migrated from the old ontology. DL expressivity ALI(D) ALRIN (D) SRIQ 12 Table 1 13 Additional vertical modules (see Sec.7 axioma- 13 Number of classes, object properties, and datatype properties, de- 14 tize alignments with other related ontologies, includ- 14 fined in SOSA, SSN, and SSNX (for comparison); DL expressivity 15 15 ing O&M [13, 26], OBOE [43] and PROV-O [34]. of these ontologies. 16 16 17 4.2. Horizontal Segmentation 17 18 18 Terms defined by the core SOSA ontology are iden- 19 Modules that are horizontally layered may depend 19 20 on each other, i.e., they may rely on the import of tified by URIs under the namespace http://www.w3. 20 21 another horizontal module, but only extend scope by org/ns/sosa/, while those defined by the SSN ontol- 21 22 adding classes and properties, and do not otherwise en- ogy are identified by URIs under the namespace http: 22 23 rich the semantics of existing terms. Two horizontal //www.w3.org/ns/ssn/. In the rest of this article, we 23 24 modules are defined in SSN (see Sec. 6.1): the Sample shorten these namespaces with the following prefixes 24 25 Relations Module and the System Capabilities Mod- (that are registered at http://prefix.cc). 25 26 ule. 26 @prefix sosa:
1 a sosa:FeatureOfInterest, which reflects a terminology to find the ultimate feature of interest for the ob- 1 2 heritage from OGC8. servation. In Listing 5.2, which continues the exam- 2 3 The property sosa:hasFeatureOfInterest is ple introduced in Sec.3, we can infer that the ulti- 3 4 used to link between a sosa:Observation and mate feature of interest is in fact the garden denoted 4 5 its associated sosa:FeatureOfInterest. This re-
22
1 other hand, we consider that multiple observations Listing 5.6: Generalised Property Modelling 1 2 2 across different features of interest or by different sen- @prefix qudt:
1
1 If the result of an observation is a web document 5.4. Results 1 2 having some representation (e.g., in JSON or XML) 2 3 other ontologies such as the RDF Presentation ontol- SSN offers two ways of attaching properties to ac- 3 4 ogy12 [37] or RaUL [23] can be used to model the re- tivities that observe, actuate or sample them. For sim- 4 5 sult using the ssn:hasOutput relation of SSN. It links ple (though frequent) cases that merely require a lit- 5 6 the output of an observation to a description of how eral typed with an appropriate datatype, one may use 6 7 a result document can be validated (e.g., using some the sosa:hasSimpleResult datatype property. Alterna- 7 8 JSON Schema), or how an RDF description can be ob- tively, observation results can be modeled as individu- 8 9 tained from it (using some RDF lifting rule such as als and linked to the observation using the object prop- 9 10 [39, 48] as shown in Listing 5.11). erty sosa:hasResult. In cases where the observed prop- 10 11 erty is a physical quantity, one may then use one of the 11 12 Listing 5.11: Validation Rule Modelling several existing ontologies to model the result. 12 13 13 @prefix rdfp:
1 result of this observation that was required in ]; 1 2 14 time:hasEnd[ 2 SSNX . Compatibility with SSNX (see Sec. 7.4) a time:Instant; 3 is obtained through both oldssn:SensorOutput and time:inXSDDateTimeStamp 3 4 "2017-04-16T00:00:00+00:00"^^xsd:dateTimeStamp 4 oldssn:ObservationValue being subclasses of the new ] 5 sosa:Result, and oldssn:observationResult being a ]. 5 6 subproperty of ssn:hasResult. 6 7 There have been discussions in the working group The distinction between sosa:resultTime and 7 8 on potential actuation commands15, but their inclusion sosa:phenomenonTime is important where the end 8 9 has been deemed out of scope for the current version of the observation, actuation, or sampling, activity is 9 10 of SSN. significantly different from that of the phenomenon 10 11 that is observed or acted on. The separation covers 11 12 5.4.2. Result of a Sampling activity cases involving observations over a long period of 12 13 sosa:Sample is a subclass of sosa:Result be- time, late results due to long-lasting procedures, 13 14 cause a sample is the result of a sosa:Sampling ac- delays due to lengthy information travel (e.g., in- 14 15 tivity. This is in addition to being a subclass of formation traveling long distances), cases where the 15 16 sosa:FeatureOfInterest so that it can serve as the target result describes the state in the distant past (e.g. 16 17 of a sosa:Observation. observations that described the pressure and tem- 17 18 5.4.3. Result Time and Phenomenon Time perature of a mineral at its time of formation), and 18 19 SOSA distinguishes between the predictions and forecasts - which may be defined 19 20 sosa:phenomenonTime and sosa:resultTime, the as observations with a sosa:resultTime before the 20 21 former being the time that the result of an observa- sosa:phenomenonTime [13, 22, 26, §7.2]. In both 21 22 tion, actuation, or sampling applies to the feature of of the last two cases, it is common to have multiple 22 23 interest, while the latter specifies the instant of time observations relating to the same feature of interest, 23 24 when an act, such as an observation, was completed. observed property and phenomenon time, but with 24 25 The sosa:resultTime is a datatype property with different result times. For example, different proce- 25 26 rdfs:range xsd:dateTime to capture the time instant dures might be used in different geology labs. And 26 27 that the activity completed and the result obtained. the results of forecasts obtained using computational 27 28 The sosa:phenomenonTime is an object property with procedures might later be subject to validation by 28 29 range time:TemporalEntity [15], since it may be either instrumental observations. The outcome of the latter 29 30 an instant or interval, or even a temporal complex. would be encoded as sosa:Observations with the same 30 31 For example, Listing 5.15 describes that the temper- sosa:hasFeatureOfInterest, sosa:observedProperty, 31 32 ature was observed through April 15th 2017, and that and sosa:phenomenonTime, as the forecast, but with 32 33 the result was available 12 seconds after the end of this a different sosa:usedProcedure, sosa:madeBySensor 33 34 period. and sosa:resultTime. 34 35 35 36 5.5. Systems and their deployments 36 37 Listing 5.15: Phenomenon Time Modelling 37 38 @prefix time:
1 similar reasons, the notion of a sampling device has 5.5.3. Deployment 1 2 been dropped16. An ssn:Deployment is an activity or a set of activi- 2 3 ties that encompass all phases in the lifecycle of a de- 3 5.5.1. Platforms and hosts 4 ployed system, such as, the installation, maintenance 4 One or more sensors (as well as actuators and sam- 5 and decommissioning of the platform, sensors, actu- 5 plers) can be hosted or mounted on a sosa:Platform. 6 ators or samplers attached to that system. The class 6 Such platforms can also define the geometric prop- 7 of ssn:Deployment describes the deployment of one 7 erties, i.e., placement, of sensors in relation to 8 or more systems (ssn:deployedSystem) or platforms 8 one another. sosa:Platforms can also host other 9 (ssn:deployedOnPlatform) for a particular purpose. For 9 10 sosa:Platforms. example, a temperature sensor deployed on a wall, or a 10 11 The properties oldssn:attachedSystem and whole network of sensors deployed for an observation 11 12 oldssn:onPlatform have been renamed to sosa:hosts campaign. 12 13 and sosa:isHostedBy, respectively, and they can Listing 5.17 shows an example of how to model a 13 sosa:Platform 14 now be used on both, the and the deployment (i.e.
1 system capabilities, operating range, and survival normal temperature and humidity 1 2 conditions."@en; 2 range. This part of SSNX was rarely used in im- schema:value 0.1 ; 3 plementations, hence specific effort has been made schema:unitCode qudt-unit-1-1:DegreeCelsius. 3 4 to clarify and simplify its documentation, along with 4 5 providing illustrative examples. Terms defined by the The Terms ssn-system:SystemCapability and ssn- 5 6 SSN-System ontology are identified by URIs un- system:SystemProperty are named after the SSNX 6 7 der the namespace http://www.w3.org/ns/ssn/systems/. oldssn:SensorCapability and oldssn:SensorProperty 7 8 We shorten this namespace with prefix ssn-system:. terms, that were generalized so that the new ones 8 9 apply to the more general concept of ssn:System 9 10 @prefix ssn-system: 18 10
1 6.1.3. Extensibility of the System Capabilities Module Listing 6.2: Sub-Sample Modelling 1 2 2 As a matter of fact, the SSN System Capabilities
1 alignment to OGC O&M is provided as a vertical mod- Thus, the alignment expresses this as a property- 1 2 ule which owl:imports SOSA, and uses the URI scheme chain axiom: oboe:measurementFor ◦ oboe:ofEntity v 2 3 defined by ISO 19150-2 to denote the O&M classes sosa:hasFeatureOfInterest. 3 4 and properties [27]. 4 5 The main conceptual difference between SSN and 7.4. Alignment to the Old SSN Ontology 5 6 O&M is that the latter conflates both Procedures 6 7 and Systems into a pair of classes: OM_Process It is strongly recommended that applications that 7 8 and SF_Process. Alignment is achieved by way of use the SSNX ontology are migrated to the new 8 9 the following axiom: iso19156-om:OM_Process ≡ SSN ontology published at: http://www.w3.org/ns/ 9 10 sosa:Sensor t sosa-om:ObservationProcedure where ssn/. However, for legacy applications that continue to 10 11 sosa-om:ObservationProcedure v sosa:Procedure. use SSNX, a new version of that ontology has been 11 12 Some other entities and properties of O&M, such as published at the old namespace: http://purl.oclc.org/ 12 13 validTime, are not presently mapped to any terms of NET/ssnx/ssn. This new version has been updated as 13 14 SOSA/SSN. follows: 14 15 15 – some errors with the previous version, such as the 16 7.2. Alignment to PROV-O 16 outdated import location for the DUL ontology, 17 17 have been fixed; 18 The re-orientation of SSN so that observations (as 18 – all axioms that pertain to the alignment of the 19 well as samplings and actuations) are activities or “acts 19 SSNX to the Dolce-UltraLite ontology have been 20 of sensing | sampling | actuation” means that SSN now 20 removed and an import of the DUL alignment 21 clearly matches a process-flow model. This makes an 21 module http://www.w3.org/ns/ssn/dul has been 22 alignment with PROV-O [34] quite natural, as fore- 22 added instead; 23 seen in [10, 14]. A formal (axiomatized) alignment 23 – and mapping relations to the new SSN through 24 to PROV-O is provided as a vertical module which 24 owl:equivalentClass, owl:equivalentProperty and 25 owl:imports SOSA and PROV-O. The key alignments 25 owl:subClassOf axioms have been added, while 26 are: 26 owl:deprecated annotation properties have been 27 27 1. sosa:Observation v prov:Activity added to terms that were removed in the new SSN. 28 28 sosa:Sampling v prov:Activity 29 The June 2011 version of SSNX remains avail- 29 sosa:Actuation v prov:Activity; 30 able at https://www.w3.org/2005/Incubator/ssn/ssnx/ 30 2. ssn:System v prov:Agent u prov:Entity 31 ssn, where either an HTML (ssn.html) or an RD- 31 sosa:Sensor v prov:Agent u prov:Entity 32 F/XML (ssn.owl) representation will be served by the 32 sosa:Sampler v prov:Agent u prov:Entity 33 W3C server depending on the client preferences. 33 sosa:Actuator v prov:Agent u prov:Entity. 34 34 35 The latter merits a little more explanation. When 35 36 participating in an act of observation, sampling or ac- 8. Topics out of Scope for SSN 36 37 tuation the sensors, samplers or actuators are respon- 37 38 sible for the activity, so are thus agents. When not in- While the reworked SSN has achieved most of 38 39 volved in the activity, they are merely entities which the goals set by the Charter and the Working Group 39 40 have to be maintained or stored. chairs [54], and more, there are some concepts that are 40 41 relevant to the intended scope of SSN but are not in- 41 42 7.3. Alignment to OBOE cluded in any of the present SOSA/SSN modules. 42 43 Since the publication of SSNX [36], the authors 43 44 The OBOE ontology [43] is used by parts of the bio- have been collecting feature requests from the user 44 45 diversity community in particular to represent obser- community. Early in the standardization process the 45 46 vations of traits or characteristics of organisms. A for- Working Group members were asked to solicit and 46 47 mal (axiomatized) alignment to OBOE is provided as a document use cases from which requirements were de- 47 48 vertical module which owl:imports SOSA and OBOE. rived and published by the W3C and OGC [41]. Of 48 49 In OBOE a set of oboe:Measurements of different the 28 requirements for SSN noted there, 10 relate to 49 50 characteristics relating to the same entity (usually an the representation of temporal and spatial aspects of 50 51 organism) are grouped into a single oboe:Observation. sensors and their observations. Like SSNX before it, a 51 A. Haller et al. / The Modular SSN Ontology: A Joint W3C and OGC Standard 17
1 decision was made to defer to external ontologies for (sensing, actuating, forecasting, some algorithm) and 1 2 such modelling, and this is consistent with the advice make pep:ProcedureExecution activities (observation, 2 3 of the Working Group in its Best Practice publication actuation, web service execution, forecast), which may 3 4 [52], which identifies some suitable ontologies rang- then be linked to some description of the command 4 5 ing from W3C-BASIC-GEO [7] to GeoSPARQL [47]. and/or the result. 5 6 Although this omission from SSN will have the effect 6 7 of making SSN harder to use, and perhaps too lightly 7 8 passes off demanding requirements for streaming mea- 9. Evaluation of Implementation Evidence 8 9 surements, mobile sensors and compact time series, 9 10 there is no ideal single answer to this need. These re- Since its publication in 2011 the SSNX ontology has 10 11 quirements may be well served by followup primer been used in many IoT applications, linked datasets 11 12 publications currently planned, in preference to ontol- and ontologies. Examples of its use in linked datasets 12 13 ogy extension. include meteorological models from the Spanish Me- 13 14 Two requirements are met simply by virtue of the teorological Office [1], a case study on environmen- 14 15 choice of a Web Ontology Model for SSN, and three tal sensing and livestock monitoring published by 15 16 others have been met by preserving SSNX capabilities. CSIRO [53], long-term climate observation data pub- 16 17 Nine have been met by the new work reported here. lished by the Australian Bureau of Meteorology [35], 17 18 Arguably, a requirement for verifiable profiles has been real-time passenger data in the GetThere smartphone 18 19 partly met by the modularization presented here, and app [11] and fault analysis and worker support for 19 20 a requirement for examples in concert with external cyber-physical production systems in a case study in 20 21 vocabularies has been met via the ontology mappings the German Industrie 4.0 initiative [56]. 21 22 and examples presented in the specification and here. The decision to formally standardize the SSN was 22 23 Multilingual annotation is being developed at present. a consequence of the interest expressed at a public 23 24 The requirement for aggregated observations has not workshop held in London in March 2015 https://www. 24 25 been specifically addressed. w3.org/2014/03/lgd/ and was managed through a joint 25 26 Other informally requested features that have not W3C-OGC working group. 26 27 been implemented include direct support for net- The use of SSN for data and applications pub- 27 28 works of sensors, such as device communications, net- lished openly on the Web has been documented 28 29 work structures, relations between sensors, or spe- in detail by the Spatial Data on the Web working 29 30 cific data discovery and exchange interfaces. Some group in a note published at: https://w3c.github.io/ 30 31 IoT-specific ontologies such as [3] and [4] (built on sdw/ssn-usage/. The list of usage of SSNX and SSN 31 32 SSNX) as well as [17], and APIs such as [40] do cover was obtained by crawling the LOD Laundromat, the 32 33 LOD Cloud Cache, LODStats and the LOV Ontology 33 some of these aspects. The recursive ssn:System class 34 repository, as well as through requests for implemen- 34 might be a starting point for network nodes, but net- 35 tation evidence on the Spatial Data on the Web work- 35 work relations would still be required. Such relations 36 ing group mailing list. During the development of the 36 could perhaps be modelled by extending the concepts 37 new SSN between March 2016 and October 2017, the 37 InteractionPattern and Link of the “Thing 38 working group collected implementation evidence of 38 Description” 19 standard being developed by the W3C 39 all old (but equivalent) and new SOSA/SSN terms in 39 Web of Things Working Group. 40 the same document [19]. Standardization of the SSN 40 The new terms for actuation do not include actua- 41 through the W3C required evidence of use of each term 41 tion commands (analogous to sensor capabilities for 42 in at least two consumer and two provider applications, 42 observations). Other ontologies could add these con- 43 i.e. applications or datasets that use SSN to describe 43 cepts as a vertical module. For example, the Proce- 44 their data and ontologies that extend SSN, respectively. 44 dure Execution ontology, one of the core modules of 45 At the time of its publication as a W3C candidate 45 the Smart Energy Aware Systems ontology [38] gen- 46 recommendation in July 2017, SOSA/SSN terms had 46 eralizes the core classes and properties of SSN to de- 47 been used in 23 open linked datasets, and 23 openly 47 scribe pep:ProcedureExecutor (sensor, actuator, web 48 published ontologies were known to use the SSN on- 48 service, etc.) that implement pep:Procedure methods 49 tology to either describe their data or extend the SSN 49 50 ontology, respectively. All terms have been used at 50 51 19https://www.w3.org/TR/wot-thing-description/ least once in a dataset and an ontology, while 87% of 51 18 A. Haller et al. / The Modular SSN Ontology: A Joint W3C and OGC Standard
1 terms have been used in at least two datasets and 81% vation, Sampler, and Actuator) as a replacement of 1 2 of all terms have been used in at least two ontologies. the initial Stimulus Sensor Observation (SSO) pat- 2 3 Community expectations were an important motiva- tern which is available at: http://www.w3.org/ns/sosa/. 3 4 tion for reconsideration of the core model. In particu- SOSA and SSN together can now be used to describe 4 5 lar, with the term “observation” now used for “event of sensors and their observations, the involved proce- 5 6 observation” this allows for closer alignment of SSN dures, the studied features of interest, the samples used 6 7 to the O&M model. As a consequence, the OGC com- to do so, the feature’s properties being observed or 7 8 munity is now examining adoption of SSN/SOSA for sampled, as well as actuators and the activities they 8 9 internet of things and linked data applications, for ex- trigger. 9 10 ample in the ELFIE 20 activity. SSNX has already been broadly accepted as a de- 10 11 The newly introduced sampling terms in SOSA are facto standard for representing sensor data on the Web 11 12 implemented in a register of several million geological and has been the inspiration for multiple ontologies 12 13 samples at Geoscience Australia that provides descrip- layered on top of SSNX. With the standardization of 13 14 tions using several alternative schemas and ontologies, the SSN and SOSA ontologies through the OGC and 14 15 including SOSA/SSN21. the W3C and the introduction of different modules for 15 16 Some datasets and ontologies using SSNX have al- different audiences, we expect the new ontology to be 16 17 ready been adapted to SOSA/SSN. For example, a used in even more varied use cases, especially in the 17 18 dataset of measurements of a meteorological station, Internet-of-Things domain. 18 19 Irstea owns in one of its experimental farms, between 19 20 2010 and 2015 and that has previously been described 20 21 using SSN [50] has since been updated to SOSA22. Acknowledgements 21 22 22 23 The SSN ontology was developed through the OGC/W3C 23 24 10. Conclusion Spatial Data on the Web Working Group, see https://www. 24 25 w3.org/2000/09/dbwg/details?group=75471&public=1 25 for the list of members. The efforts of W3C staff Phil 26 The W3C/OGC Spatial Data on the Web Working 26 Archer and François Daoust were invaluable in enabling the 27 Group has redesigned the SSNX ontology that was 27 successful completion of the work through to publication as 28 28 published through a W3C Incubator Group in 2011, a W3C Recommendation and OGC Standard. The authors 29 incorporated feedback from users of the ontology and acknowledge partial support from NSF (award number 29 30 extended it with terms to model sampling and actua- 1540849), CSIRO (Oznome project) and Marie Skodowska- 30 31 tion activities that have been identified as missing from Curie Programme H2020-MSCA-IF-2014 (SMARTER 31 32 the original ontology in many use cases. A new ver- project, under Grant No. 661180). 32 33 sion of the ontology has been published as an official 33 34 W3C recommendation and an OGC implementation 34 35 standard at: http://www.w3.org/ns/ssn/. References 35 36 The initial SSNX was perceived as too heavyweight 36 37 in its axiomatization, and too dependent on OWL rea- [1] G. A. Atemezing, Óscar Corcho, D. Garijo, J. Mora, 37 38 soning by some users. To strike a balance, the com- M. Poveda-Villalón, P. Rozas, D. Vila-Suero, and B. Villazón- 38 Terrazas. Transforming meteorological data into Linked Data. 39 39 plexity of the new SSN ontology has been reduced Semantic Web, 4(3):285–290, 2013. https://doi.org/10.3233/ 40 through a modularization that allows different user SW-120089. 40 41 groups to pick and chose terms of the ontology appro- [2] P. Barnaghi, S. Meissner, M. Presser, and K. Moessner. Sense 41 42 priate for their domain of discourse and also chose be- and sensability: Semantic data modelling for sensor networks. 42 43 tween different levels of axiomatization of the ontol- In Proceedings of the ICT Mobile Summit, pages 1–9, San- 43 tander, Spain, 2009. IIMC. 44 44 ogy. [3] M. Bermudez-Edo, T. Elsaleh, P. Barnaghi, and K. Taylor. 45 Another key novelty in the modularization of SSN IoT-Lite Ontology. W3C Member Submission, World Wide 45 46 has been the introduction of the lightweight and self- Web Consortium, nov 2015. http://www.w3.org/Submission/ 46 47 contained core pattern called SOSA (Sensor, Obser- iot-lite/. 47 48 [4] M. Bermudez-Edo, T. Elsaleh, P. Barnaghi, and K. Taylor. 48 IoT-Lite: A Lightweight Semantic Model for the Inter- 49 49 20http://www.opengeospatial.org/projects/initiatives/elfie net of Things. In Proceedings of the International IEEE 50 21http://pid.geoscience.gov.au/sample/ Conferences on Ubiquitous Intelligence Computing, Ad- 50 51 22http://ontology.irstea.fr/pmwiki.php/Site/Weather2017 vanced and Trusted Computing, Scalable Computing and 51 A. Haller et al. / The Modular SSN Ontology: A Joint W3C and OGC Standard 19
1 Communications, Cloud and Big Data Computing, Inter- [18] A. Gangemi, N. Guarino, C. Masolo, A. Oltramari, and 1 2 net of People, and Smart World Congress (UIC/ATC/Scal- L. Schneider. Sweetening ontologies with dolce. In 2 3 Com/CBDCom/IoP/SmartWorld), pages 90–97, Toulouse, Proceedings of the International Conference on Knowledge 3 France, July 2016. IEEE. https://doi.org/10.1109/ Engineering and Knowledge Management, pages 166–181, 4 4 UIC-ATC-ScalCom-CBDCom-IoP-SmartWorld.2016.0035. Siguenza, Spain, 2002. Springer. https://doi.org/10.1007/ 5 [5] M. Botts, G. Percivall, C. Reed, and J. Davidson. OGC 3-540-45810-7_18. 5 6 sensor web enablement: Overview and high level archi- [19] R. García-Castro, A. Haller, and N. Mihindukulasooriya. On 6 7 tecture. Technical Report OGC 07-165, Open Geospa- the usage of the SSN ontology. W3C Note, World Wide 7 8 tial Consortium, 2007. http://www.opengeospatial.org/ogc/ Web Consortium, November 2017. https://w3c.github.io/sdw/ 8 9 markets-technologies/swe. ssn-usage/. 9 [6] M. Botts and A. Robin. OGC SensorML: Model and XML [20] R. Guha, D. Brickley, and S. Macbeth. Schema.org: Evolution 10 10 Encoding Standard. OGC Encoding Standard, version 2.0, of structured data on the web. ACM Queue, 13(9), 2015. https: 11 Open Geospatial Consortium, Feb. 04 2014. http://www. //doi.org/10.1145/2857274.2857276. 11 12 opengeospatial.org/standards/sensorml. [21] A. Haller, E. Cimpian, A. Mocan, E. Oren, and C. Bussler. 12 13 [7] D. Brickley. Basic Geo (WGS84 lat/long) Vocabulary. Tech- WSMX - a semantic service-oriented architecture. In Proceed- 13 14 nical report, W3C Semantic Web Interest Group, 2006. https: ings of the International Conference on Web Services (ICWS), 14 //www.w3.org/2003/01/geo/. pages 321–328, Orlando, FL, USA, 2005. IEEE. https://doi. 15 15 [8] A. Bröring, C. Stasch, and J. Echterhoff. OGC Sensor Obser- org/10.1109/ICWS.2005.139. 16 vation Service Interface Standard. OpenGIS Implementation [22] A. Haller, K. Janowicz, S. J. D. Cox, D. Le Phuoc, K. Tay- 16 17 Standard, version 2.0, Open Geospatial Consortium, Apr. 16 lor, and M. Lefrançois. Semantic Sensor Network Ontology. 17 18 2012. http://www.opengeospatial.org/standards/sos. W3C Recommendation, World Wide Web Consortium, Oct. 19 18 19 [9] M. Compton, P. Barnaghi, L. Bermudez, R. García-Castro, 2017. https://www.w3.org/TR/vocab-ssn/. 19 20 Óscar Corcho, S. J. D. Cox, J. Graybeal, M. Hauswirth, [23] A. Haller, J. Umbrich, and M. Hausenblas. RaUL: RDFa User 20 C. Henson, A. Herzog, V. Huang, K. Janowicz, W. D. Kelsey, Interface Language – A Data Processing Model for Web Ap- 21 21 D. L. Phuoc, L. Lefort, M. Leggieri, H. Neuhaus, A. Nikolov, plications. In Proceedings of the 11th International Confer- 22 K. Page, A. Passant, A. Sheth, and K. Taylor. The SSN ontol- ence of Web Information Systems Engineering (WISE), pages 22 23 ogy of the W3C semantic sensor network incubator group. Web 400–410, Hong Kong, China, 2010. LNCS. https://doi.org/10. 23 24 Semantics: Science, Services and Agents on the World Wide 1007/978-3-642-17616-6_36. 24 25 Web, 17(0):25–32, 2012. https://doi.org/10.1016/j.websem. [24] C. A. Henson, J. K. Pschorr, A. P. Sheth, and K. Thirunarayan. 25 2012.05.003. SemSOS: semantic sensor observation service. In Proceedings 26 26 [10] M. Compton, D. Corsar, and K. Taylor. Sensor data prove- of International Symposium on Collaborative Technologies 27 nance: SSNO and PROV-O together at last. In Joint Proceed- and Systems (CTS’09), pages 44–53, Baltimore, MD, USA, 27 28 ings of the 6th International Workshop on the Foundations, 2009. IEEE. https://doi.org/10.1109/CTS.2009.5067461. 28 29 Technologies and Applications of the Geospatial Web and 7th [25] R. Hodgson, D. Mekonnen, D. Price, J. Hodges, J. E. Mas- 29 30 International Workshop on Semantic Sensor Networks, volume ters, S. J. D. Cox, and S. Ray. Quantities, Units, Dimensions 30 31 1401, pages 1–16, Riva del Garda, Italy, 2014. CEUR. and Types (QUDT) Schema - Version 2.0. Technical report, 31 [11] D. Corsar, P. Edwards, J. Nelson, C. Baillie, K. Papangelis, qudt.org, Jan. 2017. 32 32 and N. Velaga. Linking open data and the crowd for real- [26] ISO. ISO 19156:2011 Geographic information - Observations 33 time passenger information. Web Semantics: Science, Services and measurements. International Standard, ISO, Dec. 2011. 33 34 and Agents on the World Wide Web, 43(Supplement C):18–24, [27] ISO. ISO 19150-2:2015 Geographic information - Ontology – 34 35 2017. https://doi.org/10.1016/j.websem.2017.02.002. Part 2: Rules for developing ontologies in the Web Ontology 35 36 [12] S. J. D. Cox. Observations and Measurements - XML Language (OWL). International Standard, ISO, July 2015. 36 Implementation. OGC Encoding Standard, Version 2.0, [28] K. Janowicz, A. Bröring, C. Stasch, S. Schade, T. Everding, 37 37 Open Geospatial Consortium, Mar. 22 2011. http://portal. and A. Llaves. A RESTful proxy and data model for linked 38 38 opengeospatial.org/files/?artifact_id=41510. sensor data. International Journal of Digital Earth, 6(3):233– 39 [13] S. J. D. Cox. Geographic information - Observations and 254, 2013. https://doi.org/10.1080/17538947.2011.614698. 39 40 measurements. OGC Abstract Specification, Version 2.0, [29] K. Janowicz and M. Compton. The stimulus-sensor- 40 41 Open Geospatial Consortium, Sept. 17 2013. http://portal. observation ontology design pattern and its integration into the 41 42 opengeospatial.org/files/?artifact_id=41579. semantic sensor network ontology. In Proceedings of the 3rd 42 [14] S. J. D. Cox. Ontology for observations and sampling features, International Workshop on Semantic Sensor Networks, volume 43 43 with alignments to existing models. Semantic Web, 8(3):453– 668, pages 64–78, Shanghai, China, 2010. CEUR. 44 470, 2017. https://doi.org/10.3233/SW-160214. [30] K. Janowicz, A. Haller, S. Cox, D. Le Phuoc, and 44 45 [15] S. J. D. Cox and C. Little. Time ontology in OWL. W3C M. Lefrançois. SOSA: A lightweight ontology for sensors, ob- 45 46 Recommendation, World Wide Web Consortium, Oct. 2017. servations, samples, and actuators. Journal of Web Semantics, 46 47 https://www.w3.org/TR/owl-time/. In Press. https://doi.org/10.1016/j.websem.2018.06.003. 47 48 [16] J. de la Beaujardiere. OpenGIS Web Map Server Implemen- [31] R. Kitchin. The real-time city? Big data and smart urban- 48 tation Specification. OpenGIS Implementation Specification, ism. GeoJournal, 79(1):1–14, 2014. https://doi.org/10.1007/ 49 49 Open Geospatial Consortium, Mar. 15 2006. version 1.3.0. s10708-013-9516-8. 50 [17] D. P. et al. Spitfire: Toward a semantic web of things. IEEE [32] F. Knibbe and A. Llaves. Spatial Data on the Web Use 50 51 Communications Magazine, 49(11):40–48, 2011. Cases & Requirements. W3C Note, World Wide Web 51 20 A. Haller et al. / The Modular SSN Ontology: A Joint W3C and OGC Standard
1 Consortium, Oct. 25 2016. https://www.w3.org/TR/2016/ [47] M. Perry and J. Herring. OGC GeoSPARQL - A Geographic 1 2 NOTE-sdw-ucr-20161025/. Query Language for RDF Data. OGC Implementation Stan- 2 3 [33] M. Krötzsch. OWL 2 Profiles: An Introduction to Lightweight dard 11-052r4, OGC, Sept. 2012. 3 Ontology Languages, pages 112–183. LNCS, Vienna, Austria, [48] A. Polleres, T. Krennwallner, N. Lopes, J. Kopecký, 4 4 2012. https://doi.org/10.1007/978-3-642-33158-9_4,. and S. Decker. XSPARQL Language Specification. 5 5 [34] T. Lebo, S. Sahoo, and D. McGuiness. PROV-O: The PROV W3C Member Submission, World Wide Web Consor- 6 Ontology. W3C Recommendation, World Wide Web Consor- tium, Jan. 2009. http://www.w3.org/Submission/2009/ 6 7 tium, Apr. 30 2013. https://www.w3.org/TR/prov-o/. SUBM-xsparql-language-specification-20090120/. 7 8 [35] L. Lefort, A. Haller, K. Taylor, G. Squire, P. Taylor, D. Perci- [49] H. Rijgersberg, M. van Assem, and J. Top. Ontology of units of 8 measure and related concepts. Semantic Web, 4(1):3–13, 2013. 9 val, and A. Woolf. The ACORN-SAT linked climate dataset. 9 https://doi.org/10.3233/SW-2012-0069. 10 Semantic Web, 8(6):959–967, 2017. https://doi.org/10.3233/ 10 SW-160241. [50] C. Roussey, S. Bernard, G. André, O. Corcho, G. De Sousa, 11 D. Boffety, and J.-P. Chanet. Weather Station Data Publication 11 [36] L. Lefort, C. Henson, and K. Taylor. Semantic Sensor Net- at Irstea: an Implementation Report. In Joint Proceedings of 12 work XG Final Report. W3C Incubator Group Report, World 12 the 6th International Workshop on the Foundations, Technolo- 13 Wide Web Consortium, June 28 2011. http://www.w3.org/ 13 gies and Applications of the Geospatial Web and 7th Interna- 14 2005/Incubator/ssn/XGR-ssn-20110628/. 14 tional Workshop on Semantic Sensor Networks, volume 1401, [37] M. Lefrançois. Interopérabilité sémantique libérale pour les 15 Riva del Garda, Italy, Oct. 2014. CEUR. 15 16 services et les objets. In Actes de la 17ème conférence Ex- [51] J. Subercaze, C. Gravier, J. Chevalier, and F. Laforest. Inferray: 16 traction et Gestion des Connaissances (EGC’17), Grenoble, 17 fast in-memory RDF inference. PVLDB, 9(6):468–479, 2016. 17 France, Jan. 2017. 18 https://doi.org/10.14778/2904121.2904123. 18 [38] M. Lefrançois. Planned ETSI SAREF Extensions based on the [52] J. Tandy, P. Barnaghi, and L. van den Brink (editors). Spatial 19 19 W3C&OGC SOSA/SSN-compatible SEAS Ontology Patterns. Data on the Web Best Practices. W3C Note, W3C, September 20 In Proceedings of Workshop on Semantic Interoperability and 2017. https://www.w3.org/TR/sdw-bp/. 20 21 Standardization in the IoT, SIS-IoT, Amsterdam, The Nether- [53] K. Taylor, C. Griffith, L. Lefort, R. Gaire, M. Compton, 21 22 lands, July 2017. T. Wark, D. Lamb, G. Falzon, and M. Trotter. Farming the 22 [39] M. Lefrançois, A. Zimmermann, and N. Bakerally. A SPARQL 23 Web of Things. IEEE Intelligent Systems, 28(6):12–19, 2013. 23 extension for generating RDF from heterogeneous formats. https://doi.org/10.1109/MIS.2013.102. 24 24 In Proceedings of the Extended Semantic Web Conference [54] K. Taylor and E. Parsons. Where is everywhere: Bringing lo- 25 (ESWC’17), Portoroz, Slovenia, May 2017. LNCS. https: cation to the web. IEEE Internet Computing, 19(2):83–87, Mar 25 26 //doi.org/10.1007/978-3-319-58068-5_3. 2015. https://doi.org/10.1109/MIC.2015.50. 26 27 [40] S. Liang, C.-Y. Huang, and T. Khalafbeigi. OGC Sensor- [55] D. van der Werf, M. Adamescu, M. Ayromlou, N. Bertrand, 27 28 Things API Part 1: Sensing. Technical Report 15-078r6, J. Borovec, H. Boussard, C. Cazacu, T. V. Daele, S. Datcu, 28 OGC, July 2016. http://docs.opengeospatial.org/is/15-078r6/ M. Frenzel, V. Hammen, H. Karasti, M. Kertesz, P. Kuitunen, 29 29 15-078r6.html. M. Lane, J. Lieskovsky, B. Magagna, J. Peterseil, S. Ren- 30 30 [41] A. Llaves and F. Knibbe. Spatial data on the web use cases & nie, H. Schentz, K. Schleidt, and L. Tuominen. SERONTO 31 requirements. W3C note, W3C, Oct. 2016. https://www.w3. A Socio-Ecological Research and Observation Ontology: the 31 32 org/TR/2016/NOTE-sdw-ucr-20161025/. core ontology. Alter-Net Deliverable 4.I6.D2, Wageningen 32 33 [42] B. F. Lóscio, C. Burle, and N. C. (editors). Data on the Web University, 2009. 33 [56] I. Zinnikus, A. Antakli, P. Kapahnke, M. Klusch, C. Krauss, 34 Best Practices. W3C recommendation, W3C, January 2017. 34 https://www.w3.org/TR/dwbp/. A. Nonnengart, and P. Slusallek. Integrated Semantic Fault 35 Analysis and Worker Support for Cyber-Physical Production 35 [43] J. Madina, S. Bowers, M. Schildhauer, S. Krivovc, D. Penning- 36 Systems. In Proceedings of the IEEE 19th Conference on 36 ton, and F. Villa. An ontology for describing and synthesizing Business Informatics (CBI), Thessaloniki, Greece, 2017. IEEE. 37 ecological observation data. Ecological Informatics, 2(3):279– 37 https://doi.org/10.1109/CBI.2017.54. 38 296, 2007. https://doi.org/10.1016/j.ecoinf.2007.05.004. 38 39 [44] D. Martin, M. Burstein, J. Hobbs, O. Lassila, D. McDermott, 39 40 S. McIlraith, S. Narayanan, M. Paolucci, B. Parsia, T. Payne, 40 41 et al. OWL-S: Semantic markup for web services. W3c 41 member submission, W3C, Nov. 2004. https://www.w3.org/ 42 42 Submission/OWL-S/. 43 [45] C. Masolo, S. Borgo, A. Gangemini, N. Guarino, A. Oltramari, 43 44 and L. Schneider. The WonderWeb Library of Fundational On- 44 45 tologies and the DOLCE ontology. Technical report, LOA- 45 46 ISTC, 2003. 46 47 [46] Y. Nenov, R. Piro, B. Motik, I. Horrocks, Z. Wu, and J. Baner- 47 jee. RDFox: A Highly-Scalable RDF Store. In Proceed- 48 48 ings of the 14th International Semantic Web Conference 49 49 (ISWC), volume 9367 of LNCS, pages 3–20, Bethlehem, PA, 50 USA, October 11–15 2015. Springer. https://doi.org/10.1007/ 50 51 978-3-319-25010-6_1. 51 A. Haller et al. / The Modular SSN Ontology: A Joint W3C and OGC Standard 21
1 Appendix A. List of all SOSA/SSN Terms 1 2 2 3 Appendix B. SSN-System terms 3 4 4 5 Appendix C. Deprecated SSNX Terms 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 22 A. Haller et al. / The Modular SSN Ontology: A Joint W3C and OGC Standard
1 1 2 2 3 SOSA/SSN term replaces SOSA/SSN term replaces 3
4 sosa:FeatureOfInterest w oldssn:FeatureOfInterest ssn:hasProperty ≡ oldssn:hasProperty 4 5 ssn:Property ≡ oldssn:Property ssn:isPropertyOf ≡ oldssn:isPropertyOf 5 6 6 sosa:ObservableProperty - 7 7 sosa:ActuatableProperty - 8 8 sosa:Sample - sosa:hasSample - 9 9 sosa:isSampleOf - 10 10 11 sosa:Platform ≡ oldssn:Platform sosa:hosts ≡ oldssn:attachedSystem 11 12 sosa:isHostedBy ≡ oldssn:onPlatform 12 13 sosa:Procedure ≡ oldssn:Process 13 14 ssn:hasInput ≡ oldssn:hasInput ssn:hasOutput ≡ oldssn:hasOutput 14 15 ssn:Input ≡ oldssn:Input ssn:Output ≡ oldssn:Output 15 16 ssn:implementedBy ≡ oldssn:implementedBy 16 17 ssn:implements ≡ oldssn:implements 17 18 18 sosa:Sensor ≡ oldssn:Sensor sosa:Actuator - 19 19 sosa:observes ≡ oldssn:observes ssn:forProperty ≡ oldssn:forProperty 20 20 sosa:isObservedBy - 21 21 sosa:Sampler - 22 22 sosa:usedProcedure ≡ oldssn:sensingMethodUsed sosa:hasFeatureOfInterest ≡ oldssn:featureOfInterest 23 23 sosa:isFeatureOfInterestOf - 24 24 sosa:Observation oldssn:Observation sosa:Actuation - 25 25 sosa:madeObservation ≡ oldssn:madeObservation sosa:madeActuation - 26 26 sosa:madeBySensor ≡ oldssn:observedBy sosa:actuationMadeBy - 27 27 sosa:observedProperty ≡ oldssn:observedProperty sosa:actsOnProperty - 28 28 sosa:isActedOnBy - 29 29 sosa:Sampling - 30 30 sosa:madeSampling - 31 31 sosa:madeBySampler - 32 32 33 ssn:Stimulus ≡ oldssn:Stimulus , ≡ oldssn:SensorInput ssn:wasOriginatedBy - 33 34 ssn:detects ≡ oldssn:detects 34 35 ssn:isProxyFor ≡ oldssn:isProxyFor 35 36 sosa:Result w oldssn:ObservationValue, w oldssn:SensorOutput sosa:hasSimpleResult - 36 37 sosa:hasResult w oldssn:hasValue, w oldssn:observationResult sosa:hasResultingSample - 37 38 sosa:isResultOf ≡ oldssn:isProducedBy sosa:isSamplingResultOf - 38 39 sosa:resultTime oldssn:observationResultTime sosa:phenomenonTime ≡ oldssn:observationSamplingTime 39 40 40 ssn:System ≡ oldssn:System ssn:hasSubSystem ≡ oldssn:hasSubSystem 41 41 ssn:Deployment ≡ oldssn:Deployment 42 42 ssn:deployedSystem ≡ oldssn:deployedSystem ssn:deployedOnPlatform ≡ oldssn:deployedOnPlatform 43 43 ssn:hasDeployment ≡ oldssn:hasDeployment ssn:inDeployment ≡ oldssn:inDeployment 44 44 45 TOTAL SOSA: 13 classes, 21 object properties, 2 datatype properties 45 46 TOTAL SSN: 6 classes, 15 object properties 46 47 Table 2 47 48 Complete list of SOSA and SSN terms, and the terms in the old SSN that they supersede, if they exist, along with the formal relation between 48 the new term and the old term. No relation means rdfs:seeAlso. The grouping of terms is only meant to ease readability. 49 49 50 50 51 51 A. Haller et al. / The Modular SSN Ontology: A Joint W3C and OGC Standard 23
1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 SOSA/SSN term replaces SOSA/SSN term replaces 8 9 ssn-system:qualityOfObservation ≡ oldssn:qualityOfObservation 9 10 ssn-system:inCondition ≡ oldssn:inCondition ssn-system:Condition ≡ oldssn:Condition 10 11 11 ssn-system:hasSystemCapability w oldssn:hasMeasurementCapability 12 12 ssn-system:SystemCapability w oldssn:MeasurementCapability 13 13 ssn-system:hasSystemProperty w oldssn:hasMeasurementProperty 14 14 ssn-system:SystemProperty w oldssn:MeasurementProperty 15 15 System properties for sensors 16 16 ssn-system:MeasurementRange ≡ oldssn:MeasurementRange ssn-system:DetectionLimit w oldssn:DetectionLimit 17 17 18 System property for actuators 18 19 ssn-system:ActuationRange - 19 20 System properties for any system 20 21 ssn-system:Accuracy w oldssn:Accuracy ssn-system:Drift w oldssn:Drift 21 22 ssn-system:Frequency w oldssn:Frequency ssn-system:Latency w oldssn:Latency 22 23 ssn-system:Precision ≡ oldssn:Precision ssn-system:Resolution w oldssn:Resolution 23 24 ssn-system:Repeatability - ssn-system:ResponseTime w oldssn:ResponseTime 24 25 ssn-system:Selectivity w oldssn:Selectivity ssn-system:Sensitivity ≡ oldssn:Sensitivity 25 26 26 ssn-system:hasOperatingRange ≡ oldssn:hasOperatingRange 27 27 ssn-system:OperatingRange ≡ oldssn:OperatingRange 28 28 ssn-system:hasOperatingProperty ≡ oldssn:hasOperatingProperty 29 29 ssn-system:OperatingProperty ≡ oldssn:OperatingProperty 30 30 Operating ranges for any system 31 31 ssn-system:MaintenanceSchedule ≡ oldssn:MaintenanceSchedule 32 32 ssn-system:OperatingPowerRange ≡ oldssn:OperatingPowerRange 33 33 34 ssn-system:hasSurvivalRange ≡ oldssn:hasSurvivalRange 34 35 ssn-system:SurvivalRange ≡ oldssn:SurvivalRange 35 36 ssn-system:hasSurvivalProperty ≡ oldssn:hasSurvivalProperty 36 37 ssn-system:SurvivalProperty ≡ oldssn:SurvivalProperty 37 38 Survival ranges for any system 38 39 ssn-system:SystemLifetime ≡ oldssn:SystemLifetime 39 40 ssn-system:BatteryLifetime ≡ oldssn:BatteryLifetime 40 41 TOTAL SSN-System: 23 classes, 8 object properties 41 42 Table 3 42 43 Complete list of terms in SSN-System, and the terms in the old SSN that they supersede, if they exist, along with the formal relation between the 43 44 new term and the old term. The grouping of terms is only meant to ease readability. 44 45 45 46 46 47 47 48 48 49 49 50 50 51 51 24 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 Term Cause Alignment to concepts in SOSA/SSN 19 20 oldssn:startTime Unused - 20 21 oldssn:endTime Unused - 21 22 oldssn:Device Misused v sosa:Platform u ssn:System 22 23 oldssn:SensingDevice Misused v sosa:Platform u sosa:Sensor 23 24 oldssn:Sensing Unused v sosa:Procedure 24 25 oldssn:DeploymentRelatedProcess Unused - 25 26 oldssn:deploymentProcessPart Unused - 26 27 oldssn:ofFeature Unused 27 28 oldssn:SensorDataSheet Unused 28 29 TOTAL: 9 deprecated terms 29 30 Table 4 30 31 Terms in the old SSN that have no equivalent in the SOSA or SSN, and are simply deprecated. Unused terms were deprecated because no imple- 31 32 mentation evidence was found, and no requirement justified their inclusion in SSN. Misused terms were proven to be prone to misinterpretation 32 and were deprecated in SSN. 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