OBO Foundry
A subset of OBO that fulfils certain criteria. OBO Foundry ontologies strive to be orthogonal with respect to one another, and use relations from the OBO Relations Ontology
Custodians
Michael Ashburner (Cambridge)
Suzanna Lewis (Berkeley)
Barry Smith (Buffalo/Saarbrücken)
Introduction
The OBO Foundry is a collaborative experiment, involving a group of ontology developers who have agreed in advance to the adoption of a growing set of principles specifying best practices in ontology development. These principles are designed to foster interoperability of ontologies within the broader OBO framework, and also to ensure a gradual improvement of quality and formal rigor in ontologies, in ways designed to meet the increasing needs of data and information integration in the biomedical domain.
The primary objective is to establish gold standard reference ontologies for individual domains of inquiry. We are striving for community acceptance of a single ontology for each domain, rather than encouraging rivalry among ontologies, which we believe defeats the purpose of ontology development. Each reference ontology will incorporate multiple perspectives wherever necessary, but it will do so always in such a way that the different perspectives work together within a common framework.
Our goal is to develop a set of ontologies which can be used in combination because they are based on common principles. The Foundry thus represents a new paradigm in ontology development. In contrast to existing methodologies, which rely on the creation of more or less ad hoc mappings between ontologies constructed independently by separate groups, the Foundry will attempt to guarantee interoperability of ontologies from the very start by working closely with ontology developers to ensure mutual compatibility.
By joining the OBO Foundry, the authors of an ontology commit to its maintenance in light of scientific advance, and to soliciting community feedback for its improvement. They also give an assurance that they will work with other Foundry members to ensure that, for any particular domain, there is community convergence on a single reference ontology. Application ontologies developed for specific purposes can then be referred back to this common reference, which will be updated in light of scientific advance. In this way application ontologies, too, for example the application ontologies developed for purposes of managing clinical trial data, can take advantage of the Foundry methodology.
Principles
(Version as of 24 April 2006.) Further principles will be added over time, in order to bring about a gradual improvement in the quality of the ontologies included in the Foundry.
1. The ontology is open and available to be used by all without any constraint other than (1) its origin must be acknowledged and (2) it is not to be altered and subsequently redistributed under the original name or with the same identifiers. The OBO ontologies are for sharing and are resources for the entire community. For this reason, they must be available to all without any constraint or license on their use or redistribution. However, it is proper that their original source is always credited. Furthermore, after any alterations by external users, they must not be redistributed using the original name or with the same identifiers.
2. The ontology is in, or can be expressed in, a common formal language. A provisional list of languages supported by OBO is provided at http://obo.sf.net/
The reason for this requirement is that the same tools can then be usefully applied. The use of standard formal languages facilitates shared software implementations.
3. The ontology possesses a unique identifier space within OBO.
The source of terms from any ontology can be immediately identified by the prefix of the identifier of each term. It is, therefore, important that this prefix be unique. Each term in the ontology must have a unique identifier comprehending also a unique identifier or namespace for the ontology itself.
4. The ontology provider has procedures for identifying distinct successive versions.
All maintained ontologies change over time and it is important that there is a rigorous way to refer to a particular version and to identify changes (including deletions or additions of terms) with respect to previous versions, as well as the reasons for such changes.
5. The ontology has a clearly specified and clearly delineated content.
An ontology should have a clearly specified subject matter, and the name of the ontology should make this subject- matter clear. An ontology devoted to, say, cell components should not include terms like: ‘database’, or ‘microscope’, or ‘photograph’. (These terms might, though, belong in other ontologies.)
6. The ontology includes textual definitions for all terms.
Many biological and medical terms may be ambiguous, so terms must be defined in such a way that their precise meaning is clear to a human reader. Some high-level terms may be declared to be primitive. Definitions should be in a form that is intelligible to human users. Equivalent computationally intelligible definitions should also be supplied (see criterion regarding relationships).
7. The ontology uses relations which are unambiguously defined following the pattern of definitions laid down in the OBO Relation Ontology.
The reason for this requirement is so that the meaning of particular relationships (e.g., is_a, part_of) are the same in all ontologies. This requirement is designed to facilitate integration of and reasoning over a plurality of ontologies.
8. The ontology is well-documented.
An ontology should have good overall documentation, which is clearly written for nonexperts in ontologies. This documentation should provide a clear description of the domain of the ontology, of how it can be used to support reasoning, and how changes and additions to the ontology can be proposed. (Examples of best practices in ontology documentation will be provided.)
9. The ontology has a plurality of independent users.
Interoperability of ontologies is not an end in itself, but is designed to facilitate new types of biomedical informatics experiment, involving computer-assisted combination of data derived from different sources. The data which drives such experiments will exist only when ontologies are set to work in different contexts and by independent sets of users.
10. The ontologies in the OBO Foundry will be developed in a collaborative effort.
Ontology developers agree in advance that when disagreements arise, the rationale for these disagreements will be documented and that good faith efforts will be made to resolve them in the spirit of scientific inquiry.
Initial Candidate Members of the OBO Foundry
GO Gene Ontology
CL Cell Ontology
SO Sequence Ontology
ChEBI Chemical Ontology
PATO Phenotype Ontology
FuGO Functional Genomics Investigation Ontology
FMA Foundational Model of Anatomy
RO Relation Ontology
Under development / review:
Disease Ontology
NCI Thesaurus
Mammalian Phenotype Ontology
OBO-UBO / Ontology of Biomedical Reality
Organism (Species) Ontology
Plant Trait Ontology
Protein Ontology
RnaO RNA Ontology
Considered for development:
Environment Ontology
Behavior Ontology
Biomedical Image Ontology
Clinical Trial Ontology
A Note on Reference Ontologies and Application Ontologies
Application ontologies are ontologies developed for specific purposes, for example the National Cancer Institute Thesaurus, which is designed to support informatics-based biomedical research in the cancer domain. Application ontologies built on the basis of reference ontologies should be constructed in such a way that updates in the latter are automatically transmitted through to the former.
The key to advancing ontology quality in the biomedical domain lies in the creation of reference ontologies in ways designed to support the kind of interoperability of data and information which will allow genuine reasoning.
A reference ontology is analogous to a scientific theory; it has a unified subject-matter, which consists of entities existing independently of the ontology, and it seeks to optimize descriptive or representational adequacy to this subject matter to the maximal degree that is compatible with the constraints of formal rigor and computational usefulness. Because a reference ontology is analogous to a scientific theory, it consists of representations of biological reality which are correct when viewed in light of our current understanding of reality (and thus it should be subjected to updating in light of scientific advance).
An application ontology is comparable to an engineering artifact such as a software tool. It is constructed for specific practical purposes. Unfortunately it is still common practice that application ontologies are built afresh for each specific task; the authors of such ontologies commonly introduce not only idiosyncrasies of format or logic, but also simplifications or distortions of their subject matter. The latter may do no harm in relation to the specific application (for example radiology, tissue classification, cancer staging) for which the ontology was built. They become harmful, however, at later stages, when other applications want to use the data annotated in their terms, or when there is a need to expand the ontology. To correct for these simplifications will then likely bring the consequence that the expanded ontology is no longer compatible with software designed for its original application. The consequence is that different groups start to work with different versions of ontologies that are incompatible, engendering a spiraling complexity as these different versions themselves become revised and extended for different purposes. The methodology of developing application ontologies always against the background of a formally robust reference ontology framework, and of ensuring updating of application ontologies in light of updating of the reference ontology basis, can both counteract these tendencies toward ontology proliferation and ensure the interoperability of application ontologies constructed in its terms.
For further information contact: obofoundry@buffalo.edu