Registry: Implémenter un service de recherche pour les collections GrSciColl

J'ai mis en DEV une première version du service de recherche de collections (il n'utilise toujours pas les balises machine) pour voir si c'est ce que nous attendions.

Il renvoie une liste des correspondances d'institution et une autre pour les correspondances de collection. C'est une liste parce que les codes ne sont pas uniques, il peut donc y avoir des cas où nous pouvons avoir plusieurs options et nous ne pouvons pas discriminer par un autre champ.

Pour chaque match, il affiche :

• type : il peut être exact ou fuzzy . exact est uniquement si le code et l'identifiant correspondent. Sinon, c'est fuzzy .
• remarques : ce sont des observations pour comprendre comment le match a été fait. Les valeurs possibles sont :
  
  
  
  • CODE_MATCH : il n'ignore pas la casse
  
  
  • IDENTIFIER_MATCH : il n'ignore pas la casse
  
  
  • ALTERNATIVE_CODE_MATCH : il n'ignore pas la casse
  
  
  • NAME_MATCH : il ignore la casse et supprime les accents et les espaces mais ne fait pas de correspondance de préfixe ou de suffixe
  
  
  • PROBABLY_ON_LOAN : cela se produit lorsque l'établissement propriétaire et l'établissement ne sont pas les mêmes
  
  
  • INST_COLL_MISMATCH : cela se produit lorsque l'institution d'une collection n'est pas présente dans les institutions appariées.
  
  

Lorsqu'il existe des correspondances d'institutions, une collection ne correspond que de manière approximative si elle appartient à l'une des institutions correspondantes. Les correspondances exactes de la collection seront toujours renvoyées.

Vous pouvez consulter ces exemples pour voir comment le service fonctionne :

• http://api.gbif-dev.org/v1/grscicoll/lookup?collectionCode=herbarium renvoie 567 collections
• http://api.gbif-dev.org/v1/grscicoll/lookup?collectionCode=herbarium&institutionCode=UNCA renvoie 1 institution et 1 collection
• http://api.gbif-dev.org/v1/grscicoll/lookup?collectionCode=UNCA&institutionCode=UNCA&institutionId=gbif :ih: irn:240135 renvoie 1 institution et 2 collections
• http://api.gbif-dev.org/v1/grscicoll/lookup?collectionCode=UIMNH&collectionId=http ://grbio.org/cool/zrdp-fspx&institutionCode=K est un exemple de INST_COLL_MISMATCH
• http://api.gbif-dev.org/v1/grscicoll/lookup?ownerInstitutionCode=MBMC&institutionCode=K est un exemple de PROBABLY_ON_LOAN

Ai-je raté quelque chose @MortenHofft @timrobertson100 ?

J'ai ajouté la vérification des balises machine en suivant le format déjà utilisé dans les pipelines pour l'instant :

• Espace de noms : processing.gbif.org
• Noms:
  
  
  
  • institutionCode : associe un code d'établissement à un établissement GrSciColl
  
  
  • collectionCode : mappe un code de collection à une collection GrSciColl
  
  
  • collectionToInstitutionCode : associe un code de collection à une institution GrSciColl. Je le renommerais probablement en collectionCodeToInstitution (TBD).
  
  
  • institutionToCollectionCode : associe un code d'établissement à une collection GrSciColl. Je le renommerais probablement en institutionCodeToCollection (TBD).
  
  

La valeur des balises doit suivre le modèle {key}:{code} .

Cela a l'air bien - je suis très curieux de le voir appliqué aux données réelles.

verbeux ou pas
Devrions-nous avoir une option "verbose" comme dans la correspondance des espèces ?

Si nous imaginons que quelqu'un d'autre que le personnel l'utilise, il pourrait être utile d'avoir simplement une option match or none . Dites Plazi en l'utilisant pour créer des liens à partir des codes de collection dans les articles.

// 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": [
    ...
  ]
}

sur la dénomination
l'API de correspondance des espèces utilise matchType au lieu de type et les clusters utilisent reasons au lieu de remarks .

