Publication Date: 2017-06-19

Approval Date: 2016-09-18

Posted Date: 2016-08-09

Reference number of this document: OGC 16-039r2

Reference URL for this document:

Category: Public Engineering Report

Editor: Aleksandar Balaban,

Title: Testbed-12 Aviation Semantics Engineering Report

OGC Engineering Report


Copyright © 2017 Open Geospatial Consortium. To obtain additional rights of use, visit


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


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

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


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

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

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

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

Table of Contents

This engineering report examines the role of geospatial semantic technology in the domain of civil aviation. Many aeronautical services (providing information on request or processing the data) are based on OGC Web Service specifications. A number of aeronautical services possess geospatial attributes. The aviation services follow OWS Common Service requirements but also have domain specific capabilities. Services metadata is often very relevant for service consumption, especially in the SOA environment of aviation’s System Wide Information Management (SWIM). Therefore, it shall be exposed to consumer stakeholders for either design or runtime service discovery in an efficient, standardized way.

This ER starts introducing the WSDOM service ontology developed by FAA for semantic service discovery. It proposes several extensions useful for OWS compatible, geospatial aviation services. It combines GeoSPARQL with WSDOM ontology and FAA service classification taxonomies and elaborates the interoperability between ontology based WSDOM and OWS compatible service descriptions.

Business Value

Geospatial enabled semantic service metadata discovery proposals, as described in this report, provide valuable technical and organizational improvements for the SOA governance, especially regarding the service configuration, discovery, and consumption in the aviation’s System Wide Information Management (SWIM).

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

The document demonstrates the combination of OGC semantic standards (GeoSPARQL) with service description methodology developed by the FAA (WSDOM) for the domain of civil aviation and aeronautical traffic management. It also elaborates the interoperability between WSDOM ontology an the OWS GetCapabilities taxonomy used to describe geospatial services. Therefore, it demonstrates the importance and usefulness of OGC standards to solve the complex, real world tasks such as those from the transportation domain.

How does this ER relates to the work of the Working Group

This report proposes the use of OGC standards developed by the OGC Geosemantics DWG, such as the GeoSPARQL, with ontology based service descriptions for the domain of civil aviation and the air traffic management. The report clearly stresses the importance of geosemantics for the service discovery in a SOA environment and also highlights the need for an equivalent, ontological, interoperable representation for OWS GetCapabilities metadata documents.


OGC, OWS, WSDOM, OWL-S, Aviation, GetCapabilities, Semantic, Discovery, Testbed-12

1. Introduction

1.1. Scope

This OGC® document gives guidelines for the concept of service discovery for semantic described aviation services with consideration of specific OGC compatible web services (OWS). It has been created as part of the aviation thread on behalf of Testbed 12 sponsors from FAA.

This OGC® document is applicable to all readers interested in the aviation topics, as well as those who are looking for the service description ontologies and are interested in semantic enriched metadata for OGC compatible web services.

1.2. Document contributor contact points

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

Table 1. Contacts
Name Organization

Aleksandar Balaban

1.3. Future Work

No future work is planned to this document.

1.4. 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 documents are referenced in this document. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies.

3. Terms and definitions

For the purposes of this report, the definitions specified in Clause 4 of the OWS Common Implementation Standard [16] shall apply. In addition, the following terms and definitions apply.

Table 2. Terms and definitions


An association between an interface, a concrete protocol, and a data format. A binding specifies the protocol and data format to be used in transmitting messages defined by the associated interface.

Business Function

A characteristic action or activity that needs to be performed to achieve a desired objective, or in the context of this standard, to achieve a real world effect.


A set of distinct values, characterized by properties of those values, and by operations on those values.


A state or condition that results from interaction with a service. Multiple states may result depending on the extent to which the interaction completes successfully or generates a fault.

End Point

An association between a fully-specified binding and a physical point (i.e., a network address) at which a service may be accessed.


A message that is returned as a result of an error that prevents a service from implementing a required function. A fault usually contains information about the cause of the error.

Input Data

entered into, or the process of entering data into, an information processing system or any of its parts for storage or processing.


An identifiable collection of units of information (data elements), presented in a manner suitable for communication, interpretation, or processing within a context of interacting SOA components.


