The Object Network

No URLs?

O'Reilly's Government as a Platform chapter is an excellent foundation for a strategy for Digital Government, with enough examples, guidelines and slogans to keep any Department going for years.

But it's missing a vital ingredient to fulfil its vision: Data should have URLs!

That is the first of four "Data Platform Principles" that I'd like to propose, as the base foundation for building Government-as-a-Platform.

Note that none of the following has anything to do with the Semantic Web or Linked Data - what follows is simply about applying the most basic principles of the unbelievably successful Web.

Data Platform Principle 1: URLs Pointing To Data

Now supplying URLs to access data may seem so obvious it's not worth mentioning, and a less technical person might even assume that the techies would obviously have that covered. But it needs to be demanded explicitly if it's going to happen, because currently the mainstream approaches are ignoring this principle - at great cost to any would-be Open Platform.

O'Reilly cites Berners-Lee's Web next to APIs and iPhone apps all in the same breath. But APIs and apps have not scaled anything like as well as the Web.

Why? Because they don't have URLs.

Each app, each API is a closed, mutually-incompatible, often proprietary land-grab, almost designed to stifle the free expansion that the open web offers. Unlike the browser, each app is your special gateway to the walled garden of that service.

API consumers have to learn a whole new language and write more new code for every API used. Each API represents a uniquely-shaped pipe joint to each service's silo. APIs may use the Web's technology (HTTP, JSON), but the URLs in APIs are not handles on data.

The first API you build should be one that simply gives access to the data via URLs. If a Government Data Platform is to be built on the principles of the Web, the first and most obvious thing it needs is URLs pointing to its data.

Doing that leads inevitably to the three other (equally obvious) principles for Government via a Data Platform..

Data Platform Principle 2: URLs Inside Data

We have partly addressed this one through the Standards Hub and the Persistent resolvable identifiers profile, but it still needs to be stated more simply: Put URLs inside your data!

Create a wide landscape of interlinked data, even linking to data from other Departments.

That creates a web of data, like the world-dominating web of documents. Webs are exponentially more powerful than isolated buckets.

Again, note that this is not the same as the Semantic Web's "Linked Data", in spite of the similarity in the words. It means just what it says: "Link up your Data"!

Data Platform Principle 3: Data Looks The Same If It Is The Same

As Tim Berners-Lee said in his proposal for the Web in 1989:

"Most systems available today use a single database. .. There are few products .. allowing links between nodes in different databases. In order to do this, some standardisation would be necessary. "

If you have links between your data, you'd better make sure that anyone jumping those links recognises what they see when they get there.

It's another obvious principle that still needs to be stated: Don't create arbitrary differences in your published data!

If you publish data with contact details, don't be arbitrarily different from the contacts published by your colleagues in another Department. Doing so adds friction to the whole Platform ecosystem, requiring literally pointless extra code to be written to cope.

The benefits are not just in reduced costs to engage. You should follow Tim's HTML: keep backwards-compatibility and eliminate all that headache around API versioning. For example, your browser can still read this document created by Tim in 1991!

Make all data look the same if it is the same. You may use the standards published on the Standards Hub, such as vCard and iCalendar, or those on schema.org, for example.

Don't reinvent the wheel, always look for a matching data standard first.

Data Platform Principle 4: Publish Derived Data and Link Back To Sources

Just applying the above three simple, proven principles would be enough to create a Government Platform that would be revolutionary. Simple and powerful: link up your data and use data standards.

This fourth principle is no less obvious, simple or powerful. It describes how the Government Data Platform or data landscape described above would be used, built upon and evolved.

In short: when you derive new data from the stuff that's already out there, republish it alongside (or 'on top of') the source data, linking back to it.

That way, you stand on the shoulders of others, give them credit and give users immediate access to your sources.

It's up to you how often you update that dependent data - you could poll for changes in the source data every second or every month. You could regenerate it on a schedule. You could use some kind of notification mechanism to be alerted that it's changed and that it's now time to refetch the sources and regenerate your dependent data.

Government as a Platform means creating a Web of Data

It's actually odd that no-one, Government or otherwise, routinely publishes data on URLs.

Doing so could lead to a revolution as far-reaching as the original Web itself.

Government is, of course, uniquely positioned to lead that revolution, especially the UK Government, through GDS. The UK Government could create the first city in a global landscape of data.

Here's a Government as a Platform slogan to add to O'Reilly's calls to action:

"Link all the Things!"

Duncan Cragg, 2016

Contact me and/or subscribe to my blog and/or follow me on Twitter.