Testbed-12 Aviation Semantics Engineering Report

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: http://www.opengis.net/doc/PER/t12-F002

Category: Public Engineering Report

Editor: Aleksandar Balaban, m-click.aero

Title: Testbed-12 Aviation Semantics Engineering Report

OGC Engineering Report

COPYRIGHT

WARNING

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

LICENSE AGREEMENT

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

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

THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD. THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.

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

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

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

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

Table of Contents

1. Introduction
2. References
3. Terms and definitions
4. Conventions
- 4.1. Abbreviated terms
- 4.2. UML notation
5. Overview
6. Status Quo & New Requirements Statement
- 6.1. Status Quo
- 6.2. Requirements Statement
7. Solutions
- 7.1. Targeted Solutions
- 7.2. Recommendations
8. Discovery of OGC OWS compatible services in the aviation domain
- 8.1. Introduction
9. OGC web service metadata
10. WSDOM Ontology
- 10.1. Introduction
- 10.2. The structure
11. WSDOM Extension Proposal
12. Semantic tools used for verification
13. Conclusion
Appendix A: SESAR SWIM Registry Service Taxonomy
Appendix B: FAA Service Taxonomies
Appendix C: WSDOM service metadata examples
- 1.1. GeoSPARQL Queries
Appendix D: Revision History

Abstract

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.

Keywords

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	m-click.aero

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.

References

[1] OGC OWS Context Conceptual Model
[2] SPARQL Query Language for RDF
[3] GeoSPARQL
[4] Digital NOTAM Event Specification
[5] Service Description Conceptual Model (SDCM)
[6] Concept of Operations for the SWIM Common Registry (SCR)
[7] FAA STD-066 WEB Service Taxonomies
[8] Standard Practice, Preparation of Web Service Description Documents
[9] OGC Web Service Common Implementation Specification
[10] Stock Kerstin, Robertson Anne, Small Mark - Representing OGC Geospatial Web Services in OWL-S Web Service Ontologies
[11] OGC® Catalogue Services - OWL Application Profile of CSW (0.3.0)
[12] Enabling the Geospatial Semantic Web with Parliament and GeoSPARQL
[13] GeoSPARQL: Enabling a Geospatial Semantic Web
[14] Hao Li, Yandong Wang, Penggen Cheng2 - Semantic Description for the Taxonomy of the Geospatial Services
[15] NAS Service Registry and Repository
[16] OGC Web Service Common Implementation Specification
[17] FAA Web Service Description Ontological Model (WSDOM)

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
Binding	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.
Datatype	A set of distinct values, characterized by properties of those values, and by operations on those values.
Effect	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.
Fault	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.
Message	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.
Metadata	Data that defines or describes other data.
Namespace	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.
Ontology	An explicit and formal specification of a shared conceptualization.
Operation	A set of messages related to a single Web service action.
Organization	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.
Output	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.
Precondition	A state or condition that is required to be true before an action can be successfully invoked.
Processing	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.
Protocol	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.
Semantics	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.
Taxonomy	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.
User	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
AIS	Aeronautical Information System
AIXM	The Aeronautical Information Exchange Model
API	Application Program Interface
COTS	Commercial Off The Shelf
FAA	Federal Aviation Administration
FIXM	The Flight Information Exchange Model
GML	Geography Markup Language
MEP	Message Exchange Pattern
NAS	National Airspace System
OGC	Open Geospatial Consortium
OWL	Web Ontology Language
OWL-S	Ontology Web Language (OWL)-based Web Service Ontology
QoS	Quality of Service
SCR	SWIM Common Registry
SOA	Service-Oriented Architecture
SWIM	System Wide Information Management
UML	Unified Modeling Language
URI	Uniform Resource Identifier
URL	Uniform Resource Locator
W3C	World Wide Web Consortium
WS	Web Service
WSDD	Web Service Description Document
WSDL	Web Service Description Language
WSDOM	Web Service Description Ontological Model
XML	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 (http://www.opengeospatial.org/projects/groups/semantics) 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.

Requirements

Semantic aviation service description shall enable discovery based on geospatial criteria.
Semantic aviation service description for OWS compatible aviation services shall be interoperable with Service Description documents provided by "getCapabilities".
Semantic service discovery shall be performed based on standard ontology query languages SPARQL and GeoSPARQL.
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:

Extensions for semantic geospatial properties;
Extensions for interoperability with GetCapabilities document; and
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.

The first one is dedicated to the geospatial service metadata and related to GeoSPARQL query language and required ontological extensions in WSDOM.
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.
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:

Include all concepts from FAA Service Taxonomies into WSDOM ontology;
Extend WSDOM ontology for service discovery concepts using GeoSPARQL;
Support the methods (mappings, extensions) for interoperability between WSDOM and OGC specific service metadata;
Explore the importance of axioms and reasoning for service discovery; and
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:

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.

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.

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.

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.

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: <http://example.org/ApplicationSchema#>
PREFIX geo: <http://www.opengis.net/ont/geosparql#>
PREFIX geof: <http://www.opengis.net/def/function/geosparql/>

SELECT ?f
WHERE {
    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"/>
</owl:Thing>

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:Class>

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

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:

Figure 10. FAA Taxonomy Classes

The figure displays a subset of overall FAA Service Taxonomy in ontological form for demonstration purposes. The taxonomy has been modeled in OWL as hierarchical class structure with inheritance.

The hierarchical categorization presented here has been modeled using inheritance. The WSDOM ontology (ServiceProfile) already contained a property aimed for service classification. In WSProfile.owl there is a class named "ServiceCategory" with property "hasServiceCategry". Service profile individual shall therefore contain one or many “hasServiceproperty” properties, which reference service category instances. For this option a query expressed in pseudo language would look like this:

"Select all Services that have WSProfile, which has property "hasServiceCategrory" associated with  NOTAMService instance".

Alternatively, service categories can also be modeled by creating a class hierarchy (as it has been depicted in the figure). Service class individuals implement one or many category classes. A query example in pseudo language:

"Select all Services that are NOTAMService."

The third option is related to the original proposal from the ontology. Service categories are modeled using class hierarchy and a service profile individual additionally implements one or more category classes. A query looks a little bit more complex compared to the previous one:

"Select all Services that have WSProfile that is NOTAMService."

Even if the "Service" class was said to be just a container for binding, profile and implementation concepts it feels the most naturally to introduce subclasses of class Service for all aviation service category. An alternative would be to do the same with "ServiceProfile" class.

However, both approaches preferred here are not fully aligned with WSDOM’s "property based" service categorization. If the categorization would be implemented using properties, the ontology has to provide a class hierarchy category for categorization taxonomy and an additional instance/individual for every category. This approach would also make queries look more complex. It also does not reflect the fact that a service IS an aviation service of particular type.

The usage has been depicted on the class diagram and code examples below. Again, instead of having service profile class instances linking to a particular classification category using property mechanism (as it has been suggested in the WSDOM), service profile individuals shall receive an additional class type according to chosen category. This approach has been demonstrated in the following OWL listing (in XML):

Service individual implements profile and taxonomy types

<owl:Class rdf:ID="AeronauticalInformationService">
</owl:Class>

<owl:Class rdf:ID="NOTAMService">
</owl:Class>

<owl:Thing rdf:ID="D-NOTAM" />

<owl:Thing rdf:about="#D-NOTAM">
  <rdf:type rdf:resource="#AeronauticalInformationService"/>
  <rdf:type rdf:resource="#NOTAMService"/>
  <rdf:type rdf:resource="#ServiceProfile"/>
</owl:Thing>

An instance/individual called D-NOTAM of type "ServiceProfile" IS also a "NOTAMService" and "AeronauticalInformationService". Following figure provides visual explanation using class diagram notation.

Figure 11. WSDOM FAA Taxonomy Extension

An alternative would be to create new aviation service profile classes which would inherit from the WSDOM’s service profile:

ServiceProfile individual with concept from service taxonomy

<owl:Class rdf:ID="AeronauticalInformationServiceProfile">
  <rdfs:subClassOf rdf:resource="#ServiceProfile" />
</owl:Class>

<owl:Class rdf:ID="NOTAMServiceProfile">
  <rdfs:subClassOf rdf:resource="#ServiceProfile" />
</owl:Class>

<owl:Thing rdf:ID="D-NOTAM" />

<owl:Thing rdf:about="#D-NOTAM">
  <rdf:type rdf:resource="#AeronauticalInformationServiceProfile"/>
  <rdf:type rdf:resource="#NOTAMServiceProfile"/>
</owl:Thing>

This extension approach seems to be a little bit more compact compared to the first one. An advantage would however become more clearer if one considers the GeoSPARQL extensions, as well.

ServiceProfile with geospatial and taxonomy extensions

<owl:Class rdf:ID="GeospatialAeronauticalInformationServiceProfile">
  <rdfs:subClassOf rdf:resource="#ServiceProfile" />
  <rdfs:subClassOf rdf:resource="&gml;Feature" />
</owl:Class>

<owl:Thing rdf:ID="AIS" />
<owl:Thing rdf:about="#AIS">
    <rdf:type rdf:resource="#GeospatialAeronauticalInformationServiceProfile"/>
</owl:Thing>

The new class GeospatialAeronauticalInformationServiceProfile extends WSDOM ServiceProfile and gml:Entity which makes it compatible with GeoSPARQL. At the same time, due to the naming convention (AeronauticalInformationService), it corresponds to a category from FAA Service Taxonomies.

There is an Appendix in this report, which provides more examples for an OWL class hierarchy used to model the FAA Service Taxonomies. Only service types used in aeronautical traffic management are considered (for example those of aeronautical information service type).

11.5. SDCM 2.0

The Service Description Conceptual Model (SDCM) [5] provides a graphical and lexical representation of the properties, structure, and interrelationships of service metadata elements. As it has been stated in the specification document, the aim was "to define a conceptual model of a service description based on consistent application of service oriented architecture (SOA) principles and establish adequate and consistent semantics for concepts used in documentation for SOA-based services." The SDCM is a product of the Federal Aviation Administration (FAA) System Wide Information Management Program (SWIM) and the Single European Sky Air Traffic Management (ATM) Research Program (SESAR) Joint Undertaking (SJU).

SDCM is aimed to be used as conceptual fundament for SWIM Common Registry (SCR) [6], as well as for FAA SWIM Registry (NSRR) [15].

SDCM 2.0 conceptual model has many similarities to the WSDOM ontology. SDCM is platform independent (it was designed in UML 2.0). For interoperability, an option would be the to define similarities between SDCM 2.0 concepts and the WSDOM ontology and extend ontology for missing elements:

Identify similarities between SDCM and WSDOM;
Using OWL extension mechanism to include SDCM conceptual model into WSDOM ontology; and
Alternatively, instantiate the SDCM conceptual model as dedicated ontology and use it with WSDOM;

Additional axioms for mediation between service description concepts (SDCM and WSDOM classes and properties) could be provided as extension. In inclusion of axioms would require following activities:

Generate SDCM equivalent OWL ontology;
Introduce OWL axioms to describe similarities and differences between SDCM and WSDOM concepts;
Pick and test a reasoner to derive equivalent service representations; and
Perform SPARQL queries considering original and deduced concepts.

11.6. WSDOM Service Ontology and OGC OWS GetCapabilities

11.6.1. Introduction

This clause proposes a method for the semantic representation of OGC-compliant geospatial web services using an equivalent OWL ontology, possibly as part of WSDOM ontology. The method could be used to automatically populate the ontology from the OGC GetCapabilities document and augment the WSDOM metadata with additional information. The goal is to achieve interoperability between WSDOM and OGC GetCapabilities document, avoid metadata inconsistencies and enable flawless semantic discovery of aviation OWS services.

As it has been stated in the OGC Web Service Common Implementation Specification [9] the mandatory GetCapabilities operation allows any client to retrieve metadata about the capabilities provided by any server that implements an OWS interface Implementation Specification. The normal response to the GetCapabilities operation is a Service Metadata document encoded in XML.

Considering the importance of interoperability between OWS and WSDOM metadata representations WSDOM classes and properties could be directly or indirectly mapped to or filled up with concepts and attributes from Service metadata document. In order to implement unsupported metadata elements, the extensions to WDSOM shall be considered. An option would be to work with two independent ontologies (the WSDOM and the GetCapabilities one) but specify the axioms in order to describe similarities and differences.

Interesting work has already been done in describing OGC Geospatial Web Services using OWL-S Web Service Ontologies [10]. The paper provides an analysis of Service Metadata document and presents an OWL-S based ontology, which supports a subset (binding part was not included) of metadata attributes from GetCapabilities for WFS and WMS services.

An OGC discussion document from the same authors [11] has provided an endpoint specification for semantic enabled OGC catalogue services specifying the technical interface for semantic service discovery. While this engineering report deals with spatial extensions for WSDOM and the interoperability with OWS metadata, it remains for the future to explore how the WSDOM metadata shall be integrated into a service catalogue infrastructure.

The Following diagram created by http://vowl.visualdataweb.org/webvowl/index.html gives a visualization of the OWL-S extension made to support GetCapabilities documents for WFS and WMS service types. The OWL-S service profile class (which is also available in WSDOM) has been inherited by two dedicated profile classes for WFS and WMS web services. The WMS profile class also contains properties (highlighted), which are not available in original ontology and are supposed to be populated with values from corresponding GetCapabilities document attributes.

Figure 12. OWL-S GetCapabilities extension

For WMS service type following screenshot displays extensions done on OWL-S in order to describe attributes provided by GetCapabilities document. Similar approach might be used to extend the WSDOM ontology for interoperability with GetCapabilities document format.

Figure 13. OWL-S extended for GetCapabilities concepts

11.6.2. GetCapabilities document taxonomy

Section 7.4 of [16] defines Service metadata document contents, which are mandatory for all OGC Web Services.

There is a subset of metadata common to all OWS types (WFS, WMS and WPS), some attributes are specific as defined by particular implementation specification. Following table borrowed from [10] depicts section and common attributes.

Table 4. Core GetCapabilities components
Name	Definition	Data Type	Multiplicity
version	The version of the specification for the GetCapabilities operation.	Character String.	1
updateSequence	The version of the service metadata document.	Character String.	0..1
ServiceIdentification Section: Information identifying the specific web service.
serviceType	The type of OGC web service (the specification, for example WMS).	Character String.	1
serviceTypeVersion	The version of the web service specification supported (may be several) by the service.	Character String.	1..*
profile	The application profile supported by the service.	Character String.	0..*
title	The title of the web service, for human consumption.	Character String.	1..*
abstract	A brief narrative description of the web service, for human consumption.	Character String.	0..*
keywords	Unordered list of keywords or phrases.	MD_Keywords (ISO 19115)	0..*
fees	The fees and terms for using the web service.	Character String.	0..1
accessConstraints	Any access constraints that apply on the data from the web service.	Character String.	0..*
ServiceProvider Section: Information about the organization providing the web service.
providerName	The name of the organization providing the web service.	Character String.	1
providerSite	The web site of the service provider.	CI_OnlineResource (ISO 19115)	0..1
serviceContact	Contact name, address and other relevant details.	CI_ResponsibleParty (ISO 19115)	0..1
OperationsMetadata Section: Information about the operations implemented by the service. For each operation
DCP	Information for a Distributed Computing Platform supported for this operation.	DCP data structure, consisting of HTTP connect point URLs and get and post URLs and domain constraints (OGC Web Services Common)	1..*
parameter	Details of domains of a parameter for the operation.	DomainType (OGC Web Services Common)	0..*
constraint	Constraints on a quantity used by this operation that is not a parameter.	DomainType (OGC Web Services Common)	0..*
Contents	Metadata about the data served by this server. The contents and organization of this section are specific to each OWS type, as defined by that Implementation Specification.
Languages	Languages supported by this server.

The complete Common OWS XML Schema is available at the following URL:

http://schemas.opengis.net/ows/2.0/owsGetCapabilities.xsd

And an extension for WFS OWS type could be found here:

http://schemas.opengis.net/wfs/2.0/wfs.xsd

11.6.3. GetCapabilities ontology and interoperability with WSDOM

According to [10] the interoperability between GetCapabilities document and OWL-S OGC ontology was successfully demonstrated, although with certain limitations. Only WFS and WMS services were used. Service grounding was not fully considered for the mapping and according to the report there were many redundant attributes, due to property redundancies inside of OWL-S. WSDOM is however not equal to OWL-S, therefore it could be optimized to avoid such redundancies.

Following table shows more details regarding the mapping between WFS and WMS service metadata and the concepts from an OWL-S OGC ontology created as part of work already mentioned above:

Table 5. Mappings from GetCapabilities to OWL-S
Core	WFS	WMS	OWL-S
version			Service.sourceDocVersion
updateSequence			Service.sourceDocVersion
serviceType			Service.serviceType
serviceTypeVersion			Service.serviceTypeVersion
profile			Not required as there are no commonly used profiles for WFS and WMS.
title		Title	Profile:serviceName
abstract		Abstract	Profile:textDescription
keywords		KeywordList	Profile.hasTopic
fees		Fees	Profile.fees
accessConstraints		AccessConstraints	Profile.accessConstraints
providerName		ContactInformation	ActorDefault:Actor (instance name)
providerSite		OnlineResource	ActorDefault:Actor.webURL
serviceContact.IndivudualName		ContactInformation	ActorDefault:Actor.name
serviceContact.PositionName			ActorDefault:Actor.title
serviceContact.ContactInfo.Phone.Voice			ActorDefault:Actor.phone
serviceContact.ContactInfo.Phone.Facsimile			ActorDefault:Actor.fax
serviceContact.ContactInfo.Address (excluding email)			ActorDefault:Actor.physicaladdress
serviceContact.ContactInfo.ElectronicMailAddress			ActorDefault:Actor.email
serviceContact.Role			ServiceProvider.role
serviceContact.ContactInfo.HoursOfService			ServiceProvider.hoursOfService
serviceContact.ContactInfo.ContactInstructions			ServiceProvider.contactInformation
Name		Request	OgcHttpOperation.name
DCP5		Request	OgcHttpConnectPoints
Parameter			OgcHttpParameter
Constraint			OgcHttpConstraints
	Name		HasFeatureTypeComponent.Name
	Title		HasFeatureTypeComponent.Title
	Abstract		HasFeatureTypeComponent.Abstract
	Keywords		FeatureType.hasTopic
	DefaultSRS		HasFeatureTypeComponent.DefaultSRS
	OtherSRS6		HasFeatureTypeComponent.OtherSRS
	NoSRS6		Not included, indicated by absence of DefaultSRS and OtherSRS
	Operations		HasFeatureTypeComponent.FeatureTypeOperations
	OutputFormat		HasFeatureTypeComponent.Format
	WGS84BoundingBox		HasFeatureTypeComponent.owlcsw:BoundingBox
	MetadataURL		HasFeatureTypeComponent.MetadataResource
	Name		HasFeatureTypeComponent.Name
	Title		HasFeatureTypeComponent.Title
	Abstract		HasFeatureTypeComponent.Abstract
	Keywords		FeatureType.hasTopic
	OutputFormat		HasFeatureTypeComponent.Format
	Name		HasFeatureTypeComponent.Name
	Title		HasFeatureTypeComponent.Title
	Abstract		HasFeatureTypeComponent.Aabstract
	Keywords		FeatureType.hasTopic
	OutputFormat		HasFeatureTypeComponent.Format
	Spatial_Capabilities		SpatialCapabilities
	Scalar_Capabilities		ScalarCapabilities
	Id_Capabilities		IdCapabilities
		LayerLimit	WMSOperationProfile.layerLimit
		MaxWidth	WMSOperationProfile.maxMapWidth
		MaxHeight	WMSOperationProfile.maxMapHeight
		Exception	WMSOperationProfile.exceptionFormat
		Name	hasLayerComponent.Name
		Title	hasLayerComponent.Title
		Abstract	hasLayerComponent.Abstract
		Constraint	OgcHttpConstraints
		KeywordList	Layer.hasTopic
		CRS	hasLayerComponent.SRS
		EX_GeographicBoundingBox	hasLayerComponent.owl-csw:BoundingBox
		BoundingBox	hasLayerComponent.owl- csw:BoundingBox
		Dimension	hasLayerComponent.Dimension
		Attribution	hasLayerComponent.Attribution
		AuthorityURL	hasLayerComponent.URI (with URI.purpose = Authority)
		Identifier	hasLayerComponent.Identifier
		MetadataURL	hasLayerComponent.MetadataResource
		DataURL	hasLayerComponent.URI (with URI.purpose = Data)
		FeatureListURL	hasLayerComponent.URI (with URI.purpose = FeatureList)
		Style	hasLayerComponent.Style
		MinScaleDenominator	hasLayerComponent.MinimumScaleDenominator
		MaxScaleDenominator	hasLayerComponent.MaximumScaleDenominator
		Layer	hasLayerComponent.Layer
		queryable	hasLayerComponent.Queryable
		cascaded	hasLayerComponent.Cascaded
		opaque	hasLayerComponent.Opaque
		noSubsets	hasLayerComponent.NotSubsettable
		fixedWidth	hasLayerComponent.Width
		fixedHeight	hasLayerComponent.Height

The table provides an overview into the problem complexity. Ontological properties and classes in the most right column are concepts specified in OWL-S OGC ontology. Other elements are members of OWS metadata taxonomy. Recommended solution for mapping specification is to start with platform independent UML model for GetCapabilities taxonomy (if available), generate ontological artifacts and integrate them into the WSDOM ontology. Some concepts, such as Service Provider and Consumer, are obviously already available in WSDOM. Of course, the other required concepts could be directly borrowed from the existing OWL-S OGC ontology. The ontology is available in Appendix C of [10].

For OWL generation a COTS tool with corresponding transformation capabilities should be used. Other approach would be to start with XML Schema (OWS, WFS, WMS etc.) and create an equivalent OWL representation. Once the GetCapability concepts in OWL becomes available, it will be easier to compare them with WSDOM elements and identify similarities and differences.

The major advantage of tooling would be that the code generation tool can be configured to produce not only the ontological representation but also to create a software component, which generates semantic service metadata descriptions based on input GetCapabilities documents. Such semantic outputs could then be used as templates and be manually enriched with advanced semantic concepts.

11.7. Business functions and real world effects

According to STD-065 [8] a business function is a characteristic action or activity that needs to be performed to achieve a desired objective. This section provides several ideas about how to model business functions and real world effects because these two properties are specified in the WSDOM and would be useful for service modeling.

11.7.1. Examples for real world effects

The list below presents some events from the aviation domain, which might occur as consequence of service execution. Therefore, they would be candidates for the Real World Effects taxonomy.

Flight delayed
Flight postponed
Flight cancelled
Flight route changed
Airport slot reallocated
Airport closed, open
Airport capacity exceeded
Airport capacity changed
Runway opened, closed
Airspace opened, closed

11.7.2. Real World Effects as Digital NOTAM event types

Real world effects might also (fully or partially) be derived from the Digital NOTAM Event specification 2.0 [4]. This specification provides definitions for 23 events relevant for air traffic management.

Table 6. Digital NOTAM Events
Event Type	Description
NAV.UNS	Navaid unserviceable
OBS.NEW	New obstacle
OBL.UNS	Obstacle lights unserviceable
AD.CLS	Airport/Heliport closure
RWY.CLS	Runway closure
RWE.CLS	Runway portion closure
SAA.ACT	Published special activity area - activation
ATSA.ACT	Published ATS airspace - activation or deactivation
SAA.NEW	Ad-hoc special activity area - creation
ATSA.NEW	Ad-hoc ATS airspace - creation
RTE.CLS	Route portion closure
RTE.OPN	Route portion opening
TWY.CLS	Taxiway Closure
THR.CHG	Displaced Threshold
RWD.CHG	Runway Declared Distance Change
ALS.UNS	Approach Lights Unserviceable
ALS.LIM	Approach lights downgraded
VAS.UNS	Visual approach slope indicator unserviceable
RWL.UNS	Runway Lights Unserviceable
TWL.UNS	Taxiway Lights Unserviceable
SFC.CON	Airport surface contamination
VOLC.WRN	Volcano pre-eruption
OTHER	Other Events

Some of events listed above occurs as consequence of business activities, in which case they could be interpreted as real world effects of service execution. All "effects" listed here are related to aviation data types such as AIXM 5.1, GML FIXM, WXXM. Therefore, they are always associated with an OGC compatible data type. For example: An airspace closure shall be performed due to some operational condition. An OWS airspace service (OGC WFS-T service) will be used to “close” an airspace by updating the corresponding airspace entity (setting corresponding attribute to "CLOSED"). The real world effect would be captured as an "Airspace Closure" event. Of course, certain NOTAM events related to weather phenomena or other circumstances, which usually occur without prior human/system activities are not best candidates to describe the “real world effects.”

The proposal here is to model real world effects using a subset of Digital NOTAM event types and combine them with effects expected from OGC compatible services.

11.7.3. Real World Effects and OWS service restrictions

The OGC OWS services have been designed for provision and processing of geospatial data. They do not cover all possible aviation business cases and are not the best fit for some business functions. Therefore, real world effects with consideration of OGC OWS service endpoints used in aviation (WFS, WMS, WCS and WPS) are mostly limited on the effects like create, read, update and delete:

Calculated value returned (WPS);
Processed data returned (WPS - document processing/transformation/validation);
Data retrieved (WFS, WMS, WCS); and
Data set modified (WFS-T).

The WPS services, as the name suggests, are supposed to perform different sorts of geospatial calculations or even business functions with real world effects. In the other cases the effects are focused on data provision (vector or map data) but sometimes (as it has been described above) there could be a broader business meaning even behind a simple update operation. For example, an airspace might be updated and set to be closed using WFS-T, which is an event with more business relevance than the simple airspace entity update. Similar is true for updates affecting other elements of aeronautical infrastructure (airports, runways, navigation aids).

11.8. Examples

In order to better explain the extensions presented, this report provides an Appendix with more service metadata sets and discover query examples. However, a working example would require properly configured and deployed ontology server. To prepare and run an ontology repository would be out of scope of this ER and remains for the future work. Therefore, the appendix section will provide only OWL listings and GeoSPARQL query examples.

12. Semantic tools used for verification

12.1. Introduction

Several ontology servers (triple stores) with GeoSPARQL support were considered in order to test and verify WSDOM with GeoSPARQL and FAA Service Taxonomy extensions. The W3C wiki dedicated to semantic technologies https://www.w3.org/wiki/SparqlImplementations or the http://semwebcentral.org/ contains both collections of commercial and open source solutions that can help in developing GeoSPARQL based semantic service registries. These include complete development environments, editors, libraries and modules for various programming languages.

12.2. Ontology editor

Protege is an ontology editor used to inspect the WSDOM ontology, create extensions and service descriptions and test GeoSPARQL queries. Extensions and service metadata examples were created internally in Protege using graphical editor and exported into the XML/OWL representation before they were loaded in a locale instance of Parliament RDF triple store.

Figure 14. Protege with service description ontology

12.3. Service ontology repository

In order to take advantage of geospatial semantic, a service discovery implementation has to understand the GeoSPARQL query syntax and corresponding geospatial ontology extensions. The Parliament™ triple store (http://parliament.semwebcentral.org/) provides such one implementation that allows GeoSPARQL data to be spatially indexed and also contains a query engine that supports GeoSPARQL queries 12. The figure taken from the documentation gives an overview into the layers of Parliament’s modular architecture and highlights the complexity of ontology based data repositories.

Figure 15. Parliament Architecture

13. Conclusion

FAA WSDOM ontology provides the basis for development of semantic service metadata repositories in the aviation domain. In its essence this ontology is not limited to any specific business domain, although it has been created by FAA for aviation purposes and with respect to their service description methods. This section provides several final words regarding service description ontology, extensions and solution stack used for verification.

The WSDOM contains high level service description concepts and shall be enhanced to support geospatial semantic and the classifications used in the aviation domain. It requires more domain specific concepts (classes and properties, metadata instances, geometries, spatial relations) to develop its full potential.

This ER has elaborated several options regarding the new concepts in the WSDOM and proposed an important extension, which is the augmentation with OGC GeoSPARQL to allow geospatial relations and geometries be defined as part of service metadata.

The issue of interoperability between the WSDOM semantic service descriptions and the OWS metadata documents provided by GetCapabilities has been analyzed and an example of GetCapabilities ontology was provided. The consistency between these metadata representations is very important. WSDOM service description must not contain redundant or contradictory informations compared to contents provided by GetCapabilities. The best way to ensure consistency is to specify the mappings, extend the WSDOM ontology if required and begin with getCapability document, whenever a new semantic service description is required.

For mapping of GetCapabilities to an ontological representation, such as WSDOM this ER has analyzed some work already done [10]. The document has described an equivalent GetCapabilities ontology based on OWL-S with some properties and mappings also applicable for the WSDOM ontology.

Service discovery is based on the querying of semantic data. The fact that WSDOM schema has been created with OWL DL actually implies that SPARQL shall be used as the query language of choice. This ER has provided a couple of examples for GeoSPARQL queries, which takes advantage of geospatial properties added to service definitions as part of GeoSPARQL extensions. Using aviation service classification and geospatial attributes it was possible to achieve basic level of service discovery comparable to non semantic service catalogues but with better extensibility (semantic discovery approach based on axioms and reasoning) and better geospatial query expressions.

Appendix A: SESAR SWIM Registry Service Taxonomy

This annex provides an overview into service taxonomy used to describe aeronautical services in the SESAR SWIM registry (ATM Classification).

ATM Flight phases
- Airport (ramp)
- Take Off
- Departure
- En-route
- Oceanic
- Arrival
ATM activity category
- Traffic Sequencing
- CNS Infrastructure
- Surveillance Infrastructure
- Navigation Infrastructure
- Communication Infrastructure
- ATM Information Management
- Aeronautical Information Management
- Flight Information Management
- Meteorological Information
- MET Information Management
- Shared Information Service Management
- Conflict Management
- Collision Avoidance
- Separation Provision
- Airport Management
- Airport CDM
- Trajectory Management
- Trajectory Execution And Conformance Monitoring
- Trajectory Planning
- Route Assignment And Guidance
- ATM Network Management
- Traffic Synchronization
- Route Design
- Airspace And Surface Structure Design
- Airspace And Surface Structure Allocation
- Airspace Access
- Demand And Capacity Balancing
ATM data category
- Flight
- Aeronautical Information
- Meteorology
- Environment
- Capacity Demand and Flow
- Surveillance
- Other
ATM stakeholders
- Airport Operator
- Airspace User
- ANSP
- Network Manager

Appendix B: FAA Service Taxonomies

This annex provides an ontological representation for the service categorization specified in FAA Web Service Taxonomies (FAA‐STD‐066 [7]). A subset of overall categorization from the Appendix A (dedicated to the aeronautical information services and traffic management) was transformed into an OWL ontology and presented here.

FAA Service Taxonomies as OWL

<?xml version="1.0"?>
<rdf:RDF xmlns="http://faa.gov/wsdom/1.1/faa-std-066#"
     xml:base="http://faa.gov/wsdom/1.1/faa-std-066"
     xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
     xmlns:owl="http://www.w3.org/2002/07/owl#"
     xmlns:xml="http://www.w3.org/XML/1998/namespace"
     xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
     xmlns:wsdomsp="http://faa.gov/wsdom/1.1/WSProfile.owl"
     xmlns:geosparql="http://www.opengis.net/ont/geosparql"
     xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#">
    <owl:Ontology rdf:about="http://faa.gov/wsdom/1.1/faa-std-066">
        <rdfs:comment>An ontological representation of a subset of FAA Service Taxonomy (FAA-STD-066).</rdfs:comment>
    </owl:Ontology>


    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#GeoWSProfile">
        <rdfs:comment rdf:datatype="http://www.w3.org/2000/01/rdf-schema#Literal"> This class extends the WSDOM service profile and implements the Feature from GeoSPARQL.</rdfs:comment>
        <rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/geosparql#Feature"/>
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/WSProfile.owl#WSProfile"/>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AccidentInformationService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AccidentInformationService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationSafetyInvestigationInformationService"/>
        <rdfs:comment>An air transportation safety investigation service category that describes services providing information collected during a safety investigation of an air transportation accident (which usually results in human injury, loss of life, loss of an airframe, or significant property damage).</rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AerodromeFacilityInformationService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AerodromeFacilityInformationService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationFacilityInformationService"/>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AerodromeFacilityService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AerodromeFacilityService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationFacilityService"/>
        <rdfs:comment rdf:datatype="http://www.w3.org/2000/01/rdf-schema#Literal">An air transportation facility service category that describes services within the confines of the Aerodrome.</rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AeronauticalInformationService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AeronauticalInformationService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AirTrafficInformationService"/>
        <rdfs:comment>An air traffic information service category that describes services providing information about the infrastructure elements that manage the aeronautical information service assets, including the collection of data for and production of pre‐ flight and in‐flight aeronautical information publications (APIs) within the FAA and globally.</rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AirTrafficControlService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AirTrafficControlService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AirTrafficService"/>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AirTrafficEventInformationService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AirTrafficEventInformationService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AirtrafficComandAndControlInformationService"/>
        <rdfs:comment rdf:datatype="http://www.w3.org/2000/01/rdf-schema#Literal">An air traffic command and control information service category that describes services for the purpose of providing information about a detailed account of an air traffic event to appropriate
entities. </rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AirTrafficInformationService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AirTrafficInformationService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationInformationService"/>
        <rdfs:comment>An air transportation information service category that describes services for the purpose of providing advice or information about aeronautical</rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AirTrafficService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AirTrafficService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationService"/>
        <rdfs:comment rdf:datatype="http://www.w3.org/2000/01/rdf-schema#Literal">An air transportation service category that describes services requiring the performance of tasks that ensures the safe, secure, and efficient movement of commercial, private, and military air traffic. The tasks associated with the provision of air traffic services include air traffic control, air traffic management, and air traffic command and control.</rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AirTrafficStatisticsService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AirTrafficStatisticsService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AirtrafficComandAndControlInformationService"/>
        <rdfs:comment rdf:datatype="http://www.w3.org/2000/01/rdf-schema#Literal">An air traffic command and control information service category that describes services for the purpose of providing information about the quantity and/or type of aircraft in movement within a geographic area, facility, or handled by an air traffic system.</rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AirTrafficSupportService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AirTrafficSupportService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AirTrafficService"/>
        <rdfs:comment rdf:datatype="http://www.w3.org/2000/01/rdf-schema#Literal">An air traffic service category that describes services involving the performance of tasks that: 1) assist air traffic controllers in their executing duties; and/or 2) assist the air traffic controllers maintain situation awareness by enabling the fast and efficient exchange of air traffic information.</rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationAirspaceInformationService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationAirspaceInformationService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationInfrastructureInformationService"/>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationAirspaceService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationAirspaceService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationInfrastructureService"/>
        <rdfs:comment rdf:datatype="http://www.w3.org/2000/01/rdf-schema#Literal">An air transportation infrastructure service category that describes services performing tasks or assisting others with the necessary tasks to conduct safe, secure, and efficient air transportation activities within the confines of the airspace over the United States and its territories and Atlantic and Pacific Ocean coastlines.</rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationFacilityInformationService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationFacilityInformationService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationInfrastructureInformationService"/>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationFacilityService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationFacilityService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationInfrastructureService"/>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationInformationService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationInformationService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/Service#Service"/>
        <rdfs:comment>A category (or conceptual grouping) of the services performed for the purpose of providing information, advice, or guidance about the current state of a flight, air traffic, or other transport‐ related activities required to ensure the safe movement of aircraft through all phases of flight for commercial and military operations.</rdfs:comment>
    </owl:Class>


    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationInfrastructureInformationService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationInfrastructureInformationService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/Service#Service"/>
        <rdfs:comment rdf:datatype="http://www.w3.org/2000/01/rdf-schema#Literal">A category (or conceptual grouping) of the services performed for the purpose of providing advice or information about the airspace, facilities (including land, buildings, utilities, and other support equipment), systems (automated and manual), and relevant procedures within the geographic and functional boundaries of the United States.</rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationInfrastructureService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationInfrastructureService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/Service#Service"/>
        <rdfs:comment rdf:datatype="http://www.w3.org/2000/01/rdf-schema#Literal">A category (or conceptual grouping) of the services performed for the purpose of providing assistance or help in the use of the airspace, facilities (including land, buildings, utilities, and other support equipment), systems (automated and manual), and relevant procedures within the geographic and functional boundaries of the United States.</rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationProceduresInformationService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationProceduresInformationService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationInfrastructureInformationService"/>
        <rdfs:comment>An air transportation infrastructure information service category that describes services providing information about the drafting, review, publication, and subsequent archival of procedures directing the safe and efficient conduct, operation, and flow of air traffic and performance of air transportation activities.</rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationSafetyInformationService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationSafetyInformationService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationInformationService"/>
        <rdfs:comment>An air transportation information service category that describes services providing information to facilitate and ensure the safe and efficient conduct of flights, including those air transportation activities that support the conduct of flights.</rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationSafetyInvestigationInformationService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationSafetyInvestigationInformationService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationSafetyInformationService"/>
        <rdfs:comment>An air transportation safety information service category that describes services requiring the performance of tasks to ensure the information collected as the result of a safety investigations is specific to and consistent with the observation and systematic examination of air transportation activities </rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationSafetyService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationSafetyService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationService"/>
        <rdfs:comment rdf:datatype="http://www.w3.org/2000/01/rdf-schema#Literal">An air transportation service category that describes services involving the performance of tasks to facilitate and ensure 1) the safe and efficient conduct of flights; and 2) the safety of passengers, personnel (e.g., FAA, airline, facility), and air transportation infrastructure and operations (e.g., airspace, facilities, systems).</rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationSecurityInformationService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationSecurityInformationService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationInformationService"/>
        <rdfs:comment>An air transportation information service category that describes services for the purpose of providing information to facilitate and ensure the security of: 1) flights and their passengers and crew; and 2) air transportation facilities, systems, and their operation.</rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationSecurityInvestigationInformationService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationSecurityInvestigationInformationService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationSecurityInformationService"/>
        <rdfs:comment>An air transportation security information service category that describes services requiring the performance of tasks to facilitate and ensure the security of:   1) flights and their passengers and crew;   2) the national airspace; and   3) air transportation facilities, systems, and their operation. </rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationSecurityService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationSecurityService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationService"/>
        <rdfs:comment rdf:datatype="http://www.w3.org/2000/01/rdf-schema#Literal">An air transportation service category that describes services involving the performance of tasks to facilitate and ensure the security of 1) flights and their passengers and crew; and 2) air transportation facilities, systems, and their operation. </rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/Service#Service"/>
        <rdfs:comment rdf:datatype="http://www.w3.org/2000/01/rdf-schema#Literal">A category (or conceptual grouping) of the services performed for the purpose of directly performing activities to: 1) transfer or convey passengers or cargo from one geographic location to another via aircraft; 2) command and control air traffic; 3) obtain authorizations from air transportation regulatory authorities for planned aircraft flights; 4) design, construct, operate, and maintain aircraft and air transportation systems and facilities; or 5) lend assistance to others to ensure the safe and secure movement of aircraft through all phases of flight for civilian, commercial, and military operations</rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationSupportService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationSupportService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationService"/>
        <rdfs:comment rdf:datatype="http://www.w3.org/2000/01/rdf-schema#Literal">An air transportation service category that describes services performed by one or more employees or contractors who lend assistance to others in the performance of tasks that ensures the safe, secure, and efficient movement of commercial, private, and military air traffic. This service involves providing assistance to air traffic</rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationSystemsInformationService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationSystemsInformationService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationInfrastructureInformationService"/>
        <rdfs:comment>An air transportation infrastructure information service category that describes services providing information about the necessary air transportation activities involved in the design, development, implementation, operation, utilization, and maintenance of the air transportation systems and air transportation information systems.</rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AircraftDesignEngineeringService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AircraftDesignEngineeringService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AircraftEngineeringService"/>
        <rdfs:comment rdf:datatype="http://www.w3.org/2000/01/rdf-schema#Literal">An aircraft engineering service category that describes services performed by one or more employees or contractors who lend assistance to an aircraft designer in the development of plans and specifications for an aircraft and aircraft systems.</rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AircraftEngineeringService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AircraftEngineeringService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AircraftService"/>
        <rdfs:comment rdf:datatype="http://www.w3.org/2000/01/rdf-schema#Literal">An aircraft service category that describes services performed by one or more employees or contractors who lend assistance in the form of providing technical and engineering advice, guidance, and recommendations regarding the evolving design, manufacture, and maintenance of aircraft while continuing to ensure the overall safety, security, and airworthiness of the aircraft.</rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AircraftInformationService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AircraftInformationService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/Service#Service"/>
        <rdfs:comment rdf:datatype="http://www.w3.org/2000/01/rdf-schema#Literal">A category (or conceptual grouping) of the services performed for the purpose of providing advice or information about aircraft. </rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AircraftMaintenanceEngineeringService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AircraftMaintenanceEngineeringService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AircraftEngineeringService"/>
        <rdfs:comment rdf:datatype="http://www.w3.org/2000/01/rdf-schema#Literal">An aircraft engineering service category that describes services performed by one or more employees or contractors who lend assistance to an air operator maintenance facility regarding the maintenance of an aircraft or aircraft system.</rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AircraftManufacturingEngineeringService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AircraftManufacturingEngineeringService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AircraftEngineeringService"/>
        <rdfs:comment rdf:datatype="http://www.w3.org/2000/01/rdf-schema#Literal">An aircraft engineering service category that describes services performed by one or more employees or contractors who lend assistance to an aircraft manufacturer in the fabrication of an aircraft or aircraft system.</rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AircraftService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AircraftService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/Service#Service"/>
        <rdfs:comment rdf:datatype="http://www.w3.org/2000/01/rdf-schema#Literal">A category (or conceptual grouping) of the services performed by the FAA that are focused on providing engineering advice and technical expertise in the design and manufacture of aircraft.</rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AircraftSystemInformationService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AircraftSystemInformationService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AircraftInformationService"/>
        <rdfs:comment rdf:datatype="http://www.w3.org/2000/01/rdf-schema#Literal">An aircraft information service category that describes services performed for the purpose of providing advice or information about aircraft systems (automated and manual), and relevant procedures within the geographic and functional boundaries of the United States.</rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AirportInformationService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AirportInformationService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AerodromeFacilityInformationService"/>
        <rdfs:comment>An aerodrome facility information service category that describes services providing information about the:   1) status of arriving and departing flights within the airport;   2) list of services offered at the airport; 3) statistics associated with the operation of flights and availability of services offered;   4) list of air transportation organizations operating within the airport; and   5) hours of operation, access to, and utilization of the land, buildings, structures, utilities, and other support systems and equipment within the geographic and functional boundaries of the airport.  </rdfs:comment>
         </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AirportService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AirportService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AerodromeFacilityService"/>
        <rdfs:comment rdf:datatype="http://www.w3.org/2000/01/rdf-schema#Literal">An aerodrome facility service category that describes services requiring the performance of tasks (by employee, contractor, or airport personnel) to: 1) support the air carriers operating within the airport; 2) respond to emergencies by offering fire, rescue, and accident services; 3) support the needs of passengers moving through the airport; 4) ensure the safety and security of all activities, resources, personnel, and passengers within the airport; and 5) maintain the proper operation of the airport facility, its buildings, structures, systems, and equipment within the geographic and functional boundaries of the airport.</rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AirspaceManagementService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AirspaceManagementService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationAirspaceService"/>
        <rdfs:comment rdf:datatype="http://www.w3.org/2000/01/rdf-schema#Literal">An air transportation airspace service category that describes services involving the performance of tasks that makes the national airspace available to aircraft.</rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AirspaceSurveillanceService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AirspaceSurveillanceService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AirTrafficControlService"/>
        <rdfs:comment rdf:datatype="http://www.w3.org/2000/01/rdf-schema#Literal">An air traffic control service category that describes services requiring the air traffic controller to detects, track, and monitor aircraft and /or objects and their movement within the assigned airspace.</rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AirtrafficComandAndControlInformationExchangeService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AirtrafficComandAndControlInformationExchangeService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AirtrafficComandAndControlInformationService"/>
        <rdfs:comment rdf:datatype="http://www.w3.org/2000/01/rdf-schema#Literal">An air traffic command and control information service category that describes services for the purpose of supporting: 1) the exchange of information between the FAA, air operators, and their pilots to support the need to conduct continuous real‐time operational decisions; and 2) the information necessary to manage the integrated network of communications and sensor capability including aircraft tracking, aircraft separation assistance (safety functions), traffic flow management, and flight data recording. This information is exchanged among trusted entities and individuals, facilities and aircraft through a common system of symbols, signs, behavior or technology.</rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#AirtrafficComandAndControlInformationService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#AirtrafficComandAndControlInformationService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AirTrafficInformationService"/>
        <rdfs:comment rdf:datatype="http://www.w3.org/2000/01/rdf-schema#Literal">An air traffic information service category that describes services involving the delivery of information necessary to perform tasks that control air transportation infrastructure operations Service including:   1) real‐time traffic flow management;   2) balancing air traffic load levels based on current and projected airspace and airport capacity measures; and   3) re‐routing of air traffic and aircraft based on current traffic flow situational awareness (including responses to airspace and airport statistics, weather events and phenomena, and real or potential safety or security threats).    This information includes the production, maintenance, and distribution of air traffic policy, guidance, directives, procedures, regulations, rules, and standards. </rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#EmergencyService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#EmergencyService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AirTrafficControlService"/>
        <rdfs:comment rdf:datatype="http://www.w3.org/2000/01/rdf-schema#Literal">An air traffic control service category that describes services requiring the air traffic controller to provide the appropriate assistance to aircraft in an emergency state, with coordination of efforts managed between all necessary facilities.</rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#EnvironmentalInformationService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#EnvironmentalInformationService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AeronauticalInformationService"/>
        <rdfs:comment>An aeronautical information service category that describes services for the purpose of providing information about: 1) the circumstances, conditions, and objects within a geographic area; and 2) the impact they may reveal on the effect that air transportation activities may have on them.</rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#FlightControlService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#FlightControlService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AirTrafficControlService"/>
        <rdfs:comment rdf:datatype="http://www.w3.org/2000/01/rdf-schema#Literal">An air traffic control service category that that describes services requiring the air traffic controller to exercise of authority over the continuation of a flight in the interest of the safety of the aircraft and the regularity and efficiency of the flight.</rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#GeospatialInformationService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#GeospatialInformationService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AeronauticalInformationService"/>
        <rdfs:comment>An aeronautical information service category that describes services for the purpose of providing information about the geographic location or position of an object in space.</rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#HeliportInformationService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#HeliportInformationService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AerodromeFacilityInformationService"/>
        <rdfs:comment>An aerodrome facility information service category that describes services providing information about the:   1) status of arriving and departing flights within the heliport;   2) list of services offered at the heliport;   3) statistics associated with the operation of flights and availability of services offered;   4) list of air transportation organizations operating within the heliport; and   5) hours of operation, access to, and utilization of the land, buildings, structures, utilities, and other support systems and equipment within the geographic and functional boundaries of the heliport.  </rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#HeliportService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#HeliportService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AerodromeFacilityService"/>
        <rdfs:comment rdf:datatype="http://www.w3.org/2000/01/rdf-schema#Literal">An aerodrome facility service category that describes services requiring the performance of tasks (by employee, contractor, or heliport personnel) to: 1) support the air carriers operating within the heliport: 2) respond to emergencies by offering fire, rescue, and accident services; 3) support the needs of passengers moving through the heliport; 4) ensure the safety and security of all activities, resources, personnel, and passengers within the heliport; and 5) maintain the proper operation of the heliport facility, its buildings, structures, systems, and equipment within the geographic and functional</rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#IncidentInformationService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#IncidentInformationService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationSafetyInvestigationInformationService"/>
        <rdfs:comment>An air transportation safety investigation service category that describes services providing information collected during a safety investigation of an air transportation incident (where the resulting injury, or property damage or loss did not meet the threshold criteria for an accident). </rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#NOTAMService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#NOTAMService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AeronauticalInformationService"/>
        <rdfs:comment>An aeronautical information service category that describes services for the purpose of providing time sensitive and critical information to airmen (especially pilots) concerning the establishment, condition, or change in any component (facility, service, or procedure of, or hazard in the National Airspace System) that is essential to conduct flight operations.</rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#PhysicalResourceSecurityService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#PhysicalResourceSecurityService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AirTransportationSecurityService"/>
        <rdfs:comment rdf:datatype="http://www.w3.org/2000/01/rdf-schema#Literal">An air transportation security service category that describes services requiring the performance of tasks necessary to protect: 1) the national airspace; 2) flights within the airspace; 3) air transportation facilities; and 4) cargo and payloads on those flights and within those facilities.</rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#TrafficControlService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#TrafficControlService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AirTrafficControlService"/>
        <rdfs:comment rdf:datatype="http://www.w3.org/2000/01/rdf-schema#Literal">An air traffic control service category that describes services requiring the air traffic controller to supervise a specific volume of airspace and any implemented changes in sectors, airspace restrictions, and special use airspace in order to safely and efficiently direct aircraft navigating in the arrival/departure airspace.</rdfs:comment>
    </owl:Class>

    <!-- http://faa.gov/wsdom/1.1/faa-std-066#WeatherInformationService -->

    <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#WeatherInformationService">
        <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066#AeronauticalInformationService"/>
        <rdfs:comment>An aeronautical information service category that describes services for the purpose of providing time sensitive and critical information to airmen (especial air operators and pilots) who concerning the state of the atmosphere with respect to temperature, humidity, transmissivity, and condition. This acquisition of this information is necessary to adjust flight plans before and during their execution.</rdfs:comment>
    </owl:Class>
