Wir könnten dies natürlich in einer anderen Reihenfolge tun.
Da iDigBio Sammlungen beschreibt, sollten wir wahrscheinlich:
Sobald wir eine Liste mit Übereinstimmungen haben, könnten wir den GrSciColl-Einträgen Kennungen hinzufügen, um am Import zu arbeiten (ähnlich wie wir es im Fall von IH tun).
Jeder hat wahrscheinlich eine Idee, wie es weitergehen soll, aber um zu verfolgen, was passiert, schreibe ich hier die Schritte des Matching-Prozesses:
Wer macht jetzt was?
Die Modelle zwischen iDigBio und GrSciColl scheinen ziemlich ähnlich zu sein. So schlagen wir vor, die Felder zuzuordnen. Könnten Sie das durchgehen und uns mitteilen, wenn Sie einen Kommentar haben?
iDiBio | GrSciColl
-- | --
Institution | Zugeordnet zu „Institution“ in der Sammlungsentität und „Name“, falls verwendet, um eine Institution zu erstellen
Sammlung | Name in Coll
Datensätze | Als MachineTag gesetzt (da es für den internen Gebrauch ist) in coll
RecordsetQuery | MachineTag in coll
Institutionscode | Dem "Code" in der Institution zugeordnet
Sammlungscode | In der Sammlung „Code“ zugeordnet
Sammlungs-UUID | Als Kennung hinzugefügt
Sammlung Lsid | Als Kennung hinzugefügt
Sammlungs-URL | Homepage in Coll
Sammlungskatalog-URL | Katalog-URL in Coll
Beschreibung | Beschreibung in Coll
BeschreibungFürSpezialisten | Verkettet mit Beschreibung in Coll (oder neues Feld?)
Katalogisierte Exemplare | Anzahl der Exemplare in Coll
KnownToContainTypes | Verwerfen? (das Feld wird weniger als 100 Mal verwendet) Ist es für den internen Gebrauch notwendig? In diesem Fall können wir es als machineTag hinzufügen.
TaxonCoverage | Taxonomische Abdeckung in Coll
Geografische Reichweite | Geografische Abdeckung in Coll
CollectionExtent | Verwerfen? (Es scheint, als ob es in den meisten Fällen eine Zeichenfolge mit demselben Wert wie cataloguedSpecimens enthält.)
Kontakt | Dem Personalnamen zugeordnet
Kontakt Rolle | Der Stabsstelle zugeordnet
Kontakt E-Mail | Mitarbeiter-E-Mail zugeordnet
Postanschrift | Postanschrift in Coll
Mailing-Stadt | Poststadt in Coll
Versandstaat | Versandstaat in Coll
Mailing-Zip | Postleitzahl in Coll
Physische Adresse | Physische Adresse in Coll
Physische Stadt | Physische Stadt in Coll
Physikalischer Zustand | Physikalischer Zustand in Coll
Physischer Reißverschluss | Physische Postleitzahl in Coll
EindeutigerNameUUID | Als Bezeichner in inst hinzugefügt
NamensnennungLogoURL | Neues Feld?
ProviderManagedID | Als Kennung hinzugefügt
AbgeleitetVon | Als MachineTag hinzugefügt, wenn es für den internen Gebrauch bestimmt ist?
SameAs | Als Kennung hinzugefügt
Flaggen | Als MachineTag hinzugefügt
PortalAnzeige | Als MachineTag hinzugefügt
Breite | Breitengrad in der Institution
Lon | Längengrad in Institution
Wie bereits erwähnt, arbeiten wir daran, Index Herbariorum und GrSciColl (https://github.com/gbif/registry/issues/167) zu synchronisieren. Es gibt eine teilweise Überschneidung zwischen iDigBio und IH.
Was sollen wir in diesen Fällen tun?
Ich schlage vor, die Informationen für die von IH bereitgestellten Felder zu überschreiben (IH-Wert überschreibt iDigBio- oder GrSciColl-Wert) und nur die Felder zu behalten, die von iDigBio stammen.
Wenn der iDigBio-Eintrag der aktuellste ist, würden wir ein GitHub-Problem erstellen und dann das neueste Update an IH senden.
Wäre das in Ordnung?
zu Teil 1:
Was die Person betrifft, die die Arbeit ausführt, denke ich respektvoll, dass es am besten und zweckmäßigsten wäre, wenn GBIF die Zeit dafür aufwenden könnte. iDigBio/ACIS IT fehlt immer noch 1 Teammitglied, und trotz unseres Gefühls, dass das resultierende Produkt für alle viel besser funktionieren wird, glaube ich nicht, dass wir garantieren können, dass wir uns in absehbarer Zeit dazu verpflichten können.
Hier sind einige weitere Anmerkungen zu Abschnitt 1 dieser Ausgabe:
Für den Abgleich ist es möglicherweise möglich, den Institutionscode von GBIF mit dem Institutionscode von collections.json abzugleichen
Basierend auf der vorhandenen Dokumentation von collections.json (in der Readme-Datei des Repositorys) wird institution_lsid
einer „GRBio-LSID oder einer coolURI für die Institutions-LSID“ zugeordnet, falls sie gefunden wird, andernfalls ist sie leer
andere Übereinstimmungen müssen wahrscheinlich Zeichenfolgen-basierte Übereinstimmungsalgorithmen sein. Ein potenziell hilfreicher Hinweis für Abgleichs-/Verifizierungszwecke ist, dass die Recordset-UUID in collections.json mit der Recordset-UUID übereinstimmt, die von unserer API bereitgestellt wird.
Teil 2:
Die einzelnen Datensätze in der collections.json von iDigBio sind Institution-Collection-Datensätze. GBIF unterteilt Institution und Sammlung ordnungsgemäß in separate Einheiten. Siehe beigefügtes Diagramm für beabsichtigte Hierarchie.
Hinweis: Es gibt Felddefinitionen in der Readme von: https://github.com/iDigBio/idb-us-collections
Anmerkungen zu einzelnen Mappings:
„UniqueNameUUID Added as identifier“ – dies scheint als „Institution“-UUID in einer Hierarchie von iDigBio-Einträgen gedacht zu sein, scheint aber nicht implementiert worden zu sein. Als Kennung im GBIF-System behalten.
recordsetQuery: Dies generiert einen Link zum iDigBio-Recordset (dh https://www.idigbio.org/portal/recordsets/ea12da76-1b2e-4944-8709-1de3af1c65e2). Dieses Feld kann verworfen werden, wenn Sie Links zum Recordset auf andere Weise generieren.
Datensätze – Zur Erinnerung: Dies ist unser übergeordnetes Objekt für einzelne Datensätze in unserem System
KnownToContainTypes: Dies scheint in Ordnung zu verwerfen.
Collectionextent: kann in CatalogedSpecimens kopiert werden, wo CatalogedSpecimens leer ist, aber nicht als separates Feld aufbewahrt werden muss (verwerfen).
„AttributionsLogoURL, AnbieterManagedID, AbgeleitetVon“ – Beachten Sie, dass dies Audubon Core-Begriffe sind
Zu Teil 3:
Wir sind mit der vorgeschlagenen Methode zur Integration von IH- und iDigBio-Daten einverstanden. Um festzustellen, wer der neueste Datensatz ist, IH oder iDigBio, können Sie das Commit-Datum für eine einzelne Datei im iDigBio-Repo als hinzugefügtes/geändertes Datum verwenden.
Das Repository funktioniert so, dass ein Mensch einen JSON-Block mit dem Namen ./collections/{collection_uuid}.json erstellt/aktualisiert und festschreibt. Der Software-Workflow führt dann Tests aus und aggregiert diesen JSON-Block in die vollständige collections.json. Ein Beispiel für eine einzelne JSON-Datei wäre:
Wichtiger Hinweis : Die collections.json
-Datei, die tatsächlich geladen und verwendet wird, wird vom json-index
- oder gh-pages
-Zweig bereitgestellt (sie wird an beide gepusht) und nicht vom Master-Zweig. Zum Beispiel:
https://raw.githubusercontent.com/iDigBio/idb-us-collections/json-index/collections.json
oder
http://idigbio.github.io/idb-us-collections/collections.json
Ich hoffe, dass all dies hilft. Bitte zögern Sie nicht, @ uns für weitere Fragen oder Erläuterungen zu kontaktieren.
@roncanepa @nrejack Ich habe die Zuordnungen überprüft und es sieht so aus, als ob AttributionLogoURL
das einzige iDigBio-Feld ist, das uns in unserer Registrierung fehlt. Aber ich habe die Datei collections.json
überprüft und festgestellt, dass dieses Feld immer leer ist. Sollten wir es trotzdem zu unserer Registrierung hinzufügen? oder können wir es auch verwerfen?
@asturcon Wir haben dieses Feld von Audubon Core übernommen, aber wir waren uns einig, dass Sie das Feld verwerfen können, da wir nichts damit machen.
Vielen Dank für eure Antworten @roncanepa und @nrejack !
In diesem Fall beginnen wir mit [ 1. Verknüpfung von iDigBio- und GrSciColl-Einträgen ]. Wir werden so viel wie möglich automatisch erledigen und dir und Cat einige Dinge schicken, die möglicherweise manuell überprüft werden müssen. Ist das für dich in Ordnung?
Gut mit mir, schick weg! Vielen Dank an alle!!
Hallo @CatChapman , Morten hat daran gearbeitet, iDigBio- und GrSciColl-Einträge abzugleichen: https://github.com/gbif/registry/issues/187
Es stellt sich heraus, dass es sinnvoller ist, zuerst alles GrSCiColl-Institutionen zuzuordnen, da wir für diese Einträge viel mehr Details und Identifikatoren haben. Sobald wir die Übereinstimmungen für die Institution hatten, konnten wir uns die Sammlungen ansehen und diese ebenfalls abgleichen.
Morten beschrieb seinen gesamten Matching-Prozess und die Ergebnisse zu dem oben verlinkten Thema, aber hier sind die Highlights:
Damit bleiben 235 iDigBio-Einträge ohne Übereinstimmung, für die wir neue Einträge in GrSciColl erstellen würden.
Jetzt brauchen wir Ihre Hilfe, um die Übereinstimmung zu überprüfen! Könnten Sie über https://github.com/gbif/registry/issues/187 gehen und sich das passende Ergebnis ansehen? (Wenn es bequemer ist, können wir Ihnen auch eine Tabelle zur Verfügung stellen).
Beachten Sie, dass wir am Anfang möglicherweise einige doppelte Sammlungen haben, da einige Sammlungstitel in GrSciColl etwas vage sein können und wir nicht immer zuverlässige Codes haben. Keine Sorge, wir gehen davon aus, dass wir sie etwas später ausbügeln werden.
Morten hat hier auch dokumentiert, wie wir die Zusammenführung selbst voraussichtlich durchführen: https://github.com/gbif/registry/issues/188
@ManonGros WOW! Das ist toll. Ihr rockt so sehr.
Eine Tabelle wäre fantastisch - ich habe Ihnen gerade eine E-Mail gesendet, also können Sie sie gerne dorthin senden oder hier darauf verlinken (wenn es sich um eine Google-Tabelle usw. handelt).
Werde jetzt einen Blick auf #188 werfen.
Toll! Ich füge die tabulatorgetrennte CSV-Datei für den Abgleich hinzu:
iDigBio_GrSciColl_matches_march2020.tsv.zip
Es wäre großartig, Ihren Scheck in einem maschinenlesbaren Format zurückzubekommen. Wir empfehlen, dieser Datei eine Spalte mit wahr/falsch für jede Übereinstimmung hinzuzufügen, zusammen mit einer potenziellen „Korrektur“-Spalte mit der entsprechenden Übereinstimmung, die Sie für wahr halten.
Mortens JSON-Datei aktualisiert mit Eingaben von CAT:
iDigBio_Morten_matches_AND_Cat_addition.json.zip
Hilfreichster Kommentar
@asturcon Wir haben dieses Feld von Audubon Core übernommen, aber wir waren uns einig, dass Sie das Feld verwerfen können, da wir nichts damit machen.