Change term - subgenus

[tucotuco]

Change term

• Submitter: John Wieczorek @tucotuco
• Justification (why is this change necessary?): Based on discussions in Issue #176, it was suggested that the examples for subgenus were not strictly correct. The examples were changed to remove the reference to the genus, but the definition of the term still includes "Values should include the genus to avoid homonym confusion." First of all, that should be a usage note and not a part of the definition and should have been pulled when work was done to divide comments from definitions. This is an interesting case, because it isn't actually a semantic change that is being proposed, despite the fact that the definition would change. Thus, it is a little unclear whether it would have to go through public review. To stay on the safe side, we should include it with a series of Taxon term change requests. The issue that inspired this change request was made by @Jegelewicz.
• Proponents (who needs this change): Everyone sharing or searching for information based on subgenus.

Current Term definition: https://dwc.tdwg.org/terms/#dwc:subgenus

Proposed new attributes of the term:

• Term name (in lowerCamelCase): subgenus
• Organized in Class (e.g. Location, Taxon): Taxon
• Definition of the term: The full scientific name of the subgenus in which the taxon is classified.
• Usage comments (recommendations regarding content, etc.): Values should not include the genus, nor should they be in parentheses.
• Examples: Strobus, Amerigo, Pilosella
• Refines (identifier of the broader term this term refines, if applicable):
• Replaces (identifier of the existing term that would be deprecated and replaced by this term, if applicable): http://rs.tdwg.org/dwc/terms/version/subgenus-2017-10-06
• ABCD 2.06 (XPATH of the equivalent term in ABCD or EFG, if applicable): DataSets/DataSet/Units/Unit/Identifications/Identification/Result/TaxonIdentified/HigherTaxa/HigherTaxon[HigherTaxonRank="subgenus"]/HigherTaxonName

[baskaufs]

dwc:subgenus falls into the category of "convenience terms" so there will be no change to a dwciri: analog.

[nielsklazenga]

I would remove the ABCD 2.06 equivalent, as Subgenus in ABCD is the infragenericEpithet, not the taxon as intended here.

[tucotuco]

I would remove the ABCD 2.06 equivalent, as Subgenus in ABCD is the infragenericEpithet, not the taxon as intended here.

@nielsklazenga I'm not sure I understand this, but I trust your observation and no one has objected. I have amended the ABCD mapping from "DataSets/DataSet/Units/Unit/Identifications/Identification/TaxonIdentified/ScientificName/NameAtomised/Zoological/Subgenus" to "not in ABCD".

[nielsklazenga]

@tucotuco , kingdom, phylum, ..., and subgenus are all taxa (or at least complete names), while genericName, infragenericEpithet, specificEpithet and infraspecificEpithet are parts of names (that are combinations). The ../Subgenus elements in ABCD are equivalent to infragenericEpithet (#30), not subgenus.

[tucotuco]

Thank you @nielsklazenga. I think that clarification will be helpful for a lot of people.

[nielsklazenga]

I did not think about this before, but even simpler might be that subgenus is part of higherClassification and infragenericEpithet of scientificName.

ABCD 2.06 equivalent for subgenus could be DataSets/DataSet/Units/Unit/Identifications/Identification/Result/TaxonIdentified/HigherTaxa/HigherTaxon[HigherTaxonRank="subgenus"]/HigherTaxonName, if you want to go that way. I think that is valid XPath, but my XML is a bit rusty.

[jholetschek]

That's a good idea, Niels, but according to the ABCD documentation, the HigherTaxa are for "taxonomic ranks above the rank of genus". So I'm afraid there is no equivalent.

[nielsklazenga]

Ha, good one @jholetschek. Could you confirm that I at least put the condition in the XPath correctly? @DavidFichtmueller suggested something similar for subfamily in https://github.com/tdwg/dwc/issues/44#issuecomment-831194476.

[jholetschek]

Yes, David just confirmed that this XPath is correct ;)

[tucotuco]

Thanks @nielsklazenga and @jholetschek, updated in the proposal in the first comment.

[JCGiron]

I would argue that keeping the subgenus accompanied by its genus and in parenthesis [i.e. Genus (Subgenus)] would prevent misinterpretations. In some groups of beetles, sometimes, entire subgenera have been transferred to different genera, so I think it is important to be able to point to the correct, current treatment and avoid ambiguity in those cases.

[tucotuco]

This proposal has been labeled as 'Controversial'. It will remain open for public review in pursuit of a consensus solution for another 30 days, but will not be included in the release to be prepared from the public review of 2021-05-01/2021-05/31.

[dschigel]

As this came in the GBIF Global Nodes meeting, my two cents from entomological past: subgenus has been a useful and broadly used rank in families with huge genera, e.g. Staphylinidae. I have seen independent use of subgeneric epithets but I can consider this suboptimal practice and I support use of sg together with the genus epithet. Example of the view that is pleasing to my eyes from page 5: Acylophorus (Paracylophorus) schmidti Bierig, 1938. Similar wishes were expressed above.

