Welcome to the ODI
Knowledge for everyone
The ODI helps to unlock the value of open data.
If you want to use our logo, different sizes and types are here: http://theodi.org/brand
At the ODI, you may have noticed that we’ve recently launched a brand new website (you may be reading this blog post on it now). We’re really proud of it, not least because it’s based on the fantastic work that Government Digital Service have done on gov.uk.
However, it’s not just a new website (or even *shudder*, a CMS), it’s a platform that can enable multiple websites. As well as powering the ODI website, it has the potential to power many other websites from the same backend, such as the Data as a Platform and Service website (which you may also be reading this blog post on - we can publish to both if we want).
Now, I know this can be done with many commercial and open source CMSs (such as Wordpress for example), but what makes this special is the way the publishing platform is structured. Instead of treating content as web pages to be published as static HTML pages, all content is treated as data.
Before I go on to describe what I mean by this, I’ll give you a little tour of our architecture. As I mentioned before, we use the same platform that is used for gov.uk, which is effectively four Ruby on Rails apps:
Signonotron manages users, Panopticon manages page creation and metadata, Publisher manages the actual content of pages and publication, and content API serves up the content in JSON format, which is then consumed by the frontends.
This is what I mean by treating content as data. If you append .json to this page’s URL (or any other page on the site), you’ll be redirected to the content API. This isn’t just a JSON representation of the content you’re reading, we’re eating our own dogfood. If you look at the source code for both sites, you’ll see there’s no database behind either.
Because of the way the platform is structured, it’s therefore pretty trivial to serve up content to multiple frontends (this was, in fact, one of the main reasons for choosing to fork the GDS code in the first place). We set up a Rails app, templated it (using another GDS project - Slimmer), and we’re good to go.
In fact, after a few tweaks to the core Panopticon and Content API code, the DaPaaS frontend was built in the space of a day - far quicker than having to set up and template a brand new Wordpress or Drupal instance, and much more maintainable.
As our work continues at the ODI, we’ll also be building more frontends to aid our work, making the publishing platform more than a Content Management System, it’s the beating heart at the core of our organisation.