Following on from Catherine’s blog post on the subject of Openness, I thought I should lay out the roadmap that the Development Department is going to travel in order to provide our clients, and their clients in turn, with open data from our applications.
As I am in the main a man of structure, process and words, I’ve started by laying down the two types of document that will be created to support the process. The very simple mind map (right) shows these (click on the picture to expand). Firstly, I am working on an “Open Data Application Policy” document that will define how our applications will implement access to their data, and which also defines the structure of the second document type – the “Application Open Data Specification” – that will define, for each application, the data that a client can expect to get from the application.
Is this process necessary, or should we just get on and “give you the data”, as the Open Data evangelists would, well, evangelise? Personally, I think that it’s important to have this framework in place: it preempts a number of questions from the developers; it ensures consistency of implementation across applications (and, let’s face it, Linked Data is our ultimate goal, with Open Data being just a small step towards it); it promotes reuse within the organisation; and finally, it’s easier to correct mistakes in documents and processes than it is in code. Also, I hope it may be of use to others who are in a similar position – it is my intention to publish the policy document under a Creative Commons licence, as part of our move toward open practice.
As a taster for what’s to come, here are a few bullet points from the Open Data Policy document (remembering that it’s a work in progress):
- Access to data via a RESTful, read-only API
- API interrogation data will be available via the API. (I.e. you can ask the API what things people have been asking for.)
- Clients can opt out of providing their data through the API, but it is open by default
- Application’s UI will provide a clear link to the API documentation
- Data will be available in a number of formats – XML, JSON, CSV, (and various RDF formats for linked data)
The plan
So the plan, then, is as follows:
- Finish the Framework document
- Define an Open Data Specification for the Connect product
- Implement the specification in the Connect product
- Repeat 2 & 3 for our other applications
I don’t have any concrete timescales at this point, but I would expect to complete the Framework document before year end and have it published early in the new year. A template document for the Open Data Specification should follow swiftly thereafter.
I am in discussion with a client regarding open data in the Connect product and will define its Open Data Specification, and get the framework developed, with their input and support.
Look out for further blog posts as we work towards our goal of providing access our application data in an open, well defined way.
