We keep hearing the same story: there’s more data than ever, and somehow we still can’t make the right decision. Earth observation satellites, sensor networks, corporate disclosures, government registries, decades of research output are all piling up. Yet when someone actually needs to answer a concrete question (“how exposed is this watershed to flooding, and what will that mean for the people living in it?”), the honest answer is usually: it depends who you ask, how long you’re willing to wait, and whether you happen to know the right modeler or can pay for the consultancy. The accumulation of data, without the knowledge of how to appropriately reuse it, can actually make it harder for the decision maker.
The real bottleneck is integration
Every dataset and model out there was built inside its own little world — its own units, definitions, and assumptions about what a variable even means. Reusing any of it means someone has to sit down and manually translate between those worlds, over and over, project after project. That translation work is expensive, invisible, and rarely gets reused itself. So while information is more abundant than it’s ever been, usable knowledge is scarcer than ever.
On top of that, much of this information sits behind walls — proprietary platforms, closed data products, systems built to keep control centralized. Meanwhile the problems we’re trying to solve (climate adaptation, biodiversity loss, water security) are multi-scaled, complex, and distributed in space and time. They need knowledge that can move as freely as the problems themselves.
Where k.LAB comes in
A genuine knowledge commons – not a portal or a data service – lets meaning itself travel across disciplines and institutions. Talking about a “semantic commons” in the abstract is easy; building the plumbing for one – as we’re doing with k.LAB – is hard. That infrastructure lets datasets, models, and services directly talk to each other without a human translator in the loop every time.
The way k.LAB does this is simple to describe: you ask it to observe a concept in a context — say, “flood exposure” in a particular watershed — and k.LAB figures out, on its own, which resources and models need to be assembled to answer that question in that context. k.LAB supplies a live resolution process that assembles the right computation, based on integrated, cross-domain science, on the fly, using a shared semantic backbone (what we call the worldview) to judge which resources actually fit the question and the context. It thus differs from keyword searches, fixed computational pipelines, or LLM-based queries and tools.
What comes back is more than just a result – numbers, maps, or sequences of events. It comes bundled with its own provenance — the full trail of how it was computed, so it can be checked, reproduced, or challenged rather than just trusted on faith. That bundling of meaning plus method plus proof turns “open data” into something you can actually act on.
Observations can persist as a living object as part of a digital twin, making it more than just a one-off answer. It can keep updating as conditions change, respond to new events, and connect to other twins across a wider network. That’s a different proposition from the “digital twin as a massive monolithic model” idea that many big Earth-system initiatives are still chasing. Once again, semantic resolution enables the composition of adaptive, dynamic, and epistemically bounded digital twins. k.LAB’s twins stay bounded and hierarchically composable — city twins composing a watershed twin contributing to a biodiversity twin – linking through shared semantics rather than getting merged through direct embedding or hard URLs into one unwieldy unit.
Under the hood, k.LAB is a distributed infrastructure composed of four services that each own a distinct piece of the problem. A resources service keeps track of what knowledge actually exists; a reasoner knows what things mean; a resolver builds a plan to answer queries; and a runtime runs that plan and keeps the resulting digital twin alive and accessible. The four are intentionally separable — an institution can run just the pieces it cares about, or all four, and many instances of each service are designed to exist and interoperate. A lightweight mechanism called a scope carries your identity and context across all of them, so a request that touches many different services run by different organizations still behaves like one coherent workflow instead of many disconnected API calls. The semantic commons can be built as a dynamic network of Resources services, plus enough instances of the other services to support load distribution and replication. In addition, the Resources service API directly supports a more modern vision for the peer review process: one where the first-class objects are the directly actionable knowledge assets, and their review status affects their prioritization as well as their relative visibility across the commons.
Nobody owns the whole thing
One architectural detail matters enormously in practice: there is no central authority. Just like the World Wide Web, the semantic commons functions as a network of independently run nodes and services — some publishing data, others hosting models or just managing access — all speaking the same semantic language. Institutions can run their own piece of it, keep access control and full ownership over their own resources, and still plug into the wider commons. The whole stack is open source, which means anyone can stand up a node, inspect how it works, or improve it.
That distributed design gives the commons resilience — no single point of failure, technical or political, can put the entire infrastructure at risk.
A commons is a community, not a repository
None of this technology, on its own, makes a commons. A commons is a governed entity — an agreement about who contributes, who benefits, how quality gets maintained, and how the whole system avoids capture by whoever had the most leverage. k.LAB provides the technical primitives to make that governance possible — provenance, controlled access, semantic alignment — but the incentives and the rules are still built by the people using it.
Concretely, that means first of all that the “worldview” — the shared vocabularies that let everyone’s data and models actually understand each other — can’t just be one team’s private ontology. It needs the open, accountable process of a healthy open-source project: people accountable for maintaining coherence and running the tooling, domain experts who own the relevant definitions, and a clear path for anyone to propose a new concept, debate it, and see it move from draft to accepted (or retired if it stops being useful). AI can help with drafting and search, but it doesn’t get to define meaning — that remains a human, accountable process. In k.LAB, specialized review workflows are built to support the community so that the shared worldview can evolve in traceable, safe and self-consistent ways.
Opening things up doesn’t mean that “everything becomes free,” but that the semantics, the metadata, and the APIs are open and unbundled public goods. This enables meaning to travel freely, while still keeping ownership of content that cannot always be freely provided: compute, support, training, customization, specialized validation. Providers who participate see wider reach, better reputation, sharper quality through reuse, and less exposure to being trapped behind someone else’s platform. All options remain open; those who share solve more problems and see their own value increase. Integration becomes the actual value proposition.
What “democratizing” this really means
Too often, the phrase “democratizing science” just means “we shared our data by uploading a CSV file somewhere.” Making knowledge genuinely usable by more people in the AI age implies the ability to search by what you actually need to know — “soil organic carbon,” “flood exposure probability” — instead of hunting for the right file name, model, or consultant. It also means not needing to delegate the answer to a corporate-owned search tool, or an opaque language model whose answers you cannot trust for decision. The output should already fit your place, time, and scenario, without requiring an advanced degree to fully understand. And it should come permanently bundled with enough provenance so that anyone can check how it was produced, reproduce it, find its weak points, and enable constant improvement – one of the main lessons that open source software has taught us.
That last part is critical: a lot of “open science” stops at findable and accessible and never really gets to being interoperable and reusable in any deep sense — the two FAIR Principles that a semantics-first approach like this is built to deliver on.
Why we’re saying this now
k.LAB has been developed and refined for years, and ARIES has been put to good use, remaining popular in contexts from the very local to the global, and nearing 10k active users. But k.LAB 0.11, the version that runs our most popular applications such as ARIES for SEEA, remains a research-grade tool — powerful, but hard for outside institutions to stand up and own, so that the federated architecture it was envisioned to support could be built. Version 1.0 changes that. It replaces the version 0.11 infrastructure with the four independent, separately deployable services mentioned above, each with a clearly defined job and a proper API — which enable true federation. A university can run a Resources service next to its own datasets, a statistical agency can run one near its authoritative, public-facing registries, a compute center can host a pool of Runtime services with different performance profiles, and a semantics-focused institution can coordinate the worldview and deploy scalable Reasoners serving different tiers of expertise — all while participating in the same commons without anyone having to centralize anything. An easily installed modeler software enables anyone to develop, test and run knowledge artifacts and dataflows locally, until they’re ready for sharing or not.
k.LAB 1.0 also brings an improved set of languages for the different jobs in this pipeline: one for defining the shared vocabulary itself, one (k.IM) for annotating real resources and publishing models against that vocabulary, and one (k.Actors) for giving observations and digital twins live, reactive behavior — the ability to respond to a threshold being crossed, a new observation arriving, or another twin’s state changing. Semantics itself becomes the query language for the commons. Put together, they let scientific observations graduate from being one-off computation results to living resources: provenance-rich, semantically explicit data and computational pipelines that remain to provide provenance, history and comparison when better knowledge becomes available.
While k.LAB 0.11 keeps serving many thousands of users through ARIES and its applications, the TODO list for the k.LAB 1.0 release gets shorter by the day. This post is the first, and the less technical, of several where the various components of k.LAB will be defined, eliciting comments and documenting progress as the release gets closer. For now, the short version is this: if a semantically aligned knowledge commons is going to be more than a nice idea in a white paper, it needs infrastructure solid enough for independent institutions to build on without asking anyone’s permission first. That’s what k.LAB 1.0 is being built to provide.
See you around!
ferdinando
