Chronological Thread 

< Chronological >      < Thread >

---

>> The only issue with this is what happens when you upload models into
>> the repository (the relative URIs would need to remain consistent with
>> what is in the model, or alternatively, we would need to modify the
>> URIs).

I don't think anyone has yet come up with a solution for uploading
CellML 1.1 models into the repository. If we follow the naming
convention then all the submodels in a 1.1 model become parts of the top
level model. And then I'm not sure how to handle different top level
models for the same base model - i.e., all the different simulations
performed to create/validate a given model are all going to be different
top level models that import the mathematics from the base model and
apply different boundary/initial conditions.

I my current models, I have a directory for each model. In that
directory I have the base model(s) for that model - i.e., model(s) that
simply import all the appropriate component submodels and connect them
together (there can be more than one base model if a given article
describes different variants of a model that are more than simple
parameter changes, such as different ion channel representations). Then
there is a components directory which contains all the components of the
model - this is where the math gets defined as well as some
encapsulation. In this directory I currently give each component a
meaningful english name, which generally matches the model's name
attribute. As well as a components directory I have an experiments
directory. In the experiments directory are all the models that provide
the boundary/initial conditions for running various simulations. These
models may import one or more of the components directly (to perform
voltage clamp experiments on single channels, for example) or work with
one of the main base models (e.g., applying a periodic stimulus to the
cell). For example:

2004_tenTusscher:
2004_tenTusscher_noble_noble_panfilov-endo.xml
2004_tenTusscher_noble_noble_panfilov-M.xml
2004_tenTusscher_noble_noble_panfilov-epi.xml

components/
Cai.xml IbNa.xml IK1.xml IKs.xml INaK.xml IpCa.xml
Ito-components.xml Ito-epi.xml Jleak.xml Jup.xml Nai.xml
IbCa.xml ICaL.xml IKr.xml INaCa.xml INa.xml IpK.xml
Ito-endo.xml Ito-M.xml Jrel.xml Ki.xml
experiments/
INa_gates-voltage_clamp.xml periodic-stimulus-M.xml
single-stimulus-erpicardial.xml ICaL_gates-calcium_clamp.xml
Ito_gates-voltage_clamp-endo.xml ICaL_gates-voltage_clamp.xml
Ito_gates-voltage_clamp-epi.xml IKr_gates-voltage_clamp.xml

I the past when this has come up, I think we have always thought that
the model repository would be a flat structure and all the various
components of a CellML 1.1 model would be renamed when you upload such
models into the repository, basically using the _partXX suffix to give
each component model a unique filename. This results in quite a mess of
files and pretty much makes it impossible to manually work out what a
given part of a model represents based solely on the URI for that model.
Thus it then becomes critical to have a decent query interface to the
repository so that when I want to import the fast sodium channel from
the 2004 ten Tusscher human ventricular model into my current model I
don't need to browse through all the different parts looking for the
appropriate component (of course there are all sorts of other parameters
for such queries like curation level, authors, etc.). I'm guessing that
as both software and the model repository develop we're going to be
wanting to use such query based imports - which will all be nicely
hidden away and resolved into appropriate URI's for when the the model
imports are instantiated.

> Revision 706 will now use relative URIs when you call instantiate, since
> this seems to correspond to what the CellML specification requires (it
> even has an example with a relative URI in it). I don't strictly follow
> the procedure from RFC3986 for resolving relative URLs, because we don't
> currently have a URL parser in the CellML API. However, the procedure
> used should produce identical results for URLs with no query or fragment
> on the end (which doesn't make sense for CellML models anyway).

Hopefully the above shows that, at least in my mind, query based URL's
do make sense when importing models from the model repository. To what
extent they are hidden from the user/application developer remains to be
seen. And not that such functionality is currently required (or
expected) from the CellML API implementation.


David.

--
David Nickerson, PhD
Research Fellow
Division of Bioengineering
Faculty of Engineering
National University of Singapore
Email: david.nickerson at nus.edu.sg

---

• [cellml-discussion] [team-cellml] Linux functional test build of PCEnv available, Andrew Miller, 10/02/2006
  • [cellml-discussion] [team-cellml] Linux functional test buildof PCEnv available, David Nickerson, 10/02/2006
    • [cellml-discussion] [team-cellml] Linux functional test buildof PCEnv available, Andrew Miller, 10/02/2006
      • [cellml-discussion] [team-cellml] Linux functional test buildofPCEnv available, David Nickerson, 10/02/2006
        • [cellml-discussion] [team-cellml] Linux functional test buildofPCEnv available, Andrew Miller, 10/02/2006
          • [cellml-discussion] [team-cellml] Linux functional testbuildofPCEnv available, David Nickerson, 10/04/2006
            • [cellml-discussion] [team-cellml] Linux functional testbuildofPCEnv available, Andrew Miller, 10/04/2006
              • [cellml-discussion] [team-cellml] Linux functionaltestbuildofPCEnv available, David Nickerson, 10/04/2006

---

Archive powered by MHonArc 2.6.18.