Why on earth would you publish data as RDF?

Last year, Anne wrote something about Linked Data (that should be) Considered Harmful. It says aloud what probably many developers feel when a Linked Data architecture appears in a meeting: this may become abstract, over-modelled and hard to ship. That criticism deserves an answer in the same spirit: concrete, prototype-first, and honest about trade-offs.

RDF of course should never be a dogmatic decision. It should earn its place and should be used when the system needs durable identifiers, explicit semantics, reusable alignments, provenance, and deterministic data integration across teams that do not share one codebase. In other words: the strongest argument for Linked Data begins when one organization alone cannot define the whole system.

I will first dive into the main criticisms of Anne, and then propose a future architecture where RDF will undoubtedly make the difference.

“You have to invent URIs for everything.”

Any serious data ecosystem needs to document its identifiers. Can a field change? Can identifiers conflict? Are they stable across a merge, rename or migration? Publishing URIs is a practical way to make those expectations explicit with globally persistent identifiers. RDF also has blank nodes for things that should remain local. The hard part is choosing which URIs to reuse, and there I agree with Anne: reusing the wrong term too early creates friction. This is why I argued for eventual interoperability: start with your own coherent model, publish it clearly, and let the ecosystem add alignments when a concrete reuse case appears.

“Linked data tempts you to model everything at the most granular level.”

This criticism lands: Linked Data engineers can over-model and stall while the production system still has no working data flow. Granularity however is a modelling decision. RDF can describe a coarse profile, a detailed ontology, or just a local identifier and stop there. The right level depends on the decision the system must make and on the number of organizations that need to reuse the same terms, policies and provenance.

Dan Brickley and Libby Miller once wrote that “People think RDF is a pain because it is complicated. The truth is even worse. RDF is painfully simplistic, but it allows you to work with real-world data and problems that are horribly complicated.” Real ecosystems are the complicated part.

“Modern language models have overtaken the whole linked data premise.”

LLMs make Linked Data more practical. They can draft vocabularies, propose alignments, summarize documentation and detect suspicious mappings. Then the accepted result needs to be recorded in a deterministic form. Data pipelines cannot depend on a probabilistic answer changing from one run to the next. If different people ask an agent to align the same water-level dataset to the same target model, the resulting production pipeline should use the same mapping, with the same explanation, the same provenance, and the same test fixtures. That is where RDF, SHACL, OWL, SKOS, N3 rules and named graphs remain useful. Probabilistic AI can help create and review an alignment; the accepted alignment should be published, reused and audited.

“Wikidata uses Elasticsearch via the MediaWiki API for full-text search, and many triple stores use Lucene or Elasticsearch for that too.”

Agreed: full-text search is a search problem. Wikidata using Elasticsearch says very little against RDF, just like a relational database using a B-tree says very little against SQL. Linked Data earns its place as glue between workflow steps: search finds candidates, queues move messages, analytics engines aggregate, and a graph documents what records mean, how identifiers behave, which terms align, which policy applies, and which transformation was used.

“After almost two decades, linked data has proven that it is not going to bring a revolution. It is a niche technology for niche problems, not the future of data integration. If Linked Data has helped you enormously, I am genuinely curious about your experience.”

Sure: we should not oversell what RDF can do for a project. CSV alone does not solve a public transport ecosystem, and JSON Schema alone does not solve government interoperability. So far, the clearest market for RDF has been graph storage, querying and semantic data management, sometimes positioned next to property-graph technology such as Neo4j. That market is real: look at Graphwise GraphDB, TriplyDB, OpenLink Virtuoso, QLeverize, Amazon Neptune, Zazuko, TopBraid EDG and Ontop. At the same time, RDF adoption is nowhere near relational database adoption.

As an academic, I am more interested in what becomes possible next than in listing successful RDF projects you probably already know. I like comparing RDF, even after two (probably three) decades, to machine learning. Not so long ago, many people were applying simple statistical regressions and calling themselves AI companies. It took time before AI models started making a visible difference in actual businesses. The same may happen for RDF when it becomes part of practical neurosymbolic systems: LLMs help draft and review knowledge, while deterministic RDF artefacts make the accepted result reusable.

I do not believe generative AI has solved data integration. It can probably produce a useful one-off mapping, but that is not the same as deterministic integration across systems. Recomputing the same decision again and again also has a cost. Let me try to convince you with the demo in the architecture section.

“Invest in documentation, not ontologies. Build in iterations. Involve the people who have to build and use the system.”

Yes: start with the data that must be shared, with whom, and why; build a prototype; involve the people who must operate the system. My disagreement is about what documentation becomes in a data ecosystem. At one organization, prose, OpenAPI and JSON Schema may be enough. Across organizations, documentation should become executable assets: dataset descriptions, application profiles, vocabulary terms, policy rules, alignment statements, validation reports, and examples. This is the shift-left architecture I want data portals to grow into: document the richest useful model as close as possible to the source, so consumers can automate more of the integration work.

“The real problem of data integration between government systems is not technical. It is organizational. It is governance. It is the question of who owns which data, who has access, who maintains it. Linked data solves none of these problems. It only adds a layer of technical complexity that makes it harder to make real progress.”

He is right that RDF does not decide who owns a dataset, who may change it, or who is accountable when it breaks. That’s why the European Interoperability Framework (since 2004, but updated in 2010, 2017 and a revision coming up in 2027) separates legal, organizational, semantic and technical interoperability into distinct layers: solving one layer does not solve the others. RDF only helps once those legal and organizational decisions have already been made. DCAT can publish who maintains a dataset and where the authoritative version lives. ODRL can publish which access and usage policies apply. SHACL can publish what shape of data a source commits to. The organizational decision remains organizational; Linked Data makes that decision reusable by machines instead of re-explained by every new pair of departments.

An architecture for automated alignments

Today, the most important asset data ecosystem managers run is a data portal. A data portal tells you which datasets exist. Whether it is open data, a public-sector portal, or a data space with contract negotiation, the first layer is discovery.

However, I vividly remember that prof. Oscar Corcho once said to me that, while portals were a nice step in the right direction, “open data portals are where datasets go to die”. That line hurts because it is often true. We focused on getting datasets into catalogues. We have not yet made those catalogues rich enough to automate integration. The uncontested standards used around data catalogues and data-space policy, DCAT and ODRL, are Linked Data standards by the way. That is a useful starting point.

Some data spaces split this catalogue into two roles: a data portal for datasets, and a vocabulary hub for the schemas, ontologies and shapes those datasets reuse or align with. The DeployEMDS project's vocabulary hub paper extends that idea with two further semantic artefacts: dataset profiles, the structural and semantic constraints a dataset commits to, and profile alignments, for example SPARQL CONSTRUCT queries, that map one profile onto another. Made discoverable through the hub, a consumer no longer only finds which datasets exist; it also finds which alignment paths already lead toward the data model it needs. I want to keep this responsibility as simple as possible, though: a vocabulary hub does not need to be a separate service with its own governance process. In the architecture below, the vocabulary hub is nothing more than the schemas, shapes and alignments registered and made discoverable through the same data portal, right alongside the datasets that use them.

Let us build this up more slowly. The first thing an ecosystem needs is still boring: a data portal record. It says that a dataset exists, who maintains it, where it can be found, and which schema or shape describes the data. In Linked Data ecosystems, the usual vocabulary for this is DCAT.

The important line is the last one. The dataset points to a source shape. A shape is documentation that can be executed: it tells consumers which structure the source can provide. With SHACL, the source can say that every water-level observation has exactly one water level, expressed as a single literal using the generic cdt:ucum datatype, encoding both the number and the unit in one lexical string, for example "314 cm"^^cdt:ucum. The record and shape below are fixed in this demo; the editable incoming RDF Messages appear later in this section.

If you dislike this syntax, that is fine (I avoided pointy brackets ;-) ). I am using Turtle because it is compact in a blog post and common in the RDF community. The same graph can be converted to JSON-LD, YAML-LD, RDF/XML, N-Triples, Jelly-RDF, or another RDF serialization. Pick the syntax that fits your tooling. The graph, the identifiers, and the alignments remain the stable part.

At this point, no heavy ontology work is needed. The source has documented its data. The publisher can host that documentation and its own domain model, while the ecosystem manager can make those assets discoverable through the portal. The ecosystem can already validate incoming data, show useful documentation, and help consumers understand the source format. The part Anne dislikes, building alignments and doing ontology work, should appear only when a concrete use case benefits from it. LLMs can help speed up that otherwise tedious work. The accepted alignments will this way still become maintainable, reusable and reviewable artefacts.

That moment arrives when we want to automate alignments. The SHACL shape can be built using terms from the publisher's own domain model, and that domain model can gradually add links to existing standards. The ecosystem manager does not need to own that domain model. Its role is to stimulate, govern and make discoverable the creation of useful alignments with standards. A water-level observation can become a subclass of SOSA's observation concept once that is useful. Local properties can become subproperties of SOSA properties. Units can be aligned to established unit vocabularies such as QUDT or UCUM.

