CellML.org - Meeting Minutes 15 March 2001
 |  |  | | | | | |||||||||||||||||||||||||
| | ||||||||||||||||||||||||||||||
| | ||||||||||||||||||||||||||||||
| | ||||||||||||||||||||||||||||||
| | ||||||||||||||||||||||||||||||
| | | | |
April 2001 March 2001 29 March 2001 28 March 2001 27 March 2001 26 March 2001 21 March 2001 20 March 2001 15 March 2001 14 March 2001 13 March 2001 | | | | | | | | | | |
Author: 1 Introduction
The CellML specification defines the basic framework for including metadata in a CellML document, and the actual metadata structure for CellML documents will be defined in a companion specification. We would like to provide a solid draft of this companion specification by the 6 April 2001, CellML freeze. The work on metadata will be divided into two groups: metadata for references and everything else. We'll work on the "everything else" group first. This group currently uses three namespaces: These meeting minutes begin the process of specifying a metadata structure for CellML documents. The following sections examine the non-reference metadata types. Each of these sections is split into three subsections: description of the information being stored, a summary of the current implementation, and a list of remaining issues to be resolved (or an indication that this type of metadata seems to be fully handled). 2 Alternative Names2.1 Information Content
The primary name of an element is given by the value of its 2.2 Current ImplementationAlternative names are stored using the Dublin Core title element, as shown in Figure 1. Figure 1 An example of the use of alternative name metadata. 2.3 Remaining Issues
The Dublin Core now has an "alternative" qualifier for the Figure 2 An example of the use of alternative name metadata. 3 Model Builder3.1 Information ContentThe model builder metadata stores information about the person or persons who coded the model into CellML. (Note that the person or persons who originally authored the model can be stored in the reference metadata.) A given element can have multiple model builders, which may need to be considered as individuals or as members of a group. If they are members of a group, the group may or may not need to be ordered. 3.2 Current Implementation
Model builder metadata can be stored using the Dublin Core creator element, as shown in Figure 3. This example shows extension Figure 3 An example of model builder information.
If a CellML element has more than one creator, it is up to the model builder to decide whether to simply repeat the 3.3 Remaining Issues
4 Species4.1 Information ContentSpecies metadata refers to the biological species (such as human, dog, pig, etc.) for which a model is relevant. A given CellML element may be relevant for multiple species. It may also be relevant for an entire class of species (such as all mammals). 4.2 Current ImplementationSpecies metadata is stored using a CellML-specific species metadata element, as shown in Figure 4. Figure 4 An example of the use of species metadata
The content of the 4.3 Remaining IssuesWe need to determine if we should limit the allowed names for groups of species. We could create a controlled vocabulary, or we may be able to use standard taxonomy names for groups of species. 5 Sex5.1 Information ContentSex metadata refers to the sex for which a CellML element is relevant. 5.2 Current ImplementationSex metadata is stored using a CellML-specific sex metadata element, as shown in Figure 5. Figure 5 An example of the use of sex metadata
A given CellML element may contain multiple
5.3 Remaining IssuesThere are no remaining issues about sex metadata. 6 Creation Date6.1 Information ContentThe creation date is the date upon which the model or model part was coded into CellML. A given CellML element can have only one creation date. 6.2 Current ImplementationCreation date metadata is stored using an extension of the Dublin Core Date element, as shown in Figure 6. Figure 6 Extension of the Dublin Core Date element to store the model creation date. 6.3 Remaining IssuesThere are no remaining issues with creation date metadata 7 Last Modified Date7.1 Information ContentThe last modified date is the date upon which the content of a CellML element was last changed. A given CellML element can have only one last modified date. 7.2 Current ImplementationLast modified date metadata is stored using an extension of the Dublin Core Date element, as shown in Figure 7. Figure 7 Extension of the Dublin Core Date element to store the last modified date. 7.3 Remaining IssuesThere are no remaining issues with last modified date metadata 8 Annotations8.1 Information ContentCurrently, there are three types of annotations:
Each annotation also has creator and creation date metadata that refers to it. 8.2 Current Implementation
Annotations are stored using a CellML-specific annotation element. The metadata about the creator of the annotation should be stored in the same way as the metadata about a CellML element creator (model builder) is stored. The metadata about the creation date of the annotation is stored with the same extended form of the Dublin Core date element used for the CellML element creation and last modified dates. Examples of the three current types of annotation metadata are shown in Figure 8. Note that the implementation of this metadata has changed since the last specification. The annotation text is now direct content of the Figure 8 An example of the three types of annotation metadata. 8.3 Remaining IssuesThe following three issues need to be resolved:
9 Biological Entity9.1 Information ContentThis area of the metadata will almost certainly be expanded in future versions of CellML. For now, it is simply a name or database unique identifier for a biological entity, such as an ion channel, signaling pathway, or specific cell type, that is represented by the model or model component. A given CellML element can represent multiple biological entities. 9.2 Current Implementation
Biological entity metadata is stored using a CellML-specific Figure 9 An example of biological entity metadata. 9.3 Remaining IssuesWe need to decide how to refer to biological entities by a database unique identifier. This requires referring to both the identity of the database (GenBank, SWISS-PROT, Physiome's DB, etc.) and the value of the unique identifier for the entity within the database. 10 Copyright10.1 Information ContentThe copyright metadata refers to the copyright that protects the model, model component, or other CellML element. It is implemented using the Dublin Core Rights element, and therefore, a given CellML element can technically have multiple copyrights. However, the recommended best practice is to include only one copyright for any given element. 10.2 Current ImplementationCopyright metadata is stored using the copyright element from the Dublin Core, as shown in Figure 10. Figure 10 An example of the inclusion of copyright metadata 10.3 Remaining IssuesThere are no remaining issues about copyright metadata. 11 Publisher11.1 Information ContentThe publisher is the person or organization responsible for providing the model, model component, or other CellML element. A given CellML element can have multiple publishers. 11.2 Current ImplementationPublisher metadata is stored using the Dublin Core Publisher element, as shown in Figure 11. Figure 11 An example of the inclusion of publisher metadata
As defined for model builder metadata, publisher metadata can be repeated in three ways. If the 11.3 Remaining IssuesThere are no remaining issues about publisher metadata. 12 Mathematical Problem Type12.1 Information ContentThe mathematical problem type is a classification of the type of problem encoded in the math associated with the model or model component. It should be specified using some sort of controlled vocabulary, such as the NIST's GAMS classification tree. 12.2 Current ImplementationMathematical problem type metadata is stored using the CellML-specific math_problem_type element, as shown in Figure 12. Figure 12 An example of the mathematical problem type metadata. 12.3 Remaining IssuesWe need to add a way to provide a URL for the problem classification scheme. 13 Additional Issues to DiscussThe metadata specification will define the metadata elements that processing software must be able to handle if they claim to be "CellML metadata compliant". Software and model authors will be free to use other metadata if appropriate, but this metadata will be less interoperable than metadata defined using the elements and rules in the CellML metadata specification. The decision about whether or not to include a specific metadata element in the specification must balance the desire to provide a complete set of interoperable metadata, and the need to keep the set a manageable size for processing software to implement. The following additional Dublin Core elements should be considered for inclusion in the specification:
| | | | | | ||||||||||
| | | | | | | | | | | | | | | | |
| | | | | | |||||||||
 | |  | | | | | |||||||||||||||||||||||||
| | ||||||||||||||||||||||||||||||
| | ||||||||||||||||||||||||||||||
| | ||||||||||||||||||||||||||||||
| | ||||||||||||||||||||||||||||||
