Local Digital Coalition

by Paul Mackay, Technical Lead for the DCLG Local Waste Service Standards Project

In this, my 2nd blog on our emerging data standards for local waste services, I’ll focus on the data model I’m building, why it’s structured the way it is, and what I’ve learned about building common data models for local services so far.

For anyone new to this series, I outlined the kinds of things we’re building and defined them, and I talked about the taxonomies we’re using in my last blog, so start there if you’re coming in fresh!

What’s a data model?

As I wrote last time, a data model is a key part of designing how digital systems can talk to each other. It defines the objects of a system and what properties they have. For example, waste collections empty bins of different types and sizes. Our data model will describe a local authority waste service. It’s the foundation for the standard application programme interface (API) we’re building to interface between the different software systems that support waste management, from in cab technology, to customer services systems, to web forms and websites.

What our standard data model looks like and why

The data model is organised around several general objects with extra detail specific to waste services added where necessary:

• • Services: the different types of collections that are offered by the council

• • Tasks: units of work to be done, e.g. emptying bins at each property

• Events: unusual occurrences that need to be recorded, such as a bin being too full to empty

How councils and suppliers influenced the design

We partnered with 5 councils on this project to make sure that our suggested data model and API would work for all of them. Our hope is that this group is sufficiently diverse to represent all local authorities – or least to establish a standard that could be adapted to work for everyone. So, some of our partners outsource collection, others do everything ‘in house’. Some are building their own web services, others use forms built by suppliers.

We’ve also tried to work with councils that use different ‘in cab’ technology in their bin trucks, and different case management systems, as these varying suppliers will be crucial to the impact and sustainability of the standard. In other words, the majority of waste management IT is designed and maintained by the private sector. So, we must ensure that they are broadly on board if councils are to benefit from data standards and the interoperability of IT systems that they allow.

Our individual workshops with all partner councils made clear exactly what the data model and API needed to do, what functionality it had to have. However, the real key to success has been to get a copy of technical documentation from different in-cab technology suppliers and councils who run digital waste services, and talking through how it should influence the standard with these suppliers.

The biggest challenges so far

This has posed perhaps our biggest challenges to date:

1. Getting a hold of data models and API documentation that suppliers aren’t used to sharing. This was especially hard at the beginning of the project, but has become a lot easier as we gain momentum and supporters. Our business case work and communications material has been essential in getting this buy-in and in convincing suppliers that it’s worth their while to support the standard.
2. Proposing something that all these organisations are actually willing and able to adopt.
3. Testing the new model that I’m proposing: Documentation and test systems to interact with are useful but can take longer to obtain due to the nature of the services and relationships with their customers (sometimes via a waste collection company). Their existing models give useful insights towards a common model but choices must be made. For example, should a resident’s property be called a Place, Premises, Site, Property and so on. We’re lucky to have increasing access to test data from a number of suppliers now, so will be working on these details over the next month.

So, while our standard data model has already taken form, as you can see on the github page, we’ll still be tweaking it over the coming weeks to ensure that the version that’s implemented by a number of organisations as part of this Beta phase of work is the beginning of a sustainable standard.

Taking the best of other standards and protocols

There are 3 main national and international data standards frameworks that I’ve used as a template for the Waste Management Data Model and API.

1. 1. Schema.org is a leading international repository of data model definitions for everyday things. As a rich source of general data models used for website metadata, schema.org is a good starting point. Imagining how the waste models could fit into the schema.org type hierarchy can help to link with existing concepts. Its properties can also be applied to new properties where applicable.

1. 1. I’ve also taken inspiration from the Popolo Project which, though less influential than schema.org, is a great example of data models for democratic processes built on common specifications for representing Organisations, People, etc.

1. The Smart Cities Data Concept Model developed by iStandUK and the British Standards Institute is another framework that focuses on the UK. It was developed in partnership with a number of cities to map out how all kinds of city data might interrelate. So, we’re doing our best to abide by this standard, and are informing its detail as we go in partnership with iStandUK’s standards lead, Paul Davidson.

Government as a Platform (GaaP)… because we have to mention it

This year’s local government trending topic is Government as a Platform and how to think of a council’s digital systems as a set of reusable capabilities rather than siloed systems. Thus it is quite important to model stuff in as decoupled a way as possible. In the case of our waste management data model, the most obvious example of including reusable capabilities is defining a common ‘Places API’ for postcode lookup that is separate from the Waste API, which is specific to waste services. Likewise, when the API is expanded to include paid for services, the ‘payments in’ function would be separate to better connect with other services that the council charges for, like parking permits and council tax.  

Keep iterating

Designing for the needs of a diverse group of councils, supporting integration with multiple suppliers and accommodating aspects of a wider framework is a nebulous and challenging task, and it’s important to adjust as new insights and information emerge. So, right now, we’re doing as much as possible to get the basics right before working with our collaborating suppliers and councils to implement our waste data model and the API it will power. We hope to start implementation in December and have a few examples up and running by by February’s Beta Showcase.