Removing PhysicalEntityParticipant/Discussion


 * Gary: PEP is clearly annoying in a number of ways. However, this solution doesn't seem scalable - sure, having 6-9 properties would cover a lot of cases, but what about the cases not covered?  How would you describe a complex assembly of the ribosome this way.  Other ideas have been to use annotation properties to store stoichiometry (this is done for cellular locations in the EcoCyc ontology).  The issue with this that annotation properties are not meant for data.  The way stoichiometry was stored in EcoCyc was as an ordered list of values that matched the interaction participants. The issue with this is that ordered lists are dificult to create and maintain in OWL.  The current PEP implementation follows the n-ary relationship desgn pattern popularized by Alan Rector and Natasha Noy at http://www.w3.org/TR/2004/WD-swbp-n-aryRelations-20040721/. Unfortunately, you can't make restrictions and easily query across these relationships as you normally can.  The MSKCC group has gotten around the PEP issue by using XQuery-like expressions on BioPAX RDF.  The code is freely available on the BioPAX Cytoscape plugin download page.  It sounds like OWL and accompanying tools need to be fixed to deal with this case better, especially if it is a recognized best practice design pattern in OWL.
 * Alan: Things I agree with:
 * "this solution doesn't seem scalable"
 * Matthias: Of course there are limits, but how grave are these limitations? I think having up to 12 or at most 15 such properties is still workable (more than that an it becomes a bit ridiculous). Is there really a significant number of use cases where this number of participants on one side is exceeded? Furthermore, we still can have as many values for the "LEFT" and "RIGHT" superproperties as we like (we just cannot asign a stoichiometry to them).
 * Alan: It's not a huge problem. But there is another proposal on the table (see below) that solves the problem without this limitation. Is there a limitation of that proposal that you see?
 * Matthias: No, it obviously has less limitations than my proposal. I only have reservations because we could end up with too many instances of "stoichiometryAssociation". The relation between an interaction and its participants is probably the most fundamental thing in BioPAX and it would seem a bit problematic to me to add this additional layer of complexity to such a basic and common relation.
 * Alan: Things I don't understand (are they true?):
 * "annotation properties are not meant for data"
 * Gary: actually, I was thinking of the default rdfs and owl annotation properties, however you can create your own annotation properties and store data in them - I don't know if these values are easily accessible to a reasoner.
 * Alan: The reasoner ignores them. But that doesn't mean you can't have data in them.
 * "ordered lists are dificult to create and maintain in OWL"
 * Gary: OWL doesn't define an ordered list, there is a design pattern in place to create them, it is difficult to use
 * Alan: Difficult in what sense?
 * "you can't make restrictions and easily query across these relationships as you normally can"
 * Gary: this is the 'no triangle' rule you mentioned
 * Alan: This may be true, but in March, when you last mentioned this, I asked for an example, because I couldn't remember any. You didn't respond then - perhaps you could dig up an example now.
 * Gary: actually, another idea is to create a tuple (physicalEntity, stoichiometry) as a utility class ad add this to an interaction class.
 * Alan: If what you are saying is what I think you are saying, then this would be an improvement.
 * New class stoichiometryAssociation. Restrictions PHYSICAL-ENTITY exactly 1, STOICHOMETRY exactly 1
 * STOICHIOMETRY domain stoichiometryAssociation
 * New property, STOICHIOMETRY-ASSOCIATION domain interaction, range stoichiometryAssociation
 * PARTICIPANTS are now physicalEntities, physicalEntityParticipants deprecated.
 * Validator checks that PHYSICAL-ENTITY of interactions is superset of PHYSICAL-ENTITYs of STOICHIOMETRY-ASSOCIATIONs of interaction.
 * Gary: precisely. We didn't do this before since there were other properties in physicalEntityParticipant (PEP), however, the state proposal solves this by moving those other properties out of PEP - so if we go with the state proposal, this would be easy to implement.
 * Alan: Why couldn't we have done this before? The class could have been called something different and included whatever properties we wanted.
 * Nicolas: So in a conversion, PARTICIPANTS would point to a physicalEntity and the stoichiometry would be retrieved from this and the new tuple? Or would this tuple be pointed to directly from PARTICIPANTS? Where would the cellular-location be? Based on the discussion on the mailing-list, I am under the impression that there is a near consensus to say that physicalEntity is a pool. So it should carry this information (that leave open the problem of the type of entity).
 * Alan: The former: PARTICIPANTS would point to a physicalEntity and the stoichiometry would be retrieved from this and the new tuple. Regarding physicalEntity being a pool, I would take this as a requirement for subsequent level, unless the DX folks, who are interested in the short term only, want to take this up. But I would ask: What are the implications of this - how can we tighten up our definitions (including axioms) to reflect this. What other implications are there for the ontology?
 * Andrea: Using a tuple is a good idea as it is, in fact, reification. Having LEFT-1, LEFT-2... I think it's a bad solution. You rely on applications to know what you are doing ? What's the difference in using a PEP ? For me a PEP is even easier as I can query an RDF graph and this follow a standard pattern.. LEFT-1, LEFT-2 would indeed make me unable to use the stoichimetry as a number...
 * Andrea: As for Pools... maybe they should not be confused with PEP. There should be and explicit characterization for them.