Menu
For working with GO taxon constraints (TCs) using onlyin:/neverin: superclass assertions
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | taxon-constraint |
| description | For working with GO taxon constraints (TCs) using onlyin:/neverin: superclass assertions |
Taxon constraints are edited directly in src/ontology/go-edit.obo.
A GO term gets a taxon constraint by asserting is_a to one of these
materialized classes:
is_a: onlyin:33213
is_a: neverin:4896
is_a: onlyin:4952 {source="PMID:10629216", source="PMID:14504266"}
The class labels are "only in " and "never in ". OBO comments
after ! are helpful when present, but do not rely on them being preserved by
serialization for these internal idspaces.
These should generally be done under instruction. You should balance following user instructions with parsimony. Sometimes it is better to:
neverin: constraints to a more general clade than requestedonlyin: constraints to a more general clade than requestedHowever, great care can be taken. Don't assume TCs based just on the GO name. Sometimes GO will use terms like "heart development" in a very general way (encompassing insect 'hearts'), and sometimes in a more specific way.
Remember, if a term references an external ontology like CL and UBERON, it's likely these ontologies will have the appropriate TC, which is inherited. No need for duplication.
Use onlyin:<taxon_id> for only_in_taxon constraints and
neverin:<taxon_id> for never_in_taxon constraints. The local ID is the
NCBITaxon local ID with the NCBITaxon: prefix removed:
NCBITaxon:33213 becomes onlyin:33213NCBITaxon:4896 becomes neverin:4896NCBITaxon_Union:0000023 becomes onlyin:Union_0000023Union/grouping taxa are only used for onlyin: constraints. Do not create
neverin:Union_* constraints. Prefer multiple separate neverin: constraints when
multiple taxa are needed.
If the needed atomic taxon class does not exist, add the taxon to
src/ontology/imports/taxon_constraints_seed.txt and regenerate
src/ontology/imports/go-taxon-constraint-classes.ofn. Union classes come from
src/ontology/imports/go-taxon-groupings-edit.owl.
Check whether a class exists before using it:
rg "only-in/NCBITaxon_33213|never-in/NCBITaxon_4896" src/ontology/imports/go-taxon-constraint-classes.ofn
Put evidence on the is_a axiom as source annotations. Multiple sources are
multiple annotations on the same axiom:
is_a: onlyin:4952 {source="PMID:10629216", source="PMID:14504266"}
Use the same care as before: research both phylogeny and GO term usage, and report the evidence when communicating on the issue or PR.
Use OAK with the OLS adapter:
runoak -i ols:ncbitaxon info Mammalia
For ordinary term edits, validate the ontology as usual. The old
only_in_taxon.tsv / never_in_taxon.tsv column checks no longer apply.
Useful targeted checks:
cd src/ontology && make check_all_taxon_constraints_columns
cd src/ontology && make imports/go-taxon-constraint-classes.ofn
Run the import regeneration target when you change
taxon_constraints_seed.txt or taxon grouping definitions. Otherwise, adding an
is_a: onlyin: or is_a: neverin: axiom in go-edit.obo should not require
regenerating the class import.
When obsoleting a term, you may need to remove the taxon constraint, as these should never point to obsoletes
Use whenever you run a Makefile target (e.g. `make travis_build`, `make test`, `make reasoned.ofn`) or any one-off ROBOT / owltools / dosdp-tools / scala-cli command derived from a Makefile recipe. These must run inside the pinned ODK Docker image, not against host tools. Covers validation, reasoning, imports, and release builds in src/ontology.
For handling the process around obsoleting GO terms. This is a complex process involving substantial analysis of impact, both on existing terms that reference to the to-be-obsoleted term, and on annotations
Use the /research skill when performing background research from the literature or the web to create a RESEARCH.md file; also covers use of `deep-research-client`
For working with any terms referencing chemical entities (CHEBI). CHEBI has some unusual properties that are counter-intuitive, so always use this skill to plan or check work that involves a chemical entity or CHEBI IDs, whether a new term, or significant alteration of existing terms
Use this skill when planning to create new ontology terms or modify existing ones to ensure proper design pattern compliance. This skill should be used proactively during issue planning to identify appropriate design patterns before term creation begins. No intersection_of tags should be added without using this skill.
Use this to search for relevant terms in external ontologies. NEVER guess ontology terms or term IDs, always confirm using this skill. The general methodology is to use `obo-grep.pl`