Complying with Open Gov: The November Deadlines - Part 2
by barrett.smith barrett.smith
(Part 3 of the "Open Gov" blog series)
In the previous post in this series, we talked about the activities necessary to fulfill the minimum requirements for the first two implementation steps due in November. At the time I wrote that post, the plan for this post was to discuss the last two implementation step for the November deadline. In the interim, though, there have been some changes.
First, and most importantly, the deadline is November 1, 2013, not November 5 as I had previously stated.
Second, the much awaited Cross-Agency Priority Goal has been released. Unfortunately, there’s no real meat to the CAP Goal in terms of what specifically must be done and on what timelines. The Implementation Guide page on Project Open Data has been updated with more detail as to what is required, particularly in November.
Some of those details, though, are completely new requirements. So, let me highlight what changed about the items we already covered in my previous posts.
To start with, in the requirement to “Create and maintain an enterprise data inventory,” which we discussed in the last post, there are several new components. An Inventory Schedule must first be developed, then submitted to OMB in JSON format via MAX Community, and published on your agency’s digital strategy page. The Inventory Schedule on the digital strategy page must be updated quarterly following the November 1 deadline.
Second, a new implementation step has been been added to the previous list of four steps. The five implementation steps due in November are:
1. Create and maintain an enterprise data inventory,
2. Create and maintain a public data catalog,
3. Engage with customers to help facilitate and prioritize data release,
4. Document if data cannot be released, and
5. Clarify roles and responsibilities.
We covered steps 1 and 2 previously, so on to step 3...
Step 3, Create a Process to Engage with Customers to Help Facilitate and Prioritize Data Release requires that all agencies must create a process for accepting and responding to feedback from both public and governmental consumers of their data in order to fulfill the November requirements of the “Engage with customers” implementation step. Each agency must describe the process on their digital strategy page, and provide access to that feedback mechanism either directly through data or link to it from data.
The details of the feedback process are left to the discretion of each agency, but stated goals are for the consuming public to be involved in the prioritization of dataset release and determination of the formats in which those data will be released. At a minimum then, the process should logically support feedback pertaining to those two areas.
Step 4. The new implementation step is Document if Data Cannot be Released. This requirement had been alluded to previously, but no due dates and specifics had been attached to it. Now, by November 1, agencies must develop a process for determining if a reason why a dataset cannot be released exists and publish an overview of that process on their digital strategy page. This process must categorize each dataset with one of three accessLevel values: Public, Restricted Public, and Nonpublic. If the accessLevel value is not Public, the accessLevelComment field must contain a description of how access may be attained, or why the data cannot be made public.
What stands out about this step is that, according to the Common Core Metadata schema, the values for accessLevel are Public, Restricted, and Private. Yes, it’s a minor difference, but it’s troubling that the schema is not being strictly followed. There’s also the question of the accessLevelComment field, which doesn’t appear in the CCM schema at all. My hope is that these issues will be clarified in future releases from the Administration.
Step 5. Clarify roles and responsibilities requires that a point of contact (POC) be identified for many of the sub-requirements this implementation requirement. The identification of POCs is solely left up to the agency. One agency might have a POC whose entire job is to handle these requests, or they may have a separate POC or team of POCs to deal with each individual sub-requirement.
POCs need to be identified for each of the following sub-requirements:
-Communicating the strategic value of open data to internal stakeholders and the public.
-Ensuring that data released to the public are open, as appropriate, and that there is a POC designated to assist open data use and to respond to complaints about adherence to open data requirements.
-Engaging entrepreneurs and innovators in the private and nonprofit sectors to encourage and facilitate the use of agency data to build applications and services.
-Working with agency components to scale best practices from bureaus and offices that excel in open data practices across the enterprise.
-Working with the agency’s Senior Agency Official for Privacy (SAOP) or other relevant officials to ensure that privacy and confidentiality are fully protected.
-Working with the Chief Information Security Officer (CISO) and mission owners to assess overall organizational risk, based on the impact of releasing potentially sensitive data, and make a risk-based determination.
To sum up, there’s a lot to do in the next few months. Some of which should already have been done based on other memoranda, but if your agency hasn’t started yet it’s going to be a busy time for you. Assuming no further major changes in the requirements, in the next post we’ll start looking at the tools available for fulfilling the requirements with a Drupal environment.