パート1に関して：

誰が作業を行うかに関しては、GBIFがこれに時間を割くことができれば、それが最善で最も便利だと私は敬意を表して思います。 iDigBio / ACIS ITはまだ1人のチームメンバーが不足しており、結果として得られる製品はすべての人にとってはるかにうまく機能すると私たちは感じていますが、すぐにコミットできるとは限りません。

この号のセクション1に関するその他の注意事項は次のとおりです。

• 一致するものが見つからない場合の3の提案された解決策を含め、リストの1〜3は理にかなっています

• 照合の場合、GBIFの機関コードからcollections.json機関コードに照合できる可能性があります

• collections.jsonの既存のドキュメント（リポジトリのreadme内）に基づいて、 institution_lsidは、見つかった場合は「GRBio LSIDまたは機関LSIDのcoolURI」にマップされ、それ以外の場合は空白になります。

• 他の一致は、文字列ベースの一致アルゴリズムである必要があります。 照合/検証の目的で役立つ可能性のある注意点は、collections.jsonのレコードセットuuidが、APIから提供されるレコードセットuuidと一致することです。

パート2：
iDigBioのcollections.jsonの個々のレコードは、Institution-Collectionレコードです。 GBIFは、機関とコレクションを別々のエンティティに適切に分割します。 目的の階層については、添付の図を参照してください。

注： https ：//github.com/iDigBio/idb-us-collectionsのreadmeにフィールド定義があります。

個々のマッピングに関するコメント：

「識別子として追加されたUniqueNameUUID」-これは、iDigBioレコードの階層内の「機関」UUIDとして意図されているように見えますが、実装されていないようです。 GBIFシステムで識別子として保持します。

recordsetQuery：これにより、iDigBioレコードセットへのリンクが生成されます（つまり、https：//www.idigbio.org/portal/recordsets/ea12da76-1b2e-4944-8709-1de3af1c65e2）。 別の方法でレコードセットへのリンクを生成している場合は、このフィールドを破棄できます。

レコードセット-リマインダー：これは、システム内の個々のレコードの親オブジェクトです

KnowToContainTypes：これは破棄しても問題ないようです。

Collectionextent：CatalogedSpecimensが空白のCatalogedSpecimensにコピーできますが、個別のフィールドとして保持する必要はありません（破棄）。

「attributionLogoURL、providerManagedID、deriveFrom」-これらはAudubonコア用語であることに注意してください

パート3について：

IHとiDigBioデータを統合する提案された方法で大丈夫です。 IHまたはiDigBioのどちらが最新のレコードであるかを判断するために、iDigBioリポジトリ内の個々のファイルのコミット日を追加/変更日として使用できます。

リポジトリが機能する方法は、人間が./collections/{collection_uuid}.jsonという名前のjsonのチャンクを作成/更新してコミットすることです。 次に、ソフトウェアワークフローはテストを実行し、そのjsonチャンクを完全なcollections.jsonに集約します。 個々のjsonファイルの例は次のとおりです。

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

重要な注意：実際にロードされて使用されるcollections.jsonファイルは、マスターブランチではなく、 json-indexまたはgh-pagesブランチ（両方にプッシュされます）から提供されます。 例えば：

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

また

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

これらすべてがお役に立てば幸いです。 その他の質問や説明については、お気軽に@お問い合わせください。

@roncanepa @nrejackマッピングを確認していましたが、レジストリに欠落しているiDigBioフィールドはAttributionLogoURLだけのようです。 しかし、 collections.jsonファイルを確認したところ、このフィールドは常に空であることがわかりました。 それでもレジストリに追加する必要がありますか？ または私たちもそれを捨てることができますか？

@asturconこのフィールドはAudubonCoreから取得しましたが、何もしていないため、フィールドを破棄できることに同意しました。

@roncanepaと@nrejackの返信に感謝します。
その場合は、[ 1。iDigBioとGrSciCollのエントリをリンクする]から始めます。 可能な限り自動的に行い、手動チェックが必要になる可能性のあるものをあなたとCatに送信しますが、大丈夫ですか？

私と一緒に元気に送ってください！ みなさん、ありがとうございました!!

ねえ@CatChapman 、モーテンはiDigBioとGrSciCollエントリのマッチングに取り組んでいます： https ：//github.com/gbif/registry/issues/187
これらはより多くの詳細と識別子を持っているエントリであるため、最初にすべてをGrSCiColl機関に一致させる方が理にかなっていることがわかります。 次に、機関の一致を取得したら、コレクションを確認して、これらも一致させることができます。

モーテンは、上記にリンクされた問題に関する彼のマッチングプロセス全体と結果について説明しましたが、ここにハイライトがあります。

1. IRNに基づいてiDigBioエントリを照合します
2. 他の識別子に基づいて左側のiDigBioエントリを照合します
3. タイトルとコードに基づいて左側のiDigBioエントリを照合します（照合を容易にするためにタイトルが処理されたことに注意してください）
4. 都市とコードに基づいて左側のiDigBioエントリを照合します
5. iDigBio機関コードがない場合は、左側のiDigBioエントリベースのタイトルのみを照合します
6. 左側のiDigBioエントリベースのタイトルと一致します（コードが競合しているにもかかわらず）
7. 左側のiDigBioエントリを手動で照合します

これにより、235個のiDigBioエントリが一致しなくなり、GrSciCollに新しいエントリが作成されます。
今、私たちはあなたの助けが一致をチェックする必要があります！ https://github.com/gbif/registry/issues/187にアクセスして、一致する結果を確認していただけますか？ （より便利な場合は、スプレッドシートを提供することもできます）。

GrSciCollではコレクションのタイトルが少しあいまいである可能性があり、信頼できるコードが常にあるとは限らないため、最初に重複するコレクションがある可能性があることに注意してください。 心配はいりません。少し後で解決する予定です。

モーテンはまた、ここで自分自身をマージする方法を文書化しました： https ：//github.com/gbif/registry/issues/188

@ManonGros WOW！ これは素晴らしい。 君たちはロックする、そんなに。

スプレッドシートは素晴らしいでしょう-私はちょうどあなたに電子メールを送ったので、そこにそれを送るか、ここでそれにリンクしてください（それがGoogleスプレッドシートなどである場合）。

＃188を今から覗いてみます。

素晴らしい！ マッチングのためにタブ区切りのCSVファイルを追加しています：
iDigBio_GrSciColl_matches_march2020.tsv.zip

機械可読形式で小切手を取り戻すのに最適な場合。 このファイルに、一致するたびにtrue / falseの列を追加し、対応する一致がtrueであると思われる潜在的な「修正」列を追加することをお勧めします。

CATからの入力で更新されたMortenのJSONファイル：
iDigBio_Morten_matches_AND_Cat_addition.json.zip