- From: david.nickerson at nus.edu.sg (David Nickerson)
- Subject: [cellml-discussion] CellML terminology: distinguishing CellMLmodels from the XML in which they are represented
- Date: Wed, 12 Dec 2007 09:05:49 +0800
I think option 1 would be much better than 2.
An alternative might be the RDF and RDF/XML approach? Not too sure what
that implies, but personally I see it as an RDF graph and then the XML
serialisation of that graph. Could we use something like CellML Model
and CellML Model/XML or maybe CellML/XML ?
Andre.
Andrew Miller wrote:
>
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
>
cellml-discussion at cellml.org
>
http://www.cellml.org/mailman/listinfo/cellml-discussion
--
David Nickerson, PhD
Research Fellow
Division of Bioengineering
Faculty of Engineering
National University of Singapore
Email: david.nickerson at nus.edu.sg
Archive powered by MHonArc 2.6.18.