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.

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

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

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

OntoSensor

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?>

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.

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

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.

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.

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

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.

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

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.

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.

SERES O&M

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.

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.

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.

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.

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.

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.

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.

Socio-Ecological Research and Observation oNTOlogy (SERONTO)

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).

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.

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:

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.