Mike Botts – October 2008 1

Semanticsand

Sensor Web Enablement (SWE)

OOSSI

November 18, 2008

Dr. Mike Botts

mike.botts@uah.edu

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