Principle: Textual Definitions (principle 6)
- Open (principle 1)
- Common Format (principle 2)
- URI/Identifier Space (principle 3)
- Versioning (principle 4)
- Scope (principle 5)
- Textual Definitions (principle 6)
- Relations (principle 7)
- Documentation (principle 8)
- Documented Plurality of Users (principle 9)
- Commitment To Collaboration (principle 10)
- Locus of Authority (principle 11)
- Naming Conventions (principle 12)
- Notification of Changes (principle 13)
- Maintenance (principle 16)
- Responsiveness (principle 20)
GO TO: Recommendations/Requirements | Implementation | Examples/Counter‑Examples | Criteria for Review | Feedback/Discussion
The ontology has textual definitions for the majority of its classes and for top level terms in particular.
A textual definition provides a human-readable understanding about what is a member of the associated class. Textual definitions are, optimally, in concordance with associated machine-readable logical definitions (the latter of which are OPTIONAL).
Recommendations and Requirements
Textual definitions MUST be unique within an ontology (i.e. no two terms should share a definition) and be written in English. Textual definitions SHOULD follow Aristotelian form (e.g. “a B that Cs” where B is the parent and C is the differentia), where this is practical.
For terms lacking textual definitions, there should be evidence of implementation of a strategy to provide definitions for all remaining undefined terms. In lieu of textual definitions, there can be elucidations when the term can not be rigorously defined. Note that textual definitions can be programmatically generated from logical definitions, if available (see http://oro.open.ac.uk/21501/1/). In addition, Dead Simple Ontology Design Patterns (DOSDPs) can be used to generate both textual and logical definitions. DOSDPs are design specifications, written in YAML format, that specify structured text definitions and logical definitions for groups of ontology terms. These are widely used in many OBO Foundry ontologies, such as Mondo and uPheno. For some example patterns, see Mondo patterns and uPheno patterns.
Logical definitions, when present, should agree with textual definitions and vice versa. This is important for two reasons: (1) Reasoners classify terms solely based on logical definitions, while humans predominantly classify terms based on textual definitions, and mismatches between the two can cause unexpected misclassification; and (2) Curators could create incorrect annotations. An example of mismatched definitions:
http://purl.obolibrary.org/obo/OBI_0003243 blood assay datum Text definition: "A data item that is the specified output of a blood assay."
Logical definition (that does not match the textual def):
= 'information content entity' and (is_specified_output_of some 'blood assay')
Logical definition (that matches the textual def):
= 'data item' and (is_specified_output_of some 'blood assay')
While both logical definitions can be used to define the class, one better fits with the textual definition than the other.
Note that it’s permissible to not to have a logical definition if the class is fuzzy or the axioms/relations can’t be composed equivalence axioms.
Terms often benefit from examples of usage, as well as editor notes about edge cases and the history of the term, but these should be included as separate annotations and not in the definition.
Instances, such as organizations or geographical locations, can benefit from definitions although it is understood that definitions for instances are not required. It is recognized that OBO format (e.g., versions 1.2 and 1.4) does not allow this as an option.
Textual definitions should be identified using the annotation property: ‘definition’ http://purl.obolibrary.org/obo/IAO_0000115. The source of the definition should be provided using the annotation property ‘definition source’ http://purl.obolibrary.org/obo/IAO_0000119, or as an axiom annotation on the definition assertion.
An example of providing source in an axiom annotation:
<http://purl.obolibrary.org/obo/GO_0000109> rdf:type owl:Class ; <http://purl.obolibrary.org/obo/IAO_0000115> "Any complex formed of proteins that act in nucleotide-excision repair."@en ; rdfs:label "nucleotide-excision repair complex"^^xsd:string . [ rdf:type owl:Axiom ; owl:annotatedSource <http://purl.obolibrary.org/obo/GO_0000109> ; owl:annotatedProperty <http://purl.obolibrary.org/obo/IAO_0000115> ; owl:annotatedTarget "Any complex formed of proteins that act in nucleotide-excision repair."@en ; <http://www.geneontology.org/formats/oboInOwl#hasDbXref> "PMID:10915862"^^xsd:string ] .
this corresponds to the obo format:
id: GO:0000109 name: nucleotide-excision repair complex def: "Any complex formed of proteins that act in nucleotide-excision repair." [PMID:10915862]
Class: primary phloem sieve element
Term IRI: http://purl.obolibrary.org/obo/PO_0025452
Definition: A sieve element (PO:0025406) that is part of a portion of primary phloem (PO:0006075).
'sieve element' and ('part of' some 'primary phloem')
Class: ecto-epithelial cell
Term IRI: http://purl.obolibrary.org/obo/CL_0002077
Definition: An epithelial cell derived from ectoderm.
'epithelial cell' and ('develops from' some 'ectodermal cell')
- No definition
- Circular/Self-referential definition “A chromatography device is a device that uses chromatography” when chromatography is not defined elsewhere
Criteria for Review
Each definition MUST be unique. Each entity MUST NOT have more than one textual definition (tagged using IAO:0000115). Textual definitions SHOULD be provided for most terms, and for top level terms especially.
This check is automatically validated.
Feedback and Discussion
To suggest revisions or begin a discussion pertaining to this principle, please create an issue on GitHub.
To suggest revisions or begin a discussion pertaining to the automated validation of this principle, please create an issue on GitHub.