Throughout the Open Data Scotland Code for Europe project so far the names of various APIs and server technologies have been thrown about – usually rapidly followed by the questions of:
- So what is it?
- What’s the difference between A and B?
- Do we need A if we use B and how does adding C affect it all?
- Can we download it or do we have to write it?
- Where’s it going to be hosted?
As anyone who has even vaguely glanced into the world of software knows, part of it is working on what you know and a big part of it is exploring and learning new things – a learning that often includes failing at something so it can be eliminated from the list before trying a new approach.
With this in mind I must add the caveat that at the time of writing, this blog post is based on my current knowledge and may well prove to be wrong as I learn more.
The current list of server and API technologies in the project is as follows:
Now a list of only three may look unimpressive but that combination has caused all of us involved to do some head scratching to varying degrees.
In addition to the above list, we also have numerous legacy internal closed data sources locked away behind local authorities’ firewalls.
In the trials so far this data has included:
- Community Groups (which take place at various locations)
- Community Centres (physical locations where the community groups hold their activities)
- Sports Centres (physical locations)
- Sports Activities (which take place at various locations)
- Car Parks (physical locations with varying available capacity)
- Food Hygiene Reports
- Freedom of Information Requests
This is an API specification used for reporting non-emergency issues to a local authority and for finding out information about services provided by a local authority. It is designed to be communicated with by other software rather than humans.
For our project we are creating our own Open311 server that meets the API specification.
This is a server that hosts a directory of links to data. It is designed for data discovery but not so friendly for the average human consumer wanting everything presented on a plate.
This is an API specification used for merging different layers of data into objects that can be easily displayed on a map. These different layers of data can come from various sources and are not restricted to geolocation data.
For example, using the Sports Centre information from Open311 merged with the Sports Activities from Open311, an item can be added to the map that when clicked displays the activities at the venue. This could also link to entries in the CKAN server to point to Food Hygiene Reports for the cafe at the venue.
All of this would be displayed on a map which is generated in a web page or mobile app that sits above the CitySDK layer.
For our project we are creating our own CitySDK server that meets the API specification.
The accompanying diagram shows how the various components of the project fit together.
In addition to the data being consumed and displayed by a top-level application, it is possible for an application to extract data directly from the Open311 or CKAN layers.