Summary of OBO Foundry Principles for development of an OBO-compatible life sciences
ontology:
Openness The ontologies are openly available and have to be released under either the license
CC BY 3.0 or under the public domain (
CC0). The openness of the ontologies has enabled, for example, the import of terms from the
Gene Ontology (one of the ontologies that follow OBO Principles) to the
Wikidata project.
Common format The ontologies have to be available in a common
formal language. In practice, that means that ontologies that are part of the OBO foundry need to describe items unsing the formats OWL/
OWL2 or
OBO using a
RDF/XML syntax to maximize interoperability.
Orthogonality (URI). New ontologies have, then, to reuse work done in other efforts.
Versioning Ontologies evolve in time, refining concepts and descriptions according to advances in the knowledge of their specific domains. In order to ensure that new versions are updated, but tools that use older version of the ontologies are still function, OBO enforces a system of
versioning systems, with each ontology version receiving a unique identifier, either in the format of a date or a numbering system, and
metadata dags.
Scope The ontologies should have a clearly specified scope (the domain it intends to cover).
Have textual definitions The ontologies should have textual definitions for each item, in a
human-readable way. That means that beside the alphanumeric identification for each item, they should be described in natural language by logical affirmations following the
Aristotelian logic in a way that is unique within the ontology.
Standardized relations and the Relation Ontology (RO) The ontologies should use relations between items from the
Relations Ontology (RO). This ensures that different ontologies can integrated seamlessly, which is specially important for
logical inference. The Relation Ontology (RO) is an
ontology designed to represent the
relationships between different biomedical concepts. It describes rigorously relations like "part_of", "located_in" and "preceded_by" that are reused by many OBO Foundry ontologies.
Documentation OBO ontologies need to be thoroughly documented. Frequently this is done via
GitHub repositories for each specific ontologies (see
List of OBO Foundry ontologies).
Plurality of users The ontologies should be useful for multiple different people, and ontology developers should document the evidence of use. This criterion is important for the review process. Examples of use include linking to terms by other ontologies, use in
semantic web projects, use in
annotations or other research applications.
Openness to collaborations The ontologies should be developed in a way that allows collaborations with other OBO Foundry members.
Locus of authority The ontologies should have one person responsible for the ontology who mediates interaction with the community.
Naming conventions Naming conventions for OBO ontologies aim at making primary labels unambiguous and unique inside the ontology (and preferably, inside OBO). Labels and synonyms should be written in English, avoiding the use of
underscores and
camel case. OBO lacks a mechanism for multilingual support, in contrast to
Wikidata, which allows labels in different systems. The naming system in OBO is based on a series of surveys at cataloguing naming conventions of current ontologies, as well as discover issues relating to these conventions.
Maintenance The ontologies should be updated with regards to changes in
scientific consensus. The OBO Foundry defines scientific consensus as "multiple publications by independent labs over a year come to the same conclusion, and there is no or limited (<10%) dissenting opinions published in the same time frame." == See also ==