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

Re: [sbml-comp] Comp validations rules: replacements

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

Hi Lucian,

I think you missed a key point.  I was not saying everything had to be an input or output.  I was just saying if you choose to use that designation, there are restrictions on their usage which come with the benefit of some confidence that it will flatten.  However, you can also leave the direction off the port which means you can do all the other things you might want to do like have a species appear in reactions in more than one subModel.  Note this idea is inspired by other uses where it has worked well.  

1) Software - in many programming languages you can be confident that the parameters passed to a function will not be changed by that function and values must be explicitly returned when you want modified values.  Note that (most thought not all) programming languages also allow you a way around this usually by passing a reference instead of the object itself.

2) Digital hardware modeling - there are input and output ports in VHDL and Verilog where an input can be read but not written to while an output can be written to though it cannot be read.  Again, there is an out to use an inout direction which allows you to do both.  However, it is considered good practice to not simply use inout for everything despite the fact that you could get away with it.

Perhaps, someone may want the complicated scheme you mentioned, but it would be a devil to keep up-to-date in any tool.  I think the scheme I proposed is simple and quite useful in many situations especially in synthetic biology modeling, but it certainly will not cover all cases.  So, much like requiring ports in our tool, it is likely going to be just something we try to maintain whenever possible.

My question actually to you and anyone else that is interested is whether my scheme (like it or not) would actually guarantee validity after flatten or am I missing something.  Algebraic rules may be one thing more that I will need to restrict the use of, but that is okay as we never use them.

Thanks for your input.

Chris

On Aug 15, 2013, at 6:16 PM, Lucian Smith <luc...@gm...> wrote:

> Hmm, let's see.  To sum it up in a single sentence, if the potential
> problem with deletions is that there may be things that now point to
> nothing, the problem with replacements is that there may be too many
> things that now point to the replacement.
> 
> It would be possible to group a bunch of rules into simple 'input' and
> 'output', but that wouldn't allow the normal variety of expression we
> normally have in SBML.  As an example, a Species could appear in two
> reactions and in an event assignment in the submodel, and would thus
> be allowed to appear in more reactions, event assignments, and an
> initial assignment in a containing model, but not in any kind of Rule.
> Does that mean it counts as an 'input' or an 'output'?
> 
> For the vast majority of the attributes I listed in the 'deletions'
> message, it doesn't matter if multiple elements all point to the same
> replaced element:  for things like units, that's what they were
> designed for.  Here's the list of things that remain:
> 
> * InitialAssignments
> * AssignmentRules,
> * RateRules
> * EventAssignments
> * SpeciesReferences
> * AlgebraicRules
> 
> The rules about how many of the above you may appear in is actually
> quite complicated!  The presence of algebraic rules makes it *super*
> complicated, but even disregarding that, it's still a little crazy.
> 
> My inclination here would be simply to have the port note all the
> things the element appears in, in the submodel.  Something like <port
> id="P" idRef="p" initialAssignment="false" assignmentRule="false"
> rateRule="false" eventAssignment="true" speciesReference="true"
> algebraicRule="none"/>
> 
> Then you know, "OK, I can still give this thing an initialAssignment,
> event assignment, and have it appear in more reactions, but I can't
> give it an assignment rule or rate rule".  Or:
> 
> <port id="P" idRef="p" initialAssignment="false"
> assignmentRule="false" rateRule="true" eventAssignment="true"
> speciesReference="false" algebraicRule="none"/>
> 
> and know "I can't put this in any reactions or any rules, but I could
> give it an initial assignment or an event assignment"
> 
> I dunno, maybe nobody wants this.  But I do know that 'input' and
> 'output' have already been deemed insufficient by the group that
> Stefan works with--they want 'this is a species that appears in some
> reactions, and may appear in more, too'.
> 
> Even this doesn't address the case where the modeler may want to
> simply delete or replace the offending extra reference: delete an
> assignment rule and instead use reactions, say, or replace an initial
> assignment.  What does that do to your port semantics?  It's really
> hard to say.
> 
> Now, all this doesn't really matter if you want to have your 'input'
> and 'output' semantics simply be much more stringent than SBML would
> otherwise allow.  But that does mean that you won't be able to use
> ports to do *all* the things that would otherwise be legal.  Maybe
> this isn't a problem?
> 
> -Lucian
> 
> 
> On Thu, Aug 15, 2013 at 2:30 PM, Chris J. Myers <my...@ec...> wrote:
>> As I mentioned, replacements are a lot more difficult to set down a fixed rule for ensuring validation after flattening.  The problem is that you can have issues like two submodels that have an initial assignment to a species and after the replacement of that species with a top-level species you end up with two initial assignments which is not consistent.
>> 
>> To address this problem, we have been considering the idea of using port directionality to determine how an object can be used.  Note that this idea would not be perfect, but it would at least allow someone that wanted to follow a set of rules a means to ensure a valid model.  We leave open the possibility of marking ports with no direction (or referencing objects directly with no port) as a means to get around the validation.
>> 
>> The idea works like this.
>> 
>> 1) A species referenced by an input port could not be assigned in a rule, event, or initial assignment and it could not participate as a reactant or product in a reaction.
>> 
>> 2) A species referenced by an output port can be referenced anywhere within a model, but when it is connected to by a higher level model, it can only be connected to species in other subModels through input ports.
>> 
>> 3) A species used to connect ports in a top-level model could only be assigned in rules, events, or initial assignments and used as reactants or products in a reaction if it was being used to only connect to input ports.
>> 
>> 4) Similar rules are made for compartments, parameters, and speciesReferences.
>> 
>> 5) Replacements cannot reference output ports.
>> 
>> 6) ReplacedBys cannot reference input ports.
>> 
>> Again, note there would still be ports without directionality for which you would not have these restrictions or you could reference an object directly without using a port.  However, I think if you followed these rules and only used input and output ports to reference to objects you may be able to guarantee validity after flattening, if I have not missed something.
>> 
>> Cheers,
>> 
>> Chris
>> 
>> 
>> 
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>> It's a free troubleshooting tool designed for production.
>> Get down to code-level detail for bottlenecks, with <2% overhead.
>> Download for free and get started troubleshooting in minutes.
>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>> _______________________________________________
>> sbml-comp mailing list
>> sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbml-comp
> 
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead. 
> Download for free and get started troubleshooting in minutes. 
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> sbml-comp mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-comp

Re: [sbml-comp] Comp validations rules: replacements

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

Hmm, let's see.  To sum it up in a single sentence, if the potential
problem with deletions is that there may be things that now point to
nothing, the problem with replacements is that there may be too many
things that now point to the replacement.

It would be possible to group a bunch of rules into simple 'input' and
'output', but that wouldn't allow the normal variety of expression we
normally have in SBML.  As an example, a Species could appear in two
reactions and in an event assignment in the submodel, and would thus
be allowed to appear in more reactions, event assignments, and an
initial assignment in a containing model, but not in any kind of Rule.
 Does that mean it counts as an 'input' or an 'output'?

For the vast majority of the attributes I listed in the 'deletions'
message, it doesn't matter if multiple elements all point to the same
replaced element:  for things like units, that's what they were
designed for.  Here's the list of things that remain:

* InitialAssignments
* AssignmentRules,
* RateRules
* EventAssignments
* SpeciesReferences
* AlgebraicRules

The rules about how many of the above you may appear in is actually
quite complicated!  The presence of algebraic rules makes it *super*
complicated, but even disregarding that, it's still a little crazy.

My inclination here would be simply to have the port note all the
things the element appears in, in the submodel.  Something like <port
id="P" idRef="p" initialAssignment="false" assignmentRule="false"
rateRule="false" eventAssignment="true" speciesReference="true"
algebraicRule="none"/>

Then you know, "OK, I can still give this thing an initialAssignment,
event assignment, and have it appear in more reactions, but I can't
give it an assignment rule or rate rule".  Or:

<port id="P" idRef="p" initialAssignment="false"
assignmentRule="false" rateRule="true" eventAssignment="true"
speciesReference="false" algebraicRule="none"/>

