Archivos de Categoría: Documentación técnica

Adaptando a OpenAIRE 4 (I): Identificadores de autor

Incorpore Identificadores de autor en sus metadatos

Entre los objetivos de OpenAIRE v4.0 figura la búsqueda de una mayor precisión, mas allá de los nombres normalizados que planteaba DRIVER, sobre los agentes del sistema investigador. Para ello OpenAIRE propone el uso de esquemas de identificación (identifier schemes) para autores, organizaciones, agencias financiadoras, etc.

Por tanto el primer problema que debemos abordar es cómo incorporar a nuestro repositorio procesos de normalización de nombres de autor y asignación de identificadores de autor, preferiblemente ORCID iDs.

Nuestra propuesta es el uso de métodos de desambiguación de nombres y asignación de identificadores, embebidos en los procesos de ingesta de contenidos y revisión de la metadatación, preferiblemente mediante el uso de funciones de control de autoridades. Hay algunas instituciones que han optado por soluciones diferentes, todas valen en tanto logren hacer correctamente la correspondencia Nombre de autor <–> Identificador de autor (para todos las posibles fuentes de autoridad, añadiríamos)

Recuerde que es posible, aunque en algunos escenarios puede desaconsejarse, efectuar consultas sobre la API de ORCID, incorporando datos de identificación de autores no institucionales a su repositorio.

Igualmente, si tiene la posibilidad de identificar la institución u organización de los autores, puede considerar exponer ese dato.

Exposición en el interface OAI_PMH de los identificadores de autor

El uso de esquemas de identificación (identifier schemes) para autores, organizaciones, agencias financiadoras, etc. se realiza en OpenAIRE 4 mediante la exposición de los identificadores únicos, PIDS, (principalmente ORCID iDs e ISNI) en los elementos de autoría, y más específicamente en los elementos datacite:creator y datacite:contributor junto con sus atributos, affiliation, nameIdentifier, contributorType, nameIdentifierScheme y schemeURI

Dependiendo de la solución adoptada (ver epígrafe anterior) para almacenar las asociaciones Autor-Identificador, trasladar éstas a la interface OAI-PMH puede resultar mas o menos compleja y/o efectiva.

En la figura siguiente, el modelo autoridades-SOLR authority cache-SOLR OAI-PMH que usamos en nuestras implementaciones, intentando mostraros rla posible complejidad de dicha exposición.

Si todo está ensamblado, estaremos en condiciones de exponer la información de autores de forma compatible openAIRE 4. Una muestra de lo dicho:

<datacite:creator>

<datacite:creatorName>Gavilán Ceballos, Beatriz</datacite:creatorName>
<datacite:nameIdentifier schemeURI=»https://orcid.org» nameIdentifierScheme=»ORCID»>0000-0001-7515-1186</datacite:nameIdentifier>
<datacite:affiliation>Universidad de Huelva</datacite:affiliation>
</datacite:creator>

Por ahora, suficiente. Mas entregas en unos días

Preservación e integridad de ficheros en DSpace

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.

DSpace versión 6

Bien, la versión 6 ya está aquí, se anunció su disponibilidad el 24 de octubre y ya está lista para ser instalada…

