Ontology for Enterprise Architecture

1. Ontology for Enterprise Architecture Mitre EA Conference Con Kenney & Irene Polikoff September 7, 2006

2. Budget Planning Cycle Strategic Planning Enterprise Architecture Business Case Development Feedback / Results Capital Planning Direction Portfolio Management Program Management Change Performance Measurement Operations Enterprise Architecture processes • Strategic Planning - establishes vision, mission, goals, objectives, & enterprise performance measures • Enterprise Architecture – Develops modernization blueprints to meet strategic goals • Business Case Development – Creates the OMB 300s from selected blueprint initiatives • Capital Planning – Selects which initiative business cases will be funded • Investment/Portfolio Management – Compares investment options and guides decision making • Program Management – Implements the funding decisions to change the operational environment according to the modernization blueprint • Performance Measurement – Measure execution performance against targets

3. Enterprise Architecture Layers Federal Investment Management Model Has Multiple Layers DOT EA Repository, Metis, AND Portfolio Management Software

4. EA Domain Models

5. Two FAA Enterprise Architecture parts for NAS and Non-NAS FAA Enterprise Architecture NAS Non NAS ASH AVS ATO Sys Ops ARP ABA Tech Ops Ops Plan ARC Safety AIO Comm ACR FlightServ API Fin AGI AHR AGC Terminal Acq & Biz En Route & Ocean AST AOC AEP

6. 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)

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

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

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

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

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

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

13. ‘Location’ in the DOT EA Ontology

14. The DOT EA Ontology is a collection of linked Models

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

16. Bridging models through rsdf:subClassOf Axioms

17. Bridging models through rsdf:subPropertyOf Axioms

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

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

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