// 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 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 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`
For working with mappings (dbxrefs) in GO.
For working with any terms in the catalytic activity branch; these often correspond to RHEA or EC terms
For working with GO taxon constraints (TCs), i.e never_in_taxon and only_in_taxon relationships
| name | design-pattern |
| description | 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. |
Design Patterns (DPs) are designed to ensure that labels, text definitions (def tags), logical definitions (intersection_of tags) are consistent within a term, and across terms. i.e. a term "X development" uses "X" in the label, definition, and logical definition (but prioritizing human readability over robotic conformance); and that "X development" terms look similar in form to "X development" terms.
Design patterns are documented here, using the DOSDP system:
src/patterns/*.yaml
This skill should provide documentation in the form of a DESIGN_PATTERNS.md doc (not committed) that document relevant DPs for the task at hand.
DP documentation may be incomplete or out of date, so always check for similar terms / precedent using obo-grep.pl.
Side Note: CHEBI has particular rules. Always use the /chemical-entity skill for anything involving chemical entities.
Consider this GO term:
id: GO:0001710
name: mesodermal cell fate commitment
namespace: biological_process
def: "The cell differentiation process that results in commitment of a cell to become part of the mesoderm." [GOC:go_curators, ISBN:0878932437]
synonym: "mesoderm cell fate commitment" EXACT []
is_a: GO:0060795 ! cell fate commitment involved in formation of primary germ layer
intersection_of: GO:0045165 ! cell fate commitment
intersection_of: results_in_commitment_to CL:0000222 ! mesodermal cell
relationship: part_of GO:0048333 ! mesodermal cell differentiation
This corresponds to this DP: src/design_patterns/cell_fate_commitment.yaml, which defines a variable 'target' that must be a type of cell:
vars:
target: "'cell'"
classes:
cell: "CL:0000000" # Should ensure plant cells are subclasses
It also defines lexical patterns:
name:
text: "%s cell fate commitment"
=> the name tag is consistent with this
def:
text: "The process involved in the commitment of %s cell identity."
=> the GO definition varies a little from this but is still essentially consistent
And a logical definition pattern:
equivalentTo:
text: "'cell fate commitment' and 'results in commitment of' some %s"
vars:
- target
The OWL expression equivalentTo G and R some D maps to
intersection_of: G
intersection_of: R D
You should not add logical definitions unless the term truly corresponds to a DP (or if a user really wants you to). A common anti-pattern is over-specifying logical definition (intersection_of), not realizing these are necessary and sufficient conditions. If in doubt, it is better to specify necessary only (is_a and intersection_of).
When intersection_of is specified, it's generally not necessary to specify an is_a parent because this can be inferred.
This can be checked via:
cd src/ontology && robot reason -i go-edit.obo -o go-edit.entailed.obo and checking the is_a parent
The output of this skill can be a document DESIGN_PATTERNS.md that lists and gives examples from the DP docs and existing ontology precedent, this doc will be used to guide term creation and updates, and to provide justification.
Note this document is temporary, it should not be committed, and do not waste time documenting DPs in general, this doc is for specifyng relevant DPs to the task in hand