| Working Draft - 2 November 2001 | |
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.
The latest version of the CellML Metadata specification can always be found on the CellML website.
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.
Information about RDF can be found on the W3C's Resource Description Framework (RDF) Page.
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.
Information about the Dublin Core can be found on the Dublin Core's website.
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.
Namespace URIs and recommended prefixes are given in Table 1.
| 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/" | dcq | | BQS | "http://www.cellml.org/bqs/1.0#" | bqs |
Table 1
The names, URIs and recommended prefixes of the namespaces referenced in this specification.
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.
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:rdf:about="#some_element_id">
...
</rdf:Description>
</rdf: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.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:toon="http://www.cartoon_times.com/what_namespace">
<rdf:Description rdf:rdf:about="#Wilma_Flintstone">
<toon:spouse>Fred Flintstone</toon:spouse>
</rdf:Description>
</rdf:RDF>
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.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:toon="http://www.cartoon_times.com/what_namespace">
<rdf:Description rdf:rdf:about="#Wilma_Flintstone">
<toon:spouse rdf:rdf:id="spouse">Fred Flintstone</toon:spouse>
</rdf:Description>
<rdf:Description rdf:rdf:about="#spouse">
<toon:favourite_hobby>bowling</toon:favourite_hobby>
</rdf:Description>
</rdf:RDF>
Figure 3 A set of two RDF triplets, in which the second <rdf:Description> element describes Wilma's spouse, as indicated by the second rdf:about attribute.
Figure 4 shows an alternate method to describe the two triplets shown in Figure 3.
The second <rdf:Description> element is embedded in the <toon:spouse> element to indicate that it is a new resource.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:toon="http://www.cartoon_times.com/what_namespace">
<rdf:Description rdf:rdf:about="#Wilma_Flintstone">
<toon:spouse>
<rdf:Description>
<rdf:value>Fred Flintstone</rdf:value>
<toon:favourite_hobby>bowling</toon:favourite_hobby>
</rdf:Description>
</toon:spouse>
</rdf:Description>
</rdf:RDF>
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:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:toon="http://www.cartoon_times.com/what_namespace">
<rdf:Description rdf:rdf:about="#Wilma_Flintstone">
<toon:spouse rdf:parseType="Resource">
<rdf:value>Fred Flintstone</rdf:value>
<toon:favourite_hobby>bowling</toon:favourite_hobby>
</toon:spouse>
</rdf:Description>
</rdf:RDF>
Figure 5 The rdf:parstType attribute with a value of "resource" is another way to introduce a new resource. In this case the new resource is <toon:spouse>.
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.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:toon="http://www.cartoon_times.com/what_namespace">
<rdf:Description rdf:rdf:about="#Jetsons">
<toon:family_member>
<rdf:Bag>
<rdf:li>George</rdf:li>
<rdf:li>Jane</rdf:li>
<rdf:li>Judy</rdf:li>
<rdf:li>Elroy</rdf:li>
<rdf:li>Astro</rdf:li>
<rdf:li>Rosie</rdf:li>
</rdf:Bag>
</toon:family_member>
</rdf:Description>
</rdf:RDF>
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.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:toon="http://www.cartoon_times.com/what_namespace">
<rdf:Description rdf:rdf:about="#Jetsons">
<toon:age rdf:parseType="Resource">
<rdf:Seq>
<rdf:li>George</rdf:li>
<rdf:li>Jane</rdf:li>
<rdf:li>Judy</rdf:li>
<rdf:li>Elroy</rdf:li>
<rdf:li>Astro</rdf:li>
<rdf:li>Rosie</rdf:li>
</rdf:Seq>
</toon:age>
</rdf:Description>
</rdf:RDF>
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.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:toon="http://www.cartoon_times.com/what_namespace">
<rdf:Description rdf:rdf:about="#companies">
<toon:supply rdf:parseType="Resource">
<rdf:Alt>
<rdf:li>Spacely's Space Sprockets</rdf:li>
<rdf:li>Cogswell's Coggs</rdf:li>
</rdf:Alt>
</toon:supply>
</rdf:Description>
</rdf:RDF>
Figure 8 The <rdf:Alt> element implies that any one of the listed values is valid.
The Dublin Core Metadata Elements and their corresponding qualifiers are listed in Table 2.
| 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 |
|
DCMI Point
ISO 3166
DCMI Box
TGN |
DCMI Period
W3C-DTF |
|
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.
<rdf:RDF
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:rdf:about="#toon_times">
<dc:title>Toonville Times</dc:title>
<dc:creator>R.J. Gopher</dc:creator>
<dc:date>2001-10-18</dc:date>
</rdf:Description>
</rdf:RDF>
Figure 9 Each Dublin Core Metadata Element is its own element in the Dublin Core namespace.
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.
<rdf:RDF
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:vCard="http://www.w3.org/2001/vcard-rdf/3.0#">
<rdf:Description rdf:about="#cellml_element_id">
<dc:creator>
<vCard:N rdf:parseType="Resource">
<vCard:Family>Flintstone</vCard:Family>
<vCard:Given>Fred</vCard:Given>
</vCard:N>
</dc:creator>
<dc:creator>
<vCard:N rdf:parseType="Resource">
<vCard:Family>Brown</vCard:Family>
<vCard:Given>Charlie</vCard:Given>
</vCard:N>
</dc:creator>
<dc:creator>
<vCard:N rdf:parseType="Resource">
<vCard:Family>Doo</vCard:Family>
<vCard:Given>Scooby</vCard:Given>
</vCard:N>
</dc:creator>
</rdf:Description>
</rdf:RDF>
Figure 10 Recommended definition of model builder metadata in which multiple people worked independently on the model.
<rdf:RDF
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:vCard="http://www.w3.org/2001/vcard-rdf/3.0#">
<rdf:Description rdf:about="#cellml_element_id">
<dc:creator>
<rdf:Bag>
<rdf:li>
<vCard:N rdf:parseType="Resource">
<vCard:Family>Flintstone</vCard:Family>
<vCard:Given>Fred</vCard:Given>
</vCard:N>
</rdf:li>
<rdf:li>
<vCard:N rdf:parseType="Resource">
<vCard:Family>Brown</vCard:Family>
<vCard:Given>Charlie</vCard:Given>
</vCard:N>
</rdf:li>
<rdf:li>
<vCard:N rdf:parseType="Resource">
<vCard:Family>Doo</vCard:Family>
<vCard:Given>Scooby</vCard:Given>
</vCard:N>
</rdf:li>
</rdf:Bag>
</dc:creator>
</rdf:Description>
</rdf:RDF>
Figure 11 Recommended definition of model builder metadata in which multiple people worked together on the model and all are considered equal contributors.
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.
<rdf:RDF
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:vCard="http://www.w3.org/2001/vcard-rdf/3.0#">
<rdf:Description rdf:about="#cellml_element_id">
<dc:contributor rdf:parseType="Resource">
<vCard:N rdf:parseType="Resource">
<vCard:Family>Flinstone</vCard:Family>
<vCard:Given>Fred</vCard:Given>
</vCard:N>
</dc:contributor>
</rdf:Description>
</rdf:RDF>
Figure 12 Recommended definition of contributor metadata.
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:RDF
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf: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.
Figure 14 demonstrates the definition of the copyright metadata.
<rdf:RDF
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="#cellml_element_id">
<dc:rights>Physiome Sciences, 2000</dc:rights>
</rdf:Description>
</rdf:RDF>
Figure 14 Recommended definition of copyright metadata.
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.
<rdf:RDF
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:Description rdf:about="#cellml_element_id">
<dcq:created>
<dcq:W3CDTF>2000-10-05</dcq:W3CDTF>
</dcq:created>
</rdf:Description>
</rdf:RDF>
Figure 15
Recommended definition of the creation date metadata.
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.
<rdf:RDF
xmlns:dcq="http://purl.org/dc/terms/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="#cellml_element_id">
<dcq:modified>
<dcq:W3CDTF>2000-10-05</dcq:W3CDTF>
</dcq:modified>
</rdf:Description>
</rdf:RDF>
Figure 16
Recommended definition of the last modified date metadata.
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''.
<rdf:RDF
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:Description rdf:about="#cellml_element_id">
<dc:title>EGF-EGFR complex</dc:title>
<dcq:alternative>epidermal growth factor-epidermal growth factor receptor complex</dcq:alternative>
</rdf:Description>
</rdf:RDF>
Figure 17 Recommended definition of alternative name metadata.
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.
<rdf:RDF
xmlns:cmeta="http://www.cellml.org/metadata/1.0#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="#cellml_element_id">
<cmeta:species>Mammalia</cmeta:species>
<cmeta:species>Xenopus laevis</cmeta:species>
</rdf:Description>
</rdf:RDF>
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.
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).
<rdf:RDF
xmlns:cmeta="http://www.cellml.org/metadata/1.0#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="#cellml_element_id">
<cmeta:sex>male</cmeta:sex>
</rdf:Description>
</rdf:RDF>
Figure 19 An example of the use of sex metadata
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:
-
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, 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.
<rdf:RDF
xmlns:cmeta="http://www.cellml.org/metadata/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:dcq="http://purl.org/dc/qualifiers/1.0/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#">
<rdf:Description rdf:about="#cellml_element_id">
<cmeta:bio_entity>
<rdf:Bag>
<rdf:li rdf:parseType="Resource">
<dc:title>calmodulin</dc:title>
<dcq:alternative>CaM</dcq:alternative>
<cmeta:identifier rdf:parseType="Resource">
<cmeta:identifier_scheme>SWISS-PROT</cmeta:identifier_scheme>
<rdf:value>CALM_HUMAN</rdf:value>
</cmeta:identifier>
</rdf:li>
<rdf:li rdf:parseType="Resource">
<dc:title>troponin C</dc:title>
</rdf:li>
<rdf:li rdf:parseType="Resource">
<cmeta:identifier rdf:parseType="Resource">
<cmeta:identifier_scheme>SWISS-PROT</cmeta:identifier_scheme>
<rdf:value>PRVA_HUMAN</rdf:value>
<rdfs:label>parvalbumin</rdfs:label>
</cmeta:identifier>
</rdf:li>
</rdf:Bag>
</cmeta:bio_entity>
</rdf:Description>
</rdf:RDF>
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.
Figure 21 shows the recommended definition of mathematical problem type metadata.
<rdf:RDF
xmlns:cmeta="http://www.cellml.org/metadata/1.0#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#">
<rdf:Description rdf:about="#cellml_element_id">
<cmeta:GAMS>
<rdfs:label>1st order ODE- Initial Value Problem</rdfs:label>
<rdf:value>I1a</rdf:value>
</cmeta:GAMS>
</rdf:Description>
</rdf:RDF>
Figure 21 Recommended definition of the mathematical problem type metadata.
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.
Figure 22 shows how to define description metadata.
<rdf:RDF
xmlns:dcq="http://purl.org/dc/terms/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="#cellml_element_id">
<dcq:abstract>
This element uses simple mass-action kinetics to describe the
A + B <-> C + D reaction.
</dcq:abstract>
</rdf:Description>
</rdf:RDF>
Figure 22 Recommended definition of the Dublin Core description 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.
Annotation metadata is defined using CellML-specific elements: <cmeta:comment>, <cmeta:limitation>, <cmeta:modification>, and <cmeta:validation>.
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:RDF
xmlns:cmeta="http://www.cellml.org/metadata/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:Description rdf:about="#cellml_element_id">
<cmeta:comment rdf: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:N rdf: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:limitation rdf:parseType="Resource">
<rdf:value>
This component is only valid for temperatures above 20 degrees C.
</rdf:value>
<dc:creator>
<vCard:N rdf: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>
Figure 23 Recommended definition of comment and limitation annotation metadata.
<rdf:RDF
xmlns:cmeta="http://www.cellml.org/metadata/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:Description rdf:about="#cellml_element_id">
<cmeta:modification rdf:parseType="Resource">
<rdf:value>Changed the equation for the sodium current.</rdf:value>
<dc:creator>
<vCard:N rdf: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:validation rdf:parseType="Resource">
<rdf:value>Physiome level 2</rdf:value>
<dc:creator>
<vCard:N rdf: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>
Figure 24 Recommended definition of modification and validation annotation metadata.
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.
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.
<rdf:RDF
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="#cellml_element_id">
<bqs:reference>
<bqs:Medline_id>97219925</bqs:Medline_id>
</bqs:reference>
</rdf:Description>
</rdf:RDF>
Figure 25 Serialization of the BibliographicReference class's identifier 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 a second database identifier element qualified by a nested <bqs:alternative> element, as shown in Figure 26.
<rdf:RDF
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="#cellml_element_id">
<bqs:reference rdf:parseType="Resource">
<bqs:Medline>97219925</bqs:Medline>
<bqs:PubMed>
<bqs:alternative>9067300</bqs:alternative>
</bqs:PubMed>
</bqs:reference>
</rdf:Description>
</rdf:RDF>
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.
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.
<rdf:RDF
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="#cellml_element_id">
<bqs:JournalArticle rdf:parseType="Resource">
...
</bqs:JournalArticle>
</rdf:Description>
</rdf:RDF>
Figure 27 Serialization of reference type information using type=JournalArticle as an example. See text for more info. The description of a journal article is left out for the time being.
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.
<rdf:RDF
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="#cellml_element_id">
<bqs:reference rdf:parseType="Resource">
<dc:title>
Inhibition of cardiac potassium currents by the vesnarinone
analog OPC-18790: comparison with quinidine and dofetilide
</dc:title>
</bqs:reference>
</rdf:Description>
</rdf:RDF>
Figure 28 Serialization of reference title information.
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.
<rdf:RDF
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="#cellml_element_id">
<bqs:reference rdf:parseType="Resource">
<dc:rights>Physiome Sciences, 2001</dc:rights>
</bqs:reference>
</rdf:Description>
</rdf:RDF>
Figure 29 Serialization of reference rights information.
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.
<rdf:RDF
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dcq="http://purl.org/dc/terms/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="#cellml_element_id">
<bqs:reference>
<dcq:RFC1766>en-uk</dcq:RFC1766>
</bqs:reference>
</rdf:Description>
</rdf:RDF>
Figure 30 Serialization of language information. This metadata indicates the content of the cited resource is written in United Kingdom English.
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.
<rdf:RDF
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dcq="http://purl.org/dc/terms/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="#cellml_element_id">
<bqs:reference>
<dcq:medium>
<dcq:IMT>application/pdf</dcq:IMT>
</dcq:medium>
</bqs:reference>
</rdf:Description>
</rdf:RDF>
Figure 31 Serialization of format information. This metadata indicates the content of the cited resource is in the PDF format.
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.
<rdf:RDF
xmlns: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:Description rdf:about="#cellml_element_id">
<bqs:reference rdf:parseType="Resource">
<dcq:issued>
<dcq:W3CDTF>1997</dcq:W3CDTF>
</dcq:issued>
</bqs:reference>
</rdf:Description>
</rdf:RDF>
Figure 32 Serialization of date information. This metadata indicates the cited resource was published in 1997 (note that the W3C-DTF encoding allows full dates, month/year dates, and year-only dates).
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:RDF
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:vCard="http://www.w3.org/2001/vcard-rdf/3.0#">
<rdf:Description rdf:about="#cellml_element_id">
<bqs:reference rdf:parseType="Resource">
<dc:creator>
<rdf:Seq>
<rdf:li>
<bqs:Person rdf:parseType="Resource">
<vCard:N rdf:parseType="Resource">
<vCard:Family>Yang</vCard:Family>
<vCard:Given>T</vCard:Given>
</vCard:N>
<vCard:EMAIL rdf:parseType="Resource">
<rdf:value>phoney@nowhere.com</rdf:value>
<rdf:type rdf:resource="http://imc.org/vCard/3.0#internet" />
</vCard:EMAIL>
</bqs:Person>
</rdf:li>
<rdf:li>
<bqs:Person rdf:parseType="Resource">
<vCard:N rdf:parseType="Resource">
<vCard:Family>Snyders</vCard:Family>
<vCard:Given>D</vCard:Given>
<vCard:Other>J</vCard:Other>
</vCard:N>
<vCard:ORG rdf: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:Person rdf:parseType="Resource">
<vCard:N rdf:parseType="Resource">
<vCard:Family>Roden</vCard:Family>
<vCard:Given>D</vCard:Given>
<vCard:Other>M</vCard:Other>
</vCard:N>
<vCard:ADR rdf: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.
<rdf:RDF
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="#cellml_element_id">
<bqs:reference rdf:parseType="Resource">
<dc:contributor rdf:parseType="Resource">
<bqs:Organization>Super Scientific Graphics, Inc.</bqs:Organization>
</dc:contributor>
</bqs:reference>
</rdf:Description>
</rdf:RDF>
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.
<rdf:RDF
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="#cellml_element_id">
<bqs:reference rdf:parseType="Resource">
<dc:publisher rdf:parseType="Resource">
<bqs:Service>my software service</bqs:Service>
</dc:publisher>
</bqs:reference>
</rdf:Description>
</rdf:RDF>
Figure 35 Serialization of publisher information. A software service is the publisher of the reference in this example.
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.
<rdf:RDF
xmlns: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:Description rdf:about="#cellml_element_id">
<bqs:reference rdf:parseType="Resource">
<bqs:subject_heading>
<dcq:MESH>
<rdf:Bag>
<rdf:li>Signal Transduction</rdf:li>
<rdf:li>Ion Transport</rdf:li>
</rdf:Bag>
</dcq:MESH>
</bqs:subject_heading>
<bqs:classification_code>
<dcq:DDC>572</dcq:DDC>
</bqs:classification_code>
<bqs:keyword>
<rdf:Seq>
<rdf:li>calcium signaling</rdf:li>
<rdf:li>calcium import</rdf:li>
</rdf:Seq>
</bqs:keyword>
</bqs:reference>
</rdf:Description>
</rdf:RDF>
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:
-
keywords:
<bqs:keyword> value of keyword, no Dublin Core Qualifier elements.
-
subheadings:
<bqs:subject_heading>, Dublin Core Qualifier elements of <dcq:LCSH> (Library of Congress Subject Headings) or <dcq:MESH> (Medical Subject Headings).
-
codes:
<bqs:classification_code>, Dublin Core Qualifier elements of <dcq:DDC> (Dewey Decimal Classification), LCC (Library of Congress Classification), or <dcq:UDC> (Universal Decimal Classification).
In all cases, multiple values should be stored in the appropriate RDF container.
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.
<rdf:RDF
xmlns: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:Description rdf:about="#cellml_element_id">
<bqs:reference rdf:parseType="Resource">
<dc:description rdf:parseType="Resource" xml:lang="en">
<dcq:abstract>
<dcq:IMT>text/url</dcq:IMT>
<rdf:value>
http://www.abstractsRus.com/abstract567843
</rdf:value>
</dcq:abstract>
</dc:description>
<dc:description rdf:parseType="Resource" xml:lang="en">
<dcq:tableOfContents>
<dcq:IMT>text/html</dcq:IMT>
</dcq:tableOfContents>
<rdf:value rdf:parseType="Literal">
<p> ... table of contents info here ...</p>
</rdf:value>
</dc:description>
</bqs:reference>
</rdf:Description>
</rdf:RDF>
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.
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.
Figure 38 shows the serialization of the scope metadata.
<rdf:RDF
xmlns: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:Description rdf:about="#cellml_element_id">
<bqs:reference rdf:parseType="Resource">
<dcq:temporal>
<dcq:W3CDTF>1997</dcq:W3CDTF>
</dcq:temporal>
<dcq:spatial>
<dcq:ISO3166>BS</dcq:ISO3166>
</dcq:spatial>
</bqs:reference>
</rdf:Description>
</rdf:RDF>
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).
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
-
A subset, stored in a
<bqs:subset> element, as shown in Figure 39
-
A property, stored as defined in Section 5.9
<rdf:RDF
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dcq="http://purl.org/dc/terms/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="#cellml_element_id">
<bqs:reference rdf:parseType="Resource">
<bqs:entry_status rdf:parseType="Resource">
<dcq:modified>
<dcq:W3CDTF>2001-04-06</dcq:W3CDTF>
</dcq:modified>
<bqs:subset>312-A</bqs:subset>
</bqs:entry_status>
</bqs:reference>
</rdf:Description>
</rdf:RDF>
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:
Medline: Most biological and medical journals are indexed by Medline, which provides a downloadable list of its journals.
-
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.
<rdf:RDF
xmlns: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:Description rdf:id="journal1">
<bqs:journal rdf:parseType="Resource">
<dc:title>Journal of Biological Chemistry</dc:title>
<bqs:issn>0021-9258</bqs:issn>
<bqs:abbreviation rdf:parseType="Resource">
<bqs:abbreviation_scheme>Medline</bqs:abbreviation_scheme>
<rdf:value>J Biol Chem</rdf:value>
</bqs:abbreviation>
</bqs:journal>
</rdf:Description>
</rdf:RDF>
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 will demonstrate possible methods for referring to journals in journal article references.
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.
<rdf:RDF
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="#cellml_element_id">
<bqs:reference>
<bqs:property rdf:parseType="Resource">
<bqs:property_type>online</bqs:property_type>
<rdf:value>yes</rdf:value>
</bqs:property>
</bqs:reference>
</rdf:Description>
</rdf:RDF>
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.
<rdf:RDF
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="#cellml_element_id">
<bqs:reference>
<dc:publisher rdf:parseType="Resource">
<bqs:Organization>O'Reilly and Associates, Inc.</bqs:Organization>
<bqs:property rdf:parseType="Resource">
<bqs:property_type>location</bqs:property_type>
<rdf:value>Sebastopol, CA</rdf:value>
</bqs:property>
</dc:publisher>
</bqs:reference>
</rdf:Description>
</rdf:RDF>
Figure 42 The use of a property to provide the location of a publisher.
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.
<rdf:RDF
xmlns: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:Description rdf:about="#cellml_element_id">
<bqs:Book>
<bqs:isbn>9-999-99999-X</bqs:isbn>
<bqs:volume>5</bqs:volume>
<bqs:edition>2nd</bqs:edition>
<bqs:editor>
<rdf:Seq>
<rdf:li>
<bqs:Person>
<vCard:N rdf:parseType="Resource">
<vCard:Family>Doe</vCard:Family>
<vCard:Given>John</vCard:Given>
</vCard:N>
</bqs:Person>
</rdf:li>
<rdf:li rdf:parseType="Resource">
<bqs:Person>
<vCard:N rdf:parseType="Resource">
<vCard:Family>Smith</vCard:Family>
<vCard:Given>Suzy</vCard:Given>
</vCard:N>
</bqs:Person>
</rdf:li>
</rdf:Seq>
</bqs:editor>
</bqs:Book>
</rdf:Description>
</rdf:RDF>
Figure 43 Serialization of book information. This example is fictitious.
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).
-
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.
<rdf:RDF
xmlns: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:Description rdf:about="#cellml_element_id">
<bqs:JournalArticle>
<bqs:first_page>56</bqs:first_page>
<bqs:last_page>62</bqs:last_page>
<bqs:volume>356</bqs:volume>
<bqs:issue>6</bqs:issue>
<bqs:issue_supplement>A</bqs:issue_supplement>
<bqs:Journal rdf:parseType="Resource">
<dc:title>Journal of Biological Chemistry</dc:title>
<bqs:Medline>J Biol Chem</bqs:Medline>
</bqs:Journal>
</bqs:JournalArticle>
</rdf:Description>
</rdf:RDF>
Figure 44 Serialization of journal article information. In this example, the journal information is provided inline.
<rdf:RDF
xmlns: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:Description rdf:about="#cellml_element_id">
<bqs:JournalArticle>
<bqs:first_page>56</bqs:first_page>
<bqs:last_page>62</bqs:last_page>
<bqs:volume>356</bqs:volume>
<bqs:issue>6</bqs:issue>
<bqs:issue_supplement>A</bqs:issue_supplement>
<bqs:Journal rdf:resource="#journal1" />
</bqs:JournalArticle>
</rdf:Description>
</rdf:RDF>
Figure 45 Serialization of journal article information. In this example, the journal information is provided by referring to the resource created in Figure 40.
<rdf:RDF
xmlns: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:Description rdf:about="#cellml_element_id">
<bqs:BookArticle>
<bqs:first_page>56</bqs:first_page>
<bqs:last_page>62</bqs:last_page>
<bqs:Book>
<bqs:isbn>9-999-99999-X</bqs:isbn>
<bqs:volume>5</bqs:volume>
<bqs:edition>2nd</bqs:edition>
<bqs:editor>
<rdf:Seq>
<rdf:li rdf:parseType="Resource">
<bqs:Person>
<vCard:N rdf:parseType="Resource">
<vCard:Family>Doe</vCard:Family>
<vCard:Given>John</vCard:Given>
</vCard:N>
</bqs:Person>
</rdf:li>
<rdf:li rdf:parseType="Resource">
<bqs:Person>
<vCard:N rdf:parseType="Resource">
<vCard:Family>Smith</vCard:Family>
<vCard:Given>Suzy</vCard:Given>
</vCard:N>
</bqs:Person>
</rdf:li>
</rdf:Seq>
</bqs:editor>
</bqs:Book>
</bqs:BookArticle>
</rdf:Description>
</rdf:RDF>
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.
Serialization of this subclass is postponed pending further information.
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 47 shows the definition of information about a web resource.
<rdf:RDF
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="#cellml_element_id">
<bqs:WebResource>
<bqs:url>http://www.some_website.com/</bqs:url>
<bqs:estimated_size rdf:parseType="Resource">
<rdf:value>100</rdf:value>
<bqs:property rdf:parseType="Resource">
<bqs:property_type>units</bqs:property_type>
<rdf:value>kilobytes</rdf:value>
</bqs:property>
</bqs:estimated_size>
<bqs:cost rdf:parseType="Resource">
<rdf:value>100</rdf:value>
<bqs:property rdf:parseType="Resource">
<bqs:property_type>units</bqs:property_type>
<rdf:value>kilobytes</rdf:value>
</bqs:property>
</bqs:cost>
</bqs:WebResource>
</rdf:Description>
</rdf:RDF>
Figure 47 Serialization of web resource information.
This section provides several complete citation examples.
Figure 48 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.
<rdf:RDF
xmlns: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:Description rdf:about="#cellml_element_id">
<bqs:JournalArticle>
<dc:creator>
<rdf:Seq>
<rdf:li>
<bqs:Person>
<vCard:N rdf:parseType="Resource">
<vCard:Family>Jafri</vCard:Family>
<vCard:Given>M</vCard:Given>
<vCard:Other>S</vCard:Other>
</vCard:N>
</bqs:Person>
</rdf:li>
<rdf:li rdf:parseType="Resource">
<bqs:Person>
<vCard:N rdf:parseType="Resource">
<vCard:Family>Rice</vCard:Family>
<vCard:Given>J</vCard:Given>
<vCard:Other>J</vCard:Other>
</vCard:N>
</bqs:Person>
</rdf:li>
<rdf:li>
<bqs:Person>
<vCard:N rdf:parseType="Resource">
<vCard:Family>Winslow</vCard:Family>
<vCard:Given>R</vCard:Given>
<vCard:Other>L</vCard:Other>
</vCard:N>
</bqs:Person>
</rdf:li>
</rdf:Seq>
</dc:creator>
<dc:title>
Cardiac Ca2+ dynamics: the role of ryanodine receptor
adaptation and sarcoplasmic reticulum load
</dc:title>
<dcq:issued>
<dcq:W3CDTF>1998</dcq:W3CDTF>
</dcq:issued>
<bqs:Journal rdf:parseType="Resource">
<dc:title>Biophysical Journal</dc:title>
<bqs:Medline>Biophys J</bqs:Medline>
</bqs:Journal>
<bqs:volume>74</bqs:volume>
<bqs:first_page>1149</bqs:first_page>
<bqs:last_page>1168</bqs:last_page>
</bqs:JournalArticle>
</rdf:Description>
</rdf:RDF>
Figure 48 A complete journal article reference. Information about the journal itself is embedded within the reference.
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.
<rdf:RDF
xmlns: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:Description rdf:about="#cellml_element_id">
<bqs:JournalArticle>
<dc:creator>
<rdf:Seq>
<rdf:li>
<bqs:Person>
<vCard:N rdf:parseType="Resource">
<vCard:Family>Jafri</vCard:Family>
<vCard:Given>M</vCard:Given>
<vCard:Other>S</vCard:Other>
</vCard:N>
</bqs:Person>
</rdf:li>
<rdf:li>
<bqs:Person>
<vCard:N rdf:parseType="Resource">
<vCard:Family>Rice</vCard:Family>
<vCard:Given>J</vCard:Given>
<vCard:Other>J</vCard:Other>
</vCard:N>
</bqs:Person>
</rdf:li>
<rdf:li>
<bqs:Person>
<vCard:N rdf:parseType="Resource">
<vCard:Family>Winslow</vCard:Family>
<vCard:Given>R</vCard:Given>
<vCard:Other>L</vCard:Other>
</vCard:N>
</bqs:Person>
</rdf:li>
</rdf:Seq>
</dc:creator>
<dc:title>
Cardiac Ca2+ dynamics: the role of ryanodine receptor
adaptation and sarcoplasmic reticulum load
</dc:title>
<dcq:issued>
<dcq:W3CDTF>1998</dcq:W3CDTF>
</dcq:issued>
<bqs:Journal
rdf:resource="http://www.example.org/journals#BiophysJ" />
<bqs:volume>74</bqs:volume>
<bqs:first_page>1149</bqs:first_page>
<bqs:last_page>1168</bqs:last_page>
</bqs:JournalArticle>
</rdf:Description>
</rdf:RDF>
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:RDF
xmlns: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:Description rdf:id="BiophysJ">
<bqs:journal rdf:parseType="Resource">
<dc:title>Biophysical Journal</dc:title>
<bqs:Medline>Biophys J</bqs:Medline>
<bqs:issn>0006-3495</bqs:issn>
</bqs:journal>
</rdf:Description>
<rdf:Description rdf:id="JBiolChem">
<bqs:journal rdf:parseType="Resource">
<dc:title>Journal of Biological Chemistry</dc:title>
<bqs:Medline>J Biol Chem</bqs:Medline>
<bqs:issn>0021-9258</bqs:issn>
</bqs:journal>
</rdf:Description>
</rdf:RDF>
Figure 50 Information about two journals. This information could be referenced by bibliographic citations defined in the <bqs:reference> element.
Figure 51 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.
<rdf:RDF
xmlns: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:Description rdf:about="#cellml_element_id">
<bqs:reference rdf: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.
Figure 52 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.
<rdf:RDF
xmlns: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:Description rdf:about="#cellml_element_id">
<bqs:Book>
<dc:creator>
<rdf:Seq>
<rdf:li>
<bqs:Person>
<vCard:N rdf:parseType="Resource">
<vCard:Family>Branden</vCard:Family>
<vCard:Given>Carl</vCard:Given>
</vCard:N>
</bqs:Person>
</rdf:li>
<rdf:li rdf:parseType="Resource">
<bqs:Person>
<vCard:N rdf:parseType="Resource">
<vCard:Family>Tooze</vCard:Family>
<vCard:Given>John</vCard:Given>
</vCard:N>
</bqs:Person>
</rdf:li>
</rdf:Seq>
</dc:creator>
<dc:title>Introduction to Protein Structure</dc:title>
<dcq:issued>
<dcq:W3CDTF>1991</dcq:W3CDTF>
</dcq:issued>
<dc:publisher rdf:parseType="Resource">
<bqs:Organization>Garland Publishing, Inc.</bqs:Organization>
<bqs:property rdf:parseType="Resource">
<bqs:property_type>location</bqs:property_type>
<rdf:value>New York</rdf:value>
</bqs:property>
</dc:publisher>
</bqs:Book>
</rdf:Description>
</rdf:RDF>
Figure 52 A complete book reference. Note the use of the Property class to provide the location of the publisher.
Figure 53 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.
<rdf:RDF
xmlns: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:Description rdf:about="#cellml_element_id">
<bqs:Book>
<bqs:editor>
<rdf:Seq>
<rdf:li>
<bqs:Person>
<vCard:N rdf:parseType="Resource">
<vCard:Family>Brody</vCard:Family>
<vCard:Given>Jerome</vCard:Given>
<vCard:Other>S</vCard:Other>
</vCard:N>
</bqs:Person>
</rdf:li>
<rdf:li>
<bqs:Person>
<vCard:N rdf:parseType="Resource">
<vCard:Family>Center</vCard:Family>
<vCard:Given>David</vCard:Given>
<vCard:Other>M</vCard:Other>
</vCard:N>
</bqs:Person>
</rdf:li>
<rdf:li>
<bqs:Person>
<vCard:N rdf:parseType="Resource">
<vCard:Family>Tkachuk</vCard:Family>
<vCard:Given>Vsevolod</vCard:Given>
<vCard:Other>A</vCard:Other>
</vCard:N>
</bqs:Person>
</rdf:li>
</rdf:Seq>
</bqs:editor>
<dc:title>Signal Transduction in Lung Cells</dc:title>
<dcq:issued>
<dcq:W3CDTF>1993</dcq:W3CDTF>
</dcq:issued>
<bqs:series>Lung Biology in Health and Disease</bqs:series>
<bqs:volume>65</bqs:volume>
<dc:publisher>
<bqs:Organization rdf:parseType="Resource">
<rdf:value>Marcel Dekker, Inc.</rdf:value>
<bqs:property rdf:parseType="Resource">
<bqs:property_type>location</bqs:property_type>
<rdf:value>New York</rdf:value>
</bqs:property>
</bqs:Organization>
</dc:publisher>
</bqs:Book>
</rdf:Description>
</rdf:RDF>
Figure 53 A more complicated complete book reference.
Figure 54 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.
<rdf:RDF
xmlns: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:Description rdf:about="#cellml_element_id">
<bqs:BookArticle>
<dc:creator>
<rdf:Seq>
<rdf:li>
<bqs:Person>
<vCard:N rdf: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:N rdf: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:N rdf: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:N rdf:parseType="Resource">
<vCard:Family>Pauls</vCard:Family>
<vCard:Given>Thomas</vCard:Given>
</vCard:N>
</bqs:Person>
</rdf:li>
<rdf:li>
<bqs:Person>
<vCard:N rdf:parseType="Resource">
<vCard:Family>Schwaller</vCard:Family>
<vCard:Given>Beat</vCard:Given>
</vCard:N>
</bqs:Person>
</rdf:li>
</rdf:Seq>
</bqs:editor>
<dc:publisher rdf:parseType="Resource">
<bqs:Organization>
<rdf:value>Oxford University Press</rdf:value>
<bqs:property rdf: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.)
<?xml version="1.0" encoding="iso-8859-1"?>">
<!--This Version:
Title: RDF Schema Declaration Draft for CellML Metadata terms.
Creator: Autumn A. Cuellar
Bioengineering Research Group, The University of Auckland
Date Created: 2001-11-02
Comments: This is a premilinary version to be used only as a model and will
almost certainly change.
Comments may be sent to cellml-discussion@cellml.org.-->
<!DOCTYPE rdf:RDF [
<!ENTITY rdfns 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'>
<!ENTITY rdfsns 'http://www.w3.org/2000/01/rdf-schema#'>
<!ENTITY dcns 'http://purl.org/dc/elements/1.1/'>
<!ENTITY dcqns 'http://purl.org/dc/terms/'>
<!ENTITY cmetans 'http://www.cellml.org/metadata/1.0#'>
]>
<rdf:RDF
xmlns:cmeta="&cmetans;"
xmlns:dc="&dcns;"
xmlns:dcq="&dcqns;"
xmlns:rdf="&rdfns;"
xmlns:rdfs="&rdfns;">
<!--Description of this Schema-->
<rdf:Description rdf: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:Property rdf:about="&cmetans;sex">
<rdfs:label>Sex</rdfs:label>
<rdfs:comment>The sex for which a CellML element is relevant.</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="&cmetans;" />
</rdf:Property>
<!--Biological Entity-->
<rdf:Property rdf: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:isDefinedBy rdf:resource="&cmetans;" />
</rdf:Property>
<!--Alternative Database Identifier-->
<rdf:Property rdf:about="&cmetans;alternative">
<rdfs:label>Alternative Database Identifier</rdfs:label>
<rdfs:comment>
An alternative database unique identifier for a biological entity.
</rdfs:comment>
<rdfs:subPropertyOf rdf:resource="&cmetans;bio_entity" />
<rdfs:isDefinedBy rdf:resource="&cmetans;" />
</rdf:Property>
<!--Mathematical Problem Type: GAMS classification tree-->
<rdf:Property rdf:about="&cmetans;alternative">
<rdfs:label>Mathematical Problem Type: GAMS classification tree</rdfs:label>
<rdfs:comment>
A classification of the type of problem encoded in the math associated
with the CellML model or model component.
</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="&cmetans;" />
<rdfs:seeAlso rdf:resource="http://gams.nist.gov" />
</rdf:Property>
<!--Annotation-->
<rdf:Property rdf:about="&cmetans;annotation">
<rdfs:label>Annotation</rdfs:label>
<rdfs:comment>
An annotation that describes the CellML model or model component.
</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="&cmetans;" />
</rdf:Property>
<!--Annotation:coment-->
<rdf:Property rdf: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:type rdf:resource="&cmetans;annotation" />
<rdfs:isDefinedBy rdf:resource="&cmetans;" />
</rdf:Property>
<!--Annotation:limitation-->
<rdf:Property rdf: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:type rdf:resource="&cmetans;annotation" />
<rdfs:isDefinedBy rdf:resource="&cmetans;" />
</rdf:Property>
<!--Annotation:modification-->
<rdf:Property rdf: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:type rdf:resource="&cmetans;annotation" />
<rdfs:isDefinedBy rdf:resource="&cmetans;" />
</rdf:Property>
<!--Annotation:validation-->
<rdf:Property rdf: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:type rdf:resource="&cmetans;annotation" />
<rdfs:isDefinedBy rdf:resource="&cmetans;" />
</rdf:Property>
</rdf:RDF>
<?xml version="1.0" encoding="iso-8859-1"?>
<!--This Version:
Title: RDF Schema Declaration Draft for Bibliographic Query Service terms.
Creator: Autumn A. Cuellar
Bioengineering Research Group, The University of Auckland
Date Created: 2001-11-02
Comments: This is a premilinary version to be used only as a model and will
almost certainly change (constraints need to be added, etc.).
Comments may be sent to cellml-discussion@cellml.org.-->
<!DOCTYPE rdf:RDF [
<!ENTITY rdfns 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'>
<!ENTITY rdfsns 'http://www.w3.org/2000/01/rdf-schema#'>
<!ENTITY dcns 'http://purl.org/dc/elements/1.1/'>
<!ENTITY dcqns 'http://purl.org/dc/terms/'>
<!ENTITY bqsns 'http://www.cellml.org/bqs/1.0#'>
]>
<rdf:RDF
xmlns:bqsns="&bqs;"
xmlns:dc="&dcns;"
xmlns:dcq="&dcqns;"
xmlns:rdf="&rdfns;"
xmlns:rdfs="&rdfns;">
<!--Description of this Schema-->
<rdf:Description rdf: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>
<!--BibliographicReference Class-->
<rdf:Property rdf:about="&bqsns;reference">
<rdfs:label>reference</rdfs:label>
<rdfs:comment>
The root class for all BQS bibliographic references.
</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--Bibliographic Identifier Scheme-->
<rdf:Property rdf:about="&bqsns;identifier_scheme">
<rdfs:label>Identifier Scheme</rdfs:label>
<rdfs:comment>
Identifies a cited reference using a database unique identifier.
</rdfs:comment>
<rdfs:subPropertyOf rdf:resource="&dcns;identifier" />
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--Medline Indetifier Scheme-->
<rdf:Property rdf:about="&bqsns;Medline_id">
<rdfs:label>Medline identifier</rdfs:label>
<rdfs:comment>
The Medline database unique identifier.
</rdfs:comment>
<rdf:type rdf:resource="&bqsns;identifier_scheme" />
<rdfs:seeAlso rdf:resource="http://medline.cos.com" />
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--PubMed Indetifier Scheme-->
<rdf:Property rdf:about="&bqsns;PubMed_id">
<rdfs:label>PubMed identifier</rdfs:label>
<rdfs:comment>
The PubMed database unique identifier.
</rdfs:comment>
<rdf:type rdf:resource="&bqsns;identifier_scheme" />
<rdfs:seeAlso rdf:resource="http://www4.ncbi.nlm.nih.gov/PubMed/" />
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--CAS Indetifier Scheme-->
<rdf:Property rdf:about="&bqsns;CAS_id">
<rdfs:label>CAS (Chemical Abstract Service) identifier</rdfs:label>
<rdfs:comment>
The CAS database unique identifier.
</rdfs:comment>
<rdf:type rdf:resource="&bqsns;identifier_scheme" />
<rdfs:seeAlso rdf:resource="http://www.cas.org/" />
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--Reference Type-->
<rdf:Property rdf:about="&bqsns;reference_type">
<rdfs:label>Reference Type</rdfs:label>
<rdfs:comment>
Identifies the genre of a cited reference.
</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--Reference Type:Article-->
<rdf:Property rdf:about="&bqsns;Article">
<rdfs:label>Article</rdfs:label>
<rdfs:comment>
The cited reference is an article.
</rdfs:comment>
<rdf:type rdf:resource="&bqsns;reference_type" />
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--Reference Type:JournalArticle-->
<rdf:Property rdf:about="&bqsns;JournalArticle">
<rdfs:label>JournalArticle</rdfs:label>
<rdfs:comment>
The cited reference is a journal article.
</rdfs:comment>
<rdf:type rdf:resource="&bqsns;Article" />
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--Reference Type:BookArticle-->
<rdf:Property rdf:about="&bqsns;BookArticle">
<rdfs:label>BookArticle</rdfs:label>
<rdfs:comment>
The cited reference is a book article.
</rdfs:comment>
<rdf:type rdf:resource="&bqsns;Article" />
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--Reference Type:Book-->
<rdf:Property rdf:about="&bqsns;Book">
<rdfs:label>Book</rdfs:label>
<rdfs:comment>
The cited reference is a book.
</rdfs:comment>
<rdf:type rdf:resource="&bqsns;reference_type" />
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--Reference Type:Patent-->
<rdf:Property rdf:about="&bqsns;Patent">
<rdfs:label>Patent</rdfs:label>
<rdfs:comment>
The cited reference is a patent.
</rdfs:comment>
<rdf:type rdf:resource="&bqsns;reference_type" />
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--Reference Type:Proceeding-->
<rdf:Property rdf:about="&bqsns;Proceeding">
<rdfs:label>Proceeding</rdfs:label>
<rdfs:comment>
The cited reference is a proceeding.
</rdfs:comment>
<rdf:type rdf:resource="&bqsns;reference_type" />
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--Reference Type:TechReport-->
<rdf:Property rdf:about="&bqsns;TechReport">
<rdfs:label>Technical Report</rdfs:label>
<rdfs:comment>
The cited reference is a technical report.
</rdfs:comment>
<rdf:type rdf:resource="&bqsns;reference_type" />
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--Reference Type:Thesis-->
<rdf:Property rdf:about="&bqsns;Thesis">
<rdfs:label>Thesis</rdfs:label>
<rdfs:comment>
The cited reference is a thesis.
</rdfs:comment>
<rdf:type rdf:resource="&bqsns;reference_type" />
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--Reference Type:WebResource-->
<rdf:Property rdf:about="&bqsns;WebResource">
<rdfs:label>WebResource</rdfs:label>
<rdfs:comment>
The cited reference is a web resource.
</rdfs:comment>
<rdf:type rdf:resource="&bqsns;reference_type" />
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--Provider Type-->
<rdf:Property rdf:about="&bqsns;provider_type">
<rdfs:label>provider type</rdfs:label>
<rdfs:comment>
Who the resource is provided by.
</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--Provider Type:Person-->
<rdf:Property rdf:about="&bqsns;Person">
<rdfs:label>Person</rdfs:label>
<rdfs:comment>
The resource is provided by a person.
</rdfs:comment>
<rdf:type rdf:resource="&bqsns;provider_type" />
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--Provider Type:Organization-->
<rdf:Property rdf:about="&bqsns;Organization">
<rdfs:label>Organization</rdfs:label>
<rdfs:comment>
The resource is provided by an organization.
</rdfs:comment>
<rdf:type rdf:resource="&bqsns;provider_type" />
<rdf:seeAlso rdf:resource="&bqsns;Organisation" />
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--Provider Type:Organisation-->
<rdf:Property rdf:about="&bqsns;Organisation">
<rdfs:label>Organisation</rdfs:label>
<rdfs:comment>
The resource is provided by an organisation.
</rdfs:comment>
<rdf:type rdf:resource="&bqsns;provider_type" />
<rdf:seeAlso rdf:resource="&bqsns;Organization" />
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--Provider Type:Service-->
<rdf:Property rdf:about="&bqsns;Service">
<rdfs:label>Service</rdfs:label>
<rdfs:comment>
The resource is provided by a service.
</rdfs:comment>
<rdf:type rdf:resource="&bqsns;provider_type" />
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--Subject Type-->
<rdf:Property rdf:about="&bqsns;subject_type">
<rdfs:label>subject type</rdfs:label>
<rdfs:comment>
Defines the topic of a resource.
</rdfs:comment>
<rdfs:subPropertyOf rdf:resource="&dcns;subject" />
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--Subject Type:Keyword-->
<rdf:Property rdf:about="&bqsns;keyword">
<rdfs:label>keyword</rdfs:label>
<rdfs:comment>
Defines the topic of a resource using keywords.
</rdfs:comment>
<rdfs:type rdf:resource="&dcns;subject_type" />
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--Subject Type:Subject Heading-->
<rdf:Property rdf:about="&bqsns;subject_heading">
<rdfs:label>subject heading</rdfs:label>
<rdfs:comment>
Defines the topic of a resource using subject headings.
</rdfs:comment>
<rdfs:type rdf:resource="&dcns;subject_type" />
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--Subject Type:Classification Code-->
<rdf:Property rdf:about="&bqsns;classification_code">
<rdfs:label>classification code</rdfs:label>
<rdfs:comment>
Defines the topic of a resource using classification codes.
</rdfs:comment>
<rdfs:type rdf:resource="&dcns;subject_type" />
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--Entry Status-->
<rdf:Property rdf: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:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--Subset-->
<rdf:Property rdf:about="&bqsns;subset">
<rdfs:label>Subset</rdfs:label>
<rdfs:comment>
Provides reference subset information.
</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--Property-->
<rdf:Property rdf:about="&bqsns;property">
<rdfs:label>Property</rdfs:label>
<rdfs:comment>
Provides a property about the reference.
</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--Property Type-->
<rdf:Property rdf:about="&bqsns;property_type">
<rdfs:label>Property Type</rdfs:label>
<rdfs:comment>
Declares the property name.
</rdfs:comment>
<rdfs:subPropertyOf rdf:resource="&bqsns;property" />
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--Book:ISBN-->
<rdf:Property rdf:about="&bqsns;isbn">
<rdfs:label>International Standard Book Number</rdfs:label>
<rdfs:comment>
International Standard Book Number unique identifier.
</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--Book (& Article):Volume-->
<rdf:Property rdf:about="&bqsns;volume">
<rdfs:label>Volume</rdfs:label>
<rdfs:comment>
Book or journal volume number.
</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--Book:Edition-->
<rdf:Property rdf:about="&bqsns;edition">
<rdfs:label>Edition</rdfs:label>
<rdfs:comment>
Book edition.
</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--Book:Series-->
<rdf:Property rdf: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:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--Book:Editor-->
<rdf:Property rdf:about="&bqsns;editor">
<rdfs:label>Editor</rdfs:label>
<rdfs:comment>
The books's editor.
</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--Article:first_page-->
<rdf:Property rdf:about="&bqsns;first_page">
<rdfs:label>First Page</rdfs:label>
<rdfs:comment>
The first page of the article referenced.
</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--Article:last_page-->
<rdf:Property rdf:about="&bqsns;last_page">
<rdfs:label>Last Page</rdfs:label>
<rdfs:comment>
The last page of the article referenced.
</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--Article:last_page-->
<rdf:Property rdf:about="&bqsns;last_page">
<rdfs:label>Last Page</rdfs:label>
<rdfs:comment>
The last page of the article referenced.
</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--Article:issue-->
<rdf:Property rdf:about="&bqsns;issue">
<rdfs:label>Issue</rdfs:label>
<rdfs:comment>
The issue in which the referenced article is found.
</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--Article:issue_supplement-->
<rdf:Property rdf: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:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--Journal-->
<rdf:Property rdf:about="&bqsns;Journal">
<rdfs:label>Journal</rdfs:label>
<rdfs:comment>
Journal reference.
</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--Journal:ISSN-->
<rdf:Property rdf:about="&bqsns;issn">
<rdfs:label>International Standard Serial Number</rdfs:label>
<rdfs:comment>
International Standard Serial Number unique identifier.
</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--Journal:abbreviation-->
<rdf:Property rdf:about="&bqsns;abbreviation">
<rdfs:label>Abbreviation</rdfs:label>
<rdfs:comment>
Journal abbreviation.
</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--Journal:abbreviation_scheme-->
<rdf:Property rdf:about="&bqsns;abbreviation_scheme">
<rdfs:label>Abbreviation Scheme</rdfs:label>
<rdfs:comment>
Standard journal abbreviation scheme.
</rdfs:comment>
<rdfs:subPropertyOf rdf:resource="&bqsns;abbreviation" />
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--WebResource:url-->
<rdf:Property rdf:about="&bqsns;url">
<rdfs:label>Uniform Resource Locator</rdfs:label>
<rdfs:comment>
The Uniform Resource Locator that identifies the Web Resource.
</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--WebResource:estimated size-->
<rdf:Property rdf:about="&bqsns;estimated_size">
<rdfs:label>Estimated Size</rdfs:label>
<rdfs:comment>
The estimated size of the Web Resource.
</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
<!--WebResource:cost-->
<rdf:Property rdf:about="&bqsns;cost">
<rdfs:label>Cost</rdfs:label>
<rdfs:comment>
The cost of the Web Resource.
</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
</rdf:Property>
</rdf:RDF>
- Specification Wide
- Many minor editorial changes have been made to all sections of the specification.
- Examples have been updated and expanded where appropriate.
- Section 2.1.2: The Advantages of Using RDF
- New information about the W3C's "SiRPAC" has been included.
- Section 2.1.3: Multiple Methods for Expressing Metadata in RDF
- Section 2.2.1: What is the Dublin Core?
- Section 2.2.2: The Advantages of Using Dublin Core
- Defines the use of the prefixes
dc (for Dublin Core)and dcq (Dublin Core Qualifiers).
- Section 2.3: vCard
- A new section that explains the use of the "vCard" system to give metadata about people. It has been included as the now standard method for this type information.
- Section 2.4: Bibliographic Query Service
- A generalized description of bibliographic referencing in RDF.
- Section 2.5: CellML Metadata
- A new section that describes the use of the
cmeta namespace prefix for all otherwise undefined CellML relevant metadata.
- Section 2.6: Namespaces in CellML Metadata
- With an accompanying table, appropriate namespace URIs and prefixes are given.
- Section 3: Fundamentals
- This section provides a new description of metadata
as it is defined within the an
<rdf:RDF> element.
- Section 3.2: Dublin Core Elements and Qualifiers
- A new table (Table 2) is provided giving suitable Dublin Core Metadata elements and their respective qualifiers.
- Section 4.5: Creation Date
<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". - The following encoding schemes have now been added to those
previously defined: GO Consortium (Gene Ontology controlled vocabulary), OMIM (Online Mendelian Inheritance in Man catalog of human genes and genetic disorders), LocusLink (LocusLink Genetic Loci database), and Unigene (GenBank non-redundant gene clusters database).
- Figure 20 now includes the use of the
<rdfs:label> element (an alternative to the <dc:title> element).
- Section 4.11: Mathematical Problem Type
<dcq:abstract> or <dcq:tableOfContents> replaces the previous <dc:description> that was qualified by <dcq:descriptionType>.
- Section 4.12: Description
<dcq:modified> replaces the <dcq:dateType> with the value of "modified".
- Section 4.13: Annotations
<cmeta:comment>, <cmeta:limitation>, <cmeta:modification> & <cmeta:validation> are now recommended instead of
<cmeta:annotation> with the <cmeta:annotation_type> qualifier.
- Section 5: Citations
- A new comprehensive section on citations has been added.
- Section 5.2.1: The identifier attribute
- The database elements
<bqs:medline_id>, <bqs:PubMed_id> & <bqs:CAS_id> replaces the need for the <dc:identifier_scheme> element to be used with the value of the database.
- Section 5.2.2: The cross_references attribute
<bqs:alternative> element can
provide and alternative identifier and replaces the <dc:identifier> and <bqs:identifier_type> combination.
- Section 5.2.3: The type attribute
<bqs:JournalArticle> replaces
<bqs:reference_type>.
- Section 5.2.6: The language attribute
- It is recommended that the RFC1766 encoding scheme is used to define the language of the cited resource. The
<dc:RFC1766> element replaces <dcq:language>.
- Section 5.2.7: The format attribute
<dcq:medium> element qualified by <dcq:IMT> is recommended to describe the cited resource, replacing <dc:format>.
- Section 5.2.8: The date attribute
- Updated to embrace the W3C-DTF format.
<dcq:issued> qualified by <dcq:W3CDTF> replaces the <dc:date> element.
- Section 5.4: The
<BibRefSubject> class
- Keywords:
<bqs:keywords> replaces <bqs:subject_type> value = keyword. - Subheadings:
<bqs:subject_heading> with <dcq:LCSH> or <dcq:MESH> replace <bqs:subject_type>, value = subject heading and
<dcq:subjectscheme> value = LCSH or UDC. - Codes:
<bqs:classification_code> with <dcq:DDC> or <dcq:UDC> replaces <bqs:subject_type> value=classification_code with <dcq:subjectScheme> with value = DDC or LCC.
- Section 5.5: The BibRefDescription class
- The
<dcq:abstract> &
<dcq:tableOfContents> elements replace <dcq:descriptiontype> with the values of abstract or tableofcontents. - Abstract_type and toc_type can be serilized with
<dcq:IMT> instead of the previous <dcq:format>. - Similarly the
<dcq:IMT> element replaces <dc:format> when used if the abstract of table of contents is supplied by a URI.
- Section 5.7: The EntryStatus class
- Information about the modification date of a citation is now given by the
<dcq:modified> element replacing the <dc:date> element.
- Section 5.10.1: The Book subclass
- The editor subclass element
<bqs:editor>
replaces the <dc:contributor> qualified by <bqs:contributor_type> with value = editor.
- Section 5.10.2: The Article subclass and its subclasses
- The from_book attribute is now
<bqs:book> instead of the <bqs:reference> with the type 'book'.
- Appendices
- Two new appendices "Cmeta Terms RDF SChema Draft" and "BQS Terms RDF Schema Draft" have been added.
| 
