Applications of Ontology OWL to: Geospatial Feature Data Dictionaries

1. Applications of Ontology OWL to: • Geospatial Feature Data Dictionaries • Rapid Data Generation: Order of Battle and Entity Type Data Management

2. My involvement • Participation • M&S COI Data Management Working Group • ASW COI Data Management Working Group • NATO M&S Group (MSG) 085 – C2 & Simulation Interoperability • Simulation Interoperability Standards Organization (SISO) • Standards Activity Committee • Military Scenario Definition Language (MSDL) • Coalition Battle Management Language (C-BML) • Simulation Conceptual Modeling (SCM) • Architecture-Neutral Data Exchange Model (ANDEM) • Projects: • M&S Coordination Office • US Army Simulation to C4I Interoperability (SIMCI) OIPT • Joint Staff J7 Joint Coalition Warfighting (formerly JFCOM) • Coordinated with • US Army Operational Test Command • AMSAA • Global Force Management Data Initiative (GFM DI) • US Army PD Tactical Network Initialization

3. 10F-SIW-068Mapping Data Models and Data Dictionaries – Removing the Ambiguity

4. Overview • Background • Data dictionaries must be mapped to enable translation and reuse of datasets and tools based on one data dictionary or another. • Problems • Current mapping processes use English language and spreadsheets to capture the mappings. • Too much room for interpretation. • Difficult to evaluate or compare mapping results. • No clear path to using mappings in data mediation software. • Our objective • Explore and demonstrate the benefits of an ontology-base approach to data dictionary mapping.

5. We focused on mapping of EDCS and NFDD ... • Both are dictionaries of geospatial feature concepts • Both contain concepts as: • Features / Classifications • Attributes • Enumerations • Both provide definitions for each Concept, but little or no taxonomy or relationships • Both are available as MS Access Databases EDCS – SEDRIS Environmental Data Coding Specification NFDD – National System for Geospatial-Intelligence (NSG) Feature Data Dictionary

6. ...But recognized that there are others. Unlike NFDD and EDCS, these are actual thesauri with broader / narrower relations, preferred and alternate names, definitions, etc. Sub-schemes and implementation schemes • Some schemes are “based” on a common data dictionary, but semantics have drifted and diverged for various reasons. • Some schemes are not based on any common data dictionary. Environment-related thesauri: • GEMET – GEneral Multilingual Environmental Thesaurus • AGROVOC – a thesaurus of agriculture, forestry, fisheries, and other domains • NALT – National Agriculture Library Thesaurus General use knowledge bases: • DBPedia – a structured extraction of the Wikipedia body of knowledge • OpenCyc – Open source Cycorp general knowledge base • WordNet – Lexical database of the English Language

7. AGC Mapping Relations Set Theory shows duplicate relationshipswith ambiguous differences.

8. AGC Mapping Relationships OWL is built upon set theory, where OWL classes are sets. A B A B A A \ B“small” B A B has part A B A \ B“small” B \ A“small” A B Set Theory shows duplicate relationships with ambiguous differences. A \ B B \ A

9. “Qualified” Relationships • A “qualified” relationship is one that hold under some known condition or criteria. • Described as one or more attributes having certain values. • In the examples below, a qualification Q1on concept B forms a subconceptBQ1. B B BQ1=A B \ A B \ A A=B? B A B BQ2=A2 BQ3=A3 BQ1=A1 AQ1=A \ B BQ1=B \ A Both AGC and SEDRIS team schemes capture qualified relationships.

10. Example of “Qualified” Relationship AGC Relation: “EDCS (Well) and NFDD (Fountain) concepts overlap completely (qualified)” EDCS: Well EDCS NFDD equivalent EDCS: WellQ1: well type = ‘Fountain’ NFDD: Fountain

11. Integration and Linking of Dictionaries Railway network Infrastructure Track AGC Relation: “NFDD (Railway) is an aggregate of EDCS (Railway track)” Aggregate of Railway Railway track Railway Equivalent EDCS NFDD GEMET AGROVOC WordNet High-speed railway Underground railway Railroad • Potential outcome: Integration of data dictionary concepts • More than just mapping • Semantic alignment across multiple data dictionaries • Example: NFDD “railway” and EDCS “railway track”

