<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Thanks for sharing this, Paul. Is there a place where the 350000
occurrence records and their RDF can be accessed via the web, or a
SPARQL interface? <br>
<br>
One of the features of the draft Vocabulary Maintenance Specification
[1] is that it specifies that proposed enhancements to TDWG
vocabularies (such as the development of object properties connecting
DwC classes) should include a feature report and an implementation
experience report. For an enhancement such as this, the feature report
would probably include uses cases/competency questions that document
why the features of the enhancement were needed. The Implementation
Experience Report documents experience with independent implementations
where, among other things, implementers can report behavior when
features are tested with real data. <br>
<br>
Although we aren't actually proposing a particular enhancement here, we
have three attempts to develop object properties to link instances of
Darwin Core classes (Darwin-SW, dwcFP, and BCO), each with some
experience with using those properties with real data. As part of a
fairly recent email thread, Donald Hobern suggested [2] a series of
steps for enabling human and machine users to traverse data connections
to discover linked biodiversity resources. The second step was:
"Agreement on the set of core relationships between instances of these
classes that we consider important enough to standardise (specimen
identifiedAs taxon concept, taxon name publishedIn publication,
etc.)." This is essentially what we have been talking about in this
thread. If an attempt were made to reach this kind of agreement
(through a workshop, task group, etc.) it would be a useful preliminary
step to assemble from these efforts (Darwin-SW, dwcFP, BCO and any
others that exist) use cases/competency questions and reports on
implementation experience. This information would provide a good
starting point for the development of a consensus domain model. <br>
<br>
At one point, the RDF Task Group talked about maintaining some sort of
use case repository. I don't think that ever actually happened. But
now that the TDWG GitHub site is fully operational, maybe this is the
time to make that a reality.<br>
<br>
Steve<br>
<br>
[1]
<a class="moz-txt-link-freetext" href="https://github.com/tdwg/vocab/blob/master/maintenance-specification.md">https://github.com/tdwg/vocab/blob/master/maintenance-specification.md</a>
(Section 4)<br>
[2] <a class="moz-txt-link-freetext" href="http://lists.tdwg.org/pipermail/tdwg-content/2016-May/003614.html">http://lists.tdwg.org/pipermail/tdwg-content/2016-May/003614.html</a><br>
<br>
Paul J. Morris wrote:
<blockquote cite="mid:20160817105955.651c1ef6@morris.net" type="cite">
<pre wrap="">While commenting on the RDF guide, I wrote implementations of delivery
of flat Darwin Core in RDF into Symbiota and the Harvard University
Herbaria web search using content negotiation. Symbiota, when an
occurrence (or agent record) is requested with an accept header of
text/turtle; will deliver the occurrence record in a turtle
serialization (an example is below), when requested with an accept
header of application/rdf+xml will return flat Darwin Core in RDF/XML
For structured relations beyond flat Darwin Core, there is another
alternative to darwin-sw (which is also in use in the wild), dwcFP:
<a class="moz-txt-link-freetext" href="http://filteredpush.org/ontologies/FP/2.0/dwcFP.owl">http://filteredpush.org/ontologies/FP/2.0/dwcFP.owl</a> Bob Morris can
probably comment further, but one of the design goals of dwcFP was
fewer added inferences than darwin-sw (object properties have ranges
specified, but not domains).
dwcFP defines a set of object properties for making relations between
core Darwin Core classes that we've been using in annotations:
owl:ObjectProperty rdf:about="dwcFP:hasIdentification"
owl:ObjectProperty rdf:about="dwcFP:usesTaxon"
owl:ObjectProperty rdf:about="dwcFP:hasCollectingEvent"
owl:ObjectProperty rdf:about="dwcFP:hasLocality"
owl:ObjectProperty rdf:about="dwcFP:hasGeologicalContext"
owl:ObjectProperty rdf:about="dwcFP:hasGeoreference"
owl:ObjectProperty rdf:about="dwcFP:hasAssociatedMedia"
One object property we added specifically to simplyfy SPARQL queries on
taxonomic trees:
owl:ObjectProperty rdf:about="dwcFP:descendantTaxonOf"
And additional object properties that cover more possible relations:
owl:ObjectProperty rdf:about="dwcFP:relationProperty"
owl:ObjectProperty rdf:about="dwcFP:hasAcceptedNameUsage"
owl:ObjectProperty rdf:about="dwcFP:namePublishedIn"
owl:ObjectProperty rdf:about="dwcFP:hasOriginalNameUsage"
owl:ObjectProperty rdf:about="dwcFP:hasParentNameUsage"
owl:ObjectProperty rdf:about="dwcFP:hasScientificName"
owl:ObjectProperty rdf:about="dwcFP:hasTaxonConcept"
owl:ObjectProperty rdf:about="dwcFP:taxonomicAuthorityFor"
owl:ObjectProperty rdf:about="dwcFP:nomenclaturalCode"
owl:ObjectProperty rdf:about="dwcFP:nomenclaturalStatus"
Attached is an example RDF document (which is a commented extract from
the body of an annotation in a new occurrence annotation document)
that describes an occurrence. There were about 350,000 such occurrence
records wrapped in annotations generated in the NEVP project. This
representation preceeded the Darwin Core RDF guide, and I've added a
couple of comments about things we would do differently now.
In using dwcFP, we encountered the same kind of questions you are
raising about where to place datatype properties that might go in more
than one place. We ended up hanging dwc:scientificName,
dwc:scientificNameAuthorship, etc, off of the Identification, and then
a Taxon (through dwcFP:usesTaxon) off the Identification, with only a
guid hung off the Taxon. Bob can probably comment further, but I think
our motivation for this was that the new occurrence annotation
documents are intended to describe transcription of data off of
specimens (and container (herbarium sheet and folder)), and that
conceptually these scientfic names were properties of transcriptions of
identifications. If I recall correctly, we are doing the opposite in
new identification annotations (hanging dwc:scientificName off of a
Taxon instance).
-Paul
--
Example flat Darwin Core occurrence record as RDF produced by Symbiota:
<a class="moz-txt-link-freetext" href="http://symbiota4.acis.ufl.edu/scan/portal/collections/individual/index.php?occid=16950169&clid=0">http://symbiota4.acis.ufl.edu/scan/portal/collections/individual/index.php?occid=16950169&clid=0</a>
with
HTTP Accept (through, for example, the Modify Headers firefox plugin):
text/turtle;q=1.0,text/xml,application/xml,application/xhtml+xml,text/html;
q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Delivers:
@prefix rdf: <a class="moz-txt-link-rfc2396E" href="http://www.w3.org/1999/02/22-rdf-syntax-ns#"><http://www.w3.org/1999/02/22-rdf-syntax-ns#></a> .
@prefix rdfs: <a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2000/01/rdf-schema#"><http://www.w3.org/2000/01/rdf-schema#></a> .
@prefix owl: <a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2002/07/owl#"><http://www.w3.org/2002/07/owl#></a> .
@prefix foaf: <a class="moz-txt-link-rfc2396E" href="http://xmlns.com/foaf/0.1/"><http://xmlns.com/foaf/0.1/></a> .
@prefix dwc: <a class="moz-txt-link-rfc2396E" href="http://rs.tdwg.org/dwc/terms/"><http://rs.tdwg.org/dwc/terms/></a> .
@prefix dwciri: <a class="moz-txt-link-rfc2396E" href="http://rs.tdwg.org/dwc/iri/"><http://rs.tdwg.org/dwc/iri/></a> .
@prefix dc: <a class="moz-txt-link-rfc2396E" href="http://purl.org/dc/elements/1.1/"><http://purl.org/dc/elements/1.1/></a> .
@prefix dcterms: <a class="moz-txt-link-rfc2396E" href="http://purl.org/dc/terms/"><http://purl.org/dc/terms/></a> .
@prefix dcmitype: <a class="moz-txt-link-rfc2396E" href="http://purl.org/dc/dcmitype/"><http://purl.org/dc/dcmitype/></a> .
<urn:uuid:00032bdf-8862-4ca1-b8a6-ba35ee59f56a>
a dwc:Occurrence ;
dwc:institutionCode "ASNP" ;
dwc:collectionCode "ENT" ;
dwciri:inCollection
<urn:uuid:af7140c3-4aa2-41ac-b3e9-4c7415b3ce90> ; a
dcmitype:PhysicalObject ; dwc:basisOfRecord "PreservedSpecimen" ;
dwc:catalogNumber "735" ;
dwc:kingdom "Animalia" ;
dwc:phylum "Arthropoda" ;
dwc:class "Insecta" ;
dwc:order "Hemiptera" ;
dwc:family "Miridae" ;
dwc:scientificName "Phytocoris" ;
dwc:scientificNameAuthorship "Fallén, 1814" ;
dwc:genus "Phytocoris" ;
dwc:identifiedBy "G. W. Cowper 2008" ;
dwc:recordedBy "G. W. Cowper" ;
dwc:eventDate "2008-10-18" ;
dwc:year "2008" ;
dwc:month "10" ;
dwc:day "18" ;
dwc:startDayOfYear "292" ;
dwc:fieldNumber "-" ;
dwc:individualCount "1" ;
dwc:preparations "Academy Drawer" ;
dwc:country "United States" ;
dwc:stateProvince "New Jersey" ;
dwc:county "Burlington" ;
dwc:municipality "Woodland" ;
dwc:locality "SW of Chatsworth Beat Pinus along sandy road in
upland pine & oak woodland.; 1 individual(s) collected; Way Point
[-]" ; dwc:decimalLatitude "39.806067" ; dwc:decimalLongitude
"-74.545333" ; dwc:verbatimCoordinates "N+39º48.364' W-074º32.720'" ;
dwc:disposition "ANSP" ;
dcterms:modified "2015-04-25 17:13:22" ;
dcterms:license <a class="moz-txt-link-rfc2396E" href="http://creativecommons.org/licenses/by-nc/3.0/"><http://creativecommons.org/licenses/by-nc/3.0/></a> ;
dcterms:rightsHolder <Academy of Natural Sciences> ;
dcterms:accessRights "CC BY-NC (Attribution-Non-Commercial)" ;
dcterms:references
<a class="moz-txt-link-rfc2396E" href="http://symbiota4.acis.ufl.edu/scan/portal/collections/individual/index.php?occid=16950169">"http://symbiota4.acis.ufl.edu/scan/portal/collections/individual/index.php?occid=16950169"</a>.
On Wed, 17 Aug 2016 06:02:01 +0000
Douglas Campbell <a class="moz-txt-link-rfc2396E" href="mailto:Douglas.Campbell@tepapa.govt.nz"><Douglas.Campbell@tepapa.govt.nz></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Thanks for taking the time to bring me up to speed, Steve.
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?
For the taxon convenience fields...
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. :)
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.
Cheers,
Douglas
From: Steve Baskauf [<a class="moz-txt-link-freetext" href="mailto:steve.baskauf@Vanderbilt.Edu">mailto:steve.baskauf@Vanderbilt.Edu</a>]
Sent: Wednesday, 17 August 2016 6:32 a.m.
To: Douglas Campbell
Cc: <a class="moz-txt-link-abbreviated" href="mailto:tdwg-content@lists.tdwg.org">tdwg-content@lists.tdwg.org</a>
Subject: Re: [tdwg-content] Implementing Darwin Core in RDF
Douglas,
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.
*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.
*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].
*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 class="moz-txt-link-freetext" 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:
<a class="moz-txt-link-freetext" href="http://bioimages.vanderbilt.edu/org-jorgem/rec13_0004">http://bioimages.vanderbilt.edu/org-jorgem/rec13_0004</a> 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.
*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:
a collection item linked by dwciri:inCollection to an IRI-identified
collection an identification instance linked by dwciri:toTaxon to an
IRI-identified taxon (a.k.a. taxon concept) a location instance
linked by dwciri:inDescribedPlace to an IRI-identified geographic
place (a.k.a. "feature")
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
dwc:collectionCode="Mamm"
dwc:institutionCode ="MVZ"
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
dwc:genus="Hersiliiadae"
dwc:specificEpithet="yaeyamaensis"
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:
a collection item linked by dwciri:inCollection to
<a class="moz-txt-link-freetext" href="http://grbio.org/cool/0rht-pj95">http://grbio.org/cool/0rht-pj95</a> an identification instance linked to
<a class="moz-txt-link-freetext" href="http://zoobank.org/75C9EA16-72B1-44C9-AD40-3C3D41323AB9">http://zoobank.org/75C9EA16-72B1-44C9-AD40-3C3D41323AB9</a>
although I don't think either of these IRIs currently dereference to
meaningful machine-readable RDF (although they have human-readable
web pages).
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.
Steve Baskauf
[1] <a class="moz-txt-link-freetext" href="https://github.com/tdwg/rdf">https://github.com/tdwg/rdf</a>
[2] <a class="moz-txt-link-freetext" href="http://groups.google.com/group/tdwg-rdf">http://groups.google.com/group/tdwg-rdf</a>
[3]
<a class="moz-txt-link-freetext" 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>
[4]
<a class="moz-txt-link-freetext" href="https://github.com/tdwg/vocab/blob/master/documentation-specification.md">https://github.com/tdwg/vocab/blob/master/documentation-specification.md</a>
[5]
<a class="moz-txt-link-freetext" href="https://github.com/tdwg/vocab/blob/master/maintenance-specification.md">https://github.com/tdwg/vocab/blob/master/maintenance-specification.md</a>
[6] <a class="moz-txt-link-freetext" href="https://github.com/tdwg/rdf/blob/master/DwCAncillary.md">https://github.com/tdwg/rdf/blob/master/DwCAncillary.md</a> [7]
<a class="moz-txt-link-freetext" href="https://github.com/darwin-sw/dsw">https://github.com/darwin-sw/dsw</a> [8]
<a 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>
[9] <a class="moz-txt-link-freetext" href="https://github.com/darwin-sw/dsw/wiki/TdwgContentEmailSummary">https://github.com/darwin-sw/dsw/wiki/TdwgContentEmailSummary</a>
[10]
<a class="moz-txt-link-freetext" 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>
[11] <a class="moz-txt-link-freetext" href="http://rdf.library.vanderbilt.edu/sparql?view">http://rdf.library.vanderbilt.edu/sparql?view</a> [12]
<a class="moz-txt-link-freetext" 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>
[13] <a class="moz-txt-link-freetext" href="https://github.com/darwin-sw/dsw/wiki/ClassOccurrence">https://github.com/darwin-sw/dsw/wiki/ClassOccurrence</a> [14]
<a class="moz-txt-link-freetext" href="http://bioimages.vanderbilt.edu/org-jorgem/rec13_0004.rdf">http://bioimages.vanderbilt.edu/org-jorgem/rec13_0004.rdf</a> [15]
<a class="moz-txt-link-freetext" 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>
[16]
<a class="moz-txt-link-freetext" 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>
Douglas Campbell wrote:
Hi all,
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.
The areas of confusion I have include:
* Best practice for connecting containers together
* Dereferencing of the DwC IRI namespace
* The overlapping scope of the Occurrence and Specimen types
* Conflicting usage of Taxon fields in the Identification object.
I'm hoping for suggestions:
1. Are there any implementations of DwC RDF data online that I could
look at as examples to follow? 2. What/to whom is the best way to ask
specific questions about DwC RDF?
At this stage our API prototype is only available internally but
there is some documentation available publicly at:
<a class="moz-txt-link-freetext" href="https://github.com/te-papa/collections-api/wiki">https://github.com/te-papa/collections-api/wiki</a>
Thanks in advance,
Douglas
Douglas Campbell
Business Analyst
Collections Information Services
Museum of New Zealand Te Papa Tongarewa
________________________________
Visit the Te Papa website <a class="moz-txt-link-freetext" href="http://www.tepapa.govt.nz">http://www.tepapa.govt.nz</a>
The email message together with the accompanying attachments may be
CONFIDENTIAL. If you have received this message in error, please
notify <a class="moz-txt-link-freetext" 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.
________________________________
This email has been filtered by SMX. For more information visit
smxemail.com<a class="moz-txt-link-rfc2396E" href="http://smxemail.com/"><http://smxemail.com/></a>
--
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>
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Visit the Te Papa website <a class="moz-txt-link-freetext" href="http://www.tepapa.govt.nz">http://www.tepapa.govt.nz</a>
The email message together with the accompanying attachments may be
CONFIDENTIAL. If you have received this message in error, please
notify <a class="moz-txt-link-freetext" 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.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
______________________________________________________________________________
This email has been filtered by SMX.
For more information visit <a class="moz-txt-link-freetext" href="http://smxemail.com">http://smxemail.com</a>
______________________________________________________________________________
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</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 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>