Relationship between STAC and OAPIR

[pvretano]

SWG MEETING 14-DEC-2020: The purpose of this issue is to capture use cases or stories about the relationship between STAC and OAPIR. Ostensibly the idea is that STAC would be a profile of OAPIR but I have seen cases where STAC is being used in other contexts and so I want to capture those.
If you have any thoughts about this, please add them here.

[cnreediii]

Oh No - Another acronym :-)

[tomkralidis]

As discussed earlier today, MSC usage perspectives:

• STAC as a value added Web Accessible Folder atop file directory trees: We disseminate much of our real-time data via both AMQP and HTTP (WAF). Putting STAC atop the WAF will provide value-added traversal/browsing, including HTML/maps with footprints/etc.)
• OARec for discovery / product collection, STAC for product: Using our global 15km weather model as an example, we would have "discovery" level metadata at the OARec level, with associations to STAC collection of files (as well as other APIs, etc.)

[pvretano]

05APR2021: @cnreediii will create an issue in the OAB to discuss the relationship between STAC and OAPIR ... since right now, the relationship is not clear.

[pvretano]

19-APR-2021: Clemens proposed that one approach here would be to invite Chris and @m-mohr to a meeting to discuss the relationship between OAPIR and STAC.

[m-mohr]

I'm happy to join a discussion but may need to dive a bit more into the current state of Records first. :-)

[kalxas]

cc @cholmes

[mhogeweg]

I have a geoportal that indexes images from a number of STAC sources. This catalog itself also implements an output of the search results in STAC format (work in progress), while at the same time also providing CSW on the same catalog.

point I'm trying to make is that once in a catalog, there's not a lot of issues supporting either/both STAC/CSW.

we have also implemented harvesting STAC sources, following a same approach as we use for harvesting CSW, web accessible folders, etc. Again, a lot of similarities.

[cnreediii]

So, by extension the same could be said for using OAPIR - once metadata records are in some catalog, there could well be numerous mechanisms for discovery and access to that catalog (or catalogs)? Thanks

[tomkralidis]

SWG 2021-06-17:

• @fhoubie matter of communication, exchange point of view, converging, need to find relationships
  • OARec: query descriptions
  • STAC: "extension" of OARec given specific set of domains (EO)
• @tomkralidis: OARec first order search, STAC lower level granule/search
• @cholmes: STAC gets asked for collection level search (use OARec)
• @fhoubie: feature and record models are similar, different information communities may have different profiles (e.g. DGIWG)
• @cholmes: fitting Landsat metadata into ISO might be cumbersome
  • https://github.com/cholmes/ogc-collection
• @pvretano: need to query anything (not everything is a collection), not sure how many will deploy a vanilla/core (i.e. federation)
• @cholmes: lock down dataset search, STAC can also use that, be explicit about Records building on features
• @tomkralidis: add verbage on granularity/how to apply
• @cportele: move sortby/q to Features, then records just uses that and use content/queryables
• @pvretano: common parameters can be attached to many endpoints

Need to continue discussion to further clarify. Propose next SWG (2021-06-28)

[kalxas]

I will give it a try to sort things out from the last 10 mins of the meeting :)
I think we all agree in the following:

• OARec extends OAFeat with bbox=, q=, some queryables and a small record model (avoids to define something heavy like a dataset record e.g. based on ISO-19115)
• STAC also extends OAFeat with definition of collections, items (and assets).
• Both use Feature as a base.
• Ideally both OARec and STAC should align with the OAFeat API (see sort, CQL etc).

What is not yet clear is the following:
Is STAC Collection a record or is STAC Item a record within a catalogue?
My personal opinion is that BOTH are potential records and there is nothing to prevent that.

Example:
Someone can easily define one record for the entire Sentinel2 collection and add a link to the STAC catalogue in the record associations.
Someone else can define each Sentinel2 scene as a record by using STAC Item in place of the simple record model of OARec.
Both cases are valid in my opinion and can and will happen :)

My proposal:
Lets define two record types within an OARec extension: a "stac collection" record type and a "stac item" record type. This way we offer two solutions:

• Those who want 100% compatibility with STAC they can register their STAC Catalogue as a record in OARec
• Those who want 100% compatibility with OARec can reuse the representation of STAC Item as a record.

We should then focus to align OARec and STAC APIs as much as possible with OAFeat API and perhaps merge in the future.

[mhogeweg]

apart form the focus on dataset vs granule, there really is not a lot of difference between OARec and STAC catalogs. We have worked for years with agencies that have this 2-level search challenge where they have created full ISO records for individual granules and implemented catalogs for both using CSW.

The backend to the catalogs we develop can handle both. In the same catalog even. This example:

• images harvested from various STACs over an area
• the same results as a csw:GetRecordsResponse
• the same results as a STAC

[tomkralidis]

Exactly @mhogeweg. There's nothing preventing OARec to serve out a collection of images, or anything for that matter. What's critical here is how this ends up getting implemented the wild (just because someone shouldn't doesn't mean they won't). I wonder if we could have a guidance section in the spec somewhere (after we kick the tires between OARec/STAC use cases).

[cholmes]

Lets define two record types within an OARec extension: a "stac collection" record type and a "stac item" record type. This way we offer two solutions:

That mostly makes sense to me. But I do think it'd be more valuable to define the record type that sits 'above' STAC Collection. Our collection is designed to be 100% compatible with OGC 'Collection' as defined by features api & common. I'd much prefer to focus on that more common 'collection', and just say that STAC is a particular instance of that. Defining that feels to me like the big missing piece.

I think most of our first catalogs will be records of those OGC Collections, I see it as the 'dataset' record that we talked about on the call. To me that was the key part of our agreement on the call - actually define the dataset record, as that's what 'most' people expect when they come to OARec, but then many appreciate that it's not limited to those.

I can take a stab at fleshing it out, I think it's close to what I was experimenting with in https://github.com/cholmes/ogc-collection I see it as pretty much the same fields in the core record, but I'd like to make more of them 'required'. In STAC Collection we require more, and I think it makes sense for something as a dataset to require more than just type.

[tomkralidis]

SWG 2021-06-28: some mid/tail-end discussion. The basic idea here is to break out the OARec collections model as well as the record model into separate building blocks, so that a given user can cast collection level or record level metadata as static files, without an OARec API per se.

I haven't reviewed @cholmes' proposal in detail, but I like the approach of loose coupling. In addition, it dovetails with ideas we have for the WMO Information System 2.0 for users to publish metadata via either static files or APIs.

[cholmes]

Apologies for missing the discussion today. I made a bit more progress in proposing a 'dataset record' building block. Basically just a higher number of required fields on top of the core 'record'. I think it might be valuable to have some defaults in it, for things like language and vocabulary / theme type stuff.

The other core idea that I didn't yet fully flesh out is to define the 'OGC Dataset Collection' JSON, which would just be the Collection JSON that OGC API Features uses (and that STAC extends) with the same required fields as the 'Dataset Record' GeoJSON. And then clearly define the mapping to it.

[pvretano]

09-AUG-2021: There has been considerable clarity introduced in recent weeks on the relationship between STAC and OAPI.
However, lets leave this issue open for now. At the next TC there will be a Metadata & Search session where we can discuss the relationship a bit more especially in light of the recent updates to the spec. After that we can come up with some shared wording between STAC and OAPIR and then close this issue.

[uvoges]

I was thinking about the naming "Static Catalogue": I guess what is static is the structure of the catalogue not the content. So it is a fixed organization of the records along one or more parameters. E.g. if it organized along the themes with values "wind" and "water" you can access all records having assigned either the theme "wind" or records having assigned the theme "water" but not all records having assigned a theme which value is starting with "w". For the latter you need the dynamic API.
So it may be renamed in something like: (“Pre”)”Arranged”, “Fixed” or “Designed” Catalogue… ?

[pvretano]

07-FEB-2022: We need to put this item on the agenda for the upcoming member meeting and maybe have @cholmes gives us a presentation about how the STAC group sees OAPIR, the other OGC API and STAC relating. Is STAC a profile of records? Features? etc. Might need to get in touch with @ghobona to coordinate this topic with the STAC people.

[pvretano]

31-MAR-2023: This seems to be a duplicate of #178 so we are closing this one and discussion can continue in the related issue.