CellML Metadata 1.0 Specification Draft

This Version:
          http://www.cellml.org/specifications/metadata/cellml_metadata_1.0
Latest Version:
          http://www.cellml.org/specifications/metadata/cellml_metadata_1.0
Previous Versions:
          http://www.cellml.org/specifications/archive/metadata/20011102/cellml_metadata_specification
          http://www.cellml.org/specifications/archive/metadata/20010518/cellml_metadata_specification
Authors:
          Autumn A. Cuellar (Bioengineering Research Group, University of Auckland)
          Melanie Nelson (Physiome Sciences Inc.)
          Warren Hedley (Bioengineering Research Group, University of Auckland)
Contributors:
          David Bullivant (Bioengineering Research Group, University of Auckland)
          Fred Livingston (Physiome Sciences Inc.)
          Catherine Lloyd (Bioengineering Research Group, University of Auckland)
          Poul Nielsen (Bioengineering Research Group, University of Auckland)

Abstract

This document specifies CellMLTM Metadata 1.0, the recommended method for identifying types of metadata embedded in a CellML document. The CellML specification recommends the use of the Resource Description Framework for the association of metadata with CellML objects. This document demonstrates how the Dublin Core, BQS and vCard data models can be used to classify metadata. It also defines some CellML-specific types of metadata.

Status of this document

This document is a draft version of the specification for version 1.0 of CellML Metadata. As a Working Draft, this specification may be updated, replaced, or made obsolete at any time. It is distributed for discussion purposes only and should not be used as a reference.

The authors invite feedback from the public. Readers are encouraged to subscribe and send comments to the cellml-discussion mailing list. Alternatively, readers may send comments and questions via e-mail to info@cellml.org.

The latest version of the CellML Metadata specification can always be found on the CellML website.

Contents

1  Introduction

1.1  Need for Metadata in CellML

Metadata is usually defined as "data about data". It is the supporting information that provides context to a resource. In CellML, the model (i.e. the structure and mathematics of the model) is the resource. Information that puts the model into a wider context is metadata. Metadata in CellML includes information such as the literature reference that supports the model, the identity of the creator(s) of the model, and the species for which the model is relevant.

The CellML project needs metadata for two primary reasons:

  • It will be difficult to reuse other people's models and components without metadata to provide the context for these objects. A modeller considering reusing someone else's model component will need to know things such as: what biological entity the component represents, for which species the component is relevant, and when the component was created and last modified (to help determine whether it is likely to incorporate the most recent experimental results).
  • As the number of models and components grows, metadata will provide the only scalable method for locating particular models and components. Experience in other biological fields shows that as a field grows, powerful search techniques are needed to enable researchers to find relevant resources. These search techniques require structured metadata.

Metadata in CellML can be used in many different ways, such as:

  • To support searches of a model repository (or at least to make it possible to automate loading of a database that will support such searches).
  • To enable automatic discovery of models published on remote websites, such as laboratory websites.
  • To allow the documentation for a model to be kept in the same document as the model itself, which will keep the documentation from becoming obsolete as work continues on the model.

The metadata structure should be flexible and extensible because it is almost certain that we have not thought of all possible uses of CellML Metadata.

1.2  The Larger Metadata Picture

Currently it is not particularly easy to find a specific piece of information on the web, and, once you have found the information, it is not easy to determine whether or not you should trust it. Metadata can address both of these problems. Therefore, there is a push to begin to incorporate metadata into web resources to allow users to get the maximum use out of the information on the web. Tim Berners-Lee has been particularly active in advocating a "semantic web" in which resources would include the semantic information necessary to allow machines to understand (not just read) them. The W3C has set up a semantic web activity to promote what they view as phase two of the Internet. Some software projects, such as Mozilla, have begun trying to take advantage of the metadata that is currently available about web resources. The CellML development team is working to make CellML compatible with the semantic web activity.

2  Background

The CellML development team has decided to use existing standards wherever possible to describe metadata. RDF, Dublin Core, vCard, and BQS are existing standards used to specify metadata. This section describes our use of these standards and our own CellML Metadata.

2.1  Resource Description Framework

Information about RDF can be found on the W3C's Resource Description Framework (RDF) Page.

2.1.1  What is RDF?

RDF, which stands for the "Resource Description Framework", is the W3C's recommendation for handling metadata on the web. The Resource Description Framework is just that: it is a framework that allows you to store descriptions (i.e. metadata) about resources. A resource can be literally anything. For the purposes of CellML, resources can be the model document, the model itself, or components in the model.

2.1.2  The advantages of using RDF

RDF by itself does not allow people to store metadata. It merely provides a standard framework onto which various groups can hang their metadata vocabularies. Some benefits of having this standard framework are:

  • It provides a common attribute=value data model for the metadata. All metadata expressed in RDF can be presented as a series of attributes (i.e. properties of the resource) and their values. For instance, one attribute=value pair for a CellML model might be species=Mus musculus.
  • It provides an extensible method for storing metadata of increasing complexity. Some metadata properties will have simple values, such as the species property shown above. Other metadata properties will have complex values. In the latter case, the value of the metadata property is itself considered a resource, and additional metadata properties are stored about it. This is made more clear by an example. Consider the case of the creator attribute. 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. This allows additional metadata to be stored about the person, such as the person's mailing address, phone number, etc. Most importantly, we don't have to know ahead of time what sorts of metadata processing software might want to store about the person. If a particular application wants to store the person's favourite colour, it can do so. Other applications might not recognise the meaning of the particular element that stores the favourite colour, but they will be able to understand that it is some sort of property about the resource (i.e. person) that is the creator of the model. This allows the application to handle the unknown metadata gracefully (most likely, many applications would at least be able to present the attribute=value pair to the user).
  • It makes it possible for applications that don't know anything about CellML to understand our metadata. Though not a reality yet, it is part of Tim Berners-Lee's vision of a semantic web. Eventually, search engine tools could become RDF capable. In that case, people would be able to perform much more powerful searches for information on the web. If someone wants to find all web resources created by John Doe, he/she could search explicitly for resources where creator=John Doe, instead of just searching for resources that contain the string "John Doe".
  • There are tools out there that use RDF. It is true that RDF is still a fledgling technology. However, there are tools out there that parse RDF and tools that actually use RDF to build databases, knowledge stores, and other such things. For instance, the W3C provides SiRPAC, a Simple RDF Parser and Compiler which returns a graphical representation of the RDF code it is fed to aid in visualization of the attribute=value constructs as well as validate RDF segments. See the W3C's RDF project list for a list of tools and projects using RDF.

2.1.3  The Generalized Structure of RDF

The RDF Model and Syntax Specification specifies a generalized structure. RDF's generalized structure allows many possible methods of storing metadata. RDF's flexible data model gives one the ability to add new classes of information without changing a previously specified schema; intead, the new classes build on the base schema. This extensibility makes RDF particularly appealing for use in CellML.

In order to ensure consistency of notation, the CellML development team has chosen one way of expressing metadata in RDF. This is the recommended way of implementing RDF in CellML, but it is not the only way of representing metadata. From here on, the rdf prefix will be used to indicate that elements and attributes are in the RDF namespace.

2.2  The Dublin Core Metadata Initiative

Information about the Dublin Core Metadata Initiative can be found on the Dublin Core's website.

2.2.1  What is the Dublin Core?

The Dublin Core is a group of metadata properties. These properties were identified as "common" across a large range of resources by a group of library science and knowledge management communities. These properties include attributes like creator, publisher, subject, and date. A full list is found in Table 3, and their corresponding definitions can be found in the Dublin Core Metadata Element Set, Version 1.1: Reference Description.

The Dublin Core Metadata Initiative group has also provided a standard set of "qualifier" elements. These elements add information to the basic elements. Qualifier elements either provide type information or scheme information. Type information classifies the basic element. For instance, the date element can have a type of created, modified, valid, available, or issued. Scheme information indicates how the content of the element is encoded. For instance, the date element can have a scheme of W3C-DTF or DCMI Period. A full list of qualifiers and their allowed values can be found in Table 2, and their corresponding definitions can be found in the Dublin Core Qualifiers document.

It is important to note that Dublin Core does not have to be expressed in RDF. The Dublin Core elements are not elements in the XML sense. They are simply standard names and definitions for common types of metadata. However, the Dublin Core Metadata Initiative has released two articles that suggest a method for implementing an RDF representation of Dublin Core elements and qualifiers: Expressing Simple Dublin Core in RDF/XML and Expressing Qualified Dublin Core in RDF/XML, respectively. These suggestions have been adopted for use in CellML.

2.2.2  The advantages of using Dublin Core

The Dublin Core set of elements is widely referenced, and the W3C designed the Resource Description Framework with the Dublin Core in mind. General purpose tools are more likely to understand the Dublin Core metadata vocabulary than any other vocabulary. Also, using the Dublin Core metadata vocabulary makes it obvious that certain CellML Metadata properties (such as model creator) map directly to metadata properties that are found in other fields.

Henceforth, the prefixes dc and dcterms will indicate that elements and attributes are in the Dublin Core and the Dublin Core Qualifiers namespaces, respectively.

2.3  vCard

At the time of writing, the only existing RDF definition of metadata about people is a note submitted to the W3C in February 2001 entitled Representing vCard Objects in RDF/XML. (This note is the work of Renato Iannella working at the Distributed Systems Technology Centre at the University of Queensland and orginally appeared on their RDF project page.) This note's suggestions are widely used for referencing people in RDF.

