What linked data is for, and what it costs
Ask an engineer under forty what the semantic web was and you will usually get a polite shrug, or a story about OWL reasoners in 2006 that ends badly. Ask the same engineer whether they have shipped schema.org markup, consumed an ActivityPub feed, handled a DID document, or integrated a verifiable credential, and the answer is frequently yes to several. The vision did not arrive. Parts of the plumbing did, and those parts are now load-bearing in places most people never look.
That gap is worth taking seriously, because it tells you which of linked data's bets actually paid off. It was never one idea. It was a stack of them, and they have very different track records.
The bets, scored
Global identifiers won, completely. The proposal was that the thing you are talking about should have a name that is unique across the whole internet, not across your one database — and that the name should be a URL, so that anyone who finds it has somewhere to look. This is now so ordinary that it is invisible. Every OAuth issuer, every OCI image reference, every DID, every package coordinate is an instance of it. Nobody calls it the semantic web because nobody needs to.
A shared data model mostly won. Subject, predicate, object — the triple — turns out to be a fine lowest common denominator for merging data from sources that never coordinated. Two datasets about the same IRI combine by concatenation. There is no schema negotiation, no migration, no join key to agree on. That is a genuinely unusual property and it is the reason RDF keeps quietly reappearing in knowledge-graph projects that started out swearing they would use property graphs.
Formal ontology and inference largely lost, at least as a default. OWL's expressive power came with a cost curve most teams could not justify, and the promised payoff — machines deriving facts you did not state — turned out to be something most systems either do not need or would rather do explicitly, in code they can debug. There are real exceptions in biomedicine, in aerospace, in regulatory compliance. They are exceptions.
And RDF/XML lost so thoroughly that it very nearly took the identifiers and the data model down with it. Syntax matters more than architects like to admit. JSON-LD exists because someone eventually noticed that the model was fine and the encoding was repelling everyone.
The score, roughly. Identifiers: unambiguous win. Merge-by-IRI data model: quiet win. Inference: niche. Syntax: a decade lost and recovered. If you are deciding whether to adopt linked data, you are deciding about the first two, and you can decline the third.
The question that decides it
Here is the way to make this concrete for a specific system. Do your identifiers have to survive leaving your database?
If the answer is no — if every consumer of your data is a service you operate, if a record is only ever joined against records from the same system, if the vocabulary is settled by a Slack message — then linked data is overhead. Use integer primary keys and an OpenAPI schema. You will be happier and nothing will be lost. This is most software.
The answer becomes yes under a few specific pressures, and they are recognisable:
- Data arrives from parties you do not control, and you cannot require them to adopt your field names. Aggregators, registries, standards bodies, public-sector integrations.
- Data leaves and must still mean something years later, verified or re-read by software you will never see. Credentials, archives, provenance records, anything with a legal shelf life.
- The vocabulary itself is a deliverable — you are publishing a standard, and the whole point is that strangers implement against it.
- Datasets keep having to be merged and every merge costs a bespoke mapping project. This is the one that sneaks up on people: the fifth mapping is when merge-by-IRI starts looking cheap.
Note that none of these are about scale. A small system publishing a standard needs this. A very large system with one owner does not.
What it actually costs
The honest accounting matters, because the advocacy literature is bad at it. Three costs, in order of how much they hurt.
You have to decide what your terms mean
This is presented as a cost of linked data. It is really a cost you were already
paying, moved somewhere visible. A field called status with five
possible string values has an unwritten specification today, living in the heads of
four people and in a switch statement. Minting
https://vocab.example.org/status and writing down what it means forces
the conversation early, and the conversation is unpleasant precisely because the
ambiguity was load-bearing.
So the real cost is organisational, not technical, and it is front-loaded. Budget for a week of arguments that would otherwise have been a year of incidents.
The tooling assumes you know the model
This one is a genuine, unambiguous cost, and it is where most adoptions stall. The RDF ecosystem's tooling is written by people who know RDF, for people who know RDF. Error messages assume the model. Libraries expose the algorithms rather than the task. And JSON-LD specifically has the property discussed at length in the handbook: it does not fail on input it does not understand, it drops it.
A team's first six months with JSON-LD are usually spent discovering loss. A field is missing downstream. Someone adds it to the context. Two weeks later a different field is missing. The cause is structural — expansion is total — and the fix is not more care, it is a tool that reports what expansion discarded, wired into CI on day one rather than month eight.
Context resolution is a runtime dependency
The third cost is the one that surprises operators rather than developers. A
document that references https://www.w3.org/ns/credentials/v2 needs
that document to read it. In the naive implementation, that is an HTTP request, in
your hot path, to someone else's server, whose contents can change.
Every serious deployment ends up caching contexts locally, and most do it after an incident rather than before. Do it before: fetch each referenced context once, commit it, record its hash, and have every other code path read only the committed copy. Then an upstream editorial change appears as a diff in a pull request instead of as a Tuesday-morning behaviour shift, and your build does not depend on a stranger's uptime. There is a security argument on top of the availability one — a build step that fetches URLs named in an untrusted document is a request-forgery primitive — but the availability argument alone is sufficient.
What you get, concretely
Against those costs, the returns are narrower than the pitch and better than the scepticism.
Integration cost stops scaling with the number of partners. Two
systems that both use https://schema.org/name need no mapping for that
field. Not a cheap mapping — none. The n-squared curve of pairwise integrations
flattens for every term that is shared, which in practice is the boring 80% of any
schema: names, identifiers, dates, addresses, organisations.
Extension stops being a negotiation. Anyone can say something new
about your IRI without asking you, and the statement merges cleanly with yours.
There is no version bump, no reserved extension block, no x- prefix
convention. This is the property that makes linked data the right substrate for
ecosystems with no central authority, which is why it keeps winning in
standards contexts and losing inside single companies.
Data outlives its schema. A document whose keys are IRIs remains interpretable when the API that produced it is gone, the company is gone, and the documentation is gone — because the meaning is in the identifiers, not in a wiki. For a ten-year archive this is not a nicety.
The adoption path that works
For a team that has decided yes, the ordering matters more than any individual decision:
- Reuse before you mint. Check schema.org, then the domain vocabularies, then the W3C ones. A term someone else defined and you reuse is worth more than a better term only you use. Most of your first vocabulary should not be yours.
- Start with one document type. Not the whole domain. One document that already crosses a boundary, modelled properly end to end, teaches more than a six-month ontology exercise and produces something shippable.
- Put a loss check in CI immediately. Before the second document type. Real example documents, expanded, with every dropped key reported as a failure. This is the single highest-leverage thing on the list and it is almost always done last.
- Vendor every referenced context. Hashes committed. No network in any command except an explicit, human-invoked refresh.
- Version the vocabulary from the first publish, immutably, at content-addressed URLs, with human-readable labels layered on top as movable pointers. Retrofitting immutability onto a URL people already depend on is not possible, only apologised for.
- Add inference last, or never. It is the part of the stack with the worst cost-to-value ratio for most teams, and declining it costs you nothing else on this list.
Linked data is not a philosophy to adopt. It is a set of engineering trades with a clear trigger condition: identifiers that must survive leaving your database. If that describes you, the trades are good, and the failure modes are well enough understood by now that they can be tooled rather than suffered. If it does not, the honest advice is to keep your integer keys and read something else.
