Archivos de Tags: dspace

Versiones en DSpace

Nos preguntan en ocasiones qué significan los números de las versiones de Dspace. Vamos a intentar explicarlo:

Antes de 2012, las versiones se numeraban como 1.x, 1.6, 1.7 y 1.8.. Cada año aproximadamente se lograba terminar una versión nueva y se liberaba.  En ese momento, 2008 -2010,  se tenía en mente la version “definitiva”, DSpace 2. Todavía hay documentos indexados por google que hablan de esa versión.

Pero esa versión 2 nunca llegó, así que en 2013 se decidió comenzar un nuevo esquema de numeración de versiones en forma [major].[minor].  Dspace desde entonces se numera como 3.0 (la primera tras el cambio de criterio) 3.1, 3.2…. 4.0,  4.1. Nunca hubo una versión 2 de Dspace.

¿Y cómo se decide el [major].[minor]…?

Incrementar el primer número, [major], significa que estamos ante una versión principal de Dspace. Esta incluye: nuevas funcionalidades, cambio de arquitectura, mejoras del sistema y corrección de errores.  Así, las versiones 3.0, 4.0, 5.0, 6.0 y la próxima 7.0, suponen una evolución sustancial del software.  Evolucionar entre versiones, cambiando el primer número, supone por lo general un esfuerzo considerable para:

  • La comunidad de desarrolladores de Dspace, que intenta mantener un calendario de una [major] por año, aunque no siempre se consigue.
  • Los repositorios DSpace, las instalaciones propiamente dichas, que deben ejecutar procedimientos de migración de datos y código entre versiones, prueba de la nueva versión, formación en las nuevas funcionalidades, etc. Es decir, proyectos por lo general, complejos.

Dspace releases

Las versiones menores [minor] son las que incrementan el segundo número. Sólo incluyen parches y resolución de bugs (bugs fixes) de la versión principal. Así tenemos p.ej. 5.1, 5.2, 5.3, 5.4, 5.5 y 5.6 por ahora.  Moverse entre versiones menores es un proceso por lo general simple. Basta con (haciendo un backup) actualizar nuestra version en los directorios fuente, y desplegar. Por lo general es un proceso simple…(¡¡o al menos mucho mas simple que un cambio de versión mayor¡¡)

El compromiso de la comunidad Dpsace es proporcionar parches de seguridad a las tres últimas versiones mayores de Dspace.  Es decir si , ahora al escribir esto, mayo de 2017, hay una vulnerabilidad  detectada y se corrige con un parche, se emitiría una actualización, denominándose 4.8 , 5.7 y 6.1 que son los siguientes numeros [minor] que hay disponibles…… Sin embargo, la comunidad de desarrollo DSpace solo nos comprometemos a parches funcionales para la versión última (aunque a veces se aprovecha para meter algún parche a versiones mayores anteriores….)

DSpace versión 6

Bien, la versión 6 ya está aquí, se anunció su disponibilidad el 24 de octubre y ya está lista para ser instalada…

¿y qué nos trae de nuevo la versión 6? Pues unas cuantas funcionalidades y cambios:

  • Incorporación de Hibernate, herramienta de mapeo objeto-relacional, paso necesario para poder abordad la refactorización de la API de Dspace (estamos pensando en la versión 7). Si teníais código propio que accedía a la base de datos de Dspace, posiblemente tengas que reescribirlo…
  • Se mejora el sistema de configuración de Dspace, que ahora usa la sintaxis de Apache Commons Configurations. Las configuraciones de dspace.cfg pueden recargarse sin rearrancar el Tomcat, el fichero de configuración build.properties se ha cambiado por un local.cfg  y algunas mejoras más. Algunas mejoras, pero al ser un nuevo sistema pues hay que volver a aprender la forma de hacer despliegues…
  • Se ha retirado el soporte al sistema de acceso al almacenamiento (assetstore) basado en SRB (no habia constancia de que lo usasen muchas instalaciones). Para compensar, se ha añadido soporte al sistema Amazon S3.
  • Ya no se distribuye la interfaz LNI (poco o nulo uso).  Quedará no obstante como “add-on”
  • El motor de búsqueda basado en Lucene y los métodos de browse basados en base de datos desaparecen por completo del código (deprecated, en terminología de desarrollo de software). Ya se desaconsejaba su uso en la v4, si querías usarlo daba muchísimos problemas en la V5 y se ha finalizado eliminando estos elementos de código.
  • Tenemos unos nuevos informes, denominados Healthcheck (chequeo de salud) que revisan una serie de parámetros del repositorio y pueden enviar esos informes al administrador, por correo electrónico. Nos parece un avance sobre las posibilidades de comprobación existentes en versiones anteriores.
  • Es posible exportar los resultados de una búsqueda a CSV  (en XMLUI)
  • Hay un panel de control administrativo ampliado y configurable, las opciones del control panel, crecen y crecen….
  • Se anuncia el framework de importación de metadatos (aclaremos que realmente estaba  ya funcionando e incluso documentado extensamente en la versión 5) pero parece que hacen ahora el anuncio oficial. Será porque se aprovecha este framework para posibilitar la importación de metadataciones desde Pubmed, CrossRef, ScienceDirect, que insistimos, ya se podía hacer en la versión anterior….
  • La interface REST admite los mismos métodos de autenticación que las UI (hasta ahora solo se soportaba el login-password). Parece lógico, ¿verdad? sobre todo desde que se plantea para la próxima versión desagregar DSpace de las interfaces de usuario…
  • Aparece un sistema de chequeo de metadatos (REST metadata quality control) que permite interrogar via la interface REST sobre los valores de metadatos que tenemos en nuestros ítems..¡¡¡ muy curioso el funcionamiento !!! recomendable….
  • El operador de búsqueda de Discovery pasa a ser AND (el OR causaba más preguntas de la cuenta, pero realmente el cambio es mínimo, unas lineas en un fichero de configuración)
  • Se posibilita el indexado de documentos que se escriben de derecha a izquierda (RTL), como el árabe o el hebreo.
  • Se actualiza a PDfbox 2.0 y se incluye un nuevo generador de miniaturas de PDF (por lo que ya no es necesario el xpdf)

y seguro que me dejo algo….

Novedades Dspace en la conferencia Open Repositories 2016

La Conferencia Internacional de Repositorios Abiertos (11th International Conference on Open Repositories) se acaba de celebrar la semana pasada en Dublín. Al ser uno de los eventos principales en el mundo de los repositorios, pues no nos lo pudimos perder, pues concentra un gran número de novedades, presentaciones, proyectos, comunicaciones y  asistentes, de evidente interés.

Además, la Conferencia se aprovecha para la sesión plenaria de DuraSpace, en que la dirección rinde cuentas a los miembros de la organización, ver las diapositivas de la presentación y se anunció la nueva política de transparencia y apertura, openness, de DuraSpace.

Adicionalmente se celebraron los DSpace Interest Groups,  en que se actualiza el estado del proyecto. Tim Donohue, responsable técnico del proyecto DSpace, junto con un grupo de desarrolladores proporcionó una visión de la versión 6, del proyecto DSpace-CRIS y de la nueva interface de Dspace basada en Angular2.js. Ampliaremos estos temas en otro post.

Y no acabó ahí la conferencia, pues el jueves el DSpace Steering Group hizo una presentación sobre el Estado de Dspace, hablando sobre el modelo de gobernanza, la financiación, la membresía, el papel de los diversos grupos en el ecosistema DSpace  (DCAT, Registered Service Providers, Marketing Interest Group…) y la planificación o roadmap.

En cuanto a nosotros, pues la conferencia era un lugar ideal para presentar a una audiencia especializada el módulo OPRM que os hablamos en otro post. Y alli hablamos,  junto con Pandelis Perakakis, responsable del proyecto Open Peer Review, e Isabel Bernal, de digital.CSIC. Os mantendremos informados de novedades en este módulo.
IMAG1154

El soporte del estándar METS en DSpace

El estándar METS, Metadata Encoding and Transmission Standard, es una especificación XML que especifica los metadatos necesarios para la gestión de objetos digitales en un contexto digital así como para el intercambio entre sistemas de dichos objetos. METS se crea y diseña para proporcionar un formato relativamente simple de descripción de las actividades realizadas durante el ciclo de vida de un objeto digital.

Adicionalmente a la metadatación descriptiva interna, realizada habitualmente en Dublin Core Cualificado, el software Dspace incluye entre sus funcionalidades lo que se denomina un package disseminator and matching ingester adecuado para el tratamiento de determinados documentos METS.  La finalidad de este elemento es ayudar a los usuarios en la ingesta y exposición de los objetos DSpace usando el estándar METS.

DSpace tiene definidas pasarelas en formatos METS que usan el perfil de aplicación denominado, DspaceMETSSIPProfile,  en el que se han tomado las siguientes decisiones de diseño relevantes:

  • Los elementos de metadatación descriptiva se contemplan bajo un esquema MODS (Metadata Object Description Schema) aunque el formato METS acepta el encapsulado (wrapping) de otros esquemas, incluso coexistiendo en una única declaración.
  • Los elementos de metadatos técnicos que DSpace tiene definidos, sirven para sus propias necesidades de gestión del ciclo de vida y preservación de los objetos almacenados, lo que significa que no se contemplen objetos, eventos u agentes fuera de esas necesidades de gestión propias.  Mediante mapeo del  DSpace Content Object Model al modelo de objeto METS estos elementos se expresan usando el esquema de metadatos de preservación PREMIS. Es importante notar que el uso del PREMIS Data Dictionary no significa que DSpace soporte una implementación completa del modelo de datos PREMIS (p.ej. no usa las entidades de tipo evento)
  • Entre los elementos de metadatación administrativa, los correspondientes  derechos y autorías, si éstos son explícitos, se referencian, p.ej.  las licencias CC como rdf/xml, e incluyen en el manifiesto xml

Los creadores de este perfil METS, siguiendo criterios de simplicidad en la transferencia de información en los formatos SIP/DIP,  eran plenamente conscientes de la sobre-simplificación del mismo para una descripción completa de los AIPs:

Future use of this profile, or related profiles, to govern the creation of Archive Information Packages (AIPs) will require the inclusion of additional information to account for the larger information needs of AIPs.

Estas pasarelas o transformaciones se emplean en los siguientes ámbitos
Ingesta

  • El soporte de formatos empaquetados METS (conformes al perfil apuntado) está incluido en la herramienta de importación denominado packager
  • La interface SWORD también está adaptada para la ingesta de paquetes METS, haciendo uso del perfil especificado, mediante el plugin SWORDMETSIngester

Difusión:

  • El soporte de formatos empaquetados METS está incluido en la herramienta de exportación del packager
  • OAI-PMH, con metadataFormat METS
  • además, se expone en el interface XMLUI   (p.ej. añadiendo a la url de un item el /mets.xml)

Estas transformaciones exponen nada más que una historia parcial del ítem, no recogiendo todo el ciclo de vida de nuestro objeto digital, por otra parte desconocido para DSpace, ya que DspaceMETSSIPProfile es un perfil con objetivos diferentes de los requeridos habitualmente en los proyectos de digitalización como p.e.j:

  • Library of Congress METS Profile for Bibliographic Records
  • METS profile Biblioteca Virtual Patrimonio Bibliográfico del Ministerio de Educación y Cultura
  • METS Profile for Historical Newspapers (no registrado aún)

 

Conexión con los servicios de Creative Commons

En ocasiones, los servicios de Creative Commons se caen, o funcionan intermitentemente, lo que provoca que fallen los envíos de ítems a un repositorio con el paso de asignación de Licencias Creative Commons activado. Cuando los servicios de Creative Commons se recuperan, todo vuelve a la normalidad, pero hasta entonces, las aplicaciones como Dspace que hacen uso de la API de conexión dejan de funcionar correctamente.

Este tipo de errores se reconocen, en primer lugar, porque los envíos fallan en el paso de asignación de la Licencia Creative Commons. En este paso, la herramienta tarda un rato en cargar, y cuando finalmente lo hace, aparece un error similar al que puede verse a continuación:

error java stacktrace

que ya nos dice que el paso CCLiecenseStep está dando problemas, si además explosionamos el error pulsando sobre el enlace [show] que aparece situado al lado del apartado Java stacktrace,  veríamos, dependiendo n una de las líneas del error puede leerse algo así:

org.dspace.app.xmlui.aspect.submission.submit.CCLicenseStep.addBody(CCLicenseStep.java:121)

La solución no está en nuestras manos (a no ser que desactivemos el paso CCLicenseStep con un nuevo item-submission.xml o ideemos alguna otra solución de código imaginativa) y solo restará esperar un tiempo hasta que los servicios de Creative Commons se restablezcan.  (Bueno existe una posibilidad más siniestra,  como que hayamos perdido la conectividad por el puerto 80 o circunstancias similares…)