and know "I can't put this in any reactions or any rules, but I could
give it an initial assignment or an event assignment"

I dunno, maybe nobody wants this.  But I do know that 'input' and
'output' have already been deemed insufficient by the group that
Stefan works with--they want 'this is a species that appears in some
reactions, and may appear in more, too'.

Even this doesn't address the case where the modeler may want to
simply delete or replace the offending extra reference: delete an
assignment rule and instead use reactions, say, or replace an initial
assignment.  What does that do to your port semantics?  It's really
hard to say.

Now, all this doesn't really matter if you want to have your 'input'
and 'output' semantics simply be much more stringent than SBML would
otherwise allow.  But that does mean that you won't be able to use
ports to do *all* the things that would otherwise be legal.  Maybe
this isn't a problem?

-Lucian


On Thu, Aug 15, 2013 at 2:30 PM, Chris J. Myers <my...@ec...> wrote:
> As I mentioned, replacements are a lot more difficult to set down a fixed rule for ensuring validation after flattening.  The problem is that you can have issues like two submodels that have an initial assignment to a species and after the replacement of that species with a top-level species you end up with two initial assignments which is not consistent.
>
> To address this problem, we have been considering the idea of using port directionality to determine how an object can be used.  Note that this idea would not be perfect, but it would at least allow someone that wanted to follow a set of rules a means to ensure a valid model.  We leave open the possibility of marking ports with no direction (or referencing objects directly with no port) as a means to get around the validation.
>
> The idea works like this.
>
> 1) A species referenced by an input port could not be assigned in a rule, event, or initial assignment and it could not participate as a reactant or product in a reaction.
>
> 2) A species referenced by an output port can be referenced anywhere within a model, but when it is connected to by a higher level model, it can only be connected to species in other subModels through input ports.
>
> 3) A species used to connect ports in a top-level model could only be assigned in rules, events, or initial assignments and used as reactants or products in a reaction if it was being used to only connect to input ports.
>
> 4) Similar rules are made for compartments, parameters, and speciesReferences.
>
> 5) Replacements cannot reference output ports.
>
> 6) ReplacedBys cannot reference input ports.
>
> Again, note there would still be ports without directionality for which you would not have these restrictions or you could reference an object directly without using a port.  However, I think if you followed these rules and only used input and output ports to reference to objects you may be able to guarantee validity after flattening, if I have not missed something.
>
> Cheers,
>
> Chris
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> sbml-comp mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-comp

[sbml-comp] Comp validations rules: replacements

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

As I mentioned, replacements are a lot more difficult to set down a fixed rule for ensuring validation after flattening.  The problem is that you can have issues like two submodels that have an initial assignment to a species and after the replacement of that species with a top-level species you end up with two initial assignments which is not consistent.  

To address this problem, we have been considering the idea of using port directionality to determine how an object can be used.  Note that this idea would not be perfect, but it would at least allow someone that wanted to follow a set of rules a means to ensure a valid model.  We leave open the possibility of marking ports with no direction (or referencing objects directly with no port) as a means to get around the validation.

The idea works like this.  

1) A species referenced by an input port could not be assigned in a rule, event, or initial assignment and it could not participate as a reactant or product in a reaction.

2) A species referenced by an output port can be referenced anywhere within a model, but when it is connected to by a higher level model, it can only be connected to species in other subModels through input ports.

3) A species used to connect ports in a top-level model could only be assigned in rules, events, or initial assignments and used as reactants or products in a reaction if it was being used to only connect to input ports.

4) Similar rules are made for compartments, parameters, and speciesReferences.

5) Replacements cannot reference output ports.

6) ReplacedBys cannot reference input ports.

Again, note there would still be ports without directionality for which you would not have these restrictions or you could reference an object directly without using a port.  However, I think if you followed these rules and only used input and output ports to reference to objects you may be able to guarantee validity after flattening, if I have not missed something.

Cheers,

Chris

Re: [sbml-comp] Comp validation rules: deletions

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

> 
>  "An SBML element can only be deleted if all references to that
> element are also deleted."
> 
> Yup, I think that sums it up nicely.  The only thing from core that
> you left out of the rest of your analysis is Units, but they, too,
> fall under the general rule above.
> 
Hmm, I forgot function definitions as well, but you covered it in your list below.

> The full list of placed in core that can reference other elements is
> (I believe, from looking through the spec for 'SIdRef's):
> 
> * Model
>  * substance/time/volume/area/length/extent-Units (relevant to
> deleted UnitDefinitions)
>  * conversionFactor (relevant to deleted Parameters)
> * Compartment
>  * units (relevant to deleted UnitDefinitions)
> * Species
>  * compartment (relevant to deleted Compartments)
>  * substanceUnits (relevant to deleted UnitDefinitions)
>  * conversionFactor (relevant to deleted Parameters)
> * Parameter
>  * units (relevant to deleted UnitDefinitions)
> * InitialAssignment
>  * symbol (relevant to deleted Compartments, Species,
> SpeciesReference (and therefore, by proxy, deleted Reactions), and
> Parameters)
> * AssignmentRules, RateRules,and EventAssignments
>  * variable (relevant to deleted Compartments, Species,
> SpeciesReference (and therefore, by proxy, deleted Reactions), and
> Parameters)
> * Reaction
>  * compartment (relevant to deleted Compartments)
> * SimpleSpeciesReference
>  * species (relevant to deleted Species)
> * LocalParameter
>  * units (relevant to deleted UnitDefinitions)
> * Math
>  * 'ci' elements (relevant to deleted Compartments, Species,
> SpeciesReference (and therefore, by proxy, deleted Reactions),
> Reactions themselves, Parameters, and FunctionDefinitions)
>  * the cn 'units' attribute (relevant to deleted UnitDefinitions)
> * Annotations
>  * Potentially anything, but the 'rdf:about' attribute in particular.
> Relevant to anything, but helpfully, compliant annotations only
> annotate their parents, and are therefore already deleted when their
> parents are deleted.  One need only worry about non-compliant
> annotations, then.)
> 
> (anything else I missed?)

Seems good to me.  Will need similar list for packages.
> 
> Also remember that it is technically possible to delete an entire
> list, so if you delete the ListOfReactions (say) you'll have to go
> through and check all of its children Reaction and SpeciesReference
> elements.
> 
Ugh, we don't allow that.  Couldn't we just add a validation rule disallowing that?  :-)

> My only other comment is:
> 
>> Caveat: there are times where a replacement acts like a deletion.  For example, when you replace a rule with another rule, you are effectively deleting the rule.  In these situations, they can also serve to delete the objects that reference the object you are trying to delete.
> 
> This is incorrect.  Replacements should always redirect all references
> to the old object to the replacement object, regardless of the package
> the reference came from.  The only reason why replacements act like
> deletions in core for rules is that nothing refers to rules in core.
> If a package (like layout) refers to a replaced rule, that reference
> should be considered to point to the replacement object.
> 
Good point.

> However, there is indeed a different sort of caveat here:
> replacements *do* act like deletions for the *children* of the
> replaced object.  If a reaction is replaced, its children
> SpeciesReferences are considered to be deleted,
> 
Also, good point.

> -Lucian
> 
> (Oh, geez, this probably means that replacing a Reaction *and*
> replacing one of its child SpeciesReferences needs to work without
> double-deleting the child SpeciesReference in the libsbml flattening
> routine.  I'll put that on my list...)

You lost me here.  Can you give an example?

Chris

Re: [sbml-comp] Comp validation rules: deletions

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

  "An SBML element can only be deleted if all references to that
element are also deleted."

Yup, I think that sums it up nicely.  The only thing from core that
you left out of the rest of your analysis is Units, but they, too,
fall under the general rule above.

The full list of placed in core that can reference other elements is
(I believe, from looking through the spec for 'SIdRef's):

* Model
  * substance/time/volume/area/length/extent-Units (relevant to
deleted UnitDefinitions)
  * conversionFactor (relevant to deleted Parameters)
* Compartment
  * units (relevant to deleted UnitDefinitions)
* Species
  * compartment (relevant to deleted Compartments)
  * substanceUnits (relevant to deleted UnitDefinitions)
  * conversionFactor (relevant to deleted Parameters)
* Parameter
  * units (relevant to deleted UnitDefinitions)
* InitialAssignment
  * symbol (relevant to deleted Compartments, Species,
SpeciesReference (and therefore, by proxy, deleted Reactions), and
Parameters)
* AssignmentRules, RateRules,and EventAssignments
  * variable (relevant to deleted Compartments, Species,
SpeciesReference (and therefore, by proxy, deleted Reactions), and
Parameters)
* Reaction
  * compartment (relevant to deleted Compartments)
* SimpleSpeciesReference
  * species (relevant to deleted Species)
* LocalParameter
  * units (relevant to deleted UnitDefinitions)
* Math
  * 'ci' elements (relevant to deleted Compartments, Species,
SpeciesReference (and therefore, by proxy, deleted Reactions),
Reactions themselves, Parameters, and FunctionDefinitions)
  * the cn 'units' attribute (relevant to deleted UnitDefinitions)
* Annotations
  * Potentially anything, but the 'rdf:about' attribute in particular.
 Relevant to anything, but helpfully, compliant annotations only
annotate their parents, and are therefore already deleted when their
parents are deleted.  One need only worry about non-compliant
annotations, then.)

(anything else I missed?)

Also remember that it is technically possible to delete an entire
list, so if you delete the ListOfReactions (say) you'll have to go
through and check all of its children Reaction and SpeciesReference
elements.

My only other comment is:

> Caveat: there are times where a replacement acts like a deletion.  For example, when you replace a rule with another rule, you are effectively deleting the rule.  In these situations, they can also serve to delete the objects that reference the object you are trying to delete.

This is incorrect.  Replacements should always redirect all references
to the old object to the replacement object, regardless of the package
the reference came from.  The only reason why replacements act like
deletions in core for rules is that nothing refers to rules in core.
If a package (like layout) refers to a replaced rule, that reference
should be considered to point to the replacement object.

However, there is indeed a different sort of caveat here:
replacements *do* act like deletions for the *children* of the
replaced object.  If a reaction is replaced, its children
SpeciesReferences are considered to be deleted,

-Lucian

(Oh, geez, this probably means that replacing a Reaction *and*
replacing one of its child SpeciesReferences needs to work without
double-deleting the child SpeciesReference in the libsbml flattening
routine.  I'll put that on my list...)


:54 AM, Chris J. Myers <my...@ec...> wrote:
> I've been wondering for some time if it may be possible to come up with a set of validation rules that can ensure that a flattened model is valid assuming the submodels are all valid to begin with.  This is a challenging problem, so I would like to take it in steps.  I believe that invalidity is caused by problems with deletions and replacements.  In other words, assuming there are no deletions or replacements, I believe that a valid model composed of valid submodels when flattened results in a valid model.  Can anyone think of a counterexample to this?
>
> Assuming this, we need to consider rules on deletions and replacements, and lets take deletions first.
>
> 1) Assuming SBML Core only, I believe deletions of events, rules, and initial assignments never create an invalid model.  Note that the comp validation rule that we discussed earlier which says you cannot have a reference in a deletion and also in replacements, etc. is important to ensure this.  Considering approved packages, there is a potential problem with layout as layout can have a reference to one of these objects.  However, in is highly unlikely that layout is valid after flattening, so it is not too bad assumption to assume there is no layout information that is preserved after flattening.  If for some reason this is not the case, then we need to only add another rule that says deletions of events, rules, and initial assignments are safe as long as any references to them by layout in the submodel are also deleted.
>
> 2) Compartments, species, reactions, parameters, and species reference ids are trickier because they can occur in math.  Therefore, the deletion of one of these objects is only valid if all other SBML elements that reference it are also removed.  Besides math, this may be in the left hand side of event/initial/rule assignments, or in the case of compartments in species and reactions references to them.  There is the same issue with the layout package described above.  With comp, there are references to parameters in conversion factors.  With fbc, there are references to reactions in both objectives and flux bounds.  With qual, I don't believe there are any problems.
>
> 3) Local reaction parameters can be deleted if they are either not used by the kinetic law or they are covered by a global parameter of the same name.
>
> 4) Package objects have similar considerations as above, and they are too numerous to list at this time.  However, they all boil down to I think a general rule which states:
>
> "An SBML element can only be deleted if all references to that element are also deleted."
>
> Caveat: there are times where a replacement acts like a deletion.  For example, when you replace a rule with another rule, you are effectively deleting the rule.  In these situations, they can also serve to delete the objects that reference the object you are trying to delete.
>
> Ok, I think I will stop there.  Replacements are a lot trickier, so I will discuss them later.  I just wanted to get the ball rolling with deletions.
>
> Cheers,
>
> Chris
>
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> sbml-comp mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-comp

[sbml-comp] Comp validation rules: deletions

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

I've been wondering for some time if it may be possible to come up with a set of validation rules that can ensure that a flattened model is valid assuming the submodels are all valid to begin with.  This is a challenging problem, so I would like to take it in steps.  I believe that invalidity is caused by problems with deletions and replacements.  In other words, assuming there are no deletions or replacements, I believe that a valid model composed of valid submodels when flattened results in a valid model.  Can anyone think of a counterexample to this?

Assuming this, we need to consider rules on deletions and replacements, and lets take deletions first.

1) Assuming SBML Core only, I believe deletions of events, rules, and initial assignments never create an invalid model.  Note that the comp validation rule that we discussed earlier which says you cannot have a reference in a deletion and also in replacements, etc. is important to ensure this.  Considering approved packages, there is a potential problem with layout as layout can have a reference to one of these objects.  However, in is highly unlikely that layout is valid after flattening, so it is not too bad assumption to assume there is no layout information that is preserved after flattening.  If for some reason this is not the case, then we need to only add another rule that says deletions of events, rules, and initial assignments are safe as long as any references to them by layout in the submodel are also deleted.

2) Compartments, species, reactions, parameters, and species reference ids are trickier because they can occur in math.  Therefore, the deletion of one of these objects is only valid if all other SBML elements that reference it are also removed.  Besides math, this may be in the left hand side of event/initial/rule assignments, or in the case of compartments in species and reactions references to them.  There is the same issue with the layout package described above.  With comp, there are references to parameters in conversion factors.  With fbc, there are references to reactions in both objectives and flux bounds.  With qual, I don't believe there are any problems.

3) Local reaction parameters can be deleted if they are either not used by the kinetic law or they are covered by a global parameter of the same name.

4) Package objects have similar considerations as above, and they are too numerous to list at this time.  However, they all boil down to I think a general rule which states:

"An SBML element can only be deleted if all references to that element are also deleted."

Caveat: there are times where a replacement acts like a deletion.  For example, when you replace a rule with another rule, you are effectively deleting the rule.  In these situations, they can also serve to delete the objects that reference the object you are trying to delete.

Ok, I think I will stop there.  Replacements are a lot trickier, so I will discuss them later.  I just wanted to get the ball rolling with deletions.

Cheers,

Chris

Re: [sbml-comp] Reference validation

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

I think so but a bullet list would be more clear.

Chris

Sent from my iPhone

On Aug 5, 2013, at 2:28 PM, Lucian Smith <luc...@gm...> wrote:

