Sensor Network Pilots for DRM 2.0: Sensor Standards Harmonization Working Group Meeting at NIST

1
Sensor Network Pilots for DRM 2.0Sensor
Standards Harmonization Working Group Meeting at
NIST

• Brand L. Niemann (US EPA), Co-Chair,
• Semantic Interoperability Community of Practice
  (SICoP)
• Best Practices Committee (BPC), Federal CIO
  Council
• November 28, 2006

2
Overview

• 1. Data Networks
• 2. Highlights of Previous
• 3. Harmonization Approaches
• 4. Results
• 5. Some Next Steps

3
1. Data Networks

• Responsibilities
• Enterprise Architecture Team Data Architecture
• Leads the architecting of environmental and
  health information needed to truly understand the
  state of the environment, measure environmental
  performance gains, and enable EPA be able to be
  respond to emergencies.
• Source http//colab.cim3.net/cgi-bin/wiki.pl?Bran
  dNiemann

4
1. Data Networks
Type Task/Tool Community of Practice Example
SOA Multiple Web Services/Model-Driven Architecture Federal SOA SOA CoP Demo (10/31/2006)
Semantic Multiple Vocabularies/Semantic Wikis Federal HITOP NHIN (11/9/2006) (EH DAT)
Sensor Multiple Standards/Semantic Wikis SSHWG SSHWG (9/12/2006 11/28/2006)
See Next Slide for Acronyms.
5
1. Data Networks

• Acronyms
• SOA-Services- Oriented Architecture
• HITOP Health Information Technology Ontology
  Project
• CoP Community of Practice
• NHIN National Health Information Network
• EH DAT US EPA State Environmental Health Data
  Action Team
• SSHWG Sensor Standards Harmonization Working
  Group

6
1. Data Networks

• Management (Governance)
• Federal Enterprise Architecture Reference Models
  Performance (goal), Business, Services, Data, and
  Technical (technology)
• Maturity Model 1 The Fifth Stage of Architecture
  Maturity Dynamic Venturing (partnering)
• Maturity Model 2 Shared Services-to-Web
  Services-to-Semantic Services
• Data Feeds Structured and the Network
  Semantically Interoperable.

Source Enterprise Architecture as Strategy by
Jeanne Ross, Peter Weill, and David Robertson,
Harvard Business School Press, 2006, 234 pp.
7
2. Highlights of Previous

• 2.1 DRM 2.0 and SICoPs Knowledge Reference Model
  1.0 and Metamodel
• 2. 2 Ontological Engineering
• 2. 3 Composite Applications and Semantic Wiki
• 2.4 Initial Pilot Results
• 2.5 Some Next Steps

8
2.1 DRM 2.0 and SICoPs Knowledge Reference Model
1.0 and Metamodel
Relationships and associations

• Metamodel Precise definitions of constructs and
  rules needed for abstraction, generalization, and
  semantic models.
• Model Relationships between the data and its
  metadata.
• Metadata Data about the data.
• Data Facts or figures from which conclusions can
  be inferred.

Source Professor Andreas Tolk, August 16, 2005
The purpose of this schematic is to show that we
need to describe information model relationships
and associations in a way that can be accessed
and searched.
9
2.2 Ontological Engineering

• Interoperability and Ontology
• Computer systems interoperate by passing
  messages.
• Every message has a meaning (semantics) and a
  purpose (pragmatics).
• The role of ontology is to make the semantics and
  pragmatics explicit in terms of the people,
  places, things, events, and properties involved.
• Communications among people and computers are
  always based on task-oriented ontologies. Those
  ontologies are bottom-up, highly specialized, and
  usually de facto.
• At every level, intentions, expressed in speech
  acts, are fundamental.

Source John Sowa Extending Semantic
Interoperability To Legacy Systems and an
Unpredictable Future, August 15, 2006,
Collaborative Expedition Workshop, National
Science Foundation, Arlington, VA.
10
2.3 Composite Applications and Semantic Wikis

• Composite Applications Use a Business Ontology to
  Make Diverse and Distributed Data and Information
  Sources Interoperate and Deliver a High-End User
  Interface
• See SICoP Pilots with Digital Harbor.
• Semantic Wikis Implement the SICoP DRM 2.0 and
  KRM 1.0 by Allowing Communities of Practice to
  Collaborate on Managing (using and reusing)
  Ontologies and Building Ontology-Driven
  Applications.
• See SICoP Pilots with Visual Knowledge and other
  Semantic Wiki Developers.

11
2.4 Initial Pilot Results
http//web-services.gov
12
2.5 Some Next Steps

• Sensor Standard Harmonization, Kang Lee, August
  29, 2006
• Solution of Sensor Standard Harmonization-Slide
  41
• The sensor standard harmonization is to extract
  the common terminologies, properties used by many
  of the sensor standards, and create a common
  sensor data model which could be a new standard
  to be developed or an existing sensor standard to
  be revised.
