Principles: Overview

• Overview
• 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)

These principles are intended as normative for OBO Foundry ontologies, and ontologies submitted for review will be evaluated according to them. We consider these to be generally good practice, and recommend they be considered even if there are no plans to submit an ontology for review by the Foundry. Where we use capitalized words such as “MUST”, and “SHOULD”, they will be interpreted according to RFC 2119: Key words for use in RFCs to Indicate Requirement Levels when the principles are applied during reviews of ontologies for inclusion in the Foundry.

There is currently an ongoing process to clarify the wording of the principles and expand on their purpose, implementation, and criteria to be used to evaluate ontologies for compliance with each principle. Please use the issue tracker to let us know if there are further clarifications that you would like to see addressed for any of the principles.

Quick Summary

The following summarizes each principle. See individual pages for details.

P1) Open - The ontology MUST be openly 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 in altered form under the original name or with the same identifiers.

P2) Common Format - The ontology is made available in a common formal language in an accepted concrete syntax.

P3) URI/Identifier Space - Each ontology MUST have a unique IRI in the form of an OBO Foundry permanent URL (PURL).

P4) Versioning - The ontology provider has documented procedures for versioning the ontology, and different versions of ontology are marked, stored, and officially released.

P5) Scope - The scope of an ontology is the extent of the domain or subject matter it intends to cover. The ontology must have a clearly specified scope and content that adheres to that scope.

P6) Textual Definitions - The ontology has textual definitions for the majority of its classes and for top level terms in particular.

P7) Relations - Relations should be reused from the Relations Ontology (RO).

P8) Documentation - The owners of the ontology should strive to provide as much documentation as possible.

P9) Documented Plurality of Users - The ontology developers should document that the ontology is used by multiple independent people or organizations.

P10) Commitment To Collaboration - OBO Foundry ontology development, in common with many other standards-oriented scientific activities, should be carried out in a collaborative fashion.

P11) Locus of Authority - There should be a person who is responsible for communications between the community and the ontology developers, for communicating with the Foundry on all Foundry-related matters, for mediating discussions involving maintenance in the light of scientific advance, and for ensuring that all user feedback is addressed.

P12) Naming Conventions - The names (primary labels) for elements (classes, properties, etc.) in an ontology must be intelligible to scientists and amenable to natural language processing. Primary labels should be unique among OBO Library ontologies.

P13) Notification of Changes - Ontologies SHOULD announce major changes to relevant stakeholders and collaborators ahead of release.

P16) Maintenance - The ontology needs to reflect changes in scientific consensus to remain accurate over time.

P20) Responsiveness - Ontology developers MUST offer channels for community participation and SHOULD be responsive to requests.