Archivos de Tags: dspace - Paginas 2

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.

Arvo Consultores en Biredial 2013

Este año Arvo Consultores también asistió a Biredial 2013 en la cita de Costa Rica. Hasta ahí viajó Sergio Nieto, para impartir un taller sobre el Control de autoridades en DSpace, en el cual explicamos el porqué de esta funcionalidad authority control, las particularidades de su implantación en DSpace y los consejos y recomendaciones para su implantación exitosa.

IMG-20131017-WA0001

En el evento, agradecer a Meilyn Garro y al resto del comité organizador de la Universidad de Costa Rica la bienvenida que nos brindaron. Esperamos la programación de Biredial 2014 y que según parece puede que se realice en Brasil… eso el tiempo nos lo dirá.

Para mas información sobre lo que ocurrió en el evento, programa y demás no dejen de consultar la siguiente página de Biredial   http://biredial2013.ucr.ac.cr/index.php/Biredial2013/ai

Si desean ver las fotos de los participantes al evento en facebook:

https://www.facebook.com/media/set/?set=a.682451368454664.1073741828.136503766382763&type=3

Exprimiendo el interface XMLUI

Ya hemos explicado en otro post las diferencias entre  XMLUI  y JSPUI, dando unas pinceladas sobre el funcionamiento de XMLUI. Nuestra inclinación es más o menos clara, preferimos XMLUI:  permite aplicar  apariencias  diferentes a distintas colecciones, nos parece que separa mejor la lógica de negocio de la lógica de representación, etc …

Pues en este post daremos algunos comandos para acceder a alguno de los puntos intermedios de la cadena cocoon de transformación y que nos podrían ayudar en nuestros procesos de desarrollo y debugging.

Intentaremos (si no nos borran nuestro ejemplo) trabajar con este item http://demo.dspace.org/xmlui/handle/10673/590 (si no funciona, usar cualquier otra URL de un Dspace/XMLUI)

DRI
Para obtener el DRI subyacente debajo de esa URL, tenemos que escribir DRI/
después del path xmlui/
http://demo.dspace.org/xmlui/DRI/handle/10673/590

XML
Para obtener el XML de dicha URL, teclear:
http://demo.dspace.org/xmlui/handle/10673/590?XML
fijaros en todas las etiquetas i18n, es decir estamos antes de aplicar la transformación i18n

Idioma, i18n
Para forzar la aplicación de un idioma (sin tener que cambiar el idioma del navegador)

http://demo.dspace.org/xmlui/handle/10673/590?locale-attribute=es

http://demo.dspace.org/xmlui/handle/10673/590?locale-attribute=en

Tema
A la hora de elegir el tema o «theme» que queremos para nuestra instancia de DSpace es bastante engorroso indicar cuál queremos que sea visualizado editando el fichero [dir_instalación]/config/sitemap.xconf en sus últimas líneas…
Existe un parámetro, en el fichero de configuración dspace.cfg llamado:

xmlui.theme.allowoverrides

y si lo descomentamos y lo activamos a true podremos, podemos forzar (momentáneamente) el uso de los temas que tengamos definidos en nuestro directorio de Themes

http://demo.dspace.org/xmlui/handle/10673/590?themepath=Classic/

http://demo.dspace.org/xmlui/handle/10673/590?themepath=Reference/

Como es de suponer, si vais haciendo esto por los Dspace/xmlui de por ahí os encontrareis que niguno cambia, porque por defecto este parámetro va desactivado en el dspace.cfg. Solo lo recomendamos activar en procesos de depuración de Temas.

Mets
Y si eres de los que enredan con las XSL, esta es la URL necesaria para arrancar tus desarrollos:
http://demo.dspace.org/xmlui/metadata/handle/10673/590/mets.xml

Un saludo

Envíos basados en tipologías en DSpace 3.x

Una de las novedades que incorpora la versión 3 de DSpace, es la personalización de los envíos de ítems en función del tipo de contenido que se está enviando. Existía un parche en Jira_Dspace, el DS-464, Item type based submission, pero ha habido que esperar hasta la versión 3.0 para verlo incluido en el código estándar.

Esta función soluciona la necesidad de muchos Repositorios de adaptar sus formularios de envío a los diversos tipos de objetos que contienen, y cuya única solución, hasta el momento, consistía en definir Colecciones diferenciadas, cada una con un <form> específico.

