Re: [cellml-discussion] embedded stimulus currents in CellML models

[Matt]

On 7/19/07, David Nickerson <[EMAIL PROTECTED]> 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? and should
it be necessary to actually do the former if we can easily see where
the math needs to be written out differently?
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] CellML 1.1.1 specification

[Matt]

>
> It seems there is some misunderstanding as to whether we are discussing
> a proposal to remove the reaction element from CellML or a proposed new
> specification. I thought it was the latter but you seem to be talking
> about the former...


Both. I think.

So I will try another explanation.

If we had our specification in a version control system and tagged out
releases and release candidates etc, and if we followed a protocol of
releasing at least one stable minor release that marks depreciation
only, then the following would be the result (in my mind)

- The current trunk is the development version of cellml 1.2 (i.e.
unreleased-dev).
- This current trunk look likes CellML 1.1 and the associated
definitions in DTDs etc.
- We update this to mark out that reaction elements are going to be
depreciated, this includes comments in DTDs etc. We don't remove
reaction elements from the specification at this stage because that's
where we hang the depreciation notices.
- We tag this as 1.1.1 and release it
- We then delete reaction elements from the specification that is on trunk.

Now, this is the kind of process I think covers the steps you have
been talking about and at the end makes available a trunk version of
1.2-dev-unreleased that doesn't have reaction elements that people can
check out an play with (this is essentially the proposal page the
Andrew wrote up - though I think there are issues remaining now with
the absence of biology from a "Cell" ML standard.

But what I am also saying is that this is still just an idea, so it
should be put forward as a proposal that has not been accepted. I.e.
that the steps I described above are purely hypothetical at the
moment, since we haven't had the chance to hear arguments from people
about it - it might turn out to be a silly proposal.

cheers
Matt
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] CellML 1.1.1 specification

[David Nickerson]

> I'm not pretending to understand the CellML version numbering system,
> but to serve as an example, would you be suggesting that changes such
> as removing a reaction element are a proposal for a future say 1.2
> versions where the namespace is changed?

yes. assuming there is a 1.1.1 (or 1.1a) specification as outlined by Poul.

> Also, if there is something we call the proposal to remove reaction
> elements, I think there needs to be a way to present what the formal
> normative specification would look like if that were the case: which
> is the current 1.1 minus the reaction element and the associated DTD
> and Schema that represent these. The reason for this is that is we
> want to write a test implementation of this proposal, we want to be
> sure that by only using what information there is in that proposal
> that we indeed have enough to implement what we intended. I just don't
> know what to call this - is it 1.2a1, is it 1.1.1, is it
> 1.1-branch-reactions-removed?

wouldn't this simply be the implementation of the draft 1.2 
specification? The same as when we went from 1.0 to 1.1

> I think we agree that a proposal to remove reactions in warranted, I
> think we need to figure out how we publish the draft specification
> that would represent this.

a proposal to remove the reaction element is just one potential 
candidate for inclusion in the next revision of the CellML 
specification. Things like simple variable typing may also be worth 
considering in a 1.2 version.

> I think depreciation warnings are important, but don't form the core
> of the actual proposal - they sit at some level that goes with
> whatever it is that governs new version numbers and the notices we
> provide with those.

right - and the thing that governs this is the specification, isn't it? 
the deprecation notice is nothing to do with a proposal to remove the 
reaction element, it is one of the steps that must be gone through in 
order to achieve the desired goal of the proposal.

It seems there is some misunderstanding as to whether we are discussing 
a proposal to remove the reaction element from CellML or a proposed new 
specification. I thought it was the latter but you seem to be talking 
about the former...
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] CellML 1.1.1 specification

[David Nickerson]

Hi Poul,

That makes sense to me - although I would call it 1.1.1 rather than 1.1a 
which to me implies an alpha pre-release of 1.1.


Andre.

Poul Nielsen wrote:
> Dear all
> 
> I think that we are in agreement about the need to signal to the  
> CellML community that the reaction element is deprecated. As I  
> mentioned at the CellML meeting, I favour doing this by formally  
> indicating so in the specification. I appreciate that some would like  
> to move quickly on this issue by releasing a new version of CellML  
> that has all references to the reaction element removed. I also agree  
> with Andre that we need to be careful about suddenly removing a  
> feature without having at least one specification release indicating  
> our intention to do so. I would like to suggest that we try to  
> resolve this issue by releasing a CellML 1.1a specification identical  
> to the CellML 1.1 specification except that the 1.1a specification is  
> annotated with a clear statement that the reaction element is  
> deprecated and can be expected to be removed in future versions. Both  
> specifications will operate under the same 1.1 namespace because they  
> are functionally identical. It seems to me that this approach will  
> satisfy both ends of the spectrum - CellML users are given a clear  
> notice of our intentions while, for the interim, the specification  
> remains unchanged.
> 
> Best wishes
> Poul
> 
> On 2007 Jul 19, at 16:19, David Nickerson wrote:
> 
>>> I think that we disagree about how the specification process  
>>> should work
>>> and what it aims to address. I see a given version of a CellML
>>> specification as being a 'protocol' which both tools and model  
>>> authors
>>> speak, therefore allowing them to interwork.
>> All I'm trying to point out is that in the vast majority of XML/SGML
>> based standards in use today, including ones from the W3C as well as
>> SBML, elements are marked as deprecated before they are made obsolete
>> and removed from the specification. I don't see how this can be  
>> seen to
>> be acting as a tutorial or newsletter?
>>
>>> In my view, it is inappropriate for specifications to act like either
>>> tutorials or newsletters (a small amount of such editorial  
>>> material may
>>> be appropriate and useful in some cases, but it should not detract  
>>> from
>>> the primary goal of the specification, which is to provide a  
>>> normative
>>> definition of that particular version of CellML).
>> yes - such as indicating that a particular element is known to have  
>> been
>> superseded by some new and better feature and that the element will be
>> phased out in some future version of the specification.
>>
>>> If IETF believes that it is okay to remove features simply be removed
>>> because they have never been implemented, then certainly we should at
>>> least allow them to be removed if they are not only poorly  
>>> implemented
>>> but also a bad fit conceptually.
>> While I agree that the reaction element should be removed and I am
>> certainly not trying to say that it should never be removed, I am just
>> saying that the way you are proposing to do this is not setting the
>> right kind of precedence for the way we want to evolve CellML.
>>
>> I also think you will find strong disagreement from the SBML community
>> on how reactions are poorly implemented reactions.
>>
>>
>>
>> Andre.
>> ___
>> cellml-discussion mailing list
>> cellml-discussion@cellml.org
>> http://www.cellml.org/mailman/listinfo/cellml-discussion
> 
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

-- 
David Nickerson, PhD
Research Fellow
Division of Bioengineering
Faculty of Engineering
National University of Singapore
Email: [EMAIL PROTECTED]
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] CellML 1.1.1 specification

[Poul Nielsen]

Dear all

I think that we are in agreement about the need to signal to the  
CellML community that the reaction element is deprecated. As I  
mentioned at the CellML meeting, I favour doing this by formally  
indicating so in the specification. I appreciate that some would like  
to move quickly on this issue by releasing a new version of CellML  
that has all references to the reaction element removed. I also agree  
with Andre that we need to be careful about suddenly removing a  
feature without having at least one specification release indicating  
our intention to do so. I would like to suggest that we try to  
resolve this issue by releasing a CellML 1.1a specification identical  
to the CellML 1.1 specification except that the 1.1a specification is  
annotated with a clear statement that the reaction element is  
deprecated and can be expected to be removed in future versions. Both  
specifications will operate under the same 1.1 namespace because they  
are functionally identical. It seems to me that this approach will  
satisfy both ends of the spectrum - CellML users are given a clear  
notice of our intentions while, for the interim, the specification  
remains unchanged.

Best wishes
Poul

On 2007 Jul 19, at 16:19, David Nickerson wrote:

>> I think that we disagree about how the specification process  
>> should work
>> and what it aims to address. I see a given version of a CellML
>> specification as being a 'protocol' which both tools and model  
>> authors
>> speak, therefore allowing them to interwork.
>
> All I'm trying to point out is that in the vast majority of XML/SGML
> based standards in use today, including ones from the W3C as well as
> SBML, elements are marked as deprecated before they are made obsolete
> and removed from the specification. I don't see how this can be  
> seen to
> be acting as a tutorial or newsletter?
>
>> In my view, it is inappropriate for specifications to act like either
>> tutorials or newsletters (a small amount of such editorial  
>> material may
>> be appropriate and useful in some cases, but it should not detract  
>> from
>> the primary goal of the specification, which is to provide a  
>> normative
>> definition of that particular version of CellML).
>
> yes - such as indicating that a particular element is known to have  
> been
> superseded by some new and better feature and that the element will be
> phased out in some future version of the specification.
>
>> If IETF believes that it is okay to remove features simply be removed
>> because they have never been implemented, then certainly we should at
>> least allow them to be removed if they are not only poorly  
>> implemented
>> but also a bad fit conceptually.
>
> While I agree that the reaction element should be removed and I am
> certainly not trying to say that it should never be removed, I am just
> saying that the way you are proposing to do this is not setting the
> right kind of precedence for the way we want to evolve CellML.
>
> I also think you will find strong disagreement from the SBML community
> on how reactions are poorly implemented reactions.
>
>
>
> Andre.
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] CellML 1.1.1 specification

[Matt]

Hi Andre,

I'm not pretending to understand the CellML version numbering system,
but to serve as an example, would you be suggesting that changes such
as removing a reaction element are a proposal for a future say 1.2
versions where the namespace is changed?

Also, if there is something we call the proposal to remove reaction
elements, I think there needs to be a way to present what the formal
normative specification would look like if that were the case: which
is the current 1.1 minus the reaction element and the associated DTD
and Schema that represent these. The reason for this is that is we
want to write a test implementation of this proposal, we want to be
sure that by only using what information there is in that proposal
that we indeed have enough to implement what we intended. I just don't
know what to call this - is it 1.2a1, is it 1.1.1, is it
1.1-branch-reactions-removed?

I think we agree that a proposal to remove reactions in warranted, I
think we need to figure out how we publish the draft specification
that would represent this.

I think depreciation warnings are important, but don't form the core
of the actual proposal - they sit at some level that goes with
whatever it is that governs new version numbers and the notices we
provide with those.

