Traducción al español de Dspace 3.0 disponible

Ya está puesta a disposición de la comunidad la traducción al español de la versión 3.0 e interfaz XMLUI. El fichero messages_es.xml   está incorporado en la distribución de la versión 3.0, aunque también se encuentra disponible en el ticket jira 1398.

En ese mismo tícket está disponible el fichero de traducción de los mensajes correspondientes al Discovery, y señalar que por premuras de ensamblaje de la versión 3.0, no pudimos incluir la traducción de los módulos SwordClient y XMLWorkflow.  Recordar que desde la version 1.8, cada módulo distribuye su propio messages.xml, separado del messages.xml principal, de manera similar a la fragmentación de los ficheros de configuración…

Como en ocasiones anteriores, hemos revisado algunas de las traducciones de mensajes que veníamos arrastrando de versiones anteriores, intentando luchar algo contra el desorden natural de los mensajes…. Pues eso, sean benevolentes.

 

 

 

Share

BIREDIAL 2012, Universidad del Norte, Barranquilla

Estuvimos presentes en la  II Conferencia Internacional sobre Bibliotecas y Repositorios Digitales -BIREDIAL , que fué organizada por la Universidad del Norte en Barranquilla, Colombia, y en la cual impartí un taller acerca de las tareas de curación en DSpace.

Antes de nada agradecer a la Universidad del Norte su excelente  hospitalidad  y ayuda permanante en toda la estancia.  (nota al margen: además es muy recomendable ir a Barranquilla porque,  aparte de ser la ciudad natal de Shakira, su gente es excepcional y siempre te atenderán magníficamente :-)

BIREDIAL  pudo reunir a profesionales de DSpace y otras herramientas de gestión de repositorios digitales,  Directore/as y resto de personal de Bibliotecas y otras instituciones, siendo un marco adecuado para intercambiar experiencias de los diferentes países a los que pertenecían todos los asistentes.

En las ponencias se comentaron experiencias acerca del uso y características de diferentes herramientas, así como determinadas  carencias que tenían,  lo que sirvió para una interesantísima  puesta en común para dar soluciones a los diferentes tipos de problemas que surgían. Desde Arvo Consultores aportamos nuestra experiencia y conocimiento de DSpace para intentar dar soluciones y orientar a las diferentes instituciones presentes.

Especificamante en el taller que impartí, y que tuvo como tema central  las tareas de curación, expuse  ejemplos prácticos asi como teóricos sobre la inclusión-activación de las tareas de curación en DSpace (para los que no estuvieron presentes, en el blog tenemos unos post acerca de las tareas de curación). Adicionalmente,  en el taller se pudo hacer una pequeña demostración de la aplicación Easydeposit (desarrollada por Stuart Lewis,  mas información aquí  y en unos cuantos post de este blog)

Para acabar el post quiero acabar con un rotundo Gracias a la Universidad del Norte por su acogida, y por supuesto  están invitados a conocer nuestra tierra.

Share

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.

Share

Traduccion al gallego de Dspace 1.8- XMLUI

La traducción al gallego de la interfaz XMLUI de Dspace para versiones 1.8 y anteriores está ya disponible. El fichero messages_gl.xml se encuentra disponible en el ticket jira 1394.

La traducción se ha realizado en el marco de un proyecto para la Universidade de Vigo, revisándose por el Área de Normalización Lingüistica de dicha universidad.

Share

Auto-Registro y Registro de Usuario

La mayoria de las funciones de Dspace, como buscar documentos o descargarlos si están en acceso abierto, pueden usarse de forma anónima, es decir, sin realizar ningún tipo de autenticación de los usuarios. Sin embargo, ciertas características de DSpace solo son accesibles a usuarios privilegiados, y eso significa ser capaz de identificarlos y una vez hecho esto, asignarles permisos y acceso a esas funciones restringidas.

Las e-personas (e-people) y los grupos son los entes usados por Dspace para identificar usuarios y asignar privilegios. Las e-personas pueden existir mediante proceso de auto-registro o bien registradas (creadas)  por un administrador.  Existen diferencias sustanciales en el uso de cada opción.

