This talk will describe the RAGLD framework (Rapid Assembly of Geo-centred Linked Data) and examples will be given on how it can be used to make it easier to develop linked data applications.
As more linked data and open data emerges a need was identified to meet a rising demand for a suite of application developers’ tools to make it easier to bring together, use and exploit these diverse data sets. RAGLD aims to create a set of tools, components and services to make it easier to develop linked Data applications. This talk will describe the RAGLD framework and examples will be given on how it can be used.
2. About RAGLD
• A collaborative project between Ordnance Survey, the University of
Southampton and Seme4
• Part-funded by the Technology Strategy Board„s “Harnessing Large
and Diverse Sources of Data” programme
• 18 month long project. Started Oct 2011. Due to complete March
2013
• Building tools to enable developers to make greater use of linked
data
3. “Linking Open Data cloud diagram, by Richard Cyganiak and Anja Jentzsch.
http://lod-cloud.net/”
6. As more and more linked data and open data emerges, RAGLD aims to meet rising demand for a suite of
application developers‟ tools to make it easier to bring together, use and exploit this diverse data.
This project aims to provide the tools, components and services necessary to build linked data applications,
helping to speed up and enhance the use of linked data and realise the potential in linked data for data
integration and discovery.
7. Tools and Services
• Relationship Management Services
• Data Enhancement Services
• Data Transformation Services
• Spatial Query Services
• Reconciliation Services
• Visualisation Components
• Linked Data Publication Framework
• Workflow Management
• Federation of Services
22. RAGLD provides access to tools and technologies that
enable data consumers to easily select, filter,
manipulate, visualise, transform and communicate
data in ways that are suited to specific decision-making
processes.
23. Contact for further information
John Goodwin
john.goodwin@ordnancesurvey.co.uk
Notas do Editor
1 Needs a web serverGo to your friendly Nimbus store and pick up one of their standard box sets. For our internal version of RAGLD, we chose a LAMP stack. A basic linux machine, nothing particularly special in terms of memory, processors or disk space. In fact, we only have a default 50g of disk space – Nimbus is keen that people only order the amount of space they need at the time, in the knowledge that it can be extended later. The LAMP stack provides everything we need to build our web applications.On top of the basic services, we added PostGIS as I thought it provided more advanced spatial functionality than the MySQL Spatial Extensions. And it’s also open source, hugely popular and has very good online resources. We also installed the raptor RDF interpreter and a couple of other things. Everything that RAGLD uses is open source and easily available, and to make things easier there is a RAGLD installation script that fetches each of the packages and installs whatever isn’t already available on the host.With all the building blocks in place, we can now run a RAGLD setup script that will create a local environment and we’re good to go.The core of RAGLD is built in php, as are all of the individual services. It’s easily configurable, once you know where to go, and remarkably simply to add new services for additional functionality or to support new data.PostGIS is used to store data. Run spatial queries. Common methods perform the tricky extract of spatial information from online resources.
To access the local environment, type in the address in a browser. So, for example, lv320.ordsvy.gov.uk/tony, and you get the welcome page
Click on the index of services to see what services are available in the current environment. All of the available services are written in php and accessed through the address bar (or by clicking on the links).
This is the section of the config file that sets up the data source for the airports service. The common template file is the GeospatialRelationshipService.php, and that has all the method calls for running spatial queries. To make it specific for airports, we set the datasource in the config file. We’ll do this sort of thing whenever we’ve set up a local store of indexed URIs (basically a PostGIS table of URI/geometry with a spatial index) which simplifies the querying. The URI in the table provides the link back to the big wide world of linked data
Each of the services are called through a php template file, which has all of the common spatial queries. How the file operates for individual service types (ie to access airports, but stops, postcodes and so on) is configurable in a turtle file in the home directory for the current environment.
Services are called through a URI. For example, to get a list of the features available in the airports store you would type http://lv320.ordsvy.gov.uk/tony/services/geo/airport/features/ into a browser, and back comes a list of available URIs which you can then click to wander merrily around the online resources.
Calling the services through URIs is where the RAGLD magic really starts to work. By requesting a service through a URI we are effectively creating a URI that encapsulates the results of that service. So, with the previous example of a service request to list airport features in the index, what we’re effectively doing is creating a URI that embodies that list. So this URI can be passed as a resource to another RAGLD service to do even more interesting things.I’ll go through a simple example to try and explain. Let’s say we want to find B&Bs that are within a certain distance of a planned route
We start with an indexed store of UK B&Bs derived from online resources. The B&Bs are stored in a PostGIS table to simplify indexing and querying
This is a geometry of a journey from Totton to Basingstoke which we will use as the input to our query request. The coordinates could be derived in many ways – in this instance, Ian stored GPS coordinates from a drive up the M3. But they could have been digitised, or downloaded, or whatever. These coordinates are in WKT format, to simplify viewing. The important thing is that it has a URI, which is what we will use to reference the route in RAGLD service calls
We take our URI for the route, and encode it so that it can be passed around the RAGLD services. If we pass the encoded version of the original resource to our ingestion service, we can see the route on a map. Lovely
Again, we start with our route and encode it so that it can be passed around the services. This time, we will call our buffering service to create a 10km buffer around the original line.
We then use that URI for the buffered line as the argument to our B&B ‘within’ service. This is asking ‘which of our B&Bs in the store are contained within the buffered version of the original text representation of our line?’ And back comes a list of results. All very nice, but it would be nicer on a map
So we pass the whole URI of the query of which B&Bs are within our buffered line to thestandard ingestion service to put those results onto a map, with clickable icons that will whizz us off to whatever the online resource is for that URI. So we can do a whole load of things through a single URI that encapsulates calls to various services.Which is all great in theory. But what about in practice? Guy/Lucy can tell us more about whether creating an application in this way is as easy as it sounds
