Hi Joel,<div><br></div><div>Maybe we can do the hackathon virtually so that there is some progress by the time of the meeting.</div><div><br></div><div>A lot of this could be done via email and perhaps a videoconference or two.</div>
<div><br></div><div>- Pete<br><br><div class="gmail_quote">On Tue, May 10, 2011 at 8:06 AM, joel sachs <span dir="ltr">&lt;<a href="mailto:jsachs@csee.umbc.edu">jsachs@csee.umbc.edu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Tue, 10 May 2011, Greg Whitbread wrote:<br>
<br>
&gt; Kevin,<br>
&gt;<br>
&gt; I&#39;m not too keen on the hack-a-thon idea.  It will in all probability<br>
&gt; just consume important contact time with activity that is best<br>
&gt; integrated into real projects and reported in a forum such as this or at<br>
&gt; the TDWG meeting. Much in the way that Steve and Cam and Pete and Paul<br>
&gt; are doing now.<br>
&gt;<br>
<br>
</div>Hi Greg,<br>
<br>
The conversation that&#39;s going on now is useful. But something is<br>
missing, namely reference to the use cases and competency questions that<br>
we sometimes talk about generating. Hackathons focus the mind (I&#39;ve seen<br>
it happen), and a DwC-RDF VoCamp/hackathon would be an opportunity to move<br>
forward on stuff that keeps getting deferred. Ideally, we&#39;d define the<br>
competency questions in advance, and spend the hackathon addressing them.<br>
But, if we all turn out to be lazy/indifferent/&quot;busy&quot;,<br>
and come to New Orleans without use cases, then spending cloister time<br>
working them out would, IMHO, be cloister time well spent.<br>
<br>
There are any number of possible approaches we could take. We could have<br>
an integration competition; we could rely on digitization efforts to<br>
supply data; we could tie the hackathon into observations from a field<br>
event; we could explore how the work of the observation and annotation<br>
task groups interact with DwC in a semantic web context; we can do<br>
anything we want!<br>
<br>
I encourage anyone with a vision of how such an event might unfold to<br>
share it, on or off list, so that the program committee can discuss it.<br>
(And it would be great, as Kevin suggested, if someone steps forward as a spearhead.)<br>
<font color="#888888"><br>
Joel.<br>
</font><div><div></div><div class="h5"><br>
<br>
&gt; We (you and I ) have drafted a proposal to put to TDWG executive for a<br>
&gt; 2-3 day workshop prior to this years meeting to establish context for<br>
&gt; these issues within the framework of a TDWG Technical Architecture.  Do<br>
&gt; we need to evolve a TDWG level understanding of the requirement for<br>
&gt; semantic interoperability within our standards space? Would it be useful<br>
&gt; to spend time and effort to formally model the TDWG domain? Is there a<br>
&gt; role for TAG? Can we improve the process?<br>
&gt;<br>
&gt; Hopefully, we can find an opportunity to get a small group together<br>
&gt; between now and then do a little planning around agenda, background<br>
&gt; requirements, preparation workload and specialist inputs.<br>
<br>
&gt; greg<br>
&gt;<br>
&gt; On Tue, 2011-05-10 at 07:26, Kevin Richards wrote:<br>
&gt;&gt; I wonder if it would be a good idea to have a session (hackathon?) at<br>
&gt;&gt; this years TDWG meeting to look at / prove / experiment with, the<br>
&gt;&gt; various ways of working with semantic web data and ontologies we<br>
&gt;&gt; discuss here?<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; This would soon show any benefits/disadvantages etc of the various<br>
&gt;&gt; approaches.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Is anyone lined up / keen to promote such a session?<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Kevin<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; From: <a href="mailto:tdwg-content-bounces@lists.tdwg.org">tdwg-content-bounces@lists.tdwg.org</a><br>
&gt;&gt; [mailto:<a href="mailto:tdwg-content-bounces@lists.tdwg.org">tdwg-content-bounces@lists.tdwg.org</a>] On Behalf Of Steve<br>
&gt;&gt; Baskauf<br>
&gt;&gt; Sent: Tuesday, 10 May 2011 8:54 a.m.<br>
&gt;&gt; To: Paul Murray<br>
&gt;&gt; Cc: <a href="mailto:tdwg-content@lists.tdwg.org">tdwg-content@lists.tdwg.org</a> List<br>
&gt;&gt; Subject: Re: [tdwg-content] Heretics and illuminati, oh my!<br>
&gt;&gt; [SEC=UNCLASSIFIED]<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Being either fearless or a fool (is there actually a difference?), I<br>
&gt;&gt; shall tread into this subject area at which I am a mere novice.  So be<br>
&gt;&gt; kind...<br>
&gt;&gt;<br>
&gt;&gt; I think that there may be several &quot;solutions&quot; to this problem.  The<br>
&gt;&gt; one that is &quot;correct&quot; probably depends on what one is trying to<br>
&gt;&gt; accomplish.  So I will try to describe in the most succinct way what<br>
&gt;&gt; Cam and I were trying to accomplish with DSW, and how that fits in<br>
&gt;&gt; with this thread.  Cam and I basically wanted to do two things:<br>
&gt;&gt; 1. Make it possible to use GUIDs RIGHT NOW (not five years from now).<br>
&gt;&gt; 2. Create an extremely stripped down ontology that would be<br>
&gt;&gt; non-controversial enough that people might actually use it, but which<br>
&gt;&gt; wouldn&#39;t do anything so bad that it would inhibit future development<br>
&gt;&gt; in the Semantic Web context (i.e. it could be extended in the future<br>
&gt;&gt; by clever people to do clever Semantic Web stuff).<br>
&gt;&gt;<br>
&gt;&gt; Amazingly, the GUID Applicability Statement has achieved the status of<br>
&gt;&gt; Standard-hood! (<a href="http://www.tdwg.org/standards/150/" target="_blank">http://www.tdwg.org/standards/150/</a>)  Hooray!  I sort<br>
&gt;&gt; of missed the announcement, but ran across the fact the other day when<br>
&gt;&gt; I was surfing through the TDWG website.  Since the GUID A.S. is now a<br>
&gt;&gt; TDWG Standard, I would say it would now officially be a best-practice<br>
&gt;&gt; to follow it.  In particular, Recommendation 11 states &quot;Objects in the<br>
&gt;&gt; biodiversity domain that are identified by a GUID should be typed<br>
&gt;&gt; using the TDWG ontology or other well-known vocabularies in accordance<br>
&gt;&gt; with the TDWG common architecture.&quot;  This is somewhat problematic,<br>
&gt;&gt; given that the TDWG ontology (with the possible exception of the<br>
&gt;&gt; Taxon/TaxonConcept part) is effectively (&quot;socially&quot;?) deprecated.<br>
&gt;&gt; What is the alternative &quot;other well-known vocabulary&quot;?  There is none,<br>
&gt;&gt; at least none having any kind of official status with TDWG.<br>
&gt;&gt;<br>
&gt;&gt; I recently discovered (or maybe re-discovered) the Technical<br>
&gt;&gt; Architecture Group (TAG) Technical Roadmaps from 2006-2008:<br>
&gt;&gt; <a href="http://www.tdwg.org/uploads/media/TAG_Roadmap_01.doc" target="_blank">http://www.tdwg.org/uploads/media/TAG_Roadmap_01.doc</a><br>
&gt;&gt; <a href="http://www.tdwg.org/fileadmin/subgroups/tag/TAG_Roadmap_2007_final.pdf" target="_blank">http://www.tdwg.org/fileadmin/subgroups/tag/TAG_Roadmap_2007_final.pdf</a><br>
&gt;&gt; <a href="http://www.tdwg.org/fileadmin/subgroups/tag/TAG_Roadmap_2008.pdf" target="_blank">http://www.tdwg.org/fileadmin/subgroups/tag/TAG_Roadmap_2008.pdf</a><br>
&gt;&gt; I might have seen them before, but if so it was at the point where I<br>
&gt;&gt; was really not knowledgeable enough to comprehend them.  I found it<br>
&gt;&gt; very instructive to read about what the TAG had in mind when it set<br>
&gt;&gt; out to create the TDWG Ontology.  In particular (from the 2007<br>
&gt;&gt; Roadmap):<br>
&gt;&gt; &quot;From the point of view of exchanging data - such as in the federation<br>
&gt;&gt; of a number of natural history collections - there is no need for a<br>
&gt;&gt; standards architecture.  The federation is a closed system where a<br>
&gt;&gt; single exchange format can be agreed on. ... This model has worked<br>
&gt;&gt; well in the past but it does not meet the primary use case that is<br>
&gt;&gt; emerging.  Biodiversity research is typically carried out by combining<br>
&gt;&gt; data of different kinds from multiple sources. The providers of data<br>
&gt;&gt; do not know who will use their data or how it will be combined with<br>
&gt;&gt; data from other sources. The consumer needs some level of commonality<br>
&gt;&gt; across all the data received so that it can be combined for analysis<br>
&gt;&gt; without the need to write computer software for every new<br>
&gt;&gt; combination.&quot; [This brings to mind the very &quot;different kinds&quot; of<br>
&gt;&gt; resources Cam is documenting in Borneo and the &quot;multiple sources&quot; that<br>
&gt;&gt; will be handling the metadata once those resources are sent off to<br>
&gt;&gt; herbaria, labs, and arboreta.]<br>
&gt;&gt;<br>
&gt;&gt; and from the 2008 Roadmap:<br>
&gt;&gt; &quot;If GUIDs are used to uniquely identify &#39;pieces&#39; of data we need to<br>
&gt;&gt; have a shared understanding of what we mean by a &#39;piece of data&#39; i.e.<br>
&gt;&gt; what kind of thing is it that a particular id applies to, a specimen,<br>
&gt;&gt; a person, an observation, a complete data set. We also need to have a<br>
&gt;&gt; shared understanding of at least some of the properties we use to<br>
&gt;&gt; describe these things.&quot;<br>
&gt;&gt;<br>
&gt;&gt; Having been barely aware of TDWG&#39;s existence in 2008, I am blissfully<br>
&gt;&gt; ignorant of whatever disagreements may have occurred regarding LSIDs,<br>
&gt;&gt; reification, or whatever, and really don&#39;t want to know about them.<br>
&gt;&gt; All I can say as an outside observer is that it appears that the<br>
&gt;&gt; failure of the initial efforts to get GUIDs and the TDWG Ontology off<br>
&gt;&gt; the ground was because the system envisioned was too complicated to<br>
&gt;&gt; maintain, too complicated to gain a consensus, and to complicated to<br>
&gt;&gt; actually explain to anybody.  Now that GUIDs seem to have a new lease<br>
&gt;&gt; on life, it seems like the greatest chance of successfully<br>
&gt;&gt; implementing them is to start by keeping things absolutely as simple<br>
&gt;&gt; as possible.  To Cam and me, Darwin Core seemed to be the only<br>
&gt;&gt; candidate for something relatively simple and relatively universally<br>
&gt;&gt; accepted on which one could base an ontology that could be used to<br>
&gt;&gt; type GUIDs and to use to express &quot;a shared understanding of at least<br>
&gt;&gt; some of the properties used to describe&quot; biodiversity resources.<br>
&gt;&gt; Although I was somewhat skeptical that there was a &quot;community<br>
&gt;&gt; consensus&quot; about what the DwC classes meant and how they were related<br>
&gt;&gt; to each other, the exhaustive discussion on this list in Oct/Nov<br>
&gt;&gt; convinced me that maybe there WAS a consensus, or at least enough of a<br>
&gt;&gt; consensus to move forward.  Although some people may at the present<br>
&gt;&gt; time be interested in figuring out how to do things like &quot;define<br>
&gt;&gt; &#39;Fish&#39; as an owl class as well as as a Taxon object&quot;, I would assert<br>
&gt;&gt; that is outside the core mission of TDWG as stated: to &quot;develop, adopt<br>
&gt;&gt; and promote standards and guidelines for the recording and exchange of<br>
&gt;&gt; data about organisms evidenced by the historical record&quot;.  It is fun<br>
&gt;&gt; to talk about, but to me not the primary consideration in designing a<br>
&gt;&gt; community data exchange model.  This outlook explains to some extent<br>
&gt;&gt; why I asked questions about the complexity of <a href="http://taxonconcept.org" target="_blank">taxonconcept.org</a> and its<br>
&gt;&gt; orientation toward facilitating semantic queries.  There is nothing<br>
&gt;&gt; wrong with that, but it doesn&#39;t seem to be the direction that TDWG has<br>
&gt;&gt; said it wants to go.  Perhaps when we have &quot;gotten there&quot; (i.e. have a<br>
&gt;&gt; functioning system using GUIDs for clearly typed resources), we might<br>
&gt;&gt; want to embark further down the road to the Semantic Web.<br>
&gt;&gt;<br>
&gt;&gt; Aside from just importing the DwC classes into the DSW ontology and<br>
&gt;&gt; connecting them with object properties, Cam and I did a little nasty<br>
&gt;&gt; thing with them.  It has been said that declaring ranges and domains<br>
&gt;&gt; for terms doesn&#39;t prevent people from using the terms to express<br>
&gt;&gt; relationships among the &quot;wrong&quot; types of things.  Rather, it simply<br>
&gt;&gt; asserts that those things are instances of the classes used in the<br>
&gt;&gt; range and domain declarations for the term.  That is sort of true, but<br>
&gt;&gt; by declaring many of the core DwC classes to be disjoint, we actually<br>
&gt;&gt; ARE preventing people from using the wrong object properties with<br>
&gt;&gt; instances of the wrong classes.  If  Joe Curator rdf:type&#39;s a<br>
&gt;&gt; determination as a dwc:Identification, but then uses dsw:atEvent<br>
&gt;&gt; (which has the domain dwc:Occurrence) as a property of the<br>
&gt;&gt; determination, then a reasoner will infer that the determination is a<br>
&gt;&gt; type dwc:Occurrence as well as the explicitly declared type<br>
&gt;&gt; dwc:Identification.  Because dwc:Identification and dwc:Occurrence are<br>
&gt;&gt; disjoint classes, the reasoner will have a fit.  Cam and I are being<br>
&gt;&gt; Naughty (sensu Bob Morris) because we are inhibiting the extensibility<br>
&gt;&gt; of dsw:atEvent, but Joe Curator is being Naughty (sensu Baskauf and<br>
&gt;&gt; Webb) because Cam and I believe in the statement from the 2007<br>
&gt;&gt; Roadmap: &quot;The consumer needs some level of commonality across all the<br>
&gt;&gt; data received...&quot;.  Joe Curator is not being consistent with the<br>
&gt;&gt; &quot;shared understanding of at least some of the properties&quot; to the<br>
&gt;&gt; extent that DSW reflects the &quot;shared understanding&quot; of the TDWG<br>
&gt;&gt; community.  We are basically trying to enforce a sort of orthodoxy on<br>
&gt;&gt; the use of DwC classes as rdf:types and on the connections between the<br>
&gt;&gt; dwc:classes so that people can have some reasonable expectation that<br>
&gt;&gt; they are talking the same language as their partners whose data are<br>
&gt;&gt; also being aggregated in the same federated database.<br>
&gt;&gt;<br>
&gt;&gt; It seems to me that this &quot;enforcement of orthodoxy&quot; may be very much<br>
&gt;&gt; at odds with the free-wheeling spirit of the Semantic Web community<br>
&gt;&gt; where Anybody Can Say Anything About Anything.  But when I look over<br>
&gt;&gt; those old TAG roadmaps, I see little having to do with clever Semantic<br>
&gt;&gt; inferencing.  I see a lot about providers and consumers understanding<br>
&gt;&gt; what each other are talking about.  To some extent, Darwin Core can<br>
&gt;&gt; provide most of the necessary commonality between providers and<br>
&gt;&gt; consumers.  There were (in our opinion) three areas where it could<br>
&gt;&gt; not.  One was the lack of a class to link repeated sampling events and<br>
&gt;&gt; determinations (dwc:IndividualOrganism or<br>
&gt;&gt; TaxonomicallyHomogeneousEntity if you prefer) and another was a class<br>
&gt;&gt; that allowed for the separation of evidence from the Occurrence<br>
&gt;&gt; documented by it (called by us the dsw:Token class).  The other area<br>
&gt;&gt; was the dwc:Taxon class which did not seem clear enough in its<br>
&gt;&gt; definition nor to possess enough complexity to express the kinds of<br>
&gt;&gt; relationships commonly discussed on this list.  dwc:Taxon needs to be<br>
&gt;&gt; &quot;fixed&quot; before it is Ready For Prime Time (i.e. usable in rdf:type<br>
&gt;&gt; declarations)<br>
&gt;&gt;<br>
&gt;&gt; So I guess having read the various responses to my query and thinking<br>
&gt;&gt; about the history of the TDWG Ontology, I would say that it may not<br>
&gt;&gt; really be important how dwc:Taxon could be tied to tc:Taxon because<br>
&gt;&gt; the two classes probably don&#39;t need to be tied together anyway.  As it<br>
&gt;&gt; currently stands, dwc:Taxon (outside of DSW) has no semantic meaning<br>
&gt;&gt; other than what people want to believe that it means because it&#39;s not<br>
&gt;&gt; tied to any other classes by object properties of its instances.   The<br>
&gt;&gt; mish-mash of terms describing names and taxa listed under dwc:Taxon<br>
&gt;&gt; add to the confusion - since the DwC vocabulary purposefully does not<br>
&gt;&gt; declare domains for the terms listed under a class they really could<br>
&gt;&gt; be used as properties for an instance of any class anywhere.  In<br>
&gt;&gt; contract, tc:Taxon does have properties that are described clearly in<br>
&gt;&gt; the TDWG Ontology.  The only reason that we declared the two classes<br>
&gt;&gt; to be equivalent was to signal that we felt that some of the DwC terms<br>
&gt;&gt; listed under dwc:Taxon in the DwC vocabulary could be used as data<br>
&gt;&gt; properties for the things in the tc:Taxon class that people like Paul<br>
&gt;&gt; were describing with properties from the TDWG Ontology.  Tying them<br>
&gt;&gt; together doesn&#39;t (at the moment) mess up anything that anybody is<br>
&gt;&gt; doing with dwc:Taxon because (outside of DSW) there isn&#39;t anything to<br>
&gt;&gt; actually DO with dwc:Taxon in RDF.  However, the point is well taken<br>
&gt;&gt; that if someone in the future did decide to define properties<br>
&gt;&gt; specifically intended for use with dwc:Taxon, those properties would<br>
&gt;&gt; be hopelessly tangled with tc:Taxon properties.<br>
&gt;&gt;<br>
&gt;&gt; It seems to me like the real road forward (if one believes as I do<br>
&gt;&gt; that DwC is the only practical alternative to use for typing GUIDs)<br>
&gt;&gt; would be to:<br>
&gt;&gt; 1. decide that the TDWG Ontology in its dead form adequately describes<br>
&gt;&gt; taxa, names, and their properties (use it as-is).  OR<br>
&gt;&gt; 2. decide that although the TDWG Ontology doesn&#39;t do everything that<br>
&gt;&gt; people want it to do at the present time, it could resurrected and<br>
&gt;&gt; modified to do what people want (use it and hope for the future).  OR<br>
&gt;&gt; 3. decide to just create the additional classes, e.g. dwc:Name (or<br>
&gt;&gt; dsw:Name if you prefer not to adulterate the &quot;pure&quot; Darwin Core), and<br>
&gt;&gt; object properties for dwc:Taxon and dwc:Name that are needed to get<br>
&gt;&gt; the job done (i.e. just dump the TDWG Ontology as unfixable and make<br>
&gt;&gt; up new stuff).<br>
&gt;&gt;<br>
&gt;&gt; In any of these three alternatives, there isn&#39;t actually any reason to<br>
&gt;&gt; tie the two classes together that I can see.  Of these three, I think<br>
&gt;&gt; the third option would probably be preferable, although it might put<br>
&gt;&gt; Paul (and any others currently using the TDWG Ontology to describe<br>
&gt;&gt; Taxon instances) in the unpleasant position of having to redo their<br>
&gt;&gt; RDF.<br>
&gt;&gt;<br>
&gt;&gt; Steve<br>
&gt;&gt;<br>
&gt;&gt; Paul Murray wrote:<br>
&gt;&gt;<br>
&gt;&gt; On 09/05/2011, at 2:07 PM, Kevin Richards wrote:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;         Paul<br>
&gt;&gt;<br>
&gt;&gt;         I had the same thought (ie the x is of type dwc:Taxon, y is of type tc:Taxon, we know dwc:Taxon and tc:Taxon are equivalent, so we can reasonably compare x and y).<br>
&gt;&gt;         And this is built into standard semantic web reasoners - which is a bonus.<br>
&gt;&gt;         But this was debated (taking into account Bob Morris&#39; issue) with respect to DwC and it was decided the benefits weren&#39;t significantly better than having a &quot;dwc:isInCategory&quot; sort of property that could then be &quot;equivalent to&quot; another class property and therefore giving you a similar advantage (admittedly not as good, but similar).<br>

&gt;&gt;         Do you think this is reasonable or are we just losing too much semantic web benefits by not specifying the domain constraint?<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; A thing to watch out for is that in OWL DL, you cannot apply ordinary data and object properties to vocabulary objects (classes, predicates) - you can only apply annotation properties. If you apply an ordinary data property to a class, OWL DL treats this as what it calls &quot;punning&quot;: it decides that there is a class named X and also a named individual named X, and that these have nothing to do with one another. The individual has properties, the class has members, and the annotation properties, well: whatever. Reasoners do not reason over annotation properties: indeed - that&#39;s the entire point. Attempting to put properties on properties and having classes being instances of classes results in things that are mathematically undecidable (&quot;this statement cannot be proven to be true&quot;).<br>

&gt;&gt;<br>
&gt;&gt; (another reason is that is allows you to put dc:comments and labels on classes, and even if you declare those classes to be equivalent nevertheless the comment only applies to the particular thing you put it on)<br>

&gt;&gt;<br>
&gt;&gt; This all means that dwc:isInCategory, if you want to apply it to dwc:taxon or other classes, will never have any meaning that semweb &quot;engines&quot; can get at. The underlying thing is that dwc:isInCategory is actually a meta-syntactic construct: rather than using owl to define a vocabulary, you are effectively attempting to extend OWL itself.<br>

&gt;&gt;<br>
&gt;&gt; But ... maybe that&#39;s ok. Maybe what is attempting to be done here only ever needs to be understood by humans.<br>
&gt;&gt;<br>
&gt;&gt; Now ... if what you are trying to do is to define &quot;Fish&quot; as an owl class as well as as a Taxon object - that is do-able, even to the point of being able to get inheritance working, using reflexive properties.  At least ... I think it is. I should write a test case.<br>

&gt;&gt; If you have received this transmission in error please notify us immediately by return e-mail and delete all copies. If this e-mail or any attachments have been sent to you in error, that error does not constitute waiver of any confidentiality, privilege or copyright in respect of information in the e-mail or attachments.<br>

&gt;&gt;<br>
&gt;&gt; Please consider the environment before printing this email.<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; tdwg-content mailing list<br>
&gt;&gt; <a href="mailto:tdwg-content@lists.tdwg.org">tdwg-content@lists.tdwg.org</a><br>
&gt;&gt; <a href="http://lists.tdwg.org/mailman/listinfo/tdwg-content" target="_blank">http://lists.tdwg.org/mailman/listinfo/tdwg-content</a><br>
&gt;&gt; .<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; --<br>
&gt;&gt; Steven J. Baskauf, Ph.D., Senior Lecturer<br>
&gt;&gt; Vanderbilt University Dept. of Biological Sciences<br>
&gt;&gt;<br>
&gt;&gt; postal mail address:<br>
&gt;&gt; VU Station B 351634<br>
&gt;&gt; Nashville, TN  37235-1634,  U.S.A.<br>
&gt;&gt;<br>
&gt;&gt; delivery address:<br>
&gt;&gt; 2125 Stevenson Center<br>
&gt;&gt; 1161 21st Ave., S.<br>
&gt;&gt; Nashville, TN 37235<br>
&gt;&gt;<br>
&gt;&gt; office: 2128 Stevenson Center<br>
&gt;&gt; phone: <a href="tel:%28615%29%20343-4582" value="+16153434582">(615) 343-4582</a>,  fax: <a href="tel:%28615%29%20343-6707" value="+16153436707">(615) 343-6707</a><br>
&gt;&gt; <a href="http://bioimages.vanderbilt.edu" target="_blank">http://bioimages.vanderbilt.edu</a><br>
&gt;&gt;<br>
&gt;&gt; ______________________________________________________________________<br>
&gt;&gt; Please consider the environment before printing this email<br>
&gt;&gt; Warning: This electronic message together with any attachments is<br>
&gt;&gt; confidential. If you receive it in error: (i) you must not read, use,<br>
&gt;&gt; disclose, copy or retain it; (ii) please contact the sender<br>
&gt;&gt; immediately by reply email and then delete the emails.<br>
&gt;&gt; The views expressed in this email may not be those of Landcare<br>
&gt;&gt; Research New Zealand Limited. <a href="http://www.landcareresearch.co.nz" target="_blank">http://www.landcareresearch.co.nz</a><br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; ______________________________________________________________________<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; tdwg-content mailing list<br>
&gt;&gt; <a href="mailto:tdwg-content@lists.tdwg.org">tdwg-content@lists.tdwg.org</a><br>
&gt;&gt; <a href="http://lists.tdwg.org/mailman/listinfo/tdwg-content" target="_blank">http://lists.tdwg.org/mailman/listinfo/tdwg-content</a><br>
&gt; --<br>
&gt;<br>
&gt;<br>
&gt; australian centre for plant bIodiversity research&lt;------------------+<br>
&gt; national            greg whitBread             voice: <a href="tel:%2B61%202%2062509%20482" value="+61262509482">+61 2 62509 482</a><br>
&gt; botanic Integrated Botanical Information System  fax: <a href="tel:%2B61%202%2062509%20599" value="+61262509599">+61 2 62509 599</a><br>
&gt; gardens                      S........ I.T. happens.. <a href="mailto:ghw@anbg.gov.au">ghw@anbg.gov.au</a><br>
&gt; +-----------------------------------------&gt;GPO Box 1777 Canberra 2601<br>
&gt;<br>
&gt;<br>
&gt; If you have received this transmission in error please notify us immediately by return e-mail and delete all copies. If this e-mail or any attachments have been sent to you in error, that error does not constitute waiver of any confidentiality, privilege or copyright in respect of information in the e-mail or attachments.<br>

&gt;<br>
&gt; Please consider the environment before printing this email.<br>
&gt; _______________________________________________<br>
&gt; tdwg-content mailing list<br>
&gt; <a href="mailto:tdwg-content@lists.tdwg.org">tdwg-content@lists.tdwg.org</a><br>
&gt; <a href="http://lists.tdwg.org/mailman/listinfo/tdwg-content" target="_blank">http://lists.tdwg.org/mailman/listinfo/tdwg-content</a><br>
&gt;<br>
_______________________________________________<br>
tdwg-content mailing list<br>
<a href="mailto:tdwg-content@lists.tdwg.org">tdwg-content@lists.tdwg.org</a><br>
<a href="http://lists.tdwg.org/mailman/listinfo/tdwg-content" target="_blank">http://lists.tdwg.org/mailman/listinfo/tdwg-content</a><br>
</div></div></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>
Email: <a href="mailto:pdevries@wisc.edu" target="_blank">pdevries@wisc.edu</a><br><a href="http://www.taxonconcept.org/" target="_blank">TaxonConcept</a>  &amp;  <a href="http://about.geospecies.org/" target="_blank">GeoSpecies</a> Knowledge Bases<br>
A Semantic Web, <a href="http://linkeddata.org/" target="_blank">Linked Open Data</a>  Project<br>--------------------------------------------------------------------------------------<br>
</div>