Eventual Interoperability

I don’t want interoperability to stall any progress on reaching a project’s main goals. If it does stall, it needs to be worth the effort and deliver short-term business value. If it does not do that for your project, then working on interoperability will be seen as a nuisance and a distraction. It feels like advocating for goals that promote future business goals that might never become relevant.

Yet, interoperability is most noticeable when it’s absent. It’s when you are frustrated that you have to enter the same data over and over again, or when your route planner doesn’t contain the schedule of the bus service you want to use. In your day-to-day job, it’s when you identify an added value that needs data to flow from one system into another, but then you have to sit through too many alignment meetings on too many levels before you can actually make the end result work. Why can’t these systems simply work together?

This tension is palpable: end-users will eventually need interoperability, but at the start of the project, it feels like premature optimization. We need an approach that allows you to start quickly, so that you can reach your business goals without additional friction, even if there’s no standard yet that can evolve over time by design.

From rich to aligned semantics

By rich semantics, I mean the full, nuanced way you describe your own domain so your system can make precise decisions. By aligned semantics, I mean the shared vocabulary and constraints that make your data usable across systems. Rich semantics, on the one hand, fit our own project goals perfectly, but are not interoperable across systems. Aligned semantics, on the other hand, sacrifice this richness in favor of being able to reuse the data in another system. When offered the choice, I believe well-intentioned data engineers often choose aligned semantics too prematurely. Do we have to make a choice though?

Eventual interoperability means you document and design your data interactions for your own work first, and align with other systems later when there is a concrete need. It avoids forcing an early trade-off between semantic richness and alignment. Instead, it treats interoperability as a sequence: first capture the full meaning you can provide, then create alignments when collaboration, adoption, or reuse actually depends on them. However, it is not an argument for ignoring interoperability at the start: stable identifiers and explicit semantics (even if they are local to your domain) remain the foundations that keep future alignment feasible and inexpensive.

In that regard, the principle interoperability by design (cfr. the EIF’s definition) is often misunderstood. While the majority of the burden of data integration has been on the consumers so far, the point is not to instead move all integration work to data producers. Eventual interoperability is about balancing that burden of integration across the ecosystem, rather than assuming it should sit entirely with producers or entirely with consumers. In any case, data engineers building consumer pipelines today are already used to dealing with heterogeneous models, with ideas like Medallion Architecture (~2020) or shift-left architectures (~2024) gaining traction. Whatever you publish is pulled through ingestion, normalization, validation, and enrichment pipelines, until it can be used to help create insights in a product. The question is how these pipelines can become smarter and more cost-efficient with symbolic AI or Linked Data techniques.

A practical implication is that interoperability becomes—or maybe always was—a one-to-many process. If you preserve rich semantics at the source, you retain optionality: the same dataset can be aligned to multiple target models, standards, and downstream systems (including systems that do not yet exist).

Linked Data and eventual alignments

I often see Linked Data and Knowledge Graph engineers overcomplicating their projects for interoperability’s sake. Driven by good intentions, engineers start reusing terms from existing vocabularies immediately—often by cherry-picking predicates and classes across many ontologies. I believe this is a form of aligning too early: it introduces up-front coordination cost and semantic ambiguity without materially reducing later integration work. The underlying reason is that most systems do not integrate against individual terms in isolation, but against shapes or profiles: expected graph patterns plus constraints that define what a consumer can reliably act upon.

Robert Sanderson (a reference in the world of Linked Data for Digital Humanities) has also argued against cherry-picking terms across many ontologies, for a slightly different reason. He says those kinds of projects tend to produce solutions that are confusing and calls them Frankenstein’s monster-like models.

There is a big difference between reusing models and ontologies, and cherry-picking individual terms from ontologies. The first is important, the second is at worst dangerous and at best confusing. When you run into a relationship you need that doesn't exist in your foundational ontology or profile, the typical advice is “Find it in some other ontology and reuse it.”… I disagree.

» Robert Sanderson in a LinkedIn post.

Avoiding cherry-picking terms does not mean avoiding Linked Data altogether. On the contrary: Linked Data provides strong building blocks for eventual interoperability, precisely because it supports explicit alignments. The key is to keep your source semantics internally coherent, and externalize interoperability as mappings that can be introduced by the right actor at the right time. In practice, those mappings can take the form of SPARQL CONSTRUCT queries, or rule-based interpretations of recurring ontological patterns.

Starting with your own vocabulary can alleviate quite some burden and uncertainty when engineering your own project with interoperability by design at heart. As Niklas Emegård recently described it, it can feel like a “secret Linked Data hack”: you model what you actually need, using terms that make sense in your own context, and resist the urge to prematurely converge. When alignment becomes necessary, vocabularies can be linked across systems and projects, and those links can be reused wherever the same interaction patterns apply.

1
2
3
4
5
6
7
8
9
10
11
CONSTRUCT {
  ?student a other:Student ;
           other:name ?name ;
           other:identifier ?studentID .
  ?course other:hasStudent ?student .
} WHERE {
  ?student a my:Student ;
           my:name ?name ;
           my:hasStudentID ?studentID ;
           my:enrolledInCourse ?course .
}

The CONSTRUCT query above assumes a specific source shape and produces a target shape. Creating interoperability between systems then becomes a matter of maintaining a set of such transformations—versioned, testable, and scoped to concrete interactions—rather than prematurely converging on a single shared vocabulary.

If you want to hear these ideas from someone else, the great Ora Lassila (Amazon) recently did a talk at re:Invent 2025 in which he exemplifies reasoning using SPARQL CONSTRUCT queries. The talk shows how this ties in with Generative AI, and explains how he calls this kind of Linked Data approach Symbolic AI, as the knowledge graph can produce entailments.

I think Ora Lassila would agree if I’d say that writing these transformations by hand as SPARQL queries does not scale indefinitely. Once alignments are made explicit at the vocabulary level, they can be reused across multiple shapes. Simple statements such as equivalence or inversion between terms already provide enough structure to generalize alignments, and to derive concrete transformations from them. In that sense, vocabulary-level alignments act as inputs for shape-level interoperability.

1
2
3
4
other:Student owl:equivalentClass my:Student .
other:name owl:equivalentProperty my:name .
other:identifier owl:equivalentProperty my:hasStudentID .
other:hasStudent owl:inverseOf my:enrolledInCourse .

With just a small number of RDF statements, it becomes possible to express how terms in one vocabulary relate to terms in another. Those relationships can then be used to generate SPARQL CONSTRUCT queries automatically, or to guide their systematic creation. This is also where rule-based approaches, such as N3 (see Notation3), become relevant: they allow expressing interaction patterns once, and applying them repeatedly as new alignments are introduced.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
# More vocabulary statements from the OWL vocabulary
owl:equivalentClass a owl:SymmetricProperty .
owl:equivalentProperty a owl:SymmetricProperty .
owl:inverseOf a owl:SymmetricProperty .
# Rule for symmetric properties
{
  ?p a owl:SymmetricProperty .
  ?s ?p ?o .
} => {
  ?o ?p ?s .
} .
# Rule for equivalent classes
{
  ?c1 owl:equivalentClass ?c2 .
  ?x a ?c1 .
} => {
  ?x a ?c2 .
} .
# Rule for equivalent properties
{
  ?p1 owl:equivalentProperty ?p2 .
  ?s ?p1 ?o .
} => {
  ?s ?p2 ?o .
} .
# Rule for inverse properties
{
  ?p1 owl:inverseOf ?p2 .
  ?s ?p1 ?o .
} => {
  ?o ?p2 ?s .
} .

Once this mechanism is understood, as demonstrated by Eyeling, it becomes clear why this approach fits so naturally with eventual interoperability. Alignments can be introduced incrementally, applied at different points in the data pipeline, and revised without destabilizing the source model. The question remains: how do we make all of that manageable as part of the assets, such as shapes and vocabulary terms, in a specifications strategy.

Specifications as building blocks

When you start a project, you will start from the business case and describe what needs to happen. Something comes in, some decision logic runs, and something comes out. That input may come from a user who writes into your system, or from a dataset you fetch elsewhere. The output may be a state change of your own resources, or a response that another system will act upon. It is this processor—the part where you validate, transform, and decide—that you want to design with interoperability mechanisms in mind. If you do that well, your service is not only useful locally, but can also operate in a cross-border context without a redesign.

I therefore approach a project, an API, or even a data space connector, as a collection of interaction patterns. An interaction pattern is a protocol or procedure that describes a repeatable exchange: what the parties send, what is checked, and what is produced. Some patterns are generic and recur across domains—think verifying credentials using the W3C Verifiable Credentials pattern, or doing discovery and contract negotiation using the Dataspace Protocol. Other patterns are domain-specific: they capture how your business process works, and they encode the decisions that make your organisation’s service what it is.

