When Ontologies Meet APIs
Appreciating Kurt Cagle’s thinking on context, shape, and meaning
Every now and then, someone from a seemingly different space writes something that feels deeply familiar. Kurt Cagle’s post
is one of those rare moments where two worlds, ontologies and APIs, start to sound like they are describing the same thing, just in different vocabularies.
His argument touches on something that those of us in the API space have been sensing for years. The world is messy. Meaning is contextual. Interfaces and data models do not exist in isolation; they live within evolving conversations. And maybe the biggest illusion we keep trying to preserve is that there could ever be something like a global model of truth.
Meaning emerges, not from models but from interaction
Kurt uses the example of a casual conversation at a cocktail party to show how people negotiate meaning through context. The term “bill” shifts its meaning depending on who is listening and what they already know. This small story captures something essential. Meaning is deferred until enough context exists to disambiguate it. Ontologists call this deferred classification.
In the world of APIs, this dynamic is mirrored every day. An API specification is not a final statement of truth. It is a conversation starter, a working agreement that evolves as producers and consumers interact. Within the APIOps Cycles, this continuous refinement is the heartbeat of the process. Design, deploy, observe, evolve. Meaning crystallises through use. It is less about defining everything up front and more about creating the right loops to refine understanding over time.
Scoped meaning and bounded contexts
Kurt questions the idea of global identifiers, arguing that all meaning is scoped to the authority that defines it. That idea aligns almost perfectly with how Capability Thinking views organisations. Each capability defines its own bounded context, its own local ontology. Within that boundary, the world makes sense and identifiers are stable. Across boundaries, translation and alignment are required.
In the API world, this is the reason federated API management has become so relevant. It recognises that APIs express localised worldviews. There is no single shared ontology across an enterprise. What we can build, however, are the structures to navigate between them. Capability Thinking provides those structures conceptually. Federated management provides them operationally.
Standards as social contracts
Kurt also draws attention to consensus and scope. When groups of people agree on how to use terms, they effectively create a scoped ontology, a contract for shared meaning. Standards emerge from this social process.
In API Thinking, standards and governance work in exactly this way. They are not there to impose control but to sustain coherence. Each team, each capability, has the autonomy to express its local view, yet governance ensures those views can be related and composed. This is what the APIOps Cycles describe when governance, design, and feedback are interwoven. Consensus becomes a dynamic and living process.
Context, intent, and affordance
Kurt’s example of “bill” shows that words are only meaningful within a context of intent and usage. APIs behave the same way. The field names in a payload tell us very little until we understand the capability behind them.
This is why Capability Thinking puts intent at the center. Instead of focusing purely on data or schema, it asks what action this API enables, what problem it helps to solve, and what capability it exposes to others. Meaning arises from affordance, not from syntax. It is a shift from describing the world to describing what we can do in the world.
Local identifiers and federated sense-making
Kurt’s reflection on local identifiers could almost be read as a description of federated API landscapes. Each domain issues its own identifiers under its own authority. Uniqueness exists only within context. The combination of value and issuing domain forms the qualified meaning.
In federated API management, we see the same principle. Instead of a single registry of global truth, we have interconnected catalogs that preserve local autonomy but remain discoverable through context. It is a living map of local ontologies that form the enterprise’s semantic fabric.
Evolving systems and continuous learning
What stands out most in Kurt’s writing is his view of knowledge graphs as evolving systems. They learn by refining themselves as new information arrives. They are not static models but adaptive representations of reality.
The APIOps Cycles embody the same idea operationally. APIs evolve through observation and feedback. Usage metrics, consumer experience, and telemetry all feed back into design. The API landscape becomes a learning system. It is, in a sense, a symbolic system that continually reshapes its own ontology based on interaction and evidence.
Capability Thinking adds another dimension to this. It ensures that this learning connects back to business purpose. Each iteration of an API is not just a technical adjustment but a refinement of how the organization expresses what it can do. Over time, the landscape becomes a living capability graph.
Shapes, schemas, and shared understanding
Kurt highlights SHACL as a powerful way to define shapes, structured patterns that describe how entities and relationships are expected to look. APIs have their own shape languages: OpenAPI, AsyncAPI, GraphQL Schema all define how interactions are structured and constrained.
These shapes enable validation and composition. More importantly, they allow shared understanding without demanding global uniformity. Within APIOps Cycles, these definitions are treated as living artefacts that evolve alongside the systems they describe. Patterns emerge, get recognised, refined, and sometimes retired. Governance in this context acts like the ontologist pruning the evolving taxonomy of interfaces.
From ontologies to capabilities
At the heart of both perspectives lies a belief that structure and meaning must evolve together. Kurt’s evolving ontologies and Capability Thinking’s evolving capabilities describe the same phenomenon. Each capability is a local ontology of intent and behaviour. Its API expresses that ontology to others.
When connected across an enterprise, these capabilities form a federated graph, not of data but of meaning and purpose. The relationships between them are governed through standards, feedback, and shared understanding. This is where the ontology and API spaces begin to converge. They are both about creating sustainable coherence in a world that refuses to be globally uniform.
Looking ahead
Kurt Cagle’s work reminds us that the boundary between symbolic knowledge systems and API ecosystems is thinner than it seems. Both are attempts to make meaning explicit without freezing it. Both rely on feedback and context to stay relevant. Both recognise that semantics live in interaction, not in definitions.
As API Thinking continues to evolve and as knowledge graph technologies mature, the two domains are likely to meet in the middle. We may soon speak of APIs as semantic surfaces over organisational ontologies or of knowledge graphs that learn through API telemetry. Either way, it will be the shared recognition that meaning is local, contextual, and evolving that brings these spaces together.
This article comes at a perfect moment, as your insight that 'the biggest illusion we keep trying to preserve is that there could ever be something like a global model of truth' truly resonates with the contextual nature of meaning in real-world data arcitectures, a point I frequently discuss with my students.