[SEEK-Taxon] guids

[Nico M. Franz]

Hi Rich: excellent examples! The fine mechanics of certain parts of your 
questions are not clear to us yet either (see ITIS comments), so this is 
very useful. I inserted my comments below, starting with "---".

At 12:55 PM 5/24/2004 -1000, you wrote:

>Hi Nico,
>
>Thanks for the clarification!  I'll have to digest it a bit more to make
>sure I understand our respective perspectives.
>
> > But, realistically, we're not in a position to
> > assign GUIDs to referenced names ONLY when we have reasons to
> > believe that
> > there's different taxonomic carving-up of the world implied.
>
>On this, I agree 100%!!  But my question was really more about:  How do you
>make the distinction between constructing a new GUID that represents a
>different "version" of the same "concept", vs. a new GUID that represents a
>different "concept".  Clearly, if there need be more than one version of the
>same concept, then some difference has been identified.  If
>version-differences are restricted to typographical sorts of issues of what
>otherwise is clearly the same concept entity (Name Sec Reference), then the
>question is about whether such sorts of issues need to be *intentionally*
>tracked by different GUIDs ("intentionally", to separate out the inevitable
>inadvertent duplicate entries).
>
>However, if a "version" spans more than one "Name Sec Reference" instance,
>then it seems to me to be a potentially subjective decision as to whether
>we're talking about the a different version of the same concept, or two
>potentially different concepts.
--- I would've said that referring to the same name/reference/date 
intersection is the cut-off point for a GUID. That's the first of your two 
options. Though I'm not exactly sure how ITIS does and should do things. 
They're kind of silently revolutionizing taxonomy as we knew it and we are 
building to keep up (or so I feel sometimes). When ITIS puts out a new 
version of ITIS, en bloc and at a particular time, maybe that should really 
be handled as a mix of old and new GUIDs, depending on what (little, 
probably) has changed.

>I guess that's why I'm not clear on what constitutes examples of "two
>versions of the same concept", vs. "two separate concepts".  Perhaps some
>specific examples would help clarify?
>
>For example,  Allen et al. 1998 and Debelius et al. 2003 both treat the name
>"Paracentropyge" as a distinct genus from "Centropyge"; whereas Pyle 2003
>treats  Paracentropyge as a subgenus of Centropyge.
>
>All three references include the same 3 species within Paracentropyge, so
>all 3 concepts of Paracentropyge are congruent.  The first two references
>apply the name "Centropyge" to the same concept circumscription (i.e.,
>exclusive of the 3 Paracentropyge species); whereas the third reference
>applies the name "Centropyge" to a broader concept circumscription (i.e.,
>inclusive of the 3 Paracentropyge).
>
>So, I see six distinct Concept GUID's here:
>
>GUID    Concpet Description
>-------------------------
>  1      Centropyge Sec Allen et al. 1998
>  2      Paracentropyge Sec Allen et al. 1998
>  3      Centropyge Sec Debelius et al. 2003
>  4      Paracentropyge Sec Debelius et al. 2003
>  5      Centropyge Sec Pyle 2003
>  6      Paracentropyge Sec Pyle 2003
>
>The congruencies among these would be:
>
>1=3
>2=4
>2=6
>4=6
>5=(1+2)
>5=(3+4)
>1 excludes 2
>3 excludes 4
>5 includes 6
>
>(...and other redundant/implied logical equivalencies)
>
>So...would any of these represent "versions" of the same concept?  For
>example, would anyone ever consider 3 to be a subsequent version of 1? Or 4
>a subsequent version of 2?
--- six concepts - check!; the relations among them - check!; perfect 
example of how to do it right. Since the deeper intuitions about "how much 
is new" (e.g. nothing between 1 & 3) are captured in the synonymy relations 
(tapping myself on the shoulder here...), I see no need to merge them. 
After all one could (perhaps in other situations) disagree about the "=" 
judgment, or put things together differently. A merge of 1 & 3 into one 
GUID would put a lot of burden on the shoulders of that GUID, essentially 
the same burden that names couldn't lift in the first place.

>-- OR --
>
>Suppose ITIS recorded the concepts of 5 and 6; and SP2K recorded the same
>concepts of 5 & 6, but mis-spelled the author's name as "Pile".  Would
>those, then, represent different versions of the same concepts?
>
>i.e.: Concept 5, Version ITIS  |  Concept 5, Version SP2K  |  etc.

--- yes again. When the task is to refer to someone else's concept, which 
has a fixed extension in space and time (your 2003 paper), the implication 
is that there only exists one Pyle 2003 view. More or less faulty/complete 
representations of that view in different databases would be versions of 
the same concept. What you have here is only 1 concept/GUID, e.g. 
Centropyge [whoever named it first] SEC. PYLE 2003. I think we don't want 
to assign GUIDs to versions. In Edinburgh Jessie made strong arguments for 
a 1-concept-1-GUID policy that allows versions to take care of sloppy 
transferring (who knows when we'll have Linnaeus' figures scanned and put 
into the database?). Your examples capture this very well.

>Before we delve into arguments about whether different versions need to be
>tracked by different GUIDs, I think it would be helpful to more clearly
>define the difference between two versions of the same concept, as opposed
>to two separate concepts.
>
>Sorry for the bandwidth, if this stuff is clear to everyone except me....
>
>Aloha,
>Rich
>
>=======================================================
>Richard L. Pyle, PhD
>Natural Sciences Database Coordinator, Bishop Museum
>1525 Bernice St., Honolulu, HI 96817
>Ph: (808)848-4115, Fax: (808)847-8252
>email: deepreef at bishopmuseum.org
>http://www.bishopmuseum.org/bishop/HBS/pylerichard.html