OBI Minimal metadata

This list represents the mandatory and optional metadata for representational units as agreed by the OBI coordinator committee. The proposed cardinalities are indicated in front of the name of the annotation property. Some are however still under discussion.

The OBI meta data is encoded as a separate file which is imported by OBI and can be reused by other communities see ontology-metadata.owl

Mandatory metadata: MUST be provided for both classes and relations

 * editor preferred term: The concise, meaningful, and human-friendly name for a class or property preferred by the ontology developers that reflects community usage, or disambiguates the term if necessary. (before 16.10.07 this was: The concise, meaningful, and human-friendly name for a class or property
 * Cardinality: each class must have a single editor preferred term
 * Implementation: annotation property specified as a functional property named "preferred term".
 * definition: The official OBI definition, explaining the meaning of a class or property. Shall be Aristotelian, formalized and normalized. Can be augmented with informal definitions to further explain the meaning of the term.
 * Cardinality: each class must have a single definition
 * Implementation: annotation property specified as a functional property named "definition".
 * term editor: The name of the editor of the definition.
 * Cardinality: each class can have many definition editors
 * definition source: An unambiguous and traceable reference to the source of the definition. Examples: ISBN, URI plus date, MeSH Term, PUBMED ID, DOI.
 * Cardinality: each class can have one or more definition sources
 * Implementation: annotation property named "definition source". See guidelines for providing sources for term definitions.
 * curation status:
 * Each class has a single curation status
 * The curation status of a class or property. The allowed values must come from this enumerated list of predefined terms:


 * Cardinality: 1..1
 * Implementation: enumerated value

Optional metadata: SHOULD be provided

 * example of usage: A phrase describing how a term should be used. May also include other kinds of examples, such as widely known subclasses or instances of the class. Although essential for high level terms, examples for low level terms (e.g., Affymetrix HU133 array) are not.
 * Cardinality: each class can have none, one, or more examples of usage
 * Implementation: annotation property named "example of usage".
 * alternative term: An alternative name for a class or property which means the same thing, i.e. semantically equivalent, as the preferred term.
 * Cardinality: Each class can have many alternative terms
 * Implementation: annotation property
 * editor note: A note containing points under consideration for further term development that may be included in released versions of the ontology. It should contain nothing embarrassing and something potentially useful for end users to understand the ontology. Editor notes should include the date of edit (YYYY/MM/DD) and the author.
 * Cardinality: Each class can have one, or many editor notes
 * Implementation: annotation property
 * curator note: An administrative note intended for the curator of the ontology. It will not be included in the released versions of the ontology, so it should contain nothing necessary for end users to understand the ontology. Curator notes should include the date of edit (YYYY/MM/DD) and the author.
 * Cardinality: Each class can have one, or many curator notes
 * Implementation: annotation property