Author:
Autumn Cuellar (Bioengineering Research Group, University of Auckland)
Contributors:
David Bullivant (Bioengineering Research Group, University of Auckland)
Catherine Lloyd (Bioengineering Research Group, University of Auckland)
David Nickerson (Bioengineering Research Group, University of Auckland)
Poul Nielsen (Bioengineering Research Group, University of Auckland)
These meeting minutes cover plans for CellML example models and continue the metadata discussions last set aside in the 24 April 2001 Meeting Minutes. Alot has happened in the world of metadata since April. I will summarize the changes that have been made to RDF and Dublin Core in RDF as they apply to CellML. I will also answer questions that I, myself, have asked of Warren and Melanie. As always, questions and comments are most welcome.
I can finally offer a ray of hope to all those who have been anxiously awaiting more CellML example models: our new modeller, Catherine Lloyd, has been zealously active in writing those highly anticipated CellML models. We'll have our expanded model list out by November. If you want an e-mail alerting you when we've added the new models, join the cellml-announce mailing list.
When I decided to pick up the CellML Metadata project where Warren and Melanie had left it in May (with the 18 May 2001 Metadata Specification), I found that significant changes had been made in both the W3C's treatment of RDF and the DCMI's treatment of Dublin Core within RDF. As the May 18 Metadata Specification relies heavily on RDF and Dublin Core standards, these changes will also affect metadata in CellML.
September 6 of this year, the RDF Core Working Group released a Working Draft titled Refactoring RDF/XML Syntax. The group's intent was not to change the meaning of the Resource Description Framework (RDF) Model and Syntax Specification but to clear up any ambiguities that may have previously existed by proposing changes to the syntax (as the title indicates).
Among the changes proposed in the Working Draft are two which will affect CellML Metadata. The first is that the about attribute (and all others defined in the RDF Model and Syntax Specification) must be placed in the RDF namespace. In this document we assume that the prefix rdf is mapped to the RDF namespace URI.
<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="#rdf_namespaces">
<cmeta:annotation rdf:parseType="Resource">
<cmeta:annotation_type>comment</cmeta:annotation_type>
<rdf:value>The "about" attribute is not labelled as being in the RDF
namespace.</rdf:value>
</cmeta:annotation>
</rdf:Description>
</rdf:RDF>
Figure 1 The about attribute does not have the rdf namepace designation.
is now:
<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 rdf:about="#rdf_namespaces">
<cmeta:annotation rdf:parseType="Resource">
<cmeta:annotation_type>comment</cmeta:annotation_type>
<rdf:value>The "about" attribute is now labelled as being in the RDF
namespace.</rdf:value>
</cmeta:annotation>
</rdf:Description>
</rdf:RDF>
Figure 2 The about attribute now does have the rdf namepace prefix.
The second change in the Sept. 6 Working Draft that affects CellML metadata is the elimination of the container production which includes the elements <rdf:Bag>, <rdf:Seq>, and <rdf:Alt>. At this point I am still assessing how this will change our May 18 Metadata Specification.
The Dublin Core Metadata Initiative published two papers in August and September of this year: Expressing Qualified Dublin Core in RDF/XML and Expressing Simple Dublin Core in RDF/XML, respectively. The two papers supersede the 1999 paper Guidance on expressing the Dublin Core within the Resource Description Framework (RDF), on which Melanie and Warren based
their recommendations for marking up citations.
The good news is that the new way of expressing qualified Dublin Core in RDF seems less verbose than previously suggested. The reason for this is the authors have enlisted the use of the RDF Schema (Resource Description Framework (RDF) Schema Specification 1.0) and created their own "DC Terms RDF Schema Draft" which defines the qualifier vocabulary for us.
Perhaps the best way to explain the new method of encoding Dublin Core in RDF is by showing you a couple of examples. Figure 3 is an example from the 18 May 2001 Metadata Specification. Figure 4 is the same example updated using the new Dublin Core encoding schemes. Because the subject qualifiers MESH (Medical Subject Headings) and DDC (Dewey Decimal Classification) have been defined in the DC Terms RDF Schema, they become individual elements as do all of the element encoding schemes listed in the Dublin Core Qualifiers document. Please note that the Dublin Core and the Dublin Core Qualifier namespace URIs have been updated, as well.
<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 3 An example from the 18 May 2001 CellML Metadata Specification.
<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.1/"
xmlns:dcq="http://purl.org/dc/terms/"
xmlns:rdfs="http://www.w3.rog/2000/01/rdf-schema#">
<rdf:Description rdf:about="#cellml_element_id">
<bqs:reference rdf:parsetype="Resource">
<dc:subject rdf:parsetype="Resource">
<bqs:subject_type>subject_heading</bqs:subject_type>
<dcq:MESH rdf:parsetype="Resource">
<rdfs:label>
<rdf:li>Signal Transduction</rdf:li>
<rdf:li>Ion Transport</rdf:li>
</rdfs:label>
</dcq:MESH>
</dc:subject>
<dc:subject rdf:parsetype="Resource">
<bqs:subject_type>classification_code</bqs:subject_type>
<dcq:DDC>
<rdf:value>572</rdf:value>
</dcq:DDC>
</dc:subject>
<dc:subject rdf:parsetype="Resource">
<bqs:subject_type>keyword</bqs:subject_type>
<rdf:value>
<rdf:li>calcium signaling</rdf:li>
<rdf:li>calcium import</rdf:li>
</rdf:value>
</dc:subject>
</bqs:reference>
</rdf:Description>
</rdf:RDF>
Figure 4 The new suggested encoding of Dublin Core in RDF. Notice that the Dublin Core Qualifiers MESH and DDC are now given their own elements within the dcq namespace.
Figure 5 shows another example from the May 18 Metadata Specification. The following example, shown in Figure 6, gives the new method of encoding the element refinement qualifiers (<dc:description>'s abstract and table of contents) in RDF. As with the encoding scheme qualifiers, the refinement qualifiers are defined in the DC Terms RDF Schema to be their own elements. Also, since they are declared to be sub-properties of the element they are qualifying, there is no need to define the abstract and table of contents as being elements of the <dc:description> 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: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 5 Another example from the 18 May 2001 CellML Metadata Specification.
<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.1/"
xmlns:dcq="http://purl.org/dc/terms/">
<rdf:Description>
<bqs:reference rdf:parseType="Resource">
<dcq:abstract rdf:parseType="Resource">
<dcq:IMT>
<rdf:value>text/url</rdf:value>
</dcq:IMT>
<rdf:value>
http://www.abstractsRUS.com/abstract567843
</rdf:value>
</dcq:abstract>
<dcq:tableOfContents rdf:parseType="Resource">
<dcq:IMT>
<rdf:value>text/html</rdf:value>
</dcq:IMT>
<rdf:value rdf:parseType="Literal">
<p> ... table of contents info here ...</p>
</rdf:value>
</dcq:tableOfContents>
</bqs:reference>
</rdf:Description>
</rdf:RDF>
Figure 6 The new suggested encoding of Dublin Core in RDF. The <dc:description> element can be eliminated because the vocabulary definitions of <dcq:abstract> and <dcq:tableOfContents> explain that both properties are sub-properties of the <dc:description> element.
Since Melanie and Warren based their BQS serialization on the former method of expressing Dublin Core in RDF, we will most likely want to follow their lead and revise our serialization of the BQS to correspond with the current way of encoding Dublin Core in XML to maintain consistency. More to come.
Q: Why would you want to comment on mathematical problem type?
A: Basically this information would allow the modeller to recommend to the processing app what kind of mathematical solver it should use to run the problem. This might be useful in cases where the application isn't bright enough to figure out if it can solve a particular problem or not, or in cases where examination of the equations might lead the application to choose an inappropriate solver. Also, someone might want to search a library of CellML models and find all those that use a particular math problem type. This metadata would make that an easy search (i.e., it could be done by an app without having to parse and understand the MathML).
Q: Why use an rdf:resource attribute instead of a literal value as a property value (examples shown in Figure 7 and Figure 8)?
A: In Section 3.2 of the paper Guidance on expressing
the Dublin Core within the Resource Description Framework (1999)
the authors suggest using the rdf:resource attribute whenever possible for interoperability and to make
changes or additions to a definition of a term possible (or, at least, easier). Since this paper is now obsolete (though the authors' reasoning is not), we will further discuss this issue. Melanie gives a pretty good description of why to use one or the other in Section 4 of 3 April 2001 Meeting Minutes.
<bqs:referenceType rdf:resource="http://some.com/#journal" />
Figure 7 Use of rdf:attribute.
<bqs:referenceType>journal</bqs:referenceType>
Figure 8 Use of a literal value
| 