Data that defines or describes other data.


A collection of names, identified by a URI reference, that are used in XML documents as element types and attribute names. The use of XML namespaces to uniquely identify metadata terms allows those terms to be unambiguously used across applications, promoting the possibility of shared semantics.


An explicit and formal specification of a shared conceptualization.


A set of messages related to a single Web service action.


A unique framework of authority within which a person or persons act, or are designated to act, towards some purpose. Any department, service, or other entity within an organization which needs to be identified for information exchange.


Data transferred out of, or the process by which an information processing system or any of its parts transfers data out of, that system or part.


A state or condition that is required to be true before an action can be successfully invoked.


A set of algorithms, calculations, or business rules that operate on input data in order to produce the required output or to produce a change of internal state.


A formal set of conventions governing the format and control of interaction among communicating functional units.

Quality of Service (QoS)

A parameter that specifies and measures the value of a provided service.

Real World Effect

An ultimate purpose associated with the interaction with a particular service. It may be the response to a request for information or the change in the state of some entities shared between the participants in the interaction.


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

Service Consumer

An organization that seeks to satisfy a particular need through the use of capabilities offered by means of a service.

Service Description

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

Service Provider

An organization that offers the use of capabilities by means of a service.

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 resources, as well as query capabilities.

Service-Oriented Architecture (SOA)

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

Structured Data

Data that is organized in well-defined semantic “chunks” or units that are variously called fields, elements, objects, or entities. Individual units are often combined to form larger, more complex units.


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

Uniform Resource Locator (URL)

A type of URI that identifies a resource via a representation of its primary access mechanism (e.g., its network "location"), rather than by some other attributes it may have.

Unstructured Data

Data that does not follow any hierarchical sequence or any relational rules. Examples of unstructured data may include audio, video, and unstructured text such as the body of an e-mail or word processor document.


A human, his/her agent, a surrogate, or an entity that interacts with information processing systems. A person, an organization entity, or automated process that accesses a system, whether authorized to do so or not.

Web Service

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

Web Service Interface

A logical grouping of operations, where each operation represents a single interaction between consumer agents and a Web service. Each operation specifies the types of messages that the service can send or receive as part of that operation without any commitment to transport or wire protocol.

4. Conventions

4.1. Abbreviated terms

Table 3. Abbreviated terms


Aeronautical Information System


The Aeronautical Information Exchange Model


Application Program Interface


Commercial Off The Shelf


Federal Aviation Administration


The Flight Information Exchange Model


Geography Markup Language


Message Exchange Pattern


National Airspace System


Open Geospatial Consortium


Web Ontology Language


Ontology Web Language (OWL)-based Web Service Ontology


Quality of Service


SWIM Common Registry


Service-Oriented Architecture


System Wide Information Management


Unified Modeling Language


Uniform Resource Identifier


Uniform Resource Locator


World Wide Web Consortium


Web Service


Web Service Description Document


Web Service Description Language


Web Service Description Ontological Model


eXtensible Markup Language

4.2. UML notation

Most diagrams that appear in this standard are presented using the Unified Modeling Language (UML) static structure diagram, as described in Subclause 5.2 of [OGC 06-121r9].

5. Overview

This engineering report explores the options for use of semantic geospatial technology to describe and discover the OGC Web Services (OWS) [7] in the aviation domain. It starts giving a short introduction into the concept of semantic service description and discovery using WSDOM [17] ontology and considering the characteristics of OWS and the specific aviation traffic management needs.

