Chronological Thread 

< Chronological >      < Thread >

---

> -----Original Message-----
> From: cellml-discussion-bounces at cellml.org [mailto:cellml-discussion-
> bounces at cellml.org] On Behalf Of Lucian Smith
> Sent: 04 June 2010 00:17
> To: CellML Discussion List
> Subject: Re: [cellml-discussion] Fwd: [Fwd: Fwd: Curation flags]
>
> * Catherine Lloyd <c.lloyd at auckland.ac.nz> [2010-06-03 20:55] writes:
> > Hi Lucian
> >
> > Adding to that, I'll emphasise again that this list forms the bare
> > minimum and we will be happy to expand on the list in the future.
> > "validity" and "simulation" could be two areas which we choose to
> > expand on first - for example simulation in a specific named tool, etc.
>
> I think 'validity' probably isn't worth spending too much time on. If
it's not valid,
> there are probably a bajillion ways it can be invalid, and the actual
'this file is
> invalid on line 3 because...' message you get from the API is probably
more
> valuable than trying to classify all the invalidity error messages into
curatable
> groups. (Though perhaps 'the model is overspecified' might be a handy
> particular thing to know? And maybe it wouldn't be too hard to say 'the
model
> is syntactically invalid'
> vs 'the model is semantically invalid'?)

With regards to the flags, it would clearly be good to know, at a glance,
whether a model is valid or not. However, it would also be good (upon
clicking some kind of a link?) to know what are the issues that make a model
invalid.

> However, 'simulation' probably *is* a more productive area in which to
> expand--if you could tell, in general, what kind of math techniques a
model
> needed to be simulated, you could tell if your simulator
> (/translator) could handle those techniques. ODE's, PDE's, algebraic
rules, etc.

+1, though we could also list the environments that we know can solve the
model. Again, that might be the kind of information that one could get upon
clicking some kind of a link (or, maybe better, by hovering the flag)?

Otherwise:
- "Is the model encoded in a public, standardized, machine-readable
format?": are we just talking about CellML or also FieldML, SBML, etc.? This
is not clear to me. I get the impression that you are talking about any kind
of standard, which is fine but I would like to be able to know, at a glance,
the format in which a model is encoded.
- "Are the date and time of creation and last modification specified?": you
have included a comment asking whether "we want to make model history
obligatory?" Personally, I think we do. In fact, I was going to ask for it
before I saw your comment.
- As a general rule, should the answer to any particular question be
negative, it would then be good to be able to click on the 'negative flag'
and be directed to a page that contains some information on what the
'problem(s)' is/are.
- "NOTE: The above detailed set of curation flags will need to be condensed
into 3 summary glyphs visable next to the model name on the exposure
listing.": personally, the 3 summary glyphs I would like to see is the
format in which the model is encoded, whether the encoding is valid, and
whether the model reproduces published results.

Finally, there are a few typos in your Excel document... :)

Alan

---

• [cellml-discussion] Fwd: [Fwd: Fwd: Curation flags], Catherine Lloyd, 06/04/2010
  • [cellml-discussion] Fwd: [Fwd: Fwd: Curation flags], Lucian Smith, 06/04/2010
    • [cellml-discussion] Fwd: [Fwd: Fwd: Curation flags], Catherine Lloyd, 06/04/2010
      • [cellml-discussion] Fwd: [Fwd: Fwd: Curation flags], Lucian Smith, 06/04/2010
        • [cellml-discussion] Fwd: [Fwd: Fwd: Curation flags], Alan Garny, 06/04/2010
          • [cellml-discussion] Fwd: [Fwd: Fwd: Curation flags], Catherine Lloyd, 06/04/2010

---

Archive powered by MHonArc 2.6.18.