Re: stoichiometries of modifiers
29 Apr '05 15:15
Darren Wilkinson wrote:
> Now there isn't anything wrong with this, and this is exactly how I
> would code it (I currently avoid the use of modifiers, as they don't
> have stoichiometries...). However, if you think about how that would
> typically visualise in a visualisation tool, it is a bit clumsy,
> because it wouldn't really capture very clearly that fact that E is
> conserved. So, it might be neater to write this as
> X -> Y (modified by E with a stoichiometry of 1)
> Because _in_some_sense_, E is neither created or destroyed, and can
> therefore reasonably be regarded as a modifier (please let's not get
> into a philisophical discussion about the "true" nature of
> modifiers...). This captures the same information as the previous
> reaction, but will visualise more appropriately in many tools.
If this is only a visualization problem, you can always keep the long
complex formation notation in SBML and then at the visualization layer
you can do something about it. If things are that simple, then it should
be a no brainer. PATIKA for example goes to a great length to be able to
manage complexity at the visualization layer. No one will scream at
anyone for putting a nice 2 on a modifier edge in visualization layer.
However when you want to introduce ambigous abstractions for the sake of
visual brevity and at the cost of your fellow SBML parser programmer,
chances are they won't like it at all..