En el procedimiento de Auto-Registro de un usuario, éste accede a la sección “Registro de nuevo usuario” e introduce su dirección de correo electrónico. Dspace, de manera automática, envía un correo (con un token de seguridad) a esa dirección para que se pueda continuar el registro. Siguiendo las instrucciones del correo recibido, el usuario crea su cuenta, introducir sus datos y una contraseña. A partir de ese momento, puede acceder a Dspace mediante el formulario de login, con la dirección de correo y contraseña indicadas. Finalizado el proceso de registro, el nuevo usuario es incluido en la Base de Datos de DSpace, con un identificador único asociado.

En el procedimiento de Registro de usuario por el Administrador, es éste quien crea al nuevo usuario, accediendo a la sección de “Gestión de usuarios”, sólo disponible para usuarios con este rol, y pulsando el enlace correspondiente para añadir un nuevo usuario. El Administrador debe introducir la información del nuevo usuario, incluyendo una dirección de correo electrónico, y pulsar el botón “Crear usuario” para crear un nuevo usuario en DSpace. Mediante este procedimiento, el nuevo usuario también es incluido en la Base de Datos de la herramienta con un identificador único asociado. Sin embargo, en un principio no puede acceder a la herramienta mediante contraseña, puesto que no tiene ninguna. Este sistema se emplea principalmente cuando los credenciales de acceso a Dspace se reciben de otros sistemas de identificación como un LDAP. Claro que habrá que configurar Dspace para ello.

Como segundo escenario para que el usuario creado mediante el sistema de Registro por un Administrador pueda acceder a DSpace mediante contraseña, debería ser el Administrador quien, desde la sección de “Gestión de usuarios”, pulse el botón “Restablecer contraseña” correspondiente a dicho usuario. De esta forma, la herramienta envía, de manera automática, un correo a la dirección de ese usuario para que pueda modificar su contraseña, o, en este caso, introducir una contraseña por primera vez.

Share

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..

Share

Activar tareas de Curation. Parte 1

Las tareas de Curación (Curation tasks) son básicamente programas desarrollados en Java para añadir una funcionalidad adicional, relacionada con la gestión de los objetos del repositorio, de ahí el término Curación o Preservación, a la que nos da la instalación base repositorio.

Manual Dspace 1.8: The goal of the curation system (‘CS’) is to provide a simple, extensible way to manage routine content operations on a repository. …The DSpace core distribution will provide a number of useful tasks, but the system is designed to encourage local extension – tasks can be written for any purpose, and placed in any java package. This gives DSpace sites the ability to customize the behavior of their repository without having to alter – and therefore manage synchronization with – the DSpace source code.

El soporte a las tareas de curación aparece en la versión 1.7 y se mejora sustancialmente en la versión 1.8, principalmente con la adición de un marco bastante completo de creación de nuevas tareas.

Las tareas de curación son programas java con detección del contexto de invocación, es decir se aplican al nivel de colección, subcolección o ítem,  en el contexto en el que se esté. Además pueden ser invocadas desde el Command line interface, CLI, con lo que pueden ser programadas mediante rutinas nocturnas,  y también desde la UI del administrador (sólo interface XMLUI).
Las tareas que pueden ser apropiadas serían, p.ej :

  • Escaneado antivirus de los ficheros, asegurar la legibilidad de los ficheros…
  • Mejora de los ficheros, p.ej aplicación de marcas de agua o páginas iniciales a los pdfs…
  • Comprobación de la completitud de metadatos, valores límite de los metadatos, adherencia a determinados perfiles de uso de los mismos..
  • Conexión con servicios externos a Dspace para mejorar los metadatos, como authority controlled…

Las tareas de curación nos permiten complementar Dspace e incorporar funciones adicionales, pero debemos considerar las implicaciones ante una migración de versiones. El poder implementar cualquier función tiene la desventaja de que esa libertad puede hacer que a la hora de desarrollar una tarea estemos usando versiones de la API de DSpace que en un momento dado se abandone o entren en desuso. Por ejemplo,  programamos una tarea de curation en la cual modificamos un metadato de DSpace usando la API del DSpace 1.7.2, luego al  migrar esta tarea de curación a una versión superior,  descubrimos que la API DSpace 1.8.2 no soporta lo que hemos programado.

