Archivos de Tags: handle

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

Instalar un servidor de handle en Dspace

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