440 likes | 601 Views
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 (SICoP) Best Practices Committee (BPC), Federal CIO Council November 28, 2006. Overview. 1. Data Networks
E N D
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 (SICoP) Best Practices Committee (BPC), Federal CIO Council November 28, 2006
Overview • 1. Data Networks • 2. Highlights of Previous • 3. Harmonization Approaches • 4. Results • 5. Some Next Steps
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.cim3.net/cgi-bin/wiki.pl?BrandNiemann
1. Data Networks See Next Slide for Acronyms.
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
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.
2. Highlights of Previous • 2.1 DRM 2.0 and SICoP’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
2.1 DRM 2.0 and SICoP’s 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.
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.
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.
2.4 Initial Pilot Results http://web-services.gov
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.
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.
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)
3.1 Subject Index Subject Index becomes an interface to multiple linked documents. Source: Ontologizing NSF Policy and Guidance Documents:SICoP Semantic Wikis Pilot Project, November 20, 2006.
3.1 Subject Index Concepts Instances at a Specific Location
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
3.3 Basic Concepts from Upper Ontologies SUMO-WordNet: http://www.ontologyportal.org/
3.3 Basic Concepts from Upper Ontologies SUMO-WordNet: http://www.ontologyportal.org/
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 eGovernment, 4th Semantic Interoperability for E-Government Conference, February 8-9, 2006. Slides 14-17.
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 • <N42InstrumentData> • <Remark> • <Measurement> • <InstrumentInformation> • <MeasuredItemInformation> • <Spectrum> • <DetectorData> • <CountDoseData> • <AnalysisResults> • <Calibrarion> 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
3.5 Model (or Ontology) In Mind Figure 1 Organization of an N42 File Containing a Spectrum and Analysis Results
3.5 Model (or Ontology) In Mind CAP V 1.1 Document Object Model
3.5 Model (or Ontology) In Mind EDXL-DE 1.0 Document Object Model
3.6 Concept Map http://cmap.ihmc.us/
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
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.
4. Results 3.1 Common Subject Index
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
4. Results Not sure what to do here. 3.2 Data Model
4. Results 3.3 Basic Concepts from Upper Ontologies
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
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
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 K. Lee , NIST CBRN Data Model Sensor Standard Harmonization Using Ontology ? 3.5 Model (or Ontology) In Mind
4. Results 3.6 Concept Map
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?
4. Results “Data Model of a Data Model” (Metamodel or Ontology of DRM 2.0) Source: Brand K. Niemann, Jr. 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.cim3.net/cgi-bin/wiki.pl?EPADataArchitectureforDRM2#nid3BEP 3.6 Concept Map
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.
5. Some Next Steps http://vkwiki.visualknowledge.com/wiki/sensors
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.
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 TopQuadrant Tutorial at 5th Semantic Interoperability for E-Government Conference, October 10-11, 2006.
5. Some Next Steps Need help with populating this matrix 1 3 2 See next slide for explanation
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.