Applications of Ontology OWL to: Geospatial Feature Data Dictionaries

UNCLASSIFIEDUNCLASSIFIED

1

Kevin [email protected]

Modeling & Simulation Information Management BranchSignal and Information Sciences LaboratoryApplied Research LaboratoriesThe University of Texas at Austin

Applications of Ontology OWL to:• Geospatial Feature Data Dictionaries• Rapid Data Generation: Order of Battle and

Entity Type Data Management

UNCLASSIFIED

APPLIED RESEARCH LABORATORIES

THE UNIVERSITY OF TEXAS AT AUSTIN2

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

Kevin [email protected] 512-835-3679

Eric [email protected]

Roy [email protected] 512-835-3857

Bruce [email protected] 512-835-3120


UNCLASSIFIED



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.

UNCLASSIFIED



We focused on mapping of EDCS and NFDD ...

• EDCS – SEDRIS Environmental Data Coding Specification

• NFDD – National System for Geospatial-Intelligence (NSG) Feature Data Dictionary

• 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

UNCLASSIFIED



...But recognized that there are others.

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

Unlike NFDD and EDCS, these are actual thesauri with broader / narrower relations, preferred and alternate names, definitions, etc.

UNCLASSIFIED



AGC Mapping Relations AGC Relation

(only 7 of 18 shown here) AGC Example Set Theory Relations

Concepts are completely disjoint (EDCS:Terrain Plain, NFDD:Slope Region)(EDCS:Complex Outline, NFDD:Facility)

Concepts overlap completely (EDCS:Parcel, NFDD:Parcel)(EDCS:Marine Port, NFDD:Port)

Concepts overlap well (EDCS:Glacier, NFDD:Glacier)(EDCS:Opera House, NFDD:Building)

A \ B and B \ A are “small”

Concepts overlap somewhat (EDCS:Sports Arena, NFDD:Sports Stadium)

Concept A is a generalization of Concept B

(EDCS:Harbour, NFDD:Harbour)(EDCS:Route, NFDD:Ice Route)

Concept A is a slight generalization of Concept B

(EDCS:Traffic Light, NFDD:Traffic Light)(EDCS:Astronomical Station, NFDD:Astronomical

Observatory) A \ B is “small”

Concept A is an aggregate of Concept B

(EDCS:Airfield, NFDD:Runway)(NFDD:Tent, EDCS:Camp)

A “has part” BB “is part of” A

BA

BA

ABBABA

\\

ABBABA

\\

BA

BA

Set Theory shows duplicate relationships with ambiguous differences.

UNCLASSIFIED



AGC Relation(another 3 of 18 shown here) Class Diagram Visualization

Concept A is a generalization of Concept B

Concept A is a slight generalization of Concept B


AGC Mapping Relationships

AGC Relation(only 4 of 18 shown here) Class Diagram Visualization

Concepts are completely disjoint

Concepts overlap completely

Concepts overlap well

Concepts overlap somewhat

BA

A B

BA

A B

BAA \ B

“small”B \ A

“small”

A B

BAA \ B B \ A

A

B

A

BA \ B“small”

has partA B

Set Theory shows duplicate relationships with ambiguous differences.

OWL is built upon set theory, where OWL classes are sets.

UNCLASSIFIED



Unqualified Qualified

Clearly all A are in B, but we don’t know if b in B is in A.

We can map A to B but not B to A.

All A are in B, and we know what subset of B equals A.

We can map A and B bidirectionally (lossy).

Combined qualification examples:

B

BQ1=AB \ A

B

A=B?B \ A

B

BQ1=A1 BQ2=A2 BQ3=A3

A B

22 QQ BBAA AQ1=A \ B BQ1=B \ A

“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 Q1 on concept B forms

a subconcept BQ1.

Both AGC and SEDRIS team schemes capture qualified relationships.

UNCLASSIFIED



Example of “Qualified” Relationship

EDCS: WellQ1: well type = ‘Fountain’ NFDD: Fountain

equivalent

AGC Relation: “EDCS (Well) and NFDD (Fountain) concepts overlap completely (qualified)”

EDCS

NFDDEDCS: Well

UNCLASSIFIED



AGC Relation: “NFDD (Railway) is an aggregate of EDCS (Railway track)”

EDCS

NFDD

GEMET

AGROVOC

WordNet

Integration and Linking of Dictionaries• Potential outcome: Integration of data dictionary concepts

– More than just mapping• Semantic alignment across multiple data dictionaries• Example: NFDD “railway” and EDCS “railway track”

Railway trackRailway

Underground railway

High-speed railway Railroad

Aggregate of

Equivalent

Railway network

Infrastructure Track

Railway