¿y qué nos trae de nuevo la versión 6? Pues unas cuantas funcionalidades y cambios:

  • Incorporación de Hibernate, herramienta de mapeo objeto-relacional, paso necesario para poder abordad la refactorización de la API de Dspace (estamos pensando en la versión 7). Si teníais código propio que accedía a la base de datos de Dspace, posiblemente tengas que reescribirlo…
  • Se mejora el sistema de configuración de Dspace, que ahora usa la sintaxis de Apache Commons Configurations. Las configuraciones de dspace.cfg pueden recargarse sin rearrancar el Tomcat, el fichero de configuración build.properties se ha cambiado por un local.cfg  y algunas mejoras más. Algunas mejoras, pero al ser un nuevo sistema pues hay que volver a aprender la forma de hacer despliegues…
  • Se ha retirado el soporte al sistema de acceso al almacenamiento (assetstore) basado en SRB (no habia constancia de que lo usasen muchas instalaciones). Para compensar, se ha añadido soporte al sistema Amazon S3.
  • Ya no se distribuye la interfaz LNI (poco o nulo uso).  Quedará no obstante como «add-on»
  • El motor de búsqueda basado en Lucene y los métodos de browse basados en base de datos desaparecen por completo del código (deprecated, en terminología de desarrollo de software). Ya se desaconsejaba su uso en la v4, si querías usarlo daba muchísimos problemas en la V5 y se ha finalizado eliminando estos elementos de código.
  • Tenemos unos nuevos informes, denominados Healthcheck (chequeo de salud) que revisan una serie de parámetros del repositorio y pueden enviar esos informes al administrador, por correo electrónico. Nos parece un avance sobre las posibilidades de comprobación existentes en versiones anteriores.
  • Es posible exportar los resultados de una búsqueda a CSV  (en XMLUI)
  • Hay un panel de control administrativo ampliado y configurable, las opciones del control panel, crecen y crecen….
  • Se anuncia el framework de importación de metadatos (aclaremos que realmente estaba  ya funcionando e incluso documentado extensamente en la versión 5) pero parece que hacen ahora el anuncio oficial. Será porque se aprovecha este framework para posibilitar la importación de metadataciones desde Pubmed, CrossRef, ScienceDirect, que insistimos, ya se podía hacer en la versión anterior….
  • La interface REST admite los mismos métodos de autenticación que las UI (hasta ahora solo se soportaba el login-password). Parece lógico, ¿verdad? sobre todo desde que se plantea para la próxima versión desagregar DSpace de las interfaces de usuario…
  • Aparece un sistema de chequeo de metadatos (REST metadata quality control) que permite interrogar via la interface REST sobre los valores de metadatos que tenemos en nuestros ítems..¡¡¡ muy curioso el funcionamiento !!! recomendable….
  • El operador de búsqueda de Discovery pasa a ser AND (el OR causaba más preguntas de la cuenta, pero realmente el cambio es mínimo, unas lineas en un fichero de configuración)
  • Se posibilita el indexado de documentos que se escriben de derecha a izquierda (RTL), como el árabe o el hebreo.
  • Se actualiza a PDfbox 2.0 y se incluye un nuevo generador de miniaturas de PDF (por lo que ya no es necesario el xpdf)

y seguro que me dejo algo….

Conexión con los servicios de Creative Commons

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:

error java stacktrace

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:

status creative commons

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:

api cc ko

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

api cc ok

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

La interfaz JSPUI en DSpace 4

¡Si!, lo reconocemos, creemos que una vez que se aprende a usar XMLUI tiene mas ventajas que el interfaz JSPUI,  pero no obstante, dado que damos soporte a alguna instalación JSPUI, es necesario conocer sus líneas de evolución.  Por ello aquí os dejo mi pequeña aportación al JSPUI,  que en este caso es la customización del nuevo interfaz.

Una vez instalamos la versión 4 de DSpace nos encontramos que el interfaz de JSPUI  ha sido cambiado drásticamente. El interfaz «clásico» existente en cientos de instalaciones de DSpace por todo el mundo, y que era la «marca de la casa JSPUI»,  ha dejado paso en esta versión a un interfaz adaptativo, permitiendo la visualización de Dspace en cualquier tipo de pantalla, sea PC, tablet o dispositivos móviles.

Como explicábamos en nuestro post sobre mirage2 (liberado por nuestros compañeros de @tmire), este interfaz sigue la misma política para construir el interface adaptatativo, aunque claramente la forma de instalarlo o configurarlo es diferente (y los resultados son igualmente diferentes)

