Date submitted: 06/04/2010

-No (sólo) un repositorio, ni (sólo) una biblioteca Digital, ni (sólo) un portal: un retrato de Europeana como API Cesare Concordia CNR-ISTI Pisa, Italia cesare.concordia@isti.cnr.it Stefan Gradmann Humboldt-Universität zu Berlin Berlín, Alemania stefan.gradmann@ibi.hu-berlin.de Sjoerd Siebinga Europeana Development La Haya, Holanda sjoerd.siebinga@kb.nl

Traducción de la Biblioteca Nacional de España

Meeting: 193. Information Technology

WORLD LIBRARY AND INFORMATION CONGRESS: 75TH IFLA GENERAL CONFERENCE AND COUNCIL 23-27 August 2009, Milan, Italy

http://www.ifla.org/annual-conference/ifla75/index.htm

Resumen El público en general percibe a Europeana como un portal que exhibe una gran cantidad de información referente al patrimonio cultural. Aunque esta percepción no es del todo errónea, el principal objetivo de Europeana es, por el contrario, la construcción de una plataforma abierta de servicios que permita que tanto usuarios como instituciones culturales accedan a y gestionen una larga colección de objetos digitales que actúen como sustitutos documentales y que incorporen contenidos digitales o digitalizados a través de una API o “Interfaz de Programación de Aplicaciones” (Application Program Interface). Este trabajo analiza algunos detalles del esquema global del espacio de datos, de la descripción de la API y de las implementaciones del Portal Europeana, a la par que estudia la casuística de uso y el enfoque mental que los usuarios -y, en particular, las instituciones culturales- deberían adoptar a fin de aprovechar el potencial de Europeana como plataforma de servicios, ofreciendo asimismo una evaluación de los riesgos asociados. Los autores del trabajo son figuras clave en el proceso de especificación, desarrollo e implementación de Europeana que actualmente se halla en curso.

2

¿Qué es Europeana? De acuerdo con la percepción general, Europeana es, principalmente, un portal que pone a disposición de los ciudadanos europeos cantidades progresivamente impresionantes de patrimonio cultural proveniente de fuentes diversas. Aunque esta percepción, lógicamente, no es del todo equívoca (e incluso concuerda con la mayor parte de la información transmitida por la Comisión Europea en torno a Europeana), no capta las características esenciales de lo que tratamos de construir. A un nivel muy abstracto, Europeana puede ser concebida como una vasta colección de objetos que actúan como sustitutos documentales (surrogate objects), representando objetos patrimoniales nacidos digitales o digitalizados que en sí mismos permanecen fuera del espacio de datos de Europeana (pero que, no obstante, necesitan que se acceda inicialmente a ellos a través de Europeana para poder ser procesados, a fin de generar las representaciones sustitutas). En esta visión abstracta, los objetos sustitutos o surrogates se encuentran unidos unos a otros, contextualizándose además mediante enlaces a los nodos de una red semántica que actúa como segunda capa de datos en Europeana. Estos dos enlaces son utilizados conjuntamente para crear la funcionalidad integrada que ofrece la interfaz de uso. Esta perspectiva se ilustra según lo expuesto a continuación en la figura 1.

Figura 1: Red Semántica y objetos sustitutos en red Asimismo, como se muestra a continuación en la figura 2, estos sustitutos pueden poseer una estructura interna relativamente compleja: los círculos en azul claro muestran partes constituyentes de un Objeto Digital Sustituto o DSO (Digital Surrogate Object) tales como metadatos, información acerca de licencias, abstracciones (como por ejemplo tablas de contenidos o histogramas a color), anotaciones y representaciones del sustituto tales como páginas de inicio o mapas de recursos ORE. Al mismo tiempo, los DSOs pueden estar integrados por otros DSOs, como en el caso de un libro escaneado

3

que contenga sustitutos individuales para cada página. Por otra parte, los DSOs enlazan contextualmente con otros DSOs y con nodos conceptuales (los círculos en morado), como por ejemplo aquellos que representan entidades espaciotemporales o conceptos abstractos.