As the vCard data model includes some elements that are not necessary for CellML Metadata, such as nickname and birthday, we will not require CellML processing software to recognize those elements. However, model authors are free to use them. That is, the use of vCard elements outside of the list defined in the CellML Metadata specification will not invalidate the metadata, but these elements may not necessarily be recognized by all CellML Metadata compliant processing software.

CellML Metadata compliant processing software is expected to recognize the following "vCard in RDF" elements that meet the information needs of CellML:

  • <vCard:N> (the name construct), with all of its subelements:
    • <vCard:Family>: the person's family, or last name
    • <vCard:Given>: the person's given, or first name
    • <vCard:Other>: additional names, used for middle names and initials
    • <vCard:Prefix>: honorific prefixes, such as "Dr."
    • <vCard:Suffix>: suffixes such as "III" and "Jr."
  • <vCard:ADR> (the mailing address construct), with all of its subelements:
    • <vCard:Pobox>: post office box
    • <vCard:Street>: street address
    • <vCard:Locality>: city, town, rural route, etc.
    • <vCard:Region>: state, etc.
    • <vCard:Country>: country
    • <vCard:Pcode>: postal code (such as the American zip code)
    • <vCard:Extadd>: extended address field. This is used to include the company or institution name.
  • <vCard:EMAIL> (the e-mail address construct)
  • <vCard:TEL> (the telephone number construct)
  • <vCard:ORG> (the organization construct), with all of its subelements:
    • <vCard:Orgname>: the name of the organization (i.e. "The University of Auckland")
    • <vCard:Orgunit>: the division or department (i.e. "The Bioengineering Research Group")
  • <vCard:TITLE>: the person's job title
  • <vCard:ROLE>: the person's job role

The <rdf:type> element is used to specify "type parameters" on certain vCard elements. For instance, an address may be typed as domestic, international, postal, parcel, home, work, or preferred. Table 1 lists the vCard properties used in CellML that have a type parameter with their possible values. Note that one address may be given more than one type. See Figure 33 for an example of how to use the <rdf:type> element in vCard.


vCard PropertyType Parameter Values
TELhome, msg, work, pref, voice, fax, cell, video, pager, bbs, modem, car, isdn, pcs
EMAILinternet, x400, pref
ADRdom, intl, postal, parcel, home, work, pref

Table 1 The names, URIs and recommended prefixes of the namespaces referenced in this specification.


Examples throughout the rest of this specification demonstrate the use of vCard elements in RDF. These elements are preceded by the vCard prefix to indicate that they are in the vCard namespace.

2.4  Bibliographic Query Service

No bibliographic standards exist within RDF/XML at the time of writing. However, the Object Management Group has published the Bibliographic Query Service Specification. The DsLSRBibObjects Module from this specification presents an excellent general data model for bibliographic references. The CellML development team recommends an RDF serialization of this data model (henceforth referred to as the "BQS data model") described in detail in Section 5 of this document. BQS metadata is designated by the namespace prefix bqs in this specification.

2.5  CellML Metadata

A CellML Metadata namespace has been created to include all metadata that has not been previously defined by the four standards listed above. These include biology-related attributes (such as species and bio-entities) as well as properties we felt were missing from other standards (such as annotations). We recommend CellML Metadata be designated by the namespace prefix cmeta.

2.6  Namespaces in CellML Metadata

Namespace URIs and recommended prefixes are given in Table 2.


Namespace NameNamespace URIRecommended Prefix
CellML Metadata"http://www.cellml.org/metadata/1.0#"cmeta
RDF"http://www.w3.org/1999/02/22-rdf-syntax-ns#"rdf
RDF Schema"http://www.w3.org/2000/01/rdf-schema#"rdfs
Dublin Core"http://purl.org/dc/elements/1.1/"dc
DC Qualifiers"http://purl.org/dc/terms/"dcterms
vCard"http://www.w3.org/2001/vcard-rdf/3.0#"vCard
BQS"http://www.cellml.org/bqs/1.0#"bqs

Table 2 The names, URIs and recommended prefixes of the namespaces referenced in this specification.


3  Fundamentals

Metadata is defined within an <rdf:RDF> element as shown in Figure 1. The recommended best practice is to define the RDF namespace and any namespaces used by the enclosed metadata on the <rdf:RDF> element, even if these namespaces are already defined on the ancestor elements of the <rdf:RDF> element. This increases the re-usability of the RDF block. Furthermore, RDF processing software that does not recognise the CellML namespace can still parse a CellML document, extract the RDF blocks, and perhaps provide useful functionality with the information described in the RDF.


