Publication Date: 2017-05-12

Approval Date: 2016-12-07

Posted Date: 2016-11-03

Reference number of this document: OGC 16-046r1

Reference URL for this document:

Category: Public Engineering Report

Editor: Martin Klopfer

Title: Testbed-12 Semantic Enablement Engineering Report

OGC Engineering Report


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


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


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

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


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

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

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

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

Table of Contents

The requirement for capabilities supporting semantic understanding and reasoning in geospatial intelligence (GEOINT) is an all-encompassing paradigm shift from the past. Standards play a critical role in ensuring this is accomplished in a consistent and repeatable manner. Semantic standards and services supporting semantic capabilities are at a relatively early stage of development. Interoperability between semantic standards for encoding relationships and Web based services for discovery, access, retrieval and visualization of those relationships requires more testing and evaluation. This engineering report (ER) highlights the key findings and discussions from Testbed-12 that enable semantic interoperability, including semantic mediation, schema registries, and SPARQL endpoints. It references key findings from the Semantic Portrayal ER and helps to understand the current OGC discussion on semantics in general.

Business Value

With the opening of previously closed environments, where locally defined semantics using arbitrary approaches have been sufficient, and the increasing ad-hoc re-use of externally provided data and processing services, standardized provision of semantics has become an essential element of interoperability. Only standardized approaches enable efficient automated integration of geospatial information and ensure correct application of externally provided processes, functions, or operations. Standardized explicit semantics enable provenance of data and can improve visualizations and querying of geospatial data. Each system that uses or produces data or offers services across limited local contexts gains in business value if the meaning of data and services can be uniquely obtained in a cost-efficient automated fashion.

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

This ER summarizes the work performed in Testbed-12 and provides an outlook on possible future activities. It serves as a starting point for the OGC community in general and the Geosemantics Domain Working Group (DWG) in particular to understand some of the latest discussions on semantics in geospatial contexts. It provides a number of references to more detailed material to facilitate more in-depth research and analysis.

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

This ER does not reflect on the work of the Geosemantics DWG. It concentrates on summarizing these activities performed in Testbed-12 that are of relevance to the working group.


ogcdocs, testbed-12, semantics, RDF, OWL, SHACL

Proposed OGC Working Group for Review and Approval

Geosemantics DWG

1. Introduction

1.1. Scope

This engineering report (ER) summarizes the work performed in Testbed-12 on modeling and serialization of geospatial semantics in the context of heterogenous distributed geospatial information processing systems. It serves as a starting point for the OGC community in general and the Geosemantics Domain Working Group (DWG) in particular to understand some of the latest discussions on semantics in geospatial contexts. It provides a number of references to more detailed material to facilitate more in-depth research and analysis. It provides an outlook on possible future activities.

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

Martin Klopfer

Frisia IT

1.3. Future Work

No future work is planned to this document, but a number of work items and recommendations have been identified that should be addressed in future OGC interoperability program initiative (see Future Work).

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.

  • OGC 16-059, Testbed-12 Semantic Portrayal, Registry, Mediation Services ER

  • OGC 16-062, Testbed-12 Catalogue, SPARQL ER

  • OGC 16-020, Testbed-12 UGAS ShapeChange ER

  • OGC 16-051, Testbed-12 Javascript, JSON, JSON-LD ER

  • OGC 16-039, Testbed-12 Aviation Semantics ER

3. Terms and definitions

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

3.1. Semantics

The meaning of expressions

3.2. Syntax

Way of expressing the meaning

4. Overview

This ER serves as an entry point to Testbed-12 semantics. It integrates discussions from all threads that addressed work items being directly relevant to semantics. These threads include Aviation and Linked Data and Advanced Semantics for Data Discovery and Dynamic Integration.

The main document starts with a short overview of semantics for geospatial systems, followed by an overview of previous work from Testbed-10 and Testbed-11. It discusses the current situation in OGC and outlines areas that would benefit most from Semantic Enablement. Chapter Previous Work summarizes semantic enablement work performed in Testbed-12 and helps understanding the activities in the broader OGC semantic enablement context. In detail, it describes the main outcomes from discussions on semantics as part of semantic portrayal, catalogs, UML to RDF mapping, JSON-LD, and the aviation thread. Chapter Future Work provides an outlook on future activities that require more research to further improve OGC semantic enablement.

The following figures provides an overview of the various work items addressed herein.

Figure 1. Overview of Semantic Work Items

Within the LDS thread, the REST discussion addressed association types; the GFM (General Feature Model) discussion addressed associations as first class objects that can have properties and associations to other objects; the Catalog sub-thread experimented with enhanced models to support semantic search on traditional catalog services; semantic mappings have been explored as part of Portrayal and schema registry experiments. The overall goal was to enhance the OGC architecture towards higher levels of semantic interoperability without revolutionary changes that would void all existing technologies, products, and operational systems. This report will highlight where the journey may lead to where applicable.

5. OGC Semantic Enablement

The goal of this engineering report is to understand how OGC technology can adopt technologies and best practices from the Semantic Web in order to improve user’s experience when working with spatiotemporal data. The term Semantic Web is used here rather broadly and includes aspects that others may categorize as Linked Data.

5.1. Geospatial Semantics

Semantic issues in spatial data sharing and service interoperability have been recognized in the literature for a long time. Bishr summarized interoperability issues in 1998 under the terms semantic heterogeneity, schematic heterogeneity, and syntactic heterogeneity. Though the latter two have been addressed pretty successfully with GML and OGC Web service interface standards, semantic heterogeneity still causes several problems. These include

  • discovery of data sets and services based on keywords,

  • rigid metadata structures,

  • missing semantics on technical terms,

  • missing matching capabilities for equivalent or related terms or symbols

The Spatial Data on the Web Working Group is investigating some of these aspects, so it is certainly worth to consult their website for additional information.

5.2. Semantic Web Technologies

As mentioned before, OGC Testbed-10 Cross Community Interoperability (CCI) Ontology Engineering Report, and OGC Testbed-11 Implementing Linked Data and Semantically Enabling OGC Services Engineering Report provide already a good overview of existing Semantic Web technologies. For that reason, we will use a slightly different approach here and forgo having a general detailed introduction to Semantic Web concepts. Instead, we will reflect on the latest OGC Testbed discussions relevant to semantics, put these in context and reference or explain underlying concepts as necessary.

As discussed above, the overall goal is to move on from syntactic and schematic interoperability to semantic interoperability for geospatial data sharing over the Web; and to search and access geospatial Web services by content rather than just by keywords in metadata. This should be achieved using a number of technologies, such as ontology, semantic descriptions of geographic information using ontology, the ontology-based catalogue service, and Web service composition. Testbed-12 addressed semantics with focus on the aspects illustrated in figure below:

Figure 2. Overview of Semantic Work Items with Testbed-12 work (green) and future strategy (orange)

6. Previous Work

Previous testbeds have addressed a number of semantics aspects already. Major contributions have been made in particular in Testbed-10 and Testbed-11.

During the Testbed-10 effort, Image Matters identified, designed and formalized a set of modular geospatial core and cross-domain ontologies in OWL (mereo-topology, spatial relations, locations, features, temporal ontologies, geometries, CRS, events, measures, etc.). These “ontology components” provide a core ontological foundation for geospatial information that is universally applicable to any domain. These core ontologies leverage existing standard abstract models (ISO 19xxx), but are modularized and adapted to better leverage the expressiveness of OWL and favor reusability. The resulting Geospatial Ontology can be used as a starting point for building the OGC ontological foundation for all common geospatial information that could be used across various domains (E&DM, Law Enforcement and Public Safety, Gazetteer, Hydrology, Aviation, etc). Unfortunately, this work has not attracted the necessary attention and needs to be addressed in future testbed activities.

OGC document 15-054 that results from Testbed-11 provides a detailed overview of Semantic Web and Linked Data. Interested readers find in 15-054 discussions of the following topics:

Semantic Web

Linked Data


Linked Data Platform API






RDF Data Cube



Despite the research efforts in Testbeds 10 and 11, there is more work ahead in order to move from the traditionally hierarchical OGC data models towards graph based models and to fully implement the power and flexibility of these graph based models in OGC service and resource contexts.

7. Semantics and Links in REST APIs and the General Feature Model

One of the most active threads in Testbed-12 was the development of the REST user guide and REST Architecture Engineering Report. Though the discussion circled around the syntactical interoperability level at the beginning, it addressed more and more semantic aspects as it matured. Here, we will discuss the general issue when it comes to semantics and REST APIs. A number of aspects discussed in the following paragraphs are not restricted to REST APIs, but apply similarly to W*S implementations. Nevertheless, we use the REST API discussion here to introduce the general situation around hypermedia formats, REST API description languages, the goal of declarative programming, and the crux with custom media types.

7.1. Links Between Resources

To introduce the topic, let’s quickly recap the principles of declarative programming. Declarative programming allows separating logic from control flows, thus allows programmers to describe the intended behavior and let the software do the magic of rendering it correctly. The best example is a static Web page written in HTML. The browser will use the declarative HTML language and translates it into commands the browser software understands in order to render the page correctly. If the HTML code contains some links to images or other resources, the simple page converts into a hypermedia application, consisting of a set of representations conforming to standard media types that are interconnected via hyperlinks. The user can navigate from one page to the other and the various pages turn into finite state machines; each page representing an allowed state and links specifies allowed transitions. If the content of the page is changed, the browser can still render the new webpage without any changes to the browser code. Translated to geospatial data, it means that data content can be changed without the need to change the client rendering/processing the data; clients become generic and support all data that is compliant to a specific set of rules and constraints.

Back to the REST APIs, the goal is to allow exploring geospatial data the same way as exploring the Web. A client requests a resource from a server and starts following links to other resources. It is the underlying HTTP infrastructure that makes this work, which consists of three key aspects [3]:

  1. resolving of URIs to access other resources

  2. resources that know how to process requests via a uniform interface

  3. clients that know how to render representations that conform to standard Internet Media Types

The challenge now is to move from manual link-following (as a human) to automated link-following (as a machine); with potential intermediate levels in between. From a syntactic interoperability perspective, it is necessary to be able to read the represented linked resource. From a semantic perspective, it is necessary to understand its content and relationship to the resource it was linked from. The first aspect can be handled by standardized media types. The latter requires two things: first custom-made media types, and annotated hyperlinks that define the type of relationship between resources. The following figure illustrates this aspect. Two resources, a mall and a river, are associated in the form that the mall is located north of the river. Syntactic interoperability is ensured by standardized link encodings and Internet media types. To ensure semantic interoperability, is it further necessary to have custom made association types that explain isNorthOf sufficiently (to a machine). The content itself is either a standard media type, i.e. a image/png of the river, or a custom made media type, e.g. application/geojson or application/gml+xml; again sufficiently semantically annotated.

Figure 3. Associations between resources

Let’s start with the hypermedia links. Hypermedia formats are particularly important when APIs need to support associations between resources. The ISO 19109 General Feature Model (for a detailed discussion of the GFM, see Testbed-12 engineering report OGC 16-047) defines the metaclass GF_AssociationType to define associations between the principal elements of the model, the GF_FeatureTypes. Given that GF_AssociationType is a subclass of GF_FeatureType, associations can be modeled as first class objects, as they directly inherit from GF_FeatureType. Alternatively, they can be implemented as simple UML associations between two classes that represent different feature types. Ideally, this flexible association mechanism is fully supported by hypermedia formats, which means that associations can be either typed or implemented as objects with properties.

Reflecting the current discussion on REST in OGC, hypermedia formats are particular important for API design, though hypermedia plays an important role in other contexts as well. According to Zazueta [2] and adopted herein, an API supports hypermedia when it does the following:

  • Each resource points to related resources and available actions using the method native to its protocol (i.e. using URIs over HTTP).

  • Each resource clearly defines its media type so a client knows what it’s parsing (i.e. by providing a MIME type in the “Content-Type” response header) and responds appropriately when requested to return a specific media type (i.e. when a client lists it specifically in the “Accepts” request header).

  • Each resource points to a machine-readable description of how to parse its media type. (i.e. through one of the many emerging API descriptor languages, such as I/O Docs, Swagger (now Open API Initiative (OAI)), RAML and Blueprint).

