Publication Date: 2019-02-07

Approval Date: 2018-12-13

Submission Date: 2018-11-27

Reference number of this document: OGC 18-035

Reference URL for this document:

Category: Public Engineering Report

Editor: Stephane Fellah

Title: OGC Testbed-14: Semantically Enabled Aviation Data Models Engineering Report

OGC Engineering Report


Copyright (c) 2019 Open Geospatial Consortium. To obtain additional rights of use, visit


This document is not an OGC Standard. This document is an OGC Public Engineering Report created as a deliverable in an OGC Interoperability Initiative and is not an official position of the OGC membership. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an OGC Standard. Further, any OGC Engineering Report should not be referenced as required or mandatory technology in procurements. However, the discussions in this document could very well lead to the definition of an OGC Standard.


Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.


This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications.

This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.

Table of Contents

1. Summary

This Engineering Report (ER) summarizes the OGC Testbed-14 findings and recommendations to “semantically enable” existing data and metadata models used in the aviation industry. Examples of such data and metadata models include Aeronautical Information Exchange Model (AIXM) [1], Weather Information Exchange Model (WXXM) [2], Flight Information Exchange Model (FIXM) [3],Web Service Description Document (WSDD), Service Description Conceptual Model (SDCM) [4]). These models use Linked Data standards to represent this information and aim to improve the search and discovery of services and information in the aviation domain using the System Wide Information Management (SWIM) environment. This report provides a review of the existing data models and explore different approaches to provide a semantic representation of the current metadata and data models used in the aviation domain. The ER also discusses the role and importance of the controlled vocabularies.

1.1. Requirements & Research Motivation

The current SWIM developed by Federal Aviation Administration (FAA) provides an API to search and discover web services. The current service model is based on the SDCM model, which is inspired by the Semantic Markup for Web Services (OWL-S) [5] specification of the World Wide Web Consortium (W3C). However, the response returned by the API is encoded in Extensible Markup Language (XML) and uses XML Schema for validation. The description of the service is focused on defining how the service input/output can be constructed and manipulated (e.g., XML schemas, Web Service Description Language (WSDL) [6] files) but has limited semantics about the information it operates on. The current service description standards (e.g., WSDL and XML Schema) operate almost entirely at the syntactic level, focusing only on describing exposed functionality (methods signatures, input/output types) and failing to capture enough semantics (i.e., they define structure, not meaning). The standards for free-text, human-consumable documents, (e.g., FAA’s WSDD), support a sufficient amount of semantics but are not suitable for automated discovery and provide very limited support for semantic interoperability.

The following requirements were to be addressed in the OGC Testbed-14:

  • Testbed-14 shall provide recommendations for making existing data models used in aviation industry (e.g., AIXM, WXXM, and FIXM) “semantically enabled”.

  • The data models shall be enabled to present their contents in formats suitable for adaptation by Semantic Web technologies, including considerations for role and applicability of ontologies and linked data approaches to complex information realms such as SWIM.

  • The work shall provide a clear definition of next steps.

1.2. Prior-After Comparison

The topic of semantic-enablement of models used in the domain of aviation has been explored previously in OGC Testbeds (OGC 16-039 [7],OGC 17-036 [8]). In past demonstrations, analyses recommended the use of run-time registries and complex use cases for service discovery and data taxonomy/ontology. However, much of the information exchanged within the FAA National Airspace System (NAS) [9] System-Wide Information Management (SWIM) network is made up of various data models using XML schema encoding (such as AIXM), which addresses only the structure and syntax of information exchanged between systems, but not the semantic aspect of the model. Testbed-12 [7] and 13 [8] have made progress toward the semantic enablement of the controlled vocabularies using the Simple Knowledge Organization System (SKOS) [10] encoding but these vocabularies were still referred from the XML document based on structure and syntax. This hybrid approach does not allow the usage of off-the-shelf solutions for Linked Data such as linking heterogeneous domain entities, deductive reasoning and unified access to information. Systems are currently built around specific data models and unable to communicate and link to each other causing duplication of information and making difficult to search and discover information that are relevant for users.

The goal of this ER is to formulate an approach to semantically enable the different data models, taxonomy and service descriptions that can incorporate enough semantic metadata, including descriptive metadata, geospatial-temporal characteristics, quality information for fitness-of-use) about the services and data information, so that they can facilitate the integration of information and services, improve search and discovery in the current registry, and increase the level of automation (reasoning, access by agents) in systems.

1.3. Recommendations for Future Work

