← Blog

Integrating AI cataloging with your catalog (ILS)

How to integrate AI cataloging with a catalog or ILS is, in the usual case, a delivery. Collect reads the documents and produces records in the format the institution uses —MARC21, ISAD-G, Dublin Core, CDWA. The catalog is where they are searched, circulated and corrected. Collect is not a second catalog: it does not keep a field-by-field copy of every record in line with the ILS.

When a cataloger changes a heading or a date in the catalog, that change stays in the catalog. It does not come back to Collect so that “two databases stay in sync.” Reprocessing a document in Collect means reading the original again and producing a new record; it does not start from the ficha already edited in the ILS.

How the record arrives

There are several outbound paths, depending on how the destination is set up.

The most direct for Janium is the load batch: one file per run, ready for the catalog. SFTP exchange drops the same package (records, attachments, manifesto) in the catalog’s inbox; the catalog answers whether the batch processed or failed. That is a load acknowledgement, not the cataloger’s later edits on a single record.

Publication can also go by SFTP or folder: original, JSON, thumbnail, manifesto. An ILS that is not Janium consumes that package on its own schedule, or someone loads it by hand. Collect still produces the records; what changes is who walks the last mile.

What Collect does keep

Collect keeps what it needs in order to catalog again: the source document, the markdown it read, field provenance, the score. That serves reprocessing, the batch gate, and showing where a datum came from. It does not replace the current record in the catalog.

The hierarchical case: the tree for bubble-up

The exception is a fonds described in ISAD-G with hierarchy. There Collect does not deliver only loose documents: it generates Fonds, Section and Series nodes and raises to those levels what most of the children share —producer, date range, extent. That is bubble-up, described in from loose documents to Fonds and Series.

Recalculating those parents requires knowing the tree and the unit dates. The date range of a Fonds or Series is not written by the model: Collect computes it from the dates of the documents under that node. If a cataloger corrects a date in the catalog, that date comes back to Collect and is indexed. In a historical archive, that correction leaves the node’s range ready for the next export to recompute it.

If a cataloger moves a file to another series, adds a level or reorders the scheme in the catalog, that hierarchy change is also sent to Collect. New records hang from the current tree; bubble-up uses that tree and the dates already corrected. A current records office recalculates ranges on each export; a closed historical archive can freeze them until a date changes again.

Collect does not keep a mirror of the whole record. A heading or title amended in the ILS is not reimported to keep two catalogs in line. What comes back is what bubble-up needs: hierarchy and dates.

Without an archival location on the documents there is no tree, and without a tree there is no bubble-up. The aggregation is reviewed before it enters the catalog: it is a majority heuristic.

Limits

A catalog that consumes neither the load batch nor the SFTP package can still receive the records: someone loads them, or a local process reads the publication folder. When anything returns to Collect, it is the hierarchy and unit dates, not every field on the record.

Once loaded, the home of the description is the catalog. Collect uses the updated tree and dates to aggregate what comes next.

If your institution already has an ILS and you want to see which delivery channel fits —FLAT, SFTP plugin, folder— and whether your classification scheme needs an ISAD-G hierarchy, write to us at info@janium.com and we can look at your case.