sbml-comp — The SBML L3 Hierarchical Model Composition package discussion list

[sbml-comp] sbml Hierarchical compartment example Level 3 Version 1

[Daniela S. <dan...@gm...>]

  I have a sbml for each compartment, for this image
[image: Immagine.png]

The problem arises when I have species that are not part of compartment 'C'.
How should the compartment be declared?

Tks
Daniela.

Re: [sbml-comp] [sbml-discuss] Manuscript describing SBML

[Sarah K. <ske...@ca...>]

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

SBML Editors

Re: [sbml-comp] [sbml-discuss] Manuscript describing SBML

[Sarah K. <ske...@ca...>]

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
> 

[sbml-comp] Manuscript describing SBML

[Nicolas Le N. <n.l...@gm...>]

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.

[sbml-comp] about libSBML for java and UnsatisfiedLinkError for SBMLReader object.

[Perez V. I. C. <isa...@im...>]

Hello,

I´m working with the SBML library in java (libSBML-5.15.0-libxml2-x64), and
I have this error when I try to use the object SBMLReader.

Exception in thread "main" java.lang.UnsatisfiedLinkError:
org.sbml.libsbml.libsbmlJNI.swig_module_init()V
    at org.sbml.libsbml.libsbmlJNI.swig_module_init(Native Method)
    at org.sbml.libsbml.libsbmlJNI.<clinit>(libsbmlJNI.java:5941)
    at org.sbml.libsbml.SBMLReader.<init>(SBMLReader.java:105)

Can someone please help me?
Any comment would be apreciated.

Thank you for your time,

Re: [sbml-comp] [libsbml-development] Bug when saving comp model with ModelDefinitions which contain packages

[Sarah K. <ske...@ca...>]

Hi Matthias

> [2] I fundamentally don't understand why I have to enable Plugins on the
> comp document.
> This completely breaks the modularization of models in comp, i.e. that I
> can have submodels with different sets of activated packages.
> ModelDefinitions should behave exactly the same like
> ExternalModelDefinition. The only difference is
> that they are in the same file, not in an external file!
>
> For instance with this example model:
> I have to activate the fbc on the comp_model.
> - now the document complains that I don't have fbc on all
> ModelDefinitions!, i.e. would have to add fbc also to all
> ModelDefinitions which don't need fbc
> - I have to get all required tags of the package, i.e. I have to get
> strict add it to the main model and all submodels
> - I have to add all required things to all ModelDefinitions
> ...
> This does not make sense to me. Could someone explain this?
>

This is a good question. It stems from the fact that the package 
namespaces are on the sbml element and if you use modelDefinitions you 
have only one sbml element; whereas with externalModelDefinitions each 
has their own sbml element.

I would suggest this was a good thing to bring up on the comp mailing 
list - perhaps something to be thought about in future versions.

Context for comp list: Matthias was creating a  single file containing 
comp with modelDefinitions from a set of files where the original 'top' 
model used externalModelDefinitions - one of which used fbc whilst 
neither the 'top' nor any other models had fbc.

Sarah

Re: [sbml-comp] Comp models with L3v2

[Frank T. B. <fbe...@ca...>]

The argument for allowing L3V1 versions of extensions in L3V2 is
simply that implementations for them are likely to exist. And of
course that the packages would only have to be re-released if
something changed in them that would require the use of the newer
core.

Under those points I don't think it is too strict a requirement of not
allowing submodels of later versions. After all if it would really be
needed conversions are likely to exist.

Frank

On Wed, May 18, 2016 at 3:50 PM, Chris Myers <my...@ec...> wrote:
> Agreed. My preference would be that the top level model should always have the highest level/version.  I agree this would be much simpler.  However, this would make it invalid to include subModels of later levels/versions.  If people don’t think this is too strict a requirement, I’m perfectly okay with this simplifying requirement.
>
> Chris
>
>> On May 18, 2016, at 2:37 AM, Sarah Keating <ske...@ca...> wrote:
>>
>>> Namely, it is akin to “the flattened model should be valid rule” where the target of flattening must be a model at the highest level/version of any model included.
>>
>> But generally the model to be flattened is the top level model; I
>> suspect it would be much more complex if the flattened model had to
>> revise its level and version based on what external models it encountered.
>>
>> Sarah
>>
>>
>> ------------------------------------------------------------------------------
>> Mobile security can be enabling, not merely restricting. Employees who
>> bring their own devices (BYOD) to work are irked by the imposition of MDM
>> restrictions. Mobile Device Manager Plus allows you to control only the
>> apps on BYO-devices by containerizing them, leaving personal data untouched!
>> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
>> _______________________________________________
>> sbml-comp mailing list
>> sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbml-comp
>
>
> ------------------------------------------------------------------------------
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> _______________________________________________
> sbml-comp mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-comp

Re: [sbml-comp] Comp models with L3v2

[Chris M. <my...@ec...>]

Agreed. My preference would be that the top level model should always have the highest level/version.  I agree this would be much simpler.  However, this would make it invalid to include subModels of later levels/versions.  If people don’t think this is too strict a requirement, I’m perfectly okay with this simplifying requirement.

Chris

> On May 18, 2016, at 2:37 AM, Sarah Keating <ske...@ca...> wrote:
> 
>> Namely, it is akin to “the flattened model should be valid rule” where the target of flattening must be a model at the highest level/version of any model included.
> 
> But generally the model to be flattened is the top level model; I 
> suspect it would be much more complex if the flattened model had to 
> revise its level and version based on what external models it encountered.
> 
> Sarah
> 
> 
> ------------------------------------------------------------------------------
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> _______________________________________________
> sbml-comp mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-comp

Re: [sbml-comp] Comp models with L3v2

[Sarah K. <ske...@ca...>]

> Namely, it is akin to “the flattened model should be valid rule” where the target of flattening must be a model at the highest level/version of any model included.

But generally the model to be flattened is the top level model; I 
suspect it would be much more complex if the flattened model had to 
revise its level and version based on what external models it encountered.

Sarah

Re: [sbml-comp] Comp models with L3v2

[Chris M. <my...@ec...>]

My feeling is that a mixed model would follow the rules of the highest level/version included.  For example, and L3V2 model that has L3V1 subModels would have the validation rules of L3V2.  Similarly, an L3V1 model that references an L3V2 subModel would also have L3V2 validation rules.

Namely, it is akin to “the flattened model should be valid rule” where the target of flattening must be a model at the highest level/version of any model included.

Chris

> On May 17, 2016, at 12:33 PM, Lucian Smith <luc...@gm...> wrote:
> 
> Hey, everyone!  I have a question about how comp should handle the
> forthcoming SBML L3v2 models.
> 
> In general, one of the things that the current L3v2 draft claims is that
> all L3v1 packages should be able to work 'as-is' with L3v2 documents, as
> long as they don't use any of the new constructs or rules that were
> introduced in L3v2.  So, for example, you should be able to use comp as-is
> in an L3v2 document, as long as you don't reference any of the new IDs that
> L3v2 introduces.
> 
> Comp is unique, however, in that it allows you to combine documents, which
> means that you could have an L3v1 comp document with an L3v2 submodel, or
> an L3v2 comp document with an L3v1 submodel.
> 
> Everything will be fine if we fall back on the 'the flattened model should
> be valid' rule.  I'm half-inclined to tell people to go ahead and reference
> L3v2 IDs, too, even for l3v1 models, but maybe that's going too far?
> 
> So, we have a few options:
> 
> * We claim that the current version of comp, combined with L3v2's rule that
> current packages work as-is on L3v2 documents, is sufficient for proper
> interpretation of any combination of L3v1 and L3v2.
> 
> * We issue a new *release* of version 1 of the comp spec that still have
> L3v1 as its primary target, but explains how to incorporate L3v2 submodels.
> 
> * We issue a new *version* of comp (version 2) that is designed to work
> with L3v2 specifically.
> 
> We could even do all three!
> 
> Anyone have any opinions on how this should work?  Any caveats I should be
> aware of?
> 
> -Lucian
> ------------------------------------------------------------------------------
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> _______________________________________________
> sbml-comp mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-comp

[sbml-comp] Comp models with L3v2

[Lucian S. <luc...@gm...>]

Hey, everyone!  I have a question about how comp should handle the
forthcoming SBML L3v2 models.

In general, one of the things that the current L3v2 draft claims is that
all L3v1 packages should be able to work 'as-is' with L3v2 documents, as
long as they don't use any of the new constructs or rules that were
introduced in L3v2.  So, for example, you should be able to use comp as-is
in an L3v2 document, as long as you don't reference any of the new IDs that
L3v2 introduces.

Comp is unique, however, in that it allows you to combine documents, which
means that you could have an L3v1 comp document with an L3v2 submodel, or
an L3v2 comp document with an L3v1 submodel.

Everything will be fine if we fall back on the 'the flattened model should
be valid' rule.  I'm half-inclined to tell people to go ahead and reference
L3v2 IDs, too, even for l3v1 models, but maybe that's going too far?

So, we have a few options:

* We claim that the current version of comp, combined with L3v2's rule that
current packages work as-is on L3v2 documents, is sufficient for proper
interpretation of any combination of L3v1 and L3v2.

* We issue a new *release* of version 1 of the comp spec that still have
L3v1 as its primary target, but explains how to incorporate L3v2 submodels.

* We issue a new *version* of comp (version 2) that is designed to work
with L3v2 specifically.

We could even do all three!

Anyone have any opinions on how this should work?  Any caveats I should be
aware of?

-Lucian

