Warning: Constant WP_MEMORY_LIMIT already defined in /home/elorenzo/domains/arvo.es/public_html/dspace/wp-config.php on line 94
Documentación no técnica | Hablando de DSpace - Part 6

Archivos de Categoría: Documentación no técnica - Paginas 6

Funcionando con varios DSpace

Enviado por el 2012/07/19 Comentarios desactivados en Funcionando con varios DSpace

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.

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?

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

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.

Mapear Items entre colecciones

Enviado por el 2011/07/22 Comentarios desactivados en Mapear Items entre colecciones

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.

el contexto de OAI-PMH

Enviado por el 2011/06/17 Comentarios desactivados en el contexto de OAI-PMH

La Iniciativa de Archivos Abiertos, (Open Archives Initiative , OAI)  intenta resolver la interoperabilidad de las bibliotecas en un esfuerzo para mejorar el acceso a las publicaciones especializadas y resultados de investigación en general.  La solución adoptada, a través de la recolección de metadatos con el  protocolo OAI-PMH,   soportar el flujo de metadatos entre bibliotecas y proveedores de servicios, con el fín de proporcionar a los usuarios servicios de mayor alcance que los que cada biblioteca puede proporcionar  aisladamente.

Los esfuerzos por conseguir sistemas que posibilitasen las búsquedas de contenidos se centraron inicialmente en sistemas de búsqueda federada, en que la consulta del usuario se envía a los sistemas remotos  y las respuestas de éstos se  procesan en tiempo real. Un ejemplo de este enfoque es  la adaptación del protocolo cliente-servidor Z39.50.

Posteriormente surgieron soluciones centradas en la recolección (harvesting) de metadatos. El precursor es el sistema Harvest (creado en el 1995, discontinuado el desarrollo en 2005), en un intento de crear un índice central de búsqueda sobre websites y otros sistemas recolectados. El equipo de Harvest, participó posteriormente en la redacción del protocolo OAI-PMH.

La primera versión del Protocolo OAI-PMH, (ó OAIMH como es citado a veces)  se libera el 21 de enero del 2001, resultado de más de un año de trabajo a partir de la Reunión de Santa Fe, octubre de 1999, en que se presenta el marco de interoperabilidad técnica y organizativa  requerido para facilitar la distribución de los contenidos de archivos digitales.  La segunda versión,  PMH V2.0,  se libera en junio de 2002

OAI-PMH separa claramente los proveedores de datos (en sentido general  bibliotecas o archivos)  de los proveedores de servicios (p.ej. Agregadores),  aunque no hay impedimento conceptual en la coexistencia de roles en un único agente.  En este sentido,  el protocolo no trata de la interoperabilidad igual-a-igual entre Archivos, sino que considera la interrelación entre archivos digitales y agentes con capacidades de agregación y recopilación, éstos previsiblemente ofreciendo servicios de valor añadido a los usuarios finales.  Comentaremos en un próximo post algunas de las curiosas implantaciones derivadas de este doble rol.

OAI-PMH no está limitado a metadatos en formato DC, aunque esta malinterpretación está algo extendida. El estándar exige al menos el soporte de Dublin Core, pero las comunidades de conocimiento específico podrían (y deberían) usar recolecciones basadas en conjunto de metadatos de mayor precisión semántica.

Otra de las concepciones equivocadas sobre PMH es considerar que la recolección se realiza a nivel de contenido (documentos, ficheros, imágenes). Realmente,  hasta la fecha, PMH es un protocolo de intercambio de metadatos, por lo que los agregadores incorporarían referencias a la localización original de los contenidos (de ahí la importancia de los identificadores persistentes).

Para la agregación de objetos digitales, no solo los metadatos descriptivos, debemos recurrir a OAI-ORE, OAI Object Reuse and Exchange . El soporte a este protocolo está incorporado a la versión 1.6 de DSpace.

Todavía hoy está abierta la pregunta sobre la utilidad de ambos enfoques: búsqueda federada vs recolecta de metadatos. No obstante la vigencia de las implementaciones de OAI-PMH es innegable. Posiblemente la sencillez del protocolo, y por tanto la posibilidad de soportarlo en  sistemas de muy diversa complejidad,  hayan promovido su difusión y su uso en proyectos de la escala de Europeana, a partir de los resultados del proyecto DRIVER.

SWORD

Enviado por el 2011/04/11 Comentarios desactivados en SWORD

¿Qué es?
Sword es un protocolo usado en repositorios para poder realizar envios de contenidos desde otras aplicaciones. Sus siglas corresponde a Simple Web-service Offering Repository Deposit, es decir un Servicio Web simple que ofrece sevicios de depósito en un repositorio.

¿Para qué sirve?
Activar el protocolo Sword en el repositorio DSpace nos puede permitir acceder, mediante un servicio web, a realizar envíos directos al repositorio. Lo interesante de esta práctica es que se puede configurar el servicio de envío para poder simplificar u omitir pasos del proceso de envíos y que cualquier usuario registrado o no registrado en el repositorio pueda insertar sus contenidos de forma simple.
Poniendo un ejemplo, en un repositorio sólo los usuarios definidos pueden dar de alta contenidos. Si en este repositorio se quisiese ampliar el servicio de envíos, tendríamos que definir una cuenta por usuario, proceso realmente tedioso, complicado por el proceso de establecimiento de permisos, la correcta definición de colecciones destino, etc… El otro problema de este modelo de registro previo es que a priori no sepamos qué usuarios van a subir información.
En este escenario, una opción a valorar es habilitar el protocolo SWORD y habilitarlo en una Web en la cuál, cualquier usuario pueda subir información directamente al repositorio sin necesidad de registrarse. De esta forma no nos preocuparía el número de usuarios o si tenemos que darles permisos, ya que ese proceso se gestionaría por la apliación web. Posteriormente al depósito, un usuario cualificado del repositorio, p.ej. bibliotecario, se encargaría de validar y complementar los datos recibidos.

Clientes SWORD
easydeposit: http://easydeposit.swordapp.org/
BibApp: http://bibapp.org/
Open Journal System:  http://pkp.sfu.ca/?q=ojs
Microsoft Word: http://research.microsoft.com/en-us/projects/authoring/

Repositorios que aceptan el protocolo SWORD
arXiv: http://arxiv.org/
Dspace: http://www.dspace.org/
EPrints: http://www.eprints.org/
Fedora: http://fedoraproject.org/es/
Intralibrary: http://www.intrallect.com/
Microsoft Zentity: http://research.microsoft.com/en-us/projects/zentity/