Level 2 Release Candidate Feedback/adoption nonadoption/v4 - bader - Luciano - Zucker

Alan Ruttenberg new version, following discussion with Bader and Luciano. For review and comment. 12-22-2005

Proposed text to include in the release notes:
Known issues with Level 2

While Level 2 represents important progress relative to Level 1, it is likely that Level 3 and future levels will not be backwards compatible with Level 2 or Level 1. Specific issues are: our use of OWL does not conform to the OWL semantics, there is discussion in the community about the biological semantics of specific classes, and some current features conflict with new features that will be added. Conversion to level 2 should be done with an attempt to isolate the intended semantics of the original database from the specific OWL generated. For further information please consult Appendix C of the documentation.

Proposed text to include in Level 2 documentation:
Appendix C: Known issues with Level 2

While Level 2 represents important progress relative to Level 1, it is likely that Level 3 and future levels will not be backwards compatible with Level 2. Conversion to level 2 should be done with an attempt to isolate the intended semantics of the original database from the specific OWL generated.

In attempting to bring BioPAX into conformance with OWL semantics, an attempt will be made to preserve as much of the ontology structure as possible. However, classes and properties are expected to be changed, removed or refactored.

It is advisable to keep this in mind when designing software that currently uses BioPAX Level 1 or 2 and will use BioPAX Level 3 or beyond. The BioPAX Level 2 features under re-evaluation include (but are not limited to):


 * With the introduction of physical entity state, the class 'sequenceParticipant' is expected to change. The property SEQUENCE-FEATURE-LIST that currently stores post-translational modifications and binding site information will be changed and post-translational modifications will be stored in a new class. The SEQUENCE-FEATURE-LIST property may remain to store binding site information, but would have a different meaning and may have a different name.
 * The necessity of defining classes corresponding to participants instead of direct use of the physical entity classes. "participant" classes, representation of stoichiometry, and representation of cellular and reaction context may change.
 * In order to more closely integrate publicly available controlled vocabularies and ontologies within BioPAX, the openControlledVocabulary class may be redefined or replaced with different scheme for referencing external terms and classes.
 * BioPAX Level 2 does not fully respect OWL semantics because, until recently, we didn't understand them. Specifically we were under the impression that OWL was similar to a UML style class hierarchy definition language with a standard XML serialization. OWL follows an "open world assumption", but BioPAX Level 2 mostly assumes a "closed world", similar to most data schema definition languages. In particular:

1) There are a number of cases where open world semantics conflict with the intended semantics of BioPAX entries. For example, in the case of metabolic reactions it is often (but not always) intended that the list of participants in the reactions is considered to be complete. However we do not add closing axioms to make our OWL representation say so. On the other hand it would not be correct to say that the current BioPAX operates under closed-world semantics. One counterexample would be the representation of reactions where the catalyst is not known. Another would be assuming that a BioPAX file contains all reactions of a certain class - if a particular reaction is not found in a BioPAX file, you should not assume that it does not exist.

2) BioPAX often uses domain and range where the meaning we intended should be expressed using restrictions.

3) Aspects of the meaning of some terms, such as Pathway, are embedded in the comments for the class, rather than being made explicit in the definitions of the classes.

4) Cardinality restrictions are often used as a means to suggest which properties are required or optional, rather than being considered definitional.


 * BioPAX Level 1 and 2 assume that there are no user-defined classes and that exchange files only contain instances. This restriction may be removed in future versions.
 * BioPAX Level 1 and 2 may be reliably parsed using non OWL-aware XML parsing tools such as SAX and DOM. Future levels of BioPAX may require using OWL-aware XML parsing tools, such as Jena.
 * The precise meaning of an instance in Level 1 and 2 is not well defined.
 * As always, it may not be possible to convert existing Level 2 data to future levels in an automated manner, requiring instead new export procedures from the original data source.

For up to date list of known issues, check the BioPAX wiki at http://biopaxwiki.org

Approved By
The following individuals have read and approved the wording of the above notices. (Add your name after you've read the notices to indicate your approval of the wording.)


 * Joanne Luciano
 * Jeremy Zucker
 * bader - looks great! Thanks.