(sólo) un repositorio, ni (sólo) una biblioteca Digital, ni (sólo)

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.
¿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
2
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.
3
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.
4
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
5
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.
6
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.
7
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
8
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.
9
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
10
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.
11
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
12
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
13
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,
14
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>
15