Sensor Network Pilots for DRM 2 0 Sensor

Sensor Network Pilots for DRM 2. 0: Sensor Standards Harmonization Working Group Meeting at NIST Brand L. Niemann (US EPA), Co-Chair, Semantic Interoperability Community of Practice (SICo. P) Best Practices Committee (BPC), Federal CIO Council November 28, 2006 1

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

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 to be able to respond to emergencies. – Source: http: //colab. cim 3. net/cgibin/wiki. pl? Brand. Niemann 3

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

1. Data Networks • Acronyms: – SOA-Services- Oriented Architecture – HITOP: Health Information Technology Ontology Project – Co. P: Community of Practice – NHIN: National Health Information Network – EH DAT: US EPA – State Environmental Health Data Action Team – SSHWG: Sensor Standards Harmonization Working Group 5

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 Servicesto-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. 6

2. Highlights of Previous • 2. 1 DRM 2. 0 and SICo. P’s 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 7

2. 1 DRM 2. 0 and SICo. P’s Knowledge Reference Model 1. 0 and Metamodel • 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. Relationships and associations 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. 8

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 bottomup, 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. 9

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 SICo. P Pilots with Digital Harbor. • Semantic Wikis Implement the SICo. P 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 SICo. P Pilots with Visual Knowledge and other Semantic Wiki Developers. 10

2. 4 Initial Pilot Results http: //web-services. gov 11

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. 12

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 Co. P needs a collaborative tool to accomplish the objectives in the previous slide. • SICo. P is offering its VK Test Semantic Wiki in the next slide to accomplish this purpose. 13

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. , what’s in common and what’s not) • 3. 5 Model (or Ontology) In Mind (i. e. , Kang Lee) • 3. 6 Concept Map (e. g. Cmaps) 14

3. 1 Subject Index becomes an interface to multiple linked documents. Source: Ontologizing NSF Policy and Guidance Documents: SICo. P Semantic Wikis Pilot Project, November 20, 2006. 15

3. 1 Subject Index Concepts Instances at a Specific Location 16

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 17

3. 3 Basic Concepts from Upper Ontologies SUMO-Word. Net: http: //www. ontologyportal. org/ 18

3. 3 Basic Concepts from Upper Ontologies SUMO-Word. Net: http: //www. ontologyportal. org/ 19

3. 4 Commonality / Variability • Organization Domain Modeling (ODM)*: – http: //www. domainmodeling. com/stars. html#odm – *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 e. Government, 4 th Semantic Interoperability for EGovernment Conference, February 8 -9, 2006. Slides 14 -17. 20

3. 5 Model (or Ontology) In Mind Sensor Standards Harmonization • Sensor data • Sensor metadata ANSI N 42. 42 Data format standard for radiation detectors • <N 42 Instrument. Data> • <Remark> • <Measurement> <Instrument. Information> <Measured. Item. Information> <Spectrum> <Detector. Data> <Count. Dose. Data> <Analysis. Results> • <Calibrarion> K. Lee/NIST Sensor. ML Transducer. ML Sensor Metadata Process Model: • meta. Data. Group • Interference. Frame • Inputs • outputs • parameters • method CAP (Alert Message) IEEE 1451 (Sensor TEDS) IEEE 1451 TEDS: • Meta. TEDS • Transducer Channel TEDS • Calibration TEDS • Physical TEDS • Manufacturer-defined TEDS • Basic TEDS • Virtual TEDS CBRN Data Model Sensor Schema • Time of Observation • Contaminant ID • Dosage • Location • Weather Observation EDXL Alert. Message: • Message. ID • Sensor. ID • Send. Date • Message. Status • Message. Type • Source • Scope • Restriction • Address • Handling • Note • reference. ID • Incident. ID 21

3. 5 Model (or Ontology) In Mind Figure 1 Organization of an N 42 File Containing a Spectrum and Analysis Results 22

3. 5 Model (or Ontology) In Mind CAP V 1. 1 Document Object Model 23

3. 5 Model (or Ontology) In Mind EDXL-DE 1. 0 Document Object Model 24

