Merge pull request #62 from DruidSmith/master

Suggestions for Implementation Guide

Author: haleyvandyck

Diff for: api-sandbox.md

@@ -5,7 +5,7 @@ permalink: /api-sandbox/
 filename: api-sandbox.md
 ---
 
-By providing rich and interactive documentation, API producers strongly enhance functionality and ease-of-use for potential developers. This speeds early adoption and rewards users with a more fluid experience.Greater adoption then results in a higher return on investment, a more vibrant developer community and greater momentum for the API program.
+By providing rich and interactive documentation which also includes the ability for developers to explore and execute live calls against the API, use of API sandboxes can allow API producers to strongly enhance functionality and ease-of-use for potential developers. This speeds early adoption and rewards users with a more fluid experience. Greater adoption then results in a higher return on investment, a more vibrant developer community and greater momentum for the API program.
 
 Two free, open source options include:
 

Diff for: implementation-guide.md

@@ -55,6 +55,8 @@ While you could manually create this file in a text editor, it is recommended th
 * Consider including restricted and non-public datasets in your public data inventory listing. Remember that this file contains metadata about the data and not the data themselves.
 * When you include restricted datasets in your public data inventory, include specific information on how customers can request and qualify for access to those data.
 * Integrate your public data inventory with a tool for soliciting feedback from customers to avoid duplicative effort. For example, the [Kickstart WordPress plugin](https://github.com/project-open-data/kickstart) can automatically generate a voting and commenting mechanism from your data.json file.
+* Data consumers should not need to know an Agency's org chart in order to find data.  While it is helpful to include metadata about which part of the organization is providing the data, consider that secondary users will likely be searching for data using topical and thematic keywords as opposed to agency structure.
+* In describing data, avoid use of agency acronyms wherever possible.
 
 ### D) Resources
 
@@ -79,8 +81,9 @@ Create a process to solicit feedback from customers about existing and potential
 
 * The required set of [common core metadata](http://project-open-data.github.io/schema/) includes fields for a contact name (“person”) and an email address (“mbox”). Listing specific, accurate information in these fields for each dataset ensures that customers can give direct feedback on a dataset to the person who is most likely to be able to act on that feedback.
 * If you enable customers to leave comments on datasets, ensure someone at your agency monitors these comments and responds in a timely manner. When new visitors see outdated, unanswered comments, they are less likely to provide feedback.
+* Consider a feedback mechanism and structure whereby data quality issues identified by data consumers can be submitted and vetted and integrated back into source data systems.
+* Consider use cases for how data is likely to be accessed by API, whether by specific queries and subsets, or by entire tables, and consider building API infrastructure that is optimized to meet those needs.
 
-  
 ## 4) Clarify Roles and Responsibilities
 *\[Due by 11/9/13\]*
 
@@ -151,6 +154,7 @@ Collect or create information (data) in a way that supports downstream informati
 * Make sure your machine-readable data is also human-readable. This may mean providing two separate files, but more likely means including a human-readable key and a detailed description.
 * It is much easier to collect data in the way you will eventually distribute and publish it, rather than having to manipulate the data midway through to comply with later requirements.
 
+
 ### D) Resources
 * [Open Government Directive](http://www.whitehouse.gov/sites/default/files/omb/assets/memoranda_2010/m10-06.pdf)
 * [NIST FIPS Publication 199](http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf)
@@ -191,7 +195,11 @@ New, or significantly modified, information systems need to support interoperabi
 
 ### B) Best Practices and Examples
 
-* Brainstorm both the known and potential future uses of the data when designing an information system.
+* Consider downstream and secondary uses of the data as referenced in [M-13-13 — Memorandum for the Heads of Executive Departments and Agencies](http://project-open-data.github.io/policy-memo/) and brainstorm both the known and potential future uses of the data when designing an information system.
+* Consider the use of applicable data standards and codesets that exist for common data elements, such as ANSI/INCITS, ISO and others.
+* Consider implementing a front-end automated data QA system that can provide lookup services and/or validate many core data elements a.) on data entry, for example by API call which prepopulates picklists and autocomplete values to simplify and streamline data entry while also ensuring consistent entry of data.  Another example would be use of a geocoding service to validate street addresses and provide lat/long values and map previews for visual feedback of entered information.
+* Consider implementing a back-end data QA framework that can automate many data QA functions, along with providing a data stewardship tool
+* Consider developing a robust data stewardship community and governance structure for curating and maintaining high-quality data.
 * The more open and flexible a system is now, the less likely it is that it will need to be replaced or significantly modified in the future. Your agency should weigh upfront system design costs with the long-term potential cost savings and benefits.
 
 ### C) Resources

Diff for: standards.md

@@ -15,4 +15,21 @@ Consistent with existing agency responsibilities under [OMB Circular A-119] (htt
 
 For the purposes of implementing of the OMB Memorandum titled “Managing Information as an Asset,” agencies must follow OMB Circular A-119 in the development, maintenance, and use of standards and specifications that are developed through an open, collaborative, and transparent process. Standards and specifications developed in processes with the attributes identified above enable data, products, and services to be used by anyone, at any time, and spur innovation and growth. Agencies should prioritize the use of open data formats that are non-proprietary, publicly available, and place no restrictions upon its use. Use of standards, specifications and formats can provide significant benefits to agencies and stakeholders while helping to implement open data priorities. 
 
+### Best Practices for Data Standards
+
+System owners and data owners should, wherever possible, consider relevant international and US standards for data elements.  Standards bodies dealing with data include:
+
+#### International Standards
+[ISO](http://www.iso.org/iso/catalogue_ics) 
+[United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT)](http://www.unece.org/cefact/about.html)
+
+#### US National Standards
+[American National Standards Institute (ANSI)](http://www.ansi.org/)
+[International Committee for Information Technology Standards (INCITS)](http://incits.org/)
+
+#### US Federal Government Standards
+[The Federal Geographic Data Committee (FGDC)](http://www.fgdc.gov/standards)
+[The National Information Exchange Model (NIEM)](https://www.niem.gov/Pages/default.aspx)
+
+
 This section of Project Open Data will be updated as guidance evolves.