Búsquedas en Dspace

Posted by ebrana on 2012/06/10 None comments

En DSpace, hasta la aparición de Discovery, existían dos tipos de búsqueda, la Simple y la Avanzada. La diferencia entre ambas radica en que en el caso de la Búsqueda Simple, el usuario introduce una palabra y el motor de búsqueda busca en todos los campos de los items (autor, título, fecha, etc), devolviendo cualquier coincidencia hallada, mientras que en la Búsqueda Avanzada el usuario puede, a través de una serie de filtros, indicar los campos donde buscar y combinarlos con el uso de los conectores lógicos AND, OR o NOT, depurando de esta manera los resultados de la búsqueda y adaptándolos a sus intereses. Todo ello aplicando los filtros que tenemos definidos en el search.analyzer, y que ya hemos explicado en otro post.

La Búsqueda Simple es rápida y directa, pero tiene el inconveniente de que si la consulta no es muy específica, los resultados pueden ser demasiado amplios, mientras que los obtenidos con la Búsqueda Avanzada pueden refinarse más.

En ambos casos, DSpace nos ofrece realizar una búsqueda en Todo DSpace, o bien restringirla a una Comunidad o Colección específica, cambiar el número de resultados que aparezcan en cada página y ordenar dichos resultados por relevancia, título, fecha de publicación o fecha de envío, tanto en orden descendente como en orden ascendente.

Para las búsquedas de múltiples términos, el motor de búsqueda de DSpace utiliza por defecto el operador booleano OR, que requiere que al menos uno de dichos términos esté presente. Este operador booleano de búsqueda utilizado por defecto, puede ser personalizado modificando la siguiente línea en el archivo dspace.cfg:

search.operator = OR

En caso de introducirse el operador AND, en las búsquedas de múltiples términos se requerirá que todos ellos estén presentes.


Modificando el Buscador Avanzado

El combo de selección de campos de búsqueda del Buscador Avanzado puede ser modificado para que incluya nuevos campos o se eliminen los existentes en la herramienta por defecto. Para ello, en el fichero dspace.cfg hay que buscar el bloque que comienza por ##### Fields to Index for Search ##### , donde pueden observarse varias líneas como las siguientes:

search.index.1 = author:dc.contributor.*
search.index.2 = author:dc.creator.*
search.index.3 = title:dc.title.*
search.index.4 = keyword:dc.subject.*
search.index.5 = abstract:dc.description.abstract

Si se desea añadir un nuevo campo de búsqueda al combo, hay que añadir una línea del tipo search.index.#. Mantener el ordinal de los índices de la forma 1,2,3,4… sin saltos y bien ordenado.. Para que la etiqueta mostrada sea comprensible por el usuario, sería necesario, además, modificar los ficheros Messages.properties y advanced.jsp o messages.xml correspondientes.

En el caso de modificar el combo de selección de campos de búsqueda, es importante reindexar DSpace para evitar que la búsqueda funcione de forma anómala, ejecutando el comando:

[dspace]/bin/dspace index-init

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

Posted by elorenzo on 2012/06/02 4 comments

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)

5as Jornadas OS-Repositorios

Posted by snieto on 2012/05/26 None comments

Estuvimos en las 5as Jornadas OS-Repositorios que se celebraron, del 23 al 25 de mayo, en la E.T.S. Ingeniería de la Universidad del País Vasco, en Bilbao

En la conferencia inicial del evento, realizada por Reme Melero, se aportaron datos sobre el estado del acceso abierto en España en el período 2006-2012, un interesante ranking nacional y sobre el uso de los diferentes software de repositorios institucionales, con DSpace como el más usado en instalaciones nacionales.

image

Como aspecto recurrente durante toda la conferencia, se estudiaron y discutieron los repositorios de datos de investigación, siguiente frontera de los repositorios institucionales. Los retos principales fueron desmenuzados por Keith Jeffery, Presidente de EuroCRIS, en la conferencia invitada.

Durante los tres días del congreso, sucesivas presentaciones por parte de responsables de repositorios institucionales nos muestran las líneas de trabajo y evolución activas en sus instituciones. Nos interesaron especialmente (y seguro que me dejo alguno, perdón):

  • El workshop que Pedro Príncipe, Universidade do Minho, ofreció sobre las Nuevas directrices OpenAIRE y OpenAIREplus.
  • La presentación de Toni Prieto Jiménez y Jordi Serrano, de la Politècnica de Catalunya sobre los múltiples flujos de trabajo e integraciones en la gestión de su repositorio institucional, UPCommons. Apretando las interfaces DSpace hasta el límite.
  • La adaptación de DSpace para la visualización de objetos digitales complejos en la Universitat de València, que realizaron José Manuel Barrueco y José Angel Navalón.
  • La ponencia de Miquel Termens (Universitat de Barcelona) sobre los retos técnicos para la preservación de los repositorios institucionales.

image

En general, nos pareció que determinadas presentaciones (se adoptó el modelo de 6 minutos pechakucha) se quedaron cortas. Nos quedamos con ganas de una explicación un poco más amplia de las siguientes sesiones:

  • Linked Open Data en el repositorio de la Universidad de Salamanca, por Tránsito Ferreras
  • El Archivo Digital para la Docencia y la Investigación de la UPV/EHU: por Alcira Macías y Pablo de Castro
  • La presentación de Javier Gómez sobre el autoarchivo en el repositorio institucional de la Universidad de Alicante. Y los interesantes comentarios sobre las dificultades del autoarchivo en la mayoría de los repositorios representados, que nos debería llevar a todos a una reflexión…
  • Los retos, evolución y mecanismos de introducción de contenidos en Dadun, Universidad de Navarra, por Rocío Serrano-Vicente.
  • y la sesión de Leticia Barrionuevo sobre el Control de Autoridades en Buleria, el repositorio de la Universidad de León

Y por supuesto, el resto de ponencias, conferencias y sesiones..Un agradecimiento especial a la Universidad del País Vasco por acogernos y nos veremos en la próxima.

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

Posted by elorenzo on 2012/05/16 None comments

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

Posted by elorenzo on 2012/05/11 None comments

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?

Activar Mirage y Discovery

Posted by snieto on 2012/05/03 9 comments

Una de las principales propuestas de DSpace 1.7 fue la funcionalidad de búsquedas Discovery. Desarrollado, y cedido a la comunidad DSpace, por la empresa AtMire, el sistema de búsquedas por facetas (faceted search) es de indudable atractivo para las nuevas instalaciones y posiblemente imprescindible en instalaciones con un número de items elevado, pues las facilidades de búsqueda en esos entornos necesitan ser “reforzadas”.

Faceted search, also called faceted navigation or faceted browsing, is a technique for accessing information organized according to a faceted classification system, allowing users to explore a collection of information by applying multiple filters (wikipedia)

Para poder manejar correctamente el nuevo sistema de búsquedas, se distribuye conjuntamente con la release, el tema Mirage (y ahora debe quedar claro que hablamos de XMLUI, no de JSPUI) como complemento visual de la funcionalidad Discovery.

En este post va a proceder a explicar como se hace para activar Mirage y Discovery en nuestro Dspace 1.7 o 1.8.

ACTIVACION DE MIRAGE

Tendremos que ir al fichero xmlui.xconf ubicado en [dspace-instalación]/conf/xmlui.xconf

Ahí vamos a quitar los comentarios referentes a la linea

<!–<theme name=”Atmire Mirage Theme” regex=”.*” path=”Mirage/” />–>

Por lo que nos quedaría de la siguiente forma

<theme name=”Atmire Mirage Theme” regex=”.*” path=”Mirage/” />

Una vez hecho esto, debemos comentar el tema que se estuviese usando, normalmente el tema Reference, es decir:

<theme name=”Default Reference Theme” regex=”.*” path=”Reference/” />

y añadirle los comentarios, dejándola así.

<!– <theme name=”Default Reference Theme” regex=”.*” path=”Reference/” /> –>

Por ahora no hemos hecho mas que cambiar un tema por otro. Llega ahora la hora de la verdad, activar el faceted search.

ACTIVACIÓN DE DISCOVERY

Activar Discovery supone en primer lugar sustituir las transformaciones (aspects) relacionadas con la búsqueda de XMLUI por las nuevas transformaciones que supone Discovery. Para ello, en el fichero xmlui.xconf ubicado en la ruta [dspace-instalación]/conf/xmlui.xconf tenemos que desactivar la linea referente al uso del SearchArtifact, y activar la correspondiente al Discovery. Así, hay que comentar la linea siguiente:

<aspect name=”Searching Artifacts” path=”resource://aspects/SearchArtifacts/” />

quedando la línea de la siguiente forma

<!–<aspect name=”Searching Artifacts” path=”resource://aspects/SearchArtifacts/” />–>

y siendo consecuentes, descomentar la línea de Discovery:

<!–<aspect name=”Discovery” path=”resource://aspects/Discovery/” />–>

quedando la línea de la siguiente forma

<aspect name=”Discovery” path=”resource://aspects/Discovery/” />

El siguiente paso que tenemos que modificar el fichero dspace.cfg, cambiando un par de parámetros:

event.dispatcher.default.consumers

y añadirle a la derecha el parámetro discovery quedando de la siguiente forma.

event.dispatcher.default.consumers = search, browse, discovery, eperson, harvester

La siguiente línea a tocar es la siguiente:

recent.submissions.count

En este caso pondremos el parámetro a cero quedando así la línea:

recent.submissions.count=0

Ya estamos finalizando. El último fichero que debemos comprobar es el dspace-sorl-search.cfg, ubicado en la misma carpeta que los anteriores ficheros. Simplemente chequear que la dirección de nuestro dspace/solr coincide con la especificada en el fichero ¿aún no habíamos dicho que Discovery se apoya en SOLR?… Aseguraros que SOLR está desplegado y funcionando en vuestro Tomcat.

Bien, buscamos la línea:

solr.search.server = http://localhost:8080/solr/search

y ahí debemos comprobar que el puerto de acceso es correcto, lo cambiamos al nuestro, 8180, 8888, el que usemos:

solr.search.server = http://localhost:8180/solr/search

Cuidado, que hay una serie de problemas reportados en JIRA respecto el uso de 127.0.0.1 y el uso de localhost, por lo que quizá se tenga que tantear. (CORREGIDO gracias a la aportación de Javier, de la Universidad de Piura, Perú)

Una vez editados estos ficheros, hay que reiniciar el tomcat para que se apliquen los cambios y ejecutar en línea de comandos el programa update-discovery-index para que se actualicen los índices del Discovery.

[dspace-instalación]/bin/dspace update-discovery-index

Una vez ejecutada, podemos ver los cambios en nuestro Dspace, un magnífico DSPace con búsqueda por facetas:

Ah, un último punto… las etiquetas/textos que usa Discovery no están traducidas, pues no se incluyen en el messages-es.xml del núcleo de Dspace. La opción más razonable es localizar su messages.xml en las fuentes de dspace-discovery y copiarlas, es decir añadirlas, al messages_es.xml que usemos de forma habitual (una vez traducidas, claro..)

Suerte (y gracias a Atmire…)

Uso de identificadores persistentes

Posted by elorenzo on 2012/04/20 None comments

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 arrancarlo antes de hacer el sitio público, pues google indexará los handles “antiguos” y luego tendremos que deshacer el entuerto. Igualmente, a nivel interno, los logs, y por consiguiente, las estadísticas se referirán a identificadores cambiados..

Estructura de los archivos de importación de items

Posted by elorenzo on 2012/02/23 None comments

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

Posted by elorenzo on 2011/12/09 4 comments

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

Probando DSpace 1.8.0

Posted by snieto on 2011/11/22 None comments

El 4 de noviembre de 2011 se liberó la versión 1.8.0 del software DSpace.

Las características más reseñables de esta versión figuran aquí: https://wiki.duraspace.org/display/DSPACE/DSpace+Release+1.8.0+Notes

Pero conviene advertir de los cambios sustanciales respecto a las versiones 1.7.x y anteriores: La más importante es la separación de la configuración en múltiples ficheros. Recordemos que hasta ahora TODA la configuración residía en el fichero “dspace.cfg”, bien, pues a partir de la versión 1.8.0, este fichero se disgrega y separa la configuración de cada módulo. Así pues, tendremos:

Otro factor importante a destacar es el CAMBIO DE COMPORTAMIENTO en el despliegue al realizar el “ant“. Hasta ahora el comportamiento por defecto era no aplicar los cambios en la configuración. Ahora pasa al contrario. Por defecto se sobreescribe el/los ficheros de configuración.

Algunas de las nuevas características en esta versión son

  • Herramientas y plugins de curación/preservación – tanto en la interfaz de usuario como a través de la línea de comandos.
  • Cliente SWORD y nueva versión del servidor SWORD
  • Mejoras en el acceso y conexión a las licencias CREATIVE COMMONS, en el buscador Discovery, etc
  • Un nuevo sistema de workflows configurables (solo para interfaz XMLUI)
  • Nuevas funcionalidades a través de la edición masiva de metadatos