El tutorial que más nos ha gustado, proviene directamente de la comunidad Duraspace, puedes descargarlo aquí , páginas 29 a 38, y viene detalladamente explicado como modificar el interfaz JSPUI para poder añadir nuestros colores y logos de nuestra institución sin mayores quebraderos de cabeza. Básicamente nos cuenta cómo en 4 pasos podemos adaptar el interfaz de forma básica:

1- Cambiar los logos institucionales: Para ello modificamos los logos:

  • logo.gif 
  • dspace-logo-only.png

La ruta donde nos encontramos estos logos es la siguiente:

[dspace_i]/jspui/images/

2- Crear un nuevo tema de cero. Tenemos tres  urls en las que podemos descargarnos una serie de plantillas de tema prefijadas, o bien hacerlas nosotros de cero. Estos enlaces son los siguientes:

Usé personalmente el último de ellos, que considero es mas detallista y completo, pero a la vez más complejo si no se entienden las propiedades css. Además, mediante un formulario pude realizar mi propia adaptación simplemente rellenándolo. Si no se tiene mucho conocimiento de CSS se puede optar por bootswatch ya que nos da unas plantillas prefijadas y simplemente las podemos incluir en nuestro repositorio.

3- Aplicar los cambios: Una vez creas el estilo, lo descargas  y aplicas los cambios en el directorio

[dspace_i]/jspui/static/css/bootstrap/

4- Insertar iconos e imágenes: Aparte de insertar las css generadas de vuestro tema, si se han integrado nuevas imágenes, se han de meter en la siguiente dirección:

[dspace_i]/jspui/images/

Obviamente esta documentación es nada más que un inicio para plantar las bases de unos desarrollos posterioees, y sobre todo evitaros la primera aprensión que supone afrontar este nuevo interfaz, que no tiene nada que ver con el que nos encontramos en las versiones anteriores de DSpace.

Por ello os animo a probar dicho interfaz y si tienen dudas  no tienen mas que ponerse en contacto con nosotros.  Muchas gracias a todos los DSpacers que nos leen, y por cierto os dejo con mi obra:

 

Dspace 4.X JSPUI

Dspace 4.X JSPUI

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

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:

Ejemplo ordenación índice títulos

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.

title_en_ok

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

title_es_ok

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

title_es_ko

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

title_en_ko

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.

Moviendo assetstores

Ya vimos en un post anterior qué estructura tenía el assetsore y cómo se configuraba este subsistema de DSpace, vamos a explicar ahora cómo se mueven los assetsores.  ¿Y por qué ibamos a querer mover un assetstore?,  pues puede haber múltiples razones:

  • Tenemos otro tipo de almacenamiento, más moderno, más barato, con mejor rendimiento, el assetsore estaba antes como almacenamiento de servidor y ahora lo muevo a almacenamiento en red, SAN, etc…
  • Donde lo tenemos actualmente nos está danto algún error de disco,
  • Separamos el assetstore del resto de ficheros del sistema Dspace, para facilitarnos la migración de servidores, cambio de versiones, crecimiento orgánico de la instalación, etc..

Los pasos son bien sencillos:

  • Asumiendo que sólo tenemos un assetstore y que nunca la movimos de sitio, es decir tiene la configuración inicial que viene estándar en el dspace.cfg,  (comprobarlo viendo la variable assetstore.dir). Algo así como:
 assetstore.dir = ${dspace.dir}/assetstore

tenemos que localizar en nuestro sistema de ficheros el   ${dspace.dir}/assetstore siendo  ${dspace.dir} el directorio de ejecución de dspace, otra variable de dspace.cfg….  Es un poco recursivo, pero lo localizaremos sin problemas..

  • Paramos Dspace, es decir paramos la aplicación bajo el servidor Tomcat, o todo el Tomcat si es la única aplicación bajo el servidor de aplicaciones
  • Movemos (mejor copiamos, por ahora) todos los directorios bajo  ${dspace.dir}/assetstore a la nueva localización
  • Reconfiguramos Dspace, sustituyendo assetstore.dir por el valor de la nueva localización, como  por ejemplo:
     assetstore.dir = /data/assetstore
  • Rearrancamos Dspace, y finalizada la  tarea y el post.

Advertencia: Tener cuidado con las manipulaciones al assetstore, perderlo es perder su instalación DSpace…toda precaución es poca.

 

 

Probando Mirage2

Buenas a todos, lectores.

Tras los anuncios de las últimas semanas de la nueva interfaz adaptativa de Dspace para XMLUI,  queríamos probar el nuevo tema Mirage2 que acaban de liberar nuestros amigos de @tmire. Señalar que Mirage2 está disponible para las versiones 3 y 4 de Dspace y que está llamado a convertirse en la interfaz «estándar» de DSpace v5-XMLUI.

Sobre todo, hay que descubrirse ante el buen trabajo que ha realizado @tmire, ya que podemos ver como han suavizado el tema Mirage sin dejar de lado la gran funcionalidad que ya existía y por supuesto  añadiendo las funcionalidades de liquidness y responsiveness (lo siento pero no vamos a traducir estos términos)

Adaptive is characterized by having defined layouts for different resolutions. Within each layout, resizing the window does not change the layout.

Liquid (also called «Fluid») is characterized by scaling the width of parts of the design relative to the window. It tends to fail when the window is much smaller or much larger than it was originally designed for.

Responsive is characterized by having defined layouts for different resolutions. Within each layout, the design is liquid and resizes the width of elements relative to the changing window size.

 

 

Mirage 2

Así se ve Mirage2

A primera vista me he fijado que se adapta perfectamente a la pantalla incluso con cambios de tamaño debido a su diseño responsivo.

Aprovechando el cambio, se han introducido modificaciones en la página principal (recolocación de menús), en la vista de colecciones y en la vista del item. En ésta, vemos como se da más representatividad a los thumbnails ocupando un espacio más visible en la página respecto a Mirage.

view item

Vista de Item en Mirage2

¿ESO ES TODO?

No. La principal novedad que tiene Mirage2 no es su rediseño sino su gran compatibilidad con otro tipo de tamaño de pantallas, haciendo que este interfaz se adapte al tamaño de cualquier monitor de PC y lo más novedoso de todo es que hay necesidad de habilitar el aspecto mobile que se podía crear para las versiones 1.8, 3 o 4 de DSpace.

VISTA MÓVIL

Haciendo pruebas desde el smartphone podemos apreciar como el meńu derecho desaparece según cambiamos de tamaño de pantalla, sustituyendo ese menú por un icono situado arriba a la derecha, en el cual, si lo pulsamos tenemos acceso a las mismas funcionalidades de la página completa.

Lo mismo ha ocurrido con el menú «mi cuenta» que se ha cambiado por un icono que aparece al lado del icono del menú.

vista en móvil

Vista en un móvil

VISTA EN TABLET

En la tablet también se experimentan los cambios,  ya que si permaneces con la tablet en forma horizontal tienes una visión mas próxima a la vista en un PC. En cambio, si se gira la tablet se comporta más bien como un móvil.

tablet vista normal

Tablet en horizontal

tablet en vertical

Vista con la tablet en vertical

 

Pues bueno,  DSpacers,  eso es todo por el momento. Seguiremos trabajando por seguir aprendiendo y modelando este gran interfaz que tiene muchas posibilidades.

A continuación os dejo los enlaces a @tmire para que probéis vosotros mismos el interfaz o si queréis trastear con él (si no podéis esperar a que salga la versión 5 de Dspace)

Vista: https://atmire.com/preview/

Descarga: http://atmire.com/website/?q=download-mirage-2

ejemplo: OpenKnowledge Wordlbank

otro: Trinity´s Access to Research Archive

 

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

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.

imagen1

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.

imagen2

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)

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.