mike botts – october 2008 1 semantics and sensor web enablement (swe) oossi november 18, 2008 dr....
Post on 19-Dec-2015
215 views
TRANSCRIPT
Mike Botts – October 2008 1
Semanticsand
Sensor Web Enablement (SWE)
OOSSI
November 18, 2008
Dr. Mike Botts
Principal Research Scientist
University of Alabama in Huntsville
Helping the World to CommunicateGeographically
What is SWE?
• SWE is technology to enable the realization of Sensor Webs– much like TCP/IP, HTML, and HTTPD enabled the WWW
• SWE is a suite of standards from OGC (Open Geospatial Consortium)– 3 standard XML encodings (SensorML, O&M, TML)– 4 standard web service interfaces (SOS, SAS, SPS, WNS)
• SWE is a Service Oriented Architecture (SOA) approach
• SWE is an open, consensus-based set of standards
Helping the World to CommunicateGeographically
Why SWE?
• Break down current stovepipes
• Enable interoperability not only within communities but between traditionally disparate communities– different sensor types: in-situ vs remote sensors, video, models, CBRNE– different disciplines: science, defense, intelligence, emergency management, utilities, etc.– different sciences: ocean, atmosphere, land, bio, target recognition, signal processing, etc.– different agencies: government, commercial, private, Joe Public
• Leverage benefits of open standards– competitive tool development– more abundant data sources– utilize efforts funded by others
• Backed by the Open Geospatial Consortium process– 350+ members cooperating in consensus process– Interoperability Process testing– CITE compliance testing
Helping the World to CommunicateGeographically
What are the benefits of SWE?• Sensor system agnostic - Virtually any sensor or model system can be supported
• Net-Centric, SOA-based– Distributed architecture allows independent development of services but enables on-the-fly
connectivity between resources
• Semantically tied– Relies on online dictionaries and ontologies for semantics– Key to interoperability
• Traceability– observation lineage– quality of measurement support
• Implementation flexibility– wrap existing capabilities and sensors– implement services and processing where it makes sense (e.g. near sensors, closer to user, or
in-between)– scalable from single, simple sensor to large sensor collections
Helping the World to CommunicateGeographically
Note: You are Down in the Dirt• During this workshop, you are “down-in-the-dirt”, dealing with the details
of XML, semantic dictionaries and ontologies, web services, etc.
• You are pioneers– Many of you may remember working at the level of HTML and HTTPD at the beginning
of the WWW (some of you still may be working at that level)
• For SWE, help is on the way– Dictionaries being created– New implementations of SWE being added daily– Discovery of services and sensor coming on line (more slowly than desired)– Tools being developed (server, client, middleware)
• In the future you will:– Create SensorML and Observations without dealing with XML– Set up new services without programming– Discover sensors and observation through semantic relationships without worrying
about ontologies– Pick your client(s) of choice for discovering, accessing, processing, fusing, and
exploring observations intuitively
Mike Botts – November 2008 6
Tool Example: SensorML Table Viewer
• Provides simple view of all data in
SensorML document
• Beta Version released
• Future version will support
resolvable links to terms, as well as
plotting of curves, display of images,
etc
• Future versions will provide similar
capabilities for Observations
Mike Botts – November 2008 7
Tool Example: SensorML Process Editors
Currently, we diagram the process (right top) and then type the XML version; soon the XML will be generated from the diagram itself (right bottom)
Currently, SensorML documents are edited in XML (left), but will soon be edited using human friendly view (below)
Mike Botts – January 2008 8
Incorporation of SensorML/SWE into Space Time Toolkit
Space Time Toolkit has been retooled to be SensorML process chain executor + SLD stylers
Mike Botts – March 2008 9
Why are Semantics Important to SWE?
• SWE depends on “soft-typing” for properties and data
– You will not find elements such as temperature, wave height, standard deviation,
focal length, etc. hard typed within any of the schema
– Observable properties, sensor characteristics, events, etc. ALL get their meaning
through references to online dictionaries or ontologies
• Interoperability
– You say tomato, I say tomato, but do we mean the same thing?• If we both point to the same semantic definition, we can assume that we do.
• If we point to different semantic definitions, maybe we mean the same thing, maybe we
don’t, but we hope that ontological relationships between the two will help us understand if
and how they’re different
• Advanced discovery and exploitation
– Example: find all measurements of temperature of the ocean
– Example: find all sensors and measurements that can help me predict an algal
bloom in the Gulf of Mexico
– Example: are we heading toward an El Nino year?
Mike Botts – March 2008 10
How do we relate SWE to Semantics?
• SWE Common data schema
– Used throughout SWE for defining data
– e.g. used in Observations for defining observable properties (temperature, etc)
– e.g. used in SensorML to define inputs, outputs, parameters, characteristics,
capabilities, interface properties
– e.g. used in Sensor Planning Service (SPS) to define tasking parameters
• In SWE Common, dictionaries and ontologies referenced in two
pervasive attributes:
– “xlink:role” and “xlink:arcrole” of a property• e.g. <sml:contact xlink:arcrole=“urn.ogc:def:property:expert”>
– “definition” of a property value• e.g. <swe:Quantity definition=“urn:ogc:def:property:temperature”>
– Example of the two working together:
<sml:parameter xlink:role=“urn:ogc:def:property:maximum”>
<swe:Quantity definition=“urn:ogc:def:property:waveHeight”>
Mike Botts – March 2008 11
SWE Examples
• SensorML
– Davis thermometer
– QC Process Chain
• Observation
– Weather measurement
– Oceans ACDP
• Examples shown in SensorML PrettyView
– Video Camera on UAV
– MBARI CTD
Mike Botts – March 2008 12
Need for Term Definitions in SensorML
• Observable properties / phenomena / deriveable properties (“urn:ogc:def:property:*” )
– temperature, radiance, species , exceedingOfThreshold, earthquake, SST, etc.
– rotation angles, spectral curve, histogram, time-series, swath, etc.
• Identifiers and classifiers (“urn:ogc:def:identifierType:*” or “urn:ogc:def:property:*” ??)
– Identifiers – longName, shortName, model number, serial number, wing ID, etc.
– Classifiers – sensorType, intendedApplication, processType, etc.
• Sensor and process terms (“urn:ogc:def:property:*” )
– IFOV, focal length, slant angle, weight, etc.
– Polynomial coefficients, matrix, etc.
• Role types (“urn:ogc:def:property:*” or “urn:ogc:def:role:*” ??)
– Expert, manufacturer, integrator, etc.
– Specification document, productImage, algorithm, etc.
• Capabilities, Characteristics, Interfaces, etc. (“urn:ogc:def:property:*” )
– Width, height, material composition, etc.
– Ground resolution, dynamic range, peak wavelength, etc.
– RS-232, USB-2, bitSize, baud rate, base64, etc.
• Sensor and process events (“urn:ogc:def:eventType:*” or “urn:ogc:def:property:*” ??)
– Deployment, decommissioning, calibration, etc.
Mike Botts – March 2008 13
URL or URN ?
• The SWE schema doesn’t care; both are valid
• URL (e.g. http://blah.blah)
– con: “messier”
– con: not persistent (i.e. can break when machine or domain change)
– pro: unique identifier of resource
– pro: currently resolvable through DNS
• URN (e.g. urn:blah:blah)
– pro: “cleaner”
– pro: unique identifier of resource
– pro: persistent (in theory)
– con: must be resolved using a registry or a known urn resolver
• Can have both (i.e. a URN that resolves to a URL)
Mike Botts – March 2008 14
Relevant Links
• Open Geospatial Consortium –
http://www.opengeospatial.org
• SWE Web Pages –
http://www.ogcnetwork.net/SWE
• SWE Forum –
https://lists.opengeospatial.org/mailman/listinfo/swe.users
• SensorML Forum –
https://lists.opengeospatial.org/mailman/listinfo/sensorml