ENVIRONMENTAL DATA MODELS:

1
ENVIRONMENTAL DATA MODELS

• Necessary but Not Sufficient for Interoperability

Virginia T. Dobey, SAIC/DMSO
Virginia.Dobey.CTR_at_dmso.mil (703)
824-3411 Peter L. Eirich, JHU/APL
Peter.Eirich_at_jhuapl.edu [phone]
04S-SIW-114, April 2004
2
OUTLINE

• The Interoperability Challenge Data Interchange
• Legacy Approaches to Environmental Data
  Interchange
• Capabilities and Effectiveness of Legacy
  Approaches
• Near-Term Opportunities for Improving Legacy
  Approaches
• Findings and Conclusions

3
INTEROPERABILITY

• WHY INTEROPERABILITY?
• The application of military force in the early
  21st century is demandingthe nature and
  composition of a force structure to meet military
  requirements will bebased upon a general and
  flexible military capability. To achieve this,
  an assured capability for interoperability of
  information is essential.
• --Multilateral Interoperability Programme
• Tactical C2IS Interoperability Requirement,
• October, 2003
• WHAT INTEROPERABILITY?
• Identification interoperability, herein defined
  as the capability of two different computing
  applications, in the course of a data
  interchange,
• (1) to determine whether or not a particular
  object is the same, and
• (2) to agree on what kind of object it is

4
LEGACY APPROACHES to INTEROPERABILITY
From N2 translators
? to N translators
5
FROM N2 TO N

• Developing the common interchange hub requires
  an application-independent set of standards
• An important member of this set of standards is
  an application-independent representation of data
  exchanged between systems or between producer and
  system (an application of the three schema
  architecture)

6
DEVELOPING INTEROPERABLE DATA

• A data model is an abstract, self-contained,
  logical definition of the objects, operators, and
  so forth, that together constitute the abstract
  machine with which users interact. The objects
  allow us to model the structure of dataAn
  implementation of a given data model is a
  physical realization on a real machine of the
  components of the abstract machine that together
  constitute that modelthe familiar distinction
  between logical and physical emphasis in the
  original
  C.J. Date1
• Logical Data Model A model of data that
  represents the inherent structure of that data
  and is independent of the individual applications
  of the data and also of the software or hardware
  mechanisms which are employed in representing and
  using the data. DoD 8320.1-M2
• Normalization leads to an exact definition of
  entities and data attributes, with a clear
  identification of homonyms (the same name used to
  represent different data) and synonyms (different
  names used to represent the same data). It
  promotes a clearer understanding and knowledge of
  what each data entity and data attribute means.
  C.Finkelstein3

1Colleague of E.F. Codd, originator and developer
of relational database theory 2 DoD authority on
information engineering 3 Originator and main
architect of the Information Engineering
methodology
7
GOAL INTEROPERABLE ENVIRONMENTAL DATA
Within the SEDRIS technologies, the
Environmental Data Coding Specification (EDCS)
provides the foundation for interoperable data.
EDCS is a common set of concepts used to describe
the semantics of environmental objects and their
characteristics, independent of any specific
representation

• An EDM Environmental Data Model characterizes
  the environmental features, attributes, values
  and relationships represented by a particular
  system using the Environmental Data Coding
  Specification (EDCS) as the data dictionary.
  Miller, Janett, Nakanishi 03S-SIW-132
• EDMs were developed to better define the basis
  for terrain data production requirements, terrain
  integration constraints and expectations, SEDRIS
  transmittal contents, and runtime terrain data
  use. Birkel, Miller,
  Root 8th-CGF-004

8
WHAT IS AN EDM?

• In data modeling terminology, the EDM is a
  logical data model
  Miller, et. al., 02F-SIW-082
• A logical data model based on ORM object role
  model and traditional data modeling concepts
  Miller briefing,18Dec02
• EDM operations are facilitated by the Common
  Data Model Frameworkfor the comparison of
  EDMs. op. cit.,
  03S-SIW-132

9
EDMs ASSESSING DATA INTEROPERABILITY

• Principal tool in analysis of terrain data
  interoperability, 03S-SIW-132
• (Reference EDM, Data Requirements EDM)
• Ten EDMs used
• Results showed no common features, only 17 of
  1899 common to any six EDMs
• Addition of manually-developed hierarchical
  ontology and equivalence classes increased
  results to 28 features common to all, 37 common
  to nine
• Conclusion Even with these changes, the
  resulting REDM is far too small to be useful

10
EDMs USED TO EVALUATE EDCS

• DMSO/SISO-sponsored study of EDCS started with
  JSAF and CCTT EDMs
• Difficulty because of various translations of
  user concepts into EDCS caused by
• Level of generalization (TERRAIN_TRANSPORT
  ATION_ROUTE vs. RAILWAY)
• Level of aggregation (TERRAIN_TRAFFICABI
  LITY_COARSE vs. TERRAIN_TRAFFICABILITY_MEDIUM)
• Duplication of descriptive attributes for the
  same concept (PREDOMINANT_WATER_DEPTH,
  RIVER_DEPTH_COARSE)
• Incorporation of additional concepts/composite
  concept (TERRAIN_SURFACE_HYDROGEOLOGIC_REGION
  compared to TERRAIN)

11
REQUIREMENTS FOR EDM USE IN ASSESSING
INTEROPERABILITY

• If an EDM is a valid instrument for assessing
  data interoperability, it must be
• A logical data model
• Developed using consistent translations of user
  concepts into EDCS
• Normalized to single-concept entities and
  attributes, without synonyms (different names,
  same meaning) or homonyms (same name, different
  meanings)

12
AN EDM EVALUATION

• Authors performed an in-depth analysis of the
  Ultra-High Resolution Building (UHRB) EDM
