[SEEK-Taxon] LinneanCore Group Work

[Kennedy, Jessie]

Dear All

Sorry for the delay in responding and contributing to the Wiki but I was lucky enough to have a holiday in New Zealand and then I was working in Kansas on the SEEK project and have only returned to my office this week, needless to say to be overwhelmed by work and by the activity on the Linnean core Wiki!

I am unsure about how best to respond to certain things on the Wiki but do feel that I must so felt that an email to this group would be most sensible in the first instance (apologies for the length of it...)

I think there is some great stuff on nomenclature issues which it is good to see documented, questioned and discussed e.g. 
LinneanCoreHomoIsonym (issues of homonym isonym, and nomen novum/replacement name)
LinneanCoreHybridNothotaxa (issues about hybrid formulae and "notho"taxa [named hybrids])
LinneanCoreNameIdentity (How many elements necessary for infrageneric/specific ranks?)
LinneanCoreConceptSuffixString (provide a place in atomization for "s. lat." etc.?)
LinneanCoreResourceLinks (Links to BioCode, etc.)
LinneanCoreExampleNames (names from different kingdoms, hard cases etc.) 

It would be really valuable for me and I guess others if someone could provide for zoology what Sally has for Botany in terms of examples.

There is also some useful material on issues not confined to nomenclature alone which is great e.g. Relevant enumerations:
TaxonomicRankEum (see also formatted html page)
NomenclaturalTypeStatusOfUnitsEum
NomenclaturalStatusEnum? (e.g. Rejected, Conserved, Sanctioned, etc. Unfinished - input most welcome!)
NomenclaturalCodesEnum (e.g. "Botanical/Zoological" for ICBN, ICZN, etc.)

However..........

