<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Dear Dean,<div><br></div><div><blockquote type="cite"><div><br>Yep. I'm all in favor of opaque, non-information-bearing identifiers.<br>The moment you accuse the text of the identifier of having intrinsic<br>meaning, you accept all the ugliness of figuring out how to "update"<br>the identifier when the underlying data are updated. [Real-life case<br>in point: some departments in our institution had a system of minting<br>specimen IDs based on the year of collection plus other digits. With<br>some frequency we discover that the specimens were actually collected<br>in some other year. So either: (a) we change the identifier<br>(unacceptable for all the reasons we know and love); or (b) we know<br>that we cannot trust the year-part of any identifier (so we used this<br>formula why?).]<br><br></div></blockquote><div><br></div>One thing I'd clarify here is that opacity != obscurity. I'm OK with identifiers being generated from metadata so that they appear human-readable (which also means they may be hackable), so long as we accept that what our interpretation may be wrong.</div><div><br></div><div>Apart from human-readable, hackable identifiers being easier to work with in some situations (e.g., when you are harvesting data, navigating a hierarchy of records, or trying to figure out whether an identifier is a typo), I worry that people misinterpret opacity (this identifier might look meaningful but caveat emptor) as requiring obscurity (e.g., I will use UUIDs because nobody will try and interpret those).</div><div><br></div><div>Obviously, overtime the ability to interpret an identifier will decay, and it will be impossible to reliably interpret them as carrying meaning, and that's fine. And many of the things non-opacque identifiers are useful for would disappear if we had decent services (e.g., ways to download data), but I think creating deliberately opaque identifiers from the start may be a mistake. Nobody likes UUIDs, and no amount of "yeah, but in an ideal world you'll never see them" softens the fact they look ugly (and often connected to technologies such as LSIDs that nobody gets).</div><div><br></div><div>In other words, lets have identifiers that aren't ugly, and which are connected to some immediately valuable services so we provide value to people, rather than ugly identifiers with no obvious benefits.<br><div><br></div><div>Regards</div><div><br></div><div>Rod</div><div><br><div><div>On 26 Feb 2012, at 21:39, Dean Pentcheff wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Yes. And I would qualify what you said as follows:<br><br>On Sat, Feb 25, 2012 at 4:55 AM, Roderic Page <<a href="mailto:r.page@bio.gla.ac.uk">r.page@bio.gla.ac.uk</a>> wrote:<br><blockquote type="cite">Dear Dean,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">In essence, yes, so long as we:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">a) avoid collisions due to non-unique acronyms (hence we can't automatically<br></blockquote><blockquote type="cite">generate URIs from specimen codes without some fussing)<br></blockquote><br>It's the function of the centralizing agency to ensure this when they<br>accept a "listing formula" from an organization. If the URI-generating<br>formula could result in a collision with an existing listing, the<br>formula would have to be renegotiated before being accepted for the<br>registry.<br><br><blockquote type="cite">b) realise that we can't necessarily unpack a URI and use that to locate the<br></blockquote><blockquote type="cite">specimen (often we could, sometimes we won't be able to, in this sense the<br></blockquote><blockquote type="cite">identifiers are "opaque")<br></blockquote><br>Yep. I'm all in favor of opaque, non-information-bearing identifiers.<br>The moment you accuse the text of the identifier of having intrinsic<br>meaning, you accept all the ugliness of figuring out how to "update"<br>the identifier when the underlying data are updated. [Real-life case<br>in point: some departments in our institution had a system of minting<br>specimen IDs based on the year of collection plus other digits. With<br>some frequency we discover that the specimens were actually collected<br>in some other year. So either: (a) we change the identifier<br>(unacceptable for all the reasons we know and love); or (b) we know<br>that we cannot trust the year-part of any identifier (so we used this<br>formula why?).]<br><br><blockquote type="cite">c) avoid changing the URI if a specimen moves collection/institution or if<br></blockquote><blockquote type="cite">the host institution relabels it. Once minted the identifier doesn't change<br></blockquote><blockquote type="cite">(because that will break any links to it, defeating the point of having the<br></blockquote><blockquote type="cite">URIs).<br></blockquote><br>Yes. It's supposed to be a non-data-bearing opaque identifier. In the<br>worse (but inevitable) case where specimens get additional<br>identifiers, or get subsampled into additional identifiable pieces,<br>there has to be a "synonymy" service that would (perhaps recursively)<br>return the other relevant identifiers. That would be (cough, cough)<br>trivial to implement as long as any subsequent identifier assignment<br>includes a reference to the already-existing identifier.<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Regards<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Rod<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On 24 Feb 2012, at 17:29, Dean Pentcheff wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">This is directly in response to Rod's response to Paul. I think the two of<br></blockquote><blockquote type="cite">you may have just articulated nearly the same idea, though you seem not to<br></blockquote><blockquote type="cite">think you did.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Paul envisions institutions each declaring their own URI-creating formula<br></blockquote><blockquote type="cite">(to resolve down to a specimen at that institution), promulgated at a<br></blockquote><blockquote type="cite">"forum" location.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Rod envisions URI formulation as happening at a GBIFesque centralized site.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">If Paul's forum were GBIF (or similar), with an added function that GBIF (or<br></blockquote><blockquote type="cite">similar) renegotiates any institutional declaration that collides with a<br></blockquote><blockquote type="cite">pre-existing declaration, does that map to the same thing for both of you?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">-Dean<br></blockquote><blockquote type="cite">--<br></blockquote><blockquote type="cite">Dean Pentcheff<br></blockquote><blockquote type="cite"><a href="mailto:pentcheff@gmail.com">pentcheff@gmail.com</a><br></blockquote><blockquote type="cite"><a href="mailto:dpentche@nhm.org">dpentche@nhm.org</a><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On Fri, Feb 24, 2012 at 12:23 AM, Roderic Page <<a href="mailto:r.page@bio.gla.ac.uk">r.page@bio.gla.ac.uk</a>> wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Dear Paul,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">A few quick comments.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Constructing URLs from specimen codes is a nice ideal, but in practise<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">breaks down because museum acronyms are not globally unique, and specimen<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">codes are not always unique within institutions (this is a big issue for<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">vertebrate collections where the same code may be a used for a fish, a herp,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">a mammal, and a bird). So we need ways to disambiguate these. The Darwin<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Core triplet I've been complaining about on my blog is one attempt to do<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">this by using collectionCodes as part of the specimen code. But these are<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">not terribly stable (a lot of the duplication in GBIF is due to museums<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">mucking about with collection codes).<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I personally don't hold out much hope for museums being able to develop<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">and maintain rules for converting specimen codes into URIs. Let's be<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">realistic, most museums have no idea about the web beyond creating pretty<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">public interfaces. There are DiGiR servers at major museums running on<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">machines with no domain name, just an IP address.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I suspect it's going to be easier to delegate resolving specimens this to<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">something like GBIF. As a data consumer, I'd much prefer going to one place<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">and getting the codes resolved, rather than have to first figure out where<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">to go to find out the rule. If I want metadata for a scientific article I<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">go to CrossRef, not the individual publisher. Distributed begats<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">centralised.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I think not insisting on resolvable identifiers is a big mistake. It's<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">like saying it's OK to publish source code that you haven't actually<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">bothered to check whether it compiles. If they don't have to resolve I can<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">publish any identifier I want (witness the number of "fake" LSIDs in the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">wild) and I've made zero commitment that it means anything. And you've taken<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">away the ability of the user to test whether your identifier is meaningful,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">and thus build any degree of trust. The acid test of whether you are serious<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">is whether your identifiers are "live." The minute we say it's OK for them<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">to be unresolvable we are buggered.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Regards<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Rod<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">On 24 Feb 2012, at 06:14, Paul Murray wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">On 23/02/2012, at 9:37 PM, Roderic Page wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I've recently written an number of posts on the implications of the lack<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">of specimen-level identifiers, which makes it very hard to link different<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">sources of data together, such as GBIF and Genbank<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="http://iphylo.blogspot.com/2012/02/linking-gbif-and-genbank.html">http://iphylo.blogspot.com/2012/02/linking-gbif-and-genbank.html</a> , and are<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">also a factor in creating duplicate records in GBIF<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="http://iphylo.blogspot.com/2012/02/how-many-specimens-does-gbif-really.html">http://iphylo.blogspot.com/2012/02/how-many-specimens-does-gbif-really.html</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">This is definitely an issue. In AFD (which is not a specimen database), we<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">hold a "museum code" and an "accession number" for types specimens. Ideally,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I would like to be able to get from these two fields to a URI.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">For instance, given the data<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">nameT typeTypeT museumT museumDesc accessonNo materialElement latLong<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">locality comments<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Holothuria bivittata Mitsukuri, 1912 Syntype TIU Tokyo Imperial<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">University, Tokyo, Japan 1217 Okinawa, Riu Kiu and Yayeyana Ils, Japan<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Holothuria bivittata Mitsukuri, 1912 Syntype TIU Tokyo Imperial<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">University, Tokyo, Japan 1218<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I would like the AFD type specimen records (which are anonymous nodes in<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">our profile data) to point to<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">"<a href="http://collections.tiu.edu.jp/colleciton-X/1217">http://collections.tiu.edu.jp/colleciton-X/1217</a>" (or whatever), which could<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">be generated from the data we already have. The key is the individual<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">institutions holding collections.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">The only way I can imagine this happening is for each institution with<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">collections to state "you construct URIs from our accession numbers like<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">so". With that declaration, stores exposing data (such as the boa silos) can<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">perform the mapping when the news reaches them. Once this is in place,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">anyone handling (for instance) TIU accession numbers can publish correct<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">URIs in their RDF. Most particularly, other institutions accepting specimens<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">from TUI could publish that their new URI for the item is "owl:sameAs" the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">TUI one. And the whole thing begins to knit together.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Importantly: it is not necessary to actually make these URIs resolvable.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Hopefully, one day there *would* be something at that URL which would issue<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">a 303 redirect, but the existence of the identifier as an identifier doesn't<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">rely on it. All that is needed is that commitment to the namespace on the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">part of the issuer.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">My point is first, that this can be done in stages, and doesn't depend on<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">everybody implementing a big and expensive solution right away or in<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">synchrony; and second, that we don't need a top-down assignment of<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">identifiers. A bottom-up solution can work. Perhaps the main thing missing<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">is a forum on which an institution can announce its creation and assignment<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">of a URI namespace for persistent identifiers.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Having said all that, Rod's point is about identification of individuals.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">An accession number is put on a "token", of course, a given individual may<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">have many "tokens". A case in point is this record in AFD:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">nameT typeTypeT museumT museumDesc accessonNo materialElement latLong<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">locality comments<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Bregmaceros pseudolanceolatus Torii, Javonillo & Ozawa, 2004 Paratype URM<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">University of the Ryukyus, Nishihara, Okinawa, Japan P. 12156, 27508–27511,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">29172, 29620, 33056<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">The type specimen has 8 URM accession numbers, and there's really no way<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">around that.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Even then, however, the question of identifying the individuals comes down<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">to the same solution: if it's to happen, then it will have to be done by the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">curators of the collections - it's only the curators who actually know what<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">items are from the same individual. A third party generating UUIDs for all<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">these things just isn't going to work out - they won't get it right. What is<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">needed is for the curator to announce, for instance, "individuals shall be<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">identified by <a href="http://specimens.mymuseum.edu">http://specimens.mymuseum.edu</a>/<collection id>/<collector's<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">field number for the individual>". It really doesn't matter how the URIs are<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">done, as long as it's consistent, persistent, and public.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">If you have received this transmission in error please notify us<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">immediately by return e-mail and delete all copies. If this e-mail or any<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">attachments have been sent to you in error, that error does not constitute<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">waiver of any confidentiality, privilege or copyright in respect of<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">information in the e-mail or attachments.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Please consider the environment before printing this email.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">---------------------------------------------------------<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Roderic Page<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Professor of Taxonomy<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Institute of Biodiversity, Animal Health and Comparative Medicine<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">College of Medical, Veterinary and Life Sciences<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Graham Kerr Building<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">University of Glasgow<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Glasgow G12 8QQ, UK<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Email: <a href="mailto:r.page@bio.gla.ac.uk">r.page@bio.gla.ac.uk</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Tel: +44 141 330 4778<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Fax: +44 141 330 2792<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">AIM: <a href="mailto:rodpage1962@aim.com">rodpage1962@aim.com</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Facebook: <a href="http://www.facebook.com/profile.php?id=1112517192">http://www.facebook.com/profile.php?id=1112517192</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Twitter: <a href="http://twitter.com/rdmpage">http://twitter.com/rdmpage</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Blog: <a href="http://iphylo.blogspot.com">http://iphylo.blogspot.com</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Home page: <a href="http://taxonomy.zoology.gla.ac.uk/rod/rod.html">http://taxonomy.zoology.gla.ac.uk/rod/rod.html</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">_______________________________________________<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">tdwg-tag mailing list<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="mailto:tdwg-tag@lists.tdwg.org">tdwg-tag@lists.tdwg.org</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="http://lists.tdwg.org/mailman/listinfo/tdwg-tag">http://lists.tdwg.org/mailman/listinfo/tdwg-tag</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">---------------------------------------------------------<br></blockquote><blockquote type="cite">Roderic Page<br></blockquote><blockquote type="cite">Professor of Taxonomy<br></blockquote><blockquote type="cite">Institute of Biodiversity, Animal Health and Comparative Medicine<br></blockquote><blockquote type="cite">College of Medical, Veterinary and Life Sciences<br></blockquote><blockquote type="cite">Graham Kerr Building<br></blockquote><blockquote type="cite">University of Glasgow<br></blockquote><blockquote type="cite">Glasgow G12 8QQ, UK<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Email: <a href="mailto:r.page@bio.gla.ac.uk">r.page@bio.gla.ac.uk</a><br></blockquote><blockquote type="cite">Tel: +44 141 330 4778<br></blockquote><blockquote type="cite">Fax: +44 141 330 2792<br></blockquote><blockquote type="cite">AIM: <a href="mailto:rodpage1962@aim.com">rodpage1962@aim.com</a><br></blockquote><blockquote type="cite">Facebook: <a href="http://www.facebook.com/profile.php?id=1112517192">http://www.facebook.com/profile.php?id=1112517192</a><br></blockquote><blockquote type="cite">Twitter: <a href="http://twitter.com/rdmpage">http://twitter.com/rdmpage</a><br></blockquote><blockquote type="cite">Blog: <a href="http://iphylo.blogspot.com">http://iphylo.blogspot.com</a><br></blockquote><blockquote type="cite">Home page: <a href="http://taxonomy.zoology.gla.ac.uk/rod/rod.html">http://taxonomy.zoology.gla.ac.uk/rod/rod.html</a><br></blockquote><blockquote type="cite"><br></blockquote><br></div></blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">---------------------------------------------------------<br>Roderic Page<br>Professor of Taxonomy<br>Institute of Biodiversity, Animal Health and Comparative Medicine<br>College of Medical, Veterinary and Life Sciences<br>Graham Kerr Building<br>University of Glasgow<br>Glasgow G12 8QQ, UK<br><br>Email: <a href="mailto:r.page@bio.gla.ac.uk">r.page@bio.gla.ac.uk</a><br>Tel: +44 141 330 4778<br>Fax: +44 141 330 2792<br>AIM: <a href="mailto:rodpage1962@aim.com">rodpage1962@aim.com</a><br>Facebook: <a href="http://www.facebook.com/profile.php?id=1112517192">http://www.facebook.com/profile.php?id=1112517192</a><br>Twitter: <a href="http://twitter.com/rdmpage">http://twitter.com/rdmpage</a><br>Blog: <a href="http://iphylo.blogspot.com">http://iphylo.blogspot.com</a><br>Home page: <a href="http://taxonomy.zoology.gla.ac.uk/rod/rod.html">http://taxonomy.zoology.gla.ac.uk/rod/rod.html</a><br></span>
</div>
<br></div></div></body></html>