<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  
<rdf:Description 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 the ID attribute preceded by a hash (#). In CellML, the attribute referred to is the cmeta:id attribute on any element.

RDF is processed as triples: a resource is assigned a property of a certain value. For instance, in Figure 2, the resource (the element referenced by "Wilma_Flintstone") is assigned a property of <spouse> with a value of Fred Flintstone.


<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: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:about="#Wilma_Flintstone">
    
<toon:spouse rdf:id="spouse">Fred Flintstone</toon:spouse>
  
</rdf:Description>
  
<rdf:Description rdf:about="#spouse">
    
<toon:favourite_hobby>bowling</toon:favourite_hobby>
  
</rdf:Description>
</rdf:RDF>

Figure 3 A set of two RDF triples, in which the second <rdf:Description> element describes Wilma's spouse, as indicated by the second rdf:about attribute.


Figure 4 shows an alternative method to describe the two triples shown in Figure 3. The second <rdf:Description> element is embedded in the <toon:spouse> element to indicate that it is a new resource.


<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: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 triples, as in Figure 3. This example shows that a new resource can be created by embedding the <rdf:Description> element in the element it is describing.


Figure 5 shows yet another way to describe the two triples. This example uses the rdf:parseType attribute with a value of "Resource" to introduce a new resource (instead of the <RDF:Description> element used in the previous example). The CellML Metadata Specification uses this method frequently because it is less verbose than the methods described in the previous two examples.


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


3.1  Containers

RDF provides the ability to indicate a sequence with the use of containers. The containers <rdf:Bag>, <rdf:Seq>, and <rdf:Alt>, denote an unordered sequence, an ordered sequence, and alternative choices, respectively. Figure 6 demonstrates the use of the <rdf:Bag> element. Each family member of the Jetsons is an equal member of the family. They are grouped together using the <rdf:Bag> element to show that they all belong to the same family.


<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: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:about="#Jetsons">
    
<toon:age>
      
<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:about="#companies">
    
<toon:supply>
      
<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.


3.2  Dublin Core Elements and Qualifiers

The Dublin Core Metadata Elements and their corresponding qualifiers are listed in Table 3.


DC Metadata ElementElement Refinement(s)Element Encoding Scheme(s)
TitleAlternative-
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
Extent
Medium
-
IMT
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
Spatial
Temporal
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: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.


4  General Metadata

4.1  Model Creator

Model creator metadata stores information about the person or persons who coded the model into CellML. A given element can have multiple model creators who may need to be considered as individuals or as members of a group. If they are members of a group, the group may or may not need to be ordered.

Model creator metadata is defined using the Dublin Core creator element, <dc:creator>. Repeating this element for a given CellML element indicates that the people listed worked independently on the model. This definition is shown in Figure 10. Listing multiple people in the <dc:creator> element using an <rdf:Bag> container indicates that the group of people worked together on the model and that they are all considered equal contributors. This definition is shown in Figure 11. Listing multiple people in the <dc:creator> element using an <rdf:Seq> container indicates that the group of people worked together on the model and that their contributions are ordered (the first member of the list is first author, the second member is second author, and so on). Metadata authors are free to use the <rdf:Alt> container (as long as they produce valid RDF). However, CellML Metadata compliant software is not required to be able to consistently interpret the meaning of an <rdf:Alt> container in this context. Note that in the examples shown here, the basic vCard "name" construct is used to store the name of the model creator.


<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:parseType="Resource">
      
<vCard:N rdf:parseType="Resource">
        
<vCard:Family>Flintstone</vCard:Family>
        
<vCard:Given>Fred</vCard:Given>
      
</vCard:N>
    
</dc:creator>
    
<dc:creator rdf:parseType="Resource">
      
<vCard:N rdf:parseType="Resource">
        
<vCard:Family>Brown</vCard:Family>
        
<vCard:Given>Charlie</vCard:Given>
      
</vCard:N>
    
</dc:creator>
    
<dc:creator rdf:parseType="Resource">
      
<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 creator 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 rdf:parseType="Resource">
          
<vCard:N rdf:parseType="Resource">
            
<vCard:Family>Flintstone</vCard:Family>
            
<vCard:Given>Fred</vCard:Given>
          
</vCard:N>
        
</rdf:li>
        
<rdf:li rdf:parseType="Resource">
          
<vCard:N rdf:parseType="Resource">
            
<vCard:Family>Brown</vCard:Family>
            
<vCard:Given>Charlie</vCard:Given>
          
</vCard:N>
        
</rdf:li>
        
<rdf:li rdf:parseType="Resource">
          
<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 creator metadata in which multiple people worked together on the model and all are considered equal contributors.


4.2  Contributor

Contributor metadata indicates that a person contributed to a resource but did not actually create it (such as an editor).

Contributor metadata is defined using the Dublin Core contributor element, <dc:contributor>, as shown in Figure 12. Multivalued contributor metadata is handled exactly as multivalued model creator metadata. Simple repetition of the element indicates that the people contributed to the resource independently. The use of RDF bag (<rdf:Bag>) or sequence (<rdf:Seq>) containers indicates that the people contributed to the resource as an unordered or ordered group, respectively.


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


4.3  Publisher

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

Publisher metadata is defined with the Dublin Core publisher element (<dc:publisher>), as shown in Figure 13. Multivalued publisher metadata is handled exactly as multivalued model creator metadata. Simple repetition of the element indicates that the people or organisations publish the resource independently. The use of RDF bag (<rdf:Bag>) or sequence (<rdf:Seq>) containers indicates that the people or organisation published the resource as an unordered or ordered group, respectively.


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


4.4  Copyright

The copyright metadata refers to the copyright that protects the CellML document, model, model component, or other CellML element. It is defined using the Dublin Core rights element (<dc:rights>), and, therefore, a given CellML element can technically have multiple copyrights. However, the recommended practice is to include only one copyright for any given element.

Figure 14 demonstrates the definition of the copyright metadata.


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


4.5  Creation Date

The creation date is the date upon which the model or model part was coded into CellML. A given CellML element can have only one creation date.

Creation date metadata is defined using the Dublin Core date qualifier element, <dcterms:created>. The creation date is further qualified by using the Dublin Core date encoding scheme qualifier element, <dcterms:W3CDTF>, which indicates a YYYY-MM-DD format. The definition of creation date metadata is demonstrated in Figure 15.


<rdf:RDF
    
xmlns:dc="http://purl.org/dc/elements/1.1/"
    
xmlns:dcterms="http://purl.org/dc/terms/"
    
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  
  
<rdf:Description rdf:about="#cellml_element_id">
    
<dcterms:created rdf:parseType="Resource">
      
<dcterms:W3CDTF>2000-10-05</dcterms:W3CDTF>
    
</dcterms:created>
  
</rdf:Description>
</rdf:RDF>

Figure 15 Recommended definition of the creation date metadata.


4.6  Modification History

The modification history lists changes that have been made to the CellML document. Each separate alteration can be described in its own <cmeta:modification> element. Each modification listed should also include the name of the person who made the changes in a <cmeta:modifier> element and the date the document was modified in the Dublin Core date qualifier element, <dcterms:modified>. The definition of modification history metadata is demonstrated in Figure 16.


<rdf:RDF
    
xmlns:cmeta="http://www.cellml.org/metadata/1.0#"
    
xmlns:dcterms="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 to correspond with recent
        changes in MathML.
      
</rdf:value>
      
<cmeta:modifier rdf:parseType="Resource">
        
<vCard:N rdf:parseType="Resource">
          
<vCard:Family>PowerPuff</vCard:Family>
          
<vCard:Given>Bubbles</vCard:Given>
        
</vCard:N>
      
</cmeta:modifier>
      
<dcterms:modified rdf:parseType="Resource">
        
<dcterms:W3CDTF>2001-04-01</dcterms:W3CDTF>
      
</dcterms:modified>
    
</cmeta:modification>
    
<cmeta:modification rdf:parseType="Resource">
      
<rdf:value>
        Added an encapsulating component for re-use capabilities.
      
</rdf:value>
      
<cmeta:modifier rdf:parseType="Resource">
        
<vCard:N rdf:parseType="Resource">
          
<vCard:Family>PowerPuff</vCard:Family>
          
<vCard:Given>Buttercup</vCard:Given>
        
</vCard:N>
      
</cmeta:modifier>
      
<dcterms:modified rdf:parseType="Resource">
        
<dcterms:W3CDTF>2001-02-17</dcterms:W3CDTF>
      
</dcterms:modified>
    
</cmeta:modification>
  
</rdf:Description>
</rdf:RDF>

Figure 16 Recommended definition of the modification history metadata.


4.7  Alternative Names

Alternative name metadata provides human-readable names for CellML elements. This alternat name could be used by software whenever it needs to display a human-readable name. The use of this metadata allows us to limit the values of name attributes on CellML elements to enable efficient code generation, without worrying about whether or not the name will be sufficiently meaningful to human readers.

Alternative name metadata is defined with the Dublin Core title qualifier element, <dcterms:alternative>. One element may have multiple alternative names. Only one should be considered the preferred human-readable name. The preferred name should be stored in a <dc:title> element. Additional names should be stored in the <dcterms:alternative> element.

Figure 17 shows the definition of alternative name metadata. The element referenced by "#cellml_element_id" is given two human-readable names. The preferred one is "EGF-EGFR complex".


<rdf:RDF
    
xmlns:dc="http://purl.org/dc/elements/1.1/"
    
xmlns:dcterms="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>
    
<dcterms:alternative>epidermal growth factor-epidermal growth factor 
    receptor complex
</dcterms:alternative>
  
</rdf:Description>
</rdf:RDF>

Figure 17 Recommended definition of alternative name metadata.


4.8  Species

Species metadata refers to the biological species (such as human, dog, pig, Palaemon affinis, etc.) for which an element is relevant. A given CellML element may be relevant for multiple species. It may also be relevant for an entire class of species, such as all mammals.

Species metadata is defined with a CellML-specific metadata element, <cmeta:species>, as shown in Figure 18. The content of this metadata must be a valid scientific name for a species or group of species. Notwithstanding recent arguments among taxonomists about the impact of genomic data on species classifications, scientific names are considered to be sufficiently standard to obviate the need to use a formal controlled vocabulary. The CellML Metadata specification recommends using NCBI's Taxonomy Browser as a resource for scientific names. If a modeller needs to refer to a discontinuous group of species (i.e. one that cannot be specified by a single scientific name) he/she can include multiple <cmeta:species> elements. Multiple values for the species metadata will always mean that the CellML element is relevant for any one of the species listed. Relevance to all of the species as a group would imply some sort of population dynamics model, which is outside of the scope of CellML.


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


4.9  Sex

Sex metadata refers to the sex for which a CellML element is relevant. A given element may be relevant for more than one sex.

Sex metadata is defined with the CellML-specific element, <cmeta:sex>, as shown in Figure 19. The valid content of this element must be chosen from the following controlled vocabulary:

  • male
  • female
  • hermaphrodite
  • other
  • all
  • undefined (the element is explicitly specified not to have a defined relevance to any particular sex).

<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


4.10  Biological Entity

This area of the metadata will almost certainly be expanded in future versions of CellML. For now it is simply a name or database unique identifier for a biological entity, such as an ion channel, signalling pathway, or specific cell type, that is represented by the model or model component. A given CellML element can represent multiple biological entities either as a complete group or as a list of alternatives. A CellML element that represents a list of alternative biological entities would probably be a "superclass" component that will be re-used multiple times in a model, each time to represent a different entity on the list of alternatives. For instance, a modeller might define a general "calcium-binding protein" component and then re-use this component three times in his/her model: once to represent calmodulin, once to represent troponin C, and once to represent parvalbumin. [Note that the component re-use capabilities are not yet defined in CellML. They will be a part of a future version of CellML. The list of alternative biological entities metadata construct is provided now for use in the future.]

Biological entity metadata is defined using a CellML-specific element, <cmeta:bio_entity>. A biological entity may be identified by name, database identifier, or both. Multiple database identifiers may be provided, but all except one must be marked "alternative".

Each database identifier is stored in a <cmeta:identifier> clarified with a <cmeta:identifier_scheme> element that identifies the database. The CellML metadata specification will control names for certain encoding schemes (see below). The <cmeta:identifier> element may also be qualified by a <cmeta:identifier_type> element. This element should have a value of "alternative" for all <cmeta:identifier> elements except for one, which is considered the primary identifier. This addresses a concern about allowing multiple database identifiers that might actually refer to different biological entities. Such an error may still occur, but marking all identifiers except one as "alternative" provides software a method by which to determine which identifier should be given precedence.

The CellML metadata specification will define the following encoding schemes:

  • SWISS-PROT (SWISS-PROT protein database)
  • GenBank (GenBank nucleic acid database)
  • GO Consortium (Gene Ontology controlled vocabulary)
  • OMIM (Online Mendelian Inheritance in Man catalog of human genes and genetic disorders)
  • LocusLink (LocusLink genetic loci database)
  • Unigene (GenBank non-redundant gene clusters database)
  • URI (URI for a web resource providing info about the biological entity)

Model authors and authors of processing software are free to define additional encoding schemes, but an rdf:resource attribute must be used on the <cmeta:identifier_scheme> element to provide the URI that identifies the database.

RDF containers can be used to indicate that a given CellML element is relevant for more than one biological entity. An <rdf:Bag> element can be used to indicate that the CellML element is relevant for an entire group of biological entities. An <rdf:Alt> element can be used to indicate that the CellML element can be relevant for one member of a group of entities. Note that the first member listed in the <rdf:Alt> element will be considered the preferred value. The use of the <rdf:Bag> element is shown in Figure 20. The use of the <rdf:Alt> element would be similar. CellML Metadata compliant software will be required to recognize RDF containers in biological entity metadata. The use of RDF containers is preferred to simply repeating the <cmeta:bio_entity> element because it removes all ambiguity about how the group of biological entities relates to the referenced CellML element.

Figure 20 demonstrates the definition of biological entity metadata. Using the <rdfs:label> element is an alternative to using the <dc:title> element: it is a human-readable title of the database value.


<rdf:RDF
    
xmlns:cmeta="http://www.cellml.org/metadata/1.0#"
    
xmlns:dc="http://purl.org/dc/elements/1.0/"
    
xmlns:dcterms="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>
          
<dcterms:alternative>CaM</dcterms: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.


4.11  Mathematical Problem Type

The mathematical problem type is a classification of the type of problem encoded in the math associated with the model or model component. It is specified using NIST's GAMS classification tree.

Mathematical problem type is defined using a CellML-specific element, <cmeta:GAMS>. Modellers are free to use a different controlled vocabulary for the math problem classifications by using a <cmeta:math_problem> element clarified by a nested <cmeta:math_problem_scheme>. However, CellML Metadata compliant software is not required to recognize any classification scheme other than the GAMS tree.

Figure 21 shows the recommended definition of mathematical problem type metadata.


<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 rdf:parseType="Resource">
      
<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.


4.12  Description

Description metadata is a short description of the referenced resource. Description metadata is defined with either of the Dublin Core description qualifier elements, <dcterms:abstract> or <dcterms:tableOfContents>. Use of the <dcterms:abstract> element will most likely be more common in CellML Metadata.

Figure 22 shows how to define description metadata.


<rdf:RDF
    
xmlns:dcterms="http://purl.org/dc/terms/"
    
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
    
  
<rdf:Description rdf:about="#cellml_element_id">
    
<dcterms:abstract>
      This element uses simple mass-action kinetics to describe the
      A + B <-> C + D reaction.
    
</dcterms:abstract>
  
</rdf:Description>
</rdf:RDF>

Figure 22 Recommended definition of the Dublin Core description metadata.


4.13  Annotations

There are three types of annotations that are recognized by the CellML Metadata specification. Model authors are free to create additional types. However, CellML Metadata compliant software will not be required to recognize any annotation types except for the following three:

  • comment: free-form comment of the person who coded the model into CellML.
  • limitation: brief description of the limitations/scope of the content of the CellML element.
  • validation: description of the level of validation of the content of the CellML element. This may be a code. Note that validation codes are unlikely to be interoperable.

Annotation metadata is defined using CellML-specific elements: <cmeta:comment>, <cmeta:limitation>, and <cmeta:validation>. If a model author wishes to use a different type of annotation, he/she may specify an <cmeta:annotation_type> within a <cmeta:annotation> element.

Each annotation also has creator and creation date metadata that refers to it. The author metadata associated with an annotation is defined exactly as the model creator metadata (Section 4.1), and creation date metadata associated with an annotation is defined exactly as the general creation date metadata (Section 4.5).

Figure 23 demonstrates the definition of comment and limitation annotations. Figure 24 demonstrates the definition of the validation annotation.


<rdf:RDF
    
xmlns:cmeta="http://www.cellml.org/metadata/1.0#"
    
xmlns:dc="http://purl.org/dc/elements/1.1/"
    
xmlns:dcterms="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 rdf:parseType="Resource">
        
<vCard:N rdf:parseType="Resource">
          
<vCard:Family>PowerPuff</vCard:Family>
          
<vCard:Given>Bubbles</vCard:Given>
        
</vCard:N>
      
</dc:creator>
      
<dcterms:created rdf:parseType="Resource">
        
<dcterms:W3CDTF>2001-04-01</dcterms:W3CDTF>
      
</dcterms: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 rdf:parseType="Resource">
        
<vCard:N rdf:parseType="Resource">
          
<vCard:Family>Doo</vCard:Family>
          
<vCard:Given>Scooby</vCard:Given>
        
</vCard:N>
      
</dc:creator>
      
<dcterms:created rdf:parseType="Resource">
        
<dcterms:W3CDTF>2001-03-28</dcterms:W3CDTF>
      
</dcterms: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:dcterms="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:validation rdf:parseType="Resource">
      
<rdf:value>Physiome level 2</rdf:value>
      
<dc:creator rdf:parseType="Resource">
        
<vCard:N rdf:parseType="Resource">
          
<vCard:Family>Too</vCard:Family>
          
<vCard:Given>Shaggy</vCard:Given>
        
</vCard:N>
      
</dc:creator>
      
<dcterms:created rdf:parseType="Resource">
        
<dcterms:W3CDTF>2001-03-28</dcterms:W3CDTF>
      
</dcterms:created>
    
</cmeta:validation>
  
</rdf:Description>
</rdf:RDF>

Figure 24 Recommended definition of validation annotation metadata.


5  Citations

5.1  Introduction

The BQS data model draws extensively from the Dublin Core metadata element set. Therefore, the RDF serialization of these elements is used wherever possible. The following sections define the CellML recommended RDF serialization of the DsLSRBibObjects Module from OMG's Bibliographic Query Service Draft Specification.

5.2  The BibliographicReference Class

The BibliographicReference class is the root class for all reference information. It is represented in RDF by the <bqs:reference> element. This element creates a reference resource. All further content of this element provides metadata about the reference resource itself.

5.2.1  The identifier attribute

The identifier attribute on the BibliographicReference class provides a way to identify a cited reference using a database identifier (such as a Medline UI) instead of by providing the complete reference details.

The CellML Metadata Specification recommends the use of the following databases:

  • 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 rdf:parseType="Resource">
      
<bqs:Medline_id>97219925</bqs:Medline_id>
    
</bqs:reference>
  
</rdf:Description>
</rdf:RDF>

Figure 25 Serialization of the BibliographicReference class's identifier attribute.


5.2.2  The cross_references attribute

The cross_references attribute on the BibliographicReference class is intended to store alternative identifers for the reference represented by the contents of the identifier attribute. This can be represented by the use of the <rdf:Bag> and <rdf:Alt> containers. The <rdf:Bag> element may be used to indicate that both identifiers are equivalent. The <rdf:Alt> container may be used to indicate that one identifier is preferred to the other(s). The use of the containers was chosen over listing the identifiers without a container to prevent confusion should a model be based on more than one reference.


<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:Bag>
        
<rdf:li rdf:parseType="Resource">
          
<bqs:Medline_id>97219925</bqs:Medline_id>
        
</rdf:li>
        
<rdf:li rdf:parseType="Resource">
          
<bqs:PubMed_id>9067300</bqs:PubMed_id>
        
</rdf:li>
      
</rdf:Bag>
    
</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.


5.2.3  The type attribute

The type attribute on the BibliographicReference class identifies the "genre" of the cited resource. The BQS data model provides constructs for the following types of references:

  • "Article" (subclassed into "JournalArticle", for journal articles, and "BookArticle", for book chapters).
  • "Book"
  • "Patent"
  • "Proceeding"
  • "TechReport" (note that this can be used for unpublished reports)
  • "Thesis"
  • "WebResource"

It is possible to create additional types of references using the BQS data model. The basic information would be provided by the BibliographicReference class. Information specific to the new type of reference would need to be provided as a subclass by the person wishing to create the new reference type.

Each of the above genres is given its own element inside the BQS namespace. Figure 27 shows the use of the <bqs:JournalArticle> element.


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


5.2.4  The title attribute

The title attribute on the BibliographicReference class is used to store the title of the resource being referenced. For instance, if the referenced resource is a book chapter, the title metadata would be the title of the chapter.

The title metadata is identified with the Dublin Core <dc:title> element, as shown in Figure 28. An xml:lang attribute could be used to indicate the language of the title.


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


5.2.5  The rights attribute

The rights attribute on the BibliographicReference class provides information about the rights over the cited resource. This attribute would typically contain either a statement of the rights or a reference to a resource (such as a web page) that states the rights. Rights information may include intellectual property rights and copyrights. No assumptions can be made about the rights on the resource in the absence of this attribute.

This rights attribute maps directly to the Dublin Core <dc:rights> element. The serialization is shown in Figure 29.


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


5.2.6  The language attribute

The language attribute on the BibliographicReference class defines the language of the cited resource. Using the RFC1766 encoding scheme for this information is recommended. Language metadata can be stored using the qualified Dublin Core language qualifier <dcterms:RFC1766> element, as shown in Figure 30.


<rdf:RDF
    
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
    
xmlns:dcterms="http://purl.org/dc/terms/"
    
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">
    
<bqs:reference rdf:parseType="Resource">
      
<dcterms:RFC1766>en-UK</dcterms:RFC1766>
      
<rdfs:label>United Kingdom English</rdfs:label>
    
</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.


5.2.7  The format attribute

The format attribute on the BibliographicReference class describes the "physical or digital manifestation of the cited resource". The value of this attribute will depend heavily on the reference type. For instance, a web resource reference might have format values of application/pdf or text/html. This serialization of the BQS data model will not attempt to extend the values of this attribute beyond what is provided by the Dublin Core.

The Dublin Core recommends using the Internet Media Type (IMT) encoding scheme for formats, commonly called MIME types. A list of these types is provided by the Information Sciences Institute at the University of Southern California. The format metadata is serialized using the qualified Dublin Core format qualifier <dcterms:medium> element, which is further qualified with a nested <dcterms:IMT>, as shown in Figure 31.


<rdf:RDF
    
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
    
xmlns:dcterms="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">
      
<dcterms:medium rdf:parseType="Resource">
        
<dcterms:IMT>application/pdf</dcterms:IMT>
      
</dcterms: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.


5.2.8  The date attribute

The date attribute on the BibliographicReference class "defines a date associated with an event in the life cycle of the cited resource". For public resources, this should be the publication date. For private resources (such as unpublished technical reports), this should be the creation date.

Date metadata can be stored in a date-qualified Dublin Core element, as shown in Figure 32.


<rdf:RDF
    
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
    
xmlns:dcterms="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">
      
<dcterms:issued rdf:parseType="Resource">
        
<dcterms:W3CDTF>1997-04-23</dcterms:W3CDTF>
      
</dcterms:issued>
    
</bqs:reference> 
  
</rdf:Description>
</rdf:RDF>

Figure 32 Serialization of date information. This metadata indicates the cited resource was published on April 23, 1997 (note that the W3C-DTF encoding allows full dates, month/year dates, and year-only dates).


5.2.9  The authors attribute

The authors attribute stores information about the authors of the cited reference. Its value is an instance of the Provider class. The serialization of this class is discussed in Section 5.3. If there is more than one author for the reference, the BQS data model requires that these authors be stored in an ordered list.

The authors attribute can be serialized using the Dublin Core <dc:creator> element. Multiple authors can be stored in an <rdf:Seq> container, which creates an ordered list.

Figure 33 demonstrates how to store author metadata.


<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 rdf:parseType="Resource">
            
<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 rdf:parseType="Resource">
            
<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 rdf:parseType="Resource">
            
<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.


5.2.10  The contributors attribute

The contributors property can be used to store information about a person or entity that contributed to, but did not create, the reference. It can be serialized using the Dublin Core <dc:contributor> element, as shown in Figure 34. If there is more than one contributor, the <rdf:Seq> container can be used to create an ordered list, as was done for the authors property.


<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 organisation (in this example, a company) is listed. This company may have provided graphics work for the cited reference. In this example, there is only one contributor. However, an <rdf:Seq> container could be used to create an ordered list of contributors, as was done in the author example. If the contributors were people, information about them could be stored using vCard, as shown in the authors example.


5.2.11  The publisher attribute

The publisher attribute stores information about the publisher of the reference. It can be serialized using the Dublin Core <dc:publisher> element, as shown in Figure 35. Only one publisher is allowed, so no RDF containers may be used in this element.


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


5.3  The Provider class

The Provider class is the base class for the Person, Organization, and Service classes. These classes are used by the authors, contributors, and publisher attributes on the BibliographicReference class. The BQS data model allows only one publisher and requires that the authors and contributors be provided as an ordered list.

The Provider class is serialized by embedding the information directly in the RDF element that serializes the authors, contributors, publisher, or editor attribute. Multiple providers are supported using an <rdf:Seq> container. The subclass of provider is given its own element. The valid values are <bqs:Person>, <bqs:Organization> (or <bqs:Organisation>), and <bqs:Service>.

5.3.1  The Person subclass

Structured information about a person can be stored using the appropriate vCard constructs. See Section 2.3 for more information on vCard in CellML Metadata. Figure 33 demonstrates the use of the <bqs:Person> element.

5.3.2  The Organization and Service subclasses

The organisation and service information is a name stored as a string. This can be entered directly as the content of an RDF element. Examples of the use of the Organization and Service subclasses are shown in Figure 34 and Figure 35.

5.4  The BibRefSubject class

The BibRefSubject class defines the topic of the resource. It has three attributes, keywords, subheadings and codes, which provide a means to store keywords, subject headings, and classification codes about the cited resource, respectively.

An example demonstrating the serialization of subject metadata is shown in Figure 36.


<rdf:RDF
    
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
    
xmlns:dc="http://purl.org/dc/elements/1.1/"
    
xmlns:dcterms="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 rdf:parseType="Resource">
        
<dcterms:MESH>
          
<rdf:Bag>
            
<rdf:li>Signal Transduction</rdf:li>
            
<rdf:li>Ion Transport</rdf:li>
          
</rdf:Bag>
        
</dcterms:MESH>
      
</bqs:subject_heading>
      
<bqs:classification_code rdf:parseType="Resource">
        
<dcterms:DDC>572</dcterms: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>, no Dublin Core Qualifier elements.
  • subheadings: <bqs:subject_heading>, Dublin Core Qualifier elements of <dcterms:LCSH> (Library of Congress Subject Headings) or <dcterms:MESH> (Medical Subject Headings).
  • codes: <bqs:classification_code>, Dublin Core Qualifier elements of <dcterms:DDC> (Dewey Decimal Classification), LCC (Library of Congress Classification), or <dcterms:UDC> (Universal Decimal Classification).

In all cases, multiple values should be stored in the appropriate RDF container.

5.5  The BibRefDescription class

The BibRefDescription class allows storage of a summary of the contents of the cited reference. This summary could be an abstract or a table of contents and may be in a language different from that of the actual reference. More than one summary may be stored about a reference. The BQS Specification states that the contents of the abstract and table of contents attributes may be more than just plain text and proposes using MIME types to identify the format of these contents.

The the_abstract and table_of_contents attributes are serialized using the Dublin Core Qualifier elements, <dcterms:abstract> element and <dcterms:tableOfContents>, respectively. The language attribute can be indicated by an xml:lang attribute. Note that an <rdf:Alt> container can be used to provide the description in various languages.

The abstract_type and toc_type attributes are serialized with the Dublin Core <dcterms:IMT> element (this indicates the use of a MIME type for the value of the format element). The full serialization of description metadata is shown in Figure 37.

If the abstract or table of contents is supplied by a URL, the URL should be entered as the value of an rdf:resource attribute on the <dcterms:abstract> or the <dcterms:tableOfContents> element. This is shown for the abstract information in Figure 37.


<rdf:RDF
    
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
    
xmlns:dc="http://purl.org/dc/elements/1.1/"
    
xmlns:dcterms="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">
      
<dcterms:abstract
        
rdf:resource="http://www.abstractsRus.com/abstract567843"
        
xml:lang="en" />
      
<dcterms:tableOfContents rdf:parseType="Resource" xml:lang="en">
        
<dcterms:IMT>text/html</dcterms:IMT>
        
<rdf:value rdf:parseType="Literal">
          
<p> ... table of contents info here ...</p>
        
</rdf:value>
      
</dcterms:tableOfContents>
    
</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.


5.6  The BibRefScope class

The BibRefScope class is used to provide information about the intended scope or extent of the cited reference. It can include spatial location information and/or temporal period information in its spatial_location and temporal_period attributes.

This metadata can be mapped directly to the Dublin Core <dc:coverage> element, qualified to indicate whether the coverage is spatial or temporal and to provide the encoding scheme of the content. The qualifiers <dcterms:spatial> and <dcterms:temporal> and their corresponding encoding schemes are listed in Table 3. Two instances of this element can be used to include both spatial and temporal information.

Figure 38 shows the serialization of the scope metadata.


<rdf:RDF
    
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
    
xmlns:dc="http://purl.org/dc/elements/1.1/"
    
xmlns:dcterms="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">
      
<dcterms:temporal rdf:parseType="Resource">
        
<dcterms:W3CDTF>1997</dcterms:W3CDTF>
      
</dcterms:temporal>
      
<dcterms:spatial rdf:parseType="Resource">
        
<dcterms:ISO3166>BS</dcterms:ISO3166>
      
</dcterms: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).