The usefulness of ontology based service metadata descriptions for geospatial service discovery tasks was explained and several extensions for WSDOM ontology proposed. The extensions enhance WSDOM ontology for service classification taxonomy but also utilizes the results of OGC Geosemantics DWG ( in the area of geospatial semantic proposing GeoSPARQL as the language of choice for service discovery. Much attention has also been given to the interoperability between the WSDOM ontological service representations and the equivalent OGC OWS compatible metadata descriptions.

Finally, the report shortly describes a solution stack used to deploy ontologies and create temporary semantic service registry in order to test and verify extensions and code examples (query and metadata) used for semantic discovery.

6. Status Quo & New Requirements Statement

6.1. Status Quo

WSDOM is a formal ontological model based on OWL-S and FAA Service Taxonomies that is being developed by FAA for use in building applications that process and exchange web service information. It can be used to describe and discover service metadata instances using semantic technology. While it provides good basis for extensions, the WSDOM ontology needs additional metadata to fully classify services, describe their characteristics and express their geospatial properties. It further doesn’t include rules and axioms for reasoning nor supports mapping between WSDOM and OWS GetCapabilities document. The current WSDOM specification also lacks the description of use case scenarios, service discovery query examples and a referent demonstration/test environment.

6.2. Requirements Statement

No formal requirements are required or specified for this engineering report. The list below provides the major goals put on this report formatted in a requirement like fashion.


  1. Semantic aviation service description shall enable discovery based on geospatial criteria.

  2. Semantic aviation service description for OWS compatible aviation services shall be interoperable with Service Description documents provided by "getCapabilities".

  3. Semantic service discovery shall be performed based on standard ontology query languages SPARQL and GeoSPARQL.

  4. Service discovery shall support deducing of facts about services based on the concept of reasoning.

7. Solutions

Considered and proposed solutions which were investigated during the preparation phase and the work on this ER include following areas:

  1. Extensions for semantic geospatial properties;

  2. Extensions for interoperability with GetCapabilities document; and

  3. Extensions for aviation service classification concepts.

7.1. Targeted Solutions

Targeted solution includes several extensions for WSDOM ontology. Three of them are detailed elaborated and the extensions are proposed at the implementation level.

  1. The first one is dedicated to the geospatial service metadata and related to GeoSPARQL query language and required ontological extensions in WSDOM.

  2. The second one is focused on the interoperability between WSDOM and getCapabilities service metadata. It presents the work already done in describing OGC Geospatial Web Services using OWL-S Web Service ontologies, elaborates the limitations and options for integration with WSDOM service ontology.

  3. The third one includes a part of FAA Service Taxonomy (FAA-STD-066) encoded in OWL and made available for service metadata description.

7.2. Recommendations

Based on the investigation results presented in this report, the following recommendations are made to enable and improve the process surrounding the semantic service discovery in the aviation domain:

  1. Include all concepts from FAA Service Taxonomies into WSDOM ontology;

  2. Extend WSDOM ontology for service discovery concepts using GeoSPARQL;

  3. Support the methods (mappings, extensions) for interoperability between WSDOM and OGC specific service metadata;

  4. Explore the importance of axioms and reasoning for service discovery; and

  5. Explore WSDOM ontology for interoperability with the concepts described in SCR (SWIM Common Registry).

8. Discovery of OGC OWS compatible services in the aviation domain

8.1. Introduction

In order to understand the needs for service discovery in the domain of aviation, this section provides several use cases, which require aviation services to be described and discovered using semantic technology. The use cases are related to the common capabilities provided by traditional aeronautical information systems. The major difference is in a new assumption regarding the System Wide Information Management (SWIM) - inside SWIM, numerous aviation services might be provided by various authorized service providers. Such diversity requires the services to be properly described in order to be successfully discovered and consumed.

With highly flexible SWIM anticipated, the aeronautical data retrieval becomes more complex. Many aviation information services will be available in SWIM and the complete knowledge about characteristics and capabilities they provide (operational, data types, spatial coverage), as well as the implementation details will not always be explicitly available. With other words, the availability of service metadata consolidated in a centralized SWIM catalogue/registry for the purpose of service discovery is important precondition for successful service consumption.

8.1.1. Use case: Preparation for flight execution

Preparation for flight execution includes data dissemination in order to create a report called a pre-flight information bulletin (or pre‐ flight and in‐flight aeronautical information publications). Traditionally, an aeronautical information system (AIS) provides information services, which offer all kinds of aeronautical information required to create the bulletin. The information is usually retrieved from confident, centralized data sources, for example from a well known central database operated by an aeronautical service provider.

Pre-flight information bulletin requires mashup of aeronautical (AIXM), weather (WXXM), flight (FIXM) and map data. They will be delivered by services discovered based on operational, spatial (region) or non-functional (security, QoS) characteristics. Pieces of information representing the entities of aeronautical infrastructure like the routes, airspaces, NOTAMs, emergency airports, navigation aids, initial flight plan and weather forecasts information could originate from multiple data sources and be provided by several distinctive service providers. How many services will assist in creation of pre-flight information bulletin depends on the discovery results and is related to individual capabilities of services available in the SWIM service pool.

8.1.2. Use case: Flight planning service

In order to create and submit flight plans different kinds of aeronautical data shall be retrieved using SWIM service pool. Additionally, the more processing oriented services such as the flight plan validator service are likely to be required in order to assist the planning.

Finally, flight plan shall be submitted to some regulatory instance such as Network Manager.

Prior to the flight execution, sensitive and critical information concerning the state of the atmosphere with respect to temperature, humidity, transmissivity, and condition is necessary to adjust flight plans before and during their execution.

Service discovery for this use case would include searching for service providers capable to provide airspace, routes and airport informations, as well as the sources of so called notices for airman (NOTAM) and data validation service instances.

8.1.3. Use case: Airport slot trading

Airport slots are periodically assigned to airlines following strict operational rules. Under certain conditions an airline can initiate a desire to trade slots (buy, sell, lease in, lease out, or swap). To support the concept of slot market a semantic discovery might be used during the preparation phase in order to identify the regional or global slot traders or slot swapping offers for a particular airport.

9. OGC web service metadata

9.1. Introduction

If an OWS service shall additionally be described using semantic metadata like the WSDOM, it is important to explore how the mandatory metadata information provided by GetCapabilities could be synchronized with equivalent semantic metadata representation. The goal here is to achieve interoperability and eliminate metadata redundancy, while preserving OWS compatibility. This clause provides an introduction into the service metadata description of OGC Compatible Web Services as mandated in the OWS specification and specifies possible mappings to WSDOM properties.

9.2. Service capability document taxonomy

The mandatory GetCapabilities operation allows clients to retrieve a Capabilities XML document providing metadata for the specific service implementation. For example, the WFS service type is required to provide a GetCapabilities implementation to request an XML metadata document roughly describing:

  • The organization providing the service;

  • The WFS operations provided by the service;

  • A list of feature types that the service can operate on; and

  • A list of filtering capabilities that the service supports.

Slightly different document formats are specified for other OWS service types such as WMS or WPS services. More details are provided in chapter 11, in the section dedicated to the interoperability between WSDOM ontology and GetCapabilities documents.

9.3. OGC catalogue service

Catalogue services support the ability to publish and search collections of descriptive information (metadata) for data, services, and related information objects. Metadata in catalogues represent resource characteristics that can be queried and presented for evaluation and further processing by both humans and software. Catalogue services are required to support the discovery and binding to registered information resources within an information community.

However, the current OGC catalogue service specification only supports taxonomies, which means it is not suited for semantic based service discovery. In order to support semantic discovery, an interesting extension proposals in form of an OWL Extension Profile for CWS [11] in form of OGC discussion paper has been made. The document describes the ontological approach in general but also provides some details regarding the discovery service end points specifications.

10. WSDOM Ontology

10.1. Introduction

WSDOM is a formal Web Service description ontological model that is being developed by FAA for use in building applications that process and exchange web service information. The ontology supports both syntactical and semantical characteristics of services and provides quite good basis for further enhancements. The evaluation starts with comparison of WSDOM and other similar solutions.

10.2. The structure

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 of them provides ontological representation of FAA standard taxonomies [7].

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

Figure 1. Service Ontology

ServiceInterface (maps to OWL-S ServiceModel) and ServiceImplementation (maps to OWL-S ServiceGrounding). This structure also corresponds to that described in the Preparation of Web Service Description from [8].

Figure 2. Interface Ontology

These three classes are further refined by three additional ontologies for web services: WSProfile, WSInterface, and WSImplementation respectively.

Figure 3. Profile Ontology

There are also two other ontologies with associated taxonomies derived from FAA-STD-065 [8]: Stakeholder (equivalent of deprecated OWL-S Agent ontology) and Document (captures the various classes of artifacts used in SOA-based implementations).

11. WSDOM Extension Proposal

11.1. Introduction

This clause describes several extension proposals for WSDOM ontology version 1.1. The WSDOM extensions shall enable efficient discovery of OWS aviation services and helps to create a service knowledge base. The proposals enhance the ontology with concepts from FAA Service Taxonomies [1] and also include the geospatial semantic [3].

The interoperability between OWS service meta data documents (provided by "GetCapabilities") and semantic service descriptions such as the WSDOM was explained in a dedicated chapter.

The term extension means here the terminology extensions for WSDOM (ABox), service metadata and other instances (TBox), as well as the axioms/rules (RBox). The terms ABox and TBox are used to describe two different types of statements in ontologies. TBox statements describe a system in terms of controlled vocabularies, for example, a set of classes and properties (WSDOM), while ABox are statements about individuals (service metadata description elements, instances) belonging to those concepts.

11.2. WSDOM structure and extension strategies

There are several ways to extend an ontology. An ontology can import and utilize the concepts defined in other ontologies, therefore, ontologies can be composed out of several distinctive external ontologies.

The OWL, a semantic language used to model the WSDOM, provides three increasingly expressive versions designed for particular purposes.

  • OWL Lite is a very simple classification hierarchy.

  • OWL DL is a description logic language, allowing expressivity and decidability for reasoning.

  • OWL Full has maximum expressiveness but does not guarantee computational completeness or decidability.

An OWL profile constraint influences the overall expressiveness of ontology an can enable or disable the reasoning. Therefore, the extensions proposed here will consider the profile constraints of original WSDOM 1.1 implementation but the OWL DL is required if the axioms and the data inference shall be used in a full fledged service knowledge base.

The WSDOM has been designed as a combination of several autonomous ontologies delivered in a separated files and linked together using external import mechanism provided by the Protege ontology editor. For verification of proposed extensions all concepts have to be loaded into an ontology server/repository with query engine and reasoner components and access to all ontology elements and imports relevant for service discovery.

Extensions can be incorporated into an ontology through the inclusion of additional concepts (classes and properties), creating new elements using multiple inheritance, extended properties value/range or specifying additional declarative rules/axioms (class and property equivalence, transition rules). New concepts like new classes created by inheritance, which introduce new properties can be used to enhance already available concepts and individuals without invalidate them (related to original ontology). This kind of extension mechanism is used for WSDOM to include geospatial properties into standard service description individuals. An alternative to multiple types for service descriptions would be to derive a new class using multiple inheritance:

WSDOM Extensions Options
Figure 4. Multiple Inheritance vs. Individual Types

Extensions explained here are all focused on the “ServiceProfile” class from the WSDOM. They affect several properties as shown on the high level ServiceProfile class diagram below.

WSDOM Service Profile
Figure 5. WSDOM Service Profile

"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. As part of extensions proposed here, the service profile class will be enriched with additional classes, properties and individuals.

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.

Related to OWS compatible OGC service, the variety of possible "real world effects" seems to be limited on retrieval and processing of aviation data. With other words, if an aviation service is an OWS service, that service is likely to be either one of data provider service types (WFS, WMS, WCS) or to perform calculations/processing (WPS). This implies that the real world effects of OGC compatible aviation services are limited to “receive/store/modify/transform aviation data”. Although it could be designed that way, real world operational effects (such as flight cancellation or flight rerouting) are unlikely to be implemented using OWS compatible service endpoints, because such implementation wouldn’t be compliant with the purpose of OWS services (which is primary the data retrieval).

As part of ServiceProfile the class described in the diagram as “Categorization Facets” obviously represents a placeholder kept for ontology extensions to link profile instances with some service categorization. One of extensions presented in this ER will include a subset of FAA Service Taxonomy transformed to OWL and encoded as hierarchical class structure. It however won’t utilize that “categorization facet” concept as it was suggested in the original WSDOM ontology. Instead, service profile instances will receive additional class types in accordance with service categorization.

11.2.1. Service Topology and Taxonomy

The figure below represents two major enhancements of WSDOM proposed in this ER. Beside the concepts of “Service” and “ServiceProfile” from original ontology, part of FAA Service Taxonomy and GeoSPARQL spatial attributes are added to the ontology to support service categorization and geo referencing.

WSDOM and Proposed Extensions
Figure 6. WSDOM and Proposed Extensions
Geospatial Support

This section describes an extension related to the OGC GeoSPARQL ontology and query language. The idea is to semantically model the geospatial characteristics of aviation services by capturing geographical regions for which they provide useful capabilities and business functions.

To describe spatial properties which characterize services and their capabilities, an ontology and query language provided by OGC, the GeoSPARQL [3], will be integrated into WSDOM. The individuals of ServiceProfile shall additionally implement a new geo:Featuretype type from GeoSPARQL. Doing so, service descriptions will contain a geometry property needed for spatial reasoning and querying.

Proposed extensions enable service discovery (using SPARQL [2] or GeoSPARQL) based on service category and topological characteristics, which satisfy the query criteria.

FAA Service Taxonomy

For the extension concerning the FAA Service Taxonomy concepts a semantic equivalent of original categorization hierarchy will be created using an ontology editor (Protege). This extension will focus on aeronautical and aviation related categories for purpose of this document. The integration with WSDOM ontology will occur via service profile individuals. Those instances that originally instantiate “ServiceProfile” type will also receive additional types in accordance with FAA Service Taxonomy.

11.3. GeoSPARQL

11.3.1. Introduction

It would significantly enhance both the service description expressiveness and the discovery capabilities, if WSDOM ontology would support geo semantic relations and spatial querying. Therefore, this section presents a geo spatial extension of SPARQL and explains how it could be integrated into WSDOM ontology.

SPARQL is a protocol and query language for the Semantic Web, while the OGC GeoSPARQL is a geographic query language for RDF Data. It defines additional vocabulary for representing geospatial data in RDF and defines an extension to the SPARQL query language for querying those data. It additionally specifies OWL classes and properties for representing geographical features and their geometries.

GeoSPARQL provides following features:

  • An RDF/OWL vocabulary for representing spatial information;

  • A set of functions for spatial computations; and

  • A set of query transformation rules.

The GeoSPARQL specification contains the definition of a vocabulary to represent features, geometries, and their relationships, as well as a set of domain-specific, spatial functions for use in SPARQL queries. GeoSPARQL follows a modular design.

  • A core component defines OWL classes for spatial objects.

  • A geometry component defines RDFS data types for serializing geometry data, RDFS/OWL classes for geometry object types, geometry-related RDF properties, and non-topological spatial query functions for geometry objects.

  • A geometry topology component defines topological query functions.

  • A topological vocabulary component defines RDF properties for asserting topological relations between spatial objects.

  • A query rewrite component defines rules for transforming a simple triple pattern that tests a topological relation between two features into an equivalent query involving concrete geometries and topological query functions.

GeoSPARQL supports both quantitative and qualitative spatial reasoning:

  • A quantitative spatial reasoning involves concrete geometries for features where distances and topological relations can be explicitly calculated; and

  • Qualitative geospatial reasoning allow topological inferences for features where the geometries are not directly considered.

One example of qualitative reasoning would be the one with consideration of transitive relations. Spatial relation "contains" is transitive: if A contains B and B contains C then A contains C as well and query execution can be preformed even without explicit geometric calculations and tests.

11.3.2. GeoSPARQL Ontology

The ontology for representing features and geometries includes a class geo:SpatialObject, with two primary subclasses, geo:Feature and geo:Geometry. GeoSPARQL specification contains an ontological part with classes and properties and a part dealing with query specification. They task is to enable service discovery with geospatial querying.

GeoSPARQL Extension Classes
Figure 7. GeoSPARQL Essential Classes

The concepts described in GeoSPARQL are designed to be used together with the concepts specified in the domain ontology, which shall be augmented with geospatial properties. Having said that, every domain class, which has spatial characteristics and shall be captured by spatial queries shall instantiate the class geo:Feature. Features relate to their geometries via the geo:hasGeometry property. For example, an airport is a geo:Feature. A representation of the real world location becomes a geo:Geometry. GeoSPARQL provides different OWL classes for the geometry hierarchies associated with geometry representations for many different geometry types such as point, polygon, curve, arc, and multicurve. It also includes two different ways to represent geometry literals and their associated type hierarchies: WKT and GML. The geo:asWKT and geo:asGML properties link the geometry entities to the geometry literal representations. Values for these properties use the geo-sf: WKTLiteral and geo-gml:GMLLiteral data types respectively.

11.3.3. GeoSPARQL and Spatial Relationships

GeoSPARQL includes a standard way to query for topological relationships, such as overlaps, between spatial entities. These come in the form of:

  • Binary properties between the entities; and

  • Geospatial filter functions.

The topological binary properties can be used in SPARQL query triple patterns like a normal property (relation). Primarily they are used between objects of the geo:Geometry type. The properties can be expressed using three distinct vocabularies:

  • The OGC Simple Features;

  • Egenhofer 9-intersection model; and

  • RCC8.

The Simple Features topological relations include equals, disjoint, intersects, touches, within, contains, overlaps, and crosses.

Geospatial filter functions provide two different types of functionality. First, there are operator functions which take multiple geometries as predicates and produce either a new geometry or another datatype as a result. The second type of functionality is boolean topological tests of geometries. The major difference related to topological binary properties is that these functions take the geometry literals as parameters, while the binary properties take geo:Geometry and geo:Feature entities.

GeoSPARQL Classes and Properties
Figure 8. WSDOM Service Profile

As depicted in the ontology editor screenshot above, the GeoSPARQL ontology provides rich semantic structure used to specify geometries and relations. Topological properties such as “cross”, “cover”, “touch”, “intersect” and “disjoint” are listed on the right side.

Figure 9. WSDOM GeoSPARQL Extension

GeoSPARQL topological properties are usually derived based on spatial reasoning (qualitative spatial reasoning) inside of GeoSPARQL compatible data stores during the GeoSPARQL query evaluation.

Minimalistic Spatial Query
PREFIX serv: <>
PREFIX geo: <>
PREFIX geof: <>

    serv:A my:hasExactGeometry ?aGeom .
    ?aGeom geo:asWKT ?aWKT .
    ?f serv:hasExactGeometry ?fGeom .
    ?fGeom geo:asWKT ?fWKT .
    FILTER (geof:sfContains(?aWKT, ?fWKT) && !sameTerm(?aGeom, ?fGeom))

The spatial query example searches for all instances of class ServiceProfile, which geometry is contained inside of one other geometry.

FAA Service Taxonomy and GeoSPARQL extensions could be integrated into WSDOM service descriptions as additional types for ServiceProfile individuals. That means, ServiceProfile individuals shall instantiate gml:Feature. For example, a service called “NOTAM” is an geospatial "AeronauticalInfomationService":

ServiceProfile with Extensions
<owl:Thing rdf:ID="NOTAM" />
<owl:Thing rdf:about="#NOTAM">
    <rdf:type rdf:resource="#AeronauticalInformationService"/>
    <rdf:type rdf:resource="#ServiceProfile"/>
    <rdf:type rdf:resource="gml:Feature"/>

Service profile instance receives a new type (rdf:typeOf) as specified in the FAA service taxonomy (AeronauticalInformationService). It also receives additional geometry type (gml:Feature). During the query execution, a SPARQL query engine can now identify that the service instance represents a NOTAM service. With a spatial type put in place the query engine and reasoners can identify geometry properties and execute GeoSPARQL queries with spatial relations and geometry filters.

An alternative would be to use multiple inheritance to create new profile classes:

ServiceProfile with geospatial extensions
<owl:Class rdf:ID="GeospatialServiceProfile">
  <rdfs:subClassOf rdf:resource="#ServiceProfile" />
  <rdfs:subClassOf rdf:resource="&gml;Feature" />

<owl:Thing rdf:ID="NOTAM" />
<owl:Thing rdf:about="#NOTAM">
    <rdf:type rdf:resource="#GeospatialServiceProfile"/>

This approach has advantage that the individuals instantiate the geospatial profile and don’t instantiate multiple classes.

11.4. FAA Service Taxonomy

In order to enable the use of service classifications for the aviation domain, this section proposes an extension with classification provided in Appendix A from FAA Service Taxonomy [7]. The extension requires the original plain text categorization to be represented using equivalent ontological OWL form. This task was manually performed using Protege ontology editor: