Metadata issue in FIN-CLARIN provided by CLARINO Bergen: national project

[twagoo]

A metadata issue has been identified by Martin Matthiesen on 2024-08-24:

• Metadata provider: FIN-CLARIN
• Context: FIN-CLARIN records provided by CLARINO Bergen (superset)
• Location: https://vlo.clarin.eu/record/urn_58_nbn_58_fi_58_lb-2021101523 (example)

Desciption of the issue:

TL;DR: FIN-CLARIN metadata is listed with "CLARINO" as national project.

Martin reports:

we reviewed the VLO representation of our metadata[1] today and we have a few rather urgent change requests (in order of importance):

1) Change "National Project" to FIN-CLARIN This is the first time (I think) that an OAI-Provider is not 1:1 mappable to a national project. However FIN-CLARIN's metadata should be marked as such, Norway is not responsible for it. Could you please change the National Prover to "FIN-CLARIN"? You can use the "setSpec" field in the OAI-PMH-data[2]. (..)

[2] https://clarino.uib.no/oai?verb=ListRecords&MetadataPrefix=cmdi&set=FIN-CLARIN

Suggested solution [optional]:

Harvest CLARINO twice as two separate providers with different sets specified. There may be several caveats.

Before doing so we should check if there is an existing mechanism in the VLO to set (override) the national project based on other properties such as collection display name.

[twagoo]

Findings from a quick experiment:

• Harvesting "both" endpoints separately works if we define them explicitly as providers in the harvester configuration with separate names and a list of sets to include (there is no way to exclude). One of the endpoint URLs gets an extra forward slash after the domain.
• We could leave CLARINO (with sets) in the centre registry and only define FIN-CLARIN as an 'external' endpoint
• This approach will lead to no mapping to national project for FIN-CLARIN
• Menzo will include a change in the harvester that will allow overriding of the name of an endpoint (used to name the directory) defined in the centre registry. This will give us the exact solution that we want – we can define both endpoint variants separately in the centre registry. The only requirement for this solution is that we have a finite list of sets to harvest for both variants.