Spatiotemporal data is provided and consumed by many different communities, reaching from groups of environmental experts, over decision makers, to the public. Due to heterogeneous conceptual and technological approaches, cross-community communication and cooperation remains challenging. Linked Data has been suggested as a means to enable interoperability and first experiments indicate suitability. In this paper, we discuss how solutions for spatiotemporal data management, specifically Spatial Data Infrastructures (SDI), can be augmented with Linked Data principles. We identify two common usage scenarios and conclude that only minor changes to current SDI standards are required for implementation and identify actions for future work.
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) [
With current developments, we left island solutions in favor of aquariums [
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 [
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 [
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) level1 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 [
Opposed to classical SDI, the notion of Volunteered Geographic Information
(VGI) emerged recently [
Linked Data is a current buzz-phrase promoting access to various forms of data on the
internet [
The Linked Data movement also adds, or re-emphasizes Semantic Web principles
by following the Resource Description Framework (RDF) data model and encoding
[
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. 1 Due to the ISO General Feature Model, the concept of a feature includes feature collections. 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.
2 Each Link header field is semantically equivalent to the atom:link feed-level element in Atom
(RFC 4287).
• 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 [
In order to support data providers, tools such as the Service Framework [
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 field3. 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
3 See also HATEOAS (Hipermedia As The Engine of Application State) constrains in REST. 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 showcase4. 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 Group5, 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 that 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. [20] Holtman, K. and A. Mutz (1998). Transparent Content Negotiation in HTTP. Internet
Engineering Task Force (IETF) Memo – RFC 2295. [21] Cox, S.J.D. (Ed.) (2010). Observations and Measurements – XML Implementation v2.0.
Open Geospatial Consortium Implementation Specification. [22] Bröring, A, Stasch, C. and J. Echterhoff (Eds.) (2010). Sensor Observation Service v2.0.
Open Geospatial Consortium Implementation Specification. [23] Nativi, S., Bigagli, L. (2009) Discovery, Mediation, and Access Services for Earth Observation Data. IEEE Journal of Selected Topics in Applied Earth Observation and Remote Sensing, 2(4): 233-240. [24] Nottingham, N. (2010) Web Linking. http://tools.ietf.org/html/draft-nottingham-http-linkheader-10. [25] RFC 2068. Hypertext Transfer Protocol -- HTTP/1.1, http://tools.ietf.org/html/ rfc2068. [26] RFC 4287. The Atom Syndication Format, http://tools.ietf.org/html/rfc4287. [27] Fielding, R. (2000). Architectural Styles and the Design of Network-based Software
Architectures. PhD Dissertation, University of California, Irvine. [28] Cox, S. (2010). OGC Identifiers – the case for http URIs. OGC White Paper. [29] Schade, S. and S. Cox (2010), Linked Data in SDI or How GML Is Not about Trees.
Accepted for AGILE Conference 2010. [30] López-Pellicer, F., Florczyk, A.J., Nogueras-Iso, J., Muro-Medrano, P.R., and ZarazagaSoria. F.J. (2010) Exposing CSW catalogues as Linked Data. Geospatial Thinking (AGILE 2010), p. 183-200. [31] Rusher, J, (2003). TripleStore. Workshop on Semantic Web Storage and Retrieval
Position Paper. [32] DCMI (1998). Dublin Core Metadata Element Set, Version 1.0: Reference Description. [33] Mitra, N. and Y. Lafon (2007). W3C SOAP Version 1.2 Part 0: Primer (Second Edition).
W3C Recommendation 27 April 2007. [34] Cox, S., S. Schade, C. Portele (2010), Linked Data in SDI. Accepted for INSPIRE Conference 2010. [35] Schade, S. and M. Lutz (2010). Linked Spatiotemporal Data and INSPIRE. Workshop on Linked Spatiotemporal Data, GiScience 2010.