UNCLASSIFIED



Using Mappings in Data Translation

Relation Class Diagram Visualization Mapping A to B? Mapping B to A?Concepts A and B overlap somewhatUnqualified

NO

Some elements map, but we don’t know which ones!

NO


Concepts A and B overlap somewhatQualified

YES, WHEN APPROPRIATE

The qualification tells us which elements map.



Concept A is a generalization of Concept BUnqualified

NO


YES, ALWAYS

Subset relationship implies membership in superset A.

Concept A is a generalization of Concept BQualified



YES, ALWAYS

Subset relationship implies membership in superset A.


A might imply existence of B B might imply existence of A

A B

BAA \ B B \ A

A

B

has partA B

A B

22 QQ BBAA AQ1=A \ B BQ1=B \ A

A

AQ1=BA \ B

UNCLASSIFIED



Roadblocks: The same old problemsGarbage In Garbage Out

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

Weak semantics in EDCS and NFDD perpetuate ambiguity.


14



Rapid Data Generation (RDG)

Rapid Data Generation

RDG

UNCLASSIFIED



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.

UNCLASSIFIED



RDG Summary• 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

UNCLASSIFIED



Rapid Data Generation

FY09/10HLT-IC2

Capability

HLT IC2 GFM JTDS

5 Year M&S Data Enterprise Investment Strategy

Enterprise ApproachSC Oversight

Metrics Immediate ProgressRequirements DrivenD P

D P

D P

Geospatial, Atmosphere, Space, Ocean

Logistics

Command & Control

Red & BlueOrder of Battle

L IFE CYCLE

MANAGEMENT

SC Governance, Community Participation, Cross-Doman Interoperability

OOB Mid Term

ExamOOB Final

Exam= SC Decision Points

D P

D P D P

D P = Development Planning

FY 11 FY 12 FY 13 FY 14 FY 15FY 10

Other Capability On/Off-ramps

Common Data Production Environment

Year of Funding

UNCLASSIFIED



RDG M&S CDPE OOB Data Services Conceptual Overview(Draft Pre-decisional)

“Non-US” Force OOB Data Provider

RDGM&S CDPE CDPE

Discovery Metadata

Catalog

M&S Catalog

OperationalOOB DataProviders

(i.e. GFM DI, JPES/APEX, etc.)

Joint Training Data Services

(JTDS) OBS

USAF Scenario Generation Server (SGS)

US Special Operations Command

(USSOCOM)

CDPE Portal

Authentication/ Authorization ServiceOOB Discovery Service

OOB Subscription ServiceOOB Edit/Build Service

OSD/CAPE Joint Data Support

(JDS)

Discovery Metadata Update ServiceData Retrieval Service

Integrated Gaming System

(IGS)

USN Common Distributed

Mission Training Station (CDMTS)

Other M&S OOB Data Provider, Integrator, or

Consumer Systems

UNCLASSIFIED



DATA ISSUESRapid Data Generation

UNCLASSIFIED



Discovery, Retrieval, and Understanding

Discovery• 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

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.

UNCLASSIFIED



Metadata TypesDoD 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 MetadataInformation 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 MetadataInformation about a data asset that describes or identifies characteristics about that asset that convey meaning or context (e.g., descriptions, vocabularies, taxonomies).

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.

UNCLASSIFIED



Relationship of Discovery Metadata to OOB Data

OOB Data Asset

Format / XML Schema

“Metacard” for Data Asset

• 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

• Stored in a data repository• Tagged with a metacard• Conforms to some structure

metadata (format or structure).

• Stored in the DoD Metadata Registry (MDR)

• Tagged with a metacard• Conforms to some structure metadata

(format or structure).

Discovery Metadata

Structural Metadata

UNCLASSIFIED



What is meant by “Order of Battle?”UNITS / ORGANIZATIONS‘SIDES’ Nations

CoalitionCivilianOPFOR

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

OrganicAssignedAttachedOPCONTACONDirect supportReinforcingGeneral support-reinforcingGeneral Support

FriendlyHostileNeutral

PLATFORMS & LIFE FORMSLocationsC2 Network

Logistics Plans, orders, control graphics

Entity (unit, platform, and life form) type definitions

Platform / weapon / sensor composition

Application-specific detailsSymbols, icons,

3D models

Agent/Behavior models

Characteristics and Performance

P(hit), P(kill), P(detect), P(classify)

System environment

System data format

UNCLASSIFIED



Making OOB Searchable

OOB Data Asset

“Metacard” for Data Asset

Discovery Metadata

Based on eitherDDMS

orMSC-DMS

Annotated with UCore content to support

IC/DoD CDR OpenSearch

orRDG OOB discovery

metadata extensionsUnits• Name• UIC & FMID• UTC• Symbol code• Echelon• Capabilities• Force relationships

Equipment Types• NSN• LIN• FMID

UNCLASSIFIED



Order of Battle FormatsFormatGFM DI XML Joint Staff J8 GFM DIUCore DoD CIO / DISA, ODNI, DOJ, DHSC2 Core C2 DSSC / Joint Staff and DoD CIOMSDL Simulation Interoperability Standards

Organization (SISO)OBS XML Joint Staff J7 JCWArmy LDIF address books PEO C3TSIMCI/PD TNI XML PD TNI and Joint Staff J7 JCW

UNCLASSIFIED



Global Force Management Problem Statement

We need Global Force Management DataCurrent Unit Locations“Event” data Operational AvailabilityTotal US InventoryHistorical archiveTimely, 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:1. Enables visibility/accessibility/sharing of entire DoD force structure2. Allows integration of data across domains and systems

UNCLASSIFIED



Data from Org Servers exposed to the enterprise via NCES messaging

Standardized,

Authoritative

DataFeeder systems document authorizations in without enterprise-wide standards

6 Org Servers on NIPRmirrored and augmentedin 7 Org Servers on SIPR(Defense Intel only on SIPR)

GFM DI Task 1: Organization Servers

Feeder Systems

ARM

YAI

R FO

RCE

OrgServerAI

R FO

RCE

OSDN

AVY

MAR

INE

COPR

S

JOIN

T ST

AFF

Inte

l Com

mun

ityO

SD

Force Structure

DOD

USAFUSA USMCUSN

States

JOIN

T ST

AFF

ANG ARNGN

AVY

MAR

INE

CORP

SAR

MY

Raw Data

http://openclipart.org/clipart/tools/weapons/m16_02.svg

UNCLASSIFIED



GFM DI: Document “Authorized” Force Structure as the Basis for “On-Hand” and “Execution”

What are you authorized?

Authorization dataAuthorized by Law and

organized by the Components

What do you actually have?

“On-Hand” dataProperty Books & Personnel Systems

What do you have to operate with and where is

it?

Execution dataReadiness, Logistics &

Personnel Systems

Org Servers ITAPDB, MCTFS, MilPDS, etc.

DRRS, JOPES etc.

GFM DI Task 1 GFM DI Next Steps Task 2 -- Service/User Systems

UNCLASSIFIED


THE UNIVERSITY OF TEXAS AT AUSTIN29Person

SSG Smith

Organizations & Authorizations

Gunner

Loader

Driver

M1 TK 1

A

E-6SSG19K3OASI: K4

M1A2

TK 4 M1

Tank Cdr

GFM DI Next Steps: Using OUIDs as Reference for Real Equipment, People, other IDs and Reorganizations

OUID

EDIPI

Military Force Tracking

URN, UIC, ...OUID

OUID

Real PropertyRPUID

OE: Organization ElementOUID: Organization Unique Identifier UII: Unique Item IdentifierRPUID: Real Property Unique IdentifierEDIPI: Electronic Data Interchange

Personal Identifier URN: Unit Reference NumberUIC: Unit Identification Code

OE

OE

OE Equipment

C-2

UII

Fort Hood

UNCLASSIFIED



Example Format Utilization

JTDS OBS

Simulation systems

JDLM WARSIM / WIMSIMPLE OneSAF IGSJCATS

AR

MY

OSDNAV

YM

AR

INE

CO

PRS

JOIN

T ST

AFFAIR

FO

RC

E

Inte

l Com

mun

ityO

SD

AIR

FO

RC

E

Force Structure

DOD

USAFUSA USMCUSN

States

JOIN

T ST

AFF

ANG ARNG

NAV

YM

AR

INE

CO

RPS

AR

MY

GFM Org Servers

Other consumers and data integrators

OBS XML

Other sources

Other formats or unstructured

Army PD TNI DPDE

GFM DI XML

SIMCI / PD TNI XML

ABCS

Army LDIF, etc.

Army CADIE

MSDL

UNCLASSIFIED



ENTITY TYPE DEFINITION ANDPARAMETRIC DATA

has-parts

has-BOIP

. . .

UNCLASSIFIED



What are Entity Type Compositions (ETCs)?

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

M1114 HMMWV Up-Armored Armament Carrier

FBCB2/BFT

LRAS3M2 .50 CAL MG

M&S ETC Name : SCOUT HMMWV Armored 50 CALDIS Enum: 1-1-225-6-1-21-0

• Some ETC enumeration schemes:– SISO DIS enumerations– National Stock Numbers (NSNs)– Line Item Numbers (LINs)– US Army Standard Nomenclature– JLCCTC MRF enumerations– OneSAF enumerations

