Re: Using biopaxtool 4.1.6 to parse Reactome L3 data got "Redundant attempt to set the inverse link" warning

[Emek Demir]

Hi Fengyuan,

I need to check exactly the entity and will do it on monday- but the warning looks pretty innocent to me. You should be able to use it as it is without problems.

ED

On 05/03/2013 09:34 AM, Fengyuan Hu wrote:

Dear BioPax team,

I got the following warning message while trying to parse Reactome L3 data using biopaxtool 4.1.6:

WARN org.biopax.paxtools.impl.level3.PhysicalEntityImpl - Redundant attempt to set the inverse link! this Proteinhttp://www.reactome.org/biopax/68320#Protein3178 and - ModificationFeaturehttp://www.reactome.org>/biopax/68320#ModificationFeature404

I searched the discussion group, and saw a relevant thread here - https://groups.google.com/forum/?fromgroups=#!topic/biopax-discuss/gehKAA8cI_o

Some one had a similar problem 2 years ago, but it seems the issue remains? 

Any suggestions are highly appreciated!

Thanks

Fengyuan

--
You received this message because you are subscribed to the Google Groups "BioPAX discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to biopax-discus...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Igor Rodchenkov]

Hi Fengyuan,

But it's a different story from that in the other biopax-discuss thread that you pointed to (those were range violation, i.e., biopax syntax, errors; not warnings).

I confirm that using, e.g., the following command 

java -Xmx1g -jar paxtools-4.1.6.jar summarize ~/Downloads/biopax/Caenorhabditis\ elegans.owl

I get many "Redundant attempt to set the inverse link..." warnings (feature - featureOf - protein). 

So what happens here is that a ModificationFeature object is added to the same Protein more than once: using either 'feature' or 'notFeature' biopax property. Such state does not make any sense, and looks like a curation error.

What you can see there in the Reactome BioPAX L3 file (Caenorhabditis elegans.owl; but I am note sure which version you use, because in my local file Protein3178 does not have this issue, anyway...)

  

<bp:Protein rdf:ID="Protein394">

    <bp:displayName rdf:datatype="http://www.w3.org/2001/XMLSchema#string">P91918</bp:displayName>

    ...

    <bp:entityReference rdf:resource="#ProteinReference264" />

    <bp:feature rdf:resource="#ModificationFeature48" />

    <bp:feature rdf:resource="#ModificationFeature48" />

    <bp:feature rdf:resource="#FragmentFeature335" />

    ...

</bp:Protein>

Looks like a curation issue or biopax exporter issue. 

I'll let the Reactome team know about this issue (CC'd to Guanming).

Thank you,

Igor R.

[Igor Rodchenkov]

Fengyuan,

On Friday, May 10, 2013 9:24:42 AM UTC-4, Fengyuan Hu wrote:

Dear Igor,

Thank you for forwarding my message to Reactome team. I checked my reactome data and we have the same file I believe.

Nope. In my "Caenorhabditis elegans.owl" (from the Reactome v44 biopax3.zip), unlike yours, there is no such warning message about the Protein3178.

(Local part, like Protein3178, of the Reactome biopax entities' URIs are not stable; i.e., can change every time they re-generate biopax files)

Anyway, there are many similar ones.

Hopefully, this will be fixed soon.

This might be just a duplicate that can be ignored, but might also be a serious data error (e.g., the other important feature is missed from all data); let's wait...

 

IR.

Cheers

Fengyuan

[wgm]

Hi Fengyuan, Igor,

This is actually based on curation. Please see for the example posted by igor:

http://www.reactome.org/cgi-bin/instancebrowser?DB=gk_current&ID=3238773

In this EWAS instance (Protein in Reactome), there are two methylations with unknown position. So we annotate the same modification twice. The worm version of this protein is predicted from its human counterpart:

http://www.reactome.org/cgi-bin/instancebrowser?DB=gk_current&ID=192213&

which is our original manual curation.

Thanks,

Guanming

[Emek Demir]

Hi Guanming,

I think in that case you need to create two different methylation individuals otherwise all the RDF tools will see it just as a redundant link. This is an important open world/closed world problem and we need to discuss how to address it soon.

Best,
ED

--

[Guanming Wu]

Hi Emek,

I guess we may need. But then these two modifications will point to the same UnificationXref. Will they?

Thanks,

Guanming

[Oliver Ruebenacker]

     Hello,

  I don't understand how it is a closed versus open world issue. It sounds like the equivalent of saying:

  "This child is a daughter. It's Obama's child. It's Obama's child."

  to express that Obama has two daughters.

  Two modifications should only have the same unifications cross-ref if they are known to be the same - and apparently they are not. (Do modifications have cross-refs anyway?)

     Take care
     Oliver

Head of Systems Biology Task Force at PanGenX (http://www.pangenx.com)
Any sufficiently advanced technology is indistinguishable from magic.

[Emek Demir]

Oliver -

The open world is at a deeper level - at unknown sequence location.

Consider two different strategies for representing methylations with unknown location on a certain entity.

Strategy a) you create a single individual  of type ModificationFeature,has sequence location unknown, type is methylation.
Strategy b) For every assignment of said methylations you create a separate individual.

