[tcs-lc] Minor modifications prior TDWG ratification vote

[Richard Pyle]

Hi James,

> Don't go to phylosophy and design of your data structure.  The issue
> is whether TCS can pass regression test.  If TCS requires too
> inteligent XSLT as your discussion implies, we'd better to look for
> more practical schema for exchange.

I think my real problem is that I still don't understand exactly what
information is implied by "incertae sedis", and why it would be important to
capture in an exchange schema.  I agree with Paul -- it is just a convienent
way to flag a hierarchy jump that skips a rank that you might otherwise
expect it to include. It's not real information, as far as I can tell.

> > Without a parent-child relationship, "incertae sedis" has no
> > meaning.
>
> Disagreed.  There are cases where "incertae sedis" is stated because
> author can't give the higher taxon.

Hmmm... I'll have to think about this some more.  If I interpret you
correctly, you are saying that there is an important distinction (important
in the sense that it should be accomodated by TCS/LC schema) between "parent
not provided" and "parent not known to provider" -- is that correct?

> > Suppose "we" (TDWG, TCS, whatever) define "incertae sedis" as I
> did in the
> > previous message -- where one of the "root" rank levels has
> been skipped in
> > a direct parent-child relationship (e.g., OrderName is parent of
> > GenusName).
>
> I can't suppose it because you assume mandatory ranks.

No, I do not.  I'm quite comfortable indicating that the direct parent of a
species name is a Kingdom name -- no mandatory requirements for intermediate
rank at all.  It is not about "mandatory" ranks -- it is about defining what
"incertae sedis" means. Either there is a stable definition (e.g., skips at
least one "root" rank), or there is a dynamic definition, in which case each
data provider may define it differently in different contexts.  Also, it is
either a property of a Name/Concept, or it is a property of the
*relationship* between two names/concepts.

> Why user should provide NameObject?

Because, by my understanding, "incertae sedis" is defined in the context of
ranks, and ranks are properties of NameObjects.  But I believe that
"incertae sedis" is itself a property of a parent/child *relationship*
between two concepts.  If there is a parent/child relationship between two
concepts, and those two concepts are not each linked to a NameObject (with
associated ranks), then I don't know what incertae sedis would mean. Maybe
it simply means "parent concept not known to data provider", in which case
it would have no connection to ranks, and therefore no necessary involvement
with NameObjects, and it would be a property of a Concept (as opposed to a
property of a relationship between two Concepts.

> > So, my question was, would the purpose of an explicit incertae sedis
> > designation within a TCS record be intended to represent "treated as
> > incertae sedis by the source data provider, even though by our
> definition it
> > would not be flagged as incertae sedis"?
>
> I don't know because I don't think your logic rule and your smart
> parser is not any part of TCS 1.00.

I agree -- I don't think it is part of TCS 1.00 either.  But I don't think
incertae sedis should be, either -- because I do not understand what actual
information is being conveyed by it.

> > But at another level, I don't really understand, from an information
> > management perspective, what information value we can derive from the
> > "incertae sedis" flag anyway -- whether or not it is defined
> > algorithmically, or is explicitly indicated by the data provider/source.
> > What does it tell us that is not already self-evident from the
> other data?
>
> It tells us the fact without the oter data unecessary available.
> Don't assume perfect world.  Nitting fragmented data is one of important
> applications of TCS.

Suppose my database has records for 10 species-concepts, all of which are
within the same genus concept.  Suppose that 5 of my species concepts are
indicated as beloniging to one of two subgenus concepts, and the other 5
species are combined directly with the genus, with no subgenus concept
indicated:

 1. Aus bus Smith sensu Pyle
 2. Aus cus Jones sensu Pyle
 3. Aus dus Brown sensu Pyle
 4. Aus eus Smith sensu Pyle
 5. Aus fus Jones sensu Pyle
 6. Aus (Xus) gus Brown sensu Pyle
 7. Aus (Xus) hus Smith sensu Pyle
 8. Aus (Xus) ius Jones sensu Pyle
 9. Aus (Zus) jus Brown sensu Pyle
10. Aus (Zus) kus Smith sensu Pyle

As a data provider, should I, or should I not, flag the first 5 records as
"incertae sedis"? If I do flag them as such, what information have I
provided in doing so?  If I do not flag them as such, what useful
information have I failed to provide you?

Same question applies to concepts at any ranks (e.g., genera within families
vs. orders, etc.).

Aloha,
Rich