The solutions described in this engineering report may provide further insights if implemented as a greater solution for information registries. Furthermore, implementation of the recommendations for SDCM will provide a path forward for prototyping and implementation of SWIM registries and search/discovery of services and information.

This engineering report proposes the following tasks to be explored for future testbeds:

  • Controlled Vocabulary Management: The management and governance of controlled vocabularies play a crucial role in the semantic "tagging" of resources managed by NAS (Datasets, Services, Maps, Layers, Documents,etc..) and the search and discovery of these resources. Vocabularies also enable semantic enrichment, reasoning and provide a common framework to represent information based on Linked Data representation facilitating the integration of information silos. Future testbeds should investigate the requirements, design and implementation of an API for a controlled vocabulary services that manages ontologies and taxonomies (encoded in SKOS).

  • Development of a Semantic Registry Information Model (SRIM) [11] Application Profile for SWIM that extends the current SRIM model (which is based on a number of well-known vocabularies such as the W3C Data Catalog (DCAT) [12], GeoDCAT-AP [13], Dublin Core, SKOS [10], Provenance, Authoring and Versioning (PAV) ontology [14]) to describe services and datasets specific for the aviation domain and that aligns with the current SDCM effort.

  • SRIM Semantic Registry implementation [11] of the SWIM Application Profile that showcases the search and discovery of the assets managed by the SWIM ecosystem, focusing in particular to Services and Datasets.

  • Investigation of the modularization and encoding of aviation ontologies using the NASA ATM ontology as a starting point and identification of gaps with the current existing standards (AIXM, WXXM,FIXM).

  • Demonstration of the use of semantic enablement of aviation data using Linked Data representation based on the ontologies developed in the previous recommendations by deploying a Linked Data API that offers a Representational State Transfer (REST) API and a GeoSPARQL Endpoint), as well as demonstration of the link to the Dataset metadata description registered in a Semantic Registry.

1.4. What does this ER mean for the Working Group and OGC in general

This engineering report documents the findings, approaches and recommendations to semantically enable existing data models used in the aviation domain. The semantic-enablement of these existing models will improve search and discovery of aviation-related information using a semantic registry.

The chosen working group for review of this ER is the Geosemantics Domain Working Group (DWG). This work may also be applicable to the Aviation DWG which is co-sponsored by the FAA and EUROCONTROL.

The scope of the Geosemantics DWG is any aspect of semantic conceptual modeling and formal representation of aviation data models which advances the geospatial interoperability mission of OGC. A particular focus will be the adoption or development of tools and methods in support of these activities. It is the mission of the Geosemantics DWG to establish an interoperable and actionable semantic framework for representing the geospatial knowledge domains of information communities as well as mediating between them. This ER will address the need for semantically enablement of aviation data models. The use of semantics will enable better descriptions of aviation-related assets, including OGC web services in the FAA’s SWIM registry, datasets, maps, layers, etc.

1.5. Document contributor contact points

All questions regarding this document should be directed to the editor or the contributors:


Name Organization

Stephane Fellah

Image Matters LLC

Yann Le Franc

e-Science Data Factory

1.6. Foreword

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

2. References

3. Terms and definitions

For the purposes of this report, the definitions specified in Clause 4 of the OWS Common Implementation Standard OGC 06-121r9 shall apply. In addition, the following terms and definitions apply.

3.1. Semantics

A conceptualization of the implied meaning of information that requires words and/or symbols within a usage context.

3.2. Service Description

The information needed in order to use, or consider using, a service.

3.3. Service-Oriented Architecture (SOA)

A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. A SOA provides a uniform means to offer, discover, interact with, and use capabilities to produce desired effects consistent with measurable preconditions and expectations.

3.4. Registry

An enabling infrastructure that uses a formal registration process to store, catalog, and manage metadata relevant to a service. A registry supports the search, identification, and understanding of resources, as well as query capabilities.

3.5. System Wide Information Management (SWIM)

A concept using Service Oriented Architecture to facility the exchange Air Traffic Management information amongst stakeholders in the aviation domain such as Air Navigation Service Providers, airports, and airspace users.

3.6. Taxonomy

A system or controlled list of values by which to categorize or classify objects.

3.7. Web Service

A platform-independent, loosely-coupled software component designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format. Other systems interact with the Web service in a manner prescribed by its description by means of XML-based messages conveyed using Internet transport protocols in conjunction with other Web-related standards.

4. Abbreviated Terms

  • ATM Air Traffic Management

  • ICAO International Civil Aviation Organization

  • FAA Federal Aviation Administration (United States)

  • NAS National Airspace System (United States)

  • NSRR NAS Service Registry and Repository

  • OWL Web Ontology Language (W3C)

  • OWL-S Semantic Markup for Web Services

  • OWS OGC Web Service

  • RDF Resource Description Framework (W3C)

  • RDFS Resource Description Framework Schema (W3C)

  • SDCM Service Description Conceptual Model

  • SOA Service Oriented Architecture

  • SWIM System Wide Information Management

  • WSDOM Web Service Description Ontological Model

5. Overview

The ER is composed of the following sections:

Section 6 provides a review of the existing data models currently used by FAA and ontologies that are relevant for semantic-enablement of the aviation domain.

Section 7 provides a comparison of existing data-centric services approach with semantic-enabled services approach and highlights the benefits to use the latter approach. Two levels of semantic enablement are identified:

  • Metadata level semantic enablement to support search and discovery of information

  • Instance level semantic enablement to support data integration and reasoning.

Section 8 focuses on the Metadata-level semantic enablement. It discusses some of the issues found currently in existing metadata standards in particular ISO 19115. The section provides a review of relevant semantic metadata standards (DCAT, GeoDCAT,Project Open Data, SRIM) and discusses the approaches to semantic-enable metadata on the current infrastructure.

Section 9 focuses on the Data-level semantic enablement. It discusses the issue of data-silos and how semantics can enable the integration of data silos. An inventory of different technical approaches to semantic-enable the existing infrastructure is given with discussions of pro/cons/applicability of each approach.

Section 10 addresses the role of Controlled Vocabularies in the aviation domain. It provides a classification of the different types of controlled vocabularies. It also discusses some improvements that can be done on existing vocabularies, provides recommendations about the governance and lifecycle of controlled vocabularies, and highlights some best practices for ontology design.

Annex A provides some metadata samples illustrating the description of datasets and their relationships to services.

6. Review of Data Models

This section provides a review of the existing data models currently used by FAA and the aviation community.

6.1. Information Exchange Models

The first set of data models reviewed related to information exchange models. There are three primary standards currently used by the industry (FIXM, AIXM, and WXXM). The models have an abstract model defined in UML and an encoding based on XML schema. There is currently no encoding based on linked data standards such as the Web Ontology Language (OWL) [15] or RDF Schema [16].

6.1.1. Flight Information Exchange Model (FIXM)

The Flight Information Exchange Model (FIXM) is an exchange model capturing Flight and Flow information that is globally standardized. It captures data related to flights throughout their lifecycle from pre-flight planning through departure, en-route, and arrival segments, including data on aircraft location, aircraft characteristics, and cargo contents. The model is decomposed in modular packages ( Figure 1) encoded in XML Schema.

Figure 1. FIXM Core Package Structure

6.1.2. Aeronautical Information Exchange (AIXM) Model

The AIXM model describes airspace routes, procedures, boundaries, fixes, navaids, and airport surface elements (runways, gates, etc.). The objective of the Aeronautical Information Exchange Model (AIXM) is to enable the provision in digital format of the aeronautical information that is in the scope of Aeronautical Information Services (AIS). The AIS information/data flows are increasingly complex and made up of interconnected systems. They involve many actors including multiple suppliers and consumers. There is also a growing need in the global Air Traffic Management (ATM) system for high data quality and for cost efficiency.

6.1.3. Weather Information Exchange Model (WXXM)

The WXXM is designed to enable the management and distribution of weather data in digital format (XML). WXXM version 2.0 is based on Geography Markup Language (GML) and is one of the GML Application Schemas. It has been developed by the FAA and the European Organization for the Safety of Air Navigation (EUROCONTROL). WXXM is a member of a family of data models designed for use in aviation safety, notably AIXM and FIXM.

WXXM models meteorological observations, forecasts, and measurement procedures for weather features and phenomena with spatial and temporal extent. Independent from governmental standardization efforts, the airline industry has been developing Airline Industry Data Model (AIDM).

6.1.4. NASA Air Traffic Management (ATM) Model

The National Aeronautics and Space Administration (NASA) has developed a prototype data integration system that demonstrates how ontologies can be used to integrate, query, and search over various sources of heterogeneous air traffic management (ATM) data, including data from FAA, National Oceanic and Atmospheric Administration (NOAA), NASA, and other providers. In this prototype, a common ontology is used to bridge multiple types of aviation data models and enable cross-dataset querying. In general, cross-dataset querying is very challenging due to differing data formats, nomenclature, and organizational structure. Data can only be combined from multiple sources by expending significant effort to write customized code that integrates selected data on an as-needed, piecemeal basis. To address this problem, NASA is building an integrated data source that obviates this need to write special- purpose, one-off integration code.

