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.
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
5. 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.
6. 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
15. 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.
Notas do Editor
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
