Some of the most instructive hours I have spent in this field were spent watching a modeller begin a new model. The task is ordinary. A new public service needs to describe people, their addresses and a few kinds of permit. The modeller opens a catalogue and searches for “Person”, and a long list comes back, each entry published by a respectable body and carefully documented. Nothing on the screen says which of those models the organisations across the border actually use, which of them map to one another, or which one the nearest partner has already put into production. So the modeller does what any careful professional would do. They pick the entry that looks most complete, adapt it a little to the local need, and publish. Next year, the list is one entry longer.
Everyone in that scene behaved well, and that is what makes it worth looking at. The standards were good, the modeller was competent, the catalogue did its job. The result was one more model, because the decision was taken alone, with no view of what the peers had already chosen.
The idea I want to put forward in this piece follows from that scene. Semantic interoperability is a property of a whole ecosystem, produced by thousands of decisions like this one, taken by different people over many years. It appears when those decisions tend towards one another, and it fades when each is taken in isolation, however good the standards on offer. If that is right, the most useful work in our field is to create the conditions in which convergence can happen.
How a path forms across a lawn
Think of the footpath that appears across a park lawn. Nobody designs it. It forms where enough people choose the same route, and every walker who takes it makes it a little more visible, and therefore a little more attractive, for the next. Two things make it work. Each decision is local: one person, one walk, one moment. And each decision is shaped by what that person can see of the decisions before it.
Semantic convergence works the same way. A shared way of describing a person, a permit or a medicine pack emerges from many local modelling choices, and each choice is shaped by what the modeller can see of the choices already made. Take away the visibility and every walker starts a fresh path. That is what happened in the catalogue.
Seen like this, emergence asks for four conditions. In my experience, most programmes have one or two of them in place and assume the rest.
Convergence needs a destination
A model designed without knowing whom it must interoperate with has nothing to move towards. It will be internally coherent and broadly reusable, and it will drift, because “reusable by anyone” gives no direction to any particular decision. Interoperability always has a referent: two parties, exchanging something, for a purpose. A pension office needs to understand its counterpart in another Member State; a wholesaler needs to understand the manufacturer whose batch is being recalled.
So the first condition is that every modelling task names its counterparts, the systems and organisations on the other side of the exchanges that matter. Once they are named, a modeller has a direction, and the question “which model should I use?” becomes the far more answerable “which model do the parties I exchange with already use?”
Convergence needs to be visible
The path across the lawn works because the grass shows it. In our field, the trace of earlier decisions sits in the published models themselves: which models build on which, who has mapped their terms to whose, and which designs are running in production systems. That trace already exists in most ecosystems. It is rarely gathered, and it is almost never in front of the modeller at the moment of choice.
This is where convergence is won or lost, because divergence is seldom a dramatic event. It accumulates in small decisions, a new attribute here, a code list there, each taken under a deadline. When the evidence of what the peers chose is visible at that moment, the reasonable choice and the convergent choice become the same choice. When it is invisible, a reasonable person will keep producing new models, and nobody can blame them.
Convergence needs help at scale
At the scale of a national or European landscape there are thousands of semantic assets, published by hundreds of organisations, revised on their own schedules. People cannot do all of that comparison by hand, and expecting them to is one of the quiet reasons convergence stalls: the work that would align models is the work nobody has time for.
This is a task that modelling agents can carry, on two conditions. They have to be grounded in the evidence of what the ecosystem actually uses, and their choices have to be explained, so that the modeller can accept, question or override each one. An agent that proposes the most popular term without saying why simply adds a faster route to the same isolated decision.
Convergence needs a reason
Most efforts to reduce redundant models have relied on policy: guidelines, recommended vocabularies, mandates. Policy helps, and it gives convergence a direction and legitimacy. It also asks people to act against their short-term interest, because building your own model is usually quicker this quarter than learning someone else’s.
The most convincing case of emergence I know turns on incentive instead. In June 2011, Bing, Google and Yahoo launched schema.org, a shared vocabulary for describing things on web pages, and Yandex joined later that year. Publishers took it up because using it changed how their pages appeared in search results. Nobody was obliged to adopt it, and it spread across a large part of the web, because the reward for reusing it was immediate and visible to the person making the choice. It has its limits, and the convergence it produced follows the interests of the parties who rewarded it. As a demonstration of how incentive moves thousands of independent decisions in one direction, it is hard to beat.
Inside an ecosystem the same logic applies. A new model has to build its audience from zero, while a model that is already reused arrives with an audience attached. When that difference is visible and the tools make reuse cheap, reuse becomes the obvious choice, and the incentive does the work that policy could only request. This is the change that has moved my own thinking most: redundant models can be made unattractive, and that works far better than discouraging them.
Five questions for your own programme
If you run, fund or contribute to an interoperability programme, these questions will show you which of the four conditions are in place. Most of them can be answered from what you already know.
- Can each modelling team name its counterparts? Ask for the parties and exchanges a new model must serve, in writing, before the work starts.
- What does a modeller see before choosing? Look at the screen they use. If it shows definitions without showing who uses them, the visibility condition is missing.
- Who does the comparison work, and with what evidence? If the answer is “the modeller, in their spare time”, expect divergence.
- Is reuse the cheaper path today? Compare the effort of adopting an existing model with the effort of writing a new one, honestly, from the modeller’s side of the desk.
- Do your reports show convergence over time, or adoption on a date? A programme that watches only adoption will see the first and miss the second.
Tending the ecosystem
Standards keep all of their importance. Good standards are the paths worth walking, and an ecosystem without them has nothing to converge on. What changes is where the effort goes once they exist: into naming counterparts, making the evidence of earlier choices visible, helping modellers compare at scale, and making reuse the easy decision. At METALEVELS, that is the work we do, and it is the problem the framework we are developing was built around.
Interoperability is what a healthy ecosystem does.
If you would like to look at your own programme through these five questions, start a conversation with us.