OUseful.Info, the blog…

Reading the Sunday papers over the last couple of weekends, and the ongoing saga of how much debt the UK is in, I’ve kept asking myself the question “who is the UK government actually in debt to?”

The answer in the simplest form is (I think) the holders of “gilts”, interest bearing bonds sold by the government to whoever’s willing to buy them, such as pension funds or sovereign funds.

But then the quuestion arises: who owns these bonds, and how much are these bond owners in hock to other bond holders and, in the case of sovereign funds, other countries. That is, could we in principle do a great debt cancelling exercise based on doing the sums around: A owes B x and C y; C owes A p and C q; and C owes A l and B m, to see who actually owes whom what if all the debts were settled. (This omits things like different repayment rates, the extent to which countries holding each other’s debt plays a role in mediating exchange rates, and so on.)

I haven’t got very far with this, but I have found a few starting points (I think) as who owes whom in the most general of terms, so I thought I’d just link to them here in case for the sake of convenience and rediscoverability.

My starting point: a BBC report on Who owns the UK’s debt?

From there, I ended up finding loosely related data at:
National Statistics – UK Accounts
UK Debt Management Office Quarterly Review
Bank for International Settlements

Hopefully next weekend I’ll actually get round to building something… (then again, if it’s kite flying weather, maybe not…;-)

With a new doc out on WriteToReply published by DCMS, I’ve started getting fired up again by the sorts of things that I think the platform is capable of, so over the next couple of weeks I hope to post a few ideas, and will then start looking for ways of trying to get the ones that seem workable and useful actually implemented (and ideally, funded).

So for example, one of the things I’ve been playing with are what we might refer to as “single page consultations” (micro-consultations?). Here are a couple of examples:

• CHANGE IS OVERDUE – a public charter for libraries – an unofficial republication of a 12 point plan originally published by The Library Campagin (I think?!); see also MLA: Library Users’ Charter;
• Draft Public Data Principles, as originally posted on the data.gov.uk blog and as made available for comment and discussion on the data.gov.uk wiki, albeit in both cases without independent/unique URLs for each point (which makes offboard/remote commenting harder to track and reference.

Here’s another example:

- Lessons Learned from Publishing Local Election Data

Note that this isn’t a consultation, as such, more it’s a set of observations (lessons) that might benefit from discussion, or that independently (at paragraph level) might act as a useful focus of, or foil for, further discussion.

So – my observation, based on the examples above, is that there may be some mileage in exploring a WriteToReply-like way of publishing short, single page documents that would benefit from being able to offer:

- unique paragraph level URLs (atomisation);
- commenting at the paragraph level (commentability), with the ability to track comments associated with a particular paragraph.

Of course, it’s easy enough to add unique URLs within any document yourself using the the name attribute within and HTML <a>/anchor element.

So for example, <a name=”here”>here</a> can be linked to by appending #here to end of the current page URL.

However, the approach I’m thinking of would be more automated than that. For example, a WordPress theme (style sheet) or plugin extension that would:

- allow the user to place a chunk of text to be atomised and made commentable in a particular HTML block element (such as a blockquote, or a div with a particular class attribute) and then do the digress.it thing to the content in that block element; this could presumably be achieved by tweaking digress.it to only run over a limited set of block elements; for page load efficiency, any necessary client-side code would only be loaded if an appropriate block element was present in the page; or

- allow the user to place a chunk of text to be atomised and made commentable within a WordPress shortcode block (e.g. using the WordPress shortcode API, and then let the shortcode API mark up and include any necessary client side code within the block; or

- allow the user to create a custom blog post type that applies the digress.it theme to that post.

To make the single commentable pages work in within the context of a blog with non-commentable posts and an arbitrary visual theme, the commenting mechanic for “embedded” or “inline” atomisable and commentable areas may need to change from the floating comment panel used as a default by digress.it for an inline theme (see for example Inline Comments on WriteToReply? or this example of “sub-text annotations”: New Buzzwords: Geo-Aware eBooks and Sub-text Annotations).

I’m not sure whether any of the above strategies would work, but the sort of capability I’m after is some sort of WordPress plugin that would let me run an everyday blog, but then for certain posts, or a subset of the content of certain posts, have it atomised and made commentable. So for example, I could include a list of recommendations, or questions, or references, within a blog post, and automatically let the theme give just those elements unique URLs and make them separately commentable.

PS following a tweet from @girlinthe regarding the availability of a comments feed from a particular page, I added a simple sidebar link to just such a thing.

It’s configured simply by adding a link to: feed, which is a link relative to the current page URL. That is:

When the link is displayed, the current page URL is prepended, so the link actually points to http://example.com/thisBlog/thisPage/feed

Remember, you can also get a variety of other feeds out from the page too.

For example, the full text of the page can be grabbed as a single item RSS feed from the URL:

- http://example.com/thisBlog/thisPage/?feed=atom&withoutcomments=1

An RSS feed of the page containing each paragraph as a separate feed item can be obtained using the construction:

- http://example.com/thisBlog/feed/paragraphlevel/thisPage/

Don’t you just love WordPress, and the digress.it theme?!;-)

One of the strategies I use for reading long documents that I want to comment on take detailed notes from is to read through the document quickly, marking or highlighting the parts I think are important (or quotable), and then doing another pass where I dwell on the parts I marked.

With the publication via WriteToReply of a comment soliciting speech from Ed Vaizey on public libraries yesterday (Remodelling Libraries, [press release]), I started thinking again how we might support a highlighting approach in WriteToReply. In a post earlier this year (Skim.it – Like Digress.it, But With Ratings Rather than Comments?), I briefly considered how we might publish documents in a paragraph atomising way (as we do using the digress.it WordPress theme) and then allow readers to add ratings (rather than comments) to the document at a paragraph level. Something like this, maybe:

Another factor that I think needs to be taken into account is the ability to read documents on mobile devices. A variety of mobile themes are available for WordPress, from the “run anywhere WordPress mobile edition to the iPhone/Android loving WPTouch.

So what I’ve started thinking is that maybe iskim.it should be a mobile theme to complement a desktop browser theme along the lines of digress.it and the mooted skim.it, that would allow users to “favourite” or “star” paragraphs they think are important so they can return to them later, maybe on a desktop or portable computer, rather than a mobile device (hmm… desktop, portable, mobile…). For exampe, the iskim.it should:

0) work on mobile devices;
1) atomise docs into paragraphs;
2) allow a user to “favorite” a paragraph;
3) allow a user to review a list of the paragraph they have favourited;
4) allow a user to optionally comment on the paragraphs they have favourited;
5) allow a user to look at the paragraphs favourited by another user;
6) allow a user to look at a list of the most favourited paragraphs across all users.