En todo caso, resulta interesante saber que Creative Commons ofrece a los usuarios información sobre el estado de sus servicios en la página http://status.creativecommons.org/. Cuando alguno de ellos falla, se muestra un mensaje de aviso similar al siguiente, lo que permite seguir su evolución:

status creative commons

Asimismo, en el momento en el que los servicios de Creative Commons se encuentren de nuevo operativos, la consulta directa a su API (http://api.creativecommons.org/rest/1.5) dejará de indicar que no puede establecerse la conexión:

api cc ko

y pasará a mostrar una página con el texto “not found”, que no debe confundirse con un error, similar a la siguiente:

api cc ok

Y solo falta desear que los servicios que ofreces esta organización se restablezcan pronto.

Liberada la versión 5 de DSpace

El 21 de enero de 2015 se produjo la liberación de Dspace v5.0, tras un proceso de desarrollo que arrancó hace un año, y que tuvo su pre-versión el pasado 3 de noviembre cuando comenzó el Testhaton.

Señalaríamos que incorpora una larga lista de pequeñas correcciones, pero que su característica principal son las funcionalidades añadidas (por eso es una versión, claro..) y que pasamos a revisar rápidamente:

El tema Mirage2 para XMLUI.  Bien, qué quéreis que os digamos, no es exactamente una novedad, pero es una excleente noticia su incorporación a la versión 5. El tema Mirage2 de @tmire nos gustó según lo vimos en su presentación “oficial” en el Open Repositories de Helsinki en junio de 2014. Tanto nos sedujo que lo empezamos a implantar en versiones 4 de inmediato y ya llevamos varias.

Actualización automática de datos en las migraciones a la versión 5. Simplifica la ejecución de los scripts de actualización de los esquemas de BBDD y migra los índices SOLR.  Es un avance sobre el ¿proceso? artesanal actual de migración. No se si lo pondríamos en una lista de nuestras prioridades, pero bienvenida la simplificación.

Importación de SIPs desde el interface de usuario. Pschee, la parte más compleja de una importación no es la ejecución del comando desde la UI o desde el CLI, sino la propia creación del paquete.

REST API con CRUD (Create/Read/Update/Delete). Esto ya está mejor, sobre todo porque estabilizará  el paisaje de proliferación de interfaces REST que había por el universo DSPaciero. Recordemos que aunque otras interfaces REST (la de Hedtek, p.ej.)  ya posibilitaban el Create/read/update,  lo que se necesitaba , y así se discutió en DCAT y otros foros de desarrollo, era la continuidad de las soluciones adoptadas. La api usada es la JAX-RS: Java API for RESTful Web Services.

Todos los DSpaceObjects con soporte de metadatos. Esto es interesante. Esta extensión es la que posibilitará (posibilitará, porque la interface de usuario aún no se ha extendido para poder gestionar el nuevo modelo)  flexibilizar la infraestructura de metadatos, que hasta ahora era aplicable sólo a los ítems, a las Comunidades, colecciones, e-persons, grupos, …

Soporte Linked (Open) Data mediante una interface RDF. A partir de esta versión se podrán publicar contenidos del repositorio en forma de Linked Open Data. No obstante, no todo es tan sencillo, pues la instalación de Dspace hay que complementarla con otra webapp, un Triple Store, es decir una base de datos que almacene de forma nativa el modelo RDF. El sistema, puede servir Apache Fuseki, debe soportar SPARQL 1.1 Query Language y  SPARQL 1.1 Graph Store HTTP Protocol.

Las estadisticas de Google Analytics ahora recogen las descargas de bitstreams (p.ej, las que vienen directamente de Google Scholar y que antes no se recogían como eventos) y se pueden visualizar (al menos si se usa Mirage2)

Se ha realizado una primera integración con los identificadores ORCID mediante la generación de un nuevo índice SOLR de autoridades. La clave de autoridad enlaza ahora con metadatos adicionales, entre los que se incluyen el identificador ORCID y nombres alternativos de autor. Esto sólo funciona en XMLUI, y bien, resuelve problemas de identificación de autores a las organizaciones que usan este identificador, pero no es la integración con las ORCID_API que estábamos esperando.

Y más mejoras, como la Creación de Thumbnails con ImageMagick / Ghostscript; la Autogeneración de páginas de cubierta PDF en la descarga de los objetos, la función lookup sobre SHERPA/RoMEO y alguna funcionalidad adicional, las puedes ver aquí.

 

Open repositories 2014

Ya han pasado unas semanas desde la conferencia Open Repositories 2014. Decir que la OR2014, este año en Helsinki con cerca de 500 delegados en esta edición, es posiblemente el evento más importante del calendario del Acceso Abierto, con énfasis en las realizaciones prácticas y planteamientos tecnológicos.

Este año fuimos uno de los  patrocinadores de la conferencia, y ante todo, queríamos dar las gracias a los organizadores (la National Library de Finlandia) por la excelente hospitalidad recibida. 

IMG_20140610_154710

Comentaríamos que se presentaron muchos proyectos e iniciativas relacionados con la preservación (Hydra, Dryad..) los repositorios (DSpace, ePrints, Fedora, Islandora e Invenio) y las plataformas de servicios (Figshare, OpenRepository, DuraCloud, DspaceDirect, eudat…), pero ¿qué hay de nuevo en el ámbito de Dspace?  (recordemos que se aprovecha la celebración de OR2014 para realizar el DSpace Interest/User Group Meeting). 

De nuestro particular interés,  reseñaríamos:

  • el interés en los estándares de indentificación común, como ORCID, y se plantea su integración en el core de DSpace 5.
  • El desarrollo de funcionalidades de interoperabilidad entre plataformas, como determinadas integraciones con PubMed o WoS
  • Las nuevas interfaces adaptativas disponibles tanto en XMLUI (Mirage 2) como en JSPUI
  • las adaptaciones de compatibilidad OpenAire
  • el nuevo modelo de gobernanza de Dspace
  • y…

Las presentaciones del OR2014 podeis verlas aquí (todavía están subiendo algunas…..)  y  grabaciones del martes, miércoles y jueves,  de las sesiones de la conferencia aqui

 

 

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í

Interfaz OAI en DSpace 3.x

En la versión 3 de DSpace se ha incluido una nueva Interfaz OAI-PMH que, además de facilitar la adecuación del Repositorio a los aspectos derivados de la recolección, puede simplificarnos la compatibilidad con las Directrices DRIVER y OpenAIRE.

Hasta ahora, se podía interrogar a un Repositorio mediante el uso de comandos OAI-PMH, emitidos desde cualquier navegador (al fin y al cabo el protocolo PMH se apoya en http) puesto que la mayoría de ellos están incluyen el soporte para que sus contenidos sean recolectados por los agregadores vía este Protocolo.

Considerando el caso habitual de que el OAI esté desplegado en el directorio [webapps]/OAI/ de DSpace, las consultas OAI-PMH son de la forma:

URL base de la instancia DSPACE/oai/request?verb=Xxxxx

Siendo Xxxxxx  los verbos utilizados para las consultas OAI-PMH, cada uno de ellos con una serie de atributos y modificadores, y cuya sintaxis se describe en el documento del estándar del Protocolo (http://www.openarchives.org/OAI/openarchivesprotocol.html#ProtocolMessages), los siguientes:

Identify, ListRecords, ListSets, ListMetadataFormats, ListIdentifiers y GetRecord.

A partir de la versión 3 de DSpace, se ha añadido una hoha de estilos que posibiliat realizar las anteriores consultas utilizando una Interfaz gráfica, que facilita sobremanera dicha tarea.

Clipboard02Además, la nueva versión, ha integrado una nuevas librerías OAI (xOAI, que sustituye al código OAI usado en anteriores versiones, originario de OCLC) que posibilitan la implementación de diferentes Interfaces OAI para cada uno de las necesidades de sets virtuales que requiera el Repositorio, de acuerdo con sus requerimientos en materia de metadatos, facilitando la creación de estos sets virtuales, mediante operaciones de filtrado y la transformación. Esto es de gran utilidad para el cumplimiento de Directrices como DRIVER y OpenAIRE.

Las Interfaces DRIVER y OpenAIRE, se muestran realizando las siguientes consultas, respectivamente:

URL base de la instancia DSPACE/oai/driver?verb=Identify
URL base de la instancia DSPACE/oai/openaire?verb=Identify

Básicamente, se ha realizado una reforma completa, realizada por la empresa portuguesa Lyncode,  que podría considerarse una evolución natural del Addon OAI-Extended (puesto que los compañeros de Lyncode provienen de una amplia experiencia desde la empresa KeepSolutions y desde Repositorium de la Universidade do Minho)  basándose en un framework OAI mejorado.