Archivos de Tags: xmlui

El soporte de ORCID en Dspace 5 (y superiores)

Enviado por cfernandez el 2016/11/14 Comentarios desactivados

En el anuncio a finales de 2014 de la versión 5, figuraba entre las funcionalidades destacadas el denominado «soporte ORCID» (para interfaces XMLUI con mirage ó mirage 2), contribución de @tmire y de la Universidad de Missouri. Esta funcionalidad se definía como:

The current product will provide a means for realtime ORCID lookup during submission of an item. A subset of ORCID metadata will be retained in a local store.

Ampliando la escueta definición anterior, diríamos que DSpace incorpora la capacidad de enlazar un campo de metadatación, como dc.contributor.*, con una consulta (lookup) sobre la base de datos de autores orcid.org.

La implementación estándar de ese lookup, es decir lo incluido en Dspace v5, normaliza el nombre del autor al valor del nombre de autor orcid, le asigna una clave interna de autoridad (un id de authority control que no tiene nada que ver con el orcid-id) y crea una entrada adicional en el nuevo núcleo SOLR de caché de autoridades, ésta si, conteniendo el orcid_id. Por ejemplo, la entrada del autor que se seleccionó en la pantalla anterior quedaría (en formato JSON) así:

{
"id": "53577e21-cd61-4e84-ae73-400c73a60d31",
"field": "dc_contributor_author",
"value": "Lorenzo, Antonio",
"deleted": false,
"creation_date": "2016-08-17T15:02:25.323Z",
"last_modified_date": "2016-08-17T15:02:25.323Z",
"authority_type":"orcid",
"first_name": "Antonio", "last_name": "Lorenzo",
"orcid_id": "0000-0002-5831-0808",
 }

Es decir, conseguirá en un primer paso normalizar nombres (bueno, quizá es bastante), pero el orcid-id lo tiene por ahí oculto, dentro del SOLR y poco mas podrá aprovechar de forma fácil ese proceso de consulta-desambigüación-normalización, teniendo que recurrir a extensiones sustanciales a Dspace si se quieren incluir integraciones adicionales usando la API de orcid, como sincronización de publicaciones, uso de la autenticación, etc…

La funcionalidad base es migrable hacia atrás para versiones 4, quizá para versiones 3, y para versiones JSPUI con algún trabajo y existe una implantación adicional para aquellos valientes que se atrevieron con el módulo Dspace-CRIS.

Señalar que además hay funciones adicionales relacionadas con la importación-exportación batch de metadatos (BME) y que esta funcionalidad no cambia en la versión 6 (liberada hace nada) y no está prevista su ampliación para la versión 7 (¿enero 2018?)

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

Enviado por Adán Román el 2015/04/07 1 comentario

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 simplemente 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’> </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…

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

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.

Liberada la versión 5 de DSpace

Enviado por cfernandez el 2015/01/26 8 comentarios

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

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

Embargo en DSpace 3.x

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

Hasta la versión 3 de DSpace, el embargo era una restricción temporal de acceso a los bitstreams de los ítems. Durante el período de embargo, los metadatos de los ítems seguían estando disponibles para cualquier usuario, pero los bitstreams sólo estaban disponibles para usuarios administradores. El ámbito o duración del embargo podía variar, pero el hecho de que con el tiempo expirase era lo que lo distinguía de otras restricciones a los contenidos.

En la versión 3 de la herramienta, esta funcionalidad se ha extendido con una opción avanzada, que se establece en la siguiente línea del fichero dspace.cfg:

 xmlui.submission.restrictstep.enableAdvancedForm = true

El embargo avanzado permite establecer embargos para bitstreams de manera individualizada, añadiendo nuevas políticas de acceso a los mismos. Ofrece al usuario la oportunidad de gestionar manualmente las políticas de acceso a los bitstreams, con lo que además de poder establecer el embargo para los usuarios anónimos, se hacen posibles situaciones como establecer el embargo para cualquier usuario excepto para los pertenecientes a un grupo determinado, o establecer el embargo para ciertos grupos y no para otros, etc.

