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

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 the larger scientific 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 scientific 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.

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 pushing for a ``semantic web'', in which resources on the web would include the semantic information necessary to allow machines to understand (not just read) them. The W3C has set up a semantic web activity. Some software projects, such as Mozilla, have begun trying to take advantage of the metadata that is currently available about web resources.

The ``semantic web'' vision is one of the future and not of today. Several projects are beginning to take tentative steps towards realizing Tim Berners-Lee's dream, but success is by no means certain. The library science community is leading the way in implementing metadata. A consequence of this is that the tools being provided for handling metadata on the web (such as the Resource Description Framework, or RDF) have come from the knowledge management community. Like any academic discipline, that community has its own jargon, which can be a hindrance to many who try to understand and use these tools. However, several projects are now using RDF, and a variety of tools have been created for it.

None of the problems faced by the nascent metadata community are insurmountable. It seems very likely that something resembling the ``semantic web'' will come into existence, if for no reason other than the importance of the problem it is attempting to address. Therefore, the CellML development team is working to make CellML compatible with the semantic web activity.

The CellML development team has decided to use existing standards wherever possible to describe metadata for reasons listed below. This section describes our use of RDF, Dublin Core, vCard, BQS, and our own CellML Metadata.

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.

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. Furthermore, 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 pairs.

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 model creator property. This could be given a simple value of the creator's name, such as John 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. Why bother doing this? Because it also 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 favorite 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. See the W3C's RDF project list for a list of tools and projects using RDF.

The RDF Model and Syntax Specification allows multiple methods for expressing the same information. Perhaps the reason it does so has to do with the fundamental database design principles of generalize whenever possible and overload your classes as much as possible. This is effective database design because generalizing and overloading are both useful techniques to create a flexible data model that will handle new types of information as they become necessary. Mapping each type of information to a column in a database table (or an element in an XML schema) requires that new types of information be stored in new columns (or elements). A generalized structure that handles an entire class of information allows the handling of any type of information without changing a previously specified schema.

The CellML development team has picked one way of expressing metadata in RDF and sticks with the same method throughout the CellML Metadata 1.0 Specification. 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.

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 folks. These properties are things like creator, publisher, subject, and date. A full list, with 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 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 published 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.

Though not all of the Dublin Core elements are immediately applicable to CellML Metadata requirements, many of them do fulfill those requirements. This 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, it makes it more 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 dcq will indicate that elements and attributes are in the Dublin Core and the Dublin Core Qualifiers namespaces, respectively.

It seems 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 fast becoming the standard method of 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, which maps to the CellML requirement to be able to store a person's affiliation), 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. Note that one address may be given more than one type. See section 3.3 of the vCard in RDF document for more info.

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.

No bibliographic standards yet exist within RDF/XML. 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. BQS metadata is designated by the namespace prefix bqs in this specification.

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.

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 that attribute preceded by a hash (#). In CellML, the attribute referred to is the cmeta:id attribute on any element.

RDF is processed as triplets. 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 4 A set of two RDF triplets, 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 triplets. 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.

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

Model builder metadata stores information about the person or persons who coded the model into CellML. A given element can have multiple model builders 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 builder 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 builder.

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

The publisher is the person or organization responsible for providing the model, model component, or other CellML element. A given CellML element can have multiple publishers.

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

<rdf:Descriptionrdf:about=""><dc:publisher>
University of Auckland, Bioengineering Research Group</dc:publisher></rdf:Description></rdf:RDF>

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

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.

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, <dcq:creation>. The creation date is further qualified by using the Dublin Core date encoding scheme qualifier element, <dcq:W3CDTF>, which indicates a YYYY-MM-DD format. The definition of creation date metadata is demonstrated in Figure 15.

The modified date is the date upon which the content of a CellML element was changed. The modified date metadata is defined with the Dublin Core date qualifier element, <dcq:modified>. Otherwise, its definition is exactly the same as that of the creation date metadata. The definition of modified date metadata is demonstrated in Figure 16.

Alternative name metadata provides human-readable names for CellML elements. This preferred 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, <dcq: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 <dcq: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''.

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.

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''. The name of the biological entity is defined exactly as alternative names for CellML elements are defined (with the <dcq:alternative> element).

Each database identifier is stored in 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:

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, by putting the <entity_scheme> element in an application-specific namespace. However, software claiming to be ``CellML metadata compliant'' is not required to recognize these schemes.

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 identical. ``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.

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 ... However, CellML Metadata compliant software is not required to recognize any classification scheme other than the GAMS tree.

Description metadata is a short description of the referenced resource.

Description metadata is defined with either of the Dublin Core description qualifier elements, <dcq:abstract> or <dcq:tableOfContents>. Use of the <dcq:abstract> element will probably be most common in CellML Metadata.

There are four 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 four:

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.

modification: description of a change made to 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.

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 builder 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 modification and validation annotations.

<rdf:Descriptionrdf:about="#cellml_element_id"><cmeta:commentrdf:parseType="Resource"><rdf:value>This model does not include the data of Jones, et al.
about the corresponding pathway in canine.</rdf:value><dc:creator><vCard:Nrdf:parseType="Resource"><vCard:Family>PowerPuff</vCard:Family><vCard:Given>Bubbles</vCard:Given></vCard:N></dc:creator><dcq:created><dcq:W3CDTF>2001-04-01</dcq:W3CDTF></dcq:created></cmeta:comment><cmeta:limitationrdf:parseType="Resource"><rdf:value>
This component is only valid for temperatures above 20 degrees C.</rdf:value><dc:creator><vCard:Nrdf:parseType="Resource"><vCard:Family>Doo</vCard:Family><vCard:Given>Scooby</vCard:Given></vCard:N></dc:creator><dcq:created><dcq:W3CDTF>2001-03-28</dcq:W3CDTF></dcq:created></cmeta:limitation></rdf:Description></rdf:RDF>

<rdf:Descriptionrdf:about="#cellml_element_id"><cmeta:modificationrdf:parseType="Resource"><rdf:value>Changed the equation for the sodium current.</rdf:value><dc:creator><vCard:Nrdf:parseType="Resource"><vCard:Family>PowerPuff</vCard:Family><vCard:Given>Bubbles</vCard:Given></vCard:N></dc:creator><dcq:created><dcq:W3CDTF>2001-04-01</dcq:W3CDTF></dcq:created></cmeta:modification><cmeta:validationrdf:parseType="Resource"><rdf:value>Physiome level 2</rdf:value><dc:creator><vCard:Nrdf:parseType="Resource"><vCard:Family>Too</vCard:Family><vCard:Given>Shaggy</vCard:Given></vCard:N></dc:creator><dcq:created><dcq:W3CDTF>2001-03-28</dcq:W3CDTF></dcq:created></cmeta:validation></rdf:Description></rdf:RDF>

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.

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:

Medline for the identifier that is common to all implementations of the Medline database.

PubMed for the identifier used only by the PubMed implementation of the Medline database.

CAS for 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.

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 a second database identifier element qualified by a nested <bqs:alternative> element, as shown in Figure 26.

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"

Note that 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.

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. Note that an xml:lang attribute could be used to indicate the language of the title.

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.

The language attribute on the BibliographicReference class defines the language of the cited resource. The CellML development team, as well as the BQS data model, recommends using the RFC1766 encoding scheme for this information. Language metadata can be stored using the qualified Dublin Core language qualifier <dcq:RFC1766> element, as shown in Figure 30.

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 Information Sciences Institute at the University of Southern California. The format metadata is serialized using the qualified Dublin Core format qualifier <dcq:medium> element, which is further qualified with a nested <dcq:IMT>, as shown in Figure 31.

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.

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. All of the authors are people.

<rdf:Descriptionrdf:about="#cellml_element_id"><bqs:referencerdf:parseType="Resource"><dc:creator><rdf:Seq><rdf:li><bqs:Personrdf:parseType="Resource"><vCard:Nrdf:parseType="Resource"><vCard:Family>Yang</vCard:Family><vCard:Given>T</vCard:Given></vCard:N><vCard:EMAILrdf:parseType="Resource"><rdf:value>phoney@nowhere.com</rdf:value><rdf:typerdf:resource="http://imc.org/vCard/3.0#internet" /></vCard:EMAIL></bqs:Person></rdf:li><rdf:li><bqs:Personrdf:parseType="Resource"><vCard:Nrdf:parseType="Resource"><vCard:Family>Snyders</vCard:Family><vCard:Given>D</vCard:Given><vCard:Other>J</vCard:Other></vCard:N><vCard:ORGrdf:parseType="Resource"><vCard:Orgname>
Vanderbilt University School of Medicine</vCard:Orgname><vCard:Orgunit>Department of Pharmacology</vCard:Orgunit></vCard:ORG></bqs:Person></rdf:li><rdf:li><bqs:Personrdf:parseType="Resource"><vCard:Nrdf:parseType="Resource"><vCard:Family>Roden</vCard:Family><vCard:Given>D</vCard:Given><vCard:Other>M</vCard:Other></vCard:N><vCard:ADRrdf:parseType="Resource"><vCard:Extadd>
Dept. of Pharmacology,
Vanderbilt University School of Medicine</vCard:Extadd><vCard:Locality>Nashville</vCard:Locality><vCard:Region>TN</vCard:Region><vCard:Pcode>37232-6602</vCard:Pcode><vCard:Country>USA</vCard:Country></vCard:ADR></bqs:Person></rdf:li></rdf:Seq></dc:creator></bqs:reference></rdf:Description></rdf:RDF>

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.

The contributors class 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 authors class.

Figure 34 Serialization of contributor information. An organization (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 example.

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.

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

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.

The organisation and service information is a name stored as a string. This can be entered directly as the content of an RDF element. However, in some cases it is useful to provide the geographic location of the organization. For instance, this information is usually provided for the publisher of a book. This can be supported using the Property class, as discussed in Section 5.9. In this case, the name of the organisation is stored as element content contained in the <dc:publisher> element. Examples of the use of the Organization and Service subclasses are shown in Figure 34 and Figure 35.

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, ecnoding 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:

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 can be serialized using a <dc:description> element. This element can be qualified with type information to indicate whether the description is an abstract or a table of contents. This is done by using a <dcq:abstract> element and a <dcq:tableOfContents> element. These qualifier elements are taken from the document Expressing Qualified Dublin Core in RDF/XML. 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 can be serialized with the Dublin Core <dcq: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 the <dc:description> element, and the value of the enclosed <dcq:IMT> element should be text/url. This is shown for the abstract information in Figure 37.

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 <dcq:spatial> and <dcq:temporal> and a number of encoding schemes are defined in the Dublin Core Qualifiers specification. Two instances of this element can be used to include both spatial and temporal information.

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 will be dealt with 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:entry_status>. This resource can have three types of metadata:

A last modified date, stored in a qualified Dublin Core <dcq:modified> element, as shown in Figure 39

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.

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

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.

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

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.

The Book subclass has five attributes, which are mapped onto BQS elements as follows:

isbn (the International Standard Book Number) = <bqs:isbn> (Note that 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> (note: 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.

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 can be serialized using the same elements:

first_page = <bqs:first_page>.

last_page = <bqs:last_page>.

volume = <bqs:volume> (note that this element is also used in the serialization of the Book subclass).

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.

The WebResource subclass has three attributes, which can be serialized as follows:

url = <bqs:url> (Note that 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 of the estimated size can be stored in <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 49 demonstrates the definition of a reference to a journal article, with the journal information included by reference to a resource defined elsewhere. Figure 50 demonstrates the definition of the journal information. The cited reference is the same as that in Section 5.11.1.

Figure 49 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 50.

<!--
This RDF is part of the file http://www.example.org/journals
--><rdf:RDFxmlns:bqs="http://www.cellml.org/bqs/1.0#"xmlns:dc="http://purl.org/dc/elements/1.1/"xmlns:dcq="http://purl.org/dc/terms/"xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">

<rdf:Descriptionrdf:about="#cellml_element_id"><bqs:referencerdf:parseType="Resource"><bqs:Medline_id>97219925</bqs:Medline_id><dcq:abstract><dcq:IMT>text/url</dcq:IMT><!--
Note that the URI below, would not normally be split over two lines.
It has been split so that it fits on a page
--><rdf:value>
http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?
cmd=Retrieve&db=PubMed&list_uids=9067300&dopt=Abstract</rdf:value></dcq:abstract></bqs:reference></rdf:Description></rdf:RDF>

Figure 51 Citation by Medline unique identifier and inclusion of a reference to an abstract.

<rdf:RDFxmlns:bqs="http://www.cellml.org/bqs/1.0#"xmlns:dc="http://purl.org/dc/elements/1.1/"xmlns:dcq="http://purl.org/dc/terms/"xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"xmlns:vCard="http://www.w3.org/2001/vcard-rdf/3.0#"><rdf:Descriptionrdf:about="#cellml_element_id"><bqs:BookArticle><dc:creator><rdf:Seq><rdf:li><bqs:Person><vCard:Nrdf:parseType="Resource"><vCard:Family>Rogers</vCard:Family><vCard:Given>Michael</vCard:Given><vCard:Other>S</vCard:Other></vCard:N></bqs:Person></rdf:li><rdf:li><bqs:Person><vCard:Nrdf:parseType="Resource"><vCard:Family>Strehler</vCard:Family><vCard:Given>Emanuel</vCard:Given><vCard:Other>E</vCard:Other></vCard:N></bqs:Person></rdf:li></rdf:Seq></dc:creator><bqs:first_page>41</bqs:first_page><bqs:last_page>43</bqs:last_page><dcq:issued><dcq:W3CDTF>1996</dcq:W3CDTF></dcq:issued><bqs:Book><dc:title>Guidebook to the Calcium-Binding Proteins</dc:title><bqs:editor><rdf:Seq><rdf:li><bqs:Person><vCard:Nrdf:parseType="Resource"><vCard:Family>Celio</vCard:Family><vCard:Given>Marco</vCard:Given><vCard:Other>R</vCard:Other></vCard:N></bqs:Person></rdf:li><rdf:li><bqs:Person><vCard:Nrdf:parseType="Resource"><vCard:Family>Pauls</vCard:Family><vCard:Given>Thomas</vCard:Given></vCard:N></bqs:Person></rdf:li><rdf:li><bqs:Person><vCard:Nrdf:parseType="Resource"><vCard:Family>Schwaller</vCard:Family><vCard:Given>Beat</vCard:Given></vCard:N></bqs:Person></rdf:li></rdf:Seq></bqs:editor><dc:publisherrdf:parseType="Resource"><bqs:Organization><rdf:value>Oxford University Press</rdf:value><bqs:propertyrdf:parseType="Resource"><bqs:property_type>location</bqs:property_type><rdf:value>Oxford</rdf:value></bqs:property></bqs:Organization></dc:publisher></bqs:Book></bqs:BookArticle></rdf:Description></rdf:RDF>

Figure 54 A book chapter reference. (Some whitespace has been removed in order to fit the example on a single page.)

<!--Description of this Schema--><rdf:Descriptionrdf:about="&cmetans;"><dc:title>The CellML Metadata Element Set Vocabulary</dc:title><dc:creator>Autumn A. Cuellar</dc:creator><dcq:created><dcq:W3CDTF>2001-11-02</dcq:W3CDTF></dcq:created><dcq:RFC1766>en-uk</dcq:RFC1766><dc:description>
The CellML Metadata Element Set Vocabulary is intended to enable searches
of a CellML model repository of biological models.</dc:description></rdf:Description>

<!--Sex--><rdf:Propertyrdf:about="&cmetans;sex"><rdfs:label>Sex</rdfs:label><rdfs:comment>The sex for which a CellML element is relevant.</rdfs:comment><rdfs:isDefinedByrdf:resource="&cmetans;" /></rdf:Property>

<!--Biological Entity--><rdf:Propertyrdf:about="&cmetans;bio_entity"><rdfs:label>Biological Entity</rdfs:label><rdfs:comment>
A name or database unique identifier for a biological entity.</rdfs:comment><rdfs:isDefinedByrdf:resource="&cmetans;" /></rdf:Property>

<!--Annotation--><rdf:Propertyrdf:about="&cmetans;annotation"><rdfs:label>Annotation</rdfs:label><rdfs:comment>
An annotation that describes the CellML model or model component.</rdfs:comment><rdfs:isDefinedByrdf:resource="&cmetans;" /></rdf:Property>

<!--Annotation:coment--><rdf:Propertyrdf:about="&cmetans;comment"><rdfs:label>Comment</rdfs:label><rdfs:comment>
A free-form comment of the person who coded the model into CellML.</rdfs:comment><rdf:typerdf:resource="&cmetans;annotation" /><rdfs:isDefinedByrdf:resource="&cmetans;" /></rdf:Property>

<!--Annotation:limitation--><rdf:Propertyrdf:about="&cmetans;limitation"><rdfs:label>Limitation</rdfs:label><rdfs:comment>
A description of the limitations/scope of the content of the CellML
element.</rdfs:comment><rdf:typerdf:resource="&cmetans;annotation" /><rdfs:isDefinedByrdf:resource="&cmetans;" /></rdf:Property>

<!--Annotation:modification--><rdf:Propertyrdf:about="&cmetans;modification"><rdfs:label>Modification</rdfs:label><rdfs:comment>
A description of a change made to the content of the CellML element.</rdfs:comment><rdf:typerdf:resource="&cmetans;annotation" /><rdfs:isDefinedByrdf:resource="&cmetans;" /></rdf:Property>

<!--Annotation:validation--><rdf:Propertyrdf:about="&cmetans;validation"><rdfs:label>Validation</rdfs:label><rdfs:comment>
A description of the level of the content of the CellML element.</rdfs:comment><rdf:typerdf:resource="&cmetans;annotation" /><rdfs:isDefinedByrdf:resource="&cmetans;" /></rdf:Property>

<!--Description of this Schema--><rdf:Descriptionrdf:about="&bqsns;"><dc:title>The Bibliographic Query Service Element Set Vocabulary</dc:title><dc:creator>Autumn A. Cuellar</dc:creator><dcq:created><dcq:W3CDTF>2001-11-02</dcq:W3CDTF></dcq:created><dcq:RFC1766>en-uk</dcq:RFC1766><dc:description>
The Bibliographic Query Service Element Set Vocabulary is intended to
enhance searches of any document containing biobliographic references.</dc:description></rdf:Description>

<!--Reference Type:BookArticle--><rdf:Propertyrdf:about="&bqsns;BookArticle"><rdfs:label>BookArticle</rdfs:label><rdfs:comment>
The cited reference is a book article.</rdfs:comment><rdf:typerdf:resource="&bqsns;Article" /><rdfs:isDefinedByrdf:resource="&bqsns;" /></rdf:Property>

<!--Reference Type:Book--><rdf:Propertyrdf:about="&bqsns;Book"><rdfs:label>Book</rdfs:label><rdfs:comment>
The cited reference is a book.</rdfs:comment><rdf:typerdf:resource="&bqsns;reference_type" /><rdfs:isDefinedByrdf:resource="&bqsns;" /></rdf:Property>

<!--Reference Type:Patent--><rdf:Propertyrdf:about="&bqsns;Patent"><rdfs:label>Patent</rdfs:label><rdfs:comment>
The cited reference is a patent.</rdfs:comment><rdf:typerdf:resource="&bqsns;reference_type" /><rdfs:isDefinedByrdf:resource="&bqsns;" /></rdf:Property>

<!--Reference Type:Proceeding--><rdf:Propertyrdf:about="&bqsns;Proceeding"><rdfs:label>Proceeding</rdfs:label><rdfs:comment>
The cited reference is a proceeding.</rdfs:comment><rdf:typerdf:resource="&bqsns;reference_type" /><rdfs:isDefinedByrdf:resource="&bqsns;" /></rdf:Property>

<!--Provider Type--><rdf:Propertyrdf:about="&bqsns;provider_type"><rdfs:label>provider type</rdfs:label><rdfs:comment>
Who the resource is provided by.</rdfs:comment><rdfs:isDefinedByrdf:resource="&bqsns;" /></rdf:Property>

<!--Provider Type:Person--><rdf:Propertyrdf:about="&bqsns;Person"><rdfs:label>Person</rdfs:label><rdfs:comment>
The resource is provided by a person.</rdfs:comment><rdf:typerdf:resource="&bqsns;provider_type" /><rdfs:isDefinedByrdf:resource="&bqsns;" /></rdf:Property>

<!--Provider Type:Organization--><rdf:Propertyrdf:about="&bqsns;Organization"><rdfs:label>Organization</rdfs:label><rdfs:comment>
The resource is provided by an organization.</rdfs:comment><rdf:typerdf:resource="&bqsns;provider_type" /><rdf:seeAlsordf:resource="&bqsns;Organisation" /><rdfs:isDefinedByrdf:resource="&bqsns;" /></rdf:Property>

<!--Provider Type:Organisation--><rdf:Propertyrdf:about="&bqsns;Organisation"><rdfs:label>Organisation</rdfs:label><rdfs:comment>
The resource is provided by an organisation.</rdfs:comment><rdf:typerdf:resource="&bqsns;provider_type" /><rdf:seeAlsordf:resource="&bqsns;Organization" /><rdfs:isDefinedByrdf:resource="&bqsns;" /></rdf:Property>

<!--Provider Type:Service--><rdf:Propertyrdf:about="&bqsns;Service"><rdfs:label>Service</rdfs:label><rdfs:comment>
The resource is provided by a service.</rdfs:comment><rdf:typerdf:resource="&bqsns;provider_type" /><rdfs:isDefinedByrdf:resource="&bqsns;" /></rdf:Property>

<!--Subject Type:Keyword--><rdf:Propertyrdf:about="&bqsns;keyword"><rdfs:label>keyword</rdfs:label><rdfs:comment>
Defines the topic of a resource using keywords.</rdfs:comment><rdfs:typerdf:resource="&dcns;subject_type" /><rdfs:isDefinedByrdf:resource="&bqsns;" /></rdf:Property>

<!--Entry Status--><rdf:Propertyrdf:about="&bqsns;entry_status"><rdfs:label>Entry Status</rdfs:label><rdfs:comment>
Provides information about the citation, as opposed to the cited
reference.</rdfs:comment><rdfs:isDefinedByrdf:resource="&bqsns;" /></rdf:Property>

<!--Property--><rdf:Propertyrdf:about="&bqsns;property"><rdfs:label>Property</rdfs:label><rdfs:comment>
Provides a property about the reference.</rdfs:comment><rdfs:isDefinedByrdf:resource="&bqsns;" /></rdf:Property>

<!--Book:ISBN--><rdf:Propertyrdf:about="&bqsns;isbn"><rdfs:label>International Standard Book Number</rdfs:label><rdfs:comment>
International Standard Book Number unique identifier.</rdfs:comment><rdfs:isDefinedByrdf:resource="&bqsns;" /></rdf:Property>

<!--Book:Series--><rdf:Propertyrdf:about="&bqsns;series"><rdfs:label>Series</rdfs:label><rdfs:comment>
The title of the series of which the book is a member.</rdfs:comment><rdfs:isDefinedByrdf:resource="&bqsns;" /></rdf:Property>

<!--Article:first_page--><rdf:Propertyrdf:about="&bqsns;first_page"><rdfs:label>First Page</rdfs:label><rdfs:comment>
The first page of the article referenced.</rdfs:comment><rdfs:isDefinedByrdf:resource="&bqsns;" /></rdf:Property>

<!--Article:last_page--><rdf:Propertyrdf:about="&bqsns;last_page"><rdfs:label>Last Page</rdfs:label><rdfs:comment>
The last page of the article referenced.</rdfs:comment><rdfs:isDefinedByrdf:resource="&bqsns;" /></rdf:Property>

<!--Article:last_page--><rdf:Propertyrdf:about="&bqsns;last_page"><rdfs:label>Last Page</rdfs:label><rdfs:comment>
The last page of the article referenced.</rdfs:comment><rdfs:isDefinedByrdf:resource="&bqsns;" /></rdf:Property>

<!--Article:issue--><rdf:Propertyrdf:about="&bqsns;issue"><rdfs:label>Issue</rdfs:label><rdfs:comment>
The issue in which the referenced article is found.</rdfs:comment><rdfs:isDefinedByrdf:resource="&bqsns;" /></rdf:Property>

<!--Article:issue_supplement--><rdf:Propertyrdf:about="&bqsns;issue_supplement"><rdfs:label>Issue Supplement</rdfs:label><rdfs:comment>
The issue supplement in which the referenced article is found.</rdfs:comment><rdfs:isDefinedByrdf:resource="&bqsns;" /></rdf:Property>

<!--WebResource:cost--><rdf:Propertyrdf:about="&bqsns;cost"><rdfs:label>Cost</rdfs:label><rdfs:comment>
The cost of the Web Resource.</rdfs:comment><rdfs:isDefinedByrdf:resource="&bqsns;" /></rdf:Property></rdf:RDF>

<dcq:creation> & <dcq:w3CDTF> now replace <dc:date> with the value "created", <dcq:dateType> and <dcq:dateScheme>.

Section 4.6: Modified Date

<dcq:modified> replaces the <dcq:dateType> with the value of "modified".

Section 4.7: Alternative Names

<dcq:alternative> replaces <dcq:titleType> with the value of "alternative".

Section 4.9: Sex

The addition of the controlled vocabulary "other" and "all"
has been made.

Section 4.10: Biological Entity

Alternative biological entity names are now
described using the <dcq:alternative> element within <cmeta:bio_entity> element. This replaces the previous <dc:title> qualified by a <dcq:titleType> with the value "alternative".