Registry: Menerapkan layanan pencarian untuk koleksi GrSciColl

Saya memasukkan DEV versi pertama dari layanan pencarian koleksi (masih tidak menggunakan tag mesin) untuk melihat apakah ini yang kami harapkan.

Ini mengembalikan daftar kecocokan institusi dan satu lagi untuk kecocokan koleksi. Ini adalah daftar karena kode tidak unik sehingga mungkin ada kasus di mana kita dapat memiliki beberapa opsi dan kita tidak dapat membedakan dengan bidang lain.

Untuk setiap pertandingan itu menunjukkan:

• ketik: bisa exact atau fuzzy . exact hanya jika kode dan pengenal cocok. Kalau tidak, itu fuzzy .
• catatan: mereka adalah pengamatan untuk memahami bagaimana pertandingan itu dilakukan. Nilai yang mungkin adalah:
  
  
  
  • CODE_MATCH : tidak mengabaikan kasus
  
  
  • IDENTIFIER_MATCH : tidak mengabaikan kasus
  
  
  • ALTERNATIVE_CODE_MATCH : tidak mengabaikan kasus
  
  
  • NAME_MATCH : mengabaikan huruf besar/kecil dan menghilangkan aksen dan spasi tetapi tidak melakukan pencocokan awalan atau akhiran
  
  
  • PROBABLY_ON_LOAN : terjadi ketika institusi pemilik dan institusi tidak sama
  
  
  • INST_COLL_MISMATCH : itu terjadi ketika institusi koleksi tidak ada di institusi yang cocok.
  
  

Ketika ada kecocokan institusi, koleksi hanya cocok secara kabur jika itu milik salah satu institusi yang cocok. Kecocokan koleksi yang tepat akan selalu dikembalikan.

Anda dapat memeriksa contoh berikut untuk melihat cara kerja layanan:

• http://api.gbif-dev.org/v1/grscicoll/lookup?collectionCode=herbarium mengembalikan 567 koleksi
• http://api.gbif-dev.org/v1/grscicoll/lookup?collectionCode=herbarium&institutionCode=UNCA mengembalikan 1 institusi dan 1 koleksi
• http://api.gbif-dev.org/v1/grscicoll/lookup?collectionCode=UNCA&institutionCode=UNCA&institutionId=gbif :ih: irn:240135 mengembalikan 1 institusi dan 2 koleksi
• http://api.gbif-dev.org/v1/grscicoll/lookup?collectionCode=UIMNH&collectionId=http://grbio.org/cool/zrdp-fspx&institutionCode=K adalah contoh dari INST_COLL_MISMATCH
• http://api.gbif-dev.org/v1/grscicoll/lookup?ownerInstitutionCode=MBMC&institutionCode=K adalah contoh dari PROBABLY_ON_LOAN

Apakah saya melewatkan sesuatu @MortenHofft @timrobertson100 ?

Saya telah menambahkan pemeriksaan tag mesin mengikuti format yang sudah digunakan dalam saluran pipa untuk saat ini:

• Ruang nama: processing.gbif.org
• Nama:
  
  
  
  • institutionCode : memetakan kode institusi ke institusi GrSciColl
  
  
  • collectionCode : memetakan kode koleksi ke koleksi GrSciColl
  
  
  • collectionToInstitutionCode : memetakan kode koleksi ke institusi GrSciColl. Saya mungkin akan mengganti namanya menjadi collectionCodeToInstitution (TBD).
  
  
  • institutionToCollectionCode : memetakan kode institusi ke koleksi GrSciColl. Saya mungkin akan mengganti namanya menjadi institutionCodeToCollection (TBD).
  
  

Nilai tag harus mengikuti pola {key}:{code} .

Kelihatannya bagus - Saya sangat penasaran untuk melihatnya diterapkan pada data aktual.

bertele-tele atau tidak
Haruskah kita memiliki opsi "verbose" seperti pada pencocokan spesies?

Jika kita membayangkan siapa pun kecuali staf yang menggunakan ini, mungkin berguna untuk hanya memiliki opsi match or none . Katakanlah Plazi menggunakannya untuk membuat tautan dari kode koleksi di artikel.

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

tentang penamaan
API pencocokan spesies menggunakan matchType alih-alih type dan kluster menggunakan reasons alih-alih remarks .

