typeStatusQualifier

[nielsklazenga]

typeStatusQualifier is the new term we have minted for the ABCD //Unit/SpecimenUnit/NomenclaturalTypeDesignations/NomenclaturalTypeDesignation[0]/DoubtfulFlag element (tql was the old HISPID transfer code). Currently, there is a vocabulary on the field, which has the values '?', 'possible' and 'probable'.

I propose to drop the term and add a single value '?type' (or something like that) to the typeStatus vocabulary. This has the advantage that the information can be delivered in "pure" Darwin Core and can be delivered with the IPT. More importantly, it indicates immediately that the uncertainty is about whether the specimen is a type of a name, rather than what type of type. Losing the 'possible/probable' distinction doesn't seem a great loss.

When delivering data in ABCD, the term can be parsed into DoubtfulFlag and TypeStatusName, so that the value in the TypeStatusName field still adheres to the ABCD vocabulary.

[ben3000]

I wonder what any system could usefully do with the possible vs probable distinction :) I can't think of an application for it other than perhaps placing a slightly different background colour or icon on the typeStatus element when it is displayed in a UI. Not crucial, I'd say. Far better to provide a boolean that indicates whether there is any likelihood at all that the herbarium is unsure of the typeStatus.

I'm not yet convinced that we should mix a qualifier into typeStatus, but I can definitely see that it would force users of our data to deal with the qualification (as they might neglect to check for data in the typeStatusQualifier before counting the number of type specimens received, for example). Gee, I might have just convinced myself.

As an example, with the two term approach, typeStatusQualifier would contain ? and typeStatus would contain type, but with the proposed single term approach, typeStatus would contain ?type or perhaps type?.

[AaronWilton]

Hobart 2015-10-23: agreed