> Sarah wrote:
> 
>> "comp-20714 Any one SBML object may only be referenced in one of the
>> following ways:  referenced by a single Port object; referenced by a
>> single Deletion object; referenced by a single ReplacedElement;
>> referenced by one or more ReplacedBy  objects or be the parent of a
>> single ReplacedBy child.  Essentially once an object has been referenced
>> in one of these ways it cannot be referenced again. However, if the
>> object being referenced by a ReplacedElement is a Deletion, that
>> Deletion object may be referenced by more that one ReplacedElement object."
> 
> This is pretty good, except for the last little bit:  the exception is
> only for ReplacedElements that use the 'deletion' attribute, not for
> ReplacedElements that point to Deletions.
> 
> After a bit more implementation, I realized that while it's fine to
> have a bunch of things point to Deletions using the 'deletion'
> attribute (it's what it was designed for, after all), it is *not* OK
> to have a bunch of things point to a 'Deletion' *and* have that
> deletion itself deleted or replaced, because then you'd again have
> dangling references.
> 
> So here's a slightly updated validation rule:
> 
> "Any one SBML object may only be referenced in one of the following
> ways:  referenced by a single Port object; referenced by a single
> Deletion object; referenced by a single ReplacedElement; be the parent
> of a single ReplacedBy child; referenced by one or more ReplacedBy
> objects; or be referenced by one or more ReplacedElement objects all
> using the 'deletion' attribute.  Essentially, once an object has been
> referenced in one of these ways it cannot be referenced again."
> 
> Does that work for people?
> 
> -Lucian
> 
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent 
> caught up. So what steps can you take to put your SQL databases under 
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> _______________________________________________
> sbml-comp mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-comp

Re: [sbml-comp] Reference validation

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

Sarah wrote:

> "comp-20714 Any one SBML object may only be referenced in one of the
> following ways:  referenced by a single Port object; referenced by a
> single Deletion object; referenced by a single ReplacedElement;
> referenced by one or more ReplacedBy  objects or be the parent of a
> single ReplacedBy child.  Essentially once an object has been referenced
> in one of these ways it cannot be referenced again. However, if the
> object being referenced by a ReplacedElement is a Deletion, that
> Deletion object may be referenced by more that one ReplacedElement object."

This is pretty good, except for the last little bit:  the exception is
only for ReplacedElements that use the 'deletion' attribute, not for
ReplacedElements that point to Deletions.

After a bit more implementation, I realized that while it's fine to
have a bunch of things point to Deletions using the 'deletion'
attribute (it's what it was designed for, after all), it is *not* OK
to have a bunch of things point to a 'Deletion' *and* have that
deletion itself deleted or replaced, because then you'd again have
dangling references.

So here's a slightly updated validation rule:

"Any one SBML object may only be referenced in one of the following
ways:  referenced by a single Port object; referenced by a single
Deletion object; referenced by a single ReplacedElement; be the parent
of a single ReplacedBy child; referenced by one or more ReplacedBy
objects; or be referenced by one or more ReplacedElement objects all
using the 'deletion' attribute.  Essentially, once an object has been
referenced in one of these ways it cannot be referenced again."

Does that work for people?

-Lucian

Re: [sbml-comp] Reference Validation

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

Sounds good.

Chris

Sent from my iPhone

On Aug 2, 2013, at 8:12 PM, Lucian Smith <luc...@gm...> wrote:

> OK, I understand the issue.  Yes, this particular validation rule only
> triggers if you actively run validation:  it does not trigger if you
> are creating ReplacedElements, etc.  It would prevent flattening, but
> you'd have to write your own flattening (or pre-flattening) routine
> anyway (which, if I understand your message correctly, you would
> indeed be doing)
> 
> In other news, the upcoming version of libsbml should be a lot better
> about letting you know exactly what went wrong during flattening,
> which hopefully will prevent those head-scratching failures you
> mention (which I found frustrating myself ;-)
> 
> -Lucian
> 
> On Fri, Aug 2, 2013 at 9:19 AM, Chris J. Myers <my...@ec...> wrote:
>> Hi Sarah,
>> 
>> My question is more general one about validation.  We want to use annotations to test out arrays now.  However, my concern is that validation can get in the way of our doing testing.  In some cases, a validation rule results in libsbml disallowing the construction of objects.  For example, if you try to create an object and add it to a document without setting all defaults it does not add it to the document.  Another example is that when I had some issues like replacements pointing to things which were deleted, Lucian's flatten code failed to flatten rather than just ignoring the dangling pointers.  In both cases, I've spent a lot of time trying to figure out what went wrong.
>> 
>> My question is whether this validation rule will be one that actually prevents the creation of a document that violates it OR just one that gets checked when you ask the validator to check the document.  If it is the later, then I can do my array prototyping because we will violate the rule in our documents before we flatten out arrays but we will not run flatten until after the arrays are removed, so flatten will never see an invalid document.  I just wanted to make sure this approach to prototyping will work.
>> 
>> Chris
>> 
>> On Aug 2, 2013, at 10:12 AM, Sarah Keating <sar...@te...> wrote:
>> 
>>> On 02/08/2013 15:59, Chris J. Myers wrote:
>>>> On second thought, I do have a concern for arrays.  We want to
>>>> prototype arrays, and this validation rule may get in our way of
>>>> doing this.  Essentially, we want to create what will appear to be
>>>> multiple references in our SBML document though we will flatten out
>>>> the arrays before we flatten out the hierarchy so there will be no
>>>> ambiguity.  Will libsbml prevent us from doing this or just give us
>>>> spurious warnings when we run the validator on our models?
>>> 
>>> 
>>> Who knows ;-)
>>> 
>>> This is something that will need to be addressed when we get to the point of looking at array implementation. There may well be other validation rules that get a bit skewed if the object is an array. I imagine arrays will be the most difficult to get to play nice with the other packages !
>>> 
>>> But I don't thing this is a reason not to put the validation rule into comp at this point.
>>> 
>>> Sarah
>> 
>> 
>> ------------------------------------------------------------------------------
>> Get your SQL database under version control now!
>> Version control is standard for application code, but databases havent
>> caught up. So what steps can you take to put your SQL databases under
>> version control? Why should you start doing it? Read more to find out.
>> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
>> _______________________________________________
>> sbml-comp mailing list
>> sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbml-comp
> 
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent 
> caught up. So what steps can you take to put your SQL databases under 
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> _______________________________________________
> sbml-comp mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-comp

Re: [sbml-comp] Reference Validation

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

OK, I understand the issue.  Yes, this particular validation rule only
triggers if you actively run validation:  it does not trigger if you
are creating ReplacedElements, etc.  It would prevent flattening, but
you'd have to write your own flattening (or pre-flattening) routine
anyway (which, if I understand your message correctly, you would
indeed be doing)

In other news, the upcoming version of libsbml should be a lot better
about letting you know exactly what went wrong during flattening,
which hopefully will prevent those head-scratching failures you
mention (which I found frustrating myself ;-)

-Lucian

On Fri, Aug 2, 2013 at 9:19 AM, Chris J. Myers <my...@ec...> wrote:
> Hi Sarah,
>
> My question is more general one about validation.  We want to use annotations to test out arrays now.  However, my concern is that validation can get in the way of our doing testing.  In some cases, a validation rule results in libsbml disallowing the construction of objects.  For example, if you try to create an object and add it to a document without setting all defaults it does not add it to the document.  Another example is that when I had some issues like replacements pointing to things which were deleted, Lucian's flatten code failed to flatten rather than just ignoring the dangling pointers.  In both cases, I've spent a lot of time trying to figure out what went wrong.
>
> My question is whether this validation rule will be one that actually prevents the creation of a document that violates it OR just one that gets checked when you ask the validator to check the document.  If it is the later, then I can do my array prototyping because we will violate the rule in our documents before we flatten out arrays but we will not run flatten until after the arrays are removed, so flatten will never see an invalid document.  I just wanted to make sure this approach to prototyping will work.
>
> Chris
>
> On Aug 2, 2013, at 10:12 AM, Sarah Keating <sar...@te...> wrote:
>
>> On 02/08/2013 15:59, Chris J. Myers wrote:
>>> On second thought, I do have a concern for arrays.  We want to
>>> prototype arrays, and this validation rule may get in our way of
>>> doing this.  Essentially, we want to create what will appear to be
>>> multiple references in our SBML document though we will flatten out
>>> the arrays before we flatten out the hierarchy so there will be no
>>> ambiguity.  Will libsbml prevent us from doing this or just give us
>>> spurious warnings when we run the validator on our models?
>>
>>
>> Who knows ;-)
>>
>> This is something that will need to be addressed when we get to the point of looking at array implementation. There may well be other validation rules that get a bit skewed if the object is an array. I imagine arrays will be the most difficult to get to play nice with the other packages !
>>
>> But I don't thing this is a reason not to put the validation rule into comp at this point.
>>
>> Sarah
>
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> _______________________________________________
> sbml-comp mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-comp