En la nueva versión de DSpace, se pueden incorporar restricciones a la visualización en los campos del formulario de envío de ítems al Repositorio, dependiendo por ejemplo, de determinadas características de los objetos que se están describiendo. Ahora, un determinado campo se puede hacer visible dependiendo del valor que tome el metadato dc.type señalado previamente. Esto se consigue con la introducción de un nuevo elemento, <type-bind>, en la definición de los <field> del fichero input-forms.xml cuya visualización desea restringirse en ciertos casos.

A continuación se muestra, a modo de ejemplo, un extracto de la configuración del fichero input-forms.xml, en la que el <field> “Editor” sólo será visible si previamente en el <field> “Tipo” (dc.type), se ha introducido el valor «article».

<field>
   <dc-schema>dc</dc-schema>
   <dc-element>publisher</dc-element>
   <dc-qualifier></dc-qualifier>
   <label>Editor</label>
   <type-bind>article</type-bind>
</field>

En este otro ejemplo, el <field> “ISSN” sólo será visible si previamente en el <field> “Tipo” (dc.type), se han introducido los valores «bookPart» o «doctoralThesis».

<field>
   <dc-schema>dc</dc-schema>
   <dc-element>identifier</dc-element>
   <dc-qualifier>issn</dc-qualifier>
   <label>ISSN</label>
   <type-bind>bookPart,doctoralThesis</type-bind>
</field>

NOTA: Para que esta funcionalidad esté operativa, el elemento <type-bind> debe estar definido en el input-forms.dtd de la instalación DSpace.

El registro de formatos

DSpace admite bitstreams en una diversidad de formatos (formato: forma particular en que una información se codifica en un fichero o medio digital). La concepción inicial de Dspace se realizó con una política amplia respecto de los formatos: reconocer y soportar la mayor cantidad de formatos posibles, aunque la naturaleza propietaria de muchos formatos hace dificil garantizar lo anterior.

Administrar correctamente los formatos admitidos (en parte, mediante el registro de formatos), tal y como hablábamos en un post anterior, es una de las tareas claves de la preservación digital.
Cuando se sube un fichero a DSpace, dependiendo del formato inferido de la extensión del mismo, se le asignará uno de los tres niveles de soporte siguientes:

  • Soportado (Supported). Se reconoce y soporta completamente el formato. El administrador de Dspace lo mantendrá legible en el futuro, usando las técnicas que en cada momento considere más convenientes (conversión, migración, emulación…)
  • Conocido (Known): el formato está declarado como reconocible en el registro, pero el administrador del repositorio no puede garantizar o no ha tomado aún una decisión sobre un soporte pleno a efectos de preservación. Este podía ser el caso de formatos propietarios, pero de muy amplia difusión, (como los de Microsoft, p.ej)
  • No soportado (Unknown): el formato no está en la lista de reconocimiento de DSpace; esos ficheros aparecerán con listados como «application/octet-stream», or «Unknown»

Con el nivel de soporte, estamos haciendo una declaración sobre su uso futuro, y es responsabilidad del administrador seleccionar qué  formatos aceptará y qué servicios de evolución de los mismos se requieren para satisfacer las necesidades de los usuarios con el mejor contexto de preservación posible.

El directorio ../[dspace_inst]/config/registries contiene tres ficheros XML. El de nuestro interés es el bitstream-formats.xml. En el arranque inicial del sistema, el ant fresh_install realiza una carga inicial de dicho fichero en la BBDD.

Nota: Cualquier cambio posterior que se realice con la UI, no actualiza el fichero xml. Si efectuamos posteriormente una carga del fichero, mediante el comando registry-loader, es decir :

..\dspace_inst*\bin\dspace registry-loader bitstream-formats.xml

pues se perderán aquellos cambios que hubíesemos realizado mediante la interfaz de usuario. Lo cual es importante porque en algunos procesos de actualización de versiones (p.ej 1.7 a 1.8) hay que ejecutar este comando desde la CLI.

Los contenidos del registro de formatos de bitstreams son responsabilidad del administrador del repositorio, aunque Dspace obliga a que al menos los formatos «unknown» y «license» estén definidos. Una entrada típica de un formato definido en este registro es de la forma:

entrada <bitstream-type> del bitstream-formats.xml

<bitstream-type>
<mimetype>application/vnd.sun.xml.draw</mimetype>
<short_description>Draw 6.0 documents</short_description>
<description>Draw 6.0 documents</description>
<support_level>1</support_level>
<internal>false</internal>
<extension>sxd</extension>
</bitstream-type>

 

Ejemplo Descripción
<mimetype> application/vnd.sun.xml.draw Identificador de tipo MIME (Multipurpose Internet Mail Extensions)
<short_description> Draw 6.0 documents El nombre de formato más usual de este formato
<description> Draw 6.0 documents id
<support_level> 1 Nivel de soporte Dspace de este formato, codificado como:0= Desconocido, unknown

1 = Conocido, known

2 = Soportado, supported

<internal> false Los formatos marcados como «internal», es decir, este campo a true, se usan por el sistema, y no se representan a los usuarios
<extension> sxd Extensión habitual de filename, la parte tras el «.» del nombre completo del fichero

Administradores de Colección y Comunidad

En los repositorios digitales mayores o con estructuras de colecciones y comunidades amplias, la administración puede delegarse en los Administradores de Comunidad y Administradores de Colección. Estos usuarios (en realidad son e-grupos) pueden selecionar los revisores o editores en los flujos de aprobación-revisión,  las políticas de acceso, etc.. en sus respectivos ámbitos.

Los Administradores de Colección tienen privilegios sobre una determinada Colección, y pueden decidir a quién se le permite enviar ítems a la misma, así como añadirlos, editarlos o eliminarlos.

Un Administrador de Colección, además de disponer de los menús “Listar” y “Mi Cuenta”, dispone del menú “Contexto” para la Colección sobre la que tiene permisos de administración, desde el cual podrá editar dicha Colección, exportarla completamente o exportar sus metadatos, así como relacionar ítems pertenecientes a otras Colecciones en ésa. De la misma forma, tendrá permisos para editar, exportar completamente o solamente los metadatos, de los ítems pertenecientes a esa Colección. Sin embargo, el Administrador de Colección carece del privilegio de restringir el acceso a la lectura de los ítems y archivos entrantes en la Colección, que por defecto está asignado al Grupo Anónimo, ya que este privilegio sólo está disponible para el Administrador General del Sistema.

El Administrador de Colección dispone también del menú “Estadísticas”, desde el cual puede visualizar las estadísticas de uso de su Colección y de sus ítems, pero carece de la opción de visualización de las Estadísticas generales del sistema, así como del acceso a los Informes estadísticos mensuales. Ésta también es una opción disponible sólo para Administradores Generales del Sistema.

Hay que señalar que los Administradores de Colección carecen del menú “Administrativo”, por lo que no poseen funciones generales de control de acceso y gestión de usuarios y grupos, funcionalidades sobre registro de metadatos y formatos, de importación de metadatos, tareas de curación y tampoco acceso al “Panel de control” de la herramienta. Además, un Administrador de Colección no puede crear nuevas Colecciones.

Los Administradores de Comunidad gozan de un mayor número de permisos que los Administradores de Colección, ya que son aquellos usuarios de DSpace que tienen todos los privilegios sobre una determinada Comunidad, y pueden decidir a quién se le permite enviar ítems a sus Colecciones, editar los metadatos, y relacionar ítems existentes en otras Colecciones. Además, pueden crear Subcomunidades y Colecciones, así como gestionar o asignar permisos para las mismas. Sin embargo, no pueden crear nuevas Comunidades, funcionalidad que sólo está permitida para el Administrador General del Sistema.

De manera análoga a los adminitradores de colecciónm , además de los menús “Listar”, “Mi Cuenta” y “Contexto”, el Administrador de Comunidad dispone del menú “Estadísticas”, desde el cual puede visualizar las estadísticas de uso de su Comunidad y de sus Colecciones e ítems, pero carece de la opción de visualización de las Estadísticas generales del sistema, así como del acceso a los Informes estadísticos periódicos, ya que como se ha indicado anteriormente, ésa es una opción disponible sólo para los Administradores Generales del Sistema.

Los Administradores de Comunidad, al igual que los de Colección, carecen del menú “Administrativo”, por lo que tampoco pueden realizar las tareas Administrativas descritas anteriormente.

Probamos DSPACE 3.0. Y nos gusta…

Pues no pudimos esperar más y nos bajamos e instalamos la Dspace 3.0-rc1 release. Realizamos la décimosegunda descarga, y nosotros pensando que llegábamos tarde….

El proceso de instalación, sobre un Ubuntu 9, Postgresql y Tomcat 6 que estaba en una máquina virtualizada  fué nítido y rápido, y voilà, ya teníamos un Dspace3.0 con xmlui para probar. Mientras redactamos una evaluación detenida, os podemos contar algunos de los temas que destacan (y que estábamos esperando) de esta versión. No es una lista exhaustiva de todo lo bueno que contiene esta versión, que es mucho, y que lo podéis encontrar aquí.

Versionado a nivel de item.
La historia de un item está disponible y es posible citar una versión particular de un item.

Modificaciones al sistema de embargo. Ya no se require el uso de los crontab (embargo-setter y embargo-lifter) para aplicar las restricciones, sino que se usa el AuthorizationManager, definiéndose una Embargo Resource Policy que hace uso de las fechas de comienzo y fin de las ResourcePolicies. Tendremos que echar una pensada sobre esta implementación. Ya os contaremos.

Mejoras al Discovery. La gente de @atmire sigue marcando diferencias y en esta versión la lista de propuestas para Discovery/Solr es abrumadora: resaltado de keywords, recomendaciones, nuevo tratamiento de las facetas, etc… Y SOBRE TODO:

  • Han portado el Discovery a JSPUI (gracias al apoyo de la Universidad de Hong Kong). Enhorabuena a los usuarios de JSPUI, ahora tendrán la popsibilidad de usar Discovery
  • Y Solr tiene en cuenta los derechos de acceso a un item, de modo que detecta que si el usuario no tiene accesos de lectura, ese ítem no se muestra en los resultados en las búsquedas. Para todos aquellos que en un momento dado buscamos ocultar items y colecciones y no lo logramos porque al final aparecían en los resultados de los buscadores, este es un avance sustancial. Habrá que probar esta función en detalle.

Mejoras al sistema de estadísticas. Aparte de que se han incluído estadísticas de search en colecciones/comunidades específicas y estadísticas de los workflow, aparecen una serie de utilidades para el tratamiento de grandes ficheros de log, con el fin de intentar minimizar el problema que generan los logs en instalaciones con mucho tráfico.

Envíos basados en tipo de documentos. Esta era una solicitud que venía de lejos (Google Summer of Code, un ticket jira DS-464, muy antiguo y una adaptación-patch a la versión 1.8 con el código del ticket jira DS-1127). Se dirige a la necesidad de muchos repositorios de adaptar los formularios de envío (input-forms) a los diversos tipos de objetos del repositorio. Hasta ahora la única solución era definir colecciones diferenciadas, cada una con un <form> adaptado. El enfoque ha cambiado, y se han incorporado en los <field> restricciones a su visualización dependiendo de determinadas características de los objetos que se describen. Posiblemente un enfoque más cómodo que el anterior.

OAI 2.0 basado en xOAI, aportado por la empresa Lyncode, antiguos Universidad do Minho y Keep solutions, creo. Permite la creación de sets virtuales, filtrado y transformación. Entendemos que es una reforma completa, o quizá evolución natural del OAIextended, pero basado en un framework OAI mejorado. Lo evaluaremos.

Tratamiento de formatos bibliográficos. Los scripts de importación disponen ahora de una opción que a partir del Biblio-Transformation-Engine es capaz de importar metadatos ¿y bitstreams? de los formatos Endnote, BibTex, RIS, TSV, CSV. Pues esto hay que probarlo en detalle..

Interfaces e integraciones con DSpace

La pregunta primera que nos debemos hacer es ¿cuando necesitamos tener un interface con DSpace? y no estamos hablando solamente de interfaz de usuario (léase XMLUI o JSPUI) sino de interfaces sistema-sistema o integraciones. Bien, en ciertas ocasiones necesitaremos integrarnos con sistemas o aplicaciones web, como CMS, DMS, LMS, diseñar interfaces de usuario sustancialmente diferentes, como las móviles, lograr una interacción entre repositorios, etc. Un conjunto más amplio de lo que inicialmente se piensa.
De hecho, una gran parte de repositorios se interconectan mediante OAI-PMH. Llevamos toda la vida usando servicios de integración y ni nos habíamos dado cuenta…
Bien, este post es un repaso (con la impresión de que no es exhaustivo) a las diversas alternativas y sabores existentes.

Integración directa contra la Base de Datos y el sistema de Ficheros
Esto podríamos consideralo básicamente una declaración del tipo: «no me sirve nada el código java de Dspace y me voy a programar otra cosa». El proyecto, excepto si pensamos para el acceso a funciones muy básicas, será largo, pero claro, prácticamente podréis usar cualquier framework de desarrollo para el proyecto.

JavaAPI
Cualquier aplicación que sea capaz de llamar al JavaAPI de Dspace, podrá usarse para este tipo de integración. Así es como surgió XMLUI y están surgiendo continuamente nuevos proyectos. El problema es que la JavaAPI no proporciona una separación completa o nítida y normalmente se requerirá re-escribir parte de la lógica de negocio de DSPACE en la nueva aplicación. Ejemplo de ello es la duplicidad existente en el código XMLUI y JSPUI, indicación clara de esta insuficiencia o «imperfección» del JavaAPI.
Pero aparte de eso, ese el camino para el uso de Frameworks de Aplicaciones Web o de desarrollo rápido, como el framework Play!, la nueva interface anunciada en agosto de este año para Dspace, Freemarker WebMVC o incluso el uso de frameworks no-Java como Ruby on Rails.

OAI-PMH
Simplificando, OAI-PMH permite la recolección de los metadatos DSpace en otro sistema. El OAI-PMH, OAI’s Protocol for Metadata Harvesting, es la base de los proyectos de cooperación entre repositorios de diferente nivel (regional, nacional , temáticos…). OAI-PMH define los estándares para describir los intercambios de metadatos entre sistemas y con la creciente disponibilidad de librerías OAI-PMH para una diversidad de plataformas, pues es una opción siempre valorable.
Curiosamente siempre tenemos presente la recolección de nuestro DSpace, ya que la aplicación OAI se despliega de forma estándar en el proceso normal de construcción de DSpace, pero (creo que desde la versión 1.6) podemos configurar nuestro DSpace para recolectar otros repositorios que expongan sus contenidos mediante este interface. Por ejemplo, arXIv posibilita su recolección para proveer acceso a los metadatos de todos sus artículos. Guarden la debida precaución con los derechos y licencias.

OAI-ORE
OAI-ORE, Open Archive Initiative’s Object Reuse and Exchange, es la especificación para describir agregaciones de recursos web y el intercambio de recursos digitales. El soporte de este protocolo en Dspace se propociona desde la versión 1.6.
Si se usa en combinación con OAI-PMH el contenido de un repositorio (metadatos + ficheros) puede ser recolectado desde/hacia otro sistema. Como uso, quizá un poco raro, lo hemos usado para migraciones, obtener nuevas unidades de agregación de contenidos, y sincronización de instancias, sin necesidad de recurrir a procesos de import-export o similares.

REST-API
Existe una REST API en fase de desarrollo avanzado que permite la integración basada en REST: Transferencia de Estado Representacional (Representational State Transfer).  El código se  puede descargar para la 1.8 y previsiblemente irá incluido en el DSpace 3.0, pero ya hay una serie de proyectos interesantes sobre esta interfza, incluido una integración Moodle.

SWORD
SWORD (Simple Web-service Offering Repository Deposit) es un protocolo, basado en atompub, Atom Publish Protocol, que define el depósito remoto de items en un repositorio por otras aplicaciones. Ya nos hemos explayado bastante en este blog sobre SWORD, está claro que nos gusta. La disponibilidad de librerias Sword en diversos lenguajes, (PHP, java…) promueve el uso de este tipo de integración, p.ej, en el depósito de publicaciones desde sistemas de investigación, y otros escenarios.
Dspace implementa el protocolo SWORD de diversas formas:

  • Servidor compatible con el protocolo SWORD v1, disponible desde la versión 1.6 de Dspace
  • Servidor compatible SWORD V2, disponible desde la versión 1.8 de Dspace.
  • Cliente SWORD, para hacer que DSPACE deposite items en otros sistemas que acepten este protocolo.

LNI (Lightweight Network Interface)
Este interface permite la integración de un sistema con DSpace via el protocolo WebDAV. Puedes encontrar más información aquí. La última actualización del código se realizó en la versión 1.5, su uso parece minoritario y hay reportados problemas de rendimiento (literalmente:    suffers horrible performance issues).  Desarrollado por el MIT, su proyecto más visible parece ser CWspace, una plataforma de este Instituto de contenidos OpenCourseware.

SOLR
En el Open Repositories 2012, Stuart Lewis presentó SkylightUI, que es un front-end sobre DSpace, desarrollado en CodeIgnitor(PHP), y que usa el índice SOLR de DSpace como una API. Como nunca nos podemos resistir a las propuestas de Stuart, pues lo probaremos lo antes que podamos, y os seguiremos contando.

Funcionando con varios DSpace

Hay muchas razones por las que nos puede interesar tener más de un DSpace, por mencionar unas cuantas: tener una instancia de producción y otra(s) de pruebas, servir a diferentes organizaciones, tener diferentes funcionalidades, preparar una migración, etc.

Y del mismo modo que hay múltiples razones, hay igualmente múltiples aproximaciones a esta situación. El post anterior planteaba un proceso simple, sin complicaciones, para tener múltiples instalaciones y funcionar alternativamente con ellas. En este post vamos a efectuar un recorrido rápido, no exhaustivo, por las alternativas existentes para tener instancias DSpace simultáneamente activas.

Un esquema simple, aunque efectivo para los objetivos que nos proponemos, de lo necesario para dspace sería: HW + sistema operativo + (servidor web y/o servidor de aplicaciones) + DSpace + bbdd, es decir:

Alternativa 1: Virtualización del HW por software
Es decir, emulación por software de un sistema físico con unas características de hardware determinadas: VMWare, VirtualBOX, Hyper_V, Xen-Server….. Si quieres realmente obtener copias idénticas de entornos, interesante en múltiples ocasiones, y aislamiento completo entre entornos, ésta es posiblemente vuestra opción.

 

Alternativa 2. Múltiples tomcat + bbdd + dspace
Instalar n Tomcat. No es trivial, pero se puede hacer con diferentes directorios de instalación, con scripts de aranque/parada diferenciados y diferentes puertos.
Instalar n bases de datos.
Instalar n Dspaces, con diferentes directorios dspace_src, los cual conducirá a ficheros de configuración separados, y por supuesto cada uno usando su base de datos correspondiente.
Además, cada Tomcat deberá apuntar al webapps de su dspace correspondiente …

 

 

Alternativa 3. Virtualizaciones Apache basada en Vhosts
En esta opción se debe usar Apache como front-end de los Tomcat.
Instalar y configurar n instancias Tomcat, n bases de datos y n Dspaces (como en la alternativa 2 anterior)
Con la directiva NameVirtualHost del servidor web Apache, crear n host virtuales, cada v-host dirigido a su Tomcat correspondiente. Más información sobre Vhosts, aquí

 

Alternativa 4 –> 1 tomcat + n BBDD + n dspace
Se puede usar un único Tomcat configurado para que use n directorios webapps correspondientes a n instancias Dspace. Pero claro, como siempre, (esto no hay manera de evitarlo) se necesitan n bases de datos diferentes y n instalaciones Dspace (con sus n directorios). Cada configuración Dspace apuntará a una base de datos diferente y hay que decirle a Tomcat donde está cada Dspace (bueno, cada aplicación jspui, xmlui, oai,….de Dspace) en el fichero server.xml de tomcat.

Algo así como

 
<Context path="/jspui_1" docBase="../dspace_1/webapps/jspui/" ..../>
<Context path="/jspui_2" docBase="../dspace_2/webapps/jspui/" ..../>
<Context path="/jspui_n" docBase="../dspace_n/webapps/jspui/" ..../>

<Context path="/xmlui_1" docBase="../dspace_1/webapps/xmlui/" ..../>
<Context path="/xmlui_2" docBase="../dspace_2/webapps/jspui/" ..../>
<Context path="/xmlui_n" docBase="../dspace_n/webapps/jspui/" ..../>

..

<Context path="/oai_1" docBase="../dspace_1/webapps/xmlui/" ..../>

 

 

 

Para profundizar más
Hay múltiples caminos y vías para tener más de una instalación de DSpace. Las líneas bocetadas en los párrafos anteriores pueden presentar características que para una organización en concreto no resulten aceptables. Quizá se quiera independizar o aislar fuertemente a los usuarios de desarrollo y producción, o las políticas TI no permitan virtualizaciones, etc..

En la página wiki.duraspace.org/display/DSPACE/MultipleDspaceOneServer encontraréis soluciones a algunos de los temas relacionados con la ejecución simultánea de varios DSpace.