%META:TOPICINFO{author="RichardPyle" date="1173170740" format="1.1" version="1.4"}%
%META:TOPICPARENT{name="GUIDsForZoologicalNames"}%
See also UsageInstanceProposal.
_The following is was cut directly from Rich Pyle's message on mailing list._
There is going to be an issue regarding how GUIDs (e.g., LSIDs) are assigned
to taxon names to botanical vs. zoological names. This comes down to the
fundamental difference in how zoologists and botanists think of a "name" (or
as we informatics nerds would say, a "name object" -- the thing to which a
GUID is attached and/or represents). Consider these hypothetical names:
_Aus_ L.
_Xus_ Jones
_Aus bus_ Smith
_Xus bus_ (Smith)
The first clue to the differences between zoological and botanical practice
is that the last of these would be represented as "_Xus bus_ (Smith) Jones",
where Jones is credited as the first to have placed the species epithet
"bus" within the genus "Xus".
In our (zoological) realm, we would certainly think of the "original genus"
as an attribute of a species epithet (at the very least so that we know
whether to put parentheses around the author), but otherwise we don't track
combinations under ICZN (rules governing gender matching notwithstanding).
To a zoologist, the combination is an attribute of the particular usage
instance. For example, there may by five publications citing the species
epithet "bus" and placing it in the genus "Aus" (one of these being the
original description), and there may be five others placing "bus" within the
genus "Xus". While it may very well be that Jones was the first to create
this "Xus bus" combination, we in Zoology do not ascribe any special status
to that event -- that is, we do not regard it as a Code-governed
nomenclatural act.
Thus, from the Zoological perspective, there are three GUIDs (LSIDs) needed
to accommodate the four items above:
LSID1: Aus L.
LSID2: Xus Jones
LSID3: bus Smith [original genus: LSID1]
We would then keep track of combinations through name-usage instances. For
example, we might have ten records in out "usage instances" database to
represent the five published citations of "Aus bus" and the five published
citations of "Xus bus". These would all be thought of as usage intances of
"bus" (LSID3), and an attribute each usage instance would be which genus
combination it was placed with (five would point to LSID1 as the parent
genus, and the other five would point to LSID2 as the parent genus). E.g.:
Usage# NameID ParentID
--------------------------------
1 LSID3 LSID1
2 LSID3 LSID1
3 LSID3 LSID1
4 LSID3 LSID1
5 LSID3 LSID1
6 LSID3 LSID2
7 LSID3 LSID2
8 LSID3 LSID2
9 LSID3 LSID2
10 LSID3 LSID2
From the botanical perspective, however, each combination is treated as a
distinct (code-governed) "name" (Name-object). Thus, for botanists, there
would be four GUIDs, instead of three:
LSID1: Aus L.
LSID2: Xus Jones
LSID3: Aus bus Smith
LSID4: Xus bus (Smith) Jones [basionym: LSID3]
For usage instance records, instead of having pointers to two GUIDs per
record (one for the species epithet, one for the genus) there would simply
be a pointer to the combination as used. E.g.:
Usage# NameID
-------------------
1 LSID3
2 LSID3
3 LSID3
4 LSID3
5 LSID3
6 LSID4
7 LSID4
8 LSID4
9 LSID4
10 LSID4
I'll make two observations about this fundamental difference between the
botanical and zoological approaches to "names" (name-objects):
1) It may be that this difference ends up being transparent, once we get
this stuff implemented. In other words, there may be no problem with
ZooBank assigning GUIDs by the zoological tradition, and IPNI/IF assigning
GUIDs by the botanical tradition -- as long as the informatics architecture,
standards, and protocols are done right, there should be little difficulty
aggregating botanical and zoological names data together. On the other
hand, I can't help but think it will ultimately be to everyone's advantage
to all be on the "same page" in terms of GUID issuance, so that there is no
question how a GUID under one code corresponds to a GUID under another (in
terms of what you do with the metadata attached to that GUID).
2) At first glance, the botanical approach might seem preferable because it
leads to a (seemingly) simpler way of tracking the relationship between
"names" and other data (like usages, specimens, etc.) However, I think there
is compelling reason from an information management perspective (outside of
personal biases of different taxonomic traditions) to treat "name objects"
as monomial units (ala zoological tradition), and then layer everything else
on top of usage instances (without the need to GUID-ify name-combination
units in-between these two layers). But I'll save the details of this
perspective for another discussion.
-- Main.RogerHyam - 02 Mar 2007