Forums

Hi all,

I realize that there is no inherent order of the various MIRIAM annotations
in an <annotation> element, and I certainly don't think there should be any
such thing.

However, saying that, I'm trying to do a diff between two SBML files, and
I'm running into trouble when comparing the MIRIAM annotations. Essentially,
the ordering in the file as downloaded from BioModels seems to be different
than the ordering of the messed-with version of the SBML file that I created
and am trying to compare against.

I know that if I just run libsbml's Reader and Writer over the BioModels
file, the outputted file is identical to the one coming in. Therefore it
must be my "messing" that is changing the order of the MIRIAM annotations.

I guess all I'd like to ask at this stage is:


1. Does the order with which the CVTerms are added make a difference to
the ultimate outcome of the way the MIRIAM annotations are written out? (I'm
guessing yes from my experience)
2. Is there any helper method to ensure that the ordering of new CVTerms
would be identical to the "biomodels/sbml approved" ordering?

This #2 part would make my "diff" life much, much easier.

Thanks very much,
Allyson

--
Allyson Lister
http://themindwobbles.wordpress.com

CISBAN, http://www.cisban.ac.uk
Newcastle University
____________________________________________________________
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

* Allyson Lister <a.l.lister@newcastle.ac.uk> [2009-09-10 17:00] writes:
> Hi all,
>
> I realize that there is no inherent order of the various MIRIAM annotations
> in an <annotation> element, and I certainly don't think there should be any
> such thing.
>
> However, saying that, I'm trying to do a diff between two SBML files, and
> I'm running into trouble when comparing the MIRIAM annotations. Essentially,
> the ordering in the file as downloaded from BioModels seems to be different
> than the ordering of the messed-with version of the SBML file that I created
> and am trying to compare against.

Hrm. I think if I was in your situation, I'd write a perl/python script
to (say) alphabetize the MIRIAM annotations on both files, then diff that
output.

However, on a whim I googled 'xmldiff' and discovered

http://www.logilab.org/859

and

http://freshmeat.net/projects/xmldiff/

