[tcs-lc] Incertae Sedis, and broader issues

[Richard Pyle]

Hi All,

So far, a variety of interpretations of what "incertae sedis" means have
been put forward (please correct me if I misinterpret anyone's meaning):

Pyle:
A parent-child relationship between two Concepts where the difference
between the Ranks of the NameObjects attached to each of the two Concepts
exceeds some threshhold value -- either an absolute value [e.g., skipping
one of the "root" ranks], or an in-context value [e.g., most concepts in a
treatment attached names of rank "X" link to parent concepts attached to
names of Rank "Y", except for a few that link to parent concepts attached to
names of ranks higher than "Y"].

Ytow:
Incertae sedis is whatever a taxonomist says it is -- i.e., if an author
uses it in a publication, then capture that information, regardless of the
author's meaning. [Do I have this right, James?]

Kirk:
"Incertae sedis is just to neat term to ensure there are no gaps in
denormalized hierarchies - for people who like these" -- i.e., it is a term
used as a "placeholder" for a missing taxon that might otherwise be
considered a "mandatory"  [Do I have this right, Paul? Also, Jerry -- your
secnd message seemed to indicate it as a placholder of sorts for a
NameObject -- did I understand you correctly?]

Cooper1:
An indication by an author that a given taxon concept could not be placed
within any known parent taxon concept. [Do I have this right, Jerry?]

Cooper2:
"it is simply an 'is parent of' concept relationship sensu the asserting
author" [identical to James' interpretation?]

Lyal:
"The statement is that the author recognises the taxon as a component of the
taxon hierarchical level within which it is incertae sedis, but cannot place
it within any of the taxa at the next heirarchical level below." -- [similar
to my "in-context" interpretation, but for practical purposes recorded
according James' interpretation -- is that about right, Chirs?]

Clearly, it seems, we have various interpretations of what "incertae sedis"
means when applied to a taxon concept (or relationship between two
concepts), and I imagine those interpretations listed above represent only a
small subset of the range of interpretations by the many thousands of
authors from whom we hope to capture taxon concept instances.  So, a simple
boolean flag wouldn't actually convey any information about the concept; it
would only convey that the author of the concept applied this term (or one
of some range of functional equivalents, yet to be determined) to the named
concept, and it would require a reading of the original concept definition
to understand in what sense the term was used.

We could go around and around about this indefinitely, but there are some
more fundamental issues that I think need to be addressed before we can
resolve the incertae sedis issue.

1) Name-Name Relationships vs. Concept-Concept relationships.
In TCS 1.00, a few Name-Name relationships are explicitly embedded within
the NameObject container: SpellingCorrectionOf, Basionym, BasedOn,
ConservedAgainst, LaterHomonymOf, NomenNovumFor, and certain implied or
explicit Name-Name links within CanonicalName and Typification.  But other
Name-Name relationships are (presumably) accomodated within
TaxonConcept/Relationships.  I presume this because the annotation for the
"Relationships" element says: "Stores explicit, taxonomic and nomenclatural
relationships that are part of the original concept definition." I am
uncomfortable with the way that different Name-Name relationships are
represented in different ways, and I had expressed this discomfort
throughout the TCS/LC discussions of yore.  My discomfort is at several
levels, both fundamental (e.g., Why shouldn't Name-Name relationships be
captured in a similar generic structure in the way that Concept-Concept
relationships are captured?; Why are some relationships stored in
NameObject, and others in TaxonConcept?), and specific (e.g., shouldn't
"IsLaterHomonymOf" be "IsJuniorHomonymOf"?). Which leads me to:

2) Dependancy of TaxonConcept/Relationships on Rank of associated
NameObjects.
It seems to me that many of the RelationshipTypes depend, in some way, on
the taxonomic Rank of the NameObjects attached to each of the two related
Concepts.  I haven't thought through all of the implications of this, but I
think there are many cases where Concept-Concept relationships are
confounded with Name-Name relationships, because what should be
Concept-Concept relationships have Rank dependancy. Which further leads me
to:

3) What is the difference beteen IsParentOf/IsChildOf; and
Includes/IsIncludedIn RelationshipTypes?
Several times during the earlier TCS/LC email exchanges, I asked for someone
to distinguish between the following statements:
  1) ConceptA is Parent of Concept B
  2) ConceptA includes ConceptB
  [or, conversely, 1) ConceptB is Child of ConceptA; 2) ConceptB is included
in ConceptA]
I don't see how these differ, except in light of the relative taxonomic Rank
of the NameObject attached to each Concept. Thus, IsParentOf/IsChildOf
RelationshipTypes, which I think everyone would agree are examples of
Concept-Concept relationships, have rank-dependancy (with Rank being a
property of a NameObject, not of TaxonConcept). Which even further leads me
to:

4) Does indication of a "Parent" Taxon, in any way, contribute to the
definition of a child TaxonConcept definition?
When presented with the following information: "ConceptA is Parent of
ConceptB", have we learned anything about the defnition of ConceptB?  We
certainly have not learned anything about the circumscription of ConceptB,
so if we have learned something about the definition of ConceptB, then the
definition of ConceptB must include more than its circumscription (but how
much more -- anything else besides a hierarchical placement within a parent
Concnept?).

And this brings me back to the "incertae sedis" issue.  We all seem to agree
that it a property of TaxonConcepts, rather than of NameObjects.  It seems
that most of us also agree it is tied to the "IsParentOf/IsChildOf"
relationship between two Concepts.  If so, then a Concept cannot be
"incertae sedis nothing" -- it can only be "incertae sedis something".  That
is, it only has meaning in the context of a relationship between two
concepts, not as a stand-alone property of a single Concept.

Finally, I do agree with Jerry that we should be looking more at real-world
data; and I will try to provide some within the next couple of months.  I
don't think all of the 4 enumerated issues above require real-world data to
discuss (particularly #1), but at the very leaset, I think real-world data
will help us all to understand each other.

Aloha,
Rich