| | | | |
| | | | | | | | | | | | Author: Melanie Nelson (Physiome Sciences Inc.) Contributor: Warren Hedley (Bioengineering Research Group, University of Auckland)
Several types of CellML metadata require the storage of information about people. These meeting minutes review the options for defining such information, and present a recommended approach.
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 1 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 1 Use of vCard elements to define metadata about a model builder.
Figure 2 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 Flintstone </vCard:FN>
<vCard:N rdf:parseType=" Resource " >
<vCard:Family > Flintstone </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_flintstone@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 2 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 Flintstone'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 Flintstone works in the Parallel Computing Research Group, which is a subunit of the Department of Computer Science at the University of Bedrock.
| | | | | |