<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style>@font-face {
font-family: Wingdings;
}
@font-face {
font-family: Wingdings;
}
@font-face {
font-family: Calibri;
}
@page WordSection1 {margin: 72.0pt 72.0pt 72.0pt 72.0pt; }
P.MsoNormal {
MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Calibri","sans-serif"; FONT-SIZE: 11pt
}
LI.MsoNormal {
MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Calibri","sans-serif"; FONT-SIZE: 11pt
}
DIV.MsoNormal {
MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Calibri","sans-serif"; FONT-SIZE: 11pt
}
A:link {
COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
COLOR: purple; TEXT-DECORATION: underline
}
P.MsoListParagraph {
MARGIN: 0cm 0cm 0pt 36pt; FONT-FAMILY: "Calibri","sans-serif"; FONT-SIZE: 11pt
}
LI.MsoListParagraph {
MARGIN: 0cm 0cm 0pt 36pt; FONT-FAMILY: "Calibri","sans-serif"; FONT-SIZE: 11pt
}
DIV.MsoListParagraph {
MARGIN: 0cm 0cm 0pt 36pt; FONT-FAMILY: "Calibri","sans-serif"; FONT-SIZE: 11pt
}
SPAN.EmailStyle17 {
FONT-FAMILY: "Calibri","sans-serif"; COLOR: windowtext
}
SPAN.EmailStyle19 {
FONT-FAMILY: "Calibri","sans-serif"; COLOR: windowtext
}
.MsoChpDefault {
}
DIV.WordSection1 {
}
OL {
MARGIN-BOTTOM: 0cm
}
UL {
MARGIN-BOTTOM: 0cm
}
</style>
<meta name="GENERATOR" content="MSHTML 8.00.6001.18928">
<style title="owaParaStyle">P {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</style>
</head>
<body lang="EN-NZ" link="blue" vlink="purple" ocsi="x">
<div dir="ltr"><font color="#000000" size="2" face="Tahoma">I completely agree with you Rich about the 'atoms', and nailing those down first.</font></div>
<div dir="ltr"><font size="2" face="tahoma">This is the ideal situation of course, and could be, I suspect, applied to all name datasets that exist if we persisted enough. There are some cases where they dont have any details about the 'atoms' - in which case
I suppose there would be required a huge effort on behalf of specialists to untangle the mess - but isdoable.</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">I think it would be too restrictive to not apply IDs to the "sets of TNU IDs" though. Especially as this "set" is what is used in a lot of cases to relate to things like distribution, biostatus, vernacular names,
etc. </font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">Perhaps we need a general rule though to not allow a Taxon without a base TNU :-)</font></div>
<div dir="ltr"><font size="3" face="Times New Roman"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">I am also fairly uncomfortable with applying IDs to the reasonably dynamic Taxon, but so long as we tie them to TNUs, we will always have the building blocks to work with.</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">Kevin</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div style="DIRECTION: ltr" id="divRpF27906">
<hr tabindex="-1">
<font size="2" face="Tahoma"><b>From:</b> Richard Pyle [deepreef@bishopmuseum.org]<br>
<b>Sent:</b> Monday, 5 July 2010 7:26 p.m.<br>
<b>To:</b> Kevin Richards; tdwg-content@lists.tdwg.org<br>
<b>Subject:</b> RE: [tdwg-content] Taxon Concept dilemma<br>
</font><br>
</div>
<div></div>
<div>
<div dir="ltr" align="left"><span class="720581407-05072010"><font color="#0000ff" size="2" face="Arial">This is why I'm very uncormfortable with the entire notion of "taxonID". The main reason I'm pushing so hard for taxonNameUsageID's (ala GNUB) is that
these are the "atoms" (as Dave R. calls them) of both nomenclature *and* most existing concept definitions. If we can get permanent and widely shared/re-used IDs on these "atoms", then we can assmble the complex molecules from them. Someone's notion of a
taxon concept then becomes a set of TNUID's. I have mixed feelings about branding these sets with permanent GUIDs; but if we did, this is what I imagine taxonID in DwC would (ultimately) represent. If we want to archive the sets for posterity, then we can
certainly brand them with IDs. But I tend to think these can instead by dynamic services, that assemble the sets either algorithmically, or through the fingertips of experts.</font></span></div>
<div dir="ltr" align="left"><span class="720581407-05072010"><font color="#0000ff" size="2" face="Arial"></font></span> </div>
<div dir="ltr" align="left"><span class="720581407-05072010"><font color="#0000ff" size="2" face="Arial">So...I guess before we do anything, we need to get a common sense for what is intended to be represented by taxonID. I suspect my own view is not shared
by all (or even most).</font></span></div>
<div dir="ltr" align="left"><span class="720581407-05072010"><font color="#0000ff" size="2" face="Arial"></font></span> </div>
<div dir="ltr" align="left"><span class="720581407-05072010"><font color="#0000ff" size="2" face="Arial">Rich</font></span></div>
<br>
<blockquote style="BORDER-LEFT: #0000ff 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px">
<div dir="ltr" lang="en-us" class="OutlookMessageHeader" align="left">
<hr tabindex="-1">
<font size="2" face="Tahoma"><b>From:</b> tdwg-content-bounces@lists.tdwg.org [mailto:tdwg-content-bounces@lists.tdwg.org]
<b>On Behalf Of </b>Kevin Richards<br>
<b>Sent:</b> Sunday, July 04, 2010 5:44 PM<br>
<b>To:</b> tdwg-content@lists.tdwg.org<br>
<b>Subject:</b> [tdwg-content] Taxon Concept dilemma<br>
</font><br>
</div>
<div></div>
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US">Hello all,</span></p>
<p class="MsoNormal"><span lang="EN-US"></span> </p>
<p class="MsoNormal"><span lang="EN-US">I have an issue that I would like some comment on…</span></p>
<p class="MsoNormal"><span lang="EN-US"></span> </p>
<p class="MsoNormal"><span lang="EN-US">We have some data that covers Taxa, Names and Concept relationships.</span></p>
<p class="MsoNormal"><span lang="EN-US">Eg</span></p>
<p style="TEXT-INDENT: -18pt" class="MsoListParagraph"><span>-<span style="FONT: 7pt 'Times New Roman'">
</span></span><span lang="EN-US">A Taxon table that contains the nomenclatural details + accepted name + parent name</span></p>
<p style="TEXT-INDENT: -18pt" class="MsoListParagraph"><span>-<span style="FONT: 7pt 'Times New Roman'">
</span></span><span lang="EN-US">Concept + relationship tables that contain details about the name + references where the name has been used in a taxonomic sense (ie not nomenclatural information) – this is specifically a link between the Name and a Reference</span></p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">We have fairly permanent Ids for the Taxon Name (nomenclatural) and the Concepts, but I now what to consider the ID to cover the whole Taxon (ie the Nomenclatural data + taxon rank + parent name + accepted name, etc, as “we” understand
them). (Probably equivalent to the taxonID in Dwc)</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">The problem is this tends to be much more dynamic data – ie, in this particular case we have aggregated data from a variety of providers and are in continual revision of this data - as we revise the data the details such as the accepted
name may change – this troubles me a bit, because this could be seen as fundamentally changing the definition of the object behind the taxonID. However, I suspect this is a common case that people find themselves in – ie revision/tidying of aggregated datasets
must be quite common.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">I would prefer to NOT change the taxonID every time we revise that data (taking the angle that these changes are corrections, so are not changing the object itself).</p>
<p class="MsoNormal">Should it be OK to have an object type like this, that is likely to change, but keep the ID permanent for it – ie accept that some object types are quite dynamic?</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">The only other option is to maintain a hideous version audit trail, that probably hinders the use of the data more than it benefits the end user by providing “stability”.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Any thoughts?</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Kevin</p>
</div>
<br>
<hr>
<font color="green" size="1" face="Arial">Please consider the environment before printing this email<br>
Warning: This electronic message together with any attachments is confidential. If you receive it in error: (i) you must not read, use, disclose, copy or retain it; (ii) please contact the sender immediately by reply email and then delete the emails.<br>
The views expressed in this email may not be those of Landcare Research New Zealand Limited. http://www.landcareresearch.co.nz<br>
</blockquote>
</font></div>
<br>
<hr>
<font face="Arial" color="Green" size="1">Please consider the environment before printing this email<br>
Warning: This electronic message together with any attachments is confidential. If you receive it in error: (i) you must not read, use, disclose, copy or retain it; (ii) please contact the sender immediately by reply email and then delete the emails.<br>
The views expressed in this email may not be those of Landcare Research New Zealand Limited. http://www.landcareresearch.co.nz<br>
</font>
</body>
</html>