cheers
Matt


On 7/19/07, David Nickerson <[EMAIL PROTECTED]> wrote:
> > I think that we disagree about how the specification process should work
> > and what it aims to address. I see a given version of a CellML
> > specification as being a 'protocol' which both tools and model authors
> > speak, therefore allowing them to interwork.
>
> All I'm trying to point out is that in the vast majority of XML/SGML
> based standards in use today, including ones from the W3C as well as
> SBML, elements are marked as deprecated before they are made obsolete
> and removed from the specification. I don't see how this can be seen to
> be acting as a tutorial or newsletter?
>
> > In my view, it is inappropriate for specifications to act like either
> > tutorials or newsletters (a small amount of such editorial material may
> > be appropriate and useful in some cases, but it should not detract from
> > the primary goal of the specification, which is to provide a normative
> > definition of that particular version of CellML).
>
> yes - such as indicating that a particular element is known to have been
> superseded by some new and better feature and that the element will be
> phased out in some future version of the specification.
>
> > If IETF believes that it is okay to remove features simply be removed
> > because they have never been implemented, then certainly we should at
> > least allow them to be removed if they are not only poorly implemented
> > but also a bad fit conceptually.
>
> While I agree that the reaction element should be removed and I am
> certainly not trying to say that it should never be removed, I am just
> saying that the way you are proposing to do this is not setting the
> right kind of precedence for the way we want to evolve CellML.
>
> I also think you will find strong disagreement from the SBML community
> on how reactions are poorly implemented reactions.
>
>
>
> Andre.
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion
>
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] CellML version interoperability strategy

[Andrew Miller]

David Nickerson wrote:
>> I think that we disagree about how the specification process should work 
>> and what it aims to address. I see a given version of a CellML 
>> specification as being a 'protocol' which both tools and model authors 
>> speak, therefore allowing them to interwork.
>> 
>
> All I'm trying to point out is that in the vast majority of XML/SGML 
> based standards in use today, including ones from the W3C as well as 
> SBML, elements are marked as deprecated before they are made obsolete 
> and removed from the specification. I don't see how this can be seen to 
> be acting as a tutorial or newsletter?
>   

I think it partly depends on whether a specification aims to include all 
prior versions of the specification or not. Historically, support for a 
version of CellML has not included support for the previous version of 
CellML. Under such a regime, there is an implicit requirement to support 
multiple versions of CellML anyway, which makes the need to go through a 
deprecation phase unnecessary (compare with, for example, the HTML 
specification. Implementation of HTML4 will automatically cause a user 
agent to support all previous versions of HTML, hence the need for 
deprecation).

>   
>> In my view, it is inappropriate for specifications to act like either 
>> tutorials or newsletters (a small amount of such editorial material may 
>> be appropriate and useful in some cases, but it should not detract from 
>> the primary goal of the specification, which is to provide a normative 
>> definition of that particular version of CellML).
>> 
>
> yes - such as indicating that a particular element is known to have been 
> superseded by some new and better feature and that the element will be 
> phased out in some future version of the specification.
>   

It would be useful to draw attention to the changes regarding the 
reaction element, although we probably don't want to put any normative 
text about what to replace it with in the specification, because that 
would be harmful to the separation of metadata from the core specification.

>   
>> If IETF believes that it is okay to remove features simply be removed 
>> because they have never been implemented, then certainly we should at 
>> least allow them to be removed if they are not only poorly implemented 
>> but also a bad fit conceptually.
>> 
>
> While I agree that the reaction element should be removed and I am 
> certainly not trying to say that it should never be removed, I am just 
> saying that the way you are proposing to do this is not setting the 
> right kind of precedence for the way we want to evolve CellML.
>   

There are two ways of developing specifications while still remaining 
some interoperability between tools built at different times:
1) Define new versions which don't aim to be compatible with earlier 
versions, but state that tool implementors should implement the older 
version as well as the new version.
2) Build some compatibility mechanisms into the specification, such that 
by implementing a given version of the specification you are also 
implicitly creating compatibility with older versions.

The existing precedent for CellML is strategy 1 above (e.g. CellML 1.1 
used a completely different namespace to CellML 1.0, and CellML 1.1 
doesn't say that tools should accept documents in the CellML 1.0 namespace).

I believe that the way 1.1.1 is defined is compatible with the 
historical precedent to use strategy 1. I feel that what you are asking 
for is something that makes sense under strategy 2.

If we want to adopt 'strategy 2' for CellML, then I have no objection, 
but we should make it absolutely explicit that we are doing this, that 
it is a change from how we have operated in the past, and ensure that 
everyone understands that is what we are discussing. A consequence of 
this would probably be that CellML 1.2 needs to define what CellML 1.2 
compliant tools should accept from the CellML 1.0 and CellML 1.1 namespaces.

Best regards,
Andrew

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] CellML 1.1.1 specification

[David Nickerson]

> I think that we disagree about how the specification process should work 
> and what it aims to address. I see a given version of a CellML 
> specification as being a 'protocol' which both tools and model authors 
> speak, therefore allowing them to interwork.

All I'm trying to point out is that in the vast majority of XML/SGML 
based standards in use today, including ones from the W3C as well as 
SBML, elements are marked as deprecated before they are made obsolete 
and removed from the specification. I don't see how this can be seen to 
be acting as a tutorial or newsletter?

> In my view, it is inappropriate for specifications to act like either 
> tutorials or newsletters (a small amount of such editorial material may 
> be appropriate and useful in some cases, but it should not detract from 
> the primary goal of the specification, which is to provide a normative 
> definition of that particular version of CellML).

yes - such as indicating that a particular element is known to have been 
superseded by some new and better feature and that the element will be 
phased out in some future version of the specification.

> If IETF believes that it is okay to remove features simply be removed 
> because they have never been implemented, then certainly we should at 
> least allow them to be removed if they are not only poorly implemented 
> but also a bad fit conceptually.

While I agree that the reaction element should be removed and I am 
certainly not trying to say that it should never be removed, I am just 
saying that the way you are proposing to do this is not setting the 
right kind of precedence for the way we want to evolve CellML.

I also think you will find strong disagreement from the SBML community 
on how reactions are poorly implemented reactions.



Andre.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] CellML 1.1.1 specification

[Andrew Miller]

David Nickerson wrote:
>> Correct me if I am wrong, but I believe that nothing in the text of the 
>> CellML 1.1 specification says that reactions will or will not be 
>> deprecated in any future version of CellML, and therefore there is no 
>> need for an erratum to CellML 1.1 (and indeed, such an erratum would be 
>> inappropriate).
>> 
>
> exactly, and as a core element with an entire top level section of the 
> 1.0 and 1.1 specifications devoted to it and with no annotation to state 
> that it is not going to be around much longer it is reasonable to expect 
> that the reaction element will remain in the next version of the 
> specification.
>
> To have the reaction element go from a significant core element in 1.0 
> and 1.1 to obsolete in 1.1.1 with no formal deprecation step just seems 
> wrong to me - maybe I'm the only one that sees any problems here?
>
> While the reaction element is obviously one that we want to get rid of, 
> what kind of precedence are we setting for the evolution of CellML by 
> simply deleting it with nothing more formal than saying its about time 
> we tidied up that mess?
>   
Hi Andre,

I think that we disagree about how the specification process should work 
and what it aims to address. I see a given version of a CellML 
specification as being a 'protocol' which both tools and model authors 
speak, therefore allowing them to interwork.

In my view, it is inappropriate for specifications to act like either 
tutorials or newsletters (a small amount of such editorial material may 
be appropriate and useful in some cases, but it should not detract from 
the primary goal of the specification, which is to provide a normative 
definition of that particular version of CellML).

Tools are encouraged to process multiple versions of CellML (section 4.1 
of RFC4708  says that  "As 
efforts are made to keep the number of specific formats small, user 
agents SHOULD implement all specific formats listed in the CellML 
Umbrella Format Registry at the time they were developed."). Therefore, 
tools will continue to support reaction elements for as long as they 
decide they want to support CellML 1.1 (and 1.0).

I  think that deleting things from newer specifications is common, and 
indeed, the IETF process, which has given rise to most good quality 
protocols in use on the Internet today, calls for unused features to be 
deleted prior to something becoming a draft standard: section 4.1.2 of 
RFC2026 
"

   The requirement for at least two independent and interoperable
   implementations applies to all of the options and features of the
   specification.  In cases in which one or more options or features
   have not been demonstrated in at least two interoperable
   implementations, the specification may advance to the Draft Standard
   level only if those options or features are removed.

"

If IETF believes that it is okay to remove features simply be removed 
because they have never been implemented, then certainly we should at 
least allow them to be removed if they are not only poorly implemented 
but also a bad fit conceptually.

Best regards,
Andrew

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] CellML 1.1.1 specification

[David Nickerson]

> Correct me if I am wrong, but I believe that nothing in the text of the 
> CellML 1.1 specification says that reactions will or will not be 
> deprecated in any future version of CellML, and therefore there is no 
> need for an erratum to CellML 1.1 (and indeed, such an erratum would be 
> inappropriate).

exactly, and as a core element with an entire top level section of the 
1.0 and 1.1 specifications devoted to it and with no annotation to state 
that it is not going to be around much longer it is reasonable to expect 
that the reaction element will remain in the next version of the 
specification.

To have the reaction element go from a significant core element in 1.0 
and 1.1 to obsolete in 1.1.1 with no formal deprecation step just seems 
wrong to me - maybe I'm the only one that sees any problems here?

While the reaction element is obviously one that we want to get rid of, 
what kind of precedence are we setting for the evolution of CellML by 
simply deleting it with nothing more formal than saying its about time 
we tidied up that mess?


Andre.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] CellML 1.1.1 specification

[Andrew Miller]

David Nickerson wrote:
> Andrew Miller wrote:
>   
>> David Nickerson wrote:
>> 
 From what I gather, publicity. We need some way to direct people's
 attention to our intention to deprecate reaction elements.
 
 
>>> sure - but its still not clear to me if 1.1.1 is making clear our 
>>> intention to deprecate reaction elements or if it is making reaction 
>>> elements invalid in a 1.1.1 version model?
>>>   
>>>   
>> I think that both are true:
>> 1) Reaction elements would be invalid in the 1.1.1 specification I proposed.
>> 2) Versions of CellML earlier than 1.1.1 would be deprecated by virtue 
>> of the fact that they are no longer the latest version of CellML, and 
>> therefore reaction elements are deprecated.
>> 
>
> but neither of these address our "intention to deprecate" the reaction 
> element.
>   

I don't really understand what you are trying to say. How does releasing 
a new version which does not contain the reaction element not show an 
intention that the reaction element be deprecated)?

>   
>> I think that people who look at CellML at present are not sufficiently 
>> discouraged from using reaction elements, and I agree that a new version 
>> is reasonable to publicise what we as a community think is the proper 
>> direction for CellML.
>> 
>
> just to reiterate, when raising the issue of marking the reaction 
> element for deprecation in the final 1.1 specification the decision was 
> made to not do so and at the time it was also decided that the next 
> version of cellml would be the one to formally mark the reaction element 
> for deprecation. If this decision has been revisited and found in error, 
> then the errata for the 1.1 specification should be updated to reflect that.
>   

Errata are primarily there to correct errors in the specification, not 
errors in the process by which the specification arose, or to make 
substantive changes to the specification.

Correct me if I am wrong, but I believe that nothing in the text of the 
CellML 1.1 specification says that reactions will or will not be 
deprecated in any future version of CellML, and therefore there is no 
need for an erratum to CellML 1.1 (and indeed, such an erratum would be 
inappropriate).

Best regards,
Andrew

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] [TrackerItem 42]New: CellML1.1.1specification

[David Nickerson]

Andrew Miller wrote:
> David Nickerson wrote:
>>> From what I gather, publicity. We need some way to direct people's
>>> attention to our intention to deprecate reaction elements.
>>> 
>> sure - but its still not clear to me if 1.1.1 is making clear our 
>> intention to deprecate reaction elements or if it is making reaction 
>> elements invalid in a 1.1.1 version model?
>>   
> 
> I think that both are true:
> 1) Reaction elements would be invalid in the 1.1.1 specification I proposed.
> 2) Versions of CellML earlier than 1.1.1 would be deprecated by virtue 
> of the fact that they are no longer the latest version of CellML, and 
> therefore reaction elements are deprecated.

but neither of these address our "intention to deprecate" the reaction 
element.

> I think that people who look at CellML at present are not sufficiently 
> discouraged from using reaction elements, and I agree that a new version 
> is reasonable to publicise what we as a community think is the proper 
> direction for CellML.

just to reiterate, when raising the issue of marking the reaction 
element for deprecation in the final 1.1 specification the decision was 
made to not do so and at the time it was also decided that the next 
version of cellml would be the one to formally mark the reaction element 
for deprecation. If this decision has been revisited and found in error, 
then the errata for the 1.1 specification should be updated to reflect that.


___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] [TrackerItem 42]New: CellML1.1.1specification

[Andrew Miller]

David Nickerson wrote:
>> From what I gather, publicity. We need some way to direct people's
>> attention to our intention to deprecate reaction elements.
>> 
>
> sure - but its still not clear to me if 1.1.1 is making clear our 
> intention to deprecate reaction elements or if it is making reaction 
> elements invalid in a 1.1.1 version model?
>   

I think that both are true:
1) Reaction elements would be invalid in the 1.1.1 specification I proposed.
2) Versions of CellML earlier than 1.1.1 would be deprecated by virtue 
of the fact that they are no longer the latest version of CellML, and 
therefore reaction elements are deprecated.

I think that people who look at CellML at present are not sufficiently 
discouraged from using reaction elements, and I agree that a new version 
is reasonable to publicise what we as a community think is the proper 
direction for CellML.

Best regards,
Andrew

> If it is the former, then I guess the publicity side of things makes a 
> new version reasonable.
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion
>   

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] [TrackerItem 42]New: CellML1.1.1specification

[David Nickerson]

> From what I gather, publicity. We need some way to direct people's
> attention to our intention to deprecate reaction elements.

sure - but its still not clear to me if 1.1.1 is making clear our 
intention to deprecate reaction elements or if it is making reaction 
elements invalid in a 1.1.1 version model?

If it is the former, then I guess the publicity side of things makes a 
new version reasonable.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] embedded stimulus currents in CellML models

[David Nickerson]

> 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.

its also worth pointing out that, at least for electrophysiology models, 
most articles will be applying several different stimulus protocols as 
well as things like current and voltage clamps. In general, no single 
CellML 1.0 model can represent all these - unless you duplicate the 
mathematical model several times and have different bound variables in 
different parts of the model.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] embedded stimulus currents in CellML models

[David Nickerson]

> It would definitely be cool to get some basic documentation for these
> tools. If you have a go at installing CellML2Dot in Linux Alan, let me
> know. I'd like to see Andre's simulator too. How does it differ from
> PCEnv or COR Andre?

its quite different in that it has no GUI at all - it is a command line 
only application that simply processes my analysis metadata, cellml 
graphing metadata, and cellml simulation metadata to determine what 
simulations need to be run to produce the data required for the defined 
graphs and any analysis the user wants to perform. It uses the CellML 
API and CCGS to generate C code from CellML 1.1 models.

There is no restriction to linux, as all the libraries I use are 
available on a whole bunch of platforms (I think?), including Windows 
and Macs...not that I have tried to build the tools under anything other 
than Linux :-)
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] information_cellml_simulator

[James Lawson]

This is the email I sent him:

Dear Danilo,

My name is James Lawson, I am the curator of the CellML.org repository
of models. If you have any questions whatsoever about any of the models,
or how to simulate them, please let me know. I am at your service.

First I think you will need to download either PCEnv or COR. I would
think that COR would be more suited to your needs. You can download COR
for free from http://cor.physiol.ox.ac.uk/ although it only runs in
Windows. If you have a Linux system, you will need to get PCEnv, from
http://www.cellml.org/tools/pcenv/
You can download the binary, unzip it, and simply run the pcenv script
to load the program.

Once you have installed a simulator, please select a model from
www.cellml.org/models and download it by clicking 'standard' at the top
of the model page, under 'download options.'

You can then open the model in the simulator and integrate it. You may
want to read the documentation in 'help' for COR or PCEnv.

Most of our major cardiac electrophysiology models are well curated. Not
all of the models in the repository work, however. Please feel free to
ask any questions you have.

I wish you the best of luck.

Kind regards,
James Lawson

James Lawson wrote:
> I'm going to email this gentleman and help him out on a more intimate
> basis.
> 
> Andrew Miller wrote:
>> danilo roman wrote:
>>> Dear all
>>> I'm a master student at federal university of minas gerais, Brazil. 
>>> Actually I've carried out some research at cardiomyocyte 
>>> electrophysiology under supervision of Prof Jader dos Santos Cruz. In 
>>> our lab, we're interesting in use the cellml files in order to 
>>> simulate some action potentials and currents. So that I'd like to 
>>> request a log in to use the cellml online simulator.
>> Hi Danilo,
>>
>> There are several CellML simulators available. The one I develop is 
>> called PCEnv (which is a combined model authoring and simulation 
>> environment). PCEnv is an open source application which you can freely 
>> download and install onto your computer from 
>> http://www.cellml.org/downloads/pcenv/releases (simulations run on your 
>> own computer, so you don't need to log in anywhere).
>>
>> For a list of other simulator software, please see 
>> http://www.cellml.org/tools/ . Some of these program send simulations to 
>> run on remote servers,  although I am not aware of any of them requiring 
>> accounts for normal use.
>>
>> Best regards,
>> Andrew Miller
>>
>> ___
>> cellml-discussion mailing list
>> cellml-discussion@cellml.org
>> http://www.cellml.org/mailman/listinfo/cellml-discussion
> 
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] information_cellml_simulator

[James Lawson]

I'm going to email this gentleman and help him out on a more intimate
basis.

Andrew Miller wrote:
> danilo roman wrote:
>> Dear all
>> I'm a master student at federal university of minas gerais, Brazil. 
>> Actually I've carried out some research at cardiomyocyte 
>> electrophysiology under supervision of Prof Jader dos Santos Cruz. In 
>> our lab, we're interesting in use the cellml files in order to 
>> simulate some action potentials and currents. So that I'd like to 
>> request a log in to use the cellml online simulator.
> Hi Danilo,
> 
> There are several CellML simulators available. The one I develop is 
> called PCEnv (which is a combined model authoring and simulation 
> environment). PCEnv is an open source application which you can freely 
> download and install onto your computer from 
> http://www.cellml.org/downloads/pcenv/releases (simulations run on your 
> own computer, so you don't need to log in anywhere).
> 
> For a list of other simulator software, please see 
> http://www.cellml.org/tools/ . Some of these program send simulations to 
> run on remote servers,  although I am not aware of any of them requiring 
> accounts for normal use.
> 
> Best regards,
> Andrew Miller
> 
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] embedded stimulus currents in CellML models

[James Lawson]

Alan Garny wrote:
>>> Depending on the end-user, it could be a, b and/or c, as well as the
>> fact
>>> that apart from PCEnv, no other CellML-capable software that I am
>> aware of
>>> can deal with CellML 1.1 models. This emphasises my view that we have
>> to
>>> make the CellML API easy to use and provide several examples of its
>> use.
>>
>> http://cellml.sourceforge.net :-)
> 
> That is a good start indeed. Now, I am waiting for you to write the
> documentation... :)
>  
>   Alan.
> 
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

I was actually trying to get CellML2Dot running. I didn't try very
hard... It's in the cellml-discussion archives (or if not the
team-cellml, but I think the former.)

It would definitely be cool to get some basic documentation for these
tools. If you have a go at installing CellML2Dot in Linux Alan, let me
know. I'd like to see Andre's simulator too. How does it differ from
PCEnv or COR Andre?
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] embedded stimulus currents in CellML models

[James Lawson]

Alan Garny wrote:
>>> Shouldn't we therefore offer at least two different sets of CellML
>> 1.0
>>> files? One that only contains the model itself and another that also
>>> includes some simulation specific information?
>> I actually replied to this somewhere else - I'll repeat it...
>> We just talked about this issue in the meeting. We decided that it was
>> probably worth providing one with and one without. Obviously the one
>> without would not be able to be simulated in PCEnv or COR.
> 
> You could still easily modify the model for your own purpose in COR (and the
> same in PCEnv, I believe).
> 

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.

This is the kind of issue that really needs to go in a tracker.

>>> Though CellML 1.1 is the obvious way to go, we have to accept the
>> fact that
>>> most CellML users probably only use CellML 1.0.
>> But is that because they a.) don't need 1.1, b.) don't know how to use
>> 1.1 or c.) want to use 1.1 but don't because the repository doesn't
>> support it? I suspect it is either a or c, since most people would find
>> out how to use 1.1 if it was a tool they thought would be useful.
> 
> Depending on the end-user, it could be a, b and/or c, as well as the fact
> that apart from PCEnv, no other CellML-capable software that I am aware of
> can deal with CellML 1.1 models. This emphasises my view that we have to
> make the CellML API easy to use and provide several examples of its use.
>  

This is a good point. There is no point simply criticising other
software because it doesn't make use of 1.1. We need to ask why this is,
and if there is anything we can do to make it easier for developers to
make their software 1.1-capable. I think this is definitely an area
where you could be very useful, since you can take a fresh look at the
API, whereas it is much harder for someone like Andrew to take a step
back from it.

>   Alan.
> 
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] [Tracker Item 42]New: CellML1.1.1specification

[James Lawson]

David Nickerson wrote:
> The more this is explained, the more it sounds like this could all be 
> achieved with some additions to the errata for the CellML 1.1 
> specification. What benefit is gained by making a 1.1.1 version?

>From what I gather, publicity. We need some way to direct people's
attention to our intention to deprecate reaction elements.

> 
>> 1.1.1 doesn't describe the reaction element, but 1.1 does, and 1.1.1 and 
>> 1.1 are in the same namespace. If software which has supported reactions 
>> per the CellML 1.1 specification sees the reaction element, it will 
>> follow the 1.1 specification (indeed, we probably would benefit from an 
>> implementation guide which encourages tool developers to support more 
>> than one version of CellML if possible. How many versions back they want 
>> to support is up to them).
>>
>> Model authors on the other hand will be strongly encouraged to use 
>> CellML 1.1.1.
>>
>> Best regards,
>> Andrew
>>
>> ___
>> cellml-discussion mailing list
>> cellml-discussion@cellml.org
>> http://www.cellml.org/mailman/listinfo/cellml-discussion
> 

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] information_cellml_simulator

[Andrew Miller]

danilo roman wrote:
> Dear all
> I'm a master student at federal university of minas gerais, Brazil. 
> Actually I've carried out some research at cardiomyocyte 
> electrophysiology under supervision of Prof Jader dos Santos Cruz. In 
> our lab, we're interesting in use the cellml files in order to 
> simulate some action potentials and currents. So that I'd like to 
> request a log in to use the cellml online simulator.
Hi Danilo,

There are several CellML simulators available. The one I develop is 
called PCEnv (which is a combined model authoring and simulation 
environment). PCEnv is an open source application which you can freely 
download and install onto your computer from 
http://www.cellml.org/downloads/pcenv/releases (simulations run on your 
own computer, so you don't need to log in anywhere).

For a list of other simulator software, please see 
http://www.cellml.org/tools/ . Some of these program send simulations to 
run on remote servers,  although I am not aware of any of them requiring 
accounts for normal use.

Best regards,
Andrew Miller

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] embedded stimulus currents in CellML models

[Alan Garny]

> > Depending on the end-user, it could be a, b and/or c, as well as the
> fact
> > that apart from PCEnv, no other CellML-capable software that I am
> aware of
> > can deal with CellML 1.1 models. This emphasises my view that we have
> to
> > make the CellML API easy to use and provide several examples of its
> use.
> 
> http://cellml.sourceforge.net :-)

That is a good start indeed. Now, I am waiting for you to write the
documentation... :)
 
Alan.

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] embedded stimulus currents in CellML models

[David Nickerson]

> Depending on the end-user, it could be a, b and/or c, as well as the fact
> that apart from PCEnv, no other CellML-capable software that I am aware of
> can deal with CellML 1.1 models. This emphasises my view that we have to
> make the CellML API easy to use and provide several examples of its use.

http://cellml.sourceforge.net :-)
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] curation of BioModels Database

[Nicolas Le Novere]

David Nickerson wrote:

>> We release the models publicly twice a year.
> 
> just wondering what you mean by this? is it that the public database is 
> only gets updated twice a year, while the model curators are working on 
> the (private) next release of the models?

Yes. This is exactly that. That allow some flexibility in the curation 
schedule, and also we want a certain level of annotation before release. 
Finally, some models are not released for public consumption because of 
problems discovered late (did-you notice there was no BIOMD19?)

> Also, do you have any sense of curation (over and above the libSBML 
> consistency checks) for a model not based on a particular peer-reviewed 
> publication? 

All the models distributed by BioModels Database are described in the 
peer-reviewed literature. We do not want to be involved in any discussion 
about the biological relevance of the models.


> For example, models that are designed simply as test-cases 
> for particular expected software behaviour - where the structure and 
> expected behaviour of the model are well known but not described in any 
> specific published article. From what I remember, MIRIAM uses published 
> articles as the reference description of a model in regard to MIRIAM 
> compliance, but could another source reference description be used in 
> model curation, albeit not in conjunction with MIRIAM compliance?

This is actually incorrect. MIRIAM does not require publication in an 
article. It requires a unique reference description, that can be an 
article, a technical report, a web-page etc.

>> finally that one can reproduce published results *using different
>> software than the one used by the authors*.
> 
> I think this is very important requirement for model curation, but one 
> that is quite daunting for CellML models, especially CellML 1.1 based 
> models. One question I have is how different different tools need to be 
> to satisfy such curation? What I'm getting at is that there could 
> potentially be many "different" tools based on a common library (the 
> CellML API and code generation service, or libSBML for example), but to 
> me these wouldn't be different enough as the actual interpretation of 
> the model is essentially done by the common layer underneath whatever 
> extra bits the specific tool is adding in. Or is throwing the model 
> through a different numerical integrator, for example, enough to satisfy 
> this requirement?

:-)

We did not formalise that far. You are entirely right of course. Let's say 
it very much depends on the model. Some can be simulated in many software 
and it is easy to get the results using different solvers. Some tricky 
models can only be simulated by a couple of software ...

-- 
Nicolas LE NOVERE,  Computational Neurobiology,
EMBL-EBI, Wellcome-Trust Genome Campus, Hinxton, Cambridge, CB10 1SD, UK
Tel: +44(0)1223494521, Fax: 468, Mob: +44(0)7833147074  Skype:n.lenovere
http://www.ebi.ac.uk/~lenov, AIM: nlenovere, MSN: [EMAIL PROTECTED]
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] embedded stimulus currents in CellML models

[Alan Garny]

> > Shouldn't we therefore offer at least two different sets of CellML
> 1.0
> > files? One that only contains the model itself and another that also
> > includes some simulation specific information?
> 
> I actually replied to this somewhere else - I'll repeat it...
> We just talked about this issue in the meeting. We decided that it was
> probably worth providing one with and one without. Obviously the one
> without would not be able to be simulated in PCEnv or COR.

You could still easily modify the model for your own purpose in COR (and the
same in PCEnv, I believe).

> > Though CellML 1.1 is the obvious way to go, we have to accept the
> fact that
> > most CellML users probably only use CellML 1.0.
> 
> But is that because they a.) don't need 1.1, b.) don't know how to use
> 1.1 or c.) want to use 1.1 but don't because the repository doesn't
> support it? I suspect it is either a or c, since most people would find
> out how to use 1.1 if it was a tool they thought would be useful.

Depending on the end-user, it could be a, b and/or c, as well as the fact
that apart from PCEnv, no other CellML-capable software that I am aware of
can deal with CellML 1.1 models. This emphasises my view that we have to
make the CellML API easy to use and provide several examples of its use.
 
Alan.

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] [Tracker Item 42] New: CellML1.1.1specification

[Matt]

On 7/18/07, David Nickerson <[EMAIL PROTECTED]> wrote:
> Hi Matt,
>
> > I think there does need to be some description of what the parts of a
> > cellml specification version number is and how it relates to the
> > cellml namespace(s).
> >
> > My understanding is that the 1.1.1 was chosen so that this did
> > represent a minor step in thinking for CellML 1.1, but that the model
> > remains valid as a 1.1 model. i.e. A CellML 1.1 model is not
> > necessarily a valid 1.1.1 model and a migration step would be needed
> > to make it so. The namespace of a 1.1.1 model would still be
> > http://www.cellml.org/cellml/1.1#
> >
> > I also think that this minor version should be marked in glaring red
> > that it is precisely a depreciation of reactions step and provide
> > reasons why and the tools to help people transform any models they
> > have with reactions into ones that don't. I think there will be some
> > debate around that - especially pointing to lossless transforms
> > between SBML and CellML and back again with existing transforms
> > available out there.
> >
> > My assumption would be that CellML 1.2 or 2.0 namespace would be the
> > one where reaction elements become invalid if indeed 1.1.1 was
> > successful.
>
> you seem to be saying that version 1.1.1 is marking the reaction element
> for deprecation but that the reaction element itself won't become
> invalid until a 1.2 or 2.0 version is released? This doesn't seem to
> match with completely removing all reference of and to reaction elements
> in the 1.1.1 specification...maybe I'm missing something?
>

No. I agree that removing reference to reaction elements as they exist
in 1.1 is probably confusing and I think 1.1.1 (or whatever it will
end up being called) should emphasise that it is this depreciation of
reaction elements that the 1.0 and 1.1 specifications contain. But we
do need to have a resulting specification (including its XML DTD and
Schema) that has these reaction elements removed. In essence a
specification that is devoid of them in the way they are currently
represented, but at least a section that deals with the alternative -
that is how to represent reactions without reaction elements (which
should encourage the use of metadata that describes the participants
and their roles, etc).

In the OWL modelling context there is a formal way to depreciate
modelling constructs, but I don't know of a similar way for general
xml info sets.

I'm not set on this subset specification being 1.1.1, but I couldn't
offer another alternative. If it were code I would probably have gone
for something like 1.1.1a1 - I think at least maintaining the 1.1 is
important since the resulting models are 1.1 compliant.


>
> Andre.
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion
>
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion