concernant la partie 1 :

En ce qui concerne qui effectue le travail, je pense respectueusement qu'il serait préférable et plus opportun que le GBIF puisse consacrer du temps à cela. iDigBio/ACIS IT est encore à court d'un membre de l'équipe et, malgré notre sentiment que le produit résultant fonctionnera beaucoup mieux pour tout le monde, je ne pense pas que nous puissions garantir que nous serions en mesure de nous y engager de si tôt.

Voici quelques autres notes pour la section 1 de ce numéro :

• 1-3 sur votre liste ont du sens, y compris la solution proposée en 3 si aucune correspondance ne peut être trouvée

• pour la correspondance, il pourrait être possible de faire correspondre le code de l'institution GBIF au code de l'institution collections.json

• basé sur la documentation existante de collections.json (dans le fichier readme du dépôt), le institution_lsid est mappé à un "GRBio LSID ou coolURI pour le LSID de l'institution" s'il est trouvé, sinon il est vide

• d'autres correspondances devront probablement être des algorithmes de correspondance basés sur des chaînes. Une note potentiellement utile à des fins de correspondance/vérification est que l'uuid du jeu d'enregistrements dans collections.json correspondra à l'uuid du jeu d'enregistrements servi à partir de notre API.

Partie 2:
Les enregistrements individuels dans le fichier collections.json d'iDigBio sont des enregistrements Institution-Collection. Le GBIF divise correctement l'institution et la collection en entités distinctes. Voir le diagramme ci-joint pour la hiérarchie prévue.

Remarque : il existe des définitions de champs dans le fichier readme de : https://github.com/iDigBio/idb-us-collections

Commentaires sur les mappages individuels :

"UniqueNameUUID ajouté comme identifiant" - cela semble être conçu comme un UUID "institution" dans une hiérarchie d'enregistrements iDigBio mais ne semble pas avoir été implémenté. Conserver comme identifiant dans le système GBIF.

recordsetQuery : Cela génère un lien vers le jeu d'enregistrements iDigBio (c'est-à-dire https://www.idigbio.org/portal/recordsets/ea12da76-1b2e-4944-8709-1de3af1c65e2). Ce champ peut être ignoré si vous générez des liens vers le jeu d'enregistrements d'une autre manière.

Recordsets - Rappel : il s'agit de notre objet parent pour les enregistrements individuels dans notre système

KnownToContainTypes : cela semble acceptable de jeter.

Collectionextent : peut être copié dans CatalogedSpecimens où CatalogedSpecimens est vide, mais il n'est pas nécessaire de le conserver en tant que champ séparé (jeter).

"attributionLogoURL, providerManagedID, deriveFrom" - notez qu'il s'agit de termes Audubon Core

Concernant la partie 3 :

Nous sommes d'accord avec la méthode proposée d'intégration des données IH et iDigBio. Pour vous aider à déterminer qui est l'enregistrement le plus récent, IH ou iDigBio, vous pouvez utiliser la date de validation d'un fichier individuel dans le dépôt iDigBio comme date ajoutée/modifiée.

La façon dont ce référentiel fonctionne est qu'un humain crée/met à jour un morceau de json nommé ./collections/{collection_uuid}.json et valide. Le flux de travail logiciel exécute ensuite des tests et agrège ce morceau json dans le fichier collections.json complet. Un exemple de fichier json individuel serait :

https://github.com/iDigBio/idb-us-collections/blob/master/collections/001c5234-048b-11e5-b0ee-002315492bbc

Remarque importante : Le fichier collections.json qui est réellement chargé et utilisé est servi à partir de la branche json-index ou gh-pages (il est envoyé aux deux) et non à la branche principale. Par exemple:

https://raw.githubusercontent.com/iDigBio/idb-us-collections/json-index/collections.json

ou

http://idigbio.github.io/idb-us-collections/collections.json

J'espère que tout cela aide. N'hésitez pas à @ nous pour des questions supplémentaires ou des éclaircissements.

@roncanepa @nrejack Je vérifiais les mappages et on dirait que AttributionLogoURL est le seul champ iDigBio qui nous manque dans notre registre. Mais j'ai vérifié le fichier collections.json et j'ai remarqué que ce champ est toujours vide. Doit-on quand même l'ajouter à notre registre ? ou on peut le jeter aussi ?

@asturcon Nous avons récupéré ce champ d'Audubon Core, mais nous avons convenu que vous pouvez supprimer le champ car nous ne faisons rien avec.

Merci beaucoup pour vos réponses @roncanepa et @nrejack !
Dans ce cas, nous commencerons par [ 1. Lier les entrées iDigBio et GrSciColl ]. Nous ferons autant que possible automatiquement et vous enverrons, à vous et à Cat, certaines choses qui pourraient nécessiter une vérification manuelle, est-ce que cela vous convient ?

Ça me va, renvoyez ! Merci beaucoup, tout le monde !!

Hey @CatChapman , Morten a travaillé sur la correspondance des entrées iDigBio et GrSciColl : https://github.com/gbif/registry/issues/187
Il s'avère qu'il est plus logique de tout faire correspondre d'abord aux institutions GrSCiColl car ce sont les entrées pour lesquelles nous avons beaucoup plus de détails et d'identifiants. Ensuite, une fois que nous avons obtenu les correspondances pour l'institution, nous pourrions jeter un coup d'œil aux collections et les faire correspondre également.

Morten a décrit l'ensemble de son processus d'appariement et ses résultats sur le problème lié ci-dessus, mais voici les points saillants :

1. Faites correspondre les entrées iDigBio en fonction de l'IRN
2. Faites correspondre les entrées iDigBio de gauche en fonction d'autres identifiants
3. Faites correspondre les entrées iDigBio de gauche en fonction du titre et du code (notez que les titres ont été traités pour faciliter la correspondance)
4. Faites correspondre les entrées iDigBio de gauche en fonction de la ville et du code
5. Faites correspondre les entrées iDigBio de gauche en fonction du titre seul lorsqu'il n'y a pas de code d'institution iDigBio
6. Faire correspondre le titre basé sur les entrées iDigBio de gauche (malgré les codes contradictoires)
7. Faire correspondre manuellement les entrées iDigBio de gauche

Cela laisse 235 entrées iDigBio sans correspondance pour lesquelles nous créerions de nouvelles entrées dans GrSciColl.
Nous avons maintenant besoin de votre aide pour vérifier la correspondance ! Pourriez-vous aller sur https://github.com/gbif/registry/issues/187 et jeter un œil au résultat correspondant ? (Nous pouvons également vous fournir une feuille de calcul si cela est plus pratique).

Notez que nous pourrions avoir des collections en double au début car certains titres de collection peuvent être un peu vagues dans GrSciColl et nous n'avons pas toujours des codes fiables. Pas de soucis, nous prévoyons de les aplanir un peu plus tard.

Morten a également documenté comment nous prévoyons de faire la fusion elle-même ici : https://github.com/gbif/registry/issues/188

@ManonGros WAOUH ! C'est bien. Vous rockez, tellement.

Une feuille de calcul serait fantastique - je viens de vous envoyer un e-mail, alors n'hésitez pas à l'envoyer là-bas, ou à créer un lien vers celle-ci (s'il s'agit d'une feuille Google, etc.) ici.

Je vais jeter un coup d'œil au #188 maintenant.

Super! J'ajoute le fichier CSV séparé par des tabulations pour la correspondance :
iDigBio_GrSciColl_matches_march2020.tsv.zip

Ce serait formidable de récupérer votre chèque dans un format lisible par machine. Nous suggérons d'ajouter une colonne à ce fichier avec vrai/faux pour chaque correspondance ainsi qu'une colonne de "correction" potentielle avec la correspondance correspondante que vous pensez être vraie.

Fichier JSON de Morten mis à jour avec la contribution de CAT :
iDigBio_Morten_matches_AND_Cat_addition.json.zip