5.7  The EntryStatus class

The EntryStatus class provides information about the citation, as opposed to the cited reference. It has three attributes. The last_modified_date attribute defines the date on which the citation was last changed. The subset attribute defines the subset of the bibliographic repository from which the current citation was taken. The properties attribute is a member of the Property class and takes the form property name: property value. The properties attribute can be used to supply general properties about the citation. For instance, it could be used to provide a version number for the citation. The Property class is discussed in Section 5.9.

This metadata is about the citation, not the reference. Therefore, it must be contained in a new RDF resource. To remain consistent with the class name we use the element <bqs:EntryStatus>. This resource can have three types of metadata:

  • A last modified date, stored in a qualified Dublin Core <dcterms:modified> element, as shown in Figure 39
  • A subset, stored in a <bqs:subset> element, as shown in Figure 39
  • A property, stored as defined in Section 5.9

<rdf:RDF
    
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
    
xmlns:dcterms="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:EntryStatus rdf:parseType="Resource">
        
<dcterms:modified rdf:parseType="Resource">
          
<dcterms:W3CDTF>2001-04-06</dcterms:W3CDTF>
        
</dcterms:modified>
        
<bqs:subset>312-A</bqs:subset>
      
</bqs:EntryStatus>
    
</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.


5.8  The Journal class

The Journal class stores information about journals and is referenced by the JournalArticle, a subclass of the BibliographicReference class. The Journal class has three attributes: issn (the International Standard Serial Number for the journal), name (the full name of the journal), and abbreviation (an abbreviation for the journal).

There are two possible uses for this class. One is to create a list of journals, which can be referenced by citations of type "JournalArticle". The other is to indicate the journal for a particular bibliographic reference. The same serialization can be used in both cases. In the latter case, it is likely that only the name or abbreviation of the journal would be provided.

Journal information is stored in a <bqs:Journal> element. The attributes of the Journal class are serialized with the Dublin Core <dc:title> element for the name of the journal, a <bqs:issn> element for the ISSN, and a <bqs:abbreviation> element for the abbreviation.

A <dc:identifier> could be used to store the ISSN. However, this could lead to confusion with the use of the <dc:identifier> element to store a database UI (the identifier and cross_references attributes on the BibliographicReference class). Therefore, in this serialization of the BQS data model, the <dc:identifier> element is used to store the identifier of the citation, not the identifier of the cited resource. A new <bqs:issn> element is created to store the identifier of the journal resource.

The <bqs:abbreviation> element is qualified by a <bqs:abbreviation_scheme> element. This is necessary because there is not a single list of standard journal abbreviations. This element may take on any value. However, we recommend the use of the following:

  • Medline: Most biological and medical journals are indexed by Medline, 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:dcterms="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 demonstrate possible methods for referring to journals in journal article references.

5.9  The Property class

The Property class can be referenced by the BibliographicReference, Journal, Provider, BibRefScope, and EntryStatus classes to add properties to the data model. The Property class provides a general way to extend the data model. Note that the data model can also be extended by creating new RDF elements in a non-BQS namespace.

