CellML Discussion List

Text archives Help


[cellml-discussion] CellML terminology: distinguishing CellMLmodels from the XML in which they are represented


Chronological Thread 
  • 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.

Top of page