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

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

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

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

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

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

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

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

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

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

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

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

Figure 6 elaborates on the representation for the flight plan (atm:PlannedRouteAAL335-201407150017) shown at the root of this tree and also in Figure 5. The flight plan includes a flight route string ‘KLGA./.CFB..RAAKK.Q436.EMMMA.WYNDE5.KORD’, which is a representation of the path to be flown through the airspace. The flight route string is initially filed by the pilot prior to takeoff and modified as needed en route. The root node in the graph contains this route string as a property, but the string is also converted into an explicit sequence of ‘container’ nodes that include (via the property atm:hasNavElement) the major navigational components through which the flight is planned to progress: the originating airport (KLGA); a VOR fix (CFB); a portion of a high-altitude flight route (Q436); a traverse through a standard terminal arrival route (STAR WYNDE5); and the destination airport (KORD).

System Wide Information Management (SWIM) is a data distribution framework started by FAA and EUROCONTROL and adopted by ICAO. The goal of the framework is to standardize mechanisms for delivery of ATM data between producers and consumers using a subscription-based Service-Oriented Architecture (SOA). 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.

As part of this effort, FAA SWIM Program and the Single European Sky Air Traffic Management (ATM) Research Programme (SESAR) Joint Undertaking (SJU) have developed a conceptual model describing services semantically called Service Description Conceptual Model (SDCM) [4] [17].

SDCM provides a graphical and lexical representation of the properties, structure, and interrelationships of all service metadata elements, collectively known as a Service Description. The objectives of the SDCM are:

The SDM adheres to the following design principles:

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) (Figure 7).

The Service Profile contains mainly metadata information (provider’s information, function, quality of service, security, …) that are needed for search and discovery (Figure 8). This is part of the service description that is highly relevant for registration of services and to enable semantic search and discovery of services. In this ER, we show how the profile information can be used by a semantic registry by providing the alignment of service profile to semantic registry model. ServiceProfile class provides a good extension point. This class acts as container for the most relevant metadata, such as service functions and real-world effects, quality of service, security parameters, service providers and consumers. The service profile class can be enriched with additional classes, properties and individuals to accommodate the specific needs for search and discovery of services in a semantic registry. Individuals of "ServiceProfile" type can contain one or many properties depicting the concept of "Service function" associated with "real-world effects". In order to extend the ontology to provide controlled vocabulary (values) for these concepts, domain experts need to define taxonomy of business functions and real world effects based on aviation traffic (management) domain needs.

The SDCM Model describes to a service requester how to construct an invocation message and interpret a response message (img_sdcm_model). This part of the model is mostly technical and is used by a software agent to communicate with the service.

The SDCM grounding describes the means by which the service is invoked, including the underlying technology protocols and network locations of the service (Figure 10). This part is very technical and is usually leveraged by software agents to communicate with the service.

The Web Service Description Ontological Model (WSDOM) [18] can be considered an "RDF" realization of the SDCM conceptual model. 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.

The WSDOM ontology was designed based on the OWL-S service ontology and considering the service taxonomies used by FAA. The WSDOM 1.1 release consists of six OWL files and three RDF files. The three RDF files provide ontological representation of FAA standard taxonomies.

The structure follows the OWL-S model defining the Service ontology as being the top level ontology with three related classes: ServiceProfile (maps to OWL-S ServiceProfile), ServiceInterface (maps to OWL-S ServiceModel) and ServiceImplementation (maps to OWL-S ServiceGrounding) (Figure 11).

The ServiceProfile presents metadata about the service. This information is highly relevant for search of services and information. Figure 12 shows the information of the service profile that can be leveraged in a semantic registry.

ServiceInterface (maps to OWL-S ServiceModel) and ServiceImplementation (maps to OWL-S ServiceGrounding) describe how to access the service (its API and endpoints). This information is relevant when access to the service needs to be automated (Figure 13).

