ABI Meeting Minutes 2008-08-20

Present: Jaedo Chung, Michael Backhaus, Dougal Cowan, Tommy Yu, Mike Cooling, James Lawson, Randall Britten, Justin Marsh, Gareth de Walters

Apologies: Poul Nielsen, Catherine Lloyd, Peter Hunter


Last week's action items


1.)  Mike to add a tracker item about the flattening tool/function.

  • Mike created Tracker Item 1277 - "We need a white box grouping solution for CellML models"

2.)  Tommy to investigate the feasibility of a single sign-on system for a Plone 2+3 site.
  • Tommy looked into this and figures it can be done, with effort
  • Gareth mentioned the possibility of using LDAP, which is already implemented in the ABI's CMS
  • Andrew was concerned that this might not provide a useful service for people outside defined partner institutions
  • This is still a pending issue


Agenda for this week


Discussion of draft information architecture for cellml.org

  • Having conducted several iterations of the infocard sorting exercise, the cellml.org revision working group has come up with a draft information architecture for cellml.org
  • There is some specific graphical notation used in this document:
    • Each main box represents a top-level group
    • Content is represented by smaller boxes within the top-level groups
    • Subdirectories of content are represented by stacks
    • Within each top-level group is an index page
    • Some content is directly under this index page. This is represented by lines connecting the boxes that represent that content
  • It should be noted that the information architecture represented in this diagram specifically describes the underlying structure of the website (i.e. the directory structure within the webserver's filesystem.) This underlying structure is related to, but not the same as the presentation of the content to the user, which will obviously make use of hyperlinking, tagging etc. to facilitate site navigation and browsing
  • A website's information architecture should facilitate maintenance of the site, permission and access controls (which are particularly relevant for cellml.org,) and provide an intuitive, useful directory structure
  • The group discussed the requirement for a tree-like directory structure (as compared to a completely flat 'filedump' with an intelligent representation layer over it.) There was a general consensus that imposing a network-like representation over a directory based structure should present no serious problems
  • There was some confusion over the 'Software' grouping structure
    • It is supposed to represent an extensible, 'purpose-based' system, where the Software grouping is divided into subdirectories which contain content pertaining to a particular kind of software; the example of 'Simulation' is given.
    • The 'and API' after each example tool named within the 'Simulation' example category was questioned - the representation is slightly confusing and should be clarified

  • There was some discussion about how specific category names are. Specifically, Mike and Justin believe that the category 'Specifications' is too broad if it is only to contain primary CellML specifications and not, for example, specifications that are specific to software such as PCEnv. Mike suggested that the category should be called 'Language Specifications.' This may present a problem in this case because we have already submitted our specs to WC3, and RFCs (Requests for Comments) can not be changed. Additionally, references to our specifications in literature would be broken if we changed this. However, the general principle of the argument still stands.
  • Tommy is not happy with verbose URLs; Randall suggested that the directory name could be 'specifications' but the header of the page could display 'Language specifications'
  • There is more refinement to be done on the proposed information architecture; it is, however, not possible to please everybody.
Action item 1.)  James to create a tracker item to collect commentary and discussions about the proposed information architecture


Mike - "A whitebox grouping solution"
  • Mike has created Tracker Item 1277 to discuss the ideas that came from the recent meeting on best practice for modelling systems in a modular, reusable manner (minutes from this meeting can be found here)
  • The tracker item discusses the merits and pitfalls of the current encapsulation system
  • The discussion is aiming to find a comfortable medium between containment, which has no actual real effect on the CellML model and is more like metadata, and encapsulation, which can get in the way of what a modeller is often attempting to achieve by using it
  • Mike thinks CellML code is often being treated as program code, rather than a database of entities and the relationships between them and this is leading to the mis-application of concepts like encapsulation and also this  in and out business which we are only now trying to get rid of
  • Poul is not present, so this item will be pegged for discussion in next week's meeting
Action item 2.)  "Virtual containment" to be added to next week's agenda


Mike - "Constraints"

  • It would be good to provide human (to serve as comments) and machine readable constraints (for automated checking) on parameters in CellML
  • Some models only produce valid results when the values of certain variables are within a specific range
  • It would be useful to be able to define this range as a constraint such that the model will be invalid if the constraints are broken
  • Currently, this can only be represented in a model comment or metadata. This is not good enough, we need a method which enforces the range
Action item 3.)  Mike will make a tracker item to discuss this issue


MATLAB >> CellML translation
  • Jeffery Saucerman had inquired about the feasibility of translating from MATLAB to CellML
  • Andrew noted that this is a very difficult problem in a general sense
  • It depends heavily on how the MATLAB looks
  • Mike suggested that the MATLAB code could be copy-pasted into COR, and adjusted to fit the COR format, since it is not entirely dissimilar
  • James suggested that we could devise a kind of "MATLAB for CellML" best practice that would explain to modellers how best to write models in MATLAB to make them tractable to translate into CellML
  • Initially, a case study in this is warranted
Action item 4.)  Mike will make a tracker item to discuss such a case study


Feedback on lambda calculus proposal for CellML 1.2 spec
  • Andrew has received feedback on his proposal but would like to know how long he should wait for further feedback before he writes it up properly into a normative specificaiton draft
Action item 5.)  Randall will organise a meeting to discuss this; Poul's presence will be requested


PMR2 progress update
  • The lease on the prototype server has expired
  • Tommy has been doing some work for PMR1: he has built a Python module based on the CellML2C code so that code generation can be leveraged from within Python
  • He has encountered a deadlock within Zope, however, which has been troubling him
  • Andrew had some ideas for a solution, which he would talk to Tommy about after the meeting

PCEnv / CellML API progress update
  • Andrew has been looking at metadata handling within the API; specifically, API-side RDF/XML parsing support
  • Justin has been working on the PCEnv equation viewer / editor and considering ideas for a more general representation of the tree view
  • Andrew has made it so that invalid equations entered into the equation editor in PCEnv still get saved