Chronological Thread 

< Chronological >      < Thread >

---

Matt wrote:
> On 7/19/07, David Nickerson <david.nickerson at nus.edu.sg> wrote:
>>> Of course. And in the same sense you could simply delete the stimulus
>>> protocol component if you didn't want it. I think the issue is in fact a
>>> curation issue - we are specifying one of our curation 'levels' as
>>> "model is the same as is described in the paper." If there is a stimulus
>>> protocol that isn't in the paper in the CellML model, then this curation
>>> standard is invalidated. This is fine, as it (hopefully) moves the model
>>> up to the next 'level,' which requires that the model be able to produce
>>> the appropriate output, but doesn't necessarily require that the model
>>> be identical to that described in the paper. So the solution is that we
>>> should really have both.
>
> So there is validation in the sense that there is a true
> representation of a publication - which more often than not is pretty
> useless, and there is validation in the sense that the model can
> demonstrate what we think was intended by the publication (most
> obviously produces the right results) but perhaps many changes in the
> underlying formulation.
>
> Is it ok to only offer the former as a historical version?

I guess it depends if you define all versions that are not the most
recent version as 'historical.' What does historical mean here exactly?
But essentially, I think it's okay if it's noted in the model
documentation - perhaps a note on why the model won't run in a
simulator, and that this particular version might be better for
multicellular networks where the stimulus is externally defined? It's a
pretty simple matter to get a model to the point where it is complete
except for a stimulus protocol, upload it as version x, then add the
stimulus protocol and upload that as version y. To be honest, if people
are wanting to fiddle around with multicellular systems they probably
know what they're doing enough to be able to identify and delete an
extraneous stimulus component they don't want. The documentation will
identify it as 'foreign.'

and should
> it be necessary to actually do the former if we can easily see where
> the math needs to be written out differently?

Hmm, if it doesn't really take any effort to do, then the only reason
(besides the above,) I can think of not to do this, is that it just
creates extra versions that aren't particularly useful.

> _______________________________________________
> cellml-discussion mailing list
> cellml-discussion at cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

---

• [cellml-discussion] embedded stimulus currents in CellML models, (continued)
  • [cellml-discussion] embedded stimulus currents in CellML models, Alan Garny, 07/20/2007
  • [cellml-discussion] embedded stimulus currents in CellML models, James Lawson, 07/23/2007
  • [cellml-discussion] Using PCEnv 2.0, Ely Edison Matos, 07/26/2007
  • [cellml-discussion] Using PCEnv 2.0, Alan Garny, 07/26/2007
  • [cellml-discussion] Using PCEnv 2.0, James Lawson, 07/26/2007
  • [cellml-discussion] Using PCEnv 2.0, James Lawson, 07/26/2007
  • [cellml-discussion] embedded stimulus currents in CellML models, Alan Garny, 07/19/2007
  • [cellml-discussion] embedded stimulus currents in CellML models, James Lawson, 07/19/2007
    • [cellml-discussion] embedded stimulus currents in CellML models, David Nickerson, 07/19/2007
    • [cellml-discussion] embedded stimulus currents in CellML models, Matt , 07/19/2007
    • [cellml-discussion] embedded stimulus currents in CellML models, James Lawson, 07/20/2007
    • [cellml-discussion] embedded stimulus currents in CellML models, David Nickerson, 07/20/2007

---

Archive powered by MHonArc 2.6.18.