Author Archives: cfernandez - Paginas 4

CommunityFiliator, reorganizando estructuras de comunidades

Enviado por cfernandez el 2012/08/01 Comentarios desactivados

Aviso a navegantes, éste puede considerarse un post «raro». Si quedaste extrañado cuando explicamos el structure-builder, quizá sea mejor que no sigas leyendo.

Cuando hace tiempo nos topamos con el comando communityFiliator, la sensación de extrañeza fué mayúscula ¿y esto para qué sirve?. Ahora la pregunta sería diferente ¿y esto se usa en alguna parte?

Un poco de historia

Antes de la versión 1.2 no existía la posibilidad de definir sub-comunidades, es decir sólo habia Comunidades y Colecciones colgando de ellas.

En la actualidad se pueden definir n-elementos, sub-comunidades, entre la Comunidad de nivel superior y las Colecciones.

Pues bien, este comando sirvió a las instalaciones Dspace para «re-colocar» estructuras planas, dos niveles, en estructuras más piramidales.

Una comunidad en DSpace se puede considerar

‘padre’ (en realidad madre) en el sentido que hay al menos otra comunidad (sub-comunidad) dependiendo de ella. [Por ejemplo, en la figura anterior, las comunidades 2, i, i.j serían ‘madres’]
‘hij@’, significando que depende de una comunidad de un nivel superior. [Comunidades 2.1, 2.2, i.j, i.j.k]
Ninguna de las dos cosas (no tiene sub-comunidades dependientes y su vez no depende de otra comunidad). [Comunidad 1]
Ambas cosas (tiene sub-comunidades dependientes y a la vez depende de otra comunidad). [Comunidad i.j]

En estos términos, una comunidad ‘huérfana’ es quien no tiene ‘madre’, a éstas también las llamamos comunidades de nivel superior (top-level communities).

El comando tiene dos sabores: Set y Remove, para establecer y deshacer relaciones madre-hija.
Set sirve para coger una comunidad huérfana, es decir de nivel superior, y hacerla dependiente de otra comunidad, moviendo toda la estructura debajo de la especificada en el comando. Y Remove convierte a una comunidad ‘hija’ en ‘huérfana’.

Igual que el structure-builder, el CommunityFiliator se incluye en la clase Org.Dspace.administer y se invoca con un

[dspace]/bin/dspace community-filiator parámetros…

Los comandos tienen la sintaxis siguiente:

[dspace]/bin/dspace community-filiator -s -p ID1 -c ID2

en donde ‘-s’ o ‘–set’ significa que a la comunidad ‘huérfana’ con ID2 la hacemos depender de la ID1

y usando el comando Remove, con la sintaxis alternativa que la mayoría de comandos Dspace tienen:

[dspace]/bin/dspace community-filiator –remove –parent=ID1 –child=ID2

en donde hacemos huérfana a la comunidad ID2, ‘matando’ la relación de dependencia con la ID1

Lamentablemente, y por si no nos habíamos dado cuenta hasta ahora, el comando no sirve para mover colecciones (SOLO comunidades y sus colecciones dependientes) de una comunidad a otra, o dicho de otro modo los IDs corresponden a entradas en la tabla comunidades, no en la tabla colecciones. De hecho el comando re-escribe justamente la tabla comunidades…

Funcionando con varios DSpace

Enviado por cfernandez el 2012/07/19 Comentarios desactivados

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.

Eliminando Items

Enviado por cfernandez el 2012/06/17 Comentarios desactivados

Existen múltiples niveles de eliminación de contenidos, ficheros e ítems, en DSpace, algunos corresponden a la base de datos / metadatos, y podríamos llamarlos niveles lógicos, asociados a los denominados «estados» del ítem y otros niveles corresponden a los ficheros de los ítems y al assetstore, podríamos denominarlos niveles físicos. Revisemos las características principales de los mismos.

Eliminar ficheros de un ítem / deleting Bitstreams
El administrador tiene una serie de posibilidades para gestionar los bitstreams (archivos) del item. Desde el UI podrá añadir nuevos archivos, reordenar los bitstreams dentro de un bundle (desde la 1.8), y borrar archivos.