As part of this approach, an overarching data model (the NASA ATM Ontology [1]) has been designed and implemented to serve as a backbone upon which to overlay data from multiple sources. The ontology data model is scoped sufficiently broadly to interconnect data from several different aviation realms, including flight, traffic management, aeronautical information, weather, and carrier operations. The ontology is currently populated with instance data corresponding to over 100K flights arriving and departing the three major airports in the New York Metroplex (KEWR, KJFK, KLGA) during July 2014. This data is encoded in approximately 250M triple statements and incorporates the following sources: flight track data from FAA’s ASDI (Aircraft Situation Display to Industry) data feed; airport weather from the NOAA’s METeorological Aerodrome Reports (METAR) and Terminal Aerodrome Forecasts (TAF) data feeds; information on traffic management initiatives from FAA’s Command Center website; historical traffic counts and delay statistics from the Department of Transportation (DOT)’s Aviation System Performance Metrics (ASPM)database; infrastructure data on US routes, fixes, airways, and sectors used by FAA’s En Route Automation Modernization (ERAM) system; aircraft information from FAA’s aircraft registry and from the Commercial Aviation Safety Team (CAST)/International Civil Aviation Organization (ICAO) common aircraft taxonomy; and web-based information on airlines, airport terminals and gates. Of the 250M triples, about 99.5% represent specific flight, weather, or traffic management data. These are dominated overwhelmingly by triples capturing flight track parameters from ASDI – such as altitude, location, and groundspeed – captured at the rate of one per minute of flight. The remaining 0.5% of triples capture mostly static aeronautical infrastructure information (e.g., data on airspace routes, sectors, and fixes, NAS facilities, airports, aircraft makes and models, airlines, etc.).

The figures below (all extracted from the abovementioned NASA Technical Memo) provide some intuition about how the classes and properties represent the structure, content, and relationships found in ATM data. Only a subset of available figures is shown here; please consult the NASA Technical Memo for additional illustrations.

Figure 2 illustrates the key relationships among selected New York area airspace structure and facility instances. Sector nas:ZNYsector075 is one of the sectors located in the New York Air Route Traffic Control Center (ARTCC) instance nas:ZNYcenter. Sector 075 is composed of two stacked horizontal layers of airspace, each represented by a shear-sided polygon of a certain height (only one polygon is depicted in the figure). The ZNY ARTCC has operational agreements with the FAA command center and the New York Terminal Radar Approach Control (TRACON) facility, which in turn has agreements with each of the airports in its territory. The ZNY Tier 1 structure contains all ARTCCs that directly border the ZNY ARTCC. (Note that only a small subset of instances is illustrated in order to keep the figure uncluttered and readable.)

nasa nas structure
Figure 2. ATM Ontology- Structure of the NAS

Figure 3 illustrates the basic components of the ontology representation of a flight — in this illustration, Delta Airlines flight DAL435 on 2014-07-15. The flight is associated with its departure and arrival airports; the aircraft, aircraft type, and operating carrier; and the actual and planned flight route.

nasa atm flight
Figure 3. Flight Structure

Figure 4 illustrates the relationships among instances of aircraft, carrier, flight, model, manufacturer, and other classes associated with Delta Airlines flight DAL435 on 2014-07-15 (shown in Figure 3, above). The aircraft flown for this flight is N713TW, a Boeing model 757-2Q8, one of the B757-200 family of aircraft. The aircraft family is represented as a model class and the specific model is represented as an instance of that class. The FAA also designates an aircraft type, which may cover models in multiple aircraft families. The aircraft type for model 757-2Q8 is B752. Associated with type B752 aircraft are a set of instances that describe the engine type, wake turbulence category, and weight class of all B752 type aircraft.

nasa atm equipment
Figure 4. Relationships among aircraft, carrier, flight, model, manufacturer, and related classes

Figure 5 illustrates how the actual and planned flight routes for American Airlines Flight #AAL335 are connected to the flight instance (atm:AAL335-201407150017), which is depicted at the root of the tree structure shown. The actual flight route is represented as a sequence of track points (atm:AircraftTrackPoint). Each track point represents a specific reporting time when the aircraft’s fix and speed is captured and relayed to ground systems. The track points are each linked to an instance of atm:LatLonFix, which stores the latitude, longitude, and altitude. The planned flight root is detailed in Figure 6 below.