[tcs-lc] Minor modifications prior TDWG ratification vote

Paul Kirk p.kirk at cabi.org
Sat Sep 17 04:55:28 PDT 2005


There is no mandatory next parent rank in the hierarchy, in botany and perhasp elsewhere there are primary ranks as noted earlier in this tread. We had this 'problem' with Species 2000 which assumed all GSD species would be assignable to a family which is not the case - now we have 'family or next higher rank' (up to top level of GSD) as the appropriate term. Incertae sedis is just to neat term to ensure there are no gaps in denormalized hierarchies - for people who like these - unless I misunderstand the problem/scenario
 
Cheers,
 
Paul

________________________________

From: tcs-lc-bounces at ecoinformatics.org on behalf of Richard Pyle
Sent: Sat 17/09/2005 12:44
To: tcs-lc at ecoinformatics.org
Subject: Re: [tcs-lc] Minor modifications prior TDWG ratification vote



> Not only by mine but also data provider and author of the publication.
> Suppose a publications says that "rotifer has been considered a kind
> of ciliates, but my research indicates it is wrong even though I can't
> tell to whchi taxa should belong".  What naive deta provider can
> record is that the author gives incertae sedis status to say Rotifera
> vodka. When a user serch the database with "Rotifera vodka", [s]he
> will get only the record of Rotifera vodka except if a chain of higher
> taxa is mandatory as return record.  Would you like to have all
> chain of higher taxa for every record via TCS-compatible data souces?

I don't understand.  The publication says the parent of species "vodka" is
genus "Rotifera", and parent of genus "Rotifera" is phylum Ciliata?  If so,
then there is no incertae sedis status for species vodka within genus
Rotifera, but there is incertae sedis status for genus Rotifera placed
within phylum Ciliata. You do not need the entire chain of higher taxa to
determine incertae sedis status -- only a relationship between a child taxon
and a parent taxon, where the rank difference exceeds the threshold.
Without a parent-child relationship, "incertae sedis" has no meaning.

Or, is it a case of "Unidientified Ciliata", misidentified as "Rotifera
vodka"?

Or, am I not understanding the example?

> > Is the purpose to capture an "insertae sedis"
> > flag from the original source regardless of how the source
> defines "incertae
> > sedis"?
>
> I can't understand this sentence.  Could you prease rephrase?

Sorry.

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).
If we are given a TCS record involving a GenusName, with "is child of"
relationship to a TCS record involving a OrderName, then by our definition,
we recognize it as incertae sedis.

However, suppose the data source includes a list of many genera within one
family, and all but one of these genera are linked to one of several
subfamilies.  The data source might then choose to treat the one GenusName
that is not linked to a subfamily as "incertae sedis within Familyname".
Within the source context, it is an "incertae sedis" placement even though
it does not skip a root rank, and therefore would not be recognized by a TCS
parser as "incertae sedis" by logic rules.

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"?

That is a reason why I could understand the need to capture incertae sedis
explicitly (i.e., not everyone defines it the same way in all contexts, and
therefore the TCS record should capture how the data provider defined it on
a case-by-case basis).

Or, are we assuming one "standard" definition of incertae sedis, but it is
too much processing requirement to calculate whether a given name is
incertae sedis within its parent taxon, because it requires retrieving the
rank of the parent taxon as well as the current taxon? In this case, my
point is that incertae sedis has no meaning except in the context of a
parent-child relationship, so flagging a name as such without also knowing
details about the parent taxon (including its rank) doesn't provide us with
useful information.

> I don't know.  What I'd like to see is a way to put data without
> assistance of taxonomist as possible to assist review data and
> revision by taxonomists.

I guess I see this as a job of the TCS data parser.  When encountering a
parent-child relationship where a "root" rank is skipped, present the child
taxon as "incertae sedis" within the parent.  Perhaps I am too rigid in my
interpretation of when "incertae sedis" should be used.  I only ever have
seen it used when a "root" rank name was skipped in the classification of a
taxon.  However, a strict interpretation of the term does not necessarily
conform to this definition, and indeed it is legitimate to call a genus
"incertae sedis" within a family if all other genera within the family are
classified within subfamilies.  If this more strict definition is assumed,
then I can understand a desire to capture the data source's flagging of
incertae sedis status.

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 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.
>
> If so, how do you explain the richness of reference types of TCS?

I'm not the person to answer that question...! :-)

> > 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?
>
> I don't know SEEK-Taxon's requirement, but appropriate support of
> vernacular names is definitly necessary for GBIF.

I'm basing my recollection on the first LinneanCore break-out group meeting
we had in Christchurch (you, me, Chris, Anna, Sally, Gregor, Donald, etc.),
which (I believe) was not attended by anyone from the TCS group or SEEK. I
thought we were clear that LC (=NameObject) was limited to Code-governed
names (and possibly Cultivars and Trade Names -- I don't remember where that
ended up).

But maybe I remember things incorrectly.  I agree that GBIF needs to
accomodate vernacular names, and I don't dispute that vernacular names need
to be accomodated (they are in TCS), or even that they need robust structure
with name-name relationships & such (not, I believe, well accomodated by
TCS).  But if they do need more robust structure, then do you think it
should be built within the Concept substructure, or within NameObject,
or...?

Aloha,
Rich

Richard L. Pyle, PhD
Ichthyology, Bishop Museum
1525 Bernice St., Honolulu, HI 96817
Ph: (808)848-4115, Fax: (808)847-8252
email: deepreef at bishopmuseum.org
http://hbs.bishopmuseum.org/staff/pylerichard.html


_______________________________________________
Tcs-lc mailing list
Tcs-lc at ecoinformatics.org
http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/tcs-lc


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/tcs-lc/attachments/20050917/79806fc4/attachment.htm


More information about the Tcs-lc mailing list