12. Using Mappings in Data Translation A B A AQ1=B A \ B A B has part A A B B A \ B B \ A AQ1=A \ B BQ1=B \ A

13. Roadblocks: The same old problemsGarbage In  Garbage Out Weak semantics in EDCS and NFDD perpetuate ambiguity. • With poor mappings, we get wrong data faster. • Weak semantics in data dictionaries beget poor mappings. • Both EDCS and NFDD Concepts have: • Short definitions. • No scoping or context statement. • No relationships to other Concepts (internal or external) to capture the intended “world view”. • Perhaps NFDD and EDCS should be mapped onto themselves first? • EDCS includes a partial taxonomy in its definitions, but can be more precise.

14. Rapid Data Generation RDG Rapid Data Generation (RDG)

15. RDG Background RDG is a High Level Task (HLT) selected by the DoD M&S Steering Committee (M&S SC) for funding through the M&S Coordination Office PE to address M&S Enterprise Data issues Mr. Tom Irwin, Joint Staff (J7), and Dr. Amy Henninger, Army, are the M&S SC co-leads for governance of RDG Government PM was Mike Willoughby, JTIEC; replacement TBA Performers are JS J7 JCW (MITRE & GDIT), University of Texas Applied Research Laboratory, Oak Ridge National Laboratory and others Objective: Reduce the resources required to integrate and initiate data, eliminate or reduce duplicative efforts, and promote data commonality for M&S activities across the DoD.

16. RDG implements the DoD Net-Centric Data Strategy (NCDS) by making data Visible – search via SOA services or a user interface Accessible – access via SOA services Understandable / Interoperable – described by structural metadata Trusted – controlled access to data integrated from authoritative data sources RDG implements the DoD Net-Centric Services Strategy (NCSS) by making information and functional capabilities available as SOA services RDG implements the DoD M&S Enterprise Data Strategy by Implementing the NCDS and NCSS for M&S data Using the M&S Community of Interest (COI) Data Management Working Group to gain stakeholder input RDG Summary

17. Rapid Data Generation 5 Year M&S Data Enterprise Investment Strategy L I FE CYCLE MANAGEMENT FY 10 FY 11 FY 12 FY 13 FY 14 FY 15 Year of Funding FY09/10 HLT-IC2 Capability Red & Blue Order of Battle HLT IC2 GFM JTDS • Enterprise Approach • SC Oversight • Metrics • Immediate Progress • Requirements Driven Geospatial, Atmosphere, Space, Ocean D P Logistics D P D P Command & Control D P D P D P Common Data Production Environment OOB Final Exam OOB Mid Term Exam = SC Decision Points Other Capability On/Off-ramps D P = Development Planning SC Governance, Community Participation, Cross-Doman Interoperability

18. RDG M&S CDPE OOB Data Services Conceptual Overview(Draft Pre-decisional) “Non-US” Force OOB Data Provider M&S Catalog USN Common Distributed Mission Training Station (CDMTS) Joint Training Data Services (JTDS) OBS Integrated Gaming System (IGS) Operational OOB Data Providers (i.e. GFM DI, JPES/APEX, etc.) RDG M&S CDPE Authentication/ Authorization Service CDPE Discovery Metadata Catalog OOB Discovery Service USAF Scenario Generation Server (SGS) OOB Subscription Service CDPE Portal OOB Edit/Build Service Discovery Metadata Update Service Data Retrieval Service US Special Operations Command (USSOCOM) OSD/CAPE Joint Data Support (JDS) Other M&S OOB Data Provider, Integrator, or Consumer Systems

19. Rapid Data Generation Data issues

20. Discovery, Retrieval, and Understanding Discovery Retrieval and Understanding Need to support exchange of data in multiple data formats, including incompatible ones. Need to define and align the semantics of the formats. Promote convergence of formats (or schema fragments) for Order of Battle-related data. • Need to tag data products with “discovery metadata” to enable visibility through search services. • Specifically, need to tag data products containing Unit, Task Organization, and related data so they are discoverable based on • Unit identifiers and names • Unit types and capabilities • Major end-item equipment types • Mission, Scenario, garrison and other contexts

21. Metadata Types Descriptions about the content and context of the asset, including author, title, pedigree, source, media type, and more. Schemas, grammars, and structures that data assets conform to. The definitions, references, and models that define the meaning of data assets to capture intent and preclude misinterpretation. Typically tightly related to the Structural Metadata. DoD Directive 8320.02, “Data Sharing in a Net-Centric Department of Defense” Discovery Metadata [Information about a data asset] that allows data assets to be found using enterprise search capabilities. Structural Metadata Information provided about a data asset that describes the internal structure or representation of a data asset (e.g., database field name, schemas, web service tags). Semantic Metadata Information about a data asset that describes or identifies characteristics about that asset that convey meaning or context (e.g., descriptions, vocabularies, taxonomies).

22. Relationship of Discovery Metadata to OOB Data • Stored in a metadata repository • Shared to catalogs for search and discovery • Conforms to either • DDMS • MSC-DMS • Augmented with • Ucore/C2 Core content for discovery • RDG extensions for OOB discovery Discovery Metadata “Metacard” for Data Asset • Stored in a data repository • Tagged with a metacard • Conforms to some structure metadata (format or structure). OOB Data Asset • Stored in the DoD Metadata Registry (MDR) • Tagged with a metacard • Conforms to some structure metadata (format or structure). Structural Metadata Format / XML Schema

23. What is meant by “Order of Battle?” • Perspective: • Authorized • On-Hand • Planned • Anticipated • Reported • Scenario • Organic / garrison • Task Organized (OPORD / FRAGO) • Scope / resolution: • Operational vs. Systems Architecture • Aggregated vs. entity-level • Contains network? • Contains readiness and holdings? • Contains locations? • Contains plans and orders? • Validated for purpose: • Acquisition • Analysis • Experimentation • Intelligence • Planning • Training • Test & evaluation • Verified for system needs: • C4I system initialization • C4I network initialization • Simulation and instrumentation initialization Organic Assigned Attached OPCON TACON Direct support Reinforcing General support-reinforcing General Support Units / Organizations ‘Sides’ Nations Coalition Civilian OPFOR Friendly Hostile Neutral C2 Network Locations Platforms & Life Forms Logistics Plans, orders, control graphics Entity (unit, platform, and life form) type definitions Platform / weapon / sensor composition Application-specific details Characteristics and Performance Symbols, icons, 3D models System environment P(hit), P(kill), P(detect), P(classify) Agent/Behavior models System data format

24. Making OOB Searchable Annotated with UCore content to support IC/DoD CDR OpenSearch Discovery Metadata Based on eitherDDMS or MSC-DMS “Metacard” for Data Asset or RDG OOB discovery metadata extensions • Units • Name • UIC & FMID • UTC • Symbol code • Echelon • Capabilities • Force relationships OOB Data Asset • Equipment Types • NSN • LIN • FMID

25. Order of Battle Formats

26. Global Force ManagementProblem Statement We need Global Force Management Data • Current Unit Locations • “Event” data • Operational Availability • Total US Inventory • Historical archive • Timely, reliable, and authoritative What forces do I have? Where are the forces today? What residual capability exists? How do I manage forces, manpower, & equipment from acquisition to end of service? What happens if…? GFM DI is the Department-wide enterprise solution that: • Enables visibility/accessibility/sharing of entire DoD force structure • Allows integration of data across domains and systems

27. GFM DI Task 1: Organization Servers DOD USA USAF USN USMC States 6 Org Servers on NIPR mirrored and augmentedin 7 Org Servers on SIPR (Defense Intel only on SIPR) Feeder Systems Raw Data Org Server AIR FORCE AIR FORCE Force Structure ARMY ARMY MARINE COPRS MARINE CORPS NAVY NAVY OSD Intel Community JOINT STAFF OSD JOINT STAFF Standardized, Authoritative Data ANG ARNG Feeder systems document authorizations in without enterprise-wide standards Data from Org Servers exposed to the enterprise via NCES messaging

28. GFM DI: Document “Authorized” Force Structure as the Basis for “On-Hand” and “Execution” GFM DI Task 1 GFM DI Next Steps Task 2 -- Service/User Systems What do you actually have? What do you have to operate with and where is it? What are you authorized? 16 4 3 16 14 4 12 2 14 3 16 4 Authorization data Authorized by Law and organized by the Components “On-Hand” data Property Books & Personnel Systems Execution data Readiness, Logistics & Personnel Systems ITAPDB, MCTFS, MilPDS, etc. DRRS, JOPES etc. Org Servers

29. GFM DI Next Steps: Using OUIDs as Reference for Real Equipment, People, other IDs and Reorganizations A M1 M1 TK 1 TK 4 Military Force Tracking Organizations & Authorizations OE OUID URN, UIC, ... Equipment UII OUID OE C-2 OUID OE Tank Cdr Fort Hood M1A2 Person EDIPI Gunner Real Property RPUID E-6SSG19K3OASI: K4 SSG Smith Loader OE: Organization Element OUID: Organization Unique Identifier UII: Unique Item Identifier RPUID: Real Property Unique Identifier EDIPI: Electronic Data InterchangePersonal Identifier URN: Unit Reference Number UIC: Unit Identification Code Driver

30. Example Format Utilization DOD USA USAF USN USMC States GFM Org Servers Other consumers and data integrators Other sources AIR FORCE AIR FORCE Force Structure ARMY ARMY GFM DI XML MARINE COPRS MARINE CORPS NAVY NAVY OSD Intel Community Other formats or unstructured JOINT STAFF OSD JOINT STAFF JTDS OBS Army CADIE Army PD TNI DPDE ANG ARNG SIMCI / PD TNI XML OBS XML Army LDIF, etc. Simulation systems ABCS JCATS JDLM SIMPLE WARSIM / WIM OneSAF IGS MSDL

31. has-parts has-BOIP . . . Entity Type Definition andParametric Data

32. What are Entity Type Compositions (ETCs)? M&S ETC Name : SCOUT HMMWV Armored 50 CAL DIS Enum: 1-1-225-6-1-21-0 M2 .50 CAL MG LRAS3 • Some ETC enumeration schemes: • SISO DIS enumerations • National Stock Numbers (NSNs) • Line Item Numbers (LINs) • US Army Standard Nomenclature • JLCCTC MRF enumerations • OneSAF enumerations FBCB2/BFT M1114 HMMWV Up-Armored Armament Carrier • The “real world” / battle space (C2/Log) objects that must be accurately and consistently modeled across different simulations of a federation. • Entity types are “compositions” of a base platform or person with associated • weapon systems, • sensors, and • other (simulation-relevant) equipment. • Examples of ETC names: • M1A2 Tank • M1A2 with mine plow • M998 Cargo HMMWV • M1114 Armored HMMWV with Mk-19 • Scout HMMWV with 50 CAL MG and LRAS3 • Airborne Soldier with M4 rifle • Infantry Soldier with SAW • Could include organization and facility types too.

33. ETCs in Practice • If ETC definitions are not aligned across the C2 and M&S enterprise, • OOB data is not interoperable or reusable • C&P and PH/PK parameter data cannot be published or consumed • …without human-analyst intervention. Every • LVC M&S federation, • individual simulation, • local M&S federation site can have different definitions and names for the same “real world” ETC. ETCs are managed in multiple places C2 / logistics simulation users ETCs relate to other data SISO EWG TRADOC reference data instance data JTDS OBS Platform properties Service-level Force Management Weapon stations Force Management Object Models ETC 3D model Repositories Behavior Models ETC Logistics / Readiness PD TNI Characteristics and Performance Data Foreign / intel databases Logistics Databases OTC JLVC Scenario / Order of Battle Federation Object Models 3D Models Weapon / sensor effects evaluators JLCCTC ARCIC AMSAA Every Simulation Site GFM ORG Servers

34. ETCs as OWL Classes • Realization: ETCs are Classes. • Not just simple enumerations • ETCs are “sets of like things”, corresponding to classes in the Web Ontology Language (OWL) • OWL has class semantics “built in” • Subclass, restricted class, identifying properties and relationships • Use existing rules and tools • To avoid OWL is to redefine the same semantics and software that is available today. • Easier alignment of “enumerations” to other data standards: • MSDL • C-BML • JC3IEDM • C2 Core • RPR FOM • TENA LROMs • We can now use existing OWL tools for basic editing of ETC knowledge-bases. Equipment Vehicle Aircraft M2A3 Bradley IFV HMMWV M1114 w/ .50 CAL F/A-18 AC-130E

35. JC3IEDM and OWL Organizing ETCs using JC3IEDM-based object-type taxonomy. But JC3IEDM has three problems that had to be resolved first: • Dual taxonomies for Object-Item and Object-Type. • In OWL, they can be combined. • Flattening of class hierarchy using “category codes” to reduce table count. • Not a problem in OWL, so we fleshed out the full class hierarchies. • Only supports single-inheritance • Many of JC3IEDM’s conflicts can now be cleaned up by reconnecting the multiple inheritances. • e.g., Fox M93A1 – is it a Vehicle or a CBRN equipment?

36. RDG Plan for OOB Models & Formats

37. RDG Concept for OOB Formats • Support what exists today: Enable exchange of any existing or future data format.(in accordance with IC/DoD Content Discovery and Retrieval (CDR) Retrieve specifications) • Define a common, extensible OOB logical data model (LDM) and format to be a managed union of existing data requirements. • Start with GFM DI XML as a “common core” and extend; align with UCore and C2 Core efforts • Require data providers to support the common OOB format (in addition to any legacy format, optionally) • Leverage Entity Type management efforts • Align M&S to C2 and logistics representations and data sharing solutions. Work to converge solutions, where appropriate.

38. Principles of OOB LDM • Goal is to support GFM DI XML, OBS XML, MSDL, Army LDIF, etc. content completely. • Enable dynamic extensibility to support future data exchange requirements without imposing schema changes to established CDPE producers or consumers. • Recognize that there are more than one valid way of viewing and modeling the world: structures, resolution, dimensions. • Define foundation for aligning semantics for disparate formats, schemas, and data requirements. • Enable more automated data translation, and quantify lossiness. • Stop inventing ambiguous, unnecessary M&S corollaries to real-world concepts. • Align to operational semantics: architectures, data models, doctrine, vocabularies, taxonomies, etc. • Coordinate activities with GFM DI, UCore, etc. OWL XML XML XML XML XML XML

39. Creation of OOB LDM for RDG 1. Reverse engineer grammars / XML formats into OWL. 2. Construct modular composed ontologies GFM DI GFM DI XML OWL OWL OWL OWL XSD XSD XSD XSD … MSDL PD TNI … SIMCI / PD TNI XML Other models OBS XML OBS • UCore / C2 Core • DIS Enums • Logistics sources • C-BML • NFDD / EDCS MSDL Drafts complete In progress Other formats OWL XSD …

40. OOB LDM Elements Started with GFMIEDM v3.5 … OBJECT-ITEM-TYPE OT-ESTABLISHMENT OBJECT-ITEM-ASSC … … … … ALIAS-TYPE ESTAB-ALIAS DETAIL OI-ALIAS OBJECT-ITEM OBJECT-TYPE OBJECT-ITEM-ADDRESS FACILITY FACILITY-TYPE ADDRESS MATERIEL MATERIEL-TYPE ORGANISATION ELECTRONIC-ADDRESS ORGANISATION-TYPE PERSON PHYSICAL-ADDRESS … PERSON-TYPE

41. OOB LDM Elements Extended to also support OBS v3 … OBJECT-ITEM-LOCATION SCENARIO OWNING-FEDERATE OBJECT-ITEM-TYPE LOCATION OT-ESTABLISHMENT OBJECT-ITEM-ASSC … … … … ALIAS-TYPE LINE ESTAB-ALIAS DETAIL POINT OI-ALIAS … OBJECT-ITEM OBJECT-TYPE OBJECT-ITEM-ADDRESS NETWORK-MEMBER FACILITY FACILITY-TYPE PLATFORM ADDRESS MATERIEL MATERIEL-TYPE ORGANISATION ABCS-COMPONENT ELECTRONIC-ADDRESS ORGANISATION-TYPE SIDE PERSON … PHYSICAL-ADDRESS PERSON-TYPE DIS-CODE FACTION

42. Other models to fold in… OGRE/JACOB MIDB TRAC - Paul Works, Lee Lacy and Dean Hartley are developing an ontology for irregular warfare Army PD Tactical Network Initialization Coalition Battle Management Language

43. 19 April 2012 Questions?