radiantearth · matthewhanson · Oct 11, 2019 · Aug 28, 2019 · Aug 31, 2019 · Sep 5, 2019
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -8,6 +8,7 @@ and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.
 
 ### Fixed
 - [Label extension](extensions/label/README.md): moved label:classes to be a list of Class Objects from a single Class Object in spec markdown and json schema (matching previous example JSON).
+- [Label extension](extensions/label/README.md): moved label:overview to be a list of Overview Objects from a single Overview Object in spec markdown and json schema (matching previous example JSON).
 
 ## [v0.8.0-RC1] - 2019-08-23
 

diff --git a/README.md b/README.md
@@ -71,7 +71,7 @@ just the Items a user requests in their query. The API is specified as a couple
 **Extensions:** The *[extensions/](extensions/)* folder is where extensions live. Extensions can extend the 
 functionality of the core spec or add fields for specific domains.
 
-**Additional documents** include the current [roadmap](roadmap.md) and a complementary [how to help](how-to-help.md)
+**Additional documents** A complementary [how to help](how-to-help.md)
 document, a [list of implementations](implementations.md), 
 and a discussion of the collaboration [principles](principles.md) and specification approach.
 

diff --git a/best-practices.md b/best-practices.md
@@ -24,7 +24,7 @@ people can just search for 'landsat-8', instead of thinking through all the ways
 
 ## Static and Dynamic Catalogs
 
-As mentioned in the main [Catalog specification](catalog-spec.md), there are two main types of catalogs - static
+As mentioned in the main [Catalog specification](catalog-spec/catalog-spec.md), there are two main types of catalogs - static
 and dynamic. This section explains each of them in more depth and shares some best practices on each.
 
 ### Static Catalogs
@@ -49,7 +49,7 @@ is to place the catalog file in namespaces "directories". For example:
 ### Dynamic Catalogs
 
 Dynamic STAC Catalogs are those that generate their JSON responses programmatically instead of relying on a set of
-already defined files. Typically a dynamic catalog implements the full [STAC API](../stac-api/) which enables 
+already defined files. Typically a dynamic catalog implements the full [STAC API](api-spec/api-spec.md/) which enables 
 search of the Items indexed. But the `/stac/` endpoint returns the exact same `Catalog` and `Item` structures as a
 static catalog, enabling the same discovery from people browsing and search engines crawling. Dynamic API's that
 just seek to expose some data can also choose to only implement a Catalog the `/stac/` endpoint that returns dynamically.
@@ -83,8 +83,8 @@ This means that each item and its assets are contained in a unique subdirectory
 
 ### Dynamic Catalog Layout
 
