OGC API - Records alignment (license/title/datetime/type)

[m-mohr]

I'm currently working on a crosswalk between OGC API - Records and STAC and how their "data structures" (i.e. the JSON representations of Items, Catalogs, Collections) can be better aligned.

While I've also opened a couple of issues in Records for this purpose, I think there are also a couple of links STAC could work on:

title

title is required in Records for Collections and Items. Having titles in the resources and also in the links makes the browsing experience much nicer (see STAC Browser). Titles in Catalogs/Collections and their corresponding links should be aligned anyway. So I'm wondering whether we should require the title field in Catalogs and/or Collections and/or Items. Collections should always have a title, I think. It would also be good for Catalogs to explicitly choose a title and people use the id as title pretty often aynway. For Items real titles are often not available (e.g. for satellite captures), but anyway a default title provided by the provider would be good for UX.

license

• STAC: SPDX identifier or proprietary or various
• OAR1: SPDX identifier, SPDX expression, other or anything(?)

Due to the divergence and the cirticism we heard a couple of times about "proprietary" for "open licenses that are non-SPDX", I'd propose to add "other" to the list of allowed values in STAC. At the same time we could also deprecate "proprietary" and/or "various"

datetime

• STAC: datetime / stac_datetime / end_datetime (in properties)
• Records time with various sub-schemas (top-level)

Anything we can do to allow an easier mapping between the two? Generally the mapping is doable, except if "date only" is used:

• Single instance (date + time or date only)
• Interval (date + time or date only)
• Both (single instance and interval)

How do we map if only a date is present?

type

In the "item properties", OAR has a required free-form string type field (max length: 64). Would this something of interest to us? For example, to distinguish between ml-models and imagery in Radiant ML Hub?

[m-mohr]

Crosswalk/Status: https://github.com/stac-utils/stac-crosswalks/blob/master/ogcapi-records/README.md

[matthewhanson]

Decisions from STAC Sprint

title

• Having title for Collections is nice, but requiring would be a breaking change
• Having title for Items we think should not be required and want to lobby for OAR1 to remove the requirement

license

• Adopt other to replace proprietary
• deprecate proprietary and various
• Allow SPDX expressions (currently SPDX licenses aren't actually validated in STAC)

datetime

• No change in STAC

type

• No change in STAC

One option to promote/validate compatibility is to create an "OGC API Records Compatibility" extension which would, for example, make title and type required under properties.

[matthewhanson]

The license issue has been merged, the only unresolved piece of this ticket is that we want to lobby for OAR1 to remove the requirement of a title on Collections.
Leaving this open until @m-mohr weighs in on if an issue has been opened for OAR on this.

[m-mohr]

Can't remember whether I opened an issue, but I think I mentioned in a meeting and they were not overly convinced. Maybe it's good if someone else actually lobbies for it so that it's not just me who asks for it... @matthewhanson

[emmanuelmathot]

@m-mohr @matthewhanson What are the arguments to make title an option in collections. I may write the ticket in https://github.com/opengeospatial/ogcapi-common but I need to justify it.

[m-mohr]

I'm personally for requiring title and description, because it makes for a better user experience.
But OGC itself is pretty undecided if you ask WGs about title and description. Some groups (e.g. Features, I think) say both shouldn't be required because otherwise people just put nonsense titles if they don't have any meaningful titles.
And then there's STAC requiring description and OAR requiring title, which are rather random choices, I think. I feel that sometimes it's a little easier to fill a description because in the worst case you could just also put a title into the description, but you'd usually not put a description into a title ;-)