Re: [sbml-comp] Reference Validation

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

Hi Sarah,

My question is more general one about validation.  We want to use annotations to test out arrays now.  However, my concern is that validation can get in the way of our doing testing.  In some cases, a validation rule results in libsbml disallowing the construction of objects.  For example, if you try to create an object and add it to a document without setting all defaults it does not add it to the document.  Another example is that when I had some issues like replacements pointing to things which were deleted, Lucian's flatten code failed to flatten rather than just ignoring the dangling pointers.  In both cases, I've spent a lot of time trying to figure out what went wrong.

My question is whether this validation rule will be one that actually prevents the creation of a document that violates it OR just one that gets checked when you ask the validator to check the document.  If it is the later, then I can do my array prototyping because we will violate the rule in our documents before we flatten out arrays but we will not run flatten until after the arrays are removed, so flatten will never see an invalid document.  I just wanted to make sure this approach to prototyping will work.

Chris

On Aug 2, 2013, at 10:12 AM, Sarah Keating <sar...@te...> wrote:

> On 02/08/2013 15:59, Chris J. Myers wrote:
>> On second thought, I do have a concern for arrays.  We want to
>> prototype arrays, and this validation rule may get in our way of
>> doing this.  Essentially, we want to create what will appear to be
>> multiple references in our SBML document though we will flatten out
>> the arrays before we flatten out the hierarchy so there will be no
>> ambiguity.  Will libsbml prevent us from doing this or just give us
>> spurious warnings when we run the validator on our models?
> 
> 
> Who knows ;-)
> 
> This is something that will need to be addressed when we get to the point of looking at array implementation. There may well be other validation rules that get a bit skewed if the object is an array. I imagine arrays will be the most difficult to get to play nice with the other packages !
> 
> But I don't thing this is a reason not to put the validation rule into comp at this point.
> 
> Sarah

Re: [sbml-comp] Reference Validation

[Sarah K. <sar...@te...>]

On 02/08/2013 15:59, Chris J. Myers wrote:
> On second thought, I do have a concern for arrays.  We want to
> prototype arrays, and this validation rule may get in our way of
> doing this.  Essentially, we want to create what will appear to be
> multiple references in our SBML document though we will flatten out
> the arrays before we flatten out the hierarchy so there will be no
> ambiguity.  Will libsbml prevent us from doing this or just give us
> spurious warnings when we run the validator on our models?


Who knows ;-)

This is something that will need to be addressed when we get to the 
point of looking at array implementation. There may well be other 
validation rules that get a bit skewed if the object is an array. I 
imagine arrays will be the most difficult to get to play nice with the 
other packages !

But I don't thing this is a reason not to put the validation rule into 
comp at this point.

Sarah

Re: [sbml-comp] Reference Validation

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

On second thought, I do have a concern for arrays.  We want to prototype arrays, and this validation rule may get in our way of doing this.  Essentially, we want to create what will appear to be multiple references in our SBML document though we will flatten out the arrays before we flatten out the hierarchy so there will be no ambiguity.  Will libsbml prevent us from doing this or just give us spurious warnings when we run the validator on our models?

Chris

On Aug 1, 2013, at 3:55 PM, Lucian Smith <luc...@gm...> wrote:

> Chris wrote:
> 
>> Your email is very long, so let me see if I can summarize.
>> 
>> 1) If an element is referred to by a port, then models that refer to this element in a replacement or deletion must use the port and not refer directly to the element, correct?  I strongly agree with this.
> 
> Correct.  It also means you cannot create a port to something that has
> been replaced or deleted (iBioSim did this at one point; not sure if
> it still does or not.)
> 
>> 2) If an element in a submodel is referred to in a replacement, replacedBy, or deletion, then it must be referred to in exactly one, correct?  I agree with this for models that don't use arrays, but things get tricky with arrays.
> 
> Oy, arrays.  I think that this can be solved in the arrays spec, and
> possibly referenced in a future comp spec.  It will mean that a
> validator that does not understand arrays would think that the model
> was invalid, but that's OK, since it doesn't understand arrays.
> Libsbml would have to special-case the validation code with some
> #ifdef ARRAYS, but again, I think that is fine.
> 
> 
> 
> Since both you and Stefan seem on board with this, here's my proposed
> clarification to the spec.  This would replace item 3 in section
> 3.6.5:
> 
>   "Replacements must be unique. Any single SBML object may only
> appear in exactly one ReplacedElement, Port, or Deletion object; one
> set of ReplacedBy objects, or be the parent of a ReplacedBy object. In
> other words, a single object may be directly replaced, deleted, turned
> into a port, or replace one or more other objects, but may not do more
> than one of those things at a time. Otherwise, it would lead to
> ambiguities (e.g., in old references to the entities being replaced).
> A ReplacedElement object referring to a Deletion is the only exception
> to this rule, and may be listed in more than one
> ListOfReplacedElements."
> 
> And here's a new validation rule:
> 
> "comp-20714 Any one SBML object may only be referenced by a single
> Port, single Deletion, single ReplacedElement, one or more ReplacedBy
> objects, or have a ReplacedBy child, discounting any ReplacedElement
> that uses the deletion attribute."
> 
> Seem reasonable?
> 
> -Lucian
> 
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent 
> caught up. So what steps can you take to put your SQL databases under 
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> _______________________________________________
> sbml-comp mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-comp

Re: [sbml-comp] Reference Validation

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

I'm fine with Sarah's text. 

As for arrays, are you saying this validation rule is still okay because when you consider arrays they are not actually referring to the same object?

Chris

On Aug 2, 2013, at 3:10 AM, Sarah Keating <ske...@ca...> wrote:

> 
> Since some people read the validation rules first or indeed would only 
> encounter the rule if it is returned to them by a validator - could the 
> rule be more explicit and say:
> 
> "comp-20714 Any one SBML object may only be referenced in one of the 
> following ways:  referenced by a single Port object; referenced by a 
> single Deletion object; referenced by a single ReplacedElement; 
> referenced by one or more ReplacedBy  objects or be the parent of a 
> single ReplacedBy child.  Essentially once an object has been referenced 
> in one of these ways it cannot be referenced again. However, if the 
> object being referenced by a ReplacedElement is a Deletion, that 
> Deletion object may be referenced by more that one ReplacedElement object."
> 
> 
> 
> Sarah
> 
> PS If my reconstruction of the rule is not correct then more explanation 
> is needed :-)
> 
> 
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent 
> caught up. So what steps can you take to put your SQL databases under 
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> _______________________________________________
> sbml-comp mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-comp

Re: [sbml-comp] Reference Validation

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

Since some people read the validation rules first or indeed would only 
encounter the rule if it is returned to them by a validator - could the 
rule be more explicit and say:

"comp-20714 Any one SBML object may only be referenced in one of the 
following ways:  referenced by a single Port object; referenced by a 
single Deletion object; referenced by a single ReplacedElement; 
referenced by one or more ReplacedBy  objects or be the parent of a 
single ReplacedBy child.  Essentially once an object has been referenced 
in one of these ways it cannot be referenced again. However, if the 
object being referenced by a ReplacedElement is a Deletion, that 
Deletion object may be referenced by more that one ReplacedElement object."



Sarah

PS If my reconstruction of the rule is not correct then more explanation 
is needed :-)

Re: [sbml-comp] Reference Validation

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

Chris wrote:

> Your email is very long, so let me see if I can summarize.
>
> 1) If an element is referred to by a port, then models that refer to this element in a replacement or deletion must use the port and not refer directly to the element, correct?  I strongly agree with this.

