crkn-rcdr / iiif-presentation-api

A Simple Fastify IIIF Presentation REST API with PostgreSQL and added manifest management endpoints.
0 stars 0 forks source link

Edit in Access: Bulk label/description set #5

Closed RussellMcOrmond closed 9 months ago

RussellMcOrmond commented 1 year ago

There are a few fields that can be set in individual records that would be appropriate to be able to set in bulk.

IIIF Labels and Descriptions can also have languages associated with them beyond "none".

We would design a simple CSV format that would allow staff to make bulk changes based on a slug or noid column.

This is an alternative to crkn-rcdr/Access-Platform#594 . If we remove the "label" field from being set by the metadata loader, then we don't need to worry about having setting the label be an option rather than always done. The default for the back-end service for metadata loading would be to check if there is an existing label, and only set it if it didn't already exist ("none" for language, using the first dc:title or 245$a - see: https://github.com/crkn-rcdr/cihm-metadatabus/issues/73 )

Once this is completed, we can remove the label field from the Descriptive Metadata loader. This column was added as a convenience primarily for Issueinfo since the old CAP metadata model used partial labels. (See: https://github.com/crkn-rcdr/cap/issues/138 ).

The "label" and "objid" columns have generated confusion.

Suggestion for optional columns:

One of "slug" or "noid" is mandatory, to know which document a row is intended to modify. Multiple label:{language} columns, including repeats of the same language, should be supported (these are arrays in IIIF).

If there is a desire to set other values, such as "description", that can be added to the csv format.

The old csv files used for "Load Metadata" can be used with the new separated tool, simply by changing the "objid" heading to "slug", and by removing all the other columns other than "slug" and "label".

RussellMcOrmond commented 1 year ago

CRKN will have to decide if we continue to use the existing web framework CRKN has been using for tools which interact with the Storage Service.

I suspect the types of activities we will want to do (IE: bulk label/description setting) will be common for others in the GLAM community as well, so writing as a Manifest Editor plug-in https://github.com/digirati-co-uk/iiif-manifest-editor/issues/149 would be better.

If this is part of the Digirati editor, some resolver service will be needed to translate a column of slugs to a column of NOIDs that staff can put into their CSV files.