• A common set of sensor terminology and sensor
  classification.
• Common Properties or Characteristics of Sensors.
• Extract common properties of sensors from the
  existed sensor standards.
• Add additional information or specified
  information to sensor common data model.
• Map and translate common sensor model to each of
  existed sensor standard.

13
2.5 Some Next Steps

• So it is about finding the commonality and the
  variability in terminology across the multiple
  standards and organizing that within a framework
  of conceptual relationships.
• We have proposed and piloted a new metamodel for
  organizing a Community of Practices information
  based on the Federal Data Reference Model 2.0 and
  Ontological Engineering principles.
• The Sensor Standard Harmonization CoP needs a
  collaborative tool to accomplish the objectives
  in the previous slide.
• SICoP is offering its VK Test Semantic Wiki in
  the next slide to accomplish this purpose.

14
3. Harmonization Approaches

• 3.1 Subject Index (e.g. NSF Grants)
• 3.2 Data Model (e.g. CBRN)
• 3.3 Basic Concepts from Upper Ontologies (e.g.,
  time)
• 3.4 Commonality / Variability (i.e., whats in
  common and whats not)
• 3.5 Model (or Ontology) In Mind (i.e., Kang Lee)
• 3.6 Concept Map (e.g. Cmaps)

15
3.1 Subject Index
Subject Index becomes an interface to multiple
linked documents.
Source Ontologizing NSF Policy and Guidance
DocumentsSICoP Semantic Wikis Pilot Project,
November 20, 2006.
16
3.1 Subject Index
Concepts
Instances at a Specific Location
17
3.2 Data Model

• Caveat Represents a conceptual model of CBRN
  Battlespace relationships and common semantics
  and syntax. The model does not represent a
  canned software solution for system
  interoperability. Use in SOA and plans for
  Version 1.5.
• Formats Irwin Representation, Data Dictionary
  (Excel) and XML Schema.
• Data Dictionary (9/3/2006-4.9 MB Excel)
• Categories Entities 446, Attributes 3611, and
  Relationships 1317.
• Tabs
• Distribution Statement
• Entities
• Attributes
• Tables and Columns
• Valid Values
• Parent to Child Relationships
• Child to Parent Relationships
• All Relationships - Attribute Order

18
3.3 Basic Concepts from Upper Ontologies
SUMO-WordNet http//www.ontologyportal.org/
19
3.3 Basic Concepts from Upper Ontologies
SUMO-WordNet http//www.ontologyportal.org/
20
3.4 Commonality / Variability

• Organization Domain Modeling (ODM)
• http//www.domainmodeling.com/stars.htmlodm
• not to be confused with the Ontology Definition
  Metamodel (ODM)
• Methodology for engineering sets of reusable
  assets
• Stakeholder analysis
• Exemplar study
• Commonality and Variability modeling
• Asset-base engineering
• Exploit things in common . . . while respecting
  variation (e.g. object models and schema sharing)

Source Dean Allemang, Bringing Semantics to
Service-Oriented Architecture Ontology-based
Mediation for eGovernment, 4th Semantic
Interoperability for E-Government Conference,
February 8-9, 2006. Slides 14-17.
21
3.5 Model (or Ontology) In Mind

• Process Model
• metaDataGroup
• InterferenceFrame
• Inputs
• outputs
• parameters
• method

Sensor Standards Harmonization
SensorML
TransducerML

• Sensor data
• Sensor metadata

ANSI N42.42 Data format standard for radiation
detectors
Sensor Metadata
CAP (Alert Message)
EDXL
CBRN Data Model

• ltN42InstrumentDatagt
• ltRemarkgt
• ltMeasurementgt
• ltInstrumentInformationgt
• ltMeasuredItemInformationgt
• ltSpectrumgt
• ltDetectorDatagt
• ltCountDoseDatagt
• ltAnalysisResultsgt
• ltCalibrariongt

IEEE 1451 (Sensor TEDS)

• AlertMessage
• MessageID
• SensorID
• SendDate
• MessageStatus
• MessageType
• Source
• Scope
• Restriction
• Address
• Handling
• Note
• referenceID
• IncidentID

• Sensor Schema
• Time of Observation
• Contaminant ID
• Dosage
• Location
• Weather Observation

• IEEE 1451 TEDS
• MetaTEDS
• Transducer Channel TEDS
• Calibration TEDS
• Physical TEDS
• Manufacturer-defined TEDS
• Basic TEDS
• Virtual TEDS

K. Lee/NIST
22
3.5 Model (or Ontology) In Mind
Figure 1 Organization of an N42 File Containing a
Spectrum and Analysis Results
23
3.5 Model (or Ontology) In Mind
CAP V 1.1 Document Object Model
24
3.5 Model (or Ontology) In Mind
EDXL-DE 1.0 Document Object Model
25
3.6 Concept Map
http//cmap.ihmc.us/
26
4. Results