Re: [sbml-comp] Questions about specification and flattening algorithm

[Chris J. M. <my...@ec...>]

> I am currently polishing description of our approach on composite models
> and also do more strict comparison with SBML "comp". So I have some
> thoughts and questions about  specification and flattening algorithm
> described in it.
> 
> 1. According to flattening algorithm in specification, first step is to
> apply the same algorithm to every submodel which contains submodels itself.
> 
> I think about it as follows:
> 
> if we have submodel S with correspondent model definition M and M contains
> submodels, then:
> 1. Apply algorithm to M, result would be M_flat.
> 2. Substitute reference to M in S with reference to M_flat.
> 3. Continue algorithm
> 
> But we still want to keep ports in S (and therefore in M_flat) for
> aggregation with top level. Ports are comp elements so It looks like result
> of flattening procedure still is composite in a sense that it requires
> "comp" at least if submodel contains ports.
> 
> However specification states that result is "devoid of of the Hierarchical
> Model Composition constructs”
> 
You have a point though once you finish with flattening of the very top-level, you can drop the ports, if what you are doing next is just simulating the model.  The ports would no longer be necessary at that point.

> 2. Replacement of replacements?
> If inner modular submodels are flattened and result does not contain
> comp-related elements (except for ports?) then replacements or deletions of
> comp-related objects e.g. replacements of replacement can not be performed.
> 
> However I didn't find in specification explicit statement that such things
> are prohibited.
> 
> Moreover from the previous question if  ports are still in flattened
> versions of submodels  therefore port can be replaced by another port?
> 
> <comp:port comp:idRef="S" comp:id="S_port">
>    <comp:listOfReplacedElements>
>       <comp:replacedElement comp:metaIdRef="PortInSubmodel"
> comp:submodelRef="A"/>
>    </comp:listOfReplacedElements>
> </comp:port>
> 
Replacements of Comp objects just sounds wrong to me.  I cannot think of any use for this, and I would strongly support making it explicitly illegal, if it is not already.

> 3. Can I replace listOfSpecies or other listOf... ? It seems legal because
> I can give metaId to it and then refer to it in replacement. Actually SBML
> validator says that model with replacement of listOfSpecies is valid, but
> Antimony fails to flatten it.
> 
Again, I would prefer this was illegal.  It does not make any sense.

> For some SBase subclasses replacements does not make sense.
> For example what would replacement of event trigger do?
> It will delete target trigger leaving it triggerless (and the whole model -
> invalid).
> It will replace all references to deleted trigger with references to new
> trigger, but  there can't be any (at least in the core).
> 
Agreed, this should be illegal too.  You cannot do anything meaningful.

> Validation rules state that resulting model should be valid so replacement
> of triggers is implicitly restricted, but I think it will be better if
> specification will explicitly state which replacements can be done and
> whicn can not. Probably it also should be stated that comp structures can
> not be subjects to replacements\deletions.
> 
I could not agree more.  I would strongly support you if you wanted to make replacements and deletion targets more restricted.  

Chris

[sbml-comp] Questions about specification and flattening algorithm

[Ilya K. <ax...@de...>]

Hi all.

I am currently polishing description of our approach on composite models
and also do more strict comparison with SBML "comp". So I have some
thoughts and questions about  specification and flattening algorithm
described in it.

1. According to flattening algorithm in specification, first step is to
apply the same algorithm to every submodel which contains submodels itself.

I think about it as follows:

if we have submodel S with correspondent model definition M and M contains
submodels, then:
1. Apply algorithm to M, result would be M_flat.
2. Substitute reference to M in S with reference to M_flat.
3. Continue algorithm

But we still want to keep ports in S (and therefore in M_flat) for
aggregation with top level. Ports are comp elements so It looks like result
of flattening procedure still is composite in a sense that it requires
"comp" at least if submodel contains ports.

However specification states that result is "devoid of of the Hierarchical
Model Composition constructs"

2. Replacement of replacements?
If inner modular submodels are flattened and result does not contain
comp-related elements (except for ports?) then replacements or deletions of
comp-related objects e.g. replacements of replacement can not be performed.

However I didn't find in specification explicit statement that such things
are prohibited.

Moreover from the previous question if  ports are still in flattened
versions of submodels  therefore port can be replaced by another port?

<comp:port comp:idRef="S" comp:id="S_port">
    <comp:listOfReplacedElements>
       <comp:replacedElement comp:metaIdRef="PortInSubmodel"
comp:submodelRef="A"/>
    </comp:listOfReplacedElements>
</comp:port>

3. Can I replace listOfSpecies or other listOf... ? It seems legal because
I can give metaId to it and then refer to it in replacement. Actually SBML
validator says that model with replacement of listOfSpecies is valid, but
Antimony fails to flatten it.

