Download
1 / 14
140 likes | 291 Views
OBO Foundry Principles. http://www.obofoundry.org/wiki/index.php/Category:Accepted. 1. Openness.
E N D
OBO Foundry Principles http://www.obofoundry.org/wiki/index.php/Category:Accepted
1. Openness 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. 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 and that after any external alterations, they must never be redistributed under the same name or with the same identifiers.
2. Common format • common formal language in an accepted concrete syntax • OBO Format • OWL or OWL2 concrete syntax • RDF/XML • OWL2-XML • OWL2-Manchester Syntax • Common Logic concrete syntax • CLIF • Conceptual Graphs
3. URI Each class and relation (property) in the ontology must have a unique URI identifier. The URI should be constructed from a base URI, a prefix that is unique within the Foundry (e.g. GO, CHEBI, CL) and a local identifier (e.g. 0000001). The local identifier should not consist of labels or mnemonics meaningful to humans. • The ID-space / prefix must be registered with the OBO library in advance. Email: obo-admin @obofoundry.org
4. Versioning The ontology provider has procedures for identifying distinct successive versions.
5. clearly delineated content coherent natural language definitions of top-level term(s) incorporating cross-product links to other OBO Foundry ontologies
6. Textual definitions Textual definitions (SOP) for a substantial and representative fraction, plus equivalent formal definitions (for at least a substantial number of terms). For terms lacking textual definitions, there should be evidence of implementation of a strategy to provide definitions for all remaining undefined terms. • Text definitions should be unique (i.e. no two terms should share a definition)
7. Relations The ontology uses relations which are unambiguously defined following the pattern of definitions laid down in the OBO Relation Ontology. ?Needs modification
8. Documented The ontology is well-documented (e.g. in a published paper describing the ontology or in manuals for developers and users)
9. Users plurality of mutually independent users (documented e.g. via pointers in external URIs, use in cross-products)
10. Collaborative development It is assumed that OBO Foundry ontology development, like all scientific activity, is carried out in a collaborative fashion. The OBO Foundry requires in addition that each OBO Foundry ontology is maintained in such a way as to ensure consistency with neighboring OBO Foundry ontologies and to ensure use of relevant content from these neighboring ontologies, for example in formulation of cross-product definitions.
11. Locus of authority There should be a single person who is responsible for the ontology, for ensuring continued maintenance in light of scientific advance and prompt response to user feedback, Contact information for this person should be provided on the ontology website, and listed in the OBO Library Metadata File. There should be a single person (perhaps the same person) who is responsible for liaison between the ontology developers and the OBO Foundry coordinating editors.
12. Naming conventions • http://www.biomedcentral.com/1471-2105/10/125
13. Maintenance Maintenance in light of scientific advance
