Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New Term - typeOfType #327

Closed
nielsklazenga opened this issue Apr 1, 2021 · 6 comments
Closed

New Term - typeOfType #327

nielsklazenga opened this issue Apr 1, 2021 · 6 comments

Comments

@nielsklazenga
Copy link
Member

New term

  • Submitter: Niels Klazenga
  • Justification: Because of alternative definitions for 'type status', dwc:typeStatus has been used in a mixed way, either as the kind of type and the typified name, or just the kind of type. While the former is how it is defined, the latter usage is far more prevalent. Issue New term - typifiedName #28 identified the need to clearly separate type status (in the sense that is not compliant with the current definition) from the typified scientific name and proposed to add dwc:typifiedName. Discussions around this proposal also revealed the need to disambiguate dwc:typeStatus and create a new property for just the kind of type that can take a vocabulary term.
  • Proponents:

Proposed attributes of the new term:

  • Term name: typeOfType
  • Organized in Class: Identification
  • Definition of the term: The kind of nomenclatural type that a specimen represents
  • Usage comments: Recommended best practice is to use terms from a controlled vocabulary, e.g. the GBIF Nomenlatural Type Status Vocabulary. typeOfType is to be used in combination with a typified name, typifiedName or scientificName.
  • Examples: holotype, isotype, lectotype
  • Refines:
  • Replaces:
  • ABCD 2.06: DataSets/DataSet/Units/Unit/SpecimenUnit/NomenclaturalTypeDesignations/NomenclaturalTypeDesignation/TypeStatus
@nielsklazenga
Copy link
Member Author

@mdoering#28 (comment)

I think I am fine with the proposal to also create typeOfType - or at least some new term for this. I don't think the term typeOfType is very intuitive, I would not know what this is about without reading. Which might be a good thing.

The current typeStatus definition is slightly weird as it is a bit recursive:

A list (concatenated and separated) of nomenclatural types (type status, typified scientific name, publication) applied to the subject.

So dwc:typeStatus is definied to be composed of 3 things, the first being the type status. That to me flags that the status of a type specimen is just the typeOfType and no more. Maybe changing the definitions would not be considered a breaking change in that light? If you search in GBIF for specimens with a type status it is just that, the status: https://www.gbif.org/occurrence/search?type_status=HOLOTYPE

You find this use in many places and literature. I still think the intuitive definition for typeStatus would just be the status, and no scientific name or publication in there.

@nielsklazenga
Copy link
Member Author

@deepreef#28 (comment)

@mdoering :

I still think the intuitive definition for typeStatus would just be the status, and no scientific name or publication in there.

Yes, this has been my point all along. The original definition for typeStatus was to capture what already exists in most specimen databases, which is a single word consistent with what @nielsklazenga proposes for typeOfType. I think it was a mistake to change the definition of this term (as was done in 2007) to include both the typeStatus as originally defined, plus the name that is typified, plus the publication that established the typeStatus. The circularity of the definition (i.e., that a part of the value for typeStatus is "type status") belies how the term was overloaded. I must not have been paying attention in 2007 when the term was redefined to include additional components that we're now referring to as typifiedName and what we might call typificationPublication (or something like that).

If I understand the current proposal, it is to leave the current (post 2007) definition of typeStatus as is, with three included elements (what @nielsklazenga refers to as typeOfType, plus the content of the proposed new term typifiedName, plus the publication information referring to when the type was fixed). Then add an additional term for typeOfType to capture what typeStatus was originally defined for (pre-2007), and also add an additional term for typifiedName to capture the second element of what the current definition of typeStatus is meant to include.

In summary:
pre-2007:
typeStatus = single word (Holotype, Paratype, Lectotype, Isotype, etc.) -- and if I understand you correctly, most GBIF content still represents it this way.

post-2007:
'typeStatus` = "A list (concatenated and separated) of nomenclatural types (type status, typified scientific name, publication) applied to the subject."
This suggests to me that the term "nomenclatural type" consists of three pieces of information ("type status", "typified scientific name", and "publication"), and if a specimen has been designated a type of more than one name, then all three pieces should be included for each type designation, with each set-of-three-pieces (i.e., each "nomenclatural type") concatenated and separated in the form of a list. Or maybe the three pieces are what should be concatenated and separated from each other based on the assumption that there is only one nomenclatural type for each subject -- it's not clear.

Current proposal(s):

  • leave typeStatus as defined in 2007
  • add a new term typeOfType to capture the "type status" (as typeStatus was meant for prior to 2007)
  • add a new term typifiedName to capture the parsed second element of typeStatus ("typified scientific name")
    (optionally) add a new term typificationPublication to capture the parsed third element of typeStatus ("publication")

I've already made it clear that I think the definition of typeStatus should revert to its pre-2007 form (aka, what @nielsklazenga refers to as typeOfType), and if we need the other elements (typified scientific name and/or publication), then new terms should be proposed for those. But I've spent too much on this discussion already, so I'm not going to make this argument formally.

@nielsklazenga
Copy link
Member Author

nielsklazenga commented Apr 1, 2021

As I have said before, I think the current definition of dwc:typeStatus is the better definition of type status. Nevertheless, I agree with @deepreef that the change in definition was unfortunate, because I think you should never change the definition of a property (significantly), but rather create a new one. That's where this proposal comes from. Without the history, my preferred solution would be having typeStatus (in the sense I defined the property proposed here) and typifiedName. typeOfType sounds funky as hell to me too (I did not make it up, it comes from TCS 1), but it has the benefit that it is unambiguous.

Having just been reminded that ABCD uses TypeStatus in the sense of the kind of type, so there is significant history of using the term in this way within TDWG, and agreeing with @mdoering that typeStatus in the sense of its current definition is very little used (@mdoering can judge that way better than I can: I can only extrapolate from what I see in ALA), so we will not inconvenience people or create instability, I think on balance it will be best to indeed consider the current definition of dwc:typeStatus an error that has been very long overlooked and use typeStatus as the name for the proposed property (a.k.a. redefine dwc:typeStatus)..

So, if people agree, I am happy to close this issue and open a new 'Term change' issue (I think that is the best way to do it).

@nielsklazenga
Copy link
Member Author

...or we can just rename this issue and change the label.

@mdoering
Copy link
Contributor

mdoering commented Apr 1, 2021

I would much prefer the later proposal and create a Term change issue for typeStatus

@nielsklazenga
Copy link
Member Author

Thanks Markus, me too, just wanted to make sure what the best procedure was.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants