Change URLs to not include http://project-open-data.github.io (just use e.g. /schema/)

Author: James McKinney

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](http://project-open-data.github.io/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 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. 
 
 Why this effort
 ---------------
@@ -26,12 +26,12 @@ Each agency will describe their existing datasets as they see fit using the belo
 Machine-Readable Format
 -----------------------
 
-All information deemed "machine-readable" required in this policy must be described in the JSON file format, with the option of RDFa Lite and XML as well.  See [this specification](http://project-open-data.github.io/schema/) for the required schema.  Agencies must post their files at agency.gov/data.json (and optionally at /data.html or data.xml as well).  Additionally, the web page which reads and formats these files must be posted at /data/index.html (or data.html).  The files should be updated a minimum of monthly.  It is our intent that future publications of Data.gov will simply crawl for all agency.gov/data.json to populate Data.gov.
+All information deemed "machine-readable" required in this policy must be described in the JSON file format, with the option of RDFa Lite and XML as well.  See [this specification](/schema/) for the required schema.  Agencies must post their files at agency.gov/data.json (and optionally at /data.html or data.xml as well).  Additionally, the web page which reads and formats these files must be posted at /data/index.html (or data.html).  The files should be updated a minimum of monthly.  It is our intent that future publications of Data.gov will simply crawl for all agency.gov/data.json to populate Data.gov.
 
 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](http://project-open-data.github.io/schema/). This catalog is to be published in two places. First, as a standalone JSON file at `agency.gov/data.json` and second 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 [common core metadata](/schema/). This catalog is to be published in two places. First, as a standalone JSON file at `agency.gov/data.json` and second 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
 
@@ -47,7 +47,7 @@ The JSON representation of the catalog should track directly to the RDFa version
 Generating Machine-Readable Reporting Files
 -------------------------------------------
 
-Agencies must follow the provided [specification](http://project-open-data.github.io/schema/).  We have built a [catalog generator](http://project-open-data.github.com/catalog-generator/) to assist you in building your catalog and generating JSON, XML, or RDFa Lite files.  
+Agencies must follow the provided [specification](/schema/).  We have built a [catalog generator](http://project-open-data.github.com/catalog-generator/) to assist you in building your catalog and generating JSON, XML, or RDFa Lite files.  
 
 Presentation
 ------------
@@ -58,7 +58,7 @@ Agencies must have present a table/list of each dataset in the /data page.  The
 * Dataset description
 * URL to the dataset (endpoint)
 
-The page must be populated from the machine-readable catalog file (e.g. data.xml or data.json) following the [specification](http://project-open-data.github.io/schema/) described above.  Agencies are encouraged to add functionality to assist end-user discoverability.  Additional functions might be sorting, filtering or paging to help make a more digestible list.  Agencies are also encouraged to add more to the standard schema which might further assist end-user discoverability and usability (e.g. thumbnails).
+The page must be populated from the machine-readable catalog file (e.g. data.xml or data.json) following the [specification](/schema/) described above.  Agencies are encouraged to add functionality to assist end-user discoverability.  Additional functions might be sorting, filtering or paging to help make a more digestible list.  Agencies are also encouraged to add more to the standard schema which might further assist end-user discoverability and usability (e.g. thumbnails).
 
 Supplemental Information
 ------------------------

Diff for: faq.md

@@ -92,7 +92,7 @@ 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](http://project-open-data.github.io/schema/) is based on existing vocabularies and easily mapped to NIEM, Information Sharing Environment, and FGDC.
+The [common core metadata schema](/schema/) is based on existing vocabularies and easily mapped to NIEM, Information Sharing Environment, and FGDC.
 
 ### What is a "persistent identifier"?
 
@@ -104,9 +104,9 @@ The core metadata schema was the result of recommendations from a government-wid
 
 ### How can I recommend changes and improvements to the metadata schema?
 
-Submit a pull request for the [metadata schema](http://project-open-data.github.io/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](http://project-open-data.github.io/schema/)?
+### Can I extend the metadata schema beyond the terms specified in the [common core metadata schema](/schema/)?
 
 Yes, if your data management process includes rich metadata specific to the mission of your agency or the Line of Business 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).
 
@@ -157,7 +157,7 @@ A wide variety of tools are available to manage a data catalog, whether public-f
 
 ### What formats are required/recommended for the agency.gov/data file?
 
-There are several syntaxes that may 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). It is recommended that agencies also create a data.html file and use RDFa Lite (Resource Description Framework) to mark-up the metadata using the [common core metadata schema](http://project-open-data.github.io/schema/). The RDFa Lite file can be easily consumed by major search engines and applications and make you data easier to find by the public. A third alternative for populating your metadata file is XML (eXtensible Markup Language). Agencies are encouraged to maintain all three version of the metadata file. [Tools](http://labs.data.gov) are available to transform any instance of the file into the alternative formats.
+There are several syntaxes that may 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). It is recommended that agencies also create a data.html file and use RDFa Lite (Resource Description Framework) to mark-up the metadata using the [common core metadata schema](/schema/). The RDFa Lite file can be easily consumed by major search engines and applications and make you data easier to find by the public. A third alternative for populating your metadata file is XML (eXtensible Markup Language). Agencies are encouraged to maintain all three version of the metadata file. [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

@@ -6,7 +6,7 @@ filename: governance.md
 ---
 
 ### Background
-[Project Open Data](http://project-open-data.github.com), a new White House resource, is an online collection of code, best practices, and case studies developed to help agencies adopt the framework presented in the memorandum on “Managing Government Information as an Asset to Promote Interoperability and Openness.” Project Open Data will evolve over time as a community resource to facilitate adoption of open data practices. To facilitate collaboration across the Federal Government and in partnership with public developers, the Project is published on the developer social network GitHub. 
+[Project Open Data](/), a new White House resource, is an online collection of code, best practices, and case studies developed to help agencies adopt the framework presented in the memorandum on “Managing Government Information as an Asset to Promote Interoperability and Openness.” Project Open Data will evolve over time as a community resource to facilitate adoption of open data practices. To facilitate collaboration across the Federal Government and in partnership with public developers, the Project is published on the developer social network GitHub. 
 
 As the Project founder, the White House is dedicated to maximizing openness, participation, and collaboration while ensuring the integrity of the resources hosted within the Project. This page provides information on ways to participate in the Project and how the White House will govern it. 
 
@@ -40,7 +40,7 @@ Ultimately? You. While the White House founded and continues to oversee the proj
 At the onset, the General Services Administration is here to provide daily oversight and support, but over time, it is our vision that contributors both inside and outside of government can be empowered to take on additional leadership roles.  
 
 **Can I use the project's content or source code elsewhere?**  
-The project [as originally published](http://project-open-data.github.io/) constitutes a work of the United States Government and is not subject to domestic copyright protection under 17 USC § 105. Subsequent contributions by members of the public, however, retain their original copyright.
+The project [as originally published](/) constitutes a work of the United States Government and is not subject to domestic copyright protection under 17 USC § 105. Subsequent contributions by members of the public, however, retain their original copyright.
 In order to better facilitate collaboration, the content of this project is licensed under the [Creative Commons 3.0 License](http://creativecommons.org/licenses/by/3.0/us/deed.en_US), and the underlying source code used to format and display that content is licensed under the [MIT License](http://opensource.org/licenses/mit-license.php).
 
 **How can I contribute?**  

Diff for: implementation-guide.md

@@ -13,7 +13,7 @@ Maintain a complete listing of all datasets owned, managed, collected, and/or cr
 
 ### A) Minimum Required for Compliance
 
-Produce a single catalog or list of data managed in a single table, workspace, or other relevant location. Describe each dataset according to the [common core metadata](http://project-open-data.github.io/schema/).
+Produce a single catalog or list of data managed in a single table, workspace, or other relevant location. Describe each dataset according to the [common core metadata](/schema/).
 
 This listing can be maintained in a Data Management System (DMS) such as the open-source [CKAN](http://www.ckan.org) platform; a single spreadsheet, with each metadata field as its own column; or a DMS of your choosing.
 
@@ -38,7 +38,7 @@ While agencies are only required to list datasets with an "Access Level" value o
 
 Document any datasets or metadata in your enterprise data inventory that your agency does not believe can be made publicly available, in consultation with your Office of General Counsel or its equivalent.
 
-Publish your agency’s enterprise data inventory, with the aforementioned information removed, to a file located at [agency].gov/data.json and described using (at minimum) the [common core metadata](http://project-open-data.github.io/schema/). This file itself must be listed as a dataset within itself (see [an example of format](http://project-open-data.github.io/examples/catalog-sample-extended.json) ); if you have multiple data.json files across your agency, include all of them in the top-level data.json at agency.gov/data.json.
+Publish your agency’s enterprise data inventory, with the aforementioned information removed, to a file located at [agency].gov/data.json and described using (at minimum) the [common core metadata](/schema/). This file itself must be listed as a dataset within itself (see [an example of format](/examples/catalog-sample-extended.json) ); if you have multiple data.json files across your agency, include all of them in the top-level data.json at agency.gov/data.json.
 
 While you could manually create this file in a text editor, it is recommended that you use one of the tools provided to generate this file automatically from your existing DMS or enterprise inventory file.
 
@@ -51,7 +51,7 @@ While you could manually create this file in a text editor, it is recommended th
 
 ### C) Best Practices and Examples
 
-* Using the [common core metadata](http://project-open-data.github.io/schema) to describe your enterprise data inventory makes it very simple to use that inventory for your public inventory.
+* Using the [common core metadata](/schema) to describe your enterprise data inventory makes it very simple to use that inventory for your public inventory.
 * A detailed and descriptive title, description, and set of keywords for each dataset is the difference between customers finding your data and no one finding your data. Since agency data catalogs are harvested and searchable on Data.gov, accurate and thorough metadata is the best way to connect customers with your data.
 * 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.
@@ -77,7 +77,7 @@ Create a process to solicit feedback from customers about existing and potential
 
 ### B) Best Practices and Examples
 
-* 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.
+* The required set of [common core metadata](/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.
 
 
@@ -163,7 +163,7 @@ Collect or create information (data) in a way that supports downstream informati
 ### A) Minimum Required for Compliance
 
 * Review information for privacy, confidentiality pledge, security, and other restrictions to release.
-* Make the data available in a machine-readable format. See [this list](http://project-open-data.github.io/faq.md) of commonly accepted machine-readable formats. Where appropriate, provide access to the data via an API.
+* Make the data available in a machine-readable format. See [this list](/faq.md) of commonly accepted machine-readable formats. Where appropriate, provide access to the data via an API.
 * Post the data files in an Internet-accessible location, listing this location the dataset’s entry in your agency inventory listing.
 
 ### B) Tools
@@ -185,7 +185,7 @@ New, or significantly modified, information systems need to support interoperabi
 
 * Ensure the system can export data in a machine-readable format.
 * Ensure data is separated from the application layer of the system to maximize future export and/or reuse of the data.
-* Store and export data using open data standards whenever possible, including the [common core metadata](http://project-open-data.github.io/schema/) required by this Memorandum.
+* Store and export data using open data standards whenever possible, including the [common core metadata](/schema/) required by this Memorandum.
 * Document all data schemas and dictionaries used by the system.
 
 ### B) Best Practices and Examples

Diff for: policy-memo.md

@@ -76,7 +76,7 @@ This attachment provides definitions and implementation guidance for M-13-13, *O
 
 * *Managed Post-Release.* A point of contact must be designated to assist with data use and to respond to complaints about adherence to these open data requirements. 
 
-* *Project Open Data:* "Project Open Data," a new OMB and OSTP resource, is an online repository of tools, best practices, and schema to help agencies adopt the framework presented in this guidance. Project Open Data can be accessed at [project-open-data.github.io](http://project-open-data.github.io).[^18] Project Open Data will evolve over time as a community resource to facilitate adoption of open data practices. The repository includes definitions, code, checklists, case studies, and more, and enables collaboration across the Federal Government, in partnership with public developers, as applicable. Agencies can visit Project Open Data for a more comprehensive glossary of terms related to open data.
+* *Project Open Data:* "Project Open Data," a new OMB and OSTP resource, is an online repository of tools, best practices, and schema to help agencies adopt the framework presented in this guidance. Project Open Data can be accessed at [project-open-data.github.io](/).[^18] Project Open Data will evolve over time as a community resource to facilitate adoption of open data practices. The repository includes definitions, code, checklists, case studies, and more, and enables collaboration across the Federal Government, in partnership with public developers, as applicable. Agencies can visit Project Open Data for a more comprehensive glossary of terms related to open data.
 
 ### II. Scope