1. Introduction

The Open Geospatial Consortium (OGC®) is releasing this Call for Participation ("CFP") to solicit proposals for the OGC Testbed-16 (also called "Initiative" or just "Testbed"). The goal of the initiative is to evaluate the maturity of the Earth Observation Cloud Architecture that has been developed over the last two years as part of various OGC Innovation Program (IP) initiatives in a real world environment.

logo

1.1. Background

The OGC Testbed is an annual research and development program that explores geospatial technology from various angles. It takes the OGC Baseline into account, though at the same time allows to explore selected aspects with a fresh pair of eyes. The Testbeds integrate requirements and ideas from a group of sponsors, which allows leveraging symbiotic effects and makes the overall initiative more attractive to both participants and sponsoring organizations.

1.2. OGC Innovation Program Initiative

This Initiative is being conducted under the OGC Innovation Program. The OGC Innovation Program provides a collaborative agile process for solving geospatial challenges. Organizations (sponsors and technology implementers) come together to solve problems, produce prototypes, develop demonstrations, provide best practices, and advance the future of standards. Since 1999 more than 100 initiatives have taken place.

1.3. Benefits of Participation

This initiative provides an outstanding opportunity to engage with the latest research on geospatial system design, concept development, and rapid prototyping. The initiative provides a business opportunity for stakeholders to mutually define, refine, and evolve service interfaces and protocols in the context of hands-on experience and feedback. The outcomes are expected to shape the future of geospatial software development and data publication. The Sponsors are supporting this vision with cost-sharing funds to partially offset the costs associated with development, engineering, and demonstration of these outcomes. This offers selected Participants a unique opportunity to recoup a portion of their initiative expenses.

1.4. Master Schedule

The following table details the major Initiative milestones and events. Dates are subject to change.

Table 1. Master schedule
Milestone Date  Event

M01

23 December 2019

Release of Call for Participation (CFP)

M02

21 January 2020

Questions for CFP Bidders Q&A Webinar Due

M03

28 January 2020

CFP Bidders Q&A Webinar. Register at https://attendee.gotowebinar.com/register/5009861363812363533. The Webinar starts at 10am EST.

M04

09 February 2020

CFP Proposal Submission Deadline (11:59pm U.S. Pacific Time)

M05

31 March

All CFP Participation Agreements Signed

M06

6-8 April

Kickoff Workshop at US Geological Survey (USGS) National Center, 12201 Sunrise Valley Drive, Reston, Virginia 20192 (https://www2.usgs.gov/visitors/).

M07

31 May

Initial Engineering Reports (IERs)

M08

June

Interim Workshop at TC Meeting Montreal, Canada. Participation not mandatory but appreciated.

M09

30 September

TIE-Tested Component Implementations completed; Preliminary DERs complete & clean, ready for internal reviews

M10

31 October

Ad hoc TIE demonstrations (as requested during the month) & Demo Assets posted to Portal; Near-Final DERs posted to Pending & WG review requested

M11

November (specific date TBD)

Final DERs (incorporating WG feedback) posted to Pending to support WG & TC vote

M12

December (specific date TBD)

Final demonstration at TC meeting

M13

15 December

Participant Final Summary Reports due

2. Technical Architecture

This section provides the technical architecture and identifies all requirements and corresponding work items. It references the OGC standards baseline, i.e. the complete set of member approved Abstract Specifications, Standards including Profiles and Extensions, and Community Standards where necessary. Further information on the OGC standards baseline can be found online.

Note

Please note that some documents referenced below may not have been released to the public yet. These reports require a login to the OGC portal. If you don’t have a login, please contact OGC at techdesk@opengeospatial.org.

Testbed Threads

The Testbed is organized in a number of threads. Each thread combines a number of tasks that are further defined in the following chapters. The threads integrate both an architectural and a thematic view, which allows to keep related work items closely together and to remove dependencies across threads.

threads
Figure 1. Testbed Threads

The threads include the following tasks

2.1. Aviation

The goals of the Aviation task in Testbed-16 are: to evaluate emerging architectural and technological solutions for the FAA SWIM services, and to advance further the usage of Linked data in information integration in the SWIM context.

The API modernization work shall evaluate solutions for data distribution that complement those currently used by FAA SWIM. Particular emphasis in this context shall be on OpenAPI-based Web APIs. OGC is busy developing Web APIs for the various geospatial resource types such as features, coverages, maps, tiles, and processes among others. There are many documented benefits for using Web APIs in the context of geospatial data retrieval and processing, including faster time to market for products, more flexibility in deployment models, and straight forward upgrade paths as standards evolve.

aviationAirplane

The linked data aspect shall explore the use and benefit of semantic web technologies in the context of FAA SWIM services. Linked data shall help querying and accessing all required data for any given task and help with the heterogeneous semantics introduced by the various ontologies and taxonomies used within the aviation community. These include for example the SWIM Controlled Vocabulary (SWIM CV), the Web Service Description Ontological Model (WSDOM), or semantics.aero.

Background

The System-Wide Information Management (SWIM) program, established and maintained by the FAA, supports the sharing of Air Trafic Management (ATM) 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 to access their data. For the FAA, these services are published in the NAS Services Registry/Repository (NSRR). NSSR is a catalog of all SWIM services and provides documentation on various aspects of each service, including its provider, functionality, quality characteristics, interface, and implementation.

One of the SWIM challenges is the handling of semantics across all participants. A diverse set of ontologies, controlled vocabularies, and taxonomies has been developed over the last decade. A good overview is provided in OGC 18-035.

The SWIM Controlled Vocabulary (SWIM CV) provides to SWIM organizations, support contractors, vendors, and business partners a uniform understanding of terms employed in the SWIM environment. The CV contains a comprehensive list of terms with clear and unambiguous definitions. Each term is globally uniquely identified by a dereferenceable URI so that it can be related semantically to other terms, vocabularies, or resources. SWIM CV is now part of semantics.aero.

semantics.aero is an open repository for use by the international aviation community to publish artifacts developed using Semantic Web technologies. Besides the SWIM CV, artifacts include taxonomies for classifying services by product type, availability, flight phase, ICAO region, etc. and are available in both human-readable (HTML) and machine-readable (RDF) versions.

The Web Service Description Ontological Model (WSDOM) is an ontology intended to be a basis for model-driven implementation of SOA-related artifacts. The ontology has been developed in Web Ontology Language (OWL) version 1.1; it consists of several files and is currently available in a single downloadable zip file. WSDOM can be considered an "RDF" realization of the Service Description Conceptual Model (SDCM). WSDOM standardizes information and metadata pertinent to describing SWIM services and facilitates interchange of service data between service providers and the FAA. The intent behind the ontology is to make service definitions clear, unambiguous, and discoverable by both humans and computer systems. WSDOM consists of ontology classes covering the key notions of service profile, service interface, service implementation, stakeholder, and document. WSDOM is patterned after the OWL-S semantic web services description ontology.

WSDOM was developed before SDCM and was written in OWL. For many people in the industry, OWL ontology was too technical to be understood by a large audience. To address this gap and make the service description more "readable", the Service Description Conceptual Model was created. That said, SDCM 2.0 is more recent than WSDOM 1.0, and therefore better reflects the current NSRR data structure. WSDOM 2.0 is currently being developed and not been aligned yet with the latest version of SDCM.

2.1.1. Problem Statement and Research Questions

FAA has invested in setting up SWIM Feeds that are accessible on a feed by feed basis. Each feed was designed as stand-alone. However, the value of data increases when it’s combined with other data. In addition, real-world situations are often not related one to one with a SWIM feed (or a single data source for that matter). Therefore, Testbed-16 shall investigate data integration options based on semantic web technologies and analyze the current status of achievable interoperability. The latter is the basis for analytics, querying and visualization of data coming from distributed sources.

Research questions:

  1. Should the existing SWIM architecture be modernized with resource-oriented Web APIs?

  2. What role can OGC Web APIs play for a modernized SWIM services?

  3. How can OGC APIs be used to address the heterogeneous semantic SWIM landscape?

  4. What impact have linked data principles and requirements on OGC Web APIs?

  5. How to deal with the various ontologies and taxonomies used in SWIM?

  6. How to best enhance the various ontologies and how to build a scalable geospatial definition server?

  7. How to best combine data from various SWIM data feeds to make it available for multi-source and linked data based analytics?

2.1.2. Aim

This Testbed-16 task aims at a better understanding on the value of modern Web APIs in the context of SWIM service integration and the potential of semantic web technologies to solve complex queries.

2.1.3. Previous Work

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

Testbed-14 formulated an approach to semantic-enable the different data models, taxonomy and service description that can incorporate semantic metadata. These metadata includes descriptive metadata, geospatial-temporal characteristics, quality information, and fitness-of-use information about services and data. This additional metadata enables the integration of information and services, improves search and discovery, and increases the level of possible automation (e.g. by reasoning or access and processing by agents).

Aviation activities have been part of several initiatives in the past. The following list provides an overview. Links to the relevant Engineering Reports are provided further below.

  1. Testbed-15

    1. OGC Testbed-15: Semantic Web Link Builder and Triple Generator

  2. Testbed-14:

    1. SWIM Information Registry

    2. Semantically Enabled Aviation Data Models

  3. Testbed-13:

    1. Aviation Abstract Quality Model - Data Quality Specification

    2. Quality Assessment Service

    3. Geospatial Taxonomies

  4. Testbed-12:

    1. Aviation Semantics

    2. Catalog Services for Aviation

The following Engineering Reports are relevant in the context of this task.

  • OGC 18-022r1, OGC Testbed-14: SWIM Information Registry Engineering Report

  • OGC 18-035, OGC Testbed 14: Semantically Enabled Aviation Data Models Engineering Report

  • OGC 17-036, OGC Testbed-13: Geospatial Taxonomies Engineering Report

  • OGC 17-032r2, OGC Testbed-13: Aviation Abstract Quality Model Engineering Report

  • OGC 16-018, OGC Testbed-12: Aviation Architecture Engineering Report

  • OGC 16-024r2, OGC Testbed-12: Catalog Services for Aviation Engineering Report

  • OGC 16-028r1, OGC Testbed-12: FIXM GML Engineering Report

  • OGC 16-039r2, OGC Testbed-12 Aviation Semantics Engineering Report

  • OGC 16-061, OGC Testbed-12 Aviation SBVR Engineering Report

Reports that addressed linked data and semantic web technologies include:

  • OGC 19-021, OGC Testbed-15: Semantic Web Link Builder and Triple Generator (draft version available on OGC portal or upon request)

  • 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-018, OGC Testbed-13: Data Quality Specification Engineering Report

  • OGC 16-046r1, OGC Testbed-12 Semantic Enablement Engineering Report

2.1.4. Scenario & Requirements

Figure 2 illustrates the current SWIM situation. A number of services are available that use different taxonomies, vocabularies, and ontologies. SWIM services are described in the service registry. All services are built on the Service Oriented Architecture (SOA).

aviationCurrent
Figure 2. Aviation scenario, current situation

The current situation illustrated above shall be explored along two axes. First, the value and role of Web APIs and here more specifically OGC APIs for SWIM. Second, the handling of semantics and integration of data from various services, as illustrated in Figure 3.