Adicionalmente, se ha incluido la posibilidad de hacer privados los ítems, permitiendo controlar la visibilidad de sus metadatos en los diferentes índices de la herramienta (búsqueda, navegación, discovery, etc), así como en las interfaces externas (REST-API, OAI-PMH, etc). En este caso, sólo los usuarios administradores podrán acceder a los ítems privados, con la nueva opción “Items Privados” del menú “Administrativo”, que les permite visualizar la lista de ítems privados existentes.

También es posible ajustar el estado “Público/Privado” de un ítem después de que haya sido archivado en el repositorio, con un nuevo botón disponible en la pantalla de edición de ítems. Pero hay que tener en cuenta que una vez el estado de un ítem sea privado, sólo los administradores podrán acceder a ellos para cambiarlo al estado público.

Hay que señalar que los usuarios de la Interfaz JSPUI todavía no podrán beneficiarse de algunas de estas mejoras, ya que por en la version 3 sólo están disponibles para la Interfaz XMLUI.

Incorporar javascript en DSpace

Enviado por Adán Román el 2013/10/17 Comentarios desactivados

Alguna vez se nos ha ocurrido introducir algo de comportamiento dinámico en nuestro repositorio DSpace, ya sea para cambiar el comportamiento de la página sin necesidad de cargar una nueva, o por el hecho de introducir efectos que solo javascript nos puede proporcionar.

Si cumples las anteriores condiciones, entonces continúa leyendo esta mini guía en la cual explico de una forma muy simple como introducir un fichero javascript para modificar el comportamiento en XMLUI.

Antes de nada, es recomendable tener un conocimiento básico en lo referente a la creación de temas en XMLUI, puesto que, para insertar un comportamiento javascript a DSpace vamos a tener que usar los temas ya definidos por DSpace (el método recomendado es crear un tema nuevo copiando el existente y a partir de ahí, aplicar los cambios)

Los ficheros que vamos a tener presentes son varios:

[dspace-instalación]/webapss/xmlui/themes/[nombre_del_tema]/[nombre_del_tema].xsl

[dspace-instalación]/webapss/xmlui/themes/[nombre_del_tema]/sitemap.xmap

[dspace-instalación]/webapss/xmlui/themes/[nombre_del_tema]/lib/fichero.js

Para que no suene tan abstractas las rutas, vamos a tomar de ejemplo el tema Classic y hacer las modificaciones sobre él, por lo que el primer fichero descrito antes sería… (suponiendo que el dspace-instalación esté ubicado en el directorio raíz con nombre dspace)

Classic.xsl

Ruta: /dspace/webapps/themes/Classic/Classic.xsl

En este fichero hemos de coger la información pertinente para luego poderle añadir el comportamiento javascript. Por ejemplo si queremos que en el menú aparezca un icono * que al hacer click sobre él nos despligue nueva información, hemos de coger el template correspondiente de la carpeta DRI que controla la zona del menú, pegarlo en nuestro fichero Classic.xsl y ahí lo editamos añadiendo el icono *.(Insisto, esta parte requiere un conocimiento base sobre cómo editar un tema en XMLUI)

Una vez introducido el componente por el cual nos comunicaremos con el javascript, solo nos falta añadir el fichero javascript que controlará la funcionalidad. Este fichero se ha de colocar dentro de la carpeta del tema en cualquier ubicación, aunque lo recomendable es usar la carpeta lib de cada tema.

Este fichero javascript una vez creado por el desarrollador, y ubicado en la posición del tema que queramos, lo único que necesitamos para que funcione es relacionarlo con la información añadida en el fichero XSL. Para hacer esto debemos de hacer la llamada a nuestro javascript desde el fichero XMAP, de tal forma que al pinchar sobre el icono *, este llame al javascript ubicado en la carpeta de nuestro tema a través del fichero XMAP.

Esta llamada va a tener un aspecto tal que así

<map:parameter name=»javascript#2″ value=»lib/fichero.js»/>

En el ejemplo se llama a un fichero llamado fichero.js que está ubicado dentro de la carpeta lib de nuestro tema. He de decir que el name que se da en la llamada tiene que ser único, si no, DSpace nos generará un error.

NOTA: En el ejemplo hemos puesto javascript#2 puesto que ya hay una declaración posterior que es javascript (Esta hace referencia a jquery). El nombre que se le dé siempre es conveniente que siga el patrón siguiente: javascript#numero. El porqué hacerlo así es muy simple: DSpace a la hora de montar la página Web va a incluir esas llamadas a los javascript en el meta y estás han de tener un orden lógico (este orden coincide con el orden alfabético de las peticiones) puesto que si no, DSpace va a tener problemas a la hora de hacer llamadas a Javascript.

Vamos a ver un ejemplo del fichero Classic.xmap

<map:parameter name=»javascript» value=»lib/jquery.js»/>

<map:parameter name=»javascript#2″ value=»lib/fichero.js»/>

Este fragmento de código se ha de introducir dentro de de una etiqueta del XMAP llamada

<map:transform type=»IncludePageMeta»>

Ojo, que esta etiqueta viene definida dos veces dentro del fichero, ya que este fichero antes de aplicar nada, tiene que verificar en qué navegador se está trabajando, (diferencia entre IE6 y el resto de navegadores, por lo que se ha de incluir el fragmento de código antedicho en ambas etiquetas)

Con todo esto ya podemos insertar de forma elegante código DSpace dentro de un tema dado en XMLUI.

Ya para acabar, simplemente decir que si queréis ver un ejemplo de código javascript incluido dentro de un tema, podéis consultar el código fuente incluido en el tema Mirage, en el cual hay algo del comportamiento javascript montado tal y como acabo de relatar.

Request-copy add-on para XMLUI

Enviado por cfernandez el 2013/08/05 1 comentario

El módulo Request-copy para xmlui ha sido puesto a disposición de la comunidad Dspace. Es una conversión al XMLUI de la funcionalidad que en su día (la primera versión era para Dspace 1.3 ¡¡) desarrolló la Universidad de Minho para JSPUI.

La funcionalidad de ‘Solicitar copia’, ‘Request Copy’ o ´Fair dealing button’, que con esa variedad de nombres se refiere esta funcionalidad en la documentación de repositorios, funciona de la siguiente forma:

En todos los items restringidos, es decir no-OA (considerando éstos los que tienen permisos de acceso diferente de Anónimo) se muestra un link a «Solicitar una copia al autor»
El usuario solicitante debe rellenar un formulario con sus datos de contacto y razones de su solicitud.
Esos datos se envían al usuario que realiza el depósito (autores o persona delegada en su nombre).
El autor (o depositante) puede responder al solicitante, usando dos posibles opciones «enviar copia» y «no enviar copia», con mensajes editables.
El mensaje, tal y como lo redactó el autor, se envía al solicitante, con el fichero adjunto, si esa es la opción seleccionada.

El desarrollo se ha realizado en el marco de un proyecto para el Instituto Español de Oceanografía que ha considerado adecuado liberar el código, en palabras textuales, «para que todo el mundo pueda utilizarlo». El código correspondiente a esta función está disponible en un repositorio git , asociado al ticket Jira .

Exprimiendo el interface XMLUI

Enviado por Adán Román el 2013/06/20 2 comentarios

Ya hemos explicado en otro post las diferencias entre XMLUI y JSPUI, dando unas pinceladas sobre el funcionamiento de XMLUI. Nuestra inclinación es más o menos clara, preferimos XMLUI: permite aplicar apariencias diferentes a distintas colecciones, nos parece que separa mejor la lógica de negocio de la lógica de representación, etc …

Pues en este post daremos algunos comandos para acceder a alguno de los puntos intermedios de la cadena cocoon de transformación y que nos podrían ayudar en nuestros procesos de desarrollo y debugging.

Intentaremos (si no nos borran nuestro ejemplo) trabajar con este item http://demo.dspace.org/xmlui/handle/10673/590 (si no funciona, usar cualquier otra URL de un Dspace/XMLUI)

DRI
Para obtener el DRI subyacente debajo de esa URL, tenemos que escribir DRI/
después del path xmlui/
http://demo.dspace.org/xmlui/DRI/handle/10673/590

XML
Para obtener el XML de dicha URL, teclear:
http://demo.dspace.org/xmlui/handle/10673/590?XML
fijaros en todas las etiquetas i18n, es decir estamos antes de aplicar la transformación i18n

Idioma, i18n
Para forzar la aplicación de un idioma (sin tener que cambiar el idioma del navegador)

http://demo.dspace.org/xmlui/handle/10673/590?locale-attribute=es

http://demo.dspace.org/xmlui/handle/10673/590?locale-attribute=en

Tema
A la hora de elegir el tema o «theme» que queremos para nuestra instancia de DSpace es bastante engorroso indicar cuál queremos que sea visualizado editando el fichero [dir_instalación]/config/sitemap.xconf en sus últimas líneas…
Existe un parámetro, en el fichero de configuración dspace.cfg llamado:

xmlui.theme.allowoverrides

y si lo descomentamos y lo activamos a true podremos, podemos forzar (momentáneamente) el uso de los temas que tengamos definidos en nuestro directorio de Themes

http://demo.dspace.org/xmlui/handle/10673/590?themepath=Classic/

http://demo.dspace.org/xmlui/handle/10673/590?themepath=Reference/

Como es de suponer, si vais haciendo esto por los Dspace/xmlui de por ahí os encontrareis que niguno cambia, porque por defecto este parámetro va desactivado en el dspace.cfg. Solo lo recomendamos activar en procesos de depuración de Temas.

Mets
Y si eres de los que enredan con las XSL, esta es la URL necesaria para arrancar tus desarrollos:
http://demo.dspace.org/xmlui/metadata/handle/10673/590/mets.xml

Un saludo

¿el XMLUI?.. pero si es muy fácil

Enviado por cfernandez el 2013/04/01 Comentarios desactivados

Hace muchos años (muchos) tuve que estudiar un libro introductorio a la electrónica cuántica cuyo título terminaba con esa apostilla. Me parece que ese tipo de literatura se ha reconvertido en la seríe de títulos xxxxx, for dummies, con lo que no descartamos pasar a la fama con un libro titulado XMLUI for dummies….

Bromas aparte, comenzemos con un pequeño glosario sobre términos usados en XMLUI:

Cocoon: framework de desarrollo web (del proyecto Apache) que utiliza los conceptos de pipeline y tiene una arquitectura basada en componentes.
Sitemap: fichero XML usado para configurar los diversos componentes Cocoon, que son del tipo: generadores, trasnformadores, serializadores, …
Aspecto/ Aspect: proporciona el conjunto de funcionalidades presentes en la interface de usuario, generando mediante transformaciones encadenadas un documento DRI.
DRI (Digital Repository Interface): esquema, codificado en xml, que estructura y gobierna las páginas XMLUI
Tema / Theme : proporciona el estilo al contenido generado, produciendo el XHTML para su visualización. Básicamente es la herramienta que convierte un documento DRI en un formato legible por el usuario.

Un proceso de construcción de una página DSpace en XMLUI realiza las siguientes tareas:

Generar la página DRI, representación xml de la página solicitada, concatenando los diversos aspectos involucrados: eperson, artifact browser, etc…
Añadir referencias a los ficheros CSS que usará el tema. estas referencias se incluyen en la sección pageMeta del documento DRI. De esta manera las XSL que convierten el documento DRI en XHTML pueden encontrar esas referencias y ponerlas en la salida XHTML
Transformar DRI a XHTML. Generalmente (depende algo del tema y de las personalizaciones efectuadas) se hace a través de la librería dri2xhtml.xsl o el código modificado que se haya escrito.
Se internacionaliza la página, invocando el transformador Cocoon i18n para resolver las etiquetas <i18n:text>
Se envía al navegador, aplicando la CSS correspondiente.

Y visto de otra manera, más directa ¿o más práctica?…. ¿cuáles son los elementos involucrados en una customización de DSpace-XMLUI?

Modificación simples al diseño, creación de temas simples: XHTML + CSS
Modificaciones complejas al diseño, creación de temas complejos: XSL + XHTML + CSS
Añadir nuevas funcionalidades, modificación de los «aspects»: Cocoon + Java

Página siguiente »

Archivos de Tags: xmlui

Metodología Usada

Resultados

Contenidos