CellML.org - Meeting Minutes 2 April 2001
 |  |  | | | | | |||||||||||||||||||||||||
| | ||||||||||||||||||||||||||||||
| | ||||||||||||||||||||||||||||||
| | ||||||||||||||||||||||||||||||
| | ||||||||||||||||||||||||||||||
| | | | |
| | | | | | | | | | |
Author: 1 IntroductionIn the 27 March meeting minutes, a system of subsetting the MathML content elements was proposed for use within CellML. In this proposal, there was a basic set of MathML elements that could be used to define any model that consisted of nothing but a system of ODEs, and numerous other sets of elements that were related to specific problem domains such as integration, partial differentiation, and imaginary numbers. Naturally Poul Nielsen, though abroad, did not waste any time shooting down this proposal. In this document, we sum up Poul's comments, and present a summary of the principle approaches we can take to the subsetting problem, with their advantages and disadvantages. 2 Poul's BeefThe main problem that Poul had with Warren's MathML subsetting system was the sheer number of element sets that Warren had defined. He felt that this would lead to severe interoperability problems between CellML applications. For instance, if application A said it supported the basic and integration sets, and application B said it supported the basic and imaginary sets, you couldn't be sure that models exported from application A could be read by application B, even if the majority in fact could. Defining a number of sets makes things more difficult for both the user and the language designer (although that would be the first time he'd shown any concern for the language designer!) Whereas Warren had created sets of elements based on their function, Poul suggested ranking elements purely on the basis of difficulty of implementation. "Easy" elements should be added to the basic set, even if the chances of them showing up in models was slim. This would hopefully not greatly affect the burden of MathML implementation. This would mean that elements related to trigonometry, for instance, which could be easily implemented, should be in the basic set. Poul's single basic subset of MathML elements would contain the following of Warren's sets:
3 Subsetting SolutionsThis section presents some of the possible solutions to the math subsetting problem. 3.1 Solution 1 : Warren's Original ProposalWarren's original proposal is documented in the 27 March meeting minutes. Warren's subsets consist of a basic set containing all of the elements necessary to describe models based on systems of ODEs, plus about 10 other sets of MathML elements, sorted by problem type. The principal advantage of Warren's subsets was that it would be reasonably easy for software implementing CellML to implement the basic subset, which would cover the majority of pathway models as well as many simple EP models. Also, software would be able to easily specify what additional functionality it supported, and not be obliged to interpret large numbers of MathML elements that it didn't expect to use. This is particularly important for implementors of signal transduction pathway simulation packages, who would never achieve any level of CellML compliance if integration elements (which they are probably not interested in) are added to the basic set. The principal disadvantage of using Warren's subsets is that it could easily create an interoperability nightmare where applications could export models in CellML that no other applications could read. Before MathML parsing could begin, applications would have to scan ahead looking for elements that they were unable to interpret. However, given the "math problem type" metadata elements in the CellML metadata specification, it should be possible for software to work out beforehand if it is likely to be able to do anything useful with a given model. An alternative is for models and/or components to declare the subsets of MathML elements that make use of internally, possibly using some syntax in the CellML metadata namespace. This could be regarded as duplication of information that could be fairly easily evaluated by scanning the enclosed MathML. 3.2 Solution 2: Poul's Two Sets ProposalAs described in Section 2, Poul thought that Warren had defined too many sets. He preferred the definition of basic and difficult sets. The proposed contents of Poul's basic set are shown in Figure 1.
Figure 1 The MathML elements in Poul's proposed basic set. The advantage of having only two sets is that when an application says it implements "MathML in CellML Level One" (for want of a better name), you can be fairly confident that it will be able to exchange models with the vast majority of CellML compliant software (because this is all that most software will implement).
The disadvantage is that no-one really wants to have to implement the whole of the basic set. There are a number of elements in there that are difficult yet not useful for the majority of software (integration in particular), and many elements that are completely useless in general (think Furthermore, with two sets (the rest of the elements fall into "MathML in CellML Level Two"), extending the basic set becomes more problematic. If some hypothetical application is interested in spatial models, and they add support for Warren's partial differentiation element set, then they have no facility for advertising this capability (except by word of mouth), unless they implement the complete extended set. Realistically, this will never happen. 3.3 Solution 3 : Some Sort of CompromiseI can't believe I'm using the "C" word in meeting minutes. Let's look at what we'd like to have:
Points 1 and 2 can be handled by merging some of Warren's sets. The first step is to look for elements that can be added to the basic set. The basic set from the 27 March 2001 meeting minutes consisted only of the elements needed to define basic pathway and EP models, some logical expressions (for switching), and the MathML annotation elements (the preferred way of associating equation rendering information with an expression). Elements should only be added to the basic set if they are easy to implement and are not completely useless. These elements include (and it could be argued that most of these are, in fact, largely useless):
The second step is to add more elements to the not very useful set. This set should only contain elements that are not likely to show up in any mainstream models whatsoever. These elements include:
We are now left with the sets of MathML elements shown in Figure 2. It is anticipated that elements may be moved from the not very useful set into other sets in the future, as the needs for CellML's mathematical capabilities develop. For instance, elements like
Figure 2 A second stab at a complete subsetting of the MathML content elements for use in CellML. The third of our requirements for an ideal scheme was a simple means for software to advertise its "MathML in CellML" compliance. The basic premises of MathML compliance are:
Some options for defining further levels of "MathML in CellML" compliance are:
| | | | | | ||||||||||
| | | | | | | | | | | | | | | | |
| | | | | | |||||||||
 | |  | | | | | |||||||||||||||||||||||||
| | ||||||||||||||||||||||||||||||
| | ||||||||||||||||||||||||||||||
| | ||||||||||||||||||||||||||||||
| | ||||||||||||||||||||||||||||||