No obstante esta precaución, he de decir que a partir de la versión 1.6.0 y futuras API’s no parece haber muchos cambios importantes a la hora de programar, por lo que una tarea de curación programada para la API 1.6.0 seguramente funcione para la 1.8.2.

Una vez hecha esta introducción ahora vuestra pregunta será, ¿cómo programo y cómo activo una tarea de curación?

La respuesta a la primera pregunta mejor lo dejamos para otro futuro post  (nos quedaría este muy pesado) y nos centramos es la segunda cuestión.

Como aspecto curioso de señalar,  DSpace tiene de por sí mas tareas de curación programadas de las que aparecen en el UI, lo que pasa es que no las tiene instaladas. Por ello nos centraremos en este caso  para aclarar cómo se instala una tarea de curación.

Para que el Curation System pueda ejecutar una tarea, se deben dar dos condiciones, que el código de la tarea se incluya con el resto del código,  p.ej. en [dspace]/lib, WAR, etc, y que además se le declare y asigne un nombre en el fichero de configuración [dspace]/config/modules/curate.cfg.  Notar que este fichero se localiza en el subdirectorio config/modules/. La intención es que las tareas sean add-ons de la configuración base del sistema, sin que añadir o retirar tareas impacte en dspace.cfg (esto cambión en la v1.8 respecto la v1.7)

En este fichero hemos de introducir las tareas de curación para que el interfaz gráfico de DSpace las detecte. Para cada tarea se debe añadir un par key-value. La Key es el nombre completo cualificado de la clase java y el Value es el nombre de la tarea usado en el resto del CS para referirse a la tarea,  de tal forma que luego el usuario las pueda seleccionar.

Por ejemplo, si queremos activar el antivirus ClamScan debemos de añadir en el parámetro plugin.named.org.dspace.curate.CurationTask, el nombre de la clase Java correspondiente a la tarea de curation y luego un nombre que le queramos dar a la tarea de curación. Nuestra clase java se llama ClamScan y queremos darle el nombre vscan, y entonces la línea quedaría así:

plugin.named.org.dspace.curate.CurationTask =
org.dspace.ctask.general.ClamScan = vscan

Como tendremos mas tareas activas, este parámetro tendrá más bien este aspecto:

plugin.named.org.dspace.curate.CurationTask = \
org.dspace.ctask.general.ProfileFormats = profileformats, \
org.dspace.ctask.general..RequiredMetadata = requiredmetadata, \
org.dspace.ctask.general.ClamScan = vscan

y obviamente si quisiésemos insertar otra tarea de curación, por ejemplo un fichero java llamado MiJava y de nombre mitarea sería así

plugin.named.org.dspace.curate.CurationTask = \
org.dspace.ctask.general.ProfileFormats = profileformats, \ 
org.dspace.ctask.general..RequiredMetadata = requiredmetadata, \ 
org.dspace.ctask.general.ClamScan = vscan \
org.dspace.ctask.general.MiJava = mitarea

Ahora solo queda reiniciar el tomcat y ya tenemos disponible nuestra tarea de curación en la UI. Con los privilegios de administrador (en la 1.8 también pueden ejecutar tareas de curación los administradores de comunidad, en su contexto de administración, claro) en los paneles de edición de comunidad o colección o item, deberemos seleccionar la pestaña de curar. En el desplegable que aparece seleccionamos la tarea que queremos ejecutar, y una vez seleccionada le damos al botón de realizar.

Bueno espero que os haya abierto el gusanillo de la curiosidad, y os de por experimentar un poco con tareas de curación. En siguientes entregas explicaremos como codificar nuevas tareas de curación.

Share

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.

Share

Definir un nuevo índice de navegación

Además de la búsqueda (search), uno de los mecanismos que ofrecen los repositorios a sus usuarios es la navegación (browse) por sus contenidos, con los usuarios revisando un índice p.ej. de títulos para ver si encuentran contenidos de su interés.

En la mayoría de instalaciones surge la necesidad de redefinir los índices de navegación (Browse indexes), puesto que los cuatro índices (autor, título, fecha y materia) que vienen definidos por defecto en LUCENE, que es el buscador habitual de la mayoría de instalaciones Dspace, en contraposición a SOLR… posiblemente no se adapten suficientemente a las necesidades de nuestra organización. Dspace permite la definición de nuevos índices (incluyendo eliminar o modificar los ya definidos) como parte del proceso de configuración.

En primer lugar, índice se asocia por lo general a metadato, por lo que debemos tener definidos en Dspace los campos de metadatos relevantes, y sobre ellos configurar los índices de navegación.

  • Lo primero a tener en cuenta es incluir el metadato en el metadata-registry…claro. p.ej. dc.subject.unesco, porque queremos tener un índice de materias unesco.
  • Localizar la sección configurable browse indexes en dspace.cfg. Y en ella, editar el nuevo índice:
     webui.browse.index.(n) = Unesco:metadata:dc.subject.unesco:text

    para una explicación de la sintaxis de este campo, ver el cajetín al final de este post, y referirse al manual de Dspace. Sobre todo, cuidado con la numeración del índice, ya que deben quedar todos los índices en secuencia ordinal correcta…1,2,3..n , sin saltos, repeticiones…

  • realizar un index-init, rearrancar tomcat limpiando la memoria caché y el índice ya esta listo para ser usado..
  • Como el índice es nuevo, no existirán las etiquetas de lenguaje correspondientes. Avisados quedan, son un montón. Navegar sobre el índice recién construido y anotar las nuevas etiquetas, del tipo:
     xmlui.ArtifactBrowser.ConfigurableBrowse.title.metadata..........

    Para XMLUI, incluirlas en el messages.xml y en los messages_xx que use vuestra instalación

¿Sabías que…? si el campo sobre el que se construye el índice es un campo authority controlled, Lucene ofrece simultáneamente al índice “tradicional” un índice adicional sobre ese campo, que se construye únicamente con los valores validados… Para usar ese índice en el dspace.cfg tienes que configurar un nuevo índice con los valores:

webui.browse.index.5 = lcAuthor:metadataAuthority:dc.contributor.author:authority (ejemplo)

Sintaxis
webui.browse.index.<n>=<index name>:<metadata>:<schema prefix>.<element>.<qualifier>:<data-type field>:<sort option>.

  • Propiedad en dspace.cfg: webui.browse.index.<n>
  • <index name>: El nombre que queramos dar al índice, relevante para las messages keys
  • <metadata>: valores posibles “metadata”, “item” o “metadataAuthority”
  • <schema prefix>.<element>.<qualifier>: el campo dublin core cualificado sobre el que se construye el índice, p.ej.dc.contributor.author. Admite en <qualifier> caracteres de macheo múltiple (*)
  • <data-type field>: los tipos que permite son “date”, “title”, “text”, “other”, “authority” (y podriamos definir otros adicionales relevantes a configuraciones específicas de normalización del índice)
  • <sort option>: Opcional, puede ser ascendente o descendente.

Share

Sobre los Formatos de ficheros

Como indica el documento ISO/TC 46/ SC 11 Digital records preservation: Where to start Guide, la naturaleza de los registros digitales origina una serie de desafíos que deben ser contemplados si se busca la preservación de los registros en el transcurso del tiempo. Los desafios principales son:

  • Obsolescencia y degradación de los formatos físicos (media)
  • Obsolescencia de los formatos de ficheros
  • Obsolescencia del software ( sistemas operativos, bases de datos, ofimática…)
  • Obsolescencia de Hardware

The current rate of technological change may mean that preservation actions, such as migrating to more accessible or durable formats may be required after as little as five years. Digital preservation should therefore be addressed from as early in the object life cycle as possible, particularly as the manner in which a resource is created has a significant impact on its durability. “Digital Preservation: Continued access to authentic digital assets”; Briefing paper; JISC; nov 2006.

Como consecuencia, se requiere la intervención casi continua y desde el primer momento, de los archivistas para preservar los contenidos digitales.

Obsolescencia de Formatos de ficheros

Principalmente se requiere un enfoque de anticipación, puesto que continuamente aparecen nuevos formatos, aunque estudios recientes sobre repositorios científicos de acceso abierto muestran un dominio del formato PDF y una larga cola (long tail) de otros formatos.  “Characterising and Preserving Digital Repositories: File Format Profiles”; Steve Hitchcock and David Tarrant; 30-January-2011; Ariadne Issue 66.

