task #6606
closedImport Bogota specimen data
90%
Description
Test dataset available at //BGBM-PESIHPC/Bogota/test-data-edit-20170605.xlsx
Files
Related issues
Updated by Andreas Müller over 7 years ago
- Related to task #6557: Import Bogota data added
Updated by Andreas Müller over 7 years ago
- Related to task #6137: Urgent imports added
Updated by Andreas Müller over 7 years ago
Hallo Grischa, Walter,
vielen Dank für die Daten. Habe sie überflogen. Sieht ziemlich gut aus. Unten Anmerkungen zu den einzelnen Feldern.
An einigen Stellen gibt es Fragen, auch zu der besten Importstrategie. Einige wenige Felder passen so noch nicht sauber ins CDM (nur auf Umwegen). Da müsste jeweils entschieden werden, ob wir die wirklich im CDM brauchen. Immer unter der Voraussetzung, dass wir die Daten ja kein Collection Management System sind sondern die Daten nur mit Taxa zusammenfügen und darstellen.
Collectors:
Hier gibt es auch Institutionen (?) wie MCB, NEYBER LTDA, „Laboratorios Melser“, „Instituto de La Salle“, „Instituto Zooprofiláctico“, „Sociedad de Naturalistas de Nueva Granada“, …
Bisher kannte ich als Sammler nur Personen und Teams. Ist das gängig oder sind das eher dirty data? Handeln können wir es im CDM aber, wenn ich das richtig sehe. Muss nur sehen, wie man die automatisch am besten erkennt, dass es sich nicht um Personen/Teams handelt.
Interesssant finde ich, dass hier außer eher ungewöhnlichen Teams wie „Estudiantes Dendrología II – 1962“, „Estudiantes Botánica G. 1981“ keine wirklichen Teams (Liste von Personen) vorkommen. Absicht?
Was bedeutet Hno. In z.B „Hno. Ariste Joseph“, „Hno. Apollinaire“ oder „Hno. Antonio Camilo”, etc.
Einige Namen haben keine abgekürzten Vornamen. Auch kein Problem (obwohl das das Parsen ein bisschen unschöner macht), v.a. sollte das aber evtl. im Original korrigiert werden?
Collector's No:
Einzige Auffälligkeit: „2624 in part“, gehört das in part da wirklich hin?
Voucher ID
No problems, ist integer Zahl
[Series] Voucher location
8 unterschiedliche Einträge, sieht gut aus. Sind das alles Standardabkürzungen? Könnt ihr noch die Langnamen hinzufügen? Kann auch nachträglich gemacht werden.
Series number: fehlt wie angekündigt
Basis of record: ok, immer Preserved Specimen:
Kind of unit: ok, immer herbarium sheet
Permission: ok, immer “Available”, muss ich noch überlegen, wie ich das ins CDM bekomme.
@Walter: Brauchen wir das überhaupt, oder ist es eigentlich nur eine Info, die nur für die Collection Management Systeme relevant sind?
Könnte ich derzeit als Marker oder Rights importieren. Auch als Facts wäre es möglich
Publish: OK, immer Yes.
Collection Date from and Collection Date to: ok, aber es gibt eine nicht kleine Menge mit s.n.. Ist das akzeptabel? Ist ja Pflichtfeld und keine Angaben wie fehlende Info zu handeln ist.
Collection Notes: immer leer
Family, Genus, Specific Epithet, Rank, Infraspecific, Epithet, Author in parenthesis, Author: sieht ok aus, bisher kein Abgleich mit referenzierten Taxonnamen. Evtl. Abweichungen werde ich mitloggen.
Qualifier: cf., aff. und ?. Können wir im CDM so gut handeln, aber brauchen wir nicht eigentlich auch ein Information darüber, vor welchem epithet der Qualifier stehen soll. Ich frage, weil wir das im CDM auch noch nicht implementiert haben, aber ich das aus dem BGBM Erfassung Excelbogen so kenne. Da es aber wohl nur species gibt ist das in diesem Fall wohl klar.
Platform Name ID = cdmID / Tabelle „Missing cmdID taxa”: Das ist ein kritischer Punkt, über 200 Taxa wurden nicht gefunden. Das betrifft 844 Belege. Da sollten wir unbedingt rausfinden, woran das liegt und wie wir das zeitnah lösen.
Kind of Identification: ok, immer det., auch hierfür fehlt uns noch das Feld im CDM glaube ich.
Identifier: ok, immer Einzelpersonen. Frage: sollen wir versuchen diese Personen z.B. auf die Collectors zu matchen um Duplikate zu vermeiden? Wenn ja, wissen wir sicher, dass es sich immer um die gleichen Personen handelt und nicht um „homonyme“?
Identification date: Format ok, aber 5907 Belege mit “s.n.” obwohl Pflichtfeld. Ok? Wenn ja, soll ich s.n. oder gar kein Datum importieren? Gleiche Frage für Collection Date (s.o.)
Type: Manchmal nur „Type“ ohne genaueren Typ. Ok? Kann man immer davon ausgehen, dass es sich um den Typus zu dem angegebenen Namen handelt? Kann es nicht auch ein Typus eines Synonyms sein? Oder ist das bei diesem Feld ausgeschlossen. Für den Import brauche ich einen klaren Bezug zu einem Taxonnamen sonst kann ich die Typinformation nur bedingt importieren.
Einmal kommt „Topoholotype“ vor (zeile 51). Ist das gewollt. Das kenne ich noch nicht. Wenn ja, bräuchte ich weitere Infos zu diesem Typus Typen.
Identification history: 1200 Einträge, Format scheint ok, einige haben „Anon.“ als Autor. Sollen wir den Identifier in diesem Fall einfach weglassen? Außerdem auch hier die Frage, ob die Personen und auch die Taxon Namen dedupliziert werden sollen. Innerhalb der Identification history und außerhalb mit anderswo gleichlautenden.
Bei den Namen kommt hinzu, dass diese ohne Autor angegeben sind. D.h. das matching würde gg. Namen mit Autoren laufen, bei Homonymen natürlich ein Problem. Wenn wir es nicht machen bekommen wir andererseits ziemlich viele Namensduplikate in die Datenbank.
Country: ok, immer Colombia
State/Province/Greater Area: immer Bogotá D.C.
Locality: schwer zu prüfen, keine leeren Felder, grundsätzlich müssen Fehler dann über die Zeit erkannt werden. Einige Daten fangen mit „sin datos“ an.
Locality ID: Immer vorhanden, im CDM weiß ich allerdings nicht genau, wo ich das abspeichern soll. Locality speichern wir ja nur als Textstring und um NamedAreas daraus zu machen sind es zu viele unterschiedliche. Eine Möglichkeit wäre noch, für Belege mit gleicher Locality ID den gleichen Gathering Event zu verwenden. Das wäre schick, würde aber nur gehen, wenn auch wirklich alle gathering Daten (Datum, lat/long, Höhe, Error distance, …) gleich wären. Für einige Stichproben schien das zu stimmen. Allerdings ist die Frage, ob wir das so machen sollen. Der TaxEditor unterstützt die Bearbeitung von gleichen Gathering Events bislang noch nicht.
Alternativ könnte ich die Locality ID natürlich als Extension speichern; als Alternative Identifier eher nicht, da es sich ja auf die Locality, nicht auf das Specimen bezieht. Gathering Events kann man andererseits bislang keine Alternative Identifier hinzufügen.
Precision qualifier: immer leer
Error distance in m: ok, immer Zahl, manchmal sehr schräg, ob Zahlen wie 108642 wirklich so gemeint sind oder ob es sich da um Fehler in der Einheit handelt?
Longitude/ Latitude: Immer gefüllt, Format ok, Zahlen plausibel
Longitude To/ Latitude To: ok, immer leer
Geocode Method: Wenn vorhanden immer „Wieczorek, J., Guo, Q., & Hijmans, R. (2004). The point-radius … “, ist noch schwierig ins CDM zu bringen. Wir haben nur „Reference System“ wo wir das manchmal reinschmeißen, nicht ganz sauber, eigentlich müsste man zwischen Methode und Referenzsystem differenzieren.
Altitude Value from/to: hin und wieder kommen Dezimalzahlen vor, das sieht das CDM bislang nicht vor. Können wir diese auf Integer reduzieren? Alternativ kann man auch Freitext angeben.
Altitude Unit: ok, immer „m“, nie leer wenn Altitude Value vorliegt
Altitude Method, Habitat aspects, Habitus, Path and File Name, Context, Created Date, Creator, Comment: ok, immer leer.
Viele Grüße,
Andreas M.
Updated by Andreas Müller over 7 years ago
Frage: waren das alle derzeit relevanten Belege oder ist das nur ein Auszug?
Außerdem die Antworten zu den Fragen:
G04: Can we use a GUID like Platform Name ID field [row 16])?
Ja, kein Problem. Umso eindeutiger umso besser
G11/12: Am liebsten wäre mir 2016 für 2016. Wir können jedes Feld im Datum weglassen oder nicht weglassen. Exakt definierte Zeitspannen für fehlende Werte finde ich nicht schön, da das nicht eindeutig ist. Das 2016-00-00 der Kolumbianer ließe sich aber auch relativ leicht parsen. Speichern werden wir es als 2016 oder als 2016-05 wenn nur der Tag fehlt. Ich habe solche Daten auf Anhieb aber gar nicht gefunden, muss ich dazu erwähnen.
G27: ja das funktioniert, siehe meine Kommentare unten.
Updated by Andreas Müller over 7 years ago
AM:
Type: Manchmal nur „Type“ ohne genaueren Typ. Ok? Kann man immer davon ausgehen, dass es sich um den Typus zu dem angegebenen Namen handelt? Kann es nicht auch ein Typus eines Synonyms sein? Oder ist das bei diesem Feld ausgeschlossen. Für den Import brauche ich einen klaren Bezug zu einem Taxonnamen sonst kann ich die Typinformation nur bedingt importieren.
Einmal kommt „Topoholotype“ vor (zeile 51). Ist das gewollt. Das kenne ich noch nicht. Wenn ja, bräuchte ich weitere Infos zu diesem Typus Typen.
Das habe ich mir glaube ich gerade schon selbst beantwortet. Wir beziehen uns ja gar nicht auf akzeptierte Taxa sondern auf Namen, also auch Synonyme. Also gehe ich davon aus, dass der referenzierte Name auch wirklich zu dem Typus gehört.
Da hatte ich falsch gedacht
Updated by Andreas Müller about 7 years ago
- Target version changed from Release 4.8 to Release 4.9
Updated by Andreas Müller about 7 years ago
- Target version changed from Release 4.9 to Release 4.10
Updated by Andreas Müller almost 7 years ago
- Target version changed from Release 4.10 to Release 4.11
Updated by Andreas Müller almost 7 years ago
- Status changed from New to Resolved
- % Done changed from 0 to 90
Updated by Andreas Müller almost 7 years ago
- Target version changed from Release 4.11 to Release 4.12
Updated by Andreas Müller about 4 years ago
- Status changed from Resolved to Closed
- Target version deleted (
Release 4.12)
This can be closed as the Bogota database will not be used anyway. Cleanup import data not necessary anymore.