[tcs-lc] nameObjects, spellings, vernaculars, etc

[Robert K. Peet]

Hi Rich et al.,

> I do have a set of related questions that might help serve as a springboard
> for instantiating v0.95.2.  Specifically, which of the following would
> represent unique "name objects"?
>
>  1. Aiidae Smith
>  2. Xiidae Jones
>  3. Aus Smith
>  4. Xus Jones
>  5. Aus Brown [heterotypic junior homonym of Aus Smith]
>  5. Aus bea Smith [incorrect gender of species epithet]
>  6. Aus bus Smith [correct gender of species epithet]
>  7. Aus buus Smith [lapsus of species epithet]
>  8. Auus bus Smith [lapsus of genus name]
>  9. Aus fus Smith
> 10. Xus bus (Smith) Jones
> 11. Xus bus subsp. bus (Smith) Jones
> 12. Xus bus subsp. fus (Smith) Jones
> 13. Xus bus var. bus (Smith) Jones
> 14. Xus bus var. fus (Smith) Jones
> 15. Xus fus subs. bus (Smith) Jones* [inappropriate prioritisation of fus
> and bus]
>

We need to define what we mean by name in the sense of various uses and
places in the TCS. I see four primary forms being important. (1) The raw
character string, what ever it is, including vernaculars, (2) Character
string of a supposed code-compliant name without authorities, (3)
Character string of a supposed code-compliant name with authorities, (4) a
code-compliant name including all spellings and variants.  Each of these
has different functions and needs to in some way be supported by a
combination of TCS and related TDWG standards. From the perspective of
documenting concepts, it would be most convenient to have the first of
these be our nameObject upfront.  However, Jessie has appropriately placed
what appears to be either 3 or 4 as the nameObject to enhance
compatibility with the Linnaean Core effort. The listserve conversation
seems to be drifting toward #4 alone.  But let me reiterate, the TCS has
to accommodate the other types of "names" in some way.  In particular, if
we accept the fourth type for our meaning of nameObject, then we need to
have this use of name as an optional link to a concept, and the raw string
in the reference (#1 or #2) should be required within the concept
definition.

If a concept is a "name" as used in a reference as we have previously
asserted, we want to be as unambiguous as possible about that name used in
the reference.  To support all forms of taxonomic concept documentation,
the name needs to be the character string used in the source, be it Aus
bus, or Aus buus, or some random misspelling of the original.  This use of
name is different from a code-compliant nomenclatural unit, which might
include alternative spellings and the like. There is a many-to-one
relationship between name and nameObject.  Ultimately the nameObject might
be stable while the name applied to it might be a moving target. To me,
documenting spellings of the name associated with a nameObject is outside
the scope of TCS and should not be handled by linking concepts as Roger
had suggested yesterday..  In short, I agree with Rich that we should
someplace allow name-name relationships, even if this is not part of TCS.

The authority is not technically part of the name but only documentation
of the name. I grant that if our goal is to document names sensu
ICBN/ICZN, it can be helpful to include the authority, but there is no
standardization as to how to represent these and our list of names will
explode with the thousands of alternative abbreviations unless we stick to
the name string per se and recognize that the authority string is a
separate thing, albeit required for certain nomenclatural acts and often
useful to separate the more extreme of the different concepts to which the
name string has been applied.

Having recognized that the character string is what is important for
supporting concepts, we can take a new look at vernaculars. Should not the
vernacular "Yellow-legged Aus" be a valid name for the purposes or
reporting a concept?  Not all datasets or publications we might wish to
mark up use scientific names and in these cases all we have to work with
is the vernacular.  While the vernacular usually represents an
identification to an unspecified (or unknown) concept that is in turn
based on a code-compliant name, we often do not know what concept or
code-compliant name was intended and the reported vernacular is the best
we can do.  An individual investigator might synonymize such a vernacular
concept to a concept based on a code-compliant name, but that is a
separate act and typically unrelated to the efforts of the original
investigator who's work we are trying to document.  I see acceptance of
the concept "Yellow-legged Aus" as no better or worse than acceptance of
"Aus aff. bus".  We have previously agreed that best practice is to avoid
these, and we might not want to clutter up taxonomic databases with weak,
vernacular concepts, but for purposes of providing the capacity to
document organisms referenced in a broad range of dataset types, concepts
based on vernacular names seem essential.  Of course, if you buy into this
argument, the next logical step is to move all the vernaculars into the
name entity of the TCS concept object The alternative is to accept
concepts that have a null scientific name but do have a "has vernacular"
relationship.

Having moved the code-compliant nameObjects up front, why do we need rank
to be part of the concept?  As I see it, rank belongs as an attribute of
the nameObject and not the taxonomic concept.

Bob

 ======================================================================
     Robert K. Peet, Professor & Chair         Phone:  919-962-6942
     Curriculum in Ecology, CB#3275            Fax:    919-962-6930
     University of North Carolina              Cell:   919-368-4971
     Chapel Hill, NC  27599-3275  USA          Email:  peet at unc.edu

                   http://www.unc.edu/depts/ecology/
                 http://www.bio.unc.edu/faculty/peet/
 ======================================================================