<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I looked at the tdwg-content archives to try to figure out which of the
last two emails that I wrote were actually sent out to the list. This
one below does not show up in the archives because "An HTML attachment
was scrubbed...", apparently the actual email. I'll try sending it
again in hopes that the message actually survives. The other message
that contained comments about Douglas' example files (and which
actually had attachments) never came to me, but shows up in the
archives at
<a class="moz-txt-link-freetext" href="http://lists.tdwg.org/pipermail/tdwg-content/2016-August/003642.html">http://lists.tdwg.org/pipermail/tdwg-content/2016-August/003642.html</a><br>
<br>
I'm not sure what is going on with the listserv, my spam filter, or
both.<br>
Steve<br>
<br>
-------- Original Message --------
<table class="moz-email-headers-table" border="0" cellpadding="0"
cellspacing="0">
<tbody>
<tr>
<th align="right" nowrap="nowrap" valign="baseline">Subject: </th>
<td>Re: [tdwg-content] Implementing Darwin Core in RDF</td>
</tr>
<tr>
<th align="right" nowrap="nowrap" valign="baseline">Date: </th>
<td>Fri, 26 Aug 2016 10:44:45 -0500</td>
</tr>
<tr>
<th align="right" nowrap="nowrap" valign="baseline">From: </th>
<td>Steve Baskauf <a class="moz-txt-link-rfc2396E" href="mailto:steve.baskauf@vanderbilt.edu"><steve.baskauf@vanderbilt.edu></a></td>
</tr>
<tr>
<th align="right" nowrap="nowrap" valign="baseline">Organization:
</th>
<td>Vanderbilt University Dept. of Biological Sciences</td>
</tr>
<tr>
<th align="right" nowrap="nowrap" valign="baseline">To: </th>
<td>Douglas Campbell <a class="moz-txt-link-rfc2396E" href="mailto:Douglas.Campbell@tepapa.govt.nz"><Douglas.Campbell@tepapa.govt.nz></a>,
<a class="moz-txt-link-rfc2396E" href="mailto:tdwg-content@lists.tdwg.org">"tdwg-content@lists.tdwg.org"</a> <a class="moz-txt-link-rfc2396E" href="mailto:tdwg-content@lists.tdwg.org"><tdwg-content@lists.tdwg.org></a></td>
</tr>
<tr>
<th align="right" nowrap="nowrap" valign="baseline">References: </th>
<td><br>
</td>
</tr>
</tbody>
</table>
<br>
<br>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
Douglas (and the list),<br>
I took some time to look at your Turtle file, but will have to come
back to it again later when I have more time before giving you specific
feedback. <br>
<br>
However, I wanted to make a few general comments to express how I think
about the use of RDF in the biodiversity informatics context. Before
embarking down the path of exposing metadata as RDF, I think that one
needs to ask the question: "Why do I want to expose RDF?" There are
several things that you get with RDF:<br>
1. It's machine-readable.<br>
2. It's a W3C standard that enables linking resources described by
different data providers as a graph.<br>
3. RDF triples from different sources can easily be aggregated in a
triplestore and be queried using SPARQL.<br>
4. It is compatible with machine reasoning.<br>
<br>
If all you care about is item #1, then RDF is probably more trouble
than it is worth. There are more conventional means for providing
access to data without requiring human intervention, with vanilla JSON
being a prime example.<br>
<br>
If your primary concern is breaking down data silos (i.e. you like the
idea of Linked Data), then item #4 is probably more trouble that it's
worth. Machine reasoning is possible, but carrying out effective,
non-trivial reasoning, requires a clear idea of what kind of reasoning
you want to undertake and careful thought about how to structure the
RDF.<br>
<br>
RDF isn't the only way to achieve item #2. Although JSON-LD can be
valid RDF, it doesn't have to be. There also other popular non-RDF
graph database options may be less troublesome if all you care about is
linking data as a graph.<br>
<br>
It seems to me that item #3 is the sweet spot where the potential
benefits of using RDF could outweigh its hassles. IF multiple data
providers exposed their data using a consistent graph topology, a
machine could harvest triples from the various providers, throw them
into a standard triplestore, and other machines could query the
aggregated data using SPARQL to ask interesting questions. All of this
could be done in an automated fashion, with little or no human
intervention. (There is the additional problem of providers
disciplining themselves to using consensus URIs to identify resources
that would be linked across data silos rather than minting their own
new ones, but that's a different issue that I won't get into in this
email.)<br>
<br>
However, if the multiple providers each use their own graph topology,
then there are problems. Simply merging the triples into a single
graph would be no problem. However, constructing a query that would
work with every possible graph model that providers dream up would be
virtually impossible. <br>
<br>
So if one aspires to merge RDF triples from multiple providers, the
burden of enabling querying that will work with all data can fall at
three places in the workflow:<br>
<br>
1. The burden could fall on <b>providers</b> to discipline themselves
to follow a consensus graph model. This requires them to express their
triples as a graph that might not correspond to their native data
model, but once that is done, no further action would be required down
the pipeline.<br>
2. The burden could fall on <b>aggregators</b> to "clean up" triples
as they are ingested into the triplestore. For example, it's not
difficult to create SPARQL construct queries that would add nodes that
aren't present in the providers data but that are needed for
consistency with the graph model used by the aggregator. However, that
would depend on the aggregator to create a sort of "mapping" for each
provider that uses a different graph model. It's likely that would
require at least some human intervention, which is at odds with the
goal of automated machine discovery and ingestion. <br>
3. The burden could fall on the <b>users</b> who want to query the
aggregated triples. The "dirty" triples from multiple providers
following differing graph models could just be thrown together in a
triplestore. Those who want to query the data would have to create
complex queries that were designed to catch all of the variations in
graph topologies that providers might reasonably dream up, or else risk
missing some results that might be important. It seems likely that
this approach would be doomed to failure. Who would want to waste
their time doing all that work when there would be a high probability
of missing some results anyway?<br>
<br>
Although the second option would probably be feasible, in order to
achieve the real promise of RDF for our community, it seems to me like
option #1 would be the way to go.<br>
<br>
Bringing this back to the specific example of Douglas' data and
Darwin-SW, Darwin-SW was designed with the intention of facilitating
aggregation of RDF metadata from diverse sources: traditional museum
specimens, event-oriented occurrences (bioblitzes, trawls),
mark-recapture, repeated samples, collection of tissues/DNA without
collecting the organism, camera traps, observations without collection
(e.g. birder observations), etc. Every one of these categories of data
providers are going to have some part of the Darwin-SW model that they
don't care about. Museums may care about specimens but not organisms.
Birders may care about organisms but not specimens. Bioblitzers may
care passionately about events with many occurrences, while
mark-recapture people may think that events are useless since every
occurrence happens at a separate event. In order for Darwin-SW to work
as intended, each kind of provider is going to just have to bite the
bullet and create nodes for every kind of resource in the Darwin-SW
model whether they like it or not. This is very much NOT in the
wild-west spirit of RDF where Anybody can say Anything about Any
resource. But if one cares about standardization, one will follow the
template even if it doesn't fit perfectly with the provider's
situation. <br>
<br>
In writing Darwin-SW, we rigged it (some would say poisoned it) with
semantics that cause a graph to become inconsistent if the Darwin-SW
object properties are used to join classes in a way that's inconsistent
with the Darwin-SW model. I won't go into the details here - you can
read about them in section 3.2 of the paper [1]. We've received some
criticism for doing that, and perhaps it was a bad idea. But that's
the way things stand at the present. It's a sort of veiled threat that
says, "there's nothing to stop you from using the Darwin-SW object
properties inappropriately, but if you do, you will create a graph that
a reasoner will flag as inconsistent". If a provider is bothered by
that, it's better to mint its own object properties and not use the
Darwin-SW ones. <br>
<br>
I'll try to provide a more direct response about Douglas' sample data
later on. One thing that I might say now is that I'm not sure that I
understand what Douglas means when he says "it would be impossible to
create an Organism entity. And in fact we will not create Organism
entities as we don’t need them in our context". If the problem is a
reluctance to mint and maintain URIs for resources that don't play an
important role in the data, it's quite possible to just let them be
blank nodes without URIs. If the issue is that the Organism doesn't
have an identification, that's no problem. An Organism can have zero
to many identifications at any particular time. New identifications
can be added at any point in the future.<br>
<br>
Steve<br>
<br>
[1]
<a moz-do-not-send="true" class="moz-txt-link-freetext"
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>
<br>
Douglas Campbell wrote:
<blockquote
cite="mid:7047A35971A53E48AD4C3F5F43F1E8D764B7AB6F@BOH-EXCH2010.boh.tepapa.govt.nz"
type="cite">
<meta http-equiv="Content-Type" content="text/html; ">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
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;}
span.hoenzb
{mso-style-name:hoenzb;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@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]-->
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);">Thank
you all for your feedback.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);">I
am hopeful there will eventually be a ‘standard’ vocabulary for the DwC
associations. In the meantime it looks like DSW will suit us the best.
dwcFP is quite loose (and having version numbers in the IRI means the
namespace has broken once already). BCO is quite bewildering – I like
the solidity of underlying OBO framework, but BCO has a steep learning
curve and doesn’t seem to tie into well-known LD ontologies.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);">The
downside of DSW for us is the extra abstract Occurrence and Organism
entities. We basically hold specimens from field collection events
that we identify – that is the data in our collection management
system, so the other entities would just be fabricated for data
exchange (not because we specifically model or store them).<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);">I
have mocked up a herbaria record starting from the specimen point of
view (the core things that we hold in our collections). This is
attached as turtle and also our original JSON-LD (converted at <a
moz-do-not-send="true" href="http://json-ld.org/playground/">
http://json-ld.org/playground/</a> ).<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);">*I
had to go to Occurrence directly from the Specimen/Token using
dsw:evidenceFor (rather than via Organism and dsw:hasOccurence) as it
may not have been identified - meaning it would be impossible to create
an Organism entity. And in fact we will not create Organism entities as
we don’t need them in our context.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);">*
The Occurrence is just a placeholder (since we don’t have data for it),
which means I have associated the Agent to the Event rather than the
Occurrence – it so happens that this is valid as the domain isn’t
specified in dwciri:recordedBy.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);">*I
have include properties of linked-to entities because we need them
populated as part of the web API for searching, etc. This is similar
to the DwC concept of convenience properties.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);">*
There’s a few other messy parts like what IRIs we will create for the
Occurrence and Identification entities.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);">I’d
be interested in any comments about whether this is on the right track
and/or would be considered conformant DwC RDF </span><span
style="font-size: 11pt; font-family: Wingdings; color: rgb(31, 73, 125);">J</span><span
style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);"><o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);">Cheers,<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);">Douglas<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span
style="font-size: 10pt; font-family: "Tahoma","sans-serif";"
lang="EN-US">From:</span></b><span
style="font-size: 10pt; font-family: "Tahoma","sans-serif";"
lang="EN-US"> tdwg-content
[<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="mailto:tdwg-content-bounces@lists.tdwg.org">mailto:tdwg-content-bounces@lists.tdwg.org</a>]
<b>On Behalf Of </b>John Deck<br>
<b>Sent:</b> Thursday, 18 August 2016 4:02 a.m.<br>
<b>To:</b> <a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:tdwg-content@lists.tdwg.org">tdwg-content@lists.tdwg.org</a><br>
<b>Subject:</b> Re: [tdwg-content] Implementing Darwin Core in RDF<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Another angle to consider here is using the
Biological Collections Ontology (<a moz-do-not-send="true"
href="https://github.com/BiodiversityOntologies/bco">https://github.com/BiodiversityOntologies/bco</a>),
which is part of the OBO Foundry framework (<a moz-do-not-send="true"
href="http://www.obofoundry.org/">http://www.obofoundry.org/</a>), and
for which development and work has been done in integrating with Darwin
Core and Audubon Core (e.g. <a moz-do-not-send="true"
href="http://www.ncbi.nlm.nih.gov/pmc/articles/PMC4511409/">http://www.ncbi.nlm.nih.gov/pmc/articles/PMC4511409/</a>).
The OBO community has a longer history with the biomedical community
but gaining traction in biodiversity. Since these are all ontologies,
there should be less confusion on the meaning of classes. For example,
the notion of Observation in DwC is broken down into at least some of
the following classes: "Observing process", "Material target of
observation", "Material target of observation role". Relations are
well specified as well and drawn from the Relations Ontology (<a
moz-do-not-send="true"
href="http://www.obofoundry.org/ontology/ro.html">http://www.obofoundry.org/ontology/ro.html</a>).
BTW, along with the PPO (plant phenology ontology -- <a
moz-do-not-send="true" href="https://github.com/PlantPhenoOntology/PPO">https://github.com/PlantPhenoOntology/PPO</a>)
team, i'm working on annotating instance data with BCO and PPO now, an
ongoing project and we will have more information on this effort at the
upcoming TDWG meeting. Happy to answer additional questions you have.<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">John Deck<o:p></o:p></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Wed, Aug 17, 2016 at 7:59 AM, Paul J. Morris
<<a moz-do-not-send="true" href="mailto:mole@morris.net"
target="_blank">mole@morris.net</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal">While commenting on the RDF guide, I wrote
implementations of delivery<br>
of flat Darwin Core in RDF into Symbiota and the Harvard University<br>
Herbaria web search using content negotiation. Symbiota, when an<br>
occurrence (or agent record) is requested with an accept header of<br>
text/turtle; will deliver the occurrence record in a turtle<br>
serialization (an example is below), when requested with an accept<br>
header of application/rdf+xml will return flat Darwin Core in RDF/XML<br>
<br>
For structured relations beyond flat Darwin Core, there is another<br>
alternative to darwin-sw (which is also in use in the wild), dwcFP:<br>
<a moz-do-not-send="true"
href="http://filteredpush.org/ontologies/FP/2.0/dwcFP.owl"
target="_blank">http://filteredpush.org/ontologies/FP/2.0/dwcFP.owl</a>
Bob Morris can<br>
probably comment further, but one of the design goals of dwcFP was<br>
fewer added inferences than darwin-sw (object properties have ranges<br>
specified, but not domains).<br>
<br>
dwcFP defines a set of object properties for making relations between<br>
core Darwin Core classes that we've been using in annotations:<br>
<br>
owl:ObjectProperty rdf:about="dwcFP:hasIdentification"<br>
owl:ObjectProperty rdf:about="dwcFP:usesTaxon"<br>
owl:ObjectProperty rdf:about="dwcFP:hasCollectingEvent"<br>
owl:ObjectProperty rdf:about="dwcFP:hasLocality"<br>
owl:ObjectProperty rdf:about="dwcFP:hasGeologicalContext"<br>
owl:ObjectProperty rdf:about="dwcFP:hasGeoreference"<br>
owl:ObjectProperty rdf:about="dwcFP:hasAssociatedMedia"<br>
<br>
One object property we added specifically to simplyfy SPARQL queries on<br>
taxonomic trees:<br>
<br>
owl:ObjectProperty rdf:about="dwcFP:descendantTaxonOf"<br>
<br>
And additional object properties that cover more possible relations:<br>
<br>
owl:ObjectProperty rdf:about="dwcFP:relationProperty"<br>
owl:ObjectProperty rdf:about="dwcFP:hasAcceptedNameUsage"<br>
owl:ObjectProperty rdf:about="dwcFP:namePublishedIn"<br>
owl:ObjectProperty rdf:about="dwcFP:hasOriginalNameUsage"<br>
owl:ObjectProperty rdf:about="dwcFP:hasParentNameUsage"<br>
owl:ObjectProperty rdf:about="dwcFP:hasScientificName"<br>
owl:ObjectProperty rdf:about="dwcFP:hasTaxonConcept"<br>
owl:ObjectProperty rdf:about="dwcFP:taxonomicAuthorityFor"<br>
owl:ObjectProperty rdf:about="dwcFP:nomenclaturalCode"<br>
owl:ObjectProperty rdf:about="dwcFP:nomenclaturalStatus"<br>
<br>
Attached is an example RDF document (which is a commented extract from<br>
the body of an annotation in a new occurrence annotation document)<br>
that describes an occurrence. There were about 350,000 such occurrence<br>
records wrapped in annotations generated in the NEVP project. This<br>
representation preceeded the Darwin Core RDF guide, and I've added a<br>
couple of comments about things we would do differently now.<br>
<br>
In using dwcFP, we encountered the same kind of questions you are<br>
raising about where to place datatype properties that might go in more<br>
than one place. We ended up hanging dwc:scientificName,<br>
dwc:scientificNameAuthorship, etc, off of the Identification, and then<br>
a Taxon (through dwcFP:usesTaxon) off the Identification, with only a<br>
guid hung off the Taxon. Bob can probably comment further, but I think<br>
our motivation for this was that the new occurrence annotation<br>
documents are intended to describe transcription of data off of<br>
specimens (and container (herbarium sheet and folder)), and that<br>
conceptually these scientfic names were properties of transcriptions of<br>
identifications. If I recall correctly, we are doing the opposite in<br>
new identification annotations (hanging dwc:scientificName off of a<br>
Taxon instance).<br>
<br>
-Paul<br>
<br>
--<br>
<br>
Example flat Darwin Core occurrence record as RDF produced by Symbiota:<br>
<br>
<a moz-do-not-send="true"
href="http://symbiota4.acis.ufl.edu/scan/portal/collections/individual/index.php?occid=16950169&clid=0"
target="_blank">http://symbiota4.acis.ufl.edu/scan/portal/collections/individual/index.php?occid=16950169&clid=0</a><br>
with<br>
HTTP Accept (through, for example, the Modify Headers firefox plugin):<br>
text/turtle;q=1.0,text/xml,application/xml,application/xhtml+xml,text/html;<br>
q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5<br>
<br>
Delivers:<br>
<br>
@prefix rdf: <<a moz-do-not-send="true"
href="http://www.w3.org/1999/02/22-rdf-syntax-ns" target="_blank">http://www.w3.org/1999/02/22-rdf-syntax-ns#</a>>
.<br>
@prefix rdfs: <<a moz-do-not-send="true"
href="http://www.w3.org/2000/01/rdf-schema" target="_blank">http://www.w3.org/2000/01/rdf-schema#</a>>
.<br>
@prefix owl: <<a moz-do-not-send="true"
href="http://www.w3.org/2002/07/owl" target="_blank">http://www.w3.org/2002/07/owl#</a>>
.<br>
@prefix foaf: <<a moz-do-not-send="true"
href="http://xmlns.com/foaf/0.1/" target="_blank">http://xmlns.com/foaf/0.1/</a>>
.<br>
@prefix dwc: <<a moz-do-not-send="true"
href="http://rs.tdwg.org/dwc/terms/" target="_blank">http://rs.tdwg.org/dwc/terms/</a>>
.<br>
@prefix dwciri: <<a moz-do-not-send="true"
href="http://rs.tdwg.org/dwc/iri/" target="_blank">http://rs.tdwg.org/dwc/iri/</a>>
.<br>
@prefix dc: <<a moz-do-not-send="true"
href="http://purl.org/dc/elements/1.1/" target="_blank">http://purl.org/dc/elements/1.1/</a>>
.<br>
@prefix dcterms: <<a moz-do-not-send="true"
href="http://purl.org/dc/terms/" target="_blank">http://purl.org/dc/terms/</a>>
.<br>
@prefix dcmitype: <<a moz-do-not-send="true"
href="http://purl.org/dc/dcmitype/" target="_blank">http://purl.org/dc/dcmitype/</a>>
.<br>
<urn:uuid:00032bdf-8862-4ca1-b8a6-ba35ee59f56a><br>
a dwc:Occurrence ;<br>
dwc:institutionCode "ASNP" ;<br>
dwc:collectionCode "ENT" ;<br>
dwciri:inCollection<br>
<urn:uuid:af7140c3-4aa2-41ac-b3e9-4c7415b3ce90> ; a<br>
dcmitype:PhysicalObject ; dwc:basisOfRecord "PreservedSpecimen" ;<br>
dwc:catalogNumber "735" ;<br>
dwc:kingdom "Animalia" ;<br>
dwc:phylum "Arthropoda" ;<br>
dwc:class "Insecta" ;<br>
dwc:order "Hemiptera" ;<br>
dwc:family "Miridae" ;<br>
dwc:scientificName "Phytocoris" ;<br>
dwc:scientificNameAuthorship "Fallén, 1814" ;<br>
dwc:genus "Phytocoris" ;<br>
dwc:identifiedBy "G. W. Cowper 2008" ;<br>
dwc:recordedBy "G. W. Cowper" ;<br>
dwc:eventDate "2008-10-18" ;<br>
dwc:year "2008" ;<br>
dwc:month "10" ;<br>
dwc:day "18" ;<br>
dwc:startDayOfYear "292" ;<br>
dwc:fieldNumber "-" ;<br>
dwc:individualCount "1" ;<br>
dwc:preparations "Academy Drawer" ;<br>
dwc:country "United States" ;<br>
dwc:stateProvince "New Jersey" ;<br>
dwc:county "Burlington" ;<br>
dwc:municipality "Woodland" ;<br>
dwc:locality "SW of Chatsworth Beat Pinus along sandy road in<br>
upland pine & oak woodland.; 1 individual(s) collected; Way Point<br>
[-]" ; dwc:decimalLatitude "39.806067" ; dwc:decimalLongitude<br>
"-74.545333" ; dwc:verbatimCoordinates "N+39º48.364' W-074º32.720'" ;<br>
dwc:disposition "ANSP" ;<br>
dcterms:modified "2015-04-25 17:13:22" ;<br>
dcterms:license <<a moz-do-not-send="true"
href="http://creativecommons.org/licenses/by-nc/3.0/" target="_blank">http://creativecommons.org/licenses/by-nc/3.0/</a>>
;<br>
dcterms:rightsHolder <Academy of Natural Sciences> ;<br>
dcterms:accessRights "CC BY-NC (Attribution-Non-Commercial)" ;<br>
dcterms:references<br>
"<a moz-do-not-send="true"
href="http://symbiota4.acis.ufl.edu/scan/portal/collections/individual/index.php?occid=16950169"
target="_blank">http://symbiota4.acis.ufl.edu/scan/portal/collections/individual/index.php?occid=16950169</a>".<br>
<br>
On Wed, 17 Aug 2016 06:02:01 +0000<br>
Douglas Campbell <<a moz-do-not-send="true"
href="mailto:Douglas.Campbell@tepapa.govt.nz">Douglas.Campbell@tepapa.govt.nz</a>>
wrote:<br>
<br>
> Thanks for taking the time to bring me up to speed, Steve.<br>
><br>
> I'm familiar with the complexities of preparing specifications and<br>
> realise I've come in mid-way. I'll spend some time reading up on
the<br>
> containers and occurrences history. But I'm unclear whether it is<br>
> better to use DSW terms in anticipation of them having longevity,
or<br>
> just to mint our own in the meantime?<br>
><br>
> For the taxon convenience fields...<br>
><br>
> I thought I read in the DwC RDF schema that properties like
taxonRank<br>
> were in the Taxon class (so using them in Identification conflicts<br>
> with their definition), but looking again I see that the spec uses<br>
> "dwcattributes:organizedInClass" which specifically does not imply<br>
> domain or range. So now I'm at peace with that. :)<br>
><br>
> However, I am pointing to our own RDF versions of taxon<br>
> classification terms that we use, and using DwC properties to
define<br>
> these taxon terms, plus I am combing these all together in a single<br>
> JSON-LD API result. So at this point I don't think I need to
repeat<br>
> the convenience properties in Identification (as they are available<br>
> directly in the Taxon object). While this seems to fit our
purpose I<br>
> can see that this may be sub-optimal for others who download the
data<br>
> and use it separately - I'll need to contemplate that scenario some<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">> more.<br>
><br>
> Cheers,<br>
> Douglas<br>
><br>
><br>
> From: Steve Baskauf [mailto:<a moz-do-not-send="true"
href="mailto:steve.baskauf@Vanderbilt.Edu">steve.baskauf@Vanderbilt.Edu</a>]<br>
> Sent: Wednesday, 17 August 2016 6:32 a.m.<br>
> To: Douglas Campbell<br>
> Cc: <a moz-do-not-send="true"
href="mailto:tdwg-content@lists.tdwg.org">tdwg-content@lists.tdwg.org</a><br>
> Subject: Re: [tdwg-content] Implementing Darwin Core in RDF<br>
><br>
> Douglas,<br>
> I was the lead author on the DwC RDF Guide, so I can try to answer<br>
> your questions about it. The TDWG RDF Task Group is still in<br>
> operation, although it hasn't been very active for the past several<br>
> years. The RDG TG has an online "home" at the TDWG Github site.[1]<br>
> However, the content didn't survive the migration from Google Code<br>
> very well, so it takes some effort at this point to sort through
it.<br>
> The TG also has an email list [2] but there has been little traffic<br>
> on it recently.<br>
><br>
> *Dereferencing of the DwC IRI namespace* - Unfortunately, the
dwciri:<br>
> namespace terms don't dereference at the present time. This needs
to<br>
> be corrected. I've created a Turtle serialization [3] of how I
think<br>
> the RDF should be written for the dwciri: terms, but it isn't
served<br>
> when one attempts to dereference the terms and hasn't been<br>
> incorporated into the official DwC repository. Part of the problem<br>
> here is that the guidelines for documenting terms in
machine-readable<br>
> form are still going through the adoption process.[4] I'm hopeful<br>
> that when the Documentation Specification is ratified, we can make<br>
> sure that all existing DwC terms dereference in a consistent
manner.<br>
><br>
> *Best practice for connecting containers together* - By this, I'm<br>
> assuming you mean linking instances of the various Darwin Core<br>
> classes, or in RDF terms, linking nodes. The RDF Guide is silent
on<br>
> how to do this. That's not great from the standpoint of actually<br>
> turning Darwin Core records into RDF, but it was a way to complete<br>
> the guide in a finite amount of time. What is missing is a
consensus<br>
> domain model that would lay out how instances of the Darwin Core<br>
> classes would be linked. Such a model should be developed, but
that<br>
> has not yet happened. Again, there is a draft standard submitted
for<br>
> review [5], which if adopted will specify (in Section 4) a process<br>
> for developing such a model. When we wrote the RDF Guide, we<br>
> provided ancillary documents [6], which included examples that<br>
> followed the RDF Guide and linked instances using various proposed<br>
> models. There are links to web pages containing examples using<br>
> TaxonConcept, BiSciCol, and Darwin-SW object properties to link
class<br>
> instances. I am not sure whether there is any RDF "in the wild"
for<br>
> the first two examples. I'm more familiar with Darwin-SW, as I was<br>
> involved in its development [7]. There is a Semantic Web Journal<br>
> article about Darwin-SW [8], so I won't go into detail about it
here,<br>
> except to say that its data model was developed following an<br>
> extensive discussion on the tdwg-content email list [9] about how<br>
> members of the community understood the Darwin Core classes. The<br>
> relationship between Darwin-SW model and the historical 1993 ACS<br>
> Model can be viewed at [10]. There are a bit over a million
triples<br>
> of data "in the wild" modeled on Darwin-SW in accordance with the
DwC<br>
> RDF guide, accessible at a SPARQL end point. [11] Some examples<br>
> showing how to play around with SPARQL queries of these data are at<br>
> [12].<br>
><br>
> *The overlapping scope of Occurrence and Specimen types* - There
is a<br>
> long history behind the meaning of "Occurrence". There is an<br>
> out-of-date-summary of some of the discussion around this topic in<br>
> the Darwin-SW documentation [13]. I think that at the time when<br>
> Darwin Core was originally adopted, an Occurrence was considered a<br>
> sort of superclass of the Specimen and Observation classes.
However,<br>
> after a lot of discussion, the meaning of dwc:Occurrence was<br>
> clarified by changing it to its current definition: "An existence
of<br>
> an Organism (sensu <a moz-do-not-send="true"
href="http://rs.tdwg.org/dwc/terms/Organism" target="_blank">
http://rs.tdwg.org/dwc/terms/Organism</a>) at a<br>
> particular place at a particular time." In this view, an
Occurrence<br>
> isn't a concrete thing like a Specimen - it's more like a database<br>
> join between an Event instance (time and place) and an Organism,<br>
> which allows for a one-to-many relationship between a Organism and<br>
> Occurrences, and a one-to-many relationships between an Event and<br>
> Occurrences. It also allows for a single occurrence of an organism<br>
> at a time and place to be documented by one-to-many forms of<br>
> evidence, which could include PreservedSpecimens, HumanObservation<br>
> data, or images of various sorts. In RDF terms, an Occurrence
could<br>
> be thought of as a node that is linked to Event, Organism, and<br>
> evidence instances nodes. You can see this represented graphically<br>
> at [7], where "dsw:Token" refers to a generic class for evidence.
In<br>
> any case, separating Occurrence (as a node linking Events to<br>
> Organisms) from Specimen allows an Occurrence to be documented by
one<br>
> to many instances of any kind of evidence, or even multiple kinds
of<br>
> evidence. For example, an Occurrence could be documented by a<br>
> PhysicalSpecimen as well as several images. Here is an example of
an<br>
> organism with two Occurrences:<br>
> <a moz-do-not-send="true"
href="http://bioimages.vanderbilt.edu/org-jorgem/rec13_0004"
target="_blank">
http://bioimages.vanderbilt.edu/org-jorgem/rec13_0004</a> The first<br>
> occurrence on 2013-07-24 was documented by 42 camera trap images,
and<br>
> the second occurrence on 2013-07-25 was documented by 21 camera
trap<br>
> images. You can see how this was represented in RDF at [14]. In<br>
> most cases, specimen records will be much simpler than this, with
one<br>
> organism, documented at one occurrence, with evidence of one<br>
> PreservedSpecimen. Such a simpler case could be represented with a<br>
> simpler model. But the more complex model allows specimen-derived<br>
> occurrence records to be merged with other kinds of occurrence<br>
> records, such as the camera trap example I gave, mark-recapture
bird<br>
> banding observations, iNaturalist occurrences documented by photos
of<br>
> the organism, etc.<br>
><br>
> *Conflicting usage of Taxon fields in the Identification object* -
In<br>
> order to explain the rationale behind why what seem to be<br>
> taxon-related properties are assigned to Identification instances,
I<br>
> must refer to the idea of "convenience terms" as expressed in
Section<br>
> 2.7 of the RDF Guide.[15] In a perfect world, we would have the<br>
> following:<br>
><br>
> a collection item linked by dwciri:inCollection to an
IRI-identified<br>
> collection an identification instance linked by dwciri:toTaxon to
an<br>
> IRI-identified taxon (a.k.a. taxon concept) a location instance<br>
> linked by dwciri:inDescribedPlace to an IRI-identified geographic<br>
> place (a.k.a. "feature")<br>
><br>
> If the linked IRI-identified object resources were described by
RDF,<br>
> it would not be necessary to include any of the Darwin Core<br>
> "convenience" properties included in Table 3.5 [16]. The
information<br>
> contained in the values of those properties could be discovered by<br>
> dereferencing the object IRIs and traversing subsequent links from<br>
> that RDF. However, if those IRIs don't exist, then the convenience<br>
> properties provide a string-based mechanism to relate the subject<br>
> resource to other resources that should be linked to the same<br>
> (unidentified) object resource. So for example, if we say a
specimen<br>
> 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<br>
> and that "MVZ" is the institution code of the specimen. Rather, we<br>
> mean that the specimen should be linked to a collection (with
unknown<br>
> IRI) whose code is MVZ and whose owning institution has the code<br>
> "MVZ". Similarly, if we say that an identification has the<br>
> 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<br>
> identification and that "Hersiliiadae" is the genus of the<br>
> identification. Rather, we mean that the identification should be<br>
> linked to a taxon (with unknown IRI) for which the specificEpithet<br>
> part of its name string is "yaeyamaensis", which is included in the<br>
> genus "Hersiliiadae". This may seem odd, particularly if you are<br>
> used to thinking of genus and specific epithet as properties of a<br>
> taxon. But the sets of DwC convenience properties are intended to
be<br>
> a temporary, string-based way to describe an unidentified resource
to<br>
> which the subject resource should be linked. At some future time,
if<br>
> IRIs can be discovered, those sets of convenience properties might
be<br>
> dropped if dereferencing the IRIs provides the same information.
In<br>
> these examples, one might replace with:<br>
><br>
> a collection item linked by dwciri:inCollection to<br>
> <a moz-do-not-send="true" href="http://grbio.org/cool/0rht-pj95"
target="_blank">http://grbio.org/cool/0rht-pj95</a> an identification
instance linked to<br>
> <a moz-do-not-send="true"
href="http://zoobank.org/75C9EA16-72B1-44C9-AD40-3C3D41323AB9"
target="_blank">
http://zoobank.org/75C9EA16-72B1-44C9-AD40-3C3D41323AB9</a><br>
><br>
> although I don't think either of these IRIs currently dereference
to<br>
> meaningful machine-readable RDF (although they have human-readable<br>
> web pages).<br>
><br>
> I hope that this has provided you with some answers, or at least a<br>
> starting point for additional exploration or questions. Please
feel<br>
> free to reply if there were parts of what I wrote that weren't
clear.<br>
><br>
> Steve Baskauf<br>
><br>
> [1] <a moz-do-not-send="true" href="https://github.com/tdwg/rdf"
target="_blank">https://github.com/tdwg/rdf</a><br>
> [2] <a moz-do-not-send="true"
href="http://groups.google.com/group/tdwg-rdf" target="_blank">http://groups.google.com/group/tdwg-rdf</a><br>
> [3]<br>
> <a moz-do-not-send="true"
href="https://github.com/tdwg/vocab/blob/master/code-examples/darwin-core/dwciri.ttl"
target="_blank">
https://github.com/tdwg/vocab/blob/master/code-examples/darwin-core/dwciri.ttl</a><br>
> [4]<br>
> <a moz-do-not-send="true"
href="https://github.com/tdwg/vocab/blob/master/documentation-specification.md"
target="_blank">
https://github.com/tdwg/vocab/blob/master/documentation-specification.md</a><br>
> [5]<br>
> <a moz-do-not-send="true"
href="https://github.com/tdwg/vocab/blob/master/maintenance-specification.md"
target="_blank">
https://github.com/tdwg/vocab/blob/master/maintenance-specification.md</a><br>
> [6] <a moz-do-not-send="true"
href="https://github.com/tdwg/rdf/blob/master/DwCAncillary.md"
target="_blank">
https://github.com/tdwg/rdf/blob/master/DwCAncillary.md</a> [7]<br>
> <a moz-do-not-send="true" href="https://github.com/darwin-sw/dsw"
target="_blank">https://github.com/darwin-sw/dsw</a> [8]<br>
> <a moz-do-not-send="true"
href="http://www.semantic-web-journal.net/content/darwin-sw-darwin-core-based-terms-expressing-biodiversity-data-rdf-1"
target="_blank">
http://www.semantic-web-journal.net/content/darwin-sw-darwin-core-based-terms-expressing-biodiversity-data-rdf-1</a><br>
> [9] <a moz-do-not-send="true"
href="https://github.com/darwin-sw/dsw/wiki/TdwgContentEmailSummary"
target="_blank">
https://github.com/darwin-sw/dsw/wiki/TdwgContentEmailSummary</a><br>
> [10]<br>
> <a moz-do-not-send="true"
href="https://github.com/darwin-sw/dsw/blob/master/img/acs-dsw-poster.pptx"
target="_blank">
https://github.com/darwin-sw/dsw/blob/master/img/acs-dsw-poster.pptx</a><br>
> [11] <a moz-do-not-send="true"
href="http://rdf.library.vanderbilt.edu/sparql?view" target="_blank">http://rdf.library.vanderbilt.edu/sparql?view</a>
[12]<br>
> <a moz-do-not-send="true"
href="https://github.com/HeardLibrary/semantic-web/blob/master/learning-sparql/learning-sparql-ch3-part2-answers.md"
target="_blank">
https://github.com/HeardLibrary/semantic-web/blob/master/learning-sparql/learning-sparql-ch3-part2-answers.md</a><br>
> [13] <a moz-do-not-send="true"
href="https://github.com/darwin-sw/dsw/wiki/ClassOccurrence"
target="_blank">
https://github.com/darwin-sw/dsw/wiki/ClassOccurrence</a> [14]<br>
> <a moz-do-not-send="true"
href="http://bioimages.vanderbilt.edu/org-jorgem/rec13_0004.rdf"
target="_blank">
http://bioimages.vanderbilt.edu/org-jorgem/rec13_0004.rdf</a> [15]<br>
> <a moz-do-not-send="true"
href="http://rs.tdwg.org/dwc/terms/guides/rdf/index.htm#2.7_Darwin_Core_convenience_terms"
target="_blank">
http://rs.tdwg.org/dwc/terms/guides/rdf/index.htm#2.7_Darwin_Core_convenience_terms</a><br>
> [16]<br>
> <a moz-do-not-send="true"
href="http://rs.tdwg.org/dwc/terms/guides/rdf/index.htm#3.5_Darwin_Core_convenience_terms_that_are_expected_to_be_used_o"
target="_blank">
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>
><br>
><br>
> Douglas Campbell wrote:<br>
> Hi all,<br>
><br>
> I am implementing Darwin Core in RDF as part of our API at Te Papa<br>
> (Museum of New Zealand). My aim is to map our specimen metadata to<br>
> rich Darwin Core RDF using JSON-LD, then 'dumb down' to Simple
Darwin<br>
> Core to contribute to virtual herbariums. I have mocked-up some<br>
> records, however there are some areas where I'm not quite sure how
to<br>
> interpret the Darwin Core RDF Guide.<br>
><br>
> The areas of confusion I have include:<br>
> * Best practice for connecting containers together<br>
> * Dereferencing of the DwC IRI namespace<br>
> * The overlapping scope of the Occurrence and Specimen types<br>
> * Conflicting usage of Taxon fields in the Identification object.<br>
><br>
> I'm hoping for suggestions:<br>
> 1. Are there any implementations of DwC RDF data online that I
could<br>
> look at as examples to follow? 2. What/to whom is the best way to
ask<br>
> specific questions about DwC RDF?<br>
><br>
> At this stage our API prototype is only available internally but<br>
> there is some documentation available publicly at:<br>
> <a moz-do-not-send="true"
href="https://github.com/te-papa/collections-api/wiki" target="_blank">https://github.com/te-papa/collections-api/wiki</a><br>
><br>
> Thanks in advance,<br>
> Douglas<br>
><br>
> Douglas Campbell<br>
> Business Analyst<br>
> Collections Information Services<br>
> Museum of New Zealand Te Papa Tongarewa<br>
><br>
> ________________________________<br>
><br>
> Visit the Te Papa website <a moz-do-not-send="true"
href="http://www.tepapa.govt.nz" target="_blank">http://www.tepapa.govt.nz</a><br>
> The email message together with the accompanying attachments may be<br>
> CONFIDENTIAL. If you have received this message in error, please<br>
> notify <a moz-do-not-send="true"
href="https://www.tepapa.govt.nz/about/contact-us/general-enquiries"
target="_blank">
https://www.tepapa.govt.nz/about/contact-us/general-enquiries</a><br>
> immediately and delete the original message. The views expressed in<br>
> this message are those of the individual sender, except where the<br>
> sender specifically states them to be views of Te Papa. Te Papa<br>
> employs strict virus checking measures and accepts no liability for<br>
> any loss caused either directly or indirectly by a virus arising
from<br>
> the use of this message or any attached file.<br>
><br>
> ________________________________<br>
> This email has been filtered by SMX. For more information visit<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="margin-bottom: 12pt;">> <a
moz-do-not-send="true" href="http://smxemail.com" target="_blank">
smxemail.com</a><<a moz-do-not-send="true"
href="http://smxemail.com/" target="_blank">http://smxemail.com/</a>><br>
><br>
><br>
><br>
> --<br>
><br>
> Steven J. Baskauf, Ph.D., Senior Lecturer<br>
><br>
> Vanderbilt University Dept. of Biological Sciences<br>
><br>
><br>
><br>
> postal mail address:<br>
><br>
> PMB 351634<br>
><br>
> Nashville, TN 37235-1634, U.S.A.<br>
><br>
><br>
><br>
> delivery address:<br>
><br>
> 2125 Stevenson Center<br>
><br>
> 1161 21st Ave., S.<br>
><br>
> Nashville, TN 37235<br>
><br>
><br>
><br>
> office: 2128 Stevenson Center<br>
><br>
> phone: <a moz-do-not-send="true" href="tel:%28615%29%20343-4582">(615)
343-4582</a>, fax: <a moz-do-not-send="true"
href="tel:%28615%29%20322-4942">
(615) 322-4942</a><br>
><br>
> If you fax, please phone or email so that I will know to look for
it.<br>
><br>
> <a moz-do-not-send="true" href="http://bioimages.vanderbilt.edu"
target="_blank">http://bioimages.vanderbilt.edu</a><br>
><br>
> <a moz-do-not-send="true" href="http://vanderbilt.edu/trees"
target="_blank">http://vanderbilt.edu/trees</a><br>
><br>
><br>
><br>
>
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<br>
> Visit the Te Papa website <a moz-do-not-send="true"
href="http://www.tepapa.govt.nz" target="_blank">http://www.tepapa.govt.nz</a><br>
> The email message together with the accompanying attachments may be<br>
> CONFIDENTIAL. If you have received this message in error, please<br>
> notify <a moz-do-not-send="true"
href="https://www.tepapa.govt.nz/about/contact-us/general-enquiries"
target="_blank">
https://www.tepapa.govt.nz/about/contact-us/general-enquiries</a><br>
> immediately and delete the original message. The views expressed in<br>
> this message are those of the individual sender, except where the<br>
> sender specifically states them to be views of Te Papa. Te Papa<br>
> employs strict virus checking measures and accepts no liability for<br>
> any loss caused either directly or indirectly by a virus arising
from<br>
> the use of this message or any attached file.<br>
>
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<br>
><br>
>
______________________________________________________________________________<br>
><br>
> This email has been filtered by SMX.<br>
> For more information visit <a moz-do-not-send="true"
href="http://smxemail.com" target="_blank">http://smxemail.com</a><br>
>
______________________________________________________________________________<br>
><br>
<span style="color: rgb(136, 136, 136);"><br>
<br>
<span class="hoenzb">--</span><br>
<span class="hoenzb">Paul J. Morris</span><br>
<span class="hoenzb">Biodiversity Informatics Manager</span><br>
<span class="hoenzb">Museum of Comparative Zoölogy, Harvard University</span><br>
<span class="hoenzb"><a moz-do-not-send="true"
href="mailto:mole@morris.net">mole@morris.net</a> AA3SD PGP public
key available</span><br>
</span><br>
_______________________________________________<br>
tdwg-content mailing list<br>
<a moz-do-not-send="true" href="mailto:tdwg-content@lists.tdwg.org">tdwg-content@lists.tdwg.org</a><br>
<a moz-do-not-send="true"
href="http://lists.tdwg.org/mailman/listinfo/tdwg-content"
target="_blank">http://lists.tdwg.org/mailman/listinfo/tdwg-content</a><o:p></o:p></p>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <o:p></o:p></p>
<div>
<div>
<div>
<p class="MsoNormal">John Deck<br>
(541) 914-4739<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
<p> </p>
<hr>
<p align="center">Visit the Te Papa website <a moz-do-not-send="true"
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
moz-do-not-send="true"
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>
<div>
<div
style="border-top: 1px solid black; border-bottom: 1px solid black; margin: 20px 0pt; padding: 10px 0pt; font-size: 9pt; font-family: Verdana,Arial,Helvetica,sans-serif;">This
email has been filtered by SMX. For more information visit <a
moz-do-not-send="true" href="http://smxemail.com/">smxemail.com</a></div>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Steven J. Baskauf, Ph.D., Senior Lecturer
Vanderbilt University Dept. of Biological Sciences
postal mail address:
PMB 351634
Nashville, TN 37235-1634, U.S.A.
delivery address:
2125 Stevenson Center
1161 21st Ave., S.
Nashville, TN 37235
office: 2128 Stevenson Center
phone: (615) 343-4582, fax: (615) 322-4942
If you fax, please phone or email so that I will know to look for it.
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://bioimages.vanderbilt.edu">http://bioimages.vanderbilt.edu</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://vanderbilt.edu/trees">http://vanderbilt.edu/trees</a>
</pre>
<br>
<pre class="moz-signature" cols="72">--
Steven J. Baskauf, Ph.D., Senior Lecturer
Vanderbilt University Dept. of Biological Sciences
postal mail address:
PMB 351634
Nashville, TN 37235-1634, U.S.A.
delivery address:
2125 Stevenson Center
1161 21st Ave., S.
Nashville, TN 37235
office: 2128 Stevenson Center
phone: (615) 343-4582, fax: (615) 322-4942
If you fax, please phone or email so that I will know to look for it.
<a class="moz-txt-link-freetext" href="http://bioimages.vanderbilt.edu">http://bioimages.vanderbilt.edu</a>
<a class="moz-txt-link-freetext" href="http://vanderbilt.edu/trees">http://vanderbilt.edu/trees</a>
</pre>
</body>
</html>