OFF LIST: Re: [tcs-lc] My comments on the draft

[Gregor Hagedorn]

Hi Roger,

> I would like to drop TaxonConcept as a term because we are designing a 
> data structure for passing information that may be concept data or may 

> I am also suggesting that I write a friendly and readable "User Guide" 
> to the TCS/LC. I hope that I can then illustrate how it can be used for 
> different purposes simply and without data loss.  

I think writing such a user guide is an excellent suggestion. I would hope that 
it could be written for (at least) two perspectives: 
  a) data provider
  b) data consumer (i.e. software agent).

I think many things in current TCS are heavily geared towards a), especially by 
adding many relation vocabulary terms that may be useful to publish your data 
somehow. However, I felt at loss how to use TCS data from the b) perspective. 
The semantics of the relationships is little defined and is left for me to 
guess (as in the guide accompanying the release for TDWG 2004). Moreover, the 
interaction between relationships and the different concept types seemed to me 
unexplored. They are, however, essential to make any sense of the data for 
consumers. For example, it seems to be that the semantics of what a "parent" or 
"child" is drastically differs whether I have nomenclatural data, a hierarchy 
of concepts, or a circumscription concept. In terms of circumscription 
concepts, Ustilago violacea is a child of the Genus Microbotryum and the order 
Uredinales (or close to it), in terms of original publication concept it is a 
child of Ustilago and Ustilaginales, and in terms of nomenclature a child of 
Ustilago and the order does not matter.

Jessie in the design of TCS and - as I understand you - you lean towards 
combining TypeConcepts (nomenclature), specimen circumscription concepts 
(extend of a definition), and hierarchy concepts (phylogeny). I do agree that 
there are a number use cases where a combined view is benefical, e.g. in many 
identification use cases.

However, to my user perspective it seemed much clearer that when splitting 
nomenclatural from other concept relationships, I would know much better what I 
can do with the data and what the provider intended to express. The semantics 
of data need to be clear to both users and consumers, and should not be subject 
to individual testing by consumers for each provider what it considers a 
"parent" or a "basionym", and which semantics are meant in the context of a 
given concept type.

My feeling is that separating the issues into different types helps many 
biologists, because that is the way codes of nomenclature work for me (I cannot 
speak for "all" biologists). I welcome, however, any other approach that may   
ultimately be a better solution. The test case is exactly what you propose, 
whether communication of a different "combined" object concept, especially to 
biologists, can be achieved or not. And whether it is able to reflect current 
practices in biology, as well as future practices we may hope for.

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