Spatiotemporal data is provided and used by a large number of communities, reaching from groups of environmental experts, over decision makers, to the public. In the case of forest fires monitoring for example, environmental experts develop fuel maps, fire maps and burned area maps, decision makers have to determine required actions (such as tasking of fire fighters), and the public is affected, as well as it may provide valuable information in form of observations or photographs. The concept of Spatial Data Infrastructure (SDI) [1] has been proposed to improve interoperability between those communities, i.e. to move away from island solutions. Information systems built using standards-based distributed services have been adopted by the geospatial community for building such infrastructures. Most relevant data encodings and service interfaces are standardized by Open Geospatial Consortium (OGC) and International Organization for Standardization (ISO).
With current developments, we left island solutions in favor of aquariums [2]. SDIs become implemented, but still many people only view them from the outside and through a (thick) glass wall. In most cases, each SDI is strictly separated from the others, i.e. they use distinct data models and terminology, as well as community specific resource discovery facilities. With our work, we try to leave this stage in favor of a wider use of SDI and easier integration with any form of information infrastructures. Infrastructures for Volunteered Geographic Information (VGI) [3] are of particular interest as they represent the second major case for spatiotemporal data provision and consumption. We concentrate our work on spatiotemporal data as a source for value added information. On the one hand, we intend easier data publication; on the other hand, we aim at straightforward data discovery and access.
In the (Semantic) Web community, Linked Data has been advocated as a means to connect heterogeneous resources (data instances, data sets, services, etc.) within a distributed environment [4]. It is based on the use of uniform identifiers of resources and on the Resource Description Framework (RDF). Linked Data has been recently introduced to the geosciences community [5]. Especially, augmenting SDI, Linked Data may provide means to connect groups of environmental experts, decision makers, and the public [6].
Assuming that the Linked Data principle and technologies provide a way beyond the aquarium situation, we use the paper at hand to identify common usage scenarios of an SDI that is augmented with Linked Data principles, and analyze required changes in recent SDI standards. We suggest a possible implementation using existing technologies. While the first scenario addresses the encoding of links in SDIs presuming given standard structures, real Linked Data augmentation is provided by the second scenario. Only the latter serves the wider Linked Data community.
The remainder of this paper is structured as follows. Required background is presented in the next section (section 2). Common scenarios for spatiotemporal Linked Data provision and consumption are introduced in section 3. In section 4, we discuss the impacts on existing OGC standards, relevance for recent SDI developments, and we present our conclusions and outline future work.
Understanding the main discussions of this paper requires background on SDI technology and Linked Data principles. Both are introduced in a nutshell.
An SDI is an information infrastructure for enhancing geospatial data sharing and access [1]. Implementations rely on web service technology. The Web Map Service (WMS, [7]) and the Web Feature Service (WFS, [8]) are two prominent examples. An abstract structure for data modeling and encoding is provided in form of the Geographic Markup Language (GML, [9]). GML already provides possibilities of including metadata, more sophisticated profiles (e.g. for data and service discovery) are provided separately. The two ISO standards 19115 [10] and 19139 [11] provide the most common examples. Functionalities for data and service publication and discovery are provided by the Catalogue Service Web (CSW) [12].
Resource metadata in CSW may include links at service level, telling us what services are related to the current resource. ISO 19115 defines the CI_OnlineResource complex element that contains information about services from which resources can be obtained. This element permits to augment a URL in its linkage element together with (optional) information for service definition in the protocol and description fields. The values contained in this metadata descriptor provide the link to associated data sets in terms of query parameters to the appropriate service. In addition, the data resource itself may incorporate links at instance (aka feature) level 1 to connect related features among diverse data resources. Both aspects are revisited later in the paper.
Based on these (meta-) data encodings and service interfaces, interoperable clients for geospatial data provision and consumption are put into place [1]. Government mandates such as the European Directive on Infrastructure for Spatial Information in Europe (INSPIRE) [13] recommend such standards for sharing resources (such as data and processes) with the goal of improving environmental decision-making. In particular WFS is recommended for implementing data download services and CSW is proposed for data and service discovery. A Service Framework, which allows environmental experts to upload their data and retrieve links to access services, is under development [14].
Opposed to classical SDI, the notion of Volunteered Geographic Information (VGI) emerged recently [3]. VGI highlights that users are active producers of geographic information rather than passive recipients of geographic information by formal organizations. Possible approaches to merge this bottom-up model with the topdown SDI model are under investigation [15]. Current implementations still suffer from the aquarium situation, i.e. a restricted user community.
Linked Data is a current buzz-phrase promoting access to various forms of data on the internet [4]. Linked Data is based on two principles that have underpinned the architecture and scalability of the World Wide Web; (1) Universal Resource Identifiers (URI) [16], using the http protocol which is supported by the DNS system, and (2) hypertext, in which URIs of related resources are embedded within a dataset.
The Linked Data movement also adds, or re-emphasizes Semantic Web principles by following the Resource Description Framework (RDF) data model and encoding [17]. A basic typing system for subjects, predicates and objects has been proposed as RDF-Schema (RDF-S) [18]. RDF-S allows for extensions in order to specify domaindependent subtypes. It provides one way to describe domain vocabularies with its own namespace; for example the Simple Knowledge Organization System (SKOS) [19]. We argue later in this paper that GML and metadata standards serve similar purposes.
Content negotiation provides the client uses the 'Accept Header' to tell the service what representation of a resource is acceptable for a given client [20]. Content negotiation is not a requirement for publishing Linked Data, but it is common due to the HTTP303 publishing pattern. The diversity and richness of Linked Data sources supports a great variety of user interfaces. Browsing becomes an important mode of user interaction.
Considering the growing interest of the geosciences community in Linked Data, we analyze two common scenarios in Linked Data provision and consumption. We identified these scenarios based on personal experiences and a review of recently published research. In scenario one, we use an agnostic format to codify links instead of RDF to keep us compatible with current standard (ISO 19115). We elaborate on a complete Linked Data augmentation (with RDF) in the second scenario. The scenarios help us to illustrate potentials, requirements, and changes when augmenting SDI with Linked Data. We suggest ways for adding links capabilities, both at the service and feature level. Having two levels provide some benefits. From the service provider perspective, linking capabilities can be increasingly added into the SDI mainstream since links at the service level require less effort than ones at the feature level. In addition, when geospatial data are connected at feature level, data visibility increases greatly leading to both new synergies and unexplored set of new user applications.
We concentrate on provision, i.e. deploy and publish (Figure 1), before visiting consumption in form of discovery and access. In particular, resource deployment and publication is carried out using encoding and service standards of OGC. In Figure 1, for example, a data source provides information in the Observations and Measurement Encoding (O&M) standard [21], a specific encoding for sensing results; the WMS specification is applied to data visualization; the Sensor Observation Service (SOS) [22], a service specialized on accessing sensing-based data, offers O&M; and the CSW allows for resources advertisement and subsequent discovery. In the remainder of this section we target a scenario for augmenting data provision (access service deployment and publication) with Linked Data for open search and for offering geospatial data encodings based on Linked Data principles. These scenarios provide a basis for discussing required changes to existing SDI standards and implementation practices.
In this scenario, we suggest the use of links embedded in the metadata record of a given SDI resource. A data resource (e.g. observational data) can be deployed in multiple SDI services, such as view services (WMS) and download services (SOS), at the same time. The idea is to generate appropriate links between all SDI services related with the data resource in question. As the resource metadata description resides CSWs that codify records in ISO 19115, we elaborate on this standard to find out where links at the service level might be placed.
As argued earlier each metadata record may contain an URI in the linkage element (see also Figure 1). This may point to the associate resource (e.g. service) by providing a direct locator with the required query parameters. For SOS data retrieval this may for example be the HTTP-GET binding and the getObservation request [22]. The linkage element provides a means to link from the metadata record to the access service and the protocol field provides required information about the supported protocol. Nativi and Bigagli propose a similar solution to identify the type of binding of the access service (HTTP, HTTP-GET, HTTP-POST) [23].
Connections to other metadata records, related online services and VGI services in the context of the current metadata record, still have to be provided. To overcome this issue using the recent standards, we suggest the description of links according to ongoing work in Web Linking [24], which proposes a way to provide independentformat links within HTTP headers [25] 2 . The syntax of a link header is a set of pair parameter-value as follows: Link:<URI>;rel="typed_relationship";type="accepted_mime_types_of _target_resource"; title="human-readable_title_for_the_link"
The use of Web Linking yields at least a couple of benefits. First, links syntax is format-agnostic, i.e. does not depend on the actual representation of the resource. Second, links are annotated with the rel attribute (highlighted in bold, above) that adds semantics to the link in terms of established relation types. A link relation type conveys the role or purpose of the link and act as an identifier for the semantics associated with the link. A list of registered link relation types were already introduced in HTML and extended later in the Atom specification [26]. Below we describe some of these standard relation types that may be useful for establishing typed connections with other related SDI services:
• rel="self" means a link to the preferred URI, i.e., the URI to the download service of the resource. Self relation type is equivalent to the current behavior of the linkage element as defined in ISO 19115, when the latter field is full qualified. • rel="previous" means a link to a URI for older versions of the current metadata record. This link makes reference to a discovery service. This is common in O&M, since this type of data depends strongly on the time variable.
• rel="service" means a link to a URI for related geospatial web services (e.g., WMS or WFS) that serve the same layers. The title attribute may contain a single tag (e.g. "WMS", "WFS") to identify the actual OGC service specification. • rel="related" means links to related resources, for instance, VGI resources.
• rel="via" means a link to the source of the current resource. It refers to the sensor or to the process used to transform raw sensor data into value-added information.
Following this suggestion, link headers for a metadata record of a given SOS layer may be provided like this:
Link:<http://server.org/sos?service=sos&request=getobservation>; rel="self";type="text/xml" Link:<http://server.org/catalog?service=csw&request=getrecord>; rel="previous"; type="text/xml" Link:<http://server.org/wms?service=wms&request=getmap>; rel="service";type="imag/jpeg" title="WMS" Link:<http://server.org/photos/diagram.jpeg>;rel="related";type= "img/jpeg" Link:<http://server.org/sensor>;rel="via";type="text/html"
The obvious question that arises is where to place these links. A first attempt is to place the list of links in the ISO 19115 linkage element. One inconvenience is that it is of type URL. So a list of links encoded in such a way does not fit the data type constrains of the field. We suggest the use of the description field to accommodate links to related services and resources as illustrated in Figure 2.
In respect to provision, client applications require minimal changes to support the scenario illustrated above (Figure 2). Rather than treating the description field as free text, client applications have to view it as a set of typed links to related services. From the server perspective, this solution keeps 'almost' invariable current implementation of the CSW-based catalog services. For instance, link edition would be made through the CSW transactional interface [12]. Links would be stored in the metadata record (description) as is now. No changes are needed, excepting the semantics but not syntax of the description field.
In order to support data providers, tools such as the Service Framework [14] support some of these typed links at publication time. Figure 3 Link discovery and access would be provided by the current CSW discovery interfaces (getRecords, respectively getRecordById query). Clients would be in charge of interpreting the relation types of the set of link headers found in the description field 3 . The client would submit a HTTP HEAD to get only the set of links associated with the resource in question. This method is useful to retrieve the HTTP header fields such as the list of link headers. It gives clients to chance of retrieving only the links without processing the metadata record of the resource. In this case, we extend SDI service interfaces slightly since we introduce the use of HTTP HEAD method. An example of how such an HTTP HEAD request would look like if given below: HEAD /catalog? service=csw&request=getrecord HTTP/1.1 Host: server.org A response would return the list of links contained in the description field: HTTP 1.1 200 OK Content-Length:… Cache-Control:.. … Link:<http://server.org/sos?service=sos&request=getobservation>; rel="self";type="text/xml" Link:<http://server.org/catalog?service=csw&request=getrecord>; rel="previous"; type="text/xml" Link:<http://server.org/wms?service=wms&request=getmap>;rel="ser vice";type="img/jpeg" title="WMS" Link:<http://server.org/photos/diagram.jpeg>;rel="related";type= "img/jpeg" Link:<http://server.org/physicalsensorrel="via";type="text/html" Following the browse metaphor more strictly, access and view services may be even provided with a REST-based interface [27]. A recent implementation of 52north provides a showcase 4 . Starting from the URL representing the service endpoint, required parameters are offered as resources, which can be easily selected as links in a common browser interface. This intuitive communication with service offerings provides a direct bridge to the access of Linked Data, both being interconnected resources. Approaches for 'browsing' SOAP-based interfaces have already been suggested outside the geospatial community.
This scenario provides only one building block for resolving the 'aquarium' issue as it mainly suggest a way of interlinking SDI resources from/within metadata records. We still miss a way to access or query SDI content from outside, i.e. from the Linked Data world. We therefore consider a richer scenario in the following. It includes content negotiation to RDF and SDI specific link types provided in RDF-S.
Now that we are able to persist links in SDIs, we disclose geospatial data hidden in data access services as Linked Data by automatically generating RDF on request. In this scenario we describe how an in-depth integration of Linked Data and SDI could be realized. We develop methods for providing the content of SDI to the outside. This is particularly possible, because the OGC Naming Authority just changed the resource identification schema to http URIs [28].
To continue, we require links with well defined semantics, i.e. we have to define link types in RDF-S. As metadata is concerned, standards such as ISO 19115 and ISO 19119 provide a core vocabulary and the relation types introduced for scenario one provide an extension. Similarly, geospatial data encoded in GML can be offered in RDF [29]. Providing linked geospatial data is a matter of philosophy and not of technology. The basic mappings between GML and RDF are simple:
• xlink:href = rdf:resource • gml:identifier = rdf:about Still, if none of the standards relation types fit our requirements, we can define new relation types based for instance on the ongoing work of the NeoGeo Semantic Web Vocabularies Group 5 , an online group focused on the construction of a set of lightweight geospatial ontologies for Linked Data.
In consequence, content negotiation can be realized on service and feature level. Depending on the accessing client, WFS may offer its data in classical GML, in RDF, or in HTML; a CSW may offer ISO 19115, RDF, HTML, etc. Supported encodings remain in the responsibility of the service provider. He/She delivers the data that is under his/her responsibility including links to third party resources. It is under the control of the client to decide which links should be followed, i.e. which Linked Data should be retrieved (and in which encoding).
First implementations, such as those within the UK location program illustrate feasibility6 on feature level. A service level implementation of a CSW following the suggested principles has been suggested recently [30]. The authors provide a completely RDF based geospatial catalogue. This work indicates isomorphism between standard encodings for geospatial metadata and RDF representations. Yet, this only provides a static solution, as standard metadata is harvested first; secondly, all metadata sets are translated into RDF and stored on a triple store [31]; and thirdly, a frontend is provided. The available implementation supports only a relatively small metadata language (Dublin Core [32]), instead of facilitating the complex ISO metadata standards with the extended link capabilities that are advocated in this paper.
As a logical next step, both methods should be combined with each other, i.e. all SDI content should be represented in a graph structure (Figure 4). Interlinked metadata records (service level) provide the backbone. If service endpoints do not offer linking to provided data instances (i.e. linking on feature level), they become leave nodes of the graph; else they are able to serve as internal nodes and branch over their content. In the example, the SOS offers linked data, which allows to link form the provided O&M to diagram representations and even VGI items. The WMS does not support according functionality and thus is considered as a leave in the graph. It remains to be clarified how such links can be supported if the data is encapsulated via a data access service. We suggest using combined identifiers, where the first part of a URL corresponds to the URL of the access service, for example 'http://gsvws.dpi.vic.gov.au/test/EarthResourceML/1.1/wfs', and the second part contains a local (feature) identifier. Once such a link is followed, the service implementation is responsible for link resolving. Depending on the used implementing paradigm (REST, SOAP [33], etc.) the resolver may (internally) map the URL to a complex query among the underlying data source. This approach is completely transparent to the user. Such functionality may be provided as an add-on to the common OGC interface for data access (WFS, SOS, etc.). Once implemented, the scenarios would provide an SDI is completely augmented with Linked Data.
SDIs already contain many inter-linked resources and existing standards can be widely applied for their representation. In other words, only few things have to be changed in terms of standards and technology. From our investigations, we basically require a well defined and common use of the CI_OnlineResource and its elements. GML already serves all required capabilities. The concept of content negotiation enables us to retain classical SDI structures, which may be used by a set of (expert) applications, while we can directly address wider communities be providing encodings in RDF and HTML. This holds equally for metadata and data, where link encodings at service and feature level can be subject to content negotiation in function of client needs.
Opposed to our earlier assumption, the Linked Data principle and technologies alone do not provide a way beyond the aquarium situation of SDIs. As in any application of Linked Data, clear definitions for link types are required. Those can be provided using RDF-S. Many required link types can be derived from existing ISO and OGC standards.
As implementations of Linked Data augmented SDIs can be provided on top of existing standards, we envision a best practice for augmenting classical OGC standard based SDI with Linked Data instead of change requests for any of the recent standards. As one mandatory step, OGC already changed its resource identification schema to http URIs Most development work has to be considered at client level.
Considering potential benefits for legally mandated SDI(s), such as INSPIRE, we observe that Linked Data is not mentioned in any technical guideline or even in one of the regulations. Accordingly, no geospatial data provider is obliged to use inter-linked resources and RDF or to offer similar structures encoded in GML. The linkingcapabilities and resulting functionalities remain optional. Anyway, links between data elements, related services, and metadata are mandatory for implementation. The presented work may serve a building block for the longer term development of INSPIRE. Investigations are ongoing in the SDI-Unit of the Institute for Environment and Sustainability (JRC) [34]. INSPIRE specific link types are topic to ongoing work [35].
In summary, we are on the gateway to a new form of data provision and consumption, which is in-line with SDI principles and yet is more connected to broad audience. The concept has been outlined in scenario two. Now, it is at the time to develop a prototype for a Linked Data augmented SDI followed by a best practice implementation.
The authors thank Simon Cox and Francisco López-Pellicer for the lively discussions we had and the three anonymous reviewers for their valuable comments.