Map of fields in Catalogue API to fields/Metadata objects in IIIF Manifests

[tomcrane]

The business of mapping MARC to JSON shapes isn't the concern of the DDS any more, the Catalogue API worries about that. But we still need to then make sure the IIIF Manifest fields are correctly mapped from the Collection API.

This includes fields that are used to generate other fields - Repository logo, for example (a path to an image served by DDS), is deduced from the contents of 535a, which has the repository name.

[tomcrane]

In other words...

What descriptive metadata do you want accompanying your IIIF resources out there in the world?

Same as now? The DDS used to generate this from its own MARC mapping rules, but now it needs to map metadata provided by the Catalogue API - which will have already mapped MARC sensibly so it should be much more straightforward. But it's still a mapping of some sort that needs to be captured in code, and might not always be obvious. And could change (e.g., stop saying "Author(s)" and say "Contributors" for Henry Gillard Glindoni in the work above).

More generally, should the Manifest metadata look pretty much like the work page metadata? Same fields in the same order? https://wellcomecollection.org/works/nydjbrr7 In which case, the DDS should replicate the logic wc.org uses for the metadata.

TODO - a test page in the new DDS that dumps descriptive metadata for a given b number; we can use that to build up and test how we want to translate Catalogue API to what appears in the manifest independently of building the IIIF-delivery.

• [x] Given a b number, can I get descriptive catalogue metadata for the work? (#4471, but with questions)
• [x] Can I find the work identifier from the b number? (e.g, b14658197 => nydjbrr7) (yes, as above)
• [x] Given the descriptive metadata from the catalogue, and some additional metadata from METS (e.g., licenses, permissions), can I generate everything that is supposed to go in a Manifest?*
• [x] Given a b number, can I get a CALM ref (if it's an archive item)?
• [x] Given a b number or a CALM ref, can I navigate to parents/siblings/children in the Catalogue API? (What's in this Series?)
• [x] ...and can I see the b numbers of parents/siblings/children? - see #4671

* https://api.wellcomecollection.org/catalogue/v2/works/nydjbrr7?include=identifiers,items,subjects,genres,contributors,production,notes,collection

See also #4471

[tomcrane]

For the Spike phase of current work:

• build a simple Wellcome Catalogue API .NET Core client (but not directly from the Swagger)
• Keep up to date with the changes for archive items and reflect them in the client

This client just needs to demonstrate enough to tick the checkboxes above, without shaping the data into IIIF metadata, collections etc. See #4471 as well.

[tomcrane]

To avoid taking up too much time, we should have a first pass at this ourselves, then joint review. First pass aims to reproduce what we have now, with the possible exception of using "Contributor" to label the thing we label "Author". And obviously linking to the wc.org work page.

After our first attempt, review

• What do Wellcome Manifests look like in Mirador/UV/TIFY/etc?
• What to change, e.g., to align with the web page for the work

[tomcrane]

There are some notes about this here:

https://github.com/wellcomecollection/iiif-builder/blob/master/docs/Altering-IIIF.md

No doubt this will need to be tweaked, but we could move this to closed for its first pass.

[tomcrane]

From Slack discussion with @jtweed :

https://digirati.slack.com/archives/CBT40CMKQ/p1611746859116400

We should get rid of the switch in https://github.com/wellcomecollection/iiif-builder/blob/master/src/Wellcome.Dds/Wellcome.Dds.Repositories/Presentation/MetadataBuilder.cs#L21

...and union all the fields together - a consistent set. (It's OK because empty values are ignored).