This is a guest post by Liam Green-Hughes, a developer at The Open University, relating his experience with Linked Data to date, and his initial use of Linked Data from http://data.open.ac.uk.

Over the last few months I have been on a bit of a journey in the world of Linked Data. It has had highs and lows, frustrations and triumphs, but in the end it was worth it. When you first enter the world of the “Linked Data movement” the terminology can be baffling it is a world of “triples”, “RDF”, “SPARQL” and lots of other terms that will come as news to many developers. Yet when you see past all that it turns out it is a genuinely useful concept to developers like me. Over the past few weeks I have been experimenting with the Open University’s new Linked Data service in a number of scenarios and have now used it in a production environment.

Without a doubt the learning curve involved in being able to use Linked Data is significant. Some of this may be down to the fact that it is relatively early days for such technology so it will take a while to settle down. A lot of the learning curve to do with learning the SPARQL language. It was designed to be a SQL-like way to obtain data from endpoints. I have heard it described as “more powerful” than SQL but I am not sure that comparison serves much purpose, the two languages have similarities but exist to do different things. SPARQL often feels more difficult to understand, less obvious what is going on that SQL. Maybe it needs some more work as a language in order to open it up to more developers. Once you have worked out a few example queries though you have enough to get going and at least.

A breakthrough on my journey to be able to use Linked Data was the realisation that I should just stop worrying about the terminology and get on with using the data. When you query a SPARQL endpoint what you actually get back is XML or JSON. For a developer this is wonderful as many programming languages include tools to parse these formats. Sure there are libraries available that will give you richer functionality, it just depends on what you want to do. Parsing incoming results is easy enough. When I realised this I wrote a blog post “An approach to consuming Linked Data with PHP ” which provided me with a basis to do other things. There are many things that are complicated about Linked Data, but actually sending and receiving information to an endpoint turned out not to be one of them. In fact it turned out to be easier than using a SOAP service!

Many people use Linked Data services to construct reports or create mashups but I started experimenting with another theme. Linked Data is part of an idea to move to a “web of data” from a “web of documents”.. For me this fitted very well with another big change happening in the web; the move away from just looking at web pages on a desktop computer to consuming data on lots of other devices like mobiles, smart televisions and tablets. Each of these classes of devices have very different user interface requirements, often with dedicated applications. The underlying data driving these applications can be the same though so my experiments so far have centred around the idea of bringing OU data into new contexts such as mobiles and to the social web.

In the OU’s Linked Data store we are lucky enough to have access to all sorts of data including podcast information. With an idea in my head about using Linked Data to reach devices I looked at the new JQuery Mobile library which is designed to make creating mobile web applications easier. So the actual application still runs on a server, but when you view the output of the application on a mobile web browser (or in a thin app wrapper) it looks very much like a mobile application. The advantage of this approach is that you end up with something that works across a variety of mobile devices, for a fraction of the effort it would take to create apps for each mobile operating system. I created the app with navigation menus to drill down to the podcast you require. This was quite easy to do as I could create SPARQL queries on the fly using menu selections to filter the information. In fact I could get a prototype together in only a few hours. It would need more work to be production useful, but being able to use SPARQL on the fly was very useful.

Encouraged by this success I felt it was time to put our Linked Data store to good use with a production requirement. We have an application inside Facebook called Course Profiles which enables students to advertise what course they are studying with the OU on their profile page. For a while keeping the course list up to date has been a bit tricky. It used to be done by either manually adding entries or taking input from a file containing all of the course codes. Linked Data came in useful in this case as we can use it to obtain the live course codes and load this directly into the database though the application. The data was quite easy to parse and then it is possible to work out which courses are missing and add them. This will make it much easier to keep information up to date and I know that it is coming from a publicly documented source, making it easier for me as a developer to work with.

My third experiment was to try to hook up the Linked Data service to Google’s App Inventor for Android. Connecting these two cutting edge developments seemed like a good opportunity to me, having all of this data readily available means that all sort of new apps will be possible. App Inventor isn’t just a great teaching tool for programming, it is also a great prototyping tool. Creating an app this way might not lead to such a polished result as coding by hand but does mean that you can quickly experiment with building different kinds of apps quickly and with limited effort needed. App Inventor is a little limited in what it can cope with in web data terms, so I wrote a script to enable conversion of the results from an endpoint into a format that App Inventor could deal with. Full details are in my post: Using Linked Data in App Inventor for Android with the help of a bridging script.

So why not just use an API instead of Linked Data? Many developers are used to using APIs and many sites, e.g. Twitter and Facebook support an API to extend their functionality. I don’t think Linked Data is necessarily better than an API, but it might offer a better solution in some circumstances. The data you can return is very flexible, you don’t need to look up the syntax of a new API call every time you want new information. Also if two sites support a Linked Data endpoint the way you work with them will be broadly the same, you don’t have to worry about things like downloading any extra software libraries to be able to access the API.

It would be wrong to ignore the issues around the usage of Linked Data, the learning curve involved and the difficulties in making those first steps. My own journey with it has been difficult and at first I wasn’t persuaded. Now having experimented with it and forced myself though a bit of the learning curve it is delivering on its potential and I am encouraged to continue learning about this technology. It is still early days for the Linked Data movement so it is a great time for developers to get involved and help this idea grow and work with others to sort out difficulties along the way. The prize is ready access to lots of information about the world around us.