Open RBGE-Herbarium opened 3 years ago
Information Element Name | TypeStatus |
Modified | 2023/12/14 |
Label | Type Status |
Definition | An indication of the nomenclatural type status of the specimen, where a null value is taken to mean "Assumed not to be a type". |
Purpose | The nomenclatural type specimens are some of the most important specimens in a collection, particularly for taxonomic research. They anchor the taxon name to a physical object. |
Applicable standard(s)/recommendation(s) | It is strongly recommended to follow the list of terms included in the relevant codes of nomenclature. |
Required | Yes (Biology) |
Constraints | A null value is taken to mean "Assumed not to be a type" |
Examples | Holotype, Isotype, Syntype, Cotype, Epitype, Neotype, Lectotype |
Element specification status | to check |
Notes | none |
Type status is an important trait to digitize for a preserved specimen. Unfortunately, for most specimens either a (possibly true) type status is known, or it is not known at all whether the specimen is a type or not, nor whether this was ever checked. It's one of these properties where a negative value (i.e. not a type) is the most common one and therefore rarely explicitly stated.
MIDS can try to stimulate more explicit labeling of negative typeStatus values, but this will probably block the vast majority of specimens from MIDS level 2, at least initially.
I think this is usually solved by having only a status "known to be a type" (null if unknown or not a type).
explicit null's seem like a better approach, so three values: Known known not a type unknown
There is little practical value in confirming that it is not a type and often difficult to know this as long as not all literature is digitised and searchable, so this is usually not recorded. I do not know of current collection catalogs which would be able to provide the value 'known to be not a type'.
sounds like Known and unknown would be the most commonly used values. But if it is 'known not a type', wouldn't it be a good idea to have a way to record that?
Options:
Not include TypeStatus at MIDS-2, but to bring it into MIDS-3 We can include some discussion in the specification to indicate that it may be included in a future version of the MIDS specification.
Include TypeStatus at MIDS-2 along with the instructions to use Unknown values.
It might be important to note that for ABCD there is the possibility of having multiple TypeStatuses.
I am unsure if we should provide the option to concatenate them (as Collector) or pick one (the first?).
ABCD mapping:
abcd:specimenUnit/nomenclaturalTypeDesignations/nomenclaturalTypeDesignation/0/typeStatus
This is also the one used by GBIF in their mapping
A specimen can be a type specimen or not (boolean isType in GBIF) and if it is a type it can have one or more typestatuses (holotype, neotype, lectotype etc.), that is I think what the ABCD element is for. I would expect in MIDS rather isType (or better: KnownToBeType so you can leave out things like Uncertain as value and treat it as boolean) than TypeStatus.
Hope this helps, Wouter
Op ma 27 feb. 2023 14:50 schreef Sam Leeflang @.***>:
It might be important to note that for ABCD there is the possibility of having multiple TypeStatuses. I am unsure if we should provide the option to concatenate them (as Collector) or pick one (the first?). ABCD mapping:
abcd:specimenUnit/nomenclaturalTypeDesignations/nomenclaturalTypeDesignation/0/typeStatus This is also the one used by GBIF in their mapping https://github.com/gbif/pipelines/blob/f3aafc446e98b939c8290e2795aac3dd5aec890a/sdks/tools/archives-converters/src/main/resources/mapping/indexMapping_abcd_2_0_6.properties
— Reply to this email directly, view it on GitHub https://github.com/tdwg/mids/issues/26#issuecomment-1446356226, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADAUXVJEHUMBDOGRIGSQNDWZSWKNANCNFSM4WKLQHHA . You are receiving this because you commented.Message ID: @.***>
Thanks @wouteraddink
I had an additional comment.
This element doesn't has the Required
field specified.
I would assume that this is required for biological but is it also required for paleo specimen?
For geological specimen I assumed this isn't a required field.
Hi Sam what do you mean with required, required for MIDS2? It seems that there are also types for geological specimens and for paleo specimens.
The form above has a field called required
. Within MIDS2 we make the distinction between three different types of specimen (geological, paleological and biological). Do we want to have TypeStatus
required for all three of these types?
Yes if it is required for biology then is should be required for pal and geo too
I think not all disciplines use type specimens. so for these having a typestatus field does not make much sense, as it will never have a value. For example: plant genetic resource specimens, animal genetic resource specimens, eDNA specimens, perhaps rocks and sediment too (minerals do have type specimens).
typestatus also does not seem relevant for living specimens. One interesting case related to eDNA: it seems that In mycology, new species of fungi have been named based on genetic samples from environmental DNA.
Based on discussed at the meeting on 20 April, the following is proposed
MIDS information element | typeStatus |
Definition | An indication of the nomenclatural type status of the specimen, where a null value is taken to mean "Assumed not to be a type". |
Purpose | The nomenclatural type specimens are some of the most important specimens in a collection, particularly for taxonomic research. They anchor the taxon name to a physical object. |
Mapping | Maps exactly to: dwc:typeStatus |
Applicable standard(s)/recommendation(s) | Recommended best practice is to enter the kind of type, eg Holotype, Isotype, etc. |
Element identifier | |
Required | Yes |
Repeatable | Yes |
Constraints | |
Examples | Holotype, Isotype, Syntype, Cotype, Epitype, Neotype, Lectotype |
Element specification status | under discussion |
Notes | none |
From meeting notes 20 April 2023
Type status: https://github.com/tdwg/mids/issues/26 Suggestion: Type / Not a type is sufficient Question: How important? Recommendation 1: Type / Not a type / Assumed not a type Recommendation 2: Do not include this term (include in section on Data not included but which should be captured) Recommendation 3: Retain, with null value = Assumed not to be a type