Publication Date: 2019-02-11

Approval Date: 2018-12-13

Submission Date: 2018-11-13

Reference number of this document: OGC 18-022r1

Reference URL for this document: http://www.opengis.net/doc/PER/t14-D001

Category: Public Engineering Report

Editor: Yann Le Franc

Title: OGC Testbed-14: SWIM Information Registry Engineering Report

OGC Engineering Report

COPYRIGHT

Copyright (c) 2019 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 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.

Table of Contents

1. Summary

This Engineering Report (ER) summarizes the findings and recommendations for building an information registry working together with the existing Federal Aviation Administration (FAA) System Wide Information Management (SWIM) aviation service registries, the National Airspace System Service Registry and Repository (NSRR). This information registry should allow the different Air Traffic Management (ATM) stakeholders to retrieve the appropriate service registered in the NSRR using the semantic representation of real-life entities represented by the data served by the services (e.g. "estimated departure time", "estimated time of arrival", ”runway true bearing”…). To support the integration of this domain-specific information, the ER proposes different strategies based on the semantic annotation proposal made in OGC 08-167r2 [1] extended with a recent World Wide Web Consortium (W3C) recommendation, the Web Annotation data model [1]. In particular, the ER focuses on a solution using the W3C web annotation data model which adds semantics to the NSRR without changing the content of the database. This solution provides a low-cost, flexible and efficient alternative to add domain-specific semantics to NSRR content. The ER concludes with remarks on the elements necessary for implementing the information registry as a web annotation store as well as the necessity to build domain-specific knowledge models to support further interoperability and further service discoverability and the added-values of using the Data Catalog (DCAT) or Semantic Registry Information Model (SRIM) to better describe and retrieve ATM services.

1.1. Requirements & Research Motivation

SWIM is an interoperability framework for publishing, exchanging and manipulating ATM data based on Service Oriented Architecture (SOA) principles. One of the key elements of SOA is the service registry which provides a central access point to distributed and heterogeneous web services publishing ATM data. FAA developed such a registry, the NSRR, to provide access to the existing US ATM data service for the various ATM stakeholders. However, the discoverability of the services is limited to service-centric information. Therefore, finding services publishing specific ATM data such as airport runway information, en-route flight localization, estimated time of arrival, airport security measures, alternative arrival airport, weather information from a specific airport is cumbersome. This discoverability issue is due to the lack of accessibility to the domain-specific semantics used by the various experts for their search. This information is either buried within the XML schemas, documents such as a Web Service Deployment Descriptor (WSDD) or other documents hidden behind the service Application Programming Interface (API). The aim of this ER is to investigate possible solutions for the development of an "information registry" to extend the discoverability capabilities of NSRR with the following requirements:

  • the information registry should be a searchable catalog of information about the data served by the various web services.

  • it should ease the discoverability process for agents (both humans and machines) by providing access to domain-specific semantics hidden within the various elements of the service description.

  • link service descriptions in NSRR with domain semantics from external semantic models (i.e. controlled vocabularies, thesauri and formal ontologies).

This ER proposes a semantic annotation approach to associate service records in the NSRR with domain-specific semantics from existing external ATM semantic models. The ER does not discuss how to enable semantic information and build domain-specific models but rather to integrate semantic information with the existing descriptions. These two topics are covered in detail in the companion deliverable OGC Testbed-14 Semantically Enabled Aviation Data Models Engineering Report (OGC 18-035) [2].

1.2. Prior-After Comparison

Semantic enablement and enrichment of ATM data has been the focus of several ERs and Components in Testbeds 12 and 13. This work focused on the semantic modeling of service description, the integration of semantic geospatial information (GeoSPARQL) with the service description (OGC 16-039r2) [3], the development of semantic based business rules (SBVR, (OGC 16-061) [4]), semantic models and requirements for semantic service registries (SRIM) (OGC 16-046) [5] as well as a prototype implementation of these models (OGC 16-059) [6] and the DCAT/SRIM extension with a prototype of a semantic registry (OGC 17-040) [7]. Despite all these efforts, little has been done on the definition of ATM specific semantic models and how to associate this domain-specific information with service registries content to enrich the user experience and enhance the quality and ease to retrieve services. In this ER, we are proposing a unique solution to integrate both domain-specific semantics and geospatial semantics together with the content of NSRR without changing both the records and the database.

1.3. Recommendations for Future Work

The following future tasks are recommended:

1.3.1. Recommended Future Tasks

  • Develop domain-specific ontologies as common reference.

  • Transformation of the NSRR repository to become Linked Data conformant

  • Transform the NSRR into a semantic registry

  • Use DCAT-SRIM for structuring NSRR content

  • Enforce the use of DCAT-SRIM and existing ontologies by service providers

  • Develop an ATM Vocabulary registry to publish the various ATM semantic resources.

1.3.2. Recommended Future Deliverables

Recommended Future Components

  • Implementation of an annotation-based Information Registry for NSRR.

  • Creation of an ATM ontology repository and definition of the requirements, design and implementation of an API for controlled vocabulary services that manage ontologies and taxonomies.

Recommended Future Engineering Reports (ER)

  • Design of modular domain-specific ontologies covering at least aeronautical, flight and weather information.

  • Gap analysis to accommodate the specificities of the SWIM data model (SDCM) within the context of the SRIM model [8].

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

This ER describes a simple and efficient solution to associate a structured ATM service description with domain-specific semantics using the W3C Web Annotation data model. This work falls in the scope of both the Geosemantic Domain Working Group (DWG) for the semantic aspect and the Aviation DWG for the thematic aspects. As the solution presented in the ER can be used to integrate semantics (including geospatial semantics) with various types of data coming for various domains of application (intelligence, weather,geology,…​), it should be reviewed mainly by the GeoSemantics DWG.

1.5. Document contributor contact points

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

Contacts

Name Organization

Yann Le Franc (ed.)

e-Science Data Factory

Stephane Fellah

ImageMatters, LLC

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

The following normative documents are referenced in this document.

NOTE: Only normative standards are referenced here, e.g. OGC, ISO or other SDO standards. All other references are listed in the bibliography. Example:

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.

  • Concept

    A concept is an element of a semantic model. This specification makes no assumptions about the nature of concepts, except that they must be identifiable by URIs. A concept can for example be a classifier in some language, a predicate logic relation, the value of the property of an ontology instance, some object instance or set of related instances, an axiom, etc.
SOURCE: https://www.w3.org/TR/sawsdl/

  • Data

    Re-interpretable representation of information in a formalized manner suitable for communication, interpretation, or processing [NOTE Data can be processed by humans or by automatic means.]
SOURCE: ISO/IEC 2382-1:1993, 01.01.02

  • Information

    Knowledge concerning objects, such as facts, events, things, processes, or ideas, including concepts, that within a certain context has a particular meaning
SOURCE: ISO/IEC 2382-1:1993, 01.01.01

  • Information registry

    An enabling infrastructure that stores, catalogs and manages information describing services and the data types they serve.

  • Interoperability

    Capability to communicate, execute programs, or transfer data among various functional units in a manner that requires the user to have little or no knowledge of the unique characteristics of those units.
SOURCE: OGC 17-040

  • Metadata

    Data about data.
SOURCE OGC 17-040

  • Ontology

    A formal specification of concrete or abstract things, and the relationships among them, in a prescribed domain of knowledge [ISO/IEC 19763]
SOURCE: OGC 17-040

  • Service description

    The information needed in order to use, or consider using, a service.
SOURCE OGC 16-039r2

  • Service Description Conceptual Model

    Graphical and lexical representation of the properties, structure, and interrelationships of all service metadata elements.
SOURCE: OGC 16-024r2

  • Semantic Model

    A semantic model is a set of machine-interpretable representations used to model an area of knowledge or some part of the world, including software. Examples of such models are ontologies that embody some community agreement, logic-based representations, etc. Depending upon the framework or language used for modelling, different terminologies exist for denoting the building blocks of semantic models.
SOURCE: https://www.w3.org/TR/sawsdl/

  • Service 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 the resources, as well as query capabilities.
SOURCE OGC 16-039r2

  • Semantics

    Semantics in the scope of this specification refers to sets of concepts identified by annotations. SOURCE: https://www.w3.org/TR/sawsdl/

  • Semantic Annotation

    A semantic annotation in a document is additional information that identifies or defines a concept in a semantic model in order to describe part of that document.
SOURCE: https://www.w3.org/TR/sawsdl/

  • Semantic Interoperability

    The aspect of interoperability that assures that the content is understood in the same way in both systems, including by those humans interacting with the systems in a given context.
SOURCE: OGC 15-054

  • Syntactic interoperability

    The aspect of interoperability that assures that there is technical connection, i.e. that the data can be transferred between systems.
SOURCE: OGC 15-054

  • System Wide Information Management

    Global Air Traffic Management (ATM) industry initiative to harmonize the exchange of Aeronautical, Weather and Flight information for all Airspace Users and Stakeholders.
SOURCE: https://en.wikipedia.org/wiki/System_Wide_Information_Management

3.1. Abbreviated terms

NOTE: The abbreviated terms clause gives a list of the abbreviated terms and the symbols necessary for understanding this document. All symbols should be listed in alphabetical order. Some more frequently used abbreviated terms are provided below as examples.

  • AIXM The Aeronautical Information Exchange Model

  • API Application Program Interface

  • ATM Air Traffic Management

  • DCAT Data Catalogue

  • FAA Federal Aviation Administration

  • FIXM The Flight Information Exchange Model

  • GML Geography Markup Language

  • ICAO International Civil Aviation Organization

  • IR Information Registry

  • NAS National Airspace System

  • NSRR National Airspace System (NAS) Service Registry and Repository

  • OGC Open Geospatial Consortium

  • OWL Web Ontology Language

  • OWL-S Ontology Web Language (OWL)-based Web Service Ontology

  • RDF Resource Description Framework

  • RIM Registry Integration Module

  • SAWSDL Semantic Annotation for Web Service Description Language (WSDL)

  • SCR SWIM Common Registry

  • SDCM Service Description Conceptual Model

  • SKOS Simple Knowledge Organization System

  • SOA Service Oriented Architecture

  • SPARQL SPARQL Protocol and RDF Query Language

  • SRIM Semantic Registry Information Model

  • SWIM System Wide Information Management

  • W3C World Wide Web Consortium

  • WSDD Web Service Description Document

  • WSDL Web Service Description Language

  • WSDOM Web Service Description Ontological Model

  • WXXM The Weather Information Exchange Model

  • XML eXtensible Markup Language

4. Overview

Section 5 provides an introduction to the current state of SWIM service registries and standardized service description documents/models. It also provides an overview of the current challenges and issues, a user perspective and the ground information regarding semantic annotation and semantic resources for aviation.

Section 6 discusses in more detail the meaning of information in context of SWIM and provides an initial description of the different types of information, as well as how to relate the types both together and with the services. Based on this initial information model, the testbed participants investigated information gaps and biases in the current NSRR information model and by analyzing the information coverage of each of the information sources.

Section 7 describes different technical solutions to integrate the missing information using semantic resources.

Section 8 investigates a solution for extending NSRR search capabilities based on the World Wide Web Consortium (W3C) Web Annotation model. It presents the various annotation models for each of the information sources in the NSRR, a short description of the necessary architecture to implement this approach and propose various usage scenarios.

Section 9 provides a short summary and recommendations for future work.

5. Background and Status Quo

SWIM is an interoperability framework to support data exchange and retrieval between distributed, loosely-coupled regional and local ATM services. This framework has been developed in the context of an international collaboration involving FAA and EUROCONTROL (SESAR) to support ATM data access and exchange across national and legal borders. Based on SOA principles, the interoperability framework provides standards for information exchange, infrastructure and governance for ATM data.

A key element of SOA is the service registry which provides a central point of access to the various services that are part of the SWIM framework. In this context, FAA developed the SWIM-enabled NSRR.

Based on Drupal, the NSRR provides the following features:

  • A curated service registration process with lifecycle management

  • A database of service description in standardized format based on the Service Description Conceptual Model (SDCM) data model

  • A programmatic access to service descriptions via a Registry Integration Module (RIM), a dedicated web API [2] [3]

  • A document repository storing the various documents describing the service (pdfs, xml schemas,…​)

  • A search interface to support service retrieval for human operators using hierarchical and faceted search strategies [9] or using document types.

The general architecture is shown in Figure 1

Figure: schematic representation of the NSRR service
Figure 1. schematic representation of the NSRR service

Driven by the effort initiated by NextGen (the FAA program) and SESAR (the European program) several other efforts have emerged with various levels of maturity such as the Brazilian SWIM registry [4] [10]. In order to foster interoperability between the increasing number of service registries, FAA defined a vision of SWIM Inter-Registry Framework [5]. To support interoperability of distributed service registries, a common data model for describing service metadata i.e. information about the service, the SDCM data model has been proposed [6].

The SDCM data model provides a common structure and well-defined semantics for describing ATM services. The current version of the standard is SDCM version 2.0. SDCM2.0 is aligned with the Semantic Markup for Web Services (OWL-S), which is a W3C specification model for describing services shown in Figure 2. Note that although OWL-S was originally submitted to W3C in 2004, it has not progressed into a W3C Recommendation (i.e. W3C standard). OWL-S is still labelled as a W3C Submission (i.e. W3C candidate standard).