Figura 2: Objeto digital sustituto Tanto la estructura interna de los sustitutos como su contextualización se construyen a partir de los elementos suministrados por los proveedores de contenido, pero algunas partes sustanciales de esta estructura y contexto se crearán en el transcurso de las rutinas de ingestión de datos llevadas a cabo por Europeana. Por lo tanto –y tal y como se indica seguidamente en la figura 3– Europeana no sólo dispondrá de una API para la funcionalidad de usuarios finales, según lo que se detalla a continuación, sino que permitirá un flujo de datos I/O-API de y hacia los proveedores de contenido –en este último caso cabe la posibilidad de re-integrar el contenido enriquecido en las aplicaciones remotas de los proveedores de datos.

4

Figura 3: Visión Global de Europeana La esencia misma del proyecto Europeana es, por lo tanto, esforzarse en la construcción de una plataforma abierta que fomente la interoperabilidad a nivel funcional, técnico y de los datos. ¿Qué es una API? Según el Manifiesto DELOS DL [1], podemos concebir el software de Europeana como un “Sistema para Biblioteca Digital” o DLS (Digital Library System), sistema que se define como: “un sistema de software que se basa en una arquitectura definida (posiblemente distribuida) y que proporciona todas las funcionalidades que una Biblioteca Digital dada pueda precisar”. Diseñar un DLS es una tarea compleja, que requiere integrar conocimientos y metodologías de disciplinas diversas, tales como la gestión de contenidos, la gestión de metadatos, la recuperación de información, la gestión de bases de datos distribuidas y la interacción hombre-ordenador, por mencionar tan sólo las más relevantes [2]. Implementar un DLS requiere, por tanto, de la construcción de un software sofisticado y extensible que integre técnicas y tecnologías de las disciplinas antes mencionadas en un sistema coherente. El núcleo de un sistema de software de este tipo recibe el nombre de “Sistema de Gestión de Biblioteca Digital” o DLMS (Digital Library Management System) [1]. Por lo general, un DLMS es un sistema de software cuya implementación combina la lógica empresarial y las funcionalidades de acceso a los datos que rigen la creación, gestión y administración de DLSs; ejemplos de DLMS son DSpace [3] y BRICKS [4]. Para el proyecto Europeana 1.0 decidimos construir un DLMS mediante (a) la adaptación de componentes tomados de soluciones comerciales y (b) el desarrollo de componentes originales de software que ofreciesen sofisticadas funcionalidades de la Biblioteca Digital Europeana que ninguna otra solución existente hubiese brindado con anterioridad.

5

Las funcionalidades ofrecidas por el DLMS Europeana 1.0 pueden ser agrupadas en cinco áreas:

• Área de Captura y Difusión, que ofrece funcionalidades que permiten la introducción de nuevos contenidos en Europeana, así como su difusión;

• Área de Gestión de Objetos, que proporciona funcionalidades para la gestión de objetos con contenido digital, de sus correspondientes sustitutos y de los metadatos asociados a ambos;

• Área de Búsqueda, que permite la indexación y la exploración de los contenidos de Europeana de acuerdo con diversos parámetros;

• Área de Usuarios, que alberga la funcionalidad que permite la gestión de usuarios, tanto de individuos como de instituciones, así como la posible agrupación de los mismos en comunidades dinámicas;

• Área de Acceso, que permite el acceso tanto a servicios y contenidos de Europeana como a recursos externos

Cada área funcional está implementada por un conjunto de componentes de software. Uno de los objetivos principales es convertir el DLMS de Europeana en un sistema extensible, en el que sea posible añadir de forma fácil componentes nuevos capaces de ofrecer funcionalidades más sofisticadas o reemplazar cuando sea preciso otros componentes existentes. Para lograr esta extensibilidad, puede accederse a cada uno de los componentes de la arquitectura de Europeana mediante una Interfaz de Programación de Aplicaciones o API, que muestra todos los métodos públicos del componente; asimismo, las interacciones entre componentes tendrán lugar exclusivamente a través de sus APIs. Un subconjunto de los métodos API de los componentes del DLMS se publicará y se pondrá a disposición de las aplicaciones externas; el conjunto de estos métodos compondrá lo que llamamos “la API de Europeana”. El objetivo es permitir que otros desarrolladores construyan aplicaciones utilizando las funcionalidades del DLMS de Europeana, y que, en algunos casos, se lleguen a ampliar esas funcionalidades.

