by Paul Mackay, Technical Lead for the DCLG Local Waste Service Standards Project
Our February 22nd beta showcase marked the end of our product development phase, and the beginning of project wrap-up. So, in this blog, I want to explain how far I got in producing some common technical standards for council waste management that will help realise the benefits alluded to in our video and business case. To techies, some of it will sound quite obvious, but as we’re keen to demystify this stuff for business owners, we think it’s important to try to share our work as accessibly as possible! Here goes…
Taxonomies
One of our first building blocks was a common taxonomy for reasons for missed collection or ‘missed collection events’. While developing this, it made sense to start compiling other related taxonomies, given that some work had already been done to develop them.
The benefits of using these common taxonomies include:
- simplifying and standardising the descriptions of waste services for residents
- reducing the effort of improving and updating services and related products and web pages by taking advantage of ready-made lists of terms
So, here’s a quick walk through the taxonomies on our GitHub page, how they were created, and what kind of benefits each one brings.
Containers and materials
There is significant variation in the way elements of waste services such as materials collected and containers are described, both on council websites and in the software that supports waste services. This is partially a consequence of the diversity of council waste services. However, difference in service does not need to mean that the underlying technology or the language we use to communicate with citizens needs to be different.
As WRAP have done extensive work on defining materials and container types, we decided to develop them into machine readable taxonomies with multiple attributes based on these so that they can be easily integrated into council websites and tools. This means the taxonomies can be used in different scenarios, for example:
- the basic names should be clear for presenting to citizens
- the container sizes could populate a size dropdown selector in a “request a bin” form
- the machine names can be used in API data objects
At the moment, two common patterns used to describe services and containers on council websites are:
- colour and name, e.g. black wheelie bin
- material and name, e.g. mixed recyclables bin
By taxonomies with multiple attributes, we start to create the common building blocks of our data model and, ultimately, it becomes easier for a council that uses a small green wheelie bin for garden waste to use the same technology as a council that uses a big green wheelie bin for glass, plastic and cardboard recycling, for example. Moreover, using common language in the citizen-facing parts of the service (website, calendars, etc) should ultimately make it easier for citizens to understand the system when moving between districts.
Bulky items
The bulky items taxonomy can be easily converted into a list or used to populate a web form, again, with additional attributes added. The “qualifier” column offers extra information for display. For example, rather than listing the bulky item as a ‘cooker’, the display can also highlight whether it’s gas or electric. So, a website using the taxonomy might display information about the bulky item as ‘cooker, electric’ or ‘cooker (electric)’.
This additional data about the item can help in presenting the list to users or filtering for later processing. For example, it can identify electrical items that can be forwarded onto local charities for reuse or resale. And, if the software that charities use to find material is powered by the same data formats, it becomes possible for them to proactively find materials that councils are collecting.
The bulky items and collection events lists have been developed by reviewing and combining similar lists from several councils as a starting point but could be improved further. We need your help! If you see problems in using any of the taxonomies, or have suggestions on improving the terms, please get in touch or, better still, create a GitHub issue.
Missed collection events and the API
As Linda explained in an earlier blog, our 5 partner local authorities prioritised ‘missed bin reports’ as the highest value problem that some common standards (some common data protocol) could solve.
So, we set out to build some common rules to enable all the bits of tech that allow councils to resolve missed bin reports to share data in real time. This meant establishing taxonomies and a data model, which begins to explain how all the parts of the service should be referenced by our technology and software. See my introduction to the data model here.
However, a data model on its own is a little intangible to business owners and untested to technologists. So, we built an API to illustrate these rules in action. As mentioned in my earlier blog, an API is a bit of technology that allows the different software systems that support waste management to talk – from in cab technology, to customer services systems, to web forms and websites.
So, the final taxonomy to mention, the ‘missed collection events’ taxonomy was both our starting point and the foundation for the application programming interface (API) we built to demonstrate the standard in action.
The primary aim of our API is to allow data to move automatically between software systems that deal with resolving missed bin enquiries in real time. This means:
- Citizens using the council website, customer services teams and others can see and understand why a bin was not collected quickly and easily as soon as the collection truck reports it as missed.
- In a well-designed service, this real-time information flow will reduce customer call volumes, by enabling citizens to self-serve on the website, and when people do call the council, customer services teams won’t spend time trying to figure out why bins were missed, as they’ll have a real-time record on their system.
- It becomes easier and cheaper to integrate with supplier systems if they implement the API.
- Longer term, the API should evolve to cover more parts of waste services. So, those using it can be confident that the services they use it to manage will be well designed and integrated.
Again, having a shared set of missed collection event reasons can also help with consistent communication between councils and citizens whose behaviour they want to influence.
One comment heard a few times during this project is that it is good to standardise on the API and data exchange at a technology level, but councils can then still write their own messages in the communication that goes to residents. This is true, but the design principle of “be consistent, not uniform” feels very relevant here. Waste services in general can be made better and less confusing by more consistent use of language across local government.
Equally, consistent access to data via APIs built around common data models can make integrating different digital capabilities simpler. Think of when multiple services need a ‘book something’ capability. If all APIs deal with booking in the same way, they’ll make it easier for councils to evolve their business model into one where common capabilities are built once and used by all the council services that need them in an ecosystem where APIs all speak the same language and fit neatly together.
In terms of our pilot, what has been published so far for waste services is a start, but additional data models need developing for other parts of the service, such as bulky waste collections or fly tip reporting. Moreover, the implications of trade waste would need to be assessed, which is more complex than household waste. In spite of the work that needs to be done however, we’ve created the best tested common taxonomies, data models and API for the service to date, and we’re keen to keep the initiative alive and improving. So, please help spread the word among your technologists, and waste teams and suppliers, comment on the code in GitHub and we’ll integrate any final comments by March 15th before the pilot phase wraps up.