CellML.org - Meeting Minutes 10 April 2001

CellML Logo

Meeting Minutes 10 April 2001

Structured Annotations in CellML Metadata

Get
the PDF!

Author:
          Warren Hedley (Bioengineering Institute, University of Auckland)
Contributor:
          Melanie Nelson (Physiome Sciences Inc.)

1  Introduction

In this document, I consider the best way to allow software to add structure (i.e., formatting information) and non-text objects into CellML metadata.

2  No More Documentation!

The CellML Metadata Specification was going to define some elements that allowed the modeller to embed documentation (and in particular structured documentation such as XHTML) into CellML documents.

As the result of a discussion between Melanie and me on 10 April 2001, the CellML metadata specification will not define any elements specifically for documentation. This is due to a perceived overlap in functionality between any documentation elements and the annotation element on one hand, and the citation element on the other. When a documentation element is used to store some comments from the model builder, this should really be done using the annotation elements. When a documentation element will contain material from a scientific paper associated with the model, that should really be stored as an annotated reference.

Note that one of the original ideas behind CellML was to embed a model description within a paper describing it, or vice versa. It is now recommended that paper and model definition should be stored in separate entities and reference each other using URIs.

3  Case Studies in Structured Annotation

3.1  MathML

MathML contains two annotation elements, <annotation> and <annotation-xml> that are placed with the target content inside a <semantics> element that links the annotation with the content. Both of the annotation elements may define an encoding attribute that clarifies what format the enclosed content is in. The MathML specification defines two possible values MathML-Content and MathML-Presentation, sets the default value to (i.e., unspecified), and makes no further recommendations as to its value. An example of the MathML annotation scheme is given in Figure 1.


<semantics>
  
<apply><plus />
    
<apply><sin />
      
<ci> x </ci>
    
</apply>
    
<cn> 5 </cn>
  
</apply>
  
<annotation encoding="TeX">
    \sin x + 5
  
</annotation>
  
<annotation-xml encoding="OpenMath">
    
<OMA><OMS cd="arith1" name="plus" />
      
<OMA><OMS cd="transc1" name="sin" />
        
<OMV name="x" />
      
</OMA>
      
<OMI>5</OMI>
    
</OMA>
  
</annotation-xml>
</semantics>

Figure 1 An example of the MathML annotation scheme.


4  Thoughts

  • If there is a standard vocabulary of encodings that seems to include all of the encodings that we are likely to use, we should use that. Does the IETF Mime-Types have LaTeX, MathML and XHTML?
  • The Mime-Types list is probably way too big. Do we want to restrict people to a subset.
  • What's our policy on the use of XHTML? Do people have to use it?
  • Do we want to separate XML and non-XML encodings as MathML has done? I can't see why.
  • What's our policy on namespaces?
                                                                                

Valid HTML!Valid CSS!XML/XSL