Derechos de acceso y permisos en DSpace (Parte 2)

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

Open Access11

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)

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.

 

El soporte del estándar METS en DSpace

El estándar METS, Metadata Encoding and Transmission Standard, es una especificación XML que especifica los metadatos necesarios para la gestión de objetos digitales en un contexto digital así como para el intercambio entre sistemas de dichos objetos. METS se crea y diseña para proporcionar un formato relativamente simple de descripción de las actividades realizadas durante el ciclo de vida de un objeto digital.

Adicionalmente a la metadatación descriptiva interna, realizada habitualmente en Dublin Core Cualificado, el software Dspace incluye entre sus funcionalidades lo que se denomina un package disseminator and matching ingester adecuado para el tratamiento de determinados documentos METS.  La finalidad de este elemento es ayudar a los usuarios en la ingesta y exposición de los objetos DSpace usando el estándar METS.

DSpace tiene definidas pasarelas en formatos METS que usan el perfil de aplicación denominado, DspaceMETSSIPProfile,  en el que se han tomado las siguientes decisiones de diseño relevantes:

  • Los elementos de metadatación descriptiva se contemplan bajo un esquema MODS (Metadata Object Description Schema) aunque el formato METS acepta el encapsulado (wrapping) de otros esquemas, incluso coexistiendo en una única declaración.
  • Los elementos de metadatos técnicos que DSpace tiene definidos, sirven para sus propias necesidades de gestión del ciclo de vida y preservación de los objetos almacenados, lo que significa que no se contemplen objetos, eventos u agentes fuera de esas necesidades de gestión propias.  Mediante mapeo del  DSpace Content Object Model al modelo de objeto METS estos elementos se expresan usando el esquema de metadatos de preservación PREMIS. Es importante notar que el uso del PREMIS Data Dictionary no significa que DSpace soporte una implementación completa del modelo de datos PREMIS (p.ej. no usa las entidades de tipo evento)
  • Entre los elementos de metadatación administrativa, los correspondientes  derechos y autorías, si éstos son explícitos, se referencian, p.ej.  las licencias CC como rdf/xml, e incluyen en el manifiesto xml

Los creadores de este perfil METS, siguiendo criterios de simplicidad en la transferencia de información en los formatos SIP/DIP,  eran plenamente conscientes de la sobre-simplificación del mismo para una descripción completa de los AIPs:

Future use of this profile, or related profiles, to govern the creation of Archive Information Packages (AIPs) will require the inclusion of additional information to account for the larger information needs of AIPs.

Estas pasarelas o transformaciones se emplean en los siguientes ámbitos
Ingesta

  • El soporte de formatos empaquetados METS (conformes al perfil apuntado) está incluido en la herramienta de importación denominado packager
  • La interface SWORD también está adaptada para la ingesta de paquetes METS, haciendo uso del perfil especificado, mediante el plugin SWORDMETSIngester

Difusión:

  • El soporte de formatos empaquetados METS está incluido en la herramienta de exportación del packager
  • OAI-PMH, con metadataFormat METS
  • además, se expone en el interface XMLUI   (p.ej. añadiendo a la url de un item el /mets.xml)

Estas transformaciones exponen nada más que una historia parcial del ítem, no recogiendo todo el ciclo de vida de nuestro objeto digital, por otra parte desconocido para DSpace, ya que DspaceMETSSIPProfile es un perfil con objetivos diferentes de los requeridos habitualmente en los proyectos de digitalización como p.e.j:

  • Library of Congress METS Profile for Bibliographic Records
  • METS profile Biblioteca Virtual Patrimonio Bibliográfico del Ministerio de Educación y Cultura
  • METS Profile for Historical Newspapers (no registrado aún)

 

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.

Altmétricas en DSpace. Trasteando con la API de Altmetric.

Las altmétricas o altmetrías miden el impacto de la investigación mediante el uso de métricas alternativas a las métricas de citas, cuantificando su presencia en la redes  sociales, en forma de menciones en la web social, descargas, enlaces, cobertura mediática, inclusión en gestores de referencias, etc . Como exponente principal de estas nuevas métricas, figura Altmetric, que pone a disposición de nuestros repositorios (y de quien quiera) de un mecanismo base de integración en forma de API.

Explicaremos una de las varias formas de usar esta API.  La incorporación del API de Altmetric en DSpace no es complicada de realizar, pues Clipboard02simplemente necesitamos acceder a la carpeta de nuestro tema y realizar una serie de modificaciones al código de vista-de-item.

Debemos saber que la API de Altmetric requiere que se le pase un parámetro de identificador de objeto. Puede ser un identificador doi, un PMid, una uri, etc…. El ejemplo lo vamos a aterrizar con doi, por lo que en el ítem DSpace tendremos algo así como un dc.identifier.doi para almacenar el valor correspondiente al identificador digital.

El primer fichero que debemos de editar es el fichero item-view.xsl (o equivalente en temas no mirage). Ahí debemos de realizar una llamada a una plantilla (template)  que llamaremos p.ej. itemSummaryView-altmetrics . Dicha llamada se deberá de realizar a su vez (ya sabéis que el xsl es un poco recursivo….)  sobre una plantilla que tenga acceso a la información dublin-core del item (por ejemplo itemSummaryView-DIM-fields), puesto que necesitamos pasar a la plantilla la información del metadato dc.identifier.doi

Llamada a la plantilla (en dónde pongamos la llamada ya es otro asunto, los iconos Altmetric se dibujarán en donde defináis):

<xsl:call-template name=”itemSummaryView-altmetrics”/>

Además debemos de crear la plantilla con el script de altmetrics,  algo así como:

<!– con codigo –>

 <xsl:template name=”itemSummaryView-altmetrics”>      
          <xsl:param name=”link” select=”//@OBJID” />
          <xsl:param name=”doi” select=”//dim:field[@element=’identifier’][@qualifier=’doi’]”/>
          <div class=”simple-view-icons”>
          <xsl:choose>
              <xsl:when test=”$doi”>
                <script type=’text/javascript’ src=’https://d1bxh8uas1mnw7.cloudfront.net/assets/embed.js’>&#160;</script>
                
                <span title=”Almetrics” data-badge-popover=”bottom” data-badge-type=”2″  data-hide-no-mentions=”true” class=”altmetric-embed”>
                    <xsl:attribute name=”data-doi”>
                         <xsl:value-of select=”$doi”/>
                    </xsl:attribute>
                </span>
                
            </xsl:when>
            <xsl:otherwise>
                <span title=”Almetrics” data-badge-popover=”bottom” data-badge-type=”2″  data-hide-no-mentions=”true” class=”altmetric-embed”>
                    <xsl:attribute name=”data-handle”>
                         <xsl:value-of select=”substring-after($link,’handle/’)”/>
                    </xsl:attribute>
                </span>
            </xsl:otherwise>
            </xsl:choose>
        </div>
      </xsl:template>

Una vez guardado no necesitamos rearrancar tomcat ni nada. Si véis que no aparece nada cercioraros de que estáis pasando un identifier.doi de un objeto que existe y mejor aún con citas… (es decir, las pruebas hacerlas con un código doi “con substancia”)

NOTA DISEÑO: para personalizar el icono, solo hay que cambiar el parámetro data-badge-type y ponerle un número, por ejemplo si ponemos data-badge-type=”4″ obtendremos el clásico donut o rosco de Altmetric. La información sobre los diferentes badges que podéis usar está en https://api.altmetric.com/embeds.html, variando desde el donut de Altmetric hasta “cosas” mas abstractas que seguro desconciertan a más de un autor…

Clipboard04  Clipboard07Clipboard08

                                                                                                                                                                 Pues que disfrutéis y uséis el código y que vuestros usuarios os lo agradezcan.

DSpace en las Universidades españolas

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

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/ REBIUN

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.

 

Liberada la versión 5 de DSpace

El 21 de enero de 2015 se produjo la liberación de Dspace v5.0, tras un proceso de desarrollo que arrancó hace un año, y que tuvo su pre-versión el pasado 3 de noviembre cuando comenzó el Testhaton.

Señalaríamos que incorpora una larga lista de pequeñas correcciones, pero que su característica principal son las funcionalidades añadidas (por eso es una versión, claro..) y que pasamos a revisar rápidamente:

El tema Mirage2 para XMLUI.  Bien, qué quéreis que os digamos, no es exactamente una novedad, pero es una excleente noticia su incorporación a la versión 5. El tema Mirage2 de @tmire nos gustó según lo vimos en su presentación “oficial” en el Open Repositories de Helsinki en junio de 2014. Tanto nos sedujo que lo empezamos a implantar en versiones 4 de inmediato y ya llevamos varias.

Actualización automática de datos en las migraciones a la versión 5. Simplifica la ejecución de los scripts de actualización de los esquemas de BBDD y migra los índices SOLR.  Es un avance sobre el ¿proceso? artesanal actual de migración. No se si lo pondríamos en una lista de nuestras prioridades, pero bienvenida la simplificación.

Importación de SIPs desde el interface de usuario. Pschee, la parte más compleja de una importación no es la ejecución del comando desde la UI o desde el CLI, sino la propia creación del paquete.

REST API con CRUD (Create/Read/Update/Delete). Esto ya está mejor, sobre todo porque estabilizará  el paisaje de proliferación de interfaces REST que había por el universo DSPaciero. Recordemos que aunque otras interfaces REST (la de Hedtek, p.ej.)  ya posibilitaban el Create/read/update,  lo que se necesitaba , y así se discutió en DCAT y otros foros de desarrollo, era la continuidad de las soluciones adoptadas. La api usada es la JAX-RS: Java API for RESTful Web Services.

Todos los DSpaceObjects con soporte de metadatos. Esto es interesante. Esta extensión es la que posibilitará (posibilitará, porque la interface de usuario aún no se ha extendido para poder gestionar el nuevo modelo)  flexibilizar la infraestructura de metadatos, que hasta ahora era aplicable sólo a los ítems, a las Comunidades, colecciones, e-persons, grupos, …

Soporte Linked (Open) Data mediante una interface RDF. A partir de esta versión se podrán publicar contenidos del repositorio en forma de Linked Open Data. No obstante, no todo es tan sencillo, pues la instalación de Dspace hay que complementarla con otra webapp, un Triple Store, es decir una base de datos que almacene de forma nativa el modelo RDF. El sistema, puede servir Apache Fuseki, debe soportar SPARQL 1.1 Query Language y  SPARQL 1.1 Graph Store HTTP Protocol.

Las estadisticas de Google Analytics ahora recogen las descargas de bitstreams (p.ej, las que vienen directamente de Google Scholar y que antes no se recogían como eventos) y se pueden visualizar (al menos si se usa Mirage2)

Se ha realizado una primera integración con los identificadores ORCID mediante la generación de un nuevo índice SOLR de autoridades. La clave de autoridad enlaza ahora con metadatos adicionales, entre los que se incluyen el identificador ORCID y nombres alternativos de autor. Esto sólo funciona en XMLUI, y bien, resuelve problemas de identificación de autores a las organizaciones que usan este identificador, pero no es la integración con las ORCID_API que estábamos esperando.

Y más mejoras, como la Creación de Thumbnails con ImageMagick / Ghostscript; la Autogeneración de páginas de cubierta PDF en la descarga de los objetos, la función lookup sobre SHERPA/RoMEO y alguna funcionalidad adicional, las puedes ver aquí.

 

Traducción al español de Dspace 5 (y 4) disponible

Ya está puesta a disposición de la comunidad DSpace la traducción al español de la versión 5.0 e interfaz XMLUI. El fichero messages_es.xml y el resto de ficheros de idiomas de la release está incorporado en la distribución de la versión 5.0, además de encontrarse ya disponible en el ticket jira 2233 o en el github

Así, está disponible el fichero de traducción de los mensajes correspondientes al Discovery, SwordClient y XMLWorkflow.  Recordar que desde la versión 1.8, cada módulo distribuye su propio messages.xml, separado del messages.xml principal, de manera similar a la fragmentación de los ficheros de configuración…

Además, como los ficheros de mensajes son compatibles con versiones atrasadas, pues se puede incorporar a las versiones 4 (de las que no se disponía de versión traducida)

BIREDIAL 2014

Siempre que podemos asistimos a la conferencia BIREDIAL, Conferencia Internacional sobre Bibliotecas y Repositorios Digitales,  y así, este año nos desplazamos a Porto Alegre, Brasil, en donde se organizaba Biredial 2014.

Queremos agradecer antes de nada, la gran hospitalidad que nos ofrecieron durante las conferencias y todo el apoyo que nos brindaron durante los días de la conferencia.

Este año presentamos una comunicación sobre  DSpace y los interfaces móviles,  que podéis leer aquí, y además presentamos una ponencia conjuntamente con el Instituto Español de Oceonografía, en donde se expuso una visión global de las actuaciones en  el repositorio del Instituto, haciendo hincapié en las mejoras introducidas en el último año (autoridades, integración con sistema de gestión de investigación, vocabularios temáticos, integración básica con ORCID…)

IMG_0545

 

 

 

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