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

Adaptando a OpenAIRE 4 (I): Identificadores de autor

Enviado por Emilio Lorenzo el 2019/10/28 Comentarios desactivados

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

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.

DSpace versión 6

Enviado por cfernandez el 2016/11/07 Comentarios desactivados

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

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.

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.

Moviendo assetstores

Enviado por cfernandez el 2014/08/13 Comentarios desactivados

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

Enviado por Adán Román el 2014/06/16 8 comentarios

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.

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.

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 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 en horizontal

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)

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.

Métodos usados en el Authority Control

Enviado por Adán Román el 2014/03/04 3 comentarios

Una vez explicado en el post anterior el modelo de control de autoridades en DSpace, vamos a profundizar algo más en el authority control. En concreto os voy a comentar los aspectos más destacables que tiene la clase encargada de hacer funcionar el authority control.

SampleAuthority es el modelo de ejemplo que se usa para poder a empezar a desarrollar nuestra funcionalidad del modelo de autoridades. (Aunque lo más correcto es crear nuestra propia clase Autoridad copiando el SampleAuthority)

Esta clase la podemos localizar dentro del DSpace API en la siguiente ruta:[dspace-src]/dspace-api/src/main/java/org/dspace/content/authority/SampleAuthority.java

Esta clase tiene un aspecto como el siguiente (no se incluye todo el código)

public class SampleAuthority implements ChoiceAuthority{    

    public Choices getMatches(String field, String query, int collection, int start, int limit, String locale){
       
    }

    public Choices getBestMatch(String field, String text, int collection, String locale) {
    }

    public String getLabel(String field, String key, String locale) {
    }
}

Básicamente lo primero que vemos es que la clase ha de implementar al interfaz ChoiceAuthority, y en el nos toca programar sus tres métodos principales

getMatches: este método ha de retornar un listado con todas las coincidencias buscadas a partir de la búsqueda introducida por el usuario, por lo general serán apellidos. Es decir si el usuario busca autores por el apellido Nieto, este método debería de retornar todos los autores de la BBDD con el apellido Nieto;

Nieto Español, Juan
Nieto Caramés, Sergio
Española Nieto, Juana

getBestMatch: Este método está pensando en devolver el mejor resultado posible, es decir si antes buscábamos solo por el apellido para mostrar un listado de autores con apellido parecido, con este método hemos de aproximar el resultado a uno posible.
En cuyo caso de que el resultado sea único debemos de dar un grado de confianza del mas alto posible. (Por lo general con un valor de confianza UNDEFINED ha de ser suficiente)

Este método hay que implementarlo bien, puesto que cada vez que se introduzca un metadato controlado (que use Authority Control), DSpace va a ser el encargado de validarlo automáticamente. Es decir que nos sirve para automatizar las tareas de los usuarios administradores, pero mejor que lo hagamos de forma precisa.

getLabel: Este método ha de resolver el problema de nombramiento que tiene DSpace con los autores validados, ya que por definición, DSpace coge el valor clave de autoridad y lo muestra como nombre de autor, por lo que debemos con este método cambiar por un valor de autor que se asocie a ese identificador.

Una vez programada esta clase (compilada y desplegada) solo falta rellenar la configuración detallada en el fichero de configuración dspace.cfg para que se asocie el proceso a un metadato que queramos como por ejemplo el dc.contributor.author. (toda esta información viene detallada en la documentación de DSpace accesible desde el código fuente o desde su web ;D)

Bueno ahora solo toca entender bien las especificaciones que deseamos aplicar a nuestro modelo de autoridades y programarlo según esas espacificaciones.

Mucha suerte

Página siguiente »

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

Contenidos