UI de administrador, en editar item-->Archivos del Item-->Borrar Archivos

Retirar items / Withdrawn
Un item «retirado» significa que se prohíbe el acceso al item (no confundir con el sistema de permisos sobre los bitstreams), quedando completamente oculto en los resultados de búsquedas o índices. Sin embargo, si se referencia el handle, aparecerá un mensaje indicándonos que el item ha sido retirado, en este sentido el handle sigue existiendo. Este estado es reversible, un administrador podrá «recuperar» este item y hacerlo nuevamente visible.

UI de administrador, en Editar ítem->>Estado del Item--> Retirar...

Eliminar Items, borrado definitivo / Expunge
En un paso adicional, un ítem puede ser «eliminado», expunged en su término inglés, por el administrador de DSpace. Todos los rastros del item se eliminarán de nuestra base de datos. Este estado no es recuperable, pues supone el borrado permanente del registro en la base de datos. Una referencia al handle nos proporcionará un «page not found» y el handle nunca se reutilizará.

UI de administrador, en Editar ítem->>Estado del Item--> Borrar completamente

Borrado Físico de los archivos del item
Una vez eliminado el registro de Dspace, aún quedarán en el assetstore los ficheros del item hasta que ejecutemos un cleanup, que elimina del assetstore los ficheros de los items marcados como borrados en la base de datos. Para evitar colisiones con operaciones de archivado, este comando borra sólo bitstreams marcados como deleted con más de una hora de antiguedad.

En el interfaz CLI  [dspace]/bin/dspace cleanup

Para saber más….

A partir de la versión 1.8, la funcionalidad Edición masiva de metadatos (bulk metadata editing) incorpora la posibilidad de especificar «acciones» en los ítems. Para ello hay que añadir en el CSV a la derecha de las columnas id y collection, una nueva columna, denominada «action» y que contenga uno de estos tres valores (o vacío):

«expunge» para el borrado permanente del item (solo funciona si además hemos puesto «allowexpunge = true» en el fichero de configuración [dspace]config/modules/bulkedit.cfg

«withdraw» , es decir retirar el item del repositorio, pero sin borrarlo.

«reinstate», que corresponde a reintegrar el item al repositorio, deshaciendo un withdrawn

Configurando el buscador Lucene, sobre alfabetos, diacríticos, stemmers ….

Enviado por cfernandez el 2012/06/02 4 comentarios

A raiz de algunas preguntas que aparecieron últimamente en las listas de GUDE , sobre anomalías en los resultados de búquedas, me comprometí a escribir sobre el tema. No se si este post arrojará alguna luz o confundirá aún más…espero que lo primero.

Este post es aplicable a las configuraciones de buscador basadas en Lucene, no en SOLR, es decir, todas las 1.6 y anteriores y las 1.7 y 1.8 que no usen la facilidad Discovery…

Nuestro camino empieza a partir de la línea en dspace.cfg:

search.analyzer = org.dspace.search.DSAnalyzer

es decir, el analizador estándar de Dspace, que como bien nos recuerdan, está diseñado para textos en inglés. Y este analizador tiene los siguientes filtros, aplicados en cascada:

StandarFilter -> labores preparatorias de conversión del texto en cadena de palabras para el resto de filtros
LowerCaseFilter–> conversión a minúsculas
StopFilter –> Elimina las palabras gramaticales o «vacías» , que no aportan gran significado a la búsqueda, como artículos, conjunciones, preposiciones, etc, a partir de una lista de exclusión o «stopword». La lista original del filtro incorpora términos ingleses
PorterStemFilter–> El algoritmo de Raíces de Porter (es lo que significa Porter Stem) retira sufijos y otras terminaciones morfológicas comunes de las palabras inglesas. Y desde luego con el español, catalán, portugués, etc… no es donde ofrece sus mejores resultados….

Sobre PorterStemFilter: Básicamente mejora las búsquedas en inglés, obteniendo la raíz de una mayoría de términos. Así loving, loves, loved, lovable, .., se ven reducidas a lov- y se mejora sustancialmente la búsqueda. De manera colateral, y por eso su uso pasa desapercibido a los hispanohablantes, es un stemmer válido para algunos plurales, pero no todos, del español, ya que recordemos que no está diseñado para nuestro idioma.

Para los curiosos, el filtro implementa un proceso definido en 1979 por Martin Porter, y que puede verse aquí .. Como dice Porter, y otros antes y después, el algoritmo simplemente devuelve mejores resultados en las búsquedas automatizadas, en inglés. Mejores que si no se usa el filtro. Pero tiene, evidentemente, sus carencias y equivocaciones, ya identificadas por Porter.

Y de forma «histórica», como un conocimiento pasado de instalación en instalación, y que nosotros mismos hemos implentado, la mayoría de instalaciones con textos en español, portugués, francés… han añadido, a continuación en la cadena de transformaciones un nuevo filtro:

ISOLatin1AccentFilter, que reemplaza los caracteres acentuados del juego de caracteres ISO Latin 1 (ISO-8859-1) por sus equivalentes sin acentuar, es decir reemplaza á por a.

Con esta configuración, y con este orden de transformaciones, entre otros efectos, las palabras terminadas en es, son consideradas plurales (en inglés, pero plurales) y reducidas a su raíz, singular, por el PorterStemFilter. Por contra, las palabras terminadas en és, no son reducidas, pues para este Filtro, si terminas en és no eres un plural. Los resultados de la búsqueda son así dispares…y de ahí las preguntas en GUDE.

Un poco de wikipedia: Un signo diacrítico es un signo gráfico que confiere a los signos escritos, no necesariamente letra, un valor especial.
Son diacríticos, por ejemplo, los acentos ortográficos ( ´ ; ` ), la diéresis ( ¨ ), los signos empleados en el alfabeto fonético, como la oclusión (^) o la nasalización ( ~ ), la tilde de la ñ (virgulilla), la cedilla ( ¸ ) , la colita ( ˛ ), la coma ( , ), el doble acento agudo, ( ˝ ), el carón ( ˇ ), el breve ( ˘ ), el macrón ( ˉ ), el anillo ( ˚ ), el punto ( . ), el acento circunflejo ( ^ ) y el garfio ( ̉ ).

Otro poco de wikipedia: ISO 8859-1 es la norma de la ISO que define la codificación del alfabeto latino, incluyendo los diacríticos (como letras acentuadas, ñ, ç), y letras especiales (como ß, Ø), necesarios para la escritura de las siguientes lenguas originarias de Europa occidental: afrikáans, alemán, aragonés, asturiano, castellano, catalán, danés, escocés, español, feroés, finés, francés, gaélico, gallego, inglés, islandés, italiano, neerlandés, noruego, portugués, sueco y Euskera.
También conocida como Alfabeto Latino n.º 1 o ISO Latín 1.

Dicho esto, señalar que ISOLatin1AccentFilter ha sido retirado, «deprecated», por Apache Lucene y ha sido sustituido por ASCIIFoldingFilter (hubo un ISOLatinACCENT por el intermedio..). Los detalles de la sustitución, aquí.

Esta clase mejora la ISOLatin1Accent, ya que ésta solo trataba el primer bloque de BASIC Latin, y lo amplía incluyendo (y filtrando a sus caracteres base) una larga lista de extensiones: C1 Controls y Latin-1 Supplement, Latin Extended-A, Latin Extended-B, Phonetic Extensions, General Punctuation, Superscripts and Subscripts, etc…

Y también señalar que Lucene tiene un org.apache.lucene.analysis.es.SpanishAnalyzer, que puede ser declarado en dspace.cfg como sustitución a org.dspace.search.DSAnalyzer. Las implicaciones de esta sustitución, es que en vez de usar la cadena StandarFilter -> LowerCaseFilter–> StopFilter –> PorterStemFilter–> ISOLatin1AccentFilter, usa el filtro definido por SpanishAnalyzer, un SpanishLightStemFilter. Las malas noticias son que las pruebas que hemos realizado con este Stemmer son ¿decepcionantes?, con un tratamiento desconcertante de las palabras agudas acentuadas terminadas en o, a y e …os suena, ¿verdad? No obstante, nos reservamos una segunda evaluación más pausada sobre este filtro.

ya casi… Conclusiones o recomendaciones

Seguir adoptando y adaptando org.dspace.search.DSAnalyzer, no cambiar a org.apache.lucene.analysis.es.SpanishAnalyzer, en tanto Lucene no mejore el Stemmer de español incluido por defecto.
Posiblemente cambiar ISOLatin1AccentFilter por ASCIIFoldingFilter. No mejorará radicalmente los resultados de ninguna búsqueda, pero si en el futuro se retira de las librerías Apache, el build no os dará problemas
Dependiendo del idioma predominante en nuestro Repositorio, valorar quitar PorterStemFilter de la cadena del analizador. Si requerís un Stemmer, otra opción, que hemos probado y aparentemente no tiene los problemas reportados en las listas GUDE, aunque a lo peor tiene otros efectos colaterales, es invertir el orden de los filtros PorterStem e ISOLatin1/ASCIIFolding.

con lo que org.dspace.search.DSAnalyzer nos podría quedar así:

import org.apache.lucene.analysis.ASCIIFoldingFilter;
..
..
result = new StandardFilter(result);
result = new LowerCaseFilter(result);
result = new StopFilter(result, stopSet);
result = new ASCIIFoldingFilter(result);
result = new PorterStemFilter(result);

Ya terminamos

Sobre todo, recordar los objetivos de un analizador: simplemente devolver mejores resultados en la mayoría de consultas. Es una transacción. Si dejamos pelada la cadena de análisis, los resultados serán extremadamente precisos, en el sentido de ofrecer solo resultados coincidentes con la cadena de búsqueda, pero no estaremos aprovechando las posibilidades de Lucene y nos habremos dejado en el camino un porcentaje amplio de resultados relevantes. Vuestra decisión.

(y perdón por que esta vez me ha salido un rollo)
(y sacaremos un post con la configuración propuesta para SOLR)

Structure-builder, un comando para cómodos ¿o dubitativos?

Enviado por cfernandez el 2012/05/16 Comentarios desactivados

Este es un artículo orientado principalmente a las instalaciones que están arrancando y por tanto definiendo la estructura jerárquica de comunidades-subcomunidades-colecciones. Structure-builder es una herramienta que puede ser una ayuda inestimable en las definiciones iniciales de una instalación, para organizar, reorganizar y volver a re-reorganizar y darle otra vuelta y otra, y …..

Permite la creación «masiva» de una estructura o jerarquía compleja y completa de forma rápida. Lamentablemente no sirve para gestionar permisos de colección u otras funcionalidades de administración de colección…. Y si nunca te has enfrentado a los permisos de un centenar de colecciones, no sabrás a qué me refiero.

El comando structure-builder usa la clase java org.dspace.administer.StructBuilder (deriva del package Org.Dspace.administer). No hay versión GUI, solo hay versión CLI, por lo que toca pelearse con la pantalla oscura del terminal e invocar con un [dspace]/bin/dspace xxxxxx

El comando require de los parámetros -f -o -e ¿autoexplicativos?

[dspace]/bin/dspace structure-builder -f (/path)/source.xml -o (/path)/output.xml -e admin@user.com

que busca en (/path)/ un fichero p.ej. source.xml con un estructura como:

Recomendamos validar la estructura con alguna herramienta de edición de xml antes de invocar el comando. Éste nos dejará en output.xml el resultado, que difiere del xml de entrada básicamente en que tendremos el parámetro adicional identifier añadido en las etiquetas <community> y <collection> con los handles asignados. Y claramente, si todo ha ido bien, voilà, nos habrá definido una bonita estructura.

Además de las etiquetas <import_structure> <community>, <collection> y <name>, que son las mínimas obligatorias, podríamos añadir los metadatos de comunidad y subcomunidad siguientes:

<description>
<intro>
<copyright>
<sidebar>

y de colección, que corresponden a las etiquetas

<description>
<intro>
<copyright>
<sidebar>
<license>
<provenance>

pues que ustedes lo definan cómodo, y rápido, y bien..

La traducción al español de Dspace 1.8 ya está disponible

Enviado por cfernandez el 2012/05/11 Comentarios desactivados

Para los que instaléis, o tengáis instalada, la versión 1.8 y uséis la interfaz XMLUI, ya hemos puesto a disposición de la comunidad la traducción al español de la versión. El nuevo fichero messages_es.xml, a la espera de ser incorporado a los mecanismos estándar de distribución de código es decir, corrección final por el equipo de desarrollo de Dspace.., posiblemente para la anunciada 3.0, se encuentra disponible en el ticket jira 1146..

Comentaros que además de traducir los nuevos mensajes que aparecen en la versión 1.8, hemos realizado un esfuerzo de revisión del resto de mensajes de versiones anteriores. Dado que el messages_es.xml es acumulativo entre versiones, y por tanto compatible hacia atrás, esto quiere decir que se puede usar en versiones anteriores, por lo que quizá sea de interés o valorable la aplicación del parche a versiones 1.7 ó 1.6.

Considerar los términos y cambios a las traducciones anteriores, dentro del contexto del ejercicio interpretativo que es un traducción, por lo general díficil y con múltiples resultados….Acá van algunas temas reseñables:

Ciertos mensajes de 1.6 y 1.7 tenian cierta variabilidad de términos (upload se traducía en ocasiones como subir o cargar… y otros)..que en el nuevo fichero messages se ha intentado limitar.
Nos hemos quedado a la mitad en el tratamiento del género. Así, preguntamos si está seguro/a de …. pero quien administra Dspace, son los administradores y no hay administradoras. Ser por favor benevolentes ….
Y con ciertos términos, suficientes para dejarnos un regustillo de tarea inconclusa, seguimos atrancados. La interpretación de Curator/Curate/curation tasks, etc.. términos que en inglés tienen un sentido claro, pues en español nos asaltan con Curador/Curar/Tareas de curación que posiblemente desconcierten a alguno/a…. y otros más, no muchos, pero como dijimos, algunos haylos.

No obstante, como el messages_es.xml se puede editar, la posibilidad de cambiar términos es evidente… De hecho, estamos seguros que en las decenas de instalaciones que se están realizando en Centro y Sudamérica (el 39% de las visitas a nuestro blog en el último trimestre vienen de vuestro continente, gracias por esas lecturas) ciertos términos de nuestro «techy-español» suenan francamente extraños y lejanos. Y hemos visto personalizaciones de Dspace con un tratamiento del idioma «común» sustancialmente diferentes.

Otro aspecto a considerar. Desde Dspace 1.8, cada módulo incorpora (puede incorporar) su propio messages.xml. No tenemos aún una traducción decente de p.ej (discovery)/messages.xml.. Quizá el próximo mes.

Pues lo dicho, considerar el messages-es.xml de la versión 1.8 como un punto de partida y animaros a realizar variaciones a este fichero. ¿para cuándo, un messages_es_MX o un es_AR o un es_CL?

Uso de identificadores persistentes

Enviado por cfernandez el 2012/04/20 Comentarios desactivados

El motivo principal tras el uso de identificadores únicos y persistentes de nuestros items, como http://hdl.handle.net/2134/5137, es poder ofrecer a los usuarios que depositan objetos en Dspace, y en general al resto de usuarios, una identificación estable de dichos objetos, que puedan referenciar a lo largo del tiempo (p.ej en sus acreditaciones o curriculums).

Para Dspace, la persistencia se interpreta en el sentido del estándar del IETF rfc1737 , que exige dos requisitos a los URN, Uniform Resource Names, es decir a nuestros identificadores:

Unicidad (global uniqueness). No se asignará el mismo identificador a dos recursos diferentes..
Persistencia o Permanencia (persistence): los identificadores serán únicos, para siempre, más allá de la pervivencia del recurso o de la autoridad que asignó el identificador.

Dspace intenta conseguir esta conformidad con el estándar mediante dos mecanismos diferenciados. Veámoslo con un ejemplo sobre http://hdl.handle.net/2134/5137 (un artículo sobre vocabularios controlados descriptores de derechos de copia):

/5137–> Es el identificador externo asignado por nuesto Dspace (además hay uno interno, el InternalID). Se asignan consecutivamente desde el arranque del repositorio a comunidades, colecciones e items. Cada objeto de estas categorías llevará un ordinal, elemento principal de la Unicidad requerida.
hdl.handle.net/2134 –> un «resolvedor» que intenta asegurar la Persistencia. Cada instancia DSpace requiere un mecanismo independiente para efectuar la localización persistente de los identificadores. Dspace usa el sistema CNRI handle (hay preguntas ocasionales en los foros sobre el uso de otros resolvedores…), para lo que tendremos que registrarnos, pagar y nos atribuirán un identificado de repositorio único , el /2134 de la institución que sustituye al que viene por defecto /123456789. Con los servicios del servidor de handle arrancados, lo que explicamos en un post anterior, la url http://hdl.handle.net/2134/5137 adquiere las caracteristicas ya apuntadas.

Una serie de consideraciones adicionales:

Para lograr la persistencia, nuestro Dspace usa el sistema del CNRI, sólo a nivel del sitio Dspace, asignándole el identificador /2134. Un usuario vería sus peticiones dirigidas al CNRI, y éste enrutando las peticiones a nuestro servidor. Por ello, si cambiamos Dspace de servidor, tendremos que reinstalar el servicio de handle, reenviando determinados ficheros al CNRI, para que actualicen sus tablas de enrutamiento.
Por lo anterior, es responsabilidad de cada instalación preservar la asociación entre identificadores externos, el /5137 de nuestro ejemplo, y los objetos preservados…. Si hacemos maravillas de exportación, importación, etc.. algunas de las cuáles reasignan identificadores, podremos acabar con dicha asociación, y los items previos serán ilocalizables con los URN antiguos…
En la actualidad los identificadores persistentes no se asocian ni con bundles ni con bitstreams, los objetos debajo del nivel de item. Un bitstream tiene un identificador del tipo /2134/5137/xxxx/filename, siendo xxxx el sequence-id del bitstream, pero no son persistentes, en el sentido de que si movemos el contenido a otro servidor, la secuencia se alterará. Y la no persistencia, a efectos de preservación, tiene ventajas e inconvenientes.
No se requiere registrar nuestro Dspace para funcionar, p.ej., la Universidad Católica de Lovaina usa el identificador «por defecto». Con más de doscientos mil títulos, sus items adquieren la forma https://lirias.kuleuven.be/handle/123456789/344104 ya que no están registrados en el CNRI. El inconveniente, que están obligados a mantener el //lirias.kuleuven.be para siempre…
Si se va a usar el sistema CNRI-handle, conviene configurarlo correctamente (no hace falta que el servidor handle funcione, simplemente las URLs han de ser las correctas) antes de hacer el sitio público, pues google indexará los handles «antiguos» y luego tendremos que deshacer el entuerto, o bien usar un robots.txt que restrinja la indexación de los objetos..

Estructura de los archivos de importación de items

Enviado por cfernandez el 2012/02/23 Comentarios desactivados

A un repositorio normalmente le llega el momento de realizar una importación masiva de items, sin tener que recurrir al método de carga de uno en uno de la interfaz de usuario. El método estándar de importación es mediante el formato simple de archivo (simple archive format) y el uso por línea de comandos del import. El comando import tratará de importar una estructura de directorio-subdirectorios y ficheros con una estructura predeterminada (es decir la Simple archive format). Cada subdirectorio corresponde a un item final de nuestro Dspace y contiene una serie de ficheros para lograr la descripción completa del item.

Esta estructura es :

Realmente, los únicos ficheros importantes y/o necesarios son el dublin_core.xml y el contents. Aclaremos, normalmente tendremos ficheros de contenidos (bitstreams), pero en sentido estricto, el fichero o ficheros de bitstreams podrían no existir en un item sólo con metadatos y en ese caso, el contents sería un fichero vacio. Extraño caso de uso del import, pero posible.

Contents
El fichero contents enumera los ficheros que van en el subdirectorio, junto con posibles indicaciones del bundle en el que deben ir.

Los bundles son agrupaciones de ficheros dentro del item, que separan los diversos tipos de ficheros de modo que DSpace pueda tratarlos de forma diferenciada. Los bundles más habituales son ORIGINAL, LICENSE, LICENSE_CC y THUMBNAIL de contenido obvio, pero pueden aparecer otros bundles como METADATA, ORE y TXT y seguro que me dejo alguno. De hecho, si en el fichero Contents se nombra un nuevo bundle, DSpace creará el objeto con el fichero correspondiente incluido en ese bundle. Queda luego la tarea de modificar DSpace para que incorpore tratamientos diferenciados a los ficheros del nuevo bundle así creado…porque, claro está, el usuario con permisos normales de DSPACE solo podrá ver los ficheros contenidos en el bundle ORIGINAL.

Un ejemplo de Contents (por ahí en medio hay tabuladores, ya que el fichero content está delimitado con tabuladores)

license.txt     bundle:LICENSE
Fichero1.pdf   bundle:ORIGINAL
Fichero2.pdf   bundle:ORIGINAL

Dublin_core.XML

A su vez el dublin_core.xml será algo similar a…

<dublin_core>
<dcvalue element="contributor" qualifier="author">Nombre</dcvalue>
<dcvalue element="language" qualifier="iso">es_ES</dcvalue>
<dcvalue element="title" qualifier="none">Título</dcvalue>
...
</dublin_core>

Bien, pues una vez tengamos esta super-estructura formada llega el momento de pelearse con el comando import. Pero eso es otra historia.

XMLUI o JSPUI??

Enviado por cfernandez el 2011/12/09 6 comentarios

Una cuestión que normalmente surge en las nuevas instalaciones (o migraciones ) de DSpace es ¿qué interface usar?.

Anteriormente a Dspace 1.5, la interface única de JSPUI simplificaba la elección :), y este es el motivo de la amplia difusión de los interfaces JSPUI, pero con la aparición de XMLUI es una pregunta recurrente. Intentaremos proporcionar alguna luz, o quizá simplemente alimentar el debate al respecto… Empecemos:

XMLUI permite de forma extremadamente simple, mucho más que JSPUI, aplicar apariencias radicalmente diferentes a distintas colecciones, lo que resulta de especial relevancia en determinados ámbitos, pensemos en distintas tipologías de objetos por colección, o en diferenciación de la imagen institucional o… motivos diversos los hay, y en ocasiones son causas suficientes para decantarse por XMLUI…

Por otra parte, existe una sensación general de que los nuevos desarrollos de Dspace se alejan de JSPUI, pero nos gustaría confirmarlo con hechos. Algunas de las nuevas funcionalidades presentes en Dspace 1.8 están soportadas únicamente en XMLUI, como el Configurable Reviewer Workflow. De hecho, según se encarga de recordarnos la documentación del 1.8, la activación de esta función «deshabilita» el JSPUI. (realmente no lo deshabilita, simplemente deja de funcionar, pues se altera el esquema de la base de datos…). Y en versiones anteriores, recordamos el Authority Control en Dspace 1.6, la versión JSPUI nos produjo más quebraderos de cabeza que satisfacciones, hablando en plata. Y algunas de las características de un «tema» como Mirage, incluso considerando sus bugs pre-1.8, son inalcanzables, pensamos, para JSPUI.

Pero esto también pudiese ser cierto a la inversa. Al menos hasta la aparición de la versión 1.7, la interfaz de administración de XMLUI iba por detrás de la disponible en JSPUI. Y recordemos que la funcionalidad base para usuarios generales de JSPUI sigue siendo objetivo, a mi entender, aún no alcanzado, de los temas XMLUI como el «Classic», sin efectuar desarrollos específicos. Lo cual nos lleva al siguiente punto, modificar y desarrollar la interfaz de usuario en una u otra interfaz.

Desarrollar en XMLUI es sustancialmente más complejo que en JSPUI, para funcionalidades «estándar» si es que eso existe. La curva de aprendizaje de XMLUI es mucho más costosa y esforzada, sinceramente. La mezcla de funciones java, seguido de una cadena de transformaciones XSL, todo embutido en un framework Apache Cocoon, resulta compleja de entender. XMLUI no funciona bajo una lógica «una plantilla-una página», sino bajo una lógica «diversas plantillas- una página» y, simultáneamente «una plantilla- diversas páginas». Lo cual complica la concepción del sistema así creado…

Bien, existen más diferencias, y sobre todo más opiniones sobre las mismas, que las planteadas en la breves líneas anteriores

¿y Vds, que opinan?.

Mapear Items entre colecciones

Enviado por cfernandez el 2011/07/22 Comentarios desactivados

En la gestión de Dspace normalmente aparece la necesidad de mantener estructuras complejas de comunidades y colecciones, en las que normalmente aparece algún tipo de solapamiento… Derivado de este hecho, se requiere que determinados objetos (items) pertenezcan a más de una colección, lo que habitualmente se denomina mapear un item a múltiples colecciones.

Existen básicamente tres formas de realizar este mapeo: Mediante la Interfaz de usuario; con la función de Batch Metadata Editing y modificando directamente la Base de Datos de Dspace. La selección entre una opción u otra deberá realizarse teniendo en cuenta principalmente el número de items a mapear y la familiaridad o conocimiento que tengamos de cada una de las tres alternativas existentes.

Como características que debemos tener en cuenta, el item mapeado no cambia sus privilegios, pues mantiene las autorizaciones que «heredó» en el proceso de inclusión a su colección original. Y relacionado con este aspecto, un administrador de colección no podrá mapear items si no tiene privilegios en la colección origen, es decir necesita ser administrador de las colecciones origen y destino, evidentemente…

Interfaz de Usuario

El nombre de la función en los menús es mapeador (relacionador) de items.

Debemos estar autenticados como administradores (generales o de colección) y navegar a la colección a la que queremos mapear los items. En el menú (herramientas de administración en JSPUI y menú de contexto de colección en XMLUI) nos aparecerá la opción de relacionar items.

Podemos efectuar una búsqueda y sobre la pantalla de resultados efectuar el mapeado o directamente proporcionar el handle del item a mapear.. El «mapeador» de items permite además «des-mapear» los items que seleccionemos.

Pros: Simple de manejar, GUI directa y comprensible por el personal de administración de la colección
Cons: un poco engorroso cuando se trata de hacer trabajos de mapeo entre múltiples colecciones- items

Batch Metadata Editing.

A partir de la versión 1.6, tenemos la opción de hacer cambios amplios a los metadatos de nuestro Dspace a través de la exportación a CSV, edición del CSV e importación de la magnífica herramienta que es el Batch Metadata Editing. Junto con los metadatos, la herramienta muestra la o las colecciones en las que está incluido un objeto.

Ejemplo:

La exportación de un item, nos proporciona, además de los metadatos del mismo, la siguiente información (segunda columna de nuestro CSV, habitualmente):

collection: 123456789/15, es decir el item está archivado bajo la colección de id 123456789/15.

Para mapearlo, (o incluso moverlo) a otra colección simplemente concatenamos a la colección «primaria» el id de la otra colección a la que queremos asociar el objeto. Así, en la columna collection ponemos 123456789/15||123456789/33 y cuando hagamos la importación de metadatos habremos mapeado el item a la colección de id 123456789/33

Pros: Permite efectuar el mapeo de items-colecciones junto con el resto de tareas de limpieza, mantenimiento y curación de metadatos. Un modelo «cuasi-batch»

Cons: requiere de la versión 1.6 y superiores. Y haber manejado previamente la herramienta Batch Metadata Editing. Es simple, pero no es obvia.

Base de Datos
Anteriormente a la versión 1.6 esta era la vía «dura», usada en vez de el mapeo vía UI, si se requería el mapeo de un número considerable de items. Si se dispone el conocimiento necesario de base de datos, se puede mapear una colección adicional en un item insertando una fila adicional en la tabla «collection2item».

Cada fila de dicha tabla contiene pares de collection_id y item_id, siendo el collection_id el identificador de la colección (de la tabla «collection» y el item_id es el identificador interno de Item (no es el handle, se puede obtener de la página Editar Item).

Pros: Directo, puesto que en modo batch modificamos la BD. Permite cambios masivos a nuestos items y colecciones.
Cons: Sólo para usuarios técnicos avanzados ya que requiere conocimientos de SQL, por lo que se recomienda encarecidamente hacer un backup previo de la BD.

« Página anterior | Página siguiente »

Author Archives: cfernandez - Paginas 4

Contenidos