QUDT is the Quantities, Units, Dimensions and Types vocabulary. It gives persistent identifiers to units such as metre and centimetre, and to the quantities that carry those units. UCUM, the Unified Code for Units of Measure, is another widely used unit system, especially in health and measurement contexts. These standards let us stand on the shoulders of people who already did the hard work of modelling units. The source shape says the source uses centimetres, the target shape below says the application wants metres, and the domain model only needs to say how the source property relates to the target property. The unit conversion itself is already documented by QUDT, so the domain model should not repeat it. The demo loads the QUDT normalization profile and its packaged QUDT projection as a reusable rule profile.

Then an application can define what it can work with. That application profile is the consumer side of the documentation: the shape of data accepted by the application. In this example, the application expects SOSA observations and a water level expressed as a cdt:ucum literal in metres.

Now we have the three building blocks I want data portals to expose: the SHACL input shape, the domain model with alignments, and the SHACL output shape. With those three, a processor can compile a deterministic integration step. It can know which source properties may occur, which target properties are useful, and which vocabulary-level links explain the transformation. That is the cunning part of the RDF-JS Inference Engine. A naive reasoner would load everything it knows about OWL, SKOS, QUDT, SHACL and other vocabularies, and then try all applicable rules over the data. That can quickly become a performance problem: reusable semantic technology is powerful precisely because it contains a lot of generic rules, yet most of those rules are irrelevant for one concrete source shape and one concrete application profile.

The engine can use the SHACL shape of the source data and the SHACL shape of the application as pruning information. The source shape tells it which predicates, classes and value structures can actually occur. The target shape tells it which derived statements are worth producing. Combined with the domain model, the engine can prune the large rule space to a small runtime set of N3 rules. That runtime is what can run fast enough to be useful in a data pipeline, and small enough to run live in the browser.

The embedded demo below uses the full OWL, SKOS and QUDT rule profiles, but shows the compiled N3 runtime after the engine has pruned it. The source shape, domain model and application profile are fixed for this page, just as they would usually be fixed configuration in a data pipeline. On the first run, the engine fetches the reusable profiles, compiles the small runtime that is relevant for these shapes, and keeps that runtime in memory. The incoming data below is an RDF Message log with five separate water-level observations; each message is aligned independently, and you can step through the five aligned messages with the arrows next to the output panel. Try editing one of the cdt:ucum values, for example changing "314 cm"^^cdt:ucum to another value; the corresponding message will realign without recompiling the runtime.

The prototype proves the core mechanism live in your browser. The button uses the RDF-JS Inference Engine together with the pruned N3 runtime shown below, then reports only the time needed to align each message. The materialized output is the SOSA view requested by the application profile: the local water observation becomes a SOSA observation, and the centimetre value is normalized to metres as a single cdt:ucum literal through QUDT. If you want to edit the full example more freely, I also published it in the RDF-JS Inference Engine playground.

This prototype is deliberately modest. It does not pretend that all data integration is solved by one button. It shows the pattern I care about: the source publishes a shape, the ecosystem publishes vocabulary-level alignments only when they make sense, the consumer publishes expectations, and the processor produces deterministic output. The alignment can be reviewed, versioned, reused, tested and explained. An LLM could help propose the alignment, yet the production pipeline runs on the published artefacts.

Conclusion

Why publish data as RDF? Because future interoperability is easier when your terms, identifiers, shapes, policies and alignments are already first-class web resources. The point is not one alignment. The point is setting expectations about identifiers, documenting your model, and leaving a path for future services to align with you without rewriting your source system.

For data pipelines, we need behavior we can trust to repeat. We need explanations. We need the same alignment to be reused by different services. We need enough explicit semantics for automation to work across organizational boundaries. That is where Linked Data still has a job.

When this architecture works, Linked Data can become almost invisible to the end user. The extra abstraction will have done its job: identifiers, shapes and alignments make expectations explicit, after which data engineers can take over and do what they do best. They can build pipelines, monitor quality, optimize performance and ship useful integrations without asking every consumer to care about RDF syntax.

We are building these ideas into architectures for the WaterFRAME water data space, the DiSHACLed project in Flanders, and the DeployEMDS project's vocabulary hub for dataset profiles and alignments. Contact us if you want to build a data ecosystem where integration becomes more automated. We would love to help out.

P.S.

Thank you Anne for writing the post. It made me question and reaffirm my own assumptions again. I suspect we agree on more than the title suggests: build prototypes, avoid empty architecture, use the right tool, and let working systems teach us where the abstractions earn their keep. I’m confident we will be able to turn you to the dark side of RDF eventually. If you want to turn me away from the RDF-side, you’ll need to come up with a prototype that can also fully automate data alignments like this without using RDF (or without reinventing it either).