By Rick Jelliffe
August 16, 2010 | Comments: 2

From the Cornell Law School's blog, Head of e-Services and Strategy at The (UK) National Archives, John Sheridan has written on the launch of and mentioned this blog!

A major influence on was a blog posting by Rick Jeliffe for O'Reilly's Jeliffe writes about something he calls PRESTO. He describes this as a system for legislation and public information in which "all documents, views and metadata at all significant levels of granularity and composition should be available in the best formats practical from their own permanent hierarchical URIs."


Of course, we quickly discovered, it is one thing to suggest a design approach like PRESTO, and quite another to actually implement it. Jeni Tennison, who, working as a consultant to The Stationery Office, devised the URI Set for legislation (and much else about the system), has blogged about the limitations of PRESTO and XPath-based URLs. I hope Jeni will find the time to blog some more about, as there are many stories to be told.

One of the earliest pieces of design work we did for was the URI Set. We wanted to follow PRESTO principles, but also account for changes over time, and for some of the peculiarities of UK legislation, in particular different geographic extents. (See, e.g., here.) PRESTO thinking is very evident on; just look at the URLs as you move through the site.

Examples of PRESTO-ish behaviour are

The simplest way to get hold of the underlying data on is to go to a piece of legislation on the Website, either a whole item, or a part or section, and just append /data.xml or /data.rdf to the URL. So, the data for, say, Section 1 of the Communications Act 2003, which is at, is available at We have taken a similar approach with lists, both in browse and search results. When looking at any list of legislation on, it is easy to view the data. Simply append /data.feed to return that list in ATOM.

I have used PRESTO on a few projects now, never in a particularly doctrinaire fashion, and it always seems to have had good benefits: it just packages up some good ideas (such as TBL's Cool URLs don't change) in a different way. More importantly, it starts with an objective (all information, all significant granularity, any available formats) that can become a business requirement, rather than merely elaborating a technology (e.g. "Linked data").

I'd love to read more of what Jeni has done with it.

(Hat tip Dave Pawson)

You might also be interested in:


I would add (I'm sure I missed it in documentation) that if the content-type of the request is a specific type, then that representation should be delivered for whatever the default information is for the url. Supporting HEAD with a detailed Accept: header could disclose maybe all the representations available and make discovery easier, even customizing the behavior of browsers.

Hank: Yes, good point.

Sometimes you want to ask "what representations do you have?", sometimes you want to leave the choice to your application, and sometimes you want to ask "give me this particular representation." They should not/need not be in conflict: so providing content negotiation header information on the URL for a resource does not mean we cannot also have a TOC resource (with its own URL) that lists the different representations, and vice versa.

News Topics

Recommended for You

Got a Question?