This is the engine behind reusability. Instead of building one monolithic API that bakes everything into a single bespoke interface, I can compose a system out of interaction patterns. Each interaction pattern relies on input and output shapes to define what comes in and what goes out. These shapes in turn reuse terms from vocabularies, and vocabularies become the level on which I can express alignments and reuse them across patterns and across projects.

This layered approach lets me keep authenticity where it matters. I can reuse interaction patterns as a whole for generic functionality, and I can still define domain-specific patterns using my own shapes and vocabulary. Later, when a business case appears, I can link my vocabulary to another domain model—provided I captured enough semantics up front. If I only collect a single “name”, it becomes hard to map to a model that distinguishes first and last name. At the same time, I do not want to force that split, because not all cultures worldwide share the concept of first and last name (hat-tip to my colleague Sitt Min Oo here). This is exactly why I keep insisting on semantic richness at the source: it preserves optionality without forcing early consensus.

None of this is a manifesto against standardisation: quite the opposite. When a standard interaction pattern exists and fits the business case, adopting it as a whole is often the fastest path to interoperability and to working software. Good examples are standards such as the W3C Verifiable Credentials specification or the Dataspace Protocol that define an interaction pattern together with the shapes that make that pattern executable. Such interaction patterns are the more reusable patterns one can use in an API. Also for your domain-specific interaction patterns, standardisation remains important to make alignments scale. Standardised reference models are helpful assets: if everyone aligns to the same terms, alignments become more cost-efficient.

Neither is it a manifesto for chaos: this abstraction does not come for free. It requires better governance of specifications as first-class assets: interaction patterns, shapes, vocabularies, and the alignments between them. The cost is additional conceptual structure next to the API surface. The benefit however is that these components become reusable across projects and organisations, enabling more generic data infrastructure—an important property for data intermediaries and cross-organisational platforms.

Conclusion

I’m hopeful 2026 will be the year of a new approach to interoperability. There’s a new school of pragmatists rising, working on interoperable solutions with Semantic Web and Linked Data technologies at the core. The biggest shift is to not align from the start, but choose technology that supports reusability of components, evolvability, and of course eventually aligning when it comes to the resources you control.

We must ensure interoperability is not being perceived by your management as a distraction, but as an extremely useful asset. This is certainly relevant in public services, as the Interoperable Europe Act now mandates an interoperability assessment at the start of a project by a public administration in Europe. The consequence of that must be that a layered approach will be adopted to make API specifications more reusable. And, when cross-border use cases are identified, your domain-specific interaction patterns should be able to remain stable by just creating alignments on the vocabulary level.

So, in summary, don’t prematurely adopt existing terms just for interoperability’s sake. Start from your own terms. You can align later on when it is important. Spend effort early on preparing for interoperability by minting stable identifiers and documenting explicit semantics. Approach your API as a puzzle of interaction patterns. Some patterns will be generic standards you can reuse; others will be domain-specific. Document the latter, and adopt a layered specification approach in which interaction patterns use shapes, and shapes in turn reuse terms from vocabularies. Vocabulary-level alignments then become the driver for scaling eventual interoperability across projects and ecosystems.

P.S.

Trustflows

On the 19th of January, our four-year research project called SolidLab comes to an end. We’ll launch a continuation of the community under a new name: Trustflows. Trustflows starts from three main learnings:

1. We’ll design data systems as data flows from the initial write to one or more read interfaces.
2. We’ll separate authorisation from storage, so that a separate component can grant access to a resource, even if it travels across storage systems managed by different organisations.
3. A specification strategy that follows what I explained in this post.

The European Interoperability Framework (EIF)

The Commission's first Annual Report on Interoperability in the Union sheds light on the state of play as the Act is moving from legislation to practice. Governance is now in place as the Interoperable Europe Board has been instated, the European Interoperability Framework from 2017 (mainly focussing on Open Data) has been adopted by all Member States into a National Interoperability Framework, the Interoperable Europe Portal and Community are operational, interoperability assessments became mandatory, and sandboxes and the Interoperable Europe Academy are growing. Finally, also a catalogue of interoperable solutions is being created.

It’s worth keeping an eye on these developments, certainly with the European Interoperability Framework that is going to be revised in 2026.

SHACL Rules

Next to N3 rules, a new kid on the block will be SHACL 1.2 rules. It was just published into a first public working draft. It starts from SPARQL CONSTRUCT queries, and then adds N3-like functionality to it by defining a RULES clause.

I’ll be keeping an eye on the spec to see what the benefits could be over N3 that has a very long history already. For now, I’ll keep using the latter.