UNCLASSIFIED



Every• LVC M&S federation, • individual simulation, • local M&S federation site

can have different definitions and namesfor the same “real world” ETC.

ETCs in Practice

ETCs relate to other data

ETC

PD TNIEvery Simulation Site

Service-level Force Management

Weapon / sensor effects evaluators

SISO EWG

Object Models

3D model Repositories

ETCs are managed in multiple places

ETC

Force Management

Platform properties Weapon

stations

Behavior Models

Characteristics and Performance Data

Federation Object Models3D Models

Scenario / Order of Battle

Logistics / Readiness

instance data reference data Logistics Databases

AMSAA

JTDS OBS

GFM ORG Servers

Foreign / intel databases OTC JLVC

JLCCTCARCIC

TRADOC

C2 / logistics simulation users

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.

UNCLASSIFIED



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

ETCs as OWL Classes

HMMWV M1114 w/ .50 CAL

Vehicle

Equipment

Aircraft

F/A-18M2A3

Bradley IFV

AC-130E

UNCLASSIFIED



JC3IEDM and OWLOrganizing ETCs using JC3IEDM-based object-type taxonomy.

But JC3IEDM has three problems that had to be resolved first:1. Dual taxonomies for Object-Item and

Object-Type.– In OWL, they can be combined.

2. Flattening of class hierarchy using “category codes” to reduce table count.

– Not a problem in OWL, so we fleshed out the full class hierarchies.

3. 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?

UNCLASSIFIED



RDG PLAN FOR OOB MODELS & FORMATS

UNCLASSIFIED



RDG Concept for OOB Formats1. 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)

2. Define a common, extensible OOB logical data model (LDM) and format to be a managed union of existing data requirements.

a. Start with GFM DI XML as a “common core” and extend; align with UCore and C2 Core efforts

b. Require data providers to support the common OOB format (in addition to any legacy format, optionally)

3. Leverage Entity Type management efforts 4. Align M&S to C2 and logistics representations and data sharing solutions.

Work to converge solutions, where appropriate.

UNCLASSIFIED



XML

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.

XML

OWL

XML

XMLXMLXML

UNCLASSIFIED



Creation of OOB LDM for RDG1. Reverse engineer grammars / XML formats into OWL.

2. Construct modular composed ontologies

XSDOWL

XSDOWL

XSDOWL

GFM DI XML

SIMCI / PD TNI XML

OBS XML

XSDOWLOther formats

GFM DI

PD TNIMSDL

OBS

Other models

• UCore / C2 Core• DIS Enums• Logistics sources• C-BML• NFDD / EDCS

……

Drafts complete

In progress…XSD

OWLMSDL

UNCLASSIFIED



OOB LDM Elements

OBJECT-TYPE

FACILITY-TYPE

MATERIEL-TYPE

ORGANISATION-TYPE

PERSON-TYPE

OBJECT-ITEM

FACILITY

MATERIEL

ORGANISATION

PERSON

ADDRESS

ELECTRONIC-ADDRESS

PHYSICAL-ADDRESS

…

……

…

OBJECT-ITEM-ADDRESS

OI-ALIAS

ALIAS-TYPEOBJECT-ITEM-ASSC

OBJECT-ITEM-TYPE

OT-ESTABLISHMENT

DETAIL ESTAB-ALIAS

…

Started with GFMIEDM v3.5 …

UNCLASSIFIED



OOB LDM Elements

OBJECT-TYPE

FACILITY-TYPE

MATERIEL-TYPE

ORGANISATION-TYPE

PERSON-TYPE

OBJECT-ITEM

FACILITY

MATERIEL

ORGANISATION

PERSON

ADDRESS

ELECTRONIC-ADDRESS

PHYSICAL-ADDRESS

…

……

…

OBJECT-ITEM-ADDRESS

OI-ALIAS

ALIAS-TYPE

OBJECT-ITEM-ASSC

OBJECT-ITEM-TYPE

OT-ESTABLISHMENT

DETAILESTAB-ALIAS

…

Extended to also support OBS v3 …

LOCATION

LINE

OBJECT-ITEM-LOCATION

POINT…

SIDE

SCENARIO

PLATFORM

NETWORK-MEMBER

ABCS-COMPONENT

FACTIONDIS-CODE

OWNING-FEDERATE

UNCLASSIFIED



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

UNCLASSIFIED



QUESTIONS?

19 APRIL 2012



Applications of Ontology OWL to: Geospatial Feature Data Dictionaries

Documents

Transcript of Applications of Ontology OWL to: Geospatial Feature Data Dictionaries