3. 6 Concept Map http: //cmap. ihmc. us/ 25

4. Results • Harmonization of Standards in Semantic Wiki (partial list including): – ANSI N 42. 42 – CAP: CAP 1. 1 – Do. D CBRN Data Model – EDXL-DE – IEEE 1451. 0 – Where? – IEEE 1512. 3 -2002 – Where? – OGC SAS - Next 26

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. 27

4. Results 3. 1 Common Subject Index 28

4. Results Object Info • Type • Item Status • Reporting Data (timestamp) -------- • Person • Organisation • Equipment • Supplies • CBRN Agents • Weather • Geographic Feature • Control Feature (line, point, or shape on map) Action Info OBJECTITEMLOCATION Spatial Info ACTIONLOCATION • Location • Point • Line • Area • Volume 3. 2 Data Model CBRN Data Model High-level Overview Source: Tom Johnson, August 2, 2006 Metadata • Security classification • POCs • URLs • etc • Task • Event • CBRN Event • Location • Reporting Data (timestamp) • Objective / Target Note: This slide is for illustrative purposes only. It is not comprehensive in the entities represented nor in the relationships among them. 29

4. Results Not sure what to do here. 3. 2 Data Model 30

4. Results 3. 3 Basic Concepts from Upper Ontologies 31

4. Results • According to Word. Net, 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: Corpuscular. Object (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: has. Purpose (equivalent mapping) – 106227093 (grammar) a constituent that is acted upon; "the object of the verb". • SUMO Mappings: Noun. Phrase (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 32

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 33

Transducer. ML 4. Results Sensor. ML/OGC • Meta. Data • Calibration • Meta. Data Sensor Ontology ? ANSI 42. 42 • Calibration • Instrument Information • Data Types related to sensor • Sensor Identification Data • Sensor Metadata • Calibration data • Transfer function data • Sensor location information • Manufacturer-defined information IEEE 1451 • Calibration • Identification • Metadata • …. • Calibration • Meta. Data CBRN Data Model K. Lee , NIST Sensor Standard Harmonization Using Ontology ? 3. 5 Model (or Ontology) In Mind 34

4. Results 3. 6 Concept Map 35

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? 36

4. Results “Data Model of a Data Model” (Metamodel or Ontology of DRM 2. 0) Source: Brand K. Niemann, Jr. 37 3. 6 Concept Map

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. cim 3. net/cgibin/wiki. pl? EPAData. Architecturefor. DRM 2#nid 3 BEP 3. 6 Concept Map 38

5. Some Next Steps • Continue work on the multiple harmonization approaches. • Build the Concept Map. • Implement Five Steps for SSH Co. P: – – Co. P Mission Statement Co. P Membership List Co. P 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. 39

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

5. Some Next Steps • Harmonization Can Also Be Achieved from an Event Ontology: – Provided the messages and data from a 17 day disaster that EPA managed (chlorine tanker car derailment in Granitesville, SC, that caused death, damage, and displacement) to a team of vendors that produced an event ontology (in Protégé) that was then used to make the multiple vendors products and services semantically interoperable and to improve the rapid first response to that event. 41

5. Some Next Steps • Objectives: – – Bring in more standards to the harmonization. Involve more in the harmonization (next slide). Collect information on the sensors. Demonstration for funding. • Semantic Wiki is also a platform for building applications* with: – – Ontologies Rules Queries Inference See Top. Quadrant Tutorial at 5 th Semantic Interoperability for E-Government Conference, October 10 -11, 2006. 42

5. Some Next Steps Need help with populating this matrix Std-A Sensor-1 Std-B Std-C 1 3 Sensor-2 2 Sensor-3 See next slide for explanation 43

5. Some Next Steps • Semantic Wiki Pilot Framework: – 1 – Demonstrate compliance of Sensor-1 with Standard-A – 2 – Demonstrate design of new Sensor-2 that complies with a harmonized standard (e. g. Standard-A, Standard-B, and Standard-C). – 3 – Demonstrate that Sensors-1, 2 & 3 are interoperable with one another in a real world application. 44