Janium Collect produces records: it reads the documents of a collection and delivers structured records in the format the institution uses —MARC21, ISAD-G, Dublin Core, CDWA. But a loose record is not a catalog. The catalog is where those records are consulted, related to one another and, above all, where someone who knows how to catalog reviews and corrects them. Producing the record is one part; the other is how it reaches the catalog —and, in an archive with hierarchy, what has to happen when the cataloger corrects a record that hangs from a fonds.
How the records reach the catalog
There are two ways to take Collect’s records to the catalog system, and which one fits depends on how the institution is set up and on what its catalog exposes. There is no need to pick one as “the right one”; they are answers to different situations.
The first is direct synchronization via API, what we call connected mode. Collect sends the records to the catalog through its service interface. It is the most immediate route: when the catalog is reachable over the network and offers the necessary entry points, the records propagate with little delay. It fits well when both systems live in the same infrastructure or there is stable connectivity between them.
The second is file exchange over SFTP, through the Janium plugin. Instead of live calls, Collect drops the records as packages in a folder the catalog picks up, and the catalog returns a confirmation of what it processed. This route serves when there is no —or no wish for— a direct connection between the two systems: the file is the border, and each side crosses it at its own pace. In exchange for that independence, it has its own latency: the packages travel in the upload, pickup and polling cycles that have been configured.
The return trip exists to keep the hierarchy current
For most records, loading them is the end of the journey. The cataloger reviews and corrects them in the catalog, and there it stays: a monograph in MARC, a record in Dublin Core, a work in CDWA are independent records, and once loaded the catalog is the authority. Collect does not need to hear about those corrections, and can in fact purge those records when the work is done.
There is a case where it does matter that the correction comes back: hierarchical archives described in ISAD-G. There the records are not independent: they hang from a structure of fonds, section and series, and part of the description of the upper nodes is built by raising what the documents hanging from them share —the bubble-up—. If the cataloger corrects a piece of data in a document that takes part in that raising, the upper node falls out of step with its children.
That is why, in a hierarchical archive, the correction made in the catalog returns to Collect, which applies it to its copy and recomputes the hierarchy: it raises to the parent nodes what belongs there again, so that the fonds and the series keep reflecting the documents they contain. That recomputation of the bubble-up is the reason Collect keeps the archive’s records while it is active, and the reason the return trip exists. In a flat catalog, with no hierarchy to recompute, there is nothing to sustain on this side.
What comes back, and what Collect does with it
A correction is a specific change to an identified record: updating a field’s value, removing a piece of data that was superfluous, adding one that was missing. Each record travels with an identifier both systems recognize, so the correction is applied to the right record and not to another that looks similar.
When that correction reaches Collect, it replaces the local copy of the record —the cataloger is the authority, it is not reprocessed with the model—, the derived data that depends on it, such as persons and dates, is reindexed, and the bubble-up is recomputed for the nodes that document is part of. The effect is that the human review done in the catalog does not stay only at the top: the description of the fonds and the series stays consistent with that of its documents, without anyone having to redo it by hand.
Limits
This mechanism depends on the destination catalog exposing the corresponding interface. For synchronization via API, the catalog has to offer the entry points to receive records and emit corrections. For file exchange, the agreed SFTP space is needed, and the catalog has to generate the confirmations and the corrections in the expected format. With a catalog that exposes neither, Collect still produces the records, but loading them becomes manual work again.
The return trip, moreover, only makes sense where there is a hierarchy to maintain. For a flat collection —bibliographic, a photo library in Dublin Core, a work in CDWA— there is no bubble-up to recompute: loading the record is everything, and the correction lives in the catalog. Promising a “closed loop” there would be inventing a problem that collection does not have.
The other limit is the latency of the file channel. If the institution needs a correction to be reflected within seconds, file exchange is not the way; the API route fits there. If batch cycles are acceptable —and for many cataloging workflows they are—, the file channel offers in return not requiring a direct connection between the two systems.
To continue the conversation
If your institution describes an archive in ISAD-G and wants its catalogers’ corrections to be reflected in the hierarchy without redoing it by hand, or if it simply seeks to load into the catalog what Collect produces, the concrete question is what interface that catalog exposes today —an API, a file-exchange space, or none yet— and whether the collection has a hierarchy to maintain. That is what determines which integration applies. Write to us at info@janium.com and we will go over it for your case.