This page is being re-organised to provide a survey of the literature in relation to the use cases developed for the two deliverables defined in the charter on the sensor ontology and the semantic markup extension to SensorML-based services.
An iterative process has been used to identify and prioritize the use cases.
For the sensor ontology activity:
- A preliminary list of use cases has been established and used to rank the use cases Favorite Use Cases List
- Three categories of use cases have been short listed in the Reference Use Case List
- Each category will be further described in a separate wiki page at a general level and with more detailed information for a selected sub-use case
- These categories are:
- Device discovery: Find device(s) that meet given criteria
- Data discovery: Find data meeting certain criteria (e.g. temp + geo-temporal constraints
- Process/provenance: Describe and exploit information about how the data has been or can be collected to support other operation like composition of resources or diagnosis
The scope of the second activity is to extend the Sensor Markup Language (SML), one of the four SWE languages, to support semantic annotations of sensor descriptions and services that support sensor data exchange and sensor network management and will a serve similar purpose as that espoused by semantic annotation of Web services.
- The RDF-ization of sensor descriptions or data to support the discovery of resources and the recording of provenance information thanks to the use of named relationships and Web-based URIs,
- The creation of service annotations to enable the composition/mash up of individual sensor services and the creation of plans or workflow or macro-programs for sensor networks.
The wikipedia page on SensorML  states that:
SensorML provides standard models and an XML encoding for describing any process, including the process of measurement by sensors and instructions for deriving higher-level information from observations. It provides a provider-centric view of information in a sensor web, which is complemented by Observations and Measurements which provides a user-centric view.
Processes described in SensorML are discoverable and executable. All processes define their inputs, outputs, parameters, and method, as well as provide relevant metadata. SensorML models detectors and sensors as processes that convert real phenomena to data.
One of the challenges for the specification of the process/provenance use case is to cover not only the simple types of instrument management services allowing to access already sourced data or to acquire it according to a predefined workflow but also the more complex types of dynamically adaptive demand-driven data acquisition services.
Classification of Use cases
This classification is done in several steps:
- Identification of sub-uses cases for the ontology viewpoint and the markup viepoint
- Bundling of sub-use cases into a limited number project categories
This approach help to explain how these different use cases relate to each other:
The first table focuses on the discovery use cases. The different columns are used to specify the ontology modules which must be assembled together to cover the set of requirements for each type of discovery use case.
|Reference Use cases vs. Ontology scope||Sensor||Data||Sensor and Data||Sensor, Data and Process|
|Sensor/Device discovery||Sensor/Device Discovery (general, sensor type, functionality, host platform)||Sensor/Device Method and Classification|
|Data discovery||Data/Dataset Discovery (geospatiotemporal)||Sensor/Device Scope (output/measurable properties/measurable phenomenon)||Sensor/Device Scope and output API/format|
|Derived and Virtual Sensor Discovery||Derived and Virtual Sensor/Device (and Sensors Networks) Discovery (Method, Scope, API/format)|
Assumption: It is worth using a classifier to support discovery if and only the ontology enable reasoning over the three descriptive aspects (sensor, data and process)
The second table focuses on the provenance/process use cases. The different columns are used to specify specify the ontology modules which must be assembled together to cover the set of requirements for each type of provenance/process use case.
|Reference Use cases vs. management level||Process||Sensor, Data and Process|
|Provenance and Diagnosis||Discovery: control||Context: provenance, operation: diagnosis|
|Lightweight (static) composition and mashups||Operation: piping (predefined workflow)||Derived/Programmable Sensors and Sensors Networks|
|Dynamic composition and tasking||Operation: tasking (adaptive workflow)||Virtual Sensors and Sensors Networks|
Assumption (open to discussion): the process model is rich enough to be used on its own (or with a subset of the Sensor and Data ontologies) to control the sensor(s) operation(s).
The third table describes the bundles
|Short name||Long name||Discovery category||Process category||Examples|
|Semantic Sensor/Obs Portals||Semantically-enabled sensor and observation portal||Discovery of Sensor, Data and Process/APIs||Lightweight mashups, no possibility to command sensor, limited provenance support||Pachube, OOI, Semantic SOS-es|
|Semantic Observatories||Semantically-enabled virtual observatory||Discovery of Sensor, Data and Process/API - Discovery of Derived Sensors||Lightweight mashups and programmable sensors and sensor networks, rigorous provenance management, data quality evaluation and failure detection||SensorPedia, Semantic SAS-es, Scientific workflows|
|Semantic Sensor Networks and Grids||Semantically-enabled and programmable/adaptive sensors and sensor networks and grids||Discovery of Sensor, Data and Process/API - Discovery of Virtual Sensors||Dynamic composition and tasking of sensors and sensor networks (and models), rigorous provenance management, data quality evaluation and failure detection, adaptivity to faults and to real world events||NCSA Virtual sensor (Liu et al.), GSN/Swiss experiment|
The fourth table focuses on service annotations with the discovery use cases. The different columns are used to specify the annotations which must be present in a service description to cover the set of requirements for each type of discovery use case. The discovery of sensors and observations will likely occur through services. Annotation of these services will improve the process of discovery. There are four concepts defined within the OGC-SWE Sensor Observation Service GetCapabilities document that should be annotated to aid discovery of sensors and observations:
- ObservationOffering - SOS organizes collections of related sensor systems into Observation Offerings. The concept of an Observation Offering is often equivalent to that of a sensor constellation.
- Procedure - Method, algorithm or instrument (e.g., sensor).
- ObservationProperty - An observable or phenomenon.
- FeatureOfInterest - Represents the identifiable object(s) and event(s) on which the sensor systems are making observations (i.e, real-world entities, named locations, etc.).
The following table shows mapping of annotations to concepts in ontology.
|Service Annotation||Ontology Concept|
|Procedure||Device or Sensor (System?)|
The following table details which annotations are important for each use case.
|Reference Use cases vs. Service Annotations||Sensor||Data||Sensor and Data||Sensor, Data and Process|
|Sensor/Device discovery||ObservationOffering, Procedure, ObservationProperty, FeatureOfInterest||ObservationOffering, Procedure, ObservationProperty, FeatureOfInterest||ObservationOffering, Procedure, ObservationProperty, FeatureOfInterest|
|Data discovery||ObservationProperty, FeatureOfInterest||ObservationOffering, ObservationProperty, FeatureOfInterest||ObservationOffering, ObservationProperty, FeatureOfInterest|
|Derived and Virtual Sensor Discovery||ObservationOffering, Procedure, ObservationProperty, FeatureOfInterest|
Classification of the published literature according to the sub-categories identified above
TO BE COMPLETED
From discovery to lightweight mashup and provenance
|OntoSensor ( Goodwin and Russomanno)||Semantic Sensor/Obs Portals|
|OOSTethys/Oceans IE (Bermudez et al.)||Semantic Sensor/Obs Portals||Semantic Observatories|
|MMI (Graybeal et al. )||Semantic Sensor/Obs Portals||Semantic Observatories|
|SemSos (Henson et al.)||Semantic Sensor/Obs Portals||Semantic Observatories|
|CSIRO/IOOS and Hydro Sensor Web||Semantic Sensor/Obs Portals||Semantic Observatories|
|SemSorGrid4Env/Flooding use case||Semantic Sensor/Obs Portals||Semantic Observatories|
|University of Muenster (SIGI)||Semantic Sensor/Obs Portals||Semantic Observatories|
|S@ny||Semantic Sensor/Obs Portals||Semantic Observatories|
|Janowicz et al. (multiple papers) also Kuhn, Probst,||Semantic Sensor/Obs Portals||Semantic Observatories|
|Patrick Maue, Philippe Duchesne, and Sven Schade||Semantic Sensor/Obs Portals||Semantic Observatories|
From lightweight mashup and provenance to composition and macro-programming
|Ontology-driven Adaptive Sensor Networks (Avancha et al. 2004)||Semantic Sensor Networks and Grids|
|SensorMasher (Le Phuoc, Hauswirth)||Semantic Observatories||Semantic Sensor Networks and Grids|
|SemSorGrid4Env/Fire detection use case||(Semantic) Sensor Networks and Grids||Semantic Sensor Networks and Grids|
|SENSEI (Barnaghi et al.)||Semantic Sensor Networks and Grids||Semantic Sensor Networks and Grids|
|CSIRO Weather Station and Plant/Ecological monitoring WSNs||Semantic Sensor Networks and Grids|
|GSN (Swiss experiment) ||Semantic Sensor Networks and Grids|
|NEESGrid||Semantic Sensor Networks and Grids|
|VSTO and CEDAR||Semantic Observatories||Semantic Sensor Networks and Grids|
|SPASE||Semantic Observatories||Semantic Sensor Networks and Grids|
|Liu et al 2009 TA-RDF NCSA ||Semantic Observatories||Semantic Sensor Networks and Grids|
|Calder et al. 2009 CESN Machine reasoning about anomalous sensor data||Semantic Observatories||Semantic Sensor Networks and Grids|
|Machine reasoning about anomalous sensor data (Calder et al.) ||Semantic Observatories (with provenance / diagnosis)|
|Mac Carthy et al. Reasoning-ready Sensor data||Semantic Sensor/Obs Portals||-|
|Optima/SensorMap (Kolli and Doshi)||Semantic Sensor/Obs Portals||?|
|ES3N (Lewis et al.) ||(Semantic) Sensor Networks and Grids||?|
|MeT (Kawashima et al.) ||(Semantic) Sensor Networks and Grids||?|
|Szekely and Torres 2004 ||(Semantic) Sensor Networks and Grids||?|
|Pedigree Ontology for Level-One Sensor Fusion (Matheus et al. 2005, Cerutti 2004)||Semantic Observatories||?|
|Semantic Agent Technologies for Tactical Sensor Networks (Jiang, Cybenko 2004) ||(Semantic) Sensor Networks and Grids||?|
|Wun et al Semantic Data Fusion in Sensor Networks||(Semantic) Sensor Networks and Grids||?|
+ Other SSN06 and SSN09 papers
Identified Use Cases
- Use Cases considered for the development of the MMI device ontology
- Ocean Observing Initiative Concept of Operations -- a very detailed use case addressing automated integration of sensor results in real time (among other things)
- OOI Device Life Cycle Concept of Operations -- about all the phases of operation an instrument goes through
- Example application using ontologies to relate types of ecosystem events to properties of the ecosystem and the sensors observing it.
- Vocabulary intended to promote global harmonization of terminology used in metrology.
- International Vocabulary of Metrology - Basic and General Concepts and Associated Terms http://www.oiml.org/publications/V/V002-200-e07.pdf
- Water Data Transfer Standards - XML dataset content validation
- XML dataset content validation (1 page summary)
- https://twiki.auscope.org/twiki/bin/view/Grid/VocabularyServiceUCValidation (visible doc hosted by related project)
- https://wiki.csiro.au/confluence/display/WaterInformatics/Validation+Service (internal wiki page - restricted access)
Use Case List (survey/priority page)
- List of use cases (1 line per use case) considered most important