Forums

Hello folks,

Something aired a while ago was a mechanism to annotate an element of a model with reference to the corresponding element in a previous model. This would be *really* useful for us when dealing with iterations of unmanageably big jamboree models. We put forward the idea of mixing MIRIAM and XPath, along the lines of

<species id="met1" name="myMetabolite">
<annotation> <rdf:RDF> <rdf:Description> <bqbiol:is> <rdf:Bag>
<rdf:li rdf:resource="urn:miriam:biomodels.myOldModel[//@id='met2']"/>
</rdf:Bag> </bqbiol:is> </rdf:Description> </rdf:RDF> </annotation>
</species>

but this was poo-pooed: it's probably not a valid URI and definitely not a valid MIRIAM URI. It was suggested that we instead use something proprietary like

<mcisb:mcisb xmlns:mcisb="http://www.mcisb.org/">
<mcisb:origin xref="http://www.mcisb.org/models/myOldModel.xml[//@id='met2']"/>
</mcisb:mcisb>

I'd like to avoid this layer complexity for something which (to my eye) seems rather simple. Does anyone have an alternative idea? Or could this be brought up at the next annotationathon?

Kieran


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

Hi Kieran,

Whilst I appreciate the mechanism(s) you suggest could potentially reduce the annotation burden, this does not strike me as a good idea.
What you would be doing in essence would be using a previous model as a resource, and using an annotation to point to something (original model
element) that itself has further MIRIAM annotations which may need to be dereferenced. A suitable programming analogy may that of creating a pointer
to a pointer. After this layer of potential confusion, the MIRIAM system would then need web services that can cope with XPATH and contend with serial
dereferencing.

Also, in this scenario, since you have identified identical entities in 2 different models, could the tool you are using not transcribe the
annotations from the original model to the new model? I am assuming this is done programmatically of course.

Perhaps there is a misunderstanding on my part on what exactly you are wanting to do, or of the potential benefits?

cheers,

Nick



sbml-discuss-request@caltech.edu wrote:
> Send sbml-discuss mailing list submissions to
> sbml-discuss@caltech.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss
> or, via email, send a message with subject or body 'help' to
> sbml-discuss-request@caltech.edu
>
> You can reach the person managing the list at
> sbml-discuss-owner@caltech.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of sbml-discuss digest..."
>
>
> Today's Topics:
>
> 1. model pointers (kieran)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 24 Mar 2010 20:59:13 +0000
> From: kieran <kieran.smallbone@manchester.ac.uk>
> Subject: [sbml-discuss] model pointers
> To: SBML Discussion List <sbml-discuss@caltech.edu>
> Message-ID: <AD747DD6-E31A-4D5B-B04A-7416EF24DE49@manchester.ac.uk>
> Content-Type: text/plain; charset=us-ascii
>
> Hello folks,
>
> Something aired a while ago was a mechanism to annotate an element of a model with reference to the corresponding element in a previous model. This would be *really* useful for us when dealing with iterations of unmanageably big jamboree models. We put forward the idea of mixing MIRIAM and XPath, along the lines of
>
> <species id="met1" name="myMetabolite">
> <annotation> <rdf:RDF> <rdf:Description> <bqbiol:is> <rdf:Bag>
> <rdf:li rdf:resource="urn:miriam:biomodels.myOldModel[//@id='met2']"/>
> </rdf:Bag> </bqbiol:is> </rdf:Description> </rdf:RDF> </annotation>
> </species>
>
> but this was poo-pooed: it's probably not a valid URI and definitely not a valid MIRIAM URI. It was suggested that we instead use something proprietary like
>
> <mcisb:mcisb xmlns:mcisb="http://www.mcisb.org/">
> <mcisb:origin xref="http://www.mcisb.org/models/myOldModel.xml[//@id='met2']"/>
> </mcisb:mcisb>
>
> I'd like to avoid this layer complexity for something which (to my eye) seems rather simple. Does anyone have an alternative idea? Or could this be brought up at the next annotationathon?
>
> Kieran
>
>
> --
> 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
>
>
>
> ------------------------------
>
> _______________________________________________
> sbml-discuss mailing list
> sbml-discuss@caltech.edu
> https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss
>
>
> End of sbml-discuss Digest, Vol 72, Issue 9
> *******************************************