FAA has developed a controlled vocabulary (CV), based on the Simple Knowledge Organization System (SKOS), that provides a single source for terms and definitions used in SWIM-related documentation [19]. SKOS (Simple Knowledge Organization System) is a W3C standardized RDF ontology for representing controlled vocabularies, thesauri, and taxonomies. The SWIM CV includes textual definitions of SWIM-related terms and their connections to broader, narrower, and otherwise related terms within the CV. SWIM documentation and web pages can reference term definitions in the CV using resolvable Universal Resource Identifiers (URIs).

Table 1 describes the list of taxonomies currently used by SWIM. These taxonomies were developed during previous OGC testbeds.

The concepts of these taxonomies are encoded directly as skos:Concept, making it difficult to distinguish what category of concepts (ServiceProduct, ICAORegion, etc.) they denote. The next section addresses this gap in relation to controlled vocabularies (see also The role of Controlled Vocabularies).

Without addressing these issues in the metadata standards, interoperability at the semantic level will not be achieved. Fortunately, there are ongoing efforts using Linked Data standards to semantically describe metadata about datasets, that are addressing these gaps (DCAT, Project Open Data, GeoDCAT-AP and OGC SRIM). The US Government has enforced the use of Project Open Data for all US agencies and the European Union has enforced the use of DCAT to describe metadata about datasets used by the different EU members. The policies have proven to be successful and have been adopted rapidly by the different agencies. For example, the European Data Portal is implementing the DCAT-AP as the common vocabulary for harmonizing descriptions of over 258,000 datasets harvested from 67 data portals of 34 countries.

DCAT is an RDF vocabulary designed to facilitate interoperability between data catalogs published on the Web. By using DCAT to describe datasets in data catalogs, publishers increase discoverability and enable their applications to easily consume metadata from multiple catalogs. It further enables decentralized publishing of catalogs and facilitates federated dataset search across sites. Aggregated DCAT metadata can serve as a manifest file to facilitate digital preservation. Figure 14 illustrates defines core DCAT model.

DCAT is highly relevant for NAS as it provides a set of core classes and properties to describe datasets. To accommodate the specificities for specific domains, application profiles for DCAT have been emerging over time (DCAT-AP,GeoDCAT-AP, StatDCAT-AP, DCAT-AP-NO,DCAT-AP-IT,DCAT-AP.de,TransportDCAT-AP, EPOS-DCAT-AP,POD). Typically, application profiles for DCAT are defined by reusing existing classes and properties from different ontologies and assigning them an obligation level defined as mandatory, recommended or optional. The following subsections document the application profiles that are the most relevant for the NAS.

The DCAT Application profile for data portals in Europe (DCAT-AP) is a specification based on the Data Catalogue vocabulary (DCAT) for describing public sector datasets in Europe. Its basic use case is to enable cross-data portal search for data sets and to allow public sector data to be easily searchable across borders and sectors. This can be achieved by the exchange of descriptions of datasets among data portals.

In February 2015, the ISA² programme of the European Commission has started an activity to revise the DCAT-AP, based on experience gained since its development in 2013. The outcome of this effort was the publication of DCAT-AP 1.1.

The European Data Portal is implementing the DCAT-AP as the common vocabulary for harmonizing descriptions of over 258,000 datasets harvested from 67 data portals from 34 countries. The DCAT-AP is used in the Open Data Support service initiated by the European Commission with the purpose of realizing the vision of European data portals.

ADMS is a profile of DCAT that is used to describe semantic assets (or just 'Assets'). These assets are defined as highly reusable metadata (e.g. xml schemata, generic data models) and reference data (e.g. code lists, taxonomies, dictionaries, vocabularies) that are used for eGovernment system development.

The ADMS model is intended to facilitate federation and co-operation. Like DCAT, ADMS has the concepts of a repository (catalog), assets within the repository that are often conceptual in nature, and accessible realizations of those assets, known as distributions. An asset may have zero or multiple distributions. As an example, a W3C namespace document can be considered to be a Semantic Asset that is typically available in multiple distributions, one or more machine processable versions and one in HTML for human consumption. An asset without any distributions is effectively a concept with no tangible realization, such as a planned output of a working group that has not yet been drafted.