The Property class can be serialized with a qualified <bqs:Property> attribute, as follows:

  • property_name = <bqs:property_type>
  • property_value = <rdf:value>

If format information is required, a Dublin Core <dc:format> element is used, as described for the BibRefDescription class.

Figure 41 shows the serialization of the Property class.


<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 rdf:parseType="Resource">
      
<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 rdf:parseType="Resource">
      
<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.


5.10  Subclasses of the BibliographicReference Class

The BQS data model provides seven basic subclasses of the BibligraphicReference class, one of which is further subclassed. In addition, users can create their own type of BibliographicReference. To do this in the RDF serialization, the user would supply a new value for the type attribute on the BibliographicReference class, and provide any additional information either by using the Property class (discussed in Section 5.9) or by defining his/her own RDF schema for that reference type.

The Thesis, Proceeding, and TechReport subclasses do not define any additional attributes. The other subclasses are discussed in the following subsections.

5.10.1  The Book subclass

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

  • isbn (the International Standard Book Number) = <bqs:isbn> (A <dc:identifier> element could be used to store the ISBN. However, this could lead to confusion with the use of the <dc:identifier> element to store a database UI (the identifier and cross_references attributes on the BibliographicReference class). Therefore, in this serialization of the BQS data model, the <dc:identifier> element is used to store the identifier of the citation, not the identifier of the cited resource. A new <bqs:isbn> element is created to store the identifier of the book resource.)
  • volume = <bqs:volume> (This element is also used in the serialization of the JournalArticle subclass.)
  • edition = <bqs:edition>
  • series (the title of the series of which the book is a member) = <bqs:series>
  • editor = <bqs:editor>. Personal information about the editor (name, e-mail, etc.) is provided by the serialization of the Provider class (see Section 5.3).

Figure 43 demonstrates the storage of book information. Note that a real reference to a book would also include elements from the BibliographicReference class. Section 5.11 has several complete reference examples that demonstrate the use of information from the various BQS data model classes.


<rdf:RDF
    
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
    
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 rdf:parseType="Resource">
      
<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 rdf:parseType="Resource">
              
<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 rdf:parseType="Resource">
              
<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.


5.10.2  The Article subclass and its subclasses

The Article class has two attributes: first_page and last_page. In addition, it has two further subclasses: JournalArticle, which has volume, issue, issue_supplement and from_journal attributes, and BookArticle, which has a from_book attribute.

The attributes on the Article, JournalArticle and BookArticle classes are serialized using the same elements:

  • first_page = <bqs:first_page>
  • last_page = <bqs:last_page>
  • volume = <bqs:volume> (This element is also used in the serialization of the Book subclass.)
  • issue = <bqs:issue>
  • issue_supplement = <bqs:issue_supplement>
  • from_journal = <bqs:Journal>, as described in Section 5.8
  • from_book = <bqs:Book>

Figure 44 shows the definition of journal article metadata. In this example, the journal information is included inline. Figure 45 shows the definition of journal article metadata. In this example, the journal information is included by reference to another resource (such as a journal definition as shown in Figure 40). Figure 46 shows the definiton of book chapter metadata. Note that these examples only show the metadata specific for these subclasses of BibliographicReference. Section 5.11 will provide several examples of complete citations.


<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: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:abbreviation rdf:parseType="Resource">
          
<bqs:abbreviation_scheme>Medline</bqs:abbreviation_scheme>
          
<rdf:value>J Biol Chem</rdf:value>
        
</bqs:abbreviation>
      
</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:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
    
  
<rdf:Description rdf:about="#cellml_element_id">
    
<bqs:JournalArticle rdf:parseType="Resource"> 
      
<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: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 rdf:parseType="Resource">
      
<bqs:first_page>56</bqs:first_page>
      
<bqs:last_page>62</bqs:last_page>
      
<bqs:Book rdf:parseType="Resource">
        
<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 rdf:parseType="Resource">
                
<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 rdf:parseType="Resource">
                
<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.


5.10.3  The Patent subclass

The Patent subclass has four attributes, which are serialized as follows:

  • doc_number = <bqs:doc_number> (A <dc:identifier> element could be used to store the patent number. However, this could lead to confusion with the use of the <dc:identifier> element to store a database UI (the identifier and cross_references attributes on the BibliographicReference class). Therefore, in this serialization of the BQS data model, the <dc:identifier> element is used to store the identifier of the citation, not the identifier of the cited resource. A new <bqs:doc_number> element is created to store the identifier of the patent resource.)
  • doc_office = <bqs:doc_office>
  • doc_type = <bqs:doc_type>
  • applicant = <bqs:applicant> (Creating a <bqs:applicant> element was chosen over using the <dc:creator> element to avoid potential confusion concerning who the <dc:creator> element might refer to- inventor(s) or applicant.)

Figure 47 demonstrates the storage of patent information.


<rdf:RDF
    
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
    
xmlns:dc="http://purl.org/dc/elements/1.1/"
    
xmlns:dcterms="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:Patent rdf:parseType="Resource">
      
<bqs:doc_number>4378224</bqs:doc_number>
      
<bqs:doc_office>U.S. Patent and Trademark Office</bqs:doc_office>
      
<bqs:doc_type>Patent</bqs:doc_type>
      
<bqs:applicant>
        
<rdf:Seq>
          
<rdf:li rdf:parseType="Resource">
            
<bqs:Person rdf:parseType="Resource">
              
<vCard:N rdf:parseType="Resource">
                
<vCard:Family>Nimni</vCard:Family>
                
<vCard:Given>Marcel</vCard:Given>
                
<vCard:Other>E.</vCard:Other>
              
</vCard:N>
            
</bqs:Person>
          
</rdf:li>
          
<rdf:li rdf:parseType="Resource">
            
<bqs:Person rdf:parseType="Resource">
              
<vCard:N rdf:parseType="Resource">
                
<vCard:Family>Cheung</vCard:Family>
                
<vCard:Given>David</vCard:Given>
                
<vCard:Other>T.</vCard:Other>
              
</vCard:N>
            
</bqs:Person>
          
</rdf:li>
        
</rdf:Seq>
      
</bqs:applicant>
    
</bqs:Patent>
  
</rdf:Description>
</rdf:RDF>

Figure 47 Serialization of book article information.


5.10.4  The WebResource subclass

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

  • url = an rdf:resource attribute with the value of the url (A <dc:identifier> element could be used to store this information. However, this could lead to confusion with the use of the <dc:identifier> element to store a database UI (the identifier and cross_references attributes on the BibliographicReference class). Therefore, in this serialization of the BQS data model, the <dc:identifier> element is used to store the identifier of the citation, not the identifier of the cited resource. A new <bqs:url> element is created to store the identifier of the web resource.)
  • estimated_size = <bqs:estimated_size>. The units are assumed to be in kilobytes unless otherwise indicated with the use of a <bqs:Property> element (see Section 5.9 for more information on this element).
  • cost = <bqs:cost>. The units of the cost can be stored in <bqs:Property> element (see Section 5.9 for more information on this element).

Figure 48 shows the definition of information about a web resource.


<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 rdf:parseType="Resource">
      
<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 48 Serialization of web resource information.


5.11  Complete Examples

This section provides several complete citation examples.

5.11.1  Journal article with inline journal definition

Figure 49 demonstrates the definition of a reference to a journal article with the journal information included inline. The cited reference is:

Jafri, M.S., Rice, J.J., Winslow, R.L. "Cardiac Ca2+ dynamics: the role of ryanodine receptor adaptation and sarcoplasmic reticulum load" (1998) Biophys J 74: 1149-1168.


<rdf:RDF
    
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
    
xmlns:dc="http://purl.org/dc/elements/1.1/"
    
xmlns:dcterms="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 rdf:parseType="Resource">
      
<dc:creator>
        
<rdf:Seq>
          
<rdf:li rdf:parseType="Resource">
            
<bqs:Person rdf:parseType="Resource">
              
<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 rdf:parseType="Resource">
              
<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 rdf:parseType="Resource">
            
<bqs:Person rdf:parseType="Resource">
              
<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>
      
<dcterms:issued rdf:parseType="Resource">
        
<dcterms:W3CDTF>1998</dcterms:W3CDTF>
      
</dcterms:issued>
      
<bqs:Journal rdf:parseType="Resource">
        
<dc:title>Biophysical Journal</dc:title>
        
<bqs:abbreviation rdf:parseType="Resource">
          
<bqs:abbreviation_scheme>Medline</bqs:abbreviation_scheme>
          
<rdf:value>J Biol Chem</rdf:value>
        
</bqs:abbreviation>
      
</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 49 A complete journal article reference. Information about the journal itself is embedded within the reference.


5.11.2  Journal article with a reference to a journal definition

Figure 50 demonstrates the definition of a reference to a journal article with the journal information included by reference to a resource defined elsewhere. Figure 51 demonstrates the definition of the journal information. The cited reference is the same as that in Section 5.11.1.


<rdf:RDF
    
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
    
xmlns:dc="http://purl.org/dc/elements/1.1/"
    
xmlns:dcterms="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 rdf:parseType="Resource">
      
<dc:creator>
        
<rdf:Seq>
          
<rdf:li rdf:parseType="Resource">
            
<bqs:Person rdf:parseType="Resource">
              
<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 rdf:parseType="Resource">
              
<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 rdf:parseType="Resource">
            
<bqs:Person rdf:parseType="Resource">
              
<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>
      
<dcterms:issued rdf:parseType="Resource">
        
