Open Nomenclature

Just wondering how others have incorporated Open Nomenclature into their Specify system? I was thinking that linking to the relevant taxon in the taxon tree and having that data duplicated in another field (this is the name that actually gets displayed and pushed to the web). This latter field can then be edited to include cf., aff. ? etc - thus not going near the taxon tree. Has something like this been attempted in Specify by others?

Pip, would be good to have more discussion about this. I’d not come across the term Open Nomenclature before. Found it on Wikipedia though (Open nomenclature - Wikipedia)

We currently put most of open nomenclature, including the cf., aff., etc into the determination which works pretty well since they are more taxonomic concepts rather than nomenclatural concepts.

We put nomenclatural concepts (eg, Invalid, nom. nud., etc) into the Taxon record, using a picklist field.

I have seen this handled in a number of different ways. Some collections put this info into the names in the taxon tree as part of the genus or species name. This works but does create a bit of a mess in your taxon tree and makes searching harder.

Others include prefix and suffix fields (these can be found specified in the schema for that table) on the determination form (as these are really determination criteria and not part of the taxon name) and then use these when formatting their names for labels and other printed output to include these in the name build. An “In Question” Yes/No field can be used in much the same way but doesn’t provide as much flexibility.

I like how you include ‘cf,’ in the verbatim determination, @ehaston . The determination table has fields qualifier, subspQualifier and varQualifier. I think just one qualifier field is all that is needed. The ‘cf.’ always refers to the last part of the name determined whether that is a generic name, a specific or an infraspecific epithet.

The qualifiers such as cf. relate to a specimen determination and so should not really go in the taxon tree. There are different types of qualifiers - ones that go at the front, within or at the end. If there are subspecific or subgeneric taxa or varieties (i.e., not just a simple binomial), it is not always clear how the qualifier should relate to the taxon string and so having 3 separate boxes (which seems to be overkill anyway) still doesn’t always resolve things correctly. It seems to me that there should be a cleverer way of doing this. We implementing something similar to what I originally suggested when using EMu at the NHM in London and it seemed to work well.