ABI Meeting Minutes 2008-08-27

Present: Poul Nielsen, Justin Marsh, Michael Backhaus, Mike Cooling, Andrew Miller, David Cumin, Tommy Yu, Peter Schmiedeskamp, James Lawson

Apologies: Catherine Lloyd, Peter Hunter

Last week's action items

• Done. Item is Tracker Item 1310

• Done, item is on this week's agenda

• Done. Item is Tracker Item 1298

• Done. Item is Tracker Item 1299

• Randall, Andrew and Justin met with Poul
• A brief note on what they talked about can be found here
  

Agenda for this week

• Currently in PCEnv it is not possible to paste in multiple equations at once. This would be useful. The interface could be provided when the user clicks on the "Mathematics" element (as opposed to the equation element)

• Drag and drop functionality would also be useful within the PCEnv model view tree

• Justin suggested that some kind of function to allow merging of compatible elements would be a useful feature
  

• See Tracker Item 1277
• This item carried forward from last week pending Poul's presence
  
• Mike mentioned that has put a challenge for someone to explicitly define the advantage of encapsulation on that tracker item, and so far no one has been able to do so.
• It would be useful to be able to import packaged hierarchies of components while sidestepping the information hiding imposed by encapsulation
• Poul said that this is currently achievable if the entire encapsulation hierarchy is explicitly imported
• James noted that this is tedious and may hamper reuse of a module by forcing modellers to write extra gluing code
• Poul suggested that a tool should be used to automate this kind of tedious work, rather than a language feature
• Mike does not see the utility of information hiding in CellML; it make sense for procedural code, but CellML is more like a database with descriptions of relationships between entities
• If a model is constructed with hidden information, then the model needs to be teased apart and the information hiding negated if hidden elements within the module are to be used
• Poul doesn't think this is a bad thing: it forces the modeller to familiarise themselves with the module they are using by making them drill down to get at the element they want
• James thinks this counters the abstraction we are trying to leverage by making reusable modules
  
  
• Andrew has proposed a possible solution to this issue as a language feature:
• Encapsulation groupings would be defined as public or private. Public encapsulation would provide a packaging function so that groups of components could be imported together. Private encapsulation would allow for information hiding.
• Modellers could use a path syntax to refer to publicly encapsulated elements
• There was a general consensus that this idea should be developed

• It would be useful to provide some indication (other than the status text at the bottom of the screen) of which icons are active (i.e. displaying traces in the graph window above) within a Javascript embedded SVG diagram in PCEnv sessions
• This could be done by giving the icon a 'halo' or displaying a tick next to it
• It would also be useful to label traces to show which variable they represent. Labels can not be rendered directly on top of the graph but a mouseover could provide similar functionality

• The current system for dealing with model variants (usually alternate parameterisations of models) is inadequate and should not be repeated in PMR2
• When a model with variants is curated, sometimes only the first variant is curated, since its is a lot more work to curate all the variants. This has resulted in models which have poorly curated variants
• Additionally, some models may have many variants, as the number of variables with alternate parameterisations grows. Thus the curation burden grows combinatorially
• Variants could be handled using CellML 1.1, by creating a base model which is unparameterised, and importing the appropriate parameters from any number of secondary models. Because this is done at the component level, however, the target model would have to be expressed in a fairly fine-grained, modular fashion. This is a good example of the benefits that users could realise by using some of the best practices the group have been discussing recently
  
• Some of the group did not believe that imports were appropriate for this sort of problem. James noted that this sort of problem is exactly what imports were devised to solve. If we can not use imports for this, we should reconsider what we want imports to be able to achieve.
  
• We may need to give imports more functionality and provide options for how an import is effected, such as whether a model with a defined hierarchy is imported with the structure intact or whether it is flattened, allowing imported elements to effectively replace elements from the model into which they are being imported, etc.
  
• David suggested that we could provide parameter and equation 'overrides' for imported elements (as a language construct,) so that the model uses the imported elements unless they are redefined in some sort of special construct in which case the redefined ones take precedence.
  
• This was aimed more at modifying the model for replicating experimental conditions and was thought to be better placed in the simulation metadata rather than the core language. 
  
• It may also be useful for parameter optimisation, although Andrew suggested that there are tools which specialise in parameter optimisation; an actual language or metadata construct may not be necessary.
• There did seem to be a clear practical distinction between changes we wanted to make in the model code and changes like the ones talked about with David that are more ephemeral. Despite the intuitive difference, the group was unable to say in the meeting exactly what that difference was. Exploring this issue could be important conceptually. It may be that we have some conceptual muddling there too; at least we ought to be able to prove that this is not the face.
  
• The idea of using 'patches' to replace parts of a model was suggested. These patches could be effected by either using a text editor, which is not ideal, or by using an XSLT
• The group decided that new variants in PMR1 should not be made; rather, information should be provided within the documentation that explains how to produce them by changing parameter values etc.
• There was also some discussion about the manner in which variants would be handled in PMR2; if imports are used with fairly fine-grained models, variant branching should not present the maintenance problem that it currently does in PMR1. If the core model is changed, then each top level model that imports the core model and a parameter set model will change with it.
  

• The prototype has been a success. The most common negative feedback had to do with the user interface, but the purpose of the prototype was to test out the DCVS based back-end, which was shown to be sound.  T
• Tommy has received the green light and has officially started coding up PMR2

• James made some SVG session files
• He is currently working on curating the circadian rhythm models

• A new, working snapshot has been created which makes use of the validator
• Justin is now working on the algorithms for pane resizing

• Andrew has been working on the API-side RDF parser, which is a prerequisite for metadata editing within PCEnv