I think it might be helpful to suggest that if this system is too<br>specialized and complicated to implement the vast majority of<br>collections will not adopt it. <br><br>If your goal is to make as much of this data available as possible
<br>to researchers then you need to devise a system that the typical<br>museum curator can understand and maintain using only<br>bright computer savvy undergraduates.<br><br>Respectfully,<br><br>Pete<br><br><div><span class="gmail_quote">

On 6/6/07, <b class="gmail_sendername">Dave Vieglais</b> &lt;<a href="mailto:vieglais@ku.edu" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">vieglais@ku.edu</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Hi Bob,<br>it&#39;s pretty simple - DNS is used to resolve an ip address to which a<br>client may connect with a service to resolve the GUID.&nbsp;&nbsp;In the case<br>of LSIDs the suggested mechanism (and actually the only existing
<br>mechanism) is to use DNS SRV records to provide a level of<br>indirection that is meant to preserve the discovery of service ip<br>address independent of the normal issues with A records (although<br>much of the same functionality can be provided with judicious use of
<br>CNAME and A records).&nbsp;&nbsp;To state that LSID resolution is independent<br>of DNS is a bit misleading since the entire basis of LSIDs and their<br>functional utility beyond what can be provided by HTTP uris comes<br>down to their current use of DNS SRV records for service discovery.
<br><br>The only negative with LSIDs that I see is the fact that it is a<br>relatively unknown and so essentially un-implemented protocol.&nbsp;&nbsp;This<br>makes interoperability with the vast majority of existing<br>infrastructure more difficult than it needs to be without offering
<br>any advance in functionality.&nbsp;&nbsp;The use of LSID proxy services,<br>essentially turning LSIDs into URLs is an obvious and welcome<br>solution, but begs the question of what is really gained by the extra<br>step of using LSID URIs rather than HTTP URIs?
<br><br>Perhaps the real benefit is simply that they (LSIDs) look different,<br>which implies that they need to be handled differently than a typical<br>URL, and so people and services know immediately to ask a resolver to
<br>return bits (metadata or data) identified by the GUID.&nbsp;&nbsp;The problem<br>with this of course is that existing services and applications won&#39;t<br>know what to do with them since they are implemented to only<br>understand http (or perhaps a couple other schemes), and so need to
<br>be re-engineered to handle LSIDs unless the LSIDs are wrapped in HTTP<br>URLs...&nbsp;&nbsp;One could also argue that it is the context in which an<br>identifier appears that really indicates what is an identifier rather<br>than just a string - so in practice the visual appearance of a GUID
<br>shouldn&#39;t matter.<br><br>Perhaps an adequate solution is to use LSIDs and provide definitive<br>guidelines indicating how they can be embedded in URLs so that we do<br>not loose interoperability with the rest of the world?&nbsp;&nbsp;This is
<br>probably much like Ricardo&#39;s LSID proxy proposal.&nbsp;&nbsp;Except in my<br>opinion it should be extended further to be a general GUID resolver<br>to help resolve whatever form is used for GUIDs - then one could<br>embed a handle, LSID, HTTP URI, FTP URI, LDAP URI, or even, for the
<br>ancients of the internet, z39.50 URIs in a resolver proxy URL and get<br>something back.&nbsp;&nbsp;The problem of course is that the content that comes<br>back will be different for different protocols - but it would, I<br>suspect be possible to provide a generic form of metadata for the
<br>different protocols.<br><br>It would be pretty simple to add some provenance handling to such a<br>service so that if a particular web server, ftp server, or even LSID<br>system were moved, then the resolver service could lookup the new
<br>location information and appropriately service the request.<br><br>There should of course be multiple instances of such a resolver<br>service, and the provenance information should be shared and<br>replicated between them all.
<br><br>Dave V.<br><br>On Jun 6, 2007, at 15:13, Bob Morris wrote:<br><br>&gt; I&#39;m confused about what arguments in this thread are about the merits<br>&gt; of HTTP (e.g. content negotiation) and what are about the merits of
<br>&gt; DNS (e.g. resource and service location). The fact that most humans<br>&gt; usually exploit these together is because most humans use web browsers<br>&gt; for discovering resources doesn&#39;t have much to do with GUIDs. Even
<br>&gt; LSID resolution itself is actually independent of anything to do with<br>&gt; DNS, although all current resolvers are based on DNS services.<br>&gt;<br>&gt; OK, I confess to not reading all the arguments in detail, but my
<br>&gt; impression is that several of the opposite conclusions from the same<br>&gt; facts may because one set of conclusions is about service discovery<br>&gt; and one is about (meta)data provision. It won&#39;t surprise me if ANY
<br>&gt; guid scheme is stronger about one of these than the other. This might<br>&gt; be what Donald is arguing.<br>&gt;<br>&gt; Bob<br>&gt;<br>&gt; On 6/6/07, Dave Vieglais &lt;<a href="mailto:vieglais@ku.edu" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
vieglais@ku.edu
</a>&gt; wrote:<br>&gt;&gt; This discussion has been very interesting reading, and though I agree<br>&gt;&gt; with Donald&#39;s comments, I find myself coming to a different<br>&gt;&gt; conclusion, leaning towards HTTP URIs as a preferable scheme.&nbsp;&nbsp;The
<br>&gt;&gt; reasons are simple - HTTP has been around for a long time, it is<br>&gt;&gt; widely implemented, and mechanisms for implementing robust services<br>&gt;&gt; with that protocol are pretty well sorted out - and really there is
<br>&gt;&gt; nothing to stop implementation of the same functionality exhibited by<br>&gt;&gt; LSIDs using HTTP.&nbsp;&nbsp;As Rod has pointed out, http is widely used for<br>&gt;&gt; referencing entities within a semantic web type of context, and it
<br>&gt;&gt; seems foolish to ignore the momentum in those technologies as they<br>&gt;&gt; provide a great deal of the desired functionality for<br>&gt;&gt; interoperability and interchange of our data.&nbsp;&nbsp;As a result my<br>

&gt;&gt; preference is towards the use of http, primarily because my intents<br>&gt;&gt; are to integrate data from a much broader community.&nbsp;&nbsp;In the end<br>&gt;&gt; though, it doesn&#39;t really matter which scheme is adopted by TDWG - we
<br>&gt;&gt; will build http resolvers regardless, since they will be necessary<br>&gt;&gt; for reasons of convenience in order to utilize LSIDs in all but<br>&gt;&gt; specific, custom built applications.<br>&gt;&gt;<br>
&gt;&gt; However, regardless of the scheme used to implement the GUIDs used by
<br>&gt;&gt; this community, it is critical that the identifiers are persistent<br>&gt;&gt; and useful beyond the lives of whatever services are constructed to<br>&gt;&gt; resolve them.&nbsp;&nbsp;This implies some provenance information may need to
<br>&gt;&gt; be captured, and I would argue that the use of DNS alone for handling<br>&gt;&gt; server changes as utilized by LSIDs may be insufficient.&nbsp;&nbsp;The only<br>&gt;&gt; benefit provided by DNS in this context is that it is acting as a
<br>&gt;&gt; single source of authority for directing how to locate something (in<br>&gt;&gt; this case an ip address).&nbsp;&nbsp;What I suspect is really required is a<br>&gt;&gt; more robust, and richer mechanism for discovering and recording
<br>&gt;&gt; provenance.&nbsp;&nbsp;The ideal would be a large, replicated, and distributed<br>&gt;&gt; data store with a single service point which provided people and<br>&gt;&gt; systems with a one-stop shop for discovering provenance for a GUID.
<br>&gt;&gt; Then if an particular GUID could not be directly resolved, the global<br>&gt;&gt; provenance store could be consulted and the resulting information<br>&gt;&gt; providing a pointer (or perhaps a series of pointers) indicating how
<br>&gt;&gt; the guid can now be resolved.<br>&gt;&gt;<br>&gt;&gt; By creating such provenance records and persisting them with as much<br>&gt;&gt; care as the data, it seems that a system with stability beyond the<br>&gt;&gt; vagaries of the internet could reasonably be constructed.
<br>&gt;&gt;<br>&gt;&gt; regards,<br>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;Dave V.<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt; On Jun 6, 2007, at 00:46, Donald Hobern wrote:<br>&gt;&gt;<br>&gt;&gt; &gt; Yesterday was a vacation here in Denmark - otherwise I&#39;d have
<br>&gt;&gt; &gt; responded a little earlier, but I&#39;m glad to see all the comments<br>&gt;&gt; &gt; from others.&nbsp;&nbsp;I thoroughly agree with Kevin, Jason, Rich and Anna.<br>&gt;&gt; &gt; No one here believes that any particular solution is going to be
<br>&gt;&gt; &gt; perfect.&nbsp;&nbsp;Our biggest need is consensus and the readiness to get<br>&gt;&gt; &gt; going with a workable solution.<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; I do recognise the strength of Rod&#39;s arguments.&nbsp;&nbsp;Indeed, if I were
<br>&gt;&gt; &gt; building some system for integrating data using semantic web<br>&gt;&gt; &gt; technologies, and my only concern was ensuring the efficiency of<br>&gt;&gt; &gt; synchronous connections now, I am sure I would adopt HTTP URIs for
<br>&gt;&gt; &gt; the purpose.&nbsp;&nbsp;However I remain convinced (as I&#39;ve stated before)<br>&gt;&gt; &gt; that the needs of this community do subtly shift the balance in<br>&gt;&gt; &gt; another direction.&nbsp;&nbsp;We are interested in maintaining long-term
<br>&gt;&gt; &gt; connections between our objects and have a perspective which goes<br>&gt;&gt; &gt; back hundreds of years.&nbsp;&nbsp;This at least should give us pause over<br>&gt;&gt; &gt; whether we want our specimens to be referenced using identifiers so
<br>&gt;&gt; &gt; firmly tied to the Internet of today.&nbsp;&nbsp;More importantly, one of the<br>&gt;&gt; &gt; key drivers right at the beginning of TDWG&#39;s consideration of GUIDs<br>&gt;&gt; &gt; was that the community had plenty of experience of URL rot and
<br>&gt;&gt; &gt; didn&#39;t want to rely on everyone maintaining stable virtual<br>&gt;&gt; &gt; directories on their web servers to preserve the integrity of<br>&gt;&gt; &gt; object identifiers.<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; Both LSIDs and HTTP URIs could be made to work for us.&nbsp;&nbsp;Both are
<br>&gt;&gt; &gt; totally reliant on good practice on the part of data owners.<br>&gt;&gt; &gt; Personally I believe our chances of getting the community to<br>&gt;&gt; &gt; consider, define and apply such practices are enhanced by the
<br>&gt;&gt; &gt; identifier technology being something a little more different and<br>&gt;&gt; &gt; distinct than just a &quot;special URL&quot;.<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; Thanks,<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; Donald
<br>&gt;&gt; &gt; ------------------------------------------------------------<br>&gt;&gt; &gt; Donald Hobern (<a href="mailto:dhobern@gbif.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">dhobern@gbif.org
</a>)<br>&gt;&gt; &gt; Deputy Director for Informatics<br>&gt;&gt; &gt; Global Biodiversity Information Facility Secretariat
<br>&gt;&gt; &gt; Universitetsparken 15, DK-2100 Copenhagen, Denmark<br>&gt;&gt; &gt; Tel: +45-35321483&nbsp;&nbsp; Mobile: +45-28751483&nbsp;&nbsp; Fax: +45-35321480<br>&gt;&gt; &gt; ------------------------------------------------------------
<br>&gt;&gt; &gt;<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; On Jun 6, 2007, at 12:51 AM, Kevin Richards wrote:<br>&gt;&gt; &gt;<br>&gt;&gt; &gt;&gt; I agree with Jason.&nbsp;&nbsp;It is not the GUID that is the cause of all<br>&gt;&gt; &gt;&gt; the problems here - THERE IS NOTHING WRONG WITH LSIDS - we just
<br>&gt;&gt; &gt;&gt; need to move on and start using them in our own context&nbsp;&nbsp;(or any<br>&gt;&gt; &gt;&gt; other suitable GUID - LSIDs are only the recommended GUID, NOT the<br>&gt;&gt; &gt;&gt; only premissable GUID).<br>

&gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; If it all falls to pieces later on we could just do a search and<br>&gt;&gt; &gt;&gt; replace to change all our GUIDs to some other scheme (to quote<br>&gt;&gt; &gt;&gt; Bob, just serious).
<br>&gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; I agree, it is the RDF/metadata/ontologies that are the key to<br>&gt;&gt; &gt;&gt; getting things working well.<br>&gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; Kevin<br>&gt;&gt; &gt;&gt;
<br>&gt;&gt; &gt;&gt;&gt;&gt;&gt; &quot;Jason Best&quot; &lt;<a href="mailto:jbest@brit.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">jbest@brit.org</a>&gt; 06/06/07 8:39 AM &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt; Rod,<br>&gt;&gt; &gt;&gt; I&#39;ve only had a chance to quickly skim the documents you
<br>&gt;&gt; &gt;&gt; reference, but it seems to me that the alternatives to LSIDs don&#39;t<br>&gt;&gt; &gt;&gt; necessarily make the issues with which we are wrestling go away.<br>&gt;&gt; &gt;&gt; We still need to decide WHAT a URI references - is it the
<br>&gt;&gt; &gt;&gt; metadata, the physical object etc? URIs don&#39;t explicitly require<br>&gt;&gt; &gt;&gt; persistance, while LSIDs do so I see that as a positive for<br>&gt;&gt; &gt;&gt; adopting a standard GUID that is explicit in that regard. I think
<br>&gt;&gt; &gt;&gt; the TDWG effort to spec an HTTP proxy for LSIDs makes it clear<br>&gt;&gt; &gt;&gt; that the technical hurdles of implementing an LSID resolver (SVR<br>&gt;&gt; &gt;&gt; records, new protocol, client limitations etc) are a bit
<br>&gt;&gt; &gt;&gt; cumbersome, but I don&#39;t think the underlying concept is fatally<br>&gt;&gt; &gt;&gt; flawed. In reading these discussions, I&#39;m starting to believe/<br>&gt;&gt; &gt;&gt; understand that RDF may hold the key, regardless of the GUID that
<br>&gt;&gt; &gt;&gt; is implemented. Now I have to go read up more on RDF to see if my<br>&gt;&gt; &gt;&gt; new-found belief has merit! ;)<br>&gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; Jason<br>&gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; ________________________________
<br>&gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; From: Roderic Page [mailto:<a href="mailto:r.page@bio.gla.ac.uk" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">r.page@bio.gla.ac.uk</a>]<br>&gt;&gt; &gt;&gt; Sent: Tuesday, June 05, 2007 2:10 PM
<br>&gt;&gt; &gt;&gt; To: Chuck Miller
<br>&gt;&gt; &gt;&gt; Cc: Bob Morris; Kevin Richards; <a href="mailto:tdwg-guid@lists.tdwg.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">tdwg-guid@lists.tdwg.org</a>;<br>&gt;&gt; &gt;&gt; <a href="mailto:WEITZMAN@si.edu" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
WEITZMAN@si.edu</a>; Jason Best<br>&gt;&gt; &gt;&gt; Subject: Re: [tdwg-guid] First step in implementing LSIDs?
<br>&gt;&gt; [Scanned]<br>&gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; Maybe it&#39;s time to bite the bullet and consider the elephant in<br>&gt;&gt; &gt;&gt; the room -- LSIDs might not be what we want. Markus D�ring sent
<br>&gt;&gt; &gt;&gt; some nice references to the list in April, which I&#39;ve repeated<br>&gt;&gt; &gt;&gt; below, there is also <a href="http://dx.doi.org/10.1109/MIS.2006.62" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://dx.doi.org/10.1109/MIS.2006.62</a> .
<br>&gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; I think the LSID debate is throwing up issues which have been<br>&gt;&gt; &gt;&gt; addressed elsewhere (e.g., identifiers for physical things versus<br>&gt;&gt; &gt;&gt; digital records), and some would argue have been solved to at
<br>&gt;&gt; &gt;&gt; least some people&#39;s satisfaction.<br>&gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; LSIDs got us thinking about RDF, which is great. But otherwise I<br>&gt;&gt; &gt;&gt; think they are making things more complicated than they need to
<br>&gt;&gt; &gt;&gt; be. I think this community is running a grave risk of committing<br>&gt;&gt; &gt;&gt; to a technology that nobody else takes that seriously (hell, even<br>&gt;&gt; &gt;&gt; the <a href="http://lsid.sourceforge.net/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">

http://lsid.sourceforge.net/</a> web site is broken).<br>&gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; The references posted by Markus D�ring&nbsp;&nbsp;were:<br>&gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; (1) <a href="http://www.dfki.uni-kl.de/dfkidok/publications/TM/07/01/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">

http://www.dfki.uni-kl.de/dfkidok/publications/TM/07/01/</a><br>&gt;&gt; &gt;&gt; tm-07-01.pdf<br>&gt;&gt; &gt;&gt; &quot;Cool URIs for the Semantic Web&quot; by Leo Sauermann DFKI GmbH,<br>&gt;&gt; &gt;&gt; Richard Cyganiak Freie Universit�t Berlin (D2R author), Max V�lkel
<br>&gt;&gt; &gt;&gt; FZI Karlsruhe<br>&gt;&gt; &gt;&gt; The authors of this document come from the semantic web community<br>&gt;&gt; &gt;&gt; and discuss what kind of URIs should be used for RDF resources.<br>&gt;&gt; &gt;&gt;
<br>&gt;&gt; &gt;&gt; (2) <a href="http://www.w3.org/2001/tag/doc/URNsAndRegistries-50" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.w3.org/2001/tag/doc/URNsAndRegistries-50</a><br>&gt;&gt; &gt;&gt; This one here is written by the W3C and addresses the questions
<br>&gt;&gt; &gt;&gt; &quot;When should URNs or URIs with novel URI schemes be used to name<br>&gt;&gt; &gt;&gt; information resources for the Web?&quot; The answers given are &quot;Rarely<br>&gt;&gt; &gt;&gt; if ever&quot; and &quot;Probably not&quot;. Common arguments in favor of such
<br>&gt;&gt; &gt;&gt; novel naming schemas are examined, and their properties compared<br>&gt;&gt; &gt;&gt; with those of the existing http: URI scheme.<br>&gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; Regards
<br>&gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; Rod<br>&gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<br>&gt;&gt; +++<br>&gt;&gt; &gt;&gt; +++++++++
<br>&gt;&gt; &gt;&gt; WARNING: This email and any attachments may be confidential and/or<br>&gt;&gt; &gt;&gt; privileged. They are intended for the addressee only and are not<br>&gt;&gt; &gt;&gt; to be read,<br>&gt;&gt; &gt;&gt; used, copied or disseminated by anyone receiving them in error.
<br>&gt;&gt; &gt;&gt; If you are<br>&gt;&gt; &gt;&gt; not the intended recipient, please notify the sender by return<br>&gt;&gt; &gt;&gt; email and<br>&gt;&gt; &gt;&gt; delete this message and any attachments.<br>&gt;&gt; &gt;&gt;
<br>&gt;&gt; &gt;&gt; The views expressed in this email are those of the sender and<br>&gt;&gt; do not<br>&gt;&gt; &gt;&gt; necessarily reflect the official views of Landcare Research.<br>&gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; Landcare Research
<br>&gt;&gt; &gt;&gt; <a href="http://www.landcareresearch.co.nz" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.landcareresearch.co.nz</a><br>&gt;&gt; &gt;&gt; ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
<br>&gt;&gt; +++<br>&gt;&gt; &gt;&gt; +++++++++
<br>&gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; _______________________________________________<br>&gt;&gt; &gt;&gt; tdwg-guid mailing list<br>&gt;&gt; &gt;&gt; <a href="mailto:tdwg-guid@lists.tdwg.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
tdwg-guid@lists.tdwg.org
</a><br>&gt;&gt; &gt;&gt; <a href="http://lists.tdwg.org/mailman/listinfo/tdwg-guid" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://lists.tdwg.org/mailman/listinfo/tdwg-guid</a><br>&gt;&gt; &gt;&gt;
<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; _______________________________________________
<br>&gt;&gt; &gt; tdwg-guid mailing list<br>&gt;&gt; &gt; <a href="mailto:tdwg-guid@lists.tdwg.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">tdwg-guid@lists.tdwg.org</a><br>&gt;&gt; &gt; <a href="http://lists.tdwg.org/mailman/listinfo/tdwg-guid" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://lists.tdwg.org/mailman/listinfo/tdwg-guid
</a><br>&gt;&gt;<br>&gt;&gt; _______________________________________________<br>&gt;&gt; tdwg-guid mailing list<br>&gt;&gt; <a href="mailto:tdwg-guid@lists.tdwg.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
tdwg-guid@lists.tdwg.org</a><br>&gt;&gt; <a href="http://lists.tdwg.org/mailman/listinfo/tdwg-guid" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://lists.tdwg.org/mailman/listinfo/tdwg-guid</a><br>&gt;&gt;<br><br>_______________________________________________<br>tdwg-guid mailing list<br><a href="mailto:tdwg-guid@lists.tdwg.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
tdwg-guid@lists.tdwg.org</a><br>
<a href="http://lists.tdwg.org/mailman/listinfo/tdwg-guid" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://lists.tdwg.org/mailman/listinfo/tdwg-guid</a><br></blockquote></div><br><br clear="all">
<br>-- <br>---------------------------------------------------------------
<br>Pete DeVries<br>Department of Entomology<br>University of Wisconsin - Madison<br>445 Russell Laboratories<br>1630 Linden Drive<br>Madison, WI 53706<br>------------------------------------------------------------