(Note that similar functionality (1+) should also be made available on the parent website via a parent skim.it theme.)

The aim of doing this is to identify quickly, and without the need to comment, those paragraphs that are deemed “important”. (I did wonder whether the “favouriting” should offer two options – “important”, and “needs challenging”?)

Unlike the 5 star ranking scheme sketched in the image above, we’d only need a single star:

It might also be worth considering indicating how many other people had favourited a paragraph? For example:

In the above example, the star/count appears at the end of the paragraph, because you ant to signal the importance of the paragraph after you have read it…

ALternatively, we might try to signal the perceived importance of the paragraph at the start of the paragraph, and then allow to the reader to make their own signal after reading it:

The aim of the skim.it idea is to provide a way for readers to flag those sections of a document that are worthy or requiring of comment, and thus be capable of acting as a precursor to commenting on those sections. For mobile users, where time may be tight, the keyboard interface fiddly or difficult to use, the simple interaction – click to star – means that users can read a document and bookmark those parts of it that are important to them.

The ability to view the document via a filter of “most heavily favourited” provides a crowd sourced alternative to an executive summary of the document.

PS I am using the star as a way of signaling the importance of particular paragraphs. It’s not hard to extend this idea to social signaling, where for example a user clicks to tweet the link to that particular paragraph, or clicks to share the link to that paragraph on a social bookmarking service such as delicious.

It’s all very academics in favour of openness ranting about the walled garden approaches of Facebook and Apple, and the paywall perimeters put up by embattled media organisations such as News International, but how do our own institutional systems fare on the openness and data portability front?

A recent initiative to encourage sites to publish a data portability policy has made available this handy Portability Policy Generator which covers issues such as:
- Identity and Authentication: e.g. do people need to create a new identity for the local site, or can they use an existing one?
- Working with Things Stored Somewhere Else: e.g. Must people import things into this product, or can the product refer to things stored someplace else?
- Watching For Updates: e.g. Can this site watch for updates that people make on other sites?
- Broadcasting Changes Made Here: e.g. If person updates something here, is that change stored only locally or can it notify another product?
- Access from Other Products: e.g. Can the person allow other sites to use the things they’ve created or updated?
- Backing Up: e.g. Can the person download or remotely access a copy of everything they’ve provided to the service?
- Public Data: e.g. Can the person download or remotely access information that others have provided to the product?
- Closing an Account: e.g. Will the site delete an account and all associated data upon a user’s request?
- Where things are: e.g. Do you disclose where personal data is being kept in the real world?

