Building Semantic and Syntactic Interoperability Into EnviroSensing Systems: Part 1


The ESIP EnviroSensing Collaboration Area was organized around the need to create resource guides and share deployment strategies for real-time sensor networks. The NSF EarthCube Integrative Activity called the X-DOMES (Cross-Domain Metadata EnviroSensing) Network is actively building tools and seeks to develop a community of stakeholders within the ESIP community to foster sensor metadata best practices that result in the creation of machine-harvestable, standards-based descriptions of how an observation came to be.

The first half of the workshop is intended to guide participants in the creation of sensor-related vocabularies that include observable properties, sensing technologies, observational parameters and processing methods as spreadsheets and then to assist them in the registery of the content using the newly implemented ESIP-COR (Community Ontology Registry) or a registry within their domain, such as the MMI-ORR (Marine Metadata Interoperability - Ontology Registry & Repository). This will provide a resolvable resource (URLS) for each term which can be used in annotating web services (such as OGC-SWE SOS).

The second half of the session enables participants to develop SensorML profiles for sensors within their domain, referencing the registered terms. This exercise prefaces X-DOMES planned work to engage sensor manufacturers to build machine-harvestable sensor descriptions, which will be also be registered so the content can be resolvable, discoverable and persist within the ESIP Enviro-Sensing community. As the participants assess the SensorML Editor/Viewer, we will develop a cross-domain approach that engages sensor manufacturers and sensor field operators. The main goal is to capture knowledge where it is best understood and provide the capability to fully-describe content to enable data quality assessment and automated quality control.


This workshop relates to activities being planned by Tom Narock and the Semantic Web Committee.

Log in to see presentations attached to this page.

Building Semantic and Syntactic Interoperability Into EnviroSensing Systems: Part 1 
Basic introductions into why we might care about these different things.
Work toward building ontologies has been demonstrated.
There was a need for role-based creation.
Sensor manufacturer knows more than operators, and this information can change with different parameters moved. You need all this information to describe how observable property becomes and observation.
Three big things to discuss in this meeting:
Community Ontology Registry
SensorML Viewer/Editor
Content Access Modules
Community Ontology Registry
Formally capturing knowledge about the world
            Sometimes associated with artificial intelligence
Statements are captured as statements: “Triples”
            Subject -> Predicate -> Object        
            “Calvin” -> “Has friend” -> “Hobbes”
RDF: Resource Description Framework
            Resource -> Resource -> Resource
Resources: IRIs and Literals
            IRI: Internationalized Resource Identifier
            Literal: Number or String
            Subject -> Predicate -> Object
            IRI         -> IRI                        -> Literal or IRI
IRIs have replaced URIs in use throughout much of this. Though, URIs are still very popular.
There are rules for inference to take into account as well.
Based on facts, certain statements can be inferred.
            Triples can reference triples
            Can be seen as recursive
Capturing the triple data can be done in multiple ways.
            Listing them is the most simple.
            Table methods work as well
How do you handle complex variables with triples?
            Example: The sky is not ALWAYS blue, so Sky -> Has Color -> Blue, is kinda                wrong.
            Sometimes these sorts of things are limiting.
            Triples can make any assertion. They are axiomatic.
            In the “real” web world, knowledge is always changing. This is a fairly philosophical discussion.
            The end result is that there are some limitations if this is compared to how the actual world is, but this is still a strong way to represent reality.
Note that there are a variety of tools to do these sort of things.
First, we name things, then we use names.
            “This ‘SST’ dataset was produced by the organization ‘Acme’”
                        This sentence is not useful out of context, it is not formal enough.
What about ontologies?
            Vocabularies are ontologies.
            The more sophisticated the rules or semantics that you want to associate with names, the more you should use the term ontology.
Controlled vocabularies
            Names should be agreed upon by the community.
            This reduced discrepancies.
            Example: CF Standard names
The idea here is to use vocabularies in your own vocabularies.
            These are very important for discovery, including metadata.
Semantic interoperability does not need an overarching vocabulary.
Use standard vocabulary in your own data and metadata in your own vocabulary.
ORR Origins
            Born as part of MMI’s vision for a sematic framework
MMI ORR is on version 3. There is another year to go before the end, thought it is already usable.
The backend is in good shape. The front end is the current work in progress.
What is ORR?
            A registry, a catalog of pointers to ontologies and the associated metatdata
            A repository for all those ontologies
ORR Capabilities
            IRIs have “first class” status
            Inferences can happen
            Metadata ontology capabilities
Community driven, and open source
There are several client application-ORR interactions
            Data Portal (categories)
            Data Providers (terms)
            Data Portal and client applications
 3 major instances of this system: MMI, ESIP, and SensorML ORR
Live demo time.
Check out the recording!
Building Semantic and Syntactic Interoperability Into EnviroSensing Systems: Part 2
SWE and SensorML
Focus: Creating SensorML documents is challenging, which limits the number of users. This is a problem that needs to be solved, because SensorML is useful.
OGC Sensor Web Enablement (SWE)
            Currently being used, but we’d like them to be used further.
SWE = sensor, actuator, and process interoperability and integration
            Designed to support all of these
Substantial supported functionality.
There are encoded standards, web service interfaces, and hardware interface standards.
This talk is about SensorML 2.0.
What is SensorML?
            Models and XML encoding for describing systems.
            Describes processes and process networks related to observations and measurements
Example Applications
            Electronic spec sheets
            Lineage of observations (sensors, environment, processing, QA/QC)
            Sensor and data stream description
            And more!
Process chains can give many useful bits of information!
            Georeferencing satellite data, or calculating quantities from multiple sensors.
Goal: push processing using a vast set of interconnected SensorHubs.
            Simple process (interpolation)
            Physical Component (detector)
            Aggregate (computational model)
            Physical (sensor system)
There is a large amount of SensorML Properties that are useful to know (listed on slides).
Semantic Connections
            Hybrid system using XML to describe documents
            Definition attributes link to ontology entries
There are some code demos available on the recorded version of this presentation.
These include the interpolators and a simple sensor descriptor.
SensorML 2.0 has provided a way to look and work with SensorML documents (viewer and editors). Take a sensor description and show it in a way that’s friendly, and more.
A demonstration of the spec sheet and workflow are shown.
Live demonstration of SensorML 2.0 (check out the recording)
Ultimately, SensorML should be integrated into OpenSensorHub (OSH).
            Ideally, connect SensorML to “the whole big picture”
A SensorML Registry will be available for optional data storage and more.
User Stories and examples for what this project should consider to develop the software.
Example Discussion (on the recording):
            -What kinds of instruments were deployed during a given field campaign?
            -Use as a discovery tool in both space and time and by attributes.
            -Dynamic search capabilities
            -Referenced to a unique ID for a given sensor
            -How should data be linked?
            -Get SensorML data from registry so that I don’t have to encode all this metadata myself.
            -Create and compile information by author or organization

Fredericks, J.; Botts, M.; Building Semantic and Syntactic Interoperability Into EnviroSensing Systems: Part 1; 2016 ESIP Summer Meeting. ESIP Commons , April 2016