• Harmonization of Standards in Semantic Wiki
  (partial list including)
• ANSI N42.42
• CAP CAP 1.1
• DoD CBRN Data Model
• EDXL-DE
• IEEE 1451.0 Where?
• IEEE 1512.3-2002 Where?
• OGC SAS - Next

27
4. Results

• Standards documents put on the Web generally lack
  enough structural features and semantic
  interlinking and searchability to support
  effective online use.
• Not providing semantics in the links is one of
  the main navigational problems of the World Wide
  Web It is not until one opens the destination
  page of a link that one finds out that its
  content is not of interest.
• Semantic Links Within and Across Standards.

28
4. Results
3.1 Common Subject Index
29
4. Results

• Object Info
• Type
• Item
• Item Status
• Reporting Data (timestamp)
• -----------------
• Person
• Organisation
• Equipment
• Supplies
• CBRN Agents
• Weather
• Geographic Feature
• Control Feature (line, point, or shape on map)

• Action Info
• Task
• Event
• CBRN Event
• Location
• Reporting Data (timestamp)
• Objective / Target

OBJECT-ITEM-LOCATION
ACTION-LOCATION

• Spatial Info
• Location
• Point
• Line
• Area
• Volume

Note This slide is for illustrative purposes
only. It is not comprehensive in the entities
represented nor in the relationships among them.

• Metadata
• Security classification
• POCs
• URLs
• etc

3.2 Data Model
CBRN Data Model High-level Overview Source Tom
Johnson, August 2, 2006
30
4. Results
Not sure what to do here.
3.2 Data Model
31
4. Results
3.3 Basic Concepts from Upper Ontologies
32
4. Results

• According to WordNet, the noun"Object" has 4
  sense(s).
• 100003122 a tangible and visible entity an
  entity that can cast a shadow "it was full of
  rackets, balls and other objects".
• SUMO Mappings CorpuscularObject (equivalent
  mapping)
• 105905038 the goal intended to be attained (and
  which is believed to be attainable) "the sole
  object of her trip was to see her children".
• SUMO Mappings hasPurpose (equivalent mapping)
• 106227093 (grammar) a constituent that is acted
  upon "the object of the verb".
• SUMO Mappings NounPhrase (subsuming mapping)
• 105739206 the focus of cognitions or feelings
  "objects of thought" "the object of my
  affection".
• SUMO Mappings patient (subsuming mapping)

3.3 Basic Concepts from Upper Ontologies
33
4. Results

• Recall Common Subject Index (slide 28).
• Also see next slide
• Commonality Calibration and Metadata
• Variability Instrument Information and
  Identification.

3.4 Commonality / Variability
34
4. Results
TransducerML
SensorML/OGC

• MetaData

• Calibration
• MetaData

• Sensor Ontology ?
• Data Types related to sensor
• Sensor Identification Data
• Sensor Metadata
• Calibration data
• Transfer function data
• Sensor location information
• Manufacturer-defined information
• .

ANSI 42.42
IEEE 1451

• Calibration
• Instrument Information

• Calibration
• Identification
• Metadata

• Calibration
• MetaData

CBRN Data Model
K. Lee , NIST
Sensor Standard Harmonization Using
Ontology ?
3.5 Model (or Ontology) In Mind
35
4. Results
3.6 Concept Map
36
4. Results

• So the result can be
• An sensor ontology built from the concepts in
  slide 34 which references the standards
• An interlinked interface like the previous slide
  and/or
• A formal ontology information system using a tool
  like Cmaps (see next slide).
• Question Is this what we are expecting and can
  use?

37
4. Results
Data Model of a Data Model (Metamodel or
Ontology of DRM 2.0) Source Brand K. Niemann, Jr.
3.6 Concept Map
38
4. Results

• Use Cmaps
• http//cmap.ihmc.us/
• Output in Multiple File Formats
• PDF Version for Use in Document
• SVG Version for Use on the Web
• XML Version for Structure
• OWL Version for Semantic Relationships
• Simple Text Version
• Data Model for DRM 2.0
• See http//colab.cim3.net/cgi-bin/wiki.pl?EPADataA
  rchitectureforDRM2nid3BEP

3.6 Concept Map
39
5. Some Next Steps

• Continue work on the multiple harmonization
  approaches.
• Build the Concept Map.
• Implement Five Steps for SSH CoP
• CoP Mission Statement
• CoP Membership List
• CoP Strategy
• Training Conference Call (with items 1-3 entered
  into the Semantic Wiki space)
• Commitments to collaboratively publish and edit
  trusted reference knowledge sources in the
  Semantic Wiki space.

40
5. Some Next Steps
http//vkwiki.visualknowledge.com/wiki/sensors