Figura 4: Funcionalidad API y DLMS

6

Para ocultar la complejidad del sistema subyacente, la API de Europeana será publicada como un conjunto de métodos, terminales API y protocolos de llamada. Un desarrollador que desee construir una aplicación que use una funcionalidad del DLMS de Europeana podría escribir una rutina llevando a cabo tres tareas (véase la sección de Casos de Uso para encontrar un ejemplo):

• Seleccionar un protocolo de llamada y formatear una petición en base a ese mismo protocolo, especificando un método y sus argumentos;

• Enviar la petición a un terminal específico; • Recibir la respuesta respectiva

Los protocolos de llamada adoptados en Europeana se mapearán, inicialmente, de acuerdo con tres técnicas estándar de intercambio de información estructurada: la Transferencia de Estado Representacional o REST (Representational State Transfer), XML-RPC (http://www.xmlrpc.com/) y el protocolo SOAP (Simple Object Access Protocol, http://www.w3.org/TR/soap/). REST es una acción HTTP GET o POST; el nombre del método y los parámetros son transmitidos como valores de palabras clave definidas; en XML-RPC la petición es formateada en XML de acuerdo con un esquema definido y enviada a una URL y las peticiones SOAP hacen las veces de “sobres” de datos XML formateados y enviados a una URL. Una característica importante de estos formatos es que pueden ser utilizados para construir aplicaciones distribuidas; esto significa que otros desarrolladores pueden construir una aplicación organizada en su propio servidor y utilizar una infraestructura de comunicación (como por ejemplo la Red) para interactuar con el DLMS de Europeana. El formato de datos empleado para la respuesta depende del método de llamada y del protocolo utilizado; lo normal es que se trate de un archivo XML. Sin embargo, en el caso de algunos métodos, el DLMS de Europeana proporcionará asimismo el formato estándar de intercambio de datos JSON (http://json.org) para ayudar, por ejemplo, al trabajo de los desarrolladores que estén escribiendo Interfaces Gráficas de Usuario o GUI (Graphic User Interface) basadas en AJAX. Otro importante formato de datos compatible es el OAI-PMH, que puede ser utilizado por aplicaciones externas para recolectar contenidos alojados en Europeana. El formato de datos de la respuesta puede especificarse como parámetro de búsqueda. Hay que señalar que prácticamente todos los lenguajes de programación son compatibles con los protocolos y técnicas anteriormente mencionados y que existen diversos esquemas que proporcionan una API compatible, por lo que el DLMS de Europeana resulta fácilmente extensible. Por supuesto, publicar la API de Europeana significa que el DLMS de Europeana deberá incluir un marco de seguridad que facilite las funcionalidades de autenticación/autorización de los protocolos de la API y el cifrado/descifrado de textos en aquellos casos en los que la información deba permanecer en secreto.

7

Figura 5: Aplicaciones externas interactuando con la API Casos de uso para Europeana Caso de uso: aplicación externa “Moodle” Una “aplicación externa Europeana” es una aplicación que utiliza al menos un servicio de los que ofrece Europeana a través de su API. En este párrafo se describe brevemente un caso de uso sencillo: cómo construir un complemento o “plug-in” para el Sistema de Gestión de Cursos de Moodle o CMS (Moodle Course Management System, http://moodle.org ) utilizando la API para Búsqueda Avanzada de Europeana. La arquitectura de software de Moodle se articula en base a sus componentes –varias de sus principales prestaciones se implementan a través de componentes individuales denominados módulos, entre los que se cuentan temas, actividades, lenguajes de interfaz, esquemas de bases de datos y formatos de curso; es más, el sistema proporciona una API, permitiendo a los desarrolladores construir nuevos módulos. Si un(a) profesor(a) desea añadir una funcionalidad particular a un curso, ella o él pueden construir un módulo y añadirlo al servidor de Moodle siguiendo las especificaciones. Una vez que el módulo ha sido correctamente instalado puede ser cargado como una miniaplicación o “widget” en la Interfaz Gráfica de Usuario o GUI del curso, de forma que sus funcionalidades pasarán a estar a disposición de los demás usuarios del curso. El diagrama secuencial que se muestra en la siguiente figura ejemplifica cómo podría interactuar con el terminal API un módulo (concretamente un módulo de actividad) que emplease la API de Europeana para buscar objetos almacenados en la biblioteca digital.

8

Figura 6: Utilizando la API para conectar Moodle con Europeana Para utilizar la API de Europeana, un desarrollador Moodle debería, en esencia, poner en funcionamiento las siguientes tareas:

1. Formateado de búsquedas. Como vimos en el párrafo anterior, cada terminal API es compatible con uno o más protocolos de llamada –el desarrollador sabrá, a partir de la documentación API, cuáles son los admitidos por el gestor Europeana Discovery y formateará consiguientemente la consulta de acuerdo con uno de ellos.

2. Codificación de búsquedas. Puede darse el caso de que un desarrollador desee construir un módulo que permita además realizar búsquedas en información que se halle fuera del dominio público. Para implementar este tipo de búsqueda se necesita una llave que permita cifrar y descifrar la información y/o una tarjeta de identificación; el desarrollador debe obtener las llaves y las tarjetas de identificación con antelación para poder utilizarlas a la hora de cifrar búsquedas enviadas a terminales API.

3. Análisis del conjunto de resultados. Al igual que ocurre con los protocolos de llamada, el formato en el que una invocación de métodos produce los resultados también será documentado. En la implementación actual del prototipo, el conjunto de resultados de una búsqueda avanzada se formatea como un archivo JSON.

La API de Europeana proporcionará métodos y herramientas para ayudar a los desarrolladores a construir sus aplicaciones. Informática para las Humanidades Europeana albergará un inmenso caudal de artefactos extraídos de todos los ámbitos de nuestro legado cultural, por lo que su potencial a la hora de servir de ayuda a todo

9

género de estudios relacionados con la cultura -y, fundamentalmente, con las Humanidades- será cada vez mayor. Nuestro segundo caso de uso está por tanto tomado del ámbito de las Humanidades y, más específicamente, del campo de la Filología. Imaginémonos a una investigadora que trabajase con manuscritos medievales. El manuscrito que le ocupa se representa en Europeana como un sustituto digital complejo, en el que las reproducciones de baja calidad de las páginas escaneadas forman, al igual que la representación de las marcas de agua encontradas en el manuscrito, parte de las abstracciones. En la parte de los metadatos del objeto sustituto, la investigadora advierte que el manuscrito data de 1480 y que se supone que fue escrito en Estrasburgo. La marca de agua encontrada en el manuscrito es un ancla –y, afortunadamente, uno de los recursos contextuales de Europeana es la base de datos WZMA, que contiene marcas de agua medievales provenientes de la Academia de las Ciencias austríaca. Nuestra investigadora descubre que existen otras dos marcas de agua exactamente idénticas a la que ella ha encontrado en su manuscrito en otros dos manuscritos, ambos aparentemente escritos en Estrasburgo, pero fechados en 1446. A partir de esta combinación de información contextual, disponible a través de Europeana, nuestra investigadora concluye que debe haber un error en la datación del manuscrito, ya que está al corriente de que una marca de agua dada solía permanecer en uso por un período determinado de años, que en ningún caso alcanzaría los 34 años. Así que crea una anotación, insertando el enlace al recurso de la WZMA y añadiendo un comentario acerca del supuesto error de datación. Llegados a este punto, nuestra investigadora ha alcanzado el límite probable de lo que puede llegar a hacer con Europeana: tiene a su disposición suficientes elementos de ilación como para sospechar de la exactitud de la fecha, pero para efectuar una nueva datación correcta posiblemente necesite acudir a un sitio web que contenga datos de digitalización de alta calidad, e incluso puede que finalmente tenga que desplazarse hasta Viena, donde el manuscrito puede ser consultado en la Biblioteca Nacional de Austria. El Portal de Europeana como implementación de referencia El prototipo del portal de Europeana se lanzó en noviembre de 2008 (véase http://www.europeana.eu). Su objetivo principal era hacer de escaparate de las posibilidades de la interoperabilidad transcultural de los dominios a nivel paneuropeo. Los metadatos de archivos, bibliotecas, museos y archivos audiovisuales se pusieron a disposición de los usuarios a través de una única interfaz. Las principales funcionalidades que el prototipo de portal ofrecía eran:

• Dar información a los usuarios acerca de la iniciativa Europeana; • Navegar a través de los resultados utilizando un timeline o línea del tiempo,

consultando términos de búsqueda proporcionados por otros usuarios, o bien ojeando ítems de consulta frecuente mostrados en el carrusel de la página de inicio;

• Y, por último, buscar a través de los módulos de búsqueda sencilla y búsqueda avanzada.

10

Desde sus inicios, el portal se concibió como un thin client (cliente ligero) de la API de búsqueda. Muchas de las características avanzadas -descritas en la sección “Qué es Europeana”- estarán disponibles únicamente a partir de las próximas actualizaciones, previstas para mediados de 2010 y 2011. Así que, ¿cuál será el rol del portal de Europeana en el futuro? Con toda probabilidad, desempeñará su papel como implementación de referencia de la API de Europeana. Las nuevas características de la API verán la luz por primera vez en el Portal de Europeana. Algunos de los principales desafíos que plantea la interacción entre el portal y la API giran alrededor de cómo abordar el multilingüismo y encontrar formas innovadoras de presentar conjuntos de resultados tremendamente extensos (lo que se conoce por “infografía”). Ciertas características nuevas, como por ejemplo la presentación geotemporal y la agrupación contextual de conjuntos de resultados, están siendo sometidas a debate actualmente. Una búsqueda por una localidad o fecha, independientemente de cuán estrechamente se acote, arrojará miles de resultados relevantes. Si se busca por “París” en todas las fechas actualmente mostradas en las facetas los resultados relevantes sobrepasarán el millar. Si se selecciona la fecha “1888” en la línea del tiempo del portal nos encontraremos con casi 50.000 resultados que habrá que filtrar. Que toda la información esté disponible en múltiples lenguas al principio sólo conducirá a una explosión combinatoria de resultados relevantes. Obviamente, si uno está buscando “painting river” en inglés y la consulta se expande con las traducciones a las 27 lenguas europeas de “painting river”, el conjunto de resultados se incrementará notablemente. Es aquí donde las agrupaciones contextuales cobran su importancia. El usuario necesita ser capaz de filtrar un conjunto significante y manejable de resultados, extraído a partir de otros cientos de miles de resultados. Llegados a este punto es importante señalar que Europeana se resiente de albergar una cantidad tan grande de metadatos de alta calidad. Prácticamente todos los resultados de la búsqueda de la frase “painting river” en Europeana serán relevantes, por lo que el desarrollo de herramientas que permitan las agrupaciones contextuales y la creación de representaciones gráficas que ayuden a los usuarios a dotar a los resultados de sus búsquedas de sentido cobra una importancia crucial. Un cambio de mentalidad: hacia los espacios públicos culturales compartidos El planteamiento expuesto aquí se asienta sobre una firme premisa: suponemos que, en vez de intentar sustentar los silos de información digital del pasado, las comunidades creadas en torno al patrimonio cultural se encuentran preparadas para aceptar un paradigma de información basado en la relación entre datos y que, por ende, se hallan dispuestas a compartir la mayor cantidad de contexto semántico posible. El giro copernicano desde el paradigma del portal hasta la visión de la API como principal encarnación de Europeana sólo puede cobrar su sentido auténtico en el marco de una disposición mental como ésta. Este cambio de mentalidad implica dar un salto enorme, ya que exige que las instituciones patrimoniales abandonen una forma de pensar que las limita primordialmente a sus colecciones particulares para comenzar a pensar en lo que estas colecciones pueden aportar a un flujo continuo de información más grande, complejo y

11

distribuido que, al unirse a diversos recursos contextuales, permita que los usuarios europeos conviertan agrupaciones parciales de información en conocimiento relevante para su contexto específico. El concepto, así pues, no se basa tanto en la agregación anticipada de información en estructuras fijas para una posterior reutilización básicamente estática como en lograr que esta información se encuentre disponible junto con elementos funcionales básicos en una diversidad de escenarios de uso no definidos exclusivamente por Europeana: “colaboratorios” de Becas-e, bibliotecas digitales de todo tipo, el portal mismo de Europeana... La idea básica subyacente es que todos ellos utilicen Europeana como una suerte de espacio público cultural compartido, dirigiéndose a la API que muestra los datos y funcionalidades de Europeana de forma genérica. Como parte de este cambio de mentalidad, las instituciones patrimoniales también necesitarán sentir –de forma creciente- que son parte de una comunidad más amplia, que comparte un conjunto de estándares genéricos a la hora de organizar la información y hacerla accesible: los estándares a que hacemos referencia aquí serán creados en su mayor parte por instancias externas, tales como el Consorcio W3C, ¡y no por las propias comunidades patrimoniales! Propuesta de valor La API de Europeana es un valor añadido tanto para los organismos partícipes como para los usuarios, si bien el valor añadido cobra forma distinta en uno y otro caso. El servicio Europeana necesita mantener el delicado equilibrio entre colmar las necesidades de los usuarios y satisfacer las exigencias de las partes interesadas. Los siguientes párrafos albergan una selección de los aspectos de valor añadido de la API de Europeana. Mayor visibilidad y desarrollo coherente de una imagen de marca: Europeana es un punto de acceso a la información de perfil alto que ofrece una muestra representativa sin par del patrimonio cultural digital europeo. El contenido que forme parte de Europeana tendrá que tener, por lo tanto, una visibilidad inherentemente mayor que si se mostrase a través del sitio web de los proveedores de contenido. Por añadidura, la API de Europeana ofrecerá una estrategia de desarrollo de marca coherente tanto para Europeana misma como para los agregadores a nivel nacional o de dominio y para los proveedores de contenidos. Esta estrategia de marca incrementará la visibilidad tanto de los contenidos como de sus proveedores. Minería de datos eficaz y reutilización de datos enriquecidos: Extraer información útil de los metadatos y de otros datos indexables es muy laborioso desde el punto de vista informático, por lo que a menudo resulta demasiado caro para instituciones individuales. La infraestructura de Europeana utiliza minería de datos puntera y técnicas de enriquecimiento para la identificación de personas, lugares, eventos y conceptos, alineándolos con vocabularios controlados existentes. Esta información adicional se halla disponible a través de la API para que pueda ser reutilizada en la infraestructura de los proveedores de contenidos.

12

Ayuda multilingüe: Uno de los mayores obstáculos a la hora de crear un acceso paneuropeo a los objetos culturales patrimoniales es la recuperación de información entre varias lenguas. En versiones futuras, la API de Europeana ofrecerá servicios multilingües tales como la traducción y expansión de consultas, la traducción de metadatos y la elaboración de transcripciones ortográficas en distintos idiomas de entidades nominales tales como nombres de persona y de lugar. Determinabilidad persistente: Ya que Europeana aspira a convertir cada objeto ingerido en una URI determinable persistente, los ítems individuales pueden integrarse en servicios web conocidos por todos, tales como Wikipedia, Google Scholar, Facebook, etc. Aunque el identificador de los proveedores de contenidos pueda cambiar, el mecanismo de ingestión de Europeana efectuará un seguimiento del objeto correcto. Tener una URI persistente determinable es uno de los prerrequisitos necesarios para que los sustitutos digitales de Europeana puedan funcionar en contextos de Web Semántica, tales como, por ejemplo, el sistema de datos distribuidos de linked-data (http://linkeddata.org/). Reutilización de los servicios: Los servicios web ofrecidos por la API de Europeana pueden ser utilizados para optimizar la funcionalidad de la interfaz web de la institución. Por ejemplo, dando información acerca de cómo agrupar un determinado conjunto de resultados basado en personas, lugares, conceptos, etc. Además, la información geoespacial y temporal enriquecida que proporciona Europeana podría emplearse para crear aplicaciones personalizadas para líneas de tiempo y mapas. Análisis de riesgos En ciertos casos las necesidades de los usuarios y de los organismos partícipes pueden ser ortogonales y estas diferencias pueden llegar a considerarse como amenazas potenciales para el éxito de la API de Europeana. Estos riesgos pueden subdividirse en dos categorías: 1) riesgos que debilitan las proposiciones de valor y 2) riesgos que pueden conducir hacia usos no deseados de los datos más allá de la esfera original de uso en la que se desenvuelven las partes interesadas. Riesgos que mitigan las proposiciones de valor Las mayores amenazas para el enfoque de Europeana entendida como API son su insuficiente adopción y la ausencia de participación por parte de la comunidad. Para que una API sirva para algo la gente necesita comenzar a utilizarla. Afortunadamente para Europeana, siempre existirá al menos un usuario -a saber, la implementación de referencia del portal de Europeana. Las nuevas prestaciones de la API podrán verse en la sección thoughtlab (“laboratorio de ideas”) del portal en cuanto se estrenen. El éxito de la API dependerá también de lo fácilmente accesible que llegue a ser. Inicialmente, la API se hallará exclusivamente a disposición de los miembros de Europeana. El acceso a la API se moderará con toda probabilidad mediante la

13

obligatoriedad de disponer de una “wskey” para usar el servicio web. A partir del lanzamiento de Rhine (julio de 2010), podrá accederse a muchos de los servicios web en su versión completa de forma totalmente libre. Sin embargo, puede que la accesibilidad de algunos de los elementos sustitutos se vea aún sujeta a acuerdos con los proveedores de contenidos. La magnitud de la adopción de la API por los miembros de Europeana dependerá en gran medida de lo relevante que resulte para ellos. Para los colaboradores, la parte más relevante de la API será la reutilización de datos enriquecidos. Así pues, para estimular su adopción y proporcionar valor añadido al hecho de convertirse en un usuario de la API, Europeana necesita suministrar documentación exhaustiva y proporcionar asistencia técnica. Por último, el tema de los derechos de propiedad intelectual (DPI) resulta siempre controvertido cuando cualesquiera contenidos se hacen accesibles vía Internet. La red Europeana en pleno está elaborando actualmente una propuesta para afrontar este problema de forma global. Para poder convertirse realmente en parte del flujo de trabajo de la gente a la hora de recopilar información, Europeana necesita ir más allá de proporcionar en su mayor parte tan sólo acceso a metadatos sobre objetos. Los usuarios desean disfrutar de algún tipo de experiencia multimedia con los objetos de su interés y, para que esto sea posible, la cuestión de los DPI necesita ser resuelta. Riesgos que conducen a usos no deseados de los datos Una diferencia notable entre el Portal y los usuarios de la API de Europeana es que el Portal está configurado para posibilitar que sean los intereses de los usuarios los que determinen los resultados de las búsquedas. Sin embargo, para ciertos usuarios de la API de Europeana, esta máxima puede no cumplirse. Por ejemplo, algunas de las aplicaciones que utilizan Europeana como API pueden reunir datos en formas que nuestros usuarios pueden llegar a considerar ofensivas. Una agrupación de artefactos ligada diacrónicamente al “genocidio” puede considerarse perfectamente válida desde el punto de vista académico y sin embargo resultar políticamente indeseable. Los “amasijos” o mash-ups también pueden comportar usos imprevistos que pueden resultar poco recomendables. Por ejemplo, la información utilizada desde la API de Europeana puede convertirse en una parte subordinada del mash-up en vez de constituirse como su componente central. Así que la cuestión es cuán combinable desean -o desean permitir- los usuarios de Europeana que sea la información. Por añadidura, el peso que se le dé a la “creación de marca de identidad” o branding de los conjuntos de datos de Europeana necesita ser sopesada cuidadosamente. Es fundamentalmente cuestión de qué necesitamos y de qué deseamos potenciar. Resulta de indiscutible importancia el que siempre que se utilice la API de Europeana tanto el origen como la procedencia de los datos se identifiquen claramente. Esto es aplicable tanto para Europeana como para el desarrollo de la imagen de marca de los conjuntos de datos que realicen los proveedores de contenidos. El escenario más probable será que todas las respuestas de la API contendrán información sobre la procedencia del contenido, si bien la decisión de cómo se muestra esta información al usuario de la API se dejará como recomendación. Conclusión

14

Como ya se indicó en el título de esta colaboración, Europeana es, de esta forma, mucho más que una Biblioteca Digital: es, en el sentido definido por el manifiesto DELOS, un DLS, pero un DLS basado al mismo tiempo en un DLMS, según el desarrollo realizado al hilo de los proyectos EuropeanaV 1.0 y EuropeanaConnect, y que puede ser usado a su vez para generar variedades distintas de DLS. La API a que hacemos referencia en esta contribución es en parte una API genérica del DLMS y en parte (sobre todo en lo concerniente a los sustitutos digitales) una API del DLS de Europeana. En este sentido, las funciones API del DLMS permanecerán completamente abiertas, mientras que las funciones API del DLS podrán estar sujetas a condiciones específicas de acceso tal y como se ha mencionado anteriormente. Europeana es también mucho más que un repositorio –y al mismo tiempo mucho menos: Europeana no contendrá objetos digitales originales (ya que habrá que seguir accediendo a éstos a través de sitios controlados exclusivamente por los propietarios de los derechos). Sin embargo, al crear ricos sustitutos digitales como representaciones de estos objetos (incluyendo punteros dirigidos al objeto original) y al dotarlos asimismo de complejos contextos semánticos, Europeana generará una serie de valores añadidos que podrán ser transferidos de vuelta a los proveedores de contenidos utilizando la API: ¡los flujos de datos entre los proveedores de contenidos y Europeana deberían ser considerados bidireccionales! Y, finalmente, Europeana es mucho más que un portal: aunque ofrece funcionalidades de portal, su incorporación técnica principal es la Interfaz de Programación de Aplicaciones (o API, en sus siglas inglesas) sobre la que se construirán los servicios del portal. Europeana, por tanto, brinda a las instituciones patrimoniales una ruta migratoria con la que poder convertir los silos en los que hoy día se albergan las colecciones en un servicio web multidimensional basado en la arquitectura de la información y concebido como un entorno que a la vez facilita y exige el cambio de mentalidad que, en cualquier caso, las instituciones patrimoniales deberán operar sobre sí mismas en el futuro. En este sentido –y siendo plenamente conscientes de los riesgos que comporta nuestro enfoque- creemos que para Europeana un modelo de inspiración API tal como éste, en trance aún de especificación en estos meses, será un éxito rotundo, sobre todo cuando los principales motores de búsqueda comiencen a utilizar nuestra API para mostrar el patrimonio cultural europeo dentro de sus conjuntos de resultados e incorporen la marca “Europeana” a los sustitutos digitales: esta colaboración, entre otros objetivos, pretende servir de invitación a la cooperación en este respecto. Referencias 1. Candela L., et al, 2007 Setting the Foundations of Digital Libraries. The DELOS Manifesto. DLib Magazine, March/April 2007, Volume 13 Number 3/4. 2. Marcos André Gonçalves, Edward A. Fox, Layne T. Watson, and Neill A. Kipp (2004). Stream,

15

Structures, Spaces, Scenarios, Societies (5S): A Formal Model for Digital Library ACM TOIS, vol. 22, No 2, pp. 270-312. 3. Smith, et al, 2003: DSpace: An Open Source Dynamic Digital Repository. D-Lib Magazine 9, 1 (January 2003). 4. Nicola Aloia, Cesare Concordia, Carlo Meghini: Implementing BRICKS, a Digital Library Management System. Proceedings of SEBD 2007, the 15th Italian Symposium on Advanced Database Systems. Torre Canne, Brindisi, Italy. June 2007. pp. 4-15 5. REST: Roy Fielding Architectural Styles and the Design of Network-based Software Architectures. Irvine / Cal. 2000 <http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm>