Mike Botts – October Semantics and Sensor Web Enablement (SWE) OOSSI November 18, 2008 Dr. Mike Botts Principal Research Scientist University of Alabama in Huntsville

Helping the World to Communicate Geographically 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 Communicate Geographically 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 Communicate Geographically 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 Communicate Geographically 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 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 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 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 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 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. –“definition” of a property value e.g. –Example of the two working together:

Mike Botts – March SWE Examples SensorML –Davis thermometerDavis thermometer –QC Process ChainQC Process Chain Observation –Weather measurementWeather measurement –Oceans ACDP Examples shown in SensorML PrettyView –Video Camera on UAVVideo Camera on UAV –MBARI CTDMBARI CTD

Mike Botts – March 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 URL or URN ? The SWE schema doesn’t care; both are valid URL (e.g. –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 Relevant Links Open Geospatial Consortium – SWE Web Pages – SWE Forum – SensorML Forum –