A quick look at the OU’s policies page links to the computing code of conduct, FOI and data protection policies for example, but not a data portability policy… (I’d be surprised in any UK HEIs have one yet?)

So with HEIs increasingly encouraging students to make use of university provided e-portfolios and contribute to online forums, and researchers to contribute personal information to researcher profiles and media directories, as well as depositing their papers into institutional repositories, is it time they started at least publishing a data portability policy, and maybe looking at ways of supporting data liberation?

See also: Time for data.ac.uk? Or a local data.open.ac.uk?

Looking over the UK Gov Transparency Board’s draft Public Data Principles, one of the suggested principles (#) proposes that:

Public data underlying the Government’s own websites will be published in reusable form for others to use – anything published on Government websites should be available as data for others to reuse. Public bodies should not require people to come to their websites to obtain information.

One example of how this might work is to look at the Direct Gov Syndication API, but there are maybe some simpler alternatives…? Like RSS…

So for example, over on Mash the State, Adrian Short had a go at hassling local councils into publishing RSS feeds by the end of 2009, although not many of them took up the challenge at the time… (maybe the new principles will nudge them towards doing this?) Here, for example, are some obvious starting points:
- council news (here’s an example council news feed from Shropshire Council);
- recent planning applications (here’s an example Planning RSS feed from Lichfield District Council);
- current roadworks (here’s an example traffic/roadworks feed from Glasgow City Council);
- council jobs (here’s an example council advertised jobs feed from Sutton Council);
- current consultations (here’s an example open consultations feed from Bristol City Council).

In accord with another of the draft Public Data principles (#),

Public data will be timely and fine grained – Data will be released as quickly as possible after its collection and in as fine a detail as is possible. Speed may mean that the first release may have inaccuracies; more accurate versions will be released when available.
Release data quickly, and then re-publish it in linked data form – Linked data standards allow the most powerful and easiest re-use of data. However most existing internal public sector data is not in linked data form. Rather than delay any release of the data, our recommendation is to release it ‘as is’ as soon as possible, and then work to convert it to a better format.

even if the published feeds could be better (e.g. planning feeds might benefit from geo-data that allow planning notices to be displayed at an appropriate location on a map), there’s no reason not to start opening up this “data” now in a way that supports syndication.

At a government departmental level, one of the things I’ve been interested in tracking previously has been government consultation announcements. It’s possible to search for these, and generate email alerts and RSS subscriptions, via Tell Them What You Think. A list of government department consultation websites can also be found on Direct Gov: list of Government consultation websites. (To make that list a little more portable, I popped it onto my doodlings area of WriteToReply; WTR: Government consultation websites; and courtesy of the magic of the digress.it theme we run there, it’s easy enough to get an RSS feed out with each department listed as a separate item (although rather than resolving to the consultation web page URLs, the feed links point back to the corresponding paragraph on Doodlings): some sort of feed of Government consultation websites.)

If each of those consultation websites published an autodiscoverable RSS feed containing the currently open consultations (and maybe even made that data available as a calendar feed as well, with consultation opening and closing dates specified), it would be simple for aggregating services like Tell Them What You Think, or announcement services like a Direct Gov “New Consultations” feature, to consume and re-present this information in an alternative context.

(Note that consultation websites should also be making consultation information available on consultation web pages in a machine readable way using RDFa. E.g. see @lesteph’s Adding RDFa to a consultation.)

Any changes to website design – changes that break the screenscraping routines used by many services like Tell Them What You Think – would be able to continue operating as long as the RSS feed URLs remained unchanged. (Of course, it might be that aggregating services parse the content of RSS feeds in particular ways to extract structured information from them, essentially scraping the feed contents, so in those cases, if the way feed content was presented were to change, the services would still break…)

Anyway, to return to the draft Public Data Principle I opened this post with, RSS (and related protocols such as Atom) can go a long way towards helping achieve the aim that “[p]ublic bodies should not require people to come to their websites to obtain information”.