presented to: by: date: federal aviation administration ontology for enterprise architecture mitre...

Presented to:

By:

Date:

Federal AviationAdministrationOntology for

Enterprise Architecture

Mitre EA Conference

Con Kenney & Irene Polikoff

September 7, 2006

Roadmap for Enterprise Architecture2Federal Aviation

Administration28 February 2006

Enterprise Architecture processes

Strategic Planning

Enterprise Architecture

Business Case Development

Portfolio Management

Program Management

Performance Measurement

Operations

Budget Planning Cycle

Dire

ctio

n

Fee

dbac

k /

Res

ults

Change

Capital Planning

1) Strategic Planning - establishes vision, mission, goals, objectives, & enterprise performance measures

2) Enterprise Architecture – Develops modernization blueprints to meet strategic goals

3) Business Case Development – Creates the OMB 300s from selected blueprint initiatives

4) Capital Planning – Selects which initiative business cases will be funded

5) Investment/Portfolio Management – Compares investment options and guides decision making

6) Program Management – Implements the funding decisions to change the operational environment according to the modernization blueprint

7) Performance Measurement – Measure execution performance against targets



DOT EA Repository, Metis, AND Portfolio Management Software

Enterprise Architecture Layers

Federal Investment Management Model Has Multiple Layers



EA Domain Models



Two FAA Enterprise Architecture parts for NAS and Non-NAS

NAS Non NAS

ABA

ATO

ARP

Safety

En Route& Ocean

Terminal

FlightServ

SysOps

TechOps

FAA Enterprise Architecture

ARC

AVS

AIO

AGI

AOC

APIAGC

ASTAEP

AHR

ACR

ASHOpsPlan

Comm

Fin

Acq &Biz



FAA Situation

• Different types of applications– Air Traffic Control: Command & control

• Realtime• Safety-of-life critical• Multi-decade system lifespans• >$150M lifecycle

– Other FAA: Business information• Online and batch• 3 to 5 year lifespans• <$10M lifecycle

• Two separate architecture repositories using different frameworks– DODAF (NAS database)– FEAF (EA Portal database)



Proof of Concept for Ontology based integration• Using TopBraid Composer automatically converted database

schemas into OWL ontologies– Tables converted into classes– Columns converted into datatype properties– Foreign keys converted into object properties– These ‘proxy’ ontologies are used to federate queries to the underlying

databases• Used existing models (FEA-RMO, TQ EA ontologies, W3C

Geospatial ontology) as a basis for the DOTEA ontology model

• Examined EA Portal database schema and NAS database schema to identify any concepts missing in the base models– Extended the DOT EA ontology with new classes and properties

• When possible connected classes and properties of the proxy ontologies with the DOT EA model



A concept of ‘Facility’ (a.k.a. location) in the NAS database schema



A concept of ‘Location’ in the EA Portal database schema



Some questions we had to consider

• Are these the same concepts?• Are they different concepts?• If they are different what is the nature of

their differences?• If they are the same how can we have a

single point of access to the information stored in these databases?

• If they are different, but complimentary, how can we aggregate the associated information?



Important Advantages of Ontology Models• Documentation is part of the model

– rdfs:comment and other annotation properties

• Modular components– support for imports of ontologies and reference of concepts

from different ontologies– universal ids and namespaces– re-use of the standard vocabularies – FEA-RMO, Geospatial

ontologies, Dublin Core, …

• Support inferencing to produce information not explicitly represented– inverse, transitivity, …– if a facility is located in New Jersey and New Jersey is located

in the North East, facility is located in the North East



EA as Layered Set of Models

• Each model describes a bounded domain following rules that define– Syntax– Semantics

• Each model manages a set of facts• Each model makes a set of truth claims

based on its facts



‘Location’ in the DOT EA Ontology



The DOT EA Ontology is a collection of linked Models



How do you coordinate truth claims across models?

• Single, inclusive model– Conceptually simple– Complicated to implement– Hard to change

• Reconciliation across models– Well-understood control– Ongoing human effort– Less flexibility for individual models

• Semantic technology– More accessible but still specialized– Machine-based reasoning– Accommodates changes in models easily



Bridging models through rsdf:subClassOf Axioms



Bridging models through rsdf:subPropertyOf Axioms



More complex mappings are also possible• Using additional OWL axioms, SWRL rules

or SPAQL Construct statements – as shown in the example below

This approach will be needed for the DOT EA information:

•In the NAS database, State information stored in its own table

•In the EA Portal database, State is just a column in a Location table



SPARQL queries across the EA information repositories

A single SPARQL query in TopBraid Composer will fetch information about any locations in New York stored in either of the databases

More information on using Semantic Web standards for database integration at: http://composing-the-semantic-web.blogspot.com/

and www.topbraidcomposer.com



Next Steps

• Review with FAA stakeholders• Identify some capability cases and go

through a tabletop exercise with the ontology

• Work with Rick Murphy at GSA to make the ontology available on CORE.gov

presented to: by: date: federal aviation administration ontology for enterprise architecture mitre...

Documents

investmentportfolio

capital planning

multiple layers slide

strategic goals

business information

initiative business

dot ea repository

ea domain models