ADMS is an RDF vocabulary with an RDF schema available at its namespace http://www.w3.org/ns/adms . The original ADMS specification published by the European Commission [ADMS1] includes an XML schema that also defines all of the controlled vocabularies and cardinality constraints associated with the original document. The model is shown in Figure 15.

This model is relevant for the SWIM architecture as the current registry contains information about schemas and service definitions (such as WSDL document). ADMS provides a set of terms that could be used to better describe the metadata information about these type of assets.

Project Open Data [21] provides the implementation guide and associated resources for the Federal Executive Order on open data and data management, M-13-13 “Managing Information as an Asset,” which includes the standardized metadata schema that all CFO Act agencies are required to use to publish their enterprise data inventories.

The Project Open Data Metadata Schema is a JSON-based implementation of the W3C DCAT vocabulary. This standard is currently implemented by multiple data catalog platforms as well as state and local governments. POD is based on the DCAT model but it enforces the encoding in JSON-LD. POD defines a JSON-LD context to map the JSON document back to Linked data representation.

The POD Model is shown in Figure 16

Typically, POD documents are published in a Web Accessible Folder (WOF) and harvested by catalogs such as data.gov. The intent of POD is to lower the bar of complexity needed to represent data information by providing guidelines and recommended metadata. This improves search and discovery for datasets within the US government.