For some SBase subclasses replacements does not make sense.
For example what would replacement of event trigger do?
It will delete target trigger leaving it triggerless (and the whole model -
invalid).
It will replace all references to deleted trigger with references to new
trigger, but  there can't be any (at least in the core).

Validation rules state that resulting model should be valid so replacement
of triggers is implicitly restricted, but I think it will be better if
specification will explicitly state which replacements can be done and
whicn can not. Probably it also should be stated that comp structures can
not be subjects to replacements\deletions.

-- 
Best regards,
Ilya

Re: [sbml-comp] Publication of the Hierarchical Model Composition specification

[Stefan H. <sh...@vb...>]

This is fine with me.

Thanks,
Stefan

Sent from my Verizon 4G LTE Smartphone


------ Original message------
From: Lucian Smith
Date: Fri, Jul 31, 2015 19:20
To: Mike Hucka;Stefan Hoops;af...@ca...;gi...@mp...;Chris Myers;Ion Moraru;lie...@mo...;The SBML L3 Hierarchical Model Composition package discussion list;
Subject:Publication of the Hierarchical Model Composition specification

As some of you know from the COMBINE/HARMONY workshops, Falk Schreiber has arranged for us to have a special edition of the Journal of Integrative Bioinformatics where we can publish specifications.  The specifications are published as-is with the addition of an abstract, so that's all we need to do!  Here's the abstract I came up with:

----
Hierarchical modeling allows the modeler to break up and re-use models to compose new ones.  Core SBML does not directly allow this technique, so the Hierarchical Model Composition package was developed to address this need.  Included are elements that allow the modeler to include submodels, delete unneeded or redundant elements of that submodel, replace elements of that submodel with element of the containing model, and replace elements of the containing model with elements of the submodel.  Ports are also available as suggested interfaces between hierarchical levels, but are optional, allowing a ‘grey box’ approach to modeling where users can use the provided interface if they desire, but may also interact directly with model elements.
----

Any suggestions/comments?  Are all the authors of the spec (cc'ed on this message) OK with the publication?  Thank you!

-Lucian

Re: [sbml-comp] Publication of the Hierarchical Model Composition specification

[Moraru,Ion <mo...@uc...>]

I like the edited version.

And of course, I agree with the publication in JIB, since I actually suggested it to Lucian to get it going :)

Ion
-----Original Message-----
From: Michael Hucka [mailto:mh...@ca...] 
Sent: Friday, July 31, 2015 9:15 PM
To: Lucian Smith
Cc: Stefan Hoops; af...@ca...; gi...@mp...; Chris Myers; Moraru,Ion; lie...@mo...; The SBML L3 Hierarchical Model Composition package discussion list
Subject: Re: Publication of the Hierarchical Model Composition specification

Thanks for taking action on this.  Edited/revised abstract:

Constructing a model in a hierarchical fashion is a natural approach to managing model complexity, and offers additional opportunities such as the potential to re-use model components.  The \emph{SBML Level~3 Version~1 Core} specification does not directly provide a mechanism for defining hierarchical models, but it does provide a mechanism for SBML \emph{packages} to extend the Core specification and add additional syntactical constructs.  The SBML \emph{Hierarchical Model Composition} package for SBML Level~3 adds the necessary features to SBML to support hierarchical modeling.  The package enables a modeler to include submodels within an enclosing SBML model, delete unneeded or redundant elements of that submodel, replace elements of that submodel with element of the containing model, and replace elements of the containing model with elements of the submodel.  In addition, the package defines an optional ``port'' construct, allowing a model to be defined with suggested interfaces between hierarchical components; modelers can chose to use these interfaces, but they are not required to do so and can still interact directly with model elements if they so chose.  Finally, the SBML Hierarchical Model Composition package is defined in such a way that a hierarchical model can be ``flattened'' to an equivalent, non-hierarchical version that uses only plain SBML constructs, thus enabling software tools that do not yet support hierarchy to nevertheless work with SBML hierarchical models.

--

I'm okay with publishing the spec in JIB.

MH

Re: [sbml-comp] Publication of the Hierarchical Model Composition specification

[Michael H. <mh...@ca...>]

Thanks for taking action on this.  Edited/revised abstract:

Constructing a model in a hierarchical fashion is a natural approach to managing model complexity, and offers additional opportunities such as the potential to re-use model components.  The \emph{SBML Level~3 Version~1 Core} specification does not directly provide a mechanism for defining hierarchical models, but it does provide a mechanism for SBML \emph{packages} to extend the Core specification and add additional syntactical constructs.  The SBML \emph{Hierarchical Model Composition} package for SBML Level~3 adds the necessary features to SBML to support hierarchical modeling.  The package enables a modeler to include submodels within an enclosing SBML model, delete unneeded or redundant elements of that submodel, replace elements of that submodel with element of the containing model, and replace elements of the containing model with elements of the submodel.  In addition, the package defines an optional ``port'' construct, allowing a model to be defined with suggested 
interfaces between hierarchical components; modelers can chose to use these interfaces, but they are not required to do so and can still interact directly with model elements if they so chose.  Finally, the SBML Hierarchical Model Composition package is defined in such a way that a hierarchical model can be ``flattened'' to an equivalent, non-hierarchical version that uses only plain SBML constructs, thus enabling software tools that do not yet support hierarchy to nevertheless work with SBML hierarchical models.

