Document Actions
CellML Metadata 1.0 Specification
This Version:
http://www.cellml.org/specifications/metadata/cellml_metadata_1.0
Latest Version:
http://www.cellml.org/specifications/metadata/cellml_metadata_1.0
Previous Versions:
http://www.cellml.org/specifications/archive/metadata/20011102/cellml_metadata_specification
http://www.cellml.org/specifications/archive/metadata/20010518/cellml_metadata_specification
Authors:
Autumn A. Cuellar (Bioengineering Research Group, University of Auckland)
Melanie Nelson (Physiome Sciences Inc.)
Warren Hedley (Bioengineering Research Group, University of Auckland)
Contributors:
David Bullivant (Bioengineering Research Group, University of Auckland)
Fred Livingston (Physiome Sciences Inc.)
Catherine Lloyd (Bioengineering Research Group, University of Auckland)
Poul Nielsen (Bioengineering Research Group, University of Auckland)
Abstract
This document specifies CellMLTM Metadata 1.0, the recommended method for identifying types of metadata embedded in a CellML document. The CellML specification recommends the use of the Resource Description Framework for the association of metadata with CellML objects. This document demonstrates how the Dublin Core, BQS and vCard data models can be used to classify metadata. It also defines some CellML-specific types of metadata.
Status of this document
This document is a draft version of the specification for version 1.0 of CellML Metadata. As a Working Draft, this specification may be updated, replaced, or made obsolete at any time. It is distributed for discussion purposes only and should not be used as a reference.
The authors invite feedback from the public. Readers are encouraged to subscribe and send comments to the cellml-discussion mailing list. Alternatively, readers may send comments and questions via e-mail to info@cellml.org.
The latest version of the CellML Metadata specification can always be found on the CellML website.
Contents
- 1 Introduction
- 2 Background
- 3 Fundamentals
- 4 General Metadata
- 5 Citations
- 6 Appendix
1 Introduction
1.1 Need for Metadata in CellML
Metadata is usually defined as "data about data". It is the supporting information that provides context to a resource. In CellML, the model (i.e. the structure and mathematics of the model) is the resource. Information that puts the model into a wider context is metadata. Metadata in CellML includes information such as the literature reference that supports the model, the identity of the creator(s) of the model, and the species for which the model is relevant.
The CellML project needs metadata for two primary reasons:
- It will be difficult to reuse other people's models and components without metadata to provide the context for these objects. A modeller considering reusing someone else's model component will need to know things such as: what biological entity the component represents, for which species the component is relevant, and when the component was created and last modified (to help determine whether it is likely to incorporate the most recent experimental results).
- As the number of models and components grows, metadata will provide the only scalable method for locating particular models and components. Experience in other biological fields shows that as a field grows, powerful search techniques are needed to enable researchers to find relevant resources. These search techniques require structured metadata.
Metadata in CellML can be used in many different ways, such as:
- To support searches of a model repository (or at least to make it possible to automate loading of a database that will support such searches).
- To enable automatic discovery of models published on remote websites, such as laboratory websites.
- To allow the documentation for a model to be kept in the same document as the model itself, which will keep the documentation from becoming obsolete as work continues on the model.
The metadata structure should be flexible and extensible because it is almost certain that we have not thought of all possible uses of CellML Metadata.
1.2 The Larger Metadata Picture
Currently it is not particularly easy to find a specific piece of information on the web, and, once you have found the information, it is not easy to determine whether or not you should trust it. Metadata can address both of these problems. Therefore, there is a push to begin to incorporate metadata into web resources to allow users to get the maximum use out of the information on the web. Tim Berners-Lee has been particularly active in advocating a "semantic web" in which resources would include the semantic information necessary to allow machines to understand (not just read) them. The W3C has set up a semantic web activity to promote what they view as phase two of the Internet. Some software projects, such as Mozilla, have begun trying to take advantage of the metadata that is currently available about web resources. The CellML development team is working to make CellML compatible with the semantic web activity.
2 Background
The CellML development team has decided to use existing standards wherever possible to describe metadata. RDF, Dublin Core, vCard, and BQS are existing standards used to specify metadata. This section describes our use of these standards and our own CellML Metadata.
2.1 Resource Description Framework
Information about RDF can be found on the W3C's Resource Description Framework (RDF) Page.
2.1.1 What is RDF?
RDF, which stands for the "Resource Description Framework", is the W3C's recommendation for handling metadata on the web. The Resource Description Framework is just that: it is a framework that allows you to store descriptions (i.e. metadata) about resources. A resource can be literally anything. For the purposes of CellML, resources can be the model document, the model itself, or components in the model.
2.1.2 The advantages of using RDF
RDF by itself does not allow people to store metadata. It merely provides a standard framework onto which various groups can hang their metadata vocabularies. Some benefits of having this standard framework are:
-
It provides a common attribute=value data model for the metadata.
All metadata expressed in RDF can be presented as a series of
attributes (i.e. properties of the resource) and their values. For
instance, one attribute=value pair for a CellML model might be
species=Mus musculus. -
It provides an extensible method for storing metadata of increasing complexity.
Some metadata properties will have simple values, such as the species
property shown above. Other metadata properties will have complex
values. In the latter case, the value of the metadata property is
itself considered a resource, and additional metadata properties are
stored about it. This is made more clear by an example. Consider the
case of the
creatorattribute. This could be given a simple value of the creator's name, such asJohn Doe. However, it is more powerful to consider the value of the creator property to be a new resource (the person identified by the name "John Doe"). This allows the person's name to be stored as metadata about the new resource. This allows additional metadata to be stored about the person, such as the person's mailing address, phone number, etc. Most importantly, we don't have to know ahead of time what sorts of metadata processing software might want to store about the person. If a particular application wants to store the person's favourite colour, it can do so. Other applications might not recognise the meaning of the particular element that stores the favourite colour, but they will be able to understand that it is some sort of property about the resource (i.e. person) that is the creator of the model. This allows the application to handle the unknown metadata gracefully (most likely, many applications would at least be able to present the attribute=value pair to the user). -
It makes it possible for applications that don't know anything about CellML to understand our metadata.
Though not a reality yet, it is part of Tim Berners-Lee's vision of a
semantic web. Eventually, search engine tools could become RDF capable.
In that case, people would be able to perform much more powerful
searches for information on the web. If someone wants to find all web
resources created by John Doe, he/she could search explicitly for
resources where
creator=John Doe, instead of just searching for resources that contain the string "John Doe". - There are tools out there that use RDF. It is true that RDF is still a fledgling technology. However, there are tools out there that parse RDF and tools that actually use RDF to build databases, knowledge stores, and other such things. For instance, the W3C provides SiRPAC, a Simple RDF Parser and Compiler which returns a graphical representation of the RDF code it is fed to aid in visualization of the attribute=value constructs as well as validate RDF segments. See the W3C's RDF project list for a list of tools and projects using RDF.
2.1.3 The Generalized Structure of RDF
The RDF Model and Syntax Specification specifies a generalized structure. RDF's generalized structure allows many possible methods of storing metadata. RDF's flexible data model gives one the ability to add new classes of information without changing a previously specified schema; intead, the new classes build on the base schema. This extensibility makes RDF particularly appealing for use in CellML.
In order to ensure consistency of notation, the CellML
development team has chosen one way of expressing metadata in RDF. This
is the recommended way of implementing RDF in CellML, but it is not the
only way of representing metadata. From here on, the rdf prefix will be used to indicate that elements and attributes are in the RDF namespace.
2.2 The Dublin Core Metadata Initiative
Information about the Dublin Core Metadata Initiative can be found on the Dublin Core's website.
2.2.1 What is the Dublin Core?
The Dublin Core is a group of metadata properties. These properties were identified as "common" across a large range of resources by a group of library science and knowledge management communities. These properties include attributes like creator, publisher, subject, and date. A full list is found in Table 3, and their corresponding definitions can be found in the Dublin Core Metadata Element Set, Version 1.1: Reference Description.
The Dublin Core Metadata Initiative group has also provided a standard set of "qualifier" elements. These elements add information to the basic elements. Qualifier elements either provide type information or scheme information. Type information classifies the basic element. For instance, the date element can have a type of created, modified, valid, available, or issued. Scheme information indicates how the content of the element is encoded. For instance, the date element can have a scheme of W3C-DTF or DCMI Period. A full list of qualifiers and their allowed values can be found in Table 2, and their corresponding definitions can be found in the Dublin Core Qualifiers document.
It is important to note that Dublin Core does not have to be expressed in RDF. The Dublin Core elements are not elements in the XML sense. They are simply standard names and definitions for common types of metadata. However, the Dublin Core Metadata Initiative has released two articles that suggest a method for implementing an RDF representation of Dublin Core elements and qualifiers: Expressing Simple Dublin Core in RDF/XML and Expressing Qualified Dublin Core in RDF/XML, respectively. These suggestions have been adopted for use in CellML.
2.2.2 The advantages of using Dublin Core
The Dublin Core set of elements is widely referenced, and the W3C designed the Resource Description Framework with the Dublin Core in mind. General purpose tools are more likely to understand the Dublin Core metadata vocabulary than any other vocabulary. Also, using the Dublin Core metadata vocabulary makes it obvious that certain CellML Metadata properties (such as model creator) map directly to metadata properties that are found in other fields.
Henceforth, the prefixes dc and dcterms will indicate that elements and attributes are in the Dublin Core and the Dublin Core Qualifiers namespaces, respectively.
2.3 vCard
At the time of writing, the only existing RDF definition of metadata about people is a note submitted to the W3C in February 2001 entitled Representing vCard Objects in RDF/XML. (This note is the work of Renato Iannella working at the Distributed Systems Technology Centre at the University of Queensland and orginally appeared on their RDF project page.) This note's suggestions are widely used for referencing people in RDF.
As the vCard data model includes some elements that are not necessary for CellML Metadata, such as nickname and birthday, we will not require CellML processing software to recognize those elements. However, model authors are free to use them. That is, the use of vCard elements outside of the list defined in the CellML Metadata specification will not invalidate the metadata, but these elements may not necessarily be recognized by all CellML Metadata compliant processing software.
CellML Metadata compliant processing software is expected to recognize the following "vCard in RDF" elements that meet the information needs of CellML:
-
<vCard:N>(the name construct), with all of its subelements:-
<vCard:Family>: the person's family, or last name -
<vCard:Given>: the person's given, or first name -
<vCard:Other>: additional names, used for middle names and initials -
<vCard:Prefix>: honorific prefixes, such as "Dr." -
<vCard:Suffix>: suffixes such as "III" and "Jr."
-
-
<vCard:ADR>(the mailing address construct), with all of its subelements:-
<vCard:Pobox>: post office box -
<vCard:Street>: street address -
<vCard:Locality>: city, town, rural route, etc. -
<vCard:Region>: state, etc. -
<vCard:Country>: country -
<vCard:Pcode>: postal code (such as the American zip code) -
<vCard:Extadd>: extended address field. This is used to include the company or institution name.
-
-
<vCard:EMAIL>(the e-mail address construct) -
<vCard:TEL>(the telephone number construct) -
<vCard:ORG>(the organization construct), with all of its subelements:-
<vCard:Orgname>: the name of the organization (i.e. "The University of Auckland") -
<vCard:Orgunit>: the division or department (i.e. "The Bioengineering Research Group")
-
-
<vCard:TITLE>: the person's job title -
<vCard:ROLE>: the person's job role
The <rdf:type> element
is used to specify "type parameters" on certain vCard elements. For
instance, an address may be typed as domestic, international, postal,
parcel, home, work, or preferred. Table 1
lists the vCard properties used in CellML that have a type parameter
with their possible values. Note that one address may be given more
than one type. See Figure 33 for an example of how to use the <rdf:type> element in vCard.
| vCard Property | Type Parameter Values |
|---|---|
| TEL | home, msg, work, pref, voice, fax, cell, video, pager, bbs, modem, car, isdn, pcs |
| internet, x400, pref | |
| ADR | dom, intl, postal, parcel, home, work, pref |
Table 1 The names, URIs and recommended prefixes of the namespaces referenced in this specification.
Examples throughout the rest of this specification demonstrate the use
of vCard elements in RDF. These elements are preceded by the vCard prefix to indicate that they are in the vCard namespace.
2.4 Bibliographic Query Service
No bibliographic standards exist within RDF/XML at the time of writing. However, the Object Management Group has published the Bibliographic Query Service Specification. The DsLSRBibObjects
Module from this specification presents an excellent general data model
for bibliographic references. The CellML development team recommends an
RDF serialization of this data model (henceforth referred to as the
"BQS data model") described in detail in Section 5 of this document. BQS metadata is designated by the namespace prefix bqs in this specification.
2.5 CellML Metadata
A CellML Metadata namespace has been created to include all metadata
that has not been previously defined by the four standards listed
above. These include biology-related attributes (such as species and
bio-entities) as well as properties we felt were missing from other
standards (such as annotations). We recommend CellML Metadata be
designated by the namespace prefix cmeta.
2.6 Namespaces in CellML Metadata
Namespace URIs and recommended prefixes are given in Table 2.
| Namespace Name | Namespace URI | Recommended Prefix |
|---|---|---|
| CellML Metadata | "http://www.cellml.org/metadata/1.0#" | cmeta |
| RDF | "http://www.w3.org/1999/02/22-rdf-syntax-ns#" | rdf |
| RDF Schema | "http://www.w3.org/2000/01/rdf-schema#" | rdfs |
| Dublin Core | "http://purl.org/dc/elements/1.1/" | dc |
| DC Qualifiers | "http://purl.org/dc/terms/" | dcterms |
| vCard | "http://www.w3.org/2001/vcard-rdf/3.0#" | vCard |
| BQS | "http://www.cellml.org/bqs/1.0#" | bqs |
Table 2 The names, URIs and recommended prefixes of the namespaces referenced in this specification.
3 Fundamentals
Metadata is defined within an <rdf:RDF> element as shown in Figure 1. The recommended best practice is to define the RDF namespace and any namespaces used by the enclosed metadata on the <rdf:RDF> element, even if these namespaces are already defined on the ancestor elements of the <rdf:RDF>
element. This increases the re-usability of the RDF block. Furthermore,
RDF processing software that does not recognise the CellML namespace
can still parse a CellML document, extract the RDF blocks, and perhaps
provide useful functionality with the information described in the RDF.
Figure 1 An example of a metadata definition. The metadata about the element referenced by "some_element_id" has been left out for now.
An <rdf:RDF> element typically contains one or more <rdf:Description> elements, each of which defines an rdf:about attribute. The value of the rdf:about attribute must be a valid Uniform Resource Identifier (URI). Metadata may be associated with the document it is defined in by assigning the about attribute an empty value ("").
Metadata may be associated with an element in the current document by
defining an attribute of type ID on that element and assigning the about attribute on the <rdf:Description> element a value equal to the value of the ID attribute preceded by a hash (#). In CellML, the attribute referred to is the cmeta:id attribute on any element.
RDF is processed as triples: a resource is assigned a property of a certain value. For instance, in Figure 2, the resource (the element referenced by "Wilma_Flintstone") is assigned a property of <spouse> with a value of Fred Flintstone.
Figure 2 An example of an RDF triple in which the element referred to by "Wilma_Flintstone" is the resource, <spouse> is the property describing the resource, and Fred Flinstone is the property value.
If you wanted to also indicate that Wilma's husband (resource) has a
favourite hobby (property) of bowling (value), you could add an rdf:id attribute to the <toon:spouse> element and create another triple using a second <rdf:Description> element, as shown in Figure 3.
Figure 3 A set of two RDF triples, in which the second <rdf:Description> element describes Wilma's spouse, as indicated by the second rdf:about attribute.
Figure 4 shows an alternative method to describe the two triples shown in Figure 3.
The second <rdf:Description> element is embedded in the <toon:spouse> element to indicate that it is a new resource.
Figure 4 A set of two RDF triples, as in Figure 3. This example shows that a new resource can be created by embedding the <rdf:Description> element in the element it is describing.
Figure 5 shows yet another way to describe the two triples. This example uses the rdf:parseType attribute with a value of "Resource" to introduce a new resource (instead of the <RDF:Description>
element used in the previous example). The CellML Metadata
Specification uses this method frequently because it is less verbose
than the methods described in the previous two examples.
Figure 5 The rdf:parstType attribute with a value of "resource" is another way to introduce a new resource. In this case the new resource is <toon:spouse>.
3.1 Containers
RDF provides the ability to indicate a sequence with the use of containers. The containers <rdf:Bag>, <rdf:Seq>, and <rdf:Alt>, denote an unordered sequence, an ordered sequence, and alternative choices, respectively. Figure 6 demonstrates the use of the <rdf:Bag> element. Each family member of the Jetsons is an equal member of the family. They are grouped together using the <rdf:Bag> element to show that they all belong to the same family.
Figure 6 The <rdf:bag> element demonstrates that each person listed is an equal member of the same family.
The <rdf:Seq> element indicates that the members are in a specified order. In the example shown in Figure 7 the <rdf:Seq> element is used to list the relative ages of each person.
Figure 7 The <rdf:Seq> element implies that those listed are in order based on their age.
The <rdf:Alt> element indicates that any of the listed items may be chosen, and, generally, the first item listed is the preferred value. Figure 8 shows an example in which a choice is given of two supply companies: Spacely's Space Sprockets and Cogswell's Coggs.
Figure 8 The <rdf:Alt> element implies that any one of the listed values is valid.
3.2 Dublin Core Elements and Qualifiers
The Dublin Core Metadata Elements and their corresponding qualifiers are listed in Table 3.
| DC Metadata Element | Element Refinement(s) | Element Encoding Scheme(s) | ||||
|---|---|---|---|---|---|---|
| Title | Alternative | - | ||||
| Creator | - | - | ||||
| Subject | - |
LCSH MeSH DDC LCC UDC | ||||
| Description |
Table of Contents Abstract | - | ||||
| Publisher | - | - | ||||
| Contributor | - | - | ||||
| Date |
Created Valid Available Issued Modified |
DCMI Period W3C-DTF | ||||
| Type | - | DCMI Type Vocabulary | ||||
| Format |
|
| ||||
| Identifier | - | URI | ||||
| Source | - | URI | ||||
| Language | - |
ISO 639-2 RFC 1766 | ||||
| Relation |
Is Version Of Has Version Is Replaced By Replaces Is Required By Requires Is Part Of Has Part Is Referenced By References Is Format Of Has Format | URI | ||||
| Rights | - | - | ||||
| Coverage |
|
|
Each Dublin Core Element is given its own element in the Dublin Core namespace, as shown in Figure 9. The CellML Metadata Specification covers how to use the Dublin Core Qualifiers in later sections.
Figure 9 Each Dublin Core Metadata Element is its own element in the Dublin Core namespace.
4 General Metadata
4.1 Model Creator
Model creator metadata stores information about the person or persons who coded the model into CellML. A given element can have multiple model creators who 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.
Model creator metadata is defined using the Dublin Core creator element, <dc:creator>.
Repeating this element for a given CellML element indicates that the
people listed worked independently on the model. This definition is
shown in Figure 10. Listing multiple people in the <dc:creator> element using an <rdf:Bag>
container indicates that the group of people worked together on the
model and that they are all considered equal contributors. This
definition is shown in Figure 11. Listing multiple people in the <dc:creator> element using an <rdf:Seq>
container indicates that the group of people worked together on the
model and that their contributions are ordered (the first member of the
list is first author, the second member is second author, and so on).
Metadata authors are free to use the <rdf:Alt>
container (as long as they produce valid RDF). However, CellML Metadata
compliant software is not required to be able to consistently interpret
the meaning of an <rdf:Alt> container in
this context. Note that in the examples shown here, the basic vCard
"name" construct is used to store the name of the model creator.
Figure 10 Recommended definition of model creator metadata in which multiple people worked independently on the model.
Figure 11 Recommended definition of model creator metadata in which multiple people worked together on the model and all are considered equal contributors.
4.2 Contributor
Contributor metadata indicates that a person contributed to a resource but did not actually create it (such as an editor).
Contributor metadata is defined using the Dublin Core contributor element, <dc:contributor>, as shown in Figure 12.
Multivalued contributor metadata is handled exactly as multivalued
model creator metadata. Simple repetition of the element indicates that
the people contributed to the resource independently. The use of RDF
bag (<rdf:Bag>) or sequence (<rdf:Seq>) containers indicates that the people contributed to the resource as an unordered or ordered group, respectively.
Figure 12 Recommended definition of contributor metadata.
4.3 Publisher
The publisher is the person or organisation responsible for providing the model, model component, or other CellML element. A given CellML element can have multiple publishers.
Publisher metadata is defined with the Dublin Core publisher element (<dc:publisher>), as shown in Figure 13.
Multivalued publisher metadata is handled exactly as multivalued model
creator metadata. Simple repetition of the element indicates that the
people or organisations publish the resource independently. The use of
RDF bag (<rdf:Bag>) or sequence (<rdf:Seq>) containers indicates that the people or organisation published the resource as an unordered or ordered group, respectively.
Figure 13 Recommended definition of publisher metadata. Note that the empty about attribute indicates that this metadata refers to the CellML document (as opposed to the model or a specific element in the model).
4.4 Copyright
The copyright metadata refers to the copyright that protects the CellML
document, model, model component, or other CellML element. It is
defined using the Dublin Core rights element (<dc:rights>),
and, therefore, a given CellML element can technically have multiple
copyrights. However, the recommended practice is to include only one
copyright for any given element.
Figure 14 demonstrates the definition of the copyright metadata.
Figure 14 Recommended definition of copyright metadata.
4.5 Creation Date
The 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.
Creation date metadata is defined using the Dublin Core date qualifier element, <dcterms:created>. The creation date is further qualified by using the Dublin Core date encoding scheme qualifier element, <dcterms:W3CDTF>, which indicates a YYYY-MM-DD format. The definition of creation date metadata is demonstrated in Figure 15.
Figure 15 Recommended definition of the creation date metadata.
4.6 Modification History
The modification history lists changes that have been
made to the CellML document. Each separate alteration can be described
in its own <cmeta:modification> element. Each modification listed should also include the name of the person who made the changes in a <cmeta:modifier> element and the date the document was modified in the Dublin Core date qualifier element, <dcterms:modified>. The definition of modification history metadata is demonstrated in Figure 16.
Figure 16 Recommended definition of the modification history metadata.
4.7 Alternative Names
Alternative name metadata provides human-readable names for CellML
elements. This alternat name could be used by software whenever it
needs to display a human-readable name. The use of this metadata allows
us to limit the values of name
attributes on CellML elements to enable efficient code generation,
without worrying about whether or not the name will be sufficiently
meaningful to human readers.
Alternative name metadata is defined with the Dublin Core title qualifier element, <dcterms:alternative>.
One element may have multiple alternative names. Only one should be
considered the preferred human-readable name. The preferred name should
be stored in a <dc:title> element. Additional names should be stored in the <dcterms:alternative> element.
Figure 17 shows the definition of alternative name metadata. The element referenced by "#cellml_element_id" is given two human-readable names. The preferred one is "EGF-EGFR complex".
Figure 17 Recommended definition of alternative name metadata.
4.8 Species
Species metadata refers to the biological species (such as human, dog, pig, Palaemon affinis, etc.) for which an element 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.
Species metadata is defined with a CellML-specific metadata element, <cmeta:species>, as shown in Figure 18.
The content of this metadata must be a valid scientific name for a
species or group of species. Notwithstanding recent arguments among
taxonomists about the impact of genomic data on species
classifications, scientific names are considered to be sufficiently
standard to obviate the need to use a formal controlled vocabulary. The
CellML Metadata specification recommends using NCBI's Taxonomy Browser
as a resource for scientific names. If a modeller needs to refer to a
discontinuous group of species (i.e. one that cannot be specified by a
single scientific name) he/she can include multiple <cmeta:species>
elements. Multiple values for the species metadata will always mean
that the CellML element is relevant for any one of the species listed.
Relevance to all of the species as a group would imply some sort of
population dynamics model, which is outside of the scope of CellML.
Figure 18 Recommended definition of species metadata. The element referenced by "#cellml_element_id" is relevant for all mammals and the African clawed frog, Xenopus laevis.
4.9 Sex
Sex metadata refers to the sex for which a CellML element is relevant. A given element may be relevant for more than one sex.
Sex metadata is defined with the CellML-specific element, <cmeta:sex>, as shown in Figure 19. The valid content of this element must be chosen from the following controlled vocabulary:
- male
- female
- hermaphrodite
- other
- all
- undefined (the element is explicitly specified not to have a defined relevance to any particular sex).
Figure 19 An example of the use of sex metadata
4.10 Biological Entity
This 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, signalling pathway, or specific cell type, that is represented by the model or model component. A given CellML element can represent multiple biological entities either as a complete group or as a list of alternatives. A CellML element that represents a list of alternative biological entities would probably be a "superclass" component that will be re-used multiple times in a model, each time to represent a different entity on the list of alternatives. For instance, a modeller might define a general "calcium-binding protein" component and then re-use this component three times in his/her model: once to represent calmodulin, once to represent troponin C, and once to represent parvalbumin. [Note that the component re-use capabilities are not yet defined in CellML. They will be a part of a future version of CellML. The list of alternative biological entities metadata construct is provided now for use in the future.]
Biological entity metadata is defined using a CellML-specific element, <cmeta:bio_entity>.
A biological entity may be identified by name, database identifier, or
both. Multiple database identifiers may be provided, but all except one
must be marked "alternative".
Each database identifier is stored in a <cmeta:identifier> clarified with a
<cmeta:identifier_scheme> element that
identifies the database. The CellML metadata specification will control
names for certain encoding schemes (see below). The <cmeta:identifier> element may also be qualified by a <cmeta:identifier_type> element. This element should have a value of "alternative" for all <cmeta:identifier>
elements except for one, which is considered the primary identifier.
This addresses a concern about allowing multiple database identifiers
that might actually refer to different biological entities. Such an
error may still occur, but marking all identifiers except one as
"alternative" provides software a method by which to determine which
identifier should be given precedence.
The CellML metadata specification will define the following encoding schemes:
- SWISS-PROT (SWISS-PROT protein database)
- GenBank (GenBank nucleic acid database)
- GO Consortium (Gene Ontology controlled vocabulary)
- OMIM (Online Mendelian Inheritance in Man catalog of human genes and genetic disorders)
- LocusLink (LocusLink genetic loci database)
- Unigene (GenBank non-redundant gene clusters database)
- URI (URI for a web resource providing info about the biological entity)
Model authors and authors of processing software are free to define additional encoding schemes, but an rdf:resource attribute must be used on the <cmeta:identifier_scheme> element to provide the URI that identifies the database.
RDF containers can be used to indicate that a given CellML element is relevant for more than one biological entity. An <rdf:Bag> element can be used to indicate that the CellML element is relevant for an entire group of biological entities. An <rdf:Alt>
element can be used to indicate that the CellML element can be relevant
for one member of a group of entities. Note that the first member
listed in the <rdf:Alt> element will be considered the preferred value. The use of the <rdf:Bag> element is shown in Figure 20. The use of the <rdf:Alt>
element would be similar. CellML Metadata compliant software will be
required to recognize RDF containers in biological entity metadata. The
use of RDF containers is preferred to simply repeating the <cmeta:bio_entity> element because it removes all ambiguity about how the group of biological entities relates to the referenced CellML element.
Figure 20 demonstrates the definition of biological entity metadata. Using the <rdfs:label> element is an alternative to using the <dc:title> element: it is a human-readable title of the database value.
Figure 20 Recommended definition of
biological entity metadata. The referenced CellML element represents
the following group of proteins: calmodulin, troponin C, and
parvalbumin (the protein identified by SWISS-PROT entry PRVA_HUMAN).
The calmodulin biological entity has an alternative name and a database
entry. The troponin C biological entity is only identified by name. The
PRVA_HUMAN protein is identified by database reference and a human-readable name.
4.11 Mathematical Problem Type
The mathematical problem type is a classification of the type of problem encoded in the math associated with the model or model component. It is specified using NIST's GAMS classification tree.
Mathematical problem type is defined using a CellML-specific element, <cmeta:GAMS>. Modellers are free to use a different controlled vocabulary for the math problem classifications by using a <cmeta:math_problem> element clarified by a nested <cmeta:math_problem_scheme>. However, CellML Metadata compliant software is not required to recognize any classification scheme other than the GAMS tree.
Figure 21 shows the recommended definition of mathematical problem type metadata.
Figure 21 Recommended definition of the mathematical problem type metadata.
4.12 Description
Description metadata is a short description of the referenced resource.
Description metadata is defined with either of the Dublin Core
description qualifier elements, <dcterms:abstract> or <dcterms:tableOfContents>. Use of the <dcterms:abstract> element will most likely be more common in CellML Metadata.
Figure 22 shows how to define description metadata.
Figure 22 Recommended definition of the Dublin Core description metadata.
4.13 Annotations
There are three types of annotations that are recognized by the CellML Metadata specification. Model authors are free to create additional types. However, CellML Metadata compliant software will not be required to recognize any annotation types except for the following three:
- comment: free-form comment of the person who coded the model into CellML.
- limitation: brief description of the limitations/scope of the content of the CellML element.
- validation: description of the level of validation of the content of the CellML element. This may be a code. Note that validation codes are unlikely to be interoperable.
Annotation metadata is defined using CellML-specific elements: <cmeta:comment>, <cmeta:limitation>, and <cmeta:validation>. If a model author wishes to use a different type of annotation, he/she may specify an <cmeta:annotation_type> within a <cmeta:annotation> element.
Each annotation also has creator and creation date metadata that refers to it. The author metadata associated with an annotation is defined exactly as the model creator metadata (Section 4.1), and creation date metadata associated with an annotation is defined exactly as the general creation date metadata (Section 4.5).
Figure 23 demonstrates the definition of comment and limitation annotations. Figure 24 demonstrates the definition of the validation annotation.
Figure 23 Recommended definition of comment and limitation annotation metadata.
Figure 24 Recommended definition of validation annotation metadata.
5 Citations
5.1 Introduction
The BQS data model draws extensively from the Dublin Core metadata element set. Therefore, the RDF serialization of these elements is used wherever possible. The following sections define the CellML recommended RDF serialization of the DsLSRBibObjects Module from OMG's Bibliographic Query Service Draft Specification.
5.2 The BibliographicReference Class
The BibliographicReference class is the root class for all reference information. It is represented in RDF by the <bqs:reference>
element. This element creates a reference resource. All further content
of this element provides metadata about the reference resource itself.
5.2.1 The identifier attribute
The identifier attribute on the BibliographicReference class provides a way to identify a cited reference using a database identifier (such as a Medline UI) instead of by providing the complete reference details.
The CellML Metadata Specification recommends the use of the following databases:
-
Medlinefor the identifier that is common to all implementations of the Medline database. -
PubMedfor the identifier used only by the PubMed implementation of the Medline database. -
CASfor the identifier used by the Chemical Abstract Service database.
The BQS data model uses a structured string to store the identifier data. The first part of this string indicates the kind of identifier being used (i.e. "Medline"). The second part of the string provides the actual identifier (i.e. "9067300"). The two parts of the string are separated by a slash ("/").
RDF does not allow us to enforce the structured string format of the identifier attribute. However, as Figure 25 shows, this data can still be serialized into RDF using separate database elements: <bqs:Medline_id>, <bqs:PubMed_id>, and <bqs:CAS_id>. To reference a resource not listed above, an rdf:resource attribute with a URI value identifying the resource may be placed on a <dc:identifier> element.
Figure 25 Serialization of the BibliographicReference class's identifier attribute.
5.2.2 The cross_references attribute
The cross_references attribute on the BibliographicReference
class is intended to store alternative identifers for the reference
represented by the contents of the identifier attribute. This can be
represented by the use of the <rdf:Bag> and <rdf:Alt> containers. The <rdf:Bag> element may be used to indicate that both identifiers are equivalent. The <rdf:Alt>
container may be used to indicate that one identifier is preferred to
the other(s). The use of the containers was chosen over listing the
identifiers without a container to prevent confusion should a model be
based on more than one reference.
Figure 26 The reference information in Figure 25 is extended to include a cross reference. This cross reference provides the PubMed identifier for the same reference.