Fixed old references/texts mostly introduced by other PRs.

api-spec/WFS3core+STAC.yaml

@@ -785,11 +785,11 @@ components:
               - properties
               - constructions
         version:
-          title: Dataset Version
+          title: Collection Version
           type: string
           example: 1
         license:
-          title: Dataset License Name
+          title: Collection License Name
           type: string
           example: Apache-2.0
         provider:

api-spec/definitions/STAC-collections.fragment.yaml

@@ -26,11 +26,11 @@ components:
               - properties
               - constructions
         version:
-          title: Dataset Version
+          title: Collection Version
           type: string
           example: 1
         license:
-          title: Dataset License Name
+          title: Collection License Name
           type: string
           example: Apache-2.0
         provider:

catalog-spec/catalog-recommendations.md

@@ -101,8 +101,8 @@ definition for clients. See for example DigitalGlobe's definition:
 
 In this scenario, an `Asset` must have some field that specifies a uri to a JSON file that has the additional metadata.
 
-This would make sense at a Catalog or Dataset level, though more work is needed to define exactly how it would look. It
-could be a generic Asset Definition JSON set of fields, that could be added at the dataset level or could be used 
+This would make sense at a Catalog or Collection level, though more work is needed to define exactly how it would look. It
+could be a generic Asset Definition JSON set of fields, that could be added at the collection level or could be used 
 independently. Ideally each Asset would have a way to link directly to its definition.
 
 See for example a sample landsat definition:

catalog-spec/catalog-spec.md

@@ -77,7 +77,8 @@ the *rel* attribute to further describe the relationship.
 
 There are a few types of catalogs that implementors occasionally refer to. These get defined by the `links` structure.
 
- * A **sub-catalog** is a Catalog that is linked to from another Catalog that is used to better organize data. For example a Landsat dataset might have sub-catalogs for each Path and Row, so as to create a nice tree structure for users to follow.
+ * A **sub-catalog** is a Catalog that is linked to from another Catalog that is used to better organize data. For example a Landsat collection
+ might have sub-catalogs for each Path and Row, so as to create a nice tree structure for users to follow.
  * A **root catalog** is a Catalog that only links to sub-catalogs. These are typically entry points for browsing data. Often
  they will contain the [STAC Collection](../collection-spec) definition, but in implementations that publish diverse information it may
  contain sub-catalogs that provide a variety of collections.

extensions/README.md

@@ -49,7 +49,7 @@ stable for over a year and are used in twenty or more implementations.
 | [Commons](commons/) (-)                                      | Item             | Provides a way to specify data fields in a collection that are common across the STAC Items in that collection, so that each does not need to repeat all the same information. | *Proposal* |
 | [Datetime Range](datetime-range/) (`dtr`)                    | Item             | An extension to provide datetime ranges with a start and an end datetime stamp in a consistent way. | *Proposal* |
 | [EO](eo/) (`eo`)                                 | Item             | Covers electro-optical data that represents a snapshot of the earth for a single date and time. It could consist of multiple spectral bands, for example visible bands, infrared bands, red edge bands and panchromatic bands. The extension provides common fields like bands, cloud cover, off nadir, sun angle + elevation, gsd and more. | *Pilot* |
-| [Scientific](scientific/) (`sci`)                            | Catalog +Dataset | Scientific metadata is considered to be data that indicate from which publication a dataset originates and how the dataset itself should be cited or referenced. | *Proposal* |
+| [Scientific](scientific/) (`sci`)                            | Collection       | Scientific metadata is considered to be data that indicate from which publication a collection originates and how the collection itself should be cited or referenced. | *Proposal* |
 | [Transaction](transaction/)                                  | API              | Provides an API extension to support the creation, editing, and deleting of items on a specific WFS3 collection. | *Pilot* |
 
 ## Third-party / vendor extensions

extensions/commons/README.md

@@ -2,7 +2,7 @@
 
 **Extension [Maturity Classification](../README.md#extension-maturity): Proposal**
 
-A group of STAC Item objects from a single source can share a lot of common metadata. This is especially true with satellite imagery that uses the STAC EO Extension. Rather than including these common metadata fields on every Item, they can be provided into the [STAC Collection](../../dataset-spec/) that the STAC Items belong to.
+A group of STAC Item objects from a single source can share a lot of common metadata. This is especially true with satellite imagery that uses the STAC EO Extension. Rather than including these common metadata fields on every Item, they can be provided into the [STAC Collection](../../collection-spec/) that the STAC Items belong to.
 
 - Examples (missing, PRs welcome)
 - JSON Schema (missing, PRs welcome)

extensions/transaction/WFS3core+STAC+extensions.yaml

@@ -917,11 +917,11 @@ components:
               - properties
               - constructions
         version:
-          title: Dataset Version
+          title: Collection Version
           type: string
           example: 1
         license:
-          title: Dataset License Name
+          title: Collection License Name
           type: string
           example: Apache-2.0
         provider:

item-spec/item-spec.md

@@ -91,13 +91,13 @@ allowed to add additional fields such as a `title` and `type`.
 
 The following types are commonly used as `rel` types in the Link Object of an Item:
 
-| Type    | Description                                                  |
-| ------- | ------------------------------------------------------------ |
-| self    | **REQUIRED.** _Absolute_ URL to the item file itself. This is required, to represent the location that the file can be found online. 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 Catalog](../catalog-spec/) or [Dataset](../collection-spec/). |
-| parent  | URL to the parent [STAC Catalog](../catalog-spec/) or [Dataset](../collection-spec/). |
-| dataset | **REQUIRED.** URL to a [STAC Dataset](../collection-spec/). |
-| derived_from | URL to a STAC `Item` that was used as input data in the creation of this `Item` |
+| Type         | Description                                                  |
+| ------------ | ------------------------------------------------------------ |
+| self         | **REQUIRED.** _Absolute_ URL to the item file itself. This is required, to represent the location that the file can be found online. 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 [Catalog](../catalog-spec/) or [Collection](../collection-spec/). |
+| parent       | URL to the parent STAC [Catalog](../catalog-spec/) or [Collection](../collection-spec/). |
+| collection   | STRONGLY RECOMMENDED. URL to a [Collection](../collection-spec/), which may use the [Commons extension](../extensions/commons/) and holds common fields of this and other Items (see chapter 'Collections'). |
+| derived_from | URL to a STAC Item that was used as input data in the creation of this Item. |
 
 *Note regarding the type `derived_from`: A full provenance model is far beyond the scope of STAC, and the goal is to align with any good independent spec 
 that comes along for that. But the derived_from field is seen as a way to encourage fuller specs and at least start a linking
@@ -111,12 +111,12 @@ whenever possible. But Static Catalogs are potentially more portable if they can
 relative links, so that every link doesn't need to be rewritten when the data is copied. The `self`
 link is required to be absolute.
 
-#### Datasets
+#### Collections
 
-Items are *strongly recommended* to provide a link to a dataset definition. It is important as datasets 
-provide additional information about a set of items, for example the license and provider information 
-and optionally any common information shared across all items, giving context on the overall set of
-data that an individual Item is a part of..
+Items are *strongly recommended* to provide a link to a STAC Collection definition. It is important as Collections 
+provide additional information about a set of items, for example the license, provider information 
+and optionally any common information shared across all items using the [Commons extension](../extensions/commons/),
+giving context on the overall set of data that an individual Item is a part of.
 
 
 ### Asset Object
@@ -134,8 +134,8 @@ or streamed. It is allowed to add additional fields.
 
 The following types are commonly for assets and are used as key for the Asset Object:
 
-| Type      | Description                                                                                                                                                                                                                                                                                                                                                                                                                                        |
-| --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Type      | Description |
+| --------- | ----------- |
 | thumbnail | STRONGLY RECOMMENDED. A downsampled image of the core asset, for direct display online in a web page or interactive search application. Even assets that are less easily translated in to a visual image should provide some visual representation, that users can browse. For example a SAR asset can render an elevation mask or hillshade for display. If at all possible it should be included for a better user experience in searching data. |
 
 #### Media Types
@@ -160,7 +160,7 @@ Common STAC Item Media Types:
 | `image/jp2`                      | JPEG 2000                                                                               |
 | `image/png`                      | Visual PNGs (e.g. thumbnails)                                                           |
 | `image/jpeg`                     | Visual JPEGs (e.g. thumbnails, oblique)                                                 |
-| `text/xml` or `application/xml`  | XML metadata [RFC 7303](https://www.ietf.org/rfc/rfc7303.txt)                                                                          |
+| `text/xml` or `application/xml`  | XML metadata [RFC 7303](https://www.ietf.org/rfc/rfc7303.txt)                           |
 | `application/json`               | JSON metadata                                                                           |
 | `text/plain`                     | Plain text metadata                                                                     |
 | `application/geo+json`           | GeoJSON                                                                                 |