Warning:
This wiki has been archived and is now read-only.
Review of Sensor and Observations Ontologies
Contents
- 1 Review of Sensor and Observation ontologies
- 1.1 Overview of this activity
- 1.2 Reviews
- 1.2.1 CSIRO Sensor Ontology
- 1.2.2 OntoSensor
- 1.2.3 SWAMO
- 1.2.4 SDO
- 1.2.5 MMI Device Ontology
- 1.2.6 SensorML Processes
- 1.2.7 CESN
- 1.2.8 WISNO
- 1.2.9 A3ME
- 1.2.10 Ontonym - Sensor
- 1.2.11 SEEK OBOE
- 1.2.12 SERES O&M
- 1.2.13 Stimuli-Centered
- 1.2.14 Sensei Observation and Measurement Ontology
- 1.2.15 OOSTethys
- 1.2.16 O&M-OWL (SemSOS)
- 1.2.17 Socio-Ecological Research and Observation oNTOlogy (SERONTO)
Review of Sensor and Observation ontologies
Overview of this activity
Prior to the start of the ontology engineering work on the SSN ontology, the group extensively reviewed ontologies and data models describing sensors and their capabilities as well as observations, using these attributes.
This part of the report presents the 17 sensor-centric and observation-centric ontologies which were analysed in detail. This report also provides a record of other ontologies which were identified but which did not match the objectives stated in the SSN XG charter.
DISCLAIMER: 8 out of the 17 ontologies which are reviewed here were developed by organisations participating in the SSN XG and may have been reviewed by the participants of the XG who were involved in their development. This is because the goal of this review phase was to better understand the similarities and differences between all the existing ontologies to refine the scope of the SSN XG ontology. At such an early stage of the XG work, it was efficient to allocate the review of an ontology to someone involved in its development rather than to ask someone else from the group to do it.
Special thanks to John Graybeal, W3C Invited expert for the SSN XG at the time of this review, for taking notes during the July 1 teleconf discussion on the reviewed ontologies and for initiating this part of the report.
Reviewed ontologies
The reviewed ontologies are listed in next two tables. The first table lists the ontologies which are sensor-centric.
The second table lists the ontologies which are more observation-centric.
| Ontology Name | References | URL | Image URL | Presenter | Comments | |
|---|---|---|---|---|---|---|
| SEEK Extensible Observation Ontology (OBOE) | [Madin et al. 2007] | ontologies | image | Kevin Page | ||
| Semantic Reference Systems (SeReS) O&M | [Probst et al. 2006] [Probst 2006] [Probst 2007] [Probst 2008] |
ontologies | image | Krzysztof Janowicz | ||
| Stimuli-centered ontology | [Stasch et al. 2009] | gsn09hs, haskell musil.uni-muenster.de |
x | Krzysztof Janowicz | ||
| Sensei O&M | [Barnaghi et al. 2009] [Wei and Barnaghi 2009] |
OWL | x | Payam Barnaghi | Sensei O&M Ontology Review | |
| O&M-OWL (SemSOS) | [Henson et al. 2009] | OWL | x | Cory Henson | An encoding of O&M in OWL. Used in a semantic Sensor Observation Service. | |
| OOSTethys | [Bermudez et al. 2009] [Bermudez 2010] |
OWL | png | Luis Bermudez | Observation, procedure, systems and other semantics needed in OGC SWE services. | |
| Socio-Ecological Research and Observation oNTOlogy (SERONTO) | [Skov and Petit 2005] [van der Werf et al. 2009] |
OWL | N/A | Laurent Lefort | previously known as CEDEX or ALTER-NET Core |
Surveys of Sensor and Observation ontologies
Two peer-reviewed survey papers ([Bell et al. 2009], [Compton et al. 2009a]) were presented at the 2nd International Workshop on Semantic Sensor Networks 2009.
[Compton et al. 2009a] also discusses the ontologies developed by:
- [Avancha and Patel 2004]
- [Kim et al. 2008] (which is related to OntoSensor)
- [Matheus et al. 2005]
- [Preece et al. 2008]
In July 2007, a NSF Observations Workshop was held by Mark Schildhauer and Peter McCartney at NCEAS (National Center for Ecological Analysis and Synthesis), Santa Barbara, California, with presentations on LTER-Europe's CEDEX ontology (Mirtl), CUAHSI's ODM standard (Horsburgh), TDWG's OSR standard (Kelling), NatureServe's ODS standard (Stein), NASA's SWEET ontology (Raskin), Spire's ETHAN ontology (Parr), CDP's TreeBase standard (Zeman), OGC's O&M framework (Bermudez), VSTO's ontology (McGuinness) and SEEK's OBOE ontology [Madin et al. 2007]. A comparison of OBOE, CEDEX and CUAHSI ODM has been done by [Madin et al. 2008].
From the same community, it is no longer possible to find the SEEK ontologies [Williams et al. 2006] but other ontologies developed by SEEK collaborators for the SPIRE project are still available. All this work has fed into the development of the OBOE ontology.
Ontologies and other models which have been partially reviewed or not reviewed
Annex E.5 in earlier versions of O&M ([OM 1 2007], [OM 2 2007]) included a 'phenomenon' ontology, based on the SWE phenomenon schema, described in Annex C.3 of the same document. The ontology is incomplete, was in fact only intended to be illustrative of how the requirements described in the schema might be satisfied. Also note that if OWL had been more mature when the work started (2001) it would have been used instead of this bespoke XML serialization. See O&M Phenomenon Dictionary
SWEET [Raskin and Pan 2005] has some parts which are relevant but too shallow for direct use like sciInstrument. The VSTO ontology ([Fox et al. 2007] , [Fox et al. 2008]) extends SWEET to support the integration of data sourced from Earth Observation sensors. The SPASE data model [SPASE 2010] and the NEESGRID ontology [Peng and Law 2005] are also aimed at environmental monitoring applications.
Outcomes of the SSN XG review
At the end of this activity, the group identified concepts that should be included, but found that none of the ontologies under review supported all of those required concepts. The group opted to use one of the 17 ontologies as the starting point for the development of the Semantic Sensor Network ontology. The Sensor ontology developed by Michael Compton, Holger Neuhaus and Nguyen Tran from CSIRO (Australia) was selected. This ontology (SensorOntology2009) and its documentation are available for the readers wishing to compare it to the final product of the working group.
Some of its users have called it the Draft W3C Semantic Sensor Network Ontology ([O'Byrne et al. 2010]) instead of the denomination CSIRO Sensor Ontology 2009 which is now preferred.
Reviews
CSIRO Sensor Ontology
(Presented by Michael Compton)
Primary purpose/target: Why was this ontology created? > For describing and reasoning about sensors, observations and scientific models. Provide a semantic description of sensors for use in workflows.
Status: Is this an actively maintained ontology, or not? Would you consider it 'complete', or not? > Actively being developed. Not yet complete/finished - was designed not to be 'complete' in the sense that it should provide a language to specify sensors, but is agnostic about domain concerns, units of measurement, location, time series, etc (these are mentioned, but should be included from separate ontologies using the usual OWL mechanisms). Also, observations and sensors are fairly tightly coupled concepts, so a sensor ontology could really be a sensor-and-observation ontology and this one isn't that yet
Concept Documentation: Do the concepts have textual descriptions (always, often, sometimes, rarely, never)? > Sometimes
Reference Documentation: Does the ontology contain references to relevant publications or specification documents? > some
Key framework concept(s): What are the key concepts around which the ontology is organized? Provide a phrase describing each (up to 3). > Sensor, Grounding, OperationModel and Process (and then Feature etc from a domain perspective)
Range of subject matter: With respect to sensors, is this ontology narrowly focused, moderately broad, or comprehensive? > I think it's reasonably broad, but there is more to include from say from SensorML, O&M and OntoSensor
Level of sophistication: Is this ontology more like a basic hierarchy of concepts, or is it really semantically sophisticated? > Not a hierarchy of concepts, has some restrictions etc.
Adoption: Is anyone other than the creator using this ontology? Are there many examples?> No, there are a small number of examples.
Best feature(s): What conceptual aspects of this ontology should be represented the SSN ontology if possible? >
Composition -- A key question (as John pointed out on the wiki) is where does composition live. From my review this is the only ontology that we have considered that can do proper composition (others can do something limited or something closer to part-of) so that aspect should be included.
Plug and Play -- Removing the ontology from domain concerns, issues of how to represent units of measurements, locations etc is a good modularity feature. The SSN ontology shouldn't include these, but rather allow any such ontology to be plugged in.
Hierarchy of Sensors -- This ontology doesn't include any hierarchy of sensors, in the sense of a thermometer is a temperature sensor etc, the idea in creating the ontology was that this hierarchy lives parallel to the more capabilities and limitations description that the ontology does give. The hierarchy of sensors approach is a) more domain influenced and b) can probably be automatically derived from the other (in that the hierarchy can be set up such that sensors described in the given ontology are automatically classified into the correct places.) . However, I acknowledge that some aspects are generic and perhaps a combination of the two approaches is what the incubator should produce (ontosensor has elements of both).
Weakest feature(s): What issues does this ontology have that should be avoided in the SSN ontology? >
Other remarks: Anything else of particular interest that you think people should know about? >
Good basis: Would you recommend this ontology (or part of it) as the basis for the SSN ontology? Which parts? > Yes
Additional documentation derived from the OWL file is available here:
Slides:
- Compton et al. 2009 Semantic Sensor Network Ontology, Presentation at the SSN XG Face-to-Face meeting, Washington, 24 October 2009
- Neuhaus and Compton 2009 The Semantic Sensor Network Ontology A Generic Language to Describe Sensor Assets AGILE 2009
OntoSensor
(Presented by Danh Le Phuoc, plus comments from Laurent Lefort)
Primary purpose/target: Why was this ontology created? > OntoSensor was created to build a knowledge base of sensor (University of Memphis). This knowledge base can be queried via a Protege plugin.
Status: Is this an actively maintained ontology, or not? Would you consider it 'complete', or not?> Not updated since 2008. It is incomplete : it mostly covers the sensors listed in Crossbow catalogue.
Key framework concept(s): What are the one, two, or three key concepts around which the ontology is organized? Provide the name and brief description (a phrase) describing each of the key concepts.>
- Sensor
- Capabilities description
- Measurand
Range of subject matter: With respect to sensors, is this ontology narrowly focused, moderately broad, or comprehensive?> OntoSensor is narrowly focused on technical specifications of sensor. It targets to a small set of sensor features such as data acquisition boards, sensing elements, processor/radio units in the Crossbow 2006 catalogue.
Level of sophistication: Is this ontology more like a basic hierarchy of concepts, or is it really semantically sophisticated?> It provides a small taxonomy of sensors, but, it contains several complicated properties.
Dependencies: Which upper ontologies/concepts/properties does it depend on?>
- IEEE SUMO : Process, ContentDevelopment, MeasuringDevice, TransportationService
- ISO 19115: MD_LegalConstraints, MD_SecurityConstraints, CI_ResponsibleParty, CI_Citation, CI_OnlineResouce
- SensorML :
- GML :
Adoption: Is anyone other than the creator using this ontology?> Yes, [Kim et al. 2008].
Best feature(s): What aspects or parts of this ontology should be incorporated into the SSN ontology if possible?> The best feature for me is the inclusion of 32 individuals (instances) definitions. Recommendation: ignore all the classes and properties definitions which are not leveraged by these instances.
Weakest feature(s): What issues does this ontology have that should be avoided in the SSN ontology? (Do not consider lack of completion as an issue, in this context.)>The organization of concepts and properties is so messy to use in other application or to extend.
Other remarks: Anything else of particular interest that you think people should know about?
Good basis: Would you recommend this ontology (or part of it) as the basis for the SSN ontology? Which parts?> No.
SWAMO
(Presented by John Graybeal)
Primary purpose/target: Why was this ontology created? > Enable dynamic, composeable interoperability of sensor web products and services. Describing autonomous agents for system-wide resource sharing, distributed decision making, autonomic operations.
Status: Is this an actively maintained ontology, or not? Would you consider it 'complete', or not? > Actively maintained, and in progress (not complete).
Key framework concept(s): What are the key concepts around which the ontology is organized? Provide a phrase describing each (up to 3).> SWE sensor systems (and semantics). Autonomous agent control systems. Maximum interoperability.
Range of subject matter: With respect to sensors, is this ontology narrowly focused, moderately broad, or comprehensive? > Fairly broad, somewhat deep. It focuses on the sensor domain, and particularly on processes to control them.
Level of sophistication: Is this ontology more like a basic hierarchy of concepts, or is it really semantically sophisticated? > Sophisticated.
Adoption: Is anyone other than the creator using this ontology? Are there many examples?> Applied to multiple MidSTAR1 instances (sensor, computer, battery actuator).
Best feature(s): What conceptual aspects of this ontology should be represented the SSN ontology if possible? > Interoperable with SWE descriptions. Its inclusion of real-time information should be considered (position, orientation, etc.). Its organization of "everything is an X" (X=component in this case) is analogous to SensorML. Targets dynamic and composeable interoperability.
Weakest feature(s): What issues does this ontology have that should be avoided in the SSN ontology? > Classes look a little mixed -- acceleration is in the Position class. The highest level class (Component) does not appear to reference itself.
Other remarks: Anything else of particular interest that you think people should know about? > May be further along than our image shows.
Good basis: Would you recommend this ontology (or part of it) as the basis for the SSN ontology? Which parts? > Components on Agents. (Would something like the Position class and subclasses be useful?)
SDO
(Presented by Raúl García Castro)
Primary purpose/target: Why was this ontology created? > To search relevant sensor data over distributed and heterogeneous sensor networks.
Status: Is this an actively maintained ontology, or not? Would you consider it 'complete', or not? > The ontology is not available for use. It does not seem actively maintained, it was only described in two papers in 2006 and 2007 with "identical" content.
Concept Documentation: Do the concepts have textual descriptions (always, often, sometimes, rarely, never)? > Unknown.
Reference Documentation: Does the ontology contain references to relevant publications or specification documents? > No.
Key framework concept(s): What are the key concepts around which the ontology is organized? Provide a phrase describing each (up to 3). >
- Reuses the SUMO ontology as a whole. The rest of the modules reference to the SUMO ontology.
- Sensor Hierarchy Ontology.
- Only a figure is available.
- Describes Sensors and Sensor data.
- Built from IEEE 1451.4
- Does not completely cover the standard
- Some modelling errors: Mix subclass properties with ad-hoc properties (e.g., has, characterized_by)
- Non-justified modelling decisions. E.g., they say that "A sensor is an actuator or a transducer" and in IEEE it appears that "A transducer is a sensor or an actuator".
- Sensor Data Ontology. There is nothing available. From the paper:
- "Describes the dynamic and observational properties of transducers data that goes beyond describing individual transducers"
- "Describes the context of a sensor with respect to spatial and/or temporal observations"
- "Provides abstract measurements/operations by groping transducers (virtual transducer)"
- Extension Plug-in Ontologies. There is nothing available. Each plug-in ontology includes the representation for a particular domain of sensor data and networks.
Range of subject matter: With respect to sensors, is this ontology narrowly focused, moderately broad, or comprehensive? > Narrowly focused.
Level of sophistication: Is this ontology more like a basic hierarchy of concepts, or is it really semantically sophisticated? > Not clear, but it seems quite lightweight (a basic hierarchy of concepts with some properties).
Adoption: Is anyone other than the creator using this ontology? Are there many examples?> The ontology has not been released for third party use.
Best feature(s): What conceptual aspects of this ontology should be represented the SSN ontology if possible? > Not parts of the ontology but general concepts:
- Alignment with standard
- Alignment with upper ontologies?
- Abstraction of groups of sensors/sensor networks in virtual sensors
- Modular development
Weakest feature(s): What issues does this ontology have that should be avoided in the SSN ontology? > Limited information available, some conflicts with standards.
Other remarks: Anything else of particular interest that you think people should know about? >
Good basis: Would you recommend this ontology (or part of it) as the basis for the SSN ontology? Which parts? > No.
MMI Device Ontology
(Presented by Luis Bermudez)
Primary purpose/target: Why was this ontology created? > Develop an ontology of oceanographic devices, including both sensors (which measure things) and samplers (which pick up things). The first priority is to be able to broadly characterize the devices (i.e., sort them into groups). One significant use of such characterizations is to help users (or web applications) discover sensors or data of interest, but a set of use cases is being developed to flesh out the work
Status: Is this an actively maintained ontology, or not? Would you consider it 'complete', or not? > Not completed. In progress. Meetings every 2 weeks.
Concept Documentation: Do the concepts have textual descriptions (always, often, sometimes, rarely, never)? > some
Reference Documentation: Does the ontology contain references to relevant publications or specification documents? > No
Key framework concept(s): What are the key concepts around which the ontology is organized? Provide a phrase describing each (up to 3). > It is organized around a system concept. System is a Process. System has capabilities, like measurement capabilities (accuracy etc..)
Range of subject matter: With respect to sensors, is this ontology narrowly focused, moderately broad, or comprehensive? > Even though was meant to be for oceanographic sensor it could be used in other contexts.
Level of sophistication: Is this ontology more like a basic hierarchy of concepts, or is it really semantically sophisticated? > It contains properties and hierarchy of classes and some restrictions
Adoption: Is anyone other than the creator using this ontology? Are there many examples?> Not sure
Best feature(s): What conceptual aspects of this ontology should be represented the SSN ontology if possible? > System and capabilities concepts including the hierarchies.
Weakest feature(s): What issues does this ontology have that should be avoided in the SSN ontology? > Not sure (not well tested)
Other remarks: Anything else of particular interest that you think people should know about? >
Good basis: Would you recommend this ontology (or part of it) as the basis for the SSN ontology? Which parts? > Yes, system and capabilities
SensorML Processes
(Presented by Luis Bermudez)
Primary purpose/target: Why was this ontology created? > To represent SensorML model and serve as a starting ontology for the MMI device ontology
Status: Is this an actively maintained ontology, or not? Would you consider it 'complete', or not? > NO. Not maintained
Concept Documentation: Do the concepts have textual descriptions (always, often, sometimes, rarely, never)? > No
Reference Documentation: Does the ontology contain references to relevant publications or specification documents? > it is based on the SensorML schema
Key framework concept(s): What are the key concepts around which the ontology is organized? Provide a phrase describing each (up to 3). > Process.
Range of subject matter: With respect to sensors, is this ontology narrowly focused, moderately broad, or comprehensive? > Narrowly focus on Processes
Level of sophistication: Is this ontology more like a basic hierarchy of concepts, or is it really semantically sophisticated? > Basic
Adoption: Is anyone other than the creator using this ontology? Are there many examples?> No
Best feature(s): What conceptual aspects of this ontology should be represented the SSN ontology if possible? > None
Weakest feature(s): What issues does this ontology have that should be avoided in the SSN ontology? > based on the schema and not a conceptual SensorML model
Other remarks: Anything else of particular interest that you think people should know about? >
Good basis: Would you recommend this ontology (or part of it) as the basis for the SSN ontology? Which parts? > No.
CESN
(Presented by Holger Neuhaus)
Primary purpose/target: Why was this ontology created? > The CESN (Coastal Environment Sensor Network) ontology was created as part of the "CESN Semantic Data Reasoner" project
Status: Is this an actively maintained ontology, or not? Would you consider it 'complete', or not? > The paper "Machine reasoning about anomalous sensor data" (Calder et al.) "extended ontology will be complete and in place by autumn 2009", so assumably work in progress.
Concept Documentation: Do the concepts have textual descriptions (always, often, sometimes, rarely, never)? > There are near to no comments in the OWL file.
Reference Documentation: Does the ontology contain references to relevant publications or specification documents? > No.
Key framework concept(s): What are the key concepts around which the ontology is organized? Provide a phrase describing each. > The Sensor that is restricted to measure only one PhysicalProperty (and by that performing a PhysicalProperty); Instrument containing several Sensors; and Deployment, relating Instruments readings to time and place of a real-world event.
Range of subject matter: With respect to sensors, is this ontology narrowly focused, moderately broad, or comprehensive? > quite narrow (more like an application ontology)
Level of sophistication: Is this ontology more like a basic hierarchy of concepts, or is it really semantically sophisticated? > The sophistication is more in the entire system the ontology is only a part of. "Sensor" is more like a black box.
Adoption: Is anyone other than the creator using this ontology? Are there many examples?> Probably not.
Best feature(s): What conceptual aspects of this ontology should be represented the SSN ontology if possible? > A representation of the hierarchy Sensor - Instrument - Deployment (which, in the proposed initial version is similar to Transducer - Sensor - Grounding)
Weakest feature(s): What issues does this ontology have that should be avoided in the SSN ontology? > The explicit mention of sensor types will always be incomplete.
Other remarks: Anything else of particular interest that you think people should know about? > The rules applied in the entire system the ontology is part of - which aren't in focus of the XG - could be of interest for someone using the ontology.
Good basis: Would you recommend this ontology (or part of it) as the basis for the SSN ontology? Which parts? > No.
WISNO
(Presented by Oscar Corcho)
Primary purpose/target: Why was this ontology created? > To provide a few terms related with sensors and actuators. This is a poster demo, with no real ontology backing it up (no answer from creators), and looks like a very simple proof of concept of how to use OWL and SWRL.
Status: Is this an actively maintained ontology, or not? Would you consider it 'complete', or not? > No
Concept Documentation: Do the concepts have textual descriptions (always, often, sometimes, rarely, never)? > No
Reference Documentation: Does the ontology contain references to relevant publications or specification documents? > References to SensorML and IEEE 1454.1 (transducers)
Key framework concept(s): What are the key concepts around which the ontology is organized? Provide a phrase describing each (up to 3). > Sensor are classified into transducers and actuators.
Range of subject matter: With respect to sensors, is this ontology narrowly focused, moderately broad, or comprehensive? > Really broad, lack of detail.
Level of sophistication: Is this ontology more like a basic hierarchy of concepts, or is it really semantically sophisticated? > basic hierarchy of concepts
Adoption: Is anyone other than the creator using this ontology? Are there many examples?> No examples about it.
Best feature(s): What conceptual aspects of this ontology should be represented the SSN ontology if possible? > None
Weakest feature(s): What issues does this ontology have that should be avoided in the SSN ontology? > N/A
Other remarks: Anything else of particular interest that you think people should know about? > N/A
Good basis: Would you recommend this ontology (or part of it) as the basis for the SSN ontology? Which parts? > No
Discussion: One of those papers that should not be discussed about nor even referenced, but included here for completeness of our descriptions.
A3ME
(Presented by Arthur Herzog)
Primary purpose/target: Why was this ontology created? >
- basic simple classification for self-description and discovery of devices and their capabilities in heterogeneous networks including resource constrained sensor nodes.
Status: Is this an actively maintained ontology, or not? Would you consider it 'complete', or not? >
- Actively maintained; complete, since it has to stay simple (but can be extended).
Concept Documentation: Do the concepts have textual descriptions (always, often, sometimes, rarely, never)? >
- No
Reference Documentation: Does the ontology contain references to relevant publications or specification documents? >
- FIPA Device Ontology
- OntoSensor
- SOPRANO context ontology
Key framework concept(s): What are the key concepts around which the ontology is organized? Provide a phrase describing each (up to 3). >
- Device classification: tag, mote, mobile, workstation, server, vehicle and multimedia
- General capability classes: sensor, actuator, communication, storage, computing, energy
- Subclasses for each capability class
Range of subject matter: With respect to sensors, is this ontology narrowly focused, moderately broad, or comprehensive? >
- moderately broad
Level of sophistication: Is this ontology more like a basic hierarchy of concepts, or is it really semantically sophisticated? >
- basic hierarchy of concepts
Adoption: Is anyone other than the creator using this ontology? Are there many examples?>
- no (just published)
Best feature(s): What conceptual aspects of this ontology should be represented the SSN ontology if possible? >
- basic classification of device capabilities, with sensor as one of the capability classes
Weakest feature(s): What issues does this ontology have that should be avoided in the SSN ontology? >
Other remarks: Anything else of particular interest that you think people should know about? >
- Suggestion: Use of a simple classification of capabilities/sensors as core and build an extended semantically sophisticated version of the ontology on top of this core.
Good basis: Would you recommend this ontology (or part of it) as the basis for the SSN ontology? Which parts? >
- basic classification of capabilities as basis
Ontonym - Sensor
Ontonym is a set of upper ontologies that represent core concepts in pervasive computing (time, location, people, sensing, provenance, events, device, resource).
Next, we focus only on the sensor ontology.
Primary purpose/target: Why was this ontology created? > To describe sensors and the data that they generate.
Status: Is this an actively maintained ontology, or not? Would you consider it 'complete', or not? > It is a recent ontology, but it seems that there is some interest in maintaining it.
Concept Documentation: Do the concepts have textual descriptions (always, often, sometimes, rarely, never)? > Often.
Reference Documentation: Does the ontology contain references to relevant publications or specification documents? > Yes.
Key framework concept(s): What are the key concepts around which the ontology is organized? Provide a phrase describing each (up to 3).>
- Sensor. High level description of a sensor and its capabilities (Frequency, Coverage, Accuracy and precision pairs).
- Sensor data. Description of sensor observations (Observation-specific information, metadata, sensor, timestamp, time period over which the value is valid, rate of change).
- These ontologies must be extended to characterise any specific sensor and its data
Range of subject matter: With respect to sensors, is this ontology narrowly focused, moderately broad, or comprehensive? > It is narrowly focused and small. It contains 8 classes, 13 object properties and 1 datatype property.
Level of sophistication: Is this ontology more like a basic hierarchy of concepts, or is it really semantically sophisticated? > Is lightweight (a basic hierarchy of concepts with some properties).
Adoption: Is anyone other than the creator using this ontology? Are there many examples?> It doesn't seem so.
Best feature(s): What conceptual aspects of this ontology should be represented the SSN ontology if possible? > Not parts of the ontology but a general concept: To ground on existing ontologies and theories for representing Time, Location, People and Events.
Weakest feature(s): What issues does this ontology have that should be avoided in the SSN ontology? > -
Other remarks: Anything else of particular interest that you think people should know about? > -
Good basis: Would you recommend this ontology (or part of it) as the basis for the SSN ontology? Which parts? > No.
SEEK OBOE
(Presented by Kevin Page)
Primary purpose/target: Why was this ontology created? >
The SEEK Extensible Observation Ontology (OBOE) was developed for the SEEK project, and has since been used by Spire.
Status: Is this an actively maintained ontology, or not? Would you consider it 'complete', or not? >
OBOE is now maintained by the Scientific Observations Network - SONet - here.
Concept Documentation: Do the concepts have textual descriptions (always, often, sometimes, rarely, never)? >
Yes, nearly always. The comment documentation appears good.
Reference Documentation: Does the ontology contain references to relevant publications or specification documents? >
No.
Key framework concept(s): What are the key concepts around which the ontology is organized? Provide a phrase describing each (up to 3). >
There is a core observations ontology, a units extension, and a further extension for domain use (coastal ecosystems).
- The ontology separates separates observations from the entity being observed: the observation has a measurement while the entity has characteristics, and the measurement is then of that characteristic.
Figure 4.1 - Overview of the OBOE ontology
- Entities are extension points into domain models.
- Observations can occur within a context, which in turn is an observation; this property is transitive.
Figure 4.2 - Handling of nested contexts and observations in OBOE
Range of subject matter: With respect to sensors, is this ontology narrowly focused, moderately broad, or comprehensive? >
This is very much an observation ontology, not a device ontology.
Level of sophistication: Is this ontology more like a basic hierarchy of concepts, or is it really semantically sophisticated? >
This is more than a basic hierarchy of concepts.
Adoption: Is anyone other than the creator using this ontology? Are there many examples?>
As far as I can see there is not widespread adoption of the ontology beyond the projects that have developed it.
Best feature(s): What conceptual aspects of this ontology should be represented the SSN observation ontology if possible? >
The context concept (as an observation) is an interesting approach worth considering; whether this is the right match for the SSN ontology given other design requirements (OGC alignment, dovetailing with the device ontology, etc.) is a different matter.
Weakest feature(s): What issues does this ontology have that should be avoided in the SSN observation ontology? >
Other remarks: Anything else of particular interest that you think people should know about? >
Several observation ontologies/models have a similar set of concepts - the separation of observation from entity/feature of interest, measurements, some form of context - although the properties may differ. Further discussion and investigation is required to identify whether this is a better (or significantly different) approach than that in e.g. the OGC O&M model.
Good basis: Would you recommend this ontology (or part of it) as the basis for the SSN ontology? Which parts? >
The general design and structure seems clean, clear, and practical; but see previous comment.
Additional information:
- S. Bowers, Ontology Frameworks for Modeling Observational Data Semantics (source of figures 4.1 and 4.2)
SERES O&M
(Presented by Krzysztof Janowicz)
Primary purpose/target: Why was this ontology created? >
To align the core concepts from O&M to DOLCE.
Status: Is this an actively maintained ontology, or not? Would you consider it 'complete', or not? >
There are three ontologies, a raw version of OGC's O&M, a modified version of O&M, and an extension of DOLCE to better support observations and measurements. The O&M ontologies are not actively maintained because they are in a stable stage but the DOLCE extension is still under development.
Concept Documentation: Do the concepts have textual descriptions (always, often, sometimes, rarely, never)? >
In most cases.
Reference Documentation: Does the ontology contain references to relevant publications or specification documents? >
Yes, the changes to the original version of O&M are motivated in a discussion paper (Probst et al. 2006])
Key framework concept(s): What are the key concepts around which the ontology is organized? Provide a phrase describing each (up to 3). >
In the O&M ontologies the key concepts are Observation, Feature(OfInterest), Result,.... In the DOLCE extension different kinds of quality spaces, regions, and qualities are introduced to integrate O&M into DOLCE.
Range of subject matter: With respect to sensors, is this ontology narrowly focused, moderately broad, or comprehensive? >
The O&M versions can be used/combined with our sensor ontology. the DOLCE extension is more a high level approach (and relevant if we would like to align our work to DOLCE).
Level of sophistication: Is this ontology more like a basic hierarchy of concepts, or is it really semantically sophisticated? >
The DOLCE extension is a full axiomatized ontology (in FOL with a partial mapping to OWL) The O&M parts are basically OWL versions of the O&M specs.
Adoption: Is anyone other than the creator using this ontology? Are there many examples?>
The ontologies are used at our department (Institute for Geoinformatics, University of Muenster, Germany)
Best feature(s): What conceptual aspects of this ontology should be represented the SSN observation ontology if possible? >
We could at least use the 1:1 mapping from the original O&M specs and integrate it into the sensor ontology.
Weakest feature(s): What issues does this ontology have that should be avoided in the SSN observation ontology? > ...
Other remarks: Anything else of particular interest that you think people should know about? > ...
Good basis: Would you recommend this ontology (or part of it) as the basis for the SSN ontology? Which parts? >
Yes, at least the O&M mapping and more if we want to link our sensor ontology to DOLCE.
Additional information:
Stimuli-Centered
(Presented by Krzysztof Janowicz)
Review of the stimulus-centric ontology presented as part of the paper on A Stimulus-Centric Algebraic Approach to Sensors and Observations [Stasch et al. 2009] (note that I am a co-author of , hence this review is somehow biased).
Primary purpose/target: Why was this ontology created?> This ontology aims at bridging between the sensor-centric Sensor Model Language (SensorML) and the user-centric Observations & Measurements (O&M) specification by focusing on stimuli as objects of sensing. It does not require a strong link between sensors and features of interests such as O&M. It also include humans as sensors which are the key to volunteered geographic information.
Status: Is this an actively maintained ontology, or not? Would you consider it 'complete', or not?> It is actively maintained. As it is a top-level kind of ontology, it is not complete in the sense of listing sensor(types) or observations but focuses on establishing a common ground for both.
Concept Documentation: Do the concepts have textual descriptions (always, often, sometimes, rarely, never)?> There are many additional details provided in the paper (see below) and in the haskell source code file.
Key framework concept(s): What are the one, two, or three key concepts around which the ontology is organized? Provide the name and brief description (a phrase) describing each of the key concepts.>
- Stimuli
- Observations
- Sensors
Figure 4.3 - The role of stimuli as a proxy between the sensor and the object of sensing
Range of subject matter: With respect to sensors, is this ontology narrowly focused, moderately broad, or comprehensive?> This ontology is focused on providing a top-level view on observation, not on specific sensors (however they can be aligned to the ontology).
Level of sophistication: Is this ontology more like a basic hierarchy of concepts, or is it really semantically sophisticated?> The ontology provides algebraic specifications using the haskell programming language to define the core concepts, hence it provides rich semantics.
Dependencies: Which upper ontologies/concepts/properties does it depend on?> It is based on work on SensorML, O&M, as well as Dolce.
Adoption: Is anyone other than the creator using this ontology?> The ontology is under development and so far only used in our work. It is part of the work done in the 52°North semantics community.
Best feature(s): What aspects or parts of this ontology should be incorporated into the SSN ontology if possible?> The ontology provides a detailed view on the process of observing and could (together with others) be used as top-level for the SSN ontology. However, IMO it would be better to use it as top level for an ontology of observations (and stimuli).
Weakest feature(s): What issues does this ontology have that should be avoided in the SSN ontology? (Do not consider lack of completion as an issue, in this context.)> Needs a OWL version to work with the W3C SSN ontology.
Other remarks: Anything else of particular interest that you think people should know about?
Good basis: Would you recommend this ontology (or part of it) as the basis for the SSN ontology? Which parts?> Yes, see above.
Sensei Observation and Measurement Ontology
(Presented by Payam Barnaghi)
Primary purpose/target: Why was this ontology created? > To annotate sensor observation and measurement data; The O&M ontology is then incorporated into the SENSEI resource model.
Status: Is this an actively maintained ontology, or not? Would you consider it 'complete', or not? > No. This is only a draft version based on OGC’s observation and measurement model.
Concept Documentation: Do the concepts have textual descriptions (always, often, sometimes, rarely, never)? > No
Reference Documentation: Does the ontology contain references to relevant publications or specification documents? > No
Key framework concept(s): What are the key concepts around which the ontology is organized? Provide a phrase describing each (up to 3). > An observation and measurement data can be related to an Entity of Interest (EoI) and it is provided via a Resource. The processes and services that make the O&M data available are provided through a Resource End Point (REP).
Range of subject matter: With respect to sensors, is this ontology narrowly focused, moderately broad, or comprehensive? > This is a general observation and measurement ontology and is constructed based on the OGC model.
Level of sophistication: Is this ontology more like a basic hierarchy of concepts, or is it really semantically sophisticated? > > Basic hierarchy of concepts, very few property restrictions.
Adoption: Is anyone other than the creator using this ontology? Are there many examples?> The SENSEI project.
Best feature(s): What conceptual aspects of this ontology should be represented the SSN ontology if possible? > The observation and measurement model.
Weakest feature(s): What issues does this ontology have that should be avoided in the SSN ontology? > The property restrictions are not completely defined. The SWE properties and relations to other concepts are not included.
Other remarks: Anything else of particular interest that you think people should know about? >
Good basis: Would you recommend this ontology (or part of it) as the basis for the SSN ontology? Which parts? > The observation and measurement structure which it is based on SWE’s O&M model.
Additional information:
OOSTethys
(Presented by Luis Bermudez)
Primary purpose/target: Why was this ontology created? > To have a source that holds concepts required to tag OGC SWE services. Also to help communicate the observation model, a procedure and complex systems.
Status: Is this an actively maintained ontology, or not? Would you consider it 'complete', or not? > Not completed. It is maintained within OOSTethys, updates every ~ 3 months.
Concept Documentation: Do the concepts have textual descriptions (always, often, sometimes, rarely, never)? > No
Reference Documentation: Does the ontology contain references to relevant publications or specification documents? > ?
Key framework concept(s): What are the key concepts around which the ontology is organized? Provide a phrase describing each (up to 3). > An observation is a procedure which estimates the value of property of a feature of interest. The process is a system. A system is composed of other systems or processes that are atomic (detectors).
Range of subject matter: With respect to sensors, is this ontology narrowly focused, moderately broad, or comprehensive? > Is a general Observation model but focuses on the procedure.
Level of sophistication: Is this ontology more like a basic hierarchy of concepts, or is it really semantically sophisticated? > Basic hierarchy of concepts, very few property restrictions. Some instances.
Adoption: Is anyone other than the creator using this ontology? Are there many examples?> The OOSTethys community.
Best feature(s): What conceptual aspects of this ontology should be represented the SSN ontology if possible? > The observation model and the hierarchy of procedures and systems.
Weakest feature(s): What issues does this ontology have that should be avoided in the SSN ontology? > The details of other semantics used in SWE, like the URI of the contact role.
Other remarks: Anything else of particular interest that you think people should know about? >
Good basis: Would you recommend this ontology (or part of it) as the basis for the SSN ontology? Which parts? > The observation model and the hierarchy of procedures and systems.
O&M-OWL (SemSOS)
(Presented by Cory Henson)
Primary purpose/target: Why was this ontology created? > The O&M-OWL ontology was created so that we may reason over sensor data to infer "high-level" concepts from "low-level" phenomena. These concepts were then incorporated into a Sensor Observation Service so that users may query for events without requiring expert knowledge of how events and phenomena are related.
Status: Is this an actively maintained ontology, or not? Would you consider it 'complete', or not? > The ontology is actively maintained. We currently have 160 million observations (1.7 billion triples) describing 20,000 weather stations and eight historical weather events. This knowledge base is now a part of the Linked Open Data Cloud.
Concept Documentation: Do the concepts have textual descriptions (always, often, sometimes, rarely, never)? > Yes. Almost all concepts have textual descriptions.
Reference Documentation: Does the ontology contain references to relevant publications or specification documents? > Yes. All concepts derived from another source (e.g., Observations and Measurements) have references to the original specification.
Key framework concept(s): What are the key concepts around which the ontology is organized? Provide a phrase describing each (up to 3). > The ontology is organized around four major concepts: (1) Observation -- act of observing a phenomenon (2) Process -- method, algorithm or instrument, or system of these (3) Feature -- an abstraction of real world phenomena, or "real-world" entity (4) Phenomenon -- property of a feature that can be "sensed" or measured
Range of subject matter: With respect to sensors, is this ontology narrowly focused, moderately broad, or comprehensive? > Moderately broad. Doesn't deal with different types of sensors, but rather how sensors can be combined into a system. Although, we have descriptions of domain specific weather sensors in our extension.
Level of sophistication: Is this ontology more like a basic hierarchy of concepts, or is it really semantically sophisticated? > More than just a hierarchy of concepts. Semantics are found in the relations between the four major concepts described before. Using OWL to infer types of observations, phenomena, sensors, etc., given partial annotation.
Adoption: Is anyone other than the creator using this ontology? Are there many examples?> Not yet.
Best feature(s): What conceptual aspects of this ontology should be represented the SSN ontology if possible? > Since our ontology is based on O&M, it is already aligned with the SensorML language, which is a major foundation for the SSN ontology. For example, the concept of process within O&M is taken directly from SensorML.
Weakest feature(s): What issues does this ontology have that should be avoided in the SSN ontology? > Expressive representations of time and space are not found in O&M, so we have included concepts from OWL-Time and GML, respectively, but these domains could be better represented.
Other remarks: Anything else of particular interest that you think people should know about? > In the ontology given on the wiki, there are also concepts from the weather domain that are not relevant to the SSN ontology, but they are clearly labelled with the namespace of "weather", and thought they may be of interest so left them in.
Good basis: Would you recommend this ontology (or part of it) as the basis for the SSN ontology? Which parts? > Yes. All.
Additional information:
Socio-Ecological Research and Observation oNTOlogy (SERONTO)
(Reviewed by Laurent Lefort)
Primary purpose/target: Why was this ontology created? >
Created in the context of Long Term Ecological Research (LTER) semantic data integration (ALTER-NET).
Status: Is this an actively maintained ontology, or not? Would you consider it 'complete', or not? >
ALTER-NET project finished in March 2009. Funding for ontology work does not seem to be planned in follow-up activities.
Current version corresponds to 2nd round of development (with a test of fitness for semantic integration ability (using OntoPrise in between). It seems to be almost finished (two unsatisfiable classes left).
Finally, the intent of the developers is to get a results which is compatible with other approaches (here compatible means, either "able to reuse" external ontologies (e.g. OBOE) or mappable to existing schemas (e.g. EML (Ecological Markup Language) or the ISO 19115 metadata schemas or the Infobase data model).
Concept Documentation: Do the concepts have textual descriptions (always, often, sometimes, rarely, never)? >
Rarely, except those which corresponds to "enumerated types"
Reference Documentation: Does the ontology contain references to relevant publications or specification documents? >
No. But there are multiple documents (reports or slides and wiki) which details the ontology creation process which has been used, what other models have been looked at, how thje results has been evaluated.
Key framework concept(s): What are the key concepts around which the ontology is organized? Provide a phrase describing each (up to 3). >
Observation = ValueSet
- hasDevice a investigation_device (one class not further defined by the ontology)
- has a parameter_method (combo of method and parameter description, including units)
- hasInvestigationItem physical_thing which is a real world object (SamplingFeature)
The object of the observation is a selection_description which is based on a Population.
Range of subject matter: With respect to sensors, is this ontology narrowly focused, moderately broad, or comprehensive? >
Definitively an Observation ontology developed for BioDiversity apps.
Level of sophistication: Is this ontology more like a basic hierarchy of concepts, or is it really semantically sophisticated? >
Pretty sophisticated. It should look good in the UML view of TopBraid (assumption based on the content of the report + evidence that TopBraid was used). It also looks okay in Protege with not too many root classes.
Adoption: Is anyone other than the creator using this ontology? Are there many examples?>
There is large list of contributors. There are good and thorough examples of domain ontologies which complete the core ontology.
Best feature(s): What conceptual aspects of this ontology should be represented the SSN observation ontology if possible? >
The BioDiversity use case (handling of observation which corresponds to a population) is partially covered by O&M so anything which is handled in SERONTO and in OBOE should be taken in consideration.
Many generic aspects of an observation are covered in details.
SERONTO imports a unit ontology which looks okay.
Weakest feature(s): What issues does this ontology have that should be avoided in the SSN observation ontology? >
- the use of subPropertyOf to group properties by themes.
- the presence of unsatisfiable concepts
- the choice of using owl:individual (see Individuals by Classes tab in Protege)
- This is both good
- Because it grounds the abstract classes into complementary definitions
- and bad
- these definitions are less self-descriptive: the end user needs to read the comments (and they are not well documented elsewhere)
- this design choice could also be a roadblock for possible extensions.
- This is both good
Other remarks: Anything else of particular interest that you think people should know about? >
CEDEX ~ first iteration of SERONTO: to understand the major differences, you can compare:
- Figure 2 in [van der Werf et al. 2009]
- Figure 1 in [Madin et al. 2008]
Does someone knows what these guys plan to do next, and who they plan to collaborate with (e.g. TDWG or OBOE-led activities)?
Good basis: Would you recommend this ontology (or part of it) as the basis for the SSN ontology? Which parts? >
Yes, it shows what can be archived in terms of simplicity vs. versatility. It capture a range of uses cases at the generic level (especially some requirements which fall in the gaps between the multiple OGC standards).
Also, there is a notable effort to define the ontology against other initiatives like EML or ISO 19115.