radiantearth · m-mohr · Nov 1, 2019 · Oct 15, 2019 · Oct 15, 2019 · Oct 15, 2019
diff --git a/api-spec/extensions/README.md b/api-spec/extensions/README.md
@@ -13,7 +13,7 @@ API Extensions given follow the same guidelines for Extension Maturity as given
 | -------------  | ----------- | -------- |
 | [Fields](fields/README.md) | Adds parameter to control which fields are returned in the response. | *Pilot* |
 | [Query](query/README.md) | Adds parameter to search Item and Collection properties. | *Pilot* |
-| [Search](search/README.md) | Adds search-related metadata to [ItemCollection](../../item-spec/item-spec.md#itemcollection-fields). | *Proposal* |
+| [Search](search/README.md) | Adds search-related metadata to [ItemCollection](../../item-spec/itemcollection-spec.md). | *Proposal* |
 | [Sort](sort/README.md) | Adds Parameter to control sorting of returns results. | *Pilot* |
 | [Transaction](transaction/README.md) | Adds PUT and DELETE endpoints for the creation, editing, and deleting of items and Collections. | *Pilot* |
 

diff --git a/api-spec/extensions/search/README.md b/api-spec/extensions/search/README.md
@@ -1,8 +1,8 @@
 # Search Extension Specification
 
-**Extension [Maturity Classification](../README.md#extension-maturity): Proposal**
+**Extension [Maturity Classification](../../../extensions/README.md#extension-maturity): Proposal**
 
-This extension is intended to augment the core [ItemCollection](../../item-spec/item-spec.md#itemcollection-fields) object when the ItemCollection is the result of a 
+This extension is intended to augment the core [ItemCollection](../../../item-spec/itemcollection-spec.md) object when the ItemCollection is the result of a 
 search, for example, from calling the `/stac/search` API endpoint.
 
 - [Example](examples/example.json)
@@ -12,7 +12,7 @@ search, for example, from calling the `/stac/search` API endpoint.
 
 | Element           | Type                  | Description                                                  |
 | ----------------- | --------------------- | ------------------------------------------------------------ |
-| `search:metadata` | [SearchMetadata Object](#searchmetadata-object) | **REQUIRED.** The search-related metadata for the [ItemCollection](../../../item-spec/item-spec.md#itemcollection-fields). |
+| `search:metadata` | [SearchMetadata Object](#searchmetadata-object) | **REQUIRED.** The search-related metadata for the [ItemCollection](../../../item-spec/itemcollection-spec.md). |
 
 ### SearchMetadata Object
 

diff --git a/api-spec/extensions/search/schema.json → ...extensions/search/json-schema/schema.json b/api-spec/extensions/search/schema.json → ...extensions/search/json-schema/schema.json
diff --git a/best-practices.md b/best-practices.md
@@ -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/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 
+While these recommendations were primarily written for [static catalogs](catalog-spec/catalog-spec.md#catalog-types), they apply
+equally well to [dynamic catalogs](catalog-spec/catalog-spec.md#catalog-types). 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/catalog-spec.md b/catalog-spec/catalog-spec.md
@@ -92,7 +92,7 @@ information and links they want to, while also encouraging a natural web of info
 linked to across the web.
 
 There are a number of emerging 'best practices' for how to organize and implement good catalogs. These can be found in
-the [best practices document](catalog-best-practices.md), and include things like catalog layout, use of self links, 
+the [best practices document](../best-practices.md), and include things like catalog layout, use of self links, 
 publishing catalogs, and more. This specification is designed for maximum flexbility, but the best practices provide
 guidance for good recommendations when implementing.
 
@@ -109,7 +109,7 @@ used when data holdings are already exposed through a dynamic interface, and STA
 same core database or search cluster.
 
 The two catalog types both implement the same fields and links, and can be treated as the same by clients. For more 
-details on the two types and how you might use them see the [Static and Dynamic Catalogs](catalog-best-practices.md#static-and-dynamic-catalogs) section of the best practices document.
+details on the two types and how you might use them see the [Static and Dynamic Catalogs](../best-practices.md#static-and-dynamic-catalogs) section of the best practices document.
 
 ## Catalog fields
 
@@ -148,7 +148,7 @@ with links.
 A more complete list of possible 'rel' types can be seen at the [IANA page of Link Relation Types](https://www.iana.org/assignments/link-relations/link-relations.xhtml).
 
 Please see the chapter 'relative vs absolute links' in the [Item spec](../item-spec/item-spec.md#relative-vs-absolute-links)
- for a discussion on that topic, as well as the [use of links](catalog-best-practices.md#use-of-links) section of the 
+ for a discussion on that topic, as well as the [use of links](../best-practices.md#use-of-links) section of the 
  catalog best practices document.
 
 #### Relation types

diff --git a/extensions/asset/README.md b/extensions/asset/README.md
@@ -30,7 +30,7 @@ An asset is an object that contains details about the datafiles that will be inc
 | Field Name | Type   | Description                                                                           |
 | ---------- | ------ | ------------------------------------------------------------------------------------- |
 | title      | string | **REQUIRED.** The displayed title for clients and users. This should provide enough information to a user to understand what the asset is  |
-| type       | string | **REQUIRED.** [Media type](#media-types) of the asset.
+| type       | string | **REQUIRED.** [Media type](../../item-spec/item-spec.md#media-types) of the asset.
 
 Other custom fields, or fields from other extensions may also be included in the Asset object.
 

diff --git a/extensions/checksum/README.md b/extensions/checksum/README.md
@@ -5,7 +5,7 @@
 Provides a way to specify MD5, SHA1, SHA2 and SHA3 file checksums for assets and links in STAC Items, STAC Catalogs and STAC Collections.
 
 - [Example](examples/example-sentinel1.json)
-- [JSON Schema](json-scehma/schema.json)
+- [JSON Schema](json-schema/schema.json)
 
 ## [`Link Object`](../../item-spec/item-spec.md#link-object) and [`Asset Object`](../../item-spec/item-spec.md#asset-object) fields
 

diff --git a/how-to-help.md b/how-to-help.md
@@ -7,7 +7,7 @@ If others in the community create similar functionality with their geospatial ac
 evolve extension standards that enable increased interoperability.
 
 Right now we are in the very early days of the collaboration. So while there is a core specification there is still quite a 
-few best practices to evolve and [improvements](roadmap.md) to the spec that will be needed. 
+few best practices to evolve and improvements to the spec that will be needed. 
 
 ## Implementations and Feedback
 
@@ -28,10 +28,6 @@ the hoped for ecosystem of tools and data that hopefully will come to pass. Many
 implement. Some depend on particular knowledge or background, like deep involvement with an open source project. And some
 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](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
 
 These tools are seen as the bare minimum to move STAC spec to a broader release, so that it has a base line of feedback from
@@ -66,7 +62,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](stacspec.org). 
+data as a [spec extension](extensions/). 
 
 **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/examples/README.md b/item-spec/examples/README.md
@@ -12,11 +12,11 @@ This document also contains discussion of the various examples in this folder.
 
 ### Item Examples
 
-**[sample.json](examples/sample.json)** is the most minimal possible compliant Item record. Most all data will
+**[sample.json](sample.json)** is the most minimal possible compliant Item record. Most all data will
 include additional fields, as STAC is designed to be a minimal common subset. But it is useful for showing exactly what is
 required.
 
-**[sample-full.json](examples/sample-full.json)** is a more realistic example, for a hypothetical analytic image 
+**[sample-full.json](sample-full.json)** is a more realistic example, for a hypothetical analytic image 
 acquisition from a satellite company called 'cool sat'. It includes additional fields, including some from the Earth 
 Observation extension, as well as some vendor specific additions. It also links to a variety of assets that is typical for
 satellite imagery, as most providers include a number of complementary files.
@@ -27,7 +27,7 @@ item specification.
 
 **Landsat8** The [Landsat8 sample](landsat8-sample.json) is meant to be an example of how an S3-based catalog like the 
 [Landsat on AWS](https://landsatonaws.com/) public data set could be a STAC static catalog. It includes the 'collection'
-concept, which is explained more in the [/extensions/examples/ folder](../extensions/examples/).
+concept, which is explained more in the [/collection-spec/ folder](../../collection-spec/).
 
 **Planet** The [Planet sample](planet-sample.json) is an adaption of Planet's [Data API](https://www.planet.com/docs/reference/data-api/) 
 returned JSON, with minor tweaks to have it fit in to a STAC Item.