</rdf:RDF>

Appendix C: WSDOM service metadata examples

The semantic service description examples presented here are constructed based on enriched WSDOM ontology and proposed GeoSPARQL geometry extensions. The spatial coordinates used to describe service geometries are based on examples provided in Annex C of GeoSPARQL specification [2]).

All the following examples use the Simple Features relation family and WKT serialization.

Figure 16. Illustration of spatial data

Service metadata examples

<rdf:RDF
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
   xmlns:owl="http://www.w3.org/2002/07/owl#"
   xmlns:sfg="http://www.opengis.net/def/geometryType/OGC-SF/1.0/"
   xmlns:geo="http://www.opengis.net/ont/geosparql"
   xmlns:service="http://faa.gov/wsdom/1.1/Service"
   xmlns:tax="http://faa.gov/wsdom/1.1/faa-std-066"
   xmlns:cat="http://tb12.ogc.aero/Catalogue#">

        <owl:Ontology rdf:about="http://tb12.ogc.aero/Catalogue">
                <rdfs:comment>Semantic service repository with minimalistic service descriptions containing only geometries and categories</rdfs:comment>
            <owl:imports rdf:resource="http://www.opengis.net/ont/geosparql"/>
        <owl:imports rdf:resource="http://faa.gov/wsdom/1.1/WSProfile.owl"/>
        <owl:imports rdf:resource="http://faa.gov/wsdom/1.1/faa-std-066"/>
                <owl:imports rdf:resource="http://faa.gov/wsdom/1.1/Stakeholder"/>
                <owl:imports rdf:resource="http://faa.gov/taxonomies/lifecycle-stage"/>
                <owl:imports rdf:resource="http://faa.gov/taxonomies/service-criticality"/>
        </owl:Ontology>

        <!-- Integration with GeoSPARQL classes and properties -->

        <owl:Class rdf:about="http://faa.gov/wsdom/1.1/faa-std-066#GeoWSProfile">
                <rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/geosparql#Feature"/>
                <rdfs:subClassOf rdf:resource="http://faa.gov/wsdom/1.1/WSProfile.owl#WSProfile"/>
        </owl:Class>

        <rdf:Property rdf:about="http://tb12.ogc.aero/Catalogue#hasExactGeometry">
                   <rdfs:subPropertyOf rdf:resource="http://www.opengis.net/ont/OGC-GeoSPARQL/1.0/hasGeometry"/>
                   <rdfs:subPropertyOf rdf:resource="http://www.opengis.net/ont/OGC-GeoSPARQL/1.0/defaultGeometry"/>
        </rdf:Property>

        <rdf:Property rdf:about="http://tb12.ogc.aero/Catalogue#hasPointGeometry">
                   <rdfs:subPropertyOf rdf:resource="http://www.opengis.net/ont/OGC-GeoSPARQL/1.0/hasGeometry"/>
        </rdf:Property>


        <!-- Instance-level statements -->

        <!-- A NOTAMService -->

        <tax:NOTAMService rdf:about="http://tb12.ogc.aero/Catalogue#A-NOTAM">
                   <service:hasProfile rdf:resource="http://tb12.ogc.aero/Catalogue#ProfileA"/>
                   <!--<service:hasInterface rdf:resource="http://tb12.ogc.aero/Catalogue#InterfaceA"/>
                   <service:hasImplementation rdf:resource="http://tb12.ogc.aero/Catalogue#ImplA"/>-->
        </tax:NOTAMService>


        <cat:GeoWSProfile rdf:about="http://tb12.ogc.aero/Catalogue#ProfileA">
                   <cat:hasExactGeometry rdf:resource="http://tb12.ogc.aero/Catalogue#AExactGeom"/>
                   <cat:hasPointGeometry rdf:resource="http://tb12.ogc.aero/Catalogue#APointGeom"/>
        </cat:GeoWSProfile>

        <sfg:Polygon rdf:about="http://tb12.ogc.aero/Catalogue#AExactGeom">
                   <geo:asWKT rdf:datatype="http://www.opengis.net/def/dataType/OGC-SF/1.0/WKTLiteral">
                      <![CDATA[
                        <http://www.opengis.net/def/crs/OGC/1.3/CRS84>
                        Polygon((-83.6 34.1, -83.2 34.1, -83.2 34.5,
                         -83.6 34.5, -83.6 34.1))
                      ]]>
                   </geo:asWKT>
        </sfg:Polygon>

        <sfg:Point rdf:about="http://tb12.ogc.aero/Catalogue#APointGeom">
                   <geo:asWKT rdf:datatype="http://www.opengis.net/def/dataType/OGC-SF/1.0/WKTLiteral">
                      <![CDATA[
                        <http://www.opengis.net/def/crs/OGC/1.3/CRS84>
                        Point(-83.4 34.3)
                      ]]>
                   </geo:asWKT>
        </sfg:Point>


        <!-- B WeatherInformationService -->

        <tax:WeatherInformationService rdf:about="http://tb12.ogc.aero/Catalogue#B-Weather">
                   <service:hasProfile rdf:resource="http://tb12.ogc.aero/Catalogue#ProfileB"/>
                   <!--<service:hasInterface rdf:resource="http://tb12.ogc.aero/Catalogue#InterfaceB"/>
                   <service:hasImplementation rdf:resource="http://tb12.ogc.aero/Catalogue#ImplB"/>-->
        </tax:WeatherInformationService>

        <cat:GeoWSProfile rdf:about="http://tb12.ogc.aero/Catalogue#ProfileB">
                   <cat:hasExactGeometry rdf:resource="http://tb12.ogc.aero/Catalogue#BExactGeom"/>
                   <cat:hasPointGeometry rdf:resource="http://tb12.ogc.aero/Catalogue#BPointGeom"/>
        </cat:ServiceProfile>

        <sfg:Polygon rdf:about="http://tb12.ogc.aero/Catalogue#BExactGeom">
                   <geo:asWKT rdf:datatype="http://www.opengis.net/def/dataType/OGC-SF/1.0/WKTLiteral">
                      <![CDATA[
                        <http://www.opengis.net/def/crs/OGC/1.3/CRS84>
                        Polygon((-83.6 34.1, -83.4 34.1, -83.4 34.3,
                                 -83.6 34.3, -83.6 34.1))
                      ]]>
                   </geo:asWKT>
        </sfg:Polygon>

        <sfg:Point rdf:about="http://tb12.ogc.aero/Catalogue#BPointGeom">
                   <geo:asWKT rdf:datatype="http://www.opengis.net/def/dataType/OGC-SF/1.0/WKTLiteral">
                      <![CDATA[
                        <http://www.opengis.net/def/crs/OGC/1.3/CRS84>
                        Point(-83.5 34.2)
                      ]]>
                   </geo:asWKT>
        </sfg:Point>


        <!-- C WeatherInformationService -->

        <tax:WeatherInformationService rdf:about="http://tb12.ogc.aero/Catalogue#C-Weather">
                  <service:hasProfile rdf:resource="http://tb12.ogc.aero/Catalogue#ProfileC"/>
                   <!--<service:hasInterface rdf:resource="http://tb12.ogc.aero/Catalogue#InterfaceC"/>
                   <service:hasImplementation rdf:resource="http://tb12.ogc.aero/Catalogue#ImplC"/>-->
        </tax:WeatherInformationService>

        <cat:GeoWSProfile rdf:about="http://tb12.ogc.aero/Catalogue#ProfileC">
                   <cat:hasExactGeometry rdf:resource="http://tb12.ogc.aero/Catalogue#CExactGeom"/>
                   <cat:hasPointGeometry rdf:resource="http://tb12.ogc.aero/Catalogue#CPointGeom"/>
        </cat:ServiceProfile>

        <sfg:Polygon rdf:about="http://tb12.ogc.aero/Catalogue#CExactGeom">
                   <geo:asWKT rdf:datatype="http://www.opengis.net/def/dataType/OGC-SF/1.0/WKTLiteral">
                      <![CDATA[
                        <http://www.opengis.net/def/crs/OGC/1.3/CRS84>
                        Polygon((-83.2 34.3, -83.0 34.3, -83.0 34.5,
                         -83.2 34.5, -83.2 34.3))
                 ]]>
                   </geo:asWKT>
        </sfg:Polygon>

        <sfg:Point rdf:about="http://tb12.ogc.aero/Catalogue#CPointGeom">
                   <geo:asWKT rdf:datatype="http://www.opengis.net/def/dataType/OGC-SF/1.0/WKTLiteral">
                      <![CDATA[
                        <http://www.opengis.net/def/crs/OGC/1.3/CRS84>
                                Point(-83.1 34.4)
                        ]]>
                   </geo:asWKT>
        </sfg:Point>


        <!-- D AeronauticalInformationService -->

        <tax:AeronauticalInformationService rdf:about="http://tb12.ogc.aero/Catalogue#D-AeronauticalInfo">
                   <service:hasProfile rdf:resource="http://tb12.ogc.aero/Catalogue#ProfileD"/>
                   <!--<service:hasInterface rdf:resource="http://tb12.ogc.aero/Catalogue#InterfaceD"/>
                   <service:hasImplementation rdf:resource="http://tb12.ogc.aero/Catalogue#ImplD"/>-->
        </tax:AeronauticalInformationService>

        <cat:GeoWSProfile rdf:about="http://tb12.ogc.aero/Catalogue#ProfileD">
                   <cat:hasExactGeometry rdf:resource="http://tb12.ogc.aero/Catalogue#DExactGeom"/>
                   <cat:hasPointGeometry rdf:resource="http://tb12.ogc.aero/Catalogue#DPointGeom"/>
        </cat:ServiceProfile>

        <sfg:Polygon rdf:about="http://tb12.ogc.aero/Catalogue#DExactGeom">
                   <geo:asWKT rdf:datatype="http://www.opengis.net/def/dataType/OGC-SF/1.0/WKTLiteral">
                      <![CDATA[
                        <http://www.opengis.net/def/crs/OGC/1.3/CRS84>
                        Polygon((-83.3 34.0, -83.1 34.0, -83.1 34.2,
                         -83.3 34.2, -83.3 34.0))
                        ]]>
                   </geo:asWKT>
        </sfg:Polygon>

        <sfg:Point rdf:about="http://tb12.ogc.aero/Catalogue#DPointGeom">
                   <geo:asWKT rdf:datatype="http://www.opengis.net/def/dataType/OGC-SF/1.0/WKTLiteral">
                      <![CDATA[
                        <http://www.opengis.net/def/crs/OGC/1.3/CRS84>
                        Point(-83.2 34.1)
                      ]]>
                   </geo:asWKT>
        </sfg:Point>



  <!-- E AerodromeFacilityInformationService -->

    <tax:AerodromeFacilityInformationService rdf:about="http://tb12.ogc.aero/Catalogue#E-AirportInfo">
                     <service:hasProfile rdf:resource="http://tb12.ogc.aero/Catalogue#ProfileE"/>
                     <!--<service:hasInterface rdf:resource="http://tb12.ogc.aero/Catalogue#InterfaceE"/>
                     <service:hasImplementation rdf:resource="http://tb12.ogc.aero/Catalogue#ImplE"/>-->
          </tax:AerodromeFacilityInformationService>

          <cat:GeoWSProfile rdf:about="http://tb12.ogc.aero/Catalogue#ProfileE">
                     <cat:hasExactGeometry rdf:resource="http://tb12.ogc.aero/Catalogue#FExactGeom"/>
          </cat:ServiceProfile>

          <sfg:Point rdf:about="http://tb12.ogc.aero/Catalogue#FExactGeom">
                     <geo:asWKT rdf:datatype="http://www.opengis.net/def/dataType/OGC-SF/1.0/WKTLiteral">
          <![CDATA[
            <http://www.opengis.net/def/crs/OGC/1.3/CRS84>
            LineString((-83.4 34.0, -83.3 34.3))
          ]]>
                     </geo:asWKT>
          </sfg:Point>

  </rdf:RDF>

        <!-- F AeronauticalInformationService-->

        <!-- an alternative if the service belongs to more than one category

        <owl:Thing rdf:ID="ObstacleInfoService" />

        <owl:Thing rdf:about="#ObstacleInfoService">
                  <rdf:type rdf:resource="tax:AeronauticalInformationService"/>
                  <rdf:type rdf:resource="tax:WeatherInformationService"/>
                  <service:hasProfile rdf:resource="http://tb12.ogc.aero/Catalogue#ProfileF"/>
        </owl:Thing>
        -->

        <tax:AeronauticalInformationService rdf:about="http://tb12.ogc.aero/Catalogue#ObstacleInfoService">
                   <service:hasProfile rdf:resource="http://tb12.ogc.aero/Catalogue#ProfileF"/>
                   <!--<service:hasInterface rdf:resource="http://tb12.ogc.aero/Catalogue#InterfaceF"/>
                   <service:hasImplementation rdf:resource="http://tb12.ogc.aero/Catalogue#ImplF"/>-->
        </tax:AeronauticalInformationService>

        <cat:GeoWSProfile rdf:about="http://tb12.ogc.aero/Catalogue#ProfileF">
                   <cat:hasExactGeometry rdf:resource="http://tb12.ogc.aero/Catalogue#EExactGeom"/>
        </cat:ServiceProfile>

        <sfg:LineString rdf:about="http://tb12.ogc.aero/Catalogue#EExactGeom">
                   <geo:asWKT rdf:datatype=
                     "http://www.opengis.net/def/dataType/OGC-SF/1.0/WKTLiteral">
          <![CDATA[
                        <http://www.opengis.net/def/crs/OGC/1.3/CRS84>
                        Point(-83.4 34.4)
                ]]>
                   </geo:asWKT>
        </sfg:LineString>

