Registry: Implementieren Sie einen Suchdienst für GrSciColl-Sammlungen

Ich habe in DEV eine erste Version des Suchdienstes für Sammlungen eingefügt (der die Maschinen-Tags immer noch nicht verwendet), um zu sehen, ob dies das ist, was wir erwartet haben.

Es gibt eine Liste mit Institutionsübereinstimmungen und eine weitere mit Sammlungsübereinstimmungen zurück. Es handelt sich um eine Liste, da Codes nicht eindeutig sind, sodass es Fälle geben kann, in denen wir mehrere Optionen haben können und wir nicht nach einem anderen Feld unterscheiden können.

Für jedes Spiel zeigt es:

• Typ: Es kann exact oder fuzzy sein. exact ist nur, wenn sowohl der Code als auch die Kennung übereinstimmen. Andernfalls sind es fuzzy .
• Anmerkungen: Dies sind Beobachtungen, um zu verstehen, wie das Spiel durchgeführt wurde. Die möglichen Werte sind:
  
  
  
  • CODE_MATCH : es ignoriert den Fall nicht
  
  
  • IDENTIFIER_MATCH : es ignoriert den Fall nicht
  
  
  • ALTERNATIVE_CODE_MATCH : es ignoriert den Fall nicht
  
  
  • NAME_MATCH : Es ignoriert die Groß-/Kleinschreibung und entfernt Akzente und Leerzeichen, führt jedoch keine Präfix- oder Suffixübereinstimmungen durch
  
  
  • PROBABLY_ON_LOAN : Dies passiert, wenn die Eigentümerinstitution und die Institution nicht identisch sind
  
  
  • INST_COLL_MISMATCH : Dies geschieht, wenn die Institution einer Sammlung nicht in den übereinstimmenden Institutionen vorhanden ist.
  
  

Wenn es Institutionsübereinstimmungen gibt, stimmt eine Sammlung nur dann ungenau überein, wenn sie zu einer der übereinstimmenden Institutionen gehört. Exakte Sammlungsübereinstimmungen werden immer zurückgegeben.

Sie können diese Beispiele überprüfen, um zu sehen, wie der Dienst funktioniert:

• http://api.gbif-dev.org/v1/grscicoll/lookup?collectionCode=herbarium gibt 567 Sammlungen zurück
• http://api.gbif-dev.org/v1/grscicoll/lookup?collectionCode=herbarium&institutionCode=UNCA gibt 1 Institution und 1 Sammlung zurück
• http://api.gbif-dev.org/v1/grscicoll/lookup?collectionCode=UNCA&institutionCode=UNCA&institutionId=gbif :ih: irn:240135 gibt 1 Institution und 2 Sammlungen zurück
• http://api.gbif-dev.org/v1/grscicoll/lookup?collectionCode=UIMNH&collectionId=http://grbio.org/cool/zrdp-fspx&institutionCode=K ist ein Beispiel für INST_COLL_MISMATCH
• http://api.gbif-dev.org/v1/grscicoll/lookup?ownerInstitutionCode=MBMC&institutionCode=K ist ein Beispiel für PROBABLY_ON_LOAN

Übersehe ich etwas @MortenHofft @timrobertson100 ?

Ich habe die Maschinen-Tag-Prüfung nach dem Format hinzugefügt, das vorerst bereits in Pipelines verwendet wurde:

• Namensraum: processing.gbif.org
• Namen:
  
  
  
  • institutionCode : ordnet einen Institutionscode einer GrSciColl-Institution zu
  
  
  • collectionCode : ordnet einen Sammlungscode einer GrSciColl-Sammlung zu
  
  
  • collectionToInstitutionCode : ordnet einen Sammlungscode einer GrSciColl-Institution zu. Ich würde es wahrscheinlich in collectionCodeToInstitution (TBD) umbenennen.
  
  
  • institutionToCollectionCode : ordnet einen Institutionscode einer GrSciColl-Sammlung zu. Ich würde es wahrscheinlich in institutionCodeToCollection (TBD) umbenennen.
  
  

Der Wert der Tags sollte dem Muster {key}:{code} folgen.

Es sieht gut aus - ich bin sehr gespannt, wie es auf tatsächliche Daten angewendet wird.

ausführlich oder nicht
Sollten wir eine "ausführliche" Option wie beim Spezies-Match haben?

Wenn wir uns vorstellen, dass jemand außer den Mitarbeitern dies verwendet, könnte es nützlich sein, nur eine match or none -Option zu haben. Sagen Sie Plazi, wenn Sie es verwenden, um Links von Sammlungscodes in Artikeln zu erstellen.

// plain lookup - not verbose - will at most return one institution and one collection.
{
  institutionMatch: {
    matchType: 'NONE'
  },
  {
    collectionMatch: {
      matchType: 'FUZZY',
      reasons: ['SAME_NAME', 'SAME_CODE', 'SAME_COUNTRY'],
      entity: {
        ...
      }
    }
  }
}

// verbose option
// could be like the one running in dev
{
  "institutionMatches": [],
  "collectionMatches": [
    ...
  ]
}

