> At the moment, the data stream output by implementing a SED-ML description
> is defined by the model variable targeted. It is not explicitly stated in
> the SED-ML file. Would-it be useful to constraint the type of output for
> instance as concentration or amount? This could use a SED-ML attribute, or
> terms from an external vocabulary such as SBO.
I'm not completely sure I understand what you are after here, so I'll
just work though it out loud, so to speak...
SED-ML links to a specific target in the model (xpath) and then,
possibly with some post-processing described in MathML, this is one
data stream output by implementing the experiment. Correct? And the
type is essentially the units of the data in the stream?
If I've got it wrong here, you should probably stop reading now.
At least for CellML models, the type of the output stream would be
completely defined if we could specify units on any parameters used in
the post-processing. I think we have discussed this briefly before,
but units in SED-ML are pretty much essential in my view. With the
addition of units, and assuming the target in the encoded model format
has its type well defined, then the type of the output is completely
specified. Although as you mention below, the SED-ML would need to
understand the model encoding format to be able to determine its
type....
> Of course the simulator(s) must know what the raw output is, and know how
> to transform it, which means a knowledge of the internal structure of the
> model encoding format. But this is required to run the simulation
> experiment anyway.
Typically, SED-ML tools simply hand over running the simulation to a
model encoding language specific tool - and I think this is the right
way to be handling things. As long as you have a simulation tool that
will take in the encoded model, numerical method, etc., a SED-ML tool
only needs to operate at the XML level without needing to understand
the model encoding format at all. To completely determine the type of
the output(s) you would also need to define in the SED-ML the type of
the target in the encoded model - either through the SED-ML units or
referring to the units definition in the encoded model. If you define
the units in SED-ML you'd then have to ask the simulation tool to
ensure that the target is converted to those units on output. This has
the advantage that the SED-ML doesn't need to understand the model
encoding format, but relies on SED-ML having a units system compatible
with all possible model encoding formats and the simulation tool being
able to perform the conversion (or to know that no conversion is
necessary). Some common conversions, concentration to amount for
example, require the use of additional parameters which may or may not
be present in the model being simulated and therefore the simulation
tool may not always be able to convert targets to the appropriate
type.
Which starts to suggest that the type of the target in the encoded
model is irrelevant, and it is up to the SED-ML author to declare the
target's type correctly in the SED-ML document. Or another way to look
at it, is that the author of the experiment needs to ensure they are
using a model that is compatible with what they want to do with it.
You can then define any post-processing required to convert types in
the experiment description and where possible link parameters used in
the conversion formulas back to the encoded model.
This then leads to making standard templates available for reuse which
define the mathematics of these common transformations as well as the
ports (?) for connecting the required parameters. This is something we
have been thinking about as part of best practices for modular
modelling, in terms of providing these kinds of templates (in CellML)
for use as intermediate models when combing multiple models together
that are based on different formalism's. Something to consider as part
of extending the capabilities of post-processing in SED-ML.
This issue in general is probably something we can discuss in
tomorrow's session at COMBINE if there is time.
Cheers,
David.
|
