[tdwg-content] Name is species concept thinking
deepreef at bishopmuseum.org
Sun Jun 13 22:50:10 CEST 2010
> By linking to a populated GNUB it would also have an improved
> means to provide the protonym circumscription of the concept,
> as you describe in (5).
Just to be clear, when you say "protonym circumscription of the concept",
you mean a concept circumscription whose boundaries are defined by the set
of included protonyms (as opposed to the concept circumscription established
for the Protonym-usage instance; i.e., original description). Correct?
Although such concept/circumscription definitions (effectively represented
by the set of type specimens implied by the set of protonyms) are not as
high-resoultion as concept/circumscription definitions that are defined by a
broader suite of specimens, populations, or characters; they are, I believe,
the "best bang for the buck" in that they give us 80% of the benefit for 20%
of the work.
> In addition, we would like to support the inclusion of
> bibliographic data,
Already included via GNUB.
In my mind, a *key* value of GNUB/GNA is to serve as a taxon authority for
specimen collections (i.e., the anchorpoints for specimen/observation
> geospatial information,
Inherited from the specimens/observations.
> and general
> descriptive data.
Inherited from the PLAZI treatments anchored to the publications, as well as
the published and unpublished character data anchored through specimens.
> In (5) you describe the protonym-based circumscription to
> evaluate the relative agreement of the identified concepts (via 'meta-
> authorities'). This provides the basis for expanding the potential
> set of names for a subsequent data retrieval from GBIF (for
> example) to include all the related nomenclatural and lexical
> variants for those names (of course checking for homonym
> conflicts among them).
> In (6) it appears the output of the Taxon Concept resolution
> process is either an expanded set of name strings or an array of
Before the content is built, the name-strings can be fed back into GNI to
snoop out additional possible protonym links. However, in a data-populatd
paradigm, it would be an array of ProtonymIDs.
> If the latter, I
> can see how this would provide a more precise
> concept-informed but name-based retrieval method and probably
> the best we can expect from
> large indices like GBIF. But I don't see how it will support a
> strict concept-based retrieval.
If you are content with a protonym-based concept circumscription definition,
it has all you need. Each Taxon Name Usage instance in GNUB represents an
array of (minimually one) ProtonymIDs -- that is, the set of all protonyms
representing the asserted taxon concept in the usage instance. Like I said,
it's not as high-resolution as specimen/population/character-based
concept/circumscription definitions, but I think it gets us most of the way
there, with the least amount of effort (not to say that it requires little
effort to get us that far -- just that trying to define concept boundaries
at higher resolution requires *MUCH* more effort).
So, the question is, what concept boundaries are fuzzy when you use
Imagine an example where we have 7 protonyms of something in the Pacific;
three described from type specimens collected in the eastern Pacific, and
four from specimens collected throughout the western Pacific. We also have
a bunch of specimens from the central Pacific, but no Protonyms typified
from that region.
Taxonomist "A" declares that the three protonyms from the eastern Pacific
represents one valid species (Aus bus), and the four from the west represent
a second valid species (Aus xus). Taxonomist "B" declares the exact same
thing. Using Protonym-based circumscriptions, we can infer that each the
taxon concepts of "Aus bus" and "Aus xus" are both congruent between the two
The fuzziness comes in for the central Pacific populations:
1) Suppose that Taxonomist "A" explicitly cited the populations in the
central Pacific, and declared them to be "Aus bus"; but Taxonomist "B" never
mentioned them. In that case, we would probably want to establish the
concept realtionship as "Aus bus sec. A <includes> Aus bus sec. B" (as
opposed to "is congruent with", as would be the case for a Protonym-based
2) Suppose that Taxonomist "A" explicitly cited the populations in the
central Pacific, and declared them to be "Aus bus"; but Taxonomist "B" cited
those same populations as belonging to "Aus xus". In that case, we would
probably want to establish the concept realtionship as "Aus bus sec. A
<overlaps with> Aus bus sec. B". Again, the Protonym-based circumscription
in this case would give us an imprecise representation of the concept
However, in my experience (working in the Pacific, where this sort of
circumsctance of eastern vs. western vs. central population differences
happens a LOT), it's actually a very rare problem. That is, in scenario 1,
it's most likely the case that Taxonomist B would have included the central
populations the same way that Taxonomist A would have. As for scenario 2,
I'm struggling to think of even a single example of this. I suspect that
it's just very rare.
So the point is, I think that protonym-based circumscription definitions are
perfectly adequate for the vast majority of use cases.
> The real world example that forms my litmus test is the
> blue-headed vireo, Vireo solitarius (Wilson 1810) which was
> originally called Muscicapa solitaria and has also been
> combined to form Vireosylvia
> solitaria and Lanivireo solitarius. Of course there are lexical
> variants as well (Google "Lanivireo solitaria" for example). These,
> properly structured, would be the sort of useful set of
> lexical/ nomenclatural content I would hope as a response
> from a GNI/GNUB resolution service based on protonymID.
Send me a bunch of usage instances involving all the different name
variants, and involving various concept definitions, and I can create a
sample GNUB dataset that would illustrate how this would work. The
name-mapping things is trivial, once the TNU instances have been populated.
The concept mapping stuff is a bit more complex -- but still relatively
simple compared to algorithms for, say, oxygen control systems in
> One current view of the taxon (concept C1) has this species occupying
> the eastern part of the US. Another species, Vireo plumbeus Coues,
> 1866, (concept C2) occupies the middle west USA, and a third
> species, Vireo cassini Xántus de Vesey, 1858 (concept C3) is
> on the western coast.
> Another view lumps all three of these into a single species
> which, based on the rule of priority, has the valid name
> Vireo solitarius and results in a new concept (C4). This
> concept includes C1, C2, and
> C3. Both concepts have the scientific name of Vireo solitarius.
> We can access and represent these in a consistent fashion
> using our CLB and probably others can too in their own index models.
> So, now we have a specimen of Vireo solitarius that was captured in
> Minnesota. It might be an errant instance of C1, Vireo solitarius
> sensu stricto, that strayed a bit west of normal. It might be (C4)
> Vireo solitarius, sensu lato. The specimen would need that concept
> identifier tied to the record to make this explicit. So, let's say
> that the identifier was made using the lumped concept (C4).
> Of course, if this doesn't make it into the record, we are
> stuck with the name alone.
Right -- this sounds like the same as the hypothetical example I made above.
But like I say, I think this example is the exception, rather than the rule
(i.e., it falls in the missing 20% of the "benefit" in the 80% benefit/20%
> Using the method (6) you described would allow a user to
> discover the different treatments of Vireo solitarius (C1 and
> C4) and provide some means to discriminate them via concept
> - C4 includes C1, C2, and C3 which would include all the names above.
> - C1 would only include the nomenclatural/lexical variants
> for Vireo solitarius.
> Resolution will enable us to perform a significantly more
> useful and concept-informed search. It will, however,
> include the specimen I referenced above in BOTH cases because
> "Vireo solitarius" or it's protonymID will be a search term
> in both cases.
Right -- until someone else comes along and provides a more explicit
identification for that specimen.
> A more precise concept based system would utilise a required
> taxon concept identifier in the specimen record to
> discriminate different uses of the SAME NAME.
Sure! That would be fantastic -- and maybe someday we'll get to the point
where all specimen/observation identification events come in the form of
"Aus bus sec. Smith 1955", rather than simply "Aus bus" (as the vast
majority are now). This, in my mind, is the single greatest and most
consistent informatics failure within legacy taxonomic works and specimen
databases. But I think the good news is that we can still get 80% of the
benefit by going only as far as protonyms (which we *can* derive from a name
alone -- once we get past homonymy and gross misspellings).
> In other
> words, if you did a search of Vireo solitarius and the
> concept resolver indicated the different concepts above and
> you chose the sensu stricto (split) version, you would get
> the C1 labelled records but the C4 labelled records would be
> excluded or at least come with a warning (may not be what you
> are looking for). This of course requires our specimen
> records to have a concept
> identifier. Or, the concept definition itself will include
> additional annotations to enable us to make inferences
I think the best we can do is flag those cass, and rely on caveat emptor.
> Publication date of the concept - If the split didn't happen
> until 1980 and the specimen is from 1960 then we could infer C4.
> Distribution information for the concept - if we disregard
> errant specimens then we might infer a 1985 Minnesota
> specimen is a C2 in spite of the different name.
The date one could work within the GNUB architecture, because that dates are
all there (as long as the specimen identification was also dated). With the
right integration with GBIF, the distribution one *might* be derivable
algorithmically, but it wold depend on the nature of the data.
> In sum, we are on track for achieving this and I believe our
> data mobilisation strategy will support getting these sort of data
> published. When Markus returns from paternity leave I would hope we
> could include his thoughts on how we might expose these as
> RDF via our indices to support all aspects of this discussion.
Keep on a keepin' on....
P.S. Congrats to Markus! I was unaware!
More information about the tdwg-content