Chronological Thread 

< Chronological >      < Thread >

---

David Nickerson wrote:
> 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 ?
>
I think that this could be heading towards the right approach, although
I'm not sure that the XML serialisation is automatically the right layer
of abstraction to refer to (we are only defining XML parsing by
reference, although RDF/XML does as well) - perhaps the XML Information
Set could be the lowest level, and we describe how that relates to the
conceptual componentised model after import processing, and ultimately
the conceptual non-componentised mathematical model (when mathematical
equations are present).

How about CellML Infoset, CellML Model, and Mathematical Model?

Best regards,
Andrew

>
> 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
>>
>
>

---

• [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.