OBO Foundry principles

Following blog posts from Duncan and Allyson, and in preparation for the 2nd OBO Foundry workshop,  here is my take on the OBO Foundry principles. The list provided by the OBO Foundry is formatted similarly to the one on their website, bold blue with emphasis on some words in green, and my comments follow after each point.

Disclaimer: I am probably biaised in favor of the Foundry principles, having been working on the Ontology for Biomedical Investigations (OBI) and the Information Artifact Ontology (IAO) quite a bit :)

1. 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.

I would like to see a clear licensing policy from each of the ontologies part of the Foundry. If I want to re use part of any of them, having a straightforward way to know what is allowed or not would be great. If there is a wish from the Foundry to constrain to specific degrees of licensing (e.g. keep restrictions to a minimum) a list of acceptable licenses could be proposed.
I understand that principle as Foundries ontologies should be freely available for anybody to use, as long as proper credit is given and information is not distorted. I would think a CC-by or CC-by-sa would fit the requirements.
See also post from Allyson on Choosing a license for your ontology

2. The ontology is in, or can be expressed in, a common shared syntax. This may be either the OBO syntax, extensions of this syntax, or OWL. The reason for this is that the same tools can then be usefully applied. This facilitates shared software implementations. This criterion is not met in all of the ontologies currently listed, but we are working with the ontology developers to have them available in a common OBO syntax.

I like the goal of that one, and I think it is fundamental to have a common language that can be used by all. If we intend to build a community we need to be able to exchange between members and use common tools.
However in practice this proves difficult:
1/ there are several versions of the tools currently available, and they won't all behave in the same way
2/ evolutions of languages implies updating the converters

If I try to open the automatically generated obi.obo file it won't be possible using OBO-Edit 1.101, or even 2.0 beta 50. This file requires OBO-Edit 2.0 beta 54 to be opened. This is just an example, but similar issues exist using Protege 3 or 4 and different versions of OWL. This is no critic of the languages or the tools, on the contrary, it is a good thing that they keep evolving, but maintaining several syntaxes has a non-negligible cost.

3. The ontologies possesses a unique identifier space within the OBO Foundry. The source of a term (i.e. class) 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.

I think this principle is pretty explicit, and well followed. It could probably be extended to have a common format for URIs in general: we have been working in OBI to establish a clear ID policy and which format to adopt. In short, we chose to rely on our own domain name and use slash as separators, effectively creating URIs like http://purl.obofoundry.org/obo/OBI_0000225. (Dereferenceable URIs by Alan Ruttenberg)

4. The ontology provider has procedures for identifying distinct successive versions.

This is actually my personal favorite one :)
I think it is very important when accessing a resource to be able to evaluate its provenance (cf principle above) and quality - I want to know where it comes from (and choose to trust or not the source) and what is the current version of the resource.
We chose to mint URIs for each released version of the OBI ontology. For example, http://purl.obofoundry.org/obo/2008-03-05/obi.owl: users can choose to import specific versions of the ontology to preserve stability if they need to, or they can instead to always use the latest released version of OBI, always available at http://purl.obofoundry.org/obo/obi.owl.
OWL2 version URIs mechanism seems like a good way of achieving this.

While this is a first step in the right direction, I would in fact go even further. It is currently very hard to get an idea of the status of a resource: even using a different URI for each release, nothing tells me if the ontology is to be considered for production or is still too unstable. What would be helpful for me would be to have an idea of the state of development of the resource - similarly to what is done with software development, where released are labeled alpha, beta etc.

Initially we could rely on self-assessment from the ontology developers, and at a later stage maybe consider some milestones, like deprecation policy implemented, regular releases, etc.

5. The ontology has a clearly specified and clearly delineated content. The ontology must be orthogonal to other ontologies already lodged within OBO. The major reason for this principle is to allow two different ontologies, for example anatomy and process, to be combined through additional relationships. These relationships could then be used to constrain when terms could be jointly applied to describe complementary (but distinguishable) perspectives on the same biological or medical entity. As a corollary to this, we would strive for community acceptance of a single ontology for one domain, rather than encouraging rivalry between ontologies.

I think this is in principle an important guideline. In order to improve lightweight import of ontological resources we even developed MIREOT, the Minimum Information to Reference an External Ontology Term, with the aim of avoiding duplication of terms within the Foundry. (<commercialbreak> come and see us at the International Conference on Biomedical Ontology! </commercialbreak>) In short, instead of defining for examplea cell in OBI, we instead re-use the one from the Cell Type Ontology.

