-
Notifications
You must be signed in to change notification settings - Fork 70
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 - typifiedName #28
Comments
This proposal needs more evidence for demand (see the Vocabulary Maintenance Specification - Section 3.1). Anybody who is interested in the adoption/change of this term, should comment with their use case below. If demand is not demonstrated by the next annual review of open proposals (late 2020), this proposal will be dismissed. |
Ping @mdoering |
There is certainly a need for this and nomenclatural information like this are certainly under worked. |
How does this addition work when there are multiple typified names for a single specimen? Currently this would be concatenated into dwc:typeStatus, e.g. https://www.gbif.org/occurrence/1839378016 |
I strongly support this and can provide a use case if you need it. @matdillen , having more than one type specimen is, at least in botany, a very rare occurrence and then the specimen is a syntype or paratype (not really types) of one name and the holotype of a more recent name, so you choose the latter name. My experience though is that when you see more than one typified name for a specimen that is almost always an error. @qgroom , many people see nomenclatural type designations as Identifications, so in that sense, |
Just was directed to this thread - I strongly support the need as well!! Being able to do this in ABCD (like this https://www.gbif.org/occurrence/1638363416) but not DwC makes it difficult to effectively cluster collections. If a specimen that is the type of name X but is only listed in GBIF by its current determination Y, clustering by looking for name X would miss that specimen. |
We have semantics in TaxonWorks that would require this one-to many relationship between collection object and taxonomic name: https://rdoc.taxonworks.org/TypeMaterial.html. |
@peterdesmet I note we missed the 2020 review period, but clearly there's interest in moving this conversation forward. I"ve asked @RRabeler to get other colleagues to weigh in too. |
I guess I'm a little confused. Throughout most of DwC information is captured in one place, not multiple places. We're talking about a relationship between a specimen and a scientificName, which already exists within the We have a habit in biodiversity informatics of defining good terms and clustering them into good classes, then not using them broadly (I'm looking at you, So, the issue with a specimen and a name as a type is not an inherent property of either the specimen or the name -- it's a property of an assertion joining the specimen and the name, which is why it's correctly clustered within the Suppose I have a type specimen in my collection, and I expose it via a DwCA datset. One property of that record is materialSampleID, or even occurrenceID, or at least the DwC triplet of ICode+CCode+CatNumber -- so we know what specimen we're talking about. Another property is typeStatus, so we can capture ISOTYPE. And another set of properties are all the The problem, I assume, is that datasets will represent a I do understand that we live in the real world, where people provide content in highly flattened/denormalized form, and this leads to crude efforts to overcome the inherent limitations of doing so (such as adding information about the typified name within the typeStatus property). In this context, I guess it makes sense to add this new term -- but from my perspective, the term would exist only to further enable us to avoid leveraging the capabilities already built into the DwC standard, and perhaps represents a step backwards from fully realizing those existing capabilities within our information exchange systems. |
I agree with @deepreef that the "bits" of data can all be shunted into a format that is sharable as is. I suspect though, that 'typifiedName' represents a need for teasing out semantics? Perhaps our model in TaxonWorks will TaxonDetermination
TypeMaterial
Instances of these data can be fed to DwC as is, I'd have to look at specifics to dig into where we put the bits. |
@deepreef I understand those worries, but DwC (and other standards like ABCD or EML too) has lots of terms only existing to allow flat views. acceptedNameUsage really is the scientificName of the Taxon record linked via acceptedNameUsageID. kingdom, phylum and the other flat ranks are similar convenience terms. The same is true for other location and temporal terms that should sit on an Event or even Location instance. By far the vast majority of DwC use is flat. It's what was (once?) called Simple Darwin Core. No doubt we should be moving to a more relational world, but I think the proposed term makes a lot of sense for the current use of DwC. |
I think the issue is that, currently, the usage of Despite being in the Identification class, the way I do not really want to go into why nomenclatural type designations are not Identifications, as that is not what matters here. What matters is that, if we treat them as Identifications, they are not (necessarily) the same Identification as the current Identification, which we deliver in the Occurrence Core. So we basically want to have two Identifications in the Occurrence Core, the current Identification and the nomenclatural type designation Identification. In order to allow consistent use of (a redefined) |
@mdoering : OK, fair points! I just wanted to make sure I understood. So am I correct that the problem is that people represent type specimens with names that are different from what the specimens typify, and that for whatever reason they're not using the acceptedNameUsage term to capture the current name, and scientificName for the original typified name? (there is no requirement that acceptedNameUsageID must be populated in order to provide a value for acceptedNameUsage). Also, most of "flattened" terms aren't redundant to other terms/structures already in DwC, and/or weren't established with the explicit intention of accommodating flattened representations of the data. But if you feel there is a need for this term as an additional flat-friendly way of capturing information that people are presenting in typeStatus or some other incorrect way, then I wouldn't push back against it. I just wanted to make sure I understood the need. Also... what class would the term belong to? Would it be best to include within @mjy :
If you mean "exact" as in same determiner, same date, same taxon; then I agree. But we allow multiple determiners to assert the same taxon on the same specimen; and also the same determiner to assert the same taxon on the same specimen on different dates (why throw away information). But I agree that same determiner, same specimen, same taxon, same date is redundant.
That's how I used to model it, and that's how a lot of nomenclators model it; but there is enough grey area in this space that I finally had to acknowledge that "specimen is type of taxon" is not as "objective" we all wish it were, and really requires an "accordingTo" reference, just like any other assertion. @nielsklazenga : OK, I didn't realize this was a "thing". We represent (or at least intend to represent) our type specimens using scientificName for the typified name. If we want to represent the "current" interpretation of the name, we use acceptedNameUsage. But I agree if people are mashing additional information (like the typified name) into
That certainly is not what that term was originally intended for. I was unaware that the "Examples" in the DwC reference were updated to what they are now. It used to be for terms like "Holotype", "Paratype", "Lectotype", etc. But now that I see the Examples as given in the quick reference guide, I understand why it's a problem. I must have missed the discussion that updated those Examples, because I would have strongly objected to that. But if that's what people are doing, and that's what the community really thinks is now appropriate for this term, then I agree that adding something like
Technically not Identifications, but that's by far the closest Class in DwC to which type designations belong. They're not properties of specimens ( Anyway, now that I see how the "Examples" for dwc:typeStatus have been updated to say, I understand why this problem exists. And if adding the term typifiedName can solve problems in the near term, I would support it. |
I wonder how common that is. I always assumed scientificName should be the current determination. @timrobertson100 I believe GBIF expects that too. It probably does not make much difference as long as the accepted name and typified name are both under the same taxon in GBIF. |
But this is precisely what we are not doing. Specimen is Type of TaxonName, not Taxon (== OTU) concept. Where does this fail or become a gray area? If it does fail then the code of nomenclature doesn't work AFAIK. |
I do! They are not, and we need special treatment of these facts lest the be confused for something they are not. Object != subjective. |
I had always assumed that every Museum worked this way; but maybe not? Also, despite what I write below, the closest thing there is in our world to an "objective" determination is the one that links a scientificName to a name-bearing type. From that perspective, it seems to me that scientificName most correctly should be represented as the "typifiedName", whenever a name-bearing type is in play (not so much for Paratypes). On the other hand...
Yup... sad but true. Many (most?) names don't even have types (at least not in zoology). The ICZN Code has rules for retroactively designating types, but this is generally only done when there is a specific need to do so. Indeed the Code expressly prohibits designating neotypes unless there is a specific taxonomic ambiguity that needs to be resolved. The typical example is that a series of specimens known to be available to and examined by the author of the name are regarded as a syntype series. In some cases, one of those syntypes is elevated to a lectotype. And in very specific cases, neotypes are designated. Even in modern original description, the author "fixes" the type through a nomenclatural action (this was only explicitly required by the ICZN Code after 2000). So we have all kinds of situations where at one point in time a taxonomist retroactively recognizes a syntype series for an old name. Then later someone elevates one of those specimens to the status of lectotype. Then maybe someone else who is unaware of the lectotype designation picks another one of the syntype series and declares it to be the lectotype. Or, sometimes someone designates a neotype, then an original specimen (holotype or syntype series) is discovered. Thankfully, these situations aren't common -- but they're not so rare that we can just sweep them into the dustbin of "edge case" either. As much as the Code likes to make this stuff as objective as possible, it turns out that a non-trivial number of cases involve some level of subjective interpretation (e.g., "Did the author have access to this specimen prior to establishing the name, in which case it can be considered part of the syntype series?") That's why I had to (reluctantly) abandon my hopes and dreams to treat the relationship between a name and its type as an objective fact, as opposed to an assertion with an accordingTo. The meaning of dwc:typeStatus, to me at least, is not so much a statement "this specimen is the type specimen of that name"; but rather something more like "the label for this specimen includes the word 'Holotype' on it, in association with this name". That's probably the most compelling evidence we have that a particular specimen is, in fact, a type specimen for a name. But I've encountered more than a few cases where the label was wrong. And not just for very old names, either. And, as I said, Identification is not exactly the same thing as type fixation, but it's the closest thing DwC has to it. |
I think you've identified many cases where it's hard (or impossible) to make an assertion of a specific type. This in my mind is not the same thing as saying we shouldn't make certain assertions when they are possible, or treating our assertions specifically to mean one thing. For the record we can stack as many Citations on either class of facts I referenced (and any class of fact) in TaxonWorks, so we can precisely reifiy our data based on your view, but, more importantly, we can enforce the rules if we need to, the same can not be said if strong assertions are not made. Frankly it feels like you've made a strong argument for abandoning nomenclature all together, which in my mind is not necessarily a bad thing ;). |
@deepreef, we seem to be mostly in agreement.
In the past, I have (sort of) proposed the opposite, using
I agree. I think part of the problem is that typification is often confounded with annotations on specimens that the specimen is some kind of type for a scientific name (which putting it in the Identification class encourages). As you have already pointed out above, typification is to names, not taxa (like identifications are); also they are done in publications, not as annotations on specimens. Nomenclatural type designations are facts. That does not mean everybody gets their facts straight or even agrees what the facts are. However, the assertion will be in the annotation and will be in whether the specimen that is being annotated is the same as the specimen cited in the publication, or in the application of the rules of the relevant code. This is entirely different from the assertion that a specimen belongs to a taxonomic group, which is what an identification is. Putting typification-related terms in the Identification class is confounding the vehicle (annotation) with what it transports (identification or typification). I do not think we really need a Nomenclatural Type Designation class in Darwin Core. A DwCA extension would be nice though, as I would have real problems with delivering I also do not think we should abandon nomenclature altogether, although it might be best if some people would attach some less importance to it. Rather, people should stop confuddling taxa and their labels and realise that nomenclature only applies to (a certain type of) the latter. All of this has little bearing on this proposal, as regardless of how you want to treat nomenclatural type designations, we still need to separate the typified name from the type of type. |
This is a bit of an aside, but all this discussion makes me pity the person just trying to publish their specimen data. So much of what has been written here is undocumented. Take for example these terms...
Is there actually any substantive difference in the definition of these terms? All I can see is that you can put invalid/unaccepted names into scientificName and you can put identification qualifiers into acceptedNameUsage. Clearly, that was not the intension, but it is undocumented. Accepted names are only useful when you know who accepted them and in this case there is no link to a publication, so the term is moot, it just means accepted within the context of this dataset.
Apparently originalNameUsage actually has nothing to do with occurrence data at all. How often, and why, would anyone go to the trouble of finding out the basionym of the scientificName for an occurrence, when it might not even be the accepted name? Whereas...
I was struck recently by the clean and clear documentation of Schema.org, with rich descriptions and examples of real life data. If there really is an alternative to typifiedName then it would need to be properly documented within the standard along with examples. Using extensions is always a burden in maintenance and for users. Therefore, it has to be easy to implement or only the minority of people will use it and it becomes redundant. Typification data are some of the worst kept in our domain and I am really keen to see an improvement. |
OK, we seem to be discussing two things:
My sense is that @mdoering raised this issue in the context of # 2; but several of us seem more interested in discussing # 1. For the record, as already stated, I support the proposal by @mdoering for # 2. But I see it as a "band aid" solution to a problem of content misrepresentation resulting from peculiar "Examples" for the DwC term
Yeah, sometimes I feel that way too. But I think there is value in tracking nomenclatural acts as governed by major Codes, and as manifest through TNUs. I also think there is value in tracking treatments of taxonomic concepts/circumscriptions as treatments, also manifest through TNUs. And, I think there is value in tracking organisms, as manifest through both As I've already said, I think it's a mistake to frame the status of a specimen as a nomenclatural "type" as a direct property of either the name, or of the specimen -- the I'd like to explore this more, but I fear we'd be drifting too far from the issue at hand. Perhaps this is worth spawning a new issue? @nielsklazenga :
Agreed! This is why placing typeStatus within the
Well... sort of. Under the nomenclatural Codes, typifications are events/acts that occur within publications (which is why they are best framed as assertions). However, in practice -- and even to some extent in the sense of the Codes -- the specimen label annotation over-rides what appears in publications. I can provide specific examples of this.
Can you explain why you would have problems with this? Included among the Identification History are the instances where the publication that fixed the type also provided an Identification of the type specimen. Those are the Identification instances (i.e., the ones where type fixation occurs) where typeStatus should be populated. Obviously, that's not how the vast majority of DwCA content is created, which is why I support the need for a band-aid @qgroom : I definitely agree with the need for better documentation. I can comment a little on why there was (and, I think, still is) a need for three terms:
The intention of the "Usage" suffix on these and other terms in the
I think this is something we can ALL agree with!!! |
This discussion highlights that |
Just circling back to the definition. Could we make it something like:
? I do not think Darwin Core needs to explain what nomenclatural types are and 'based on' definitely does not cover it. |
@deepreef Couldn't we put your explanations of @mdoering and all, the dwc:Identification class doesn't contain a name that the identification refers to. Indeed, the identification is to a Taxon, rather than a name. The documentation sorts of hints that it refers to For me |
Well... those are the definitions that are in my head now -- not necessarily the definitions that were in my head when I provided those terms to @tucotuco back when they were first added. I'm happy to capture this in whatever form is appropriate to include in online resources, provided others on this thread agree that they make sense. I wouldn't want to mess things up in the same way that the comments for
My understanding is that originally, instances of in the My understanding is that In contrast to @qgroom, I still support the inclusion of both |
Not so much a proposal as a summary of what we discussed earlier:
This is |
I believe that since this term is specifically talking about a name, it is probably going to only be expressed as a |
@baskaufs, yes, that's right. |
Since this proposal is dependent on the change to typeStatus proposed in Issue #328, and that issue was withdrawn from consideration for current public review, I am removing this issue as well. |
I'm not sure this is entirely true, is it? I understand the issue with altering the definition of As per this GBIF issue ABCD has this term, and GBIF already extracts and creates it in a GBIF namespace for downloads and view. It would be better if the publisher could simply declare it and GBIF was using DwC terms for the search (e.g. |
The dependency on typeStatus is based on this comment. |
It would be great to get clarification on whether there is any dependency on issue #328, which remains controversial. In any case, this term can be included in the next Darwin Core public review. |
I am still very much in favour of having this property. In TCS 2, we define a NomenclaturalType class that can also be used as object with I propose to close #328 (which I opened). |
Controversial status eliminated. Recommendation to create Task Group removed. This will be included in the next round of public review. Thanks @nielsklazenga. |
From the TDWG Biodiversity Data Quality Interest Group - we strongly support this proposal. In trying to run our Data Quality Tests (specifically tdwg/bdq#285 and tdwg/bdq#286) we are testing against "Darwin Core typeStatus" {[https://dwc.tdwg.org/list/#dwc_typeStatus]} {dwc:typeStatus vocabulary API [https://gbif.github.io/parsers/apidocs/org/gbif/api/vocabulary/TypeStatus.html]} vocabularies which only have the first part of the dwc:typeStatus data. We are looking at using pipes (|) to test against just the first part of the data in the DwC term, but it makes sense to have separate terms as suggested by @mdoering - i.e. dwc:typeStatus and dwc:typifiedName (or equivalent - something like dwc:typeStatusCitation) I am sure that many databases only use the first part of the DwC term - i.e. the Type of Type - and I can see many cases where this would be valuable in both collection management and database maintenance. Until such a change is implemented by Darwin Core, we will have no option but to attempt to separate the information using pipes for our tests. |
New Term
Submitter: Markus Döring
Justification: Clear separation of the type status and the typified scientific name that is typified by a type specimen, the subject. Looking at how dwc:typeStatus has been used in all of GBIFs specimen data one can see there is the need to express this, but it should better be handled with a term on its own and leave typeStatus for the status of the type only. The term name itself is also used by ABCD: http://wiki.tdwg.org/twiki/bin/view/ABCD/AbcdConcept0603
Organized in Class (e.g., Occurrence, Event, Location, Taxon): Identification
Definition: Scientific name of which Organism is a nomenclatural type.
Comment: It is recommended to also indicate the typeStatus of the Organism.
Refines: None
Replaces: None
ABCD 2.06:
DataSets/DataSet/Units/Unit/SpecimenUnit/NomenclaturalTypeDesignations/NomenclaturalTypeDesignation/TypifiedName
Original comment:
Was https://code.google.com/p/darwincore/issues/detail?id=197
==New Term Recommendation==
Submitter:
Markus Döring
Justification:
Clear separation of the type status and the typified scientific name that is typified by a type specimen, the subject. Looking at how dwc:typeStatus has been used in all of GBIFs specimen data one can see there is the need to express this, but it should better be handled with a term on its own and leave typeStatus for the status of the type only. The term name itself is also used by ABCD: http://wiki.tdwg.org/twiki/bin/view/ABCD/AbcdConcept0603
Definition:
The scientific name that is based on the type specimen.
Comment:
It is recommended to also indicate the typeStatus of the specimen.
Refines:
Has Domain:
Has Range:
Replaces:
ABCD 2.06:
DataSets/DataSet/Units/Unit/SpecimenUnit/NomenclaturalTypeDesignations/NomenclaturalTypeDesignation/TypifiedName
A typical example how typeStatus is used currently is:
ISOTYPE of Polysiphonia amphibolis Womersley
which we could express much better with 2 terms:
dwc:typeStatus=ISOTYPE
dwc:typifiedName=Polysiphonia amphibolis Womersley
The text was updated successfully, but these errors were encountered: