Dennis D. McDonald (ddmcd@ddmcd.com) consults from Alexandria Virginia. His services include writing & research, proposal development, and project management.

When Are "Open Data" and "Hiding in Plain Sight" Synonymous?

By Dennis D. McDonald

Click or tap the above image to download a .pdf of this article.Alex Howard’s Beware openwashing. Question secrecy. Acknowledge ideology. is a welcome discussion of what “open” can mean when it comes to government services. Terms like “transparency,” “open data,” and “open government” tend to get thrown around a lot without critical discussions of their meanings. Howard discusses how “open” inevitably becomes intertwined with philosophy and politics.

This reminds me a bit of years ago when the term “web 2.0” was popular as a buzzword. It could mean just about anything you wanted it to mean; I even tried to define it for a National Academy of Engineering project before backing off the term.

Terms like “open data” and “open government” have a similar feel because of wide definition variety. For example, “data dumping” — making tons of discrete datasets readily accessible and available for easy downloading and manipulation — can have both good and bad connotations. It’s one thing to make geocoded transaction-based datasets about government operations and activities available for all to see. It’s quite another to make the data meaningful.

You have to ask yourself — and this is the type of question that Howard is getting at — to what lengths should the government go in making the data accessible, understandable, and usable to the public? Should that be the responsibility of citizens acting independently? Or should an independent third party — preferably one with no axe to grind  — be trusted with interpreting the data on behalf of various constituencies?

These are questions related, in my opinion, to how accessible data actually are for potential end users. I tried to get into some of these issues surrounding what “accessibility” might mean, not entirely successfully, in my post Matching Technological Literacy with Delivery of Government Services. Building from that, here is how I responded to Howard’s post when he linked to it on Google+’s Open Government community:


I think a major distinguishing point in planning for “open data” is whether or not the systems and processes surrounding how the data are managed are — or aren’t — independent of the program that is associated with the creation of the data.

It takes resources — time and money — to create and manage access to data. If those resources aren’t directly associated with the program that is generating and consuming the data, how can we be sure the data will be used in a way that is responsive to the goals of the program?

I’m not saying that making files of data available via APIs or access systems are not potentially valuable, they obviously have potential, and the “open data” movement has made much of the potential utility of data generated by government programs when made available for creative or innovative uses.

Admittedly I’m interpreting this from the perspective of an information system developer. First and foremost when I’m designing a system to support a program or operation I want to make sure the data resources that are associated with that system are directly relevant and beneficial to that system and its users and managers. That doesn’t mean that I will be able to capture all the “value” that can be generated by the program’s data resources, but it does mean that I can’t just assume that making data available for access by third party APIs will automatically benefit my own constituents.

This is why I don’t believe that making data accessible is necessarily intrinsically useful or valuable. Doing so may be responsive to an ethical or legal requirement that government operations be “transparent,” but I still feel that the program that generates the data in the first place needs to be thinking about how making the data more accessible actually supports its own program goals and objectives.

If that means working closely with third party API developers, standards bodies, and republishers, so be it. But the cost of doing so should be taken into account when developing the program’s budget.

I address some of these concepts in more detail in “A Framework for Transparency Program Planning and Assessment” located here: /outline.html .

Back to the title of this post, When Are “Open Data” and “Hiding in Plain Sight” Synonymous?

By “hiding in plain site” I mean that an aura of accessibility can surround government program data — if it can be located, downloaded, manipulated, and used. But used by whom? And for what purpose? And importantly, what are the data-generating government program’s responsibilities in this regard?

One concern is that quality and usability might suffer if data are made accessible without the appropriate tools and contextual information needed by potential users. As I discussed in Developing Digital Strategies for Web-based Public Access to Government Performance Data, the Performance.gov website operated by OMB doesn’t just provide data describing the operation of government programs, it also provides specially selected data describing program performance along with the contextual information that enables the user to select and interpret the provided data. When sustained, this type of operation takes time, money, and talent, as well as the full cooperation of the government agency that supports the provision of Performance.gov’s quarterly reporting.

Ideally, the within-agency and across-agency performance reporting provided by operations such as Performance.gov will eventually enable members of the public and their representatives to understand how well tax dollars are being spent. At issue is whether the public will have the tools, skills, wherewithal, and resources to locate, understand, and make use of the data. If not, the division between the “data haves” and “data have nots” will be exacerbated, no matter how many data files are offered for download.

If you found the above interesting, these related articles might interest you as well:

Copyright (c) 2013 by Dennis D. McDonald, Ph.D. Dennis is a Washington DC area consultant specializing in digital strategy, collaborative project management, and new technology adoption. His clients have included the US Department of Veterans Affairs, the US Environmental Protection Agency, Jive Software, the National Library of Medicine, the National Academy of Engineering, Social Media Today and Oracle, and the World Bank Group. His experience includes the management of projects involving the conversion or migration of financial and transaction data associated with large and small systems. Contact Dennis via email at ddmcd@yahoo.com or by phone at 703-402-7382.

Keep Your Eyeballs to Yourself, Chathead

Comcast Must Die

Comcast Must Die