<HTML dir=ltr><HEAD>
<META http-equiv=Content-Type content="text/html; charset=unicode">
<META content="MSHTML 6.00.2900.3059" name=GENERATOR></HEAD>
<BODY style="WORD-WRAP: break-word">
<DIV id=idOWAReplyText88806 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>Anybody got any views (strong,&nbsp;otherwise or proxy for others views) on whether the LSID should refer to data+metadata or just metadata?</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr><FONT face=Arial size=2>From where I sit, closer to physical objects than bits in&nbsp;a bit stream, I favour the former. Take names for example. Strings of characters and spaces whose form is governed by Codes and one of the means, if not the primary mean, by which we communicate (verbally, in print or electronically) about biodiversity. For LSIDs applied to names my understanding is that they must resolve to an unchanging bit stream representing the&nbsp;name&nbsp;(we implemented this in Index Fungorum 1st May 2005 when we set up the demo resolver) but the associated metadata may change. If I'm correct on this one how does it work for LSIDs only resolving metadata, which is not fixed. I know Roger tried to explain this one to me but I'm still not sure it's entirely logical.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr><FONT face=Arial size=2>I think I'm with Rod on the LSIDs for specimens - they do not represent the physical object but are a sort of digital substitute (or substitutes) of that object.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr><FONT face=Arial size=2>And I also support Rods view that we should as far as possible avoid the duplication of GUIDs. Thus, for names it appears logical (although I must declare an 'interest' here so others may see a conflict) that the globally recognized nomenclators (IPNI, IF, ZooBank (soon), the bacterial list, the algal list, the virus database -&nbsp;I forget the acronyms here) be charged with providing these GUIDs (currently as LSIDs) for all of us to use. And following on from that, the 'institution' which is charged with providing the digital representation of specimens is the institution which is the custodian of the physical object.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr><FONT face=Arial size=2>Regards,</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr><FONT face=Arial size=2>Paul</FONT></DIV></DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Roderic Page [mailto:r.page@bio.gla.ac.uk]<BR><B>Sent:</B> Sun 03/06/2007 12:03<BR><B>To:</B> Weitzman, Anna<BR><B>Cc:</B> Richard Pyle; Paul Kirk; Jason Best; tdwg-guid@lists.tdwg.org<BR><B>Subject:</B> Re: [tdwg-guid] First step in implementing LSIDs?[Scanned]<BR></FONT><BR></DIV>
<DIV>I think we need to be clear what gets an LSID (or a GUID in general). 
<DIV><BR class=khtml-block-placeholder></DIV>
<DIV>Some of the things listed by Anna are digital records, such as an image. It seems simplest to give these GUIDs that identify the image, with metadata linking the image to the thing the image depicts (there are existing RDF&nbsp;vocabularies to do this).</DIV>
<DIV><BR class=khtml-block-placeholder></DIV>
<DIV>Some things listed, such as a specimen, are physical objects. These are different from digital objects, and they way in which GUIDs that identify real things are handled has caused all manner of discussion (see&nbsp; <A href="http://www.w3.org/DesignIssues/HTTP-URI">http://www.w3.org/DesignIssues/HTTP-URI</A>&nbsp;and related pages bookmarked at&nbsp;<A href="http://del.icio.us/rdmpage/303">http://del.icio.us/rdmpage/303</A>). LSIDs don't handle this well, unless we rely on metadata saying "the thing identified by."</DIV>
<DIV><BR class=khtml-block-placeholder></DIV>
<DIV>So, at least on this level to say that all seven things get the same GUID is clearly a non starter.&nbsp; &nbsp;</DIV>
<DIV><BR class=khtml-block-placeholder></DIV>
<DIV>Relationships between things can be easily specified in metadata ("is part of", "depicts", "is kind of").</DIV>
<DIV><BR class=khtml-block-placeholder></DIV>
<DIV>The final issue is GUID reuse, that is, if somebody uses a INOTAXA record, they should at a minimum refer to the INOTAXA LSID. This would particularly apply to aggregators such as GBIF, who should not present their own identifiers unless GBIF has actually created the data. You often state "presumably shortly also available to GBIF in some form". It's not clear to what that means, but if it's GBIF because INOTAXA serves it, then I think GBIF should use INOTAXA LSIDs to refer to INOTAXA records.</DIV>
<DIV><BR class=khtml-block-placeholder></DIV>
<DIV>Clearly, generating a plethora a new, effectively local ids (masquerading as global) is not a recipe for progress. If we don't reuse GUIDs we are wasting our time.</DIV>
<DIV><BR class=khtml-block-placeholder></DIV>
<DIV>Regards</DIV>
<DIV><BR class=khtml-block-placeholder></DIV>
<DIV>Rod</DIV>
<DIV><BR class=khtml-block-placeholder></DIV>
<DIV><BR class=khtml-block-placeholder></DIV>
<DIV><BR class=khtml-block-placeholder>
<DIV><BR class=khtml-block-placeholder></DIV>
<DIV><BR>
<DIV>
<DIV>On 2 Jun 2007, at 18:53, Weitzman, Anna wrote:</DIV><BR class=Apple-interchange-newline>
<BLOCKQUOTE type="cite">
<DIV style="MARGIN: 0px">Hi Rich (et al.),</DIV>
<DIV style="MARGIN: 0px">I'm going to join this particular discussion<SPAN class=Apple-converted-space>&nbsp; </SPAN>in spite of the fact that I have not been able to follow the entire GUID discussion over the past couple of years and I may be repeating things that have been resolved.</DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style="MARGIN: 0px">Let's continue to investigate whether an LSID applies to the physical specimen or the database record (or both?). <SPAN class=Apple-converted-space>&nbsp;</SPAN></DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style="MARGIN: 0px">What about the record(s) for that same physical object in the literature?<SPAN class=Apple-converted-space>&nbsp; </SPAN>As we mark up literature, we are going to generate LSIDs for specimen records that will need to be resolved to be related to the same physical object (in a collection) and the data record (usually in that same collection's database).<SPAN class=Apple-converted-space>&nbsp;</SPAN></DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style="MARGIN: 0px">Let's look at the example that Chris Lyal and I are contemplating as we work on implementing an INOTAXA pilot to show in Bratislava:</DIV>
<DIV style="MARGIN: 0px">1) a weevil specimen here at USNM (a type described in the BCA)</DIV>
<DIV style="MARGIN: 0px">2) a record for it in the museum's database (we do have a type database for insects, and it will be available in a year or two), available on the museum's website, through GBIF, and through INOTAXA</DIV>
<DIV style="MARGIN: 0px">3) a record from digitized and parsed BCA in INOTAXA (presumably shortly also available to GBIF in some form)</DIV>
<DIV style="MARGIN: 0px">4) a record for the same weevil from a paper published in the 1950s available through INOTAXA (presumably shortly also available to GBIF in some form)</DIV>
<DIV style="MARGIN: 0px">5) a record for that weevil from a paper published in the 1990s available through INOTAXA<SPAN class=Apple-converted-space>&nbsp; </SPAN>(presumably shortly also available to GBIF in some form)</DIV>
<DIV style="MARGIN: 0px">6) a published image (or series of images) in the paper from the 1990s -- but now also digitized and made available through INOTAXA (presumably shortly also available to GBIF in some form)</DIV>
<DIV style="MARGIN: 0px">7) a digitized image (or series of images) made in our imaging project and made available through the museum's database, INOTAXA, GBIF and MorphoBank</DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style="MARGIN: 0px">Either each of these (1-7) will need to have its own LSID (or an equivalent in the case of the specimen itself) or they will all need to have the same LSID.<SPAN class=Apple-converted-space>&nbsp; </SPAN>If the former, they will all have to resolve to the same parent LSID--is this for the specimen or the record in its home database?--in order for the overall biodiversity information system to really work. <SPAN class=Apple-converted-space>&nbsp;</SPAN></DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style="MARGIN: 0px">Or let's take that a step further and make that a fish, where not only is there a record in the museum's database with its LSID, but that same record for the same fish that was imported some years ago into FishBase (now out of date perhaps, but still available to GBIF and via Fishbase).<SPAN class=Apple-converted-space>&nbsp; </SPAN>At the time, it was imported without an LSID and FishBase has (presumably) assigned it's own LSID...</DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style="MARGIN: 0px">Or let's say that someone else digitized their copy of the same BCA volume and followed the INOTAXA (taXMLit) and assigned yet another LSID for the specimen record...is that really the same 'record' or different from the one in #3?</DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style="MARGIN: 0px">I would like to think that in the long run we do not need multiple LSIDs for records that refer to the same specimen or record (as long as we can be truly certain that they are 'the same'.<SPAN class=Apple-converted-space>&nbsp; </SPAN>After all, the literature markup has a whole series of unique IDs for its various parts already, so can't we refer to 'the use of LSID 123 in workID 987' or 'the use of LSID 123 on pageID 456 in workID 987'? <SPAN class=Apple-converted-space>&nbsp;</SPAN></DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style="MARGIN: 0px">There are a lot of IDs here, but unless every collection database already has an LSID that we can 'grab' and use in INOTAXA we are going to have to create our own LSIDs and count on a community resolver to sort it all out (and even if that were true, not all the specimens that we are going to be referring to from INOTAXA have been put in electronic form anyplace else, so we will have to assign LSIDs at least temporarily--Paul did not mention how they are going to deal with the Zoological name LSIDs as at least a temporary solution--but I assume that they have a similar problem). <SPAN class=Apple-converted-space>&nbsp;</SPAN></DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style="MARGIN: 0px">I'm sure I don't know what the best solution is, but that's what I'm counting on the computer scientists in this group to tell me.<SPAN class=Apple-converted-space>&nbsp; </SPAN>I just hope they tell me soon, since we're going to need answers soon!</DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style="MARGIN: 0px">Cheers,</DIV>
<DIV style="MARGIN: 0px">Anna</DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style="MARGIN: 0px">Anna L. Weitzman, PhD</DIV>
<DIV style="MARGIN: 0px">Botanical and Biodiversity Informatics Research</DIV>
<DIV style="MARGIN: 0px">National Museum of Natural History</DIV>
<DIV style="MARGIN: 0px">Smithsonian Institution</DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style="MARGIN: 0px">office: 202.633.0846</DIV>
<DIV style="MARGIN: 0px">mobile: 202.415.4684</DIV>
<DIV style="MARGIN: 0px"><A href="mailto:weitzman@si.edu">weitzman@si.edu</A></DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style="MARGIN: 0px">________________________________</DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style="MARGIN: 0px">From: <A href="mailto:tdwg-guid-bounces@lists.tdwg.org">tdwg-guid-bounces@lists.tdwg.org</A> on behalf of Richard Pyle</DIV>
<DIV style="MARGIN: 0px">Sent: Sat 02-Jun-07 5:08 AM</DIV>
<DIV style="MARGIN: 0px">To: 'Paul Kirk'; 'Jason Best'; <A href="mailto:tdwg-guid@lists.tdwg.org">tdwg-guid@lists.tdwg.org</A></DIV>
<DIV style="MARGIN: 0px">Subject: RE: [tdwg-guid] First step in implementing LSIDs?[Scanned]</DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style="MARGIN: 0px">Paul and List,</DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style="MARGIN: 0px">First, I should clarify something about my earlier post.<SPAN class=Apple-converted-space>&nbsp; </SPAN>I wrote at the</DIV>
<DIV style="MARGIN: 0px">start of Scenario 3:</DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style="MARGIN: 0px">"3) Issue data-less LSIDs without using the revision ID feature, and track</DIV>
<DIV style="MARGIN: 0px">data change history separately from the LSIDs"</DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style="MARGIN: 0px">That should have been "...and track *metadata* change history separately</DIV>
<DIV style="MARGIN: 0px">from the LSIDs" (metadata, not data).</DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<BLOCKQUOTE type="cite">
<DIV style="MARGIN: 0px">So, without making things too complicated as we 'start to walk'</DIV>
<DIV style="MARGIN: 0px">in this domain of biodiversity informatics my vote is for a</DIV>
<DIV style="MARGIN: 0px">variation of scenario 3) from Rich. The reason I vote for this</DIV>
<DIV style="MARGIN: 0px">is that in the fullness of time, and the 'herb.IMI' database</DIV>
<DIV style="MARGIN: 0px">has already started this, much of the metadata with be</DIV>
<DIV style="MARGIN: 0px">LSIDs and it's correctness (i.e. sorting out typos etc) will</DIV>
<DIV style="MARGIN: 0px">be delegated to the entities who issue those LSIDs. As IPNI</DIV>
<DIV style="MARGIN: 0px">improves the quality of the metadata associated with the</DIV>
<DIV style="MARGIN: 0px">LSIDs they issue (and if I understand correctly they do use</DIV>
<DIV style="MARGIN: 0px">the scenario 3) from Rich) so the quality of the metadata</DIV>
<DIV style="MARGIN: 0px">associated with a 'herb.IMI' LSID improves. The reason I</DIV>
<DIV style="MARGIN: 0px">prefer the data + metadate 'model' is that in this instance</DIV>
<DIV style="MARGIN: 0px">the data is fixed ... who changes collection/accession</DIV>
<DIV style="MARGIN: 0px">numbers? ... so perfect for this role. Even if a collection</DIV>
<DIV style="MARGIN: 0px">moves to a new owner the original data need not 'disappear'</DIV>
<DIV style="MARGIN: 0px">in the same way that DOI's move with the objects as book and</DIV>
<DIV style="MARGIN: 0px">journal titles change from one publisher to another.</DIV></BLOCKQUOTE>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style="MARGIN: 0px">So...if I understand correctly, you differ from my scenario 3 in that you do</DIV>
<DIV style="MARGIN: 0px">generate data-bearing LSIDs for specimens, but the data part is limited to</DIV>
<DIV style="MARGIN: 0px">only the Accession number, not the complete set of data fields associated</DIV>
<DIV style="MARGIN: 0px">with the record -- correct?<SPAN class=Apple-converted-space>&nbsp; </SPAN>So, in effect, the object LSID actially applies</DIV>
<DIV style="MARGIN: 0px">to is the binary accession number, not the "concept" of the specimen.<SPAN class=Apple-converted-space>&nbsp; </SPAN>I can</DIV>
<DIV style="MARGIN: 0px">imagine in this case that the LSID can be thought of as representing the</DIV>
<DIV style="MARGIN: 0px">"concept of the specimen" because the accession number itself is a surrogate</DIV>
<DIV style="MARGIN: 0px">for the physical specimen.<SPAN class=Apple-converted-space>&nbsp; </SPAN>The only thing that concerns me about this</DIV>
<DIV style="MARGIN: 0px">approach is that there is a non-zero incidence of accidental duplicate</DIV>
<DIV style="MARGIN: 0px">catalog numbers within a given collection, and possibly errors in</DIV>
<DIV style="MARGIN: 0px">associating catalog numbers.<SPAN class=Apple-converted-space>&nbsp; </SPAN>For example, if the computer database for a</DIV>
<DIV style="MARGIN: 0px">collection had an error created by a technician who, for example, entered</DIV>
<DIV style="MARGIN: 0px">the metadata for accession number IMI1234569 by mistake, when it should have</DIV>
<DIV style="MARGIN: 0px">been IMI1234596 (and vice versa), then branding the accession number as</DIV>
<DIV style="MARGIN: 0px">"data" for the LSID means that the LSID technically *must* stay with the</DIV>
<DIV style="MARGIN: 0px">accession number (not the specimen associated with the metadata for that</DIV>
<DIV style="MARGIN: 0px">LSID), after the error is discovered.<SPAN class=Apple-converted-space>&nbsp; </SPAN>Not a huge problem, but could</DIV>
<DIV style="MARGIN: 0px">surprise people who had indexed the LSID before the error was discovered,</DIV>
<DIV style="MARGIN: 0px">who then came back to resolve it again after the error was fixed (i.e., they</DIV>
<DIV style="MARGIN: 0px">would get totally wrong information).<SPAN class=Apple-converted-space>&nbsp; </SPAN>Given how rare this problem is likely</DIV>
<DIV style="MARGIN: 0px">to be (against a backdrop of many far more likely problems we will have to</DIV>
<DIV style="MARGIN: 0px">overcome), I don't see this as a strong reason not to proceed with your</DIV>
<DIV style="MARGIN: 0px">plan.</DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<BLOCKQUOTE type="cite">
<DIV style="MARGIN: 0px">Final point, the 'data' is the 'herb.IMI' accession number;</DIV>
<DIV style="MARGIN: 0px">in context this is a GUI because of the existence of Index</DIV>
<DIV style="MARGIN: 0px">Herbariorum. So, our data will be 123456 not IMI123456</DIV>
<DIV style="MARGIN: 0px">because ... in the fullness of time we will include an</DIV>
<DIV style="MARGIN: 0px">Index Herbariorum LSID to 'identify' the 'institutional</DIV>
<DIV style="MARGIN: 0px">acronym' element of the metadata.</DIV></BLOCKQUOTE>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style="MARGIN: 0px">Is the binary data for the accession number in 8-bit, or 16-bit?<SPAN class=Apple-converted-space>&nbsp; </SPAN>I'm</DIV>
<DIV style="MARGIN: 0px">assuming 8-bit would be fine, as I suspect all collections would have</DIV>
<DIV style="MARGIN: 0px">accession numbers that can be rendered with 256-character ASCII.<SPAN class=Apple-converted-space>&nbsp; </SPAN>Is there</DIV>
<DIV style="MARGIN: 0px">any "wrapper" to the number as binary data, or is it a straight ASCII binary</DIV>
<DIV style="MARGIN: 0px">representation (e.g.: 001100010011001000110011001101000011010100110110 for</DIV>
<DIV style="MARGIN: 0px">"12345")?</DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style="MARGIN: 0px">I'm not sure I follow the logic of how embedding the accession number as</DIV>
<DIV style="MARGIN: 0px">data for the LSID allows the LSID to move to a new owner.<SPAN class=Apple-converted-space>&nbsp; </SPAN>I would think the</DIV>
<DIV style="MARGIN: 0px">opposite. Isn't it likely that the new owner would create their own</DIV>
<DIV style="MARGIN: 0px">accession number for the specimen?<SPAN class=Apple-converted-space>&nbsp; </SPAN>In this case, they would be forced to</DIV>
<DIV style="MARGIN: 0px">generate a new LSID if they were following the same practice of encoding the</DIV>
<DIV style="MARGIN: 0px">accession number as "data", rather than metadata.</DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style="MARGIN: 0px">Also, wouldn't it make more sense to include the acronym (IMI) as part of</DIV>
<DIV style="MARGIN: 0px">the data for the LSID? At least that way the "12345" would have *some*</DIV>
<DIV style="MARGIN: 0px">context.</DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style="MARGIN: 0px">Finally, this approach would work only for collections where there is a</DIV>
<DIV style="MARGIN: 0px">strict 1:1 correlation between accession numbers and specimen objects for</DIV>
<DIV style="MARGIN: 0px">which an LSID is desired.</DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style="MARGIN: 0px">Thanks for your comments -- this thread is already forcing me to think about</DIV>
<DIV style="MARGIN: 0px">things in a way I hadn't thought of them before.</DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style="MARGIN: 0px">Aloha,</DIV>
<DIV style="MARGIN: 0px">Rich</DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style="MARGIN: 0px">Richard L. Pyle, PhD</DIV>
<DIV style="MARGIN: 0px">Database Coordinator for Natural Sciences</DIV>
<DIV style="MARGIN: 0px"><SPAN class=Apple-converted-space>&nbsp; </SPAN>and Associate Zoologist in Ichthyology</DIV>
<DIV style="MARGIN: 0px">Department of Natural Sciences, Bishop Museum</DIV>
<DIV style="MARGIN: 0px">1525 Bernice St., Honolulu, HI 96817</DIV>
<DIV style="MARGIN: 0px">Ph: (808)848-4115, Fax: (808)847-8252</DIV>
<DIV style="MARGIN: 0px">email: <A href="mailto:deepreef@bishopmuseum.org">deepreef@bishopmuseum.org</A></DIV>
<DIV style="MARGIN: 0px"><A href="http://hbs.bishopmuseum.org/staff/pylerichard.html">http://hbs.bishopmuseum.org/staff/pylerichard.html</A></DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style="MARGIN: 0px">_______________________________________________</DIV>
<DIV style="MARGIN: 0px">tdwg-guid mailing list</DIV>
<DIV style="MARGIN: 0px"><A href="mailto:tdwg-guid@lists.tdwg.org">tdwg-guid@lists.tdwg.org</A></DIV>
<DIV style="MARGIN: 0px"><A href="http://lists.tdwg.org/mailman/listinfo/tdwg-guid">http://lists.tdwg.org/mailman/listinfo/tdwg-guid</A></DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style="MARGIN: 0px">_______________________________________________</DIV>
<DIV style="MARGIN: 0px">tdwg-guid mailing list</DIV>
<DIV style="MARGIN: 0px"><A href="mailto:tdwg-guid@lists.tdwg.org">tdwg-guid@lists.tdwg.org</A></DIV>
<DIV style="MARGIN: 0px"><A href="http://lists.tdwg.org/mailman/listinfo/tdwg-guid">http://lists.tdwg.org/mailman/listinfo/tdwg-guid</A></DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV></BLOCKQUOTE></DIV><BR>
<DIV><SPAN class=Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate; border-spacing: 0px 0px; orphans: 2; widows: 2">
<DIV style="MARGIN: 0px">----------------------------------------</DIV>
<DIV style="MARGIN: 0px">Professor Roderic D. M. Page</DIV>
<DIV style="MARGIN: 0px">Editor, Systematic Biology</DIV>
<DIV style="MARGIN: 0px">DEEB, IBLS</DIV>
<DIV style="MARGIN: 0px">Graham Kerr Building</DIV>
<DIV style="MARGIN: 0px">University of Glasgow</DIV>
<DIV style="MARGIN: 0px">Glasgow G12 8QP</DIV>
<DIV style="MARGIN: 0px">United Kingdom</DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px; FONT: 12px Helvetica"><BR></DIV>
<DIV style="MARGIN: 0px">Phone: +44 141 330 4778</DIV>
<DIV style="MARGIN: 0px">Fax: +44 141 330 2792</DIV>
<DIV style="MARGIN: 0px">email: <A href="mailto:r.page@bio.gla.ac.uk">r.page@bio.gla.ac.uk</A></DIV>
<DIV style="MARGIN: 0px">web: <A href="http://taxonomy.zoology.gla.ac.uk/rod/rod.html">http://taxonomy.zoology.gla.ac.uk/rod/rod.html</A></DIV>
<DIV style="MARGIN: 0px">iChat: <A href="">aim://rodpage1962</A></DIV>
<DIV style="MARGIN: 0px">reprints: <A href="http://taxonomy.zoology.gla.ac.uk/rod/pubs.html">http://taxonomy.zoology.gla.ac.uk/rod/pubs.html</A></DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px; FONT: 12px Helvetica"><BR></DIV>
<DIV style="MARGIN: 0px">Subscribe to Systematic Biology through the Society of Systematic</DIV>
<DIV style="MARGIN: 0px">Biologists Website: <A href="http://systematicbiology.org/">http://systematicbiology.org</A></DIV>
<DIV style="MARGIN: 0px">Search for taxon names: <A href="http://darwin.zoology.gla.ac.uk/~rpage/portal/">http://darwin.zoology.gla.ac.uk/~rpage/portal/</A></DIV>
<DIV style="MARGIN: 0px">Find out what we know about a species: <A href="http://ispecies.org/">http://ispecies.org</A></DIV>
<DIV style="MARGIN: 0px">Rod's rants on phyloinformatics: <A href="http://iphylo.blogspot.com/">http://iphylo.blogspot.com</A></DIV>
<DIV style="MARGIN: 0px">Rod's rants on ants: <A href="http://semant.blogspot.com/">http://semant.blogspot.com</A></DIV>
<DIV style="MARGIN: 0px"><BR class=khtml-block-placeholder></DIV><BR class=Apple-interchange-newline></SPAN></DIV><BR></DIV></DIV></DIV><p><font face="Arial" size="1">************************************************************************<br>
The information contained in this e-mail and any files transmitted with it is confidential and is for the exclusive use of the intended recipient. If you are not the intended recipient please note that any distribution, copying or use of this communication or the information in it is prohibited.&nbsp;<br>
<br>
Whilst CAB International trading as CABI takes steps to prevent the transmission of viruses via e-mail, we cannot guarantee that any e-mail or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions.<br>
<br>
If you have received this communication in error, please notify us by e-mail at cabi@cabi.org or by telephone on +44 (0)1491 829199 and then delete the e-mail and any copies of it.<br>
<br>
CABI is an International Organization recognised by the UK Government under Statutory Instrument 1982 No. 1071.<br>
<br>
**************************************************************************</font><br>
</p>
</BODY></HTML>