[tcs-lc] Minor modifications prior TDWG ratification vote

[Richard Pyle]

Hi James,

> > I have treated it as a condition, where the difference in
> taxonomic rank of
> > a child taxon name and its immediate parent taxon name exceeds
> a threshold
> > level (e.g., a genus name is indicated as having an immediate parent
> > assigned to a name that is of rank "order", with no indication of
> > family-rank parent).
>
> There can be cases where it doesn't work because of optional ranks
> such as subfamily.

But that's how you define the "threshold".  For example, ranks are clustered
into rank-groups: Domain, Kingdom, Phylum, Class, Order, Family, Genus,
Species.   Each of these groups has a "root" rank (of the same name as the
rank-groups I just listed), which is "mandatory" in any hierarchy.  An
incertae sedis state is true if any name of a rank below one of these "root"
ranks links directly to any rank above the "root" rank, bypassing the "root"
rank itself (e.g., species linked to a family, bypassing genus; or a genus
linked to an order, bypassing family, etc.)

> > What is the utility of defining "incertae sedis"
> > explicitly, rather than deriving it?
>
> Because source data are unnecessary perfect.  Data
> verificatin/scrutinise is one of major motivation to use TCS.

I don't follow.  Are you referring to taxonomy data, or specimen data (with
taxonomy identifications)?  Is the purpose to capture an "insertae sedis"
flag from the original source regardless of how the source defines "incertae
sedis"?  Or is there one common definition of "incertae sedis" to which all
data should conform, but that cannot always be deduced by comparing the rank
of the child to the rank of the parent?

> It is desing issue, or, application performance issue.
> You are right logically, but it is not optimal in performance.

Hmmm...I wonder if the designation is important enough to create a structure
for it simply for the purpose of improving performance.

> > Could you provide an example to illustrate how the "other"
> relationship type
> > and its corresponding modifier would be used?
>
> Example 1:
> I have relationshp types in Flora of Japan data doesn't fit to
> enumerated TCS-relationship types.  These could be resolved by
> botanist, but not by me nor part-time workers who enterd. the data.
> I'd like to ask botanists assist using TCS.  See FoJ data you
> already got our Website; I don't have convinience access to
> MS-Access now.

O.K., I guess I need to know what data in your structure would be lost, or
cannot be represented in TCS 1.0. I will look at the database.

> Example 2:
> Relationships between vernacular names in multiple scripts.  We have
> Hiragarna, Katanaka, Knaji and Roma-ji representations of single
> word in Japanes.  Kanji can be subdivided into simplified and
> traditional Kanji depending on character.  Adding more, 30% Kanji of
> UCS-2 have one or variants equivalent to the Kanji.  There is at liest
> one database recording Japanese vernacular names with distionction of
> scripts, e.g. "Hiragana of", "Kanji of".  Those relationship can't be
> covered by specifying locale execpt Roma-ji (phonetic transliteration
> into ASCII), because all has ja or ja_JP locale.

I wonder if what we really need is a VernacularNameObject structure to
accomodate such relationships.  I thought one of the original assumptions
was that TCS was primarily intended for Linnean-style scientific names, with
only rudimentary support for non-scientific names. Maybe this has changed?

Aloha,
Rich