Strategy a is assuming that all methylations with unknown locations on a certain entity are the same.
Strategy b is assuming that all methylations with unknown locations on a certain entity is different and/or you don't know.

Guanming is currently taking the strategy a - but in the case he described -A(m,m)- it is clear that he is actually talking about 2 different methylations - so strategy a fails under those situations.

But now consider an alternative case where you have

A(m) +B --> c(A(m)-B)

where A is a protein, m is a methylation with unknown location and B is some binding partner. Are the two methylation features on both sides are actually the same? Most probably yes - and most probably you know it and want to express it. So strategy b fails under some situations too..


All of these things would not be a problem if we knew the sequence location  - but since we don't know it we need to deal with this n-to-n identity problem. Things get exponentially more complex with 3 or more such modifications.

I hope this clarifies things a bit.

Best,
ED

Any sufficiently advanced technology is indistinguishable from magic. --

[Oliver Ruebenacker]

     Hello Emek,

  Still see no connection to OW/CW. But as you say strategy A is almost always wrong and strategy B is sometimes wrong.

  Strategy C: Use different individuals, unless you know it's the same

  seems to clearly be less often wrong.

     Take care
     Oliver

[Igor Rodchenkov]

To all:

I thought the example was quite obvious:

<bp:Protein rdf:ID="Protein394">

    <bp:displayName rdf:datatype="http://www.w3.org/2001/XMLSchema#string">P91918</bp:displayName>

    ...

    <bp:entityReference rdf:resource="#ProteinReference264" />

    <bp:feature rdf:resource="#ModificationFeature48" />

    <bp:feature rdf:resource="#ModificationFeature48" />

    <bp:feature rdf:resource="#FragmentFeature335" />

    ...

</bp:Protein>

It 

a) does not make sense; 

b) cannot be produced with 99% tools that write RDF/XML (scripts can do ;));

c) flags about many potential problems.

How to fix? According to Guanming, this is not a simple duplicate (which btw, is ignored by default by paxtools). 

I did not completely understand Emek's idea though, but think that in all such examples, simply using different instances of ModificationFeature (thus different URIs) would make the problem go away. 

We want:

<bp:Protein rdf:ID="Protein394">

<bp:feature rdf:resource="#ModificationFeatureX" />
<bp:feature rdf:resource="#ModificationFeatureY" />
</bp:Protein>

instead 

<bp:Protein rdf:ID="Protein394">

<bp:feature rdf:resource="#ModificationFeatureX" />
<bp:feature rdf:resource="#ModificationFeatureX" />
</bp:Protein>

Best,

IR.

[Guanming Wu]

Hi Igor,

In our data model, we allow such duplications in order to indicate multiple same modifications (with unknown positions) at one protein. We have close to 1,700 such human annotated cases! Indeed, we may write a script to duplicate these modifications for proteins. However, it seems pretty clear without any ambiguity in our end.

But we may be able to tweak the export a little bit in order to make OWL happy.

Thanks,

Guanming

[Igor Rodchenkov]

On Friday, May 10, 2013 1:54:59 PM UTC-4, wgm wrote:

Hi Emek,

I guess we may need. But then these two modifications will point to the same UnificationXref. Will they?

If we're not talking about instances of Protein, then -  MF is a utility class. Two MF in this example will definitely have different URI, cannot share no UnificationXref (ok for rel. xrefs), CAN have same modification type (controlled vocabulary instance, no problem).

off-topic PS:

Strictly speaking, different biopax Things can only have the same UnificationXref if they are about the same,.. which implies you or users will have to merge these Things into one Thing sonner or later. Therefore data providers, at least within one biopax data file, can always make it so convenient that there are no shared UnificationXref and no confusion at all. UnificationXrefs are like URIs but somewhat fuzzy and allow having several alternative identities on the same object...

IR.

[Igor Rodchenkov]

On Friday, May 10, 2013 5:57:12 PM UTC-4, wgm wrote:

Hi Igor,

In our data model, we allow such duplications in order to indicate multiple same modifications (with unknown positions) at one protein. We have close to 1,700 such human annotated cases! Indeed, we may write a script to duplicate these modifications for proteins. However, it seems pretty clear without any ambiguity in our end.

"multiple same modifications (with unknown positions)" - funny!  This phrase is clear example where same is not "same". Multiple same modifications with unknown positions are different mod. of same sort. Sort - is described by the same CV (modificationType), and to tell one from others URIs are used. Does not matter all this MF instances will have other biopax prop. same (or empty).

 

But we may be able to tweak the export a little bit in order to make OWL happy.

It's not for OWL's sake, really  ;) I believe you understand that.

 

Thanks,

Guanming

...

[Guanming Wu]

OK. If you take a look at this example (hasModifiedResidue):

http://www.reactome.org/cgi-bin/instancebrowser?DB=gk_current&ID=192213&

I think it suffices to indicate that protein SNRPB has two methylations without creating two copies of "monomethylated residue at unknown position". 

I think this is similar to reuse of a term in a controlled vocabulary without duplication. Here we just wrap a psiMod and referenceSequence together with no need to specify position:

http://www.reactome.org/cgi-bin/instancebrowser?DB=gk_current&ID=192221&

Thanks,

Guanming

 

[Oliver Ruebenacker]

     Hello Guanming,

  Think about how you would say in English that Obama has two daughters without using the word "two", without knowing their names and without using more than one verb per sentence.

  This would be wrong:

  "There is a woman X. X is daughter of Obama. X is daughter of Obama."

  A possible version could be:

  "There is a woman X. X is daughter of Obama. There is a woman Y. Y is daughter of Obama."

     Take care
     Oliver

[Guanming Wu]

However, a database modelling is not an English translation. We may simplify our modeling to make it simpler without losing information, I think.

Thanks,

Guanming

[Oliver Ruebenacker]

     Hello Guanming,

  In this particular case, RDF and English follow the same logic.

  It may seem tedious to spell out the two modifications of unknown locations, but it has advantages, too, for example if:

  - The protein is transformed somehow, and you want to state that it still has the same modifications before and after the transformation.

  - At some point, the location may be known. Maybe first for one, and later for the other.

     Take care
     Oliver

[Guanming Wu]

Hi Oliver,

I believe what you said is right regarding RDF. Indeed, it will be better if we change our web display a little bit to show something like this:

2 x "monomethylated residue at unknown position"

for easy understanding.

However, the way we store our annotations into our database is another story, which may have been mixed in this thread.

Thanks,

Guanming

[Igor Rodchenkov]

Guanming,

There is no point for fighting right now, really. 

But we could discuss about how and whether to improve it in the Level 4 biopax (looks you'd like having for 'features' something similar to stoichiometry for physical entities).

Again, the following "duplication" is simply syntactically wrong and does not make sense in BioPAX L3 (and RDF/OWL too),

regardless what is Reactome's model:

<bp:Protein rdf:ID="Protein394">

    <bp:feature rdf:resource="#ModificationFeature48" />

    <bp:feature rdf:resource="#ModificationFeature48" />

</bp:Protein>

And nobody will be able to use such information w/o hacking; so why to do so?

Please, create different modification features (with diff. URIs) in all similar cases.

(We cannot accept all data that looks like or reminds "BioPAX L3" (or "RDF") to be in fact biopax.

We have a contract defined by the specification, which is already very flexible and open...)

[Guanming Wu]

Hi Igor,

Thanks! We will enter this requirement into our software management system, and will try to fix it, though we cannot promise a time right now.

Guanming