-While these recommendations were primarily written for [static catalogs](catalog-spec.md#static-catalogs), they apply
-equally well to [dynamic catalogs](catalog-spec.md#dynamic-catalogs). Subdirectories of course would just be URL paths 
+While these recommendations were primarily written for [static catalogs](catalog-spec/catalog-spec.md#static-catalogs), they apply
+equally well to [dynamic catalogs](catalog-spec/catalog-spec.md#dynamic-catalogs). Subdirectories of course would just be URL paths 
 generated dynamically, but the structure would be the same as is recommended.
 
 One benefit of a dynamic catalog is that it can generate various 'views' of the catalog, exposing the same Items in 

diff --git a/catalog-spec/README.md b/catalog-spec/README.md
@@ -20,7 +20,7 @@ an OpenAPI definition of the standard way to do this, at the `/stac/` endpoint.
 It includes an overview and in depth explanation of the structures and fields.
 
 **Best Practices:** While the main spec is designed to be quite flexible, there are a set of emerging best practices for
-how to actually manage a catalog. The *[catalog-best-practices.md](catalog-best-practices.md)* document lays out a number
+how to actually manage a catalog. The *[catalog-best-practices.md](../best-practices.md#static-and-dynamic-catalogs)* document lays out a number
 of these. In time some of these may evolve to be part of the core spec.
 
 **Examples:** For samples of how Catalogs can be implemented the *[examples/](examples/)* folder
@@ -31,7 +31,7 @@ The primary one is *[catalog.json](json-schema/catalog.json)*.
 
 ## Schema Validation
 
-Instruction on schema validation for STAC Catalog can be found in the [validation instructions](validation/README.md).
+Instruction on schema validation for STAC Catalog can be found in the [validation instructions](../validation/README.md).
 
 
 ## Catalog Evolution 

diff --git a/catalog-spec/examples/basic.json → catalog-spec/examples/catalog.json b/catalog-spec/examples/basic.json → catalog-spec/examples/catalog.json
diff --git a/collection-spec/README.md b/collection-spec/README.md
@@ -26,7 +26,7 @@ structures and fields.
 
 ## Schema Validation
 
-Instruction on schema validation for STAC Items can be found in the [validation instructions](validation/README.md).
+Instruction on schema validation for STAC Items can be found in the [validation instructions](../validation/README.md).
 
 ## Collection Flexibility
 

diff --git a/extensions/README.md b/extensions/README.md
@@ -135,7 +135,7 @@ An example of this can be seen in a Landsat example:
 A STAC extension can have references to additional schemas within the extension schema. 
 These files should be kept together in order to preserve relative `$ref` links. 
 
-See the [EU](eo/) extension file structure as an example.
+See the [EO](eo/) extension file structure as an example.
 * Specification examples should be stored in an `examples` directory. 
 * The specification schema file(s) should be stored in a `json-schema` directory. 
 

diff --git a/extensions/label/README.md b/extensions/label/README.md
@@ -52,7 +52,7 @@ Some additional notes are given here for some of the core STAC Item fields and w
 | label:type        | string               | Type                       | **REQUIRED** An ENUM of either `vector` label type or `raster` label type |
 | label:task        | [string]             | Task                       | Recommended to be a subset of 'regression', 'classification', 'detection', or 'segmentation', but may be an arbitrary value |
 | label:method      | [string]             | Method                     | Recommended to be a subset of 'automated' or 'manual', but may be an arbitrary value. |
-| label:overview    | [Label Overview Object](#label-overview-object) | Overview | An Object storing counts (for classification-type data) or summary statistics (for continuous numerical/regression data). |
+| label:overview    | [[Label Overview Object](#label-overview-object)] | Overview | An Object storing counts (for classification-type data) or summary statistics (for continuous numerical/regression data). |
 
 #### Class Object
 | Field Name      | Type                 | name                       | description       |

diff --git a/extensions/label/schema.json b/extensions/label/schema.json
@@ -75,42 +75,45 @@
           },
           "label:overview": {
             "title": "Overview",
-            "type": "object",
-            "properties": {
-              "property_key": {
-                "title": "Property Key",
-                "type": "string"
-              },
-              "counts": {
-                "title": "Counts",
-                "type": "array",
-                "items": {
-                  "type": "object",
-                  "properties": {
-                    "name": {
-                      "title": "Class Name",
-                      "type": "string"
-                    },
-                    "count": {
-                      "title": "Count",
-                      "type": "integer"
+            "type": "array",
+            "items": {
+              "type": "object",
+              "properties": {
+                "property_key": {
+                  "title": "Property Key",
+                  "type": "string"
+                },
+                "counts": {
+                  "title": "Counts",
+                  "type": "array",
+                  "items": {
+                    "type": "object",
+                    "properties": {
+                      "name": {
+                        "title": "Class Name",
+                        "type": "string"
+                      },
+                      "count": {
+                        "title": "Count",
+                        "type": "integer"
+                      }
                     }
                   }
-                }
-              },
-              "statistics": {
-                "title": "Statistics",
-                "type": "array",
-                "items": {
-                  "type": "object",
-                  "properties": {
-                    "name": {
-                      "title": "Stat Name",
-                      "type": "string"
-                    },
-                    "value": {
-                      "title": "Value",
-                      "type": "number"
+                },
+                "statistics": {
+                  "title": "Statistics",
+                  "type": "array",
+                  "items": {
+                    "type": "object",
+                    "properties": {
+                      "name": {
+                        "title": "Stat Name",
+                        "type": "string"
+                      },
+                      "value": {
+                        "title": "Value",
+                        "type": "number"
+                      }
                     }
                   }
                 }

diff --git a/how-to-help.md b/how-to-help.md
@@ -29,7 +29,7 @@ implement. Some depend on particular knowledge or background, like deep involvem
 only a few people are able to do, since they depend on working for a particular company.
 
 In time we may try to track these in their own project, but for now this list should be sufficient. It is a complement
-to the [roadmap](roadmap.md), which is just for the specification itself. But that roadmap will only evolve with this
+to the [roadmap](stacspec.org), which is just for the specification itself. But that roadmap will only evolve with this
 set of work on real implementations to inform it.
 
 ### Tier 1
@@ -66,7 +66,7 @@ well as a nice command line tool.
 **API -> Static catalog tool** - Building on top of core client and server tooling in tier one can introduce some cool value add tools.
 A client library that crawls a STAC API and can create a static STAC can be used as a 'backup' tool for an API, making a copy
 of the catalog that can't go down (ideally this would extend the spec to have a link 'rel' type that refers back to the source
-data as a [spec extension](https://github.com/radiantearth/stac-spec/blob/dev/roadmap.md#provenance--duplication-tracking). 
+data as a [spec extension](stacspec.org). 
 
 **Static catalog -> API tool** - The flip of the previous tool,  a STAC API could crawl a static catalog and serve as a 
 dynamic query service on top of the core.

diff --git a/item-spec/README.md b/item-spec/README.md
@@ -23,7 +23,7 @@ discussion of the examples.
 
 ## Schema Validation
 
-Instruction on schema validation for STAC Items can be found in the [validation instructions](validation/README.md).
+Instruction on schema validation for STAC Items can be found in the [validation instructions](../validation/README.md).
 
 ## Item Evolution 
 

diff --git a/item-spec/item-spec.md b/item-spec/item-spec.md
@@ -232,5 +232,5 @@ There is a lot of metadata that is only of relevance to advanced processing algo
 It is recommended to have a complementary HTML version of each `Item` available for easy human consumption and search 
 engine crawlability. The exact nature of the HTML is not part of the specification, but it is recommended to use common
 ecosystem tools like [STAC Browser](https://github.com/radiantearth/stac-browser) to generate it. More information on creating 
-HTML versions of STAC can be found in the [STAC on the Web section](../catalog-spec/catalog-best-practices.md#stac-on-the-web) 
+HTML versions of STAC can be found in the [STAC on the Web section](../best-practices.md#stac-on-the-web) 
 of the catalog best practices document.