Figure 7: OWL-S data model
Figure 2. OWL-S data model

The OWL-S model provides a unique semantic to describe what the service does, how to access it and how it works.

Figure: SDCM 2.0 Service Description
Figure 3. SDCM 2.0 Service Description

The SDCM Service Description is composed of 3 classes corresponding to the main OWL-S classes, as shown in Figure 3:

  • Service Profile

  • Service Model

  • Service Grounding

Additional documents are associated with the standardized service descriptions. Text-documents such as WSDD and Web Service Description Requirements (WSDR) have been defined by FAA to support the registration process. These documents act as structured and documented text templates for providing information about the service to be registered. These documents are used by service providers to enter information into the fields corresponding to the SDCM elements. This textual service description could then be converted into a machine-processable description. The other additional sources of information contained in NSRR are the XML schema used by the different services. These models are used to provide syntactic and structural interoperability and therefore contain information regarding the data served by the service and how to structure the messages.

In addition to service-centric search capabilities, the NSRR has text-based search capabilities building upon the indexation of the additional text documents mentioned previously and tag-based search to categorize services as business products [9]. However, the NSRR has not been designed to leverage search using semantics and external semantic models. Our objective in this ER is to investigate how to use the existing available resources to extend service discovery by human and software agents with semantics. The next chapter discusses the different levels of information for describing a service and investigates existing gaps in the information model within the current NSRR implementation. Thereafter, in the following chapters, the ER investigates various integration models to integrate the missing information.

6. Information Model and Coverage

This section defines a generic information model for describing ATM web services. Using this model, the coverage of the NSRR content is evaluated and the information gaps that prevent a more efficient discoverability are identified.

First, this section starts by defining what is meant by 'information'. In the context of this ER, we consider the ISO definition of data and information i.e. data is a re-interpretable formalized representation of information and information is knowledge concerning objects that within a certain context have a particular meaning.

These definitions can be contrasted with the more recent definitions provided by the Knowledge Modeling community [11, 12]. In this context, data is considered as a meaningless symbol (i.e. a string, a number, a map, an image,…). It can be transformed into information by adding syntactic, structural and semantic elements. The created information is used to provide answers to questions such as Who? What? Where? When? How? [11].

Although different, both sets of definitions underline the contribution of a formalized representation of semantics to provide the meaning of the data element/information.

6.1. An information model to describe ATM web services

In this work, a web service is considered to present 5 main types of information:

  • The administrative information which addresses questions such as who is responsible for the service, what its lifecycle stage, what is the version of the service, which licenses,…

  • The technical information which addresses questions about how to access the data and how the service works (processes)

  • The domain-specific information which addresses questions related to the real-life entities associated with the served data or process. This type of information is composed of three subtypes:

    • The data entity information which addresses questions regarding the quality of the data, the acquisition methods and rates,… and provides also the semantic mapping with real-life entities.

    • The data model information which addresses questions regarding the type of data served by the service i.e. how the different data entities articulate together? This information describes the domain-specific semantic model (i.e. relations between the different data entities).

  • The pragmatic information which addresses questions relating to the usage of the service, its purpose, the type of product,…

This simple information model can be used to categorize the different metadata elements available within NSRR service descriptions and documents. It can be either integrated directly within the SDCM model or used as additional external facets. The next section will use it to identify information gaps and bias within the NSRR information model.

6.2. Information gap analysis

Based on this simple theoretical model, this ER now investigates where the different types of information can be found in NSRR. This analysis will allow us to identify gaps and biases in information coverage within the current NSRR information model.

The administrative information corresponds to the metadata or "data about data" describing the service and how to access it, published by service registries. This information can be accessed as structured information with a common semantic model (SDCM). However, the semantics are embedded within the service description and cannot be leveraged for inference or reasoning. Service descriptions are curated, stored and maintained by the Service Registry provider. This service-centric information is found in the Service Profile section of the SDCM 1.0 and 2.0 data model. It can be extracted from documents such as WSDD and WSDR used in NSRR. Some additional information regarding the data, i.e. the service record, is available as associated keywords within documents such as the OGC common-WS or schemata based on the Geography Markup Language (GML).

The technical information corresponds to the description of the different methods and protocols to access data, messaging system and structure, security handling, Quality-of-Service (QoS), … This information can be found within the Service Descriptions provided by NSRR as instances of the classes "Service Interface" and "Service Implementation" of the SDCM 1.0 data model. In the SDCM 2.0 these classes correspond to the "Model" and "Grounding" classes, in accordance to the OWL-S data model. This information describes the various processes to get the data from the service and/or the various operations that can be performed by services on specific data (e.g. geospatial mapping, overlay, messaging,…).

