[SEEK-Taxon] RE: GBIF and TCS-LC for data exchange

Richard Pyle deepreef at bishopmuseum.org
Tue Mar 1 13:17:27 PST 2005


Hi Roger (et alia):

> My understanding is that the LC was a spin out of the TCS for sorting
> out the naming side of things and was never meant to exist on it's own.
> It was to replace the name node in the TCS.

Not exactly.  LC started somewhat independently of TCS (by Jerry Cooper
primarily, but also by others who saw a need for a concept-less
nomenclatural schema).  At TDWG in Christchurch last year, it became evident
that a nomenclatural schema along the lines of what LC was intended to be
would (should? could?) serve the needs of the "Names" portion of TCS (in
place of the ABCD Names structure).

> This supports Jessie's groups finding that names should not be used in
> isolation from concepts. Even when we are passing round pure names data
> (a very rare event in the great scheme of things) we should have them
> wrapped in a TCS.

I happen to share this perspective (that concept-less names data should be
packaged inside a TCS wrapper); however there are others whose opinions I
respect who disagree with this viewpoint.  I think it is safer to leave this
question in the "undecided" category for the time being -- and indeed it
will probably be one of the main initial topics of discussion on the new
email list.

> All non-nomenclaturists should be assumed to be
> talking in terms of taxa not names - even if we can't practically
> delimit those taxa at present. (Excuse me if this is not a totally
> complete summary on the initial TCS findings).

I would agree with this statement, but I'm not completely sure that the need
for a means of name-only data exchange mechanism should be regarded as
trivial.  For various reasons, it makes sense (to me, anyway) from an
information structure perspective to manage data for name-objects
differently from concept-object data. As such, even if LC data objects are
always contained within a TCS package, it still may make sense to think of
the LC elements as a different schema (or "subschema") -- almost in the same
way that elements associated with publication objects are treated as a
different schema/subschema.  But this is (or can be) a rather contentious
point of discussion, so perhaps best to wait for the new email list to be up
and running before we dive into that discussion (how's that for a clever way
of deflecting debate! :-)  )

> Certainly we are dealing with issues of how the LC points to parts of
> the TCS for vouchers (types) and publications just at the moment and
> these discussions don't make sense outside the TCS.

Yes, but these are not the only issues that need to be resolved within the
context of LC.  In fact, one of the biggest issues that still needs to be
resolved (in my mind), is what constitutes a unit "name" in LC, vs. what
constitutes a subsequent "usage" of a pre-existing name (i.e., not an LC
unit).  Candidate units include (basically):

1. Basionym/Protonym
2. Replacement Names
3. First instance of a new combination of infrageneric (but supraspecific)
names
4. First instance of a new combination of species-rank names
5. First instance of a new combination of infraspecific names (congeneric)
6. First instance of a new combination of infraspecific names
(heterogeneric)
7. First instance of an alternate spelling of a name
8. Subsequent usages of a name that does not constitute a first instance of
combination or spelling

[There are others...]

I think that pretty-much everyone agrees that number 1 constitutes a
distinct LC-object; and I think that pretty-much everyone agrees that number
8 does not.  There are varying degrees of consensus among folks as to which
of the others do, or do not constitute unique LC object instances.  At the
core of this question are differences between the different Codes (primarily
between ICZN & ICBN Codes), and also the contention between Code tradition
and logical information structure. Resolving this sort of question is highly
fundamental to LC, even outside the context of TCS (although there are
TCS-relevant issues related to this question).

> What are people's feelings on merging TCS and LC in the very near future
> and only talking about one thing?

Personally, I would like to see that happen; because clearly both TCS and LC
depend on each other at some fundamental level, and as such need to be
developed in concert.

Aloha,
Rich





More information about the Seek-taxon mailing list