Registry: Реализовать службу поиска для коллекций GrSciColl

Я добавил в DEV первую версию службы поиска коллекций (она по-прежнему не использует машинные теги), чтобы убедиться, что это то, что мы ожидали.

Он возвращает список совпадений учреждений и еще один для совпадений коллекций. Это список, потому что коды не уникальны, поэтому могут быть случаи, когда у нас может быть несколько вариантов, и мы не можем различать их по какому-либо другому полю.

Для каждого матча показывает:

• тип: это может быть exact или fuzzy . exact только в том случае, если совпадают и код, и идентификатор. В противном случае это fuzzy .
• примечания: это наблюдения, чтобы понять, как был проведен матч. Возможные значения:
  
  
  
  • CODE_MATCH : регистр не игнорируется
  
  
  • IDENTIFIER_MATCH : регистр не игнорируется
  
  
  • ALTERNATIVE_CODE_MATCH : регистр не игнорируется
  
  
  • NAME_MATCH : игнорирует регистр и удаляет диакритические знаки и пробелы, но не выполняет сопоставление префикса или суффикса.
  
  
  • PROBABLY_ON_LOAN : это происходит, когда организация-владелец и организация не совпадают
  
  
  • INST_COLL_MISMATCH : это происходит, когда учреждение коллекции не присутствует в соответствующих учреждениях.
  
  

Когда есть совпадения учреждений, коллекция нечетко совпадает только в том случае, если она принадлежит какому-либо из сопоставленных учреждений. Точные совпадения коллекций всегда будут возвращены.

Вы можете проверить эти примеры, чтобы увидеть, как работает сервис:

• http://api.gbif-dev.org/v1/grscicoll/lookup?collectionCode=herbarium возвращает 567 коллекций.
• http://api.gbif-dev.org/v1/grscicoll/lookup?collectionCode=herbarium&institutionCode=UNCA возвращает 1 учреждение и 1 коллекцию
• http://api.gbif-dev.org/v1/grscicoll/lookup?collectionCode=UNCA&institutionCode=UNCA&institutionId=gbif :ih: irn:240135 возвращает 1 учреждение и 2 коллекции
• http://api.gbif-dev.org/v1/grscicoll/lookup?collectionCode=UIMNH&collectionId=http://grbio.org/cool/zrdp-fspx&institutionCode=K является примером INST_COLL_MISMATCH
• http://api.gbif-dev.org/v1/grscicoll/lookup?ownerInstitutionCode=MBMC&institutionCode=K — это пример PROBABLY_ON_LOAN

Я что-то упустил @MortenHofft @timrobertson100 ?

Я добавил проверку тега машины в формате, который уже использовался в конвейерах :

• Пространство имен: processing.gbif.org
• Имена:
  
  
  
  • institutionCode : сопоставляет код учреждения с учреждением GrSciColl.
  
  
  • collectionCode : сопоставляет код коллекции с коллекцией GrSciColl.
  
  
  • collectionToInstitutionCode : сопоставляет код коллекции с учреждением GrSciColl. Я бы, наверное, переименовал его в collectionCodeToInstitution (подлежит уточнению).
  
  
  • institutionToCollectionCode : сопоставляет код учреждения с коллекцией GrSciColl. Я бы, наверное, переименовал его в institutionCodeToCollection (подлежит уточнению).
  
  

Значение тегов должно соответствовать шаблону {key}:{code} .

Выглядит хорошо - мне очень любопытно увидеть, как это применимо к реальным данным.

многословно или нет
Должны ли у нас быть «подробные» опции, как при сопоставлении видов?

Если мы представим, что кто-то, кроме персонала, использует это, может быть полезно просто иметь опцию match or none . Скажите Plazi, используя его для создания ссылок из кодов коллекций в статьях.

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

по именованию
API сопоставления видов использует matchType вместо type , а кластеры используют reasons вместо remarks .

Реальные данные
Прежде чем запускать его на реальных данных, мне интересно, стоит ли просто проверить 500 лучших различных комбинаций кода учреждения/идентификатора colectionCode/ID и вручную оценить некоторые из них? Мы могли бы чему-то научиться (скажем, нам нужно попытаться перевернуть идентификатор и код)

Что представляет собой матч?
Как вы думаете, когда это вызовет совпадение?

• Только точно?
• Нечеткий, но только один результат
• Точное учреждение, но только одна нечеткая коллекция?

Страна как средство устранения неоднозначности
Имеет ли смысл добавить страну в качестве параметра поиска? При индексировании вхождений мы могли бы добавить страну издателя, чтобы устранить неоднозначность, когда есть, например, 2 совпадения коллекций? Или это лучше сделать, если потребитель повторяет результаты?

Я просто попытался сопоставить на основе извлечения csv, которое у меня было некоторое время назад.
CSV отличается institutionId, institutionCode, datasetKey, publisherKey с количеством вхождений для каждого.

Я взял все, что содержит более 2500 вхождений, и попытался сопоставить их с сервисом.

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)

Это неплохое начало. Хотя я не оценивал качество матчей.

_Что представляет собой совпадение?_
Как вы думаете, когда это вызовет совпадение?

• Только точно?
• Нечеткий, но только один результат
• Точное учреждение, но только одна нечеткая коллекция?

Под этим вы имеете в виду неподробную версию, где мы показываем только 1 совпадение, верно?

Это может быть что-то вроде:

• Для учреждений
  
  
  
  • Только одно точное совпадение
  
  
  • Только одно нечеткое совпадение
  
  
• Для коллекций
  
  
  
  • Только одно точное совпадение
  
  
  • Если имело место совпадение учреждения, совпало только одно нечеткое совпадение, чье учреждение совпадает с учреждением.
  
  
  • Если не было совпадения учреждения, только одно нечеткое совпадение
  
  

Считаете ли вы, что мы должны также предоставить общий статус матча?

_Что представляет собой совпадение?_
Как вы думаете, когда это вызовет совпадение?

• Только точно?
• Нечеткий, но только один результат
• Точное учреждение, но только одна нечеткая коллекция?

Под этим вы имеете в виду неподробную версию, где мы показываем только 1 совпадение, верно?

Я имел в виду при использовании его в конвейерах для назначения идентификаторов GrSciColl для вхождений. Я представлял себе, что эта услуга включает в себя решение и всю логику. Как это работает для других поисковых сервисов?

Это напомнило мне, что вы упомянули на днях, что рассматривали возможность добавления всех совпадающих идентификаторов в индекс вхождений.
Я предполагаю, что есть 2 возможных версии:

• Добавление всех возможных кандидатов. Это эффективно возлагает нагрузку на пользовательский интерфейс или пользователя. И одни и те же экземпляры появлялись в нескольких коллекциях.
• Добавляйте ссылку только тогда, когда у нас есть одно достоверное совпадение. Служба берет на себя ответственность за заявление. Мы сможем соответствовать меньшему количеству.

Я больше за версию 2. Добавлять идентификатор GrSciColl к вхождению только тогда, когда у нас есть 1 достоверное совпадение. Не массив совпадений-кандидатов. И если мы хотим больше совпадений, мы обращаемся к издателям с просьбой добавить лучшие идентификаторы либо к GrSciColl, либо к вхождениям. Или мы добавляем машинные теги в наборы данных на всякий случай.

Если полезно индексировать всех кандидатов, можем ли мы рассмотреть для этого отдельное поле?

Должна ли служба возвращать флаги. НЕЧЕТКОЕ СОВПАДЕНИЕ КОДА КОЛЛЕКЦИИ. НЕТ СОВПАДЕНИЯ КОЛЛЕКЦИОННОГО КОДА. Подобно сервису подбора видов.

Я могу думать об этих флагах:

• AMBIGUOUS_INSTITUTION : было найдено более 1 учреждения, и мы не смогли решить ничьих
• AMBIGUOUS_COLLECTION : то же, что и выше, но для коллекций
• FUZZY_INSTITUTION_MATCH : 1 учреждение соответствует, но нечетко
• FUZZY_COLLECTION_MATCH : то же, что и выше, но для коллекций
• INSTITUTION_NAME_USED : поле institutionCode содержит название учреждения вместо кода
• OWNER_INSTITUTION_NAME_USED : то же, что и выше, но для учреждения-владельца
• COLLECTION_NAME_USED : то же, что и выше, но для коллекций.
• NO_COLLECTION_CODE_MATCH : предоставленный код не соответствует
• NO_INSTITUTION_CODE_MATCH : то же, что и выше
• NO_COLLECTION_ID_MATCH : предоставленный идентификатор не совпадает
• NO_INSTITUTION_ID_MATCH : то же, что и выше
• INSTITUTION_COLLECTION_MISMATCH : найденная коллекция не принадлежит совпадающему учреждению

РЕДАКТИРОВАТЬ: INSTITUTION_NAME_USED , возможно, можно удалить и просто использовать FUZZY_INSTITUTION_MATCH для этих случаев. Не знаю, что было бы полезнее для издателей

Мне это нравится — у меня сложилось впечатление, что многие издатели ценят эти флаги и действуют в соответствии с ними. Это даст им информацию для изменения данных и улучшения сопоставления.

Служба теперь возвращает ответ, например:

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

Альтернативные совпадения отображаются только в том случае, если для параметра verbose установлено значение true. Нечеткие совпадения ограничены 20 результатами из соображений производительности.

Также был добавлен параметр Country , используемый для разрыва связей: http://api.gbif-dev.org/v1/grscicoll/lookup?institutionCode=BR&country=BE&verbose=true

Совпадение происходит, если выполняется любое из этих условий:

• Совпадает только 1 тег машины
• Есть только 1 точное совпадение
• Имеется несколько точных совпадений, но только одно соответствует полученному параметру страны.
• Есть только 1 нечеткое совпадение
• Есть несколько нечетких совпадений, но только одно соответствует как минимум коду или идентификатору и еще одному полю (имя или альтернативный код)
• Есть несколько нечетких совпадений, но только одно соответствует полученному параметру страны.

Кроме того, учреждения, чей владелец отличается от учреждения, не считаются совпадающими. Кроме того, коллекции, учреждение которых не соответствует принятому учреждению, также не считаются соответствующими.

Я не добавил флаги, а вместо этого добавил поле статуса:

• ACCEPTED : совпадение принято
• AMBIGUOUS : было найдено более 1 результата, и мы не смогли разрешить ничью
• AMBIGUOUS_MACHINE_TAGS : то же, что и выше, но с совпадением тега машины
• AMBIGUOUS_OWNER : есть результаты, но они не совпадают с владельцем учреждения, поэтому мы пропускаем их, чтобы не связывать сборы по кредитам.
• AMBIGUOUS_INSTITUTION_MISMATCH : есть нечеткие совпадения, но они не принадлежат совпадающему учреждению
• DOUBTFUL : найденное совпадение нечеткое

Остальные флаги можно вывести из поля совпадения reasons . Проблемы могут быть установлены из этого поля в пайплайнах.

Я извлек из наших данных в PROD комбинации этих полей, которые присутствуют более чем в 1000 записях:

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

Кроме того, я взял страну из организации, опубликовавшей набор данных.

Затем я передал их службе поиска в UAT. Результаты в этой рассылке