This policy has been formally adopted on April 19th 2013. Do not edit this page without consulting with the OBO Technical group. Change adopted March 2017 to add obsolete metadata to non-maintained PURLs. See issue https://github.com/OBOFoundry/OBOFoundry.github.io/issues/344. Comments to email@example.com
Identifiers are managed by giving requesting projects a series of numerical ids that have a common prefix, sometimes known as a namespace. For example, a project might request and obtain the prefix “MOBO”. The ontology would then use ids of the form http://purl.obolibrary.org/obo/MOBO_0000001 , http://purl.obolibrary.org/obo/MOBO_0000002 …
In order to ensure that there is no prefix redundancy, i.e. only one project/resource is using the namespace “MOBO”, these are allocated by the OBO Foundry technical working group.
The technical working group reserves the right to make decisions based on their experience and judgement. In addition to uniqueness of prefixes, other criteria are for example that there not be overlaps of usage. This includes awareness that there can be the appearance of overlap between accession numbers used in databases and prefixed URIs. For example, we would probably not create a prefix “ISBN” and would instead make alternative suggestions.
- While there are no review requirements, participation in the OBO Foundry implies willingness to discuss your project and collaboratively develop it. You are strongly encouraged to build upon the existing suite of ontologies available in the OBO library.
- We recommend projects be orthogonal to each other (i.e., no domain overlap). For those classes that are common across multiple resources (e.g., the class cell) we recommend importing terms from an already existing ontology. At a minimum, we expect attribution of existing work.
Status of ontology development
- A project should exist, with work started. We will not “pre-book” prefixes and domains for potential future resources.
- The required namespace must be available.
- The resource must be publicly available when released.
- There must be a contact person for the resource. We ask that the contact person for resources be subscribed to our main communication channel, the obo-discuss list.
- The requestor and/or contact person should be ready to discuss issues such as whether the ontology is orthogonal, whether there is potential to collaborate with existing efforts.
- It is expected that solicitation of a prefix is done before the prefix is used for identifiers. A common strategy is to develop an ontology, request a prefix, and translate the initial URIs used to the PURLs some time before the initial release. There is no guarantee that you will be granted your prefix, even if you have been using it in your file.
Information needed for a prefix request
You must first make your ontology available via a stable URL. Provide this to us, together with the following metadata:
- id: prefix of ontology in lowercase, e.g. mobo, uberon, chebi, cl
- title: concise title of your ontology
- home page: this can be a GitHub URL
- contact: name, email and github username
- tracker: URL of issue tracker (typically GitHub)
Note that we recommend you set up an ontology repository in GitHub using the Ontology Development Kit. This will create the required metadata fields for you.
Requesting the prefix
The requests proceeds in 2 steps:
Submit your request to our tracker
We expect general discussion to take place on the obo-discuss list, while technical follow-up will take place on the tracker.
Example of such request:
Allocate 2 weeks to give members of the community time to provide feedback and for the operations committee to act on the request. We will usually respond on the tracker ticket and acknowledge your request/provide a tentative creation date. If you don’t hear back from us after 2 weeks, please send a note to the firstname.lastname@example.org or request follow-up via the tracker ticket.