The OBO foundry principles

This week, is a week long ontology building week, consisting of two days at the OBO Foundry workshop followed by 4 days at the OBI workshop, all hosted at the EBI. In advance of the meeting (even though I am writing this during the meeting) Duncan asked “how can the ontology development principles be improved“. Ally and Melanie responded commenting on each principle, and I would pretty much agree with every issue the ontology ladies raise. These principles should be used to guide ontology developers to build a consistent resource and which are used to “peer-review” the ontology. However, my concern is that there is no indication or recommended methodology in how these principles could be met, during the development process. This was my motivation for reviewing all the existing documented methodologies are assess there applicability (shameless plug), as I think it is important to remember that the members of the OBO Foundry are not the first people in the world to build ontologies and we should make use of known and documented expertise where possible instead of re-inventing the wheel.   These are my take on the principles below. However, I would recommend reading Ally’s and Melanie’s first as I have tried not to repeat what they have already said. Although, as Duncan and the ontology ladies have independently arrived at mostly the same conclusions, there is a very real need to address or more explicitly state, these set of principles.

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.

Licenses – This is always a touchy subject, within the life-sciences and IMHO largely due to a mis-understanding of what a license is actually for. Being open in the sciences is often mis-interpreted as “you can use it, but you have to attribute me”. This is actually not being open. The attribution aspect is actually a restriction. The principle of the OBO foundry  is that there will be hundreds of separate and orthogonal ontologies that will all refer and reference each other. If every single ontology has to be attributed this will become a large overhead. In addition, if we do insist on attribution, how do we acknowledge the use?  An official statement? Is importing the URI enough?  This aspect of the principles really needs to be explicit and clearly stated. Making use of  licenses that already exist may be a good starting point, rather than trying to define a bespoke OBO Foundry license. Two possibilities are Creative Commons – Attribution or CCO. The current OBO principles seem to merge these two licenses together. An explicit statement on licenses  is  really needed. Ally covers this in more detail on her post.

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.

mm, this is confusing “expressed in a common shared syntax”, but you can use either OBO or OWL that would be two different syntax – no? Either the OBO foundry are in a shared syntax, or they are in OBO or OWL.

3. The ontologies possesses a unique identifier space within the OBO Foundry.

I would be good just to tighten this up a bit. A clear statement of the identification schema would be helpful

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

This is a good statement and version of ontologies definitely need to be identified. As Ally mentions, we probably do not want to legislate which versioning system to use (svn, git etc). However maybe a recommendation of which to use and what constitutes a change may be helpful.

5. The ontology has a clearly specified and clearly delineated content.

How would you describe this to your users or developers? In ontology development this is traditionally called defining your scope. Your scope can be described by competency questions – questions your ontology should answer.

6.The ontologies include textual definitions for all terms.

A definition of a class in the ontology is its assertion in the hierarchy and all the logical restrictions, it can also include a natural language definition. I would re-word this to ” The classes in the ontology shoud have a natural language definition which reflection the logical definition of the class”.

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

Same comment as Ally

8. The ontology is well documented.

Not really sure what this actually means or how to implement it. There are a set of naming recommendations within the OBO Foundry, is this what it is referring to? There are also metadata recommendation from OBI, is this the same thing?

9.The ontology has a plurality of independent users.

Why is this important as a principle for inclusion? Is listing on the OBO Foundry not an attempt to gain wider use? Are the computational users? is a user an individual, a  lab, a project, community?

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

Why? Is this really a guiding development policy? What does collaboratively mean? In terms of the license? Does branching in a versioning repository count as collaborative development? I would suggest that if we get the terms of the license explicit an the idea of the Foundry then this principle is probably not necessary to be stated.

These comments are more a mix questions for debate rather than any clear cut corrections.