[tcs-lc] [Tcs-lc] concepts of Higher taxa

[Paul Kirk]

I've been doing '"implied, undefined concepts" linking for many years without realizing - thanks for the label Gregor ;-)

________________________________

From: Gregor Hagedorn [mailto:G.Hagedorn at BBA.DE]
Sent: Tue 05/04/2005 12:21
To: Richard Pyle; tcs-lc at ecoinformatics.org
Subject: Re: [tcs-lc] [Tcs-lc] concepts of Higher taxa



(Note: I accidentially did not sent my previous answer, to which Rich 
responded, to the list; therefore repeated below) 

> Gregor wrote: 
> > I fully agree that this 
> > (the information about placement of new species in higher taxa) 
> > is not nomenclatural information, the question I try to 
> > raise is that for me, in the almost ubiquitous absence of revisionary 
> > treatments, information about higher placement is a valuable data 
> > item in my work. What brings you to say we can ignore this? 
> 
> I didn't mean ignore the information altogether -- I meant disregard the 
> Nomenclatural connection.  That means the connection between a genus and a 
> family should be established via TCS "Conceptual placement" structure. 

We agree on this, but how does the "Conceptual placement" work? 

> I think what it means is that I am more liberal than most in 
> accepting an "implied concept" for non-revisionary work; which can only be 
> mapped to other (more well-defined) concepts via third-party (interpretive) 
> RelationshipAssertions. 
> 
> > The question at 
> > the bottom is: should we treat these fragementary classification 
> > assignments identical to a full, revisionary and coherent classification 
> > SYSTEM, should we 
> > completely ignore them and provide no place for them in TCS, or 
> > should they get 
> > a special handling - as an option. 

Rich wrote: 
> These are why I proposed changing the TaxonConcept type enumration from: 
> 
> 1. Original 
> 2. Revision 
> [...] 
> 
>  -- to -- 
> 
> 1. Defined 
> 2. Implied 
> [...] 
> 
> Types 1 & 2 from current TCS would be lumped together into Type 1 of my 
> proposed change (the distinction between "Original" and "Revision" being 
> nomenclatural in nature); and my proposed type 2 would be for cases you 
> describe -- scientific in nature (and therefore useful), but not including 
> full definitions of concepts. 
> 
> [Note: In my previous post on this, I used the word "Undefined" in place of 
> "Implied"; but on reflection I think "Implied" is a better word, because often 
> they will be partially defined.] 
> 
> So, my vote would be for "special handling" in the form of type="implied" 

That sounds good to me, except I am not sure where exactly to draw the border 
between defined and implied concepts. That is, I fail to be able to define it 
in an exact way, but I think we try to. 

> Gregor wrote: 
> > I meant to 
> > indicate that I would like SOME mechanism to keep them apart. The 
> > old LC was 
> > only an attempt, I try to say that any other, including the standard 
> > "Conceptual placement" is fine - but how do we tame the tiger of 
> > exploding numbers of concepts, which I see at the bottom of the this thread? 

Rich wrote: 
> I think we should embrace that tiger, and we should accept that the 
> reusability will come via RelationshipAssertions. 
> 
> As I have argued in the past, my gut tells me that all Auther-Date-Name 
> usages should be (skeletally, at least) considered "potential" 
> TaxonConcepts.  Howeverm I'm not reaching that far in this case.  I won't go so 
> far as to say that every single name-usage (specimen labels, ecological 
> datasets, etc.) should be represented as a TCS instance.  However, like you (and 
> I think like Martin as well), I see a need to represent "implied" (but not well 
> defined) TCS TaxonConcept instances; for example, to serve as a genus "bridge" 
> between a new species description (outside the context of a generic revision), 
> and the family in which the original describer placed the new species. 
> 
> > If any author publishing a species and placing it in a phylum creates a 
> > new, unique classification concept of the phylum (containing only the new 
> > species, because that is the only information in that publication) 
> 
> No!  When the author described the new species and placed it in a phylum, 
> the author (almost always) did *not* intend the phylum concept to be 
> monotypic.  The author had in mind a concept for the phylum -- but simply 
> failed to include sufficient information within the context of the species 
> description to fully document the boundaries of that phylum TaxonConcept. 
> Thus, to me, it represents an "implied" concept that was not fully defined, 
> which can be mapped to other (more well-defined) TaxonConcepts via third-party 
> RelationshipAssertions. 

I think I agree with you regarding the implied concepts, but wouldn't we 
technically have to create a TCS instance for each of these "undefined" 
concepts? 

> > we end up 
> > having 100s or 
> > 1000s of concepts of this phylum. 
> 
> We may end up with 100s or 1000s of TCS instances (each with a unique GUID), but 
> many of these will collapse into "Congruent" Relationships with other "Defined" 
> concepts via RelationshipAssertion mappings. 

Who will be doing this? I think this is impractical. Since these implied 
concepts do not carry any information (as you say, we simply do not know which 
concept the author pointing to a family for the new genus meant), but only 
existence, it seems to me that the model should be able to handle them 
otherwise, i.e. not having to create "dummy implied concept" instances. 

It seems to me easier to point these generically to the name level rather than 
to concept record. Pointer from a name or concept to a name would by definition 
be "implied, undefined concepts". 

> > My proposal is to allow a somewhat separate 
> > way of expressing an indicated placement without the need to 
> > creat a new higher class concept. I imagine this simplest by creating a 
> separate 
> > relation, but if the difference of "Conceptual placement" relations can be 
> > detected otherwise, and that would become part of the TCS specs, I am 
> quite happy. 
> 
> I don't think we're that far off -- I just have no aversion to allowing 
> pr0liferation of "implied" TaxonConcept instances -- especially if limited 
> mostly to published/taxonomic ones where a TaxonConcept really was implied 
> (but not well-defined). 
> 
> Aloha, 
> Rich 

Gruss nach Hawai! 

Gregor---------------------------------------------------------- 
Gregor Hagedorn (G.Hagedorn at bba.de) 
Institute for Plant Virology, Microbiology, and Biosafety 
Federal Research Center for Agriculture and Forestry (BBA) 
Königin-Luise-Str. 19           Tel: +49-30-8304-2220 
14195 Berlin, Germany           Fax: +49-30-8304-2203 

_______________________________________________ 
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/20050405/e3f88593/attachment-0001.htm