<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
        {font-family:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
        {font-family:Verdana;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";
        color:black;
        mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p
        {mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0cm;
        mso-margin-bottom-alt:auto;
        margin-left:0cm;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";
        color:black;}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0cm;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New";
        color:black;}
span.EmailStyle17
        {mso-style-type:personal;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:"Consolas","serif";
        color:black;
        mso-fareast-language:EN-US;}
span.EmailStyle22
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor="white" lang="EN-NZ" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">Thanks for taking the time to bring me up to speed, Steve.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">I’m familiar with the complexities of preparing specifications and realise I’ve come in mid-way.  I’ll spend some time reading up on the containers and occurrences history.  But I’m unclear whether it is better
 to use DSW terms in anticipation of them having longevity, or just to mint our own in the meantime?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">For the taxon convenience fields...  <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">I thought I read in the DwC RDF schema that properties like taxonRank were in the Taxon class (so using them in Identification conflicts with their definition), but looking again I see that the spec uses “dwcattributes:organizedInClass”
 which specifically does not imply domain or range.  So now I’m at peace with that.
</span><span style="font-family:Wingdings;color:#1F497D">J</span><span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">However, I am pointing to our own RDF versions of taxon classification terms that we use, and using DwC properties to define these taxon terms, plus I am combing these all together in a single JSON-LD API result. 
 So at this point I don’t think I need to repeat the convenience properties in Identification (as they are available directly in the Taxon object).  While this seems to fit our purpose I can see that this may be sub-optimal for others who download the data
 and use it separately – I’ll need to contemplate that scenario some more.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Cheers,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Douglas<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext;mso-fareast-language:EN-NZ">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext;mso-fareast-language:EN-NZ">
 Steve Baskauf [mailto:steve.baskauf@Vanderbilt.Edu] <br>
<b>Sent:</b> Wednesday, 17 August 2016 6:32 a.m.<br>
<b>To:</b> Douglas Campbell<br>
<b>Cc:</b> tdwg-content@lists.tdwg.org<br>
<b>Subject:</b> Re: [tdwg-content] Implementing Darwin Core in RDF<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Douglas,<br>
I was the lead author on the DwC RDF Guide, so I can try to answer your questions about it.  The TDWG RDF Task Group is still in operation, although it hasn't been very active for the past several years.  The RDG TG has an online "home" at the TDWG Github site.[1] 
 However, the content didn't survive the migration from Google Code very well, so it takes some effort at this point to sort through it.  The TG also has an email list [2] but there has been little traffic on it recently.<br>
<br>
*Dereferencing of the DwC IRI namespace* - Unfortunately, the dwciri: namespace terms don't dereference at the present time.  This needs to be corrected.  I've created a Turtle serialization [3] of how I think the RDF should be written for the dwciri: terms,
 but it isn't served when one attempts to dereference the terms and hasn't been incorporated into the official DwC repository.  Part of the problem here is that the guidelines for documenting terms in machine-readable form are still going through the adoption
 process.[4] I'm hopeful that when the Documentation Specification is ratified, we can make sure that all existing DwC terms dereference in a consistent manner.<br>
<br>
*Best practice for connecting containers together* - By this, I'm assuming you mean linking instances of the various Darwin Core classes, or in RDF terms, linking nodes.  The RDF Guide is silent on how to do this.  That's not great from the standpoint of actually
 turning Darwin Core records into RDF, but it was a way to complete the guide in a finite amount of time.  What is missing is a consensus domain model that would lay out how instances of the Darwin Core classes would be linked.  Such a model should be developed,
 but that has not yet happened.  Again, there is a draft standard submitted for review [5], which if adopted will specify (in Section 4) a process for developing such a model.  When we wrote the RDF Guide, we provided ancillary documents [6], which included
 examples that followed the RDF Guide and linked instances using various proposed models.  There are links to web pages containing examples using TaxonConcept, BiSciCol, and Darwin-SW object properties to link class instances.  I am not sure whether there is
 any RDF "in the wild" for the first two examples.  I'm more familiar with Darwin-SW, as I was involved in its development [7].  There is a Semantic Web Journal article about Darwin-SW [8], so I won't go into detail about it here, except to say that its data
 model was developed following an extensive discussion on the tdwg-content email list [9] about how members of the community understood the Darwin Core classes.  The relationship between Darwin-SW model and the historical 1993 ACS Model can be viewed at [10]. 
 There are a bit over a million triples of data "in the wild" modeled on Darwin-SW in accordance with the DwC RDF guide, accessible at a SPARQL end point. [11]  Some examples showing how to play around with SPARQL queries of these data are at [12].<br>
<br>
*The overlapping scope of Occurrence and Specimen types* - There is a long history behind the meaning of "Occurrence".  There is an out-of-date-summary of some of the discussion around this topic in the Darwin-SW documentation [13].  I think that at the time
 when Darwin Core was originally adopted, an Occurrence was considered a sort of superclass of the Specimen and Observation classes.  However, after a lot of discussion, the meaning of dwc:Occurrence was clarified by changing it to its current definition: "An
 existence of an Organism (sensu <a href="http://rs.tdwg.org/dwc/terms/Organism">
http://rs.tdwg.org/dwc/terms/Organism</a>) at a particular place at a particular time."  In this view, an Occurrence isn't a concrete thing like a Specimen - it's more like a database join between an Event instance (time and place) and an Organism, which allows
 for a one-to-many relationship between a Organism and Occurrences, and a one-to-many relationships between an Event and Occurrences.  It also allows for a single occurrence of an organism at a time and place to be documented by one-to-many forms of evidence,
 which could include PreservedSpecimens, HumanObservation data, or images of various sorts.  In RDF terms, an Occurrence could be thought of as a node that is linked to Event, Organism, and evidence instances nodes.  You can see this represented graphically
 at [7], where "dsw:Token" refers to a generic class for evidence.  In any case, separating Occurrence (as a node linking Events to Organisms) from Specimen allows an Occurrence to be documented by one to many instances of any kind of evidence, or even multiple
 kinds of evidence.  For example, an Occurrence could be documented by a PhysicalSpecimen as well as several images.  Here is an example of an organism with two Occurrences:
<br>
<a href="http://bioimages.vanderbilt.edu/org-jorgem/rec13_0004">http://bioimages.vanderbilt.edu/org-jorgem/rec13_0004</a><br>
The first occurrence on 2013-07-24 was documented by 42 camera trap images, and the second occurrence on 2013-07-25 was documented by 21 camera trap images.  You can see how this was represented in RDF at [14].  In most cases, specimen records will be much
 simpler than this, with one organism, documented at one occurrence, with evidence of one PreservedSpecimen.  Such a simpler case could be represented with a simpler model.  But the more complex model allows specimen-derived occurrence records to be merged
 with other kinds of occurrence records, such as the camera trap example I gave, mark-recapture bird banding observations, iNaturalist occurrences documented by photos of the organism, etc.<br>
<br>
*Conflicting usage of Taxon fields in the Identification object* - In order to explain the rationale behind why what seem to be taxon-related properties are assigned to Identification instances, I must refer to the idea of "convenience terms" as expressed in
 Section 2.7 of the RDF Guide.[15]   In a perfect world, we would have the following:<br>
<br>
a collection item linked by dwciri:inCollection to an IRI-identified collection<br>
an identification instance linked by dwciri:toTaxon to an IRI-identified taxon (a.k.a. taxon concept)<br>
a location instance linked by dwciri:inDescribedPlace to an IRI-identified geographic place (a.k.a. "feature")<br>
<br>
If the linked IRI-identified object resources were described by RDF, it would not be necessary to include any of the Darwin Core "convenience" properties included in Table 3.5 [16].  The information contained in the values of those properties could be discovered
 by dereferencing the object IRIs and traversing subsequent links from that RDF.  However, if those IRIs don't exist, then the convenience properties provide a string-based mechanism to relate the subject resource to other resources that should be linked to
 the same (unidentified) object resource.  So for example, if we say a specimen has the convenience properties and values
<br>
<br>
dwc:collectionCode="Mamm"<br>
dwc:institutionCode ="MVZ"<br>
<br>
we are not saying that "Mamm" is the collection code of the specimen and that "MVZ" is the institution code of the specimen.  Rather, we mean that the specimen should be linked to a collection (with unknown IRI) whose code is MVZ and whose owning institution
 has the code "MVZ".  Similarly, if we say that an identification has the convenience properties and values<br>
<br>
dwc:genus="Hersiliiadae"<br>
dwc:specificEpithet="yaeyamaensis"<br>
<br>
we are not saying that "yaeyamaensis" is the specific epithet of the identification and that "Hersiliiadae" is the genus of the identification.  Rather, we mean that the identification should be linked to a taxon (with unknown IRI) for which the specificEpithet
 part of its name string is "yaeyamaensis", which is included in the genus "Hersiliiadae".  This may seem odd, particularly if you are used to thinking of genus and specific epithet as properties of a taxon.  But the sets of DwC convenience properties are intended
 to be a temporary, string-based way to describe an unidentified resource to which the subject resource should be linked.  At some future time, if IRIs can be discovered, those sets of convenience properties might be dropped if dereferencing the IRIs provides
 the same information.  In these examples, one might replace with:<br>
<br>
a collection item linked by dwciri:inCollection to <a href="http://grbio.org/cool/0rht-pj95">
http://grbio.org/cool/0rht-pj95</a><br>
an identification instance linked to <a href="http://zoobank.org/75C9EA16-72B1-44C9-AD40-3C3D41323AB9">
http://zoobank.org/75C9EA16-72B1-44C9-AD40-3C3D41323AB9</a><br>
<br>
although I don't think either of these IRIs currently dereference to meaningful machine-readable RDF (although they have human-readable web pages). 
<br>
<br>
I hope that this has provided you with some answers, or at least a starting point for additional exploration or questions.  Please feel free to reply if there were parts of what I wrote that weren't clear.<br>
<br>
Steve Baskauf<br>
<br>
[1] <a href="https://github.com/tdwg/rdf">https://github.com/tdwg/rdf</a><br>
[2] <a href="http://groups.google.com/group/tdwg-rdf">http://groups.google.com/group/tdwg-rdf</a><br>
[3] <a href="https://github.com/tdwg/vocab/blob/master/code-examples/darwin-core/dwciri.ttl">
https://github.com/tdwg/vocab/blob/master/code-examples/darwin-core/dwciri.ttl</a><br>
[4] <a href="https://github.com/tdwg/vocab/blob/master/documentation-specification.md">
https://github.com/tdwg/vocab/blob/master/documentation-specification.md</a><br>
[5] <a href="https://github.com/tdwg/vocab/blob/master/maintenance-specification.md">
https://github.com/tdwg/vocab/blob/master/maintenance-specification.md</a><br>
[6] <a href="https://github.com/tdwg/rdf/blob/master/DwCAncillary.md">https://github.com/tdwg/rdf/blob/master/DwCAncillary.md</a><br>
[7] <a href="https://github.com/darwin-sw/dsw">https://github.com/darwin-sw/dsw</a><br>
[8] <a href="http://www.semantic-web-journal.net/content/darwin-sw-darwin-core-based-terms-expressing-biodiversity-data-rdf-1">
http://www.semantic-web-journal.net/content/darwin-sw-darwin-core-based-terms-expressing-biodiversity-data-rdf-1</a><br>
[9] <a href="https://github.com/darwin-sw/dsw/wiki/TdwgContentEmailSummary">https://github.com/darwin-sw/dsw/wiki/TdwgContentEmailSummary</a><br>
[10] <a href="https://github.com/darwin-sw/dsw/blob/master/img/acs-dsw-poster.pptx">
https://github.com/darwin-sw/dsw/blob/master/img/acs-dsw-poster.pptx</a><br>
[11] <a href="http://rdf.library.vanderbilt.edu/sparql?view">http://rdf.library.vanderbilt.edu/sparql?view</a><br>
[12] <a href="https://github.com/HeardLibrary/semantic-web/blob/master/learning-sparql/learning-sparql-ch3-part2-answers.md">
https://github.com/HeardLibrary/semantic-web/blob/master/learning-sparql/learning-sparql-ch3-part2-answers.md</a><br>
[13] <a href="https://github.com/darwin-sw/dsw/wiki/ClassOccurrence">https://github.com/darwin-sw/dsw/wiki/ClassOccurrence</a><br>
[14] <a href="http://bioimages.vanderbilt.edu/org-jorgem/rec13_0004.rdf">http://bioimages.vanderbilt.edu/org-jorgem/rec13_0004.rdf</a><br>
[15] <a href="http://rs.tdwg.org/dwc/terms/guides/rdf/index.htm#2.7_Darwin_Core_convenience_terms">
http://rs.tdwg.org/dwc/terms/guides/rdf/index.htm#2.7_Darwin_Core_convenience_terms</a><br>
[16] <a href="http://rs.tdwg.org/dwc/terms/guides/rdf/index.htm#3.5_Darwin_Core_convenience_terms_that_are_expected_to_be_used_o">
http://rs.tdwg.org/dwc/terms/guides/rdf/index.htm#3.5_Darwin_Core_convenience_terms_that_are_expected_to_be_used_o</a><br>
<br>
<span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><br>
Douglas Campbell wrote: <o:p></o:p></p>
<p class="MsoNormal">Hi all,<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">I am implementing Darwin Core in RDF as part of our API at Te Papa (Museum of New Zealand).  My aim is to map our specimen metadata to rich Darwin Core RDF using JSON-LD, then 'dumb down' to Simple Darwin Core to contribute to virtual herbariums.
  I have mocked-up some records, however there are some areas where I'm not quite sure how to interpret the Darwin Core RDF Guide.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">The areas of confusion I have include:<o:p></o:p></p>
<p class="MsoNormal">* Best practice for connecting containers together<o:p></o:p></p>
<p class="MsoNormal">* Dereferencing of the DwC IRI namespace<o:p></o:p></p>
<p class="MsoNormal">* The overlapping scope of the Occurrence and Specimen types<o:p></o:p></p>
<p class="MsoNormal">* Conflicting usage of Taxon fields in the Identification object.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">I'm hoping for suggestions:<o:p></o:p></p>
<p class="MsoNormal">1. Are there any implementations of DwC RDF data online that I could look at as examples to follow?<o:p></o:p></p>
<p class="MsoNormal">2. What/to whom is the best way to ask specific questions about DwC RDF?<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">At this stage our API prototype is only available internally but there is some documentation available publicly at:<o:p></o:p></p>
<p class="MsoNormal"><a href="https://github.com/te-papa/collections-api/wiki">https://github.com/te-papa/collections-api/wiki</a><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Thanks in advance,<o:p></o:p></p>
<p class="MsoNormal">Douglas<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><b>Douglas Campbell</b><o:p></o:p></p>
<p class="MsoNormal">Business Analyst<o:p></o:p></p>
<p class="MsoNormal">Collections Information Services<o:p></o:p></p>
<p class="MsoNormal">Museum of New Zealand Te Papa Tongarewa<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<div class="MsoNormal" align="center" style="text-align:center"><span style="font-size:12.0pt;font-family:"Times New Roman","serif";mso-fareast-language:EN-NZ">
<hr size="2" width="100%" align="center">
</span></div>
<p align="center" style="text-align:center">Visit the Te Papa website <a href="http://www.tepapa.govt.nz">
http://www.tepapa.govt.nz</a><br>
The email message together with the accompanying attachments may be <strong>CONFIDENTIAL</strong>. If you have received this message in error, please notify <a href="https://www.tepapa.govt.nz/about/contact-us/general-enquiries">https://www.tepapa.govt.nz/about/contact-us/general-enquiries</a>
 immediately and delete the original message. The views expressed in this message are those of the individual sender, except where the sender specifically states them to be views of Te Papa.  Te Papa employs strict virus checking measures and accepts no liability
 for any loss caused either directly or indirectly by a virus arising from the use of this message or any attached file.<o:p></o:p></p>
<div class="MsoNormal" align="center" style="text-align:center"><span style="font-size:12.0pt;font-family:"Times New Roman","serif";mso-fareast-language:EN-NZ">
<hr size="2" width="100%" align="center">
</span></div>
<div>
<div style="border-top:solid black 1.0pt;border-left:none;border-bottom:solid black 1.0pt;border-right:none;padding:8.0pt 0cm 8.0pt 0cm;margin-top:15.0pt;margin-bottom:15.0pt">
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Verdana","sans-serif";mso-fareast-language:EN-NZ">This email has been filtered by SMX. For more information visit
<a href="http://smxemail.com/">smxemail.com</a><o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif";mso-fareast-language:EN-NZ"><br>
<br>
<o:p></o:p></span></p>
<pre>-- <o:p></o:p></pre>
<pre>Steven J. Baskauf, Ph.D., Senior Lecturer<o:p></o:p></pre>
<pre>Vanderbilt University Dept. of Biological Sciences<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>postal mail address:<o:p></o:p></pre>
<pre>PMB 351634<o:p></o:p></pre>
<pre>Nashville, TN  37235-1634,  U.S.A.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>delivery address:<o:p></o:p></pre>
<pre>2125 Stevenson Center<o:p></o:p></pre>
<pre>1161 21st Ave., S.<o:p></o:p></pre>
<pre>Nashville, TN 37235<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>office: 2128 Stevenson Center<o:p></o:p></pre>
<pre>phone: (615) 343-4582,  fax: (615) 322-4942<o:p></o:p></pre>
<pre>If you fax, please phone or email so that I will know to look for it.<o:p></o:p></pre>
<pre><a href="http://bioimages.vanderbilt.edu">http://bioimages.vanderbilt.edu</a><o:p></o:p></pre>
<pre><a href="http://vanderbilt.edu/trees">http://vanderbilt.edu/trees</a><o:p></o:p></pre>
<pre><o:p> </o:p></pre>
</div>

<P>
<HR>
</P>
<P align=center>Visit the Te Papa website <A 
href="http://www.tepapa.govt.nz">http://www.tepapa.govt.nz</A><BR>The email 
message together with the accompanying attachments may be 
<STRONG>CONFIDENTIAL</STRONG>. If you have received this message in error, 
please notify <A 
href="https://www.tepapa.govt.nz/about/contact-us/general-enquiries">https://www.tepapa.govt.nz/about/contact-us/general-enquiries</A> 
immediately and delete the original message. The views expressed in this message 
are those of the individual sender, except where the sender specifically states 
them to be views of Te Papa.  Te Papa employs strict virus checking 
measures and accepts no liability for any loss caused either directly or 
indirectly by a virus arising from the use of this message or any attached 
file.<BR></P>
<HR>

<P></P>
<div>
<div style="border-top: solid 1px black; border-bottom: solid 1px black;
 padding: 10px 0; margin: 20px 0; font-size: 9pt;
 font-family: Verdana, Arial, Helvetica, sans-serif;">This email has been
 filtered by SMX. For more information visit
 <a href="http://smxemail.com/">smxemail.com</a></div>
</div>

</body>
</html>