05b Service · Migration
FROM STANDARD

Dublin Core

WE MIGRATE YOUR DATA TO

CollectiveAccess

Your metadata is in Dublin Core — coming out of a homegrown system, an OAI-PMH endpoint, a generic XML/CSV dump. The standard does its job (15 simple fields: title, creator, date, subject, rights…) — but flattens everything that made your collection rich: no relations, no structured authorities, no hierarchies, no qualified dates. We take your Dublin Core dump (XML, CSV, OAI-PMH) and project it into the typed relational model of CollectiveAccess, reinjecting the lost richness: authorities, hierarchies, controlled vocabularies, relations between works, places, people and exhibitions.

LOCK · STANDARD OPEN
Dublin Core flattened fields
15
ELEMENTARY DC FIELDS
Simple Dublin Core only recognises 15 flat elements. CollectiveAccess gives you back a relational model: authorities, structured places, qualified dates, hierarchies — while remaining exportable in native Dublin Core (DC, DCMI Terms) for OAI-PMH and other open protocols.
BEFORE
Dublin Core metadata (XML / CSV / OAI-PMH)
UNIVERSAL STANDARD
AFTER
Typed relational model, exported as Dublin Core
BROWSER ONLY·OPEN SOURCE·API REST
— Process
01

A migration guided, never endured.

5 steps · 8 to 16 weeks
STEP 01 · 1 TO 2 WKS

Audit

We study your data: volume, custom fields, hierarchies, linked media, access rights. Delivered as a report and a target mapping.

DELIVERABLES
  • Field inventory
  • Data mapping
  • Migration plan
STEP 02 · 1 TO 3 WKS

Mapping

Design of the target mapping — projection of the 15 DC fields into CollectiveAccess record types (objects, authorities, places, dates), enriched with your existing vocabularies if available.

DELIVERABLES
  • Customised CA profile
  • Reference lists
  • Correspondence tables
STEP 03 · 2 TO 6 WKS

Migration

Import of the Dublin Core dump (XML, CSV, JSON, or OAI-PMH feed), transformations (authority extraction, date structuring, subject normalisation against AAT/Geonames/RAMEAU where relevant), import into CollectiveAccess with reverse mapping to native DC to preserve outgoing OAI-PMH compatibility.

DELIVERABLES
  • Acceptance-ready database
  • Migrated media
  • Quality report
STEP 04 · 2 TO 4 WKS

Acceptance

Cross-checks: your reference users validate the migrated records, we adjust, we document. Iterations on a pre-production environment.

DELIVERABLES
  • Test plan
  • Issue tracking
  • Acceptance report
STEP 05 · 1 WK

Training & switch-over

Team training on their own migrated database. Switch to production, support during the first days, managed hosting included.

DELIVERABLES
  • Training sessions
  • Production rollout
  • 30-day follow-up
— Comparison
02

Eleven concrete reasons to migrate.

Dublin Core → CollectiveAccess
AXIS
DUBLIN CORE
COLLECTIVEACCESS
Data model
15 flat elementary fields (simple Dublin Core)
Open relational model (MySQL), 14 record types, native hierarchies
Structured authorities
`creator` and `subject` fields as free text — no linked entities
Person, place, event and subject authorities — first-class entities, alignable with AAT, Geonames, RAMEAU
Relations
No native relations — the `relation` field is a URL or an identifier as text
Typed relations (object ↔ place ↔ person ↔ exhibition ↔ media) with cardinalities and facets
Dates
ISO 8601 date format — no ranges, no uncertainty, no historical calendars
Qualified dates: ranges, uncertainty (« circa »), calendars (Revolutionary, Julian…), ISO 8601 export
Controlled vocabularies
Not native — `subject` accepts anything, or an external thesaurus by convention
Internal hierarchical lists, aligned with AAT, Joconde, Geonames, RAMEAU — auto-completion, redirects
Multilingual
Repeatable fields with `xml:lang` — few tools really exploit it
Native multilingual support on every field and every type, interface manageable per language
Multimedia
`format` field + URL in `identifier`/`source` — no integrated media management
Media managed inside the base: thumbnails, HD derivatives, EXIF, IIIF, inline playback
API / interoperability
OAI-PMH if you already have it — otherwise nothing native
Open REST API + OAI-PMH (native DC export), RDF, Linked Data, Z39.50, EAD, MARC
Public website
Not applicable — DC is a format, not a system
Pawtucket included — faceted public site, IIIF, ready to theme
Musées de France compliance
To be re-developed bespoke — DC does not cover the inventory check
Official SMF plugin: register, inventory number, ten-yearly inventory check, deaccessioning, generated minutes
Reversibility
You are already in an open format — the easiest to migrate
Standard MySQL base, native DC/MARC/EAD export — no lock-in

★ Three gains change the game: a true relational model (beyond the 15 flat fields), structured authorities (people, places, subjects) and typed relations between works and entities. Everything else — durability, openness, interoperability — flows from there.

— Guarantees
03

Four safety nets.

Included
01 INTEGRITY

Data preserved

No loss. Every Micromusée field finds its equivalent — including hierarchies, controlled vocabularies and media links.

02 ACCEPTANCE

Tested round-trip

Before going live, you work on a copy of your real database, in pre-production. Adjustments are free of charge.

03 SOVEREIGNTY

You stay in control

The server is hosted by us, but the database and the media belong to you. Full export available at any time, in an open format.

04 COST

No hidden licence

Once migrated, no more purchase or extension fees. You pay for hosting and support, that's it.

— FIRST STEP IS FREE

Send us a Dublin Core export.
We send back a costed migration plan.

Launch an audit

Our specialised sites