Integration of Variable Name Acronym Glossary from Airtable into STAC Browser

[ShrutiK100]

We currently retain a variable name acronym glossary in an Airtable format which provides definitions and explanations for various acronyms and terms used in STAC browser datasets. To enhance the usability and make this glossary easily accessible to the users, it would be beneficial to integrate the glossary directly into the STAC Browser interface although we find this challenging as adding or removing new datasets would not update the glossary items in Airtable. To make informed decisions, we would like to receive feedback or suggestions from the team regarding following key questions.

Current Airtable Glossary: https://airtable.com/appYNLuWqAgzLbhSq/shrgcENhJZU1y3ye0/tbleXPCaJeYeIzAhR

1. How can we best integrate the existing Airtable glossary into the STAC Browser?

   • Is there a preferred method or best practice within STAC for adding a glossary or similar reference material?
   • Should this glossary be incorporated as part of the STAC metadata or as a separate feature in the browser?

2. If a glossary mechanism already exists in STAC:

   • How can we link the existing Airtable glossary to this system?
   • What steps are needed to ensure that the glossary remains up-to-date as new datasets and variables are added to the collection?

3. Automation of Glossary Updates:

   • Would it be possible to implement an automated mechanism that ingests new variable names and acronyms into the glossary as they are added to Airtable or directly to the datasets?
   • What challenges or considerations should we be aware of when implementing such an automation process?

Desired Outcomes:

• User Experience:Users should be able to easily access definitions for variable names and acronyms directly within the STAC Browser, improving their ability to understand and work with the data.

• Maintenance: Ensure that the glossary remains current and accurate as new datasets are added, preferably with minimal manual intervention.

• Technical Feasibility: Explore whether existing STAC functionalities can be leveraged, or if new development is required to meet these goals.

[fmigneault]

The OGC API - Features - Part 1: Core (which STAC depends on) provides the /collections/{collectionId}/queryables endpoint (see requirements and examples can be found under https://docs.ogc.org/is/19-079r2/19-079r2.html#queryables). This endpoint can be employed to detail what are the supported variables (ie: the cmip6:<variable> properties, or any other STAC extension property for that matter), including the title, description, and anything else fitting JSON schema definitions, such as type, format, enum of allowed values, etc.

Furthermore, the OGC API - Features - Part 5: Schemas additional keywords (https://docs.ogc.org/DRAFTS/23-058r1.html#additional-keywords) (again schema and examples under the link), can be used to further extend the details returned by queryables, such as unit of measure, roles of the variables, and other relevant references or metadata

All of the above are defined on a per-STAC-Collection basis, since each collection can contain different data contents and structures. However, using STAC Collection's Summaries functionality, which are also relying on the properties containing the variables of interest, the variables details could be agglomerated across collections and items. This is a core functionality of STAC. Therefore, adding/removing collections should automatically update returned summaries/properties with latest definitions available to users. This could be used to maintain the mentioned glossary, without need to modify existing implementations. The only requirement is that published collection provide the relevant summaries/properties in their definition to allow discovering them.

When definitions are combined with /collections/{collectionId}/queryables, they become automatically searchable using filter (as defined by OGC API - Features - Part 3: Filtering (CQL2), https://docs.ogc.org/is/19-079r2/19-079r2.html). Therefore, using previously mentioned capabilities would be the most optimal way to describe variables and make them accessible with any client (whether by API or custom UI).