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/metadata/cellml-metadata-specification-1-0-draft
http://www.cellml.org/specifications/archive/metadata/20011102/index.html
http://www.cellml.org/specifications/archive/metadata/20010518/index.html
Authors:
Autumn A. Cuellar (Auckland Bioengineering Institute, University of Auckland)
Melanie Nelson (Physiome Sciences Inc.*)
Warren Hedley (Auckland Bioengineering Institute, University of Auckland)
Contributors:
David Bullivant (Auckland Bioengineering Institute, University of Auckland)
Alan Garny (Oxford University)
James Lawson (Auckland Bioengineering Institute, University of Auckland)
Fred Livingston (Physiome Sciences Inc.)
Catherine Lloyd (Auckland Bioengineering Institute, University of Auckland)
Poul Nielsen (Auckland Bioengineering Institute, University of Auckland)
* Physiome Sciences Inc. no longer exists.
Abstract
This document specifies CellML 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 specification was frozen on 2005-06-28 and finalised on 2009-07-22.
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 "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 Resource Description Framework (RDF): Concepts and Abstract Syntax 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; instead, 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 (e.g. "The University of Auckland")<vCard:Orgunit>: the division or department (e.g. "Auckland Bioengineering Institute")
<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 (""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:parseType 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 |
|
|
Table 3 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 alternative 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 functionality will almost certainly be expanded in future CellML Metadata specifications. 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 could 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.
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 by 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 (e.g. "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.
5.2.3 The type attribute
The type attribute on the BibliographicReference class identifies the "genre" of the cited resource. The BQS data model provides constructs for the following types of references:
"Article"(subclassed into"JournalArticle", for journal articles, and"BookArticle", for book chapters)."Book""Patent""Proceeding""TechReport"(note that this can be used for unpublished reports)"Thesis""WebResource"
It is possible to create additional types of references using the BQS data model. The basic information would be provided by the BibliographicReference class. Information specific to the new type of reference would need to be provided as a subclass by the person wishing to create the new reference type.
Each of the above genres is given its own element inside the BQS namespace. Figure 27 shows the use of the <bqs:JournalArticle> element.
Figure 27 Serialization of reference type information using type=JournalArticle as an example. See text for more information. The description of a journal article is left out for the time being.
5.2.4 The title attribute
The title attribute on the BibliographicReference class is used to store the title of the resource being referenced. For instance, if the referenced resource is a book chapter, the title metadata would be the title of the chapter.
The title metadata is identified with the Dublin Core <dc:title> element, as shown in Figure 28. An xml:lang attribute could be used to indicate the language of the title.
Figure 28 Serialization of reference title information.
5.2.5 The rights attribute
The rights attribute on the BibliographicReference class provides information about the rights over the cited resource. This attribute would typically contain either a statement of the rights or a reference to a resource (such as a web page) that states the rights. Rights information may include intellectual property rights and copyrights. No assumptions can be made about the rights on the resource in the absence of this attribute.
This rights attribute maps directly to the Dublin Core <dc:rights> element. The serialization is shown in Figure 29.
Figure 29 Serialization of reference rights information.
5.2.6 The language attribute
The language attribute on the BibliographicReference class defines the language of the cited resource. Using the RFC1766 encoding scheme for this information is recommended. Language metadata can be stored using the qualified Dublin Core language qualifier <dcterms:RFC1766> element, as shown in Figure 30.
Figure 30 Serialization of language information. This metadata indicates the content of the cited resource is written in United Kingdom English.
5.2.7 The format attribute
The format attribute on the BibliographicReference class describes the "physical or digital manifestation of the cited resource". The value of this attribute will depend heavily on the reference type. For instance, a web resource reference might have format values of application/pdf or text/html. This serialization of the BQS data model will not attempt to extend the values of this attribute beyond what is provided by the Dublin Core.
The Dublin Core recommends using the Internet Media Type (IMT) encoding scheme for formats, commonly called MIME types. A list of these types is provided by the Internet Assigned Numbers Authority. The format metadata is serialized using the qualified Dublin Core format qualifier <dcterms:medium> element, which is further qualified with a nested <dcterms:IMT>, as shown in Figure 31.
Figure 31 Serialization of format information. This metadata indicates the content of the cited resource is in the PDF format.
5.2.8 The date attribute
The date attribute on the BibliographicReference class "defines a date associated with an event in the life cycle of the cited resource". For public resources, this should be the publication date. For private resources (such as unpublished technical reports), this should be the creation date.
Date metadata can be stored in a date-qualified Dublin Core element, as shown in Figure 32.
Figure 32 Serialization of date information. This metadata indicates the cited resource was published on April 23, 1997 (note that the W3C-DTF encoding allows full dates, month/year dates, and year-only dates).
5.2.9 The authors attribute
The authors attribute stores information about the authors of the cited reference. Its value is an instance of the Provider class. The serialization of this class is discussed in Section 5.3. If there is more than one author for the reference, the BQS data model requires that these authors be stored in an ordered list.
The authors attribute can be serialized using the Dublin Core <dc:creator> element. Multiple authors can be stored in an <rdf:Seq> container, which creates an ordered list.
Figure 33 demonstrates how to store author metadata.
Figure 33 Serialization of author information. The <rdf:Seq> container creates an ordered list of authors. Information about the authors is stored using vCard. To save space in this example, the first author is given an e-mail address, the second author an affiliation, and the third author a postal address. For an actual reference, all authors could have all three types of information. Alternatively, only the authors' names might be available.
5.2.10 The contributors attribute
The contributors property can be used to store information about a person or entity that contributed to, but did not create, the reference. It can be serialized using the Dublin Core <dc:contributor> element, as shown in Figure 34. If there is more than one contributor, the <rdf:Seq> container can be used to create an ordered list, as was done for the author property.
Figure 34 Serialization of contributor information. An organisation (in this example, a company) is listed. This company may have provided graphics work for the cited reference. In this example, there is only one contributor. However, an <rdf:Seq> container could be used to create an ordered list of contributors, as was done in the author example. If the contributors were people, information about them could be stored using vCard, as shown in the authors attribute example.
5.2.11 The publisher attribute
The publisher attribute stores information about the publisher of the reference. It can be serialized using the Dublin Core <dc:publisher> element, as shown in Figure 35. Only one publisher is allowed, so no RDF containers may be used in this element.
Figure 35 Serialization of publisher information. A software service is the publisher of the reference in this example.
5.3 The Provider class
The Provider class is the base class for the Person, Organization, and Service classes. These classes are used by the authors, contributors, and publisher attributes on the BibliographicReference class. The BQS data model allows only one publisher and requires that the authors and contributors be provided as an ordered list.
The Provider class is serialized by embedding the information directly in the RDF element that serializes the authors, contributors, publisher, or editor attribute. Multiple providers are supported using an <rdf:Seq> container. The subclass of provider is given its own element. The valid values are <bqs:Person>, <bqs:Organization> (or <bqs:Organisation>), and <bqs:Service>.
5.3.1 The Person subclass
Structured information about a person can be stored using the appropriate vCard constructs. See Section 2.3 for more information on vCard in CellML Metadata. Figure 33 demonstrates the use of the <bqs:Person> element.
5.3.2 The Organization and Service subclasses
The organisation and service information is a name stored as a string. This can be entered directly as the content of an RDF element. Examples of the use of the Organization and Service subclasses are shown in Figure 34 and Figure 35.
5.4 The BibRefSubject class
The BibRefSubject class defines the topic of the resource. It has three attributes, keywords, subheadings and codes, which provide a means to store keywords, subject headings, and classification codes about the cited resource, respectively.
An example demonstrating the serialization of subject metadata is shown in Figure 36.
Figure 36 Serialization of subject information. The three types of subject information are shown. First, an unordered group of subject headings is provided, encoding in the MeSH controlled vocabulary. Next, the Dewey Decimal System classification code is provided. Finally, an ordered group of uncontrolled keywords is provided.
The formal mapping of the attributes in the BibRefSubject class to RDF is as follows:
- keywords:
<bqs:keyword>, no Dublin Core Qualifier elements. - subheadings:
<bqs:subject_heading>, Dublin Core Qualifier elements of<dcterms:LCSH>(Library of Congress Subject Headings) or<dcterms:MESH>(Medical Subject Headings). - codes:
<bqs:classification_code>, Dublin Core Qualifier elements of<dcterms:DDC>(Dewey Decimal Classification), LCC (Library of Congress Classification), or<dcterms:UDC>(Universal Decimal Classification).
In all cases, multiple values should be stored in the appropriate RDF container.
5.5 The BibRefDescription class
The BibRefDescription class allows storage of a summary of the contents of the cited reference. This summary could be an abstract or a table of contents and may be in a language different from that of the actual reference. More than one summary may be stored about a reference. The BQS Specification states that the contents of the abstract and table of contents attributes may be more than just plain text and proposes using MIME types to identify the format of these contents.
The the_abstract and table_of_contents attributes are serialized using the Dublin Core Qualifier elements, <dcterms:abstract> element and <dcterms:tableOfContents>, respectively. The language attribute can be indicated by an xml:lang attribute. Note that an <rdf:Alt> container can be used to provide the description in various languages.
The abstract_type and toc_type attributes are serialized with the Dublin Core <dcterms:IMT> element (this indicates the use of a MIME type for the value of the format element). The full serialization of description metadata is shown in Figure 37.
If the abstract or table of contents is supplied by a URL, the URL should be entered as the value of an rdf:resource attribute on the <dcterms:abstract> or the <dcterms:tableOfContents> element. This is shown for the abstract information in Figure 37.
Figure 37 Serialization of description information. In this example, the abstract is provided as a URL, and the table of contents is provided inline, in HTML.
5.6 The BibRefScope class
The BibRefScope class is used to provide information about the intended scope or extent of the cited reference. It can include spatial location information and/or temporal period information in its spatial_location and temporal_period attributes.
This metadata can be mapped directly to the Dublin Core <dc:coverage> element, qualified to indicate whether the coverage is spatial or temporal and to provide the encoding scheme of the content. The qualifiers <dcterms:spatial> and <dcterms:temporal> and their corresponding encoding schemes are listed in Table 3. Two instances of this element can be used to include both spatial and temporal information.
Figure 38 shows the serialization of the scope metadata.
Figure 38 Serialization of scope information. This metadata indicates the cited resource has a temporal scope of one year (1997) and a spatial scope of a single country (the Bahamas).
5.7 The EntryStatus class
The EntryStatus class provides information about the citation, as opposed to the cited reference. It has three attributes. The last_modified_date attribute defines the date on which the citation was last changed. The subset attribute defines the subset of the bibliographic repository from which the current citation was taken. The properties attribute is a member of the Property class and takes the form property name: property value. The properties attribute can be used to supply general properties about the citation. For instance, it could be used to provide a version number for the citation. The Property class is discussed in Section 5.9.
This metadata is about the citation, not the reference. Therefore, it must be contained in a new RDF resource. To remain consistent with the class name we use the element <bqs:EntryStatus>. This resource can have three types of metadata:
- A last modified date, stored in a qualified Dublin Core
<dcterms:modified>element, as shown in Figure 39 - A subset, stored in a
<bqs:subset>element, as shown in Figure 39 - A property, stored as defined in Section 5.9
Figure 39 Serialization of entry status information. The last modified date is stored using standard Dublin Core elements. The subset information is stored in a BQS-specific element. The subset in this example is completely fictitious.
5.8 The Journal class
The Journal class stores information about journals and is referenced by the JournalArticle, a subclass of the BibliographicReference class. The Journal class has three attributes: issn (the International Standard Serial Number for the journal), name (the full name of the journal), and abbreviation (an abbreviation for the journal).
There are two possible uses for this class. One is to create a list of journals, which can be referenced by citations of type "JournalArticle". The other is to indicate the journal for a particular bibliographic reference. The same serialization can be used in both cases. In the latter case, it is likely that only the name or abbreviation of the journal would be provided.
Journal information is stored in a <bqs:Journal> element. The attributes of the Journal class are serialized with the Dublin Core <dc:title> element for the name of the journal, a <bqs:issn> element for the ISSN, and a <bqs:abbreviation> element for the abbreviation.
A <dc:identifier> could be used to store the ISSN. However, this could lead to confusion with the use of the <dc:identifier> element to store a database UI (the identifier and cross_references attributes on the BibliographicReference class). Therefore, in this serialization of the BQS data model, the <dc:identifier> element is used to store the identifier of the citation, not the identifier of the cited resource. A new <bqs:issn> element is created to store the identifier of the journal resource.
The <bqs:abbreviation> element is qualified by a <bqs:abbreviation_scheme> element. This is necessary because there is not a single list of standard journal abbreviations. This element may take on any value. However, we recommend the use of the following:
Medline: Most biological and medical journals are indexed by Medline.CAS: The Chemical Abstract Service abstracts chemical journals.
Use of the <bqs:abbreviation> element without a <bqs:abbreviation_scheme> element can be inferred to mean that the abbreviation is not necessarily taken from a standard list. In this case, the full name of the journal or the ISSN should also be provided.
Figure 40 demonstrates the definition of information about a journal. Note that this example is not part of a <bqs:reference> resource. This means that the journal is being defined as its own resource. By giving the <rdf:Description> element that contains the <bqs:Journal> element an rdf:id attribute, we allow other resources to refer to this one. For instance, we could create a collection of journals, and refer to a journal in this collection in a reference of type "JournalArticle" using the value of the id attribute of the journal.
Figure 40 Serialization of journal information. This example shows how to create a new journal resource to which other RDF resources may refer.
Examples in Section 5.10.2 demonstrate possible methods for referring to journals in journal article references.
5.9 The Property class
The Property class can be referenced by the BibliographicReference, Journal, Provider, BibRefScope, and EntryStatus classes to add properties to the data model. The Property class provides a general way to extend the data model. Note that the data model can also be extended by creating new RDF elements in a non-BQS namespace.
The Property class can be serialized with a qualified <bqs:Property> attribute, as follows:
- property_name =
<bqs:property_type> - property_value =
<rdf:value>
If format information is required, a Dublin Core <dc:format> element is used, as described for the BibRefDescription class.
Figure 41 shows the serialization of the Property class.
Figure 41 Serialization of property information. In this example, a new property called "online" is introduced. This propertry indicates whether or not the full text of the article is available online.
Figure 42 shows the use of a <bqs:Property> element to store the location of a publisher. This information is commonly provided when referencing a book.
Figure 42 The use of a property to provide the location of a publisher.
5.10 Subclasses of the BibliographicReference Class
The BQS data model provides seven basic subclasses of the BibligraphicReference class, one of which is further subclassed. In addition, users can create their own type of BibliographicReference. To do this in the RDF serialization, the user would supply a new value for the type attribute on the BibliographicReference class, and provide any additional information either by using the Property class (discussed in Section 5.9) or by defining his/her own RDF schema for that reference type.
The Thesis, Proceeding, and TechReport subclasses do not define any additional attributes. The other subclasses are discussed in the following subsections.
5.10.1 The Book subclass
The Book subclass has five attributes, which are mapped onto BQS elements as follows:
- isbn (the International Standard Book Number) =
<bqs:isbn>(A<dc:identifier>element could be used to store the ISBN. However, this could lead to confusion with the use of the<dc:identifier>element to store a database UI (the identifier and cross_references attributes on the BibliographicReference class). Therefore, in this serialization of the BQS data model, the<dc:identifier>element is used to store the identifier of the citation, not the identifier of the cited resource. A new<bqs:isbn>element is created to store the identifier of the book resource.) - volume =
<bqs:volume>(This element is also used in the serialization of the JournalArticle subclass.) - edition =
<bqs:edition> - series (the title of the series of which the book is a member) =
<bqs:series> - editor =
<bqs:editor>. Personal information about the editor (name, e-mail, etc.) is provided by the serialization of the Provider class (see Section 5.3).
Figure 43 demonstrates the storage of book information. Note that a real reference to a book would also include elements from the BibliographicReference class. Section 5.11 has several complete reference examples that demonstrate the use of information from the various BQS data model classes.
Figure 43 Serialization of book information. This example is fictitious.
5.10.2 The Article subclass and its subclasses
The Article class has two attributes: first_page and last_page. In addition, it has two further subclasses: JournalArticle, which has volume, issue, issue_supplement and from_journal attributes, and BookArticle, which has a from_book attribute.
The attributes on the Article, JournalArticle and BookArticle classes are serialized using the same elements:
- first_page =
<bqs:first_page> - last_page =
<bqs:last_page> - volume =
<bqs:volume>(This element is also used in the serialization of the Book subclass.) - issue =
<bqs:issue> - issue_supplement =
<bqs:issue_supplement> - from_journal =
<bqs:Journal>, as described in Section 5.8 - from_book =
<bqs:Book>
Figure 44 shows the definition of journal article metadata. In this example, the journal information is included inline. Figure 45 shows the definition of journal article metadata. In this example, the journal information is included by reference to another resource (such as a journal definition as shown in Figure 40). Figure 46 shows the definiton of book chapter metadata. Note that these examples only show the metadata specific for these subclasses of BibliographicReference. Section 5.11 will provide several examples of complete citations.
Figure 44 Serialization of journal article information. In this example, the journal information is provided inline.
Figure 45 Serialization of journal article information. In this example, the journal information is provided by referring to the resource created in Figure 40.
Figure 46 Serialization of book article information. This example is a chapter from the book shown in Figure 43. The second <bqs:reference> element in this example stores information about the book.
5.10.3 The Patent subclass
The Patent subclass has four attributes, which are serialized as follows:
- doc_number =
<bqs:doc_number>(A<dc:identifier>element could be used to store the patent number. However, this could lead to confusion with the use of the<dc:identifier>element to store a database UI (the identifier and cross_references attributes on the BibliographicReference class). Therefore, in this serialization of the BQS data model, the<dc:identifier>element is used to store the identifier of the citation, not the identifier of the cited resource. A new<bqs:doc_number>element is created to store the identifier of the patent resource.) - doc_office =
<bqs:doc_office> - doc_type =
<bqs:doc_type> - applicant =
<bqs:applicant>(Creating a<bqs:applicant>element was chosen over using the<dc:creator>element to avoid potential confusion concerning who the<dc:creator>element might refer to - inventor(s) or applicant.)
Figure 47 demonstrates the storage of patent information.
Figure 47 Serialization of book article information.
5.10.4 The WebResource subclass
The WebResource subclass has three attributes, which can be serialized as follows:
- url = an
rdf:resourceattribute with the value of the url (A<dc:identifier>element could be used to store this information. However, this could lead to confusion with the use of the<dc:identifier>element to store a database UI (the identifier and cross_references attributes on the BibliographicReference class). Therefore, in this serialization of the BQS data model, the<dc:identifier>element is used to store the identifier of the citation, not the identifier of the cited resource. A new<bqs:url>element is created to store the identifier of the web resource.) - estimated_size =
<bqs:estimated_size>. The units are assumed to be in kilobytes unless otherwise indicated with the use of a<bqs:Property>element (see Section 5.9 for more information on this element). - cost =
<bqs:cost>. The units of the cost can be stored in<bqs:Property>element (see Section 5.9 for more information on this element).
Figure 48 shows the definition of information about a web resource.
Figure 48 Serialization of web resource information.
5.11 Complete Examples
This section provides several complete citation examples.
5.11.1 Journal article with inline journal definition
Figure 49 demonstrates the definition of a reference to a journal article with the journal information included inline. The cited reference is:
Jafri, M.S., Rice, J.J., Winslow, R.L. "Cardiac Ca2+ dynamics: the role of ryanodine receptor adaptation and sarcoplasmic reticulum load" (1998) Biophys J 74: 1149-1168.
Figure 49 A complete journal article reference. Information about the journal itself is embedded within the reference.
5.11.2 Journal article with a reference to a journal definition
Figure 50 demonstrates the definition of a reference to a journal article with the journal information included by reference to a resource defined elsewhere. Figure 51 demonstrates the definition of the journal information. The cited reference is the same as that in Section 5.11.1.
Figure 50 A complete journal article reference that refers to a different resource for information about the journal. The definition of the journal information is shown in Figure 51.
Figure 51 Information about two journals. This information could be referenced by bibliographic citations defined in the <bqs:reference> element.
5.11.3 Citation by unique identifier
Figure 52 demonstrates the citation of a reference using a database unique identifer. In this example, a Medline unique identifier is used. An abstract is also included, by reference to a URL.
Figure 52 Citation by Medline unique identifier and inclusion of a reference to an abstract.
5.11.4 Complete book
Figure 53 shows a relatively simple complete book reference. The cited reference is:
Branden, C., Tooze, J. "Introduction to Protein Structure" (1991) Garland Publishing, Inc., New York.
Figure 53 A complete book reference. Note the use of the Property class to provide the location of the publisher.
Figure 54 shows a more complicated reference to a book. The cited reference is:
Brody, J.S., Center, D.M., Tkachuk, V.A., Eds. "Signal Transduction in Lung Cells" (1993) Lung Biology in Health and Disease, 65. Marcel Dekker, Inc. New York.
Figure 54 A more complicated complete book reference.
5.11.5 Book chapter
Figure 55 shows a complete book chapter reference. The cited reference is:
Rogers, M.S., Strehler, E.E. "Calmodulin-like proteins" in Guidebook to the Calcium-Binding Proteins, Celio, M.R., Pauls, T., Schwaller, B., eds. (1996) Oxford University Press, Oxford. pp. 41-43.
Figure 55 A book chapter reference. (Some whitespace has been removed in order to fit the example on a single page.)
6 Appendix
6.1 Cmeta Terms RDF Schema Draft
6.2 BQS Terms RDF Schema Draft