The domain-specific information corresponds to the description of the data provided by the service i.e. what kind of real-world measurement is provided by the service. This information relies on the semantic representation of ATM concepts used by the different stakeholder. This information is not integrated directly within the SDCM model which covers the service-centric information. The following chapter investigates different solutions to associate this information with the service-centric information.

In the NSRR, the domain-specific information provided by the Service Provider is contained within the interchange data models i.e. the specific XML schemata for example the Aeronautical Information Exchange Model (AIXM), Flight Information Exchange Model (FIXM), and the Weather Information Exchange Model (WXXM). These schemata are used for syntactic and structural interoperability and the information they contain is stored in NSSR as downloadable documents, which prevents the access to the integrated information. Two main categories of information available in these documents can be identified:

  1. data entity information describing the type of data served by the service i.e. the semantic of the data or the link to real-world entities (Estimated Time of Arrival, Flight plan, route, …​ ) as well as information regarding the syntax of data entities i.e. data type (string, int,…) and

  2. data model information regarding the data itself such as which service are consuming and/or updating the data or the relation with other data entities.

These two types of information are related to the domain reference described in OGC 08-167r2 [1]. These domain references or domain vocabularies are semantic models within which complex relations can be expressed (i.e. using OWL-DL and n-ary relations) about the datum and the relations with other data. These models should be defined by the expert community and used as a semantic reference for the different stakeholders. As proposed in OGC 08-167r2 [1], these common models should be used as base elements for defining application specific models. Service providers should be responsible for providing such information to enhance the discoverability of their service.

Finally, the pragmatic information about the usage and the purpose of the data should describe in which case to use this service e.g. a service could have the activity of Flight Planning as its main purpose. This information is provided in the NSRR as a facet i.e. a categorization facet [9]. It should describe the particular business process for which the agent uses the service registry. By adding such a facet, it is possible for the user to find services for a specific business process.

In Table 1, the findings are summarized. This ER proposes association of the type of information with the information source in the NSRR, the coverage of the existing description (complete, partial or none), accessibility of the information (direct access, indirect access, hidden) and the responsible stakeholder.

Table 1. NSSR Information Coverage
Information type Source Coverage Accessibility Responsible stakeholder

Administrative information

SDCM representation – Service Profile WSDD document

Complete

Direct access (API and search interface)

NSRR

Technical information

SDCM representation – Service Model and Service Grounding

Complete

Direct and indirect access

NSRR

Data model information

AIXM, Web Feature Service (WFS), Web Map Service (WMS), FIXM, WXXM,… - Service developer

Partial

Indirect access and hidden

NSRR

Data entity information

AIXM, WFS, WMS, FIXM, WXXM,… - Service developer

Partial

Indirect access and hidden

Service provider

Pragmatic information

NSRR index

Partial

Direct access via the search interface

NSRR curators

As expected, the information currently available within the NSRR fully covers the functional information of web services i.e. administrative and technical information. The domain-specific information regarding the data entities and models served by the various services is currently within the database but is not accessible for extending the service discoverability. In the current situation, users can efficiently retrieve services using queries based on the administrative and technical information such as follows:

  • Which service provides gridded weather information?

  • Which service provides data validation for the flight plan?

  • What is the version of the service?

  • Which validated service provides Notice-to-Airmen (NOTAM) data?

  • Which service is provided by FAA?

  • What is the lifecycle stage of a particular service?

  • Which service provide Java Messaging Interface?

Despite the importance of this information for the usage of the service, access to data or operations on the data, the different stakeholders will first search for services matching their business need based on domain concepts representing real-world measurements or information. To illustrate this, the following potential queries formulated by service registry users are considered:

  • Which service provides runway true bearing information from East Cost airports ?

  • Which service provides wind measurement at Washington Dulles Airport (FAA airport code: IAD)?

  • Which service provides aeronautical information for flight planning and uses JMS?

A quick analysis of the queries shows that the different of types of information defined in our initial information model are aggregated (domain-specific information, administrative and technical information) as shown in Figure 4'.

Queries
Figure 4. The different information types within queries

By extending and refining the various types of queries that a user would need in order to achieve some specific activity (e.g. pre-flight bulletin publication, flight planning, flight plan validation, flight plan update,…​), it should be able to refine the information content of the registry.

