Removing PhysicalEntityParticipant

- = Executive Summary =

PhysicalEntityParticipant is a problematic class for many reasons; therefore we should seek a way to remove it from the ontology.

- = Introduction =

Goals/Motivation
To eliminate physicalEntityParticipant, most of the properties of this class are moved to physicalEntity. Stoichiometry is expressed as a property of the interaction. The link between a participant and its stoichiometry is implicitly made through the use of labelled subproperties of LEFT and RIGHT. Example: the stoichiometry of the entity which is the value of the LEFT-A property is given in the numerical value of the LEFT-A-STOIC property. The same is true for the LEFT-B, LEFT-C... and the LEFT-B-STOIC, LEFT-C-STOIC... properties. The use of the physicalEntityParticipant-physicalEntity system as some sort of instance-class relationship can be made obsolete through the SKOS annotation.

= Requirements =

Software processing BioPAX would need to 'understand' the implicit links between the values of the two kinds of properties. However, all of the LEFT-A etc. properties are sub-properties of LEFT and all of the RIGHT-A etc. properties are sub-properties of RIGHT, so the most important information could also be processed by naive software.

= Worked Examples =

This proposal is demonstrated in the file http://neuroscientific.net/ont/biopax-level2-noPhysEntPart.owl (please not that this file also demonstrates the use of SKOS)

How to view worked examples The examples can be imported into the Protege ontology editor (tested).

= Open Issues =


 * 1) The association between the value of e.g. the LEFT-A property and the LEFT-A-STOIC is implicit; applications have to be programmed to understand this implicit link.
 * 2) The number of distinct participants of an interaction is limited by the number of sub-properties we offer (although a number of 6 to 9 different slots might already cover 99% of all use cases).

= Expected growth and plan for growth =

= OWL considerations =

This design pattern is a good example of the use of rdfs:subPropertyOf.

= Backward Compatibility =

It seems that this proposal is surprisingly backward-compatible when the software has basic means of RDF inferencing (i.e. it understands the subProperty relations). When this is the case, many of the queries written for older BioPAX files should also work with these new design (unless they specifically refer to PhysicalEntityParticipant, of course)

-

/Discussion:Discuss this proposal.