Continued from page one.
Melbourne
Australian city open datasets can be accessed via the Australia Government’s open data CKAN catalog (which enables all datasets to be called via the CKAN API). Alongside this, open data Platform OpenDataSoft has local agents keen to sell their product to Australian city authorities. Meanwhile, Melbourne has opted for Socrata as their data Portal, which — like New York City — means all datasets are available as Socrata Open Data API endpoints.
To aid discoverability, the city has introduced a simple flowchart for data use, based on the potential role of the API developer-consumer. Potential API users interested in social change, entrepreneurial opportunities, community participation, and urban planning are routed to their own separate data catalog landing pages with a curated set of data chosen for them to initially explore.
In the past six months, Melbourne’s open data portal has seen an average of 5,000 monthly visits.
Challenges
- Timeliness: Melbourne’s data supply is quite patchy in regards to the timing of the data that is being shared. Three datasets that are suited to being regularly updated demonstrate the variety in updating machine readable data:
- The development activity monitor that lists all of the city’s major commercial and residential property development was last updated in November 2014.
- The city’s bike share data is provided as a live Feed in realtime so that it can be used in third-party apps.
- The immensely popular dataset that users sensors to count pedestrian activity (with over 20,000 visits to date) is available as hourly counts at 30 locations across the city … but the dataset is only updated online once a month.
- Terms of use: Melbourne’s open data policy is available as a footer menu option, but cannot be read online. Instead, you have to save the Word document to your computer and then open it from there. The policy confirms that data is provided for free, is reusable, and can be used for commercial product development. The city is committed to releasing all data in machine-readable format, but no assurances are given regarding frequency of updates or reliability of data access.
- Lack of developer engagement: While this is a fairly new initiative, at this stage there isn’t really any focus on cultivating a developer ecosystem around using the APIs generated from Melbourne’s open data catalogue. City-led participatory events have focused on crowdsourcing data — for example, a biodiversity initiative last year encouraged citizens to post photos of local animals, insects, birds, and plants to an open data set — but not so much with application development, as of yet. There is also no official showcase of apps made using Melbourne-related open data.
Singapore
Singapore has a longstanding partnership with UP Singapore, a non-government collective that regularly runs hacklab events aimed at fostering API skills development amongst community organizations, independent developers, and entrepreneurs making use of Singapore APIs. From May 11th to May 16th, UP Singapore will host the Smart Health CoLab, aimed at encouraging skills development around civic apps focused on citizen health. A week-long series of events includes workshops on city health data, smart health services, and a group hack day.
The Singapore developer portal lists four key sets of APIs covering environment and weather, maps, traffic, and Library services.
A marketplace is available that shows what apps have been created using government data sources and APIs.
Singapore’s data website, which includes the API Developer Portal, sees on average 30,000 visits per month. The majority of API searches are for machine-readable data to create dengue fever maps.
Challenges
- Terms of use: Use of the Singapore APIs for commercial applications require developers to register their app first. All uses of APIs in applications must include mention of the dataset source. As with all API government terms of use, there are no guarantees on provision of data or on accuracy or uptime availability. In addition to the catch-all Singapore Government open data terms of use, each API has its own terms of use.
- Documentation: The majority of API documentation is in PDF format. Some APIs require registration first before documentation can be viewed. The mapping API documentation is provided as non-interactive HTML pages, with some code samples included.
- Developer marketplace: Despite the multiple initiatives aimed at supporting developers to create apps from Singapore’s APIs, there is no direct developer showcase or easy way to see which local businesses are building civic tech solutions. The app showcase provides links to app marketplaces but not directly to the developers’ websites.
The Road to City API Usability
These four examples demonstrate that even amongst leadership cities around the world, there is still a lot of work to be done to make APIs usable and reliable for community and business use.
Some of the key issues these city API strategies demonstrate include:
Lack of Uniform Approaches to Metadata
It is difficult in many cases to see a standard format for metadata being prepared for each API. Socrata (being used in New York City and Melbourne) provide a simple metadata table for each of their datasets. Singapore also has its own table formatted metadata.
Limited Recognition of Data Ecosystems
One of the difficulties facing many startups wanting to enter the civic tech space is the fragmented nature of government responsibilities. Data and APIs may be managed or owned by a particular tier of government. For example, in Australia, it is more common for state governments to manage both crime and transport data in most jurisdictions (while in the U.S., these are city datasets). City data catalogs don’t tend to make any mention of this split in responsibilities, which could leave developers searching fruitlessly for relevant APIs within the city catalog without any signposting or reference to other government bodies that could be publishing city-relevant data via API.
Old School Documentation
City API documentation is challenging. Much of the API documentation cited in this research was still in PDF format. Several city websites have tables with links that promise to lead to API documentation, but that instead lead to another landing page with links back to the original page. There is limited use of interactive API documentation where developers can test API calls. Client libraries are pretty much non-existent.
Lack of Developer Marketplaces
While city authorities recognize the economic development potential of releasing APIs, and encourage the use of APIs for civic transparency, few are showcasing the expertise amongst civic tech developers, startups, and businesses that can assist new entrants to make use of city APIs. While several cities include showcases of apps that have been developed for the city, these often link directly to app marketplaces without highlighting the developer teams or providing direct links to the developer websites. In addition, app showcases are now facing the same discoverability issues as open data catalogs themselves: i.e., with an increasing number of apps listed, it is harder to filter search queries to surface those apps of specific interest to the end user.
No Guarantee of Supply
For now, city APIs use terms of use policies that request some acknowledgement of the API source in the end use, and that allow for commercial and community use of data in applications, with few rate limit restrictions on API calls. Some cities require that developers register any commercial application as part of the API terms of use.
Overall, data provided by API is still very much seen as a non-essential service being provided by city authorities. Unlike utility supply such as water and energy, or public transport infrastructure and services, governments are not yet prepared to treat data supply as an essential part of their service delivery and their terms of use make no promise of reliability, accuracy, or regularity of data supply.
No Acknowledgement of Equity Impacts
To date, few APIs are building-in an equity dimension to ensure that new government service design addresses the city-level inequalities that occur between those with access to local resources and those who traditionally have been marginalized. For example, transport data available via API tends not to include parameters on accessibility within the main release. Instead, this is seen as a separate dataset, often released at a later date. In addition, open 311 APIs and building permit API data are rarely discussed in terms of how developers could overlay this data supply with any available census data in order to integrate a socio-economic context into the data feed.
Will City API Supply Grow and Thrive?
Initially, city APIs have focused on providing machine-readable access to static open datasets held by city authorities, but real-time sensor feeds are rapidly being published, with the future hope that transactional APIs will be part of the next wave of API availability at the city level.
So it is exciting to see global cities dip their toes into these API waters. Hopefully, a new era of digital government service delivery, increased civic transparency and accountability, and sustainable innovation will emerge from the increasing provision of city APIs.
To aid the potential rollout of city APIs, new international projects aimed at encouraging open API standards are also blossoming. These projects may help speed up the pace of civic tech innovation, as solutions created in one city can be deployed in more settings. City APIs will require some flexibility to meet local cultural and geographical needs, but standards around nomenclature and data model design can enable civic tech startup agility across city and national borders.
This is just an initial look at city government API strategies and how they encourage discoverability of APIs for use by citizen groups, advocates, entrepreneurs, and businesses. For now, many cities are aligning their API strategies with their open data policies. This undersells the potential that APIs can play in building a city-as-platform model. There are many sparks of promise being shown by the four cities outlined here, and many others around the globe, but much work to do as well to create a solid API infrastructure that can adequately engage developers and end-users in building new tech solutions for the cities we live in.
