Registry: Implementar un servicio de búsqueda de colecciones GrSciColl

Puse en DEV una primera versión del servicio de búsqueda de colecciones (todavía no usa las etiquetas de la máquina) para ver si esto es lo que esperábamos.

Devuelve una lista de coincidencias de institución y otra de coincidencias de colección. Es una lista porque los códigos no son únicos, por lo que puede haber casos en los que podamos tener múltiples opciones y no podamos discriminar por ningún otro campo.

Para cada partido muestra:

• tipo: puede ser exact o fuzzy . exact es solo si tanto el código como el identificador coinciden. De lo contrario, es fuzzy .
• observaciones: son observaciones para entender cómo se hizo el partido. Los valores posibles son:
  
  
  
  • CODE_MATCH : no ignora el caso
  
  
  • IDENTIFIER_MATCH : no ignora el caso
  
  
  • ALTERNATIVE_CODE_MATCH : no ignora el caso
  
  
  • NAME_MATCH : ignora mayúsculas y minúsculas y elimina acentos y espacios en blanco, pero no hace coincidencias de prefijos o sufijos
  
  
  • PROBABLY_ON_LOAN : sucede cuando la institución propietaria y la institución no son la misma
  
  
  • INST_COLL_MISMATCH : ocurre cuando la institución de una colección no está presente en las instituciones emparejadas.
  
  

Cuando hay coincidencias de instituciones, una colección solo coincide de forma aproximada si pertenece a alguna de las instituciones coincidentes. Siempre se devolverán las coincidencias exactas de la colección.

Puedes consultar estos ejemplos para ver cómo funciona el servicio:

• http://api.gbif-dev.org/v1/grscicoll/lookup?collectionCode=herbarium devuelve 567 colecciones
• http://api.gbif-dev.org/v1/grscicoll/lookup?collectionCode=herbarium&institutionCode=UNCA devuelve 1 institución y 1 colección
• http://api.gbif-dev.org/v1/grscicoll/lookup?collectionCode=UNCA&institutionCode=UNCA&institutionId=gbif :ih: irn:240135 devuelve 1 institución y 2 colecciones
• http://api.gbif-dev.org/v1/grscicoll/lookup?collectionCode=UIMNH&collectionId=http ://grbio.org/cool/zrdp-fspx&institutionCode=K es un ejemplo de INST_COLL_MISMATCH
• http://api.gbif-dev.org/v1/grscicoll/lookup?ownerInstitutionCode=MBMC&institutionCode=K es un ejemplo de PROBABLY_ON_LOAN

¿Me estoy perdiendo algo @MortenHofft @timrobertson100 ?

Agregué la verificación de la etiqueta de la máquina siguiendo el formato que ya se usó en las canalizaciones por ahora:

• Espacio de nombres: processing.gbif.org
• nombres:
  
  
  
  • institutionCode : asigna un código de institución a una institución GrSciColl
  
  
  • collectionCode : asigna un código de colección a una colección GrSciColl
  
  
  • collectionToInstitutionCode : asigna un código de colección a una institución GrSciColl. Probablemente le cambiaría el nombre a collectionCodeToInstitution (TBD).
  
  
  • institutionToCollectionCode : asigna un código de institución a una colección GrSciColl. Probablemente le cambiaría el nombre a institutionCodeToCollection (TBD).
  
  

El valor de las etiquetas debe seguir el patrón {key}:{code} .

Se ve bien, tengo mucha curiosidad por verlo aplicado a datos reales.

detallado o no
¿Deberíamos tener una opción "detallada" como en la coincidencia de especies?

Si imaginamos que alguien más que el personal use esto, podría ser útil tener solo una opción match or none . Di Plazi usándolo para crear enlaces a partir de códigos de colección en artículos.

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

al nombrar
la API de coincidencia de especies usa matchType en lugar de type y los clústeres usan reasons en lugar de remarks .

Datos reales
Antes de ejecutarlo con datos reales, me pregunto si valdría la pena simplemente verificar las 500 combinaciones distintas principales de código de institución/código de colección de identificación/ID y evaluar manualmente algunas de ellas. Podríamos aprender algo (digamos que debemos tratar de cambiar la identificación y el código)

¿Qué constituye un partido?
¿Cuándo crees que esto desencadenará un partido?

• Exacto solo?
• Borroso pero solo un resultado
• ¿Institución exacta, pero solo una colección borrosa?

El país como desambiguador
¿Tendría sentido agregar el país como parámetro de búsqueda? Al indexar ocurrencias, ¿podríamos agregar el país del editor para eliminar la ambigüedad cuando hay, por ejemplo, 2 coincidencias de colección? ¿O es mejor que el consumidor lo haga iterando los resultados?

Solo traté de hacer coincidir según un extracto csv que tenía hace algún tiempo.
El csv es distinto institutionId, institutionCode, datasetKey, publisherKey con un recuento de ocurrencias para cada uno.

Tomé cualquier cosa con más de 2500 ocurrencias y traté de compararlas con el servicio.

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)

Eso no es un mal comienzo. Sin embargo, no he evaluado la calidad de los partidos.

_¿Qué constituye un partido?_
¿Cuándo crees que esto desencadenará un partido?

• Exacto solo?
• Borroso pero solo un resultado
• ¿Institución exacta, pero solo una colección borrosa?

Para esto te refieres a la versión no detallada donde mostramos solo 1 coincidencia, ¿verdad?

Podría ser algo como:

• Para instituciones
  
  
  
  • Solo una coincidencia exacta
  
  
  • Solo una coincidencia aproximada
  
  
• para colecciones
  
  
  
  • Solo una coincidencia exacta
  
  
  • Si hubo una coincidencia de institución, solo una coincidencia aproximada cuya institución es la misma que la institución emparejada
  
  
  • Si no hubo una coincidencia institucional, solo una coincidencia aproximada
  
  

