populate wikidata entry for Myotis nimbaensis Simmons & Flanders & Fils & Parker & Jamison D. Suter & Bamba & Douno & Mamady Kobele Keita & Morales & Frick 2021, new species urn:catalog:AMNH:Mammals:M-279589

[jhpoelen]

as asked by @Daniel-Mietchen , Nancy Simmons, Donat Agosti @myrmoteras , Deb Paul @debpaul and others helped to collect a neat example of a (holo) type specimen to serve as an example of populating links to specimen records, key images to taxonomic names and their associated literature

The following example was suggested:

Myotis nimbaensis Simmons & Flanders & Fils & Parker & Jamison D. Suter & Bamba & Douno & Mamady Kobele Keita & Morales & Frick 2021, new species

with urn:catalog:AMNH:Mammals:M-279589 AMNH 279589

https://digitallibrary.amnh.org/bitstream/handle/2246/7249/N3963.pdf?sequence=1&isAllowed=y

@daniel-mietchen - I hope to work with you to create a rich wikidata entry and then review it with experts like Nancy Simmons (who helped name Myotis nimbaensis) to ensure basic (literature | specimen | image ) links are in place.

[jhpoelen]

More information -

@Nancy Simmons if you can provide us a PID for the specimen at the AMNH then we can add it and it will also show up in GBIF https://www.gbif.org/occurrence/3015275304 as the reference . Unfortunately it is not in Wikidata because of an unresolved dispute that prevents add these sort of data via bot https://www.wikidata.org/wiki/Wikidata:Property_proposal/taxonomic_treatment

[Daniel-Mietchen]

Thanks for the suggestion. I looked into the corresponding Wikidata entry at https://www.wikidata.org/wiki/Q104957922 , which has some basic information. It also links to three Wikipedia articles and a Wikispecies entry, none of which have images.

So I checked the paper's metadata, which does not give any hint about licensing. Next, I looked into the PDF, which has a classical copyright statements and no mention of open licensing, while the Plazi copy of the figures (example) are tagged as being available under CC BY 4.0.

I also checked Zoobank for this taxon name, with zero results.

So I'll stop here for now and let others chime in.

[myrmoteras]

copied from the slack, here is all we can offer. JSON, HTML

All the images are accessible via the Article Zenodo deposit

All the treatments can be cited or accessed using the Zenodo DOI 10.5281/zenodo.4438061 (= Document Zenodo Deposition ID in the above table) or TreatmentBank stable httpUri.

[jhpoelen]

from AMNH (American Museum of Natural History) data manager 2022-02-15

---

@Donat Agosti @Jorrit Poelen (GloBI) @Deborah Paul Deb was correct about the numbers. This from our data manager at AMNH: "Hi Nancy, It seems to me there are two ways you could proceed. Option 1: Some collections assign a randomized, automatically generated GUID to each of their specimen records. We don't have the capability to automatically generate such GUIDs in our current version of EMu, but we will have that ability in the near future, once VZ upgrades to the latest version of EMu. At that point, it will be easy to generate and store GUIDs such as the following example: e83f4dc9-e7f4-4aa8-b056-d703c4e102c1 So, if you wanted to use GUIDs like the above for these two specimens, we could generate two such numbers now, store them temporarily in a note field in their corresponding EMu database records, and then once we upgrade EMu, we could transfer those values to the dedicated GUID fields in the newer version of EMu. Option 2: Because we don't currently generate GUIDs, and because portals such as VertNet request that we provide some kind of unique specimen ID with each record we provide to them, we have instead been generating more conventional but still globally unique numbers for our specimens. For example, the mammal specimen in your collection with catalog number M-100000 is represented by the following unique ID: urn:catalog:AMNH:Mammals:M-100000 (where "urn" stands for Uniform Resource Name.) This string uniquely identifies the AMNH mammal specimen with this catalog number, and so serves the purpose of a globally unique identifier. This exact string is used to represent this mammal specimen on VertNet, GBIF, and iDigBio, as you can see here: http://portal.vertnet.org/o/amnh/mammals?id=urn-catalog-amnh-mammals-m-100000 https://www.gbif.org/occurrence/859338650 https://www.idigbio.org/portal/records/0593e3e4-c577-4964-953d-3b967817079c You can see that all three pages include a term called "OccurrenceID" (or "Occurrence ID") whose value is "urn:catalog:AMNH:Mammals:M-100000". So, if you want to follow this existing format, you could use these two values as Persistent Identifiers for your two type specimens: urn:catalog:AMNH:Mammals:M-279589 urn:catalog:AMNH:Mammals:M-279590 I tend to think that, at this point in time, the second approach makes the most sense, since it's consistent with what we're already doing, and since we have not yet started generating or providing randomized GUIDs for our specimen records. Of course, you may have a different opinion."

[debpaul]

@jhpoelen et al, please note in the above response, the implications (some programmatic, some representing our current evolving standards-of-practice).

• [ ] There will be (in-future) GUIDs for AMNH objects/records.
• [ ] The current published occurrenceIds of type urn:catalog:AMNH:Mammals: remain relevant in the future, since they are already cited in literature
• [ ] Best practice in future (once the GUIDs are minted) would be for the data provider (e.g. AMNH) to use (for now) the DwC Resource Relationship extension to share all Identifers known for an object. Relationship specified between the identifiers might be "formerly known as", "also known as", etc. And using a formal relationship identifier (as in from an ontology) instead of a string like "formerly known as" would be better/best practice.
• [ ] This would (hopefully) mean that at wikidata, all these identifiers would be listed.
• [ ] Do these identifiers represent or point to the database record or physical object? Does is matter if we agree on this or not? (e.g. for how we want to reference them, use them programatically). I think understanding of this, and implications, are still evolving. For me, for a concrete example, the dwc:catalogNumber is the local (and usually not GUID) identifier helping those managing the physical objects or using the physical objects to find and curate those objects. While, the non-human-interpretable GUIDS (like UUIDs) inherently represent the digital record b/c one needs to use that GUID to "look up" the local identifier.
• [ ] Additionally, there is the fact that when aggregators ingest these records, they assign GUIDs to each record as well. There is an issue inherent in trying to understand if the record associated with a given GUID has changed (a la, the need for a SHA to go with a GUID and the date modified, etc).
• [ ] And, for those downloading from aggregators, knowing what / whom it cite is not trivial. Why? Because we are still trying to figure out how to cite the aggregator, and the records in the dataset. AFAIK, the collections still don't get any sort of formal notification when their data is being cited.