Data nyata
Sebelum menjalankannya pada data nyata, saya bertanya-tanya apakah perlu memeriksa 500 kombinasi teratas dari kode institusi/id colelctionCode/ID dan menilai beberapa di antaranya secara manual? Kita mungkin belajar sesuatu (katakanlah kita perlu mencoba membalik id dan kode)

Apa yang dimaksud dengan kecocokan?
Kapan Anda membayangkan ini akan memicu kecocokan?

• Tepat saja?
• Kabur tapi hanya satu hasil
• Institusi yang tepat, tetapi hanya satu koleksi fuzzy?

Negara sebagai disambiguator
Apakah masuk akal untuk menambahkan negara sebagai parameter pencarian? Saat mengindeks kejadian, kami dapat menambahkan negara penerbit untuk disambiguasi ketika misalnya ada 2 koleksi yang cocok? Atau apakah itu lebih baik dilakukan oleh konsumen yang mengulangi hasilnya?

Saya baru saja mencoba mencocokkan berdasarkan ekstrak csv yang saya miliki beberapa waktu lalu.
Csv berbeda institutionId, institutionCode, datasetKey, publisherKey dengan jumlah kemunculan untuk masing-masing.

Saya mengambil apa pun dengan lebih dari 2500 kemunculan dan mencoba mencocokkannya dengan layanan.

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)

Itu bukan awal yang buruk. Saya belum mengevaluasi kualitas pertandingan.

_Apa yang dimaksud dengan kecocokan?_
Kapan Anda membayangkan ini akan memicu kecocokan?

• Tepat saja?
• Kabur tapi hanya satu hasil
• Institusi yang tepat, tetapi hanya satu koleksi fuzzy?

Untuk ini maksud Anda untuk versi non-verbose di mana kami hanya menampilkan 1 kecocokan, bukan?

Itu bisa seperti:

• Untuk institusi
  
  
  
  • Hanya satu yang sama persis
  
  
  • Hanya satu pertandingan kabur
  
  
• Untuk koleksi
  
  
  
  • Hanya satu yang sama persis
  
  
  • Jika ada kecocokan institusi, hanya satu kecocokan fuzzy yang institusinya sama dengan kecocokan institusi
  
  
  • Jika tidak ada kecocokan institusi, hanya satu kecocokan fuzzy
  
  

Apakah menurut Anda kami juga harus memberikan status kecocokan secara keseluruhan?

_Apa yang dimaksud dengan kecocokan?_
Kapan Anda membayangkan ini akan memicu kecocokan?

• Tepat saja?
• Kabur tapi hanya satu hasil
• Institusi yang tepat, tetapi hanya satu koleksi fuzzy?

Untuk ini maksud Anda untuk versi non-verbose di mana kami hanya menampilkan 1 kecocokan, bukan?

Maksud saya ketika menggunakannya dalam saluran pipa untuk menetapkan ID GrSciColl ke kejadian. Saya membayangkan bahwa layanan ini mencakup keputusan dan semua logika. Bagaimana cara kerjanya untuk layanan pencarian lainnya?

Itu mengingatkan saya, Anda menyebutkan beberapa hari yang lalu bahwa Anda mempertimbangkan untuk menambahkan semua ID yang cocok ke indeks kemunculan.
Saya kira ada 2 versi yang mungkin:

• Menambahkan semua kandidat yang mungkin. Itu secara efektif mendorong beban ke UI atau pengguna. Dan spesimen yang sama akan muncul di bawah beberapa koleksi.
• Tambahkan tautan hanya jika kami memiliki satu kecocokan yang meyakinkan. Layanan bertanggung jawab atas pernyataan tersebut. Kami akan dapat mencocokkan lebih sedikit.

Saya lebih menyukai versi 2. Hanya menambahkan ID GrSciColl ke kejadian ketika kami memiliki 1 kecocokan yang meyakinkan. Bukan serangkaian kecocokan kandidat. Dan jika kami ingin lebih banyak kecocokan, maka kami meminta penerbit untuk menambahkan pengidentifikasi yang lebih baik ke GrSciColl atau kemunculannya. Atau kami menambahkan tag mesin ke set data untuk berjaga-jaga.

Jika berguna untuk membuat semua kandidat diindeks, dapatkah kita mempertimbangkan bidang terpisah untuk itu?

Haruskah Layanan mengembalikan bendera. PERTANDINGAN KODE KOLEKSI FUZZY. TIDAK ADA KECOCOKAN KODE KOLEKSI. Mirip dengan layanan pencocokan spesies.

Saya bisa memikirkan bendera ini:

• AMBIGUOUS_INSTITUTION : lebih dari 1 institusi ditemukan dan kami tidak dapat memutuskan hubungan
• AMBIGUOUS_COLLECTION : sama seperti di atas tapi untuk koleksi
• FUZZY_INSTITUTION_MATCH : 1 institusi cocok tapi tidak jelas
• FUZZY_COLLECTION_MATCH : sama seperti diatas tapi untuk koleksi
• INSTITUTION_NAME_USED : bidang institutionCode berisi nama institusi bukan kode
• OWNER_INSTITUTION_NAME_USED : sama seperti di atas tetapi untuk institusi pemilik
• COLLECTION_NAME_USED : sama seperti diatas tapi untuk koleksi
• NO_COLLECTION_CODE_MATCH : kode yang diberikan tidak cocok
• NO_INSTITUTION_CODE_MATCH : sama seperti diatas
• NO_COLLECTION_ID_MATCH : ID yang diberikan tidak cocok
• NO_INSTITUTION_ID_MATCH : sama seperti diatas
• INSTITUTION_COLLECTION_MISMATCH : koleksi yang ditemukan bukan milik institusi yang cocok

EDIT: yang INSTITUTION_NAME_USED mungkin dapat dihapus dan hanya menggunakan FUZZY_INSTITUTION_MATCH untuk kasus ini. Saya tidak tahu apa yang akan lebih berguna bagi penerbit

Saya menyukainya - menurut saya banyak penerbit menghargai bendera itu dan menindaklanjutinya. Ini akan memberi mereka wawasan untuk mengubah data dan meningkatkan pencocokan.

Layanan sekarang mengembalikan respons seperti:

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

Pencocokan alternatif hanya ditampilkan jika parameter verbose disetel ke true. Pencocokan fuzzy dibatasi hingga 20 hasil karena alasan kinerja.

Itu juga menambahkan parameter Country yang digunakan untuk memutuskan hubungan: http://api.gbif-dev.org/v1/grscicoll/lookup?institutionCode=BR&country=BE&verbose=true

Kecocokan terjadi jika salah satu dari kondisi ini terpenuhi:

• Hanya ada 1 pencocokan tag mesin
• Hanya ada 1 yang sama persis
• Ada beberapa pencocokan tepat tetapi hanya satu yang cocok dengan parameter negara yang diterima
• Hanya ada 1 pertandingan fuzzy
• Ada beberapa kecocokan fuzzy tetapi hanya satu yang cocok setidaknya dengan kode atau id dan satu bidang lagi (nama atau kode alternatif)
• Ada beberapa kecocokan fuzzy tetapi hanya satu yang cocok dengan parameter negara yang diterima

Selain itu, institusi yang pemilik institusinya berbeda dengan institusi tidak dianggap tandingan. Selain itu, koleksi yang lembaganya tidak cocok dengan lembaga yang diterima juga tidak dianggap cocok.

Saya belum menambahkan bendera tetapi bidang status sebagai gantinya:

• ACCEPTED : diterima cocok
• AMBIGUOUS : lebih dari 1 hasil ditemukan dan kami tidak dapat memutuskan hubungan
• AMBIGUOUS_MACHINE_TAGS : sama seperti di atas tetapi dengan tag mesin yang cocok
• AMBIGUOUS_OWNER : ada hasil tapi tidak cocok dengan pemilik institusi jadi kita skip agar tidak menautkan pada koleksi pinjaman
• AMBIGUOUS_INSTITUTION_MISMATCH : ada kecocokan fuzzy tetapi bukan milik institusi yang cocok
• DOUBTFUL : kecocokan yang ditemukan tidak jelas

Bendera lainnya dapat disimpulkan dari bidang pertandingan reasons . Masalah dapat diatur dari bidang ini dalam pipeline.

Saya telah mengekstrak dari data kami dalam kombinasi PROD dari bidang-bidang ini yang ada di lebih dari 1000 catatan:

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

Selain itu, saya mengambil negara dari organisasi penerbitan kumpulan data.

Kemudian saya meneruskannya ke layanan pencarian di UAT. Hasilnya ada di spreadhseet ini