I can see two issues with that idea however:
1. like mentioned by Ally, how to check on unicity at the level of the terms, and who is in charge of this?
2. this may cause issues when an ontolgoy has been developed by one group, and an other group would like to improve it, or maybe even has already developed a parallel version. Ideally, the two groups would collaborate and produce a merged version of the ontology, but in reality this is a difficult process.

6. The ontology includes definitions for all terms. Many biological and medical terms may be ambiguous, so terms should be defined so that their precise meaning within the context of a particular ontology is clear to a human reader.

Necessary, and too often missing. Most of the people will assume that a label will be enough, and/or that they will have time to update the definition later. In my own experience, definitions are most often needed than not, and it is best to do as much as possible w.r.t. the curation status of a term when adding the term than trusting oneself to go back to it later.

7. The ontology uses relations which are unambiguously defined following the pattern of definitions laid down in the OBO Relation Ontology.

Hm - I work with Foundry ontologies, and I am confused by that one :) I *guess* the idea is that by using definitions similar to the ones in the Relation Ontology it will make it easier if required to add said relations into RO?
I quite like having one central Relation Ontology, it makes things much easier when trying to share between resources.

8. The ontology is well documented.

Well, that is indeed very important. It is essential to do it while developing the ontology, in order to 1/ keep track of exchanges and not waste time just trying to remember what the issue was 2/ give a chance to potential new contributors to understand what has been done and what the current status is. Unfortunately, based on my experience, documentation of ontologies is more often than not quite sparse.
I also find it difficult to know how to structure such a documentation. We do try and add information in the editor notes annotation property, but they are often not dated, not updated when new development, and it is hard to keep track of global ontology evolution by adding notes on a per term basis. Websites and wikis are great, but it is sometimes cumbersome to find your way in their maze.

9. The ontology has a plurality of independent users.

Hm - are those real users or are those "declared future users"? Are developers of the ontology (who in general are interested in developing it because they indeed plan to use it) considered users?
To be honest I am not sure about that one. What if I build a great ontology, on a very specific theme? Somebody else may use it if they wish to do so, but most probably very few people would actually have a use for it. Does that preclude my ontology to being a Foundry one?

10. The ontology will be developed collaboratively with other OBO Foundry members.

I think this should be extended to non-OBO Foundry members. I actually thought that there was a principle stating that anyone wishing to contribute to a project should be allowed to. Also I assume that in the case where a call for participation has been made and nobody volunteered this shouldn't be precluding the effort to join the foundry.

Now, I know that the above may sound negative - actually it is far from that (see disclaimer above). It is easier to find room for improvement in existing structure tahn actually starting from scracth. I think the Foundry participants really did a great job of putting together the fundations. I am really convinced of the interest of the OBO Foundry, and I would love to see it grow. I honestly believe that having a set of guidelines to help develop and insure some degree of quality is very important. Unifying principles considering the current disparity of the resources is also an ambitious endeavor, and I understand that the principles have deliberately been written as not being too constraining.

I however thing that we are reaching a critical mass in the number of Foundry participants, and an interesting level of technical development with the formalization of policies such as the naming conventions, and the proposals of others, such as the set of annotation properties, MIREOT or the ID policy (and I know that others are being worked upon as well). It would make sense to start tightening things up, and formulate maybe more precisely the recommendations and guidelines to become an OBO Foundry member.

Here are some of my suggestions:

1. Ideally I would like the OBO Foundry use a set of common policies, for example the ID policy or the deprecation policy we developed within the context of OBI (and I am sure other efforts also have internal guidelines that would be beneficial for the community at large if shared).

2. I would also propose to use identical annotation properties - for example the OBI/IAO ones, that we are on purpose shipping in a separate OWL file.

3. I didn't find any mention of using an upper-ontology such as the Basic Formal Ontology (BFO), or how the review itself is conducted. Is there a "public" audit of the resource, or on the contrary is the decision process confidential between OBO coordinators?

4. Finally, I think that expanding the current http://www.obofoundry.org website to actually host the documentation of Foundry ontologies would make sense. Why not add a wiki that ontologies developers could edit directly, but which would have a pre-defined core organization? They would be free to add extra pages, but some commonalities could be pre-provided, like, "developers'", "meetings", "policies", "documentation"... It would make it very easy for users to find their way in such a wiki, and it would also provide some guidance for developers and avoid uncontrolled wiki explosion.

Hm - it appears I have been more prolific than expected :) Well, if you made it until here without being bored to death, I would be happy to hear your thoughts and comments on the matter. If you didn't.. well no chance you are reading this now, is there....? ;)