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

More rel types #884

Merged
merged 3 commits into from
Dec 11, 2020
Merged

More rel types #884

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
4988a40
Merge pull request #868 from radiantearth/dev
m-mohr Jul 8, 2020
b99e992
Added via and canonical rel types
cholmes Aug 20, 2020
560c352
Update CHANGELOG.md
cholmes Aug 20, 2020
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
1 change: 1 addition & 0 deletions CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,6 +7,7 @@ and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.
## [Unreleased]

### Added
- 'via' and 'canonical' rel types as options in items.

### Changed

Expand Down
2 changes: 2 additions & 0 deletions item-spec/item-spec.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -134,6 +134,8 @@ The following types are commonly used as `rel` types in the Link Object of an It
| collection | STRONGLY RECOMMENDED. URL to a [Collection](../collection-spec/README.md). *Absolute* URLs should be used whenever possible. The referenced Collection is STRONGLY RECOMMENDED to implement the same STAC version as the Item. |
| derived_from | URL to a STAC Item that was used as input data in the creation of this Item. |
| alternate | It is recommended that STAC Items are also available as HTML, and should use this rel with `"type" : "text/html"` to tell clients where they can get a version of the Item to view in a browser. See [STAC on the Web in Best Practices](../best-practices.md#stac-on-the-web) for more information. |
| canonical | The URL of the [canonical](https://en.wikipedia.org/wiki/Canonical_link_element) version of the Item. API responses and copies of catalogs should use this to inform users that they are direct copy of another STAC Item, using the canonical rel to refer back to the primary location. |
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we also add this rel type to Collections and/or Catalogs? Seems to apply there, too.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I had that thought a couple hours after submitting this. I'll add it.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cholmes I think this is a los hanging fruit for merging, but it need the final additions to the Collections/Catalogs.

I'm wondering whether we should make a general list of useful relation types that we could link to from the other specs... It seems not so good to duplicate too much content...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I've been trying to just focus on the API, to get that out, so have been neglecting all the STAC Core stuff. Agree it's low hanging fruit, I'll put it at the top of my list.

And yeah, a general list of rel types would be good. Not sure where to put it though... I guess maybe just in Item and the others can refer to it?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe common-rel-types.md, like we have common-metadata.md? Then we could put all relation types with descriptions and their scope in there, even the ones likely to be seen in APIs to make implementers aware of them. Overall it would also make the individual specs a bit more lightweight. I guess we could also centralize the common media types due to the fact we have now extensions (collection and item assets) referring to them, and it can also be useful for links.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good. I like the idea of common media types as well, since type is often used in conjunction with the rel in a link.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like common rel types as well.

Annoying thing though about our "derived_from" link though...the convention for rel types is to use "-" instead of "_"....
We should probably change it so it's not an exception.

| via | The URL of the metadata that this STAC Item is created from. Used similarly to canonical, but refers back to a non-STAC record (Landsat MTL, Sentinel tileInfo.json, etc) |

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).

Expand Down