SAEON / odp-server

Source code for the SAEON Open Data Platform server components.
GNU Affero General Public License v3.0
0 stars 2 forks source link

Request for human readable collection keys #1

Closed zachsa closed 1 year ago

zachsa commented 1 year ago

Hi @marksparkza.

When I ingest ODP metadata into the Elasticsearch index, for a couple fields I get keys that are human readable, but not exactly human formatted. For example institution_key, collection_key, project_keys.

Now I'm using these values to create HTML keywords <meta name="keywords" content="... dynamically produced depending on the data list"/>.

I remember you mentioned that there is a plan to provide human readable versions of this. Does this exist yet?

marksparkza commented 1 year ago

Hi @zachsa,

The short answer is no, but there is work in the pipeline (to be done in the near future) which will make info such as abbreviations and names of collections, projects, etc, available for published metadata.

The exact structure of published records and API lookup functions is still to be finalized, but it's something we can experiment with when we get onto integrating the catalogue with the ODP v2 API.

marksparkza commented 1 year ago

What I have in mind is for you to be able to do a "one shot" lookup, i.e. in your import process, in the same way as you can harvest all published records from /api/catalog/SAEON/records, you'll be able to harvest all published collection info from /api/catalog/SAEON/collections. Published records will most likely link to published collection info with UUIDs. On the ODP side, an ODP publishing run (scheduled twice daily) will update published collection info at the same time as updating published metadata.

zachsa commented 1 year ago

Thanks - that will work

marksparkza commented 1 year ago

This has been done - the info is embedded in the catalog record output, rather than available via a separate API - much simpler all around.

For example, you'll get something like the following in a record dict:

      "collection_key": "Carbon-Sinks",
      "collection_name": "South African Carbon Sinks Atlas",
      "provider_key": "DFFE",
      "provider_name": "Department of Forestry, Fisheries and the Environment",

Collection and provider keys are configurable by curators.

Projects are now implemented as collection tags, so you can get something like the following appearing in the record:

      "tags": [
        {
          "tag_id": "Collection.Project",
          "data": {
            "project": "NCCIS"
          },
          "user_name": null,
          "timestamp": "2022-12-22T22:40:30.516618+02:00"
        }
      ],

(In the above case user_name is null because the tag was set by the v1 to v2 migration process.)