Appearance
You should map metadata in Omeka S whenever your data will be harvested, linked, or reused beyond a single site, and you can skip elaborate mapping when you are building one small, self-contained collection. Mapping means deciding which source field corresponds to which RDF property, and the payoff is interoperability: a well-mapped record speaks the same language as VIAF, the Getty vocabularies and other repositories. The cost is upfront modelling time, so the real question is whether your project's future justifies it.
What exactly are you mapping, and to what?
Mapping connects two things: the source (a CSV column, a legacy field, an existing record) and the target (an RDF property drawn from a vocabulary). In Omeka S the common targets are Dublin Core Terms (dcterms:), but you can also reach into Bibo, FOAF, Schema.org and custom vocabularies.
text
Source column "Photographer" -> dcterms:creator (typed as foaf:Person)
Source column "Taken" -> dcterms:date
Source column "Place" -> dcterms:spatial (linked to a gazetteer URI)The mapping decision is semantic: "Photographer" is a creator, not a contributor, and that choice shapes how machines interpret the record.
When is mapping worth the effort?
Map richly when any of these are true:
- You will publish linked open data or expose a SPARQL endpoint downstream.
- Other institutions or aggregators (Europeana, DPLA-style hubs) will harvest you.
- You need reconciled URIs for people, places and subjects, not free text.
- You are crosswalking from an existing schema like MODS or MARC.
In those cases mapping is the work, not overhead.
When should you keep it simple instead?
Do not over-engineer a single teaching exhibit or a 200-item departmental gallery with no interoperability goal. Plain dcterms: Dublin Core covers Title, Creator, Date, Subject, Description and Rights, which is enough for a self-contained site. Mapping every field into three vocabularies "to be safe" costs hours and produces records nobody harvests. Match the modelling depth to the audience.
How do you decide field-by-field?
| Signal | Map deeply | Keep to Dublin Core |
|---|---|---|
| Reuse beyond one site | Yes | No |
| Reconciliation to authorities | Yes | No |
| Crosswalk from MODS/MARC | Yes | No |
| One-off exhibit, fixed audience | No | Yes |
| Tiny collection, no harvesting | No | Yes |
A pragmatic middle path: model the high-value fields (creator, subject, place, date) as reconciled URIs, and leave low-value descriptive prose as plain text.
How do you map values to URIs rather than strings?
Free-text "Paris" is ambiguous; a URI is not. Use the Value Suggest module to attach LCSH, VIAF or Getty TGN identifiers, or import a pre-reconciled URI column and set the property's data type to a linked-resource type. During CSV Import, set the column's data type to uri or map it through Value Suggest so values resolve to authority records instead of remaining literals.
Does mapping change what the outside world sees?
Yes, directly. The properties you map to are what appears in the REST API, in any OAI-PMH feed, and in JSON-LD output. A record mapped only to a custom field nobody recognises is invisible to standard harvesters, while one mapped to dcterms: and Schema.org surfaces in aggregators and, often, in search engines. Mapping is therefore a discoverability decision as much as a cataloguing one.
Key Takeaways
- Map metadata when data will be harvested, linked, or reused; keep it simple otherwise.
- Mapping is semantic: choose the property whose meaning matches the source field.
- The resource template declares properties; CSV Import maps columns onto them at ingest.
- Reconcile high-value fields (creator, place, subject) to URIs; leave prose as text.
- Avoid mapping one column to several near-identical properties without a reason.
- Your mapping choices determine API, OAI-PMH and JSON-LD output, hence discoverability.
Frequently Asked Questions
What does mapping metadata in Omeka S actually mean?
It means deciding which source column or field corresponds to which RDF property, such as mapping a spreadsheet 'Author' column to dcterms:creator, so imported data lands in the right semantic slot.
When should I not bother mapping to multiple vocabularies?
For small, single-purpose collections with no linked-data or interoperability goal, plain Dublin Core is enough. Mapping into Bibo, FOAF and Schema.org adds cost you will not recover.
Is mapping done during import or in the resource template?
Both. The resource template declares which properties an item type uses; the CSV Import module maps source columns onto those properties at ingest time.
Can one source column map to several properties?
Yes, but avoid it unless intentional. Mapping a single date column to both dcterms:date and dcterms:created duplicates data and can confuse downstream harvesters.
How do I map values to URIs instead of plain text?
Use the Value Suggest module or import a column of URIs and set the data type to 'resource' or a linked-data type, so creators and subjects become reconciled links rather than strings.
Does mapping affect OAI-PMH and API output?
Yes. The properties you map to determine what gets exposed through the API and any OAI-PMH harvest, so good mapping directly improves interoperability and discoverability.