Forums

Hej Neil,

I might add that we had some problems with SBML model versioning as well in
1) context of simulation descriptions... where we need to refer to a
specific version of an SBML model. Which turned out to be not too easy
to solve.
2) context of model retrieval... where we have to decide which version
of a model to return as relevant to a user, and even more: to decide
when to create new model versions and when to decide for storing a new
model.

I do agree with you that the problem Kieran mentioned seem to be more in
of a versioning kind (although I was not sure I understood them fully.).

We're currently looking at a mechanism to do versioning that fills the
needs for model retrieval and also for SED-ML, and it would definitely
be nice to see what other people think about how to solve the problems.

Dagmar


Neil Swainston wrote:
> Hi all,
>
> I can understand Kieran's requirements for this (some of them came up through stuff that we've done together). However, I'm still not sure whether this is an annotation problem, or something that can be fixed with a more modular approach (utilising the "comp" extension) or something that requires a better handling of SBML versioning and tracking.
>
> It seems to me that we (as a community) are not too clever at this. I guess that this hasn't been a problem previously, but my guess is that it will as models evolve and people start extending and merging existing models.
>
> Anyone out there in the SBML-osphere looking at SBML versioning / tracking?
>
> Cheers,
>
> Neil.
>
> Neil Swainston
> Experimental Officer
>
> Manchester Centre for Integrative Systems Biology
> Manchester Interdisciplinary Biocentre
> University of Manchester
> Manchester M1 7DN
> England
>
> On 26 Mar 2010, at 18:28, kieran wrote:
>
>
>> Hello Camille,
>>
>> Thanks for the reply, though I'm not convinced by your arguments either. Here's my two cents.
>>
>>
>>> Why one would update a model (I understand "make it better") and after
>>> that still work on the older version? And, in the case both actions
>>> (update and analysis) were done concurrently, can't you run a similar
>>> analysis on 2 afterwards?
>>>
>> The real problem is that different groups are involved in each activity. As an example, other groups are using http://dx.doi.org/10.1038/nbt1492 as a tool, despite the fact that there are two newer versions available http://www.comp-sys-bio.org/yeastnet/. Should they provide a list of ids and a list of interesting things to do with those ids, we (or indeed a third party) would like to be able compare those things to the current version.
>>
>>
>>>> * we decide to merge two big models #A and #B into one really big "consensus" model #C. A and B are not necessarily well-annotated. We'd like to ask questions like "how many reactions from A are present in C?" but are lacking the mapping needed.
>>>>
>>> Fundamentally, I still think the best is to annotate the models A and B
>>> instead of annotating (only) C (and if you do annotate A and B, C will
>>> come fully annotated for free). This is for the simple fact that, if
>>> one, later, wants to use A and D for something else, he/she will need to
>>> redo part of the work you already did...
>>>
>> A and B could already be annotated (by another group); I'm a big fan of annotating other people's models when you can, but nonetheless we can only get so far by comparing annotations. For example, following Oliver's lead, urn:miriam:biomodels.element:BIOMD0000000001.BLL and urn:miriam:biomodels.element:BIOMD0000000001.IL have the same annotation, but are clearly different. If I were to create a model containing these species, but not the whole Edelstein model, there is currently no mechanism other than sticking something in the notes to identify them. A computer-readable annotation would (if possible) be highly preferable for us.
>>
>> Cheers,
>> Kieran
>>
>>
>> On 26 Mar 2010, at 17:00, Camille Laibe wrote:
>>
>>
>>> Hi Kieran,
>>>
>>> This is a rather interesting issue. Although I'm not convinced by your
>>> examples. I'm sorry, but this is important because there are various
>>> proper solutions to handle this situation, depending on what you are
>>> actually trying to achieve.
>>>
>>>
>>>> Thanks for your mail, and I appreciate your point. However, the reason behind this would not be to reduce the annotation burden (rather the opposite!)
>>>>
>>> If that would take more time, so why not just annotating the models of
>>> interest in the first place? Like that, there is no need to invent
>>> anything new and you save time. I don't understand.
>>>
>>>
>>>> * big model #1 is annotated with bells and whistles, and we create an updated version #2, also fully annotated. Now suppose someone does analysis on 1; the question is how we map these results onto the new network. Ideally, of course, metabolites (say) in each model would be annotated with the same ChEBI. But if we realise that the wrong ChEBI was used (and we don't rely on IDs), then any relationship between the models has been lost.
>>>>
>>> Why one would update a model (I understand "make it better") and after
>>> that still work on the older version? And, in the case both actions
>>> (update and analysis) were done concurrently, can't you run a similar
>>> analysis on 2 afterwards?
>>>
>>>
>>>> * we decide to merge two big models #A and #B into one really big "consensus" model #C. A and B are not necessarily well-annotated. We'd like to ask questions like "how many reactions from A are present in C?" but are lacking the mapping needed.
>>>>
>>> If you are lacking the mapping, nobody will ever be able to answer this
>>> question. This mapping can either be achieved by properly annotating A
>>> and B, or by adding a new kind of annotation in C.
>>> Now the big question is: which one is the easiest/fastest/cheapest?
>>> According to what you said in your first sentence, I'm not sure to
>>> understand why you are trying to come up with a new annotation scheme...
>>>
>>> Fundamentally, I still think the best is to annotate the models A and B
>>> instead of annotating (only) C (and if you do annotate A and B, C will
>>> come fully annotated for free). This is for the simple fact that, if
>>> one, later, wants to use A and D for something else, he/she will need to
>>> redo part of the work you already did...
>>>
>>> Anyway, for this kind of case, I would suggest you to have a look at the
>>> "comp" extension for SBML L3
>>> (http://sbml.org/Community/Wiki/SBML_Level_3_Proposals/Hierarchical_Model_Composition).
>>>
>>>
>>> Best regards.
>>>
>>> --
>>> Camille Laibe
>>> BioModels.net Coordinator
>>> European Bioinformatics Institute, Cambridge (UK)
>>> ____________________________________________________________
>>> To manage your sbml-discuss list subscription, visit
>>> https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss
>>>
>>> For a web interface to the sbml-discuss mailing list, visit
>>> http://sbml.org/Forums/
>>>
>>> For questions or feedback about the sbml-discuss list,
>>> contact sbml-team@caltech.edu
>>>
>> --
>> kieran smallbone
>> kieran.smallbone@manchester.ac.uk
>> http://www.mcisb.org/people/smallbone
>>
>> manchester centre for integrative systems biology
>> manchester interdisciplinary biocentre
>> 131 princess street
>> manchester m1 7dn. uk
>>
>> ____________________________________________________________
>> To manage your sbml-discuss list subscription, visit
>> https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss
>>
>> For a web interface to the sbml-discuss mailing list, visit
>> http://sbml.org/Forums/
>>
>> For questions or feedback about the sbml-discuss list,
>> contact sbml-team@caltech.edu
>>
>
> ____________________________________________________________
> To manage your sbml-discuss list subscription, visit
> https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss
>
> For a web interface to the sbml-discuss mailing list, visit
> http://sbml.org/Forums/
>
> For questions or feedback about the sbml-discuss list,
> contact sbml-team@caltech.edu
>

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

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

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