En un momento dado, una comunidad de usuarios como la que conforma nuestros repositorios Dspace podría estar usando decenas de aplicaciones y cientos de formatos, y lo que es más importante, deseando efectuar depósitos con las menores restricciones posibles. Al fin y al cabo, ¿a quién le gusta convertir formatos?

Los responsables de un repositorio, si son precavidos, deberían tener en cuenta este escenario de cambio, evolución y desorden, ya que una política de preservación que no considere el cambio, no es una buena política.

Formatos de Archivo (Archival Data Formats)

Uno de los elementos principales de un enfoque de preservación es el uso (sugerencia, recomendación u obligación) de formatos de archivo que no sean propietarios (se caen los formatos ms-office y decenas de otros) y que además estén específicamente definidos para el acceso en el largo plazo y desde diferentes plataformas tecnológicas.

Entre los candidatos a formato estable para documentos típicos, se considera normalmente el uso del Portable Document Format (PDF) de Adobe. Por ello nuestros repositorios están repletos de este formato, gusta a los usuarios y por tanto PDF es un buen candidato para formato de archivo.

Incidentalmente, PDF puede corresponder a Portable Document Format (Adobe), Printer Definition File (Netware) o a Package Definition File (Microsoft Systems Management Server) y aunque posiblemente no veremos nunca por nuestros Dspaces un PDF no-Adobe, el ejemplo ilustra los riesgos de asumir la extensión como indicación del formato. La extensión del nombre de fichero de tres caracteres no está ni estandarizada, ni es única, siendo además interpretada diferentemente por diferentes entornos.

Y a efectos de preservación, PDF significa al menos 17 formatos diferentes de Adobe: Acrobat pdf 1.0, 1.2, 1.3,..1.7, Acrobat PDF/A, Acrobat PDF/X Exchange 1a:2003, etc… con estrategias de preservación (migración y conversión) igualmente diferentes. Si a esto le añadimos las funcionalidades de protección de documentos de Adobe, la amenaza de los Digital Rights Management, u otras curiosas posibilidades de este magnífico software, pues entenderemos que la tarea de preservación puede ser muy complicada.

Recomendamos: Asomarse un poco a a la complejidad de los formatos, y de sus efectos en la preservación, en el registro PRONOM de los National Archives del Reino Unido.

 

Los formatos en Dspace

Por contra de otras muchas virtudes que tiene Dspace, en el asunto de formatos considero que nos ofrece poca ayuda a nuestra tarea. Expliquémosnos.

DSpace usa la extensión de fichero como indicación de la codificación (formato) del fichero. En ese sentido, Dspace considera la extensión como un “metadato” y a partir de ahí, mediante un macheo con el format-registry, asume el formato del fichero y el nivel de soporte que se determina sobre el formato. Sobre el soporte de formatos y el format-registry en DSpace ya escribiremos un post detallado.

Las consecuencias de esta sobre-simplificación de la identificación de formato son diversas, ya que podemos tener:

  • Un único saco para varios formatos similares y teóricamente compatibles, pero no lo olvidemos, a efectos de preservación, distintos: el caso explicado antes de los 17 formatos de Adobe PDF.
  • Asignaciones incorrectas tipo 1: considerar que tenemos un Adobe/pdf  y en realidad estamos “custodiando” un MS-Package Definition File, o cualquier otra cosa que el autor ha decidido renombrar con esa extensión.
  • Asignaciones incorrectas tipo 2: considerar que un fichero no está soportado, porque su extensión no corresponde a una soportada (el caso más obvio, los ficheros sin extensión)
  • etc..

Las soluciones que podemos vislumbrar, no son complejas, y están desde hace tiempo en la línea de evolución y desarrollo de Dspace, con una mezcla de tareas automáticas, como procesos batch o empotradas en los workflows de envio, de data profiling basadas en el software Droid (también de los National Archives del Reino Unido, qué bárbaros) o el framework Jhove2 (que usa Droid para la identificación de formatos) o alguna otra alternativa.

Share