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 > [email protected] > http://www.cellml.org/mailman/listinfo/cellml-discussion -- David Nickerson, PhD Research Fellow Division of Bioengineering Faculty of Engineering National University of Singapore Email: [EMAIL PROTECTED] _______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
