updated rel descriptions, moved info to best practice #951
Conversation
| @@ -133,11 +137,11 @@ The following types are commonly used as `rel` types in the Link Object of an It | |||
| | parent | URL to the parent STAC [Catalog](../catalog-spec/README.md) or [Collection](../collection-spec/README.md). | | |||
| | 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. | | |||
There was a problem hiding this comment.
Should we move the whole derived_from part also to best practices? I think it would make sense.
|
I went back and forth in my head on derived_from:
But I see the argument as to why it feels less mature than the others. I think in my ideal world it eventually drops away in favor of a real 'provenance' extension, that is based on some other 'real' provenance work, instead of us just making stuff up. But I do feel it's really important to emphasize in STAC, in the core specs, that marking where something has come from is essential. So to me it's a case of not letting 'great' be the enemy of good, so I think overall I prefer it in the core spec, vs burying it in a new extension. I could potentially be convinced otherwise, but I don't think we should introduce new rels in a best practice. |
|
Good arguments, I'm convinced to leave it as it is for now. Thanks! |
|
Cool, thanks for your review and bringing it up. |
Related Issue(s): #929
Proposed Changes:
PR Checklist: