Separate media type for STAC?

[m-mohr]

Do we need a way to distinguish links to STAC and OGC API - Records somehow?

A link to a STAC JSON file with relation type child looks exactly like a link to OGC API - Records, although they are not fully compatible. They both would look as follows:

{
  "href": "./catalog.json",
  "rel": "child",
  "type": "application/json"
}

I could see a world where STAC and Record JSON files will be mixed in one catalog (actually, I'm currently working on a project that would benefit from it).

The only way I could distinguish them right now consistently, is probably to load the files and check whether stac_version is present (STAC) or not (=> likely Records, but could also be something else).

Thoughts?

Records is adding explicit media types: https://github.com/opengeospatial/ogcapi-records/issues/276 Should we also add explicit media types that could be used? application/stac+json?

[gadomski]

How would this work for Items, which are currently application/geo+json? Changing that type (which is auto-detected by tooling e.g. for display) would remove functionality we currently get for free.

[m-mohr]

Not sure, the same applies for Records. We can also all live under the the same media type, but then you may not know whether you actually get a STAC or not. You may also only use it if it's mixed content. Maybe this really is just an optional addition in case you start to mix things? Not sure. I really just raised it in both specs to discuss and collect thoughts.

[m-mohr]

Maybe the better way is application/geo+json; application=stac-item and application/json; application=stac-collection etc? That at least keeps the main media type (although I'm sure many implementations don't parse media types and only compare strings for equallity).

[gadomski]

(although I'm sure many implementations don't parse media types and only compare strings for equallity). [sic]

Yeah this is a downside, I usually just see == in tooling when checking media types.

One benefit of application/json; application=stac-collection is you can actually know (probably) whether you're getting a collection or catalog when you're resolving a child.

[PowerChell]

We want to have a discussion about this so we can close and have some sort of clear statement regarding our stance on this.

[matthewhanson]

Should mention somewhere (best practices) that if you mix OGC API Records and STAC that clients cannot tell from the type alone if the target is a STAC Item or an OGC Record.

[matthewhanson]

Not sure where this left off in the sprint. can we arbitrarily and legitimately add a profile to a media type, e.g., application=stac-collection ?

[m-mohr]

I think we concluded that media types are difficult to extend for us. Maybe Records gets a separate media type or we just use an additional field to indicate it? Ultimately, you'd not need it anway if STAC is a profile of Records....

[fmigneault]

Explicit types for STAC would be amazing! Currently, many processes return application/geo+json without distinction. For backward compatibility of servers expecting and already supporting this type, I believe application/geo+json; application=stac-item and application/json; application=stac-collection are more appropriate than application/stac+json.

[m-mohr]

Changing the media type in 1.1 is likely breaking in a lot of implementations, as such we need to to this in 2.0.

Here's a related discussion on the do and don'ts: https://github.com/opengeospatial/ogc-feat-geo-json/issues/129