Closed m-mohr closed 2 months ago
Decisions from STAC Sprint
other
to replace proprietary
proprietary
and various
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.
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.
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
@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.
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 ;-)
Shall we close this? @emmanuelmathot
I agree. I created a new issue for the required title in 2.0.
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
proprietary
orvarious
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
Anything we can do to allow an easier mapping between the two? Generally the mapping is doable, except if "date only" is used:
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?