Clarification on linking Items

[JorisCod]

In the readme, "Linking the Items"

Describes:

In Items that declare this processing extension, it is recommended to add one or more Links with derived_from or via relationships to the eventual source metadata & data used in the processing. They could be used to trace back the processing history of the dataset.

However, it would be clearer to state that via refers to metadata and derived_from to data:

.. with derived_from or via relationships to the eventual source data and metadata used in the processing, respectively. ...

Additionally, is derived_from reserved for references to STAC items or not?

In the best practices, it is stated:

URL to a STAC Entity that was used as input data in the creation of this Entity.

If it is only to a STAC entity, what is the recommended way for non-STAC data instead?

[emmanuelmathot]

Thank you for the clarification request.
I agree for the via and derived_from clarifications. Feel free to open a PR.

Regarding best practises, this is a discrepancy that should be solved there. I would be in favor to accept other than STAC items in derived_from. It is already the case in many catalogs implementation.

@m-mohr WDYT?

[m-mohr]

This is indeed a bit unclear. @emmanuelmathot @JorisCod

My understanding is the following:

• via is for simple conversion between metadata formats (e.g. ISO 19115 to STAC), but the data that both metadata files describe is the same
• derived_from is for pointing to metadata that this data was derived from after processing (e.g. L2 STAC pointing to L1 STAC).

STAC obviously in its best practices(!) recommendes to point back to STAC entities, that's the best practice. But the relation types are taken from the IANA relation type lists so apply generally. So you can indeed point back to other metadata and distinguish them through the media type:

• application/geo+json => STAC Item
• application/json => STAC Catalog/Collection - this conflicts with other JSON metadata though, especially e.g. in the STAC Browser implementation. For the sake of avoiding this conflict, I'd do something like application/json; profile=my-other-metadata-standard or so.
• any other media type (e.g. application/xml) => other metadata (e.g. XML)