• Applied principles of logical Entity-Relationship
  data modeling
• Applied principles of normalization (to 3NF for
  you geeks)
• Based on August 2003 version of the UHRB

13
RESULTS
TOP-LEVEL ENTITIES

• CURRENT UHRB
• COMPARTMENT_LAYER
• COMPARTMENT_LAYER_ INHABITABLE
• COMPARTMENT_LAYER_ UNINHABITABLE
• VENTILATION_DUCT
• CONTROL_PANEL
• VERTICAL_PASSAGE
• BUILDING

• NORMALIZED UHRB
• STRUCTURE
• BUILDING
• CONSTRUCTION_ MATERIEL
• EMISSIVITY
• BUILDING_SYSTEM
• APERTURE
• BUILDING_PORTION
• ROOF
• STOREY
• INTER-STOREY

14
UHRB DETAILS

• CURRENT UHRB
• COMPARTMENT_LAYER_ UNINHABITABLE
• ROOF_ASSEMBLY
• BREACH_HOLE
• TRAPDOOR
• SKYLIGHT
• DOOR
• CEILING_CRAWL_SPACE
• FLOOR_CRAWL_SPACE
• EXTERIOR_WALL
• VERTICAL_PARTITION
• VENTILATION_APERTURE
• COMPARTMENT_LAYER_INHABITABLE
• COMPARTMENT_ROOM
• COMPARTMENT_ROOM_EXTERIOR
• COMPARTMENT_ROOM_INTERIOR
• FLOOR_LEVEL
• COMPARTMENT_CONTENT
• BUILDING_COMPONENT_ENTRANCE_OR_EXIT

• NORMALIZED UHRB
• STOREY
• ATTIC
• ABOVE_GROUND_STOREY
• MEZZANINE
• GROUND_FLOOR
• BASEMENT
• COMPARTMENT (with attribute HABITABILITY)
• ROOM
• WALL
• CUBICLE
• PARTITION
• PASSAGEWAY
• COMPARTMENT_VENTILATION
• COMPARTMENT_FORTIFICATION
• INTER-STOREY
• VERTICAL_SHAFT
• INTER_STOREY_CRAWL_SPACE
• LADDER

15
FINDINGS CONCLUSIONS

• EDMs provide important documentation where none
  had existed.
• EDMs are NOT normalized logical data models!!!
• (but should be for use in interoperability
  analyses)
• EDMs document application-specific data AS-IS
• EDMs leverage EDCS, but in very
  application-specific ways
• Limited results of CDMF REDM/DREDM reflect the
  limitations of input EDMs
• Interoperability results (CDMF REDM/DREDM) were
  improved by ADDING ontologies and equivalence
  classes
• Such results would be further improved by a
  fully-developed ontology (based on a logical data
  model built from application-independent EDCS
  concepts)

16
FINDINGS CONCLUSIONS (cont.)

• Without normalization, EDMs will continue to be
  too application-specific for use in assessing
  interoperability
• Techniques for properly creating EDMs to
  determine data interoperability exist and can be
  implemented NOW
• EDMs cannot be considered SUFFICIENT to assess
  interoperability until they are converted into
  properly normalized, application-independent
  relational data models.

17
IMPLICATIONS

• Interoperability assessments based on the current
  set of EDMs are invalid
• Current and future use of EDMs in any context
  other than documentation of application-specific
  requirements must be contingent upon reworking
  EDMs into true normalized, logical data models
• Conversion of EDMs into normalized, logical data
  models will reduce, if not eliminate, differences
  in the manner in which EDCS terms are
  used/incorporated (translational differences)

18
BACK-UP SLIDES
19
SOME UHRB DETAILS (Draft 3NF Logical Data
Model Based on UHRB EDM Contents)
20
STRUCTURE View, Draft 3NF Logical Data Model of
UHRB EDM contents
21
STOREY View, Draft 3NF Logical Data Model of
UHRB EDM contents
22
(No Transcript)
23
INTER-STOREY1
PK
Building_portion_ID
PK
Building_ID (Structure_ID)
INTER-STOREY View, Draft 3NF Logical Data
Model of UHRB EDM contents
PK
Inter_storey_portion_id
Inter_storey_type
Inter_storey_exposure
Inter_storey_type
VERTICAL_SHAFT
LADDER
PK,FK1
Building_ID (Structure_ID)
PK,FK1
Building_ID (Structure_ID)
PK,FK1
Building_portion_ID
PK,FK1
Building_portion_ID
PK,FK1
Inter_storey_portion_id
PK,FK1
Inter_storey_portion_id
elevator
Ladder_rail_present
laundry
trash
STAIRWAY
INTER_STORY_CRAWL_SPACE1
PK,FK1
Building_ID (Structure_ID)
PK,FK1
Building_ID (Structure_ID)
PK,FK1
Building_portion_ID
PK,FK1
Building_portion_ID
PK,FK1
Inter_storey_portion_id
PK,FK1
Inter_storey_portion_id
Stair_railing_present
Crawl_space_location
24
BUILDING SYSTEM View, Draft 3NF Logical Data
Model of UHRB EDM contents
25
APERTURE View, Draft 3NF Logical Data Model of
UHRB EDM contents
26
COMPARTMENT CONTENTS View, Draft 3NF
Logical Data Model of UHRB EDM contents
27
UHRB EXTRACTS
04S-SIW-114, April 2004
27
28
OneSAF Objective System EDM for Ultra High
Resolution Buildings Version 1.2
04S-SIW-114, April 2004
28
29
04S-SIW-114, April 2004
29
30
04S-SIW-114, April 2004
30
31
04S-SIW-114, April 2004
31
32
04S-SIW-114, April 2004
32
33

• OneSAF EDM
• extracts

34
04S-SIW-114, April 2004
34