Proposed CellML 1.2 change: removing group and replacing it with an encapsulation element

Hi all,

As has been previously discussed on this mailing list, grouping in the 
general sense can be used to represent information such as containment 
which would more appropriately be treated as metadata and represented in 
RDF/XML. The overall process of moving this information out into 
metadata is discussed in tracker item 316 
(https://tracker.physiomeproject.org/show_bug.cgi?id=316).

As a step towards this, I have created a derivative of the connection 
simplification branch in which the group and relationship_ref elements 
are removed from the specification, and replaced with an encapsulation 
element. The encapsulation element still contains a hierarchy of 
component_ref children, as before.

I have pushed this change into my public git repository at 
git://repo.or.cz/srv/git/cellml-draft-miller.git branch 
encapsulation-only. I have also put up a rendered version of this draft 
at

http://www.cellml.org/Members/miller/draft-normative-spec-encapsulation-only/toplevel.xhtml 
. I created https://tracker.physiomeproject.org/show_bug.cgi?id=356 for 
discussion on this issue - please add yourself to the CC list for the 
tracker item if you are interested.

Best regards,
Andrew

Call for community input: final decisions on a number of specification related issues

Hi all,

There are a number of items in the CellML tracker regarding decisions 
about the next version of the CellML specification, which have been 
discussed in the past and around which consensus seems to have been 
reached, but on which we have yet to declare a final decision. By making 
a final decision as a community on a set of questions, further important 
questions about what will be in the specification can be more easily 
discussed (without having to consider the interaction with every 
possible other decision that is still open).

There has recently been some discussion over the best process to make 
decisions on specification related proposals. Although the exact details 
of the process still has to be worked out, there was agreement (at least 
amongst people in Auckland) that we should make decisions by unanimous 
agreement where possible, and only fall back onto some other process 
where this has been shown not to be possible. The process for 
determining such unanimous agreement seems to be to that the issue is 
proposed, discussion on the proposal takes place, and when this 
discussion dies down and there is an apparent consensus, community input 
is sought, and a deadline (sufficiently far in the future) for 
objections is provided. In the event that no objections are raised by 
the expiry of the deadline, the decision has been made. Objections could 
relate to the substance of the proposal, or simply be to request more 
time for the decision to be made.

So that the list of decisions I identified can be made, I have set a 
deadline of one week from now, that is, Wednesday March the 12th, at 
00:00:00 GMT (which is March 12th, 1:00 pm in NZDT). If you feel that 
this is not enough time, please make a note of this on the tracker item, 

Re: Call for community input: final decisions on anumber of specification related issues

Hi Andrew,

While I agree that the listed proposals all seem to have reached 
consensus and that final decisions need to be made in order for the 
development of CellML 1.2 to progress, this seems a rather arbitrary 
manner in which to be declaring the proposal handling method. Especially 
as the discussion actually dealing with the handling of proposals 
(tracker item 347) has yet to come close to an agreed upon method for 
dealing with this issue.

I would suggest that the proposed method for handling decisions on 
proposals contained in this email should be added to the discussion of 
tracker item 347 where we can debate its merits and be assured that 
community members outside the Auckland meeting can have some input into 
this process and hence achieve some consensus on the handling of 
proposals before deadlines are set on the actual proposal decisions.

Just to note in advance of the expected discussion, we have previously 
decided against using such a "passive" decision making process back in 
the early days of the CellML project.

David.

Andrew Miller wrote:
> Hi all,
> 
> There are a number of items in the CellML tracker regarding decisions 
> about the next version of the CellML specification, which have been 
> discussed in the past and around which consensus seems to have been 
> reached, but on which we have yet to declare a final decision. By making 

Re: Call for community input: final decisions on anumber of specification related issues

David Nickerson wrote:
> Hi Andrew,
>
> While I agree that the listed proposals all seem to have reached 
> consensus and that final decisions need to be made in order for the 
> development of CellML 1.2 to progress, this seems a rather arbitrary 
> manner in which to be declaring the proposal handling method.
>  Especially 
> as the discussion actually dealing with the handling of proposals 
> (tracker item 347) has yet to come close to an agreed upon method for 
> dealing with this issue.
>   
Hi Andre,

I think this creates a bit of a 'catch-22' situation because we need a 
decision process to decide on a decision process. I think that until we 
have such a process, we need to stick to the status quo, which has 
generally been that we discuss things with the community, and if there 
is disagreement, then a smaller group of people make the decision (I 
personally would prefer a more formalised voting based system with a 
fairly large number of eligible voters, but both Poul and Peter seem to 
favour a system where we define a fairly small set of people from a 
range of different groups who can vote, and only use this mechanism to 
make a decision when the community has discussed an issue and not 
reached agreement).

> I would suggest that the proposed method for handling decisions on 
> proposals contained in this email should be added to the discussion of 
> tracker item 347 where we can debate its merits and be assured that 
> community members outside the Auckland meeting can have some input into 

Re: Call for community input: final decisions on anumber of specification related issues

Hi

I have summarised the decision as a comment on the Proposal handling tracker
item (https://tracker.physiomeproject.org/show_bug.cgi?id=347)

This currently only applies for the CellML specification work.

Regards,
Randall

> -----Original Message-----
> From: cellml-discussion-bounces@... [mailto:cellml-discussion-
> bounces@...] On Behalf Of Andrew Miller
> Sent: Wednesday, 5 March 2008 3:11 p.m.
> To: CellML Discussion List
> Subject: Re: [cellml-discussion] Call for community input: final
> decisions on anumber of specification related issues
> 
> David Nickerson wrote:
> > Hi Andrew,
> >
> > While I agree that the listed proposals all seem to have reached
> > consensus and that final decisions need to be made in order for the
> > development of CellML 1.2 to progress, this seems a rather arbitrary
> > manner in which to be declaring the proposal handling method.
> >  Especially
> > as the discussion actually dealing with the handling of proposals
> > (tracker item 347) has yet to come close to an agreed upon method for
> > dealing with this issue.
> >

Re: Call for community input: final decisionson anumber of specification related issues

> I think this creates a bit of a 'catch-22' situation because we need a 
> decision process to decide on a decision process. I think that until we 
> have such a process, we need to stick to the status quo, which has 
> generally been that we discuss things with the community, and if there 
> is disagreement, then a smaller group of people make the decision (I 
> personally would prefer a more formalised voting based system with a 
> fairly large number of eligible voters, but both Poul and Peter seem to 
> favour a system where we define a fairly small set of people from a 
> range of different groups who can vote, and only use this mechanism to 
> make a decision when the community has discussed an issue and not 
> reached agreement).

I'm not really commenting on whether the proposed system is suitable or 
not, at least not yet :) just that given we have a tracker, we have an 
item in the tracker discussing this issue, and we are encouraged to use 
the tracker for such discussion. So this solution and the justification 
for it should have been posted to the tracker item first before 
announcing that the solution has been decided upon.

Currently I am getting the impression that any discussion of tracker 
items is superfluous and decisions will always be made by the Auckland 
meeting.

> Just to clarify, are you objecting to all or any of the deadlines (on 
> any of the specific issues listed below) or are you happy with the 
> actual tracker items (as opposed to the decision-making process)?

the latter :)

Re: Call for community input: final decisionson anumber of specification related issues

Hi 

> -----Original Message-----
> From: cellml-discussion-bounces@... [mailto:cellml-discussion-
> bounces@...] On Behalf Of David Nickerson
...
> Currently I am getting the impression that any discussion of tracker
> items is superfluous and decisions will always be made by the Auckland
> meeting.

We had a brief summary of the tracker item before proceeding with the
discussion, so input on the tracker item is discussed at the meeting, and is
very valuable.

I think it can be seen in a different light: We are not attempting to manage
the community.  We are investing a lot into the CellML project, and we are
attempting to smooth out the way we manage that investment.  Decisions at
the Auckland meetings allow us to manage that investment.  In everything we
do, we are aiming to involve the community as much as possible, so that the
community has as much influence over those decisions as possible while still
balancing the need for progress to be made.

Regards,
Randall

ABI CellML group meeting 2008-03-05

Hi all,

The ABI CellML group meeting minutes for this week's meeting - 
2008-03-05 are now up at:
http://www.cellml.org/meeting_minutes/abi-meeting-minutes-2008-03-05/

Kind regards,
James Lawson

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

MIASE: towards the description of simulation runs

Dear all,

having seen your proposal for a CellML Simulation Metadata Specification 
just recently, I thought you might be interested to know that there is a 
quite similar effort going on at the moment, called MIASE (Minimum 
Information About a Simulation Experiment). 

The aim of MIASE is to find a minimal way of describing the simulation 
run on a quantitative model. Thus, we are trying to encode information 
such as the algorithm/method used for the simulation, model changes done 
on the model in order to run the simulation properly, defining several 
tasks to be applied to the model and finally defining the output of the 
simulation.

All of this should be described independent of the format the model is 
encoded in.

MIASE is aimed at being a community effort, reaching as many research 
groups as possible. So far, it has been discussed on the Super Hackathon 
"standards and ontologies for Systems Biology" in Okinawa in January 
this year and the following email discussion has been joined by people 
from different simulation tools, such as COPASI, SBW, Virtual Cell and 
SBToolbox.

I have had a look at the CellML Simulation Metadata Specification by 
Andrew at http://www.cellml.org/specifications/metadata/simulations/ . 
It actually seems that we are heading for quite similar aims. That is 
why I just wanted to direct you to the following web resources, and I 
would like to ask you participate in the current MIASE discussion, as it 
might be nice to bring both efforts together:

Specifying the variable(s) of integration / independent variable(s) in MIASE

Dear all,

Based off the UML diagram at 
http://miase.cvs.sourceforge.net/*checkout*/miase/miaseOM/miaseOM/miaseOM.pdf?revision=1.5 
, I notice that the UniformTimeCourse UML class makes the assumption 
that the model is being evaluated across a time variable (in other 
words, that time is special in some sense).

I understand that one of the goals of MIASE is for it to be format 
independent. However, I believe that the assumption that time is special 
harms the applicability to languages such as CellML (which aim to 
represent models in a domain-independent form, which means that concepts 
like time are not built into the standard, but rather, are defined as 
part of the model).

As has been pointed out on an earlier thread on the MIAME mailing list,

https://sourceforge.net/mailarchive/forum.php?thread_name=18374.18884.225456.303727%40mellow.local&forum_name=miase-discuss 
, I have previously defined a short draft specification designed to 
represent similar information (although I agree entirely with the idea 
of replacing this with a better specification common to multiple 
modelling languages).

The CellML Simulation Metadata focuses on the equivalent of the 
UniformTimeCourse simulation. However, these simulations are composed of 
one or more objects, which each associate with a variable in the CellML 
model and the range of the variable over the simulation (in the common 
case where time is the independent variable, there is one such object, 
which references time, and the initialStartTime and initialEndTime 
attributes on UniformTimeCourse simulation correspond to similar slots