Environmental Data Modeling: REDM, DREDM, Ontology and Metrics

1
Environmental Data ModelingREDM, DREDM,
Ontology and Metrics

• Dale D. Miller, Ph.D.
• Annette Janett
• Melissa Nakanishi
• Lockheed Martin Information Systems
• Advanced Simulation Center
• Bellevue, WA

2
The System-of-SystemsInteroperability Problem

• Providers of Data
• Whether observed/measured, interpolated, or
  generated/modeled
• Willie Sutton Rule
• NIMA, AFCCC, FNMOC INE ARP
• Question What do you want and how should it be
  represented?
• Developers of Systems/Software
• Interact with (use) Data
• C4ISR, MS, Games,
• CECOM, STRICOM, ESC, PMS430
• Question I need this, it will be represented
  like that, and you have what!?
• Specifiers of Functionality
• Define behavior/capability required (supported by
  Data)
• TRADOC, NSC, Schools, Consumers,
• Question When will I get what I want, and how
  good will it be?

3
The Bottom Line

• Goal Establish common EDMs across communities
  of interest
• Increased interoperability (pre-ex and runtime)
• Increased data reuse and decreased data
  manipulation
• Increased data availability (pooling of
  production resources)
• Method
• Capture existing EDMs of providers,
  consumers,and system-level requirements
• Develop common EDMs as rational supersets across
  appropriate sets of providers/consumers/systems
• Will require negotiation and adjustments of
  individual EDMs
• Establish result(s) as reference EDMs
• Characterize specific provider/consumer/system
  EDMs as profiles of those reference EDMs
• Objective is a single reference EDM across the
  broadest community base e.g., a Reference EDM
  for Terrain

4
Why Data Models

• Benefits of Environmental Data Models (EDMs)
• Interoperability EDMs allow you to compare and
  contrast similar or diverse simulations to
  evaluate interoperability. Use of EDMs early in
  the system development process can help in the
  development of an interoperable solution
• Requirements EDMs can be used to specify and
  document system data requirements. EDMs can be
  used to identify source data meeting the needs of
  the system.
• Analysis EDMs enable you to analyze the models
  used within a simulation, identify models that
  may be plugged in. EDMs provide to behavior
  developers, the data available to the developer.
• Benefits depend on
• Common data dictionary, EDCS
• Common data model framework, CDMF

5
C4I/MS Interoperability
An Interoperable MS and C4ISR Framework
D. Timian et al., Report Out of the C4I Study
Group 00F-SIW-005
6
Solution - Common Data Model Framework (CDMF)

• Extensions to classical E-R modeling
• Framework for data modeling
• Expressed in a language, contained in a
  relational database
• May be directly queried
• Diagrams may be derived from the language
• Logical Data Model
• Feature (Entity) Environmental objects having
  common attributes of interest
• Attribute A characteristic or property
  associated with an entity
• Relationship Specific or non-specific
  association between entities
• Attribute Values
• The set of allowed data values that an attribute
  may take on
• Enumerant, Textual, Numeric, Interval

7
Features, Attributes, Relationships

• Feature
• Classification
• Type (point, line, area, grid)
• Variant (for variations such as different
  coverages)
• Attribute
• Feature code as indicated above
• Attribute
• Relationships
• Facilitate reasoning
• Levels of resolution (aggregate)
• Connectivity (over, under, connected to)

8
Data Dictionary EDCS

• Classifications, attributes, enumerants, units of
  measure
• ISO/IEC Final Committee Draft (ISO/IEC 18025)
• EDCS extensions
• Labels vs Codes
• Qualified attributes

9
Environmental Data Models (EDMs)
10
Common Data Model Framework (CDMF)
Setup
Environmental Data Model (EDM)
Capabilities
Maintenance
Comparison
Conversion
Diagrams
Verification
Mapping
Using MS Access MS Visual Basic
11
Reference/Requirements EDMs

• EDMs have been or are being developed for many
  MS and C4ISR systems
• Reference EDM (REDM) will be the intersection
  of their contents
• Defines maximal environmental content for which
  all systems can interoperate
• Goal is to have the Reference EDM as large as
  possible
• Data Requirements EDM (DREDM) will be the union
  of EDM contents
• Defines a minimal set of environmental data for
  which requirements have been established

12
DREDM / REDM of Stakeholder EDMs (Terrain)
13
Comparing Feature IDs

• 1 feature is common across 8 EDMs
• 4 features are common across 7 EDMs
• 12 features are common across 6 EDMs
• 692 features appear in only 1 EDM
• 1893 features in total

14
Syntax vs. Semantics

• Well established that similar semantic can be
  expressed via multiple syntaxes (even in EDCS)
• E.g., LIGHTHOUSE feature vs. BUILDING feature
  with BUILDING FUNCTION LIGHTHOUSE
• Generalize Specialize relationships
• If one EDM has a TERRAIN_OBSTACLE and another has
  LOG_OBSTACLE, they share some semantic similarity
• Attributes are important too if, in the first
  EDM, TERRAIN_OBSTACLE has an attribute of
  TERRAIN_OBSTACLE_TYPE with an allowable value of
  LOG_CRIB, the semantic is closer yet

15
Fuzzy Comparisons

• Equivalence Classes
• An Ontology for the EDCS

16
Equivalence Classes

• Feature of high specificity (Generic feature
  with specific attribute)
• LIGHTHOUSE (BUILDING, BF LIGHTHOUSE)
• Currently identified over 650 equivalences

17
Some Equivalences Better Then Others

• Maintained a Confidence Level field
• Inexact matches

18
An Ontology for the EDCS

• Relationships
• Hierarchical A ltWIRE_OBSTACLEgt is a
  ltTERRAIN_OBSTACLEgt
• Component ltAPRONgt is a component of ltAERODROMEgt
• First cut relate features when the EDCS label
  of one appears in the definition of the other
• WIRE_OBSTACLE A ltTERRAIN_OBSTACLEgt constructed
  of ltWIREgt, usually containing barbs or razors a
  wire obstacle.

19
Ontology Refinement
20
Barriers
21
EDCS Extensions

• In the EDCS, a group of related concepts often
  does not have a parent which embodies this group
• New EDCS classifications proposed for completeness

22
TERRAIN OBSTACLE group
23
ABATIS group
24
VEHICLE BARRIER group
25
Results of Applying the Ontology and Equivalence
Classes to the 10 Source EDMs
26
New REDM Approach Common Core Data Model

• TLM / VMAP2 as starting point
• Represents what todays warfighters are demanding
• Surrogate for C4ISR
• Adding terrain overlays for dynamic environmental
  data elements from MIL-STD-2525B
• Intersect with WARSIM TCDM and OOS EDM-Terrain
• The two emerging Army MS systems
• Grow this intersection with the ontology analysis
  and equivalence classes

27
Feature and Attribute Counts
28
Fuzzy Intersection Methodology
29
Common Core Data Model (CCDM)TLM/VMAP2 2525B,
WARSIM, OOS
30
(No Transcript)
31
Measuring the Alignment between EDMs

• An extension to the work of Brian Haugh (IDA) et
  al. in measuring the alignment between the
  LC2IEDM and TCDM
• Which have different data dictionaries
• What percentage of concepts in data model A
  align with concepts in data model B? and vice
  versa
• alignment from A to B is A n B / A (A n
  B)
• alignment from B to A is A n B / B (A n
  B)

32
Haugh et al. Methodology

• Drill down may terminate prematurely if alignment
  is zero
• Alignments are rolled up from the bottom up
• Computed alignment between two data models is
  primarily driven by alignment of attribute values
• Assigned alignments while drilling down are
  discarded

• Drill down to make alignment assessments at four
  levels
• Assessments most subjective at the conceptual
  level, most rigorous at the enumeration level

Conceptual
Entire Data Model
Entities
Feature by Feature
State
Values
Attribute by Attribute
Value by Value
33
Alignment (cont.)

• Types of attributes
• mensuration attributes, which are generally
  continuous-valued measurements of a property of
  an entity HEIGHT, LENGH, WIDTH, SOIL MOISTURE,
  TEMPERATURE, etc.
• qualifying attributes, which add additional
  descriptive information about the entity, but do
  not change its fundamental thing-ness.
  Examples include COLOR, SURFACE ROUGHNESS, SOIL
  TYPE, GENERAL DAMAGE FRACTION, MATERIAL
  COMPOSITION, etc.
• metadata attributes, which include UNIQUE
  IDENTIFICATION NUMBER, SOURCE TYPE CATEGORY, etc.
  
• identifying attributes, which serve to further
  clarify the type of object the entity represents.
  These are generally enumerated, and include
  BUILDING FUNCTION, OBSTACLE TYPE CATEGORY,
  BUILDING COMPONENT TYPE, etc.

34
Alignment (cont.)

• Reduced entities in a data model
• (entity type, identifying attribute enumeration
  value)
• Capture the following metrics
• Assigned alignment of reduced entities (based on
  analysis of definitions)
• Assigned alignment of mensuration and qualifying
  attributes on a per-reduced-entity basis (based
  on analysis of definitions)
• Assigned alignment of metadata attributes on a
  per-reduced-entity basis
• Calculated alignment of non-metadata attribute
  values on a per-reduced-entity basis
• Calculated alignment of metadata attribute values
  for mensuration, qualifying and metadata
  attributes
• Averages in each class of metrics
• But maintain as six separate metrics

35
Conclusions

• Reasonable REDMs for a set of EDMs cannot be
  generated syntactically
• Equivalence classes and EDCS ontology allow
  semantic comparisons
• New metrics have been proposed for measuring the
  alignment between two EDMs, even using different
  data dictionaries
• Going forward
• Many judgment calls in defining ontological
  relationships
• Needs review by larger community