What does it mean in the context of OGC? In any OGC service response, independently of being a traditional W*S or a REST(ful) implementation, hypermedia formats play the crucial role of encoding links to other resources (resources being data or other services). Following these links confronts the user with the problem of handling different Internet media types, as links may point to other services, video streams, audio files, or XML or JSON encoded feature collections. In any case, the client application needs to be prepared to handle these types. In the case of exploring the Web, browsers commonly have in-built support for a variety of Internet media types, such as text (e.g. text/plain), image files (e.g. image/png), audio and video. In case an Internet media type is not supported, there are often plug-ins available and browsers know how to discover and install appropriate plugins. Though a few more clicks for the user, it’s still a smooth user experience. In addition, browsers can adapt to new types by either adding internal type handling or by loading another plug-in. The same smooth user experience needs to be generated for spatiotemporal data exploration and usage. Links from one resource to any other resource need to carry sufficient information to allow understanding the Internet media type of the linked resource and the link association type. Otherwise, a link "liegt südöstlich von" or "ist Mittelpunkt von" stops further state transitions if the link does not make sense to the user. Thus, it is absolutely essential to provide an ontology with typical link types. This ontology needs to be made permanently available online under the supervision of the OGC Naming Authority and should include a wide set of geo-spatially relevant link types. The ontology needs to be aligned with existing link type registries, such as the IANA link relations or Dublin Core (see future work section also).

Exact semantics of link types are just a first step towards semantic interoperability. Link types allow understanding aspects such as a resource isVisualizedIn a map, or isPartOfCollection, but full semantic interoperability is only achieved if the linked resource is sufficiently annotated. Providing the Internet media type of the resource is a first important step that allows processing linked resources, but Internet media types such as text/xml or application/json only describe the serialization. It remains at the syntactical level, i.e. the client application can read the resource, but does not understand it. As an example, making sense of a coverage requires understanding the internal structure of the coverage serialization in order to e.g. display the coverage on a map, which is all on the syntactical level. Once it comes to making sense of the displayed coverage, understanding the value type "Mittlere Jahreswindgeschwindigkeit" is essential.

In summary, a link to a spatiotemporal resource needs to carry additional information in order to allow full understanding of the linked resource(s). The ultimate goal is the development of a semantically sound declarative language for geospatial data. This language would allow clients to render all geospatial data in a way perfectly aligned with user’s expectations without the need to change anything programatically. To achieve this goal, a number of ontologies need to be made available. In this context, the OGC should concentrate on the semantics of geospatial link types.

7.2. REST API Description Languages

With The Open API Initiative (OAI), Hypertext Application Language (HAL), JSON-LD, Hypermedia-Driven Web APIs (Hydra), and Siren, there exist a number of hypermedia formats that allow linking resources. Future IP initiatives should investigate these formats and develop recommendations on how to integrate which type into the OGC meta architecture.

8. Semantic Enablement in Testbed-12

The following chapter summarizes the activities performed in Testbed-12 that are relevant to OGC Semantic Enablement and provides guidance for future activities required to explore the applicability of Testbed-12 results to real world situations. Semantic activities have been subject of two threads: Linked Data and Advanced Semantics for Data Discovery and Dynamic Integration (LDS) and Aviation (AVI). Whereas the first thread addressed semantics in a domain-neutral manner, the latter focused on specific requirements and aspects applicable to the aviation community.

As with all experiments featuring semantic mediation, future testbeds need to focus more on actual implementations of the developed ontologies, service interfaces, and data exchange models and formats. The current work provides a great start, but only future experiments will allow proper evaluation of the results produced in Testbed-12. It is recommended to develop an entire semantic exploration thread with a number of actual components implementing the ontologies developed herein, providing mappings between ontologies, and supporting the developed APIs. These future activities should not develop yet another stack of technologies, but implement was has been reported in Testbed-12.

In addition, what is currently missing is a complete guidance on "geospatial - the semantic way". To realize automatic search and discovery of geospatial feature data at the semantic level, various challenges have to be matched depending on the maturity of the system or data at hand. If new data is provided, the challenge will be how to match geospatial features to a predefined geospatial ontology. If the data is already available and organized according to a domain ontology, the challenge is how to map between different feature types from various ontologies that are not perfect matches. Though subject of substantial research, automated schema mapping between feature types is still a huge challenge and currently not ripe for operational systems. The approaches taken in Testbed-12 feature manual mappings to mitigate the problem. Nevertheless, in order to better understand where OGC currently stands in terms of operationalization of its semantic research work, we recommend extensive tests with real world data/scenarios.

The following paragraphs use material from other Testbed-12 Engineering Reports. As re-used text has often be modified, quotations are not highlighted. This summary is based on the following underlying reports:

  • OGC 16-020 Testbed-12 ShapeChange Engineering Report

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

  • OGC 16-051 Testbed-12 Javascript-JSON-JSON-LD ER

  • OGC 16-059 Testbed-12 Semantic Portrayal, Registry and Mediation Engineering Report

8.1. Semantic Models and Integration of Semantic Services

Testbed-12 work outside of the aviation thread focused on the integration of Semantic Web technologies into Spatial Data Infrastructure data models and services with the goal to improve OGC data discovery, exchange, representation and visualization closely. The following diagram illustrates these concepts.

Figure 4. Overview of semantic services

8.1.1. Semantic Registry Information Model and Semantic Registry Service

The optimal provisioning of metadata is still subject to debate. A number of standards are available to express metadata, all of them focusing on particular requirements, serialization models, or encodings. The virtual goal is the development of a metadata structure that allows the discovery of all other objects, services, and metadata that are associated to any single object. This approach requires a graph structure with associations between individual objects that are themselves first class citizens, i.e. objects with properties and potentially further links to other objects (see previous chapter on links between resources in addition to the Testbed-12 report on the General Feature Model).

Traditionally, metadata standards in the Geospatial domain have focused on either data or service descriptions, but rarely addressed links between objects or associations to particular object portrayal or other processing services. To overcome these shortcomings, Testbed-12 analyzed a number of metadata standards including W3C standard DCAT, DCAT-AP, GeoDCAT-AP, ADMS, Project Open Data 1.1, Dublin Core, ISO 19115, and ISO 19119 to identify the common and relevant metadata information needed for search and discovery. Testbed-12 also identified gaps in existing standards to provide a complete dataset description, including service, portrayal information, schema and schema mapping. These efforts resulted in the development of the Semantic Registry Information Model (SRIM), and the Semantic Registry Service. SRIM is defined as superset of DCAT and its existing application profiles (DCAT-AP, GeoDCAT-AP, ADMS) and introduces a superclass of dcat:Dataset called srim:Item. The reason not to use DCAT exclusively is the strict focus of DCAT on data; excluding other elements such as e.g. services or map layers. SRIM enables the integration of different metadata providers (CSW, CKAN, POD, WMS, WCS) by providing a common core vocabulary to describe resources (data, services, vocabularies, maps, layers, schemas, etc.) and to accommodate specificities of each source by leveraging the built-in extensibility mechanism in OWL. SRIM has been defined in UML and serialized in RDF and JSON. The JSON serialization has been closely aligned with the Project Open Data metadata schema 1.1 standard. However, to accommodate some of the requirements needed by the Semantic Registry Service it has been extended and partly modified.

The Semantic Registry Service implements the Semantic Registry Information Model and allows acting as a proxy between a client and any number of catalog services. Passing on clients' search requests to OGC CSW instances requires the dynamic query-rewriting to bridge between the various service metadata encodings models and formats and the Semantic Registry Service JSON encoding supported by the service’s REST API. This aspect needs to be implemented and further explored in future testbeds. The Testbed-12 implementation focused on a harvesting approach, where metadata elements from CSW services have been harvested and locally converted in order to fit the Semantic Registry Information Model.

8.1.2. Semantic Portrayal

The initial implementation of the Semantic Portrayal Service during the OGC Testbed-11 focused on defining styles, portrayal rules, point-based symbols and graphics to enable Web Processing Services to produce SLD documents. Testbed-12 now broadened the focus to include in particular symbology styles for lines, areas, and texts based on existing standards such as Symbol Encoding and Styled Layer Descriptor, SVG, ISO 19117, and KML. All portrayal information is captured in a set of microtheories, including a style ontology, a symbol ontology, a graphic ontology, and a portrayal catalog ontology. All semantic portrayal information (i.e. styles, rulesets, symbol-sets, and symbols) has been made available through a hypermedia-driven REST-based API.

8.1.3. Semantic Mediation

The semantic mediation work in Testbed-12 was closely related to the semantic portrayal work described above and built on the achievements from Testbed-11. OGC 15-058, Symbology Mediation Engineering Report from Testbed-11 describes the basic principles of semantic mediation using the example of two portrayal ontologies that need to be aligned in an ad hoc manner. Testbed-12 now focused on the usage of a schema registry to store information about schemas and schema mappings to support ad hoc transformations between source and a target schemas, see chapter semantic registry. Schema mappings can be considered a simple form of semantic mediation, but go without explicit formalization of the underlying semantic knowledge required to map from one schema to another. For that reason, the idea was to design Semantic Mediation Service REST API and integrate it with the Semantic Registry and CSW ebRIM profile for Schema Registry.

8.1.4. Semantic Catalogs

The OGC approach to support data and service discovery is the Catalog Service for the Web (CSW). The current versions of the CSW are supporting syntactical and schematic interoperability. CSW support searches by temporal and spatial dimensions, keywords, and well defined terms organized in the service taxonomy (e.g. search for a specific service type); an approach that is insufficient for automatic service discovery based on data contents. Service brokers that mediate between a client and catalogs or other services can only partly mitigate that problem, despite being loaded with additional knowledge (which is a very complex and cumbersome task).

In particular the keyword-based search approach, which uses a lexical comparison between search and target terms, often leads to poor discovery results because the keywords in the query may be semantically similar but syntactically different, or syntactically similar but semantically different from the terms in a Web service description. Thus, traditional keyword-based search approaches are inherently restricted by the ambiguities of natural languages.

8.2. UML to OWL/RDF Mapping

Testbed-12 experimented with deriving an ontology representation of an application schema (using RDF(S)/SKOS/OWL) - to support Semantic Web / Linked Data implementations. Application schemas are a key enabler of interoperable information exchange. They define the structure and semantics of geographic features for a specific domain, community, or application. Numerous application schemas exist, for example in the defense and intelligence as well as aviation domains.

Traditionally, XML Schemas have been derived from application schemas, based upon the encoding rules of the Geography Markup Language (GML). These schemas are used for exchanging XML encoded geographic information in an interoperable way. OGC 16-020 defines rules for converting an application schema into an OWL ontology. The design is based upon the conversion rules defined by ISO 19150-2. A number of configuration options as well as additional conversion rules provide a higher level of control and flexibility when deriving an ontology compared to the conversion rules defined by ISO 19150-2. Converting an application schema into an ontology results in a key component that can be used by web applications. The ontology defines the concepts for encoding geographic information in machine-processable representation languages (RDF/OWL/SKOS). RDF data published on the web supports linking between different datasets. The ontology makes conceptual knowledge available for automated reasoning over RDF data. Combined, this can unlock new information.

8.3. JSON-LD

The experiments in Testbed-12 on JSON-LD focused on the UML to JSON-LD mapping without using XML as an intermediate step. The work primarily addressed technical details of the conversion process and the usage of JSON schema for further validation processes. From a semantic perspective, these research activities play an important roles once it comes to integration efforts between various models and approaches. In this context, future work need to address real world situations where data serialized in JSON-LD, RDF and other formats need to be integrated, mapped, or aligned.

8.4. Aviation Semantic

Aviation semantics explores the usage of FAA Web Service Description Ontological Model (WSDOM) to improve service discovery within Spatial Data Infrastructures. The results of this work are documented in OGC 16-039r1, Testbed-12 Aviation Semantics Engineering Report. It starts giving a short introduction into the concept of semantic service description and discovery using the WSDOM [6] ontology while considering OWS' characteristics and specific needs by aviation traffic management. An overall goal is to integrate OGC technologies with aviation semantic web technologies, in particular those related to service and data discovery. The Testbed-12 focus was on semantic aviation service description for OWS compatible aviation services shall be interoperable with service description approaches based on OGC getCapabilities-request responses. At the same time, the power and expressiveness of query languages such as SPARQL and GeoSPARQL should be leveraged.