The main information gap identified in the current registry is related to the thematic or domain-specific information. This information includes the semantics describing the specific domain information e.g. departure airport, alternate airport, runway true bearing,en-route flight information, weather information, … but also a semantic model relating these different types of information together. This information relates to the domain expertise of the user to retrieve services offering the needed domain-specific information. The next chapter presents the different possible solutions to associate these different levels of information together to enhance the user experience by enabling queries such as the examples provided above.

7. Integrating domain-specific information

The various documents and existing data models used to describe ATM web services provide contextual information about the service, as well as information about how to access and involve the service in retrieving ATM data. They provide an interoperability layer describing the operation and the format to encode the data i.e. covering only the functional dimension of the Web services. But they lack a methodology to describe the thematic dimension of the web services i.e. what the served data or process represent.

To support our research work, the fictitious Flight Planning Service provided by the NSRR was used to build our examples. This fictitious service has been designed for training and demonstration purposes. It is one of the services registered in the NSRR (see Figure 5).

Figure: FPS Service Profile in NSRR
Figure 5. FPS Service Profile in NSRR

In the NSRR database, the service is registered and identified with a GRID : http://nsrr.faa.gov/services/fps. Service record information are identified by a specific Uniform Resource Identifier (URI) pointing to the service profile resource.

From this landing page, it is possible for a human agent to access a variety of information regarding the service, supported by the SDCM model briefly described in chapter 5 and more extensively described in (OGC 18-035) [2].

The FPS service provides several types of documents extending the initial service description as shown in Figure 6.

Figure: FPS service additional documentation
Figure 6. FPS service additional documentation

These documents include the FAA WSDD and WSDR documents, a word document including the UML diagram of the data model underlying the service, a word document containing a table describing a subset of the data elements provided by the service and 2 XML documents, the WSDL description of the service and the XML schema defining the data elements provided by the service.

In addition to these sources of information, the FPS service profile can be accessed programmatically through the RIM API as shown by the Service Profile snippet provided below in section 7.2.1. The complete service description can be found in Annex A.

7.1. Using Semantic Annotations

7.1.1. General principles

To extend the existing descriptions with a thematic dimension which will be used by users to discover the services, it is necessary to consider how to link the service descriptions with external models. These external models comprise conceptualized knowledge about the represented ATM operations or information.

Linking the service description with these ATM knowledge models will allow reasoning algorithms to be able to infer if the web services match the user information need.

A proposal for such integration has already been made in the “Semantic Annotation in OGC standards” document (OGC 08-167r2) [1].

In this proposal, the authors have identified three levels of annotations for OGC compliant web services:

  • Level 1: Service metadata contained in WFS, WMS, and Capabilities documents of other OGC Web Services (OWS)

  • Level 2: Data model provided by GML-based schemata

  • Level 3: Data entity

In order to link the different levels of information together with external Knowledge Models (i.e. thesauri, ontologies, controlled vocabularies, code lists, …), they are proposing different mechanisms of integration that we will be considering in the next sections.

In particular they introduce the concept of resource ontology as a means to describe the inter-relationship between the different elements specific to a particular service i.e. an application specific ontology describing the served data model but building upon common elements coming from global and accessible domain ontologies.

7.1.2. Why using thesauri, controlled vocabulary or ontologies?

Controlled vocabularies, thesauri, and ontologies are conceptual models of the real-world defined by humans in a machine processable format. These semantic models are used to build a common understanding between humans and machines and also reach consensus between domain experts. These models need to address the various semantic heterogeneities such as synonymy, homonymy and polysemy to allow machines to disambiguate the data, provide hierarchical information to organize the various concepts and support multi-lingual communities. Such resources can be built using W3C standards such as RDF, OWL or SKOS depending on the complexity of the model. For an overview of these standards and their usage refer to [OGC 18-035] [2]. These models enable machines to make inferences on the data thereby retrieving information more relevant to humans. As we argued in the previous chapter, the domain-specific information is the missing element to achieve semantic interoperability and improve service discovery. The following section investigates the existing domain-specific semantic resource which could be used to extend the NSRR’s Semantic interoperability.

7.1.3. Existing ATM semantic resources