<dcterms:W3CDTF>1998</dcterms:W3CDTF>
      
</dcterms: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 50 A complete journal article reference that refers to a different resource for information about the journal. The definition of the journal information is shown in Figure 51.



<!-- 
  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:dcterms="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:abbreviation rdf:parseType="Resource">
        
<bqs:abbreviation_scheme>Medline</bqs:abbreviation_scheme>
        
<rdf:value>Biophys J</rdf:value>
      
</bqs:abbreviation>
      
<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:abbreviation rdf:parseType="Resource">
        
<bqs:abbreviation_scheme>Medline</bqs:abbreviation_scheme>
        
<rdf:value>J Biol Chem</rdf:value>
      
</bqs:abbreviation>
      
<bqs:issn>0021-9258</bqs:issn>
    
</bqs:Journal>
  
</rdf:Description>
  
</rdf:RDF>

Figure 51 Information about two journals. This information could be referenced by bibliographic citations defined in the <bqs:reference> element.


5.11.3  Citation by unique identifier

Figure 52 demonstrates the citation of a reference using a database unique identifer. In this example, a Medline unique identifier is used. An abstract is also included, by reference to a URL.


<rdf:RDF
    
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
    
xmlns:dc="http://purl.org/dc/elements/1.1/"
    
xmlns:dcterms="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>
      
<dcterms:abstract rdf:parseType="Resource">
        
<dcterms:IMT>text/url</dcterms: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>
      
</dcterms:abstract>
    
</bqs:reference> 
  
</rdf:Description>
</rdf:RDF>

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


5.11.4  Complete book

Figure 53 shows a relatively simple complete book reference. The cited reference is:

Branden, C., Tooze, J. "Introduction to Protein Structure" (1991) Garland Publishing, Inc., New York.


<rdf:RDF
    
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
    
xmlns:dc="http://purl.org/dc/elements/1.1/"
    
xmlns:dcterms="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 rdf:parseType="Resource">
      
<dc:creator>
        
<rdf:Seq>
          
<rdf:li rdf:parseType="Resource">
            
<bqs:Person rdf:parseType="Resource">
              
<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 rdf:parseType="Resource">
              
<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>
      
<dcterms:issued rdf:parseType="Resource">
        
<dcterms:W3CDTF>1991</dcterms:W3CDTF>
      
</dcterms: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 53 A complete book reference. Note the use of the Property class to provide the location of the publisher.


Figure 54 shows a more complicated reference to a book. The cited reference is:

Brody, J.S., Center, D.M., Tkachuk, V.A., Eds. "Signal Transduction in Lung Cells" (1993) Lung Biology in Health and Disease, 65. Marcel Dekker, Inc. New York.


<rdf:RDF
    
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
    
xmlns:dc="http://purl.org/dc/elements/1.1/"
    
xmlns:dcterms="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>
      
<dcterms:issued>
        
<dcterms:W3CDTF>1993</dcterms:W3CDTF>
      
</dcterms: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 54 A more complicated complete book reference.


5.11.5  Book chapter

Figure 55 shows a complete book chapter reference. The cited reference is:

Rogers, M.S., Strehler, E.E. "Calmodulin-like proteins" in Guidebook to the Calcium-Binding Proteins, Celio, M.R., Pauls, T., Schwaller, B., eds. (1996) Oxford University Press, Oxford. pp. 41-43.


<rdf:RDF
    
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
    
xmlns:dc="http://purl.org/dc/elements/1.1/"
    
xmlns:dcterms="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>
      
<dcterms:issued>
        
<dcterms:W3CDTF>1996</dcterms:W3CDTF>
      
</dcterms: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 55 A book chapter reference. (Some whitespace has been removed in order to fit the example on a single page.)


6  Appendix

6.1  Cmeta Terms RDF Schema Draft



<?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 dctermsns 'http://purl.org/dc/terms/'>
  <!ENTITY cmetans 'http://www.cellml.org/metadata/1.0#'>
]>

<rdf:RDF
    
xmlns:cmeta="&cmetans;"
    
xmlns:dc="&dcns;"
    
xmlns:dcterms="&dctermsns;"
    
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>
    
<dcterms:created>
      
<dcterms:W3CDTF>2001-11-02</dcterms:W3CDTF>
    
</dcterms:created>
    
<dcterms:RFC1766>en-uk</dcterms:RFC1766>
    
<dc:description>
      The CellML Metadata Element Set Vocabulary is intended to enable searches
      of a CellML model repository of biological models as well as give context
      to the models.
    
</dc:description>
  
</rdf:Description>
  
  
<!--Modification History: 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>
  
  
<!--Modification History: Modifier-->
  
<rdf:Property rdf:about="&cmetans;modifier">
    
<rdfs:label>Modifier</rdfs:label>
    
<rdfs:comment>
      The person or group of people responsible for changes made to the CellML
      description of the model.
    
</rdfs:comment>
    
<rdfs:isDefinedBy rdf:resource="&cmetans;" />
  
</rdf:Property>
  
  
<!--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>
  
  
<!--Database Identifier-->
  
<rdf:Property rdf:about="&cmetans;identifier">
    
<rdfs:label>Database Identifier</rdfs:label>
    
<rdfs:comment>
      A database unique identifier for a biological entity.
    
</rdfs:comment>
    
<rdfs:subPropertyOf rdf:resource="&cmetans;bio_entity" />
    
<rdfs:isDefinedBy rdf:resource="&cmetans;" />
  
</rdf:Property>
     
  
<!--Database Identifier Scheme-->
  
<rdf:Property rdf:about="&cmetans;identifier_scheme">
    
<rdfs:label>Database Identifier Scheme</rdfs:label>
    
<rdfs:comment>
      The database identifier scheme used to refer to a biological entity.
    
</rdfs:comment>
    
<rdfs:subPropertyOf rdf:resource="&cmetans;identifier" />
    
<rdfs:isDefinedBy rdf:resource="&cmetans;" />
  
</rdf:Property>
     
  
<!--Database Identifier Type-->
  
<rdf:Property rdf:about="&cmetans;identifier_type">
    
<rdfs:label>Database Identifier Type</rdfs:label>
    
<rdfs:comment>
      The database identifier type used to refer to a biological entity.
    
</rdfs:comment>
    
<rdfs:subPropertyOf rdf:resource="&cmetans;identifier" />
    
<rdfs:isDefinedBy rdf:resource="&cmetans;" />
  
</rdf:Property>
     
  
<!--Mathematical Problem Type-->
  
<rdf:Property rdf:about="&cmetans;math_problem">
    
<rdfs:label>Mathematical Problem Type</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>

  
<!--Mathematical Problem Type: Scheme-->
  
<rdfs:Class rdf:about="&cmetans;math_problem_scheme">
    
<rdfs:label>Mathematical Problem Type Scheme</rdfs:label>
    
<rdfs:comment>
      The scheme used to classify the type of problem encoded in the math
      associated with the CellML model or model component.
    
</rdfs:comment>
    
<rdfs:subPropertyOf rdf:resource="&cmetans;math_problem" />
    
<rdfs:isDefinedBy rdf:resource="&cmetans;" />
    
<rdfs:seeAlso rdf:resource="http://gams.nist.gov" />
  
</rdfs:Class>

  
<!--Mathematical Problem Type: GAMS classification tree-->
  
<rdfs:Class rdf:about="&cmetans;GAMS">
    
<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 using the GAMS classification
      tree.
    
</rdfs:comment>
    
<rdf:type rdf:resource="&cmetans;math_problem_scheme" />
    
<rdfs:isDefinedBy rdf:resource="&cmetans;" />
    
<rdfs:seeAlso rdf:resource="http://gams.nist.gov" />
  
</rdfs:Class>

  
<!--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: Type-->
  
<rdf:Property rdf:about="&cmetans;annotation_type">
    
<rdfs:label>Annotation Type</rdfs:label>
    
<rdfs:comment>
      The type of annotation that describes the CellML model or model component.
    
</rdfs:comment>
    
<rdfs:supPropertyOf rdf:resource="&cmetans;annotation" />
    
<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: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>

6.2  BQS Terms RDF Schema Draft


<?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 dctermsns 'http://purl.org/dc/terms/'>
  <!ENTITY bqsns 'http://www.cellml.org/bqs/1.0#'>
]>

<rdf:RDF
    
xmlns:bqsns="&bqs;"
    
xmlns:dc="&dcns;"
    
xmlns:dcterms="&dctermsns;"
    
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>
    
<dcterms:created>
      
<dcterms:W3CDTF>2001-11-02</dcterms:W3CDTF>
    
</dcterms:created>
    
<dcterms:RFC1766>en-uk</dcterms:RFC1766>
    
<dc:description>
      The Bibliographic Query Service Element Set Vocabulary is intended to
      enhance searches of any document containing bibliographic references.
    
</dc:description>
  
</rdf:Description>
  
  
<!--BibliographicReference Class-->
  
<rdfs:Class rdf:about="&bqsns;reference">
    
<rdfs:label>BibliographicReference Class</rdfs:label>
    
<rdfs:comment>
      The root class for all BQS bibliographic references.
    
</rdfs:comment>
    
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
  
</rdfs:Class>
  
  
<!--Bibliographic Identifier Type-->
  
<rdf:Property rdf:about="&bqsns;identifier_type">
    
<rdfs:label>Identifier Type</rdfs:label>
    
<rdfs:comment>
      Gives the type of identifier being used to cite a reference.
    
</rdfs:comment>
    
<rdf:type rdf:resource="&dcns;identifier" />
    
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
  
</rdf:Property>  

  
<!--Bibliographic Identifier Scheme-->
  
<rdfs:Class 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:isDefinedBy rdf:resource="&bqsns;" />
  
</rdfs:Class>  

  
<!--Medline Indetifier Scheme-->
  
<rdfs:Class 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;" />
  
</rdfs:Class>    
  
  
<!--PubMed Indetifier Scheme-->
  
<rdfs:Class 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;" />
  
</rdfs:Class>    
  
  
<!--CAS Indetifier Scheme-->
  
<rdfs:Class 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;" />
  
</rdfs:Class>  
  
  
<!--Reference Type-->
<!--  <rdf:Property rdf:about="&amp;bqsns;reference_type">
    <rdfs:label>Reference Type</rdfs:label>
    <rdfs:comment>
      Identifies the genre of a cited reference.
    </rdfs:comment>
    <rdfs:isDefinedBy rdf:resource="&amp;bqsns;" />
  </rdf:Property>    
-->

  
  
<!--Reference Type:Article-->
  
<rdfs:Class rdf:about="&bqsns;Article">
    
<rdfs:label>Article</rdfs:label>
    
<rdfs:comment>
      The cited reference is an article.
    
</rdfs:comment>
    
<rdfs:subClassOf rdf:resource="&bqsns;reference" />
    
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
  
</rdfs:Class>  

  
<!--Reference Type:JournalArticle-->
  
<rdfs:Class rdf:about="&bqsns;JournalArticle">
    
<rdfs:label>JournalArticle</rdfs:label>
    
<rdfs:comment>
      The cited reference is a journal article.
    
</rdfs:comment>
    
<rdfs:subClassOf rdf:resource="&bqsns;Article" />
    
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
  
</rdfs:Class>  

  
<!--Reference Type:BookArticle-->
  
<rdfs:Class rdf:about="&bqsns;BookArticle">
    
<rdfs:label>BookArticle</rdfs:label>
    
<rdfs:comment>
      The cited reference is a book article.
    
</rdfs:comment>
    
<rdfs:subClassOf rdf:resource="&bqsns;Article" />
    
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
  
</rdfs:Class>  
  
  
<!--Reference Type:Book-->
  
<rdfs:Class rdf:about="&bqsns;Book">
    
<rdfs:label>Book</rdfs:label>
    
<rdfs:comment>
      The cited reference is a book.
    
</rdfs:comment>
    
<rdfs:subClassOf rdf:resource="&bqsns;reference" />
    
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
  
</rdfs:Class>  

  
<!--Reference Type:Patent-->
  
<rdfs:Class rdf:about="&bqsns;Patent">
    
<rdfs:label>Patent</rdfs:label>
    
<rdfs:comment>
      The cited reference is a patent.
    
</rdfs:comment>
    
<rdfs:subClassOf rdf:resource="&bqsns;reference" />
    
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
  
</rdfs:Class>      

  
<!--Reference Type:Proceeding-->
  
<rdfs:Class rdf:about="&bqsns;Proceeding">
    
<rdfs:label>Proceeding</rdfs:label>
    
<rdfs:comment>
      The cited reference is a proceeding.
    
</rdfs:comment>
    
<rdfs:subClassOf rdf:resource="&bqsns;reference" />
    
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
  
</rdfs:Class>      

  
<!--Reference Type:TechReport-->
  
<rdfs:Class rdf:about="&bqsns;TechReport">
    
<rdfs:label>Technical Report</rdfs:label>
    
<rdfs:comment>
      The cited reference is a technical report.
    
</rdfs:comment>
    
<rdfs:subClassOf rdf:resource="&bqsns;reference" />
    
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
  
</rdfs:Class>      

  
<!--Reference Type:Thesis-->
  
<rdfs:Class rdf:about="&bqsns;Thesis">
    
<rdfs:label>Thesis</rdfs:label>
    
<rdfs:comment>
      The cited reference is a thesis.
    
</rdfs:comment>
    
<rdfs:subClassOf rdf:resource="&bqsns;reference" />
    
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
  
</rdfs:Class>      

  
<!--Reference Type:WebResource-->
  
<rdfs:Class rdf:about="&bqsns;WebResource">
    
<rdfs:label>WebResource</rdfs:label>
    
<rdfs:comment>
      The cited reference is a web resource.
    
</rdfs:comment>
    
<rdfs:subClassOf rdf:resource="&bqsns;reference" />
    
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
  
</rdfs:Class>      
  
  
<!--Provider-->
  
<rdfs:Class rdf:about="&bqsns;Provider">
    
<rdfs:label>Provider class</rdfs:label>
    
<rdfs:comment>
      Who the resource is provided by.
    
</rdfs:comment>
    
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
  
</rdfs:Class>

  
<!--Provider Type:Person-->
  
<rdfs:Class rdf:about="&bqsns;Person">
    
<rdfs:label>Person</rdfs:label>
    
<rdfs:comment>
      The resource is provided by a person.
    
</rdfs:comment>
    
<rdfs:subClassOf rdf:resource="&bqsns;Provider" />
    
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
  
</rdfs:Class>
  
  
<!--Provider Type:Organization-->
  
<rdfs:Class rdf:about="&bqsns;Organization">
    
<rdfs:label>Organization</rdfs:label>
    
<rdfs:comment>
      The resource is provided by an organization.
    
</rdfs:comment>
    
<rdfs:subClassOf rdf:resource="&bqsns;Provider" />
    
<rdf:seeAlso rdf:resource="&bqsns;Organisation" />
    
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
  
</rdfs:Class>
      
  
<!--Provider Type:Organisation-->
  
<rdfs:Class rdf:about="&bqsns;Organisation">
    
<rdfs:label>Organisation</rdfs:label>
    
<rdfs:comment>
      The resource is provided by an organisation.
    
</rdfs:comment>
    
<rdfs:subClassOf rdf:resource="&bqsns;Provider" />
    
<rdf:seeAlso rdf:resource="&bqsns;Organization" />
    
<rdfs:isDefinedBy rdf:resource="&bqsns;" />    
  
</rdfs:Class>
  
  
<!--Provider Type:Service-->
  
<rdfs:Class rdf:about="&bqsns;Service">
    
<rdfs:label>Service</rdfs:label>
    
<rdfs:comment>
      The resource is provided by a service.
    
</rdfs:comment>
    
<rdfs:subClassOf rdf:resource="&bqsns;Provider" />
    
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
  
</rdfs:Class>
      
  
<!--Subject Type-->
  
<rdf:Property rdf:about="&amp;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-->
  
<rdfs:Class rdf:about="&bqsns;EntryStatus">
    
<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;" />
  
</rdfs:Class>

  
<!--Subset-->
  
<rdf:Property rdf:about="&bqsns;subset">
    
<rdfs:label>Subset</rdfs:label>
    
<rdfs:comment>
      Provides reference subset information.
    
</rdfs:comment>
    
<rdfs:doman rdf:resource="&bqsns;EntryStatus" /> 
    
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
  
</rdf:Property> 
  
  
<!--Property-->
  
<rdfs:Class rdf:about="&bqsns;Property">
    
<rdfs:label>Property</rdfs:label>
    
<rdfs:comment>
      Provides a property about the reference.
    
</rdfs:comment>
    
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
  
</rdfs:Class> 
  
  
<!--Property Type-->
  
<rdf:Property rdf:about="&bqsns;property_type">
    
<rdfs:label>Property Type</rdfs:label>
    
<rdfs:comment>
      Declares the property name.
    
</rdfs:comment>
    
<rdfs:doman 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:domain rdf:resource="&bqsns;Book" />
    
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
  
</rdf:Property> 

  
<!--Book (& JournalArticle):Volume-->
  
<rdf:Property rdf:about="&bqsns;volume">
    
<rdfs:label>Volume</rdfs:label>
    
<rdfs:comment>
      Book or journal volume number.
    
</rdfs:comment>
    
<rdfs:domain rdf:resource="&bqsns;Book" />
    
<rdfs:domain rdf:resource="&bqsns;JournalArticle" />
    
<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:domain rdf:resource="&bqsns;Book" />
    
<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:domain rdf:resource="&bqsns;Book" />
    
<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:domain rdf:resource="&bqsns;Book" />
    
<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:domain rdf:resource="&bqsns;Article" />
    
<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:domain rdf:resource="&bqsns;Article" />
    
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
  
</rdf:Property>
  
  
<!--JournalArticle: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:domain rdf:resource="&bqsns;JournalArticle" />
    
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
  
</rdf:Property>
  
  
<!--JournalArticle: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:domain rdf:resource="&bqsns;JournalArticle" />
    
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
  
</rdf:Property>
  
  
<!--Journal-->
  
<rdfs:Class rdf:about="&bqsns;Journal">
    
<rdfs:label>Journal</rdfs:label>
    
<rdfs:comment>
      Journal reference.
    
</rdfs:comment>
    
<rdfs:domain rdf:resource="&bqsns;Journal" />
    
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
  
</rdfs:Class>

  
<!--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:domain rdf:resource="&bqsns;Journal" />
    
<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:domain rdf:resource="&bqsns;Journal" />
    
<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:domain rdf:resource="&bqsns;Journal" />
    
<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:domain rdf:resource="&bqsns;WebResource" />
    
<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:domain rdf:resource="&bqsns;WebResource" />
    
<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:domain rdf:resource="&bqsns;WebResource" />
    
<rdfs:isDefinedBy rdf:resource="&bqsns;" />
  
</rdf:Property>
</rdf:RDF>