1.1. GeoSPARQL Queries

Example 1: Find all services that Service reg:A contains, where spatial calculations are based on reg:hasExactGeometry.

GeoSPARQL Example 1

PREFIX reg: <http://tb12.ogc.aero/Catalogue#>
PREFIX geo: <http://www.opengis.net/ont/geosparql#>
PREFIX geof: <http://www.opengis.net/def/function/geosparql/>
SELECT ?f
WHERE { reg:A-NOTAM service:hasProfile ?aProfile .
    ?aProfile reg:hasExactGeometry ?aGeom .
    ?aGeom geo:asWKT ?aWKT .
    ?f reg:hasExactGeometry ?fGeom .
    ?fGeom geo:asWKT ?fWKT .
    FILTER (geof:sfContains(?aWKT, ?fWKT) && !sameTerm(?aGeom, ?fGeom))
}

Example 2: Find all services that are within a transient bounding box geometry, where spatial calculations are based on reg:hasPointGeometry.

GeoSPARQL Example 2

PREFIX reg: <http://tb12.ogc.aero/Catalogue#>
PREFIX geo: <http://www.opengis.net/ont/geosparql#>
PREFIX geof: <http://www.opengis.net/def/function/geosparql/>
SELECT ?s
WHERE { ?s service:hasProfile ?f .
  ?f reg:hasPointGeometry ?fGeom .
   ?fGeom geo:asWKT ?fWKT .
   FILTER (geof:sfWithin(?fWKT,
     "<http://www.opengis.net/def/crs/OGC/1.3/CRS84>
     Polygon ((-83.4 34.0, -83.1 34.0,
        -83.1 34.2, -83.4 34.2, -83.4 34.0))"^^geo:wktLiteral))
}

Example 3: Find all service that touch the union of service reg:A-NOTAM and service reg:AeronauticalInfo, where computations are based on reg:hasExactGeometry.

GeoSPARQL Example 3

PREFIX reg: <http://tb12.ogc.aero/Catalogue#>
PREFIX geo: <http://www.opengis.net/ont/geosparql#>
PREFIX geof: <http://www.opengis.net/def/function/geosparql/>
SELECT ?s
WHERE { ?s service:hasProfile ?f .
  ?f reg:hasPointGeometry ?fGeom .
   ?fGeom geo:asWKT ?fWKT .
   reg:A-NOTAM reg:hasExactGeometry ?aGeom .
   ?aGeom geo:asWKT ?aWKT .
   ?reg:AeronauticalInfo reg:hasExactGeometry ?dGeom .
   ?dGeom geo:asWKT ?dWKT .
   FILTER (geof:sfTouches(?fWKT, geof:union(?aWKT, ?dWKT)))
}

Example 4: Find the 2 closest services to service reg:C-Weather, where computations are based on reg:hasExactGeometry.

GeoSPARQL Example 4

PREFIX uom: <http://www.opengis.net/def/uom/OGC/1.0/>
PREFIX reg: <http://tb12.ogc.aero/Catalogue>
PREFIX geo: <http://www.opengis.net/ont/geosparql#>
PREFIX geof: <http://www.opengis.net/def/geosparql/function>

SELECT ?f
WHERE { reg:C-Weather service:hasProfile ?cProfile .
    ?cProfile reg:hasExactGeometry ?cGeom .
    ?cGeom geo:asWKT ?cWKT .
    ?f reg:hasExactGeometry ?fGeom .
    ?fGeom geo:asWKT ?fWKT .
    FILTER (?fGeom != ?cGeom) }
    ORDER BY ASC (geof:distance(?cWKT, ?fWKT, uom:metre))
    LIMIT 2

Example 5: Which service provides NOTAM messages for a given geographical region?

GeoSPARQL Example 5

PREFIX reg: <http://tb12.ogc.aero/Catalogue#>
PREFIX geo: <http://www.opengis.net/ont/geosparql#>
PREFIX geof: <http://www.opengis.net/def/function/geosparql/>

SELECT ?service
WHERE { ?service rdf:typeOf tax:NOTAMService .
?service service:hasProfile ?p .
?p reg:hasExactGeometry ?geo .
?geo geo:asWKT ?fWKT .
FILTER (geof:sfWithin(?fWKT,
  "<http://www.opengis.net/def/crs/OGC/1.3/CRS84>
  Polygon ((-83.6 34.1, -83.4 34.1, -83.4 34.3, -83.6 34.3, -83.6 34.1))"^^geo:wktLiteral))}

Example 6: Find a service within a radius of 50 NM, which can provide airport informations?

GeoSPARQL Example 6

PREFIX reg: <http://tb12.ogc.aero/Catalogue#>
PREFIX geo: <http://www.opengis.net/ont/geosparql#>
PREFIX geof: <http://www.opengis.net/def/function/geosparql/>

SELECT ?service
WHERE { ?service rdf:typeOf tax:AerodromeInformationService .
?service service:hasProfile ?p .
?p reg:hasExactGeometry ?geo .
?geo geo:asWKT ?fWKT .
FILTER (geof:distance(?fWKT, "<http://www.opengis.net/def/crs/OGC/1.3/CRS84>
  Point (-83.4 34.4)"^^geo:wktLiteral, units:m) < 75000)}

Appendix D: Revision History

Table 7. Revision History
Date	Release	Editor	Primary clauses modified	Descriptions
February 29, 2016	.1	A. Balaban	all	initial version
June 10, 2016	.2	A. Balaban	all	Pre draft version 1
July 16, 2016	.3	A. Balaban	all	Draft version 1
Aug 01, 2016	.3	A. Balaban	all	Draft version 2
Aug 09, 2016	.3	A. Balaban	all	Draft version 3