You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jun 18, 2024. It is now read-only.
Copy file name to clipboardExpand all lines: index.md
+1-1
Original file line number
Diff line number
Diff line change
@@ -66,7 +66,7 @@ This section is a list of ready-to-use solutions or tools that will help agencie
66
66
67
67
4-5 [PDF Filler](https://github.com/project-open-data/pdf-filler) - PDF Filler is a RESTful service (API) to aid in the completion of existing PDF-based forms and empower web developers to use browser-based forms and modern web standards to facilitate the collection of information. - *[Hosted](http://labs.data.gov/pdf-filler)*
68
68
69
-
4-6 [Catalog Generator](http://labs.data.gov/dashboard/datagov/csv_to_json) - Multi-format tool to generate and maintain agency.gov/data catalog files. - *[Alternative](http://project-open-data.github.com/catalog-generator/)*
69
+
4-6 [Inventory.data.gov](https://inventory.data.gov/) - A data management tool to generate and maintain Enterprise Data Inventory and Public Data Listing JSON files. - *[How to Guide](https://www.digitalgov.gov/resources/inventory-data-gov-guide/)*
70
70
71
71
4-7 [Data.json validator](http://labs.data.gov/dashboard/validate) can help you check compliance with the POD schema.
Copy file name to clipboardExpand all lines: licensing-resources.md
+10
Original file line number
Diff line number
Diff line change
@@ -76,5 +76,15 @@ An educational resource for government employees and government contractors to u
76
76
77
77
A checklist developed at NSA to document the internal processes required to release government-developed software as open source software. It provides a detailed example for other agencies to use as a starting point. The original document contained a number of NSA-specific processes, the linked document is a "template" version that removes the specifics, and leaves just the outline and advisory material.
78
78
79
+
###[National Aeronautics and Space Administration ESDSWG Open Source Working Group](https://earthdata.nasa.gov/esdswg#OpenSourceWorkingGroup-MissionStatement)
80
+
81
+
The National Aeronuatics and Space Administration (NASA) Earth Science Data System Working Groups (ESDSWG) are chartered to
82
+
provide recommendations and guidance to the NASA data center community (missions, archives, etc.) in Earth
83
+
science including standards, technical infusion, recommendations in open source and software reuse and in
84
+
big data. The Open Source Working Group within this organization promotes the consumption and production of
85
+
open source software, processes, standards and governance models throughout NASA’s Earth Science Data Systems.
86
+
Work includes recommendations of open source licenses for NASA software projects, and case studies and use
87
+
cases of leveraging licenses in both the consumption and production of open source software.
Copy file name to clipboardExpand all lines: schema.md
+14-4
Original file line number
Diff line number
Diff line change
@@ -6,11 +6,21 @@ permalink: /schema/
6
6
filename: schema.md
7
7
id: schema
8
8
---
9
-
9
+
10
+
11
+
******************
12
+
13
+
14
+
10
15
{: .bg-warning .text-danger}
11
-
***IMPORTANT NOTE***
12
-
This version of the schema has been deprecated in favor of the [Project Open Data Metadata Schema v1.1](/v1.1/schema). Federal CFO-Act agencies are expected to complete the transition to the v1.1 schema by **February 1st, 2015**.
13
-
16
+
***IMPORTANT NOTE***
17
+
This version of the schema has been deprecated in favor of the [Project Open Data Metadata Schema v1.1](/v1.1/schema). Federal CFO-Act agencies are expected to complete the transition to the v1.1 schema by **February 1st, 2015**.
18
+
19
+
20
+
******************
21
+
22
+
23
+
14
24
This section contains guidance to support the use of the common core metadata to list agency datasets and application programming interfaces (APIs) as hosted at agency.gov/data.
15
25
16
26
Updates to the metadata schema can be found in the [changelog](/metadata-changelog). This is metadata version: 1.0 FINAL as of 9/20/13.
Copy file name to clipboardExpand all lines: standards.md
+1-1
Original file line number
Diff line number
Diff line change
@@ -5,7 +5,7 @@ permalink: /open-standards/
5
5
filename: standards.md
6
6
---
7
7
8
-
Consistent with existing agency responsibilities under [OMB Circular A-119](http://www.whitehouse.gov/omb/circulars_a119) (Federal Participation in the Development and Use of Voluntary Consensus Standards and in Conformity Assessment Activities), and [M-12-08](http://www.whitehouse.gov/sites/default/files/omb/memoranda/2012/m-12-08.pdf), the use of consensus standards, specifications, and formats can be used to support open data objectives. OMB Circular A-119 states that voluntary consensus standards should be developed through a process that is defined by the following attributes:
8
+
Consistent with existing agency responsibilities under [OMB Circular A-119](http://www.whitehouse.gov/omb/circulars_a119) (Federal Participation in the Development and Use of Voluntary Consensus Standards and in Conformity Assessment Activities), and [M-12-08](http://www.whitehouse.gov/sites/default/files/omb/memoranda/2012/m-12-08.pdf), the use of consensus standards, specifications, and formats can be used to support open data objectives. OMB Circular A-119 states that voluntary consensus standards should be developed through a process that is defined by the following attributes:
Copy file name to clipboardExpand all lines: v1.1/api.md
+10-10
Original file line number
Diff line number
Diff line change
@@ -6,38 +6,38 @@ permalink: /v1.1/api/
6
6
filename: api.md
7
7
---
8
8
9
-
Agencies should list private, internal, and public-facing web APIs as part of their Enterprise Data Inventory and Public Data Listing data.json files. The original v1.0 schema accommodated the listing of APIs with a separate `webServices` field, but with the [v1.1 schema](/v1.1/schema/), APIs should now be listed as a separate distribution within a dataset. Since an API provides indirect access to a dataset and the primary URL that a user needs in order to access the API is the API documentation, all web APIs should be referenced using the primary API documentation URL as an `accessURL` with the `format` specified as "API". The `downloadURL` and `mediaType` fields should be left empty for a distribution that describes an API, but if the raw data download that powers the API is also available (as it should be) then that should be specified using the `downloadURL` and `mediaType` of another distribution entry on the same dataset.
9
+
Agencies should list private, internal, and public-facing web APIs as part of their Enterprise Data Inventory and Public Data Listing data.json files. The original v1.0 schema accommodated the listing of APIs with a separate `webServices` field, but with the [v1.1 schema](/v1.1/schema/), APIs should now be listed as a separate distribution within a dataset. Since an API provides indirect access to a dataset and the primary URL that a user needs in order to access the API is the API documentation, all web APIs should be referenced using the primary API documentation URL as an `accessURL` with the `format` specified as "API". The `downloadURL` and `mediaType` fields should be left empty for a distribution that describes an API, but if the raw data download that powers the API is also available (as it should be) then that should be specified using the `downloadURL` and `mediaType` of another distribution entry on the same dataset.
For APIs that also have machine readable documentation (like [Swagger](https://github.com/swagger-api/swagger-spec#readme), [RAML](http://raml.org/), [API Blueprint](https://apiblueprint.org/), [HAL](http://stateless.co/hal_specification.html), [Hydra](http://www.w3.org/ns/hydra/spec/latest/core/), etc) it can be specified with `describedBy` and `describedByType`. The URL for the machine readable documentation should be specified by `describedBy` and `describedByType` should be a media type that identifies the format of the machine readable documentation.
14
+
For APIs that also have machine readable documentation (like [Swagger](https://github.com/swagger-api/swagger-spec#readme), [RAML](http://raml.org/), [API Blueprint](https://apiblueprint.org/), [HAL](http://stateless.co/hal_specification.html), [Hydra](http://www.w3.org/ns/hydra/spec/latest/core/), etc) it can be specified with `describedBy` and `describedByType`. The URL for the machine readable documentation should be specified by `describedBy` and `describedByType` should be a media type that identifies the format of the machine readable documentation.
15
15
16
16
Media Types for Machine Readable API Documentation
These media types should be used for the `describedByType` field along with the URL to the machine readable documentation itself using the `describedBy` field. This should not be confused with the `format` field which should be "API" for an API and `mediaType` which should be blank for an API.
19
+
These media types should be used for the `describedByType` field along with the URL to the machine readable documentation itself using the `describedBy` field. This should not be confused with the `format` field which should be "API" for an API and `mediaType` which should be blank for an API.
20
20
21
-
* The media type for Swagger has been [proposed](https://github.com/wordnik/swagger-spec/issues/110) as `application/swagger+json`
21
+
* The media type for Swagger has been [proposed](https://github.com/wordnik/swagger-spec/issues/110) as `application/swagger+json`
22
22
* The media type for RAML has been [defined](http://raml.org/spec.html#overview) as `application/raml+yaml`
23
23
* The media type for API Blueprint has been [defined](https://github.com/apiaryio/api-blueprint-ast#media-types) as `application/vnd.apiblueprint.ast` in abstract syntax tree form, plus others depending on the serialization
24
24
* The media type for HAL has been [defined](http://stateless.co/hal_specification.html) as `application/hal+json` and `application/hal+xml` for the JSON and XML variants.
25
-
* The media type for Hydra has been [proposed](http://www.w3.org/ns/hydra/spec/latest/core/#h3_adding-affordances-to-representations) as `application/ld+json` with `rel="http://www.w3.org/ns/hydra/core#apiDocumentation"` included in the `Link` HTTP header.
25
+
* The media type for Hydra has been [proposed](http://www.w3.org/ns/hydra/spec/latest/core/#h3_adding-affordances-to-representations) as `application/ld+json` with `rel="http://www.w3.org/ns/hydra/core#apiDocumentation"` included in the `Link` HTTP header.
Some APIs may implement a common standard such as WMS, WFS, or Open311. If this is an established standard, use the canonical URI for the standard as the value for the `conformsTo` field in the same distribution object where the API is listed.
29
+
Some APIs may implement a common standard such as WMS, WFS, or Open311. If this is an established standard, use the canonical URI for the standard as the value for the `conformsTo` field in the same distribution object where the API is listed.
0 commit comments