Forums

Dear Allyson,

species: id="Y2_1" name="i_cyclinE_CDK2".
There was indeed an error in the annotation of the above species. Both
the bags should have "hasVersion" as qualifier.
It has now been corrected.
Thank you for pointing out the usage of incorrect qualifier in the
annotation.

I have also changed the annotation for "p27" with UNIPORT id. p27 was
initially annotated with an Interpro term, which no longer exist.

best regards,
Viji



Camille Laibe wrote:
> Dear curators,
>
> Could you have a look at the annotations of BIOMD0000000169? Specially
> the ones for the "i_cyclinE_CDK2" (there might be others).
> Please refer to the message below from Allyson about a potential bug in
> libSBML, but also a potential annotation error in BioModels Database.
>
> Thanks.
>
> -------- Original Message --------
> Subject: [sbml-interoperability] accidental removal of MIRIAM
> annotation from Biomodels 169
> Date: Tue, 21 Jun 2011 16:05:07 +0100
> From: Allyson Lister <allyson.lister@newcastle.ac.uk>
> Reply-To: SBML Software Interoperability Discussion List
> <sbml-interoperability@caltech.edu>
> To: SBML Software Interoperability Discussion List
> <sbml-interoperability@caltech.edu>
>
> Hi all,
>
> This is a question about libSBML 5.0.0 (java version), running on Natty.
>
> I have a test where, for each SBML element with such annotation, the MIRIAM
> annotation is extracted. This test is currently using Biomodels entry number
> 169.
> It reorganizes all extracted annotation alphabetically, then adds the
> annotation back into the sbml element (having deleted the original
> annotation first). This is part of a bit of a comparison class, but that's
> not really relevant to this discussion.
>
> In Biomodels 169, some weird behaviour is encountered during the parsing of
> the MIRIAM annotation for the species with ID Y2_1.
>
> Here is the relevant code:
>
> // here, all CV terms are copied via cloneObject() int a
> variable called cvTerms
> ArrayList<CVTerm> cvTerms = new ArrayList<CVTerm>();
> for ( long iii = 0; iii < sbase.getNumCVTerms(); iii++ ) {
> cvTerms.add( sbase.getCVTerm( iii ).cloneObject() );
> }
> // delete all terms
> sbase.unsetCVTerms();
>
> // do some stuff here with cvTerms (unimportant for this
> discussion I think)
>
> // print out the current state of cvTerms
> if (sbase instanceof Species && sbase.getId().equals("Y2_1")) {
> System.err.println( "BEFORE number of cv terms = " +
> cvTerms.size() );
> for ( CVTerm cvTerm : cvTerms ) {
> System.err.println( "BEFORE (start of cv term)" );
> for ( long jjj = 0; jjj < cvTerm.getNumResources();
> jjj++ ) {
> System.err.println( "BEFORE resource URI: " +
> cvTerm.getResourceURI( jjj ) );
> }
> }
> }
> // this is the only bit of code that's actually run in this
> excerpt: add cvTerms back to sbase.
> for ( CVTerm cvterm : cvTerms ) {
> sbase.addCVTerm( cvterm );
> }
> // repeat the verbosity but with the sbase object this time
> if (sbase instanceof Species && sbase.getId().equals("Y2_1")) {
> System.err.println( " AFTER number of cv terms = " +
> sbase.getNumCVTerms() );
> for ( long iii = 0; iii < sbase.getNumCVTerms(); iii++ ) {
> System.err.println( "AFTER (start of cv term)" );
> for ( long jjj = 0; jjj <
> sbase.getCVTerm(iii).getNumResources(); jjj++ ) {
> System.err.println("AFTER resource URI: " +
> sbase.getCVTerm( iii ).getResourceURI(jjj));
> }
> }
> }
>
> So, all I'm doing here is adding a bunch of CVTerms to the sbase object.
> But, take a look at the output:
>
> BEFORE number of cv terms = 2
> BEFORE (start of cv term)
> BEFORE resource URI: urn:miriam:uniprot:P24941
> BEFORE resource URI: urn:miriam:uniprot:O96020
> BEFORE (start of cv term)
> BEFORE resource URI: urn:miriam:uniprot:P24941
> BEFORE resource URI: urn:miriam:uniprot:P24864
>
> So far so good: the "BEFORE" lines match what you can see if you look at
> biomodels entry 169. Then the addCVTerm method is run over each CVTerm, and
> then the output is:
>
> AFTER number of cv terms = 2
> AFTER (start of cv term)
> AFTER resource URI: urn:miriam:uniprot:P24941
> AFTER resource URI: urn:miriam:uniprot:O96020
> AFTER (start of cv term)
> AFTER resource URI: urn:miriam:uniprot:P24864
>
> Yes, it is weird that 169 has both a isVersionOf and a hasVersion that's
> pointing to P24941, but is libSBML doing some fancy checking at this stage
> to remove what it thinks might be a duplicate? I would have thought it would
> preserve the way the annotation was to begin with. Is this expected
> behaviour?
>
> Am I missing something obvious?
>
> Thanks,
> Allyson
> ____________________________________________________________
> To manage your sbml-interoperability list subscription, visit
> https://utils.its.caltech.edu/mailman/listinfo/sbml-interoperability
>
> For a web interface to the sbml-interoperability mailing list, visit
> http://sbml.org/Forums/
>
> For questions or feedback about the sbml-interoperability list,
> contact sbml-team@caltech.edu
> _______________________________________________
> Biomodels-cura mailing list
> Biomodels-cura@ebi.ac.uk
> http://listserver.ebi.ac.uk/mailman/listinfo/biomodels-cura
>


--


Vijayalakshmi Chelliah PhD

Computational Systems Neurobiology Group,
European Bioinformatics Institute,
Wellcome Trust Genome Campus,
Hinxton,
Cambridge, CB10 1SD,
United Kingdom
Ph : +44-1223-494418
Fax: +44-1223-494468

http://twitter.com/emblebi

____________________________________________________________
To manage your sbml-interoperability list subscription, visit
https://utils.its.caltech.edu/mailman/listinfo/sbml-interoperability

For a web interface to the sbml-interoperability mailing list, visit
http://sbml.org/Forums/

For questions or feedback about the sbml-interoperability list,
contact sbml-team@caltech.edu