Hi all, I have been working on resolving the current terminology issues in CellML 1.1 where 'model' is used to mean both the XML file in which the model element resides, and the abstract mathematical model represented by that XML file when any imports have been processed. This overloading has occurred as a result of the transition from CellML 1.0 to CellML 1.1. It is an issue which is worth trying to resolve, because issues like this cause the CellML 1.1 text lacks the precision that a well specified format should have.
In my initial drafting work, I used the terms 'CellML File' and 'CellML Model' to distinguish the two concepts. These terms were defined, but the aim was that they could be understood without needing to refer to the definitions. However, concerns about this have been raised, because what is being referred to as a CellML File could be embedded into another XML document. This could be addressed by ensuring the definition of CellML File allows for that, but confusion could still occur from this. There were several alternatives proposed at today's CellML meeting: 1) 'CellML Model with no imports or with uninstantiated imports' vs 'CellML Model with all imports instantiated'. The problems with this is that it is cumbersome especially when it appears multiple times in the same sentence (and would possibly be unambiguous in that case), it is confusing to use these terms before imports have been explained, or in the section explaining imports, and it doesn't create a very clear conceptual separation between the representational layer and the model represented in that representational layer. 2) 'CellML model element information item and all descendant information items' vs 'CellML Model'. The former is reasonably cumbersome and would probably be confusing when used in a sentences. Examples from the beginning of the specification of how it could sound... "Every CellML model element information item and all descendant information items SHALL be represented in an XML document which conforms with the well-formedness requirements of the XML 1.0 specification" "Two CellML model element information items and all descendant information items shall be equivalent if one can be transformed to another by making zero or more of the following changes" 3) Make up an acronym of some kind. I have looked into other specifications which may have similar requirements. XInclude uses the phrases 'source infoset' and 'result infoset', and writes the specification as a transformation between the two. I don't think this could work for CellML because import processing is not easily described as a simple transformation, and it is part of a large specification which also cannot easily be written as a transformation (unless we want to describe CellML with imports as a transformation to a single CellML model file with no imports, and then describe that in terms of a transformation into MathML, which might work but would be radically different from the approach we have taken so far). I think we have a few remaining options: 1) Retain the CellML File / CellML Model terminology, and then create another mini-specification for how to embed CellML into other documents which explains that a CellML File is not necessarily the document element. This would probably be a good way to take the specification from a standardisation point of view, because by and large we want people to be exchanging files which have the CellML model element as the document element if they are calling it a CellML File - otherwise it is some other type of document which happens to have CellML embedded in it, and it is not possible to use it from standard CellML tools. 2) Invent an abbreviation. I suggest 'CellML Model Representation (CMR)' vs 'CellML Model Instantiation (CMI)', as one option, although this again could be confusing. However, upon seeing these for the first the reader is likely to look them up in the definitions section rather than relying on any prior knowledge (which may be a good thing if there is a chance that their prior understanding of what the word means is incorrect within the current context). Please let me know what you think on this issue. I personally think that option 1 is the best, but based on the discussion at the CellML meeting today it doesn't seem likely that I will get much support for that approach. Best regards, Andrew _______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