--

I'm okay with publishing the spec in JIB.

MH

Re: [sbml-comp] Publication of the Hierarchical Model Composition specification

[Chris J. M. <my...@ec...>]

Looks fine, and I’m okay with the publication.

Chris

> On Jul 31, 2015, at 5:20 PM, Lucian Smith <luc...@gm...> wrote:
> 
> As some of you know from the COMBINE/HARMONY workshops, Falk Schreiber has arranged for us to have a special edition of the Journal of Integrative Bioinformatics where we can publish specifications.  The specifications are published as-is with the addition of an abstract, so that's all we need to do!  Here's the abstract I came up with:
> 
> ----
> Hierarchical modeling allows the modeler to break up and re-use models to compose new ones.  Core SBML does not directly allow this technique, so the Hierarchical Model Composition package was developed to address this need.  Included are elements that allow the modeler to include submodels, delete unneeded or redundant elements of that submodel, replace elements of that submodel with element of the containing model, and replace elements of the containing model with elements of the submodel.  Ports are also available as suggested interfaces between hierarchical levels, but are optional, allowing a ‘grey box’ approach to modeling where users can use the provided interface if they desire, but may also interact directly with model elements.
> 
> ----
> 
> 
> 
> Any suggestions/comments?  Are all the authors of the spec (cc'ed on this message) OK with the publication?  Thank you!
> 
> 
> 
> -Lucian
> 

[sbml-comp] Publication of the Hierarchical Model Composition specification

[Lucian S. <luc...@gm...>]

As some of you know from the COMBINE/HARMONY workshops, Falk Schreiber has
arranged for us to have a special edition of the Journal of Integrative
Bioinformatics where we can publish specifications.  The specifications are
published as-is with the addition of an abstract, so that's all we need to
do!  Here's the abstract I came up with:

----

Hierarchical modeling allows the modeler to break up and re-use models to
compose new ones.  Core SBML does not directly allow this technique, so the
Hierarchical Model Composition package was developed to address this need.
Included are elements that allow the modeler to include submodels, delete
unneeded or redundant elements of that submodel, replace elements of that
submodel with element of the containing model, and replace elements of the
containing model with elements of the submodel.  Ports are also available
as suggested interfaces between hierarchical levels, but are optional,
allowing a ‘grey box’ approach to modeling where users can use the provided
interface if they desire, but may also interact directly with model
elements.

----


Any suggestions/comments?  Are all the authors of the spec (cc'ed on this
message) OK with the publication?  Thank you!


-Lucian

Re: [sbml-comp] [libsbml-development] Comp package: Have a species in one submodel replace a species in another submodel?

[Lucian S. <luc...@gm...>]

Sure!  Don't forget that the point of the comp format is that it stores the
information unambiguously, but it is the point of front ends *to* the comp
specification to hide some of these details from the user.  So, for
example, Antimony takes care of the initial assignments for you, as you
guessed, by using metaids.  The model:

model mod1()
  x1 = 1+y
end

model mod2()
  x2 = 1-z
end

model main()
  A: mod1()
  B: mod2()
  A.x1 is xmain
  B.x2 is xmain
end

gets translated to SBML as:

<?xml version="1.0" encoding="UTF-8"?>
<!-- Created by libAntimony version v2.6.1 on 2015-01-21 08:54 with libSBML
version 5.11.1. -->
<sbml xmlns="http://www.sbml.org/sbml/level3/version1/core" xmlns:comp="
http://www.sbml.org/sbml/level3/version1/comp/version1" level="3"
version="1" comp:required="true">
  <model id="main" name="main">
    <listOfParameters>
      <parameter id="xmain" constant="true">
        <comp:listOfReplacedElements>
          <comp:replacedElement comp:idRef="x1" comp:submodelRef="A"/>
          <comp:replacedElement comp:idRef="x2" comp:submodelRef="B"/>
        </comp:listOfReplacedElements>
      </parameter>
    </listOfParameters>
    <comp:listOfSubmodels>
      <comp:submodel comp:id="A" comp:modelRef="mod1"/>
      <comp:submodel comp:id="B" comp:modelRef="mod2">
        <comp:listOfDeletions>
          <comp:deletion comp:metaIdRef="mod2__x2__initialAssignment"/>
        </comp:listOfDeletions>
      </comp:submodel>
    </comp:listOfSubmodels>
  </model>
  <comp:listOfModelDefinitions>
    <comp:modelDefinition id="mod1" name="mod1">
      <listOfParameters>
        <parameter id="x1" constant="true"/>
        <parameter id="y" constant="true"/>
      </listOfParameters>
      <listOfInitialAssignments>
        <initialAssignment symbol="x1">
          <math xmlns="http://www.w3.org/1998/Math/MathML">
            <apply>
              <plus/>
              <cn type="integer"> 1 </cn>
              <ci> y </ci>
            </apply>
          </math>
        </initialAssignment>
      </listOfInitialAssignments>
    </comp:modelDefinition>
    <comp:modelDefinition id="mod2" name="mod2">
      <listOfParameters>
        <parameter id="x2" constant="true"/>
        <parameter id="z" constant="true"/>
      </listOfParameters>
      <listOfInitialAssignments>
        <initialAssignment metaid="mod2__x2__initialAssignment" symbol="x2">
          <math xmlns="http://www.w3.org/1998/Math/MathML">
            <apply>
              <minus/>
              <cn type="integer"> 1 </cn>
              <ci> z </ci>
            </apply>
          </math>
        </initialAssignment>
      </listOfInitialAssignments>
    </comp:modelDefinition>
  </comp:listOfModelDefinitions>
</sbml>

which gives the extra initial assignment a metaid, and then uses that
metaid in a deletion.

If you can't modify the submodel at all, even to give the initialAssignment
a metaid, there's unfortunately nothing in the Hierarchical Composition
package that will let you reference that element!  This was a sort of
compromise position in the end--we could have used the xpath operator to
reference these elements, but the complexity of doing so was judged (at
least for version 1) to be too much for a situation that, it was believed,
would not come up all that often.  If this turns out to be a major design
barrier to you, however, we can consider adding it back in for version 2!

As far as 'replacedBy', unfortunately, Antimony does not use that construct
at the moment in its output (though this could be added in the future).
But I can mock you up an example.  For simplicity, I'm just using
parameters with a 'value' attribute:

<?xml version="1.0" encoding="UTF-8"?>
<sbml xmlns="http://www.sbml.org/sbml/level3/version1/core" xmlns:comp="
http://www.sbml.org/sbml/level3/version1/comp/version1" level="3"
version="1" comp:required="true">
  <model id="main" name="main">
    <listOfParameters>
      <parameter id="xmain" value="3" constant="true">
        <comp:listOfReplacedElements>
          <comp:replacedElement comp:idRef="x1" comp:submodelRef="A"/>
        </comp:listOfReplacedElements>
        <comp:replacedBy comp:idRef="x2" comp:submodelRef="B"/>
      </parameter>
    </listOfParameters>
    <comp:listOfSubmodels>
      <comp:submodel comp:id="A" comp:modelRef="mod1"/>
      <comp:submodel comp:id="B" comp:modelRef="mod2"/>
    </comp:listOfSubmodels>
  </model>
  <comp:listOfModelDefinitions>
    <comp:modelDefinition id="mod1" name="mod1">
      <listOfParameters>
        <parameter id="x1" value="1" constant="true"/>
      </listOfParameters>
    </comp:modelDefinition>
    <comp:modelDefinition id="mod2" name="mod2">
      <listOfParameters>
        <parameter id="x2" value="2" constant="true"/>
      </listOfParameters>
    </comp:modelDefinition>
  </comp:listOfModelDefinitions>
</sbml>


In the above model, the parameter 'xmain' replaces x1 from submodel A, and
is in turn replaced by x2 from submodel B.  This means that in the final
assessment, that parameter has a value of 2:  the '1' and the '3' were both
replaced.  Note also that both x1 and xmain could have been set
'constant="false"', but the final assessment of the model would give that
parameter a constant value of 'true', since that's what x2 had.  (Just keep
this in mind moving forward--if it's important that the final parameter
have a value of '2' but 'constant=false', you'll need to create a new
parameter at the top level with those attributes, and have it replace the
others.  Again, this is something a front end would ideally take care of.)

