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

Author Archives: cfernandez - Paginas 3

Request-copy add-on para XMLUI

Enviado por el 2013/08/05 1 comentario

El módulo Request-copy para xmlui ha sido puesto a disposición de la comunidad Dspace. Es una  conversión al XMLUI de la funcionalidad que en su día (la primera versión era para Dspace 1.3 ¡¡) desarrolló la Universidad de Minho para JSPUI.

La funcionalidad de ‘Solicitar copia’, ‘Request Copy’ o ´Fair dealing button’, que con esa variedad de nombres se refiere esta funcionalidad en la documentación de repositorios, funciona de la siguiente forma:

  1. En todos los items restringidos, es decir no-OA (considerando éstos los que tienen permisos de acceso diferente de Anónimo) se muestra un link a «Solicitar una copia al autor»
  2. El usuario solicitante debe rellenar un formulario con sus datos de contacto y razones de su solicitud.
  3. Esos datos se envían al usuario que realiza el depósito (autores o persona delegada en su nombre).
  4. El autor (o depositante) puede responder al solicitante, usando dos posibles opciones «enviar copia» y «no enviar copia», con mensajes editables.
  5. El mensaje, tal y como lo redactó el autor, se envía al solicitante, con el fichero adjunto, si esa es la opción seleccionada.

El desarrollo se ha realizado en el marco de un proyecto para el Instituto Español de Oceanografía que ha considerado adecuado liberar el código, en palabras textuales, «para que todo el mundo pueda utilizarlo». El código correspondiente a esta función está disponible en un repositorio git , asociado al ticket Jira .

Configurando SOLR

Enviado por el 2013/05/14 5 comentarios

Empecemos con una definición de la página del proyecto Apache SOLR (traducida rápidamente)

SOLR es una plataforma de búsqueda de código abierto, evolución del proyecto Apache Lucene. Sus principales características incluyen la búsqueda de texto completo,  búsqueda facetada,  indexación en casi- tiempo real, la agrupación dinámica, la integración de bases de datos, documentos ricos (por ejemplo, Word, PDF) y la búsqueda geoespacial. SOLR es fiable, escalable y tolerante a fallos, proporcionando indexación distribuida,  replicación y consultas en configuraciones con equilibrio de carga, failover automatizado y recuperación, configuración centralizada etc..

SOLR está presente en las características de búsqueda y navegación características de muchas de las mayores webs existentes (Resumiendo: es una evolución de Lucene y es extremadamente potente)

 SOLR y Dspace

SOLR se usa en Dspace para lograr dos funcionalidades: estadísticas y búsquedas. Como nada es perfecto, el uso de SOLR se mezcla con antiguas capas de código pre-existente Lucene. Así tenemos que en Dspace version 1.7, 1.8 y  3, conviven las estadísticas del «sistema» a partir del procesado de los logs del sistema  Y  las estadísticas de uso y descarga, obtenidas a partir /solr/statistics. En el -ambito de la búsqueda, la situación es que con Discovery activado, la búsqueda se hará sobre el motor SOLR y sus índices, pero la navegación por índices se hace sobre Lucene (desconcierto garantizado). Está planificado simplificar esta situación en la versión 4, eliminando Lucene… veremos..

Configurando las búsquedas SOLR

Hoy veremos el segundo bloque funcional, las búsquedas. La buena noticia es que SOLR se configura mediante ficheros XML, la mala es que esta configuración es sustancialmente más compleja que la configuración Lucene.   Rompamos una lanza: SOLR tiene una potencia espectacular aunque resulte difícil de comprender su funcionamiento. Pero… ¿quien entiende el comportamiento de Google? ¿y quién lo usa? ¿a que no podríamos vivir sin él?    Pues comprender el funcionamiento de SOLR es complejo y su potencial es enorme, aunque quizá podamos conformarnos con realizar una serie de adaptaciones.

Como ejemplo de lo anterior, y ya que teníamos pendiente hablar sobre las configuraciones de diacríticos, pues vamos a comentar como lograr lo mismo que hacíamos en Lucene en este post.

Básicamente el proceso de construcción del índice Solr es la aplicación de una serie de transformaciones a nuestros campos (fields). Las transformaciones son del mimo tipo que las que aplicábamos en Lucene. En general se mantienen los nombres de las clases transformadoras y se les añade el prefijo «solr», refiriéndose así a las clases java del paquete org.apache.solr.analysis.

Hay que especificarlas relacionándolas con el tipo de campo que queramos transformar, y esta relación se especifica dentro del fichero «principal» de configuración ../solr/search/conf/schema.xml.

En este fichero tenemos que localizar el <fieldType name=»text» ……> que es el que corresponde con los campos de tipo textual. Hay datos de múltiples tipos: numéricos, string, numéricos con ordenación textual, fechas, booleanos, hasta 39 diferentes contamos en schema.xml

pues bien dentro de esa etiqueta fielType, localizar

<filter class="solr.EnglishPorterFilterFactory" protected="protwords.txt">

y cambiarla, añadiendo..

<filter class="solr.ASCIIFoldingFilterFactory"></filter>
<filter class="solr.EnglishPorterFilterFactory" protected="protwords.txt">

Lo ponemos «antes» del Porter-Stemmer por las mismas razones que explicamos cuando configuramos el índice Lucene.  Ya de paso, y contestando una pregunta que nos hicísteis, aprovechamos para revisar en ese mismo fichero el operador lógico usado en las queries:

<!-- SolrQueryParser configuration: defaultOperator="AND|OR" -->

<solrQueryParser defaultOperator="AND"/>

Ahora nos queda reindexar SOLR. Nos parece que es más adecuado proceder a una reconstrucción completa del índice y por eso, la opción de borrado del índice.

..\bin\dspace update-discovery-index -b

Y ya debiera estar. Suerte.

¿el XMLUI?.. pero si es muy fácil

Enviado por el 2013/04/01 Comentarios desactivados en ¿el XMLUI?.. pero si es muy fácil

Hace muchos años (muchos) tuve que estudiar un libro introductorio a la electrónica cuántica cuyo título terminaba con esa apostilla.  Me parece que ese tipo de literatura se ha reconvertido en la seríe de títulos xxxxx, for dummies,  con lo que no descartamos pasar a la fama con un libro titulado  XMLUI for dummies….

Bromas aparte, comenzemos con un pequeño glosario sobre términos usados en XMLUI:

  • Cocoon:  framework de desarrollo web (del  proyecto Apache) que utiliza los conceptos de pipeline y tiene una arquitectura basada en componentes.
  • Sitemap:   fichero  XML usado para configurar los diversos componentes Cocoon,  que son del tipo: generadores, trasnformadores, serializadores,  …
  • Aspecto/ Aspect: proporciona el conjunto de funcionalidades presentes en la interface de usuario, generando mediante transformaciones encadenadas un documento DRI.
  • DRI (Digital Repository Interface): esquema, codificado en xml,  que estructura y gobierna las páginas XMLUI
  • Tema / Theme : proporciona el estilo al contenido generado, produciendo el XHTML para su visualización. Básicamente es la herramienta que convierte un documento DRI en un formato legible por el usuario.

 

Un proceso de construcción de una página DSpace  en XMLUI realiza las siguientes tareas:

  1. Generar la página DRI, representación xml de la página solicitada, concatenando los diversos aspectos involucrados: eperson, artifact browser, etc…
  2. Añadir referencias a los ficheros CSS que usará el tema. estas referencias se incluyen en la sección pageMeta del documento DRI. De esta manera las XSL que convierten el documento DRI en XHTML pueden encontrar esas referencias y ponerlas en la salida XHTML
  3. Transformar DRI a XHTML.  Generalmente (depende algo del tema y de las personalizaciones efectuadas) se hace a través de la librería dri2xhtml.xsl  o el código modificado que se haya escrito.
  4. Se internacionaliza la página, invocando el transformador Cocoon i18n  para resolver las etiquetas <i18n:text>
  5. Se envía al navegador, aplicando la CSS correspondiente.

 

Y visto de otra manera, más directa ¿o más práctica?….  ¿cuáles son los elementos involucrados en una customización de DSpace-XMLUI?

  1. Modificación simples al diseño, creación de temas simples: XHTML + CSS
  2. Modificaciones complejas al diseño, creación de temas complejos: XSL + XHTML + CSS
  3. Añadir nuevas funcionalidades, modificación de los «aspects»: Cocoon + Java

 

El registro de formatos

Enviado por el 2013/02/18 Comentarios desactivados en 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

Traducción al español de Dspace 3.0 disponible

Enviado por el 2013/01/11 2 comentarios

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.

 

 

 

Traduccion al gallego de Dspace 1.8- XMLUI

Enviado por el 2012/11/28 Comentarios desactivados en 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.

Probamos DSPACE 3.0. Y nos gusta…

Enviado por el 2012/10/30 Comentarios desactivados en 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

Enviado por el 2012/09/21 2 comentarios

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.

Definir un nuevo índice de navegación

Enviado por el 2012/08/22 Comentarios desactivados en 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.

Sobre los Formatos de ficheros

Enviado por el 2012/08/09 Comentarios desactivados en 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.