Testbed-12 Semantic Enablement Engineering Report

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.

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

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

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.

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

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.

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:

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

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.

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:

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.

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.

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.

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.

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.

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.