[tucotuco]

Public review of this issue has now concluded with objections to the proposed change. The issue will remain open for discussion and potential resolution.

[nielsklazenga]

I agree with @JCGiron and @dschigel that subgenus should include the generic name. The Botanical Code requires this in infrageneric names, so for me it does not need to be in the definition, but it is probably different in other Codes.

The botanical examples should be written as 'Pinus subgen. Strobus' and 'Hieracium subgen. Pilosella', but they are problematic, as these combinations do not exist. "Strobus" is a section of Pinus (or a genus on its own) and Pilosella is a genus, not a subdivision of Hieracium. It might be best to remove the botanical examples altogether, as the term is unlikely to be used by botanists, as in botany there are additional infrageneric ranks.

I think the addition of the term infragenericEpithet (#30) has achieved what the proposers tried to achieve here, so I think this issue can be closed, but do not take my word for it.

There remains the issue that currently the examples for subgenus do not correspond with the definition.

[timrobertson100]

I think the addition of the term infragenericEpithet (#30) has achieved what the proposers tried to achieve here

Please bear in mind I'm not a biologist when reading this, but I'm not sure I agree.

Using the scientific name Doryteuthis (Amerigo) surinamensis (Voss, 1974) as an example, you would have Amerigo as the infragenericEpithet, but that is different from the concept for the subgenus which would presumably be something like Doryteuthis (Amerigo) Brakoniecki, 1996

keeping the subgenus accompanied by its genus and in parenthesis [i.e. Genus (Subgenus)] would prevent misinterpretations

With guidance to render it as you propose, is it perhaps disambiguated enough to avoid misuse?

I'm not the instigator of this request, but my interest in keeping the discussion open is that, rightly or wrongly, GBIF uses convenience denormalized pointers into a taxonomy to search occurrence records. I'm interested in making sure we use the subgenus and its associated subGenusKey correctly when we implement it.

[mdoering]

It would be good to at least address the wrong examples for the current definition which all uses just the plain subgenus name without genus or authorship

[mdoering]

This is very much related to all other higher rank terms which all say the same, e.g. for family:

The full scientific name of the family in which the taxon is classified. Examples | Felidae, Monocleaceae

So does the full scientific name include authorship? The DwC definition of dwc:scientificName suggests that:

The full scientific name, with authorship and date information if known

And if that's the case I reckon all examples should at least also include one with authorship. And probably the usage notes should be emended too.

[nielsklazenga]

@timrobertson100 :

Please bear in mind I'm not a biologist when reading this, but I'm not sure I agree.

I am a botanist, which probably disqualifies me from talking about subgenus. I did realise something though when reading your next paragraph. At least in botany, infragenericEpithet is only used in infrageneric names (names for subgenera, sections etc.), so infragenericEpithet cannot be used instead of subgenus, which is often used with species and infraspecific taxa.

[nielsklazenga]

@mdoering :

So does the full scientific name include authorship?

At least according to the Botanical Code (sorry, it is the only one I know) the authorship is not part of the scientific name. I do not think the definition of dwc:scientificName suggests that it does, but I will grant you that it can be read either way. dwc:scientificName seems to definitely include authorship (which I do not like).

I always get tripped up by 'full scientific name', as to me, for taxa below the rank of genus, that means the generic name plus the epithets and rank prefixes. It might mean something different to other people.

[Jegelewicz]

dwc:scientificName

The full scientific name, with authorship and date information if known.

Seems to me that authorship is part of that? If authorship is not included, there could be added confusion when it comes homonyms, although this could be disambiguated with scientificNameAuthorship (which ends up seeming redundant if it is also part of scientificName). So there we are - maybe scientificName should NOT include authorship, then we could lose GBIF's canonicalName?

Which probably means a new issue....

[nielsklazenga]

@Jegelewicz , I agree, but it is bound to be controversial and I am not sure it is a fight worth having. I think it is probably best to aim for the inclusion of authorship and date to be optional, which it sort of is now, and leave whether it SHOULD or SHOULD NOT be included in scientificName to application profiles. canonicalName is a useful term no matter what, but possibly best to keep out of Darwin Core, as it is a result of data processing. We (in the TNC) will be discussing it in relationship to TCS.

[jar398]

For the record I've just had occasion to consult the documentation for subgenus and encountered the inconsistency between the definition and examples. I have no opinion as to which way it should be resolved, but I think it should be resolved somehow because it makes no sense as it stands. From the perspective of someone who writes software that generates and processes Darwin Core files I don't think it matters much how it's resolved; perhaps current (deployed) use (if there is any) should guide the decision?