¿Crees que también deberíamos proporcionar un estado de coincidencia general?

_¿Qué constituye un partido?_
¿Cuándo crees que esto desencadenará un partido?

• Exacto solo?
• Borroso pero solo un resultado
• ¿Institución exacta, pero solo una colección borrosa?

Para esto te refieres a la versión no detallada donde mostramos solo 1 coincidencia, ¿verdad?

Quise decir cuando lo usé en canalizaciones para asignar ID de GrSciColl a ocurrencias. Me había imaginado que este servicio incluía la decisión y toda la lógica. ¿Cómo funciona para otros servicios de búsqueda?

Eso me recuerda, usted mencionó el otro día que consideró agregar todas las identificaciones coincidentes al índice de ocurrencia.
Supongo que hay 2 versiones posibles:

• Agregar todos los posibles candidatos. Eso empuja efectivamente la carga a la interfaz de usuario o al usuario. Y los mismos especímenes aparecerían en múltiples colecciones.
• Solo agregue un enlace cuando tengamos una coincidencia segura. El servicio asume la responsabilidad de la declaración. Podremos coincidir con menos.

Estoy más a favor de la versión 2. Solo se agrega una ID de GrSciColl a una ocurrencia cuando tenemos 1 coincidencia segura. No es una serie de coincidencias candidatas. Y si queremos más coincidencias, nos dirigimos a los editores para que agreguen mejores identificadores a GrSciColl oa las ocurrencias. O agregamos etiquetas de máquina a los conjuntos de datos por si acaso.

Si es útil tener todos los candidatos indexados, ¿podríamos entonces considerar un campo separado para ello?

En caso de que el servicio devuelva banderas. COINCIDENCIA DEL CÓDIGO DE LA COLECCIÓN FUZZY. NINGÚN CÓDIGO DE COLECCIÓN COINCIDE. Similar al servicio de coincidencia de especies.

Puedo pensar en estas banderas:

• AMBIGUOUS_INSTITUTION : se encontró más de 1 institución y no pudimos desempatar
• AMBIGUOUS_COLLECTION : igual que arriba pero para colecciones
• FUZZY_INSTITUTION_MATCH : 1 institución coincidente pero de forma confusa
• FUZZY_COLLECTION_MATCH : igual que arriba pero para colecciones
• INSTITUTION_NAME_USED : el campo institutionCode contiene el nombre de la institución en lugar del código
• OWNER_INSTITUTION_NAME_USED : igual que arriba pero para la institución propietaria
• COLLECTION_NAME_USED : igual que arriba pero para colecciones
• NO_COLLECTION_CODE_MATCH : el código proporcionado no coincide
• NO_INSTITUTION_CODE_MATCH : igual que arriba
• NO_COLLECTION_ID_MATCH : el ID proporcionado no coincide
• NO_INSTITUTION_ID_MATCH : igual que arriba
• INSTITUTION_COLLECTION_MISMATCH : la colección encontrada no pertenece a la institución emparejada

EDITAR: los INSTITUTION_NAME_USED tal vez se puedan quitar y solo usar los FUZZY_INSTITUTION_MATCH para estos casos. No sé qué sería más útil para los editores.

Me gusta: tengo la impresión de que muchos editores aprecian esas banderas y actúan en consecuencia. Esto les dará los conocimientos necesarios para modificar los datos y mejorar la coincidencia.

El servicio ahora devuelve una respuesta como:

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

Las coincidencias alternativas solo se muestran si el parámetro verbose se establece en verdadero. Las coincidencias aproximadas están limitadas a 20 resultados por motivos de rendimiento.

También se agregó un parámetro Country que se usa para desempatar: http://api.gbif-dev.org/v1/grscicoll/lookup?institutionCode=BR&country=BE&verbose=true

Se produce una coincidencia si se cumple alguna de estas condiciones:

• Solo hay 1 coincidencia de etiqueta de máquina
• Solo hay 1 coincidencia exacta
• Hay varias coincidencias exactas, pero solo una coincide con el parámetro de país recibido
• Solo hay 1 coincidencia aproximada
• Hay varias coincidencias aproximadas, pero solo una coincide al menos con el código o la identificación y un campo más (nombre o código alternativo)
• Hay varias coincidencias aproximadas, pero solo una coincide con el parámetro de país recibido

Además, las instituciones cuya institución propietaria es diferente a la institución no se consideran coincidencia. Además, las colecciones cuya institución no coincide con la coincidencia aceptada por la institución tampoco se consideran una coincidencia.

No he agregado las banderas sino un campo de estado en su lugar:

• ACCEPTED : coincidencia aceptada
• AMBIGUOUS : se encontró más de 1 resultado y no pudimos desempatar
• AMBIGUOUS_MACHINE_TAGS : igual que arriba pero con coincidencias de etiqueta de máquina
• AMBIGUOUS_OWNER : hay resultados pero no coinciden con el propietario de la institución, por lo que los omitimos para no vincularlos a las cobranzas de préstamos
• AMBIGUOUS_INSTITUTION_MISMATCH : hay coincidencias parciales pero no pertenecen a la institución coincidente
• DOUBTFUL : la coincidencia encontrada es borrosa

El resto de las banderas se pueden inferir del campo reasons de la coincidencia. Los problemas se pueden configurar desde este campo en las canalizaciones.

He extraído de nuestros datos en PROD combinaciones de estos campos que están presentes en más de 1000 registros:

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

Además, tomé el país de la organización de publicación del conjunto de datos.

Luego los pasé al servicio de búsqueda en UAT. Los resultados están en esta hoja de cálculo.