Developing and deploying Spatial Data Infrastructures based on OGC services is attractive for two reasons. First, these services are well standardized and their implementations can be tested for conformity. Second, the OGC has defined a top-level interface standard called OWS Common [1] defining main aspects that are shared by most OGC web services. Frequent testbeds investigate, report on, and discuss the interoperability between specific services. Both aspects ease the integration of services into Spatial Data Infrastructures, make them more adaptable, and form the basis for their orchestration [2].
Services, however, are not built for their own sake but to encapsulate data or processing models. To exchange data between services, i.e., to make them interoperable, they have to share common schemas or translate between them. For example, if one processing service requires a string representing wind direction as input and was developed with a wind blows from conceptualization in mind, a second service offering wind direction observations as strings, but based on a wind blows to conceptualization, can still act as input source [3]. The OGC standards guarantee interoperability on a syntactic level. Services can exchange data if they agree on names and types for their inputs, outputs, and operations. Whether data exchanged between services can be interpreted in a meaningful way is not covered by the specifications. For example, a Web Processing Service (WPS) [4] can be used to compute the dispersion of a gas plume caused by a factory fire based on wind direction observations delivered by a Sensor Observation Service (SOS) [5]. Both services need to share a common understanding of wind direction to compute meaningful results [3,6]; otherwise the simulated dispersion plume would point in the opposite direction. Hence, the challenge is to establish semantic interoperability, i.e., the ability of services to exchange data in a meaningful1 way and with a minimum of human intervention [7,8]. For instance, mapping national geodata models to the specifications of the INSPIRE initiative for a European SDI requires formal specifications of the national data models (as well as the INSPIRE model) [9]. So far, the mappings between these models have to be specified and tested outside of OGC services. There is no way to check on-the-fly whether a dataset has been consistently mapped or whether it contains contradictions. To perform such checks, the application schemas and the contained feature type definitions have to be downloaded manually in order to perform common reasoning tasks.
The remaining paper is structured as follows. First, we introduce related work on SWE and geo-semantics related to OGC services and SDI. Next, we discuss the idea of a horizontal and vertical semantic enablement layer and its integration with OGC services. We stick to the gas plume dispersion example throughout the paper as a running scenario. We conclude our work by summarizing the proposed approach and point to further work.
The Open Geospatial Consortium provides standards to geospatially enable the Web with the goal of making spatial data and services accessible in an interoperable way for all kinds of applications. The Sensor Web Enablement [10] initiative as one focus area of OGC's specification program develops standards to integrate sensors into Spatial Data Infrastructures. SWE incorporates different data models for describing sensors (SensorML [11]) as well as gathered sensor data (Observations & Measurements [12]). Additionally, web service interfaces are defined which make these models available to enable the discovery and controlling of sensors, the retrieval of sensor data, as well as alerts in case of particular events within a sensor network. A central role in this framework plays the Sensor Observation Service (SOS) [5] which provides a standardized interface for the pull-based access of both archived and near-realtime sensor observations and metadata.
Over the last years, work on semantics [13] and geo-ontologies has focused on several challenges towards establishing semantic interoperability between OGC services. This includes work on the role of ontology for spatio-temporal databases [14], the notion of semantic reference systems and the grounding of geographical categories [15,16], semantics-based and context-aware retrieval of geographic information [17][18][19][20], ontology alignment [21], as well as work on Semantic Geospatial Web services [22] and their chaining [23]. This research has lead to several new services and tools such as ConceptVISTA2 for ontology creation and visualization, the SWING Concept Repository3 , the SIM-DL similarity server and Protégé plug-in 4 , or the semantically-enabled Sensor Observation Service Sem-SOS [24]. Opposed to work on Spatial Data Infrastructures, these services do not share common interfaces but are isolated solutions which lack a binding to each other and partially also to existing OGC services. For instance, while the SIM-DL server can compute the similarity of geographic feature types, it uses an extended version of the Description Logics Interface Group (DIG) protocol for communication and the Web Ontology Language (OWL) for knowledge representation 5 . In contrast, OGC services such as the Web Feature Service (WFS), which could be chained with the similarity server, use GetCapabilities requests and the Geographic Markup Language (GML).
To integrate Semantic Web services into SDI we propose a transparent Semantic Enablement Layer (SEL) for OGC services. It resides on top of recent standards and considers the following three challenges: (1) How to link data encodings and service protocols to formal specifications stored within ontologies? (2) How to manage and maintain these ontologies? (3) How to incorporate reasoning services known from the Semantic Web?
Based on these challenges we can derive functionalities, which should be provided by the SEL (see Table 1). For further structuring, we categorized atomic functionalities into four conformance classes. Storage groups functionalities which are required for ontology storage, evolution, and access. The functionality to connect elements of a specific resource, e.g., a GML or RDF data model, with concepts or instances from an ontology is provided by the Lookup and Retrieval conformance class. Reasoning groups operations about inferring hidden facts as well as adding new ones, while the Deployment functionality supports the deployment of OGC services if their data models have been encoded in ontologies. Such deployment includes the generation of a content description for an OGC web service which is advertised in its capabilities document, as well as an automated creation of descriptions of resources such as feature type serializations using XSD. This functionality ensures explicit linkages between services and content descriptions Table 1. Overview of SEL run-time functionalities.
• createOntology: creates a new ontology with all its classes and relations inside the repository.
• updateOntology: registers a new version of an ontology to the repository.
• getConcept, getRelation, getOntology: returns different types of elements from a registered ontology.
• getModelReference: returns the appropriate ontology element ID for a given resource ID, e.g., GML Feature ID.
• retrieve: executes semantic matchmaking between a goal/query and (a) available web service advertisements and (b) feature type definitions.
• loadOntology: loads a specific ontology into the reasoner.
• releaseOntology: removes a specific ontology from the reasoner.
• tells: inserts a new fact into the knowledge base.
• asks: returns facts from the knowledge base.
• createCapabilities: creates content-specific section of an OGC Capabilities Document.
• createFeatureTypeDescription: creates a GML feature type in XSD format (created file may contain annotations).
We propose to group the functionalities of the conformance classes in two services, the Web Ontology Service (WOS) for managing and accessing ontologies and the Web Reasoning Service (WRS) for providing reasoning functionality within SDIs. Instead of creating new services from scratch, the WOS is defined as a profile of the Web Catalog Service (CS-W) and the WRS as a profile of the Web Processing Service (WPS). This facilitates the integration with existing SDI technologies and simplifies the service orchestration. As WRS and WOS have to follow the OWS Common specification, a major challenge is the mapping between the protocols and representation languages used on the Semantic Web and the OGC world. Note that we do not propose to develop separate reasoners or ontology repositories for SDI but to transparently encapsulate existing Semantic Web solutions by the WOS and WRS.
Components, which support the creation of semantic annotations, i.e., which provide means to link elements from data model to concepts from an ontology, are not considered in this setting. Such components are not used during SEL run-time, but in a previous development phase. Examples of supporting tools are given in [25]. They can be used to generate content for successful lookup. The semantic annotation of OGC services as well as the WOS and the WRS are explained in more detail in the following subsections.
We illustrate the integration of the proposed services into SDI using the gas plume example. We assume that air pollutants peril an important European bird sanctuary, the so called Rieselfelder in Münster (Germany), as well as the surrounding natural reserves. For reasons of simplification, we further assume that a local Sensor Web is already set up and used by a disaster relief organization, i.e., mobile sensors are deployed to monitor air pollutants, wind speed, and wind direction.
Service operations such as GetCapabilities and data encodings such as SensorML describe the functionality and data offered by a specific OGC service. This includes sensor inputs and outputs in case of SensorML, and a list of contained geographic feature types in case of a Web Feature Service's capabilities document. Currently, the descriptions of these resources are only syntactic, e.g., encoded in GML. If additional descriptions are contained, they mostly consist of plain-text. A first step towards semantic enablement is to annotate these elements of the General Feature Model [26]. Semantic annotation links them to the according classes specified within ontologies. Recently, Maué et al. [27] proposed a methodology for the annotation of OGC services. The authors suggest three different levels of (semantic) annotations. They distinguish between the annotation of resource metadata, e.g., an OWS Capabilities Document, of a data model, e.g. a GML Application Schema, and of data entities, such as a GML file. Annotations may point to information source ontologies, a specific form of application ontologies, or to shared domain ontologies. Figure 1 provides an example for annotating an OGC SOS. Level 1 links the keywords of a capabilities document to concepts from a domain ontology, NaturalReserve in this case. The connection between the application schema to an application ontology is illustrated in level 2, while linking features to concepts from a domain ontology is depicted at the bottom of the figure (level 3). Listing 1.1 shows an example of an InsertObservation request offered by an SOS. By invoking this operation new sensor observations can be fed into the SOS. For example, the element of the observed property contains an attribute that links to an external resource. Following Maué et al. [27], the links are implemented as SAWSDL model references [28]. The model references point to concept (e.g. WindDirection) or instance (e.g., Anemometer01 and Rieselfelder ) identifiers from a populated ontology. The formal specifications of these concepts can then be used for tasks such as semantics-based information retrieval. Note that the annotations may refer to concepts or individuals from a resource or domain ontology.
While annotations establish links between elements of data and service models to concepts, individuals, and relations in ontologies, these ontologies need to be stored and managed in repositories [29]. Typically, ontology repositories act as interfaces offering access and URI resolution as well as auxiliary services for querying, visualizing, versioning, and comparing the stored definitions 6 . With regards to SDIs built on OGC services, a decomposition of the functionality into separate services would be more appropriate (comparable to the separation of WFS and WMS). We therefore argue that a Web Ontology Service should provide access, lookup, and retrieval functionalities. A WOS could provide access to definitions from multiple domains ranging from geographic feature types over types of observations, to sensor types. In case of the gas plume example, a particular WOS could store feature types such as Factory, NaturalReserve, and InhabitedPlace, as well as sensor types such as Anemometer. By providing access to the formal specifications, a WOS could support a semantic mapping between sensor outputs and the properties of features of interest when registering new sensors or adding their observations to a Sensor Observation Service [6].
A WOS serves two requirements. First, it provides access to formal specifications for the elements annotated in data encodings and service operations. Second, and in conjunction with a Web Reasoning Service, a WOS can be used for semantics-based information retrieval. In this sense, a WOS is a semanticallyenabled catalogue supporting information retrieval beyond simple keyword search [17,18]. Therefore and in conformity with Lieberman et al. [30], we argue that a WOS should be designed as a profile of the OGC Catalogue Service (CS-W) [31]. Thereby, it abstracts from spatial and temporal search, while focusing on thematic aspects. As ontologies in general require specific querying, the Filter Encoding standard [32] requires an according profile. In conjunction with the CS-W it provides novel means to sophisticated retrieval of geospatial data and services. The enhanced filter encoding may even be re-used by other OGC service types, such as WFS or SOS in order to enhance data querying capabilities.
Using the gas plume scenario, Figure 2 illustrates how the WOS can support the transparent gathering of relevant data, e.g., sensor observations. A WOS is queried for all subtypes of NaturalReserve which are located within a particular bounding box, e.g., the greater Münster area. To process such a query, the WOS utilizes an associated Web Reasoning Service. The WOS response contains all feature types satisfying the input query, e.g., Bird Sanctuary. These types can be used in further discovery tasks to find features of interest affected by the fire and gas plume.
An OWL-Profile for CS-W was suggested recently by Stock et al. [33]. The authors suggest a non-transparent approach, which restricts the format (in their case OWL) and reasoning capabilities (in their case reasoning on description logics). In contrast, we propose a transparent approach which abstracts from a particular inference engine and from specific ontology languages such as OWL, OWL 2.0, Web Service Modelling Language (WSML), or Topic Maps.
While the Web Ontology Service encapsulates ontologies, a second service has to encapsulate the functionalities defined in the reasoning conformance class. This Fig. 2. Transparent integration of existing ontology repositories in to an SDI to support semantics-based lookup and retrieval using the Web Ontology Service as a CSW profile.
service has to bridge between the inference engines as key components of the Semantic (Geospatial) Web and the OGC world. Reasoners are not restricted to subsumption reasoning, but include non-standard inference such as finding the most specific concept, least common subsumer, similarity reasoning [17], as well as context-aware instantiation based on SWRL rules and built-ins [19]. We argue that such a Web Reasoning Service should be developed as a profile of the Web Processing Service specification [4]. Since the WRS should encapsulate semantic web reasoners and make them accessible for SDIs, it has to map in both directions between DIG tells and asks calls on the one side and GetCapabilities request and GML on the other side 7 .
With respect to Sensor Web Enablement, a WRS could be used to discover appropriate sensors using a feature of interest as query [6]. For instance, a semantically-enabled SDI could automatically choose and register sonic anemometers if the user is interested in data on the dispersion of a gas plume. In case of semantics-based retrieval of feature types [18] as depicted in figure 2, the WRS gives the necessary reasoning power to the WOS.
Figure 3 illustrates how the WRS can be used to incorporate reasoning services into an OGC service chain. With respect to the gas plume example, the WRS encapsulated the SIM-DL similarity server to select features similar to the Rieselfelder in the greater Münster area, e.g., the Wienburgpark. Next, a SOS is 7 If the WRS should also encapsulate other ontology languages and their reasoning services, such as WSML and IRIS, it has to implement additional mappings. used to access sensor observations about the potential pollution of these features, and, finally, a web processing service delivers a risk analysis.
In this paper, we outlined the need for a Semantic Enablement Layer for OGC web services. We argued that such a layer is a prerequisite for semantics-based information retrieval tailored to the user's context, semantic translation, the orchestration of sensors and web services, and finally semantic interoperability. Three steps towards establishing a SEL have been identified. First, data encodings and service protocols have to be linked to formal specifications stored in ontologies using semantic annotations. Second, a service has to be established for managing and maintaining these ontologies. Third, a service has to encapsulate Semantic Web reasoners to integrate them into SDIs. Additional services, such as the WRS can be integrated into SDIs without changing existing clients. The proposed approach generalizes over previously suggested solutions and provides a tight (and transparent) integration into recent SDI developments. We also clearly separate data models (in any encoding) from domain ontologies. This separation acknowledges the distinction between information items from the real world. While we focused on introducing the need for and components of the Semantic Enablement Layer, the reference implementation of the WOS and WRS is part of the 52 • N orth semantics community 8 . Currently, our work on the WRS focuses on the encapsulation of the SIM-DL similarity server and Pellet reasoner to make them accessible for OGC services such as the SOS and WFS. A semantic annotation API for the lookup and injection functionality is developed in the sapience project 9 . Adding annotations on-the-fly to existing OGC metadata is required as long as the data models are not represented as ontologies within the WOS. In the long term, the functionality described by the deployment conformance class will enable the creation of (parts of) the OGC Capability Documents by the WOS.
An interesting question is whether and to which degree OGC services will co-exist with upcoming semantic Web technologies and especially with linked data infrastructures. While this is difficult to predict, we assume what both approaches do not necessarily exclude each other. For instance, one could think of a micro-SDI for linked data. Examples include recent work on next generation gazetteers [34], a forthcoming linked data serialization of OpenStreetMap [35], or JavaScript reasoners such as JSExplicit10 which can directly be embedded into web pages to generate context and user-aware information from RDF or OWL data on the fly.
The presented work is funded by the International Research Training Group on Semantic Integration of Geospatial Information (DFG GRK 1498), the DFG SimCat II project (DFG Ja1709/2-2), the SWING project of the European Commission (FP6-026514), as well as the 52 • N orth semantics community which aims at establishing a semantic enablement layer for OGC services.