Chronological Thread 

< Chronological >      < Thread >

---

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] CellML terminology: distinguishing CellML models from the XML in which they are represented, Andrew Miller, 12/12/2007
  • [cellml-discussion] CellML terminology: distinguishing CellMLmodels from the XML in which they are represented, David Nickerson, 12/12/2007
    • [cellml-discussion] CellML terminology: distinguishing CellMLmodels from the XML in which they are represented, Andrew Miller, 12/12/2007
      • [cellml-discussion] CellML terminology: distinguishingCellMLmodels from the XML in which they are represented, David Nickerson, 12/12/2007
        • [cellml-discussion] CellML terminology: distinguishingCellMLmodels from the XML in which they are represented, Andrew Miller, 12/12/2007
          • [cellml-discussion] CellML terminology:distinguishingCellMLmodels from the XML in which they are represented, David Nickerson, 12/12/2007
            • [cellml-discussion] CellML terminology:distinguishingCellMLmodels from the XML in which they are represented, Andrew Miller, 12/19/2007

---

Archive powered by MHonArc 2.6.18.