[tcs-lc] Incertae Sedis

[Roger Hyam]

I have added this as a issue (036) against the User Guide. We should 
have a section summarising comments below. Whether a schema change is 
needed will come out in the future.

Kennedy, Jessie wrote:

> I propose that we make this a discussion point for the next version. 
> We will add this to the Wiki as a discussion item. I would hope that 
> we get clarification from the taxonomists on this before we start 
> changing the schema or proposing ways of dealing with it when there 
> are many ways to interpret it.
>
>  
>
> Thanks to Rich for the summary of the interpretations of Incertae 
> Sedis - I've now added James' last interpretation and his options for 
> dealing with it.
>
>  
>
> 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.
>
> Ytow2:
>
> incertae sedis is a kind of hierarchical relationship between 
> TaxonConcepts of different ranks, although one of these TaxonConcepts 
> may or may not exist in the source databases depending on scope of the 
> database (and query?).
>
>  
>
> 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 second message seemed to indicate it as a placeholder 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 hierarchical level 
> below." -- [similar to Richs' "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.
>
>  
>
> James' Options:
>
> Option 0:  Ignore incertae sedis this time, may be documented our 
> recoginition though.
>
> Option 1a: Add incertae sedis as to rlationship type enumeration.  It 
> may require data providers to create a dummy data say "Life".  We 
> shall see.
>
> Option 1b: Add incertae sedis as to rlationship type enumeration, and 
> allow minOccur=0.
>
> Option 2: Add incertae sedis as a subtype of "is parent of" and "is 
> child of".  It could be non-minor modification.
>
>  
>
>  
>
> This message is intended for the addressee(s) only and should not be 
> read, copied or disclosed to anyone else outwith the University 
> without the permission of the sender. It is your responsibility to 
> ensure that this message and any attachments are scanned for viruses 
> or other defects. Napier University does not accept liability for any 
> loss or damage which may result from this email or any attachment, or 
> for errors or omissions arising after it was sent. Email is not a 
> secure medium. Email entering the University's system is subject to 
> routine monitoring and filtering by the University.
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Tcs-lc mailing list
>Tcs-lc at ecoinformatics.org
>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/tcs-lc
>  
>

-- 

==============================================
 Roger Hyam
----------------------------------------------
 Biodiversity Informatics
 Independent Web Development 
----------------------------------------------
 http://www.hyam.net  roger at hyam.net
----------------------------------------------
 2 Janefield Rise, Lauder, TD2 6SP, UK.
 T: +44 (0)1578 722782 M: +44 (0)7890 341847
==============================================


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