sbml-dynamic Mailing List for Systems Biology Markup Language (SBML)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Please note the current SBML Editors will continue to work on this 
publication and it will proceed as planned.

SBML Editors

Sorry I was perhaps not completely clear.

Nicolas Le Novere has withdrawn from the paper and has handed over all 
notes/comments etc to the remaining SBML Editors.

There will be a slight hiatus in the timing, but we are close to having 
a manuscript for submission, and we will proceed with this.

Thank you to everyone who has commented so far and I hope this 
completely clarifies the situation.

Sarah
Coordinator of SBML Editors

On 18/09/2018 09:04, Sarah Keating wrote:
> Please note the current SBML Editors will continue to work on this
> publication and it will proceed as planned.
> 
> SBML Editors
> 

Dear Colleagues,

We are in the process of submitting a manuscript describing SBML Level 3 for publication in Molecular Systems Biology as a perspective (current version attached). The manuscript has been written by past and current SBML editors and both its content and structure discussed with MSB editors.

Although the structure and the main messages of the paper have been settled, we would welcome any suggestion you would have in relation with the manuscript.

Best regards

The SBML editors.

The google doc where I have tried to capture today's discussion is at: http://tinyurl.com/ps8ccnt

Thanks to all who contributed. It was very useful.  I also attach the slides but I've also sent them to the drop site.

Ally

Ally Hume
Software Architect
EPCC, The University of Edinburgh
Tel: 0131 651 3397   Skype: ally.hume

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

We developed a dynamic simulator using SBML annotations that is described here:

http://pubs.acs.org/doi/abs/10.1021/sb300082b <http://pubs.acs.org/doi/abs/10.1021/sb300082b>

Some of the ideas from this experience influenced the current SBML dynamic draft package.   This package also has JSBML support, and I think perhaps libSBML support.  The key thing is it piggybacks off the Cell Behavior Ontology (CBO) which is the current effort in this domain with the most support.  

A lot of interesting feedback came in today’s discussion.  It will be an interesting session on Friday I’m sure.  Thanks for your help leading it.

Cheers,

Chris

> On Oct 13, 2015, at 3:12 PM, Ally Hume <a....@ed...> wrote:
> 
> Hi,
> 
> Chris Myers has asked me to lead the Friday afternoon session on Dynamic Structures at Combine.
> 
> I'm keen to discuss the suitability of the package for the dynamic creation of new sub-models as perviously discussed on this forum but I don't want to hijack the whole session for this purpose.
> 
> If anybody else has other topics they would like to discuss please me know so I can ensure we fit them in.  I would be interested to know more about the current status, any draft implementations, the main driving use cases etc.
> 
> Please just email me or catch we at one of the breaks.
> 
> Regards,
> 
> Ally
> 
> 
> Ally Hume
> Researcher, SynthSys, The University of Edinburgh
> Software and Data Architect, EPCC, The University of Edinburgh
> 
> 
> 
> 
> -- 
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> sbml-dynamic mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-dynamic

Hi,

Chris Myers has asked me to lead the Friday afternoon session on Dynamic Structures at Combine.

I'm keen to discuss the suitability of the package for the dynamic creation of new sub-models as perviously discussed on this forum but I don't want to hijack the whole session for this purpose.

If anybody else has other topics they would like to discuss please me know so I can ensure we fit them in.  I would be interested to know more about the current status, any draft implementations, the main driving use cases etc.

Please just email me or catch we at one of the breaks.

Regards,

Ally

Ally Hume
Researcher, SynthSys, The University of Edinburgh
Software and Data Architect, EPCC, The University of Edinburgh

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

Hi,

We are also very interested in dynamic modeling, and we have supported this in our iBioSim tool for some time.  We have been leading the development of the dynamic package, and we would greatly value input.
> 
> The plant model has dynamic sub-mobels for leaves. When it is time to create a new leaf then a new sub-model is create for this leaf.  It would be great to use the Hierarchical Model Composition for the leaf sub-model and use Dynamic Processes for the creation of these sub-models when required.
> 
Yes, this is what is intended.  In our implementation, we use a dynamic cell division event to handle this type of behavior.

> My first question is whether you see this type of thing as something the Dynamic Processes package is attempting to support? Having read the draft specification the type of dynamic functionality supported is tied in very closely to the Cell Behavior Ontology (CBO).  While I can certainly see the need for dynamic functionality such as that proposed in the draft I was expecting to see also more generic dynamic functionality such as to simply create a new sub-model instance. Given this tight coupling to the CBO am wondering if my use case if something you feel the package is trying to support?
> 
Yes, I think we are trying to support your use case.  We use the CBO as that is already being used by people doing multicellular modeling.  We have also come to believe that most tools are implementing these types of models so differently that it is difficult to give a precise semantics for simulation.  Instead, we wanted to encode the timing of key cellular events like cell division.  In this case, we would have an event which is annotated with the CBO term of cell division and an indication that it affects the elements of the sub-model.

> Assuming for the moment that the package should cover the new-leaf dynamics then my next question is regarding how Dynamic Processes would work with Hierarchical Model Composition. In particular, I would like to be able to define variables that are aggregations over the dynamically created sub-models. For example, it would be good to have a variable that is the sum of the masses of each individual leaf.  Hierarchical Model Composition does not define such aggregate functions. I assume the reason for this is because there is not great need for them in a static model as one can simply implement the aggregation by explicitly summing up all the static sub-model variables. However, when sub-models are created dynamically one starts to need such functionality. Therefore, while the such details as probably not part of the Dynamic Processes role there is a strong need for other packages to understand the potential impact on dynamic functionality on them. How would one go about supporting aggregate functions of dynamic sub-models?
> 
Interesting question.  You are correct that this is not easy to do in static models.  However, I’ve been wondering if the groups package may work for this, assuming we gave a group id some mathematical meaning.  The other possibility would be to use new math constructs like Sum to sum over all elements in some way, but again this may require a way of grouping them.  

> That is about as far as I've got in my current thinking. I have no doubt that those in the community have probably discussed such issues for many years now and I'm sure I'm missed many details that have shaped the thinking. Can somebody possibly advise as to how they see SBML being extended to support my use case or whether such functionality is simply not on the radar?
> 
I believe it is on the radar.  There are several potential approaches including extending the dynamic draft to support your needs.  This is still a draft and we need to experiment with it to see how close or far it is from the needs of implementers.

> I am planning to attend the Combine meeting in October and have some time to work on these issues and help where possible so I'm keen to know if anybody is working along these lines so I could maybe collaborate with them.
> 
Excellent.  We would love to discuss this with you while you are here.

Chris

> Thank you for your time.
> 
> Ally
> 
> [1] http://www.pnas.org/content/111/39/E4127
> 
> Ally Hume
> Software Architect, EPCC and Systems Biology modeller at SynthSys  
> The University of Edinburgh
> Skype: ally.hume
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> sbml-dynamic mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-dynamic

Hi Ally,

I work on MultiCellDS and we are working on a data standard for dynamic
multicellular systems. We (theoretically) support hierarchical systems. My
understanding is that SBML (non-multi) is for single cells. We integrate
with CBO and are in touch with the group at Indiana. We can talk more off
list or in person at COMBINE.

Sam

P.S. I'm a little busy this weekend so I won't have timely responses for a
little while.
On Aug 28, 2015 5:41 PM, "Ally Hume" <a....@ed...> wrote:

> Hi,
>
> I am currently exploring how a digital Arabidopsis plant model [1] can be
> rendered in SBML.
>
> Looking at the various packages, the Hierarchical Model Composition and
> Dynamic Processes packages look very useful for capturing the functionality
> of the model.
>
> Having read these specification/drafts I have a few questions that
> hopefully somebody on this help me with or at least point me in the correct
> direction.
>
> The plant model has dynamic sub-mobels for leaves. When it is time to
> create a new leaf then a new sub-model is create for this leaf.  It would
> be great to use the Hierarchical Model Composition for the leaf sub-model
> and use Dynamic Processes for the creation of these sub-models when
> required.
>
> My first question is whether you see this type of thing as something the
> Dynamic Processes package is attempting to support? Having read the draft
> specification the type of dynamic functionality supported is tied in very
> closely to the Cell Behavior Ontology (CBO).  While I can certainly see the
> need for dynamic functionality such as that proposed in the draft I was
> expecting to see also more generic dynamic functionality such as to simply
> create a new sub-model instance. Given this tight coupling to the CBO am
> wondering if my use case if something you feel the package is trying to
> support?
>
> Assuming for the moment that the package should cover the new-leaf
> dynamics then my next question is regarding how Dynamic Processes would
> work with Hierarchical Model Composition. In particular, I would like to be
> able to define variables that are aggregations over the dynamically created
> sub-models. For example, it would be good to have a variable that is the
> sum of the masses of each individual leaf.  Hierarchical Model Composition
> does not define such aggregate functions. I assume the reason for this is
> because there is not great need for them in a static model as one can
> simply implement the aggregation by explicitly summing up all the static
> sub-model variables. However, when sub-models are created dynamically one
> starts to need such functionality. Therefore, while the such details as
> probably not part of the Dynamic Processes role there is a strong need for
> other packages to understand the potential impact on dynamic functionality
> on them. How would one go about supporting aggregate functions of dynamic
> sub-models?
>
> That is about as far as I've got in my current thinking. I have no doubt
> that those in the community have probably discussed such issues for many
> years now and I'm sure I'm missed many details that have shaped the
> thinking. Can somebody possibly advise as to how they see SBML being
> extended to support my use case or whether such functionality is simply not
> on the radar?
>
> I am planning to attend the Combine meeting in October and have some time
> to work on these issues and help where possible so I'm keen to know if
> anybody is working along these lines so I could maybe collaborate with them.
>
> Thank you for your time.
>
> Ally
>
> [1] http://www.pnas.org/content/111/39/E4127
>
> Ally Hume
> Software Architect, EPCC and Systems Biology modeller at SynthSys
> The University of Edinburgh
> Skype: ally.hume
>
>
>
>
>
>
>
>
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> sbml-dynamic mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-dynamic
>

Hi,

I am currently exploring how a digital Arabidopsis plant model [1] can be rendered in SBML.

Looking at the various packages, the Hierarchical Model Composition and Dynamic Processes packages look very useful for capturing the functionality of the model.