Données réelles
Avant de l'exécuter sur des données réelles, je me demande s'il ne serait pas utile de vérifier les 500 principales combinaisons distinctes de code d'institution/id colelctionCode/ID et d'évaluer manuellement certaines d'entre elles ? Nous pourrions apprendre quelque chose (disons que nous devons essayer d'inverser l'identifiant et le code)

Qu'est-ce qui constitue un match ?
Quand pensez-vous que cela déclenchera un match?

• Exact seulement ?
• Flou mais un seul résultat
• Institution exacte, mais une seule collection floue ?

Le pays comme désambiguïsateur
Serait-il judicieux d'ajouter le pays comme paramètre de recherche ? Lors de l'indexation des occurrences, nous pourrions ajouter le pays de l'éditeur pour lever l'ambiguïté lorsqu'il y a par exemple 2 correspondances de collection ? Ou vaut-il mieux que le consommateur itère les résultats ?

J'ai juste essayé de faire correspondre basé sur un extrait csv que j'avais il y a quelque temps.
Le csv est distinct institutionId, institutionCode, datasetKey, publisherKey avec un nombre d'occurrences pour chacun.

J'ai pris n'importe quoi avec plus de 2500 occurrences et j'ai essayé de les comparer au service.

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)

Ce n'est pas un mauvais début. Je n'ai pas évalué la qualité des matchs.

_Qu'est-ce qu'un match ?_
Quand pensez-vous que cela déclenchera un match?

• Exact seulement ?
• Flou mais un seul résultat
• Institution exacte, mais une seule collection floue ?

Pour cela, vous voulez dire pour la version non verbeuse où nous ne montrons qu'une seule correspondance, n'est-ce pas ?

Cela pourrait être quelque chose comme :

• Pour les établissements
  
  
  
  • Une seule correspondance exacte
  
  
  • Une seule correspondance floue
  
  
• Pour les collectes
  
  
  
  • Une seule correspondance exacte
  
  
  • S'il y avait une correspondance d'établissement, une seule correspondance approximative dont l'établissement est le même que l'établissement correspondant
  
  
  • S'il n'y avait pas de correspondance d'établissement, une seule correspondance approximative
  
  

Pensez-vous que nous devrions également fournir un statut de correspondance global ?

_Qu'est-ce qu'un match ?_
Quand pensez-vous que cela déclenchera un match?

• Exact seulement ?
• Flou mais un seul résultat
• Institution exacte, mais une seule collection floue ?

Pour cela, vous voulez dire pour la version non verbeuse où nous ne montrons qu'une seule correspondance, n'est-ce pas ?

Je voulais dire lors de son utilisation dans des pipelines pour attribuer des ID GrSciColl à des occurrences. J'avais imaginé que ce service incluait la décision et toute la logique. Comment cela fonctionne-t-il pour les autres services de recherche ?

Cela me rappelle que vous avez mentionné l'autre jour que vous envisagez d'ajouter tous les identifiants correspondants à l'index des occurrences.
Je pense qu'il y a 2 versions possibles :

• Ajouter tous les candidats possibles. Cela pousse efficacement le fardeau sur l'interface utilisateur ou l'utilisateur. Et les mêmes spécimens apparaîtraient sous plusieurs collections.
• N'ajoutez un lien que lorsque nous avons une correspondance fiable. Le service assume la responsabilité de la déclaration. Nous pourrons en égaler moins.

Je suis plus en faveur de la version 2. Ajouter uniquement un identifiant GrSciColl à une occurrence lorsque nous avons 1 correspondance confiante. Pas un tableau de correspondances de candidats. Et si nous voulons plus de correspondances, nous nous adressons aux éditeurs pour ajouter de meilleurs identifiants à GrSciColl ou aux occurrences. Ou nous ajoutons des balises machine aux ensembles de données au cas où.

S'il est utile d'avoir tous les candidats indexés, pourrait-on alors envisager un champ séparé pour cela ?

Le service devrait-il renvoyer des drapeaux. MATCH FUZZY DE CODE DE COLLECTION. AUCUNE CORRESPONDANCE DE CODE DE COLLECTE. Similaire au service d'appariement d'espèces.

Je peux penser à ces drapeaux:

• AMBIGUOUS_INSTITUTION : plus d'une institution a été trouvée et nous n'avons pas pu briser l'égalité
• AMBIGUOUS_COLLECTION : idem ci-dessus mais pour les collections
• FUZZY_INSTITUTION_MATCH : 1 institution appariée, mais de manière floue
• FUZZY_COLLECTION_MATCH : idem ci-dessus mais pour les collections
• INSTITUTION_NAME_USED : le champ institutionCode contient le nom de l'institution au lieu du code
• OWNER_INSTITUTION_NAME_USED : idem ci-dessus mais pour l'institution propriétaire
• COLLECTION_NAME_USED : idem ci-dessus mais pour les collections
• NO_COLLECTION_CODE_MATCH : le code fourni ne correspond pas
• NO_INSTITUTION_CODE_MATCH : comme ci-dessus
• NO_COLLECTION_ID_MATCH : l'identifiant fourni ne correspond pas
• NO_INSTITUTION_ID_MATCH : comme ci-dessus
• INSTITUTION_COLLECTION_MISMATCH : la collection trouvée n'appartient pas à l'institution recherchée

EDIT : les INSTITUTION_NAME_USED peuvent peut-être être supprimés et n'utiliser que les FUZZY_INSTITUTION_MATCH pour ces cas. Je ne sais pas ce qui serait plus utile pour les éditeurs

J'aime ça - j'ai l'impression que de nombreux éditeurs apprécient ces drapeaux et agissent en conséquence. Cela leur donnera les informations nécessaires pour modifier les données et améliorer la correspondance.

Le service renvoie maintenant une réponse du type :

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

Les correspondances alternatives ne sont affichées que si le paramètre verbose est défini sur true. Les correspondances floues sont limitées à 20 résultats pour des raisons de performances.

Il a également été ajouté un paramètre Country utilisé pour rompre les liens : http://api.gbif-dev.org/v1/grscicoll/lookup?institutionCode=BR&country=BE&verbose=true

Une correspondance a lieu si l'une de ces conditions est remplie :

• Il n'y a qu'une seule correspondance de tag machine
• Il n'y a qu'une seule correspondance exacte
• Il existe plusieurs correspondances exactes, mais une seule correspond au paramètre de pays reçu
• Il n'y a qu'une seule correspondance floue
• Il existe plusieurs correspondances approximatives, mais une seule correspond au moins au code ou à l'identifiant et à un autre champ (nom ou code alternatif)
• Il existe plusieurs correspondances approximatives, mais une seule correspond au paramètre de pays reçu

De plus, les établissements dont l'établissement propriétaire est différent de l'établissement ne sont pas considérés comme correspondants. De plus, les collections dont l'institution ne correspond pas à la correspondance acceptée par l'institution ne sont pas non plus considérées comme une correspondance.

Je n'ai pas ajouté les drapeaux mais un champ d'état à la place :

• ACCEPTED : correspondance acceptée
• AMBIGUOUS : plus d'un résultat a été trouvé et nous n'avons pas pu départager
• AMBIGUOUS_MACHINE_TAGS : comme ci-dessus, mais avec des correspondances de balises machine
• AMBIGUOUS_OWNER : il y a des résultats mais ils ne correspondent pas au propriétaire de l'institution, nous les ignorons donc pour ne pas créer de lien sur les recouvrements de prêts
• AMBIGUOUS_INSTITUTION_MISMATCH : il y a des correspondances floues mais n'appartiennent pas à l'institution correspondante
• DOUBTFUL : la correspondance trouvée est floue

Le reste des drapeaux peut être déduit du champ reasons du match. Les problèmes peuvent être définis à partir de ce champ dans les pipelines.

J'ai extrait de nos données dans PROD des combinaisons de ces champs qui sont présentes dans plus de 1000 enregistrements :

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

De plus, j'ai pris le pays de l'organisation de publication de l'ensemble de données.

Ensuite, je les ai transmis au service de recherche dans UAT. Les résultats sont dans ce tableur