OntoGPT and SPIRES: grounded extraction from text into LinkML schemas
LLM-based ontological extraction tools, including SPIRES
At a glance
- What is it?
- OntoGPT is a Python package that turns text into schema-conformant structured data by asking a language model for names, grounding them through OAK, and walking a LinkML schema one class at a time. It is built for reproducible batch extraction, not for autonomous agents.
- Who is it for?
- Adopt OntoGPT if you have a LinkML schema or one of the bundled templates and a corpus of abstracts or papers to process the same way every time. Do not adopt it if you need an agent that decides its own next step, or if you cannot supply ontology access and an API key.
- Can I use it commercially?
- Yes. BSD-3-Clause is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly Jupyter Notebook, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The failure OntoGPT was written to avoid: invented identifiers
Ask a general-purpose model for an ontology identifier and it will frequently produce one that looks plausible and does not exist, or attach a real identifier to the wrong term. The README states the design response plainly: OntoGPT does not ask the model for identifiers at all. It asks for names, grounds each name against the actual ontology through OAK annotators, and then validates every grounded identifier against its source ontology. A name that cannot be grounded is marked with the AUTO: prefix rather than guessed. The claim the project makes about its output is narrow and checkable: the only identifiers present are ones that exist. That is the whole pitch, and it defines the audience. This is for curators, biocurators and data modelers who already have an ontology or a LinkML schema and need text mapped into it at a scale where hand-reading is not an option. It is not a general text-to-JSON tool, and it is not a chatbot.
SPIRES: prompting one class at a time instead of the whole schema
The mechanism that distinguishes SPIRES from a single large prompt is recursion over the schema. A large data model does not fit comfortably in a context window, and the README notes that an agent searching the model field by field for each document is slow and expensive. SPIRES walks a LinkML schema recursively and prompts the model for one class at a time, with only that class's fields in the prompt. Each prompt therefore stays small, and the assembled result conforms to the full schema rather than to whatever subset happened to fit. The data flow is: text plus template plus model produce an extracted object, which is then grounded and validated. Output can be written as YAML, JSON, RDF or OWL. The README also mentions prompt caching and describes the procedure as repeatable and batchable, running from the command line or from Python over one abstract or thousands of papers, with no agent in the loop deciding what to do next. That last clause is a design position, not an oversight.
Templates are LinkML schemas, and the bundled ones are the practical entry point
The README says dozens of bundled templates cover diseases, phenotypes, drugs, genes, GO terms, environmental samples and more, each already wired to the right ontologies. A new template is a LinkML schema with a few annotations, and the documentation points to docs/custom.md for that. This is where the real adoption cost sits. If a bundled template matches your extraction target, the first run is a few commands. If it does not, you are writing a LinkML schema and deciding which ontologies each slot should ground against, which is ontology work rather than prompt work. The project's own framing supports that reading: the template plus a model is described as giving the same procedure for every document. Consistency across a corpus comes from the template, not from the model.
Install, keys and a first extraction
Python 3.10 or greater is required, and installation is pip install ontogpt. Credentials can be set through Oaklib with runoak set-apikey -e openai <key>, which the README shows as the quick-start step, and the same command accepts anthropic-key, mistral-key, groq-key, azure-key, azure-base and azure-version. Standard LiteLLM environment variables such as OPENAI_API_KEY, ANTHROPIC_API_KEY, GROQ_API_KEY, MISTRAL_API_KEY, AZURE_API_KEY, AZURE_API_BASE and AZURE_API_VERSION are supported directly, and the README says credential handling follows LiteLLM first, with Oaklib credentials checked afterward for backward compatibility. The quick-start example writes a one-line file and runs ontogpt extract -i example.txt -t drug. Output appears on the command line under extracted_object, with a validation section reporting whether each grounded identifier exists in its ontology and matches its label. Invalid ones are replaced when a valid term can be found. A minimal web interface exists behind pip install ontogpt[web] and the command web-ontogpt, and the README explicitly does not recommend hosting it publicly without authentication. Model selection uses ontogpt list-models, and the README says the most reliable form is a provider-qualified name such as openai/gpt-5.5 or anthropic/claude-sonnet-5. Without --model, OntoGPT uses gpt-5.5. If a provider is not encoded in the model name, --model-provider sets it explicitly, which the README calls out as most common for OpenAI-compatible proxy endpoints.
Reasoning models, temperature, and the retry you should expect
Reasoning models including the GPT-5 family and Claude Sonnet 5 and Opus 5 accept only their default temperature. If --temperature is set for one of these, OntoGPT logs a warning and retries the request without it. The practical consequence is that temperature is not a portable knob across providers. A pipeline that tunes sampling for one model will silently lose that setting when the model changes, and the only signal is a warning in the log. If your extraction quality depends on temperature, pin the model and treat the temperature flag as model-specific. Anthropic OAuth tokens beginning with sk-ant-oat may be supplied in ANTHROPIC_API_KEY, and the README says LiteLLM sends them with the bearer authorization the API expects. Model routers are handled the same way: store the key with runoak set-apikey -e openrouter-key <key> or set OPENROUTER_API_KEY, then prefix the model, for example --model openrouter/anthropic/claude-sonnet-4.5. The naming rule the README gives is that the runoak set-apikey name must match the provider in the model name.
Where OntoGPT is the wrong tool
The AUTO: prefix is the honest part of the design and also the limitation. A name that cannot be grounded is not dropped; it is emitted with that marker, which means downstream consumers must decide what to do with ungrounded values rather than receiving a clean record. If your ontology lacks coverage for the terms in your corpus, the output will contain a meaningful proportion of AUTO: entries, and no amount of prompt tuning fixes a missing term. The second boundary is the no-agent stance. OntoGPT will not decide which document to read next, which tool to call, or how to recover from an extraction that looks wrong. The README's answer to that need is the bundled Agent Skills, which teach an agent to call OntoGPT for the extraction and grounding step rather than reimplement it. If you want the reasoning loop itself, you are building it elsewhere. Third, every run depends on live ontology access through OAK plus a model API, so both are external dependencies in your pipeline. Fourth, the web application is described as bare bones and not recommended for public hosting without authentication, so it is a local viewer rather than a deployment target.
How this differs from asking a model for JSON directly
The obvious alternative is a single prompt that asks a capable model to return JSON matching your schema, with the ontology identifiers supplied as a list in the prompt. That approach collapses the whole pipeline into one call and needs no template, no OAK, and no schema walk. It also reintroduces exactly the failure OntoGPT was written around: identifiers come from the model's memory rather than from the ontology, and nothing validates them afterward. The difference is not model quality but where the identifiers originate and whether anything checks them. A second alternative is an agent framework that searches a data model field by field per document. The README's own comparison is that this is slow and expensive, and that SPIRES keeps each prompt small by prompting for one class at a time. The trade is that OntoGPT gives up the agent's flexibility in exchange for a fixed procedure that produces the same shape of output for every document in a batch.
Maintenance, licence and what to verify before you commit
OntoGPT is BSD-3-Clause, a permissive licence that generally allows modification and redistribution provided the copyright notice and licence text are retained; this is a description of the licence identifier, not legal advice, and you should read the LICENSE file and your own obligations. The repository is not archived, the default branch is main, and the release history shows v1.1.0 in March 2026, v1.1.1 in April 2026 and v1.2.0 in September 2026, so the project is being released rather than frozen. The upgrade cost that matters most is not the Python package but the templates and the provider surface. Because model naming, credential handling and temperature behaviour are routed through LiteLLM, moving to a new provider or a new model generation is a configuration change plus a re-check of extraction quality on your own corpus. The README's own note that reasoning models reject a set temperature is a small example of why that re-check is not optional. Before adopting, run ontogpt extract against a sample of your documents with the template you plan to use, then read the validation section to see how many identifiers were grounded and how many were replaced or marked AUTO:. That number, not the template list, tells you whether the tool fits your corpus.
Editorial conclusion
Adopt OntoGPT if you have a LinkML schema or one of the bundled templates and a corpus of abstracts or papers to process the same way every time. Do not adopt it if you need an agent that decides its own next step, or if you cannot supply ontology access and an API key. Before committing, run ontogpt extract on a handful of your own documents with the template you intend to use, then check the validation section to see how many identifiers were grounded and how many fell back to the AUTO: prefix.
Community notes