CMF published an interim report Communicating with Congress: Recommendations for Improving the Democratic Dialogue . I had one of those “someone got it right” moments reading the report. Following what seemed to be tireless work by Daniel Bennett and Rob Pierson (Rep. Mike Honda’s office) and CMF staff going back a long time, and a conference in October that I really enjoyed, they recommend adding metadata to constituent communication to reliably indicate who the sender is, what the issue is, and what advocacy organization helped the sender send the message.
The recommendation serves to help congressional staff manage incoming communication. It’s a method of triage on the one hand, and a tool to help tally communications by position on the other. Critical as this may be, I find tallying to be incredibly superficial — and it really reveals, I think, that the world of communicating with Congress has become extremely narrow. (But I’ve written on that before.)
I was very lucky this week to have stumbled into the middle of an update being done to a page maintained by the U.S.’s GSA at webcontent.gov on best practices for making data available, for executive branch agencies. The site serves as a collection of best practices and uses OMB policies
as a starting point. I think it had been last updated in 2005.
The page updated is here.
The updates were a combination of suggestions from Scott Horvath and Jeremy Fee at the USGS, Kol Peterson from EPA, and me, and really big thanks go to Scott and Kol for reaching out to others for input on Monday and getting the feedback back to Bev Godwin at GSA who runs webcontent.gov who published the changes only a few days later. Scott also notes that additional suggestions could still be considered (his email address is at the bottom of that page).
In making my suggestions, I turned to the Open Government Data Principles and tried to squeeze in as much as I could without overloading the document, and I drew from ideas that came up in the preparation of the Open House Project report. Some of the changes made were:
- It now provides examples of data as being documents, audio/visual recordings, and databases.
- It now says to support “the widest practical range of public uses of
the data”. It had formerly suggested supporting the “intended” use of
the website by visitors.
- It notes the benefit of providing data: “New uses of your agency’s
data may become a valuable public resource that would be out of the
scope of your own website, such as helping to keep the public informed
about the work of your agency and supporting civic education and
- There is a new paragraph that I might be misunderstanding but which
seems to make a suggestion along the lines of the recent “Invisible
Hand” paper about the agency’s website getting the data the same way the
public does: “Providing a uniform method to access raw data can also be
the first step in internal development, accomplishing both goals at
once. When a uniform method to access data is available, developers and
webâ€“services can focus on data presentation.”
- It notes that the availability of bulk downloads of data is something
to consider when building data access.
- It notes some disadvantages of using proprietary formats.
- It recommends that if a proprietary format is needed, a
non-proprietary format should be used in addition.
- It adds a benchmark to test for success: “One benchmark for
determining whether data is made sufficiently available is whether the
public has all of the data needed to replicate any searching, sorting,
and display functionality provided on the agency’s own website.”
- It notes that consulting the public in the development of data access
seems to be entailed from OMB policy: “When choosing data formats and
distribution methods, keep in mind that your agency’s visitors are the
best judges of their own needs. Agencies must “establish and maintain
communications with members of the public and with State and local
governments to ensure your agency creates information dissemination
products meeting their respective needs” (OMB Policies for Federal
Public Websites #4A).”
We have a real success story here.
The guys over at Princeton’s new Center for Information Technology Policy wrote a really great paper for the Yale Journal of Law & Technology on the role data should have, compared to websites, in government. It articulates a point that I think many of us subconsciously have had in mind:
“The new administration should specify that the federal governmentâ€™s primary objective as an online publisher is to provide data that is easy for others to reuse, rather than to help citizens use the data in one particular way or another.”
And they suggest an interesting way to push that forward:
“The policy route to realizing this principle is to require that federal government websites retrieve the underlying data using the same infrastructure that they have made available to the public. Such a rule incentivizes government bodies to keep this infrastructure in good working order, and ensures that private parties will have no less an opportunity to use public data than the government itself does. The rule prevents the situation, sadly typical of government websites today, in which governmental interest in presenting data in a particular fashion distracts from, and thereby impedes, the provision of data to users for their own purposes.”
I think this is a worthwhile addition to the opengovdata and publicmarkup.org policy documents — if not as a direct recommendation (because I think it may be too much to ask for in a grand form) then noted as a long-term goal or (in terms of the second paragraph I quoted) as a benchmark, a concrete way to tell whether data is open.
The full citation is: Robinson, David, Yu, Harlan, Zeller, William P and Felten, Edward W, “Government Data and the Invisible Hand” (2008). Yale Journal of Law & Technology, Vol. 11, 2008