<div dir="ltr">Catching up on some responses...<div><br></div><div>It's interesting, and I think encouraging, that I'm hearing responses that reprise many of the discussions we've had about this subject over the last 5 years or so. That suggests to me that we've pretty well plowed the ground and are well positioned to work out solutions, rather than continuing a hunt for use cases and edge cases.</div>
<div><br></div><div>The cascading number/letter schemes are, indeed, appealing. They give a direct visual guide to the physical hierarchy. But, as has been pointed out, they add complexity and a very real entry-point for human error. It's a matter of opinion (and we all know how strongly we hold such near-religious opinions :) but I lean towards a single, opaque, numerical identifier for each object, rather than a more-explicit, information-conveying string. The implication, of course, is that there's an information system that makes it easy and immediate to see the relationships of that ID to any/all other IDs in the collection. I'm sure I haven't seen as many seemed-like-a-good-idea-at-the-time complex ID schemes as Andy has seen, but even I've seen enough that I'm terribly disinclined to invent yet one more. (Ah, I see John Simmons has jumped in with that viewpoint, too, and very well put.)</div>
<div><br></div><div>Key to keep in mind here is that the idea I raised was precipitated by tracking objects (and derivatives), and is independent of taxonomic sorting (or subsorting). I may not have been clear about that initially. Some levels of subdivision may, indeed, be assigned taxon names at various ranks, but that's not directly related to tracking the things themselves. </div>
<div><br></div><div>And relative to some other comments — indeed you're all correct that it's not really a "mystery" why we have the schemes we have. Collections databases were, for obvious and justifiable reasons, usually derived directly from the pre-existing paper ledger schemes. But as Rob implies, we're now at a point where we're trying to expose the existence and nature of specimens across all collections in addition to tracking jars in one room. Schemes we come up with now should have that target in mind. </div>
<div><br></div><div>On that note, I think that what I'm thinking about is at once more focussed and more abstract than Rob's semantic ontology suggestions. More focussed in that it's directed to being a simple way of tracking objects as they move through the specimen curation pipeline. More abstract in that it's a simple directed graph, independent of semantics. </div>
<div><br></div><div>Having said that, I think that a collection object bookkeeping system based on a branching parent-child hierarchy can be:</div><div>1. Overlaid with potentially very useful semantics, ontology-based or otherwise, but can be used with no semantic implications if desired.</div>
<div>2. Used as an underlying scheme for global-scope assemblages of specimen information.</div><div><br></div><div>On #2, my assumption is that we're unlikely to use within-institution ID tags directly in a global context, if only because we can't discard all the existing numbering schemes that already have an object ID of "1234". However, if every object has a simple unique identifier within the institution, it seems very tractable to assign each of those objects a globally unique identifier for public exposure. If the in-house identifier is also globally unique, so much the better (but does suffer from the very-long-label problem that was pointed out). </div>
<div><br></div><div>It sounds as though Arctos has a pretty straightforward branching hierarchical scheme. </div><div><br></div><div>In Specify, as I understand it, not quite yet. Specify has:</div><div>- Containers — which unify all the parts of a common-base object (by the analogy that all the parts are in the same physical container). However, there is no way to represent the chain of derivation of parts.</div>
<div>- Relationships — seems fertile, as it's a joining table that makes directed connections between collection objects. I don't know what would need to be done to the UI to make this an easily-accessed way of creating object parent-child relationships and recalling the descendent and parent hierarchies. I don't think there's (currently) any way of propagating information from parent to child as a relationship is created (e.g. the child object automatically gets the same collecting-event information as its parent).</div>
<div>- Projects — like containers, unify all the bits of a common-base set, but isn't directed.</div><div>- Preps — predefined sub-parts of collection objects. These are limited to a single level of derivation and to predefined kinds of derivatives (though the predefined kinds are, of course, definable by the user).</div>
<div><br></div><div>It is, I think, important to be able to capture the chain of derivation. One example that is not at all abstract these days: We have DNA extracts that come from one leg of one individual from an unsorted lot. We also have environmental DNA extracts that come from the alcohol of the unsorted lot jar. While it's essential to know that those both derive from the same collecting event, it's also essential to know the particular parent of each of those DNA extracts.</div>
<div><br></div><div>So in Specify, maybe what I'm looking for could be built on top of "Relationships" (Hmph. Not surprising, in retrospect). There would need to be UI components that allow for:</div><div>- Easy visualization of an objects descendants and an object's parents.</div>
<div>- Easy child-creation based on a particular object as parent.</div><div>- Information propagation from parent to children.</div><div><br></div><div>The last piece of functionality is the part, I think, that will take some head-scratching and room-with-whiteboard-and-coffee time. Some information should propagate from parent to child (e.g. accession information, collecting event information). Some information must be assignable per-object (e.g. object type [unsorted lot, individual, DNA extract]). I can see (at least) two approaches to doing that. </div>
<div><br></div><div>A "soft" approach copies a set of fields from the parent object to the newly-created child at the time of child creation (and of course also creates the child->parent pointer). After that, it's up to the database user to maintain consistency So, if someone corrects an erroneous link to the wrong collecting event in a parent record, she also needs to find and fix that field in all the children.</div>
<div><br></div><div>A "hard" approach has coded logic that pushes corrections like that down the ordered chain to all the children. Care would need to be taken to pick and choose which fields to overwrite.</div>
<div><br></div><div>A possible intermediate could be an "advisory" approach that, on a change to a parent, recommends a set of changes to the user that should be propagated (but it's his responsibility to do so, or choose not to). </div>
<div><br></div><div>It would also seem advisable to have code that does a consistency audit to find potential bogosities (e.g. someone forced a collecting-event change on a child but not on the parent). </div><div><br></div>
<div><br></div><div>Damn. I'll shut up now. </div><div><br></div><div>For a little while...</div></div><div class="gmail_extra"><br clear="all"><div>-Dean<br>-- <br>Dean Pentcheff<br><a href="mailto:pentcheff@gmail.com">pentcheff@gmail.com</a><br>
<a href="mailto:dpentche@nhm.org">dpentche@nhm.org</a></div>
<br><br><div class="gmail_quote">On Thu, Aug 14, 2014 at 9:58 AM, DLMcDonald <span dir="ltr"><<a href="mailto:dlmcdonald@alaska.edu" target="_blank">dlmcdonald@alaska.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><div>Arctos has two relevant object types:<br><br>1) <a href="http://arctosdb.org/documentation/catalog/" target="_blank">Cataloged Items</a> are what a Curator says they are: <a href="http://arctos.database.museum/guid/UAM:Mamm:19268" target="_blank">Individuals</a>, <a href="http://arctos.database.museum/guid/CUMV:Fish:11005" target="_blank">lots</a>, a <a href="http://arctos.database.museum/guid/DMNS:Mamm:12422" target="_blank">collection's part of a co-cataloged individual</a>, etc.<br>
2) <a href="http://arctosdb.org/documentation/parts/" target="_blank">Parts</a> are physical objects (and simultaneously leaf nodes of a hierarchical object tracking system).<br><br></div>It is possible to catalog the aggregate (<a href="http://arctos.database.museum/guid/MSB:Para:14740" target="_blank">slide</a>, <a href="http://arctos.database.museum/guid/MVZ:Egg:10588" target="_blank">nest</a>, <a href="http://arctos.database.museum/guid/UAM:ES:3397" target="_blank">whatever</a>) and call the individuals parts, or to catalog the individuals, or any <a href="http://arctos.database.museum/guid/MSB:Para:1145" target="_blank">combination</a> thereof. The choice is somewhat arbitrary from a curatorial perspective, perhaps less so when considering potential citations.<br>
<br></div><div>Arctos creates relationships between cataloged items through Identifiers, and provides resolvable identifiers for all specimens. This allows hierarchical relationships for tracking split lots, and also <a href="http://arctos.database.museum/guid/UAM:Mamm:30681" target="_blank">specimens to GenBank</a>, or to <a href="http://arctos.database.museum/guid/UAM:ES:12505" target="_blank">other specimen databases</a>, or within and across Arctos collections (<a href="http://arctos.database.museum/guid/MSB:Bird:34763" target="_blank">host</a>/<a href="http://arctos.database.museum/guid/KNWR:Ento:8763" target="_blank">parasite</a>, <a href="http://arctos.database.museum/guid/DMNS:Bird:34623" target="_blank">predator</a>/<a href="http://arctos.database.museum/guid/DMNS:Mamm:13143" target="_blank">prey</a>, <a href="http://arctos.database.museum/guid/MVZ:Herp:256547" target="_blank">etc</a>.). If the "target" provides machine-readable data, queries such as <a href="http://arctos.database.museum/SpecimenResults.cfm?related_term_val_1=Microtus&scientific_name=Cuterebra" target="_blank">botfly parasites of voles</a> become possible.<span class="HOEnZb"><font color="#888888"><br>
</font></span></div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-D<br></div><div><br></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">
On Thu, Aug 14, 2014 at 7:18 AM, Bentley, Andrew Charles <span dir="ltr"><<a href="mailto:abentley@ku.edu" target="_blank">abentley@ku.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">There are a number of issues brought up here.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The first is numbering systems. Having worked with a large number of collections in my role as Usability specialist for Specify I can attest that I have come
across virtually every numbering system known to mankind. The only one that works effectively is a simple number. The more complex a number becomes (adding delimiters or sub numbers or sub-sub numbers) the more error prone the possibilities become. Not only
that, but it is no longer a number (in digital jargon) but is now a string which has all sorts of other implications in the digital world.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Secondly we have the issue of lots vs. specimens. It has always baffled me as to why entomology collections do not work on a hybrid lot system as opposed to
a specimen based system. With this system you could number the original “bag” or lot of mixed specimens as soon as it arrives. As that bag is separated out into other “bags” or lots through identification etc., they too can be numbered until you get to the
point where individual specimens are being extracted, identified and cataloged with an individual number. If any of these “bags” or lots becomes “empty” through this process, they could of course be deleted from the database or maintained and indicated as
being empty with a count of zero. All of this material would of course be linked by the collecting event and locality information as having come from the same collection but you could also group these together in other ways to indicate that they are related
– see below.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The other issue is derivatives. There are a number of ways in which these can be handled but they both fall into two main categories. They are either treated
as “new” objects or they are treated as “preparations” of the original object. If they are “new” objects they should be given a new number. If they are “preparations” of the original object, then they should retain the original number and should be indicated
as preparations by a preparation type (skeleton, C&S, tissue, DNA extract etc.). The preparation scenario is the easiest in terms of keeping track of how these items are related as they will all have the same number. The “new” items are a little more tricky
but can also be handled. In Specify there are three mechanisms in which to handle these:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>1.<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Containers – within Specify there is a concept of containers whereby distinct objects with individual catalog numbers can be linked together within
a single container to indicate that they came from the same “parent” object or are linked in some other way. This is most commonly used in herbaria and paleo collections where multiple objects on the same sheet or rock have been given different catalog numbers.<u></u><u></u></span></p>
<p><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>2.<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Relationships – there is also a concept of relationships whereby individuals from different collections can also be linked i.e. tissue/voucher, host/parasite,
host/pollinator etc. This accommodates some instances where the linked items are not from the same taxonomic group and are in distinct collections.<u></u><u></u></span></p>
<p><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>3.<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Projects – there is also a project table in Specify that allows for multiple collection objects to be grouped together in a defined manner with a
project title and other information.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">There are so many ways in which different collections and even collections within the same discipline do things that it is near impossible to cover every variation
found. The only way to do this is to offer as many possibilities as possible to accommodate these relationships.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Andy<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:black" lang="EN-AU"> A : A : A :<br>
}<(((_°>.,.,.,.}<(((_°>.,.,.,.}<)))_°><br>
V V V<br>
Andy Bentley<br>
Ichthyology Collection Manager<br>
University of Kansas<br>
Biodiversity Institute<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:black" lang="EN-AU">Dyche Hall<br>
1345 Jayhawk Boulevard<br>
Lawrence, KS, 66045-7561<br>
USA<br>
<br>
Tel: <a href="tel:%28785%29%20864-3863" value="+17858643863" target="_blank">(785) 864-3863</a><br>
Fax: <a href="tel:%28785%29%20864-5335" value="+17858645335" target="_blank">(785) 864-5335</a> <br>
Email: <a href="mailto:abentley@ku.edu" target="_blank">abentley@ku.edu</a> <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:black" lang="EN-AU"><a href="http://ichthyology.biodiversity.ku.edu/" target="_blank">http://ichthyology.biodiversity.ku.edu</a><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:black" lang="EN-AU"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:black" lang="EN-AU">SPNHC President<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:black" lang="EN-AU"><a href="http://www.spnhc.org/" target="_blank">http://www.spnhc.org</a><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:black" lang="EN-AU"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:black" lang="EN-AU"> : : <br>
A : A : A :<br>
}<(((_°>.,.,.,.}<(((_°>.,.,.,.}<)))_°><br>
V V V</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" lang="EN-AU"><u></u><u></u></span></p><div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""> <a href="mailto:nhcoll-l-bounces@mailman.yale.edu" target="_blank">nhcoll-l-bounces@mailman.yale.edu</a> [mailto:<a href="mailto:nhcoll-l-bounces@mailman.yale.edu" target="_blank">nhcoll-l-bounces@mailman.yale.edu</a>]
<b>On Behalf Of </b>Dean Pentcheff<br>
<b>Sent:</b> Wednesday, August 13, 2014 8:12 PM<br>
<b>To:</b> Colin Favret<br>
<b>Cc:</b> <a href="mailto:nhcoll-l@mailman.yale.edu" target="_blank">nhcoll-l@mailman.yale.edu</a><br>
<b>Subject:</b> Re: [Nhcoll-l] Unique IDs for museum objects versus specimens<u></u><u></u></span></p>
<p class="MsoNormal"><u></u> <u></u></p>
</div><div>
<p class="MsoNormal">This is an issue that I've raised in the past with the Specify team (and plan to raise again in the near future — fair warning, guys :)<u></u><u></u></p><div><div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">The precipitating example for us comes from marine specimens. Often an unsorted jar of material will arrive (e.g. from a dredge sample) to be cataloged in the collection — this unsorted lot should get a unique ID — it may be around for
years before it's touched. Then we may pull out (for example) all the crustacea into another jar. This partly-sorted lot also needs a unique ID (it may go to a different room under different staff, so just keeping it with the original jar is not an option).
Then we may pull out a single individual, identify it, and use that in a publication, so that, too, needs an ID. A visiting researcher then examines that individual and pulls off parasitic crustacea, identifying each and putting them into individual vials,
each of which needs an ID. Etc.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">What we have is a clear hierarchical branching parent-child relationship from the initial unsorted lot down to the individual parasites (and their parasites, and their molecular derivatives, etc.). Logically, the way to accommodate this
is to have any "thing" in the collection identified with a unique ID. Any derived or subsorted "thing" gets another unique ID and (and this is critical) is linked to its parent so that all the information from the parent (and on up the chain to the top) is
immediately available via any "child" ID. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Every "thing" gets a first-class ID (no sub-IDs or a limited list of "preps" from an initial object). Key to the concept is retaining the parent-child-grandchild-... chain. At any moment, one should be able to retrieve any ID's entire chain
of parents (and their associated data), or any ID's entire chain of derived children (and their associated data). <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">It is a mystery to me why this scheme is not the standard model for specimen databases where there is a habit of creating chains of derivatives over time. There certainly are implementation details that need careful consideration (for
example with propagation of data down the chain, how "locked" that propagation is, and how to handle things that get completely subdivided so they no longer exist as such, but whose data must persist), but it seems like a very clean, very flexible base model.<u></u><u></u></p>
</div>
</div></div></div><div><div>
<div>
<p class="MsoNormal"><br clear="all">
<u></u><u></u></p>
<div>
<p class="MsoNormal">-Dean<br>
-- <br>
Dean Pentcheff<br>
<a href="mailto:pentcheff@gmail.com" target="_blank">pentcheff@gmail.com</a><br>
<a href="mailto:dpentche@nhm.org" target="_blank">dpentche@nhm.org</a><u></u><u></u></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Wed, Aug 13, 2014 at 4:01 PM, Colin Favret <<a href="mailto:ColinFavret@aphidnet.org" target="_blank">ColinFavret@aphidnet.org</a>> wrote:<u></u><u></u></p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif"">Has anyone dealt with the distinction between issuing unique IDs (for labels and database records) for museum objects versus specimens? A case in point might be a microscope slide with 100
specimens on it (or a jar, envelope, etc.). These specimens can be of multiple taxa, different sexes, life stages, etc. I believe most collections label the museum object (slide, jar, envelope, etc.) with a unique identifier and then treat the specimens as
a lot, but this doesn't fully parse out the data associated with the various specimens in a specimen database.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif""><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif"">I've developed my own solution (unique ID label for the object, decimal numbers but no label for the individual specimens or specimen lots - e.g. INST123456 for the slide, INST123456.001
for the first specimen lot, INST123456.002 for the second, etc.).<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif""><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif"">But I'm wondering what others have done or if there is anything out there approaching an industry standard.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif""><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif"">Thanks for your input!<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif""><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif"">Colin<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana","sans-serif";color:#888888"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Verdana","sans-serif";color:#888888">Colin Favret</span><span style="font-family:"Verdana","sans-serif";color:#888888"><u></u><u></u></span></p>
</div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:7.5pt;font-family:"Verdana","sans-serif";color:#888888">Université de Montréal</span><span style="font-family:"Arial","sans-serif";color:#888888"><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:7.5pt;font-family:"Verdana","sans-serif";color:#888888"><a href="http://favret.aphidnet.org/" target="_blank">Favret.AphidNet.org</a></span><span style="font-family:"Arial","sans-serif";color:#888888"><u></u><u></u></span></p>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
Nhcoll-l mailing list<br>
<a href="mailto:Nhcoll-l@mailman.yale.edu" target="_blank">Nhcoll-l@mailman.yale.edu</a><br>
<a href="http://mailman.yale.edu/mailman/listinfo/nhcoll-l" target="_blank">http://mailman.yale.edu/mailman/listinfo/nhcoll-l</a><br>
<br>
_______________________________________________<br>
NHCOLL-L is brought to you by the Society for the Preservation of<br>
Natural History Collections (SPNHC), an international society whose<br>
mission is to improve the preservation, conservation and management of<br>
natural history collections to ensure their continuing value to<br>
society. See <a href="http://www.spnhc.org" target="_blank">http://www.spnhc.org</a> for membership information.<u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div></div></div>
</div>
<br>_______________________________________________<br>
Nhcoll-l mailing list<br>
<a href="mailto:Nhcoll-l@mailman.yale.edu" target="_blank">Nhcoll-l@mailman.yale.edu</a><br>
<a href="http://mailman.yale.edu/mailman/listinfo/nhcoll-l" target="_blank">http://mailman.yale.edu/mailman/listinfo/nhcoll-l</a><br>
<br>
_______________________________________________<br>
NHCOLL-L is brought to you by the Society for the Preservation of<br>
Natural History Collections (SPNHC), an international society whose<br>
mission is to improve the preservation, conservation and management of<br>
natural history collections to ensure their continuing value to<br>
society. See <a href="http://www.spnhc.org" target="_blank">http://www.spnhc.org</a> for membership information.<br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>