updates from review comments

best-practices.md

@@ -467,11 +467,11 @@ if you follow these recommendations.
 1. Root documents (Catalogs / Collections) should be at the root of a directory tree containing the static catalog.
 2. Catalogs should be named `catalog.json` and Collections should be named `collection.json`.
 3. Items should be named `<id>.json`.
-4. Sub-Catalogs should be stored in subdirectories of their parent
+4. Sub-Catalogs or sub-Collections should be stored in subdirectories of their parent
    (and only 1 subdirectory deeper than a document's parent, e.g. `.../sample/sub1/catalog.json`).
-5. Items should be stored in subdirectories of their parent Catalog. 
+5. Items should be stored in subdirectories of their parent Catalog or Collection. 
 This means that each Item and its assets are contained in a unique subdirectory.
-6. Limit the number of Items in a Catalog or sub-Catalog, grouping / partitioning as relevant to the dataset.
+6. Limit the number of Items in a Catalog or Collection, grouping / partitioning as relevant to the dataset.
 7. Use structural elements (Catalog and Collection) consistently across each 'level' of your hierarchy.
    For example, if levels 2 and 4 of the hierarchy only contain Collections, 
 don't add a Catalog at levels 2 and 4.
@@ -487,7 +487,7 @@ different sub-catalog organization structures. For example one catalog could div
 by providers, and users could browse down to both. The leaf Items should just be linked to in a single canonical location 
 (or at least use a rel link that indicates the location of the canonical one). It is recommended that dynamic catalogs 
 provide multiple 'views' to allow users to navigate in a way that makes sense to them, providing multiple 'sub-catalogs'
-from the root Catalog that enable different paths to browse (country/state, date/time, constellation/satellite, etc). But the 
+from the root that enable different paths to browse (country/state, date/time, constellation/satellite, etc). But the 
 canonical 'rel' link should be used to designate the primary location of the Item to search engine crawlers.
 
 #### Mixing STAC Versions
@@ -612,7 +612,7 @@ implement it.
 #### Relative Published Catalog
 
 This is a self-contained catalog as described above, except it includes an absolute `self` link at
-the root catalog, to identify its online location. This is designed so that a self-contained catalog (of either type, with its 
+the root to identify its online location. This is designed so that a self-contained catalog (of either type, with its 
 assets or just metadata) can be 'published' online
 by just adding one field (the self link) to its root (Catalog or Collection). All the other links should remain the same. The resulting catalog
 is no longer compliant with the self-contained catalog recommendations, but instead transforms into a 'relative published catalog'. 

catalog-spec/catalog-spec.md

@@ -36,8 +36,8 @@ and fields to be compliant.
 This Catalog specification primarily defines a structure for information to be discoverable. Any use 
 that is publishing a set of related spatiotemporal assets is strongly recommended to also use the 
 STAC Collection specification to provide additional information about the set of Items 
-contained in a Catalog, in order to give contextual information to aid in discovery. Every STAC Collection is 
-also a valid STAC Catalog.
+contained in a Catalog, in order to give contextual information to aid in discovery. Every STAC Collection contains all
+the same fields as Catalog, though returns 'Collection' instead of 'Catalog' for the type field.
 
 ## Catalog fields
 
@@ -93,7 +93,7 @@ The following types are commonly used as `rel` types in the Link Object of a STA
 | child   | URL to a child STAC Catalog or Collection. |
 | item    | URL to a STAC Item. |
 
-**Note:** A link to at least one `item` or `child` Catalog is **REQUIRED**.
+**Note:** A link to at least one `item` or `child` (Catalog or Collection) is **REQUIRED**.
 
 There are additional `rel` types in the [Using Relation Types](../best-practices.md#using-relation-types) best practice, but as 
 they are more typically used in Collections, as Catalogs tend to just be used to structure STAC organization, so tend to just use

collection-spec/collection-spec.md

@@ -254,7 +254,7 @@ This is done where there is not a clear official option, or where STAC uses an o
 | self    | STRONGLY RECOMMENDED. *Absolute* URL to the location that the Collection file can be found online, if available. This is particularly useful when in a download package that includes metadata, so that the downstream user can know where the data has come from. |
 | root    | URL to the root STAC entity (Catalog or Collection). Collections should include a link to their root, even if it's the root and points to itself. |
 | parent  | URL to the parent STAC entity (Catalog or Collection). Non-root Collections should include a link to their parent. |
-| child   | URL to a child STAC Catalog or Collection. |
+| child   | URL to a child STAC entity (Catalog or Collection). |
 | item    | URL to a STAC Item. All Items linked from a Collection MUST refer back to its Collection with the [`collection` relation type](../item-spec/item-spec.md#relation-types). |
 | license | The license URL(s) for the Collection SHOULD be specified if the `license` field is set to `proprietary` or `various`. If there is no public license URL available, it is RECOMMENDED to put the license text in a separate file and link to this file. |
 | derived_from | URL to a STAC Collection that was used as input data in the creation of this Collection. See the note in [STAC Item](../item-spec/item-spec.md#derived_from) for more info. |