5as Jornadas OS-Repositorios

Enviado por el 2012/05/26 Comentarios desactivados en 5as Jornadas OS-Repositorios

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?

Enviado por el 2012/05/16 Comentarios desactivados en Structure-builder, un comando para cómodos ¿o dubitativos?

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 el 2012/05/11 Comentarios desactivados en La traducción al español de Dspace 1.8 ya está disponible

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

Enviado por el 2012/05/03 9 comentarios

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

Enviado por el 2012/04/20 Comentarios desactivados en Uso de identificadores persistentes

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 el 2012/02/23 Comentarios desactivados en Estructura de los archivos de importación de items

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

Probando DSpace 1.8.0

Enviado por el 2011/11/22 Comentarios desactivados en Probando DSpace 1.8.0

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

 

Instalar un servidor de handle en Dspace

Enviado por el 2011/10/18 2 comentarios

A continuación se van a mostrar los pasos para poder instalar un servidor de handle en un DSpace.

1- Seguridad perimetral: Apertura de puertos 2641 y 8000 TCP/UDP para poder realizar el proceso de registro con la entidad que proporciona el handle: CNRI.

2- Solicitud de un handle a handle.net por lo que tendremos que rellenar un cuestionario y realizar el registro de un usuario (previo pago) para así obtener un número de handle que luego lo usaremos en DSpace.
http://www.handle.net/registration_agreement.html?
3- Con el número en nuestro poder tenemos que crear el servidor de handle, para ello ejecutamos la siguiente orden en un terminal

[dspace]/bin/dspace make-handle-config [dspace]/handle-server


NOTA: En las preguntas formuladas por el script existe una relativa a la encriptación de las contraseñas. En nuestro caso una respuesta afirmativa produjo un error posterior por lo que en un segunda ejecución modificamos esta respuesta a NO. Es decir, SIN encriptación.

4- Una vez creado el server en la carpeta del handle-server tenemos un fichero .zip que se ha de enviar por mail para que sea validado.

Asunto: Número de handle que hemos comprado Ejemplo 1000

Attach: sitebndl.zip

Cuerpo del mensaje: «Saludarla porque es una persona y siempre sienta bien que te saluden, además un gracias ayuda siempre de mucho»
4.1- mientas esperas que te validen el servidor podemos ir modificando los siguiente ficheros:

dspace.cfg

Ubicación: [dspace-dir]/dspace/config/dspace.cfg

Ahí tenemos que cambiar en la propiedad handle.prefix por el número que nos dieron (suponiendo que fuera el 100000 sería así)

handle.prefix= 100000
config.dct


Añadir las siguientes líneas al fichero. Hay que insertarlas al final despues del ultimo texto escrito y manteniendo las comillas dobles

"storage_type" = "CUSTOM"
"storage_class"="org.dspace.handle.HandlePlugin"

5- Al poco tiempo, si hay suerte en 1 hora te mandan la confirmación por lo tanto solo queda arrancar el servidor handle:
(Antes de ello por si acaso reiniciamos el tomcat aunque no suele ser necesario)

[dspace_dir]/bin/start-handle-server

NOTA: Es recomendable incluir la rutina anterior en un cronjob dado que si se reinicia la máquina está bien no tener que acordarse de arrancar este proceso.

Posibles fallos

  • Sino arranca comprobar que los puertos 8000 y 2642 estén correctamente abiertos
  • Encriptación de las claves.
  • Una vez arrancado el servidor de handle comprobar en el fichero error.log (ubicado en la carpeta handle-server) si hay algun problema.

6- Actualizar los handle antiguos (Solo en caso de tener items con el antiguo handle)

Se puede dar el caso de que apliquemos nuestro nuevo handle y que ya haya items con el handle antiguo, es decir, que los nuevos items que ya introducimos vendrán con el nuevo handle mientras que los items antiguos tendrán el que viene por defecto es decir el 123456789.
Para actualizar el antiguo handle al nuevo hay que ejecutar la siguiente línea en un terminal:

[dspace]/bin/dspace update-handle-prefix antiguo_handle nuevo_handle

EJ (suponiendo que el nuevo handle sea 10000):

[dspace]/bin/dspace update-handle-prefix 123456789 10000


Más información en:
https://wiki.duraspace.org/display/DSDOC/Installation#Installation-TheHandleServer

 

 

Métodos apilados de autenticación

Enviado por el 2011/10/18 Comentarios desactivados en Métodos apilados de autenticación

Con esta entrada veremos cómo apilar consecutivamente distintos métodos de autenticación que ofrece DSpace.

Posiblemente durante nuestra configuración del sistema DSpace nos hemos encontrado con que queremos activar el sistema de autenticación LDAP y, una vez configurado y activado, vemos que desaparece nuestra antigua forma de acceso al DSpace.

Es por ello que DSpace ha creado un sistema de pila, métodos stackables de autenticación para que pueda convivir más de un tipo, de forma que si uno falla pasa al siguiente.

Si queremos activar ambos sistemas de autentificación, es decir el que viene por defecto, la autenticación interna,  en Dspace y el sistema por LDAP no hay más que editar el fichero dspace.cfg ubicado en el directorio siguiente:

[dspace-dir]/dspace/config/dspace.cfg

y  buscamos el plugin correspondiente para activarlo:

plugin.sequence.org.dspace.authenticate.AuthenticationMethod

Ahí cambiamos su valor por lo siguiente:

plugin.sequence.org.dspace.authenticate.AuthenticationMethod = \       
org.dspace.authenticate.LDAPHierarchicalAuthentication,\       
org.dspace.authenticate.PasswordAuthentication

De tal forma que ahora al identificarnos en dspace nos aparecerá una nueva ventana en la que nos indicará si queremos usar el LDAP como medio de autentificación o el que venía por defecto.