To make metadata linked-data friendly, do three things: give every record and every described thing a persistent URI, replace string values with URIs from shared authorities wherever you can, and express the record using standard RDF properties so any system can read it. You do not have to abandon your existing catalogue — you add a linked-data view on top. This guide takes a plain catalogue record and makes it linkable, step by step.

What does "linked-data friendly" actually mean?

Three properties, in order of importance:

1. Things have URIs. The photograph, its creator and its place are identified by resolvable web addresses, not just labels.
2. Values link out. "Ipswich" becomes https://www.wikidata.org/entity/Q133263; "John Constable" becomes a VIAF URI.
3. Standard properties. You use dcterms:creator, schema:name, skos:prefLabel — vocabularies others already understand.

Strings describe; URIs connect. The whole point is connection.

Step 1 — Start from a plain record

Here is an ordinary record as key-value strings:

title: "High Street, Ipswich, looking west"
creator: "Felix Cobbold"
place: "Ipswich"
date: "1903"
type: "photograph"

It is human-readable but a closed island: nothing links anywhere. We will open it up.

Step 2 — Mint persistent URIs for your records

Every item needs a stable, resolvable identifier. Do not use a raw database ID or a fragile path. Use a persistence layer — an ARK, a DOI, or a w3id.org redirect you control:

https://w3id.org/aetherforge/item/ips-0903

If that URI keeps resolving for decades, everyone can safely link to your data. If it breaks, every inbound link rots. This is the foundation; get it right first.

Step 3 — Reconcile values to authority URIs

Turn strings into links by reconciliation — matching values to authority entries. OpenRefine is the standard tool: load your data, add a column, reconcile against Wikidata or VIAF, and accept the matches. Afterwards:

creator:
  label: "Felix Cobbold"
  uri: "https://viaf.org/viaf/12345678"
place:
  label: "Ipswich"
  uri: "https://www.wikidata.org/entity/Q133263"
type:
  label: "photographs"
  uri: "http://vocab.getty.edu/aat/300046300"

Now each value points at a shared concept, so your "Ipswich" is provably the same place as another dataset's "Ipswich."

Step 4 — Map fields to standard RDF properties

Choose properties from vocabularies others use. For general description, dcterms and schema.org; for concepts, SKOS; for rich cultural-heritage relationships, CIDOC-CRM. Express the record as JSON-LD:

{
  "@context": "https://schema.org/",
  "@id": "https://w3id.org/aetherforge/item/ips-0903",
  "@type": "Photograph",
  "name": "High Street, Ipswich, looking west",
  "creator": { "@id": "https://viaf.org/viaf/12345678", "name": "Felix Cobbold" },
  "contentLocation": { "@id": "https://www.wikidata.org/entity/Q133263", "name": "Ipswich" },
  "dateCreated": "1903"
}

This is valid RDF and ordinary JSON. Search engines parse the schema.org terms; triplestores ingest the triples.

What is the simplest way to publish it?

Embed the JSON-LD in a script type="application/ld+json" block on each item page. You get linked data with no triplestore, no SPARQL endpoint, and a bonus of rich-result eligibility in search engines. Stand up a triplestore (Fuseki, Blazegraph) only when you actually need SPARQL querying across the dataset.

How do you check it really is linked data?

A quick checklist:

Check	Pass condition
Record URI resolves	Returns content (not 404)
Values carry URIs	Names/places/types are URIs, not bare strings
Properties are standard	dcterms/schema/skos, not invented terms
JSON-LD is valid	Passes a JSON-LD playground / structured-data test
URIs are persistent	Behind a resolver you control

Validate the JSON-LD with a structured-data testing tool before publishing; a single malformed @context silently disables the whole block.

What are the common mistakes?

• Fragile URIs tied to a CMS path that changes on migration.
• Reconciling once and never re-checking — authority matches can be wrong; spot-check them.
• Inventing properties when dcterms/schema already have one.
• Mixing labels and URIs inconsistently, so some places link and others do not.
• Publishing RDF nobody can find — link it from human pages and a sitemap.

Key Takeaways

• Linked-data-friendly = persistent URIs, values as authority URIs, standard RDF properties.
• You add a linked-data view; you do not rewrite your whole catalogue.
• Mint stable, resolvable record URIs behind a resolver you control — this is the foundation.
• Reconcile string values to Wikidata/VIAF/Getty URIs, typically in OpenRefine.
• Map fields to dcterms, schema.org, SKOS or CIDOC-CRM — reuse before inventing.
• JSON-LD embedded in item pages is the simplest publishing route and aids search.
• Validate the JSON-LD and verify URIs resolve before going live.

Frequently Asked Questions

What makes metadata linked-data friendly?

Linked-data-friendly metadata uses persistent URIs for both records and the things they describe, draws values from shared vocabularies as URIs rather than strings, and uses standard RDF properties so other systems can interpret it without a custom parser.

Do I have to rewrite all my metadata in RDF?

No. You can keep your existing records and add a linked-data view by minting URIs, reconciling string values to authority URIs, and mapping fields to RDF properties. JSON-LD lets you publish linked data that still looks like ordinary JSON.

What is reconciliation in this context?

Reconciliation is matching your free-text values (names, places, subjects) to entries in an authority such as Wikidata, VIAF or Getty, so each value gains a stable URI. OpenRefine's reconciliation service is the common tool for doing it at scale.

Which vocabularies should linked-data metadata use?

Use widely adopted ones: Dublin Core Terms and schema.org for general properties, SKOS for concept schemes, and domain models like CIDOC-CRM for cultural heritage relationships. Reuse before you invent.

What is the simplest way to publish linked data?

Embed JSON-LD in your item pages. It is valid RDF, search engines read schema.org JSON-LD, and you avoid running a triplestore until you actually need SPARQL querying.

Why are persistent URIs so important for linked data?

Linked data is a web of references; if your URIs break, every link into your data breaks. Persistent, resolvable URIs (via a resolver like w3id.org or a DOI/ARK) are the foundation everything else depends on.

Related reading

• Getting started with Wikidata for heritage
• Controlled vocabularies for heritage metadata
• Persistent identifiers for digital objects
• Model RDF triples for heritage
• Reconcile metadata against Wikidata in OpenRefine