Correct.  It also means you cannot create a port to something that has
been replaced or deleted (iBioSim did this at one point; not sure if
it still does or not.)

> 2) If an element in a submodel is referred to in a replacement, replacedBy, or deletion, then it must be referred to in exactly one, correct?  I agree with this for models that don't use arrays, but things get tricky with arrays.

Oy, arrays.  I think that this can be solved in the arrays spec, and
possibly referenced in a future comp spec.  It will mean that a
validator that does not understand arrays would think that the model
was invalid, but that's OK, since it doesn't understand arrays.
Libsbml would have to special-case the validation code with some
#ifdef ARRAYS, but again, I think that is fine.



Since both you and Stefan seem on board with this, here's my proposed
clarification to the spec.  This would replace item 3 in section
3.6.5:

   "Replacements must be unique. Any single SBML object may only
appear in exactly one ReplacedElement, Port, or Deletion object; one
set of ReplacedBy objects, or be the parent of a ReplacedBy object. In
other words, a single object may be directly replaced, deleted, turned
into a port, or replace one or more other objects, but may not do more
than one of those things at a time. Otherwise, it would lead to
ambiguities (e.g., in old references to the entities being replaced).
A ReplacedElement object referring to a Deletion is the only exception
to this rule, and may be listed in more than one
ListOfReplacedElements."

And here's a new validation rule:

"comp-20714 Any one SBML object may only be referenced by a single
Port, single Deletion, single ReplacedElement, one or more ReplacedBy
objects, or have a ReplacedBy child, discounting any ReplacedElement
that uses the deletion attribute."

Seem reasonable?

-Lucian

Re: [sbml-comp] Reference validation

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

Your email is very long, so let me see if I can summarize.

1) If an element is referred to by a port, then models that refer to this element in a replacement or deletion must use the port and not refer directly to the element, correct?  I strongly agree with this.

2) If an element in a submodel is referred to in a replacement, replacedBy, or deletion, then it must be referred to in exactly one, correct?  I agree with this for models that don't use arrays, but things get tricky with arrays.

Consider the following assuming an arrays package:
----------------
Model mod

Species S0[2]
	replace S0[0] with S in M[0]
  	replace S0[1] with S in M[1]

Species S1[2]
	replace S1[0] with S in M[2]
  	replace S1[1] with S in M[3]

Submodel M[4] of type submod

Model submod
Species S
---------------
If we ignore the array annotations, this will look like the same species is being replaced four times, but it is not the same species because it comes from a different submodel.  I'm not sure of a clean way to handle this except by making the comp package aware of the arrays package.  Perhaps, arrays has to become part of Version 2 of comp as they are both ways actually to represent models in a more compact form and can always be flattened away.  Any other ideas?

Chris

On Aug 1, 2013, at 10:44 AM, Lucian Smith <luc...@gm...> wrote:

> I have been continuing to go through the more complicated validation
> rules in comp in libsbml (as has Sarah), and I realized that there is
> some ambiguity in the spec as to where, exactly, some lines should be
> drawn.  I thought it was probably best if I asked you all about it!
> 
> The issue is: in what situations should it be illegal for two
> different constructs to point to the same element?
> 
> Some situations are obvious:  you don't want two deletions pointing to
> the same element, nor two replacedElements, nor a deletion and a
> replacedElement.
> 
> When you throw ports into the mix, it gets a little more tricky.  By
> far the simplest rule would be to simply say 'no two deletions,
> replacedElements, nor ports may point directly to the same object'.
> If we can agree this is the best course of action, that'd be great.
> 
> But there might be some situations where we could allow it?  One
> implication of the above rule is that if something has a port, you
> *must* reference the port, and not the element directly.  So instead
> of this:
> 
> <?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="test">
>    <listOfParameters>
>      <parameter id="Q" constant="false">
>        <comp:listOfReplacedElements>
>          <comp:replacedElement comp:idRef="q" comp:submodelRef="A"/>
>        </comp:listOfReplacedElements>
>      </parameter>
>    </listOfParameters>
>    <comp:listOfSubmodels>
>      <comp:submodel comp:id="A" comp:modelRef="submod"/>
>    </comp:listOfSubmodels>
>  </model>
>  <comp:listOfModelDefinitions>
>    <comp:modelDefinition id="submod">
>      <listOfParameters>
>        <parameter id="q" constant="false"/>
>      </listOfParameters>
>      <comp:listOfPorts>
>        <comp:port comp:idRef="q" comp:id="q_port"/>
>      </comp:listOfPorts>
>    </comp:modelDefinition>
>  </comp:listOfModelDefinitions>
> </sbml>
> 
> which has a submodel with parameter 'q' and a port 'q_port' that
> points to it, but where the replacedElement points to the parameter
> directly using an 'idRef'.  Instead, you must use the following, which
> uses portRef:
> 
> <?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="test">
>    <listOfParameters>
>      <parameter id="Q" constant="false">
>        <comp:listOfReplacedElements>
>          <comp:replacedElement comp:portRef="q_port" comp:submodelRef="A"/>
>        </comp:listOfReplacedElements>
>      </parameter>
>    </listOfParameters>
>    <comp:listOfSubmodels>
>      <comp:submodel comp:id="A" comp:modelRef="submod"/>
>    </comp:listOfSubmodels>
>  </model>
>  <comp:listOfModelDefinitions>
>    <comp:modelDefinition id="submod">
>      <listOfParameters>
>        <parameter id="q" constant="false"/>
>      </listOfParameters>
>      <comp:listOfPorts>
>        <comp:port comp:idRef="q" comp:id="q_port"/>
>      </comp:listOfPorts>
>    </comp:modelDefinition>
>  </comp:listOfModelDefinitions>
> </sbml>
> 
> However, if we say that we want to allow the first option above, and
> not put 'ports' in our restriction rule at all, we allow the
> following, where we have both a deletion and a port point to the same
> thing:
> 
> <?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="test">
>    <comp:listOfSubmodels>
>      <comp:submodel metaid="iBioSim2" comp:id="A"
> comp:modelRef="submod" comp:timeConversionFactor="extentconv"
> comp:extentConversionFactor="timeconv">
>        <comp:listOfDeletions>
>          <comp:deletion comp:idRef="q">
>        </comp:listOfDeletions>
>      </comp:submodel>
>    </comp:listOfSubmodels>
>    <comp:listOfPorts>
>      <comp:port comp:idRef="A" comp:id="q__A">
>        <comp:sBaseRef comp:idRef="q"/>
>      </comp:port>
>    </comp:listOfPorts>
>  </model>
>  <comp:listOfModelDefinitions>
>    <comp:modelDefinition metaid="submod__iBioSim1" id="submod" name="submod">
>      <listOfParameters>
>        <parameter id="q" constant="false"/>
>      </listOfParameters>
>    </comp:modelDefinition>
>  </comp:listOfModelDefinitions>
> </sbml>
> 
> Now, while this is technically OK, it is what a friend used to call a
> 'prescription for failure', since we have a port pointing at something
> that's been deleted:  any time the model is used as a submodel
> somewhere else, if they use the port, they suddenly end up with an
> invalid model.  But I'm not sure how to write a validation rule that
> allows the first example, and disallows the third.  Instead, it just
> seems simplest to me to require that any element can only be pointed
> at by a single port, replacedElement, or deletion.
> 
> It then gets more complicated considering the replacedBy element,
> which is sort of a reverse replacedElement.  Perhaps the simplest
> thing here would be to say that if an element has a replacedBy child,
> no port, replacedElement, or deletion may point to *it* (and instead
> require that those things point to the referenced replacement).
> 
> Any other opinions?
> 
> -Lucian
> 
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent 
> caught up. So what steps can you take to put your SQL databases under 
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> _______________________________________________
> sbml-comp mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-comp

Re: [sbml-comp] Reference validation

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

Hello Lucian

On Thu, 1 Aug 2013 09:44:21 -0700
Lucian Smith <luc...@gm...> wrote:

> Instead, it just
> seems simplest to me to require that any element can only be pointed
> at by a single port, replacedElement, or deletion.

I strongly agree with this. If we look at replacedBy as an inverse
replacedElement we should be able to cover all cases.

Thanks,
Stefan


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

[sbml-comp] Reference validation

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

I have been continuing to go through the more complicated validation
rules in comp in libsbml (as has Sarah), and I realized that there is
some ambiguity in the spec as to where, exactly, some lines should be
drawn.  I thought it was probably best if I asked you all about it!

The issue is: in what situations should it be illegal for two
different constructs to point to the same element?

Some situations are obvious:  you don't want two deletions pointing to
the same element, nor two replacedElements, nor a deletion and a
replacedElement.

When you throw ports into the mix, it gets a little more tricky.  By
far the simplest rule would be to simply say 'no two deletions,
replacedElements, nor ports may point directly to the same object'.
If we can agree this is the best course of action, that'd be great.

But there might be some situations where we could allow it?  One
implication of the above rule is that if something has a port, you
*must* reference the port, and not the element directly.  So instead
of this:

<?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="test">
    <listOfParameters>
      <parameter id="Q" constant="false">
        <comp:listOfReplacedElements>
          <comp:replacedElement comp:idRef="q" comp:submodelRef="A"/>
        </comp:listOfReplacedElements>
      </parameter>
    </listOfParameters>
    <comp:listOfSubmodels>
      <comp:submodel comp:id="A" comp:modelRef="submod"/>
    </comp:listOfSubmodels>
  </model>
  <comp:listOfModelDefinitions>
    <comp:modelDefinition id="submod">
      <listOfParameters>
        <parameter id="q" constant="false"/>
      </listOfParameters>
      <comp:listOfPorts>
        <comp:port comp:idRef="q" comp:id="q_port"/>
      </comp:listOfPorts>
    </comp:modelDefinition>
  </comp:listOfModelDefinitions>
</sbml>

which has a submodel with parameter 'q' and a port 'q_port' that
points to it, but where the replacedElement points to the parameter
directly using an 'idRef'.  Instead, you must use the following, which
uses portRef:

<?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="test">
    <listOfParameters>
      <parameter id="Q" constant="false">
        <comp:listOfReplacedElements>
          <comp:replacedElement comp:portRef="q_port" comp:submodelRef="A"/>
        </comp:listOfReplacedElements>
      </parameter>
    </listOfParameters>
    <comp:listOfSubmodels>
      <comp:submodel comp:id="A" comp:modelRef="submod"/>
    </comp:listOfSubmodels>
  </model>
  <comp:listOfModelDefinitions>
    <comp:modelDefinition id="submod">
      <listOfParameters>
        <parameter id="q" constant="false"/>
      </listOfParameters>
      <comp:listOfPorts>
        <comp:port comp:idRef="q" comp:id="q_port"/>
      </comp:listOfPorts>
    </comp:modelDefinition>
  </comp:listOfModelDefinitions>
</sbml>

However, if we say that we want to allow the first option above, and
not put 'ports' in our restriction rule at all, we allow the
following, where we have both a deletion and a port point to the same
thing:

<?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="test">
    <comp:listOfSubmodels>
      <comp:submodel metaid="iBioSim2" comp:id="A"
comp:modelRef="submod" comp:timeConversionFactor="extentconv"
comp:extentConversionFactor="timeconv">
        <comp:listOfDeletions>
          <comp:deletion comp:idRef="q">
        </comp:listOfDeletions>
      </comp:submodel>
    </comp:listOfSubmodels>
    <comp:listOfPorts>
      <comp:port comp:idRef="A" comp:id="q__A">
        <comp:sBaseRef comp:idRef="q"/>
      </comp:port>
    </comp:listOfPorts>
  </model>
  <comp:listOfModelDefinitions>
    <comp:modelDefinition metaid="submod__iBioSim1" id="submod" name="submod">
      <listOfParameters>
        <parameter id="q" constant="false"/>
      </listOfParameters>
    </comp:modelDefinition>
  </comp:listOfModelDefinitions>
</sbml>

Now, while this is technically OK, it is what a friend used to call a
'prescription for failure', since we have a port pointing at something
that's been deleted:  any time the model is used as a submodel
somewhere else, if they use the port, they suddenly end up with an
invalid model.  But I'm not sure how to write a validation rule that
allows the first example, and disallows the third.  Instead, it just
seems simplest to me to require that any element can only be pointed
at by a single port, replacedElement, or deletion.

It then gets more complicated considering the replacedBy element,
which is sort of a reverse replacedElement.  Perhaps the simplest
thing here would be to say that if an element has a replacedBy child,
no port, replacedElement, or deletion may point to *it* (and instead
require that those things point to the referenced replacement).

Any other opinions?

-Lucian

Re: [sbml-comp] Replacement restrictions

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

I agree with Stefen.

Chris

Sent from my iPhone

On Jul 19, 2013, at 11:08 PM, Stefan Hoops <sh...@vb...> wrote:

> Hello Lucian,
> 
> On Fri, 19 Jul 2013 22:45:45 +0100
> Lucian Smith <lp...@sp...> wrote:
> 
>> Hello again, everyone!  Libsbml has almost finished implementing
>> support for all the different validation rules in sbml-comp, and as
>> I've been working through things, I have one new question.
>> 
>> At HARMONY in Maastrict, we decided to implement a 'like replaces
>> like' rule, stating that any SBML class could only replace an element
>> of the same class, or of a derived class, with one exception:  an
>> slement with mathematical meaning could replace a Parameter.
>> 
>> However, the reverse (we decided) was not true:  a Parameter could
>> not replace some other element with mathematical meaning.
>> 
>> Now that people are starting to implement comp and use it in their 
>> tools, however, I cam across a model that does exactly this--it
>> replaces a Species with a Parameter.
>> 
>> Now, I came across this model because the flattened version of it was 
>> invalid:  the ID of the element was still being used as a 
>> ModifierSpeciesReference.  This can be corrected by simply deleting
>> the reference in question, but it does illustrate the reasoning
>> behind not allowing the situation in the first place:  there is often
>> extra semantic information associated with SBML elements with
>> mathematical meaning that are not Parameters, and it might be hard to
>> end up with viable models that no longer have that semantic meaning.
>> But perhaps that is what the tools are for, and modelers should be
>> allowed to attempt this anyway?
> 
> I know where the model came from. We have corrected the issue and
> implemented the following additional replacement options in addition to
> the like replace like:
> 
> Species can replace Parameter
> Compartment can replace Parameter
> 
> All others are prohibited. These are exactly the ones you have in mind. 
> 
> To do other replacements one has to delete the replaced object with all
> its consequences, i.e., if a species is delete all reactions in which
> it appears as a reactant or product should also go. If the species is a
> modifier the modifier should be removed and the kinetic law modified.
> These changes I think should never be automatic and should be left to
> the user or tool.
> 
>> 
>> So the general question is: is replacing a Species with a Parameter
>> (or a Compartment with a Parameter, etc.) something that people think
>> they might want to continue to do in the future?  Should we perhaps
>> relax the restriction?
> 
> No, what happens to species contained in a compartment when the
> compartment is replaced with a parameter? The model is broken. The
> restriction do not prohibit that tool may implement automatic rules but
> this should not be part of the comp package.
> 
> Thanks,
> Stefan
> 
> P.S.: The problem was caused by using replaced by instead of only using
> replace.  
> 
> 
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> sbml-comp mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-comp

Re: [sbml-comp] Replacement restrictions

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

Hello Lucian,

On Fri, 19 Jul 2013 22:45:45 +0100
Lucian Smith <lp...@sp...> wrote:

> Hello again, everyone!  Libsbml has almost finished implementing
> support for all the different validation rules in sbml-comp, and as
> I've been working through things, I have one new question.
> 
> At HARMONY in Maastrict, we decided to implement a 'like replaces
> like' rule, stating that any SBML class could only replace an element
> of the same class, or of a derived class, with one exception:  an
> slement with mathematical meaning could replace a Parameter.
> 
> However, the reverse (we decided) was not true:  a Parameter could
> not replace some other element with mathematical meaning.
> 
> Now that people are starting to implement comp and use it in their 
> tools, however, I cam across a model that does exactly this--it
> replaces a Species with a Parameter.
> 
> Now, I came across this model because the flattened version of it was 
> invalid:  the ID of the element was still being used as a 
> ModifierSpeciesReference.  This can be corrected by simply deleting
> the reference in question, but it does illustrate the reasoning
> behind not allowing the situation in the first place:  there is often
> extra semantic information associated with SBML elements with
> mathematical meaning that are not Parameters, and it might be hard to
> end up with viable models that no longer have that semantic meaning.
> But perhaps that is what the tools are for, and modelers should be
> allowed to attempt this anyway?

I know where the model came from. We have corrected the issue and
implemented the following additional replacement options in addition to
the like replace like:

Species can replace Parameter
Compartment can replace Parameter

All others are prohibited. These are exactly the ones you have in mind. 

To do other replacements one has to delete the replaced object with all
its consequences, i.e., if a species is delete all reactions in which
it appears as a reactant or product should also go. If the species is a
modifier the modifier should be removed and the kinetic law modified.
These changes I think should never be automatic and should be left to
the user or tool.

> 
> So the general question is: is replacing a Species with a Parameter
> (or a Compartment with a Parameter, etc.) something that people think
> they might want to continue to do in the future?  Should we perhaps
> relax the restriction?

No, what happens to species contained in a compartment when the
compartment is replaced with a parameter? The model is broken. The
restriction do not prohibit that tool may implement automatic rules but
this should not be part of the comp package.

Thanks,
Stefan

P.S.: The problem was caused by using replaced by instead of only using
replace.  

[sbml-comp] Replacement restrictions

[Lucian S. <lp...@sp...>]

Hello again, everyone!  Libsbml has almost finished implementing support 
for all the different validation rules in sbml-comp, and as I've been 
working through things, I have one new question.

At HARMONY in Maastrict, we decided to implement a 'like replaces like' 
rule, stating that any SBML class could only replace an element of the 
same class, or of a derived class, with one exception:  an slement with 
mathematical meaning could replace a Parameter.

However, the reverse (we decided) was not true:  a Parameter could not 
replace some other element with mathematical meaning.

Now that people are starting to implement comp and use it in their 
tools, however, I cam across a model that does exactly this--it replaces 
a Species with a Parameter.

Now, I came across this model because the flattened version of it was 
invalid:  the ID of the element was still being used as a 
ModifierSpeciesReference.  This can be corrected by simply deleting the 
reference in question, but it does illustrate the reasoning behind not 
allowing the situation in the first place:  there is often extra 
semantic information associated with SBML elements with mathematical 
meaning that are not Parameters, and it might be hard to end up with 
viable models that no longer have that semantic meaning.  But perhaps 
that is what the tools are for, and modelers should be allowed to 
attempt this anyway?

So the general question is: is replacing a Species with a Parameter (or 
a Compartment with a Parameter, etc.) something that people think they 
might want to continue to do in the future?  Should we perhaps relax the 
restriction?

All comments welcome!

-Lucian

Re: [sbml-comp] Query re validation of comp

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

Sorry guys - panic over

In fact the issue I was finding was due to the fact that an externalMD 
can point to a model that is not the main model of the source file.

Looks like I jumped the gun on this one.

I'll add some more tests for this horrible, horrible nightmare situation ;-)


Sarah

Re: [sbml-comp] Query re validation of comp

[Lucian S. <lp...@sp...>]

Yeah, it sounds like you found a bug in a flattening code.  I'll look 
into it.

-Lucian

* Chris J. Myers <my...@ec...> [2013-07-10 17:12] writes:
> Your example is a validation error.  If you want to reference an object within a submodel of a submodel, you must use recursive sBaseRefs or ports which handle the recursion.  Flattening should not be necessary.  Note though that the validation may need to be recursive though as a model may perhaps only be valid when all its submodels and their submodels etc. are valid.
> 
> Chris
> 
> On Jul 10, 2013, at 3:49 AM, Sarah Keating <ske...@ca...> wrote:
> 
> > Hi Guys
> > 
> > So I have a semantic issue with wording and interpretation:
> > 
> > Rule comp-20702:
> > 
> > The value of a comp:idRef attribute on an SBaseRef object must be the 
> > identifier of an
> > object contained in (that is, within the SId namespace of) the Model 
> > referenced by that
> > SBaseRef.
> > 
> > When it says Model I initially assumed it meant the actual <model> or 
> > <modelDefinition> element
> > 
> > but I'm getting the feeling that it perhaps means the "instantiation" of 
> > that Model.
> > 
> > (Indeed any of the rules relating to references to a referenced Model 
> > have this slight ambiguity).
> > 
> > Example
> > =======
> > 
> > My main model has a replacedElement with idRef="comp" subModelRef="A"
> > 
> > subModel A points to a modelDefinition that does NOT include an element 
> > with id="comp"
> > 
> > but it DOES include a submodel that points to another modelDefinition 
> > which does have an element with id = "comp"
> > 
> > ==========
> > 
> > So would validation report that there is no element with id="comp" in 
> > submodel A OR not.
> > 
> > My first thoughts were yes it would BUT flattening is still possible so 
> > I changed it so it does not.
> > 
> > NOTE: my validation code is attempting to solve the chicken and egg 
> > problem by performing validation WITHOUT flattening - as well as then 
> > flattening and validating the flat model.
> > 
> > Any thoughts/insights ?
> > 
> > Sarah
> > 
> > 
> > ------------------------------------------------------------------------------
> > See everything from the browser to the database with AppDynamics
> > Get end-to-end visibility with application monitoring from AppDynamics
> > Isolate bottlenecks and diagnose root cause in seconds.
> > Start your free trial of AppDynamics Pro today!
> > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> > _______________________________________________
> > sbml-comp mailing list
> > sbm...@li...
> > https://lists.sourceforge.net/lists/listinfo/sbml-comp
> 
> 
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> sbml-comp mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-comp

Re: [sbml-comp] Query re validation of comp

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

Your example is a validation error.  If you want to reference an object within a submodel of a submodel, you must use recursive sBaseRefs or ports which handle the recursion.  Flattening should not be necessary.  Note though that the validation may need to be recursive though as a model may perhaps only be valid when all its submodels and their submodels etc. are valid.

Chris

On Jul 10, 2013, at 3:49 AM, Sarah Keating <ske...@ca...> wrote:

> Hi Guys
> 
> So I have a semantic issue with wording and interpretation:
> 
> Rule comp-20702:
> 
> The value of a comp:idRef attribute on an SBaseRef object must be the 
> identifier of an
> object contained in (that is, within the SId namespace of) the Model 
> referenced by that
> SBaseRef.
> 
> When it says Model I initially assumed it meant the actual <model> or 
> <modelDefinition> element
> 
> but I'm getting the feeling that it perhaps means the "instantiation" of 
> that Model.
> 
> (Indeed any of the rules relating to references to a referenced Model 
> have this slight ambiguity).
> 
> Example
> =======
> 
> My main model has a replacedElement with idRef="comp" subModelRef="A"
> 
> subModel A points to a modelDefinition that does NOT include an element 
> with id="comp"
> 
> but it DOES include a submodel that points to another modelDefinition 
> which does have an element with id = "comp"
> 
> ==========
> 
> So would validation report that there is no element with id="comp" in 
> submodel A OR not.
> 
> My first thoughts were yes it would BUT flattening is still possible so 
> I changed it so it does not.
> 
> NOTE: my validation code is attempting to solve the chicken and egg 
> problem by performing validation WITHOUT flattening - as well as then 
> flattening and validating the flat model.
> 
> Any thoughts/insights ?
> 
> Sarah
> 
> 
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> sbml-comp mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-comp