Warning: Constant WP_MEMORY_LIMIT already defined in /home/elorenzo/domains/arvo.es/public_html/dspace/wp-config.php on line 94
Control de Autoridades | Hablando de DSpace

Archivos de Tags: Control de Autoridades

Adaptando a OpenAIRE 4 (I): Identificadores de autor

Incorpore Identificadores de autor en sus metadatos

Entre los objetivos de OpenAIRE v4.0 figura la búsqueda de una mayor precisión, mas allá de los nombres normalizados que planteaba DRIVER, sobre los agentes del sistema investigador. Para ello OpenAIRE propone el uso de esquemas de identificación (identifier schemes) para autores, organizaciones, agencias financiadoras, etc.

Por tanto el primer problema que debemos abordar es cómo incorporar a nuestro repositorio procesos de normalización de nombres de autor y asignación de identificadores de autor, preferiblemente ORCID iDs.

Nuestra propuesta es el uso de métodos de desambiguación de nombres y asignación de identificadores, embebidos en los procesos de ingesta de contenidos y revisión de la metadatación, preferiblemente mediante el uso de funciones de control de autoridades. Hay algunas instituciones que han optado por soluciones diferentes, todas valen en tanto logren hacer correctamente la correspondencia Nombre de autor <–> Identificador de autor (para todos las posibles fuentes de autoridad, añadiríamos)

Recuerde que es posible, aunque en algunos escenarios puede desaconsejarse, efectuar consultas sobre la API de ORCID, incorporando datos de identificación de autores no institucionales a su repositorio.

Igualmente, si tiene la posibilidad de identificar la institución u organización de los autores, puede considerar exponer ese dato.

Exposición en el interface OAI_PMH de los identificadores de autor

El uso de esquemas de identificación (identifier schemes) para autores, organizaciones, agencias financiadoras, etc. se realiza en OpenAIRE 4 mediante la exposición de los identificadores únicos, PIDS, (principalmente ORCID iDs e ISNI) en los elementos de autoría, y más específicamente en los elementos datacite:creator y datacite:contributor junto con sus atributos, affiliation, nameIdentifier, contributorType, nameIdentifierScheme y schemeURI

Dependiendo de la solución adoptada (ver epígrafe anterior) para almacenar las asociaciones Autor-Identificador, trasladar éstas a la interface OAI-PMH puede resultar mas o menos compleja y/o efectiva.

En la figura siguiente, el modelo autoridades-SOLR authority cache-SOLR OAI-PMH que usamos en nuestras implementaciones, intentando mostraros rla posible complejidad de dicha exposición.

Si todo está ensamblado, estaremos en condiciones de exponer la información de autores de forma compatible openAIRE 4. Una muestra de lo dicho:

<datacite:creator>

<datacite:creatorName>Gavilán Ceballos, Beatriz</datacite:creatorName>
<datacite:nameIdentifier schemeURI=»https://orcid.org» nameIdentifierScheme=»ORCID»>0000-0001-7515-1186</datacite:nameIdentifier>
<datacite:affiliation>Universidad de Huelva</datacite:affiliation>
</datacite:creator>

Por ahora, suficiente. Mas entregas en unos días

Métodos usados en el Authority Control

Una vez explicado en el post anterior el modelo de control de autoridades en DSpace, vamos a profundizar algo más en el authority control. En concreto os voy a comentar los aspectos más destacables que tiene la clase encargada de hacer funcionar el authority control.

SampleAuthority es el modelo de ejemplo que se usa para poder a empezar a desarrollar nuestra funcionalidad del modelo de autoridades. (Aunque lo más correcto es crear nuestra propia clase Autoridad copiando el SampleAuthority)

Esta clase la podemos localizar dentro del DSpace API en la siguiente ruta:[dspace-src]/dspace-api/src/main/java/org/dspace/content/authority/SampleAuthority.java

Esta clase tiene un aspecto como el siguiente (no se incluye todo el código)

public class SampleAuthority implements ChoiceAuthority{    

    public Choices getMatches(String field, String query, int collection, int start, int limit, String locale){
       
    }

    public Choices getBestMatch(String field, String text, int collection, String locale) {
    }

    public String getLabel(String field, String key, String locale) {
    }
}

Básicamente lo primero que vemos es que la clase ha de implementar al interfaz ChoiceAuthority, y en el nos toca programar sus tres métodos principales

getMatches: este método ha de retornar un listado con todas las coincidencias buscadas a partir de la búsqueda introducida por el usuario, por lo general serán apellidos. Es decir si el usuario busca autores por el apellido Nieto, este método debería de retornar todos los autores de la BBDD con el apellido Nieto;

  • Nieto Español, Juan
  • Nieto Caramés, Sergio
  • Española Nieto, Juana

getBestMatch: Este método está pensando en devolver el mejor resultado posible, es decir si antes buscábamos solo por el apellido para mostrar un listado de autores con apellido parecido, con este método hemos de aproximar el resultado a uno posible.
En cuyo caso de que el resultado sea único debemos de dar un grado de confianza del mas alto posible. (Por lo general con un valor de confianza UNDEFINED ha de ser suficiente)

Este método hay que implementarlo bien, puesto que cada vez que se introduzca un metadato controlado (que use Authority Control), DSpace va a ser el encargado de validarlo automáticamente. Es decir que nos sirve para automatizar las tareas de los usuarios administradores, pero mejor que lo hagamos de forma precisa.

getLabel: Este método ha de resolver el problema de nombramiento que tiene DSpace con los autores validados, ya que por definición, DSpace coge el valor clave de autoridad y lo muestra como nombre de autor, por lo que debemos con este método cambiar por un valor de autor que se asocie a ese identificador.

Una vez programada esta clase (compilada y desplegada) solo falta rellenar la configuración detallada en el fichero de configuración dspace.cfg para que se asocie el proceso a un metadato que queramos como por ejemplo el dc.contributor.author. (toda esta información viene detallada en la documentación de DSpace accesible desde el código fuente o desde su web ;D)

Bueno ahora solo toca entender bien las especificaciones que deseamos aplicar a nuestro modelo de autoridades y programarlo según esas espacificaciones.

Mucha suerte

Authority Control en DSpace

El Control de Autoridades o Authority Control es una de las piezas clave a disposición de los responsables de Repositorios Digitales para mejorar la calidad de contenidos y posibilitar la interoperabilidad entre repositorios.

Una autoridad es un conjunto de valores controlados para un dominio determinado, estando cada valor único identificado por una clave (clave de autoridad).

Un registro de autoridad es la información asociada con cada uno de los valores en una autoridad (incluyendo variaciones de deletreo, valores equivalentes y/o alternativos, etc).

Una clave de autoridad es un identificador opaco y persistente correspondiente a un registro de autoridad.

En la práctica habitual, un registro de autoridad (de nombres de autor, por ejemplo), contiene la forma autorizada del nombre del autor, establecida por la institución normalizadora como forma preferida para visualizar en sus sistemas, así como las formas variantes del nombre y nombres relacionados. Además, el registro de autoridad puede contener información relativa a la persona, representada por el punto de acceso), así como a las relaciones entre esa persona y otras entidades relacionadas, información para identificar las reglas de acuerdo con que se establecieron valores controlados, las fuentes consultadas, la agencia de catalogación encargada de establecer la normalización y la agencia responsable de establecer las formas preferidas del nombre.

Objetivos del Control de Autoridades

  • Dar consistencia e integridad a los metadatos
  • Conseguir mejorar la precisión en la recuperación de la información
  • Facilitar el intercambio de información bibliográfica

El modelo de authority control de DSPACE

El modelo de autoridades de Dspace aparece en la versión 1.6 de forma estándar, pues previamente era una pieza de código separada como add-on. La implementación en Dspace es de un framework que mediante configuración permite conectar (plug-in) clases programáticas para controlar dos aspectos básicos: Cómo se realiza la selección de valores en un metadato (choice management) y la inclusión de valores de autoridad asociados a los valores de metadatos (Authority Control).

Por tanto, no ofrece funcionalidad alguna para la gestión de las autoridades, de los registros de autoridad o de las claves de autoridad, que se consideran fuera del ámbito de DSpace y que por tanto se deberán gestionar mediante un aplicativo externo o bien desarrollos adicionales de DSpace.

Junto con el código que ofrece la funcionalidad de control de autoridades, se distribuyen con DSpace una serie de conectores con servicios de autoridades ya existentes, a modo demostrativo, como el Servicio de Nombres de la Biblioteca del Congreso (Library of Congress Names service) y el servicio de autoridades de nombres de revistas y editores Sherpa-Romeo, entre otros

Funcionalidades básicas del framework

  • Choice Management: En los elementos del Interfaz de usuario que se ocupan de la edición de metadatos (principalmente módulo de envíos para usuarios de autoarchivo u módulo de edición de metadatos para administradores) se pueden incluir funcionalidades que asisten en la selección de valores de los metadatos que se hayan configurado. Para dichos campos de metadatos se pueden generar listas de valores a partir de vocabularios extensos, navegación por tesauros jerárquicos, selección cerrada a los valores de una lista, lista abierta, …
  • Authority Control: El control de autoridades proporciona incluye la clave de autoridad junto con el valor del metadato seleccionado. Señalar que los metadatos controlados por autoridad deben llevar asociado el plugin Choice management. La información de autoridad consiste del valor del metadato, el valor de la clave de autoridad (authority key) y el denominado valor de confianza (confidence value), cuya utilidad explicaremos más adelante.
  • Visibilidad de las claves de autoridad y de los valores de confianza: En la interfaz OAI_PMH se expone únicamente el valor del metadato, (ya mencionamos antes la limitación del protocolo para exponer valores de autoridad) estando ocultos los valores de autoridad y de confianza (confidence value). Esto lo pongo alto y claro para evitar tentaciones: ES UNA MALA PRÁCTICA EXPONER LA CLAVE DE AUTORIDAD O EL VALOR DE CONFIANZA COMO METADATO, ESTOS VALORES SON EXCLUSIVOS DE DSPACE PARA SU CORRECTO FUNCIONAMIENTO.
  • Indices de autoridad:  Una característica normalmente poco conocida es la posibilidad de construir índices (browse o search indexes) que contengan sólo valores con clave de autoridad asociada. Así podemos tener un índice de autores y otro índice que incluya sólo autores validados. Además, la inclusión de un valor validado en este índice puede ser controlada mediante el valor de confianza (seguir leyendo..)
  • El valor de confianza (confidence value) se expresa como un valor simbólico dentro del rango siguiente: (aceptado, incierto, ambiguo, no encontrado, fallido) y puede asignarse adicionalmente al valor de clave de autoridad. A continuación, podemos especificar el nivel inferior de confianza que es necesario para incluir un valor de metadato en el índice construido, con lo que el índice así construido, incluirá los valores validados con ciertas condiciones, que sobrepasen ese nivel inferior (minimun confidence value).
  • Los registros de autoridad son externos a DSpace, es decir, DSpace no incluye ninguna funcionalidad para gestionarlos, depurarlos o ampliarlos, es decir, no incluye la posibilidad de añadir o asociar un valor adicional a un registro de autoridad ya existente. Típicamente es una base de datos de la institución, un proveedor externo, un servidor de vocabularios, etc… La arquitectura de plugins de DSpace permite integrar conectores a estos servicios de forma simple, sin tocar el código original de DSpace.

nota: este post es un extracto readaptado de la comunicación realizada por Sergio Nieto y Emilio Lorenzo en el congreso internacional Biredial 2013 celebrado en Costa Rica. Disponible aquí