Is that clearer?  Thanks for asking!

-Lucian

On Tue, Jan 20, 2015 at 11:51 PM, Daniel Palm <pa...@gm...> wrote:

> Thanks for the detailed reply Lucian.
>
> Would it be possible to give me an example of using replacedBy. My concern
> with replacedElement is that it violates the DRY principle in that you have
> to specify the details of the compartments and species again in the parent
> model. This probably isn't usually a big deal, but with large models it can
> become a pain.
>
> Moreover, I have initial assignments for everything, which results in
> warnings about duplicate initial assignments. It is not clear to me how to
> remove or even replace initial assignments (or other rules) in one of the
> submodels. Should one rely on metaids there?
>
> Thanks again
> Daniel
>
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> sbml-comp mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-comp
>
>

Re: [sbml-comp] [libsbml-development] Comp package: Have a species in one submodel replace a species in another submodel?

[Daniel P. <pa...@gm...>]

Thanks for the detailed reply Lucian.

Would it be possible to give me an example of using replacedBy. My concern 
with replacedElement is that it violates the DRY principle in that you have 
to specify the details of the compartments and species again in the parent 
model. This probably isn't usually a big deal, but with large models it can 
become a pain.

Moreover, I have initial assignments for everything, which results in 
warnings about duplicate initial assignments. It is not clear to me how to 
remove or even replace initial assignments (or other rules) in one of the 
submodels. Should one rely on metaids there?

