directly asserting PARTICIPANT

0 views
Skip to first unread message

Alan Ruttenberg

unread,
Jun 1, 2006, 12:49:57 AM6/1/06
to Ken I Fukuda, BioPAX Manchester
my understanding of PARTICIPANT is that it is a superproperty of
LEFT, RIGHT etc, and is not meant to be directly asserted.
Asserting the same values as would be computed is harmless, though it
unnecessarily increases the size of the file. However I also not that
in at least in one case (probably others) there are PARTICIPANTS that
are not the LEFT, RIGHT etc.

For example:

<catalysis rdf:ID="id866102253_Catalyze">
<PARTICIPANTS
rdf:resource="#id1759043015_TGF_beta_receptor_I_ub0"/>
<PARTICIPANTS rdf:resource="#id2087004980_TGF_beta_receptor_I0"/>
<PARTICIPANTS rdf:resource="#id1116560532_smurf20"/>
<CONTROLLER rdf:resource="#id1116560532_smurf20"/>
<CONTROLLED rdf:resource="#id1509676705_ubiquitination"/>
<NAME rdf:datatype="http://www.w3.org/2001/
XMLSchema#string">Catalyze</NAME>
<SHORT-NAME rdf:datatype="http://www.w3.org/2001/
XMLSchema#string">Catalyze</SHORT-NAME>
<DATA-SOURCE rdf:resource="#INOHDataSource"/>
<XREF rdf:resource="#INOH_II0000028_id866102253"/>
</catalysis>


In this case, #id1759043015_TGF_beta_receptor_I_ub0 and
id2087004980_TGF_beta_receptor_I0 would be participants of the
controlled, but not of the catalysis. At least in BioPAX level 2.
Arguably they should be, but that would be something to add to the spec.

Apologies for the bunch of separate messages. I keep trying to go
back to doing the work I am supposed to be doing, then dragged back
in to reviewing your file as I procrastinate :)

Regards,
Alan

Ken I Fukuda

unread,
Jun 1, 2006, 1:18:11 AM6/1/06
to Alan Ruttenberg, BioPAX Manchester
Hi,

> my understanding of PARTICIPANT is that it is a superproperty of
> LEFT, RIGHT etc, and is not meant to be directly asserted.
> Asserting the same values as would be computed is harmless, though it
> unnecessarily increases the size of the file. However I also not that
> in at least in one case (probably others) there are PARTICIPANTS that
> are not the LEFT, RIGHT etc.

Yes.

There were some cases where we wanted to distinguish
"participants" and "direct participatns". I requested this
as a requirement to Emek.

As I mentioned before we found some bugs in our XSLT
and that's the reason for the delay in sending INOH owl
to the disucssion list. Sorry about this.
The known (and fixed) bugs include
* namespace.
* some interactions have empty LEFT/RIGHT properties.
* no Event Ontology reference in control/catalysis/modulation etc.
* some INOH's connected edges are duplicated in OWL.

I will send the lates OWL tgf-beta file with some documentations today.

Thanks again for your comments.

Best,
Ken

>
> For example:
>
> <catalysis rdf:ID="id866102253_Catalyze">
> <PARTICIPANTS
> rdf:resource="#id1759043015_TGF_beta_receptor_I_ub0"/>
> <PARTICIPANTS rdf:resource="#id2087004980_TGF_beta_receptor_I0"/>
> <PARTICIPANTS rdf:resource="#id1116560532_smurf20"/>
> <CONTROLLER rdf:resource="#id1116560532_smurf20"/>
> <CONTROLLED rdf:resource="#id1509676705_ubiquitination"/>
> <NAME rdf:datatype="http://www.w3.org/2001/
> XMLSchema#string">Catalyze</NAME>
> <SHORT-NAME rdf:datatype="http://www.w3.org/2001/
> XMLSchema#string">Catalyze</SHORT-NAME>
> <DATA-SOURCE rdf:resource="#INOHDataSource"/>
> <XREF rdf:resource="#INOH_II0000028_id866102253"/>
> </catalysis>
>
>
> In this case, #id1759043015_TGF_beta_receptor_I_ub0 and
> id2087004980_TGF_beta_receptor_I0 would be participants of the
> controlled, but not of the catalysis. At least in BioPAX level 2.
> Arguably they should be, but that would be something to add to the spec.
>
> Apologies for the bunch of separate messages. I keep trying to go
> back to doing the work I am supposed to be doing, then dragged back
> in to reviewing your file as I procrastinate :)
>
> Regards,
> Alan
>

---------------------------------------------
Ken Ichiro Fukuda, Ph.D.
Computational Biology Research Center (CBRC)
National Institute of
Advanced Industrial Science and Technology (AIST)
AIST Tokyo Waterfront Bio-IT Research Bldg. 10F
2-42 Aomi, Koutou-ku, Tokyo 135-0064 JAPAN
Phone: +81-3-3599-8049 FAX: +81-3-3599-8081
fukud...@aist.go.jp - http://www.cbrc.jp/~fukuda/index.html
- INOH Pathway Database Project -
- Integrating Network Objects with Hierarchies
- http://www.inoh.org

Ken I Fukuda

unread,
Jun 1, 2006, 1:43:23 PM6/1/06
to Alan Ruttenberg, BioPAX Manchester
Hi,

On Thu, 1 Jun 2006 00:49:57 -0400
Alan Ruttenberg <alanrut...@gmail.com> wrote:

> my understanding of PARTICIPANT is that it is a superproperty of
> LEFT, RIGHT etc, and is not meant to be directly asserted.
> Asserting the same values as would be computed is harmless, though it
> unnecessarily increases the size of the file. However I also not that
> in at least in one case (probably others) there are PARTICIPANTS that
> are not the LEFT, RIGHT etc.

As I mentioned before, there were cases where we wanted to
distinguish participants (e.g. complex) from
direct (LEFT/RIGHT) participants (e.g. complex subunit).
But the current BioPAX is not designed to distinguish this.
So we will delete the code that directly assert values into
the PARTICIPANT property.

> For example:
>
> <catalysis rdf:ID="id866102253_Catalyze">
> <PARTICIPANTS
> rdf:resource="#id1759043015_TGF_beta_receptor_I_ub0"/>
> <PARTICIPANTS rdf:resource="#id2087004980_TGF_beta_receptor_I0"/>
> <PARTICIPANTS rdf:resource="#id1116560532_smurf20"/>
> <CONTROLLER rdf:resource="#id1116560532_smurf20"/>
> <CONTROLLED rdf:resource="#id1509676705_ubiquitination"/>
> <NAME rdf:datatype="http://www.w3.org/2001/
> XMLSchema#string">Catalyze</NAME>
> <SHORT-NAME rdf:datatype="http://www.w3.org/2001/
> XMLSchema#string">Catalyze</SHORT-NAME>
> <DATA-SOURCE rdf:resource="#INOHDataSource"/>
> <XREF rdf:resource="#INOH_II0000028_id866102253"/>
> </catalysis>
>
>
> In this case, #id1759043015_TGF_beta_receptor_I_ub0 and
> id2087004980_TGF_beta_receptor_I0 would be participants of the
> controlled, but not of the catalysis. At least in BioPAX level 2.
> Arguably they should be, but that would be something to add to the spec.

Yes, this is simply a bug...

> Apologies for the bunch of separate messages. I keep trying to go
> back to doing the work I am supposed to be doing, then dragged back
> in to reviewing your file as I procrastinate :)

Many thanks again for reviewing :)

Ken

> Regards,
> Alan
>


Reply all
Reply to author
Forward
0 new messages