[tcs-lc] Names as Objects

[Kennedy, Jessie]

Gregor wrote:
>
>Even I - having followed of this discussion - don't understand 
>how that would 
>look. If I publish an xml document that contains the new 
>monograph for a genus -
> how do I represent the names for which I provide keys and 
>descriptions in that 
>document? 

you would just enter the name in the name element - if it were a completely new name then nothing else, if you were syaing the name was a nov.comb or whatever you would enter a relationship to the original concept that is was nov/comb of. As fzar as I know all names have to be published to you would put the your name and the publication in the AccordingTo. 
>
>I believe, to allow some diversity in biodiversity research :-), it is 
>desirable not to embed everything in TCS. I would like to have 
>the Fauna/Flora 
>xml creation, or perhaps separately xml text markup standards. 
>How, in the 
>context of this standard, assuming it is not TCS, do I express 
>a simple name 
>like Sally's "Poa acroleuca var. ryukyuensis H.Koba & 
>T.Tateoka"? This my 
>question. 
>
I will do that soon....
>Importantly, the issue is not simply about linking to an 
>existing taxon-
>concepts database and put the id into the new document. If the 
>online-monograph 
>creates a new concept, at least the nominal concept may be in 
>a name service 
>(most likely it is not databased yet, however). But if the 
>name is new as well, 
>it can not possibly be there. 

?why?

>The author of that monograph, although creating well defined 
>taxon character 
>circumscription concepts, may not be very well educated on how 
>to use a TCS 
>application, she or he may not desire to do so and may not 
>desire to understand 
>the distinction between nominal, Original, Revision, 
>Incomplete, Aggregate 
>concepts.
>
agreed but same could be said of any of the schemas we come up with....

>I have personal doubts about the TCS concepts types because I fail to 
>understand the definitions given in the TCS documentation. 
>These seem to not 
>speak my language. However, I believe it is important to have 
>such mechanisms, 
>for those expressing concept knowledge. I just try to argue 
>for lowering the 
>entry level for the kind of data that are currently being 
>produced. I do not 
>believe that the theory is far enough progressed to make it a 
>prerequisite for 
>delivering any biodiversity data.
>
yes I realise you know the importance of concepts etc and I know why many see names as being re-used all the time. If I changed TaxonConcept to TaxonName what really would be different (apart form details please...) We would need a name element like we have, something like an According_To to say who published the name and where, we would want vouchers - for the type specimens, we would want relationships to relate the name histories etc., name placements e.g. bus placed in Aus, and potentially a description (or pointer to the original description) going by Rich's last emails. This looks very much in abstract terms like the TCS schema....

Thing is I believe you don't want to pass all of this nomenclatural informaitn around with your names either Gregor, you just want the code validated name - not the reasons why it is valid etc. - am I correct? I think this is what Walter wants too for ABCD. So I think he was hoping for a "simple type" to replace in ABDC - even though I think he should have a concept reference in there (even if it is a nominal one)

If we had the name type as we took from ABCD or something equivalent (maybe modelled slightly differently) then you could use these types and if you really wanted to give them guids - but they would be GUIDs for "simple" names without the extra references to other objects etc. Is this what people really want - I really can't tell any more....

Jessie

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.