Advice on locality records

[PipBrewer]

I am looking at transcription for DaSSCo, and for version 1 focussing on localities for pinned insects. I have a few questions which I could do with advice on from the Specify team.

1. I would like advice on mapping a dataset containing localities to Specify. This is an example:

Stednavn	Distrikt	YKoord	XKoord	GI	Genstand	Lat	Long
Aabenraa (Åbenrå)	SJ	6099728	526398	11	10	55.0427005	9.41310486
Aabenraa Fjord (Åbenrå Fjord)	SJ	6099631	532634	6	680	55.0414586	9.51067763

 

2. I would like to know if there is a way to mark certain locality records by their source/quality in Specify. This would allow us to filter by these tags (so not all localities are viewed in the transcription platform or exported)

3. I would also like to know if you are aware of any robust tools that will allow accurate and quick assignment of latitudes and longitudes to locality records in bulk (some kind of tool – perhaps there has been one developed by GBIF)?

4. Would it be possible to implement a system, whereby, if we are unable to transcribe a piece of information (e.g., it is missing from the label and/or indecipherable) with values such as, unknown:missing or unknown:indecipherable (following advice in https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6901386/ and also being considered by MIDS task group).

5. How long would it take to add a verbatim locality field to NHMD pinned insects in test and the above features? I would also like to ask your availability this month regarding these (in test only).

[FedorSteeman]

A few remarks in preparation of the meeting:

1. Most of these fields can be mapped otherwise we can devise custom fields
2. A custom flag field can be made
3. There's GeoLocate which we used for that purpose before. E.g.: #242
4. Adding custom fields can be done very quickly and within less than a day. Going through the localities curating the proper coords may take longer.

[PipBrewer]

Thank you for the meeting today regarding the first version of the transcription platform which will be used to capture localities for Alexey and Aslak’s dung beetle project.

The process was agreed to be as follows, at least for the first iteration:

• We will add localities from Aslak’s curated list to Specify and mark them as part of this project. Pip to chat further with Aslak on how best to map the fields.
• We will create a group of specimens (object records) that need transcribing for this.
• We will regularly export the specimen records that need transcribing and the locality records (perhaps once a day?) to the transcription platform.
• There will be a verbatim field in the transcription platform that will correspond to a new verbatim field in Specify, where digitisers write the locality exactly as it appears on the label.
• There will also be a localities field in the transcription platform. This will not be a drop-down list, but when you start typing, pre-loaded localities can be selected. If the locality is not in there, it will be possible to add one. It will be assumed for this first version/project that the geography will be Denmark (at least until the records have been checked and updated following geolocation). New localities will be imported back into Specify and will be tagged as part of this data set and will also be tagged as needing validation. These will be part of the next days export as well (so digitiser do not need to keep typing the same localities in). There will be a later stage when all localities which are flagged as needing validation will be exported, geolocated (probably using Geolocate), updated and checked before being re-imported back to Specify.
• The issue of almost identical locality records was raised (and the possibility that the wrong Specify locality record could be attached to the new transcribed specimen records) using the API. A way to help mitigate this risk slightly is to tag the locality records for this project in Specify (which will involve adding a new field).
• Joaquim mentioned that it might be useful in a future iteration to have separated geography and locality fields. We will push this issue for now (as need to strike a compromise so digitisation speed is maintained). I’ve had a look at some of the dung beetle labels and there isn’t the geography on there anyway, so digitisers wouldn’t be able to resolve during transcription.
• In the transcription platform, there will be a check box that allows digitisers to mark absence of locality information on a label. There should also be the option to be able to skip records.
• At the end of each day, all validated specimen records will also be re-imported back to Specify using the API.

Pip to add Github tickets to DanSpecify for the following (after consultation with Collection Managers):

• Add verbatim locality field to Collecting Information on Object records for NHMD Entomology, should add source as well e.g., could be verbatim from label, from register etc. Pip to check this with Collection Managers.
• Add new field to locality records in NHMD entomology to add source of locality information. This will help identify the correct locality records for the project.
• Add check box (or drop down) to localities record in NHMD Entomology so can flag when a locality record needs checking/validation.
• Add the “Alias” field to localities records in NHMD Entomology to facilitate name changes and different spellings of localities (with the hope that in future Kansas will enable searching of this field as well).
• There should be a locality record in NHMD Entomology that says “unknown:missing” for when we do not have locality data associated with a specimen and another that says “unknown:indecipherable”. This means that when these values are filled in in Specify, they do not need to be re-exported to the transcription platform.

[FedorSteeman]

Let us know when the tickets are added.