--
--------------------------------------------------------
Nick Juty
Database Curator
European Bioinformatics Institute
Cambridge, United Kingdom
--------------------------------------------------------
____________________________________________________________
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

Hello,

Perhaps we could adopt a new MIRIAM type biomodels.element to build
new URNs of the form:

urn:miriam:biomodels.element:myOldModel.met2

That URN is already wellformed, and shouldn't cause problems with
current software.

Alternatively, we could adopt a datatype biomodels.species. We could
also extend this into a larger framework of contained types, say, for
every MIRIAM type XXX referring to models, XXX.element refers to
elements of these models (or XXX.species to a species in that model).

Take care
Oliver


On Fri, Mar 26, 2010 at 8:52 AM, kieran
<kieran.smallbone@manchester.ac.uk> wrote:
> Hi Nick,
>
> 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!), nor to use the previous model as a resource. Two exemplar cases where I wish we already had this in place are:
>
> * 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.
>
> * 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.
>
> Hope that makes more sense.
>
> Cheers,
> Kieran
>
>
> On 26 Mar 2010, at 10:10, Nick Juty wrote:
>
>> Hi Kieran,
>>
>> Whilst I appreciate the mechanism(s) you suggest could potentially reduce the annotation burden, this does not strike me as a good idea.
>> What you would be doing in essence would be using a previous model as a resource, and using an annotation to point to something (original model
>> element) that itself  has further MIRIAM annotations which may need to be dereferenced. A suitable programming analogy may that of creating a pointer
>> to a pointer. After this layer of potential confusion, the MIRIAM system would then need web services that can cope with XPATH and contend with serial
>> dereferencing.
>>
>> Also, in this scenario, since you have identified identical entities in 2 different models, could the tool you are using not transcribe the
>> annotations from the original model to the new model? I am assuming this is done programmatically of course.
>>
>> Perhaps there is a misunderstanding on my part on what exactly you are wanting to do, or of the potential benefits?
>>
>> cheers,
>>
>> Nick
>>
>>
>>
>> sbml-discuss-request@caltech.edu wrote:
>>> Send sbml-discuss mailing list submissions to
>>>      sbml-discuss@caltech.edu
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>      https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss
>>> or, via email, send a message with subject or body 'help' to
>>>      sbml-discuss-request@caltech.edu
>>>
>>> You can reach the person managing the list at
>>>      sbml-discuss-owner@caltech.edu
>>>
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of sbml-discuss digest..."
>>>
>>>
>>> Today's Topics:
>>>
>>>   1. model pointers (kieran)
>>>
>>>
>>> ----------------------------------------------------------------------
>>>
>>> Message: 1
>>> Date: Wed, 24 Mar 2010 20:59:13 +0000
>>> From: kieran <kieran.smallbone@manchester.ac.uk>
>>> Subject: [sbml-discuss] model pointers
>>> To: SBML Discussion List <sbml-discuss@caltech.edu>
>>> Message-ID: <AD747DD6-E31A-4D5B-B04A-7416EF24DE49@manchester.ac.uk>
>>> Content-Type: text/plain; charset=us-ascii
>>>
>>> Hello folks,
>>>
>>> Something aired a while ago was a mechanism to annotate an element of a model with reference to the corresponding element in a previous model. This would be *really* useful for us when dealing with iterations of unmanageably big jamboree models. We put forward the idea of mixing MIRIAM and XPath, along the lines of
>>>
>>> <species id="met1" name="myMetabolite">
>>> <annotation> <rdf:RDF> <rdf:Description> <bqbiol:is> <rdf:Bag>
>>> <rdf:li rdf:resource="urn:miriam:biomodels.myOldModel[//@id='met2']"/>
>>> </rdf:Bag> </bqbiol:is> </rdf:Description> </rdf:RDF> </annotation>
>>> </species>
>>>
>>> but this was poo-pooed: it's probably not a valid URI and definitely not a valid MIRIAM URI. It was suggested that we instead use something proprietary like
>>>
>>> <mcisb:mcisb xmlns:mcisb="http://www.mcisb.org/">
>>> <mcisb:origin xref="http://www.mcisb.org/models/myOldModel.xml[//@id='met2']"/>
>>> </mcisb:mcisb>
>>>
>>> I'd like to avoid this layer complexity for something which (to my eye) seems rather simple. Does anyone have an alternative idea? Or could this be brought up at the next annotationathon?
>>>
>>> Kieran
>>>
>>>
>>> --
>>> 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
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> _______________________________________________
>>> sbml-discuss mailing list
>>> sbml-discuss@caltech.edu
>>> https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss
>>>
>>>
>>> End of sbml-discuss Digest, Vol 72, Issue 9
>>> *******************************************
>>
>> --
>> --------------------------------------------------------
>> Nick Juty
>> Database Curator
>> European Bioinformatics Institute
>> Cambridge, United Kingdom
>> --------------------------------------------------------
>> ____________________________________________________________
>> 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
>



--
Oliver Ruebenacker, Computational Cell Biologist
Systems Biology Linker at Virtual Cell (http://vcell.org/sybil)
Turning Knowledge Data into Models
Center for Cell Analysis and Modeling
http://www.oliver.curiousworld.org
____________________________________________________________
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

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

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

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

Hello folks,

A few months back we discussed the pros and cons of annotating with
pointers to model components. Regardless of their dis/advantages, Neil
has come up with a (probably) legal method of implementing this, using
RDF and metaids, that I wanted to pass around.


Example #1 - annotating a complex of two model elements

<species metaid="metaid_A" id="a" name="YAL023C"/>

<species metaid="metaid_B" id="b" name="YDL095W"/>

<species metaid="metaid_C" id="complex" name="YAL023C:YDL095W">
<annotation><rdf:RDF><rdf:Description rdf:about="#metaid_C">
<bqbiol:hasPart><rdf:Bag>
<rdf:li rdf:resource="#metaid_A"/>
<rdf:li rdf:resource="#metaid_B"/>
</rdf:Bag></bqbiol:hasPart>
</rdf:Description></rdf:RDF></annotation>
</species>


Example #2 - annotation pointing to earlier models

<species metaid="metaid" id="glc" name="glucose">
<annotation><rdf:RDF><rdf:Description rdf:about="#metaid">
<bqbiol:is><rdf:Bag>
<rdf:li rdf:resource="http://www.mcisb.org/model1.xml#metaid_glu"/>
<rdf:li rdf:resource="urn:miriam:biomodels.db:MODEL2#metaid_G"/>
</rdf:Bag></bqbiol:is>
</rdf:Description></rdf:RDF></annotation>
</species>


Comments greatly appreciated.

Cheers,
Kieran


--
kieran smallbone
kieran.smallbone@manchester.ac.uk
http://u003f.com/

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

Hi Kieran,

> Example #2 - annotation pointing to earlier models
>
> <species metaid="metaid" id="glc" name="glucose">
> <annotation><rdf:RDF><rdf:Description rdf:about="#metaid">
> <bqbiol:is><rdf:Bag>
> <rdf:li rdf:resource="http://www.mcisb.org/model1.xml#metaid_glu"/>
> <rdf:li rdf:resource="urn:miriam:biomodels.db:MODEL2#metaid_G"/>
> </rdf:Bag></bqbiol:is>
> </rdf:Description></rdf:RDF></annotation>
> </species>

There is one main issue with this solution: the stability of
"http://www.mcisb.org/model1.xml#metaid_glu". This is why MIRIAM URNs
were created in the first place: to have perennial annotations and
therefore not relying on unstable physical locations.
Another minor issue here is the fact to have put both URIs in the same
bag: I believe these should be considered alternative and therefore
should be in separate bags.

Anyway, you will be glad to know that we are working on a new software
architecture for BioModels Database, and one of the new feature will be
the handling of all the various revisions of a model. So, users will be
able to access older versions of a given model. We did not settle yet on
the specific way to identify (and access to) these revisions, but one
simple idea is to have another part in the identifier, for example:
BIOMD0000000011.3, where 3 is the "revision number". If such solution
was to be implemented, a MIRIAM URN would be perfectly suitable for
referencing a specific revision of a model.

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