Change term - typeStatus

[nielsklazenga]

Change term

• Submitter: Niels Klazenga
• Justification: This proposal clarifies the usage of dwc:typeStatus. Issue New term - typifiedName #28 identified the need to clearly separate type status (in the sense proposed here) from the typified scientific name. During the discussion around New term - typifiedName #28, it came to light that the current definition of typeStatus is at odds with the most prevalent usage of the term. We consider usage of dwc:typeStatus in accordance with the current definition sufficiently rare that the least disruptive solution is to change the definition of the term, rather than mint a new URI. ABCD uses TypeStatus in the sense proposed here, so adopting this change will lead to consistent usage of the term throughout TDWG (and that we do not have to have this discussion again when Darwin Core and ABCD are being reconciled). typeStatus is also in the dwciri namespace, for use with an IRI, which only makes sense if it takes a vocabulary term, as is proposed here, rather than free text, which is the case under the current definition. This proposal replaces the proposal in issue New Term - typeOfType #327 and should go together with the proposal in New term - typifiedName #28.
• Proponents: Markus Doering, Rich Pyle

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

Proposed new attributes of the term:

• Term name: typeStatus
• Organized in Class: Identification
• Definition of the term: The kind of nomenclatural type an Organism represents.
• Usage comments: Recommended best practice is to use a controlled vocabulary such as the GBIF Nomenlatural Type Status Vocabulary. typeStatus is to be used together with a typified name, either typifiedName or scientificName, depending on how it is used.
• Examples: holotype, isotype, lectotype
• Refines: None
• Replaces: http://rs.tdwg.org/dwc/terms/version/typeStatus-2017-10-06
• ABCD 2.06: DataSets/DataSet/Units/Unit/SpecimenUnit/NomenclaturalTypeDesignations/NomenclaturalTypeDesignation/TypeStatus

[tucotuco]

This proposal has a serious challenge with respect to the Vocabulary Maintenance Specification stability requirement (Section 3.1 Justifications for change in https://github.com/tdwg/vocab/blob/master/vms/maintenance-specification.md ). The definition of the term has included the typifiedName and well as the type of type since 2007 (http://rs.tdwg.org/dwc/curatorial/version/TypeStatus-2007-04-17.htm), two years before Darwin Core was ratified as a standard. The proposal would break that stability. Furthermore, the statement "the current definition of typeStatus is at odds with the most prevalent usage of the term" is false. As of the 2021-01-12 snapshot of GBIF, 61.4% of Occurrences that have a value in the typeStatus field (n=6,673,342) are definitively not simply a typeStatus by the proposed redefinition. Of the remaining 38.6% there is an unknown number of values that are also not type of type values, meaning the prevalence of non-conformant data is even higher than 61.4%. A quick perusal of the top ten values of typeStatus suggests that the at least 5% more are not type of type values.
Given that the majority of usage is actually following the standard definition (especially since it is fine to only include the type of type and not the typified name), I believe the only viable solution is to propose a new term with the exact meaning that is sought.
In doing so, be aware of the requirement to demonstrate demand as well. TDWGers thinking it would be a good idea is not sufficient. There have to be independent stakeholders who actually need to share or aggregate the data in this way. Getting their endorsement and listing them as proponents will make it possible for the proposal to move forward.

[deepreef]

Thanks, @tucotuco -- this is very helpful! My inclination would be to leave it alone, and not even mess with a proposed new term at this time, until we see what emerges from the TNC-TCS effort. I think a single shift to a more robust/comprehensive taxonomy/nomenclature standard would be preferable than small incremental changes to DwC. I'm still mystified that my brain is stuck in the pre-2007 interpretation of typeStatus, and that I somehow completely missed the change to the current definition. But that's 100% on me.

[nielsklazenga]

@tucotuco and @deepreef, I agree.

[tucotuco]

Retracted. See #28 (comment).

[mdoering]

I would like to reopen this issue. The reality in GBIF is that 92% of records with values in dwc:typeStatus follow the proposed new definition of just the status. In such light it makes little sense to me to reject the issue because of stability.

[nielsklazenga]

I think it is good this issue has been reopened, so that it can be further discussed and we can come to a conclusion. We need a term with the proposed definition, but personally I think that with such a significant change to the meaning it is better and less disruptive to create a new term than to apply an existing term to a new concept. TCS has the term TypeOfType (Dataset/TaxonNames/TaxonName/Typification/TypeVouchers/TypeVoucher/@typeofType), so it seems obvious to go with that (prop. #327).

dwc:typeStatus in its current meaning might not be a great loss, but dwciri:typeStatus in my view would be, as that can provide a link to the Nomenclatural Type object and through that to the Taxon Name.

[CecSve]

It would be good to open this issue again. GBIF normalises values to an updated type status vocabulary: https://registry.gbif.org/vocabulary/TypeStatus - it may be relevant to update the usage comment with this link instead of the rs.gbif.org resource, but I have not looked at the potential implications of doing so yet.

[matdillen]

It would be good to open this issue again. GBIF normalises values to an updated type status vocabulary: https://registry.gbif.org/vocabulary/TypeStatus - it may be relevant to update the usage comment with this link instead of the rs.gbif.org resource, but I have not looked at the potential implications of doing so yet.

Unless I'm missing something, this normalisation process now flags provided values for dwc:typeStatus that fit the examples of the current Darwin Core definition as invalid. The current examples, not the proposed ones, i.e.:

    holotype of Ctenomys sociabilis. Pearson O. P., and M. I. Christie. 1985. Historia Natural, 5(37):388
    holotype of Pinus abies | holotype of Picea abies

For example: https://www.gbif.org/occurrence/1839377904 with a provided value for typeStatus of Isotype of Pithecellobium curvicarpum H.S.Irwin

This specimen is no longer findable as a type specimen. In the API response, gbif:typifiedName is still listed (as parsed out of the provided dwc:typeStatus value), but dwc:typeStatus is not. The typeStatus value is listed in this SQL-based download, but not in this predicate one.

This is a discussion best held at gbif and not on this repo, but it highlights the need for a change. The reality is that the current definition of dwc:typeStatus is not intuitive, ambiguous and is only used correctly in a minority of cases.

That's to say, I am puzzled by @tucotuco 's comment:

(especially since it is fine to only include the type of type and not the typified name)

From the discussion here (and in the related issues) and the documentation of dwc:typeStatus, my interpretation is that this is not the case. At the very least the examples do not support the usage of dwc:typeStatus solely for type of type values like Holotype.

So perhaps an easy change without breaking repercussions would be to explicitly state that, in addition to the current examples, 'bare' type of type values like Holotype are allowed in dwc:typeStatus and that the recommendation is to then provide the typifiedName (even if just to remove any room for ambiguity) as dwc:typifiedName, a new property that should then be added to the Identification class. This would also make it available for the Identification History extension (I think, not sure how the maintenance of that works specifically), which would be a way to address the (potential) cardinality problem.