Rename "Common Core" to "Project Open Data"

As described in #379

The term was in place in the policy memo and documents specific to the
v1.0 schema

Author: philipashlock

Diff for: catalog.md

@@ -10,7 +10,7 @@ This section provides further guidance and explanation for implementing the agen
 /Data Requirements
 ------------------
 
-The Open Data Policy requires agencies to list and describe all agency data that *can* be made publicly available (i.e. there are no valid restrictions to release) in a publicly available open data catalog with [common core metadata](/schema/).  It further requires the catalog to be human-readable and machine-readable.  This guidance describes to agencies steps for implementing this portion of the policy. 
+The Open Data Policy requires agencies to list and describe all agency data that *can* be made publicly available (i.e. there are no valid restrictions to release) in a publicly available open data catalog using the [Project Open Data metadata schema](/schema/).  It further requires the catalog to be human-readable and machine-readable.  This guidance describes to agencies steps for implementing this portion of the policy. 
 
 Why this effort
 ---------------
@@ -31,7 +31,7 @@ All information deemed "machine-readable" required in this policy must be descri
 Implementing
 ------------
 
-To fulfill the requirements of this memorandum, agencies should begin to describe datasets as a catalog using the vocabulary of the [common core metadata](/schema/). This catalog is to be published as a standalone JSON file at `agency.gov/data.json`.  Agencies may optionally also publish it with RDFa Lite, either embedded within a HTML page which include human readable markups (e.g., `agency.gov/data.html`) or as an XML file (e.g., `agency.gov/data.xml`). 
+To fulfill the requirements of this memorandum, agencies should begin to describe datasets as a catalog using the vocabulary of the [Project Open Data metadata schema](/schema/). This catalog is to be published as a standalone JSON file at `agency.gov/data.json`.  Agencies may optionally also publish it with RDFa Lite, either embedded within a HTML page which include human readable markups (e.g., `agency.gov/data.html`) or as an XML file (e.g., `agency.gov/data.xml`). 
 
 ### JSON
 
@@ -59,7 +59,7 @@ Agencies must follow the provided [specification](/schema/).  We have built a [c
 Inclusion of the Public Data Listing as a Record
 ------------------------------------------------
 
-Each 'data.json' catalog file should include a record for the data asset that is the data catalog itself.  Contact Name and Contact Email can be used to provide a PoC for the 'data.json' efforts;  Data Standard (_conformsTo_) can be used to clarify which version of the common core metadata schema the agency is currently using; and Last Update can be used to indicate the date when the Public Data Listing was last modified.  
+Each 'data.json' catalog file should include a record for the data asset that is the data catalog itself.  Contact Name and Contact Email can be used to provide a PoC for the 'data.json' efforts;  Data Standard (_conformsTo_) can be used to clarify which version of the Project Open Data metadata schema the agency is currently using; and Last Update can be used to indicate the date when the Public Data Listing was last modified.  
 
 Presentation
 ------------
@@ -75,7 +75,7 @@ The page must be populated from the machine-readable catalog file (e.g. data.xml
 Version 1.1 Update 
 ------------------
 
-In the year since the release of the Open Data Policy, agencies and the public have suggested several updates to the metadata schema.  In the interest of stability, these updates have been tied together into a methodical update to a version 1.1 of the common core schema.  Each issue has been rigorously discussed in its own issue thread and at the [July government-wide offsite session](https://github.com/project-open-data/project-open-data.github.io/issues/325) dedicated to this update.  
+In the year since the release of the Open Data Policy, agencies and the public have suggested several updates to the metadata schema.  In the interest of stability, these updates have been tied together into a methodical update to a version 1.1 of the metadata schema.  Each issue has been rigorously discussed in its own issue thread and at the [July government-wide offsite session](https://github.com/project-open-data/project-open-data.github.io/issues/325) dedicated to this update.  
 
 * [Changelog for the version 1.1 schema](http://project-open-data.civicagency.org/metadata-changelog/).
 * [Preview of the new updated metadata schema page](http://project-open-data.civicagency.org/v1.1/schema/).  

Diff for: faq.md

@@ -95,21 +95,21 @@ While ISO 32000 is an open standard, the Portable Document Format (PDF) does not
 
 ### What is the relationship of the metadata standard (specifically) to NIEM, ISE, FGDC, and other existing (especially official) government data standards?
 
-The [common core metadata schema](/schema/) is based on existing vocabularies and easily mapped to NIEM, Information Sharing Environment, and FGDC.
+The [Project Open Data metadata schema](/schema/) is based on existing vocabularies and easily mapped to NIEM, Information Sharing Environment, and FGDC.
 
 ### What is a "persistent identifier"?
 
 A persistent identifier is a unique label assigned to digital objects or data files that is managed and kept up to date over a defined time period (e.g., Unique Investment Identifiers).
 
-### Who established the common core metadata schema?
+### Who established the Project Open Data metadata schema?
 
 The core metadata schema was the result of recommendations from a government-wide Metadata Working Group at Data.gov combined with research of existing public schemas for data catalogs.  Most of the elements trace their roots to the Dublin Core Library.
 
 ### How can I recommend changes and improvements to the metadata schema?
 
 Submit a pull request for the [metadata schema](/schema/). 
 
-### Can I extend the metadata schema beyond the terms specified in the [common core metadata schema](/schema/)?
+### Can I extend the metadata schema beyond the terms specified in the [Project Open Data metadata schema](/schema/)?
 
 Yes, if your data management process includes rich metadata specific to the mission of your agency or the Line of Business in which your agency participates, publishing additional metadata that makes your data more useful to the public is welcomed and encouraged.  Note that Data.gov will be harvesting only the metadata in this published schema unless specific arrangements are in place (e.g. geospatial FGDC/ISO).
 
@@ -160,7 +160,7 @@ A wide variety of tools are available to manage a data catalog, whether public-f
 
 ### What formats are required/optional for the agency.gov/data file?
 
-JSON is required though there are several optional syntaxes that can also be used when publishing the data file. The syntax that is required to make the data readily available to developers is JSON (JavaScript Object Notation). Agencies should also create a data.html file for the human-browsable data homepage and may use RDFa Lite (Resource Description Framework) to mark-up each dataset's metadata using the [common core metadata schema](/schema/). Agencies may also choose to populate a metadata file using XML (eXtensible Markup Language). These alternate metadata files are optional but agencies must maintain the JSON version at agency.gov/data.json. [Tools](http://labs.data.gov) are available to transform any instance of the file into the alternative formats.
+JSON is required though there are several optional syntaxes that can also be used when publishing the data file. The syntax that is required to make the data readily available to developers is JSON (JavaScript Object Notation). Agencies should also create a data.html file for the human-browsable data homepage and may use RDFa Lite (Resource Description Framework) to mark-up each dataset's metadata using the [Project Open Data metadata schema](/schema/). Agencies may also choose to populate a metadata file using XML (eXtensible Markup Language). These alternate metadata files are optional but agencies must maintain the JSON version at agency.gov/data.json. [Tools](http://labs.data.gov) are available to transform any instance of the file into the alternative formats.
 
 ## Agency participation with Open Data
 

Diff for: governance.md

@@ -35,5 +35,5 @@ Given that the breadth of Project Open Data supports both technical and policy w
 
 There are two policies repos that will have very regulated release cycles:
 
-* _Common Core Metadata Schema_— Changes to the common core metadata schema will be reviewed on an ongoing basis. Starting November 9th, new releases of the schema will only be issued every 6 months, as needed. Suggested changes that alter implementation and structure of the schema will not be merged in-between the regular release cycles, though discussion and commenting during these periods are encouraged. Each version of the schema will have a depreciation date of one year.   
+* _Project Open Data Metadata Schema_— Changes to the Project Open Data metadata schema will be reviewed on an ongoing basis. Starting November 9th, new releases of the schema will only be issued every 6 months, as needed. Suggested changes that alter implementation and structure of the schema will not be merged in-between the regular release cycles, though discussion and commenting during these periods are encouraged. Each version of the schema will have a depreciation date of one year.   
 * _The Open Data Policy M-13-13_— A version of The Open Data Policy (M-13-13) is available for public feedback and suggested changes through Project Open Data. Suggested changes to the policy will be reviewed bi-annually.  Adjudication times will depend on the extent of the suggested policy changes and decisions regarding the mechanism for dissemination (e.g., the need to consider updating official version of M-13-13, or other forms of guidance). Accepted changes to the policy will not be merged in-between the regular release cycles to prevent inconsistencies and confusion, though discussion and commenting during these periods are encouraged.

Diff for: implementation-guide.md

@@ -38,14 +38,14 @@ This guidance introduces an Enterprise Data Inventory framework to provide agenc
 ### A. Create and Maintain an Enterprise Data Inventory
 
 #### Purpose
-To develop a clear and comprehensive understanding of what data assets they possess, Federal Agencies are required to create an Enterprise Data Inventory (Inventory) that accounts for all data assets created or collected by the agency.  This includes, but is not limited to, data assets used in the agency’s information systems. The Inventory must be enterprise-wide, accounting for data assets across programs<sup>[2](#footnote-2)</sup>  and bureaus<sup>[3](#footnote-3)</sup>,  and must use the required [common core metadata](/schema) available on Project Open Data.   After creating the Inventory, agencies should continually improve the usefulness of the Inventory by expanding, enriching, and opening the Inventory (concepts described in the framework below).
+To develop a clear and comprehensive understanding of what data assets they possess, Federal Agencies are required to create an Enterprise Data Inventory (Inventory) that accounts for all data assets created or collected by the agency.  This includes, but is not limited to, data assets used in the agency’s information systems. The Inventory must be enterprise-wide, accounting for data assets across programs<sup>[2](#footnote-2)</sup>  and bureaus<sup>[3](#footnote-3)</sup>,  and must use the required [Project Open Data metadata schema](/schema) available on Project Open Data.   After creating the Inventory, agencies should continually improve the usefulness of the Inventory by expanding, enriching, and opening the Inventory (concepts described in the framework below).
 
 The objectives of this activity are to:
 
 * Build an internal inventory that accounts for data assets used in the agency' s information systems
 * Include data assets produced through agency contracts and cooperative agreements, and in some cases agency-funded grants; include data assets associated with, but not limited to, research, program administration, statistical, and financial activities
 * Indicate if the data may be made publicly available and if currently available
-* Describe the data with [common core metadata](/schema) available on Project Open Data.
+* Describe the data with [Project Open Data metadata schema](/schema) available on Project Open Data.
 
 #### Framework to Create and Maintain the Enterprise Data Inventory: Expand, Enrich, Open
 Since agencies have varying levels of visibility into their data assets, the size and maturity of agencies’ Enterprise Data Inventories will differ across agencies. OMB will assess agency progress toward overall maturity of the Enterprise Data Inventory through the maturity areas of “Expand,” “Enrich,” and “Open.”
@@ -89,16 +89,16 @@ Project Open Data provides metadata requirements, additional optional metadata f
 #### Create an Enterprise Data Inventory (by November 30, 2013)
 * Include, at a minimum, all data assets which were posted on Data.gov before August 1, 2013 and additional representative data assets from programs and bureaus.
 * Ensure the Inventory contains one metadata record for each data asset. A data asset can describe a collection of datasets (such as a CSV file for each state).
-* Use common core “required” fields and “required-if-applicable” fields on Project Open Data (includes indicating whether data can be made publicly available).
+* Use “required” fields and “required-if-applicable” fields on Project Open Data (includes indicating whether data can be made publicly available).
 * Submit to OMB via MAX Community<sup>[12](#footnote-12)</sup>  the inventory as a single JSON file using the defined schema from Project Open Data. OMB invites agency input on the option of replacing future submission with an API via a discussion on Project Open Data.
 
 #### Maintain the Enterprise Data Inventory (ongoing after November 30, 2013)
 * Continue to expand, enrich, and open the Inventory on an on-going basis.
 * Update the Inventory Schedule submitted on November 30, 2013 on a quarterly basis on the www.\[agency].gov/digitalstrategy page.<sup>[13](#footnote-13)</sup>
 
 #### Tools and Resources on Project Open Data
-* Out-of-the-box Inventory Tool: OMB and GSA have provided a data inventory tool (CKAN) that is customized to be compliant with the Open Data Policy out of the box. Customization includes the ability to generate the compliant Public Data Listing directly from the Inventory, as well as integration of the required common core metadata schema. Agencies may choose to install CKAN on their servers or use the centrally hosted tool.
-* Definitions and schema of “common core metadata fields” and selected “extensible metadata fields”
+* Out-of-the-box Inventory Tool: OMB and GSA have provided a data inventory tool (CKAN) that is customized to be compliant with the Open Data Policy out of the box. Customization includes the ability to generate the compliant Public Data Listing directly from the Inventory, as well as integration of the required Project Open Data metadata schema. Agencies may choose to install CKAN on their servers or use the centrally hosted tool.
+* Definitions and schema of “Project Open Data metadata fields” and selected “extensible metadata fields”
 * The JSON schema for each Inventory’s “JSON Snapshot” as well as a schema generator and validator tools to facilitate agency efforts to create metadata
 * Additional best practices, case studies, and tools
 
@@ -109,7 +109,7 @@ To improve the discoverability and usability of data assets, all federal agencie
 
 Agencies, at their discretion, may choose to include entries for non-public data assets in their Public Data Listings, taking into account guidance in section D. For example, an agency may choose to list data assets with an ‘accessLevel’ of ‘restricted public’ to make the public aware of their existence and the process by which these data may be obtained.
 
-Agencies’ Public Data Listings will be used to dynamically populate the newly renovated Data.gov, the main website to find data assets generated and held by the U.S. Government.  Data.gov allows anyone from the public to find, download, and use government data.  The upcoming re-launch of Data.gov (currently in beta at next.data.gov) will automatically aggregate the agency-managed Public Data Listings into one centralized location, using the common core metadata standards and tagging to improve the user ability to find and use government data.  
+Agencies’ Public Data Listings will be used to dynamically populate the newly renovated Data.gov, the main website to find data assets generated and held by the U.S. Government.  Data.gov allows anyone from the public to find, download, and use government data.  The upcoming re-launch of Data.gov (currently in beta at next.data.gov) will automatically aggregate the agency-managed Public Data Listings into one centralized location, using the Project Open Data metadata standards and tagging to improve the user ability to find and use government data.  
 
 The objectives of this activity are to:
 
@@ -147,7 +147,7 @@ The objectives of this activity are to:
 
 **Establish Customer Feedback Mechanism (by November 30, 2013)**
 
-* Through the common core metadata requirements, agencies are already required to include a point of contact within each data asset’s metadata listed.
+* Through the Project Open Data metadata requirements, agencies are already required to include a point of contact within each data asset’s metadata listed.
 * Agencies should create a process to engage with customers on the www.\[agency].gov/data page or other appropriate mechanism. If the feedback tool is in an external location, it must be linked to the www.\[agency].gov/data page.
 * Agencies should consider utilizing tools available on Project Open Data, such as the “Kickstart”
  plug-in, to organize feedback around individual data assets.

Diff for: index.md

@@ -30,7 +30,7 @@ This section is a list of definitions and principles used to guide the project.
 
 2-4 [Open Licenses](open-licenses/) - The definition for open licenses.
 
-2-5 [Common Core Metadata](schema/) - The schema used to describe datasets, APIs, and published data at agency.gov/data.
+2-5 [Project Open Data Metadata Schema](schema/) - The schema used to describe datasets, APIs, and published data at agency.gov/data.
 
 ----------------
 

Diff for: metadata-changelog.md

@@ -1,11 +1,11 @@
 ---
 published: true
 layout: default
-title: Common Core Metadata Changelog
+title: Metadata Changelog
 permalink: /metadata-changelog/
 filename: metadata-changelog.md
 ---
-This page lists changes to the common core metadata schema by version. Latest changes at the top. Consult [repository history](https://github.com/project-open-data/project-open-data.github.io/issues?q=is%3Aopen) for explanations.
+This page lists changes to the Project Open Data metadata schema by version. Latest changes at the top. Consult [repository history](https://github.com/project-open-data/project-open-data.github.io/issues?q=is%3Aopen) for explanations.
 
 ## Changelog