Appearance
When linked data misbehaves in Omeka S, the cause is almost always one of three things: the property is set to a literal data type instead of URI, the Value Suggest endpoint is misconfigured, or a URI was saved without a human-readable label. Fix the data type on the resource template, verify the suggest service URL, and always store both the URI and a label. Below are the concrete symptoms and the fixes that hold.
Why won't a property accept a URI value?
By default many properties are set to the literal data type, so the editor only offers a text box. Open Resource templates, edit the template, and for the property in question set the data type to URI — or to a module-provided type such as Value Suggest. Then re-save affected items.
Important caveat: changing the template does not retroactively convert existing literal values. Those stay as text. You either re-edit them by hand or, for bulk fixes, export with the CSV Import/Export module and re-import with the property mapped to a URI column.
Why does Value Suggest return nothing?
Value Suggest queries an external authority (LCSH, Getty AAT/TGN, GeoNames, Wikidata) live. A blank dropdown almost always means the request never reached the service. Diagnose in order:
text
1. Module settings → confirm the Value Suggest service is enabled
2. Copy the service endpoint URL and open it directly in a browser
3. Check the server can make outbound HTTPS (no firewall block)
4. Watch for HTTP 429 — the authority is rate-limiting youIf the raw endpoint works in a browser but not in Omeka, the problem is server-side outbound networking, not Omeka itself. On a locked-down host, allow-list the authority domains.
Why is my JSON-LD missing labels?
Omeka S stores a linked value as two parts: the @id (the URI) and o:label (the display text). If you pasted only a URI, the label is empty and downstream consumers see a bare IRI. Always fill both fields. When inspecting output:
bash
curl -s "https://yoursite.org/api/items/42?format=jsonld" | python -m json.toolLook for entries shaped like this:
json
{
"dcterms:subject": [
{
"type": "uri",
"@id": "http://id.loc.gov/authorities/subjects/sh85076671",
"o:label": "Manuscripts, Medieval"
}
]
}If o:label is absent, re-enter the value supplying the label.
How do I confirm an item emits valid RDF?
Do not trust the editing UI alone — validate the actual serialisation. Request the item as JSON-LD via the API, then run it through a validator:
| Tool | Use |
|---|---|
json-ld.org playground | Expand/compact, catch malformed @context |
| W3C RDF validator | Confirm triples parse |
riot --validate (Apache Jena) | Command-line batch checking |
A common failure is a typo'd vocabulary prefix that makes the @context un-expandable; the playground flags it immediately.
What breaks when a vocabulary changes underneath you?
If you imported a custom vocabulary and later re-imported it with different term URIs, every value pointing at the old URIs is now orphaned — the link resolves to nothing. The fix and the prevention are the same principle: URIs are identifiers, treat them as permanent. If a change is unavoidable, export the values, run a controlled find-and-replace mapping old URI to new, and re-import. Never edit term URIs casually in a live vocabulary.
Why don't external URIs show live remote data?
A frequent expectation gap: storing http://www.wikidata.org/entity/Q42 does not make Omeka fetch and display Wikidata content. By default the URI renders as a hyperlink only. To pull live remote data you need a module that dereferences the URI at render time, or a custom template that does a server-side fetch and caches the result. Decide deliberately whether you want live federation (slower, network-dependent) or a static stored label (fast, robust).
Key Takeaways
- A property that won't accept a URI is set to the
literaldata type — change it in the resource template. - Template changes never retro-convert existing literal values; fix those by hand or by re-import.
- Empty Value Suggest dropdowns usually mean a blocked or rate-limited outbound request, not an Omeka bug.
- Always store both the URI (
@id) and a human label (o:label). - Validate real JSON-LD output, not just the editor, using the json-ld.org playground or Jena.
- Treat vocabulary URIs as permanent identifiers; changing them orphans existing values.
- Stored external URIs are links, not live data — federation needs a dereferencing module.
Frequently Asked Questions
Why does my property only accept plain text, not a URI?
The property's value annotation is set to literal. Edit the resource template, set that property's data type to 'URI' (or a custom data type from a module), and re-save the item. Existing literal values will not auto-convert.
Why does the Value Suggest dropdown return no results?
Usually the configured endpoint is wrong or rate-limited. Check the Value Suggest service URL in the module settings, confirm the vocabulary (e.g. LCSH, Getty AAT) is reachable, and test the endpoint URL directly in a browser.
My JSON-LD output shows @id but no label — why?
Omeka S stores the URI and an optional human label separately. If you pasted only a URI, the o:label is empty. Re-enter the value providing both the URI and a display label so consumers see readable text.
Why did my linked URIs break after a vocabulary update?
If you imported a custom vocabulary and re-imported it with different term URIs, existing values now point at terms that changed. Keep vocabulary URIs stable, and if they must change, run a find-and-replace on the value table via a controlled export/import.
How do I confirm an item actually emits valid RDF?
Append a format extension or use the API: request the item with ?format=jsonld, then paste the output into the W3C RDF validator or json-ld.org playground to confirm it expands correctly.
Why are external URIs not dereferencing to live data on my site?
Omeka S stores the URI but does not fetch remote data at display time by default. To show live external content you need a module (or custom template) that dereferences the URI; otherwise it renders as a link only.