No collection is too small, no request too local

This is a checkpoint in a much longer conversation about how resource sharing software should be developed, demonstrated, and trusted. It sits after years of thinking and many months of shaping the plan with peers.

Some of the thinking behind it has been forming for a long time, including conversations with Adam Murray from Marmot and George Machovec from the Colorado Alliance. It is also heavily influenced by Casey Henderson’s brilliant work on DCB Admin. It also builds on the “three legged” model developed by Jag Goraya and Marc Johnson in collaboration with the MOBIUS team: the idea that a request is not simply borrower-to-lender, but often has a patron, a supplying institution, and a pickup location whose policy and fulfilment role must be represented clearly.

That model changes the protocol question. Direct consortial borrowing is not just document delivery with a different label. A broker has to coordinate request placement, lending, pickup, status, fulfilment, and return across systems that do not all share the same local model. That points toward a central broker and a serious reading of NCIP, rather than treating ISO 18626 as the obvious default for every part of the flow.

Show, do not tell

Resource sharing work is full of diagrams. Diagrams are useful, but they are not enough.

The founder-blog style I want to bring into this work is evidence-led. Show the running thing. Show the awkward edge. Show the local developer path. Show the record moving through the system. If the argument is that a broker can coordinate independent library systems, then the useful evidence is not a polished architecture picture. It is a running stack where a developer can open a browser and see the coordination happen.

The important local development move is simple:

cd dcb-ops/docker-local
./qa-local.sh start

That is not the product. It is not a production deployment story. It is a developer proof surface. But it gives us a place to make integration failures visible early, instead of discovering them only after a downstream hosting deployment has assembled the missing pieces.

ORS-Appliance as a stand-in library system

ORS-Appliance is becoming the local stand-in for a remote library system. It is deliberately more than a mock. It has tenants, identity, staff-facing screens, metadata records, search indexing, and public OAI-PMH exposure.

In this run, Hogwarts is one configured ORS-Appliance tenant. It has a small metadata registry with deliberately familiar seed records, including two entries for Brain of the firm and the longer-running Stafford Beer test case, Platform for Change.

The current OAI shape is intentionally path-based. DCB is configured with a base URL and tenant id, then the ORS-Appliance ingest source builds the tenant-specific public OAI endpoint:

http://ors-appliance:8080/ors-appliance/api/V1/public/hogwarts/oai

That keeps the OAI surface easy to inspect and avoids making DCB depend on browser-style tenant hostnames or an X-TENANT header for this public harvest path.

DCB sees source records

The next useful proof is DCB Admin itself.

Before DCB can harvest from ORS-Appliance, the remote system needs to be visible as a configured Host LMS. In this local stack, Hogwarts is wired through a new ORS-Appliance adapter: a DCB-side integration intended to let ORS-Appliance participate as a library system in the brokered network.

That adapter matters because not every library has an API, a full LMS integration surface, or the local capacity to expose structured real-time interfaces. Some collections may need a human to bridge the gap between a local ILS and a consortial resource-sharing system: place the hold locally, enter the item barcode, decline when necessary, and keep the broker informed. “No collection is too small” is the principle behind that fallback path. The goal is not to pretend every collection has the same automation level. It is to make participation possible without forcing every institution through the same technical doorway.

The bib records screen shows the records after OAI harvest and source-record processing. This is still early, deliberately small test data, but it is real movement through the stack: ORS-Appliance seed records, exposed as MARCXML through OAI-PMH, harvested by DCB, and visible in the DCB admin surface.

This is where the developer experience matters. When DCB is only exercised as a container handed to a downstream deployment, the centre of gravity for QA sits too far away from the development tree. A local full-system path changes that. It lets protocol, identity, harvest, indexing, and admin behaviour be tested as a system while still remaining close to the code.

One discovery result

The final visible proof is the shared index.

The two ORS-Appliance source records for Brain of the firm are not interesting because they are many. They are interesting because DCB can ingest them and the shared index can present the discovery layer with a single coalesced result.

Following the cluster UUID link shows the other side of that same proof. The discovery result is one cluster, but DCB still retains the source members that contributed to it.

The member row can then be expanded again to inspect the harvested source record underneath the cluster.

That is the line between “we harvested some XML” and “we are beginning to show the user-facing resource-sharing shape”.

The protocol lesson

The working hypothesis has shifted.

ISO 18626 remains useful, and earlier exploration was not wasted. It helped make the broker problem clearer. But for direct consortial borrowing, especially where a pickup location has its own operational significance, NCIP looks like the more important protocol surface for the DCB-to-library-system relationship.

That does not mean “just use NCIP” as a slogan. RequestItem and AcceptItem are relatively common. DCB needs the richer parts that are much less often implemented: ItemShipped, ItemReceived, ItemCheckedOut, and the surrounding status and cancellation choreography that lets a central broker coordinate the full trip.

That is where ORS-Appliance becomes important. It gives us a way to use and test those services even when the downstream ILS cannot support them directly. In fallback LMS mode, a staff member can bridge the local operational gap while ORS-Appliance still exposes the consortial state DCB needs.

The emerging distinction is useful. If you want anyone in a state to carry their library card into any library in that state and walk out with a book, or request an item from anywhere in the network and pick it up anywhere else in the network, then DCB and a serious NCIP implementation look like the right centre of gravity. If a researcher is approaching an unfamiliar library across the world about a specific annotated copy, or negotiating a paid copy of a government report, that is ILL territory. Different problem, different protocol posture.

DCB is narrow in one sense, but the narrowness is where the value is. In mixed conversations with library service directors, the practical need was clear: better-funded libraries want to share effectively with less well-funded colleagues, and the cost-avoidance case improves when resource sharing becomes indistinguishable from the normal request-hold-loan flow every library worker knows by heart, from seasoned professional to summer student.

What this changes

This is not a launch announcement. It is a more useful kind of progress marker.

The system is starting to become demonstrable in the right way:

• identity is local and reproducible through Zitadel;
• ORS-Appliance tenants can be bootstrapped;
• seed records can be exposed through OAI-PMH;
• DCB can configure an ORS-Appliance Host LMS adapter for a participating tenant;
• DCB can harvest and process those records;
• dcb-locate can sit beside DCB as a clean shared-index facade;
• DCB Admin can show both the raw harvested bibs and the coalesced discovery view;
• the whole thing can be started, inspected, and torn down from the local development stack.

There is still a lot missing. Patron discovery, patron auth, NCIP supplier operations, fallback LMS workflows, richer request state, and clean smoke tests all need careful iteration.

But this is a useful concrete step because it changes the quality of the conversation. We can stop only describing the resource-sharing architecture and start pointing at it.

That is the point of bringing this style of public notebook to DCB and OpenRS: show the running system, explain the boundary, name the learning, and keep going.