Specify mechanism for non-spatial data to be referenced in Catalogs

[cholmes]

So I firmly believe that a compliant STAC Catalog should consist of SpatioTemporal Items, as tooling should be able to expect that all data in the catalog would have space in time.

But there are a growing number of people who like the STAC concept a lot, but not all their data is spatial and temporal.

In line with our philosophy of being easy to extend (put your own properties into a STAC Item), I think we should say that a compliant STAC catalog can include links to non-STAC 'stuff'. A validator should validate that all the STAC specified links in the catalog (item, child, root, etc) are valid, but should ignore (and not fail) on other link types. Perhaps a validator could run in a mode that verifies that everything linked to is STAC compliant.

But I think we should support 'mixed catalogs', that have some STAC Items, and some other 'item type json' that people can use as they want. Eventually, there might be a 'meta-spec' that specifies more generic asset catalogs that aren't spatiotemporal.

If people agree with this we should add a bit of language explaining in the Catalog spec that people can use other link types. I think I'd reserve the rel 'item' to mean a STAC item, but someone could do a link with rel = 'special_item' for their own stuff.

See #366 for some more discussion.

[m-mohr]

Non-STAC Items could still use the rel-type item, but are required to specify another (media) type. We basically imply it is application/geo+json by default if not set. So if anybody else wants to specify something different: Go ahead, just don't use the GeoJSON media type. Validators should anyway not try to validate items if the type is not set to application/geo+json (or is empty), because it is suspicious. ;-) I doubt the implementations do check this, but I think they should.

If we really want to specify a JSON structure for non-Geo/Time items then it should basically be just id, properties, links and assests as specified in the Item spec. The type would be just application/json and then you can put whatever you like (and extensions specify) in the properties.

IMHO that's not much work, is easy to specify, seems flexible enough and just fits perfectly into our current specification. Other thoughts?

[cholmes]

Awesome, thanks for the specific ideas - they all sound great.

…

On Sun, Dec 30, 2018, 10:52 AM Matthias Mohr ***@***.*** wrote: Non-STAC Items could still use the rel-type item, but are required to specify another (media) type. We basically imply it is application/geo+json by default if not set. So if anybody else wants to specify something different: Go ahead, just don't use the GeoJSON media type. Validators should anyway not try to validate items if the type is not set to application/geo+json (or is empty), because it is suspicious. ;-) I doubt the implementations do check this, but I think they should. If we really want to specify a JSON structure for non-Geo/Time items then it should basically be just id, properties, links and assests as specified in the Item spec. The type would be just application/json and then you can put whatever you like (and extensions specify) in the properties. IMHO that's not much work, easy to specify and just fits perfectly into out current specification. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#367 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAY16XurLqzJM8fp_alTZ-ACMH_7Kvrfks5u-O9bgaJpZM4ZkSkg> .

[cholmes]

Discussed on the call on April 22, agreed that more thought and input is needed.

Ideally those who have this use case sound in. And even more ideally we have a sample catalog with non-spatial data that we can look at.

cc @hgs-msmith

[cholmes]

Closing this, can re-open when we have an example catalog to look at, and decide what changes we need to the core spec to enable good validation while allowing these non-spatial mixed catalogs.