Week 8 - Prototyping APIs

We're still in the summer holiday period here at the Centre for AI & Climate, so you have me (Steve) writing these for a change, whilst Jon takes a short break.

This week we have something a bit different to talk about, as we've pen to paper - well, keyboard to editor - and actually built something of a prototype.

We’ve had a lot of conversations and done a lot of research since the start of the project, trying to find the right overlap between what users have told us they need and what is possible with data that exists today. As Jon has covered in previous weeks, it's been a tricky cycle of seeing potential in the data, but hunting for the killer use case that would tell us what to build to make the most of it.

With our first prototype, we've taken a slightly different track of meeting the data where it is today and trying to make the most of it, while keeping users' options open on exactly how to use it.

The basic idea is this:

• Electricity Distribution Network Operators (DNOs) are releasing increasingly granular smart meter data, which has huge potential, but it’s hard to get it all in one place.
• Even when you do get it, you need to do a lot of work to make it usable.
• Furthermore, you can’t really use it in isolation - you need other information about the grid and ideally about what’s going on behind the smart meters to make sense of it.
• Really useful parts of that information also now exist but they’re not immediately useful either - they don’t “match up” to the DNO data in their native forms.

What we’re proposing is basically bringing all this stuff together: energy consumption, building performance and low carbon technologies. Doing the hard work of collating everything to the grid topology and other spatial aggregations, so that we unlock the potential of the smart meter data.

We've put all our ideas together for this as documentation for a hypothetical API that could serve this data, which you can see here:

https://bit.ly/3yUUYzk

This is a really neat way of prototyping something that looks and feels real enough to get useful feedback, but is also quick and easy to change. It also happens to be generally accepted best practice: outside-in or API-first design, win-win!

The prototype we’ve put together is a REST API. This might not be the best or only way we share this data in the future, but it seemed a good way to try to explain the concepts and possibilities initially.

We know there are some obvious things missing, like metadata about provenance, freshness and the processing we’ve done - you can assume we’ll flesh that kind of stuff out in due course.

We’ve also been intentionally broad in the options the API supports - it’s designed as a generic repository that we could load lots of different kinds of data into in the future, from lots of different sources. It’s probably way too much work for a small team to build everything here.

We'd love to get your feedback on this and see if we've hit upon anything useful:

• Would this kind of data, collated in this way, be useful to you? If not, why not?
• If it does look useful, which bits you would use? What’s the first endpoint you’d want to call? What parameters would you pass?

Until next week!

Steve