Publication Date: 2021-01-13
Approval Date: 2020-12-14
Submission Date: 2020-11-07
Reference number of this document: OGC 20-020
Reference URL for this document: http://www.opengis.net/doc/PER/t16-D001
Category: OGC Public Engineering Report
Editor: Sergio Taleisnik
Title: OGC Testbed-16: Aviation Engineering Report
COPYRIGHT
Copyright © 2021 Open Geospatial Consortium. To obtain additional rights of use, visit http://www.opengeospatial.org/
WARNING
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 Public 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.
LICENSE AGREEMENT
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 A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD. THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.
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.
- 1. Subject
- 2. Executive Summary
- 3. References
- 4. Terms and definitions
- 5. Overview
- 6. Background
- 7. Technical Architecture
- 8. SWIM Data Relay API
- 9. Semantic Registry
- 10. Triple Builder and Triple Store
- 11. Aviation Ontologies
- 12. Semantic Web Client
- 13. SWIM Data Client
- 14. Recommendations and Future Work
- 14.1. Fostering the use of OGC API and Linked Data in aviation
- 14.1.1. Implementing OGC API - Features within SWIM Data Services
- 14.1.2. Demonstrating The Value of Linked Data in Aviation
- 14.1.3. Exploring Alternatives for a Seamless Transition to Linked Data
- 14.1.4. Demonstrating Interoperability Between Diverse APIs
- 14.1.5. Exploring Linked Data Support Alternatives for OGC APIs
- 14.2. Ontology Development
- 14.3. Better Understanding the Industry by Engaging with SWIM Consumers
- 14.1. Fostering the use of OGC API and Linked Data in aviation
- Appendix A: SWIM Data Relay API: Sample FIXM to GeoJSON Mapping
- Appendix B: Semantic Registry: Sample Resource and Collection Mapping
- Appendix C: Semantic Registry: GraphQL Schema
- Appendix D: Triple Builder: Sample Triple Generation
- Appendix E: SWIM Data Client: Sample GraphQL Call to the Semantic Registry
- Appendix F: Revision History
- Appendix G: Bibliography
1. Subject
This Testbed-16 Aviation Engineering Report (ER) summarizes the implementations, findings and recommendations that emerged from the efforts of further advancing interoperability and usage of Linked Data within the Federal Aviation Administration (FAA) System Wide Information Management (SWIM) context. The goal of this effort was to experiment with OpenAPI and Linked Data to explore new ways for locating and retrieving SWIM data in order to enable consumers to consume SWIM data more easily in their business applications, and enable the discovery of additional relevant information for their needs.
Specifically, this ER documents the possibility of querying and accessing data (and its metadata) using Semantic Web Technologies as well as interlinking heterogeneous semantic data sources available on the Web. Together with an analysis on the potential for using OpenAPI-based Application Programming Interface (API) definitions to simplify access to geospatial information, an exploration of solutions for data distribution that complement those currently used by SWIM is presented.
This ER describes a solution architecture consisting of a collection of interoperable components developed to demonstrate technologies that can help achieve Testbed 16 objectives. This document describes 1.) a component built to relay SWIM data through an OGC API – Features endpoint, and 2.) a Client Application built to interact with this API. This document also describes:
-
A Semantic Registry built to serve SWIM service and collection metadata,
-
A Triple Builder and a Triple Store designed to generate aviation linked data, and
-
A Semantic Web Client built to interact with the Triple Store.
Finally, this ER captures lessons learned and recommendations for future work.
2. Executive Summary
FAA SWIM Data Services currently produce data from the National Airspace System (NAS) to consumers using various protocols and service offerings in both synchronous and asynchronous messaging formats. These services are documented and described in the FAA’s NAS Service Registry/Repository (NSRR). Consumers can access the NSRR to obtain this information for each SWIM service offering in order to develop their business applications. Often, business applications require multiple SWIM data. Therefore, efforts were made to standardize the SWIM data models for their domains (i.e. weather, aeronautical, and flight) based on XML standards such as Weather Information Exchange Model (WXXM), Flight Information Exchange Model (FIXM), and Aeronautical Information Exchange Model (AIXM).
The use of standardized data models improves the interoperability of data processing. SWIM Data Services are designed with "data-centric approaches" consisting on defining and standardizing logical data models. These in turn drive the implementation of dictionaries (what to call things), metadata (a means to discover things) and services (how to access and process things). As the implementations that result from these approaches fall short of providing sufficient semantics and context, the interoperability between them becomes limited. These circumstances can be improved by taking a semantic-enabled approach which adds a machine-encoded, semantics-based knowledge layer to NAS data and services, helping ensure that SWIM objects and entities are properly interpreted and employed, in a useful mission context [1].
Previous OGC work has addressed the challenges of increasing interoperability and semantically-enabling aviation data services. Recently, the OGC community has developed a new family of standardized OpenAPI-based Web APIs for the various geospatial resource types with the potential to enhance the way in which consumers can access geospatial data from various sources. One initiative in particular, reflected in the Testbed-14 (OGC 18-035) Semantically Enabled Aviation Data Models Engineering Report, provided the baseline and recommendations that shaped the requirements for the Testbed-16 Aviation Task.
The goals for the Aviation Task were classified into two main areas:
-
API Modernization
-
Evaluating solutions for data distribution that complement those currently used by FAA SWIM
-
Advancing data integration in the aviation community by facilitating flexibility in deployment solutions
-
Exploring the potential of OpenAPI on simplifying and modernizing access to geospatial information
-
-
Linked Data
-
Querying and accessing SWIM data (and associated metadata) using Semantic Web technologies
-
Interlinking heterogeneous aviation related semantic data sources available on the Web
-
To achieve these goals, the Aviation Task was organized into the development and testing of a system of six interconnected components, as shown in Figure 1:
-
A SWIM Data Relay API (identified as D100): An OGC API - Features endpoint relaying SWIM data retrieved from SWIM Data Services.
-
A Semantic Registry (identified as D101): An API serving metadata for SWIM services and metadata for the datasets these services provide.
-
A Triple Builder and a Triple Store (identified as D103): A generator and provider of aviation linked data by combining aviation ontologies with data retrieved from either the SWIM Data Relay API or from other external data sources.
-
A set of Aviation Ontologies: Built to support the generation of aviation linked data by the Triple Builder.
-
A Semantic Web Client (identified as D105): A client application built to consume SWIM linked data from the Triple Store and use it in several types of user interfaces.
-
A SWIM Data Client (identified as D106): A client application built to consume SWIM data from the SWIM Data Relay API and use it in a 3D map environment.
-
The API Modernization goals were explored through the work in the SWIM Data Relay API (D100) and the SWIM Data Client (D106). The development and testing of these components demonstrated the use of OGC API - Features as a proxy to fetch, serve and ultimately consume heterogeneous SWIM data.
-
The Linked Data goals were explored through the work in the Semantic Registry (D101), the Triple Builder / Triple Store (D103), and the Semantic Web Client (D105). The development and testing of these components demonstrated the generation and consumption of aviation linked data, as well as the generation and consumption of semantically-enriched SRIM assets.
All components were successfully developed and tested. The lessons learned throughout the Testbed are captured in this ER. The following is a set of recommendations for future work:
-
Fostering the use of OGC API and Linked Data in aviation: Work in Testbed 16 demonstrated the benefits of using OGC APIs but also documented several downsides that may require adapting the perspective on how the aviation industry pretends to leverage their power of interoperability. The Testbed also shed light on the complexities of generating and consuming aviation linked data while at the same time laying the foundation for future activities that could facilitate the adoption of linked data by the aviation community. Recommendations include:
-
Implementing OGC API - Features within SWIM Data Services would eliminate the two main issues demonstrated in this Testbed of an OpenAPI-based SWIM API: the need for massive additional storage and a complex transformation logic.
-
Demonstrating Interoperability Between Diverse APIs would speed up the development of OpenAPI-based SWIM APIs by troubleshooting the design and communication of both servers and clients.
-
Demonstrating the Value of Linked Data in Aviation would help the aviation industry leverage the return of investment of transitioning to using linked data. The components built in this Testbed could be used as a starting point for such a demonstration.
-
Exploring Alternatives for a Seamless Transition to Linked Data would make it easier for servers and clients to gradually transition to using linked data.
-
Exploring Linked Data Support Alternatives for OGC APIs would help foster the adoption of linked data within OGC APIs.
-
-
Ontology Development: Work on this Testbed demonstrated the critical role of ontologies to support information integration and reasoning by means of search and discovery of assets and support of aviation linked data. Recommendations include:
-
Expanding the Scope of Aviation Ontologies by first building foundational cross-domain ontologies followed by aviation-specific ontologies based on the aforementioned.
-
Standardizing the SRIM Model to facilitate the adoption of semantic registries.
-
Improving the GeoSPARQL Standard to enhance support for querying aviation linked data
-
2.1. What does this ER mean for the Geosemantics Working Group and the OGC in general
The OGC Working Group for review of this ER is the Geosemantics Domain Working Group (DWG). This Testbed work may also be applicable to the Aviation DWG which is co-chaired by the FAA and EUROCONTROL.
The scope of the Geosemantics DWG is any aspect of semantic conceptual modeling and formal representation of data models that advances the geospatial interoperability mission of the OGC. The mission of the Geosemantics DWG is to establish an interoperable and actionable semantic framework for representing the geospatial knowledge domains of information communities as well as mediating between them.
The Geosemantics DWG has reviewed several ERs that served as baseline for the Testbed-16 Aviation Task, most notably the Semantically Enabled Aviation Data Models ER of Testbed-14 (OGC 18-035), making this DWG the ideal reviewer of this Testbed-16 Aviation ER. This Task took a step further from the conceptual elements explored in previous work and generated a working example of a modern and semantically-enabled system of interconnected aviation data sources. The lessons learnt from the development of this system will help advance the objectives of this DWG and the OGC.
2.2. Document contributor contact points
All questions regarding this document should be directed to the editor or the contributors:
Contacts
Name | Organization | Role |
---|---|---|
Sergio Taleisnik |
Skymantics |
Editor |
Charles Chen |
Skymantics |
Contributor |
Eugene Yu |
George Mason University |
Contributor |
Felipe Carrillo Romero |
Hexagon |
Contributor |
Stephane Fellah |
Image Matters |
Contributor |
Wenwen Li |
Arizona State University |
Contributor |
Yuanyuan Tian |
Arizona State University |
Contributor |
Scott Serich |
OGC |
Contributor |
2.3. 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.
3. References
The following normative documents are referenced in this document.
4. 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.
- ● Linked Data
-
a set of best practices for publishing and connecting structured data on the Web.
- ● Semantics
-
a conceptualization of the implied meaning of information that requires words and/or symbols within a usage context. [1]
- ● DCAT
-
Data Catalog Vocabulary — an RDF vocabulary designed to facilitate interoperability between data catalogs published on the Web.
- ● SRIM
-
Semantic Registry Information Model — a superset of the DCAT ontology that defines the set of classes and properties commonly used to represent any item in a register. [2]
- ● SWIM
-
System Wide Information Management — program overseen by the Federal Aviation Administration (FAA) designed to facilitate greater sharing of Air Traffic Management (ATM) system information
- ● Taxonomy
-
a system or controlled list of values by which to categorize or classify objects. [1]
- ● Triple
-
the most high-level abstraction in the semantic web. It describes a statement using a triple of "Subject - Predicate - Object". URIs are used to identify the subject of the statement. The object of the statement can be another URI or a literal like a string or number. [3]
4.1. Abbreviated terms
-
AIXM Aeronautical Information Exchange Model
-
API Application Programming Interface
-
DCAT Data Catalog Vocabulary
-
FIXM Flight Information Exchange Model
-
OWL Web Ontology Language
-
RDF Resources Description Framework
-
SKOS Simple Knowledge Organization System
-
SRIM Semantic Registry Information Model
-
SWIM System Wide Information Management
-
WSDOM Web Service Description Ontological Model
-
WXXM Weather Information Exchange Model
5. Overview
Section 6 describes the background work that preceded and laid the foundation for the work performed in the Aviation Task.
Section 7 outlines the status quo, presents the Testbed 16 Aviation Task goals and summarizes the work performed on this Testbed activity.
Section 8 describes the SWIM Data Relay API developed to meet the goals of this Testbed activity as well as documenting lessons learned and challenges.
Section 9 describes the Semantic Registry developed to meet the goals of this Testbed activity as well as documenting lessons learned and challenges.
Section 10 describes the Aviation Ontologies developed to meet the goals of this Testbed activity as well as documenting lessons learned and challenges.
Section 11 describes the Triple Builder and Triple Store developed to meet the goals of this Testbed activity as well as documenting lessons learned and challenges.
Section 12 describes the Semantic Web Client developed to meet the goals of this Testbed activity as well as documenting lessons learned and challenges.
Section 13 describes the SWIM Data Client developed to meet the goals of this Testbed activity as well as documenting lessons learned and challenges.
Section 14 provides recommendations for future work.
6. Background
This Testbed-16 task worked on better understanding the value of semantic-enablement and of modern Web APIs in the context of SWIM service integration. The work carried out in this Testbed was based on a knowledge base composed of a plethora of OGC initiatives, summarized in Figure 2 and further described in this chapter.
6.1. Semantic-Enablement
The Semantic Web is a Web of Data — of dates and titles and any other data one might conceive of. The collection of Semantic Web technologies (RDF, OWL, SKOS, SPARQL, etc.) provides an environment where applications can query that data and draw inferences using vocabularies, among others [4].
To enable wider adoption of the Semantic Web, the term of Linked Data was introduced in 2008. Linked data provides a simplified view of the Semantic Web as a web of linkage between data nodes. The idea of linked data is similar to the web of hypertext. However the semantic web is not merely about publishing data on the web but more about making links in such a way that a person or a machine can explore the data [3]. The linked data leads to other related data. The semantic web is also constructed in such a way that it can be parsed and reasoned about. The web of hypertext is constructed with links anchored in HTML documents. At the same time the semantic web is constructed in such a way that arbitrary links between entities are described by Triples in RDF. URIs are used to identify any kind of concept [5].
OGC has investigated the use of Linked Data and Semantic Web Technologies in numerous past Testbeds:
-
OGC 18-094r1, OGC Testbed-14: Characterization of RDF Application Profiles for Simple Linked Data Application and Complex Analytic Applications Engineering Report
-
OGC 18-032r2, OGC Testbed-14: Application Schema-based Ontology Development Engineering Report
-
OGC 17-040, OGC Testbed-13: DCAT/SRIM Engineering Report
-
OGC 17-032r2, OGC Testbed-13: Aviation Abstract Quality Model Engineering Report
-
OGC 17-018, OGC Testbed-13: Data Quality Specification Engineering Report
The topic of semantic-enablement of models used in the domain of aviation has been explored previously in OGC Testbeds.
-
OGC 19-021, OGC Testbed-15: Semantic Web Link Builder and Triple Generator
-
OGC 18-035, OGC Testbed 14: Semantically Enabled Aviation Data Models Engineering Report
-
OGC 17-036, OGC Testbed-13: Geospatial Taxonomies Engineering Report
-
OGC 16-039r2, OGC Testbed-12: Aviation Semantics Engineering Report
-
OGC 16-046r1, OGC Testbed-12: Semantic Enablement Engineering Report
Testbed-12 participants focused on semantic-enablement by means of parallel initiatives that worked on topics of semantic portrayal, semantic search and semantic mediation (OGC 16-046r1). An OGC ER (OGC 16-039r2) examined the role of geospatial semantic technology within aviation by proposing extensions to WSDOM that enabled an efficient discovery of OGC-compatible web services (OWS) and helped to create a service knowledge base. A Semantic Registry Information Model (SRIM) was defined as a superset of the W3C Data Catalog (DCAT) ontology that defined the set of classes and properties commonly used to represent any item in a register (OGC 16-059).
Other initiatives within Testbed-12 reviewed the topic of cyber security within the aviation domain in conjunction with OGC Web Services (OWS) (OGC 16-040r1), provided recommendations for the implementation of GML elements into FIXM (OGC 16-028r1), and advanced previous work in the area of business rules for AIXM 5 based on SBVR (OGC 16-061).
Testbed-13 saw the implementation of a RESTful Semantic Registry that supported the Semantic Registry Information Model (SRIM) (OGC 17-040). This work served as a foundation for the Semantic Registry built in Testbed-16.
Further work in Testbed-13 focused on formulating geospatial taxonomies to support the classification of aviation services based on their geospatial characteristics and integrating them with SDCM in order to enable the discovery of those services (OGC 17-036).
Finally, Testbed-13 also focused on aviation data quality. The Aviation Abstract Quality Model ER (OGC 17-032r2) describes a taxonomy and a model for the fundamental concepts related to data quality. The OGC Data Quality Specification ER (OGC 17-018) provided methods to quantify the quality concepts described in the AQM, and extended the SDCM to be able to support this quality information for each service described in the registry.
The Testbed-14 Semantically Enabled Aviation Data Models ER (OGC 18-035) describes work on semantically-enabling existing data and metadata models used in the aviation industry. Before Testbed-14, these models were already using Linked Data standards to represent information. However, these models were failing to provide enough semantics to facilitate the integration of information and services, improve search and discovery in the current registry, and increase the level of automation in systems. OGC 18-035 laid out a series of recommendations for future work, many of which were addressed in Testbed-16: Managing controlled vocabularies, developing a Semantic Registry, investigating the modularization and encoding of aviation ontologies, as well as demonstrating the use of semantic enablement of aviation data.
Finally, the Testbed-15 Semantic Web Link Builder and Triple Generator (OGC 19-021) described a generalized approach towards performing data fusion from multiple heterogeneous geospatial linked data sources. Despite the use case in this Testbed was not aviation focused, the concepts developed were deemed reusable within any other domain and were therefore utilized for the Testbed 16 Aviation task.
6.2. OpenAPI-based Web APIs
There are many documented benefits for using Web APIs in the context of data retrieval and processing like SWIM. Benefits include faster time to market for products, more flexibility in deployment models, and straight forward upgrade paths as standards evolve.
The goal of the OpenAPI Specification is to define a standard, language-agnostic interface description for HTTP APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection. When properly defined via OpenAPI, a consumer can understand and interact with the remote service with a minimal amount of implementation logic. Similar to what interfaces have done for lower-level programming, OpenAPI removes the guesswork in calling the service [6].
OGC members have been investigating the use of OpenAPI since 2016. This investigation was in part due to recognizing that OGC’s existing web service standards (aka W*S or OWS) were in effect web APIs. Modernizing the OGC model for getting content on the web required a fairly fundamental change in underlying design [7].
Work in Testbed-14 initiated OGC developments in OpenAPI. A major revision of the OGC Web Feature Service (WFS) was revised by proposing a set of innovations, including the support of the OpenAPI specification (OGC 18-021, OGC 18-045). OGC built upon that experience and one year later published OGC API - Features (OGC 17-069r3), the first OGC standard defined and documented using OpenAPI. Concurrently, Testbed-15 proposed an OpenAPI-based API specification for maps and tiles (OGC 19-069), as well as styles (OGC 19-010r2).
At the time of publication of this ER, the OGC members are actively working on nine API standards, each one focused on serving a specific set of elements:
This section next describes two of the OGC APIs that are most relevant to this Testbed-16 Aviation task.
OGC API - Features
The OGC API – Features Standard is a multi-part standard that defines the capability to create, modify, and query vector feature data on the Web and specifies requirements and recommendations for APIs that want to follow a standard way of accessing and sharing feature data [8].
This OGC API was considered as the foundation for the SWIM Data Relay API and the SWIM Data Client developed in this Testbed, as the data retrieved from SWIM services would ultimately be displayed as geospatial elements on maps.
OGC API - Records
The OGC API – Records document is a multi-part draft specification that defines the capability to create, modify, and query metadata on the Web. The draft specification enables the discovery of geospatial resources by standardizing the way collections of descriptive information about the resources (metadata) are exposed [9].
This draft OGC API was initially considered as the foundation for the Semantic Registry developed in this Testbed, as metadata querying was a fundamental part of these components, but was eventually replaced by a standard REST API.
7. Technical Architecture
This chapter outlines the current status of semantic-enablement and interoperability of SWIM Services, presents the goals defined for this Testbed based on the status quo, and finally describes the components and their interactions that were built to tackle those goals.
7.1. Status Quo
The System-Wide Information Management (SWIM) initiative supports the sharing of aeronautical, air traffic and weather information by providing communications infrastructure and architectural solutions for identifying, developing, provisioning, and operating a network of highly-distributed, interoperable, and reusable services.
As part of the SWIM architecture, data providers create services for consumers to access their data. Each service is designed to be stand-alone. However, the value of data increases when combined with other data. Real-world situations are often not related to data from not just one but from several SWIM Data Services. Having consumers retrieving data from several SWIM services raises the need for interoperability between those services. In recent years OGC members have worked on the development of a standardized family of Web APIs defined using OpenAPI for the various geospatial resource types utilized by the geospatial community. Currently, there are no SWIM services implemented using the new generation of OGC APIs.
The diversity of actors providing SWIM Services requires measures ensuring the data being transmitted can be successfully consumed. Traditionally, SWIM Data Services are designed with "data-centric approaches" consisting of defining and standardizing logical data models. These models in turn drive the implementation of dictionaries (what to call things), metadata (a means to discover things) and services (how to access and process things). As the implementations that result from these approaches fall short of providing sufficient semantics and context, the interoperability between them becomes limited [1].
The FAA has engaged in initiatives to facilitate the integration of heterogeneous data sources, including:
-
Service Description Conceptual Model (SDCM): A joint FAA-SESAR work, the SDCM is a graphical and lexical representation of the properties, structure, and interrelationships of all service metadata elements, collectively known as a Service Description.
-
SWIM Controlled Vocabulary (SWIM CV): A single source providing terms and definitions commonly employed in SWIM.
-
Web Service Description Ontological Model (WSDOM): An ontology model intended to be a basis for model-driven implementation of artifacts related to Service Oriented Architectures (SOA)
-
Semantic Web for Air Transportation (SWAT) Special Interest Group: A taskforce dedicated to sharing experiences and approaches in applying Semantic Web technologies
-
semantics.aero: An open repository for use by the international aviation community to publish artifacts developed using Semantic Web technologies
7.2. Problem Statement
Testbed-16 required investigating data integration options based on semantic web technologies and analyzing the current status of achievable interoperability.
The goals of the Testbed-16 Aviation Task were classified into two areas:
-
API Modernization
-
Evaluating solutions for data distribution that complement those currently used by FAA SWIM.
-
Advancing data integration in the aviation community by facilitating flexibility in deployment solutions.
-
Exploring the potential of OpenAPI for simplifying and modernizing access to geospatial information.
-
-
Linked Data
-
Querying and accessing SWIM data (and associated metadata) using Semantic Web technologies.
-
Interlinking heterogeneous aviation related semantic data sources available on the Web.
-
The following questions were proposed in the Testbed 16 Call for Participation (CFP) as guidance for the Task efforts:
-
Should the existing SWIM architecture be modernized with resource-oriented Web APIs?
-
What role can OGC Web APIs play for a modernized SWIM services?
-
How can OGC APIs be used to address the heterogeneous semantic SWIM landscape?
-
What impact do Linked Data principles and requirements have on OGC Web APIs?
-
How to deal with the various ontologies and taxonomies used in SWIM?
-
How to best enhance the various ontologies and how to build a scalable geospatial definition server?
-
How to best combine data from various SWIM data feeds to make it available for multi-source and linked data based analytics?
The long-term goal for the FAA is, as seen on Figure 3, to facilitate access to SWIM services and registries from not only the FAA but also other aviation partners as well such as EUROCONTROL or the Korea Aviation Corporation (KAC), Republic of Korea (ROK). For the purposes of this Testbed, only FAA SWIM services were considered as part of the scope.
7.3. Functional Overview
As shown in Figure 4, the Aviation Task architecture was organized into a system of six interconnected components. All six components were developed simultaneously throughout the Testbed, with permanent communication and cooperation among participant organizations. The following is an overview of each component and their interactions between them. A more thorough description of their internal architecture and lessons learned can be found in the following chapters in this ER.
-
A SWIM Data Relay API (identified as D100): An OGC API - Features endpoint serving SWIM data.
-
A Semantic Registry (identified as D101): An API serving metadata of SWIM services together with metadata of the datasets they provide.
Note
|
The Testbed CFP included two instances of the SWIM Data Relay API and did not include the Semantic Registry. The need for a Semantic Registry, and the replacement of the second SWIM Data Relay API instance with the Semantic Registry, was proposed and accepted early in the Testbed. |
-
A Triple Builder and Triple Store (identified as D103): A generator and provider of aviation linked data by combining aviation ontologies with data retrieved from either the SWIM Data Relay API or from other external data sources.
-
A set of Aviation Ontologies: Built to support the generation of aviation linked data by the Triple Builder.
Note
|
The development of ontologies was not part of the requirements specified in the Testbed CFP. The need for ontologies was identified in the early stages of the Testbed and acquired enough significance to be considered a separate component. |
-
A Semantic Web Client (identified as D105): A client application built to consume SWIM linked data from the Triple Store and use it in several types of user interfaces.
-
A SWIM Data Client (identified as D106): A client application built to consume SWIM data from the SWIM Data Relay API and use it in a 3D map environment.
Each component, as well as their interactions, was designed to help answer the questions laid out by the main Testbed goals:
-
The Linked Data goals were explored through the work in the Semantic Registry (D101), the Triple Builder / Triple Store (D103), and the Semantic Web Client (D105). The development and testing of these components demonstrated the generation and consumption of aviation linked data, as well as the generation and consumption of semantically-enriched SRIM assets.
-
The API Modernization goals were explored through the work in the SWIM Data Relay API (D100) and the SWIM Data Client (D106). The development and testing of these components demonstrated the use of OGC API - Features as a proxy to fetch and serve heterogeneous SWIM data.
7.3.1. Frontend Component Interactions
Two scenarios involving end users were identified - one for each of the two clients developed in this Testbed: The SWIM Data Client (D106) and the Semantic Web Client (D105). Both scenarios consist of the end user interfacing a client application to visualize aviation data. The major differences between the scenarios are:
-
Clients have different visual interfaces to display aviation data. The SWIM Data Client is a 3D map environment displaying aeronautical infrastructure, airspaces, and routes. The Semantic Web Client displays linked data about airports and flights on 2D maps, tables and graphs.
-
The SWIM Data Client retrieves SWIM data via the SWIM Data Relay API, while the Semantic Web Client retrieves SWIM linked data from the Triple Store.
-
The SWIM Data Client discovers data source endpoints through the Semantic Registry, while the Semantic Web Client has the endpoints hardcoded.
The frontend scenarios are described in Figure 5. Detailed descriptions and lessons learned from each component are presented in the following chapters in this ER.
7.3.2. Backend Component Interactions
The backend processes support the operations of the frontend. There are three main backend scenarios, one for each of the backend components. These have in common the consumption, processing and storage of data related to aviation.
-
The operation of the SWIM Data Relay API (D100) consists of extracting features from SWIM Publish/Subscribe (Pub/Sub) messages and making them available for other components to consume through an OGC API - Features endpoint.
-
The operation of the Semantic Registry (D101) consists of extracting service and collection metadata from providers of SWIM data and making them available for other components to consume as SRIM/DCAT assets through a REST or a GraphQL endpoint.
-
The operation of the Triple Builder and Triple Store (D103) consists of extracting aviation data, transforming it into linked data, and making it available for other components to consume through a GeoSPARQL endpoint.
The backend scenarios are described in Figure 6. Detailed descriptions and lessons learned from each component are presented in the following chapters in this ER.
8. SWIM Data Relay API
The SWIM Data Relay API was the component designed to fetch information from SWIM data sources, receive requests from the SWIM Data Client or the Triple Builder, and relay that information through an OGC API - Features service. This Component provides unified discovery operations that allow users to retrieve metadata (capabilities and information about the distribution of data) and data (encoded in standard simple feature formats, e.g. GeoJSON).
George Mason University participants did the development of this component. The main design objective of this component was to demonstrate the distribution of SWIM data through an OpenAPI-based API.
8.1. Status Quo
There are different services to enable the discovery and access of data within a System Wide Information Management (SWIM) system for aeronautic information. For the Federal Aviation Administration (FAA) SWIM, the NAS (National Aviation Services) Service Registry and Repository (NSRR) provides a centralized registry to hold detailed information about all existing and planned SWIM-enabled services. This includes information on where services and documents can be registered and searched. In addition, the FAA System Wide Information Management (SWIM) Cloud Distribution Service (SCDS) provides near real-time FAA SWIM data to the public via Solace Java Message Service (JMS) messaging.
Among the data services in SCDS, there are:
-
SWIM Terminal Data Distribution System (STDDS) for surface movement data (Airport Surface Detection System — Model X (ASDE-X), Airport Surface Surveillance Capability (ASSC)), approach surveillance radar data from STARS systems, Runway Visual Range (RVR), and a variety of departure event data; Integrated Terminal Weather System (ITWS) for a variety of weather information in graphic and textual forms from different sites;
-
Traffic Flow Management(TFMS) for both flight data (Flight Plans, Departure/Arrival Notifications, Position Reports) and flow information (Traffic Management Initiative (TMI), Ground Stop (GS), Ground Delay Program (GDP));
-
Time Based Flow Management (TBFM) metering information data for knowledge of when metering is in effect at an Air Route Traffic Control Center (ARTCC) when Adjacent Center Metering (ACM) is occurring and at which sites, flight Scheduled Time of Arrivals (STAs) to the runway threshold, meter fix and all arcs, and flight Estimate Time of Arrivals (ETAs) to the runway threshold;
-
SWIM Flight Data Publication Service (SFDPS) for a variety of En Route flight data (such as flight plans, beacon codes, and handoff status) and airspaces (such as sector configuration data, route status, Special Activity Airspace (SAA) status, and altimeter settings, and general data including En Route Automation Modernization (ERAM) status information);
-
The Aeronautical Information Management (AIM) Federal Notices to Airmen (NOTAM) System (AIM FNS) for information on temporary changes to components of, or hazards in the National Airspace System (NAS).
There are different schemas for discovering and accessing data with the FAA SWIM. For example, the AIM FNS delivers messages that contain encoding in the Aeronautical Information Exchange Model (AIXM) 5.1 format with different extensions (e.g. FAA extension, Event extension). The SFDPS delivers en-route flight information in Flight Information Exchange Model (FIXM) NAS 3.0. The ITWS in production delivers weather information in legacy ITWS data models.
Standard exchange information models have been developed in the aviation domain. AIXM is designed to exchange information on aerodrome/heliport including movement areas, services, facilities, airspace structures, organizations and units (including services), points and NAVAIDs, procedures, routes, and flying restrictions. The latest version of AIXM is 5.1.1. FIXM is designed to exchange information on flight and flow Information. Version 4.2.0 is the latest version of FIXM. The Weather Information Exchange Model (WXXM) is designed to deliver weather data. The latest version of WXXM is version 2.0. The implementation and support of these standard exchange information models differs among different services and organizations.
SWIM data are time sensitive. Most SWIM data are delivered through message services in near real time or real time. Data volume is high volume and velocity. Over 1.6 trillion messages per day and 4.3 terabytes of data per day are passing through the SWIM. There is no direct support of spatiotemporal searching.
The emerging suite of OGC APIs is a new generation of OGC standard interfaces to enable the interoperation of geospatial resource discovery and access. The currently approved OGC API – Features is defined and documented using the OpenAPI 3.0 specification. OpenAPI supports the automation of coding for servers and clients in unified RESTful services, i.e. those implementing Representational State Transfer (REST). To the knowledge of this Testbed’s participants, there is currently no SWIM data service implemented as a service described using OpenAPI.
8.2. Functional Overview
This component acts as a proxy service to relay information from SWIM data services. SWIM data is normally delivered by SWIM Data Providers through publish/subscribe services. Since APIs defined using the OpenAPI specification deliver data through on-demand RESTful calls, the SWIM Data Relay API Component had to restructure the retrieved SWIM data before making it available through its REST endpoint. To achieve this, the component consists of four interconnected subcomponents:
-
A Harvester periodically captures SWIM messages.
-
A Feature Handler maps the incoming messages into a common feature model that supports both spatial and temporal searches.
-
A geospatially-aware database manages and stores the harvested data.
-
An OGC API - Feature Service publishes and relays SWIM data stored in the database.
Figure 7 breaks down the SWIM Data Relay API, and outlines how data flows through its subcomponents. The workflow sequence of its elements, as well as their connections to external components, is outlined on Figure 8.
8.2.1. Harvester
SWIM data services are primarily publish/subscribe services for messages that flow from providers to users. Publish/subscribe messaging, or pub/sub messaging, is a form of asynchronous service-to-service communication. In a pub/sub model, any message published to a topic is immediately received by all of the subscribers to the topic. Regular SWIM data consumers first need to subscribe to approved services they may be interested in, then start a client service to receive messages delivered in near real time from those SWIM data services they subscribed to.
The harvester consists of a Solace JMS (Java Message Service) Message Client. The JMS message client is responsible for listening to subscribed services in SWIM and relay the incoming messages to the feature handlers that process the messages.
8.2.2. Feature Handler
For each service, there is an information handler application built to analyze and process each service feed. Message handlers are implemented using Java. All these handlers run as services to continuously monitor and analyze incoming messages.
Processing spatial and temporal extent:
In each SWIM message, features have location, coverage, or geometric dimensions, which are used to define the spatial extent of each feature. Each message also includes temporal validation, distribution timestamp, or creation timestamp, which are used to define the temporal extent of each feature described. The handlers extract geospatial information and temporal extent from each message and store spatiotemporal information into the geo-database for indexing and searching.
Specific attributes are also extracted from each feed as required. Selection of attributes depend on the services and the data types to be handled. As an example, flight data may have speed and altitude, while airspace data may have elevation and upper limit of vertical structures. During the harvest stage, some of these native attributes are extracted and elevated as properties in GeoJSON encoding. For example, speed and altitude of a flight from FIXM-NAS flight data are exposed as properties.
Feature description, abstract, and topics are extracted from their schema description, or relevant online document. For example, AIXM features have an online UML model document. The online document was used to extract relevant information about each feature, such as AIXM data representing airspace. Title and description are directly extracted from the heading and the table element, respectively. Schema information is extracted from the section for the table of “List of attributes”. These are used in describing each airspace collection.
Generating encodings:
To support different media-types in the SWIM Data Relay API Component, the harvesting stage includes a preliminary encoding process. Each message is converted and encoded in a supported format with native or default projections. The projection may be changed by reprojection in the server of the Feature Server. Additional attributes may be added to combine each message into feature collections. For this Testbed, the component was designed with three types of encodings supported:
-
First, there is a native encoding which depends on the message service that provided the data. For example, the message may be kept in AIXM, FIXM-NAS, or TFM Data Service schema.
-
Second, a conversion to GeoJSON is performed based on a common model. Spatial and temporal extents are extracted from the original message. Geocoding may be applied to get spatial extent in actual longitude and latitude coordinates. Selected properties may be elevated and extracted as properties from its original message. For example, altitude and speed are extracted for flight and elevation and top limit for airspace. The original message is also converted into JSON and kept completely in a property “json”.
-
Third, the conversion to Text/HTML is done on the fly by using a writer under media negotiation support through JAX-RS service implementation. The conversion is primarily from GeoJSON but adding some necessary JavaScript functions to support map viewer and active links.
8.2.3. Database
The database manages the harvested information as documents. Attributes commonly found in AIXM, FIXM or GeoJSON objects do not have a corresponding table or field in the database. The data schema is treated within each document (feature) encoding. Attributes commonly indexed and frequently searched could be eventually elevated as fields in the database for performance and convenience. PostGIS was used to maintain and index spatial properties. PostgreSQL was used to manage and archive indexes.
To store the same SWIM data in different encodings, the database has an encoding table, where two attributes "type" and "encoding" pair the data to its corresponding different encodings. The field "type" uses the actual media type supported by the service. The media types are currently (or proposed to be) registered with the Internet Assigned Numbers Authority (IANA).
The metadata is stored in a collection table (Collections
) and a linked encoding table (CollectionEncoding
). For example, title and description for a collection are stored in corresponding fields in the collection table. The "list of attributes" are extracted, re-formatted, encoded, and stored in the encoding table by linking to the collection identifier. The pair of type
and encoding
has the similar relationship as that used in feature encoding table, i.e. type is media type and encoding store the stubs of collection class in related encoding type.
Reusable and common attributes for a collection are directly stored in the Collection
table while details and customized attributes are encoded and stored in the CollectionEncoding
table. With the current implementation, customized attributes are only available for AIXM feature because that is the only one that has corresponding pages to scrape information from. Only text/html encoding is stored for now. Because of this limitation, the details in the encoding table are not necessarily available/used during the serving stage for the current implementation.
Figure 9 shows the Entity-Relationship Diagram of the SWIM Data Relay API Component.