Change term - scientificName

[qgroom]

Term change

• Submitter: Quentin Groom
• Efficacy Justification (why is this change necessary?): The names of hybrids are very poorly standardized and the International Code of Nomenclature for algae, fungi, and plants (Shenzhen Code) is not being followed in the case of hybrid names. Data managers are probably not aware that the Code rules on this and changing the not normative elements of this term will help guide people to create more standardized names.
• Demand Justification (if the change is semantic in nature, name at least two organizations that independently need this term): Almost every taxonomic resource for algae, fungi and plants needs to handle names of hybrids.
• Stability Justification (what concerns are there that this might affect existing implementations?): These changes are only likely to improve stability
• Implications for dwciri: namespace (does this change affect a dwciri term version)?: none

Current Term definition: https://dwc.tdwg.org/list/#dwc_scientificName

Proposed attributes of the new term:

• Usage comments (recommendations regarding content, etc., not normative): Names of hybrids for algae, fungi and plants should follow the rules of the nomenclatural code (Articles H.1, H.2 and H.3). This means using the multiplication sign × to identify a hybrid, not an x or X. In Unicode U+00D7
• Examples (not normative): add examples ×Agropogon littoralis (Sm.) C. E. Hubb. , Mentha ×smithiana R. A. Graham and Agrostis stolonifera L. × Polypogon monspeliensis (L.) Desf.

[qgroom]

linked to issue #388

[qgroom]

Also some relevant debate in the closed issue #43

[matdillen]

I suspect some workflows, search engines and databases will trip over a character like ×, which is also not readily available on any modern keyboard without knowing the unicode. Can we include a fallback recommendation of lower case x, always followed by a space to avoid ambiguity?

Maybe also add the HTML encoding of the character (×) in addition to the unicode, as some people may find that easier to find and decode.

[MattBlissett]

Other non-ASCII characters like é, ß, š etc are necessary in author names, so I think it's best to update the workflow UI, search engines etc to cope, rather than reduce the quality of the data.

[matdillen]

Other non-ASCII characters like é, ß, š etc are necessary in author names, so I think it's best to update the workflow UI, search engines etc to cope, rather than reduce the quality of the data.

Ideally, yes, but I don't think that is always so easy to implement. I just checked, and most of our hybrid names are published with a lower case x to our IPT, as this is how our database exports them. Fixing this in our database seems unlikely to happen any time soon, given budget and priority constraints. Our system does offer an alternative solution (yet one that we would need to hack a bit) and the issue could also be addressed with an extra scripted step in the workflow post-database export.

But GBIF's name parser currently interprets these lower case x's to × anyway. Are there any scenarios where ambiguity would arise? Can a space-delimited x have any other meaning? I think that if we want hybrid names to get published in a less messy manner, we shouldn't set up additional technical blockers.

(It doesn't seem to be possible to query the API for ×, nor for š. é and ß do work. Also, ß seems to have a similar problem as the hybrid x, as sometimes the greek β is used instead.)

[MattBlissett]

Quentin's proposal uses "should" rather than "must".

We'll continue to do what we can with the data we receive, but it is always easier when the input is of high quality.

Greek letters were sometimes used as infraspecific ranks. You can search for names like Košel: https://www.gbif.org/species/search?q=Ko%C5%A1el with different results than for Kosel: https://www.gbif.org/species/search?q=Kosel

[matdillen]

It says should, and it also says that lower case x should not be used. I would clarify this and state that × should be used, but lower case x is acceptable if this is not feasible.