bei der Benennung
die Artenübereinstimmungs-API verwendet matchType anstelle von type und die Cluster verwenden reasons anstelle von remarks .

Echte Daten
Bevor ich es mit echten Daten ausführe, frage ich mich, ob es sich lohnen würde, nur die 500 wichtigsten eindeutigen Kombinationen aus Institutionscode/ID, Sammlungscode/ID zu überprüfen und einige davon manuell zu bewerten. Wir könnten etwas lernen (sagen wir, wir müssen versuchen, ID und Code umzudrehen)

Was macht ein Match aus?
Wann, glauben Sie, wird dies ein Match auslösen?

• Nur genau?
• Fuzzy, aber nur ein Ergebnis
• Exakte Institution, aber nur eine unscharfe Sammlung?

Land als Disambiguator
Wäre es sinnvoll, Land als Suchparameter hinzuzufügen? Bei der Indizierung von Vorkommen könnten wir das Land des Herausgebers hinzufügen, um es eindeutig zu machen, wenn es beispielsweise 2 Übereinstimmungen in der Sammlung gibt? Oder macht man das besser, indem der Verbraucher die Ergebnisse iteriert?

Ich habe gerade versucht, anhand eines CSV-Extrakts, den ich vor einiger Zeit hatte, eine Übereinstimmung herzustellen.
Die CSV-Datei ist eindeutig institutionId, institutionCode, datasetKey, publisherKey mit einer Vorkommensanzahl für jeden.

Ich habe alles mit mehr als 2500 Vorkommen genommen und versucht, sie mit dem Dienst abzugleichen.

105,871,241 occurrences had a single match
 24,553,278 with an exact singular match
 27,113,941 occurrences had multiple matches
 34,998,066 occurrences had no match

2,374 combinations was tested against the service (multiple can be the same since it included dataset and publisher)

Das ist kein schlechter Anfang. Die Qualität der Matches habe ich allerdings nicht bewertet.

_Was macht eine Übereinstimmung aus?_
Wann, glauben Sie, wird dies ein Match auslösen?

• Nur genau?
• Fuzzy, aber nur ein Ergebnis
• Exakte Institution, aber nur eine unscharfe Sammlung?

Damit meinen Sie die nicht ausführliche Version, in der wir nur 1 Übereinstimmung anzeigen, oder?

Es könnte so etwas sein:

• Für Institutionen
  
  
  
  • Nur eine exakte Übereinstimmung
  
  
  • Nur ein Fuzzy-Match
  
  
• Für Sammlungen
  
  
  
  • Nur eine exakte Übereinstimmung
  
  
  • Wenn eine Institutionsübereinstimmung vorhanden war, wurde nur eine Fuzzy-Übereinstimmung gefunden, deren Institution mit der übereinstimmenden Institution übereinstimmt
  
  
  • Wenn es keinen Institutions-Match gab, nur einen Fuzzy-Match
  
  

Denkst du, wir sollten auch einen allgemeinen Spielstatus angeben?

_Was macht eine Übereinstimmung aus?_
Wann, glauben Sie, wird dies ein Match auslösen?

• Nur genau?
• Fuzzy, aber nur ein Ergebnis
• Exakte Institution, aber nur eine unscharfe Sammlung?

Damit meinen Sie die nicht ausführliche Version, in der wir nur 1 Übereinstimmung anzeigen, oder?

Ich meinte die Verwendung in Pipelines zum Zuweisen von GrSciColl-IDs zu Vorkommen. Ich hatte mir vorgestellt, dass dieser Service die Entscheidung und alle Logik beinhaltet. Wie funktioniert es bei anderen Suchdiensten?

Das erinnert mich daran, dass Sie neulich erwähnt haben, dass Sie erwogen haben, alle übereinstimmenden IDs zum Vorkommensindex hinzuzufügen.
Ich denke, es gibt 2 mögliche Versionen:

• Hinzufügen aller möglichen Kandidaten. Das verschiebt die Last effektiv auf die Benutzeroberfläche oder den Benutzer. Und dieselben Exemplare würden in mehreren Sammlungen erscheinen.
• Fügen Sie nur dann einen Link hinzu, wenn wir eine sichere Übereinstimmung haben. Der Dienst übernimmt die Verantwortung für die Erklärung. Wir werden in der Lage sein, weniger zusammenzubringen.

Ich bin eher für Version 2. Hinzufügen einer GrSciColl-ID zu einem Vorkommen nur, wenn wir 1 sichere Übereinstimmung haben. Keine Reihe von Kandidatenübereinstimmungen. Und wenn wir mehr Übereinstimmungen wollen, wenden wir uns an die Verlage, um entweder GrSciColl oder den Vorkommen bessere Kennungen hinzuzufügen. Oder wir fügen den Datensätzen gegebenenfalls Maschinen-Tags hinzu.

Wenn es sinnvoll ist, alle Kandidaten indizieren zu lassen, könnten wir dann ein separates Feld dafür in Betracht ziehen?

Sollte Der Dienst Flags zurückgeben. FUZZY COLLECTION CODE-ÜBEREINSTIMMUNG. KEINE SAMMLUNGSCODE-ÜBEREINSTIMMUNG. Ähnlich wie beim Art-Match-Service.

Ich kann mir diese Flaggen vorstellen:

• AMBIGUOUS_INSTITUTION : mehr als 1 Institution wurde gefunden und wir konnten das Unentschieden nicht lösen
• AMBIGUOUS_COLLECTION : wie oben, aber für Sammlungen
• FUZZY_INSTITUTION_MATCH : 1 Institution stimmte überein, aber verschwommen
• FUZZY_COLLECTION_MATCH : wie oben, aber für Sammlungen
• INSTITUTION_NAME_USED : Das Feld institutionCode enthält den Institutionsnamen anstelle des Codes
• OWNER_INSTITUTION_NAME_USED : wie oben, aber für die Eigentümerinstitution
• COLLECTION_NAME_USED : wie oben, aber für Sammlungen
• NO_COLLECTION_CODE_MATCH : Der angegebene Code stimmt nicht überein
• NO_INSTITUTION_CODE_MATCH : wie oben
• NO_COLLECTION_ID_MATCH : Die angegebene ID stimmt nicht überein
• NO_INSTITUTION_ID_MATCH : wie oben
• INSTITUTION_COLLECTION_MISMATCH : Die gefundene Sammlung gehört nicht zur passenden Institution

BEARBEITEN: Die INSTITUTION_NAME_USED können möglicherweise entfernt und nur die FUZZY_INSTITUTION_MATCH für diese Fälle verwendet werden. Ich wüsste nicht, was für Verlage nützlicher wäre

Ich mag es – ich habe den Eindruck, dass viele Verlage diese Flaggen schätzen und danach handeln. Dies gibt ihnen die Einblicke, um Daten zu ändern und den Abgleich zu verbessern.

Der Dienst gibt jetzt eine Antwort zurück wie:

{
  "institutionMatch": {
    ...
  },
  "collectionMatch": {
    ...
  },
  alternativeMatches { 
    institutionMatches: []
    collectionMatches: []
  }
}

Die alternativen Übereinstimmungen werden nur angezeigt, wenn der Parameter verbose auf „true“ gesetzt ist. Die Fuzzy-Matches sind aus Performance-Gründen auf 20 Ergebnisse begrenzt.

Es wurde auch ein Country -Parameter hinzugefügt, der verwendet wird, um Bindungen zu lösen: http://api.gbif-dev.org/v1/grscicoll/lookup?institutionCode=BR&country=BE&verbose=true

Eine Übereinstimmung findet statt, wenn eine dieser Bedingungen erfüllt ist:

• Es gibt nur eine Maschinen-Tag-Übereinstimmung
• Es gibt nur 1 exakte Übereinstimmung
• Es gibt mehrere genaue Übereinstimmungen, aber nur eine stimmt mit dem empfangenen Länderparameter überein
• Es gibt nur 1 Fuzzy-Match
• Es gibt mehrere Fuzzy-Matches, aber nur einer stimmt mindestens mit dem Code oder der ID und einem weiteren Feld (Name oder alternativer Code) überein.
• Es gibt mehrere Fuzzy-Übereinstimmungen, aber nur eine stimmt mit dem empfangenen Länderparameter überein

Darüber hinaus werden Institutionen, deren Eigentümerinstitution sich von der Institution unterscheidet, nicht als Übereinstimmung angesehen. Auch Sammlungen, deren Institution nicht mit der von der Institution akzeptierten Übereinstimmung übereinstimmt, werden ebenfalls nicht als Übereinstimmung angesehen.

Ich habe die Flags nicht hinzugefügt, sondern stattdessen ein Statusfeld:

• ACCEPTED : akzeptierte Übereinstimmung
• AMBIGUOUS : Es wurde mehr als 1 Ergebnis gefunden und wir konnten das Unentschieden nicht brechen
• AMBIGUOUS_MACHINE_TAGS : wie oben, aber mit Maschinen-Tag-Übereinstimmungen
• AMBIGUOUS_OWNER : Es gibt Ergebnisse, die aber nicht mit dem Eigentümer der Institution übereinstimmen, daher überspringen wir sie, um keine Links zu Leihsammlungen zu erstellen
• AMBIGUOUS_INSTITUTION_MISMATCH : Es gibt Fuzzy-Matches, die aber nicht zu der passenden Institution gehören
• DOUBTFUL : Die gefundene Übereinstimmung ist unscharf

Der Rest der Flags kann aus dem Feld reasons des Spiels abgeleitet werden. Über dieses Feld können Probleme in Pipelines festgelegt werden.

Ich habe aus unseren Daten in PROD Kombinationen dieser Felder extrahiert, die in mehr als 1000 Datensätzen vorhanden sind:

• v_institutionid
• v_institutioncode
• v_ownerinstitutioncode
• v_collectioncode
• v_collectionid
• datasetkey

Außerdem habe ich das Land aus der Verlagsorganisation des Datensatzes übernommen.

Dann habe ich sie an den Suchdienst in UAT weitergegeben. Die Ergebnisse befinden sich in dieser Tabelle