Beyond a crosswalk: making ORS-Appliance BIBFRAME-native

Libraries have been discussing life beyond MARC for a long time. The difficult part has never been declaring that a linked-data model would be better. It has been making that model carry real library operations while continuing to respect the records, exports and expertise on which libraries depend.

Our latest ORS-Appliance work puts a stake in the ground: BIBFRAME is now the canonical bibliographic model inside the appliance. MARC remains a critical source and interchange format, but it is no longer the application’s internal destination.

That distinction matters. We are not treating MARC as a problem to be escaped, and we are not criticising projects that have sensibly continued to use it. MARC is exceptionally dense, mature and widely deployed. It also carries local practice that a generic converter cannot safely guess. Our crosswalks, source profiles and replayable imports are therefore core product capabilities, not a temporary migration shim.

The opportunity comes after that careful ingress. Once a record is represented as a BIBFRAME 2 Work, Instance and Item graph, ORS-Appliance can add the location, availability, supply and resource-sharing semantics it needs as linked, namespaced data. We can enrich the graph without redefining BIBFRAME terms or flattening the record into a proprietary search document.

From file transfer to a bibliographic graph

The screenshots in this post come from the current local OpenRS stack. The source files were published through SFTP into an atomic intake route. FTP, browser upload, object storage or another publisher can use the same application-owned ready boundary; SFTP is simply the secure transport used in this evidence run.

Once a complete file appears, ORS-Appliance claims it, validates it, streams the MARC records, archives successful payloads for replay and quarantines failures with an audit trail. Format detection uses content signatures rather than trusting the filename. The current route accepts ISO 2709 or MARCXML, including bounded gzip and ZIP containers, while rejecting unsafe paths, encrypted or nested archives, DTDs and external XML entities.

Import is deliberately separate from supply workflow. A Record Source contributes descriptions to a host-owned collection; the resulting ResourceDescription enters the tenant’s metadata registry. Discovery, OAI-PMH, item availability and later resource-sharing decisions read from that common registry rather than from a special FTP catalogue path.

What “BIBFRAME-native” means here

Each canonical description is JSON-LD 1.1 containing linked bf:Work, bf:Instance and bf:Item nodes. ORS-Appliance mints stable graph-node identifiers, links the Instance to its Work with bf:instanceOf, and links every actionable Item to its Instance with bf:itemOf. External identifiers such as ISBN, ISSN and DOI remain typed bf:identifiedBy nodes rather than being mistaken for graph identity.

The current OpenRS BIBFRAME profile maps a much broader surface than title and author:

Description area	Representative MARC evidence	Canonical result
Titles and scripts	130, 240, 245, 246 and linked 880	Structured bf:Title nodes, parts, responsibility and retained alternate-script linkage
People and organisations	100/110/111 and 700/710/711	Repeatable bf:Contribution nodes with typed agents, roles and authority identifiers
Identity and subjects	001/003, 010, 016, 020, 022, 024, 028, 030, 035 and 6XX	Typed identifiers, classifications, subjects, subdivisions and authority data
Publication and physical form	260/264, 300 and 336/337/338	Provision activity, extent, dimensions and linked RDA content/media/carrier terms
Relationships and notes	490, 7XX, 8XX and public 5XX	Series, typed related resources and public notes with source-field provenance

MARC language, relator and RDA codes are mapped deterministically to id.loc.gov URIs while retaining their supplied labels, codes and sources. Explicit URI-valued $0 and $1 identifiers become node identifiers. Unlinked 880 fields are retained with a warning instead of being silently attached to the wrong field. Private notes are not promoted into the public graph.

This is a profile, not a claim that every possible MARC record can be converted without judgement or loss. It is also not the Elasticsearch document shape. Search projections may denormalise values for querying, but the JSON-LD graph remains the descriptive source of truth.

The UI offers a human-readable view and the canonical graph side by side. That is important for two audiences: staff need intelligible metadata, while implementers and metadata specialists need to see the actual model and provenance.

Item import is where resource sharing becomes real

Description alone does not tell a resource-sharing service what can actually be supplied. The BIBFRAME Item model gives us the right place to represent an actual physical or electronic copy, including its holder, location, shelf mark, electronic locator and usage policy.

It is tempting to turn every holdings-looking MARC field into an Item. We deliberately do not.

ORS-Appliance first builds holdings observations from standard evidence: institution-level 850, location-level 852, linked captions and chronology in 853–868, item information in 876–878, electronic locations in 856/857, and explicitly configured local fields. The MARC holdings definitions distinguish these levels; the import should not erase that distinction.

An institution statement, a shelf location or a serial coverage note may be useful and valid without identifying one actionable copy. Those values remain attached to the Instance as observations. A bf:Item is created only when the evidence justifies a concrete thing.

For a print monograph Item, the graph can retain:

• the source-local item identifier and barcode;
• bf:itemOf linkage to the Instance;
• holding institution and its source;
• an ordered institution / collection / shelving-location path;
• shelf mark and physical reference;
• supplied and normalised status;
• field occurrence, linkage and source subfields;
• mapping profile, confidence and warnings.

Availability and lending policy are intentionally different. A source status may map to openrs:availabilityStatus: AVAILABLE; it does not automatically create openrs:isLoanable: true. “Observed as available” and “permitted to lend through this service” are different assertions, owned by different evidence and policy.

That restraint is a feature. It lets ORS-Appliance use BIBFRAME as an operational model without making cataloguing evidence say more than it says.

Profiles make local MARC explicit

MARC’s standard fields matter, but real exports also contain local decisions. A 945 can mean item data in one system and something entirely different elsewhere. Treating every 9XX as universal would be easy to implement and hard to trust.

ORS-Appliance therefore resolves a layered MARC mapping profile for every route:

base profile → Host System configuration → collection configuration → Record Source configuration

The most specific layer can refine the identifier selector, local item tag and subfields, status map, holdings profile and source institution. The generic base profile uses standard fields and does not guess local 9XX semantics.

The first built-in source profile is Sierra-shaped. It can select the bibliographic identifier from 907 $a with 001 as a fallback, interpret local 945 item identifiers, barcodes, locations and statuses, and map known status codes into the small operational vocabulary used by the appliance. Crucially, those rules activate only for a Sierra source or explicit configuration. The same 945 in a generic source remains uninterpreted and produces a diagnostic rather than a fabricated Item.

Profiles are also evidence. The canonical description records the mapping profile and revision, while holdings observations carry detected profiles, confidence and warnings. Current assessment states include clean explicit evidence, clean evidence using a source default, partial, ambiguous, no holdings and failed. This gives operators and future reconciliation tools something much better than a binary “converted” flag.

The roadmap is intentionally empirical: add and refine profiles from representative exports, keep local overrides bounded, and do not infer vendor-specific semantics merely because a familiar field number appears.

Print monographs first, without narrowing the model

This increment concentrates on print monograph volumes because they expose the complete resource- sharing chain: description, a concrete copy, location, current status, policy, retrieval and physical movement.

The model is already broader. For continuing resources, 310/321 frequency and 362 designation are mapped, while 853–868 captions, chronology and textual holdings remain evidence rather than pretending that a verbatim range is machine-authoritative. Separate MFHD correlation through 004 is not silently guessed; unsupported files are diagnosed and skipped until representative feeds justify a safe rule.

Electronic links receive the same care. MARC 856 can identify the resource itself, another version or a related resource; the field’s second indicator carries that relationship. Only a link that identifies the resource becomes an actionable electronic Item by default. Related or ambiguous links are preserved as observations. This foundation connects naturally to ORS-Appliance’s electronic delivery provider boundary, where a digital Item can later be governed by delivery, rights and provenance rather than by the presence of a URL alone.

Why this matters for OpenRS

ORS-Appliance is a library’s point of presence in a resource-sharing network. It may receive records from an LMS, a repository, a managed file feed or a future live adapter. It may publish into DCB, answer an NCIP availability request, support an ISO 18626 transaction or help staff fulfil a request manually. Those paths need one coherent account of what the resource is and what concrete things can be supplied.

BIBFRAME gives us that centre of gravity. Namespaced OpenRS terms then describe operational facts for which the base vocabulary is silent: source-local identity, availability observation, canonical institution context, mapping evidence, delivery references and resource-sharing policy. Because the extensions are explicit JSON-LD terms, they enrich the graph rather than forcing BIBFRAME concepts to carry meanings they do not have.

This is the implementation opportunity: not “MARC bad, BIBFRAME good”, but MARC carefully in; BIBFRAME natively within; standards-based projections and protocols out.

MARC crosswalk quality remains a critical part of the roadmap. So do replay, diagnostics, profiles and representative fixtures. The more seriously we take MARC on ingress, the more confidently we can make BIBFRAME the model in which ORS-Appliance grows.

For the wider architecture around this work, see What is ORS-Appliance? and the latest returnable-print lending checkpoint.