Although I was under the impression that at the Taxon Concepts/Names subgroup on the Saturday at TDWG there was general understanding of the goals and rationale for the TCS and how it intended to deal with nomenclature issues in addition to concepts issues within the one framework, I can see from the discussion that either I (and those present at the meeting) was wrong or it no longer seems to be the case amongst those contributing to the Wiki. I also see that there is confusion and disagreement amongst those contributing to discussion on the Wiki what the role of Linnean core subgroup is and I see the beginnings of TCS discussions emerging all over again (maybe this is side effect of using Wiki's as any comment can be made thereby making it difficult to know and follow what the relevant discussion points are)

During TDWG Linnean core was being pushed by some as a simple way of providing access to lists of valid names with Darwin core being used as an analogy i.e. it would be a simple list of fields. That was basically what the name components from ABCD which were incorporated into TCS were and what I was informed was being discussed and re-considered by the Linnean core group to ensure the requirements of the nomenclator community were being addressed (and I was and am grateful that this work is being done). 

However I am disappointed that much of the confusion and requests for changes to Linnean core/ABCD and hence TCS is coming from Gregor (sorry Gregor, I am impressed by your drive and enthusiasm to have your say in all these discussions but find some of your comments unconstructive). There was invitation to all interested in TCS (names and concepts) to attend the relevant working group meetings during TDWG, so I find it unreasonable that Gregor is saying that he doesn't understand TCS when I went to lengths to explain it's rationale and design philosophy and gave people a chance to raise any questions or issues and to address any misunderstandings. Gregor however didn't give a presentation on his ideas at the meeting even though he submitted an abstract suggesting he would nor did he attend the subgroup session on Saturday nor the Linnean group session on the Sunday. I wasn't even aware that Gregor was a nomenclator but perhaps I'm wrong or I misunderstood the reasons for re-considering the ABCD section. However, I would've thought that Gregor had enough on his plate trying to finalise possibly the most complicated of all the TDWG standards (SDD in addition to UBIF) and that it would have been reasonable for him to accept that other groups can consider and reason about the conflicting requirements of all potential users of the standard on coming to a design decision.


I have the following reservations based on some of the discussion on the Wiki:

It is unfortunate that following years of work by the ABCD group that there doesn't appear to be an ABCD representative contributing to the discussion - are you sure that you aren't overturning well reasoned and argued decisions on why things were designed the way they were?

ALL agreed at the meeting that specimens or observations should be labelled with concepts_names (or concept GUIDs) not scientific names ( e.g. binomial plus original author) therefore I don't understand why is this even being given wiki space unless you're starting the modelling process from scratch again.

There seems to be confusion about what a transfer schema should do. To support the community at large it should not dictate how any application should be implemented, nor should it dictate what any database system must or must not contain, nor should it present a view of the world from only one of the community's perspective - if we want a community standard exchange format everyone must move from their own view/model of the problem/requirements but still be able to map their data to the schema to exchange their data. (Why I explained the different types of users/views of what concepts/names were in my presentation)

Some of the discussion is about what a particular application i.e. a nomenclature tracking system or name resolution system should do and requires - I don't believe this should be encoded in the schema - it should be documented in the mapping from that database onto the schema or in the specification of the software design. This is still important and the work may still to be done....but not as part of a schema design.

Although the process of nomenclature is separate from the process of classification (and yes I'm co-author on a paper in Taxon arguing this), as soon as one considers the use of names - either by taxonomists or other biologists or even nomenclature specialists I haven't seen a convincing discussion or proposal that actually keeps names separate from concepts and I am even more convinced of this having talked to a wide range of potential users this past year. So let me re-iterate: people can't refer to concepts without names nor does a name exist without some kind of relationship to a concept. Perhaps those of you who are expert in and only interested in names for their own sake think you can and if that's so I accept that as I do the many ways that people define concepts which to me may personally seem strange, however the vast majority of biologist and users of names can't and don't. So regardless of the fact that some people say a concept can have many names - how I interpret this is that they mean that the definition part of the concept can be the same in different taxonomic concepts with different names - this is how we have modelled it, explained it and require it to be understood to engage in a meaningful discussion about how for example Linnean core fits into TCS or how any particular issue or data problem can be represented in TCS. I tried to emphasise this at TDWG and thought I had succeeded but now am wondering if I did.  


Based on these points it seems to me that the discussion on the Wiki is introducing concept issues into the requirements even though some people are trying hard to keep it concept free. If this continues  what in my mind will eventually happen (even if you try your hardest to ignore information that is unequivocally only about concepts) is that you will still come up with an abstract model that needs to deal with everything that the TCS already does, e.g. names will have: specimens, relationships between them of different types (whether you choose to model this as relationships or embed them in the data type), citations, authors, (descriptions?), other people's opinions on the relationships someone else asserted about a name etc.... So we will have two schemas to handle taxonomic names and concepts - does the community really need this? Will this be finalised any quicker than TCS? Concern has been raised about waiting for TCS to be finalised... so what's actually holding up finalisation of TCS - is it because of a "it doesn't represent things the way I do it" phenomenon? I believe that TCS is almost finalised or could be very soon and I hoped that the Linnean core would help that by getting agreement on the fields necessary to detail a name applied to a concept - currently the according to element and the name element (ABCD name) in TCS. The only other things we are waiting on is an agreed interface to the other schemas being developed, i.e. the elements we have marked with placeholders. However we don't need to wait for all the other schemas to be completed to move on - for those desperate to move on they can use a proposed schema knowing that they will have to transform their data or software to deal with the agreed schemas in due course (this is not a problem confined on ly to TCS). The placeholders include publication, specimen vouchers for which TCS would suggest a GUID attribute plus a set of fields which can uniquely identify the object being represented by the other schema in the absence of GUIDs and which also act as a human readable version of those elements. 

I guess I could continue but I'm sure that it will be counter-productive at the moment. I could and in fact would like to try and explain things again if anyone doesn't get the idea we're presenting. I would like to ensure that we have understood and taken into account all of the requirements of nomenclators - much of the information on the Linnean core Wiki will contribute to that understanding, and am sure we can find a good solution. I only ask you to be careful that you don't end up re-doing what we did last year but with a narrower group of users unless you really intend to, in which case we should be clear about the fact that that's what Linnean core is doing.

Having read this far I hope you don't think I've made these comments because the Linnean core Wiki is suggesting changes to our proposal and I simply don't like it. I'm very happy to have good suggestions which improve the schema but if the suggestions fundamentally change it then I'm reluctant to start modelling TCS over again. If they are suggestions because of misunderstandings then it's a waste of time arguing back and forth until we explain TCS more clearly. So I am happy to reply to specific questions about the relationship between Linnean core and TCS but unless the philosophy of TCS is understood the discussion may become a bit pointless.

Jessie