Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Assign specific media types to relation types #1259

Merged
merged 7 commits into from
May 15, 2024
Merged

Assign specific media types to relation types #1259

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
47f8e2d
Clarified which media types should be used for the hierarchical relat…
m-mohr Oct 5, 2023
6c92e40
Apply suggestions from code review
m-mohr Oct 9, 2023
3ea38b2
tables formatted
emmanuelmathot Nov 9, 2023
2342cf7
Merge remote-tracking branch 'origin/dev' into rel-media-types
emmanuelmathot Nov 9, 2023
80b75c9
Add notes about OGC APIs
m-mohr May 14, 2024
b07cd6a
Fix CI
m-mohr May 14, 2024
9d8c00b
Update item-spec/item-spec.md
m-mohr May 15, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 1 addition & 3 deletions CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -25,10 +25,8 @@ and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.
### Fixed

- Several typos and minor language changes

### Fixed

- Clarified that collection IDs should be unique across all collections in the corresponding root catalog.
- Clarified which media types should be used for the hierarchical relation types

## [v1.0.0] - 2021-05-25

Expand Down
14 changes: 7 additions & 7 deletions catalog-spec/catalog-spec.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -85,13 +85,13 @@ For a full discussion of the situations where relative and absolute links are re

The following types are commonly used as `rel` types in the Link Object of a STAC Catalog:

| Type | Description |
| ------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| self | STRONGLY RECOMMENDED. *Absolute* URL to the location that the Catalog 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 | STRONGLY RECOMMENDED. URL to the root STAC Catalog or [Collection](../collection-spec/README.md). Catalogs 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 Catalogs should include a link to their parent. |
| child | URL to a child STAC entity (Catalog or Collection). |
| item | URL to a STAC Item. |
| Type | Description | Media Type |
| ------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------ |
| self | STRONGLY RECOMMENDED. *Absolute* URL to the location that the Catalog 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. | application/json |
| root | STRONGLY RECOMMENDED. URL to the root STAC Catalog or [Collection](../collection-spec/README.md). Catalogs should include a link to their root, even if it's the root and points to itself. | application/json |
| parent | URL to the parent STAC entity (Catalog or Collection). Non-root Catalogs should include a link to their parent. | application/json |
| child | URL to a child STAC entity (Catalog or Collection). | application/json |
| item | URL to a STAC Item. | application/geo+json (preferred) or application/json |

**Note:** A link to at least one `item` or `child` (Catalog or Collection) is **RECOMMENDED**, but empty catalogs are
allowed if there is an intent to populate it or its children were removed.
Expand Down
18 changes: 9 additions & 9 deletions collection-spec/collection-spec.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -259,15 +259,15 @@ It is recommended to use the official
The following table explains places where custom STAC `rel` types are used for Collections.
This is done where there is not a clear official option, or where STAC uses an official type but adds additional meaning for the STAC context.

| Type | Description |
| ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| 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 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. |
| Type | Description | Media Type |
| ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------ |
| 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. | application/json |
| 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. | application/json |
| parent | URL to the parent STAC entity (Catalog or Collection). Non-root Collections should include a link to their parent. | application/json |
| child | URL to a child STAC entity (Catalog or Collection). | application/json |
| 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). | application/geo+json (preferred) or application/json |
| 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. | Any |
| 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. | application/json |

A more complete list of possible `rel` types and their meaning in STAC can be found in the
[Using Relation Types](../best-practices.md#using-relation-types) best practice.
Expand Down
14 changes: 7 additions & 7 deletions item-spec/item-spec.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -190,13 +190,13 @@ It is recommended to use the official
The following table explains places where STAC use custom `rel` types are used with Items.
This happens where there is not a clear official option, or where STAC uses an official type but adds additional meaning for the STAC context.

| Type | Description |
| ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| self | STRONGLY RECOMMENDED. *Absolute* URL to the Item if it is available at a public URL. 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). |
| parent | URL to the parent STAC entity (Catalog or Collection). |
| collection | STRONGLY RECOMMENDED. URL to a Collection. *Absolute* URLs should be used whenever possible. The referenced Collection is STRONGLY RECOMMENDED to implement the same STAC version as the Item. A link with this `rel` type is *required* if the `collection` field in properties is present. |
| derived_from | URL to a STAC Item that was used as input data in the creation of this Item. |
| Type | Description | |
| ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------ |
| self | STRONGLY RECOMMENDED. *Absolute* URL to the Item if it is available at a public URL. 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. | application/geo+json (preferred) or application/json |
| root | URL to the root STAC entity (Catalog or Collection). | application/json |
| parent | URL to the parent STAC entity (Catalog or Collection). | application/json |
| collection | STRONGLY RECOMMENDED. URL to a Collection. *Absolute* URLs should be used whenever possible. The referenced Collection is STRONGLY RECOMMENDED to implement the same STAC version as the Item. A link with this `rel` type is *required* if the `collection` field in properties is present. | application/json |
| derived_from | URL to a STAC Item that was used as input data in the creation of this Item. | application/geo+json (preferred) or application/json |

A more complete list of potential `rel` types and their meaning in STAC can be found in the [Using Relation
Types](../best-practices.md#using-relation-types) best practice.
Expand Down