=Paper=
{{Paper
|id=None
|storemode=property
|title=An Open Source Linked Data Framework for Publishing Environmental Data under the UK Location Strategy
|pdfUrl=https://ceur-ws.org/Vol-798/paper6.pdf
|volume=Vol-798
}}
==An Open Source Linked Data Framework for Publishing Environmental Data under the UK Location Strategy==
https://ceur-ws.org/Vol-798/paper6.pdf
An Open Source Linked Data Framework for
Publishing Environmental Data under the UK Location
Strategy
Arif Shaon1, Andrew Woolf2, Shirley Crompton1, Robert Boczek1, Will Rogers1,
Mike Jackson3
1
e-Science Centre, The Science And Technology Facilities Council, Rutherford Appleton
Laboratory, Didcot, OX11 0QX, UK
{arif.shaon, shirley.crompton, will.rogers, robert.boczek}@stfc.ac.uk
2
The Bureau of Meteorology, Canberra, Australia
A.Woolf@bom.gov.au
3
The Software Sustainability Institute, The University of Edinburgh, Edinburgh, UK
michaelj@epcc.ed.ac.uk
Abstract. Linked data offers a novel and more flexible means of sharing
complex geospatial datasets by breaking away from the traditional domain-
specific technologies used for accessing and integrating geospatial data with
heterogeneous sources and disparate formats. In 2010, the UK Cabinet Office
released a set of draft guidelines for exposing geospatial data as linked-data in
support of the UK Open Data initiative. These draft guidelines have been
proposed under the UK Location Strategy in specific recognition of the
importance of geospatial data, and also with a view to promote linked-data
within the EU INSPIRE community. This paper presents a customisable open-
source linked-data framework developed by the GeoTOD-II project that
implements these guidelines. The framework provides an efficient means for
exposing both existing and new data sources in the linked-data form. We also
attempt to articulate and address a number of issues and hidden assumptions
with these guidelines identified during the development of the framework.
Keywords: linked-data, geospatial data, INSPIRE, DEFRA, GeoTOD
1 Introduction and Motivation
The UK government’s “data transparency agenda” aims to make public sector data
freely accessible on the web as linked-data. This was greatly inspired by Tim Berners-
Lee’s invitation in 2009 [1] to publish government data online in light of the
emergence of the Linked Open Data movement. While the primary goal of this
initiative is to increase accountability associated key public sector datasets, it will,
more importantly, enable harmonisation of heterogeneous datasets in a standardised
manner by creating a “web of data”, thus supplementing the knowledge base of
individuals as well as society.
For geospatial information in particular, the linked-data approach offers the
potential for developing more flexible means of data sharing and accessibility. In
essence, this could help solve the traditional problems of harmonising geospatial data
with heterogeneous sources and disparate formats through standardised but complex
web-services. For example, an RDF1-based linked-data representation of a climate
research dataset identified by a unique HTTP URI could be seamlessly linked to
another related but external dataset also exposed as linked-data in RDF, through an
appropriate vocabulary e.g. RDFS2 ‘seeAlso’. This would enable a user (whether an
application or human) to seamlessly access both of these datasets through their
respective resolvable URIs and/or interrogate the datasets using the linked-data
recommended query language, SPARQL3 without being constrained by the query
language or access mechanism(s) specific to the underlying geospatial web-service(s)
(e.g., an OGC Web Feature Service4 instance) responsible for serving up these
datasets.
There are however several caveats to effectively sharing linked resources using
URI and RDF. The chief amongst these is the necessity of a specific community data
model, or ‘RDF vocabulary’. While RDF provides the base representation for linked-
data, this is not enough to specify the internal structure of any specific dataset (much
as HTML provides a flexible structure for a huge variety of web page content). As
noted by Tim Berners-Lee [2], “Different communities have specific preferences on
the vocabularies they prefer to use for publishing data on the Web. The Web of Data
is therefore open to arbitrary vocabularies being used in parallel. Despite this general
openness, it is considered good practice to reuse terms from well-known RDF
vocabularies...” Unfortunately the most well-known RDF vocabularies have little to
do with climate research data – they are concerned with social networking (FOAF5),
blogs/wikis (SIOC6), thesauri (SKOS7), software projects (DOAP8), etc.
It is also important with linked-data to strike the right balance with URI structure
between completely opaque identifiers and excessive human-readable semantics9. To
address this issue, the UK Cabinet Office has released a set of draft recommendations
[3] for designing URI identifiers for location data in support of the UK Open Data
initiative. These draft guidelines extend more general ones [4] for publishing public
sector data (under data.gov.uk), and have been proposed under the UK Location
Strategy in specific recognition of the importance of geospatial data, and also
1 Resource Description Framework (RDF) - http://www.w3.org/RDF/
2 RDF Schema - http://www.w3.org/TR/rdf-schema/
3 SPARQL Query Language for RDF - http://www.w3.org/TR/rdf-sparql-query/
4 Open Geospatial Consortium (OGC) Web Feature Service -
http://www.opengeospatial.org/standards/wfs
5 The Friend of a Friend (FOAF) vocabulary - http://xmlns.com/foaf/spec/
6 Semantically-Interlinked Online Communities (SIOC) - http://sioc-project.org/ontology
7 Simple Knowledge Organization System Reference (SKOS) - http://www.w3.org/TR/swbp-
skos-core-spec
8 http://code.google.com/p/baetle/wiki/DoapOntology
9 W3C, “Cool URIs don’t change”, http://www.w3.org/Provider/Style/URI
recognising parallel work at the European level on deploying the INSPIRE10 ‘spatial
data infrastructure’ (which uses web services, but not linked-data principles).
In addition, a linked-data service should integrate (e.g. as a layer over or an
additional component) with existing data sources (e.g. web services, databases)
without the need to make substantial changes to the underlying infrastructure. For
example, it may not be desirable to significantly modify an existing Web Feature
Service serving up external data from a third party database; or to replace it with a
linked-data service to provide linked-data representations of these data. What might
be more efficient and practical in this scenario is to implement a linked-data service
that wraps the Web Feature Service and leverages it as a “proxy” data source for
exposing linked-data.
This paper presents an open-source geospatial linked-data framework developed by
the GeoTOD-II11 project that implements the UK Cabinet Office’s draft guidelines
for exposing geospatial data as linked-data. This framework provides an efficient
means for exposing existing data sources as linked-data using the approach proposed
above.
2 Key Concepts
In this section, we provide an overview of the key concepts pertinent to the work of
the GeoTOD-II project presented in this paper.
2.1 Linked-data
Fig. 1. Linked-data principles: client-dependant resource identification through HTTP URI and
resource retrieval through content negotiation. (Source: http://www.w3.org/TR/cooluris/)
The success of today’s web results from two core functionalities: the ability to
identify and link documents using the HTTP protocol. Simple to implement, widely
deployed, and with ubiquitous client support, these two elements provide an obvious
model for moving beyond text and documents to a web of data. The ‘linked data
principles’ [5] adopt this model by using URIs to identify data objects (or the real-
10 INSPIRE Directive - http://inspire.jrc.ec.europa.eu/
11 Geospatial Transformation with OGSA-DAI (GeoTOD-II), SourceForge
http://geotod.sourceforge.net/about.html
world ‘things’ that they represent), and creating a data web by linking together related
data objects. While HTML provides the lingua franca for the web of documents, RDF
plays that role for data (Fig. 1). Common to both is the use of HTTP to access
information (linked-data also recommends a human-readable representation e.g.,
HTML, if accessed via a web browser, using ‘content negotiation’12 – Fig. 1). The
adoption of the four elements of linked data (URIs, RDF, HTTP, links between data)
has already led to a massive ‘linked data cloud’13 connecting hundreds of datasets
and billions of individual data items.
2.2 Designing ‘URI Sets’ for Location
The European Union’s INSPIRE Directive requires public authorities across Europe
to provide access to their environmental datasets through the adoption of a common
framework for uniquely identifying the datasets within a pan-European ‘spatial data
infrastructure’. The UK Cabinet Office’s guidelines for “Designing URI Sets for
Location” [3] “is focussed on the use of http: URI by the UK public sector to meet
that INSPIRE objective”. To that end, the guidelines define three different types of
resources identified by three different Uniform Resource Identifier (URI) schemes.
Fig. 2. HTTP URI identifiers for ‘Spatial Things’ and ‘Spatial Objects’
Spatial Thing. The guidelines define this as anything that has a spatial extent, i.e.
size, shape or position, and is a subset of ‘real-world’ phenomena associated with a
location, e.g. the ‘River Thames’. To uniquely identify a Spatial Thing, the
guidelines recommend the following URI scheme, referred to as the “Id” URI:
http://location.data.gov.uk/id/{INSPIRE
theme}/{concept}[/{codeset}]/{reference}[/{version}]
([] denotes an optional term).
12 A web server returns a representation of a resource based on the HTTP-Accept header of a
client request.
13 http://linkeddata.org
An example URI for the ‘River Thames’:
http://location.data.gov.uk/id/HY/Watercourse/Thames/v1
According to the guidelines, the URI for a Spatial Thing, if de-referenced, should be
re-directed to a web document containing metadata about the Spatial Thing (Fig. 2).
The granularity of the metadata is implementation or provider specific. The URI
pattern for identifying this metadata document should be that for the Spatial Thing but
with the term “id” replaced with the term “doc” – hence, it is referred to as the “Doc”
URI.
An example “Doc” URI for the ‘River Thames’:
http://location.data.gov.uk/doc/HY/Watercourse/Thames/v1
In addition, a metadata document about a Spatial Thing could also include a list of
relevant, known, Spatial Objects (described below) through appropriate vocabulary
(e.g. RDFS ‘seeAlso’ or OpenVocab14 ‘similarTo’ – Fig. 2).
Spatial Object. This is essentially a concrete digital representation of a ‘real-world’
phenomenon associated with a specific geographical location. Notably, this is a direct
proxy of the INSPIRE definition of a Spatial Object15. The guidelines propose the
following URI scheme (referred to as the “So” URI) for uniquely identifying a Spatial
Object in an INSPIRE compliant way:
http://location.data.gov.uk/so/{INSPIRE theme}/{Ontology Class}/{Ontology
Namespace}/{local id}[/{version id}][/{rendition}]
For example, the URI for a Spatial Object representation of the ‘River Thames’ could
be:
http://mydata.co.uk/so/HY/Watercourse/hy-p/1234/v1
As illustrated in Fig.2, multiple representations of the same Spatial Object could be
provided by using an efficient content negotiation mechanism.
Ontology. In addition, the guidelines also define a number of URI patterns for
querying the concepts used within a description of a Spatial Thing or Spatial Object.
These concepts are essentially the Classes and their associated properties defined
within an OWL Ontology16 or RDF Schema representation of an INSPIRE
conceptual model (typically formulated in UML17) underpinning the description of a
Spatial Thing or Spatial Object. These URI schemes (referred to as the “Def” URIs)
are:
- URI for a class
14 http://open.vocab.org/docs/similarTo
15 INSPIRE Glossary item 67 in https://inspire-
registry.jrc.ec.europa.eu/registers/GLOSSARY/items
16 OWL 2 Web Ontology Language Document Overview - http://www.w3.org/TR/owl2-
overview/
17 Unified Modelling Language (UML) - http://www.uml.org/
http://location.data.gov.uk/def/{theme}[/{package}][/{concept|class}][/{version}
]/{class}
- URI for a property exclusively associated with the given class
http://location.data.gov.uk/def/{theme}[/{package}][/{concept|class}][/{version}
]/{class}/{property}
- URI for a shared or re-usable property
http://location.data.gov.uk/def/{theme}[/{package}][/{concept|class}][/{version}
]/{property}
So, to access the definition of the ‘Watercourse’ class in the above ‘River Thames’
Spatial Object example, the URI would be:
http://mydata.co.uk/def/HY/rivers-package/Watercourse
3 Key Issues and Challenges
3.1 Pragmatic Interpretation of the “Designing URI Sets for Location” guidelines
The key challenge faced by the GeoTOD-II project was interpreting the Cabinet
Office’s guidelines in a pragmatic and implementable fashion, as there had so far
been little practical application of these guidelines. There are a number of issues and
hidden assumptions in the guidelines that needed to be articulated by the project.
For instance, a key question raised by the URI scheme proposed for identifying a
‘Spatial Thing’ is: in an operational context what information should be available at
the ‘Doc’ URI which describes a Spatial Thing? We choose to regard this as a ‘master
catalogue’ of individual Spatial Objects available from different providers and which
relate to the associated Spatial Thing, e.g. all registered representations of the River
Thames.
Similarly, it is necessary to clarify matters relating to governance and ownership of
concepts: e.g. who is the owner of the concept ‘River Thames’ with responsibility to
maintain the ‘id/Doc’ URI? There is an implied ‘registration’ process – all owners of
‘River Thames’ objects must register them with the owner of the concept ‘River
Thames’.
3.2 Legacy Geospatial Data Sources
Another issue is how to achieve linked-data representation of legacy geospatial data
sources with minimal cost to data providers. As highlighted before, the recommended
practice is for linked-data representations to co-exist with any current data sources
and representations in order for it to be useful. Therefore, a linked-data solution
would effectively sit on top of existing data sources and be configured to use those
data sources without changing their underlying data structures or storage formats.
3.3 Ontology Representations of the INSPIRE Conceptual Models
Additionally, there is also the question of representing geospatial data in RDF, which
requires developing RDF ontologies based on the UML conceptual information
models adopted by INSPIRE (and their underpinning ISO standards) to describe these
legacy data sources. There are a number of issues related to the “mappings” between
the INSPIRE UML models and their OWL/RDF Ontology/Schema representations.
For instance:
• There is a need to define a canonical transformation from geospatial UML
conceptual models to an ontology representation. In general, the ‘closed-
world’ semantics of UML are more restrictive than the ‘open-world’ model of
OWL and RDFS. As well, the UML meta-model does not support properties
as first-class entities. Nevertheless, UML bears similarities to frame-based
knowledge modelling systems, and the Object Modelling Group has developed
the Ontology Definition Metamodel (ODM) as a mechanism for modelling
UML-based ontology development.
• Developing an ontology representation of an INSPIRE UML model would
need also to address the ‘import’ of already-existing information models
developed as international standards by ISO’s Technical Committee 211 (e.g.
ISO 19107 for spatial schemas, ISO 19108 for temporal schemas, ISO 19115
for geospatial metadata, etc.). It would require the development of ontologies
for these ‘imported’ models as well. These are substantial tasks in their own
right requiring considerable involvement of the wider standards community.
• In order to provide conventional GML18 as a specific representation of
INSPIRE geospatial data under a linked-data server (through content
negotiation), further work is required on developing open-source
implementations of the INSPIRE web services (i.e. the OGC ‘Web Feature
Service’).
Notably, there have been a few such ontologies, albeit unofficial and generally
incomplete, emerging from the INSPIRE and other related communities. For instance,
the W3C Semantic Sensor Network Incubator Group (SSN XG)19 developed an
ontology based in part on the ISO 19156 ‘Observations and Measurements’
conceptual model. And the UK Environment Agency has developed a linked-data
representation of Bathing Water Quality including ‘sampling points’20 motivated by
the INSPIRE ‘Environmental Monitoring Facility’ theme. The OGC GeoSPARQL
working group is developing a SPARQL extension to include spatial query
predicates21 (touches, disjoint, overlaps, contains, etc.). In addition, the draft
specification includes a number of OWL class definitions for geometry, topology, and
geospatial ‘features’.
18 Geography Markup Language - http://www.opengeospatial.org/standards/gml
19 W3C Semantic Sensor Network Incubator Group - http://www.w3.org/2005/Incubator/ssn/
20 http://location.data.gov.uk/def/ef/SamplingPoint/SamplingPoint
21 The so-called Egenhofer relations.
4 Existing Linked-data Servers
We assessed the suitability of a number of existing open-source linked-data servers
for publishing geospatial datasets in accordance with the Cabinet Office’s guidelines
discussed above. These servers included D2R22, Virtuoso23, Triplify24,
SquirrelRDF25 and Pubby26. In general, these existing products enable exposing
RDF views of datasets residing in relational databases through customisable HTTP
URLs and querying them using SPARQL. In all cases, the desired mappings between
an RDF schema and a relation database schema are specified in some form of
mapping file(s) written in RDF/Turtle based languages with varying levels of
syntactical and conceptual complexity. Additionally, some of these servers, such as
D2R and Virtuoso support automated generation of the mapping files based on the
schema of the relational database specified.
We also reviewed a number of geospatial linked-data services that are based on
some of the aforementioned linked-data servers. This included the UK
Environmental Agency’s linked-data server27 that implements the Cabinet Office’s
guidelines, and the “GeoLinked Data” service developed by the Ontology
Engineering Group (OEG)28 for publishing environmental data held by the National
Geographic Institute of Spain.
Generally, most of the existing linked-data servers and services reviewed provide
complete (and in some cases, complex) solutions for publishing linked-data.
However, the major drawback of these solutions is the limited scope for their
functional extensibility. For instance, adding a non-relational data source, such as a
Web Feature Service for rendering GML representation of a geospatial resource, to
any of these servers would likely require substantial re-implementation of its
underlying architecture. Such a task, while achievable as most of these servers are
open-source products, may not be practical within the related scope of work.
Providing alternative non-RDF representations (e.g. XML) of a linked-data
resource is recommended in the linked-data principles. And considering that RDF is
not a prevalent format for encoding geospatial datasets, there is added value for a
geospatial linked-data server to have the capability to provide both non-RDF (such as
GML) and RDF representations of a resource. Notably, the provision of GML-
encoded environmental data is also not supported by either of the two geospatial
linked-data services mentioned above.
To this end, we concluded that there would be merit in developing an open-source
linked–data server for publishing geospatial datasets with the key features of the
22 http://www4.wiwiss.fu-berlin.de/bizer/d2r-server/
23 http://virtuoso.openlinksw.com/linked-data/
24 http://triplify.org/
25 http://jena.sourceforge.net/SquirrelRDF/
26 http://www4.wiwiss.fu-berlin.de/pubby/
27 http://data.gov.uk/linked-data
28 http://geo.linkeddata.es/web/guest/home
aforementioned servers but crucially with appropriate extensibility points for adding
new functionality as needed.
5 Methodology and Implementation
5.1 GeoTOD Linked-data Server Framework
To address the issues of the existing linked-data servers, in the GeoTOD project we
developed a highly-extensible framework for a linked-data server, namely the
GeoTOD Linked Data Server (GLS), which implements a set of Linked Resource
interface specifications compliant with the Cabinet Office guidelines for the
publication of geospatial data.
Fig. 3. An architectural view of the GLS Framework
The GLS architecture (Fig. 3) follows the Spring Model-View-Controller
(MVC)29-based Java EE630 framework with four different layers of components:
Spring MVC framework, Linked Resource, Authentication and Data Source. Of
particular note is the Linked Resource layer, which integrates within the GLS
framework three Linked Stores (LinkedDocStore, LinkedSOStore and
29 The Spring MVC Framework - http://static.springsource.org/spring/docs/3.0.x/spring-
framework-reference/html/mvc.html
30 Java Enterprise Edition 6- http://www.oracle.com/technetwork/java/javaee/tech/index.html
LinkedDefStore) representing the three resource types (Spatial Thing, Spatial Object
and Ontology respectively) specified in the Cabinet Office’s guidelines (Section 2.2).
In general, the Spring MVC layer of the GLS framework receives requests related
to any of the three Linked Stores as either HTTP URIs or SPARQL queries, and
determines the appropriate response to be sent to the client. Formulation of the
response to a client’s request mainly involves identification of and communication
with an appropriate implementation of the Linked Store in question. The mode of
communication between the Spring MVC layer and the Linked Resource layer
depends on the type and output format (e.g. HTML, RDF etc.) of the resource
requested.
In addition, the GLS Spring Framework handles authentication of users with
administration privileges with the help of the “Authentication” layer. User
authentication in GLS is required to perform administration related functions (e.g.
adding, removing Spatial Objects etc.) in the “Linked Resource” layer.
Fig. 4. Integration of the “Linked Stores” within the GLS Framework
As illustrated in Fig. 3 and Fig. 4, depending on the implementation, a GLS Linked
Store can act as an interface to any type of service or data store within the GLS Data
Source layer. For example, a GLS Linked Store could be implemented as an interface
to a single service responsible for serving up linked resources in various supported
output formats; or a set of aggregated services, where each service is responsible for
producing a specific representation of a linked resource. In other words, the GLS can
be integrated with any concrete implementations of Linked Stores conforming to the
Linked Resource interface specifications. Thus, the GLS framework enables the
publication of both existing and new geospatial data sources as linked-data.
5.2 Prototype Implementation
We implemented a prototype of the GLS framework for a demonstration dataset
(described later in Section 6) with the LinkedSoStore implemented using OGSA-
DAI31 - an open source framework for distributed data management. OGSA-DAI
provides the LinkedSoStore with an uniform interface to access and integrate third-
party heterogeneous relational as well as web data sources (Fig. 3). We extended
OGSA-DAI to support RDF resources using the D2RQ platform32 (the mapping
engine behind the D2R server). Relational data sources are transformed into virtual
RDF graphs using a mapping file, which describes the relation between an ontology
and a relational data model. D2RQ also provides RDF/SPARQL access mechanisms
to support different types of linked-data query on the legacy geospatial data resources.
With this extension to OGSA-DAI, we are able to exploit different types of third party
data services and convert their output into linked data representations using
configurable OGSA-DAI workflows. With OGSA-DAI open framework, new data
services can simply be wrapped and deployed into these workflow via software
configuration. The LinkedDocStore and LinkedDefStore were implemented as
interfaces to two native RDF triple stores (Fig. 3). The prototype GeoTOD Linked
data server is available at: http://tiger.dl.ac.uk:8080/geotodls/index.htm
5.3 RDFS Generator
To support the provision of ontologies via RDF, we also developed a simple UML to
RDFS conversion tool for converting UML-based conceptual models of a domain,
such as INSPIRE thematic data specifications, to an RDF schema (ontology).
Fig. 5. Generation of RDFS vocabulary from UML Models created using Enterprise Architect
(EA)33
In general, this tool allows generating RDFS vocabulary from an XML Schema
transformation of an INSPIRE UML model (Fig. 5). It is mainly designed to support
the GML application schemas (XML schemas) generated by FullMoon34 - a widely
31 OGSA-DAI - http://www.ogsadai.org.uk/
32 D2RQ - http://www4.wiwiss.fu-berlin.de/bizer/d2rq/
33 Enterprise Architect - http://www.sparxsystems.com/
34 FullMoon - https://projects.arcs.org.au/trac/fullmoon/wiki/FullMoon
adopted tool for generating (GML-based) XML Schema representations of the ISO
19000 series (adopted by INSPIRE) UML models. (It proved easier to generate RDFS
from the XSD representation, rather than directly from UML.)
The underlying algorithm for performing the XML Schema-to-RDFS conversion is
tightly coupled to the naming convention of XML type definitions and element
declarations. However, these conventions arise from UML-to-XML encoding rules
specified in ISO 19136 (‘Geography Markup Language’, Annex E), from which the
underlying UML classes may directly be inferred. The RDFS Generator is available
at: http://tiger.dl.ac.uk:8080/rdfsgenerator.
6 Demonstration Datasets
We have tested our prototype implementation of the GLS framework using the
Ordnance Survey’s ‘Strategi’35 dataset in order to demonstrate the transformation of
an existing resource into linked-data form. The Strategi data is relevant to the UK,
containing a view of the whole UK including natural and man-made features. This
dataset has been made freely available online under the Ordnance Survey’s
OpenData™ initiative in support of the UK government’s ‘data transparency agenda’.
For this, we have used an ontology auto-generated from relevant INSPIRE
conceptual models (i.e. the ‘Hydrography’ and ‘Transport Networks’ themes), using
the RDFS Generator described above. Additionally, it was necessary to convert the
Strategi data from the original ESRI Shapefiles36 to relational data format (i.e. SQL)
using a freely-available tool, namely shp2pgsql37, and then store it in a PostgreSQL38
database. As well as following the UK URI guidelines for spatial data, our prototype
provided several representations of Spatial Objects through HTTP content negotiation
– RDF, HTML, and GML. The latter was provided through the Geoserver39 open-
source Web Feature Service application.
7 Conclusions
The most significant outcome of the work presented here is a customisable linked-
data framework that is aligned with the UK Cabinet Office’s draft guidelines on
applying linked-data in the geospatial context. In developing this framework, we have
identified and attempted to articulate and address a number of issues and hidden
assumptions with these guidelines. In addition, we have learned key lessons that
should be considered by other members of the geospatial linked-data community.
Foremost amongst these is the requirement to more fully develop mechanisms for
mapping geospatial conceptual information models (normally formulated in UML) to
35 http://www.ordnancesurvey.co.uk/oswebsite/products/strategi/index.html
36 http://en.wikipedia.org/wiki/Shapefile
37 http://postgis.refractions.net/docs/ch04.html
38 http://www.postgresql.org/
39 http://www.geoserver.org
RDF schemas and ontologies. Further, our implementation of the demonstrator
provides an optimal solution combining both the strengths of OGSA-DAI for
implementing database-to-linked data transformation together with a linked-data
server that can be customised to support other both existing and new data stores and
data formats.
On the whole, the work presented should benefit those organisations looking to
deploy their geospatial data assets as linked-data among. While a number of industry
players are developing commercial tools for linked-data, the availability of a
conformant open-source framework will provide substantial benefit both to
organisations wishing to publish their geospatial data as linked-data, and to the
linked-data community (and Cabinet Office CTO Council itself) in developing best
practice in this new field. Notably, the GeoTOD framework was used in a recently
completed high-profile project, namely ACRID40 that has developed a linked-data
approach to publishing complex scientific workflows associated with climate research
datasets held by the Climatic Research Unit of the University of East Anglia.
However, in order to fully exploit the work described here, further engagement
with key players in both the linked-data and geospatial communities will be required,
especially those involved with the UK Location Programme and INSPIRE.
Furthermore, the initial development and proof-of-concept presented in this paper is
only a small part of the effort required to develop hardened software – significant
extra development resource would be required to take the project outcomes the next
step to a fully tested, efficient, and reliable software product. Future work will need
to address these issues.
Acknowledgments. We are grateful to Dr Brian Matthews (Group Leader, Scientific
Information Group, e-Science Centre, STFC) for his advice and feedback. The work
presented in this paper was funded by the OMII-UK (formerly the 'Open Middleware
Infrastructure Institute UK').
References
1. Berners-Lee, T.: “Putting Government Data Online”, W3C (2009),
http://www.w3.org/DesignIssues/GovData.html
2. Bizer, C., T. Heath and T. Berners-Lee: “Linked Data – The Story So Far”, International
Journal on Semantic Web and Information Systems, 5(3), 1-22 (2009).
http://tomheath.com/papers/bizer-heath-berners-lee-ijswis-linked-data.pdf
3. UK Cabinet Office: “Designing URI Sets for Location”, v1.0 (2011).
http://location.defra.gov.uk/wp-
content/uploads/2011/09/Designing_URI_Sets_for_Location-V1.0.pdf
4. UK Cabinet Office: “Designing URI Sets for the UK Public Sector”, v1.0 (2009).
http://www.cabinetoffice.gov.uk/sites/default/files/resources/designing-URI-sets-uk-public-
sector.pdf
5. Berners-Lee, T.: “Linked Data – Design Issues”, W3C, (2009).
http://www.w3.org/DesignIssues/LinkedData.html
40 Advanced Climate Research Infrastructure for Data (ACRID) -
http://www.cru.uea.ac.uk/cru/projects/acrid/