[tcs-lc] Comments on Draft TCS for TDWG voting

[Richard Pyle]

Thanks, Jessie --

> thanks for your comments - which have just confirmed to me that
> it is just about impossible to talk about any of this clearly and
> ensure that what is written will be interpreted the way it was
> meant.....this is no doubt as much my inability to communicate
> what I mean succinctly and clearly as it is yours to interpret
> what is written without adding more to it....

Agreed -- this is an extremely difficult topic to articulate! So many
ambiguously defined terms and homonyms (not the scientific name kind)....

> no offence to nomenclaturalists meant if any was taken.... I'm
> just saying that they don't necessarily have the same priorities
> as taxonomists undertaking monographs and revisions, nor will
> they have the same priorities as biologists wanting to identify
> organisms in a meaningful way, or biologsits trying to decide if
> two records recorded in different coutnries or at differnt times
> refer to the same taxon. The different perspectives are equally important.

Well -- I'm not so sure on this.  But another way to look at it is that,
whereas TCS seeks to encourage biologists to appreciate and make appropriate
use of concepts rather than simply using "unqualified names", we seek to
encourage biologists to appreciate and make appropriate use of *scientific
names* for what they *should be*, rather than simply using "unqualified
names". If TCS wants to fundamentally entangle "names" and "definitions",
then I don't see why the "names" part shouldn't be treated as robustly as
the "definitions" part currently is in TCS.

> >"They interpreted the Name element to be a more efficient way to store
> >information about names."
> >
> maybe now after months of discussion.... but at first I was
> informed that it was because they didn't think they could
> represent all they needed to be able to with the Name element and
> were going to suggest a new Name element to be inserted.

Well, I refer you back to the first paragraph in your email, quoted above.
As you know, I've been involved (at a distance) with TCS for quite a while,
and to be honest, I didn't quite "get it" until Nico sent the list of
possible relationships.  That is the very first time that I realized that
name-name relationships were being accomodated by the same "Relationship"
element as circumscription-circumscription relationships.  It also forced me
to understand the difference between the definitive "Relationships" (within
TaxonConcept) and interpretive "RelationshipAssertions" (top-level objects).

> >This paragraph, I believe, captures the real heart
> >(nitty-gritty) of what we
> >need to focus on, and where, ultimately, the fundamental dispute lies.
>
> really? If that's the case then I would say is an issue for the
> computing people who are going to implement the solutions for the
> biologists.....because it really is an implementation issue.

I thought we were all clear that we were talking about an implementation
issue a long time ago?  But implementation issues are not the sole domain of
computing people.  Implementation also depends on the nature and "natural
stucture" of the data that will be transmitted via the exchange schema --
and that's the part we've been discussiong.  Ultimately, it is really just
an implementation issue as to whether or not full nomenclatural data will be
extracted by interrogating a series of multiple TaxonConcept instances, or
by packaging the nomenclatural data in a modular unit.  This is what we have
been discussiong lately -- isn't it?

> Tools could be designed to let different user groups see the data
> the way they want.

Agreed!  That's the premise behind the perspecive (which I don't necesarily
endorse) to manage names as protonyms only, and leave it to the software
layer to assemble name objects in botanical form or in zoological form.

> What I think was intended by the schema is that people will
> continue to use their own systems with their preferred
> terminology and tools and will only use the schema for
> transferring data between systems.

Absolutely!  But there is a reason why the TCS schema is more like ABCD
(highly structured), rather than DarwinCore (flat) -- a difference that one
could argue is simply implementation.  But I think the structure is
important for many reasons -- even for an exchange schema -- because
implementing some complex structure allows enforcement of logical rules that
apply to the data, and improves efficiency for building and deconstructing
transferred datasets.  TCS recognizes that Vochers, Publications, and
RelationshopAssertions each needs their own complex structure (and I agree).
I believe that names *almost* fall into this category as well -- but not so
detached from TaxonConcepts that they should be rendered as top-level
elements.  But isolated enough that name-name Relationships should be
clearly disentangled from concept-concept Relationships.

> right and wrong ;-)
> the definition for a TaxonConcept (or Taxon as Roger is
> suggesting) could also include or be the rationale for the
> existence of the name that a nomenclator is interested in.

Huh???  Isn't the "rationale" simply a justification that a circumscription
boundary should be drawn in one particular way, different from how it was
drawn before?  And if so, why isn't that simply a function of defining the
circumscription?  What rationale for the existence of the name is a
nomenclator interested in (other than the fact that the name has been fixed
to a distinct type specimen)?

> >The so-called "nomenclaturalists" are simply saying that a
> >similarly robust
> >set of elements are needed to capture the "Name" part of that equation.
>
> you have them - if you consider name as a TaxonConcept

Sort of -- but not quite.  It's really more a case of force-fitting
name-name relationships in a structure that is optimized to represent
concept-concept relationships. And it also confuses the question of whether
or not a particular TaxonConcept instance represents the taxonomic
circumscription intended by the AccordingTo authors, or simply the
nomenclatural acts established by the authors.

> >Personally, I think TCS should have defined a TaxonConcept as
> >simply the
> >"Definition" part (which I think it accommodates very elegantly).
>
> I disagree when you take on board the perspective of someone (a
> normal biologsit) trying to use the output from taxonomists and
> nomenclators (is there a difference between nomenclators and
> nomenclaturalists?? sorry I keep interchanging them). They use a
> name to mean something they don't go around citing definitions in
> their survey data and citing names isn't meaningful enough for
> later interpretation by others.

Well, we're in full agreement here (I think -- kind of depends on who the
various "they" pronouns above refer to: the nomenclaturalists, or the normal
biologists).  So I'm not so sure on where we disagree.

> > "Name"
> >should be a referenced attribute of a TaxonConcept instance,
> >in the same way
> >that Publications, Vouchers, and Characters are referenced.  One way to
> >structure this would be to treat "Names" like these other
> >top-level objects,
> >and represent them as such in the schema (i.e., outside of
> >TaxonConcept).
> >I'm not (yet) of that belief,
>
> so why did you just say you think TCS should only have dealt with
> the definition.

Because if it had, we wouldn't have spent so much time arguing about it.  I
can certainly live with Names as top-level elements, and I believe that if
this process began with that perspective, we'd find a lot more harmony in
our discussions.  The reason for my "not (yet)" statement is that I find a
lot of appeal in the Nominal Taxon Concept instance as a mechanism that
achieves both basic goals (of TCS, and of nomenclators): It encourages
normal biologists to represent their data with concepts, rather than with
unqualified names (score one for concept-based taxonomic data); and it
forces normal biologists to recognize the distinction between a name-object,
with its name-name relationships, and a concept circumscription, with its
circumscription-circumscription relationships (score one for nomenclators).

> And anyway when we started TCS there was nothing
> else - apart form Walter's Name element in ABCD which we took on
> board. I'm not really sure what you're saying now....

What I'm saying now is that I understand why names should be thought of as
objects (with their own name-name relationships), rather than simply as
attributes of Concept circumscription definitions; and I also understand
that names as top-level objects ignores the very tight connection between
names and concept circumscriptions.  I really believe that Nominal Concepts
(as the TCS developers have defined their "conceptual" meaning) serve as the
*perfect* bearers of name-only data.  Later this week I will try to
articulate this via a modified TCS v095, a corresponding instance document,
and a "whitepaper" documentaion containing an explanation and rationale.

> >we should instead recognize that if we are going to define a TCS
> >TaxonConcept as "name+definition", then we should:
> >
> >1) Not confound the equation by creating a structure that, in
> >some ways,
> >represents "name~=definition";
> >
>
> depends on your definition of name......
> which does vary from person to person......

..and which I *tried* to pin down on this list last week.

> >2) Put as much care and thought into accounting for the first
> >half of the
> >equation, as has been put into the second half; and
> >
>
> I think ABCD did a lot of work that we took on board and LC have
> added a lot more useful work and re-structured the Name element -
> which we have taken on board. The only thing is we're saying the
> "definitional part of a name can be captured within the TaxonConcept part.

Now it depends on what your definition of "definition" is... :-)

A name is (nomenclaturally) defined in a very different way from a concept
circumscription.  A name, by definition, is connected to only one specimen
(the primary type); whereas a concept, essentially by definition,
circumscribes more than one specimen.  The nature of name-name Relationships
(is basionym of, is type species of, is a relacement name for, is a
homotypic synonym of, etc.) is, in my mind fundamentally different from that
of circumscription-circumscription Relationships (is congruent with,
includes, is included in, excludes, etc.).  TCS currently mixes these things
in the same structure. I'm not persuaded that such mixing is the best way to
represent the data in a transfer schema.

> >3) Not mis-characterize the needs of "nomenclaturalists" as "a
> >particular
> >type of user of taxonomic names", when, in fact, a "Name"
> >represents 50% of
> >the "essence" of a TaxonConcept instance.
>
> I think this is an unhelpful comment - we're not trying to
> mis-characterize anyone - but it is very easy to be thought of as
> doing that - diplomacy is clearl not one of my best skills.....

O.K., then I apologize.  But evidently, I'm not the only one who felt that
way.

> >"If a TaxonConcept is defined as 'name+definition', then what
> >is meant by
> >the 'name' part?"
>
> agree and I hoped we could keep it to the parts that we need to
> represent any name, with any rationale being kept to the
> definitional bits - i.e. the relationships, links to specimens
> and publications etc.
> So more than a string but not links to other elements.

Hmmm...maybe you can describe how you define a "name" that is more than a
string, but does not have links to other elements?

> >I am assuming that the "definition" part means the taxonomic
> >circumscription -- which is accomodated very well via the
> >"Relationships" to
> >other concepts, plus references to vouchers, plus references
> >to characters.
> >
> so is the information you want to capture about names, e.g. type
> specimen, relationships to other names, where the name was published etc.

Yes, I know that -- but TCS does not allow me to "modularize" nomenclatural
data (which may span multiple "AccordingTo"s) in a convenient way -- and
that's what this debate is really about (if I understand the comments of the
other nomenclator-folks correctly).

I will try to develop some documents to help explain my points more clearly.

Aloha,
Rich