ISAD(G)General International Standard Archival Description
Our Item and Fonds modules are shaped around the seven ISAD(G) areas: identity, context, content, condition, allied materials, notes, and description control.
- Reference code, title, dates, level of description, extent
- Name of creator linked to authority records
- Scope and content, arrangement, and appraisal notes
- Access, reproduction, and language conditions
Dublin CoreDCMI metadata terms
Every published record can be expressed as Dublin Core for discovery, harvesting, and cross-repository search.
- 15 core elements plus extended DCMI terms
- Exposed via the live OAI-PMH harvesting endpoint
- Exposed via API for third-party discovery tools
MARC21MARC 21 bibliographic format
For institutions with library-integrated workflows, we support MARC-style export for catalog sync.
- Leader, control fields, and common data fields
- Round-trippable with LOC authority files
- Subject heading mapping to LCSH (planned)
PREMISPreservation metadata & active fixity
Every file carries PREMIS-style preservation metadata — and the bytes themselves are verified on a schedule, not just at ingest. A SHA-256 baseline is established the first time we see a file, then a recurring worker re-hashes it on a monthly cadence and alerts tenant admins the moment something diverges.
- SHA-256 fixity baseline on every stored object
- Scheduled re-verification — 6-hour worker cycle, 30-day window per file
- On-demand "Verify integrity now" from any file's detail page
- Append-only PreservationEvent log: Baseline + FixityCheck × Pass / Fail / Skipped
- Per-row checksum algorithm so a future SHA-256 → SHA-3 migration leaves history readable
- Tenant-admin notifications (in-app + email) on fixity failure
- PREMIS fields native on every file: preservation level, significant properties, inhibitors, creating application + version, migration history
ARK / DOIPersistent identifiers
Mint an ARK or DOI on publish so a record stays citable for decades — even if your URL scheme, your department, or your domain changes.
- Per-tenant configuration: ARK NAAN or DataCite DOI prefix
- Identifier minted automatically on first publish
- Resolver endpoint preserves every published version
- Identifiers travel with EAD, MARC21, and Dublin Core exports
EAD 2002 + EAD3Encoded Archival Description — both ways
Export any Fonds as a valid EAD finding aid in either the legacy EAD 2002 schema or the current EAD3 (2015 revision) that ArchivesSpace and modern aggregators expect. The same parser also ingests EAD finding aids from other systems — drop a file and we'll rebuild the fonds + series + items in your tenant.
- Full hierarchy: fonds → sub-fonds → series → items
- ISAD(G) fields mapped to standard EAD elements
- EAD3 emits structured ISO-8601 dates (<unitdatestructured>) alongside legacy free-text
- EAD3 control block with maintenance history per the 2015 schema
- Only published items included — drafts are never exported
- Import EAD finding aids from ArchivesSpace, AtoM, or any system that emits the standard
- Per-job conflict policy on import: skip existing, fill empty fields only, or overwrite
EAC-CPFAuthority records for people & organizations
Companion standard to EAD: every Person and Organization can be exported as a valid EAC-CPF (2010 schema) XML authority record — and the same format imports back. Stable identifiers (ORCID / VIAF / ISNI / Wikidata for people; ISIL / ROR / Wikidata for organizations) let agents dedupe across repositories automatically, whether you're sending or receiving.
- <entityType> dispatched: person or corporateBody
- Identifiers mapped to <entityId localType=...> for each authority
- Existence dates as ISO-8601 <dateRange> (birth/death or established/dissolved)
- Structured name parts (surname / forename) plus alternative-name variants
- Cross-agent relations: affiliations, parent/child orgs, person-to-person
- Mandatory <control> + <maintenanceHistory> block per the schema
- Import authority records from partner repositories — ORCID / VIAF / ISNI / ROR dedupe across institutions
MODS 3.7Metadata Object Description Schema
Library of Congress' richer alternative to Dublin Core for catalog interchange. Preserves curator-vetted structure (parts, role-typed names, kind-aware subjects, identifier types) that DC's flat 15 elements lose. Same format imports back from any system that emits MODS — and the import kernel is reused by METS, BagIt, and OAI-PMH harvesting under the hood.
- Role-typed personal + corporate names with NameVariants as alternatives
- Subject dispatch by kind (topic / geographic / temporal / personal / corporate / conference)
- LCSH / AAT / MeSH / UNESCO authority + valueURI on subjects when set
- Typed identifiers: ISBN, ISSN, DOI, ARK, local (ISAD code, accession number)
- Parent Fonds as <relatedItem type="host">
- Standalone download + exposed as the mods metadataPrefix on OAI-PMH
- Import MODS records from library catalogs and union systems — same identifier rules dedupe
OAI-PMH 2.0Harvest both directions, on a schedule
Expose your published records to DPLA, Europeana, national libraries, and regional aggregators via a public OAI-PMH 2.0 endpoint — and harvest the other way too, pulling records from any partner OAI-PMH server into your tenant on a recurring schedule (Hourly / Daily / Weekly / Monthly) or on demand.
- Public server: all 6 verbs (Identify, ListMetadataFormats, ListSets, ListIdentifiers, ListRecords, GetRecord)
- Both GET and POST supported per spec §3.4 — works with every major harvester
- Dual metadata prefixes: oai_dc (Dublin Core) and mods (MODS 3.7)
- Paged harvesting via resumption tokens — large repositories stream cleanly
- Multi-tenant: each institution's endpoint at /oai?tenant=slug
- Sets mapped to Fonds — harvest a single collection or the whole repository
- Only published records exposed — drafts are never harvested
- Harvester client: paste a remote OAI-PMH URL, pick the metadataPrefix, and pull records in — resumption tokens auto-followed
- Recurring schedules: register a source once, the background worker fires it Hourly / Daily / Weekly / Monthly and writes per-run counts + status back to the registry
- Pause, resume, edit cadence, or Harvest now — without losing the schedule
BagIt 1.0Preservation packaging (RFC 8493)
Bundle any Item with every linked file into a standards-compliant preservation tarball — accepted directly by Archivematica, institutional repositories, and BagIt-aware ingest pipelines. Restore the other way from any conforming bag, including the payload bytes.
- Canonical layout: bagit.txt, bag-info.txt, manifest-sha256.txt, tagmanifest-sha256.txt, data/ payload
- Reuses the fixity SHA-256 baseline — no recomputing checksums on download
- bag-info.txt carries External-Identifier, External-Description, Payload-Oxum, Bagging-Date, Source-Organization
- Tag manifest covers all three metadata files for end-to-end fixity
- One-click download from any Item detail page
- Restore from a bag — drop a .tar and we extract the embedded MODS plus every payload file into your tenant storage
- Manifest SHA-256 hashes carry straight onto the restored files — fixity is continuous with the bag's baseline, no re-hashing on import
METSArchivematica handoff packaging
Wrap descriptive (Dublin Core + MODS), administrative (PREMIS), and structural metadata around a file inventory in one Library-of-Congress METS envelope. Accepted directly by Archivematica as an SIP/AIP manifest and by any institutional preservation pipeline that expects METS. The same envelope imports back — descriptive metadata plus any file inventory the producer linked over http(s).
- Envelope: <metsHdr> + <dmdSec> (DC + MODS) + <amdSec> (PREMIS) + <fileSec> + <structMap>
- Per-file PREMIS metadata with SHA-256 fixity, size, and format from the live baseline
- MODS section embeds the same MODS 3.7 we expose standalone — single source of truth
- Relative data/ paths so the METS XML drops alongside a BagIt payload without rewriting
- Import unwraps the embedded MODS — or falls back to the Dublin Core dmdSec for Rosetta-style packages
- Restore payload files from any FLocat that points at an absolute http(s) URL; the producer's CHECKSUM + CHECKSUMTYPE flow straight onto the restored file row
- Non-fetchable hrefs (local file:// paths, in-bag relative refs) skipped with per-file errors so curators see exactly what didn't land
IIIF Presentation 3.0Manifest API for external viewers
Every published Item exposes a IIIF Presentation 3.0 manifest that Mirador, Universal Viewer, and IIIF-aware research portals can render directly — embed our material in scholar-facing surfaces without scraping.
- JSON-LD manifest with one Canvas per linked file (image / sound / video / PDF)
- Content-type dispatched to the right IIIF body type (Image / Sound / Video / Text)
- Width + height for images; duration for audio + video
- Metadata rows (Identifier / Date / Publisher / Language / Extent / Type / Collection / Creators)
- Public endpoint — no auth required, multi-tenant via /iiif/items/{id}/manifest?tenant=slug
- Only published items exposed — drafts never appear in IIIF
IIIF Image API 3.0Deep-zoom & region serving (Level 2)
Serve any image at any crop, scale, rotation, and format via canonical IIIF URLs. Mirador, Universal Viewer, OpenSeadragon, and research portals pick up tiles + crops automatically once the Presentation manifest advertises the service — no extra integration on their end.
- info.json + /{region}/{size}/{rotation}/{quality}.{format} routes per spec
- Level 2: region (full / square / pixel / percent), size with upscaling, arbitrary rotation, gray / bitonal / mirror, jpg / png / webp / gif / tif
- S3 derivative cache — every distinct URL becomes a cached object after the first render
- Per-tenant flag, off by default — opt in from Settings → Processing when your viewers actually consume IIIF
- Cantaloupe-friendly: institutions with multi-gigapixel needs can deploy an external IIIF server and route URLs out — manifests still work
Authority linkingLive VIAF / LCNAF / ORCID / ROR lookup, inside the editor
Type a name in any Person or Organization editor and matches from the major international authority files surface inline. Pick one and every cross-walked identifier — VIAF cluster, LCNAF naco, ORCID iD, ROR id, ISNI, Wikidata — drops in at once, along with the canonical name forms. Paste an id you already know and it resolves directly. Same picker available inline from Item Detail when linking creators.
- Live search across VIAF + LCNAF + ORCID (people) and VIAF + LCNAF + ROR (organizations)
- Cross-walked identifier bundle pre-fills in one click — pick a VIAF cluster, get LCNAF + ISNI + Wikidata for free
- Paste an ORCID iD, VIAF cluster id, LCNAF naco, or ROR id — resolves via the provider's direct-record endpoint
- Name variants from the authority record append to NameVariants / AlternateNames so search hits other forms too
- Dedupe on create — picking the same authority twice always returns the existing record, never makes a duplicate
- Same picker on Item Detail's Add Person, Accession's donor field, Org Detail's affiliations — one flow everywhere
Two-way interopEvery export format also imports
Move records in and out without lock-in. Drop a finding aid from another system, an authority record from a partner repository, a BagIt bag from a Preservica handoff, a METS package from Archivematica, or harvest records from a remote OAI-PMH server — and the records land in your catalog. The same XML you can hand to ArchivesSpace, you can hand back to Archively next year.
- Format auto-detected from the file itself — drop and import without picking the standard first
- Per-job conflict policy: skip existing records, fill only empty fields, or overwrite
- Dry-run preview before you commit — see exactly what will land, no surprises
- Authority dedupe by ORCID / VIAF / ISNI / ROR / Wikidata so cross-repository merges stay stable
- Result panel routes each new record straight to its detail page — no hunting for what just imported
- Round-trip tested: every export format re-imports through the same parser
