Building Semantic and Syntactic Interoperability Into EnviroSensing Systems: Part 1

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.
 
Reification
            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.
 
Vocabularies
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.
 
Models:
            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”
 
 
X-DOMES
 
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