| Research Summary - 18 May 2001 | |
Abstract
This document specifies CellMLTM Metadata 1.0, the recommended method for identifying types of metadata embedded in a CellML document. The CellML specification recommends the use of the Resource Description Framework for the association of metadata with CellML objects. This document demonstrates how the Dublin Core, BQS and vCard data models can be used to classify metadata. It also defines some CellML specific types of metadata.
Status of this document
On 18 May 2001, this document was cobbled together from various meeting minutes resulting from metadata-related research undertaken in the first quarter of 2001. It is not intended to be a formal specification at all, and has been made available purely as a roadmap for the CellML Metadata project.
The authors invite feedback from the public. Readers are encouraged to subscribe and send comments to the cellml-discussion mailing list. Alternatively, readers may send comments and questions via e-mail to info@cellml.org.
The latest version of the CellML Metadata specification can always be found on the CellML website.
Metadata is usually defined as "data about data". It is the supporting information that provides context to a resource. In CellML, the model (i.e., the structure and mathematics of the model) is the resource. Information that puts the model into the larger scientific context is metadata. Metadata in CellML includes information such as the literature reference that supports the model, the identity of the creator(s) of the model, and the species for which the model is relevant.
The CellML metadata project needs metadata for two primary reasons:
-
It will be difficult to reuse other people's models and components without metadata to provide the scientific context for these objects. A modeller considering reusing someone else's model component will need to know things such as: what biological entity the component represents, for which species the component is relevant, and when the component was created and last modified (to help determine whether it is likely to incorporate the most recent experimental results).
-
As the number of models and components grows, metadata will provide the only scalable method for locating particular models and components. Experience in other biological fields shows that as a field grows, powerful search techniques are needed to enable researchers to find relevant resources. These search techniques require structured metadata.
Metadata in CellML can be used in many different ways, such as:
-
To support searches of a model repository (or at least to make it possible to automate loading of a database that will support such searches).
-
To enable automatic discovery of models published on remote websites, such as laboratory websites.
-
To allow the documentation for a model to be kept in the same document as the model itself, which will keep the documentation from becoming obsolete as work continues on the model.
The metadata structure should be flexible and extensible, because it is almost certain that we have not thought of all possible uses of CellML metadata.
Metadata has become a bit of a buzzword lately. This is because people are starting to realise that we cannot get the maximum use out of the information stored on the web without metadata. It is currently 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. Tim Berners-Lee has been particularly active in pushing for a "semantic web", in which resources on the web would include the semantic information necessary to allow machines to understand (not just read) them. The W3C has set up a semantic web activity. Some software projects, such as Mozilla, have begun trying to take advantage of the metadata that is currently available about web resources.
The "semantic web" vision is one of the future, and not of today. Several projects are beginning to take tentative steps towards realising Tim Berners-Lee's dream, but success is by no means certain. The library science community is leading the way in implementing metadata. A consequence of this is that the tools being provided for handling metadata on the web (such as the Resource Description Framework, or RDF) have come from the knowledge management community. Like any academic discipline, that community has its own jargon, which can be a hindrance to the rest of us when we try to understand and use these tools. However, several projects are now using RDF, and a variety of tools have been created for it. These will be discussed in Section 1.4.
None of the problems faced by the nascent metadata community are insurmountable. It seems very likely that something resembling the "semantic web" will come into existence, if for no reason other than the importance of the problem it is attempting to address. Therefore, we should at least consider how we can make metadata in CellML compatible with the semantic web activity.
The initial step in incorporating metadata into CellML was to determine what sorts of information modellers might want to store about their models, and what sort of information software developers might find useful to be able to store. This was done as part of the requirements gathering for version 1.0 of CellML. A list of the metadata requirements for CellML is included in the requirements document.
The necessary metadata can be split into three broad categories:
-
Metadata that can be mapped easily onto the Dublin Core elements (see Section 1.5).
-
Literature citations, which we might be able to handle using an existing standard such as DocBook or the Object Mangement Group's Bibliographic Query Service.
-
Metadata that is specific to biology and/or CellML, an implementation of which we will probably need to develop ourselves.
Information about RDF can be found on the W3C's Semantic Web Activity Page.
There is no doubt about it: RDF is nowhere near as intuitive as XML is. It is pretty clear what the purpose of XML is and how to go about using XML to solve problems. Not so for RDF. However, with a little patience, I think most people can understand what RDF is and what it hopes to accomplish. With a little more work, your average XML geek can figure out how to use and create RDF vocabularies, too.
So what is RDF? Well, the easy answer is that it is the W3C's recommendation for handling metadata on the web. But that doesn't tell you much. RDF stands for "Resource Description Framework", and that really does describe what RDF is. It is a framework that allows you to store descriptions (i.e., metadata) about resources. A resource can be literally anything. For the purposes of CellML, resources can be the model document, the model itself, or components in the model.
RDF by itself does not allow people to store metadata. It merely provides a standard framework onto which various groups can hang their metadata vocabularies. Some benefits of having this standard framework are:
-
It provides a common attribute=value data model for the metadata. All metadata expressed in RDF can be presented as a series of attributes (i.e., properties of the resource) and their values. For instance, one attribute:value pair for a CellML model might be
species=Mus musculus.
-
It provides an extensible method for storing metadata of increasing complexity. Some metadata properties will have simple values, such as the species property shown above. Other metadata properties will have complex values. In the latter case, the value of the metadata property is itself considered a resource, and additional metadata properties are stored about it. This is made more clear by an example. Consider the case of the
model creator property. This could be given a simple value of the creator's name, such as John Doe. However, it is more powerful to consider the value of the creator property to be a new resource (the person identified by the name "John Doe"). This allows the person's name to be stored as metadata about the new resource. Why bother doing this? Because it also allows additional metadata to be stored about the person, such as the person's mailing address, phone number, etc. Most importantly, we don't have to know ahead of time what sorts of metadata processing software might want to store about the person. If a particular application wants to store the person's favorite color, it can do so. Other applications might not recognize the meaning of the particular element that stores the favorite color, 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 (I suspect most 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. OK, this one isn't a reality yet, but 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 definitely true that RDF is still a fledgling technology. However, there are tools out there that parse RDF, and tools that actually use RDF to build databases, knowledge stores, and other such things. See the W3C's RDF project list for a list of tools and projects using RDF.
-
RDF provides some good basic data structures. The RDF team did a good job defining groupings for metadata values, for instance. This makes it easy to allow multiple values for a metadata property, and allows you to unambiguously specify whether the multiple values should be considered an ordered list, a list of alternative values, or just an unorder group. These data structures (called containers) can be used with any RDF element, with not additional definition by the RDF vocabulary author.
The plethora of methods for expressing the same basic piece of information is probably Warren's biggest problem with RDF. (Well, maybe the verbosity is his biggest problem, which is saying something, given his penchant for verbose implementations....)
Why does RDF allow multiple methods for storing the same information? I think it has to do with the fundamental database design principle of generalize whenever possible, and overload your classes as much as possible. The reason this is good database design is that generalizing and overloading are both good techniques to create a flexible data model that will handle new types of information as they become necessary. If you exactly map each type of information to a column in a database table (or an element in an XML schema), new types of information will require new columns (or elements). If you have a generalized structure that handles an entire class of information, you are much more likely to be able to handle any type of information without changing your schema. I suspect that this line of reasoning explains why the basic RDF data model allows some types of information to be stored in more than one way.
Of course the downside is that someone new to RDF has incredible anxiety attacks trying to figure out which way is the "right way", when in fact, all that matters is that he/she pick a method and implement it consistently.
Information about the Dublin Core can be found on the Dublin Core's website.
The Dublin Core is a group of metadata properties. These properties were identified as "common" across a large range of resources by a group of library science and knowledge management folks. These properties are things like creator, publisher, subject, and date. A full list, with definitions, can be found in the Dublin Core Metadata Element Set, Version 1.1: Reference Description.
The Dublin Core Metadata Initiative group has also provided a standard set of "qualifier" elements. These elements add information to the basic elements. Qualifier elements either provide type information or scheme information. Type information classifies the basic element. For instance, the date element can have a type of created, modified, valid, available, or issued. Scheme information indicates how the content of the element is encoded. For instance, the date element can have a scheme of W3C-DTF or DCMI Period. A full list of qualifiers and their allowed values can be found in the Dublin Core Qualifiers document.
It is important to note that Dublin Core does not have to be expressed in RDF. The Dublin Core elements are not elements in the XML sense. They are simply standard names and definitions for common types of metadata. However, the Dublin Core can be expressed in RDF, which is how I recommend the CellML project take advantage of this work.
Not all of the Dublin Core elements are immediately applicable to CellML metadata requirements. So why should we bother with the Dublin Core? Because this set of elements is widely referenced. General purpose tools are more likely to understand the Dublin Core metadata vocabulary than any other vocabulary. Also, it makes it more obvious that certain CellML metadata properties (such as model creator) map directly to metadata properties that are found in other fields. While this may not be of great value to us right now, later on we will probably be glad we took the effort to make our metadata more generally understandable.
The basic CellML metadata properties were defined in section 16 of the CellML requirements document.
In the interests of writing the serialization section, and because the data model for CellML metadata hasn't really changed since October of 1999, this section will be done last. Which probably means I won't have time to do it at all!
This section assumes that the reader is reasonably familiar with basic RDF constructs such as containers and the rdf:resource and rdf:parseType attributes. It also assumes a certain familiarity with the Dublin Core element set and qualifiers set.
Both the <rdf:Description> element and the rdf:parseType attribute (with a value of "Resource") can be used to create a new resource. When should each be used? Well, this is largely up to the discretion of the vocabulary author. I have used the rdf:parseType attribute wherever possible, because it is less verbose. However, the <rdf:Description> element must be used if you want to give the new resource an identifier, which would allow the resource to be referenced by other RDF constructs.
The <rdf:value> element is often used when a new resource is created inline, and some metadata is stored about it. The <rdf:value> element stores the actual value of the metadata, and additional elements can be used to store qualifying information. If a processing application does not recognize the qualifying elements, it can take the contents of the <rdf:value> element and transfer them to the containing element. For instance, in the example shown in Figure 1, an application that only understands the Dublin Core, but not the Dublin Core qualifiers, could reasonably be expected to assign the date metadata a value of 2001-04-24. An application that understands the Dublin Core qualifiers would also know that this is a creation date, encoded using the W3C-DTF format.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:dcq="http://purl.org/dc/qualifiers/1.0/">
<rdf:Description about="#cellml_element_id">
<dc:date rdf:parseType="Resource">
<dcq:dateType>created</dcq:dateType>
<dcq:dateScheme>W3C-DTF</dcq:dateScheme>
<rdf:value>2001-04-24</rdf:value>
</dc:date>
</rdf:Description>
</rdf:RDF>
Figure 1 Date metadata that uses the <rdf:value> element.
The Dublin Core qualifier scheme is such a good one that I copied it extensively in other areas of the CellML metadata. Any time I wanted to provide a classification for a piece of metadata, I used a type qualifier. Any time I wanted to provide information about how the metadata information is encoded, I used a scheme qualifier. These elements are named by taking the name of the containing element and appending "_type" or "_scheme".
It is often desirable to control the value of a metadata property. This is particularly true for qualifiers. For instance, knowing that the date is encoded using "W3C-DTF" doesn't do you much good if you don't know what "W3C-DTF" means. There are several ways to control the value of a metadata property in RDF. I've listed them below, with an explanation for when I think each method should be used:
-
Use the rdf:resource attribute. The rdf:resource attribute can be defined on an RDF element to indicate that the value of the element is a resource, which is identified by the value of the rdf:resource attribute. I recommend using this method to control the value of a metadata property when the value subtypes the containing resource, and the subtyping adds properties to the metadata content of the containing resource.
"What did she just say?" I hear you cry. Let me try to explain. The containing resource is the RDF element that creates a resource to represent the thing about which we are trying to define metadata. The best example of this from the CellML metadata is the definition of a literature citation for a CellML model. The citation is represented by the <bqs:reference> element. This creates a resource to represent the journal article, or whatever it is we are trying to reference, and contains a lot of metadata about the article. One of the pieces of metadata is the <bqs:reference_type> element. This element identifies the subtype of reference: is it a journal article, book article, web resource, or what? Additional metadata properties are required for a reference based upon which subtype is identified. If it is a journal article, we need to identify the journal, the volume, and the first and last pages. If it is a book, we need to identify the publisher, edition, volume, etc. The data structure for each of these subtypes is represented in the RDF schema. That is, there is a resource (in the RDF schema) that defines the additional metadata content added to the reference resource by the subtyping. I think the best way to serialize this is to make the URI that identifies the resource (in the RDF schema) that defines the new metadata properties on the containing resource.
-
Define a controlled vocabulary and enforce it in the RDF schema. This method can be used whenever you think you know ahead of time all of the allowed values for the metadata. The Dublin Core qualifiers are good examples of this method. The Dublin Core folks have defined certain qualifiers for their elements, and defined certain allowed values for these qualifiers. An RDF schema implementing the Dublin Core could limit the values of the qualifier elements to the values defined in the DC qualifiers document. The value of the qualifier element adds information to the metadata about the containing resource, but does not add content to the metadata allowed on the containing resource.
-
Define a standard method for storing the information, and recommend some values. If you think it is likely that you don't know all the values that an element may receive, but would still like to recommend some limitations, you can define the meaning of certain values for the element in the textual documentation on your scheme, and/or in any technical specification you provide for your RDF vocabulary. A good example of this is the
<cmeta:species> element. The CellML metadata specification will recommend that the value of this element be a scientific name for a species, but the accompanying RDF schema will not enforce this.
An rdf:resource attribute is used to indicate that the value of the metadata property represented by the element is a resource, which is identified by the value of the rdf:resource attribute. I use this attribute in two ways:
-
As a way to control the value of a qualifier element that is subtyping another element, as described in Section 1.7.4.
-
When the value of an element is a resource that is defined elsewhere. For instance, in the BQS serialization, information can be defined about a journal, and then referenced via an
rdf:resource attribute in a journal article citation.
Technically, the first case is just a special instance of the second case. The resource identified by the value of the rdf:resource attribute is in the RDF schema, but it is still a resource.
RDF provides three types of containers for multivalued metadata: bags, sequences, and alternatives. The RDF specification defines the meaning of each of these. A bag is used if a metadata element has unordered, multivalued content. An example is the students in a class. A sequence is used if a metadata element has ordered, multivalued content. An example is the authors on a scientific paper. An alternative is used if a metadata element has single-valued content that is chosen from a list of alternatives. An example is the title of a document provided in multiple languages.
Warren is concerned that not every type of RDF container may be relevant for each metadata element in the CellML metadata specification, and wonders if we need to restrict the use of containers. This should not be necessary. The RDF specification already defines the meaning of each type of container. The recommendations in the CellML metadata specification will demonstrate how to use containers to represent the types of metadata that CellML metadata compliant software must recognize. If software chooses to become CellML metadata compliant by implementing only the types of metadata defined in the CellML metadata specification, it need only recognize the containers shown in the recommended definitions in the specification. If software choses to become CellML metadata compliant by becoming fully RDF capable, the RDF specification will define the meaning of the different containers for us.
There are several possible methods for dealing with controlled vocabularies of terms in RDF metadata:
-
List the terms and their meanings in the CellML metadata specification, and leave it to processing software to restrict the allowed values of the relevant metadata elements.
-
Use the
<rdfs:range> property in the RDF schema to limit the allowed values for an element to a specified set. (The terms and their meanings will also be listed in the CellML metadata specification).
-
Use the
rdf:resource attribute on the metadata element to point to a namespace URL.
The first two options produce the same RDF in the CellML document, an example of which is shown in Figure 2. This is because the control of the vocabulary is handled in a separate document (the CellML metadata specification for option 1 and the CellML RDF Schema for option 2). The second option is preferable to the first because it produces machine-understandable limits on the allowed values of the element. Since these allowed values would also be defined in the specification, the second option does not produce any additional demands on CellML processing software: software could still ignore the RDF Schema and implement only the recommendations in the CellML metadata specification.
The third option produces the RDF shown in Figure 3. The metadata content in the two figures is identical.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:cmeta="http://www.cellml.org/metadata/1.0#">
<rdf:Description about="some_element_id">
<cmeta:math_problem rdf:parseType="Resource">
<cmeta:math_problem_scheme>GAMS</cmeta:math_problem_scheme>
<rdf:value>I1a</rdf:value>
</cmeta:math_problem>
</rdf:Description>
</rdf:RDF>
Figure 2 An example of RDF metadata produced by controlling vocabularies of terms in the specification and the RDF schema.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:cmeta="http://www.cellml.org/metadata/1.0#">
<rdf:Description about="some_element_id">
<cmeta:math_problem rdf:parseType="Resource">
<cmeta:math_problem_scheme
rdf:resource="http://www.cellml.org/metadata/terms#GAMS/" />
<rdf:value>I1a</rdf:value>
</cmeta:math_problem>
</rdf:Description>
</rdf:RDF>
Figure 3 An example of RDF metadata produced by controlling vocabularies of terms using the rdf:resource attribute.
One important difference between the options presented in the two figures is the method by which modellers can use their own terms as values for the RDF element. If the terms in the vocabulary are controlled by the RDF schema and the CellML metadata specification (Figure 2), modellers would need to place the metadata element in their own namespace in order to use a term not in the CellML controlled vocabulary, as shown in Figure 4. If the terms in the vocabulary are controlled using the rdf:resource attribute, modellers would need to supply their own URL as a value for this attribute, as shown in Figure 5.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:cmeta="http://www.cellml.org/metadata/1.0#"
xmlns:app="http://www.bozo.com/my_app/">
<rdf:Description about="some_element_id">
<cmeta:math_problem rdf:parseType="Resource">
<app:problem_scheme>my classification scheme</app:problem_scheme>
<rdf:value>system of ODEs</rdf:value>
</cmeta:math_problem>
</rdf:Description>
</rdf:RDF>
Figure 4 An example of using a term not in the CellML controlled vocabulary if the controlling vocabularies of terms are defined in the specification and the RDF schema.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:cmeta="http://www.cellml.org/metadata/1.0#">
<rdf:Description about="some_element_id">
<cmeta:math_problem rdf:parseType="Resource">
<cmeta:math_problem_scheme
rdf:resource="http://www.bozo.com/my_app/terms#sillymath/" />
<rdf:value>ODE</rdf:value>
</cmeta:math_problem>
</rdf:Description>
</rdf:RDF>
Figure 5 An example of using a term not in the CellML controlled vocabulary if the controlling vocabularies of terms are defined using the rdf:resource attribute.
Recommendation: Control vocabularies in the RDF schema, and include an explanation of all terms in the CellML metadata specification (this results in RDF as shown in Figure 2 and Figure 4). This method is marginally preferable to the method shown in Figure 3 and Figure 5, because that method mixes RDF abbreviated syntax with the full syntax. Mixing the two syntaxes is legal in RDF, but using such a mixed syntax would increase the demands on CellML processing software.
The following subsections demonstrate the application of the recommendations in the previous three sections to all non-reference and non-person metadata. Note that the names of the mathematical problem type metadata elements have changed slightly, to remove a potential source of confusion. This is discussed in Section 2.11.
The discussion presented here assumes that the reader is familiar with the use of Dublin Core elements and Dublin Core qualifiers. These are discussed in the 26 March 2001 meeting minutes.
Alternative name metadata provides human-readable names for CellML elements. One of these names can be considered to be the preferred name, equivalent to the old "displayname" concept in CellML99. This preferred name could be used by software whenever it needs to display a human-readable name. The use of this metadata allows us to limit the values of name attributes on CellML elements to enable efficient code generation, without worrying about whether or not the name will be sufficiently meaningful to human readers.
Alternative name metadata is defined with the Dublin Core title element, <dc:title>.
One element may have multiple alternative names. Only one should be considered the preferred human-readable name. The preferred name should be stored in an unquailifed <dc:title> element. Additional names should be stored in <dc:title> elements that are qualified by setting the title type (<dcq:title>) to "alternative".
Figure 6 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:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:dcq="http://purl.org/dc/qualifiers/1.0/">
<rdf:Description about="#cellml_element_id">
<dc:title>EGF-EGFR complex</dc:title>
<dc:title rdf:parseType="Resource">
<dcq:titleType>alternative</dcq:titleType>
<rdf:value>
epidermal growth factor-epidermal growth factor receptor complex
</rdf:value>
</dc:title>
</rdf:Description>
</rdf:RDF>
Figure 6 Recommended definition of alternative name metadata.
Model builder metadata stores information about the person or persons who coded the model into CellML. A given element can have multiple model builders, which may need to be considerd as individuals or as members of a group. If they are members of a group, the group may or may not need to be ordered.
Model builder metadata is defined using the Dublin Core creator element, <dc:creator>. Repeating this element for a given CellML element indicates that the people listed worked independently on the model. This definition is shown in Figure 7. 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 8. 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). This definition is shown in Figure 9. The CellML metadata specification will not include the use of an <rdf:Alt> container with this type of metadata. Metadata authors are free to use this 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 all of the examples shown here, the basic vCard "name" construct is used to store the name of the model builder. This and other vCard constructs will be discussed in a later document.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:vCard="http://www.w3.org/2001/vcard-rdf/3.0#">
<rdf:Description about="#cellml_element_id">
<dc:creator rdf:parseType="Resource">
<vCard:N rdf:parseType="Resource">
<vCard:Family>Flinstone</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 7 Recommended definition of model builder metadata in which multiple people worked independently on the model.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:vCard="http://www.w3.org/2001/vcard-rdf/3.0#">
<rdf:Description about="#cellml_element_id">
<dc:creator>
<rdf:Bag>
<rdf:li rdf:parseType="Resource">
<vCard:N rdf:parseType="Resource">
<vCard:Family>Flinstone</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 8 Recommended definition of model builder metadata in which multiple people worked together on the model, and all are considered equal contributors.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:vCard="http://www.w3.org/2001/vcard-rdf/3.0#">
<rdf:Description about="#cellml_element_id">
<dc:creator>
<rdf:Seq>
<rdf:li rdf:parseType="Resource">
<vCard:N rdf:parseType="Resource">
<vCard:Family>Flinstone</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:Seq>
</dc:creator>
</rdf:Description>
</rdf:RDF>
Figure 9 Recommended definition of model builder metadata in which multiple people worked together on the model, but all are not considered equal contributors. In this example, Fred Flinstone is the first author, Charlie Brown is the second author, and Scooby Doo is the third author.
Species metadata refers to the biological species (such as human, dog, pig, 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 10. 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. Constructing such a vocabulary would be a daunting task! However, the CellML metadata specification will refer to the NCBI's Taxonomy Browser as a good 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. This was chosen over the use of RDF containers because it is simpler, and there was no need to differentiate between different possible meanings of multiple values for the species metadata. 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:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:cmeta="http://www.cellml.org/metadata/1.0#">
<rdf:Description about="#cellml_element_id">
<cmeta:species>Mammalia</cmeta:species>
<cmeta:species>Xenopus laevis</cmeta:species>
</rdf:Description>
</rdf:RDF>
Figure 10 Recommended definition of species metadata. The element referenced by "#cellml_element_id" is relevant for all mammals and the African clawed frog, Xenopus laevis.
Sex metadata refers to the sex for which a CellML element is relevant. A given element may be relevant for more than one sex.
Sex metadata is defined with the CellML-specific element, <cmeta:sex>, as shown in Figure 11. The valid content of this element must be chosen from the following controlled vocabulary:
-
male
-
female
-
hermaphrodite
-
undefined (the element is explicitly specified not to have a defined relevance to any particular sex).
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:cmeta="http://www.cellml.org/metadata/1.0#">
<rdf:Description about="#cellml_element_id">
<cmeta:sex>male</cmeta:sex>
</rdf:Description>
</rdf:RDF>
Figure 11 An example of the use of sex metadata
The creation date is the date upon which the model or model part was coded into CellML. A given CellML element can have only one creation date.
Creation date metadata is defined using the fully-qualified form of the Dublin Core date element, <dc:date>. The fact that the date is a creation date is indicated by setting the date type qualifer (<dcq:dateType>) to "created". The encoding scheme for the date is named in the date scheme qualifier (<dcq:dateScheme>). The allowed values of the encoding scheme qualifier are a controlled vocabulary from the Dublin Core (see the Dublin Core Qualifiers document.) The definition of creation date metadata is demonstrated in Figure 12.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:dcq="http://purl.org/dc/qualifiers/1.0/">
<rdf:Description about="#cellml_element_id">
<dc:date rdf:parseType="Resource">
<dcq:dateScheme>W3C-DTF</dcq:dateScheme>
<dcq:dateType>created</dcq:dateType>
<rdf:value>2000-10-05</rdf:value>
</dc:date>
</rdf:Description>
</rdf:RDF>
Figure 12
Recommended definition of the creation date metadata.
The last modified date is the date upon which the content of a CellML element was last changed. A given CellML element can have only one last modified date.
The last modified date metadata is defined with the fully-qualifed Dublin Core date element. Its definition is exactly the same as that of the creation date metadata, except that the value of the date type qualifier (<dcq:dateType>) is "modified".The definition of creation date metadata is demonstrated in Figure 13.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:dcq="http://purl.org/dc/qualifiers/1.0/">
<rdf:Description about="#cellml_element_id">
<dc:date rdf:parseType="Resource">
<dcq:dateScheme>W3C-DTF</dcq:dateScheme>
<dcq:dateType>modified</dcq:dateType>
<rdf:value>2000-10-05</rdf:value>
</dc:date>
</rdf:Description>
</rdf:RDF>
Figure 13
Recommended definition of the last modified date metadata.
There are four types of annotations that will be recognized by the CellML metadata specification. Model authors are free to create additional types. However, CellML metadata compliant software will not be required to recognize any annotation types except for the following four:
-
comment: free-form comment of the person who coded the model into CellML.
-
limitation: brief description of the limitations/scope of the content of the CellML element.
-
modification: description of a change made to the content of the CellML element.
-
validation: description of the level of validation of the content of the CellML element. This may be a code. Note that validation codes are unlikely to be interoperable.
Each annotation also has creator and creation date metadata that refers to it.
Annotation metadata is defined using a CellML-specific element, <cmeta:annotation>. This element is qualified to include a type (<cmeta:annotation_type>) that indicates which type of annotation is included. The content of the <cmeta:annotation_type> element is a vocabulary controlled by the CellML RDF specification, with four valid values: comment, limitation, modification, validation. If a model author wishes to use a different value, he/she must place the <annotation_type> element in an application-specific namespace.
The author metadata associated with an annotation is defined exactly as the model builder metadata (Section 2.2), and creation date metadata associated with an annotation is defined exactly as the general creation date metadata (Section 2.5).
Figure 14 demonstrates the definition of comment and limitation annotations. Figure 15 demonstrates the definition of modification and validation annotations.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:cmeta="http://www.cellml.org/metadata/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:dcq="http://purl.org/dc/qualifiers/1.0/"
xmlns:vCard="http://www.w3.org/2001/vcard-rdf/3.0#">
<rdf:Description about="#cellml_element_id">
<cmeta:annotation rdf:parseType="Resource">
<cmeta:annotation_type>comment</cmeta:annotation_type>
<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>
<dc:date rdf:parseType="Resource">
<dcq:dateScheme>W3C-DTF</dcq:dateScheme>
<dcq:dateType>created</dcq:dateType>
<rdf:value>2001-04-01</rdf:value>
</dc:date>
</cmeta:annotation>
<cmeta:annotation rdf:parseType="Resource">
<cmeta:annotation_type>limitation</cmeta:annotation_type>
<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>
<dc:date rdf:parseType="Resource">
<dcq:dateScheme>W3C-DTF</dcq:dateScheme>
<dcq:dateType>created</dcq:dateType>
<rdf:value>2001-03-28</rdf:value>
</dc:date>
</cmeta:annotation>
</rdf:Description>
</rdf:RDF>
Figure 14 Recommended definition of comment and limitation annotation metadata.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:cmeta="http://www.cellml.org/metadata/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:dcq="http://purl.org/dc/qualifiers/1.0/"
xmlns:vCard="http://www.w3.org/2001/vcard-rdf/3.0#">
<rdf:Description about="#cellml_element_id">
<cmeta:annotation rdf:parseType="Resource">
<cmeta:annotation_type>modification</cmeta:annotation_type>
<rdf:value>changed the equation for the sodium current</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>
<dc:date rdf:parseType="Resource">
<dcq:dateScheme>W3C-DTF</dcq:dateScheme>
<dcq:dateType>created</dcq:dateType>
<rdf:value>2001-04-01</rdf:value>
</dc:date>
</cmeta:annotation>
<cmeta:annotation rdf:parseType="Resource">
<cmeta:annotation_type>validation</cmeta:annotation_type>
<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>
<dc:date rdf:parseType="Resource">
<dcq:dateScheme>W3C-DTF</dcq:dateScheme>
<dcq:dateType>created</dcq:dateType>
<rdf:value>2001-03-28</rdf:value>
</dc:date>
</cmeta:annotation>
</rdf:Description>
</rdf:RDF>
Figure 15 Recommended definition of modification and validation annotation metadata.
This area of the metadata will almost certainly be expanded in future versions of CellML. For now, it is simply a name or database unique identifier for a biological entity, such as an ion channel, signaling 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 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 the a future version of CellML. The list of alternative biological entities metadata construct is provided now for use in the future.]
Biological entity metadata is defined using a CellML-specific element, <cmeta:bio_entity>. A biological entity may be identified by name, database identifier, or both. Multiple database identifiers may be provided, but all except one must be marked "alternative". The name of the biological entity is defined exactly as alternative names for CellML elements are defined (with the <dc:title> element, which may be qualified by a <dcq:titleType> element).
Each database identifier is stored in a <cmeta:identifier> element, which must be qualified by 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)
-
URI (URI for a web resource providing info about the biological entity)
Model authors and authors of processing software are free to define additional encoding schemes, by putting the <entity_scheme> element in an application-specific namespace. However, software claiming to be "CellML metadata compliant" is not required to recognize these schemes.
RDF containers can be used to indicate that a given CellML element is relevant for more than one biological entity. An <rdf:Bag> element can be used to indicate that the CellML element is relevant for an entire group of biological entities. An <rdf:Alt> element can be used to indicate that the CellML element can be relevant for one member of a group of entities. Note that the first member listed in the <rdf:Alt> element will be considered the preferred value. The use of the <rdf:Bag> element is shown in Figure 16. The use of the <rdf:Alt> element would be identical. "CellML metadata compliant" software will be required to recognize RDF containers in biological entity metadata. The use of RDF containers is preferred to simply repeating the <cmeta:bio_entity> element because it removes all ambiguity about how the group of biological entities relates to the referenced CellML element.
Figure 16 demonstrates the definition of biological entity metadata.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:cmeta="http://www.cellml.org/metadata/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:dcq="http://purl.org/dc/qualifiers/1.0/">
<rdf:Description about="#cellml_element_id">
<cmeta:bio_entity>
<rdf:Bag>
<rdf:li rdf:parseType="Resource">
<dc:title>calmodulin</dc:title>
<dc:title rdf:parseType="Resource">
<dcq:titleType>alternative</dcq:titleType>
<rdf:value>CaM</rdf:value>
</dc:title>
<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>
</cmeta:identifier>
</rdf:li>
</rdf:Bag>
</cmeta:bio_entity>
</rdf:Description>
</rdf:RDF>
Figure 16
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 only identified by database reference.
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 17 demonstrates the definition of the copyright metadata.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.0/">
<rdf:Description about="#cellml_element_id">
<dc:rights>Physiome Sciences, 2000</dc:rights>
</rdf:Description>
</rdf:RDF>
Figure 17 Recommended definition of copyright metadata
The publisher is the person or organization responsible for providing the model, model component, or other CellML element. A given CellML element can have multiple publishers.
Publisher metadata is defined with the Dublin Core publisher element (<dc:publisher>), as shown in Figure 18. Multivalued publisher metadata is handled exactly as multivalued model builder metadata. Simple repetition of the element indicates that the people or organizations publsih the resource independently. The use of RDF bag (<rdf:Bag>) or sequence (<rdf:Seq>) containers indicates that the people or organization publish the resource as an unordered or ordered group, respectively.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.0/">
<rdf:Description about="">
<dc:publisher>
University of Auckland, Bioengineering Research Group
</dc:publisher>
</rdf:Description>
</rdf:RDF>
Figure 18 Recommended definition of publisher metadata. Note that the empty about attribute indicates that this metadata refers to the CellML document (as opposed to the model or a specific element in the model).
The mathematical problem type is a classification of the type of problem encoded in the math associated with the model or model component. It should be specified using some sort of controlled vocabulary, such as the NIST's GAMS classification tree.
Mathematical problem type is defined using a CellML-specific element, <cmeta:math_problem>. (Note that earlier documents use an element called <math_problem_type>. The name of the element has been changed to avoid confusion with the type element qualifier.) This element is qualified by an encoding scheme element (<cmeta:math_problem_scheme>), which provides the name of the controlled vocabulary used for the classification. The allowed values of this element are themselves a vocabulary controlled by the CellML RDF schema. Currently, the only allowed value is "GAMS", which indicates that the math problem classification is taken from the NIST's GAMS classification tree. Modellers are free to use a different controlled vocabulary for the math problem classifications by placing the <math_problem_scheme> element in an application-specific namespace. However, CellML metadata compliant software is not requried to recognize any classification scheme other than the GAMS tree.
Figure 19 shows the recommended definition of mathematical problem type metadata.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:cmeta="http://www.cellml.org/metadata/1.0#">
<rdf:Description about="#cellml_element_id">
<cmeta:math_problem rdf:parseType="Resource">
<cmeta:math_problem_scheme>GAMS</cmeta:math_problem_scheme>
<rdf:value>I1a</rdf:value>
</cmeta:math_problem>
</rdf:Description>
</rdf:RDF>
Figure 19 Recommended definition of the mathematical problem type metadata. The meaning of the value "GAMS" for the encoding scheme will be controlled by the CellML metadata specification.
Contributor metadata indicates that a person contributed to a resource, but did not actually create it (an example of this is an editor).
Contributor metadata is defined using the Dublin Core contributor element, <dc:contributor>, as shown in Figure 20. Multivalued contributor metadata is handled exactly as multivalued model builder metadata. Simple repetition of the element indicates that the people contributed to the resource independently. The use of RDF bag (<rdf:Bag>) or sequence (<rdf:Seq>) containers indicates that the people contributed to the resource as an unordered or ordered group, respectively.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:vCard="http://www.w3.org/2001/vcard-rdf/3.0#">
<rdf:Description 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 20 Recommended definition of contributor metadata.
Description metadata is a short description of the referenced resource.
Description metadata is defined with the Dublin Core description element, <dc:description>. This element is qualified by a type element (<dcq:descriptionType>), which may have a value of "abstract" or "table of contents". The "abstract" type will probably be most common in CellML metadata.
Figure 21 shows how to define description metadata.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:dcq="http://purl.org/dc/qualifiers/1.0/">
<rdf:Description about="#cellml_element_id">
<dc:description rdf:parseType="Resource">
<dcq:descriptionType>abstract</dcq:descriptionType>
<rdf:value>
This element uses simple mass-action kinetics to describe the
A + B <-> C + D reaction.
</rdf:value>
</dc:description>
</rdf:Description>
</rdf:RDF>
Figure 21 Recommended definition of the Dublin Core description metadata.
Warren and Melanie were confident that someone must have solved this problem before. After all, the need to store information about people is common to most projects. Perhaps it is so common that everyone just defines their own method, because 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 leaves us with two choices: use the "vCard in RDF" option, or define our own metadata elements for people.
The vCard data model includes all of the information that the original CellML requirements indicated we need. This is:
-
Name, split into last name, first name, and middle name/initial
-
Contact info, which may include mailing address(es), e-mail address(es), and phone number(s)
-
Affiliation
It is an attractive option to use an existing data model when (1) the model is complete, meaning that it includes all of the information we need or (2) we will use all or almost all of the elements in the model, even if we need to add some additional elements. Furthermore, the existence of an RDF implementation of a data model makes it more attractive for use in CellML. The vCard data model meets the first option, and also has an existing RDF implementation. Therefore, we should use it.
However, the vCard data model includes some elements that are not necessary for CellML metadata, such as nickname and birthday. We will therefore 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.
The CellML metadata specification should recommend the use of the following "vCard in RDF" elements to meet the information needs in the requirements:
-
<vCard:N> (the name construct), with all of its subelements:
-
<vCard:Family>: the person's family, or last name
-
<vCard:Given>: the person's given, or first name
-
<vCard:Other>: additional names, used for middle names and initials
-
<vCard:Prefix>: honorific prefixes, such as "Dr."
-
<vCard:Suffix>: suffixes such as "III" and "Jr."
-
<vCard:ADR> (the mailing address construct), with all of its subelements:
-
<vCard:Pobox>: post office box
-
<vCard:Street>: street address
-
<vCard:Locality>: city, town, rural route, etc.
-
<vCard:Region>: state, etc.
-
<vCard:Country>: country
-
<vCard:Pcode>: postal code (such as the American zip code)
-
<vCard:Extadd>: extended address field. This is used to include the company or institution name.
-
<vCard:EMAIL> (the e-mail address construct)
-
<vCard:TEL> (the telephone number construct)
-
<vCard:ORG> (the organization construct, which maps to the CellML requirement to be able to store a person's affiliation), with all of its subelements:
-
<vCard:Orgname>: the name of the organization (i.e., "The University of Auckland")
-
<vCard:Orgunit>: the division or department (i.e., "The Bioengineering Research Group")
-
<vCard:TITLE>: the person's job title (not required in original requirements list, but deemed useful enough to include in the metadata specification).
-
<vCard:ROLE>: the person's job role (not required in original requirements list, but deemed useful enough to include in the metadata specification).
The <rdf:type> element is used to specify "type parameters" on certain vCard elements. For instance, an address may be typed as domestic, international, postal, parcel, home, work, or preferred. Note that one address may be given more than one type. See section 3.3 of the vCard in RDF document for more info.
In addition, lists of alternative values for some vCard elements are implemented using the <rdf:Alt> container. Ordered groups of values are implemented using the <rdf:Seq> container, and unordered groups of values are implemented using the <rdf:Bag> container. See section 3.2 of the vCard in RDF document for more info. The CellML metadata specification will only require processing software to recognize the following group values:
-
<rdf:Seq> and <rdf:Bag> containers for job title and job role metadata.
-
<rdf:Alt> and <rdf:Bag> containers for organization metadata.
-
<rdf:Seq> for organization units, to support the implied ordering (see special case 2 in section 3.4 of the vCard in RDF document.)
The metadata specification will specifically NOT require the use of the <rdf:Alt> container for multivalued contact info. Modellers will instead be recommended to use the <rdf:type> element with repeated instances of the basic vCard contact info elements. (See section 3.3 of the vCard in RDF document.)
Figure 22 shows the use of vCard to supply basic information about a model builder.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:vCard="http://www.w3.org/2001/vcard-rdf/3.0#">
<rdf:Description about="#cellml_element_id">
<dc:creator rdf:parseType="Resource">
<vCard:N rdf:parseType="Resource">
<vCard:Family>Powerpuff</vCard:Family>
<vCard:Given>Bubbles</vCard:Given>
</vCard:N>
<vCard:EMAIL>
<rdf:value>bubbles@townville.net</rdf:value>
<rdf:type rdf:resource="http://imc.org/vCard/3.0#internet" />
</vCard:EMAIL>
<vCard:TITLE>PowerPuff Girl</vCard:TITLE>
<vCard:ROLE>fighting crime before bedtime</vCard:ROLE>
</dc:creator>
</rdf:Description>
</rdf:RDF>
Figure 22 Use of vCard elements to define metadata about a model builder.
Figure 23 shows the use of vCard to supply more detailed information about a model builder. This example attempts to show many of the complicated uses of vCard. It is unlikely that real world examples will be this pathological.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:vCard="http://www.w3.org/2001/vcard-rdf/3.0#">
<rdf:Description about="#cellml_element_id">
<dc:creator rdf:parseType="Resource">
<vCard:FN rdf:parseType="Literal">Dr. Fred Flinstone</vCard:FN>
<vCard:N rdf:parseType="Resource">
<vCard:Family>Flinstone</vCard:Family>
<vCard:Given>Fred</vCard:Given>
<vCard:Prefix>Dr.</vCard:Prefix>
</vCard:N>
<vCard:EMAIL rdf:parseType="Resource">
<rdf:value>fred@bedrock.edu</rdf:value>
<rdf:type rdf:resource="http://imc.org/vCard/3.0#internet" />
<rdf:type rdf:resource="http://imc.org/vCard/3.0#pref" />
</vCard:EMAIL>
<vCard:EMAIL rdf:parseType="Resource">
<rdf:value>fred_flinstone@yahoo.com</rdf:value>
<rdf:type rdf:resource="http://imc.org/vCard/3.0#internet" />
</vCard:EMAIL>
<vCard:ORG rdf:parseType="Resource">
<vCard:Orgname>The University of Bedrock</vCard:Orgname>
<vCard:Orgunit><rdf:Seq>
<rdf:li>Department of Computer Science</rdf:li>
<rdf:li>Parallel Computing Research Group</rdf:li>
</rdf:Seq></vCard:Orgunit>
</vCard:ORG>
<vCard:TEL rdf:parseType="Resource">
<rdf:value>609-999-1111</rdf:value>
<rdf:type rdf:resource="http://imc.org/vCard/3.0#work" />
<rdf:type rdf:resource="http://imc.org/vCard/3.0#voice" />
<rdf:type rdf:resource="http://imc.org/vCard/3.0#pref" />
</vCard:TEL>
<vCard:TEL rdf:parseType="Resource">
<rdf:value>609-777-7777</rdf:value>
<rdf:type rdf:resource="http://imc.org/vCard/3.0#cell" />
<rdf:type rdf:resource="http://imc.org/vCard/3.0#voice" />
</vCard:TEL>
<vCard:ADR rdf:parseType="Resource">
<rdf:value rdf:parseType="Resource">
<vCard:Street>800 Paleolithic Drive</vCard:Street>
<vCard:Locality>Bedrock</vCard:Locality>
<vCard:Pcode>6767</vCard:Pcode>
<vCard:Country>Australia</vCard:Country>
</rdf:value>
<rdf:type rdf:resource="http://imc.org/vCard/3.0#work" />
<rdf:type rdf:resource="http://imc.org/vCard/3.0#pref" />
</vCard:ADR>
<vCard:ADR rdf:parseType="Resource">
<rdf:value rdf:parseType="Resource">
<vCard:Street>16 Yabba Dabba Doo Ave.</vCard:Street>
<vCard:Locality>Bedrock</vCard:Locality>
<vCard:Pcode>6767</vCard:Pcode>
<vCard:Country>Australia</vCard:Country>
</rdf:value>
<rdf:type rdf:resource="http://imc.org/vCard/3.0#home" />
</vCard:ADR>
</dc:creator>
</rdf:Description>
</rdf:RDF>
Figure 23 Use of vCard elements to define detailed metadata about a model builder. See text for more info.
The example demonstrates how to include multiple e-mail addresses, phone numbers, and mailing addresses for a person, and how to indicate the type of each piece of contact info. For instance, Fred Flinstone's preferred e-mail address is his work e-mail address, fred@bedrock.edu. The example also demonstrates the use of an <rdf:Seq> container to provide multiple subunits in the organization unit metadata. The metadata in this example is correctly interpreted to say that Dr. Fred Flinstone works in the Parallel Computing Research Group, which is a subunit of the Department of Computer Science at the University of Bedrock.
These meeting minutes present an RDF serialization of the DSLSRBibOBjects Module from the OMG's Bibliographic Query Service Draft Specification. This module presents an excellent general data model for bibliographic references The CellML development team was impressed with this data model (henceforth referred to as the "BQS data model"), and wanted to use it to store references in CellML metadata. However, there was no RDF serialization for the data model, so Melanie set out to create one.
These meeting minutes are not formal documentation of the proposed serialization. This documentation will be provided elsewhere. However, the ideas and examples in these minutes will conform to the formal documentation.
The BQS data model draws extensively from the Dublin Core metadata element set. Therefore, the RDF serialization of these elements is used wherever possible. Elements specific to the BQS data model are placed in a BQS namespace with the value "http://www.cellml.org/bqs/1.0#", and a recommended prefix of bqs. (The value of this namespace will probably be different when it appears in the CellML Metadata specification.)
Most of the remaining sections of these minutes go through the data structures defined in the OMG's Bibliographic Query Service Draft Specification, indicating how these structures can be defined in RDF. Section 3.11 provides some complete examples of the use of this serialization.
The CellML Metadata specification will require CellML metadata processing software to correctly interpret the structures discussed in this document, unless otherwise noted. Model authors are free to include other metadata, including the non-required structures described in this document. However, CellML metadata compliant processors are free to ignore these non-required metadata elements.
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, and must therefore be given an rdf:parseType attribute value of "Resource". All further content of this element is providing metadata about the reference resource itself.
The identifier attribute on the BibliographicReference class was one of the attributes that first sold Melanie on using the BQS data model. This attribute provides an elegant way to identify a cited reference using a database identifier (such as a Medline UI) instead of by providing the complete reference details.
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 24 shows, this data can still be serialized into RDF using the Dublin Core <dc:identifier> element. This element is qualified by an encoding scheme, which can store the "kind of identifier" information. The encoding scheme extension is analagous to the extension provided by the Dublin Core qualifiers set, but this set does not include the necessary encoding schemes (the only encoding scheme currently supported is "URI"). Therefore, the <identifier_scheme> element is placed in the BQS namespace. The <bqs:identifier_scheme> element may take on any value. However, we recommend the use of the following:
-
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.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.0/">
<rdf:Description about="#cellml_element_id">
<bqs:reference rdf:parseType="Resource">
<dc:identifier rdf:parseType="Resource">
<bqs:identifier_scheme>Medline</bqs:identifier_scheme>
<rdf:value>97219925</rdf:value>
</dc:identifier>
</bqs:reference>
</rdf:Description>
</rdf:RDF>
Figure 24 Serialization of the BibliographicReference class's identifier attribute.
The cross_references attribute on the BibliographicReference class is intended to store alternative identifers for the reference represented by the contents of the identifier attribute. This can be represented in RDF by further qualifying the <dc:identifier> element with information about the type of identifier. Identifiers that represent cross references should be given a <bqs:identifier_type> value of alternative, as shown in Figure 25.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.0/">
<rdf:Description about="#cellml_element_id">
<bqs:reference rdf:parseType="Resource">
<dc:identifier rdf:parseType="Resource">
<bqs:identifier_scheme>Medline</bqs:identifier_scheme>
<rdf:value>97219925</rdf:value>
</dc:identifier>
<dc:identifier rdf:parseType="Resource">
<bqs:identifier_scheme>PubMed</bqs:identifier_scheme>
<bqs:identifier_type>alternative</bqs:identifier_type>
<rdf:value>9067300</rdf:value>
</dc:identifier>
</bqs:reference>
</rdf:Description>
</rdf:RDF>
Figure 25 The reference information in Figure 24 is extended to include a cross reference. This cross reference provides the PubMed identifier for the same reference.
The type attribute on the BibligraphicReference class identifies the "genre" of the cited resource. The BQS data model provides constructs for the following types of references:
-
"Article" (subclassed into "JournalArticle", for journal articles, and "BookArticle", for book chapters).
-
"Book"
-
"Patent"
-
"Proceeding"
-
"TechReport" (note that this can be used for unpublished reports)
-
"Thesis"
-
"WebResource"
Note that it is possible to create additional types of references using the BQS data model. The basic information would be provided by the BibliographicReference class. Information specific to the new type of reference would need to be provided as a subclass by the person wishing to create the new reference type.
As Figure 26 shows, reference type metadata can be provided using a <bqs:reference_type> element. The reference type should be given by a URL stored in the rdf:resource attribute on the <bqs:reference_type> element. The rdf:resource attribute is used because the structure of the subclasses that represent the different types of references is defined in the RDF schema for the BQS serialization. The RDF resource that defines the structure of a particular reference type is uniquely identified by the value of the rdf:resource attribute.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.0/">
<rdf:Description about="#cellml_element_id">
<bqs:reference rdf:parseType="Resource">
<bqs:reference_type
rdf:resource="http://www.cellml.org/bqs/1.0#JournalArticle" />
</bqs:reference>
</rdf:Description>
</rdf:RDF>
Figure 26 Serialization of reference type information. See text for more info.
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 can be serialized using the Dublin Core <dc:title> element, as shown in Figure 27. Note that an xml:lang attribute could be used to indicate the language of the title.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.0/">
<rdf:Description 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 27 Serialization of reference title information.
The rights attribute on the BibligraphicReference 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 28.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.0/">
<rdf:Description about="#cellml_element_id">
<bqs:reference rdf:parseType="Resource">
<dc:rights>Physiome Sciences, 2001</dc:rights>
</bqs:reference>
</rdf:Description>
</rdf:RDF>
Figure 28 Serialization of reference rights information. See text for more info.
[Note: this particular aspect of the BQS data model will probably not be required by the CellML metadata specification.]
The language attribute on the BibliographicReference class defines the language of the cited resource. The BQS data model recommends using the RFC1766 encoding scheme for this information.
Language metadata can be stored using the qualified Dublin Core <dc:language> element, as shown in Figure 29. The CellML Metadata specification will recommend use of RFC1766 as a language scheme.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:dcq="http://purl.org/dc/qualifiers/1.0/">
<rdf:Description about="#cellml_element_id">
<bqs:reference rdf:parseType="Resource">
<dc:language rdf:parseType="Resource">
<dcq:languageScheme>RFC1766</dcq:languageScheme>
<rdf:value>en-uk</rdf:value>
</dc:language>
</bqs:reference>
</rdf:Description>
</rdf:RDF>
Figure 29 Serialization of language information. This metadata indicates the content of the cited resource is writen in United Kingdom English.
[Note: this particular aspect of the BQS data model will probably not be required by the CellML metadata specification.]
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 format metadata is serialized using the qualified Dublin Core <dc:format> element. 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. Figure 30 demonstrates the RDF serialization of the Dublin Core format element.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:dcq="http://purl.org/dc/qualifiers/1.0/">
<rdf:Description about="#cellml_element_id">
<bqs:reference rdf:parseType="Resource">
<dc:format rdf:parseType="Resource">
<dcq:formatType>Medium</dcq:formatType>
<dcq:formatScheme>IMT</dcq:formatScheme>
<rdf:value>application/pdf</rdf:value>
</dc:format>
</bqs:reference>
</rdf:Description>
</rdf:RDF>
Figure 30 Serialization of format information. This metadata indicates the content of the cited resource is in the PDF format.
[Note: this particular aspect of the BQS data model will probably not be required by the CellML metadata specification.]
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 the qualified Dublin Core <dc:date> element, as shown in Figure 31. The use of the <dcq:dateType> and <dcq:dateScheme> elements is discussed further in the 26 March 2001 and 3 April 2001 meeting minutes.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:dcq="http://purl.org/dc/qualifiers/1.0/">
<rdf:Description about="#cellml_element_id">
<bqs:reference rdf:parseType="Resource">
<dc:date rdf:parseType="Resource">
<dcq:dateType>issued</dcq:dateType>
<dcq:dateScheme>W3C-DTF</dcq:dateScheme>
<rdf:value>1997</rdf:value>
</dc:date>
</bqs:reference>
</rdf:Description>
</rdf:RDF>
Figure 31 Serialization of date information. This metadata indicates the cited resource was published in 1997 (note that the W3C-DTF encoding allows full dates, month/year dates, and year-only dates).
The authors attribute stores information about the authors of the cited reference. Its value is an instance of the Provider class. The serialization of this class is discussed in Section 3.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 32 demonstrates how to store author metadata. All of the authors are people.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:dcq="http://purl.org/dc/qualifiers/1.0/"
xmlns:vCard="http://www.w3.org/2001/vcard-rdf/3.0#">
<rdf:Description about="#cellml_element_id">
<bqs:reference rdf:parseType="Resource">
<dc:creator>
<rdf:Seq>
<rdf:li rdf:parseType="Resource">
<bqs:provider_type
rdf:resource="http://www.cellml.org/bqs/1.0#Person" />
<rdf:value 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>
</rdf:value>
</rdf:li>
<rdf:li rdf:parseType="Resource">
<bqs:provider_type
rdf:resource="http://www.cellml.org/bqs/1.0#Person" />
<rdf:value 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>
</rdf:value>
</rdf:li>
<rdf:li rdf:parseType="Resource">
<bqs:provider_type
rdf:resource="http://www.cellml.org/bqs/1.0#Person" />
<rdf:value 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>
</rdf:value>
</rdf:li>
</rdf:Seq>
</dc:creator>
</bqs:reference>
</rdf:Description>
</rdf:RDF>
Figure 32 Serialization of author information. The <rdf:Seq> container creates an ordered list of authors. Information about the authors is stored using vCard. To save space in this example, the first author is given an e-mail address, the second author an affiliation, and the third author a postal address. For an actual reference, all authors could have all three types of information. Alternatively, only the authors' names might be available.
The contributors class can be used to store information about a person or entity that contributed to, but did not create the reference. It can be serialized using the Dublin Core <dc:contributor> element, as shown in Figure 33. If there is more than one contributor, the <rdf:Seq> container can be used to create an ordered list, as was done for the authors class.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:dcq="http://purl.org/dc/qualifiers/1.0/">
<rdf:Description about="#cellml_element_id">
<bqs:reference rdf:parseType="Resource">
<dc:contributor rdf:parseType="Resource">
<bqs:provider_type
rdf:resource="http://www.cellml.org/bqs/1.0#Organization" />
<rdf:value>Super Scientific Graphics, Inc.</rdf:value>
</dc:contributor>
</bqs:reference>
</rdf:Description>
</rdf:RDF>
Figure 33 Serialization of contributor information. An organization (in this example, a company) is listed. This company may have provided graphics work for the cited reference. In this example, there is only one contributor. However, an <rdf:Seq> container could be used to create an ordered list of contributors, as was done in the author example. If the contributors were people, information about them could be stored using vCard, as shown in the authors example.
The publisher attribute stores information about the publisher of the reference. It can be serialized using the Dublin Core <dc:publisher> element, as shown in Figure 34. Only one publisher is allowed, so no RDF containers may be used in this element.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:dcq="http://purl.org/dc/qualifiers/1.0/">
<rdf:Description about="#cellml_element_id">
<bqs:reference rdf:parseType="Resource">
<dc:publisher rdf:parseType="Resource">
<bqs:provider_type
rdf:resource="http://www.cellml.org/bqs/1.0#Service" />
<rdf:value>my software service</rdf:value>
</dc:publisher>
</bqs:reference>
</rdf:Description>
</rdf:RDF>
Figure 34 Serialization of publisher information. A software service is the publisher of the reference in this example.
The Provider class is the base class for the Person, Organization and Service classes. These classes are used by the authors, contributors and publisher attributes on the BibliographicReference class. The BQS data model allows only one publisher, and requires that the authors and contributors be provided as an ordered list.
The Provider class is serialized by embedding the information directly in the RDF element that serializes the authors, contributors, publisher, or editor attribute. Multiple providers are supported using an <rdf:Seq> container. The subclass of provider is identified using a <bqs:provider_type> element to indicate which subclass of Provider is being used. The valid values are "Person", "Organisation", and "Service". The provider type should be given by a URL stored in the rdf:resource attribute on the <bqs:provider_type> element. The rdf:resource attribute is used because the structure of the subclasses that represent the different types of providers is defined in the RDF schema for the BQS serialization. The RDF resource that defines the structure of a particular provider type is uniquely identified by the value of the rdf:resource attribute. The actual identity of the provider (as defined by the relevant subclass) is enclosed in an <rdf:value> element.
In cases where all providers in a list are from the same subclass, an RDF distributive statement could be used to indicate that each member of the <rdf:Seq> container has a given type. This construct will not be discussed further in these meeting minutes, but will be considered, and a recommendation about its use will be made in the formal description of the RDF serialization of the BQS data model.
Structured information about a person can be stored using the appropriate vCard constructs, as described in a W3C note about 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.) The BQS data model only requires a subset of vCard. The vCard elements for the attributes in the BQS Person class are:
-
surname =
<vCard:Family> element, as a child of the <vCard:N> element
-
first_name =
<vCard:Given> element, as a child of the <vCard:N> element
-
middle_initials =
<vCard:Other> element, as a child of the <vCard:N> element
-
email =
<vCard:EMAIL> element
-
postal_address =
<vCard:ADR> construct, which includes subelements for post office box, street address, locality (city), region (state), country, postal code, and an extended address field (for institute or company name).
-
affiliation =
<vCard:ORG> construct, which includes subelements for the organization name and the division/department.
Figure 32 shows an example of Person provider information for the authors attribute.
The organization and service information is a name, stored as a string. This can be entered directly as the content of an RDF element. However, in some cases it is useful to provide the geographic location of the organization. For instance, this information is usually provided for the publisher of a book. This can be supported using the Property class, as discussed in Section 3.9. In this case, the name of the organization is stored in an <rdf:value> element contained in the <dc:publisher> element. Examples of the use of the Organisation and Service subclasses are shown in Figure 33 and Figure 34.
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.
All three attributes in the BibRefSubject class can be handled by the Dublin Core <dc:subject> element. This element can be qualified with a <bqs:subject_type> element to indicate the type of subject and with a <dcq:subjectScheme> element to indicate the encoding scheme for the subject.
Multiple subjects can be stored using the appropriate RDF container (bag, sequence, or alternative). Keywords, subject headings, and classification codes may not be mixed in a single <dc:subject> element. This is consistent with the data model (which has the three types of subject information as three different attributes), and also simplifies the serialization. However, a single reference resource may have multiple <dc:subject> elements.
An example demonstrating the serialization of subject metadata is shown in
Figure 35.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:dcq="http://purl.org/dc/qualifiers/1.0/">
<rdf:Description about="#cellml_element_id">
<bqs:reference rdf:parseType="Resource">
<dc:subject rdf:parseType="Resource">
<bqs:subject_type>subject_heading</bqs:subject_type>
<dcq:subjectScheme>MESH</dcq:subjectScheme>
<rdf:value>
<rdf:Bag>
<rdf:li>Signal Transduction</rdf:li>
<rdf:li>Ion Transport</rdf:li>
</rdf:Bag>
</rdf:value>
</dc:subject>
<dc:subject rdf:parseType="Resource">
<bqs:subject_type>classification_code</bqs:subject_type>
<dcq:subjectScheme>DDC</dcq:subjectScheme>
<rdf:value>572</rdf:value>
</dc:subject>
<dc:subject rdf:parseType="Resource">
<bqs:subject_type>keyword</bqs:subject_type>
<rdf:value>
<rdf:Seq>
<rdf:li>calcium signaling</rdf:li>
<rdf:li>calcium import</rdf:li>
</rdf:Seq>
</rdf:value>
</dc:subject>
</bqs:reference>
</rdf:Description>
</rdf:RDF>
Figure 35 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:subject_type> value of keyword, no <dcq:subjectScheme> element.
-
subheadings:
<bqs:subject_type> value of subject_heading, <dcq:subjectScheme> value of LCSH (Library of Congress Subject Headings) or MeSH (Medical Subject Headings).
-
codes:
<bqs:subject_type> value of classification_code, <dcq:subjectScheme> value of DDC (Dewey Decimal Classification), LCC (Library of Congress Classification), or UDC (Universal Decimal Classification).
In all cases, multiple values should be stored in the appropriate RDF container.
[Note: this particular aspect of the BQS data model will probably not be required by the CellML metadata specification.]
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 Draft Specification states that the contents of the abstract and table of contents attributes may be more than just plain text, and proposes using MIME types to identify the format of these contents.
The the_abstract and table_of_contents attributes can be serialized using a <dc:description> element. This element can be qualified with type information to indicate whether the description is an abstract or a table of contents. This is done by adding a <dcq:descriptionType> element with a value of abstract or tableOfContents. This element and these qualifiers are taken from the Dublin Core Qualifiers specification. The language attribute can be indicated by an xml:lang attribute. Note that an <rdf:Alt> container can be used to provide the description in various languages.
The abstract_type and toc_type attributes can be serialized with the Dublin Core <dc:format> element. This element is qualified with an encoding scheme element, the value of which should be IMT (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 36.
If the abstract or table of contents is supplied by a URL, the URL should be entered as the value of the <dc:description> element, and the value of the enclosed <dc:format> element should be text/url. This is shown for the abstract information in Figure 36.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:dcq="http://purl.org/dc/qualifiers/1.0/">
<rdf:Description about="#cellml_element_id">
<bqs:reference rdf:parseType="Resource">
<dc:description rdf:parseType="Resource" xml:lang="en">
<dcq:descriptionType>abstract</dcq:descriptionType>
<dc:format rdf:parseType="Resource">
<dcq:formatScheme>IMT</dcq:formatScheme>
<rdf:value>text/url</rdf:value>
</dc:format>
<rdf:value>
http://www.abstractsRus.com/abstract567843
</rdf:value>
</dc:description>
<dc:description rdf:parseType="Resource" xml:lang="en">
<dcq:descriptionType>tableOfContents</dcq:descriptionType>
<dc:format rdf:parseType="Resource">
<dcq:formatScheme>IMT</dcq:formatScheme>
<rdf:value>text/html</rdf:value>
</dc:format>
<rdf:value rdf:parseType="Literal">
<p> ... table of contents info here ...</p>
</rdf:value>
</dc:description>
</bqs:reference>
</rdf:Description>
</rdf:RDF>
Figure 36 Serialization of description information. In this example, the abstract is provided as a URL, and the table of contents is provided inline, in HTML.
[Note: this particular aspect of the BQS data model will probably not be required by the CellML metadata specification.]
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 spatial and temporal and a number of encoding schemes are defined in the Dublin Core Qualifiers specification. Two instances of this element can be used to include both spatial and temporal information.
Figure 37 shows the serialization of the scope metadata.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:dcq="http://purl.org/dc/qualifiers/1.0/">
<rdf:Description about="#cellml_element_id">
<bqs:reference rdf:parseType="Resource">
<dc:scope rdf:parseType="Resource">
<dcq:scopeType>temporal</dcq:scopeType>
<dcq:scopeScheme>W3C-DTF</dcq:scopeScheme>
<rdf:value>1997</rdf:value>
</dc:scope>
<dc:scope rdf:parseType="Resource">
<dcq:scopeType>spatial</dcq:scopeType>
<dcq:scopeScheme>ISO3166</dcq:scopeScheme>
<rdf:value>BS</rdf:value>
</dc:scope>
</bqs:reference>
</rdf:Description>
</rdf:RDF>
Figure 37 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).
[Note: this particular aspect of the BQS data model will probably not be required by the CellML metadata specification.]
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, and can be used to supply general properties about the citation. For instance, it could be used to provide a version number for the citation. The Property class will be dealt in Section 3.9.
This metadata is about the citation, and not the reference. Therefore, it must be contained in a new RDF resource. We'll call the element that will be used to create this resource <bqs:entry_status>, to remain consistent with the class name. This resource can have three types of metadata:
-
A last modified date, stored in a qualified Dublin Core
<dc:date> element, as shown in Figure 38
-
A subset, stored in a
<bqs:subset> element, as shown in Figure 38
-
A property, stored as defined in Section 3.9
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:dcq="http://purl.org/dc/qualifiers/1.0/">
<rdf:Description about="#cellml_element_id">
<bqs:reference rdf:parseType="Resource">
<bqs:entry_status rdf:parseType="Resource">
<dc:date rdf:parseType="Resource">
<dcq:dateType>modified</dcq:dateType>
<dcq:dateScheme>W3C-DTF</dcq:dateScheme>
<rdf:value>2001-04-06</rdf:value>
</dc:date>
<bqs:subset>312-A</bqs:subset>
</bqs:entry_status>
</bqs:reference>
</rdf:Description>
</rdf:RDF>
Figure 38 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.
[Note: this particular aspect of the BQS data model will probably not be required by the CellML metadata specification.]
The Journal class stores information about journals, and is referenced by the JournalArticle, a subclass of the BibliographicReference class. The Journal class has three attributes: issn (the International Standard Serial Number for the journal), name (the full name of the journal), and abbreviation (an abbreviation for the journal).
There are two possible uses for this class. One is to create a list of journals, which can be referenced by citations of type "JournalArticle". The other is to actually indicate the journal for a particular bibliographic reference. The same serialization can be used in both cases. In the latter case, it is likely that only the name or abbreviation of the journal would be provided.
Journal information is stored in a <bqs:journal> element. The attributes of the Journal class are serialized with the Dublin Core <dc:title> element for the name of the journal, a <bqs:issn> element for the ISSN, and a <bqs:abbreviation> element for the abbreviation.
A <dc:identifier> could be used to store the ISSN. However, this could lead to confusion with the use of the <dc:identifier> element to store a database UI (the identifier and cross_references attributes on the BibliographicReference class). Therefore, in this serialization of the BQS data model, the <dc:identifier> element is used to store the identifier of the citation, not the identifier of the cited resource. A new <bqs:issn> element is created to store the identifier of the journal resource.
The <bqs:abbreviation> element is qualified by a <bqs:abbreviation_scheme> element. This is necessary because there is not a single list of standard journal abbreviations. This element may take on any value. However, we recommend the use of the following:
Medline: Most biological and medical journals are indexed by Medline, which provides a downloadable list of its journals.
-
CAS: The Chemical Abstract Service abstracts chemical journals.
Use of the <bqs:abbreviation> element without a <bqs:abbreviation_scheme> element can be inferred to mean that the abbreviation is not necessarily taken from a standard list. In this case, the full name of the journal or the ISSN should also be provided.
Figure 39 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 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:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:dcq="http://purl.org/dc/qualifiers/1.0/">
<rdf:Description 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 39 Serialization of journal information. This example shows how to create a new journal resource, to which other RDF resources may refer.
Examples in Section 3.10.2 will demonstrate possible methods for referring to journals in journal article references.
The Property class can be referenced by the BibliographicReference, Journal, Provider, BibRefScope, and EntryStatus classes to add properties to the data model. The Property class provides a general way to extend the data model. Note that the data model can also be extended by creating new RDF elements in a non-BQS namespace.
The Property class can be serialized with a qualified <bqs:property> attribute, as follows:
-
property_name =
<bqs:property_type>
-
property_value =
<rdf:value>
If format information is required, a Dublin Core <dc:format> element is used, as described for the BibRefDescription class.
Figure 40 shows the serialization of the Property class.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:bqs="http://www.cellml.org/bqs/1.0#">
<rdf:Description 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 40 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 41 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:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.0/">
<rdf:Description about="#cellml_element_id">
<bqs:reference rdf:parseType="Resource">
<dc:publisher rdf:parseType="Resource">
<bqs:provider_type
rdf:resource="http://www.cellml.org/bqs/1.0#Organisation" />
<rdf:value>O'Reilly and Associates, Inc.</rdf:value>
<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 41 The use of a property to provide the location of a publisher.
The BQS data model provides seven basic subclasses of the BibligraphicReference class, one of which is further subclassed. In addition, users can create their own type of BibliographicReference. To do this in the RDF serialization, the user would supply a new value for the type attribute on the BibliographicReference class, and provide any additional information either by using the Property class (discussed in Section 3.9) or by defining his/her own RDF schema for that reference type.
The Thesis, Proceeding, and TechReport subclasses do not define any additional attributes. The other subclasses are discussed in the following subsections.
The Book subclass has five attributes, which are mapped onto BQS elements as follows:
-
isbn (the International Standard Book Number) =
<bqs:isbn> (Note that a <dc:identifier> element could be used to store the ISBN. However, this could lead to confusion with the use of the <dc:identifier> element to store a database UI (the identifier and cross_references attributes on the BibliographicReference class). Therefore, in this serialization of the BQS data model, the <dc:identifier> element is used to store the identifier of the citation, not the identifier of the cited resource. A new <bqs:isbn> element is created to store the identifier of the book resource. )
-
volume =
<bqs:volume> (note: this element is also used in the serialization of the JournalArticle subclass)
-
edition =
<bqs:edition>
-
series (the title of the series of which the book is a member) =
<bqs:series>
-
editor =
<dc:contributor>, qualified by <bqs:contributor_type> with a value of editor. Personal information about the editor (name, e-mail, etc.) is provided by the serialization of the Provider class (see Section 3.3).
Figure 42 demonstrates the storage of book information. Note that a real reference to a book would also include elements from the BibliographicReference class. Section 3.11 has several complete reference examples that demonstrate the use of information form the various BQS data model classes.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:dcq="http://purl.org/dc/qualifiers/1.0/"
xmlns:vCard="http://www.w3.org/2001/vcard-rdf/3.0#">
<rdf:Description about="#cellml_element_id">
<bqs:reference rdf:parseType="Resource">
<bqs:reference_type
rdf:resource="http://www.cellml.org/bqs/1.0#Book" />
<bqs:isbn>9-999-99999-X</bqs:isbn>
<bqs:volume>5</bqs:volume>
<bqs:edition>2nd</bqs:edition>
<dc:contributor rdf:parseType="Resource">
<bqs:contributor_type>editor</bqs:contributor_type>
<rdf:value>
<rdf:Seq>
<rdf:li rdf:parseType="Resource">
<bqs:provider_type
rdf:resource="http://www.cellml.org/bqs/1.0#Person" />
<rdf:value rdf:parseType="Resource">
<vCard:N rdf:parseType="Resource">
<vCard:Family>Doe</vCard:Family>
<vCard:Given>John</vCard:Given>
</vCard:N>
</rdf:value>
</rdf:li>
<rdf:li rdf:parseType="Resource">
<bqs:provider_type
rdf:resource="http://www.cellml.org/bqs/1.0#Person" />
<rdf:value rdf:parseType="Resource">
<vCard:N rdf:parseType="Resource">
<vCard:Family>Smith</vCard:Family>
<vCard:Given>Suzy</vCard:Given>
</vCard:N>
</rdf:value>
</rdf:li>
</rdf:Seq>
</rdf:value>
</dc:contributor>
</bqs:reference>
</rdf:Description>
</rdf:RDF>
Figure 42 Serialization of book information. This example is fictitious.
The Article class has two attributes: first_page and last_page. In addition, it has two further subclasses: JournalArticle, which has volume, issue, issue_supplement and from_journal attributes, and BookArticle, which has a from_book attribute.
The attributes on the Article, JournalArticle and BookArticle classes can be serialized using the same elements:
-
first_page =
<bqs:first_page>.
-
last_page =
<bqs:last_page>.
-
volume =
<bqs:volume> (note that this element is also used in the serialization of the Book subclass).
-
issue =
<bqs:issue>.
-
issue_supplement =
<bqs:issue_supplement>.
-
from_journal =
<bqs:journal>, as described in Section 3.8.
-
from_book =
<bqs:reference>, where that reference is of type "Book".
Figure 43 shows the definition of journal article metadata. In this example, the journal information is included inline. Figure 44 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 39). Figure 45 shows the definiton of book chapter metadata. Note that these examples only show the metadata specific for these subclasses of BibliographicReference. Section 3.11 will provide several examples of complete citations.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:dcq="http://purl.org/dc/qualifiers/1.0/"
xmlns:vCard="http://www.w3.org/2001/vcard-rdf/3.0#">
<rdf:Description about="#cellml_element_id">
<bqs:reference rdf:parseType="Resource">
<bqs:reference_type
rdf:resource="http://www.cellml.org/bqs/1.0#JournalArticle" />
<bqs:first_page>56</bqs:first_page>
<bqs:last_page>62</bqs:last_page>
<bqs:volume>356</bqs:volume>
<bqs:issue>6</bqs:issue>
<bqs:issue_supplement>A</bqs:issue_supplement>
<bqs:journal rdf:parseType="Resource">
<dc:title>Journal of Biological Chemistry</dc:title>
<bqs:abbreviation rdf:parseType="Resource">
<bqs:abbreviation_scheme>Medline</bqs:abbreviation_scheme>
<rdf:value>J Biol Chem</rdf:value>
</bqs:abbreviation>
</bqs:journal>
</bqs:reference>
</rdf:Description>
</rdf:RDF>
Figure 43 Serialization of journal article information. In this example, the journal information is provided inline.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:dcq="http://purl.org/dc/qualifiers/1.0/"
xmlns:vCard="http://www.w3.org/2001/vcard-rdf/3.0#">
<rdf:Description about="#cellml_element_id">
<bqs:reference rdf:parseType="Resource">
<bqs:reference_type
rdf:resource="http://www.cellml.org/bqs/1.0#JournalArticle" />
<bqs:first_page>56</bqs:first_page>
<bqs:last_page>62</bqs:last_page>
<bqs:volume>356</bqs:volume>
<bqs:issue>6</bqs:issue>
<bqs:issue_supplement>A</bqs:issue_supplement>
<bqs:journal rdf:resource="#journal1" />
</bqs:reference>
</rdf:Description>
</rdf:RDF>
Figure 44 Serialization of journal article information. In this example, the journal information is provided by referring to the resource created in Figure 39.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:dcq="http://purl.org/dc/qualifiers/1.0/"
xmlns:vCard="http://www.w3.org/2001/vcard-rdf/3.0#">
<rdf:Description about="#cellml_element_id">
<bqs:reference rdf:parseType="Resource">
<bqs:reference_type
rdf:resource="http://www.cellml.org/bqs/1.0#BookArticle" />
<bqs:first_page>56</bqs:first_page>
<bqs:last_page>62</bqs:last_page>
<bqs:reference rdf:parseType="Resource">
<bqs:reference_type
rdf:resource="http://www.cellml.org/bqs/1.0#Book" />
<bqs:isbn>9-999-99999-X</bqs:isbn>
<bqs:volume>5</bqs:volume>
<bqs:edition>2nd</bqs:edition>
<dc:contributor rdf:parseType="Resource">
<bqs:contributor_type>editor</bqs:contributor_type>
<rdf:value>
<rdf:Seq>
<rdf:li rdf:parseType="Resource">
<bqs:provider_type
rdf:resource="http://www.cellml.org/bqs/1.0#Person" />
<rdf:value rdf:parseType="Resource">
<vCard:N rdf:parseType="Resource">
<vCard:Family>Doe</vCard:Family>
<vCard:Given>John</vCard:Given>
</vCard:N>
</rdf:value>
</rdf:li>
<rdf:li rdf:parseType="Resource">
<bqs:provider_type
rdf:resource="http://www.cellml.org/bqs/1.0#Person" />
<rdf:value rdf:parseType="Resource">
<vCard:N rdf:parseType="Resource">
<vCard:Family>Smith</vCard:Family>
<vCard:Given>Suzy</vCard:Given>
</vCard:N>
</rdf:value>
</rdf:li>
</rdf:Seq>
</rdf:value>
</dc:contributor>
</bqs:reference>
</bqs:reference>
</rdf:Description>
</rdf:RDF>
Figure 45 Serialization of book article information. This example is a chapter from the book shown in Figure 42. The second <bqs:reference> element in this example stores information about the book.
Serialization of this subclass is postponed pending further information.
The WebResource subclass has three attributes, which can be serialized as follows:
-
url =
<bqs:url> (Note that a <dc:identifier> element could be used to store this information. However, this could lead to confusion with the use of the <dc:identifier> element to store a database UI (the identifier and cross_references attributes on the BibliographicReference class). Therefore, in this serialization of the BQS data model, the <dc:identifier> element is used to store the identifier of the citation, not the identifier of the cited resource. A new <bqs:url> element is created to store the identifier of the web resource. ).
-
estimated_size =
<bqs:estimated_size>. The units of the estimated size can be stored in <bqs:property> element (see Section 3.9 for more information on this element).
-
cost =
<bqs:cost>. The units of the cost can be stored in <bqs:property> element (see Section 3.9 for more information on this element).
Figure 46 shows the definition of information about a web resource.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.0/">
<rdf:Description about="#cellml_element_id">
<bqs:reference rdf:parseType="Resource">
<bqs:reference_type
rdf:resource="http://www.cellml.org/bqs/1.0#WebResource" />
<bqs:url>http://www.some_website.com/</bqs:url>
<bqs:estimated_size rdf:parseType="Resource">
<rdf:value>100</rdf:value>
<bqs:property rdf:parseType="Resource">
<bqs:property_type>units</bqs:property_type>
<rdf:value>kilobytes</rdf:value>
</bqs:property>
</bqs:estimated_size>
<bqs:cost rdf:parseType="Resource">
<rdf:value>100</rdf:value>
<bqs:property rdf:parseType="Resource">
<bqs:property_type>units</bqs:property_type>
<rdf:value>kilobytes</rdf:value>
</bqs:property>
</bqs:cost>
</bqs:reference>
</rdf:Description>
</rdf:RDF>
Figure 46 Serialization of web resource information.
This section provides several complete citation examples.
Figure 47 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:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:dcq="http://purl.org/dc/qualifiers/1.0/"
xmlns:vCard="http://www.w3.org/2001/vcard-rdf/3.0#">
<rdf:Description about="#cellml_element_id">
<bqs:reference rdf:parseType="Resource">
<bqs:reference_type
rdf:resource="http://www.cellml.org/bqs/1.0#JournalArticle" />
<dc:creator>
<rdf:Seq>
<rdf:li rdf:parseType="Resource">
<bqs:provider_type
rdf:resource="http://www.cellml.org/bqs/1.0#Person" />
<rdf:value 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>
</rdf:value>
</rdf:li>
<rdf:li rdf:parseType="Resource">
<bqs:provider_type
rdf:resource="http://www.cellml.org/bqs/1.0#Person" />
<rdf:value 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>
</rdf:value>
</rdf:li>
<rdf:li rdf:parseType="Resource">
<bqs:provider_type
rdf:resource="http://www.cellml.org/bqs/1.0#Person" />
<rdf:value 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>
</rdf:value>
</rdf:li>
</rdf:Seq>
</dc:creator>
<dc:title>
Cardiac Ca2+ dynamics: the role of ryanodine receptor
adaptation and sarcoplasmic reticulum load
</dc:title>
<dc:date rdf:parseType="Resource">
<dcq:dateType>issued</dcq:dateType>
<dcq:dateScheme>W3C-DTF</dcq:dateScheme>
<rdf:value>1998</rdf:value>
</dc:date>
<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:journal>
<bqs:volume>74</bqs:volume>
<bqs:first_page>1149</bqs:first_page>
<bqs:last_page>1168</bqs:last_page>
</bqs:reference>
</rdf:Description>
</rdf:RDF>
Figure 47 A complete journal article reference. Information about the journal itself is embedded within the reference.
Figure 48 demonstrates the definition of a reference to a journal article, with the journal information included by reference to a resource defined elsewhere. Figure 49 demonstrates the definition of the journal information. The cited reference is the same as that in Section 3.11.1.
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:dcq="http://purl.org/dc/qualifiers/1.0/"
xmlns:vCard="http://www.w3.org/2001/vcard-rdf/3.0#">
<rdf:Description about="#cellml_element_id">
<bqs:reference rdf:parseType="Resource">
<bqs:reference_type
rdf:resource="http://www.cellml.org/bqs/1.0#JournalArticle" />
<dc:creator>
<rdf:Seq>
<rdf:li rdf:parseType="Resource">
<bqs:provider_type
rdf:resource="http://www.cellml.org/bqs/1.0#Person" />
<rdf:value 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>
</rdf:value>
</rdf:li>
<rdf:li rdf:parseType="Resource">
<bqs:provider_type
rdf:resource="http://www.cellml.org/bqs/1.0#Person" />
<rdf:value 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>
</rdf:value>
</rdf:li>
<rdf:li rdf:parseType="Resource">
<bqs:provider_type
rdf:resource="http://www.cellml.org/bqs/1.0#Person" />
<rdf:value 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>
</rdf:value>
</rdf:li>
</rdf:Seq>
</dc:creator>
<dc:title>
Cardiac Ca2+ dynamics: the role of ryanodine receptor
adaptation and sarcoplasmic reticulum load
</dc:title>
<dc:date rdf:parseType="Resource">
<dcq:dateType>issued</dcq:dateType>
<dcq:dateScheme>W3C-DTF</dcq:dateScheme>
<rdf:value>1998</rdf:value>
</dc:date>
<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:reference>
</rdf:Description>
</rdf:RDF>
Figure 48 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 49.
<!--
This RDF is part of the file http://www.example.org/journals
-->
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:dcq="http://purl.org/dc/qualifiers/1.0/">
<rdf:Description 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 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 49 Information about two journals. This information could be referenced by bibliographic citations defined in the <bqs:reference> element.
Figure 50 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:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:dcq="http://purl.org/dc/qualifiers/1.0/">
<rdf:Description about="#cellml_element_id">
<bqs:reference rdf:parseType="Resource">
<dc:identifier rdf:parseType="Resource">
<bqs:identifier_scheme>Medline</bqs:identifier_scheme>
<rdf:value>97219925</rdf:value>
</dc:identifier>
<dc:description rdf:parseType="Resource" xml:lang="en">
<dcq:descriptionType>abstract</dcq:descriptionType>
<dc:format rdf:parseType="Resource">
<dcq:formatScheme>IMT</dcq:formatScheme>
<rdf:value>text/url</rdf:value>
</dc:format>
<!--
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>
</dc:description>
</bqs:reference>
</rdf:Description>
</rdf:RDF>
Figure 50 Citation by Medline unique identifier and inclusion of a reference to an abstract.
Figure 51 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:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:dcq="http://purl.org/dc/qualifiers/1.0/"
xmlns:vCard="http://www.w3.org/2001/vcard-rdf/3.0#">
<rdf:Description about="#cellml_element_id">
<bqs:reference rdf:parseType="Resource">
<bqs:reference_type
rdf:resource="http://www.cellml.org/bqs/1.0#Book" />
<dc:creator>
<rdf:Seq>
<rdf:li rdf:parseType="Resource">
<bqs:provider_type
rdf:resource="http://www.cellml.org/bqs/1.0#Person" />
<rdf:value rdf:parseType="Resource">
<vCard:N rdf:parseType="Resource">
<vCard:Family>Branden</vCard:Family>
<vCard:Given>Carl</vCard:Given>
</vCard:N>
</rdf:value>
</rdf:li>
<rdf:li rdf:parseType="Resource">
<bqs:provider_type
rdf:resource="http://www.cellml.org/bqs/1.0#Person" />
<rdf:value rdf:parseType="Resource">
<vCard:N rdf:parseType="Resource">
<vCard:Family>Tooze</vCard:Family>
<vCard:Given>John</vCard:Given>
</vCard:N>
</rdf:value>
</rdf:li>
</rdf:Seq>
</dc:creator>
<dc:title>Introduction to Protein Structure</dc:title>
<dc:date rdf:parseType="Resource">
<dcq:dateType>issued</dcq:dateType>
<dcq:dateScheme>W3C-DTF</dcq:dateScheme>
<rdf:value>1991</rdf:value>
</dc:date>
<dc:publisher rdf:parseType="Resource">
<bqs:provider_type
rdf:resource="http://www.cellml.org/bqs/1.0#Organisation" />
<rdf:value>Garland Publishing, Inc.</rdf:value>
<bqs:property rdf:parseType="Resource">
<bqs:property_type>location</bqs:property_type>
<rdf:value>New York</rdf:value>
</bqs:property>
</dc:publisher>
</bqs:reference>
</rdf:Description>
</rdf:RDF>
Figure 51 A complete book reference. Note the use of the Property class to provide the location of the publisher.
Figure 52 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:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:dcq="http://purl.org/dc/qualifiers/1.0/"
xmlns:vCard="http://www.w3.org/2001/vcard-rdf/3.0#">
<rdf:Description about="#cellml_element_id">
<bqs:reference rdf:parseType="Resource">
<bqs:reference_type
rdf:resource="http://www.cellml.org/bqs/1.0#Book" />
<dc:contributor rdf:parseType="Resource">
<bqs:contributor_type>editor</bqs:contributor_type>
<rdf:value>
<rdf:Seq>
<rdf:li rdf:parseType="Resource">
<bqs:provider_type
rdf:resource="http://www.cellml.org/bqs/1.0#Person" />
<rdf:value rdf:parseType="Resource">
<vCard:N rdf:parseType="Resource">
<vCard:Family>Brody</vCard:Family>
<vCard:Given>Jerome</vCard:Given>
<vCard:Other>S</vCard:Other>
</vCard:N>
</rdf:value>
</rdf:li>
<rdf:li rdf:parseType="Resource">
<bqs:provider_type
rdf:resource="http://www.cellml.org/bqs/1.0#Person" />
<rdf:value rdf:parseType="Resource">
<vCard:N rdf:parseType="Resource">
<vCard:Family>Center</vCard:Family>
<vCard:Given>David</vCard:Given>
<vCard:Other>M</vCard:Other>
</vCard:N>
</rdf:value>
</rdf:li>
<rdf:li rdf:parseType="Resource">
<bqs:provider_type
rdf:resource="http://www.cellml.org/bqs/1.0#Person" />
<rdf:value rdf:parseType="Resource">
<vCard:N rdf:parseType="Resource">
<vCard:Family>Tkachuk</vCard:Family>
<vCard:Given>Vsevolod</vCard:Given>
<vCard:Other>A</vCard:Other>
</vCard:N>
</rdf:value>
</rdf:li>
</rdf:Seq>
</rdf:value>
</dc:contributor>
<dc:title>Signal Transduction in Lung Cells</dc:title>
<dc:date rdf:parseType="Resource">
<dcq:dateType>issued</dcq:dateType>
<dcq:dateScheme>W3C-DTF</dcq:dateScheme>
<rdf:value>1993</rdf:value>
</dc:date>
<bqs:series>Lung Biology in Health and Disease</bqs:series>
<bqs:volume>65</bqs:volume>
<dc:publisher rdf:parseType="Resource">
<bqs:provider_type
rdf:resource="http://www.cellml.org/bqs/1.0#Organisation" />
<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>
</dc:publisher>
</bqs:reference>
</rdf:Description>
</rdf:RDF>
Figure 52 A more complicated complete book reference.
Figure 53 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:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:bqs="http://www.cellml.org/bqs/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:dcq="http://purl.org/dc/qualifiers/1.0/"
xmlns:vCard="http://www.w3.org/2001/vcard-rdf/3.0#">
<rdf:Description about="#cellml_element_id">
<bqs:reference rdf:parseType="Resource">
<bqs:reference_type
rdf:resource="http://www.cellml.org/bqs/1.0#BookArticle" />
<dc:creator>
<rdf:Seq>
<rdf:li rdf:parseType="Resource">
<bqs:provider_type
rdf:resource="http://www.cellml.org/bqs/1.0#Person" />
<rdf:value rdf:parseType="Resource">
<vCard:N rdf:parseType="Resource">
<vCard:Family>Rogers</vCard:Family>
<vCard:Given>Michael</vCard:Given>
<vCard:Other>S</vCard:Other>
</vCard:N>
</rdf:value>
</rdf:li>
<rdf:li rdf:parseType="Resource">
<bqs:provider_type
rdf:resource="http://www.cellml.org/bqs/1.0#Person" />
<rdf:value rdf:parseType="Resource">
<vCard:N rdf:parseType="Resource">
<vCard:Family>Strehler</vCard:Family>
<vCard:Given>Emanuel</vCard:Given>
<vCard:Other>E</vCard:Other>
</vCard:N>
</rdf:value>
</rdf:li>
</rdf:Seq>
</dc:creator>
<bqs:first_page>41</bqs:first_page>
<bqs:last_page>43</bqs:last_page>
<dc:date rdf:parseType="Resource">
<dcq:dateType>issued</dcq:dateType>
<dcq:dateScheme>W3C-DTF</dcq:dateScheme>
<rdf:value>1996</rdf:value>
</dc:date>
<bqs:reference rdf:parseType="Resource">
<bqs:reference_type
rdf:resource="http://www.cellml.org/bqs/1.0#Book" />
<dc:title>Guidebook to the Calcium-Binding Proteins</dc:title>
<dc:contributor rdf:parseType="Resource">
<bqs:contributor_type>editor</bqs:contributor_type>
<rdf:value>
<rdf:Seq>
<rdf:li rdf:parseType="Resource">
<bqs:provider_type
rdf:resource="http://www.cellml.org/bqs/1.0#Person" />
<rdf:value rdf:parseType="Resource">
<vCard:N rdf:parseType="Resource">
<vCard:Family>Celio</vCard:Family>
<vCard:Given>Marco</vCard:Given>
<vCard:Other>R</vCard:Other>
</vCard:N>
</rdf:value>
</rdf:li>
<rdf:li rdf:parseType="Resource">
<bqs:provider_type
rdf:resource="http://www.cellml.org/bqs/1.0#Person" />
<rdf:value rdf:parseType="Resource">
<vCard:N rdf:parseType="Resource">
<vCard:Family>Pauls</vCard:Family>
<vCard:Given>Thomas</vCard:Given>
</vCard:N>
</rdf:value>
</rdf:li>
<rdf:li rdf:parseType="Resource">
<bqs:provider_type
rdf:resource="http://www.cellml.org/bqs/1.0#Person" />
<rdf:value rdf:parseType="Resource">
<vCard:N rdf:parseType="Resource">
<vCard:Family>Schwaller</vCard:Family>
<vCard:Given>Beat</vCard:Given>
</vCard:N>
</rdf:value>
</rdf:li>
</rdf:Seq>
</rdf:value>
</dc:contributor>
<dc:publisher rdf:parseType="Resource">
<bqs:provider_type
rdf:resource="http://www.cellml.org/bqs/1.0#Organisation" />
<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>
</dc:publisher>
</bqs:reference>
</bqs:reference>
</rdf:Description>
</rdf:RDF>
Figure 53 A book chapter reference. (Some whitespace has been removed in order to fit the example on a single page.)
| 
