tdwg
Change term - typifiedName
Change term - typifiedName
- Submitter: Darwin Core Data Package Coordination Team
- Efficacy Justification (why is this term necessary?): see Darwin Core Data Package (DwC-DP) Implementation Experience and Feature Report
- Demand Justification (name at least two organizations that independently need this term): see Darwin Core Data Package (DwC-DP) Implementation Experience and Feature Report
- Stability Justification (what concerns are there that this might affect existing implementations?): None
- Implications for dwciri: namespace (does this change affect a dwciri term version)?: To be determined by DwC-MG
Current Term definition: http://rs.tdwg.org/dwc/terms/version/typifiedName
Proposed attributes of the new term version (Please put actual changes to be implemented in bold and ~strikethrough~):
- Term name (in lowerCamelCase for properties, UpperCamelCase for classes): typifiedName
- Term label (English, not normative): Typified Name
- Organized in Class (e.g., Occurrence, Event, Location, Taxon): MaterialEntity
- Definition of the term (normative): A scientific name for which a specimen or other name is the type. ~A scientific name that is based on a type specimen.~
- Usage comments (recommendations regarding content, etc., not normative): Recommended best practice is also to indicate the dwc:typeStatus of the specimen. ~Recommended best practice is also to indicate the dwc:typeStatus of the specimen.~
- Examples (not normative):
Polysiphonia amphibolis Womersley - Refines (identifier of the broader term this term refines; normative): http://rs.tdwg.org/dwc/terms/version/typifiedName
- Replaces (identifier of the existing term that would be deprecated and replaced by this term; normative):
- ABCD 2.06 (XPATH of the equivalent term in ABCD or EFG; not normative): DataSets/DataSet/Units/Unit/SpecimenUnit/NomenclaturalTypeDesignations/NomenclaturalTypeDesignation/TypifiedName
I am so confused by this term in Material. anyway, isn't it currently in Identification? Are we proposing to move it?
https://dwc.tdwg.org/terms/#dwc:typifiedName
Is this expected to refer to the scientific name for which the referenced material is the "type"? How exactly is this meant to be used?
Can someone with expertise please provide enlightening usage comments? @mdoering @deepreef @nielsklazenga anyone?
I will defer to @nielsklazenga to provide usage comments, as I'm not really clear on why this term is needed.
Having said that, my understanding for the purpose of this term is to allow a direct link from a specimen (Material instance) to dwc:scientificName, indicating a scientific name for which the specimen has been designated as a nomenclatural type.
The main concern I have about this term is that the nomenclatural-type relationship between a particular specimen and a particular name is not necessarily 1:1. From the side of the name, there may be cases with more than one name-bearing type (Syntypes, Isotypes) and non-name-bearing types (Paratypes). From the side of the specimen, there are cases where the same specimen serves (or once served) as name-bearing type for more than one name. This is why the dwc:typeStatus is organized with the Identification Class -- so that it can accommodate the N:M cardinality of the relationship between a physical specimen and its role as a nomenclatural type.
This also fits more closely with the reality (at least in Zoology), that "type status" is not so much an inherent property of a physical specimen, but rather a property of a declaration/assertion about that specimen and an associated scientificName (i.e., names are explicitly "designated" as types, and the designaton context is important).
If this term is to be maintained, then the usage comments should include a description of how to accommodate cases where a single specimen has been designated as a nomenclatural type of more than one scientificName.
I fully agree with all @deepreef said. The pretty rare case of a specimen being the type for several names should be covered, but as it is very rare I am not sure how much that should impact our design. ColDP for example also allows to concatenate typified names (via coldp:nameID) and in the same way and order their type status.
When sharing flattened dwc specimen data dwc:typifiedName comes in handy and always needs to be looked at together with dwc:typeStatus. Concatenating multiple names and status values seems sensible to me for those rare cases.
The proposed definition change though seems weird:
A scientific name for which a specimen or other name is the type.
what is "or other name"? Could we not just say:
The scientific name for which the specimen is the type.
... and in usages mention concatenation and in that case keeping the same order as typeStatus.
Usage comment suggestion:
The full scientific name including the authorship. Recommended best practice is also to indicate the dwc:typeStatus of the specimen. In case of multiple scientific names being typified by the same specimen, multiple names should be concatenated with the pipe symbol, corresponding to the multiple values and order in dwc:typeStatus.
The main utility of typifiedName is in flattened Darwin Core, where it unambiguously holds the name (or names) the specimen is a type for. This is useful to distinguish this name from other names applied to a specimen, such as the latest determination or the filing name.
It's not that useful if there already is an Identification History extension.
Apologies for being unresponsive for so long. I have been away and then got sick.
I do not think a usage comment is necessary, as the typified name is a scientific name, so has the same usage as scientificName. I personally think that only names for new taxa and replacement names—if the replaced name is illegitimate—and that, if a specimen is a type of more than one name, it is a syntype or paratype (which are not really types) of the older name and the holotype of the younger one, so dwc:typfiedName is the younger name, but other people might think differently and such a comment would be more appropriate in an application profile.
It should also be noted that the usage of dwc:typeStatus in @mdoering 's suggested usage comment is not in accordance with its definition, as dwc:typeStatus includes the typified name. Furthermore, in my mind, and according to the proposed definition, there can only be one typifiedName for any dwc:MaterialEntity, as there can only be a single value in dwc:typeStatus if you think it makes sense on a dwc:Identification,
As for @mdillen's comment, dwc:typifiedName is indeed not very useful in the DwC-A Identification History extension, but, from memory, DwC-DP has dwc:typifiedName on the Material Entity (dwc:MaterialEntity) resource.
The proposed dwc:typifiedName is a property of dwc:MaterialEntity and is implemented as a field in the Material schema in DwC-DP. So there could be only one dwc:typifiedName per dwc:MaterialEntity.
@nielsklazenga If a dwc:typifiedName is a dwc:scientificName and if the proposal for a change to the dwc:scientificName definition is successful (to "A scientific name string, not including authorship, date or identification qualifiers.") , wouldn't that make the example provided, "Polysiphonia amphibolis Womersley", incorrect?
@tucotuco
Well, yes, if the definition of dwc:scientificName changes this way, the examples of dwc:typifiedName might need to be changed. Since we are talking strings here, I do not think there needs to be such a strong link between dwc:scientificName and dwc:typifiedName. In dwc:typifiedName, most people (myself included) will want the authorship. There might be a usage comment in there.
I would just remove the 'with authorship and date information if known' from the definition of dwc:scientificName, by the way. While the authorship is not part of the scientific name under the nomenclatural codes (I can only really speak for the Botanical Code), one could see the object of dwc:scientificName as a flattened out ScientificName (or tcs:TaxonName) object, so can include the authorship and any other information that might disambiguate names. So, authorship and year are optional on dwc:scientificName, not forbidden or required. That is in principle, but, if we want to standardise the use of dwc:scientificName, it should only include the name, so I support the proposal in #712.
There is a very big difference between dwc:scientificName and dwc:typifiedName in that dwc:scientificName is for a dwc:Taxon and dwc:typifiedName is just a name. This means that for dwc:scientificName, it is better to supply the authorship and year as dwc:scientificNameAuthorship and dwc:namePublishedInYear, respectively, and one can further disambiguate by supplying dwc:kingdom and dwc:nomenclaturalCode, etc. With dwc:typifiedName we do not have these options, so all necessary information needs to be included in the value of dwc:typifiedName.
I think that after the proposed changes to Darwin Core in spring, there was no resolution on the following issues as there was no consensus:
- Should the typifiedName be included as part of the dwc:typeStatus value, or should both be separate terms: https://github.com/tdwg/dwc/issues/328
- Should dwc:typeStatus (and dwc:typifiedName) be a part of the dwc:Identification or dwc:MaterialEntity class: https://github.com/tdwg/dwc/issues/525
Resolutions to both of these are now proposed as part of the changes for dwc-dp. typeStatus stays in dwc:Identification. typifiedName moves to dwc:MaterialEntity (https://github.com/tdwg/dwc/issues/609). And typeStatus is amended so it should only include the status, not the name: https://github.com/tdwg/dwc/issues/716
My presumption from this is then that, in the Identification table, dwc:scientificName is used to indicate what name the claimed typification is for? There is no need for a separate dwc:typifiedName field because dwc:scientificName can already be used here without any ambiguity. So this specimen, would have two identifications, one for each claimed type status, with values for dwc:typeStatus and dwc:scientificName. Is there a need to model this further in the MaterialEntity table using dwc:typifiedName?
@matdillen As much as I wished this to be true, the #716 proposal still wants
A list (concatenated and separated) of nomenclatural types (type status, typified scientific name, publication) applied to the subject.
It would be so much cleaner and simpler as you have described it.
@matdillen As much as I wished this to be true, the #716 proposal still wants
A list (concatenated and separated) of nomenclatural types (type status, typified scientific name, publication) applied to the subject.
It would be so much cleaner and simpler as you have described it.
That's strange. So the example changed, but the definition did not?
Here is a summary of this and tightly related issues up to now.
In issue #716 it has been discussed that the definition of dwc:typeStatus cannot be changed to include only the type of type. That would be a breaking change. Instead, a term for typeOfType as a string literal should be added to Darwin Core. The IRI version is already covered by tcs:typeOfType (same as DataSets/DataSet/Units/Unit/SpecimenUnit/NomenclaturalTypeDesignations/TypeStatus in ABCD).
In issue #712 it was discussed that the definition of dwc:scientificName cannot be changed to explicitly exclude the author and date information. An alternative will be needed that includes just the name, but consideration of that has been deferred from the current public review.
The release of the DwC-DP accompanying the public review includes dwc:typeStatus in both the Identification and Material tables. For DwC-DP, at least, it doesn't matter what class dwc:typeStatus is a property of, it can function well in both places with appropriate context-sensitive usage notes if necessary. Thus, the controversial issue #525 can probably be resolved with dwc:typeStatus becoming a property of dwc:MaterialEntity.
It seems that typifiedName (this issue #717) is a scientificName and should share the same pattern of construction. As far as DwC-DP is concerned, typifiedName could be dcterms:isVersionOf dwc:scientificName without the need for a new term in Darwin Core. That is the option that would be implemented if a proposal for a new term for typifiedName in Darwin Core isn't successful. The term only makes sense in the Material table in DwC-DP.
If I have summarized all of this correctly, I think we can revisit all definitions, usage comments and examples to make a coherent whole that includes dwc:scientificName (unchanged), dwc:typeStatus (unchanged), dwc:typeOfType (new), and dwc:typifiedName (new). The only changes to DwC-DP would be to add typeOfType to the Identification and Material tables (where its presence in Identification is just a convenience, not a statement of semantics).
Thanks @tucotuco, that is a very good summary.
The only thing that I do not agree with, but which seems to have little effect on the outcome, is that dwc:typifiedName dcterms:isVersionOf dwc:scientificName. The object of dwc:typifiedName is a scientific name, but that does not mean that it is a version of dwc:scientificName. That would make dwc:acceptedNameUsage, dwc:parentNameUsage and dwc:originalNameUsage versions of dwc:scientificName as well.
@nielsklazenga That's great. So a new term for typifiedName isn't a problem? What would you recommend for the definition, usage comments and examples?
@tucotuco , dwc:typifiedName is not a new term. The definition proposed in this issue is fine. Give me a day or so to come up with a usage note. This will involve dwc:typeStatus and dwc:typeOfType (#783, thanks for that) as well, as these three terms go hand-in-hand.
The only thing that I do not agree with, but which seems to have little effect on the outcome, is that dwc:typifiedName dcterms:isVersionOf dwc:scientificName. The object of dwc:typifiedName is a scientific name, but that does not mean that it is a version of dwc:scientificName. That would make dwc:acceptedNameUsage, dwc:parentNameUsage and dwc:originalNameUsage versions of dwc:scientificName as well.
This is not quite right. The relationship between a specimen designated as the type of a scientific name is consistent with the expression: dwc:typifiedName dcterms:isVersionOf dwc:scientificName, because both dwc:typifiedName and dwc:scientificName are examples of the same class of thing (a scientific name).
It does NOT follow that dwc:acceptedNameUsage, dwc:parentNameUsage and dwc:originalNameUsage can be represented as "versions" of dwc:scientificName, because these three terms are examples of a different class of thing (a taxon[omic] name usage).
@deepreef, you are confuddling classes and properties. dwc:typifiedName and dwc:acceptedNameUsage (etc.) are properties of different classes, but not instances (or examples) of any class. dwc:scientificName is a property of the same class as dwc:acceptedNameUsage etc.
The release of the DwC-DP accompanying the public review includes dwc:typeStatus in both the Identification and Material tables. For DwC-DP, at least, it doesn't matter what class dwc:typeStatus is a property of, it can function well in both places with appropriate context-sensitive usage notes if necessary. Thus, the controversial issue https://github.com/tdwg/dwc/issues/525 can probably be resolved with dwc:typeStatus becoming a property of dwc:MaterialEntity.
If, by the last sentence int he quoted text above, you mean that "dwc:typeStatus becoming a property of dwc:MaterialEntity", you actually mean "dwc:typeStatus ALSO becoming a property of dwc:MaterialEntity" (in addition to remaining a property of dwc:Identification, then I guess that's probably OK -- but I would recommend that the term connected to dwc:MaterialEntity be something like dwc:designatedTypeStatus.
On the other hand, if the last sentence of the quoted text above is meant to be "dwc:typeStatus becoming a property of dwc:MaterialEntity INSTEAD OF a property of dwc:Identification", then I would push back pretty hard on this.
A specimen is not intrinsically "a name-bearing type" of a scientific name; rather it is designated as a name-bearing type of a scientific name. This is why I would suggest that the property of dwc:MaterialEntity be named someting like dwc:designatedTypeStatus. If the goal is to "simplify" how specimens can be indicated as having been designated as name-bearing types of some name, then such a term could be helpful to represent this fact. But the meaningful aspects of how a name is typified by a specimen (and vice-versa) are really properties of dwc:Identification instances.
A specimen is not intrinsically "a name-bearing type" of a scientific name; rather it is designated as a name-bearing type of a scientific name.
That is correct, but misses the point. The point is that "a name-bearing type" of a scientific name is a specimen. That is why the subject of typeStatus is a dwc:MaterialEntity and not a dwc:Identification. dwc:designatedTypeStatus indeed better covers the meaning of the term (ABCD has NomenclaturalTypeStatusDesignation (from memory)), but we are not talking about a label, but an identifier, so we cannot change this.
@deepreef, you are confuddling classes and properties.
dwc:typifiedNameanddwc:acceptedNameUsage(etc.) are properties of different classes, but not instances (or examples) of any class.dwc:scientificNameis a property of the same class asdwc:acceptedNameUsageetc.
Perhaps I didn't express myself well (lower-case 'class' not intended as the same thing as upper-case 'Class'). My point is, the values provided for the property dwc:typifiedName are intended to refer to nomenclatural entities (a scientific name). Maybe I'm misunderstanding what is meant by dcterms:isVersionOf, but the point I'm trying to make is that the values provided for dwc:typifiedName and dwc:scientificName are fundamentally congruent in their meaning. By contrast, each of the dwc:[...]Usage terms are for properties that are fundamentally different (incongruent) things from dwc:typifiedName and dwc:scientificName.
Part of the problem (and why it's hard to have clear discussions about these things) is that the Class (upper-case) dwc:Taxon is very broad, and encompasses all sorts of different kinfs of things. This Class encompasses instances meant to represent scientific names, and also instances meant to prepresent taxonomic concepts, and also instances meant to represent taxon[omic] name usages. Each of these have different properties, so it creates a lot of barriers to communication when trying to explain these subtle but important differences.
@deepreef , yes, I think you are misinterpreting dcterms:isVersionOf. For a term to be a dcterms:isVersionOf of another term it needs to be the same concept, so have the same, or at least a congruent, definition, not the same type of object. So, if the current proposal would be ratified today dwc:typifiedName-2025-12-16 would be a dcterms:isVersionOf dwc:typifiedName-2025-06-12.
The abusage of the dwc:Taxon class for other things than taxon concepts is indeed a problem, but is also not in accordance with its definition, so it does not have to be this way. Now that TCS 2 has been ratified, we do not need the dwc:Taxon class for exchange of taxonomic data anymore, so people can stop doing that and we can stick to the definition. For exchange of occurrence data, we still need the dwc:Taxon class, as most of the taxon concepts exchanged with occurrence data are nominal concepts and are best not expressed as tcs:TaxonConcept. The Darwin Core RDF Guide resolved this well by making all properties of the dwc:Taxon class that it adopted convenience properties of dwc:Identification. Darwin Core has always had the tcs:taxonConceptID property to reference tcs:TaxonConcepts. It should be our goal to have as many as possible dwc:Identifications reference tcs:TaxonConcepts, either directly through the dwciri.toTaxon property, or indirectly through the dwc:Taxon (so, dwc:taxonID property) and the tcs:taxonConceptID property. By keeping both dwc:Taxon and tcs:TaxonConcept classes, we can slowly work towards this goal without getting in the way of exchange of occurrence data.
@tucotuco, as requested:
Proposed comment for dwc:typifiedName
dwc:typifiedNameis best used in combination withdwc:typeOfType. Together they make up the type status of a specimen. Note that relatively very few specimens are nomenclatural types (types of names), so in most cases this term will have no value. Unlikedwc:typeStatus,dwc:typifiedNamecan only have a single value, so in Darwin Core Archives and Darwin Core Data Packages, adwc:Occurrenceordwc:MaterialEntity, respectively, can only have a singledwc:typifiedName.
Proposed comment for dwc:typeOfType
dwc:typeOfTypemust be used in combination withdwc:typifiedName. Together they make up the type status of a specimen. Note that relatively very few specimens are nomenclatural types (types of names), so in most cases this term will have no value. Unlikedwc:typeStatus,dwc:typeOfTypecan only have a single value, so in Darwin Core Archives and Darwin Core Data Packages, adwc:Occurrenceordwc:MaterialEntity, respectively, can only have a singledwc:typeOfType.