RFC 091: Digitisation ingest identifiers during the Sierra to Folio migration

[kenoir]

Preview

View the rendered RFC on this branch (renders the Mermaid diagrams and tables):

• RFC 091 README

---

What does this change?

Publishes the digitisation-ingest discovery work as RFC 091. The RFC sets out how digitisation ingest identifiers should work across the Sierra to Folio LMS migration.

Today the Sierra b-number is the shared key for digitised content. It is the Goobi ingest package id, the storage externalIdentifier (digitised/<b-number>/vN), the METS work's own identity (mets/<b-number>), the merge candidate that joins the METS work onto the public catalogue work, and the IIIF manifest URI and DLCS asset ids. The migration removes the b-number, so the RFC explains why it cannot simply be swapped for a Folio id (doing so would reset storage versioning and silently break the merge join key, leaving digitised content invisible on the public record with no error), and proposes minting catalogue-style identifiers at ingest instead.

The proposal builds a small application for digital production staff that creates ingest package metadata from Folio, and splits behaviour on whether the Folio record carries a predecessor pointer to an old b-number:

• Cross-migration (predecessor present): reuse the old b-number as the storage handle and keep emitting the sierra-system-number merge candidate. This is the lower-risk path; it needs no transformer change and leans on RFC 083 predecessor relationships to keep canonical ids stable. After migration it needs only Folio-target merger rules.
• Post-migration (no predecessor): mint a catalogue-style id (C) via a secured resolve-or-mint endpoint added to the Identifiers API (RFC 089). C becomes the storage handle; the Folio id rides in the METS record identifier so the transformer can emit a folio-instance merge candidate and build the mets/<folio-id> own-identity. The transformer carries C from the storage externalIdentifier into the work's identifier block, and the id_minter verifies the mets/<folio-id> ↔ C binding (raising rather than minting on a mismatch). This path is blocked on RFC 081's IIdentityService in iiif-builder.

The RFC also covers alternatives considered, the merger-rule changes needed for Folio targets, dependencies for each path, and two open questions.

Files changed:

• rfcs/091-digitisation-ingest-identifiers/README.md: the RFC document (with two Mermaid sequence diagrams for the current and proposed ingest flows).
• rfcs/README.md: RFC listing table regenerated by .scripts/create_table_summary.py (RFC 091 row added).

How to test

• Read the rendered RFC and review the context, proposal, alternatives, dependencies, and open questions.
• Confirm the RFC passes repo validation: .scripts/validate_rfc.py.
• Confirm the listing table is in sync: .scripts/create_table_summary.py --check-readme.
• Some relative links (../085…/, ../088…/, ../089…/, ../090…/) resolve only once those branches merge; they are correct against the merged layout.

How can we measure success?

No measurable runtime success criteria; this is a documentation RFC. Success is the RFC being reviewed and the team aligning on the digitisation-ingest identifier approach across the migration, in particular the decision to mint catalogue-style ids rather than reuse the Folio id, the cross-migration / post-migration split, and the secured mint endpoint on RFC 089.

Have we considered potential risks?

• Documentation only; no production code or infrastructure is changed by this PR, so there is no runtime or deployment risk.
• The design risks are enumerated in the RFC and are the subject of review. The principal one is the silent merge break that follows from moving the package id off the b-number; the proposal mitigates it by reusing the b-number on the cross-migration path and by a fail-loud guard on the post-migration path (the id_minter raises rather than minting a divergent id when a METS source identifier is not already bound to its storage handle).
• Two open questions remain, both flagged as gating the post-migration path: confirming iiif-builder and DLCS make no assumption that the storage externalIdentifier (C) equals the METS record identifier (folio-id); and confirming the id_minter can verify a supplied source-id ↔ canonical-id binding and raise on a mismatch, rather than only assigning a fresh id.

Notes for reviewers

• This RFC extends RFC 089 (Identifiers API, open in RFC 089: Identifiers API #156) with a secured mint endpoint, and depends on RFC 081 (IIdentityService in iiif-builder) for the post-migration path. Related in-flight work: RFC 085 (IIIF identities, RFC 085: IIIF identities #143), RFC 088 (identity/requesting migration, RFC 088: Record the barcode sequence service #158), RFC 090 (CMS↔LMS sync, RFC 090: CMS and LMS Sync #157), and RFC 083 (stable identifiers) on main.
• Opened as a draft for discussion.

🤖 Generated with Claude Code