OBO Foundry Principles

From OBO Foundry

Principles Accepted as of 24 April 2006

1. The ontology must be open and available to be used by all without any constraint other than (a) its origin must be acknowledged and (b) it is not to be altered and subsequently redistributed under the original name or with the same identifiers.

2. The ontology is in, or can be expressed in, a common shared syntax. This may be either the OBO syntax, extensions of this syntax, or OWL.

3. The ontologies possesses a unique identifier space within the OBO Foundry.

4. The ontology provider has procedures for identifying distinct successive versions.

5. The ontology has a clearly specified and clearly delineated content.

6. The ontology must be orthogonal to other ontologies already lodged within OBO. For each domain, there should be convergence upon a single reference ontology that is recommended for use by those who wish to become involved with the Foundry initiative

7. The ontologies include textual definitions for all terms.

8. The ontology uses relations which are unambiguously defined following the pattern of definitions laid down in the OBO Relation Ontology.

9. The ontology is well documented.

10. The ontology has a plurality of independent users.

11. The ontology will be developed collaboratively with other OBO Foundry members.

Additional Principles adopted at the First OBO Foundry Summit Meeting on 7-8 July 2008

1. All candidate Foundry ontologies will appoint a person responsible for liaison with the OBO Foundry coordinating editors. This person will be a member of the Foundry Board of Associate Editors.

2. All candidate Foundry ontologies will provide a tracker for additions and corrections, and a help desk for inquiries from users.

3. Textual definitions will, by degrees, be complemented with equivalent formal definitions.

4. Textual definitions will use the genus-species form: An A =def. a B which Cs, where B is the parent of the defined term A and C is the defining characteristic of those Bs which are also As.

5. Single is_a inheritance: ontologies will distinguish a backbone ('asserted') is_a hierarchy subject to the principle of single inheritance (each term in the ontology has maximally one is_a parent in this asserted hierarchy). Further is_a relations may be inferred.

6. Instantiability: Terms in an ontology should correspond to instances in reality. (First audit trail principle.)

7. Terms should be created and defined using terms and relations drawn from other Foundry ontologies. (Second audit trail principle.) When the terms and relations needed to create definitions of Foundry terms do not already exist in the Foundry, they should be submitted for inclusion to the relevant ontology. In this way no useful term goes undefined, and we do not land up with definitions that are in terms that themselves are not defined (except for the upper level undefinables).

8. Evaluation. Each Foundry ontology should be subject to evaluation (as far as possible quantitative):

software (conversion OBO format <-> OWL), specialist review (OWL -> controlled English)

when one version is used for a given purposes later versions should be applied to the same purpose and results compared

9. Use of Basic Formal Ontology (BFO): Each Foundry ontology should be built on the basis of BFO top-level distinctions (common top level), selected along the following lines:

Does your ontology recognize both things that continue to exist (continuants) and also processes in which such things participate (occurrents)?

Does your ontology recognize a distinction between entities (qualities, functions, roles, dispositions, ...) which have bearers (specifically dependent continuants) and those bearers themselves (independent continuants: molecules, cells, organisms, etc.)

Does your ontology recognize information artifacts (sequences in a database, protocols, publications ...)?

10. Singular Nouns: Ontologies consist of representations of types in reality – therefore, their preferred terms should consist entirely of singular nouns.

11. Preferred terms should be nouns and noun phrases belonging to ordinary English as extended by technical terms already established in the relevant discipline – they should not employ phrases like ‘EV-EXP-IGI’; they should not employ lab slang, they should not employ ellipses.

Proposed Principles (still under discussion)

Canonical vs. non-canonical ontologies

• To make the RO all-some strategy work, we need to understand meaning of ‘all’. Does it mean: all instances, or: all canonical instances. Recommendation: Identify those ontologies which are canonical; establish the best way to treat canonicity.

Identifiers

• New page added with identifier recommendations: Identifiers