From Labels to Meaning: Ontology-Grounded Schemas for FAIR Data

A column called diagnosis tells a machine almost nothing. Is it a disease, a symptom, a billing code, or a paragraph of a clinician's notes? For research data to be genuinely reusable, that ambiguity has to resolve somewhere — and the place it resolves is a shared ontology. This is how CoreModels helps you attach real, resolvable meaning to a schema element, one term at a time, with a person always making the final call.

The word "diagnosis" is not a definition

Every dataset is full of column names that feel obvious to the team that made them and mean nothing to anyone else. diagnosis, status, subject, outcome. Inside one lab, everybody knows that diagnosis holds a normalized disease label and never a symptom. Six months later, or one collaboration over, that shared understanding is gone. The label survives; the meaning does not.

This is the quiet tax on research data. Two studies both have a diagnosis column, both look joinable, and neither team can safely merge them because nobody can prove the two columns mean the same thing. The name is a promise with no one standing behind it.

The fix is not a better naming convention. It is to stop relying on the name at all, and point each element at a definition that lives outside your project — a term in a public ontology that many other datasets already point at too. That is what turns a label into meaning.

FAIR data, and where interoperability actually lives

The FAIR principles — that data should be Findable, Accessible, Interoperable, and Reusable — are the baseline expectation for research data meant to outlive the project that produced it. The first two are largely about identifiers and access. The hard ones are Interoperable and Reusable, and interoperability is not something you can assert about your own schema. You inherit it by referencing vocabularies that other people also reference.

For biomedical and life-sciences data, those vocabularies are well established and openly published: Mondo for diseases, the Human Phenotype Ontology (HPO) for phenotypic features, the Experimental Factor Ontology (EFO) for experimental variables, and many more. Each term has a stable IRI — a globally resolvable identifier — that means exactly one thing and keeps meaning it. When your diagnosis column points at a Mondo IRI, you are no longer asking a collaborator to trust your naming. You are handing them a coordinate in a vocabulary they can look up, reason over, and align to their own data.

CoreModels reaches these ontologies through the Ontology Lookup Service (OLS), the public search service operated by EMBL-EBI over dozens of curated ontologies. No credentials, no vendor lock-in — just a query against vocabularies the research community already maintains in the open.

Suggest, decide, bind — in that order

Grounding a schema in CoreModels is a three-beat rhythm, and the order matters.

Suggest. Point our suggest_ontology_terms capability at a schema element — by its node, or just by a label and a short description — and we search OLS for you. You can narrow the search to the ontologies you trust for the job (say, EFO, Mondo, and HPO) and cap how many candidates come back. What returns is a ranked shortlist: for each candidate, the term's IRI, its compact CURIE, its label, a description, and which ontology it came from, in the relevance order OLS returned them. For an ambiguous diagnosis column, that shortlist is where the ambiguity finally gets forced into the open — you can see the difference between the disease concept, the phenotype concept, and the observation concept, and pick the one you actually mean.

Crucially, this step writes nothing. It is advisory, full stop. Every response carries the same reminder: suggestions are advisory only, nothing was written, and binding a chosen IRI is a separate act. We built it that way on purpose. A machine can rank candidates; it should not get to decide what your data means.

Decide. A person reads the shortlist and chooses — or chooses none of them and refines the query. This is the load-bearing step, and it belongs to a human who understands the data. Meaning is the one thing in the whole pipeline we never auto-assign.

Bind. Once you have chosen, bind_ontology_term records exactly one thing: that this element maps to that IRI, in that ontology. It is a single, deliberate, admin-scoped write — an idempotent upsert, so binding the same term twice is a no-op, and it makes no external call because the decision has already been made. Change your mind later and unbind_ontology_term removes precisely that one binding and nothing else — never the element, never anything else attached to it.

That is the entire ceremony. Search is open and cheap and read-only; the commitment is small, explicit, and reversible. Nothing about your model's meaning moves without a person moving it.

Bind once, and it travels everywhere

Here is the payoff, and the reason grounding belongs inside your modeling tool rather than in a spreadsheet on the side.

When you bind a term, CoreModels stores it as a first-class part of the element's definition — the same mapsTo carrier the rest of our export and integration machinery already reads. So the IRI is not a note in a data dictionary that drifts out of date; it is part of the model. And because every export reads from that one model, the binding shows up automatically wherever the model goes:

• In a LinkML schema, the bound IRI surfaces as the element's meaning — the exact slot LinkML reserves for an ontology reference, so downstream LinkML tooling reads it natively.
• In an OWL/Turtle ontology export, the grounded semantics come along as part of the emitted ontology.
• In a JSON Schema, the schema you hand to an application carries the same lineage of meaning.

You bind diagnosis to its Mondo IRI once. From then on, every format you export already knows what that column means. There is no second system to keep in sync, no annotation step to remember at export time, no chance that the LinkML says one thing and the JSON Schema says another. One decision, recorded once, propagates by construction.

Model once, deploy where research platforms actually consume it

Grounding is most valuable when the grounded model is also the model you ship — not a documentation artifact that diverges from what you deploy.

That is the whole point of modeling in LinkML with CoreModels: you author and ground the schema in one place, then generate the concrete formats that specific research platforms expect. LinkML is the durable, ontology-aware source of truth. From it, we produce the artifacts a platform like Synapse ingests — per-type curation manifest and dictionary templates ready for a data-curation workflow — so the meaning you bound upstream lands where researchers actually load and annotate data. The same grounded model can also come out as plain, standards-compliant JSON Schema for the tools that speak that instead.

Model once; deploy as the formats the platforms consume. The ontology terms you chose are not left behind in the modeling tool — they ride along into each deployment, because they were part of the model, not decoration on top of it.

Why "advisory only" is the feature, not the caveat

It would be easy to build a tool that reads a column name, guesses an ontology term, and writes it in. It would demo well. It would also be exactly wrong for research data, where a bad binding is worse than none — a confidently mislabeled diagnosis propagates through every export just as faithfully as a correct one.

So we drew the line deliberately. Suggestions are generated; meaning is chosen. Search never writes; binding is a distinct, explicit, reversible act by someone with the context to make it. This is the same honesty we apply everywhere in CoreModels: we do the tedious work of finding candidates and carrying your decision through every format, and we do not quietly decide, on your behalf, what your data means.

That is how a label becomes meaning — and how meaning, once set, becomes something your collaborators can actually reuse.

---

The ontology-grounding tools live on the CoreModels MCP server (OAuth-protected): suggest_ontology_terms is read-only and available on the public /mcp endpoint, while the admin-scoped bind_ontology_term and unbind_ontology_term sit on the admin endpoint — alongside the LinkML, OWL, and JSON Schema exports. See the CoreModels quickstarts to connect a client and ground your first schema.