Having read these specification/drafts I have a few questions that hopefully somebody on this help me with or at least point me in the correct direction.

The plant model has dynamic sub-mobels for leaves. When it is time to create a new leaf then a new sub-model is create for this leaf.  It would be great to use the Hierarchical Model Composition for the leaf sub-model and use Dynamic Processes for the creation of these sub-models when required.

My first question is whether you see this type of thing as something the Dynamic Processes package is attempting to support? Having read the draft specification the type of dynamic functionality supported is tied in very closely to the Cell Behavior Ontology (CBO).  While I can certainly see the need for dynamic functionality such as that proposed in the draft I was expecting to see also more generic dynamic functionality such as to simply create a new sub-model instance. Given this tight coupling to the CBO am wondering if my use case if something you feel the package is trying to support?

Assuming for the moment that the package should cover the new-leaf dynamics then my next question is regarding how Dynamic Processes would work with Hierarchical Model Composition. In particular, I would like to be able to define variables that are aggregations over the dynamically created sub-models. For example, it would be good to have a variable that is the sum of the masses of each individual leaf.  Hierarchical Model Composition does not define such aggregate functions. I assume the reason for this is because there is not great need for them in a static model as one can simply implement the aggregation by explicitly summing up all the static sub-model variables. However, when sub-models are created dynamically one starts to need such functionality. Therefore, while the such details as probably not part of the Dynamic Processes role there is a strong need for other packages to understand the potential impact on dynamic functionality on them. How would one go about supporting aggregate functions of dynamic sub-models?

That is about as far as I've got in my current thinking. I have no doubt that those in the community have probably discussed such issues for many years now and I'm sure I'm missed many details that have shaped the thinking. Can somebody possibly advise as to how they see SBML being extended to support my use case or whether such functionality is simply not on the radar?

I am planning to attend the Combine meeting in October and have some time to work on these issues and help where possible so I'm keen to know if anybody is working along these lines so I could maybe collaborate with them.

Thank you for your time.

Ally

[1] http://www.pnas.org/content/111/39/E4127

Ally Hume
Software Architect, EPCC and Systems Biology modeller at SynthSys  
The University of Edinburgh
Skype: ally.hume

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

Hi Lucian,

I have asked the CBO developers about the possibility of expanding the
ontology should we need to, and they are very willing to work with us on
this.

Also, CBO does have generic terms for "Creation" and "Deletion" of an
object -you can find them under the CBOProcess:FundamentalPhysicalProcess
branch. This means that though the current specification focuses on cell
behavior use cases as Chris mentioned, this formulation is still able to
embody the general behavior that was envisioned for the package.

Best,

On Thu, Oct 9, 2014 at 11:00 PM, Lucian Smith <luc...@gm...>
wrote:

> Well, the point is that there *aren't* generic CBO terms for 'create' nor
> 'destroy'.  Do we forsee that happening?  I would have imagined that being
> very unlikely.
>
> -Lucian
>
> On Thu, Oct 9, 2014 at 1:55 PM, Chris J. Myers <my...@ec...> wrote:
>
>> Actually, it is possible to still do creation and destruction of
>> arbitrary SBML elements in the current draft, though we may need a new CBO
>> term.  To perform cell division, one creates an event, tags it with the CBO
>> term for cell division, and adds a list of dynElements that includes all
>> SBML elements that must be duplicated during the cell division.  Similarly,
>> to perform cell death, one creates an event, tags it with the CBO term for
>> cell death, and adds a list of dynElements that includes all SBML elements
>> that must be removed by cell death.
>>
>> If there are CBO terms for say "create" and "destroy", then the same
>> approach just described could be used to duplicate or remove any SBML
>> element but putting just that element in the list of dynElements.
>>
>> Indeed, though there is the question is whether or not this is ever a
>> useful thing to do.  I think it might be, for example, if you want to
>> create say new types of species dynamically (perhaps existing species but
>> in a new state).  I could also imagine as an efficiency, you might remove a
>> part of the model which can no longer contribute to the behavior.  Anyway,
>> the point is that nothing has been lost in the formulation we have, but we
>> just have focussed on cell behavior use cases which don't perhaps exploit
>> the general behavior.
>>
>> Chris
>>
>> On Oct 9, 2014, at 2:45 PM, Lucian Smith <luc...@gm...>
>> wrote:
>>
>> Hmm, I don't think that's *quite* true.  The original package's stated
>> goal was to enable the creation (and destruction) of SBML elements
>> dynamically, full stop.  Enabling the modeling of cellular processes was a
>> prominent use-case, but not the only potential use-case.
>>
>> However, in its current form, the package has completely hitched itself
>> to the CBO, and in so doing, slightly reduced the scope of the original
>> package idea.  It has also expanded its scope to other cellular processes
>> besides creation and destruction, but it has still lost the ability to
>> define creation and destruction outside the scope of *cell* creation and
>> *cell* destruction.
>>
>> Personally, I think the focus of the new scope lends itself better to its
>> use and uptake by the multicellular community, and believe that, overall,
>> it's a worthy direction for an SBML package, but it does raise the
>> question:  is there anyone out there who wants creation and destruction of
>> SBML elements outside of cell creation and destruction?  If not, great;
>> let's just rename the package and move on.  But if so, we'll need to
>> decide:  do we try to accommodate those people within this newly-scoped
>> package, or do we split off and leave that group the old 'dynamic' package,
>> and move forward with a newly-renamed package for CBO?
>>
>> That's probably a question worthy of sbml-discuss, if not an actual poll.
>>
>> -Lucian
>>
>> On Thu, Oct 9, 2014 at 6:29 AM, Chris J. Myers <my...@ec...>
>> wrote:
>>
>>>
>>> >
>>> >> I really think the best way forward is to rebrand what we are doing
>>> >> as "multi-cellular" modeling.  While doing multi-cellular modeling
>>> >> can be done in a limited fashion in core, it does not really handle
>>> >> well what people in this field are doing.
>>> >
>>> > You mean, rename the dynamics package, or simply call this current
>>> work "the Multicellular Modeling package" and leave the "dynamics" package
>>> alone?
>>> >
>>> If I understand you, your question asks whether or not this package
>>> replaces the dynamics package or is really a new package.  It is a bit of
>>> both.  The original dynamics package goal was to enable the creation of
>>> SBML elements dynamically in order to enable the modeling of cellular
>>> processes.  The current version of the package still does this, though
>>> perhaps in a more specialized fashion, but it adds to it the use of CBO and
>>> coarse spatial concept for location.  My vote would be that this replaces
>>> the dynamics package, since it is basically a superset of the original
>>> goals.  A better name though is in order.  I think my current preference
>>> for name would be Cellular Dynamics Package.  It allows us to keep "dyn" as
>>> the shorthand.  It allows for the modeling of single cells or populations.
>>> It would not be confused with the Multistate Modeling Package.
>>>
>>> Chris
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> sbml-dynamic mailing list
>>> sbm...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sbml-dynamic
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________
>> sbml-dynamic mailing list
>> sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbml-dynamic
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>> _______________________________________________
>> sbml-dynamic mailing list
>> sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbml-dynamic
>>
>>
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> sbml-dynamic mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-dynamic
>
>

-- 
Harold Gómez
Bioinformatics PhD. Candidate, Boston University
Graduate School of Arts & Sciences

I don't really see why not.  My experience with most ontology developers is they are usually pretty open to suggestions for terms.

Chris

On Oct 9, 2014, at 3:00 PM, Lucian Smith <luc...@gm...> wrote:

> Well, the point is that there *aren't* generic CBO terms for 'create' nor 'destroy'.  Do we forsee that happening?  I would have imagined that being very unlikely.
> 
> -Lucian
> 
> On Thu, Oct 9, 2014 at 1:55 PM, Chris J. Myers <my...@ec...> wrote:
> Actually, it is possible to still do creation and destruction of arbitrary SBML elements in the current draft, though we may need a new CBO term.  To perform cell division, one creates an event, tags it with the CBO term for cell division, and adds a list of dynElements that includes all SBML elements that must be duplicated during the cell division.  Similarly, to perform cell death, one creates an event, tags it with the CBO term for cell death, and adds a list of dynElements that includes all SBML elements that must be removed by cell death.
> 
> If there are CBO terms for say "create" and "destroy", then the same approach just described could be used to duplicate or remove any SBML element but putting just that element in the list of dynElements.  
> 
> Indeed, though there is the question is whether or not this is ever a useful thing to do.  I think it might be, for example, if you want to create say new types of species dynamically (perhaps existing species but in a new state).  I could also imagine as an efficiency, you might remove a part of the model which can no longer contribute to the behavior.  Anyway, the point is that nothing has been lost in the formulation we have, but we just have focussed on cell behavior use cases which don't perhaps exploit the general behavior.
> 
> Chris
> 
> On Oct 9, 2014, at 2:45 PM, Lucian Smith <luc...@gm...> wrote:
> 
>> Hmm, I don't think that's *quite* true.  The original package's stated goal was to enable the creation (and destruction) of SBML elements dynamically, full stop.  Enabling the modeling of cellular processes was a prominent use-case, but not the only potential use-case.
>> 
>> However, in its current form, the package has completely hitched itself to the CBO, and in so doing, slightly reduced the scope of the original package idea.  It has also expanded its scope to other cellular processes besides creation and destruction, but it has still lost the ability to define creation and destruction outside the scope of *cell* creation and *cell* destruction.
>> 
>> Personally, I think the focus of the new scope lends itself better to its use and uptake by the multicellular community, and believe that, overall, it's a worthy direction for an SBML package, but it does raise the question:  is there anyone out there who wants creation and destruction of SBML elements outside of cell creation and destruction?  If not, great; let's just rename the package and move on.  But if so, we'll need to decide:  do we try to accommodate those people within this newly-scoped package, or do we split off and leave that group the old 'dynamic' package, and move forward with a newly-renamed package for CBO?
>> 
>> That's probably a question worthy of sbml-discuss, if not an actual poll.
>> 
>> -Lucian
>> 
>> On Thu, Oct 9, 2014 at 6:29 AM, Chris J. Myers <my...@ec...> wrote:
>> 
>> >
>> >> I really think the best way forward is to rebrand what we are doing
>> >> as "multi-cellular" modeling.  While doing multi-cellular modeling
>> >> can be done in a limited fashion in core, it does not really handle
>> >> well what people in this field are doing.
>> >
>> > You mean, rename the dynamics package, or simply call this current work "the Multicellular Modeling package" and leave the "dynamics" package alone?
>> >
>> If I understand you, your question asks whether or not this package replaces the dynamics package or is really a new package.  It is a bit of both.  The original dynamics package goal was to enable the creation of SBML elements dynamically in order to enable the modeling of cellular processes.  The current version of the package still does this, though perhaps in a more specialized fashion, but it adds to it the use of CBO and coarse spatial concept for location.  My vote would be that this replaces the dynamics package, since it is basically a superset of the original goals.  A better name though is in order.  I think my current preference for name would be Cellular Dynamics Package.  It allows us to keep "dyn" as the shorthand.  It allows for the modeling of single cells or populations.  It would not be confused with the Multistate Modeling Package.
>> 
>> Chris
>> 
>> 
>> 
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>> _______________________________________________
>> sbml-dynamic mailing list
>> sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbml-dynamic
>> 
>> ------------------------------------------------------------------------------
>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________
>> sbml-dynamic mailing list
>> sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbml-dynamic
> 
> 
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> sbml-dynamic mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-dynamic
> 
> 
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________
> sbml-dynamic mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-dynamic

Thanks for the comments, James!  I think the fact that Chaste already does
multiple modeling approaches is going to make you tool a great use-case for
exchangeability, just within itself.  Have you been able to look at the
current draft in enough detail to be able to say whether its approach would
work for your tool?  Are there any specific questions or concerns that you
have?

-Lucian

On Thu, Oct 9, 2014 at 6:52 AM, James Osborne <jam...@cs...>
wrote:

> Dear all
>
> Sorry for coming late to this discussion. I am one of the Developers of
> Chaste (http://www.cs.ox.ac.uk/chaste/) which as part of it contains a
> multicellular modelling framework.
> The framework allows you to model multiple interacting cells, selecting
> from On and Off lattice modeling approaches (CA, Cell Potts, Cell Centre
> and Cell Vertex Models). It also allows the specification of subcellular
> behaviour (through cell cycle models) which couple to the cells.
>
> The main thing i think that is important for this discussion is that in
> the framework we keep track of the cells topology (and connectivity) in
> each simulation type and this allows us to so the same operations on each
> paradigm (for example solve PDEs or cell cell communication). This could be
> a possible level that the language could specify events on.
> It is the topology and connectivity of cells that is always updated on
> cell division or death. However there are also occurrences where the
> topology changes due to the movement of cells, maybe this should be
> captured separately.
>
> We have come at the problem from an implementation point of view rather
> than ontologies or abstractions but are very keen to make things more
> interchangeable.
>
> Thanks
>
> James
>
>
>
> On Thu, Oct 9, 2014 at 2:29 PM, Chris J. Myers <my...@ec...> wrote:
>
>>
>> >
>> >> I really think the best way forward is to rebrand what we are doing
>> >> as "multi-cellular" modeling.  While doing multi-cellular modeling
>> >> can be done in a limited fashion in core, it does not really handle
>> >> well what people in this field are doing.
>> >
>> > You mean, rename the dynamics package, or simply call this current work
>> "the Multicellular Modeling package" and leave the "dynamics" package alone?
>> >
>> If I understand you, your question asks whether or not this package
>> replaces the dynamics package or is really a new package.  It is a bit of
>> both.  The original dynamics package goal was to enable the creation of
>> SBML elements dynamically in order to enable the modeling of cellular
>> processes.  The current version of the package still does this, though
>> perhaps in a more specialized fashion, but it adds to it the use of CBO and
>> coarse spatial concept for location.  My vote would be that this replaces
>> the dynamics package, since it is basically a superset of the original
>> goals.  A better name though is in order.  I think my current preference
>> for name would be Cellular Dynamics Package.  It allows us to keep "dyn" as
>> the shorthand.  It allows for the modeling of single cells or populations.
>> It would not be confused with the Multistate Modeling Package.
>>
>> Chris
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>> _______________________________________________
>> sbml-dynamic mailing list
>> sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbml-dynamic
>>
>
>
>
> --
> Dr James Osborne
>
> Senior Researcher, Computational Biology,
> University of Oxford Department of Computer Science.
> Web: http://www.cs.ox.ac.uk/people/james.osborne/
> Tel: +44 (0)1865 610671
>
> Visiting Scientist, Computational Science Laboratory,
> Microsoft Research Limited
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> sbml-dynamic mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-dynamic
>
>

Well, the point is that there *aren't* generic CBO terms for 'create' nor
'destroy'.  Do we forsee that happening?  I would have imagined that being
very unlikely.

-Lucian

On Thu, Oct 9, 2014 at 1:55 PM, Chris J. Myers <my...@ec...> wrote:

> Actually, it is possible to still do creation and destruction of arbitrary
> SBML elements in the current draft, though we may need a new CBO term.  To
> perform cell division, one creates an event, tags it with the CBO term for
> cell division, and adds a list of dynElements that includes all SBML
> elements that must be duplicated during the cell division.  Similarly, to
> perform cell death, one creates an event, tags it with the CBO term for
> cell death, and adds a list of dynElements that includes all SBML elements
> that must be removed by cell death.
>
> If there are CBO terms for say "create" and "destroy", then the same
> approach just described could be used to duplicate or remove any SBML
> element but putting just that element in the list of dynElements.
>
> Indeed, though there is the question is whether or not this is ever a
> useful thing to do.  I think it might be, for example, if you want to
> create say new types of species dynamically (perhaps existing species but
> in a new state).  I could also imagine as an efficiency, you might remove a
> part of the model which can no longer contribute to the behavior.  Anyway,
> the point is that nothing has been lost in the formulation we have, but we
> just have focussed on cell behavior use cases which don't perhaps exploit
> the general behavior.
>
> Chris
>
> On Oct 9, 2014, at 2:45 PM, Lucian Smith <luc...@gm...>
> wrote:
>
> Hmm, I don't think that's *quite* true.  The original package's stated
> goal was to enable the creation (and destruction) of SBML elements
> dynamically, full stop.  Enabling the modeling of cellular processes was a
> prominent use-case, but not the only potential use-case.
>
> However, in its current form, the package has completely hitched itself to
> the CBO, and in so doing, slightly reduced the scope of the original
> package idea.  It has also expanded its scope to other cellular processes
> besides creation and destruction, but it has still lost the ability to
> define creation and destruction outside the scope of *cell* creation and
> *cell* destruction.
>
> Personally, I think the focus of the new scope lends itself better to its
> use and uptake by the multicellular community, and believe that, overall,
> it's a worthy direction for an SBML package, but it does raise the
> question:  is there anyone out there who wants creation and destruction of
> SBML elements outside of cell creation and destruction?  If not, great;
> let's just rename the package and move on.  But if so, we'll need to
> decide:  do we try to accommodate those people within this newly-scoped
> package, or do we split off and leave that group the old 'dynamic' package,
> and move forward with a newly-renamed package for CBO?
>
> That's probably a question worthy of sbml-discuss, if not an actual poll.
>
> -Lucian
>
> On Thu, Oct 9, 2014 at 6:29 AM, Chris J. Myers <my...@ec...> wrote:
>
>>
>> >
>> >> I really think the best way forward is to rebrand what we are doing
>> >> as "multi-cellular" modeling.  While doing multi-cellular modeling
>> >> can be done in a limited fashion in core, it does not really handle
>> >> well what people in this field are doing.
>> >
>> > You mean, rename the dynamics package, or simply call this current work
>> "the Multicellular Modeling package" and leave the "dynamics" package alone?
>> >
>> If I understand you, your question asks whether or not this package
>> replaces the dynamics package or is really a new package.  It is a bit of
>> both.  The original dynamics package goal was to enable the creation of
>> SBML elements dynamically in order to enable the modeling of cellular
>> processes.  The current version of the package still does this, though
>> perhaps in a more specialized fashion, but it adds to it the use of CBO and
>> coarse spatial concept for location.  My vote would be that this replaces
>> the dynamics package, since it is basically a superset of the original
>> goals.  A better name though is in order.  I think my current preference
>> for name would be Cellular Dynamics Package.  It allows us to keep "dyn" as
>> the shorthand.  It allows for the modeling of single cells or populations.
>> It would not be confused with the Multistate Modeling Package.
>>
>> Chris
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>> _______________________________________________
>> sbml-dynamic mailing list
>> sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbml-dynamic
>>
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________
> sbml-dynamic mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-dynamic
>
>
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> sbml-dynamic mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-dynamic
>
>

Actually, it is possible to still do creation and destruction of arbitrary SBML elements in the current draft, though we may need a new CBO term.  To perform cell division, one creates an event, tags it with the CBO term for cell division, and adds a list of dynElements that includes all SBML elements that must be duplicated during the cell division.  Similarly, to perform cell death, one creates an event, tags it with the CBO term for cell death, and adds a list of dynElements that includes all SBML elements that must be removed by cell death.

If there are CBO terms for say "create" and "destroy", then the same approach just described could be used to duplicate or remove any SBML element but putting just that element in the list of dynElements.  

Indeed, though there is the question is whether or not this is ever a useful thing to do.  I think it might be, for example, if you want to create say new types of species dynamically (perhaps existing species but in a new state).  I could also imagine as an efficiency, you might remove a part of the model which can no longer contribute to the behavior.  Anyway, the point is that nothing has been lost in the formulation we have, but we just have focussed on cell behavior use cases which don't perhaps exploit the general behavior.

Chris

On Oct 9, 2014, at 2:45 PM, Lucian Smith <luc...@gm...> wrote:

> Hmm, I don't think that's *quite* true.  The original package's stated goal was to enable the creation (and destruction) of SBML elements dynamically, full stop.  Enabling the modeling of cellular processes was a prominent use-case, but not the only potential use-case.
> 
> However, in its current form, the package has completely hitched itself to the CBO, and in so doing, slightly reduced the scope of the original package idea.  It has also expanded its scope to other cellular processes besides creation and destruction, but it has still lost the ability to define creation and destruction outside the scope of *cell* creation and *cell* destruction.
> 
> Personally, I think the focus of the new scope lends itself better to its use and uptake by the multicellular community, and believe that, overall, it's a worthy direction for an SBML package, but it does raise the question:  is there anyone out there who wants creation and destruction of SBML elements outside of cell creation and destruction?  If not, great; let's just rename the package and move on.  But if so, we'll need to decide:  do we try to accommodate those people within this newly-scoped package, or do we split off and leave that group the old 'dynamic' package, and move forward with a newly-renamed package for CBO?
> 
> That's probably a question worthy of sbml-discuss, if not an actual poll.
> 
> -Lucian
> 
> On Thu, Oct 9, 2014 at 6:29 AM, Chris J. Myers <my...@ec...> wrote:
> 
> >
> >> I really think the best way forward is to rebrand what we are doing
> >> as "multi-cellular" modeling.  While doing multi-cellular modeling
> >> can be done in a limited fashion in core, it does not really handle
> >> well what people in this field are doing.
> >
> > You mean, rename the dynamics package, or simply call this current work "the Multicellular Modeling package" and leave the "dynamics" package alone?
> >
> If I understand you, your question asks whether or not this package replaces the dynamics package or is really a new package.  It is a bit of both.  The original dynamics package goal was to enable the creation of SBML elements dynamically in order to enable the modeling of cellular processes.  The current version of the package still does this, though perhaps in a more specialized fashion, but it adds to it the use of CBO and coarse spatial concept for location.  My vote would be that this replaces the dynamics package, since it is basically a superset of the original goals.  A better name though is in order.  I think my current preference for name would be Cellular Dynamics Package.  It allows us to keep "dyn" as the shorthand.  It allows for the modeling of single cells or populations.  It would not be confused with the Multistate Modeling Package.
> 
> Chris
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> sbml-dynamic mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-dynamic
> 
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________
> sbml-dynamic mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-dynamic

Hmm, I don't think that's *quite* true.  The original package's stated goal
was to enable the creation (and destruction) of SBML elements dynamically,
full stop.  Enabling the modeling of cellular processes was a prominent
use-case, but not the only potential use-case.

However, in its current form, the package has completely hitched itself to
the CBO, and in so doing, slightly reduced the scope of the original
package idea.  It has also expanded its scope to other cellular processes
besides creation and destruction, but it has still lost the ability to
define creation and destruction outside the scope of *cell* creation and
*cell* destruction.

Personally, I think the focus of the new scope lends itself better to its
use and uptake by the multicellular community, and believe that, overall,
it's a worthy direction for an SBML package, but it does raise the
question:  is there anyone out there who wants creation and destruction of
SBML elements outside of cell creation and destruction?  If not, great;
let's just rename the package and move on.  But if so, we'll need to
decide:  do we try to accommodate those people within this newly-scoped
package, or do we split off and leave that group the old 'dynamic' package,
and move forward with a newly-renamed package for CBO?

That's probably a question worthy of sbml-discuss, if not an actual poll.

-Lucian

On Thu, Oct 9, 2014 at 6:29 AM, Chris J. Myers <my...@ec...> wrote:

>
> >
> >> I really think the best way forward is to rebrand what we are doing
> >> as "multi-cellular" modeling.  While doing multi-cellular modeling
> >> can be done in a limited fashion in core, it does not really handle
> >> well what people in this field are doing.
> >
> > You mean, rename the dynamics package, or simply call this current work
> "the Multicellular Modeling package" and leave the "dynamics" package alone?
> >
> If I understand you, your question asks whether or not this package
> replaces the dynamics package or is really a new package.  It is a bit of
> both.  The original dynamics package goal was to enable the creation of
> SBML elements dynamically in order to enable the modeling of cellular
> processes.  The current version of the package still does this, though
> perhaps in a more specialized fashion, but it adds to it the use of CBO and
> coarse spatial concept for location.  My vote would be that this replaces
> the dynamics package, since it is basically a superset of the original
> goals.  A better name though is in order.  I think my current preference
> for name would be Cellular Dynamics Package.  It allows us to keep "dyn" as
> the shorthand.  It allows for the modeling of single cells or populations.
> It would not be confused with the Multistate Modeling Package.
>
> Chris
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> sbml-dynamic mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-dynamic
>

On Oct 9, 2014, at 7:52 AM, James Osborne <jam...@cs...> wrote:

> Dear all 
> 
> Sorry for coming late to this discussion. I am one of the Developers of Chaste (http://www.cs.ox.ac.uk/chaste/) which as part of it contains a multicellular modelling framework.
> The framework allows you to model multiple interacting cells, selecting from On and Off lattice modeling approaches (CA, Cell Potts, Cell Centre and Cell Vertex Models). It also allows the specification of subcellular behaviour (through cell cycle models) which couple to the cells.
> 
> The main thing i think that is important for this discussion is that in the framework we keep track of the cells topology (and connectivity) in each simulation type and this allows us to so the same operations on each paradigm (for example solve PDEs or cell cell communication). This could be a possible level that the language could specify events on.
> It is the topology and connectivity of cells that is always updated on cell division or death. However there are also occurrences where the topology changes due to the movement of cells, maybe this should be captured separately.
> 
> We have come at the problem from an implementation point of view rather than ontologies or abstractions but are very keen to make things more interchangeable.
> 
I agree that maintaining topology and connectivity information is indeed challenging from a modeling point-of-view.  In our implementation, this is indeed done algorithmically and not explicitly encoded in the model.  How this is done, we believe, may be one of the areas that is very software tool dependent, so perhaps it may not be possible to encode precisely.  This indeed was one of the motivations of a package that has a semantics that is not completely precise to give flexibility to the implementations as to how to address some of these concerns.

Thanks for the input.

Cheers,

Chris

Dear all

Sorry for coming late to this discussion. I am one of the Developers of
Chaste (http://www.cs.ox.ac.uk/chaste/) which as part of it contains a
multicellular modelling framework.
The framework allows you to model multiple interacting cells, selecting
from On and Off lattice modeling approaches (CA, Cell Potts, Cell Centre
and Cell Vertex Models). It also allows the specification of subcellular
behaviour (through cell cycle models) which couple to the cells.

The main thing i think that is important for this discussion is that in the
framework we keep track of the cells topology (and connectivity) in each
simulation type and this allows us to so the same operations on each
paradigm (for example solve PDEs or cell cell communication). This could be
a possible level that the language could specify events on.
It is the topology and connectivity of cells that is always updated on cell
division or death. However there are also occurrences where the topology
changes due to the movement of cells, maybe this should be captured
separately.

We have come at the problem from an implementation point of view rather
than ontologies or abstractions but are very keen to make things more
interchangeable.

Thanks

James

On Thu, Oct 9, 2014 at 2:29 PM, Chris J. Myers <my...@ec...> wrote:

>
> >
> >> I really think the best way forward is to rebrand what we are doing
> >> as "multi-cellular" modeling.  While doing multi-cellular modeling
> >> can be done in a limited fashion in core, it does not really handle
> >> well what people in this field are doing.
> >
> > You mean, rename the dynamics package, or simply call this current work
> "the Multicellular Modeling package" and leave the "dynamics" package alone?
> >
> If I understand you, your question asks whether or not this package
> replaces the dynamics package or is really a new package.  It is a bit of
> both.  The original dynamics package goal was to enable the creation of
> SBML elements dynamically in order to enable the modeling of cellular
> processes.  The current version of the package still does this, though
> perhaps in a more specialized fashion, but it adds to it the use of CBO and
> coarse spatial concept for location.  My vote would be that this replaces
> the dynamics package, since it is basically a superset of the original
> goals.  A better name though is in order.  I think my current preference
> for name would be Cellular Dynamics Package.  It allows us to keep "dyn" as
> the shorthand.  It allows for the modeling of single cells or populations.
> It would not be confused with the Multistate Modeling Package.
>
> Chris
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> sbml-dynamic mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-dynamic
>

-- 
Dr James Osborne

Senior Researcher, Computational Biology,
University of Oxford Department of Computer Science.
Web: http://www.cs.ox.ac.uk/people/james.osborne/
Tel: +44 (0)1865 610671

Visiting Scientist, Computational Science Laboratory,
Microsoft Research Limited

> 
>> I really think the best way forward is to rebrand what we are doing 
>> as "multi-cellular" modeling.  While doing multi-cellular modeling 
>> can be done in a limited fashion in core, it does not really handle 
>> well what people in this field are doing.  
> 
> You mean, rename the dynamics package, or simply call this current work "the Multicellular Modeling package" and leave the "dynamics" package alone?
> 
If I understand you, your question asks whether or not this package replaces the dynamics package or is really a new package.  It is a bit of both.  The original dynamics package goal was to enable the creation of SBML elements dynamically in order to enable the modeling of cellular processes.  The current version of the package still does this, though perhaps in a more specialized fashion, but it adds to it the use of CBO and coarse spatial concept for location.  My vote would be that this replaces the dynamics package, since it is basically a superset of the original goals.  A better name though is in order.  I think my current preference for name would be Cellular Dynamics Package.  It allows us to keep "dyn" as the shorthand.  It allows for the modeling of single cells or populations.  It would not be confused with the Multistate Modeling Package.

Chris

On Mon, 6 Oct 2014 13:45:56 -0600, Chris J. Myers wrote:
> P.S. A discussion for another day and another list is how to 
> mix-and-match.  At ICSB, there as a poster (Fage (sp) from France, 
> Mike: please correct if you are listening) who did this by encoding 
> the stochastic part in events, so they could do hybrid simulation.  
> Clever, but a bit of a hack.  I've been thinking about how we could 
> do this with comp where comp mixes models in different formalism like 
> in the whole-cell model.  

Yes; François Fages was the one.  I don't think it's been published, but we can ask (or at least we can ask about getting a copy of the poster).

MH

Some late random comments & questions:

On Tue, 7 Oct 2014 08:24:08 -0600, Chris J. Myers wrote:
> On Oct 7, 2014, at 8:13 AM, Kepler, Thomas B. <tbk...@bu...> wrote:
>> I was not able to make the COMBINE meeting to participate in the 
>> discussion regarding the spatial package, but if “spatial” cannot 
>> accommodate cell motion, then it seems misnamed.
> 
> I disagree.  The goal of spatial modeling was not to model 
> multi-cellular systems.  The goal of spatial modeling was to model 
> the cell as not simply a "well-stirred" bag of stuff.  The spatial 
> package is for representing the cell spatially, so you can model the 
> diffusion of species within the cell using PDEs.  It does this quite 
> well.

Chris is right that the "spatial" package is not really designed for cell motion, and more about spatial geometries.  IIIRC, the goal originally was to separate out spatial geometries from dynamic processes because dynamic changes (such as cell creation and cell death) didn't necessarily have to be spatial in nature, and there exist modeling approaches that only deal with non-spatial dynamical models.

> I really think the best way forward is to rebrand what we are doing 
> as "multi-cellular" modeling.  While doing multi-cellular modeling 
> can be done in a limited fashion in core, it does not really handle 
> well what people in this field are doing.  

You mean, rename the dynamics package, or simply call this current work "the Multicellular Modeling package" and leave the "dynamics" package alone?

MH

On Oct 7, 2014, at 8:13 AM, Kepler, Thomas B. <tbk...@bu...> wrote:

> Hi, Chris and colleagues.
>  
> In this discussion, there seems to be an implicit dichotomy “continuous/stochastic”, but the appropriate dichotomies, I think, are “continuous/discrete” and “deterministic/stochastic”. One can have all four 2x2 combinations. And these can be applied at the level of individual processes: Cellular differentiation might be modeled as a discrete event (either stochastic or deterministic) while cell motion is modeled as continuous (either stochastic or deterministic).
>  
You are correct.  Our preferred modeling formalism is discrete/stochastic.

> You have mentioned the CBO several times and pointed to the paper, saying, “The mission is to bring multi-cellular modeling folks to SBML.” Is that really the mission? Did the SBML have a hand in developing the CBO?
>  
No, but they are open to working with us.  Various people from SBML community have participated in multi-cellular modeling meetings where CBO was discussed, as well as, what it would take for this community to be able to use SBML.  These discussions indeed were what was driving me in the development of the dyn package.  Indeed, I've given several talks at Harmony/Combine which include ideas from these discussions for the development of the dyn pacakge.  Arguably, we should have just started a new package, but at the time, it was decided that the goals of dyn could be extended to meet the needs of the community.  However, a new package name would have likely made this change in goals more clear.

> There is a substantial problem that the dyn package at one time seemed designed to address: the change of the topology of the state space, which, by definition must be discontinuous. Thus, having “Event” as the primary mechanism seems appropriate. But for cell motion for example, modeled continuously, there is no corresponding event, whether the motion is stochastic or deterministic.
>  
I disagree.  An event can be used for motion when movement is modeled as a discrete change in state where the state change is the position of a cell in space.  We have already developed a simulator that works in this way.

> I was not able to make the COMBINE meeting to participate in the discussion regarding the spatial package, but if “spatial” cannot accommodate cell motion, then it seems misnamed.
>  

I disagree.  The goal of spatial modeling was not to model multi-cellular systems.  The goal of spatial modeling was to model the cell as not simply a "well-stirred" bag of stuff.  The spatial package is for representing the cell spatially, so you can model the diffusion of species within the cell using PDEs.  It does this quite well.

I really think the best way forward is to rebrand what we are doing as "multi-cellular" modeling.  While doing multi-cellular modeling can be done in a limited fashion in core, it does not really handle well what people in this field are doing.  

Chris

> Best wishes,
> Tom
>  
> Thomas B. Kepler, Professor
> Department of Microbiology
> Department of Mathematics & Statistics
> Boston University School of Medicine
> 72 E. Concord St., L504D
> Boston MA 02118
> Voice: +1 617 638 4124
>  
> From: Chris J. Myers [mailto:my...@ec...] 
> Sent: Tuesday, October 07, 2014 9:42 AM
> To: The SBML L3 Dynamic Structures package discussion list
> Subject: Re: [sbml-dynamic] Draft Specification for Dynamic Structures Package
>  
>  
> I agree velocity is probably a bad concept here, but the time frame in which the movement occur and the direction should be defined (which combined are something like a velocity). You do not have a quantity in your model framework which says 'velocity', but I am sure you have an internal model reference time (at least the time of the ode model within the cell which triggers the events). Even if you assume your movement to occur 'instantaneous', this is important information about the model. In addition you have a delta x, the distance a cell should move if the movement is triggered. Delta x is defined by some multiple of your grid size (in the simplest case just to the next grid point). 
> So as far as I understand your implementation your 'velocity' is therefore v=gridsize/delay, with gridsize=distance between neighboring grid points.
> 
> We don't typically build ODE models.  Our models are usually stochastic, so time of these events is usually given as a random distribution.  
> 
> 
> This crucial information of the process should be encoded:
> - time to perform process: instantaneous or some delta t (delay)
> - direction: random selection of one free adjacent position (in case of grid this translates to one of the neighbouring free locations, in case of continuous this translates to the selection of a random vector pointing to a free adjacent position) 
> This is definitely not part of the first version, but this information should be encoded for the events.
>  
>  
> Agreed.  We do currently encode this information in our events.  We actually have five types of movement events.  One for each direction in a 2-D grid and one for a random direction choice.  We can encode this in the current specification by having five events where each update the position of a compartment accordingly.  
>  
> Chris
> 
> 
> The best,
> Matthias
> 
>  
> We are hoping that our open way of describing things will enable our tools and others to describe things in the way that is most natural to them, and after gaining some experience, we do hope things will eventually coalesce around some agreed upon forms.
>  
> I suggest that you perhaps have a look at this paper on the Cell Behavior Ontology:
>  
> http://www.ncbi.nlm.nih.gov/pubmed/24755304
>  
> This is the closest thing to a standard representation for these types of models.  It is even more loose in the semantics than we are.  Namely, terms can be backed up by code rather than any mathematics at all.  
> 
> [2]
> The semantic encoding should be clear enough so one could translate them in a working simulation. As far as I understood the approach it only encodes the single cell events. 
> But somewhere the additional information for the geometrical layout (1D, 2D, 3D) and the initial conditions has to be encoded (i.e. where in the geometry are cells located), so that a simulation can be performed.
> The Compartment extensions should enable the layout to be specified, we believe.  At least, this is the goal.  
> Regarding to the simulation? Are there any tools which would support running the basic examples (5.1, 5.2)?
> Not yet though we hope to have some support soon.  Our tool does some multi-cellular modeling with grids, but it currently uses custom annotations.  We hope to start using the package constructs soon.  Harold's group is also designing a tool which plans to use this package.  This is the typical package development path in SBML.  Namely, prototypes are done with custom annotations, this leads to a package specification and discussion, this leads to library support, and finally tools start to experiment with it.  Only after at least two implementations exist, is a package considered released.  Therefore, you may consider everything in the document open to discussion and change.  We would be happy to try to tighten the semantics, but initial attempts to do this have been difficult.
> I do not want to sound to negative. I think it is exactly the right approach to start with the semantic encoding, but the long term goal should be running simulations from the encoded information. 
> We agree.  Our goal is that simulations in different tools using the same model should be arguably consistent, if not precisely the same.  We hope that we are on the path, and we value all feedback that we can get on this.
>  
> By the way, if you are implementing such a tool, we would also value to hear of your experiences trying to encode your models using these ideas.
>  
> Thanks for your feedback.
>  
> Chris
> 
> 
> Greetings Matthias
>  
> On Wed, Oct 1, 2014 at 7:30 PM, Chris J. Myers <my...@ec...> wrote:
> Just to add a bit to Harold's response.  The challenge we face with this package is that multicellular modeling tools are so varied that it was deemed very difficult to come to a single mathematical formulation that would work for all tools.  We do not want to prescribe one formalism as this would likely preclude exchange between these tools.  For example, cell movement in a tool that is lattice-based means moving on lattice point over while in non-lattice it would not move in such a discrete fashion.
>  
> We hope that gradually we may be able to add tighter mathematical meaning through the CBO definitions, but we think for now it is best to create something very general to experiment with until we see how it will work for people.
>  
> Cheers,
>  
> Chris
>  
>  
> On Oct 1, 2014, at 9:10 AM, Harold Gomez <Har...@gm...> wrote:
> 
> 
> Hi Dr. König,
> 
> Thank you for your feedback! -it's really exciting to hear back from the community. I will try to address the concerns you raised in your email regarding the approach used in the package. 
> 
> Section 4.2. of the specification points out that while all SBase-inheriting elements can have a CBO term, CBO-annotated Events now have specific simulation semantics. Though preliminary, we do provide a small list in section 4.2.4 spelling out these semantics for dynamic cellular behaviors such as death, division and movement events. The following is an example from this list for Cell Death:
> A CBO term for Cell Death as value for a cboTerm attribute indicates that the Event defines, by means of a Trigger subobject, the mathematical conditions under which cell death is to take place. When the applyToAll Event attribute is set to “false”, the presence of this CBO termalso dictates that SBML model components whose id or metaid is referenced by a DynElement in the ListOfDynElements subobject have to be removed from the model. When the value of applyToAll is “true”, all model elements are removed.
> In essence, what we are proposing with this package is to define what happens to the model (semantically) as a result of  the cellular behaviors that are mentioned in your email, not mathematically. The Dynamic Structures package does not explicitly encode mathematically what happens for each behavior as this has proven to be problematic since different modeling tools may use widely different mathematical and spatial frameworks (e.g., cellular potts vs 3D center-based) to represent modeling elements in space, and how cellular events like movement/division affect the model. To address this, our solution (reflected in the current spec) was to provide a set of constructs so that modelers can specify: 1) which elements are involved, 2) where they are in space, and 3) offer simulation semantics for how CBO-annotated Events should be simulated.
> 
> Best,
>  
> On Wed, Oct 1, 2014 at 8:56 AM, Matthias König <kon...@go...> wrote:
> Hi Harold,
> here some short feedback, as far as I understood the approach. I am no expert, so please correct me if I am completely wrong about things.
> 
> My main problem with the approach is that it is not clearly defined (mathematically) what happens with the model components after an event of a certain type. There has to be a clear mathematical definition for what a CBO term means for the future of the model.
> 
> For instance 'cell death':
> What does it mean mathematically?
> Are all the substance amounts vanished from the model balance after cell death? Or are the substance amounts of the cell afterwards in the compartment adjacent to the cell that died (exterior)? What does this mean for mass balance for the complete model?
> 
> For instance 'cell division':
> What are the volumes of the new cell? Half of volume of the dividing cell or the equal to the standard volume of the cell? How are substances distributed between the two cells? What about unequal division?
> What happens to the sizes of internal compartments? What if a cell model has surface area and volume? How is it divided (based on surface or volume) and what happens to the other quantity (again mass balance)?
> 
> A good example for this uncertainty in what is happening is the example
> "5.1 Example of using dynamic events"
> I understand that it is a cell which can divide or die depending on certain conditions fulfilled in the model (Events). But if I had to implement the model in software I could imagine a multitude of different ways with widely different results for simulation. In my opinion the dyn package must clearly encode the rules which are applied given an event or at least define the mathematical rules associated with a CBO term.
> 
> Matthias
>  
>  
> On Tue, Sep 30, 2014 at 4:40 PM, Harold Gomez <Har...@gm...> wrote:
> Hi everyone,
>  
> I would like to share with you the latest draft specification for the Dynamic Structures package, which was expanded to accommodate some of the feedback received during COMBINE. As usual, we welcome further feedback.
>  
> Best,
> --
> Harold Gómez
> Bioinformatics PhD. Candidate, Boston University
> Graduate School of Arts & Sciences
>  
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> sbml-dynamic mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-dynamic
> 
> 
> 
> 
> -- 
> ---------------------------------------------------
> Matthias König
> Computational Systems Biochemistry
> Institute of Biochemistry
> Charité - Universitätsmedizin Berlin
> http://www.charite.de/sysbio/people/koenig/
> Tel: + 49 30 450 528 197
> Tel: + 49 176 81168480
> ---------------------------------------------------
> 
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> sbml-dynamic mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-dynamic
> 
> 
> 
>  
> --
> Harold Gómez
> Bioinformatics PhD. Candidate, Boston University
> Graduate School of Arts & Sciences
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________
> sbml-dynamic mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-dynamic
>  
> 
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> sbml-dynamic mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-dynamic
> 
> 
> 
> 
> -- 
> ---------------------------------------------------
> Matthias König
> Computational Systems Biochemistry
> Institute of Biochemistry
> Charité - Universitätsmedizin Berlin
> http://www.charite.de/sysbio/people/koenig/
> Tel: + 49 30 450 528 197
> Tel: + 49 176 81168480
> ---------------------------------------------------
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________
> sbml-dynamic mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-dynamic
>  
> 
> ------------------------------------------------------------------------------
> Slashdot TV.  Videos for Nerds.  Stuff that Matters.
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
> _______________________________________________
> sbml-dynamic mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-dynamic
> 
> 
> 
> 
> -- 
> ---------------------------------------------------
> Matthias König
> Computational Systems Biochemistry
> Institute of Biochemistry
> Charité - Universitätsmedizin Berlin
> http://www.charite.de/sysbio/people/koenig/
> Tel: + 49 30 450 528 197
> Tel: + 49 176 81168480
> ---------------------------------------------------
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________
> sbml-dynamic mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-dynamic
>  
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________
> sbml-dynamic mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-dynamic

Hi, Chris and colleagues.

In this discussion, there seems to be an implicit dichotomy "continuous/stochastic", but the appropriate dichotomies, I think, are "continuous/discrete" and "deterministic/stochastic". One can have all four 2x2 combinations. And these can be applied at the level of individual processes: Cellular differentiation might be modeled as a discrete event (either stochastic or deterministic) while cell motion is modeled as continuous (either stochastic or deterministic).

You have mentioned the CBO several times and pointed to the paper, saying, "The mission is to bring multi-cellular modeling folks to SBML." Is that really the mission? Did the SBML have a hand in developing the CBO?

There is a substantial problem that the dyn package at one time seemed designed to address: the change of the topology of the state space, which, by definition must be discontinuous. Thus, having "Event" as the primary mechanism seems appropriate. But for cell motion for example, modeled continuously, there is no corresponding event, whether the motion is stochastic or deterministic.

I was not able to make the COMBINE meeting to participate in the discussion regarding the spatial package, but if "spatial" cannot accommodate cell motion, then it seems misnamed.

Best wishes,
Tom

Thomas B. Kepler, Professor
Department of Microbiology
Department of Mathematics & Statistics
Boston University School of Medicine
72 E. Concord St., L504D
Boston MA 02118
Voice: +1 617 638 4124

From: Chris J. Myers [mailto:my...@ec...]
Sent: Tuesday, October 07, 2014 9:42 AM
To: The SBML L3 Dynamic Structures package discussion list
Subject: Re: [sbml-dynamic] Draft Specification for Dynamic Structures Package

I agree velocity is probably a bad concept here, but the time frame in which the movement occur and the direction should be defined (which combined are something like a velocity). You do not have a quantity in your model framework which says 'velocity', but I am sure you have an internal model reference time (at least the time of the ode model within the cell which triggers the events). Even if you assume your movement to occur 'instantaneous', this is important information about the model. In addition you have a delta x, the distance a cell should move if the movement is triggered. Delta x is defined by some multiple of your grid size (in the simplest case just to the next grid point).
So as far as I understand your implementation your 'velocity' is therefore v=gridsize/delay, with gridsize=distance between neighboring grid points.
We don't typically build ODE models.  Our models are usually stochastic, so time of these events is usually given as a random distribution.

This crucial information of the process should be encoded:
- time to perform process: instantaneous or some delta t (delay)
- direction: random selection of one free adjacent position (in case of grid this translates to one of the neighbouring free locations, in case of continuous this translates to the selection of a random vector pointing to a free adjacent position)
This is definitely not part of the first version, but this information should be encoded for the events.

Agreed.  We do currently encode this information in our events.  We actually have five types of movement events.  One for each direction in a 2-D grid and one for a random direction choice.  We can encode this in the current specification by having five events where each update the position of a compartment accordingly.

Chris

The best,
Matthias

We are hoping that our open way of describing things will enable our tools and others to describe things in the way that is most natural to them, and after gaining some experience, we do hope things will eventually coalesce around some agreed upon forms.

I suggest that you perhaps have a look at this paper on the Cell Behavior Ontology:

http://www.ncbi.nlm.nih.gov/pubmed/24755304

This is the closest thing to a standard representation for these types of models.  It is even more loose in the semantics than we are.  Namely, terms can be backed up by code rather than any mathematics at all.

[2]
The semantic encoding should be clear enough so one could translate them in a working simulation. As far as I understood the approach it only encodes the single cell events.

But somewhere the additional information for the geometrical layout (1D, 2D, 3D) and the initial conditions has to be encoded (i.e. where in the geometry are cells located), so that a simulation can be performed.
The Compartment extensions should enable the layout to be specified, we believe.  At least, this is the goal.

Regarding to the simulation? Are there any tools which would support running the basic examples (5.1, 5.2)?
Not yet though we hope to have some support soon.  Our tool does some multi-cellular modeling with grids, but it currently uses custom annotations.  We hope to start using the package constructs soon.  Harold's group is also designing a tool which plans to use this package.  This is the typical package development path in SBML.  Namely, prototypes are done with custom annotations, this leads to a package specification and discussion, this leads to library support, and finally tools start to experiment with it.  Only after at least two implementations exist, is a package considered released.  Therefore, you may consider everything in the document open to discussion and change.  We would be happy to try to tighten the semantics, but initial attempts to do this have been difficult.

I do not want to sound to negative. I think it is exactly the right approach to start with the semantic encoding, but the long term goal should be running simulations from the encoded information.
We agree.  Our goal is that simulations in different tools using the same model should be arguably consistent, if not precisely the same.  We hope that we are on the path, and we value all feedback that we can get on this.

By the way, if you are implementing such a tool, we would also value to hear of your experiences trying to encode your models using these ideas.

Thanks for your feedback.

Chris

Greetings Matthias

On Wed, Oct 1, 2014 at 7:30 PM, Chris J. Myers <my...@ec...<mailto:my...@ec...>> wrote:
Just to add a bit to Harold's response.  The challenge we face with this package is that multicellular modeling tools are so varied that it was deemed very difficult to come to a single mathematical formulation that would work for all tools.  We do not want to prescribe one formalism as this would likely preclude exchange between these tools.  For example, cell movement in a tool that is lattice-based means moving on lattice point over while in non-lattice it would not move in such a discrete fashion.

We hope that gradually we may be able to add tighter mathematical meaning through the CBO definitions, but we think for now it is best to create something very general to experiment with until we see how it will work for people.

Cheers,

Chris

On Oct 1, 2014, at 9:10 AM, Harold Gomez <Har...@gm...<mailto:Har...@gm...>> wrote:

Hi Dr. König,
Thank you for your feedback! -it's really exciting to hear back from the community. I will try to address the concerns you raised in your email regarding the approach used in the package.

Section 4.2. of the specification points out that while all SBase-inheriting elements can have a CBO term, CBO-annotated Events now have specific simulation semantics. Though preliminary, we do provide a small list in section 4.2.4 spelling out these semantics for dynamic cellular behaviors such as death, division and movement events. The following is an example from this list for Cell Death:

  1.  A CBO term for Cell Death as value for a cboTerm attribute indicates that the Event defines, by means of a Trigger subobject, the mathematical conditions under which cell death is to take place. When the applyToAll Event attribute is set to "false", the presence of this CBO termalso dictates that SBML model components whose id or metaid is referenced by a DynElement in the ListOfDynElements subobject have to be removed from the model. When the value of applyToAll is "true", all model elements are removed.
In essence, what we are proposing with this package is to define what happens to the model (semantically) as a result of  the cellular behaviors that are mentioned in your email, not mathematically. The Dynamic Structures package does not explicitly encode mathematically what happens for each behavior as this has proven to be problematic since different modeling tools may use widely different mathematical and spatial frameworks (e.g., cellular potts vs 3D center-based) to represent modeling elements in space, and how cellular events like movement/division affect the model. To address this, our solution (reflected in the current spec) was to provide a set of constructs so that modelers can specify: 1) which elements are involved, 2) where they are in space, and 3) offer simulation semantics for how CBO-annotated Events should be simulated.
Best,

On Wed, Oct 1, 2014 at 8:56 AM, Matthias König <kon...@go...<mailto:kon...@go...>> wrote:
Hi Harold,
here some short feedback, as far as I understood the approach. I am no expert, so please correct me if I am completely wrong about things.
My main problem with the approach is that it is not clearly defined (mathematically) what happens with the model components after an event of a certain type. There has to be a clear mathematical definition for what a CBO term means for the future of the model.

For instance 'cell death':
What does it mean mathematically?
Are all the substance amounts vanished from the model balance after cell death? Or are the substance amounts of the cell afterwards in the compartment adjacent to the cell that died (exterior)? What does this mean for mass balance for the complete model?

For instance 'cell division':
What are the volumes of the new cell? Half of volume of the dividing cell or the equal to the standard volume of the cell? How are substances distributed between the two cells? What about unequal division?
What happens to the sizes of internal compartments? What if a cell model has surface area and volume? How is it divided (based on surface or volume) and what happens to the other quantity (again mass balance)?

A good example for this uncertainty in what is happening is the example
"5.1 Example of using dynamic events"
I understand that it is a cell which can divide or die depending on certain conditions fulfilled in the model (Events). But if I had to implement the model in software I could imagine a multitude of different ways with widely different results for simulation. In my opinion the dyn package must clearly encode the rules which are applied given an event or at least define the mathematical rules associated with a CBO term.
Matthias

On Tue, Sep 30, 2014 at 4:40 PM, Harold Gomez <Har...@gm...<mailto:Har...@gm...>> wrote:
Hi everyone,

I would like to share with you the latest draft specification for the Dynamic Structures package, which was expanded to accommodate some of the feedback received during COMBINE. As usual, we welcome further feedback.

Best,
--
Harold Gómez
Bioinformatics PhD. Candidate, Boston University
Graduate School of Arts & Sciences

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
sbml-dynamic mailing list
sbm...@li...<mailto:sbm...@li...>
https://lists.sourceforge.net/lists/listinfo/sbml-dynamic

--
---------------------------------------------------
Matthias König
Computational Systems Biochemistry
Institute of Biochemistry
Charité - Universitätsmedizin Berlin
http://www.charite.de/sysbio/people/koenig/
Tel: + 49 30 450 528 197<tel:%2B%2049%2030%20450%20528%20197>
Tel: + 49 176 81168480<tel:%2B%2049%20176%2081168480>
---------------------------------------------------

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
sbml-dynamic mailing list
sbm...@li...<mailto:sbm...@li...>
https://lists.sourceforge.net/lists/listinfo/sbml-dynamic

--
Harold Gómez
Bioinformatics PhD. Candidate, Boston University
Graduate School of Arts & Sciences
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________
sbml-dynamic mailing list
sbm...@li...<mailto:sbm...@li...>
https://lists.sourceforge.net/lists/listinfo/sbml-dynamic

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
sbml-dynamic mailing list
sbm...@li...<mailto:sbm...@li...>
https://lists.sourceforge.net/lists/listinfo/sbml-dynamic

--
---------------------------------------------------
Matthias König
Computational Systems Biochemistry
Institute of Biochemistry
Charité - Universitätsmedizin Berlin
http://www.charite.de/sysbio/people/koenig/
Tel: + 49 30 450 528 197<tel:%2B%2049%2030%20450%20528%20197>
Tel: + 49 176 81168480<tel:%2B%2049%20176%2081168480>
---------------------------------------------------
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________
sbml-dynamic mailing list
sbm...@li...<mailto:sbm...@li...>
https://lists.sourceforge.net/lists/listinfo/sbml-dynamic

------------------------------------------------------------------------------
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
_______________________________________________
sbml-dynamic mailing list
sbm...@li...<mailto:sbm...@li...>
https://lists.sourceforge.net/lists/listinfo/sbml-dynamic

--
---------------------------------------------------
Matthias König
Computational Systems Biochemistry
Institute of Biochemistry
Charité - Universitätsmedizin Berlin
http://www.charite.de/sysbio/people/koenig/
Tel: + 49 30 450 528 197
Tel: + 49 176 81168480
---------------------------------------------------
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________
sbml-dynamic mailing list
sbm...@li...<mailto:sbm...@li...>
https://lists.sourceforge.net/lists/listinfo/sbml-dynamic

On Oct 6, 2014, at 6:18 PM, Stefan Hoops <sh...@vb...> wrote:

> Hello All,
> 
> On Mon, 6 Oct 2014 13:35:16 -0600
> "Chris J. Myers" <my...@ec...> wrote:
> 
>> While I always felt movement was part of this package, I agree with
>> Lucian that perhaps a new package name is in order.  The "Cell
>> Behavior Package" or "Multi-cellular Modeling Package' may be good.
>> 
> 
> I do not like either of the names. I can write multi-cellular models
> in the core and behavior reminds me of to much of social interaction. 
> 
> I would prefer the current name as this package was anticipated to
> address issues related to modification of existing sbml elements
> especially creation and destruction (other are not excluded). Cell
> division or death are just examples and might be actually to high level
> to allow general application of this package. This discussion
> especially Mathias remarks are pointing into this direction. 
> 
> With respect to movement I do not think that movement should be part of
> this package as movement can be specified with the spatial package. How
> the movement is implemented is a tool problem. Whether it is continuous
> or lattice based does not play a role in the specification similar to
> the fact that we never distinguish between stochastic or deterministic
> models in the core.
> 

No, movement is not specified by the spatial package, at least not currently.  Unfortunately, the spatial package is incapable of specifying objects that change, only diffusion of species within spaces.  We came to the conclusion at COMBINE, and we decided at COMBINE that a very simply location field was to become part of dyn in order to describe movement.  This was decided with spatial people present indicating that this was the best route forward, so movement is definitely part of what is currently called the dynamic package.  

The mission of the dynamic package is not just creation/destruction of objects anymore.  The mission is to bring multi-cellular modeling folks to SBML.  You should have a look at the CBO paper:

http://www.ncbi.nlm.nih.gov/pmc/articles/PMC4133580/

Currently, they are describing their models using just CBO and no modeling language.  What we are trying to do here is to make SBML the modeling language for CBO like SBML is the modeling language for SBO.  Therefore, I think we should change the name of the package to better match its mission.

Chris

> Thanks,
> Stefan
> 
> 
> 
>> What has happened is CBO is now out there and supposedly be used
>> without a modeling language.  We would like to see SBML become its
>> modeling language as this would get SBML used by multi-cellular
>> modeling community.  
>> 
>> Chris
>> 
> 
> 
> 
> -- 
> Stefan Hoops, Ph.D.
> Senior Project Associate
> Virginia Bioinformatics Institute 
> Virginia Tech
> 1015 Life Science Circle (0477) 
> Blacksburg, Va 24061, USA
> 
> Phone: (540) 231-1799
> Fax:   (540) 231-2606
> Email: sh...@vb...

> 
> I agree velocity is probably a bad concept here, but the time frame in which the movement occur and the direction should be defined (which combined are something like a velocity). You do not have a quantity in your model framework which says 'velocity', but I am sure you have an internal model reference time (at least the time of the ode model within the cell which triggers the events). Even if you assume your movement to occur 'instantaneous', this is important information about the model. In addition you have a delta x, the distance a cell should move if the movement is triggered. Delta x is defined by some multiple of your grid size (in the simplest case just to the next grid point). 
> So as far as I understand your implementation your 'velocity' is therefore v=gridsize/delay, with gridsize=distance between neighboring grid points. 
> 
We don't typically build ODE models.  Our models are usually stochastic, so time of these events is usually given as a random distribution.  

> This crucial information of the process should be encoded:
> - time to perform process: instantaneous or some delta t (delay)
> - direction: random selection of one free adjacent position (in case of grid this translates to one of the neighbouring free locations, in case of continuous this translates to the selection of a random vector pointing to a free adjacent position) 
> This is definitely not part of the first version, but this information should be encoded for the events.
> 

Agreed.  We do currently encode this information in our events.  We actually have five types of movement events.  One for each direction in a 2-D grid and one for a random direction choice.  We can encode this in the current specification by having five events where each update the position of a compartment accordingly.  

Chris

> The best,
> Matthias
> 
>  
> We are hoping that our open way of describing things will enable our tools and others to describe things in the way that is most natural to them, and after gaining some experience, we do hope things will eventually coalesce around some agreed upon forms.
> 
> I suggest that you perhaps have a look at this paper on the Cell Behavior Ontology:
> 
> http://www.ncbi.nlm.nih.gov/pubmed/24755304
> 
> This is the closest thing to a standard representation for these types of models.  It is even more loose in the semantics than we are.  Namely, terms can be backed up by code rather than any mathematics at all.  
>> [2]
>> The semantic encoding should be clear enough so one could translate them in a working simulation. As far as I understood the approach it only encodes the single cell events. 
>> But somewhere the additional information for the geometrical layout (1D, 2D, 3D) and the initial conditions has to be encoded (i.e. where in the geometry are cells located), so that a simulation can be performed.
> 
> The Compartment extensions should enable the layout to be specified, we believe.  At least, this is the goal.  
>> Regarding to the simulation? Are there any tools which would support running the basic examples (5.1, 5.2)?
>> 
> 
> Not yet though we hope to have some support soon.  Our tool does some multi-cellular modeling with grids, but it currently uses custom annotations.  We hope to start using the package constructs soon.  Harold's group is also designing a tool which plans to use this package.  This is the typical package development path in SBML.  Namely, prototypes are done with custom annotations, this leads to a package specification and discussion, this leads to library support, and finally tools start to experiment with it.  Only after at least two implementations exist, is a package considered released.  Therefore, you may consider everything in the document open to discussion and change.  We would be happy to try to tighten the semantics, but initial attempts to do this have been difficult.
>> I do not want to sound to negative. I think it is exactly the right approach to start with the semantic encoding, but the long term goal should be running simulations from the encoded information. 
> 
> We agree.  Our goal is that simulations in different tools using the same model should be arguably consistent, if not precisely the same.  We hope that we are on the path, and we value all feedback that we can get on this.
> 
> By the way, if you are implementing such a tool, we would also value to hear of your experiences trying to encode your models using these ideas.
> 
> Thanks for your feedback.
> 
> Chris
> 
>> Greetings Matthias
>> 
>> On Wed, Oct 1, 2014 at 7:30 PM, Chris J. Myers <my...@ec...> wrote:
>> Just to add a bit to Harold's response.  The challenge we face with this package is that multicellular modeling tools are so varied that it was deemed very difficult to come to a single mathematical formulation that would work for all tools.  We do not want to prescribe one formalism as this would likely preclude exchange between these tools.  For example, cell movement in a tool that is lattice-based means moving on lattice point over while in non-lattice it would not move in such a discrete fashion.
>> 
>> We hope that gradually we may be able to add tighter mathematical meaning through the CBO definitions, but we think for now it is best to create something very general to experiment with until we see how it will work for people.
>> 
>> Cheers,
>> 
>> Chris
>> 
>> 
>> On Oct 1, 2014, at 9:10 AM, Harold Gomez <Har...@gm...> wrote:
>> 
>>> Hi Dr. König,
>>> 
>>> Thank you for your feedback! -it's really exciting to hear back from the community. I will try to address the concerns you raised in your email regarding the approach used in the package. 
>>> 
>>> Section 4.2. of the specification points out that while all SBase-inheriting elements can have a CBO term, CBO-annotated Events now have specific simulation semantics. Though preliminary, we do provide a small list in section 4.2.4 spelling out these semantics for dynamic cellular behaviors such as death, division and movement events. The following is an example from this list for Cell Death:
>>> A CBO term for Cell Death as value for a cboTerm attribute indicates that the Event defines, by means of a Trigger subobject, the mathematical conditions under which cell death is to take place. When the applyToAll Event attribute is set to “false”, the presence of this CBO termalso dictates that SBML model components whose id or metaid is referenced by a DynElement in the ListOfDynElements subobject have to be removed from the model. When the value of applyToAll is “true”, all model elements are removed.
>>> In essence, what we are proposing with this package is to define what happens to the model (semantically) as a result of  the cellular behaviors that are mentioned in your email, not mathematically. The Dynamic Structures package does not explicitly encode mathematically what happens for each behavior as this has proven to be problematic since different modeling tools may use widely different mathematical and spatial frameworks (e.g., cellular potts vs 3D center-based) to represent modeling elements in space, and how cellular events like movement/division affect the model. To address this, our solution (reflected in the current spec) was to provide a set of constructs so that modelers can specify: 1) which elements are involved, 2) where they are in space, and 3) offer simulation semantics for how CBO-annotated Events should be simulated.
>>> 
>>> Best,
>>> 
>>> On Wed, Oct 1, 2014 at 8:56 AM, Matthias König <kon...@go...> wrote:
>>> Hi Harold, 
>>> here some short feedback, as far as I understood the approach. I am no expert, so please correct me if I am completely wrong about things.
>>> 
>>> My main problem with the approach is that it is not clearly defined (mathematically) what happens with the model components after an event of a certain type. There has to be a clear mathematical definition for what a CBO term means for the future of the model.
>>> 
>>> For instance 'cell death':
>>> What does it mean mathematically?
>>> Are all the substance amounts vanished from the model balance after cell death? Or are the substance amounts of the cell afterwards in the compartment adjacent to the cell that died (exterior)? What does this mean for mass balance for the complete model?
>>> 
>>> For instance 'cell division':
>>> What are the volumes of the new cell? Half of volume of the dividing cell or the equal to the standard volume of the cell? How are substances distributed between the two cells? What about unequal division?
>>> What happens to the sizes of internal compartments? What if a cell model has surface area and volume? How is it divided (based on surface or volume) and what happens to the other quantity (again mass balance)? 
>>> 
>>> A good example for this uncertainty in what is happening is the example
>>> "5.1 Example of using dynamic events"
>>> I understand that it is a cell which can divide or die depending on certain conditions fulfilled in the model (Events). But if I had to implement the model in software I could imagine a multitude of different ways with widely different results for simulation. In my opinion the dyn package must clearly encode the rules which are applied given an event or at least define the mathematical rules associated with a CBO term.
>>> 
>>> Matthias
>>>  
>>> 
>>> On Tue, Sep 30, 2014 at 4:40 PM, Harold Gomez <Har...@gm...> wrote:
>>> Hi everyone,
>>> 
>>> I would like to share with you the latest draft specification for the Dynamic Structures package, which was expanded to accommodate some of the feedback received during COMBINE. As usual, we welcome further feedback.
>>> 
>>> Best,
>>> -- 
>>> Harold Gómez
>>> Bioinformatics PhD. Candidate, Boston University
>>> Graduate School of Arts & Sciences
>>> 
>>> ------------------------------------------------------------------------------
>>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> sbml-dynamic mailing list
>>> sbm...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sbml-dynamic
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> ---------------------------------------------------
>>> Matthias König
>>> Computational Systems Biochemistry
>>> Institute of Biochemistry
>>> Charité - Universitätsmedizin Berlin
>>> http://www.charite.de/sysbio/people/koenig/
>>> Tel: + 49 30 450 528 197
>>> Tel: + 49 176 81168480
>>> ---------------------------------------------------
>>> 
>>> ------------------------------------------------------------------------------
>>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> sbml-dynamic mailing list
>>> sbm...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sbml-dynamic
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Harold Gómez
>>> Bioinformatics PhD. Candidate, Boston University
>>> Graduate School of Arts & Sciences
>>> ------------------------------------------------------------------------------
>>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________
>>> sbml-dynamic mailing list
>>> sbm...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sbml-dynamic
>> 
>> 
>> ------------------------------------------------------------------------------
>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>> _______________________________________________
>> sbml-dynamic mailing list
>> sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbml-dynamic
>> 
>> 
>> 
>> 
>> -- 
>> ---------------------------------------------------
>> Matthias König
>> Computational Systems Biochemistry
>> Institute of Biochemistry
>> Charité - Universitätsmedizin Berlin
>> http://www.charite.de/sysbio/people/koenig/
>> Tel: + 49 30 450 528 197
>> Tel: + 49 176 81168480
>> ---------------------------------------------------
>> ------------------------------------------------------------------------------
>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________
>> sbml-dynamic mailing list
>> sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbml-dynamic
> 
> 
> ------------------------------------------------------------------------------
> Slashdot TV.  Videos for Nerds.  Stuff that Matters.
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
> _______________________________________________
> sbml-dynamic mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-dynamic
> 
> 
> 
> 
> -- 
> ---------------------------------------------------
> Matthias König
> Computational Systems Biochemistry
> Institute of Biochemistry
> Charité - Universitätsmedizin Berlin
> http://www.charite.de/sysbio/people/koenig/
> Tel: + 49 30 450 528 197
> Tel: + 49 176 81168480
> ---------------------------------------------------
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________
> sbml-dynamic mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-dynamic

Hi Stefan,
I see your point.
Perhaps I misunderstood the direction of the package and it should be
clearly stated what the package should do.
I understood the main goal of the package is to provide the additional
structures to implement multi-cell simulations like agent-based
simulations. The implementation based on CBO terms implied this somehow. My
arguments are based on this understanding.
If the package is only concerned with the dynamic creation and destruction
of objects things are different.

The problem is in my opinion that nowhere clearly is written what the
package should encode. There is some vague introduction in the draft.

Intrinsic dynamic cellular behaviors characteristic of multicellular
> systems (e.g., proliferation, differentiation,
> endocytosis, exocytosis, and cell death) may be modeled using a variety of
> mathematical and spatial frameworks.
> However, fully representing systems that undergo discrete structural
> changes during simulation cannot currently be
> accomplished using either SBML Level 3 Version 1 Core’s structural
> constructs or available language extensions.
>

But this could be interpreted either in the 'only handle dynamic
construction/destruction' or 'provide things for mulicellular systems' way.
I think it would be a good idea to clearly state:
This package will handle ...

Matthias

On Tue, Oct 7, 2014 at 2:18 AM, Stefan Hoops <sh...@vb...> wrote:

> Hello All,
>
> On Mon, 6 Oct 2014 13:35:16 -0600
> "Chris J. Myers" <my...@ec...> wrote:
>
> > While I always felt movement was part of this package, I agree with
> > Lucian that perhaps a new package name is in order.  The "Cell
> > Behavior Package" or "Multi-cellular Modeling Package' may be good.
> >
>
> I do not like either of the names. I can write multi-cellular models
> in the core and behavior reminds me of to much of social interaction.
>
> I would prefer the current name as this package was anticipated to
> address issues related to modification of existing sbml elements
> especially creation and destruction (other are not excluded). Cell
> division or death are just examples and might be actually to high level
> to allow general application of this package. This discussion
> especially Mathias remarks are pointing into this direction.
>
> With respect to movement I do not think that movement should be part of
> this package as movement can be specified with the spatial package. How
> the movement is implemented is a tool problem. Whether it is continuous
> or lattice based does not play a role in the specification similar to
> the fact that we never distinguish between stochastic or deterministic
> models in the core.
>
> Thanks,
> Stefan
>
>
>
> > What has happened is CBO is now out there and supposedly be used
> > without a modeling language.  We would like to see SBML become its
> > modeling language as this would get SBML used by multi-cellular
> > modeling community.
> >
> > Chris
> >
>
>
>
> --
> Stefan Hoops, Ph.D.
> Senior Project Associate
> Virginia Bioinformatics Institute
> Virginia Tech
> 1015 Life Science Circle (0477)
> Blacksburg, Va 24061, USA
>
> Phone: (540) 231-1799
> Fax:   (540) 231-2606
> Email: sh...@vb...
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> sbml-dynamic mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-dynamic
>

-- 
---------------------------------------------------
Matthias König
Computational Systems Biochemistry
Institute of Biochemistry
Charité - Universitätsmedizin Berlin
http://www.charite.de/sysbio/people/koenig/
Tel: + 49 30 450 528 197
Tel: + 49 176 81168480
---------------------------------------------------

2011	Jan	Feb	Mar	Apr	May	Jun (2)	Jul	Aug	Sep	Oct	Nov	Dec
2013	Jan	Feb	Mar	Apr	May	Jun	Jul (22)	Aug	Sep (4)	Oct	Nov	Dec
2014	Jan	Feb	Mar	Apr	May	Jun (1)	Jul	Aug (2)	Sep (6)	Oct (38)	Nov	Dec
2015	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug (3)	Sep	Oct (3)	Nov	Dec
2018	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug (1)	Sep (2)	Oct	Nov	Dec

sbml-dynamic Mailing List for Systems Biology Markup Language (SBML)

A file format for exchanging computational models in systems biology

sbml-dynamic — The SBML L3 Dynamic Structures package discussion list