so maybe those will work (if indeed they're not the same thing)?

-Lucian
____________________________________________________________
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

Hi all,

Related to this mail, recent chatter about developing a pure Java
version and - dare I say it - the speciesType discussion, could I
throw in a cheeky request for implementation of equals / hashCode
methods for SBases in libsbml?

I don't know what the equivalents are in C++, but these two methods -
if implemented correctly - are enormous time-savers, and would be
immensely useful if and when we ever get around to merging our models.

Also, if the equality comparison was made at the level of annotations,
as I suspect they should be (two "things" that share "is" annotations
are equal), then it may act as an encouragement for us all to use
annotations, rather than the id="my_thing_in_this_compartment" syntax
that we've all grown to know and love.

This may reignite the "we can't annotate everything" discussion, but
given that we don't implement any kind of equality operators at the
moment, nobody would lose anything, and it also may act as an impetus
to solve outstanding "we can't annotate everything" problems.

Cheers,

Neil.

P.S. Further reading for those with lots of time on their hands this
weekend: http://java.sun.com/developer/Books/effectivejava/Chapter3.pdf

Neil Swainston
Experimental Officer

Manchester Centre for Integrative Systems Biology
Manchester Interdisciplinary Biocentre
University of Manchester
Manchester M1 7DN
England

> On 10 Sep 2009, at 15:32, Allyson Lister wrote:
>
>> Hi all,
>>
>> I realize that there is no inherent order of the various MIRIAM
>> annotations
>> in an <annotation> element, and I certainly don't think there
>> should be any
>> such thing.
>>
>> However, saying that, I'm trying to do a diff between two SBML
>> files, and
>> I'm running into trouble when comparing the MIRIAM annotations.
>> Essentially,
>> the ordering in the file as downloaded from BioModels seems to be
>> different
>> than the ordering of the messed-with version of the SBML file that
>> I created
>> and am trying to compare against.
>>
>> I know that if I just run libsbml's Reader and Writer over the
>> BioModels
>> file, the outputted file is identical to the one coming in.
>> Therefore it
>> must be my "messing" that is changing the order of the MIRIAM
>> annotations.
>>
>> I guess all I'd like to ask at this stage is:
>>
>>
>> 1. Does the order with which the CVTerms are added make a
>> difference to
>> the ultimate outcome of the way the MIRIAM annotations are
>> written out? (I'm
>> guessing yes from my experience)
>> 2. Is there any helper method to ensure that the ordering of new
>> CVTerms
>> would be identical to the "biomodels/sbml approved" ordering?
>>
>> This #2 part would make my "diff" life much, much easier.
>>
>> Thanks very much,
>> Allyson
>>
>> --
>> Allyson Lister
>> http://themindwobbles.wordpress.com
>>
>> CISBAN, http://www.cisban.ac.uk
>> Newcastle University
>> ____________________________________________________________
>> 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
____________________________________________________________
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

Hi Akiya,

> your request seems to be as follows:

equals => comparing the value of each attribute and subelements
(if any)
in the target SBase derived object
(i.e. comparing the contents of the SBase derived
object)

hashCode => returning a hash value based on the contents of the
SBase
derived object.

> Is this correct?

Yes, this is correct. Although I appreciate that it is potential
(very) problematic.

Ideally, what I would like (and I guess other people would like), is
an equals method that allows me to say that cytosolic glucose in model
1 is equal to cytsolic glucose in model 2. In an ideal world, I'd like
to be able to write something along the lines of...

Set<Species> allSpecies = new HashSet<Species>();
allSpecies.addAll( model1.getListOfSpecies() );
allSpecies.addAll( model2.getListOfSpecies() );

...such that allSpecies contains the union of both sets of species
from models 1 and 2. Merging models (or at least, networks) would
become a great deal easier.

The problems are many fold. Not least that until we're sure what a
'species' actually is, then we can't really define whether two or more
are the same.

Cheers,

Neil.

Neil Swainston
Experimental Officer

Manchester Centre for Integrative Systems Biology
Manchester Interdisciplinary Biocentre
University of Manchester
Manchester M1 7DN
England

On 16 Sep 2009, at 13:48, Akiya Jouraku wrote:

> Hello Neil,
>
> Neil Swainston <neil.swainston@manchester.ac.uk> wrote
>> Hi all,
>>
>> Related to this mail, recent chatter about developing a pure Java
>> version and - dare I say it - the speciesType discussion, could I
>> throw in a cheeky request for implementation of equals / hashCode
>> methods for SBases in libsbml?
>>
>> I don't know what the equivalents are in C++, but these two methods -
>> if implemented correctly - are enormous time-savers, and would be
>> immensely useful if and when we ever get around to merging our
>> models.
>
> Actually, equals and hashCode methods for each SBase derived class
> have already been implemented (overridden from those of Java's
> Object class)
> in libSBML Java bindings as follows (implemented in src/bindings/
> java/local.i):
>
> (Similary, Equals and GetHashCode methods have been implemented in
> C# bindings)
>
> =
> =
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> /**
> *
> * Overrides the 'equals' method for SBase subclasses and other classes
> * in libsbml.
> *
> * By default, 'equals' method ( and '==' operator) for each wrapped
> class
> * object returns 'true' if the given two objects refer to the same
> * *Java proxy object* (not the underlying C++ object).
> * For example, the following code returns 'true'.
> *
> * Model m = new Model();
> * m.createReaction();
> * Reaction r1 = m.getReaction(0);
> * Reaction r2 = r1;
> * return r1.equals(r2); <---- this returns 'true'
> *
> * On the other hand, the following code returns 'false' in spite of
> * the same underlying C++ objects.
> *
> * Model m = new Model();
> * m.createReaction();
> * Reaction r1 = m.getReaction(0);
> * Reaction r2 = m.getReaction(0);
> * return r1.equals(r2); <---- this returns 'false'
> *
> * The following override changes the behaviour of 'equals' method
> such that
> * returns 'true' if the given two objects refer to the same
> underlying C++
> * object (i.e. 'true' is returned in the both above examples).
> *
> * (Unfortunately, '==' operator can't be overidden in Java.
> * Thus, the underlying C++ objects can't be compared by the '=='
> operator.)
> *
> */
>
> %define SWIGJAVA_EQUALS(CLASS)
> %typemap("javacode") CLASS
> %{
> /**
> * Equality comparison method for CLASS.
> * <p>
> * Because the Java methods for libSBML are actually wrappers
> around code
> * implemented in C++ and C, certain operations will not behave as
> * expected. Equality comparison is one such case. An instance of a
> * libSBML object class is actually a <em>proxy object</em>
> * wrapping the real underlying C/C++ object. The normal <code>==</
> code>
> * equality operator in Java will <em>only compare the Java proxy
> objects</em>,
> * not the underlying native object. The result is almost never
> what you
> * want in practical situations. Unfortunately, Java does not
> provide a
> * way to override <code>==</code>.
> * <p>
> * The alternative that must be followed is to use the
> * <code>equals()</code> method. The <code>equals</code> method on
> this
> * class overrides the default java.lang.Object one, and performs an
> * intelligent comparison of instances of objects of this class. The
> * result is an assessment of whether two libSBML Java objects are
> truly
> * the same underlying native-code objects.
> * <p>
> * The use of this method in practice is the same as the use of any
> other
> * Java <code>equals</code> method. For example,
> * <em>a</em><code>.equals(</code><em>b</em><code>)</code> returns
> * <code>true</code> if <em>a</em> and <em>b</em> are references to
> the
> * same underlying object.
> *
> * @param sb a reference to an object to which the current object
> * instance will be compared
> *
> * @return <code>true</code> if <code>sb</code> refers to the same
> underlying
> * native object as this one, <code>false</code> otherwise
> */
> public boolean equals(Object sb)
> {
> if ( this == sb )
> {
> return true;
> }
> return swigCPtr == getCPtr((CLASS)(sb));
> }
>
> /**
> * Returns a hashcode for this CLASS object.
> *
> * @return a hash code usable by Java methods that need them.
> */
> public int hashCode()
> {
> return (int)(swigCPtr^(swigCPtr>>>32));
> }
> %}
> %enddef
> =
> =
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
>
> However, I think the behaviour of the above equals and hashCode is
> different from
> your request because the behvaiour of the above functions are such
> that
>
> equals => comparing the pointer of the underlying C++ object
> (swigCPtr)
> hashCode => returning the pointer as a bit-shifted int value
>
> (In other words, the behvaiour is SWIG/Java specific)
>
> whereas your request seems to be as follows:
>
> equals => comparing the value of each attribute and subelements
> (if any)
> in the target SBase derived object
> (i.e. comparing the contents of the SBase derived
> object)
>
> hashCode => returning a hash value based on the contents of the
> SBase
> derived object.
>
> Is this correct?
>
> If so, I think libSBML Java should provide two comparison
> functions : one is
> for comparing pointers of underlying C++ objects (existing
> functions), and the other
> is comparing the contents of the SBase derived objects (your request).
>
> I think the options would be
>
> (1) changes the behaviour of existing equals() and hashCode()
> functions
> (comparing C++ objects ---> comparing contents of the objects)
> ,and reimplements (i.e. renames) existing functions for comparing
> underlying C++ objects.
>
> or
>
> (2) adds functions for comparing contents of the objects, and
> existing equals() and hashCode() functions are not changed.
>
> (new comparison functions would be implemented in C++ and will be
> wrapped
> in each language bindings accordingly.)
>
>
> The tradeoff is that #1 seems to be what you expect but #1 can break
> existing code, and #2 may be a bit different from what you expect but
> #2 doesn't break existing code.
>
> What do you think?
>
> Thanks,
>
> Akiya
>
>

____________________________________________________________
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