In order to foster semantic interoperability of the service descriptions and of service categorization, the FAA has developed several semantic resources including various SKOS based thesauri describing generic types such as the type of SWIM Service products, the Service Availability Status, Service Interface types, Flight Phase, and various classifications of US ATM information (ICAO regions, US airways, US Flight Information Region and Airspace Classes). These semantic resources are available on the semantic aero website (https://semantics.aero/). In addition to these thesauri, FAA also developed different semantic resources to describe the registered services in NSRR i.e. the SWIM Controlled Vocabulary and Web Service Description Ontological Model (WSDOM). The latter corresponds to an OWL serialization of the SDCM data model. The current version of WSDOM is aligned with the SDCM1.0 data model. Efforts to update the WSDOM ontology to the new SDCM version are under way.

Unfortunately, these resources offer little coverage for domain-specific concepts such as airport runways, runway true bearing, and so on. Currently little effort has been dedicated to building domain-specific ontologies for ATM concepts except for the proof-of-concept ATM ontology proposed by NASA (NASA Atmonto, https://data.nasa.gov/ontologies/atmonto/index.html) and mainly based on concepts from AIXM. As previously discussed, these domain-specific ontologies will deeply contribute to the improvement of service discoverability in NSRR.

This ER focuses on usage of these resources to enrich the current NSRR content. Further details regarding these different resources are provided in [OGC 18-035] [2]. The following section proposes practical solutions for integrating domain-specific semantics with little modifications to the current NSRR registry.

7.2. Semantic Annotation and the SDCM model

SDCM is based on the OWL-S model. The three classes composing this model describe what the service does (service profile), how to access it (service model) and how it works (service grounding). The Service Profile mainly contains administrative information (provider’s information, function, security, …) as shown in Figure 7.

The Service Model (Figure 8) and the Service Grounding classes provide technical information about the interfaces and the connection protocols to the service.

7.2.1. Integration within the Service Profile class

As in OWL-S, SDCM data model provides ways to associate the service description with categorization information defined in taxonomies (Figure 7).

Figure 3: SDCM2.0 Service Profile
Figure 7. SDCM2.0 Service Profile

Domain-specific information describing the type of data served by the services could be integrated within the service profile class which provides generic information. For this purpose, the information could be provided within the “Service Category” attribute associated with the service profile. This attribute would thus contain references to concepts from external ontologies or thesauri developed by FAA and other ATM stakeholders. The reference to the model should be a resolvable URI allowing access to the full knowledge model and specific information about the concept within the context of the knowledge model i.e. subclass, superclass or relations.

In OWL-S, specific placeholders have been defined to add categorization facets to service description corresponding to generic facets or to product types. These placeholders are of two types:

  • attributes of the profile i.e. in this context datatype properties or

  • dedicated class named ServiceCategory.

Attribute of the profile are described in Table 2.

Table 2. Profile attribute in OWL-S (from OWL-S specification)
Attribute name description

serviceClassification

defines a mapping from a Profile to an OWL ontology of services, such as an OWL specification of NAICS.

serviceProduct

defines a mapping from a Profile to an OWL ontology of products, such as an OWL specification of UNSPCS.

These properties are used to link the service description with external knowledge models (i.e. ontologies, taxonomies, controlled vocabularies, thesauri,…​) describing the type of service and the type of products served by the service. The type of value for these properties are either XML Schema Definitions (XSD) links or URIs corresponding to instances of classes specified in OWL ontologies of services and products. These two properties are similar to serviceCategory described above, but they differ in that the values of the properties are OWL instances rather than strings referring to non-OWL business taxonomies.

The ServiceCategory class describes categories of services on the basis of external semantic models. The ServiceCategory class has 4 different attributes described in Table 3.

Table 3. OWL-S ServiceCategory (from OWL-S specification)
Attribute name Description

categoryName

is the name of the actual category, which could be just a literal, or perhaps the URI of the process parameter (a property).

taxonomy

stores a reference to the taxonomy scheme. It can be either a URI of the taxonomy, or a URL where the taxonomy resides, or the name of the taxonomy or anything else.

value

points to the value in a specific taxonomy There may be more than one value for each taxonomy, so no restriction is added here.

code

to each type of service stores the code associated to a taxonomy.

In SDCM2.0, a similar structure has been considered in which the Service profile has a specific attribute pointing to a taxonomy/ontology element and an abstract class. The descriptions of these elements in the SDCM specification are listed in Table 4 and Table 5.

Table 4. Profile Attributes in SDCM2.0 (from SDCM 2.0 specification)
Name Definition Notes

service category

A classification of the service that could be based on various criteria; e.g., type of service provided, technological or architectural solutions, etc. (see Service Category class)

Service categories are described as taxonomies, usually established by the implementing organization
Table 5. ServiceCategory in SDCM2.0 (from SDCM 2.0 specification)
Definition Notes Prototype

A taxonomy used to classify a service by the type of service provided or by some other technological or architectural solution.

The Service Category class is a placeholder for one or more taxonomies. Because of ongoing efforts to either update existing or create new service categorization taxonomies, this class is defined as an abstract class.

Taxonomy

This approach has already been used to integrate categorization based on SWIM service product and service category, as well as referring to the following taxonomies created by FAA as shown in the snippet of the RIM service description for the Flight Plan Service.

FPS Service Profile snippet
<ServiceDescription xmlns="http://swim.aero/rim/1.0.0">
    <Profile>
        <ServiceName>Flight Plan Service (FPS)</ServiceName>
        <ServiceVersion>1.0.0</ServiceVersion>
        <ServiceDescription>(This fictitious service is for instructional use only and cannot be consumed).
        A service for filing, updating, or canceling an IFR (Instrument Flight Rules) flight plan.
        </ServiceDescription>
        <sd:Categories xmlns:sd="http://swim.aero/rim/1.0.0">
            <sd:Category>
                <sd:Title>ATM Service Category</sd:Title>
                <sd:Value>Flight Planning</sd:Value>
            </sd:Category>
            <sd:Category>
                <sd:Title>SWIM Service Product Category</sd:Title>
                <sd:Value>Flight</sd:Value>
            </sd:Category>
            <sd:Category>
                <sd:Title>Lifecycle Status</sd:Title>
                <rim:Value xmlns:rim="http://swim.aero/rim/1.0.0">Development</rim:Value>
            </sd:Category>
        </sd:Categories>
        <Provider>
       …

In this example, three different facets are used to categorize the service: the ATM service Category, the SWIM Service Product Category and the LifeCycle Status. Two of these categories refer to taxonomies published in http://semantic.aero although the reference in this example is not direct.

It is important to note here that there is still a discrepancy between the categories format presented here and the SDCM2.0 schema used to structure the category complex type. In the SDCM2.0 schema, Service Category is aligned with the OWL-S ServiceCategory class and includes the 4 properties described in Table 3. While in the example used here, the ServiceCategory is typed with a static element (<title>) and points to a value which is a human readable label (similar to the value of <rdfs:label/>) within an ontology. Work for further alignment with the SDCM2.0 model is in progress and should include a URI as pointer to the element of the semantic resource.

The scope of the ServiceCategory class could be extended by the integration of the semantic representation of the data elements published by the service i.e. domain-specific semantics. In this case, the value definition should be extended to allow holding a list of URIs. The following example could be considered, where elements of the FPS schema are aligned with concepts coming from the NASA ontology and added as a list of values. In this case, the complexType “AircraftType” and “WakeTurbulenceCategory” are being considered. The integration of these concepts is shown in the following code snippet.

FPS Service Profile annotated: Adding domain-specific information
<ServiceDescription xmlns="http://swim.aero/rim/1.0.0">
    <Profile>
        <ServiceName>Flight Plan Service (FPS)</ServiceName>
        <ServiceVersion>1.0.0</ServiceVersion>
        <ServiceDescription>(This fictitious service is for instructional use only and cannot be consumed) A service for filing, updating, or canceling an IFR (Instrument Flight Rules) flight plan.
</ServiceDescription>
        <sd:Categories xmlns:sd="http://swim.aero/rim/1.0.0">
            <sd:Category>
                <sd:Title>ATM Service Category</sd:Title>
                <sd:Value>Flight Planning</sd:Value>
            </sd:Category>
            <sd:Category>
                <sd:Title>SWIM Service Product Category</sd:Title>
                <sd:Value>Flight</sd:Value>
            </sd:Category>
            <sd:Category>
                <sd:Title>Lifecycle Status</sd:Title>
                <rim:Value xmlns:rim="http://swim.aero/rim/1.0.0">Development</rim:Value>
            </sd:Category>
            <sd:Category>
                <sd:Title>Domain specific information</sd:Title>
                <sd:Value> https://data.nasa.gov/ontologies/atmonto/equipment#AircraftType </sd:Value> (1)
                <sd:Value> https://data.nasa.gov/ontologies/atmonto/equipment#AircraftWakeCategory </sd:Value> (2)
            </sd:Category>
        </sd:Categories>
        <Provider>
       …

  1. Annotation with the concept "AircraftType" defined in the atmonto ontology developed by NASA.

  2. Annotation with the concept "AircraftWakeCategory" defined in the atmonto ontology developed by NASA.

It is important to note here that the scope of the NASA ATM ontology covers mostly concepts from AIXM. In order to fully