More rel types #884
More rel types #884
Conversation
| @@ -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. | | |||
There was a problem hiding this comment.
Should we also add this rel type to Collections and/or Catalogs? Seems to apply there, too.
There was a problem hiding this comment.
Yeah, I had that thought a couple hours after submitting this. I'll add it.
There was a problem hiding this comment.
@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...
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
|
Is there also a re type to link back to the original data? I understand that there is via for original metadata, but how to refer to the original data? Also, I'm wondering a bit how exactly derived_from is meant to be used. In which use case is that actually useful? Until now, I thought it's used to link back to the original data. |
|
I haven't heard of a rel type to link to the original data, though perhaps there's one in use. Though wouldn't the asset generally link to the 'original data'? The 'derived_from' is used to link to original data, like when there is processing done. So like an NDVI asset or a mosaic would use derived from to link to the STAC Item that has the data it came from. |
|
Maybe we have a different understanding... my example is: Sentinel 1 GRD (original data) => process it to NRB => Sentinel 1 NRB We want to publish NRB and link to the GRD data we have derived the NRB from, but there's no STAC Item for it (I think). Not sure which rel types to use. Maybe we should also clarify the rel types in general, for me it's not 100% clear what they should be used for. |
|
I use "derived_from"* to represent the STAC Item that this STAC Item was derived from. So for the Sentinel-2 COGs this is the Sentinel-2 L2A Item (which I also indexed) that was used to create the COGs. See as example for both "derived_from" and "canonical". |
Related Issue(s): #882
Proposed Changes:
PR Checklist: