Author Archives: Eva Braña

Preservación e integridad de ficheros en DSpace

Enviado por Eva Braña el 2018/05/17 Comentarios desactivados

La preservación y la integridad de los ficheros almacenados en un sistema Dspace preocupan con frecuencia, y con razón, a los gestores de los repositorios. Intentaremos despejar las dudas más frecuentes sobre el comportamiento del software DSpace al respecto.

Una función hash es, básicamente, un algoritmo criptográfico que aplicado a un fichero produce como resultado una cadena alfanumérica única, permitiendo determinar, por comparación con valores anteriores de la cadena, los cambios en el mismo, la integridad del fichero. DSpace realiza el cálculo del valor hash de cada fichero almacenado en el sistema, incluidos los ficheros de licencia, etc.. Cuando se sube un fichero (en los cambios de estado submitted, approved y made available), se calcula automáticamente su valor hash, almacenándose en la tabla de bitstreams:

arvo.pdf   checksum: d4c4979a5f4f34f6158a2620f0d5710c (MD5)

license_rdf   checksum: 603b6a1a20b0b67b338ea745cbacb74f (MD5)

¿Y qué sucede entonces ante la modificación de un fichero? Para responder a esta pregunta, en primer lugar debemos aclarar que en DSpace un fichero en realidad no se modifica, sino que se sustituye por otro diferente (borrándose el antiguo o versionándolo) calculándose automáticamente el hash del nuevo fichero y generándose una nueva entrada en la tabla de bitstreams. Con este proceso se asegura que la integridad de cada fichero queda reflejada en la tabla bitstreams.

Parte de esta información se graba adicionalmente en el metadato dc.description.provenance. Importante tener en cuenta que este metadato sólo se graba en la subida inicial del fichero, no en las acciones de borrado o sustitución de fichero que pudieran ser realizadas posteriormente por un administrador.

dc.description.provenance	Submitted by xxxxxx (name@mail.com) on 2008-02-11T11:46:16Z No. of bitstreams: 1 RSCAS_DL_2005.pdf: 185727 bytes, checksum: 4d46d9280e930bf6a024f6d39f3a74bb (MD5)

Existe además el comando checker (cuya ejecución se programa normalmente a intervalos regulares mediante crons) que permite comprobar que los hash de los ficheros no han cambiado y cuyo resultado y fecha de ejecución se almacenan en la tabla ckecksum_history:

[dspace]/bin/dspace checker

Adicionalmente, podríamos reseñar que en los logs de DSpace se registran las acciones realizadas sobre los bitstreams (añadir nuevos y borrar los existentes) y los usuarios que las han realizado. Pero hay que señalar que interpretar los logs directamente es una tarea bastante ardua que requiere del análisis de ingentes cantidades de datos sobre la historia/logs del repositorio. Una vía que no nos atreveríamos a recomendar.

En caso de detectarse la alteración o algún problema con un fichero, se deberá recurrir a un backup del assetstore (o mas infrecuentemente, backups AIP). Este no es un proceso de DSpace propiamente dicho, sino de las políticas de recuperación de cada repositorio. Cada repositorio deberá plantearse los modos y medios de recuperación de la información ante eventuales pérdidas.

Finalmente, señalar que DSpace no comprueba la existencia de virus en los ficheros de forma estándar, pero mediante la implantación de módulos específicos es posible analizar los ficheros del repositorio en busca de virus, avisando a publicadores y administradores de potenciales riesgos en sus ficheros y eventualmente restringiendo el archivo de los mismos.

Expectativas de los usuarios sobre las búsquedas en DSpace

Enviado por Eva Braña el 2015/11/02 Comentarios desactivados

A pesar de los grandes avances que se han sucedido en las herramientas de búsqueda y recuperación de la información en los Repositorios DSpace (búsqueda facetada, Discovery, evolución del motor de búsqueda SOLR, etc), el excesivo número de registros recuperados tras una búsqueda, comúnmente conocido como “ruido”, continúa siendo, sin lugar a dudas, el principal problema de los usuarios. La necesidad de un cribado posterior desconcierta en muchos casos al usuario, por lo que el dilema está servido: ¿compensa descubrir tanta información?

Lo que el usuario de DSpace demanda del buscador, es que sea capaz de satisfacer su necesidad de información no sólo con la verosimilitud en los resultados ofrecidos, sino también con su pertinencia, logrando un equilibrio entre el descubrimiento de lo desconocido y la recuperación de lo realmente apropiado.

Por ejemplo, en un supuesto de búsqueda, entra dentro de lo verosímil que un usuario introduzca en el cajetín de búsqueda “frío” y recupere todos aquellos registros que contienen “frío” en el texto completo o en alguno de los metadatos configurados en los índices de búsqueda. Si, en su defecto, el sistema lanza una consulta con “frÄo”, los resultados presentarán un problema de verosimilitud.

La pertinencia, por su parte, ocupa la centralidad de las preocupaciones de los usuarios, asumiendo que la verosimilitud está más o menos acotada y ha sido eficazmente tratada con la configuración inicial del buscador (selección del analizador de búsqueda, stemmers, lematización, diacríticos, orden de los filtros de cribado, palabras vacías y un largo etcétera). El tratamiento de la pertinencia es un asunto que se puede atajar con las Ayudas DSpace, si bien han sido pocas las instituciones que se han molestado en aquilatar las ayudas que DSpace ofrece con una instalación estándar. Y probablemente ése sea uno de los principales problemas: los usuarios se encuentran con una herramienta de búsqueda poderosísima apenas explicada, al menos, en los términos que necesitan.

Por ello, cabe plantearse las siguientes preguntas: ¿tiene sentido cambiar el operador de búsqueda por defecto de DSpace cuando el usuario desconoce su funcionamiento efectivo? ¿Compensa configurar un mayor número de filtros si los usuarios desconocen cómo se pueden combinar para obtener un refinamiento de los resultados más preciso?

Afortunadamente, el perfil técnico de DSpace conoce el lenguaje, la sintaxis, y el modo de operar el código para lograr la verosimilitud de los resultados de las búsquedas, mientras que el perfil administrador sabe gestionarla y tiene la capacidad de comprenderla y traducirla para alcanzar la pertinencia. Conjugando adecuadamente ambos aspectos, se puede mejorar notablemente la satisfacción de los usuarios con el buscador de DSpace.

Derechos de acceso y permisos en DSpace (Parte 2)

Enviado por Eva Braña el 2015/08/24 Comentarios desactivados

En este post continuamos hablando sobre derechos de acceso y permisos en DSpace, y según lo prometido, vamos a abordar las principales demandas de los usuarios a este respecto. ¿Y cuáles son esas demandas?

De la misma forma que se entiende que la introducción de una fecha de embargo hace que el fichero adjunto quede no disponible para usuarios anónimos hasta dicha fecha, es evidente que al usuario le gustaría que al seleccionar las opciones «restrictedAccess» y «closedAccess», los ficheros quedasen de forma automática como no disponibles para los usuarios sin permisos. Asimismo, lo ideal sería que en el caso de que el fichero volviese a estar disponible para cualquier usuario, bien sea por expiración del periodo de embargo o por un reintegro manual de permisos, el metadato de derechos de acceso cambiase automáticamente a la opción «openAccess».

Si bien DSpace no tiene esas funcionalidades incluídas en su comportamiento o configuración, se pueden programar unas tareas de curación (curation tasks) para:

Detectar, a la hora de realizar un nuevo envío, los permisos que debe tener el fichero adjunto en función de la información introducida en el metadato de derechos de acceso (dc.rights.accessRights o similar), y ajustarlos según corresponda. Por defecto, cualquier usuario tiene acceso a los ficheros almacenados, por lo que la opción «openAccess» no exige ningún cambio en sus permisos. Si el publicador selecciona las opciones «restrictedAccess» y «closedAccess», la curation retira indefinidamente los permisos a los ficheros adjuntos, ya que en estos dos casos no se dispone de una fecha de reintegro de permisos como en el caso del embargo temporal. Recordemos que en el caso de «embargoedAccess», es necesario introducir una fecha de fin de embargo para que éste se active y desactive por sí solo, sin necesidad de ninguna tarea adicional. Si se selecciona esta opción, pero no se introduce fecha de fin de embargo, la curation lo entiende como un embargo indefinido y también retira permanentemente los permisos a los ficheros adjuntos.
Cambiar la información de derechos de acceso en función de los permisos del fichero adjunto. El caso más común es el cambio a «openAccess» cuando los ficheros vuelven a estar disponibles para cualquier usuario. Por ejemplo, si se introducen unos derechos de acceso con valor «embargoedAccess», al llegar la fecha de fin de embargo este valor cambia automáticamente a «openAccess». Lo mismo en el caso de que un administrador reintegre manualmente los permisos del fichero y se olvide de modificar la información descriptiva de derechos de acceso. Esta tarea resuelve aquellos casos en los que por descuido se ha almacenado el valor «openAccess» y se ha introducido una fecha de fin de embargo. Puesto que la información «openAccess» es meramente descriptiva, el fichero adjunto queda no disponible hasta que el embargo expire, por lo que la tarea detecta esta falta temporal de permisos, y cambia el valor «openAccess» por el valor «embargoedAccess». Una vez el embargo expira, el valor de los derechos de acceso son corregidos de nuevo por «openAccess».

Este tipo de tareas no sólo simplifican las labores de gestión de los administradores del repositorio sino que permiten mantener de manera automática una coherencia entre la información descriptiva proporcionada por los metadatos y los permisos de los ficheros adjuntos.

Derechos de acceso y permisos en DSpace (Parte 1)

Enviado por Eva Braña el 2015/08/18 Comentarios desactivados

La inclusión de información sobre derechos de acceso y su coherencia con los permisos reales de acceso a los ficheros, es un tema sobre el que los usuarios de DSpace suelen plantear preguntas con frecuencia, y al que dedicaremos este primer post sobre derechos de acceso y permisos en DSpace.

Habitualmente, a la hora de realizar un envío a DSpace, los publicadores rellenan la información sobre los derechos de acceso, puesto que es un dato exigido para la compatibilidad con determinadas Directrices como las Directrices OpenAIRE. Cuando los derechos de acceso son «openAccess», no hay problema alguno, puesto que el fichero adjunto permanece disponible para cualquier usuario una vez el ítem es publicado en el repositorio. Sin embargo, en ocasiones los publicadores seleccionan las opciones «embargoedAccess», «restrictedAccess» o «closedAccess». Esta selección (igual para «openAccess») se almacena en un metadato, normalmente el dc.rights.accessRights, que por sí mismo no modifica los permisos de acceso al fichero asociado al ítem, ya que simplemente es un metadato descriptivo. Por eso, cuando un usuario selecciona una de esas opciones puede pensar que está modificando los derechos de acceso al fichero adjunto, cuando en realidad solamente está enriqueciendo la descripción de su publicación.

Cuando el sistema de embargos está activo y configurado en DSpace, es necesario introducir la fecha de fin de embargo en el lugar correspondiente (en la pantalla de descripción o en la pantalla de subir fichero, dependiendo de la versión de la herramienta), para que el fichero adjunto se quede embargado hasta dicha fecha. Esto es imprescindible, puesto que la introducción de «embargoedAccess» en el metadato dc.rights.accessRights no cambia por sí sola los permisos de acceso al fichero, tal y como se indica en el párrafo anterior. Ésta es, por defecto, la única manera que el usuario tiene, durante el proceso de envío, para influir en los permisos de los ficheros adjuntos, y puede utilizarla también para la retirada de permisos cuando selecciona otras opciones como «restrictedAccess» o «closedAccess» en el campo de derechos de acceso. Una vez el ítem es publicado, solamente los usuarios con permisos de administración pueden retirar manualmente los permisos de su fichero adjunto, no pudiendo hacerlo el propio publicador.

Otra cuestión que se plantean los usuarios es qué sucede con la información almacenada en el metadato de derechos de acceso cuando los permisos de los ficheros adjuntos cambian. Pues bien, por defecto, esta información no cambia automáticamente. Es decir, un dc.rights.accessRights con valor p.ej. «embargoedAccess», no cambia automáticamente a «openAccess» cuando el embargo llega a su fin. Esta labor suele ser realizada de forma manual por un usuario con permisos de administración.

En el siguiente post hablaremos de cuáles son las principales demandas de los usuarios a este respecto y analizaremos las posibles soluciones.

Conexión con los servicios de Creative Commons

Enviado por Eva Braña el 2015/05/07 Comentarios desactivados

En ocasiones, los servicios de Creative Commons se caen, o funcionan intermitentemente, lo que provoca que fallen los envíos de ítems a un repositorio con el paso de asignación de Licencias Creative Commons activado. Cuando los servicios de Creative Commons se recuperan, todo vuelve a la normalidad, pero hasta entonces, las aplicaciones como Dspace que hacen uso de la API de conexión dejan de funcionar correctamente.

Este tipo de errores se reconocen, en primer lugar, porque los envíos fallan en el paso de asignación de la Licencia Creative Commons. En este paso, la herramienta tarda un rato en cargar, y cuando finalmente lo hace, aparece un error similar al que puede verse a continuación:

que ya nos dice que el paso CCLiecenseStep está dando problemas, si además explosionamos el error pulsando sobre el enlace [show] que aparece situado al lado del apartado Java stacktrace, veríamos, dependiendo n una de las líneas del error puede leerse algo así:

org.dspace.app.xmlui.aspect.submission.submit.CCLicenseStep.addBody(CCLicenseStep.java:121)

La solución no está en nuestras manos (a no ser que desactivemos el paso CCLicenseStep con un nuevo item-submission.xml o ideemos alguna otra solución de código imaginativa) y solo restará esperar un tiempo hasta que los servicios de Creative Commons se restablezcan. (Bueno existe una posibilidad más siniestra, como que hayamos perdido la conectividad por el puerto 80 o circunstancias similares…)

En todo caso, resulta interesante saber que Creative Commons ofrece a los usuarios información sobre el estado de sus servicios en la página http://status.creativecommons.org/. Cuando alguno de ellos falla, se muestra un mensaje de aviso similar al siguiente, lo que permite seguir su evolución:

Asimismo, en el momento en el que los servicios de Creative Commons se encuentren de nuevo operativos, la consulta directa a su API (http://api.creativecommons.org/rest/1.5) dejará de indicar que no puede establecerse la conexión:

y pasará a mostrar una página con el texto «not found», que no debe confundirse con un error, similar a la siguiente:

Y solo falta desear que los servicios que ofreces esta organización se restablezcan pronto.

DSpace en las Universidades españolas

Enviado por Eva Braña el 2015/03/25 Comentarios desactivados

Aprovechando el estudio que hicimos para el XIV Workshop Rebiun de Proyectos Digitales / VI Jornadas OS-Repositorios: Los horizontes de los Repositorios que se acaba de celebrar en Córdoba este mes de marzo, Estudio de la integración de repositorios en el sistema científico-investigador: alternativas y estado actual, pudimos extraer datos referentes al software de implementación y otros datos de caracterización de los repositorios institucionales.

Metodología Usada

Revisamos en la última semana de febrero de 2015 la lista de repositorios institucionales de REBIUN. Indiquemos que REBIUN, Red de Bibliotecas Universitarias, incluye las bibliotecas de las universidades españolas (mas el Consejo Superior de Investigaciones Cientíificas), es decir un total de 74 instituciones. Se inspeccionó la solución de software de los repositorios institucionales declarados en dicha lista, sobre la url reportada, y en el caso de repositorios con software Dspace, además se anotó la interface (JSPUI ó XMLUI ) y cuando fue posible, la información de la versión.

Resultados

De las 74 instituciones, 58 tienen repositorio institucional, y como se ve en la figura siguiente, el software DSpace, con 49 instalaciones, es indudablemente el más usado en la construcción de repositorios, con una presencia baja de otros sistemas: Invenio, Fedora, e-Prints, Greenstone…..

Software usado en repositorios institucionales REBIUN

De estos 49 repositorios Dspace, el 51% tienen versiones «antiguas», incluyendo 1.8, 1.7, 1.6 o etiquetadas desconocida» (indicativo de versión 1.6 o anterior, en que no se declaraba la versión Dspace en los metatags de la homepage). En cualquier caso, una cifra del 49% de instalaciones con versiones actualizadas (versiones 3 y 4), es una cifra en línea con la reportada del 40% que tenía el escenario más amplio, 1100 instalaciones Dspace, analizado por @atmire en diciembre de 2013.

Versiones e Interfaces Dspace en repositorios REBIUN

El 59% de las instalaciones tienen el interfaz XMLUI. aunque si consideramos solamente las instalaciones con versiones más actualizadas (v3, v4 o la ausente 5) contabilizan el 75% de las mismas. Una indicación posiblemente de cómo este interfaz está gradualmente ganado popularidad entre los gestores de repositorios universitarios.

Igualmente recordar que desde comienzos de este año 2015 se ha «discontinuado» el soporte para las versiones 1.8 y anteriores por lo que sería de importancia el que estas instalaciones considerasen la migración de sus repositorios.

Ordenación del índice de navegación por títulos

Enviado por Eva Braña el 2014/10/27 Comentarios desactivados

La ordenación de los resultados de los índices de navegación de DSpace, es un tema bastante controvertido y a veces resulta desconcertante para los usuarios de la herramienta.

En primer lugar, hay que tener en cuenta que el índice de navegación por Títulos que ofrece DSpace, no considera una serie de «palabras vacías» para la ordenación de los resultados mostrados en el mismo. Estas palabras vacías son consideradas como «no indexables», y por lo tanto, no son tenidas en cuenta para dicha ordenación.

En esta lista de palabras vacías aparecen por defecto los artículos en diferentes idiomas, como el artículo «el» en español, o su equivalente en inglés «the». Sin embargo, es importante tener en cuenta que para que estas palabras sean correctamente ignoradas en el idioma correspondiente, el idioma del metadato del título (dc.title) debe haber sido introducido de manera apropiada. Es decir, si el metadato del título está en «en_US», se ignora la lista de palabras inglesas, mientras que si está en «es_ES», se ignoran las españolas.

Esto no se tiene en consideración en muchos Repositorios, pudiendo encontrarse criterios mezclados, con coexistencia de ítems en los que el artículo «el» se ignora (apareciendo ordenados por la segunda palabra del título), e ítems en los que el artículo “el” se tiene en cuenta para la ordenación (apareciendo ordenados en la letra “E”).

Pongamos por caso un título que comience por «El derecho constitucional…»: Si su título está en español (el idioma del metadato debe ser el español), la partícula “el” se ignora y el ítem aparece indexado en la letra «D», mientras que si su título no lleva idioma o está señalado erróneamente como inglés, el ítem aparece indexado en la letra «E».

Pensemos ahora en un título que comience por «The love is…»: Si el idioma del título es el inglés, este ítem aparece indexado en la letra «L», puesto que la partícula «the» es ignorada en la ordenación del mismo. Si por el contrario el metadato del título no lleva idioma o está marcado como español, el ítem aparece en la letra «T».

Finalmente, y para aportar mayor claridad, acompañamos esta explicación con una imagen extraída del índice de títulos de un DSpace, y a continuación explicamos por qué la lista de títulos aparece ordenada de esa forma:

El título «The apple» se ha introducido en inglés, por lo que la herramienta ignora la partícula «the» y se ordena por la letra «A» de la palabra “apple”. Por eso aparece en el primer lugar.

El título «El destino final» está en español, por lo que en este caso se ignora la partícula «el» y se ordena por la «D» de la palabra «destino».

El título «El actor principal» está sin idioma, por lo que la partícula «el» es considerada para la ordenación. Si el título estuviese en español, la partícula “el” se ignoraría, y el título pasaría a la primera posición, ya que se ordenaría por la letra “A” de la palabra “actor”.

Finalmente, el título «The last function» también está sin idioma, y por ello la partícula «the» es considerada para la ordenación, apareciendo el ítem, por lo tanto, ordenado por la letra “T”.

Para entender la ordenación que siguen los resultados del índice de títulos de DSpace y que ésta sea óptima, no sólo se debe tener en cuenta la lista de palabras ignoradas en la ordenación, sino también la apropiada introducción del idioma del metadato que almacena cada título.

Licencias Creative Commons en las diferentes versiones de DSpace (Parte 2)

Enviado por Eva Braña el 2014/04/10 Comentarios desactivados

Tal y como habíamos prometido, en esta ocasión vamos a tratar el proceso de asignación de licencias Creative Commons dependiendo de la versión de DSpace utilizada.

En la versión 1.7 de DSpace, en la pantalla de licencia Creative Commons del proceso de envío de ítems, existía un botón “Acceder a Creative Commons para elegir una licencia”, que enviaba al usuario a una página externa de Creative Commons donde debía contestar a dos preguntas para seleccionar la licencia deseada.

Después de pulsar el botón “Escoge una licencia”, se mostraba la selección realizada y un enlace “proceder” para regresar al repositorio y continuar con el proceso de envío.

Una vez el ítem era publicado, en el bundle CC-LICENSE eran almacenados los siguientes tres ficheros: license_url (en formato License, conteniendo la url de la licencia asignada), license_text (en formato CC License, con el texto de la licencia asignada) y license_rdf (en formato RDF XML con el texto de la licencia asignada). Y en la sección “Este ítem tiene asociados los siguientes ficheros de licencia” de los registros simple y completo, se mostraba un enlace denominado “Creative Commons”, que mostraba el texto de la licencia Creative Commons asociada a dicho ítem, contenido en el mencionado fichero license_text.

En la versión 1.8, sin embargo, en la pantalla de licencia Creative Commons del proceso de envío de ítems se disponía de un desplegable para seleccionar hasta 5 tipos diferentes de licencias (Creative Commons, Public Domain, Public Domain Mark, Sampling y CC0), según la declaración del parámetro

cc.license.classfilter

del fichero dspace.cfg, sin necesidad de abandonar el repositorio.

En el caso de seleccionar una licencia Creative Commons, se mostraban dos preguntas cuya respuesta permitía seleccionar un tipo u otro de licencia Creative Commons. Por ejemplo, una respuesta negativa a ambas preguntas, seleccionaba una licencia Creative Commons by-nc-nd.

Al seleccionar una licencia en esta pantalla, automáticamente DSpace asignaba dos metadatos, por defecto el dc.rights y el dc.rights.uri, al ítem que se está enviando. En el metadato dc.rights se almacenaba el nombre de la Licencia seleccionada. En el ejemplo anterior sería Attribution-NonCommercial-NoDerivs 3.0 Spain, siempre y cuando la jurisdicción elegida para la licencia fuese la española, aspecto configurable en el parámetro

cc.license.jurisdiction

del fichero dspace.cfg. En el metadato dc.rights.uri se almacenaba la uri de la Licencia seleccionada. Siguiendo con el mismo ejemplo sería http://creativecommons.org/licenses/by-nc-nd/3.0/es/, también si la jurisdicción elegida para la licencia fuese la española.

Al finalizar el proceso de envío, además de estos dos metadatos automáticos, en el bundle CC-LICENSE se almacenaba un único fichero license.rdf. Adicionalmente, se añadía un logo de Creative Commons al ítem, que si se pulsaba redirigía al usuario a la página de Creative Commons de la licencia que le hubiese sido otorgada.

Este proceso de asignación de Licencias Creative Commons se ha mantenido en la versión 3.2 de DSpace.

Como puede observarse una vez leídos éste post y el previo sobre las licencias Creative Commons, los procesos de activación, configuración y asignación de las mismas son mucho mejores a partir de la versión 1.8 de DSpace, ya que, además de poder decidir fácilmente para qué Colecciones se desea activar el paso de asignación de estas licencias, para otorgarlas el usuario no abandona en ningún momento la herramienta, el proceso de asignación de metadatos es automático, y además se incorpora un logo linkable a la página de Creative Commons correspondiente en cada caso.

Licencias Creative Commons en las diferentes versiones de DSpace (Parte 1)

Enviado por Eva Braña el 2014/03/27 Comentarios desactivados

Los procesos de activación, configuración y asignación de las licencias Creative Commons han ido cambiando con las diferentes versiones de DSpace, mejorándose sustancialmente con el cambio de la versión 1.7 a la 1.8, y manteniéndose este comportamiento en la versión 3.2 de la herramienta.

En este primer post sobre las licencias Creative Commons, hablaremos sobre la activación y la configuración de las mismas.

En cuanto a la activación de estas licencias, en la versión 1.7 era necesario especificar en el fichero dspace.cfg el valor del parámetro

webui.submit.enable-cc = true

En la versión 1.8, sin embargo, las licencias Creative Commons se establecían como un paso configurable del proceso de envío de ítems, y su activación requería descomentar el paso señalado a continuación, en el fichero item-submission.xml, proceso que se ha mantenido en la versión 3.x:

<!-- Uncomment this step to allow the user to select a Creative Commons license -->

<!--

<step>

<heading>submit.progressbar.CClicense</heading>

<processing-class>org.dspace.submit.step.CCLicenseStep</processing-class>

<jspui-binding>org.dspace.app.webui.submit.step.JSPCCLicenseStep</jspui-binding>

<xmlui-binding>org.dspace.app.xmlui.aspect.submission.submit.CCLicenseStep</xmlui-binding>

<workflow-editable>false</workflow-editable>

</step>

-->

Esto facilitaba, por lo tanto, su habilitación de manera general para todas los procesos de envío de ítems definidos, o bien solamente para una Colección o Colecciones concretas.

Respecto a la configuración de las licencias Creative Commons, en la versión 1.7 tan sólo existía una pequeña parte configurable mediante el fichero dspace.cfg. Además de su activación mediante el parámetro

webui.submit.enable-cc

también se podía seleccionar la jurisdicción a utilizar para las mismas en el parámetro

webui.submit.cc-jurisdiction

En la versión 1.8, al igual que en la 3.x, además de seleccionar la jurisdicción a utilizar, también se pueden configurar las licencias a mostrar en el combo de selección de licencias del paso “Licencia CC” del proceso de envío de ítems, y los metadatos donde almacenar de manera automática el nombre y la url de la licencia seleccionada si así se desea.

Dejamos para un próximo post la descripción del proceso de asignación de las licencias Creative Commons en las diferentes versiones de DSpace.

Interfaz OAI en DSpace 3.x

Enviado por Eva Braña el 2013/12/10 Comentarios desactivados

En la versión 3 de DSpace se ha incluido una nueva Interfaz OAI-PMH que, además de facilitar la adecuación del Repositorio a los aspectos derivados de la recolección, puede simplificarnos la compatibilidad con las Directrices DRIVER y OpenAIRE.

Hasta ahora, se podía interrogar a un Repositorio mediante el uso de comandos OAI-PMH, emitidos desde cualquier navegador (al fin y al cabo el protocolo PMH se apoya en http) puesto que la mayoría de ellos están incluyen el soporte para que sus contenidos sean recolectados por los agregadores vía este Protocolo.

Considerando el caso habitual de que el OAI esté desplegado en el directorio [webapps]/OAI/ de DSpace, las consultas OAI-PMH son de la forma:

URL base de la instancia DSPACE/oai/request?verb=Xxxxx

Siendo Xxxxxx los verbos utilizados para las consultas OAI-PMH, cada uno de ellos con una serie de atributos y modificadores, y cuya sintaxis se describe en el documento del estándar del Protocolo (http://www.openarchives.org/OAI/openarchivesprotocol.html#ProtocolMessages), los siguientes:

Identify, ListRecords, ListSets, ListMetadataFormats, ListIdentifiers y GetRecord.

A partir de la versión 3 de DSpace, se ha añadido una hoha de estilos que posibiliat realizar las anteriores consultas utilizando una Interfaz gráfica, que facilita sobremanera dicha tarea.

Además, la nueva versión, ha integrado una nuevas librerías OAI (xOAI, que sustituye al código OAI usado en anteriores versiones, originario de OCLC) que posibilitan la implementación de diferentes Interfaces OAI para cada uno de las necesidades de sets virtuales que requiera el Repositorio, de acuerdo con sus requerimientos en materia de metadatos, facilitando la creación de estos sets virtuales, mediante operaciones de filtrado y la transformación. Esto es de gran utilidad para el cumplimiento de Directrices como DRIVER y OpenAIRE.

Las Interfaces DRIVER y OpenAIRE, se muestran realizando las siguientes consultas, respectivamente:

URL base de la instancia DSPACE/oai/driver?verb=Identify

URL base de la instancia DSPACE/oai/openaire?verb=Identify

Básicamente, se ha realizado una reforma completa, realizada por la empresa portuguesa Lyncode, que podría considerarse una evolución natural del Addon OAI-Extended (puesto que los compañeros de Lyncode provienen de una amplia experiencia desde la empresa KeepSolutions y desde Repositorium de la Universidade do Minho) basándose en un framework OAI mejorado.

Página siguiente »

Author Archives: Eva Braña

Metodología Usada

Resultados

Contenidos