Below is an example of a POD dataset published by FAA on data.gov (which can be found at: https://catalog.data.gov/dataset/flight-schedule-monitor)

While POD is a huge step toward enabling search and discovery of datasets and facilitates the integration with existing tools, it falls short of addressing geospatial aspects of datasets (which SRIM and GeoDCAT address). It also does not provide good guidance of the use of controlled vocabularies due to the lack of policies and solutions to manage and access controlled vocabularies (a section of this ER is dedicated on this issue). There is also no standard in place to describe services in detail. It is currently restricted to simple accessURL in dcat:Distribution.

GeoDCAT-AP is defined as an extension of DCAT-AP for describing geospatial datasets, dataset series, and services. It provides an RDF syntax binding for the union of metadata elements defined in the core profile of ISO 19115:2003 and those defined in the framework of the INSPIRE Directive. Its basic use case is to make spatial datasets, data series, and services searchable on general data portals, thereby making geospatial information more searchable across borders and sectors. This can be achieved by the exchange of descriptions of datasets among data portals. GeoDCAT-AP has been submitted to OGC as a candidate for standardization of geospatial metadata using Linked Data standards.

During OGC Testbed-12, a number of metadata specifications were reviewed, including the W3C standard DCAT, DCAT-AP, GeoDCAT-AP, ADMS, Project Open Data 1.1, Dublin Core, ISO 19115, and ISO 19119 to identify the common and relevant metadata information needed for search and discovery, but also to identify the gaps to address the requirements to describe dataset, service, portrayal information, schema and schema mapping, vocabularies and other future asset types. It quickly emerged that the DCAT standard and its different application profiles were data-centric and insufficient to describe metadata for portrayal information, schemas and services. The goal was not to define a new standard, but to leverage existing standards to define an application profile of DCAT that could accommodate the schema, service, portrayal and other asset type information needed to enable relevant search and discovery and filling the gaps by introducing additional properties and fields, all while preserving backward compatibility with existing standards.

This analysis resulted in a new application profile of DCAT called the Semantic Registry Information Model (SRIM) Core Model [11], referred to later in the document as SRIM Core. SRIM Core is defined as a superset of DCAT and its existing application profiles (DCAT-AP, GeoDCAT-AP, ADMS), and it introduces a superclass of dcat:Dataset called srim:Item. The ontology draws from multiple well-established standards such as W3C, DCAT, Project Open Data 1.1, DCAT-AP, GeoDCAT-AP, VCard, Dublin Core, and PAV, but also addresses some gaps in the standards, such as descriptions of web services (for example OGC Web Map Service (WMS), Web Feature Service (WFS)), richer description for geospatial data, additional metadata to model schema, schema mapping, and portrayal information in order to enable better semantic search of resources that fit the mission of the users. The ontology draws also on the geospatial metadata standard ISO 19115. SRIM enables the integration of different metadata providers (Catalog Service for the Web (CSW), CKAN, POD Web Accessible Folder (WAF), WMS, Web Coverage Service (WCS)) by providing a common core vocabulary to describe resources (data, services, vocabularies, map, layers, schemas, etc) and accommodate the specificities of each source by leveraging the built-in extensibility mechanism in OWL. The integration is done through the use of a semantic bridge that maps the syntactic metadata (JSON, XML based) to a semantic representation based on the SRIM model. The SRIM Core model has been extended by introducing SRIM application profiles to represent other kinds of geospatial assets such as schemas and portrayal information (see section for Semantic Mediation and Semantic Portrayal Service in Testbed-12 ER 16-056).

The purpose of SRIM Core is to define a common interchange metadata format for geospatial portals. In order to achieve this, SRIM defines a set of classes and properties, grouped into mandatory, recommended, and optional. Such classes and properties correspond to information on register items and registers that are shared by many data portals, aiding interoperability. Although SRIM is designed to be independent from its actual implementation, RDF and Linked Data are the reference technologies used to perform the modeling and preserve the semantic fidelity of the conceptual model. However, to facilitate a wide adoption, an encoding based on JSON is provided, which could be converted transparently back to a semantic model using a JSON-LD context. The JSON encoding has been closely aligned with the Project Open Data (POD) metadata schema 1.1 standard. However, to accommodate some of the requirements needed by the Semantic Registry Service, the model was extended, and sometimes modified where needed. An application profile of SRIM has been used for Geoplatform.gov, which manages all the geospatial assets of all the US government agencies. The profile has been extended to manage layers, maps and galleries. The geoplatform.gov provides importer of existing ISO 19115-x/ISO 19139 standards to SRIM and object editor to annotate assets with controlled vocabularies.

Figure 17 shows the core model of SRIM. The core mode defines all the properties that are common for most assets of any domain. The core model introduces the concept of srim:Item, which is a superclass of dcat:Dataset. It leverages geospatial extension from GeoDCAT-AP and introduces concepts of spatial extent. Attributions information are based on PROV-O and Dublin Cores. Versioning information is based on PAV ontology.

Figure 18 shows the SRIM application profile to describe dataset and services. Contrary to DCAT, which uses distribution to model both services and downloadable resources,the SRIM profile makes the Service as a first class object directly subclass of srim:Item. To accommodate the variety of service APIs (using SOAP, REST, OGC services), the model introduces the concept of API Document (srim:APIDocument), which can point to a formal specification of the API such as ISO 19115/19119, Open API (a.k.a. Swagger), WSDL or OWL-S. By introducing this concept, we have the ability to describe service API in an extensible way. The model is highly relevant for the SWIM registry as it provides a bridge between the FAA service registry and datasets metadata using Linked data approach.

During Testbed-12, a Semantic Registry Service based on the SRIM model was designed and implemented. The service used a REST API using JSON-LD and HAL format (which provides hypermedia links). The Semantic Registry provides a pluggable harvesting capability demonstrated on CSW and Electronic Business Registry Information Model (ebRIM) catalogs. The semantic registry was also used to manage schema, schema mapping and portrayal information to support semantic mediation services and portrayal services. These different scenarios demonstrated that the SRIM model was extensible enough to accommodate a variety of domains, services and applications. More details can be found in Testbed-12 ER 16-056 and ER for the Task D001 of this Testbed-14.

The SDCM ontology describes a service from different viewpoints. To support the search and discovery of relevant services, the SDCM Service Profile provides metadata information that are relevant for indexing in a catalog.

One of the main focus areas of SRIM Registry is to enable search and discovery of registry items (datasets, services, layers, maps, etc..). For this reason, the SRIM model for Service focuses on descriptive metadata, classification of services, its functions and quality of service (which is mostly addressed in the SDCM Profile description). However, the details of how to access the service mostly rely on existing well-defined standards such as OGC WFS, WMS or service API specification such as WSDL, Open API, Swagger, OWL-S, RAML etc. For the first case, an SRIM Service uses the Dublin Core property dct:conformsTo to refer to a well-defined dct:Standard which refers to well defined URI. To accommodate the second case, the SRIM Service model introduces the concept of an API Document (srim:APIDocument), which provides an access URL (dcat:accessURL) to this service description document and format information (OWL-S, OpenAPI etc). The description of the Service API is mostly useful for developers and software agents that need to access the service, but rarely plays a role in the discovery of the services in the registry.

The following table defines the mapping from SDCM to the relevant classes and properties used by SRIM.

For future testbeds, an SRIM Service Model should be investigated to identify additional properties that better align with the SDCM model. The results of this effort will be an application profile for SWIM. Harvesting of the services from the current SWIM registry could be done and converted to the application profile, so services can be searched for and discovered, as well as be linked to datasets and other assets managed by the SRIM registry. The current SWIM taxonomies would be used to classify services and search for services.

The current SWIM architecture is mostly focused on describing services but there is no relationship to the datasets a service operates on. To close this gap, the metadata about datasets should be fully formalized using GeoDCAT-AP (subset of SRIM Model) vocabulary. SRIM model provides relationships to link services and datasets using the property srim:operatesOn and its inverse property srim:usedBy. An analysis of the gaps between the current SRIM Dataset core profile and the SWIM datasets should be performed and addressed by defining an application profile specific for SWIM. The metadata documents should be made available in linked data formats (RDF, JSON-LD, Turtle) in a RESTful way so they can be harvested by a semantic registry to be indexed, to allow search and discovery.

The SRIM Registry developed during Testbed-12 and 13 provides a service to manage semantic metadata about the different assets used in SWIM. The service has been used successfully to manage metadata about datasets, services, map layers, portrayal information, schemas and schema mappings. For future testbeds, a gap analysis should be performed to accommodate the specificities of the SWIM data model. The SRIM core model can be extended by defining application profiles that capture the specific information about the SWIM services such as Quality-of-Service, Functions, API specifications. The use of controlled vocabularies specific for aviation domain could be used for classifying, enriching, reasoning and searching the assets managed by the registry.

It is possible to extend existing OGC services to support Linked Data representation, including if the services are RESTful. For example, the SensorThings API standard provides a RESTful API to access observations and sensor information. It is relatively easy to extend the API by introducing an additional RDF representation for each resource endpoint without breaking the existing APIs. If the JSON model of the service is compatible with the ontology representing the data model, it is possible to use JSON-LD by adding a JSON-LD context to existing JSON response. This allows clients to consume JSON-LD documents and convert the information to RDF representation for further processing. Providing a SPARQL endpoint of these services will facilitate the query of information without requiring the harvesting of information.

Until today, data integration has been accomplished using a single layer approach by writing a data product translator from one format to another. For example, it is common practice today to use XSLT to transform one XML document to another XML format. The problem with this approach is that it mixes the structural and semantic transformation together. Further, it does not scale, because it is based on an N-to-N mapping approach, and is error-prone due to reliance on human interpretation of data products.

The rules, which carry out the complete transformation process in one shot, have proven to be very complex. This causes serious problems in implementing and maintaining the rules of transformation. These problems arise due to the mixture of several different aspects of the overall transformation process, such terminology, granularity representation and structural and syntactic alignment. For this reason, any re-use of such rules is practically impossible.

To overcome this bottleneck a multi-layered framework should be used, which separates different aspects of the transformation process. The approach used in Image Matters Knowledge Mapping Service (KMS) in Testbed-10 [22] is able to transform a complex programming task into a simple plug-and-play process where straightforward rule patterns are selected, instantiated, and combined. KMS uses a methodology for data integration based on a three-layer model, as presented in the Figure 19. The model contains a Data Product layer, a Data Model layer, and an Ontology layer.

KMS provides the ability to map ‘legacy’ (geospatial or not) data stores and formats to a RDF knowledge representation using a unified declarative mapping expressed in RDF. KMS uses this mapping to translate semantic query (graph query, SPARQL,…​) to native query language (such as Spatial SQL, XPath/XQuery, OGC Filter) or API calls. This framework allows the virtualization of the data into a semantic graph representation and provides real-time access to data into a unified semantic representation, which could be leveraged by other knowledge-centric service components (reasoners, query engine, (Geo)SPARQL endpoints, semantic mediation, visualizations)

In Testbed-10 [23], the semantic mapping of the open source Geonames.org database, USGS GNIS gazetteers and NGA Geonames was investigated. The semantic mapping component was used to offer virtual GeoSPARQL endpoints over the mapped database and services. This approach provided a unified knowledge representation, query language and protocol to access existing gazetteer data infrastructure as illustrated in Figure 20. The semantic mapping was used to integrate WFS-G serving NGA Geonames (Interactive Instrument) and USGS GNIS (Compusult). However, the semantic mapping was limited due to some limitations in OGC Filter and issues related to usage of XLink for complex features, which tremendously impacted performance (issues are explained more in details in the OGC Engineering Report OGC 14-029).

A large numbers of Web applications have started to make their data available on the Web through Web APIs. Examples of data sources providing such APIs include Social Media APIs (Twitter, YouTube, Flickr), OGC Services such as WFS, WMS, WCS, and Sensor Observation Service (SOS). Different APIs provide diverse query and retrieval interfaces and return results using a number of different formats such as XML, JSON or ATOM. This leads to three general limitations of Web APIs:

These limitations can be overcome by implementing Linked Data wrappers around APIs. In general, Linked Data wrappers do the following:

This approach has been used in Testbed-11 to semantic-enabled Social Media APIs by using a semantic wrapper around APIs. This approach for semantically enabled WFS-G (i.e. Gazetteer profile of WFS) by transforming GeoSPARQL queries to OGC filter queries on the fly and convert the GML response to Linked Data representation.

RDFa (or Resource Description Framework in Attributes) is a W3C Recommendation that adds a set of attribute-level extensions to HTML, XHTML and various XML-based document types for embedding rich metadata within Web documents. The RDF data-model mapping enables its use for embedding RDF subject-predicate-object expressions within XHTML documents. It also enables the extraction of RDF model triples by compliant user agents. There is a wide variety of tools that can be used to generate or process RDFa data. Google leverages RDFa annotation in web pages to build its Knowledge Graph. By using RDFa in web pages, they will be displayed in an enhanced format on all major search engines. Facebook’s Open Graph Protocol, which is based on RDFa, is used express concepts that are contained in web pages, like people, places, events, movies and recipes. Major search and social companies are supporting indexing RDFa content to improve search experience.

It is worth emphasizing that RDFa uses URLs to identify just about everything. This is why, instead of just using properties like title or created, we use http://purl.org/dc/terms/title and http://purl.org/dc/terms/created. The reason behind this design decision is rooted in data portability, consistency, and information sharing. Using URLs removes the possibility for ambiguities in terminology. Without ensuring that there is no ambiguity, the term "title" might mean "the title of a work", "a job title", or "the deed for real-estate property". When each vocabulary term is a URL, a detailed explanation for the vocabulary term is just one click away. It allows anything, humans or machines, to follow the link to find out what a particular vocabulary term means. By using a URL to identify a particular creation time, for example http://purl.org/dc/terms/created, both humans and machines can understand that the URL unambiguously refers to the "Date of creating the resource", such as a web page or dataset.

The Semantic Annotations for WSDL and XML Schema (SAWSDL) specification [24] defines how to add semantic annotations to various parts of a WSDL document such as input and output message structures, interfaces and operations. The extension attributes defined in this specification fit within the WSDL 2.0, WSDL 1.1 and XML Schema extensibility frameworks. For example, this specification defines a way to annotate WSDL interfaces and operations with categorization information that can be used to publish a Web service in a registry. The annotations on schema types can be used during Web service discovery and composition. In addition, SAWSDL defines an annotation mechanism for specifying the data mapping of XML Schema types to and from an ontology; such mappings could be used during invocation, particularly when mediation is required. To accomplish semantic annotation, SAWSDL defines extension attributes that can be applied both to WSDL elements and to XML Schema elements.

The semantic annotations reference a concept in an ontology or a mapping document. The annotation mechanism is independent of the ontology expression language and this specification requires and enforces no particular ontology language. It is also independent of mapping languages and does not restrict the possible choices of such languages. One of the main motivations for SAWSDL specification is to provide mechanisms using which semantic annotations can be added to WSDL documents so that these semantics can be used to help automate the matching and composition of Web services.

SAWSDL has been suggested as a possible solution to integrate semantics within XML schemata describing geospatial data (OGC 08-167r2). Examples of SAWSDL annotations of ATM service XML schema are presented in OGC 18-022.

GRDDL is a mechanism for Gleaning Resource Descriptions from Dialects of Languages. The W3C GRDDL specification introduces markup based on existing standards for declaring that an XML document includes data compatible with the Resource Description Framework (RDF) and for linking to algorithms (typically represented in XSLT), for extracting this data from the document. The results of the transformations will usually be RDF/XML documents, although other RDF syntaxes may be used.

The markup includes a namespace-qualified attribute for use in general-purpose XML documents and a profile-qualified link relationship for use in valid XHTML documents. The GRDDL mechanism also allows an XML namespace document (or XHTML profile document) to declare that every document associated with that namespace (or profile) includes gleanable data and for linking to an algorithm for gleaning the data.

Individual publishers of data using popular vocabularies can also give users their data transformed into RDF without having to even add any new markup to individual documents. This is done by referencing GRDDL transformations in a profile document referenced in the head of the HTML. Other XML vocabularies may use their namespace documents for the same purpose. This method requires no work from the content author of individual documents but requires that the profile document contain a reference to a GRDDL transformation and be accessible to the GRDDL client, and so may require work from the creator and maintainer of the dialect. Yet this is a good use of time, since once the transformation has been linked to the profile document, all the users of the dialect get the added value of RDF.

The Web Annotation Working Group has published recommendations for capturing annotations:

JSON-LD is the serialization format used in the Web Annotation Data Model. HTML can accommodate this serialization format directly via the use of the HTML <script> element with its type attribute assigned the media type for a Web Annotation: application/ld+json;profile="http://www.w3.org/ns/anno.jsonld" (see section about Embedded JSON-LD below)

Another approach of embedding annotations into HTML is to use RDFa. The advantage of using RDFa is that the annotation terms are mixed with the core HTML content, meaning that, for example, the text in the HTML source can be also re-used as an annotation textual body. In other words, a single resource may become both human visible as well as machine-readable. On the other hand, RDFa is an RDF serialization syntax: the RDF vocabulary described in Annotation Vocabulary specification must therefore be used instead of the JSON-LD encoding used in the Annotation Data Model document.

In OGC 18-022, the web annotation data model is proposed as a solution to associate domain specific semantic tags with ATM service descriptions as well as whole or parts of the related text documents and XML schemata. More information and concrete examples can be found in OGC 18-022.

Microformats are small patterns of HTML to represent commonly published things like people, events, blog posts, reviews and tags in web pages. Microformats are the quickest & simplest way to provide an API to the information on your website. Microdata is an open-community HTML specification used to nest structured data within HTML content. Like RDFa, it uses HTML tag attributes to name the properties you want to expose as structured data. It is typically used in the page body, but can be used in the head. However the number of microdata implementations is limited (h-card, XFN, h-calendar, h-review, rel-tag, rel-license,..) and format such as RDFa and JSON-LD have gain marketshare due to their extensibility to accommodate any domain.

JSON-LD is a lightweight Linked Data format. It is easy for humans to read and write. It is based on the already successful JSON format and provides a way to help JSON data interoperate at Web-scale. JSON-LD is an ideal data format for programming environments, REST Web services, and unstructured databases such as CouchDB and MongoDB. A JSON-LD document can be embedded in a <script> tag in the page head or body. The markup is not interleaved with the user-visible text, which makes nested data items easier to express, such as the Dataset, Service description in the context of NAS. Also, Google can read JSON-LD data when it is dynamically injected into the page’s contents, such as by JavaScript code or embedded widgets in a content management system.

For example, Google uses structured data that it finds on the web to understand the content of the page, as well as to gather information about the web and the world in general. For example, here is a JSON-LD structured data snippet that might appear on the contact page of the FAA s corporation, describing their contact information:

Google Search also uses structured data to enable special search result features and enhancements. For example, a recipe page with valid structured data is eligible to appear in a graphical search result, as shown here:

Google recently recommended the use of JSON-LD as the preferred approach to capture structured data in web pages. Also note that the W3C recommended this technique to embed W3C Annotation in HTML (https://www.w3.org/TR/annotation-html/)

SKOS provides a standard vocabulary for representing thesauri, subject headings, taxonomies, flat vocabularies, using RDF. SKOS has a simple model with few key constructs, focusing on labeling and basic hierarchies. While it lacks the expressivity and rigor of languages such as OWL, its simplicity allows a broad range of vocabularies and classifiers to be ported from a diverse set of formats to RDF, promoting ease of sharing and cross-linking between vocabularies. Many existing vocabularies have been ported to SKOS including large vocabularies such as AGROVOC and the Library of Congress Subject Headers (LCSH). SKOS is now one of the most commonly used vocabularies for structured data on the web. Figure 22 shows a sample of SKOS concept.

An ontology is a formal unambiguous naming and definition of the types, properties, and interrelationships of the entities that really or fundamentally exist for a particular domain of discourse (as illustrated below). There are two main standards defined by W3C and used to encode ontologies:

The current taxonomies used in SWIM and hosted in semantics.aero are encoded in SKOS. While this is step toward the right direction, there is no ability to distinguish the categories of concepts (ServiceProduct, ICAORegion) without knowing a well-known concept scheme. This is problematic, if different taxonomies for the same concept categories exists. The ISO 19150-2 standard defines the rules of conversion of UML CodeList and enumeration to OWL to address this issue. This rule can also be used for taxonomies and thesauri.

The ISO 19150-2 specification defines the rules of conversion of UML codelist to OWL as:

Figure 24 shows the conversion of code list ClassA.

An application schema can evolve, meaning that multiple versions of the schema can be published. An automatically derived ontology can then also have multiple versions. ISO 19150-2 defines rules for the conversion of code lists to OWL and SKOS. This section discusses potential issues that can arise when considering multiple versions of an application schema and the derived ontology, specifically in these cases:

Assume that an application schema defines a code list ClassA that contains a collection of codes. The intent is to derive an ontology from this schema, thereby deriving an OWL and SKOS representation of the code list. Also assume that this representation will subsequently be managed outside of the application schema. For example, addition of new codes as well as deprecation of old codes may be performed in a registry, without reflecting those changes in the application schema. To acknowledge the fact that the code list is managed externally, subsequent versions of the application schema only contain a stub for the code list. To manage externally managed code list 'ClassA', the OWL 'ClassA' should have been created in a namespace that is different to that of the application schema as illustrated in Figure 25.This would requires to import the external ontology in the new application profile.

A gazetteer provides information about place names (toponyms), location types, partonomy and geometric information (typically point, but could also be polygon or lines). Gazetteers are useful for classifying information spatially using place names. By leveraging partonomy information, partonomic search can be performed using transitive reasoner and geometric coordinate can be used to perform spatial operations. A gazetteer place could be seen as a specialization of skos:Concept by adding toponyms are specialization of skos-xl:Label. Partonomic relations can be seen as specialization of skos:broader (partOf) and skos:narrower (hasPart). Testbed-10 explored the use of semantic for gazetteer using this approach using semantic mapping components [OGC 14-029r2].

This section describes best practices to design ontologies for aviation data models. NASA ATM ontologies is a good example of modular ontologies following these design principles.