Thanks again
Daniel

Re: [sbml-comp] [libsbml-development] Comp package: Have a species in one submodel replace a species in another submodel?

[Lucian S. <luc...@gm...>]

You are exactly correct:  you need to provide local copies of things that
can then replace or be replaced by elements in the submodels.  To recreate
your situation in Antimony:

model model1()
  species A in comp1, B in comp2
  A -> B;
end

model model2()
  species C in comp3, D in comp3
  C -> D;
end

model combined()
  //Declare the local species and compartment:
  species C2 in cMain

  //Import the other models as submodels:
  M1: model1()
  M2: model2()

  //Connect the compartments and species
  M1.comp2 is cMain
  M2.comp3 is cMain
  M1.B is C2
  M2.C is C2
end

Which in SBML would be the attached model (though presumably with external
model definitions instead of local ones).

This version used the 'replacedElement' constructs, but you could also pick
one of them and used the 'replacedBy' construct.  In that case, any
initialConcentration or other attribute value would be taken from the
submodel target of that replacedBy, instead of by the parent model.

-Lucian

On Tue, Jan 20, 2015 at 4:25 AM, Daniel Palm <pa...@gm...> wrote:

> Dear all
>
> Suppose I have two external models that I cannot change (well, I can, but
> it's undesirable for a number of reasons):
>
> model1:
>
> A -> B
>
> model 2:
>
> C -> D
>
> I want to combine these, but B and C are actually the same species and in
> the same compartments. The final model should look like this
>
> model_combined:
>
> A -> C
> C -> D
>
> with A in compartment 1 and C and D in compartment 2.
>
> Am I right that the only way would be to have model1 and model2 as
> submodels of another model. And make a new compartment that replaces that
> of B, C, and D, and make a new species C that replaces B and the old C?
>
> It would be nice if I could simply say somehow that C (model2) replaces B
> (model1) and that the compartment of C replaces the compartment of B. Is
> this possible?
>
> I would be grateful for any help.
>
> Best regards
> Daniel
>
> --
> You received this message because you are subscribed to the Google Groups
> "libsbml-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to lib...@go....
> To post to this group, send email to lib...@go....
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/libsbml-development/4de5441e-6c12-4c35-ab4e-add00670f69e%40googlegroups.com
> <https://groups.google.com/d/msgid/libsbml-development/4de5441e-6c12-4c35-ab4e-add00670f69e%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

Re: [sbml-comp] Comp for SBML L3v2

[Chris J. M. <my...@ec...>]

I agree let's keep this simple.  I think the upconversion requirement is sufficient.

Chris

On Jul 11, 2014, at 6:10 PM, Moraru,Ion <mo...@uc...> wrote:

> Here's my 2 cents, without thinking too hard :)
> 
> Translating upwards (to newer levels/versions) has generally been the more compatible path in SBML, since deprecating/eliminating/invalidating constructs have been far less then adding/relaxing/etc.  That being said, for the purposes of comp one might consider not necessarily converting all (sub)models to the latest but to the highest common denominator of them.  I am not sure though if this increases or decreases complexity of handling composite models. Having a translation package does seem overkill.
> 
> Ion
> 
> -----Original Message-----
> From: Lucian Smith [mailto:luc...@gm...] 
> Sent: Friday, July 11, 2014 7:01 PM
> To: The SBML L3 Hierarchical Model Composition package discussion list
> Subject: [sbml-comp] Comp for SBML L3v2
> 
> As many of you are no doubt aware, a new version of SBML (L3v2) is in the works, a draft of which may well be available by COMBINE.  As such, I'm now working on a new version of the comp package, which will both accommodate the changes to SBML core, and incorporate any new design changes we wish to add.
> 
> The one main design change I know some people would appreciate is the ability to reference SBML documents of different levels and versions.
> Obviously, we would want SBML L3v2-comp models to be able to reference SBML L3v1 (and L3v1-comp) models.  Since L3v2 is currently backwards-compatible with L3v1 (that is, it only lifts a few L3v1 restrictions and adds new constructs), it's easy enough to say something like "convert the L3v1 model to L3v2, and then use it as you would normally".
> 
> But it would be nice if we could also include L2 models in this 'uptranslate and continue' model. My first instinct was to set up a whole rigorous system of SBML model translation, perhaps wrapping the whole thing in a 'translation' package.  But perhaps it would be simpler, and all we really need, to just say something like the following:
> 
> "The referenced SBML document should either be a Level 3 Version 2 document itself, or be able to be losslessly and unambiguously translated to SBML Level 3 Version 2.  To the extent that such a translation is not possible, the behavior of the resulting model is not defined."
> 
> Would that be sufficient, do you think?
> 
> -Lucian
> ------------------------------------------------------------------------------
> _______________________________________________
> sbml-comp mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-comp
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> sbml-comp mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-comp

Re: [sbml-comp] Comp for SBML L3v2

[Moraru,Ion <mo...@uc...>]

Here's my 2 cents, without thinking too hard :)

Translating upwards (to newer levels/versions) has generally been the more compatible path in SBML, since deprecating/eliminating/invalidating constructs have been far less then adding/relaxing/etc.  That being said, for the purposes of comp one might consider not necessarily converting all (sub)models to the latest but to the highest common denominator of them.  I am not sure though if this increases or decreases complexity of handling composite models. Having a translation package does seem overkill.

Ion

-----Original Message-----
From: Lucian Smith [mailto:luc...@gm...] 
Sent: Friday, July 11, 2014 7:01 PM
To: The SBML L3 Hierarchical Model Composition package discussion list
Subject: [sbml-comp] Comp for SBML L3v2

As many of you are no doubt aware, a new version of SBML (L3v2) is in the works, a draft of which may well be available by COMBINE.  As such, I'm now working on a new version of the comp package, which will both accommodate the changes to SBML core, and incorporate any new design changes we wish to add.

The one main design change I know some people would appreciate is the ability to reference SBML documents of different levels and versions.
 Obviously, we would want SBML L3v2-comp models to be able to reference SBML L3v1 (and L3v1-comp) models.  Since L3v2 is currently backwards-compatible with L3v1 (that is, it only lifts a few L3v1 restrictions and adds new constructs), it's easy enough to say something like "convert the L3v1 model to L3v2, and then use it as you would normally".

But it would be nice if we could also include L2 models in this 'uptranslate and continue' model. My first instinct was to set up a whole rigorous system of SBML model translation, perhaps wrapping the whole thing in a 'translation' package.  But perhaps it would be simpler, and all we really need, to just say something like the following:

"The referenced SBML document should either be a Level 3 Version 2 document itself, or be able to be losslessly and unambiguously translated to SBML Level 3 Version 2.  To the extent that such a translation is not possible, the behavior of the resulting model is not defined."

Would that be sufficient, do you think?

-Lucian
------------------------------------------------------------------------------
_______________________________________________
sbml-comp mailing list
sbm...@li...
https://lists.sourceforge.net/lists/listinfo/sbml-comp

[sbml-comp] Comp for SBML L3v2

[Lucian S. <luc...@gm...>]

As many of you are no doubt aware, a new version of SBML (L3v2) is in the
works, a draft of which may well be available by COMBINE.  As such, I'm now
working on a new version of the comp package, which will both accommodate
the changes to SBML core, and incorporate any new design changes we wish to
add.

The one main design change I know some people would appreciate is the
ability to reference SBML documents of different levels and versions.
 Obviously, we would want SBML L3v2-comp models to be able to reference
SBML L3v1 (and L3v1-comp) models.  Since L3v2 is currently
backwards-compatible with L3v1 (that is, it only lifts a few L3v1
restrictions and adds new constructs), it's easy enough to say something
like "convert the L3v1 model to L3v2, and then use it as you would
normally".

But it would be nice if we could also include L2 models in this
'uptranslate and continue' model. My first instinct was to set up a whole
rigorous system of SBML model translation, perhaps wrapping the whole thing
in a 'translation' package.  But perhaps it would be simpler, and all we
really need, to just say something like the following:

"The referenced SBML document should either be a Level 3 Version 2 document
itself, or be able to be losslessly and unambiguously translated to SBML
Level 3 Version 2.  To the extent that such a translation is not possible,
the behavior of the resulting model is not defined."

Would that be sufficient, do you think?

-Lucian

[sbml-comp] SBML Hierarchical Model Composition package Release 3 announced

[Lucian S. <luc...@gm...>]

We are pleased to announce Release 3 of the Hierarchical Model
Composition package, available now from

http://identifiers.org/combine.specifications/sbml.level-3.version-1.comp.version-1.release-3

This release incorporates the various changes that have accumulated on
the errata page at
http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/Hierarchical_Model_Composition_(comp)/Errata

The most obvious updates have to do with validation rules that have
been clarified or added since the last release.  All the changes here
are now also incorporated into the most recent version of libSBML
(5.9.0), also released today.

Thanks again to all the members of the 'comp' package working group
for comments and suggestions, as well as the members of the libsbml
team for incorporating these changes into that software.

-Lucian Smith