viernes, 16 de diciembre de 2011

Mensaje de Navidad 2011

Nos vemos de nuevo en enero 2012, después de la llegada de los reyes.

jueves, 8 de diciembre de 2011

¿Por qué hoy se trabaja tanto en Arquitectura de Información?






Trabajar en Arquitectura de Información es hoy un imperativo.
Por diversas razones, las estrategias que usábamos en el
pasado resultan insuficientes.

¿Cuáles son los aspectos de la realidad que han estado cambiando y que requieren un trabajo intenso de Arquitectura de Información? ¿Qué es lo diferente en el reto de desarrollar un servicio de información que justifique un nuevo enfoque de integración de conocimientos de Ciencias y Tecnologías de la Información? ¿Hasta donde nos ayuda y hasta donde nos limitan nuestros conocimientos previos en una de estas dos fuentes de conocimientos? Esos son los temas de nuestro post semanal.

Como Luis Rosenfeld y Peter Morville presentan (ver El Libro del Oso Polar...), muchos de los sistemas de información modernos son productos muy diferentes de los sistemas informáticos que construíamos en el pasado. Estos, en el contexto de la institución que los albergaba, estaban restringidos en alcance, tamaño, contenido y audiencia. En las palabras de los autores: “Los viejos sistemas de información eran estrechos en su alcance, pequeños en tamaño, más homogéneos en su contenido y formato y tenían audiencias focalizadas”.

Toda esta realidad cambia con la popularización de la World Wide Web. La Web “tiene una cantidad extremadamente más grande e indeterminada de contenidos, abarca cada tópico conocido bajo el sol, usa muchos más formatos y es usada por cada audiencia imaginable” (Ibid.). Esto representa un cambio de escala tan grande que la diferencia deja de ser cuantitativa para pasar a ser cualitativa. Se trata de otra realidad que requiere de un diseño de servicios diferente (Ver Usuarios + Contenidos + Contexto). La analogía con la construcción civil puede hacerse fácilmente: en la medida en que la humanidad comenzó a dominar nuevos materiales y técnicas de construcción se definió el espacio conceptual de la ingeniería, pero también el de la Arquitectura, que debería estar a tono con las nuevas posibilidades.

Así, en una Internet donde la presencia de poderosos buscadores acercan a una múltiple gama de usuarios a nuestros contenidos y un mecanismo de gestión de la hipertextualidad tan poderoso como la Web permite enlazar no sólo nuestros contenidos entre sí, sino nuestros contenidos con los contenidos de otros y todos con aplicaciones propias y ajenas, se conforma una nueva realidad en la que los conocimientos informáticos y de tecnología, de gestión de datos y de protocolos, son necesarios pero insuficientes para el diseño de las soluciones de gestión. Por otro lado, se requiere la comprensión de las estructuras de información más allá de las conexiones de tablas de datos, las gestión de la navegación ya no es el mero diseño de menús, la funcionalidad de la información para los usuarios es más compleja por la diversidad de perfiles y por ello se requieren estrategias y conceptos de clasificación, organización y de gestión de información novedosos, fundidos en el crisol transdisciplinario de la Arquitectura de información (Ver AI: Confluencia de Ciencias y Tecnologías de la Información).

Es como dice Rosenfeld y Morville, la heterogeneidad hace mucho más duro de indexar la Web y hace más difícil la búsqueda. Poco puede asumirse acerca de los usuarios y el tipo de contenido que necesitan. Pero hay dos elementos que aún deben ser agregados al análisis de los autores que comentamos hoy: la dimensión estética como cualidad de extrema importancia en la solución, por su incidencia en la usabilidad, y la relevancia de la comunicación.

En efecto, por si fuera poco todo lo anterior, un nuevo fenómeno se sumó en la segunda década de la WWW, la marcó definitivamente y volvió a transformar la complejidad: la interactividad extrema y permanente, el rol esencial de la participación. En efecto, como hemos señalado, la Web 2.0 es cualitativamente diferente de la primera Web y esa diferencia nace en el reconocimiento de que la comunicación que se genera alrededor de los contenidos es, al menos tan importante, como los contenidos mismos.

viernes, 2 de diciembre de 2011

AI: Confluencia de Ciencias y Tecnologías de la Información

En la Arquitectura de Información confluyen
distintas fuentes de conocimiento
La Arquitectura de Información (AI) es transdisciplinaria. En ella confluyen dos fuentes de conocimientos que, a pesar de complementarse, muchas veces transcurren paralelas sin integrarse: Las Ciencias de la Información (Bibliotecología, Archivología, Gestión documental, Gerencia de información, Comunicación social, etc.) y las Tecnologías de la Información (Tecnologías de Internet, Ingeniería de software, Bases de datos, Redes, Sistemas, Telecomunicaciones, etc.). Siguiendo una trayectoria marcada por nuestros últimos post, en este nos abocamos a comentar acerca de la necesaria integración de estas fuentes de conocimientos que tiene lugar en la AI, para beneficio de los servicios donde se aplica.

Los Arquitectos de Información, esas personas que como hemos visto, aportan en los servicios de información su capacidad de diseñar, organizar y estructurar la información para que la misma sen encontrable y apropiada para sus usuarios, provienen de uno cualquiera de los dos caminos mencionados: El de las Ciencias o el de las Tecnologías de la información. Pero estos arquitectos nunca pueden quedarse, en el ejercicio de su incipiente profesión, dentro de los márgenes que le impone su formación disciplinaria. Precisamente destacan cada vez que trascienden las fronteras de su conocimiento profesional original para lograr soluciones de información que trabajan gracias a la integración de múltiples perspectivas en el crisol de una aplicación concreta.

Adicionalmente, un Arquitecto de Información sabe que para tener éxito en sus proyectos tiene trabajar en cuatro áreas típicas: Tecnologías, Procesos, Gente y Contenidos. Sólo manejándose en estas cuatro áreas puede lograr sus objetivos cuando estos implican mejoras significativas en la gestión de información de instituciones, empresas o comunidades.

Digamos que las profesiones trabajan siempre con contextos, conocimientos y métodos específicos de un cierto dominio de conocimiento ligado a ellas. Pero hay denominadores comunes. En todas las profesiones manejamos información con procesos que son similares: catalogación, indexación, uso de tesauros, taxonomías, folksonomías, búsqueda, exploración, impresión, conversión de formatos... Aunque sea información particular, la manejamos, con procesos generales, patrones que reconocemos.

Ahora bien, los especialistas en Ciencias de la Información manejan con facilidades inherentes a su formación y práctica un lado de estos procesos. A veces muy específicos. Por ejemplo los comunicadores sociales tienen conocimientos que les permiten redactar muy bien los mensajes y otros elementos conceptuales que se usan para aseguran la comunicación con un cierto público. Bibliotecólogos y archivólogos entienden de categorías taxonómicas y tesauros y tienen distinciones de clasificación que ayudan a organizar conocimiento específicos desde una perspectiva general. Los diseñadores gráficos entienden del uso de colores, tipos de letras, diagramación y otros elementos para la comunicación visual de los mensajes, etc.

Por su parte, los especialistas en Tecnologías de la Información tienen, por su manejo tecnológico, competencias especiales para trabajar con otro lado de estos mismos procesos. El lado que está ligado al hardware y software de computación, las bases de datos, los aspectos técnicos de los archivos que se usan para cada formato, etc.

Los Arquitectos de Información, independientemente de su formación inicial, en Ciencias o en Tecnologías, deben de tener las distinciones claves, n dimensionales, de todos los aspectos que tienen que ver con el resultado del procesamiento de información y el cumplimiento de los objetivos.

A la hora de diseñar una vivienda el maestro de obra sabe de los elementos que aseguran la ejecución de la construcción, el ingeniero calculista del cálculo de las estructuras involucradas, un carpintero puede ser consultado para aportar criterios vinculados con sus conocimientos de las maderas, pero el Arquitecto diseñador de la casa tiene que integrar distinciones fundamentales para garantizar que la construcción sea funcionalmente adecuada y estéticamente agradable. En un servicio de información el Arquitecto de información tiene la tarea de integrar conocimientos para que el usuario final no especializado encuentre la información que busca y la pueda manejar sin problemas.

viernes, 25 de noviembre de 2011

El Arquitecto de Información y la Wikipedia

En la Wikipedia hay definiciones de Arquitectura y
Arquitecto de Información que hay que analizar en su contexto
La semana pasada mencionamos las definiciones de Arquitecto de Información que hace alguien tan interesante y que tanto ha aportado en este y otros ámbitos como Richard Wurman. Continuando esta perspectiva de comprender lo que hacen los Arquitectos de Información, esas personas que logran diferencias cualitativas en los sitos Web exitosos del mundo contemporáneo, podemos analizar cómo se presenta en la Wikipedia lo que estos profesionales son y lo que ellos aportan. Es el análisis que hacemos hoy.

Buscar en la Wikipedia es casi una actividad obligada que hoy día debe realizar una persona común cuando quiere realizar la primera aproximación a un determinado tema. Es muy interesante esto porque ese lugar común que es la Wikipedia no existía hace algunos pocos años (Ver Las primeras estrellas de la Web 2.0)

La Wikipedia es en si misma un producto que habla de lo que la AI puede lograr, pero entender lo que la Wikipedia encierra como meta conocimiento de AI es un poco más complicado, sobre todo para los que aún están iniciándose en esta materia. Por esta razón podemos intentar un abordaje mucho más simple: lo que se dice directamente en ella acerca de lo que es un Arquitecto de Información. Al hacer esta búsqueda encontramos lo siguiente:

“Es la persona encargada de llevar a cabo y verificar el proceso de desarrollo del sitio trabajando estrechamente con los expertos en usabilidad para definir la interfaz de usuario.


“Está integrado en un equipo y se ocupa desde la fundamentación del proyecto hasta el rediseño del producto, verificando y testeando todas las fases hasta la obtención del resultado final”

Estas definiciones complementan las de Richard Wurman (Ver) que manejamos la semana pasada y las de Louis Rosenfeld (Ver) de unas semanas atrás y comentaremos en este análisis tres aspectos esenciales.

El primero es la vinculación con un término cada vez más usado, aunque aún no completamente aceptado en español: la usabilidad. Los Arquitectos de información se ocupan, entre otras cosas, que los sitios Web donde trabajan sean útiles y para ello deben asegurarse que el usuario final, la persona a la que, en última instancia, el servicio está destinado, sepa siempre qué hacer. Cómo buscar. Cómo explorar. Cómo manejar la información recuperada. A esto se refiere la usabilidad.

Otro aspecto interesante es la integración en equipo que normalmente requiere la AI. Son tantas las perspectivas necesarias para que un servicio trabaje eficazmente que normalmente se necesitan varias personas que desde sus diferentes puntos de vista estén compenetradas con la aplicación. El aporte de esta variada capacidad de análisis y de generación de ideas y soluciones suele ser clave en el logro de un resultado exitoso. Los sitios que no son enriquecidos con la mirada crítica de múltiples personas (¡con perspectivas diferentes!) tienen más probabilidades de ser deficientes en su concepción e implementación.

El tercer aspecto interesante para mencionar en este contexto es el concepto de ciclo de vida del servicio de información. Las personas que han usado Amazon.com desde hace unos años, por ejemplo, han podido apreciar como, incluso un servicio que se diseña bien desde el inicio, requiere evolución. No hay un producto de información que nazca en forma completamente acabada. Desde que se hace la fundamentación inicial comienza un proceso de rediseño permanente de la solución y de allí que, en ese proceso recurrente, los Arquitectos (de información) son personas claves. La idea de cómo se hace es más cercana a los principios de la Web 2.0 que explicamos en días atrás (Ver) que a las palabras “resultado final” que se mencionan en la definición de Arquitecto de Información de la Wikipedia y que hay que entenderlas en su contexto e intención más que en forma literal.

sábado, 12 de noviembre de 2011

Richard Wurman y El Arquitecto de Información

Richard Wurman, (Philadelphia, 1935)
Arquitecto y Diseñador gráfico,
autor de decenas de libros de variados temas.
creador de las conferencias TED.
Se le atribuye el término “Arquitecto de Información”
En las últimas semanas hemos abordado el tema de la Arquitectura de Información (AI) y en particular de su definición, su práctica y sus logros. Es indudable que los especialistas de información a quienes nos les dirigimos principalmente en este blog le interesa estar actualizado en este tema de gran actualidad. Hoy queremos sumar otra perspectiva, la de la persona que hace AI, el Arquitecto de Información. ¿Qué es un Arquitecto de Información? ¿Qué define su vocación? ¿Cómo es y qué busca con su trabajo? Estos son los temas a conversar. Para ello es obligado comentar sobre Richard Wurman, a quien se le atribuye el término.

Richard Wurman es un personaje muy interesante. Nació en Philadelphia en 1935. Es Arquitecto, Diseñador gráfico y autor de más de 80 libros de muy variados temas. Entre sus méritos está el ser creador de las conferencias TED, un espacio que ha venido marcando una huella de gran interés para la humanidad.

A Richard Wurman la literatura le atribuye el término “Arquitecto de Información” por lo que es interesante tener contacto con sus palabras en éste área:

Un Arquitecto de Información es “la persona que organiza los patrones inherentes a la Información, haciendo entendible lo complejo

Una persona que crea un mapa de información que permite a otros encontrar su vía personal hacia el conocimiento

En general, para Wurman, la Arquitectura de Información (AI) es vista como una mezcla de Ciencias de la información, Tecnología, Diseño gráfico y Periodismo. Esto es muy interesante porque su formulación expresa el carácter transdisciplinario del conocimiento que se maneja en AI. Ninguna perspectiva disciplinaria sola es suficiente. Independientemente de la formación inicial a través de la que una persona ha llegado a la AI, es claro que su capacidad para crear servicios donde la información sea un bien útil (ver), depende de una integración sustantiva de conocimientos que tiene distintos orígenes.

Cuando analizamos a profundidad el conocimiento que un sitio Web exitoso encierra, no el que alberga como contenido, sino el “saber” que lo diferencia de otros que a lo mejor tienen el mismo contenido pero no el mismo éxito, podemos comenzar a comprender lo que es la AI y el rol de los Arquitectos de Información para lograr que esos contenidos sean útiles, encontrables, contextualizados, pertinentes y prácticos para sus usuarios (Ver Usuarios+Contenidos+Contexto).

El mérito que tienen los Arquitectos de Información cuando hacen su trabajo es claro, bien sea que trabajen en un servicio universal sin fines de lucro como la Wikipedia, una hipertienda en Internet como Amazon, un sitio Web de tutoriales en línea como w3schools, una herramienta que innovó en la Web como Blogger, una red social como Facebook, el sitio Web de una universidad grande, el de una pequeña o el lugar en el ciberespacio de una empresa muy especializada. Un sitio Web construido con una buena AI es como una edificación bien diseñada arquitectónicamente: ¡funciona!

En ninguno de los casos citados en el párrafo precedente el éxito se logra sin personas que ejecuten el rol de Arquitectos de Información, que tienen, como decía Richard Wurman desde hace ya varios años, la virtud de hacer simple y entendible lo que inicialmente parecía complejo y difícil de manejar con las distinciones adecuadas. Para el que se inicia en AI y quiere convertirse en un Arquitecto de Información, es muy interesante preguntarse y analizar cuál es la Arquitectura (de Información) que subyace en cada una de los lugares que destacan en Internet y luego volver a su sitio de trabajo y preguntarse: ¿cómo puedo yo incorporar aquí ese meta conocimiento?.

domingo, 6 de noviembre de 2011

Una definición simple de Arquitectura de Información

La Arquitectura de Información no es actualmente una disciplina,
pero si un conocimiento útil que se desarrolla y aplica sistemáticamente
Recorriendo la Internet vamos a encontrar muchas definiciones de Arquitectura de Información y una conversación amplia sobre el tema. Esto es natural porque la Arquitectura de Información (AI) no es una profesión estabilizada sino un área transdisciplinaria donde el conocimiento está en desarrollo. En la AI se producen con frecuencia aportes dentro de un espacio de conocimientos que muchas veces nacen aplicados y donde la conversación entre los practicantes y el esfuerzo de conceptualización es, por ello, de vital importancia. Dentro de ese contexto, es natural que muchos de los que se acercan a la AI (bien sea que provengan de Ciencias de la Información, de Informática o de la práctica de la Comunicación Social) se confundan tanto por lo parecido y coincidente como por lo diferente y divergente de muchas definiciones. De allí la motivación de nuestra parte para este post realizado con la intención de contribuir con una definición de AI que puede ser útil por lo simple y práctica.

Podemos decir:

La Arquitectura de Información es el conocimiento que nos permite transformar la información en un bien útil.

O alternativamente, quizá más simple aún:

La Arquitectura de Información es el conocimiento que nos permite facilitar el uso de la información.

Esta definición nos quita todo lo particular, lo anecdótico, lo circunstancial, para quedarnos con la esencia de lo que logra el conocimiento de la AI: hacer que la gente pueda usar la información.

Al señalar que es un conocimiento, se destaca que la práctica de la AI puede hacerse en forma sistemática, que el buen resultado no se logra por casualidad. Expresamente no se menciona como una disciplina, porque, al menos por ahora, no lo es. La AI se mueve, antes bien, en un espacio transdisciplinario, aplicado, donde ninguna disciplina aporta una perspectiva definitoria.

Ahora bien, las connotaciones ligadas a una definición siempre son importantes. ¿Qué se necesita para facilitar el uso de la información?

En primer lugar, como hemos ya señalado, que la información sea encontrable. Este es el primer beneficio que logra la AI. Pero además de poder facilitar el que la información se encuentre, es importante que podamos trasmitir el contexto (ver el post Usuarios + Contenido + Contexto). Esto es crucial. Muchas veces se le presenta al usuario información pero en forma descontextualizada.

Otro elemento pertinente es que la información se pueda guardar con una estructura tal que pueda ser recuperada y presentada en el formato adecuado a la necesidad. Como vimos cuando estuvimos hablando de formatos, cada formato expresa un aprendizaje y es útil para algo en específico (ver Aprendizajes y Formatos). Por eso la información debe almacenarse de manera tal que pueda recuperarse en distintos formatos (¿Por qué tantos formatos?).

Finalmente un aspecto esencial es que la información pueda ser fácilmente navegable. Esto implica que con la presentación de cada contenido el próximo requerimiento de consulta o de exploración debe estar accesible, al alcance de la vista o fácilmente encontrable, de forma intuitiva para cada tipo de usuario para el que el servicio está dirigido.

La encontabilidad, el contexto, la estructura u organización, la presentación y la navegabilidad son el tipo de puntos esenciales de los que, para hacer la información útil, se ocupan los Arquitectos de Información. Precisamente sobre éstos arquitectos hablaremos la semana próxima, cuando saltemos de la AI como profesión para centrarnos en los  practicantes de la misma.

viernes, 4 de noviembre de 2011

Usuarios + Contenidos + Contexto

Una manera de pensar la Arquitectura de Información (AI)  es la propuesta
por Luis Rosenfeld en su sitio web http://louisrosenfeld.com

Hace dos semanas comenzamos abordar los problemas ligados a la definición de la Arquitectura de Información (AI), como un espacio transdisciplinario moderno, cuya necesidad se ha mostrado cada vez más clara a medida que ha ganado experiencia en el desarrollo de servicios de información Web. Como es natural en un área de conocimiento en desarrollo, aun no existe para la AI un cuerpo de conocimiento aceptado en forma general, por lo que se hacen muy pertinentes las conversaciones acerca de lo que ella debe ser y el cómo entenderla. Precisamente la semana pasada mencionamos el Libro del Oso Polar (“Architecture of Information for the World Wide Web”) de Louis Rosenfeld y Peter Morville, como una referencia importante a la hora de definir la AI. Hoy queremos hacer este comentario a partir una de las propuestas de Louis Rosenfeld en la que invita a entender la AI como la suma de Usuarios más Contenidos más Contexto.

Recordemos que en la base de la AI está la intención expresa de hacer que los contenidos sean encontrables y útiles, como lo mencionamos en nuestra conversación anterior. Para ello es claro que las tres dimensiones propuestas por Rosenfeld, la de los Usuarios, la de los Contenidos y la del Contexto tienen que funcionar sincronizadamente. En cada una de estas dimensiones hay dos aspectos a tratar: la de las características relevantes en ese dominio y la de las destrezas y roles que se requieren en el practicante de la AI.

Usuarios
Para que un servicio funcione adecuadamente es importante que sus usuarios estén bien definidos. Los diseñadores del servicio deben conocer cuáles son sus necesidades y comportamientos con respecto a la información, qué tipo de información buscan normalmente y qué tipo de información buscan eventualmente. Pero además es conveniente saber cuáles son sus comportamientos durante la búsqueda de información, cómo buscan, qué hacen cuando encuentran y qué hacen cuando no. Mientras mejor sea el conocimiento que se tiene de los usuarios mejor será el resultado del servicio diseñado sobre esta base. Cuando no se trabaja bien este tema los servicios tienden a ser una amasijo de contenidos sin estructura evidente y efectiva.

Contenidos
En relación a los contenidos, cuando se va a diseñar un servicio Web es conveniente preguntarse: ¿Cómo son y cuántos son los contenidos de información que se manejarán?. ¿Con qué formatos deben manejarse estos contenidos al momento de guardarlos, recuperarlos y presentarlos (no necesariamente es el mismo en cada caso)?. ¿Cuáles son los metadatos más apropiados para caracterizar cada tipo de contenido? ¿Cuáles son las estructuras de información más adecuadas? ¿Cómo está organizada la información que se manejará? La respuesta a estas preguntas son claves para obtener un servicio de información de calidad. Cuando no se obtienen respuestas acertadas ocurre que aunque los contenidos estén,  la gente finalmente no los encuentra o no los usa simplemente porque no halla como.

Contexto
Normalmente, conocer usuarios y contenidos no es suficiente para un buen diseño. Es importante adicionalmente caracterizar el contexto con el que se trabaja. El modelo de negocios, los aspectos culturales, políticos y organizacionales del servicio que se presta. Los recursos con los que se cuenta. Las restricciones, de todo tipo, que haya sobre ellos, etc.

Lo interesante de la AI es que, como señala Rosenfeld y las personas que trabajan en las aplicaciones, normalmente nadie está completamente preparado para contestar todas las preguntas anteriores y la AI se resuelve mejor en un equipo en el que concurran distintos tipos de conocimientos, competencias y perspectivas que, adecuadamente trabajadas, permiten hacer la integración de las tres dimensiones mencionadas (Usuarios, contenidos y contexto) en una solución o servicio de información.

viernes, 28 de octubre de 2011

El Libro del Oso Polar: Un clásico de la Arquitectura de Información

La semana pasada comenzamos en este blog a hacer un abordaje sobre el concepto de Arquitectura de Información (AI). Pero es muy difícil comentar con cierta profundidad sobre este importante tema sin hacer alusión al “Libro del Oso Polar”, que no tiene nada que ver con ningún oso, ni con la ecología del ártico y que en realidad se llama “Information Architecture for the World Wide Web”, pero como cayó en una colección de O’Reilly que coloca un animal en peligro de extinción en cada portada y a éste le tocó un oso polar muy llamativo y característico, el libro comenzó a ser llamado y reconocido en la calle, cariñosamente, como “El Libro del Oso Polar”. Este fue el primer título que se nos ocurrió para este post, pero por el temor de confundir a los que no conocieran la historia, le agregamos el subtítulo: “Un clásico de la Arquitectura de Información” a este comentario que parte desde él.

Los autores son Louis Rosenfeld y Peter Morville, que lo publicaron en el año 1.998. Ambos autores son bibliotecólogos brillantes. Estos dos aspectos, su inteligencia analítica y su formación bibliotecológica, se siente en toda su particular aproximación al tema de la AI. El Libro del Oso Polar, por su parte tuvo la virtud de darle un contexto a la AI en un momento clave de su desarrollo como transdisciplina y de la World Wide Web como fenómeno mundial.

Para los autores, la AI puede definirse como “la combinación de organización, etiquetado y esquemas de navegación en un sistema de información” o bien como “el diseño estructural de un espacio de información para facilitar la completitud de la tarea y el acceso al contenido”.

La definición que comentamos la semana pasada (ver) coincide en muchos aspectos con la de este libro en el que sus autores señalan que la AI es: “El arte y la ciencia de estructurar y clasificar sitios web e intranets para ayudar a la gente a encontrar y manejar información”. En cuanto a su carácter y actualidad Rosenfeld y Morville señalan que la AI es “una disciplina emergente y una comunidad de prácticas enfocada en traer los principios del diseño y la arquitectura al terreno digital”.

Podemos ver que la noción de AI de Rosenfeld y Morville es muy coincidente con la idea de que en la AI es un tema de actualidad, donde es claro que las aplicaciones que se han estado construyendo luego de la WWW han puesto en evidencia que la existencia de ingentes recursos de información y de poderosos sistemas de procesamiento exigen una reflexión cualitativa acerca de qué es lo que hace que la información sea encontrable (porque no siempre lo es) y qué se requiere para que una vez que se encuentra sea posible manejarla adecuadamente como un bien útil (porque no siempre esto resulta sencillo de realizar).

La experiencia muestra que no es suficiente el acceso a la información. La Internet ha popularizado (como ya señalaba en su momento el Libro del Oso Polar, hoy un clásico en AI) el acceso de innumerables recursos de información donde hay información acerca de casi cualquier tema, pero cómo se logra que el usuario necesitado, que sabe además que lo que busca existe, pueda llegar, es el conocimiento esencial para construir servicios de información que sean realmente útiles.

Indudablemente que hay un tema de organización y estructura de información, pero no desde el punto de vista del dato, que es la clásica aproximación de los computistas e informáticos, sino de la capa superior donde yacen los objetos de información que manipulamos en el contexto de cada aplicación.

En la aproximación tradicional los profesionales del software nos ayudaban a pasar del dato a las aplicaciones, pero lo que se ha mostrado en la era Web es que en el medio del dominio del dato y del dominio de las aplicaciones hay un universo de reglas de información que subyacen debajo de las aplicaciones pero arriba de los datos. Precisamente la AI ayuda a entender lo que pertenece a esta capa intermedia, el dominio de la información, una abstracción necesaria que mantiene bastante independencia de la tecnología y que trataremos de ir desenredando y exponiendo en nuestros próximos posts.

viernes, 21 de octubre de 2011

Arquitectura de Información

Página inicial del Instituto de Arquitectura de Información,
www.iainstitute.org 

Uno de los conceptos más interesantes sobre los que continuamente volvemos, sobre el que tenemos que responder preguntas y sobre el que somos invitados a exponer en seminarios, talleres, congresos y múltiples formas de conversaciones, es el de Arquitectura de Información (AI). De alguna forma todos los asuntos que se han venido entrecruzando en este blog son temas de Arquitectura de Información. Pero ¿qué es la Arquitectura de Información? ¿Cómo podemos definirla? Dedicaremos este post al tema comentando la definición de Instituto de Arquitectura de Información y más adelante, seguramente, otros, aportando puntos de vista y conceptos complementarios.

Para el Instituto de Arquitectura de Información, una entidad internacional que se dedica a su estudio (www.iainstitute.org), la AI consiste en “el arte y la ciencia de organizar y rotular sitios web, intranets, comunidades en línea y software para promover la usabilidad y la encontrabilidad”. Allí se señala que “a medida que la información prolifera exponencialmente, la usabilidad se convierte en un factor crítico de éxito para sitios webs y aplicaciones de software”.

Esta definición es muy interesante porque señala el cruce metodológico de arte y ciencia en que se desenvuelve la Arquitectura de Información. Se toca el tema de sus fines: la usabilidad y la encontrabilidad de la información. Lamentablemente estas son dos palabras complicadas, particularmente en español, por lo que estamos obligados a comentarlas ya que, sin duda, corresponden a dos puntos importantes:

El primero tiene que ver con el hecho de que la información puede ser muy útil, pero no siempre lo es. No siempre está en un formato, que en términos prácticos, nos permite usarla para lo que la necesitamos. No se trata aquí de si es incompleta o no, correcta o no. Estas son otras propiedades. Se trata de que aún siendo correcta y completa la información puede ser más o menos útil por la forma en que se encuentra disponible. Observamos en nuestra experiencia que un contenedor de información puede caracterizarse porque proporciona la información con mucha o poca “usabilidad”.

El segundo concepto aludido arriba tiene que ver con el hecho de que la información no siempre se encuentra. Incluso muchas veces está, pasamos sobre ella, al lado de ella, debajo de ella, pero no la localizamos, no la vemos, no la tropezamos claramente. Sin duda, en esta era de la industrialización de la información, de la sociedad de la información, paradójicamente, una de las propiedades de ésta que no siempre se logra desarrollar es la capacidad de ser es “encontrable”.

La definición de AI que comentamos hoy alude también a otro aspecto que merece la pena observar y es que ésta (la AI) tiene que ver con estructura (organización) de la información y con la manera como la identificamos (rotulación). En efecto, para que la información sea usable y encontrable es crucial el cómo la diseñamos y cómo la clasificamos y de allí cómo la mencionamos para fines internos o externos, de comunicación con otros.
Finalmente, la definición del IAInstitute menciona conceptos vinculados con la tecnología, la Web, la intranet, las comunidades en línea, el software. Es claro que el especialista en AI tiene que lidiar con estos conceptos, aunque no por ello tenga que se un especialista en ninguno de ellos o en la tecnología.

La AI es un tema moderno, caliente, sobre el que se produce mucho actualmente. Sin duda, necesitaremos volver varias veces sobre él, ya que es un tema crucial para nuestros lectores, muchos de ellos especialistas en información con una cierta vocación o de atracción por la Arquitectura de información.

viernes, 14 de octubre de 2011

Más sobre el PDF: tipo de formato, contenido y futuro

¿Hasta dónde es bueno usar el formato PDF?
¿Hasta donde será bueno? ¿Qué depara el furturo al PDF?
Son algunas preguntas que muchos se hacen
Hemos estado conversando acerca de los distintos formatos presentes en la Web y en las últimas dos semanas, en post llamados “Errores frecuentes en el uso del PDF” y “Lo bueno lo bonito y lo feo del formato PDF”, presentamos los aportes de este formato, como un mecanismo para mostrar lo que se va a imprimir y sus limitaciones cuando se abusa de él y se lo usa como una solución de navegación y de presentación de contenidos en un sitio Web. Por el interés que despertaron estos últimos post escribimos este tercer post sobre el PDF, ampliando la información acerca del formato y respondiendo a algunas de las preguntas que nos han hecho nuestros lectores, como por ejemplo, si se trata de un estándar abierto y recomendable o algo que cierra y restringe a favor de Adobe Systems, la compañía que lo creó. ¿Qué es lo que contiene un archivo formato PDF? y, finalmente, una reflexión acerca del futuro del PDF.

¿Estándar abierto o formato propietario?
El PDF es un formato estándar. Como formato de archivo fue creado en 1993 por Adobe System y en efecto, muchas gente se hace preguntas acerca de su uso como estándar, porque fue un formato propietario. Su origen está en un sistema llamado “Camelot” creado por John Warnock, uno de los fundadores de Adobe.

Desde el 2001 la especificación fue disponible en forma gratuita. Esto no significaba que el formato fuese exactamente un estándar abierto, ya que, en ese momento, el control del formato seguía siendo de Adobe. A partir del 2008 la historia es diferente porque, con la autorización de Adobe, la International Organization for Standardization (ISO) lo publicó con el código ISO 32000-1:2008. Los derechos de uso son ahora libres de regalías para todas las patentes relacionadas con el PDF que poseía Adobe System. Esto quiere decir que cualquier persona y organización puede usar, hacer, vender o distribuir sistemas, herramientas, soluciones o contenidos implementados con este formato.

¿Qué contiene un archivo PDF?
Cada archivo PDF es una descripción bastante precisa de la representación de un documento con una diagramación fija. La especificación abarca la definición del texto, la tipografía (fonts), imágenes o fotografías, resolución gráfica y todos los elementos que en principio deben estar definidos para especificar, sin ambigüedades, cómo el documento debe verse. Puede notarse que por eso es muy diferente la representación HTML (que tiene mucha más flexibilidad y ambigüedad) a la representación PDF de un documento.

Esta descripción precisa de la diagramación y otros elementos de la presentación es lo que hace al PDF apropiado para definir la impresión de un contenido e inapropiado como mecanismo de consulta rápida y presentación universal de ese mismo contenido en cualquier medio (Ver nuestro post “Lo bueno, lo bonito y lo feo del formato PDF”).

La especificación del PDF incluye la representación en lenguaje PostScript del diseño del documento, el encapsulado de los fonts que se requieren para presentarlo y una organización de lo requerido para que todos los componentes estén contenidos en un único archivo.

El futuro del PDF
Muchas veces nos preguntan acerca del futuro del PDF y de los documentos grabados en este formato, que cada vez son más. Afortunadamente el formato está lo bastante bien definido y bien difundido como para esperar que en el futuro va a seguir siendo posible ver los documentos grabados hoy en formato PDF.

Sin embargo, con el tiempo, es probable que el PDF deje de usarse como mecanismo de preservación de documentos imprimibles y que su uso de paso a otros esquemas que aprovechen la separación y articulación de contenidos que facilita el XML para hacer gráficas manipulables, vistas dinámicas, anotaciones enlazadas y marcas semánticas. La transición a este futuro ha sido y seguirá siendo un poco lenta debido a que, como señala Ginsparg en un artículo que citamos hace unas semanas (ver), existe la necesidad comprensible de mantener estables archivos previos, como lo hizo el papel por centenares de años.

viernes, 7 de octubre de 2011

Errores frecuentes en el uso del PDF

Un error, lamentablemente frecuente en la Web, es obligar al usuario a
navegar a través de contenidos en PDF presentados con una fachada HTML 

La semana pasada, en nuestro post “Lo bueno, lo malo y lo feo del formato PDF” estuvimos comentando de los aciertos del uso del formato PDF para representar documentos que se van a imprimir. También comentamos lo desatinado que resulta usar el PDF, consciente o inconscientemente, como un sustituto del HTML, un lenguaje más adecuado para la representación de contenidos navegables en diversos tipos de dispositivos. Algunas personas nos pidieron ampliar un poco esta explicación, particularmente ilustrando los errores frecuentes. Esto es definitivamente importante para Gerentes de información y responsables de revistas electrónicas, un tipo de aplicación donde normalmente el PDF siempre se requiere pero donde, desafortunadamente, se cometen, en muchas implementaciones, errores de Arquitectura de información.

Pecados, pero no pecadores
Atendiendo las solicitudes recibidas explicaremos una vez más el pecado (uso inapropiado del PDF que en algunos sitios Web se hace), pero sin hacer alusión innecesaria a los pecadores. Esto es, procuraremos definir mejor los errores, con más detalles, como para que un Gerente de Información o un responsable de un servicio Web pueda identificarlos, pero sin dar una dirección específica ya que por un lado es innecesario y por otro puede resultar inconveniente ya que si los responsables del servicio cambian para bien su implementación ocasionarían que, por la dinámica de la Web, lo que era inicialmente un ejemplo terminara siendo un contra ejemplo.

Un error muy frecuente en revistas electrónicas
Una arquitectura muy difundida pero muy incómoda para los usuarios son las revistas cuya existencia en la Web toma la forma de un conjunto de artículos en formato PDF presentados con una fachada de menú HTML. Este es un esquema inapropiado, francamente incómodo para la búsqueda, la consulta rápida, la navegación, la presentación en muchos dispositivos. El caso es un ejemplo de contenidos publicados sin conocimientos de Arquitectura de Información.

En una revista electrónica, sobre todo si el origen de la misma es una revista que anteriormente se publicaba sólo en papel, el uso del PDF es casi una obligación. Los usuarios muchas veces esperan imprimir adecuadamente los diversos artículos. Sin embargo, eso no significa que los artículos sólo se publiquen como PDF. Para un lector que quiere leer algo rápidamente, por ejemplo, porque quiere explorar todo el contenido de la revista para escoger cuáles artículos leer o el orden de la lectura, es inconveniente una arquitectura donde hojear la revista implica bajarse un contenido PDF, revisarlo, volver al menú o la tabla de contenido y descargar el siguiente artículo, también en PDF, y así sucesivamente. El mecanismo obliga al lector a usar la Web en forma excesivamente artesanal.

El caso de sitios institucionales de pequeñas organizaciones
Un caso todavía más grave es cuando no se trata de una revista sino de un sitio Web institucional y la organización que se presenta a los usuarios es la de un a conjunto de archivos PDF accesibles a través de una fachada HTML. Ocurre todavía en el ámbito académico con muchas memorias de congresos y en general con los sitios Web de muchas pequeñas organizaciones. Estos sitios deben ser, cuanto antes mejor, rápidamente transformados para beneficio de sus usuarios.

La recomendación
Una vez más nuestra recomendación es la misma que expresamos la semana pasada: No estamos contra el uso del PDF, que indudablemente ha sido un aporte histórico, sino contra el mal uso del formato al sacarlo de su condiciones de utilidad y emplearlo, consciente o inconcientemente, como una alternativa al HTML.

viernes, 30 de septiembre de 2011

Lo bueno, lo malo y lo feo del formato PDF


El formato PDF puede es muy bueno cuando se usa
en forma apropiada, pero es muy malo cuando se
usa inadecuadamente...
La impresión de documentos pareció resolverse desde hace algunos años con la propuesta de Adobe, basada en el lenguaje Postcript y concretada en el formato PDF. Hoy en día se dispone de muchas herramientas tanto para generar como para visualizar archivos creados con este formato y las salidas impresas lucen, por lo general, muy bien. El problema que tenemos es que muchos implementadores de sitios Web no han entendido en qué momento es bueno el HTML y en qué momento es bueno el PDF y esto genera usos incorrectos de ambos formatos. Entre estos errores, el más grave es el uso del PDF como mecanismo de exposición de contenidos en la Web. De allí que continuaremos la conversación sobre formatos que hemos estado manteniendo en las últimas semanas con los Gerentes de Información que nos siguen, dedicando este post a explicar por qué no es aconsejable usar siempre el PDF, con la esperanza de que este conocimiento ayude a mejorar el diseño y la navegación de algunos de los sitios donde se hace un uso excesivo de este formato.

El formato PDF no siempre es lo mejor
El formato PDF, creado en 1993, fue diseñado para representar documentos y lograr que la gente los imprima con gran control, no sólo de los contenidos, sino también de la diagramación y la presentación general de la salida. En ningún momento ha sido ni es un sustituto del HTML como lenguaje universal de la navegación en hipertextos. Pero a pesar de que hay personas a la que esto puede sonar una obviedad, o casi, en muchos lugares de la Web hemos visto que la gente usa documentos PDF como mecanismo de publicación y, como consecuencia, numerosas páginas resultan complicadas de navegar en el computador, o en las nuevas tabletas digitales, debido esencialmente a que los contenidos fueron publicados en PDF.

Muchas veces el volcado de información al papel es innecesario para los nativos digitales, si bien para algunos inmigrantes digitales, a veces, es imprescindible. Pero el problema al que nos referimos es independiente de este. No queremos hablar de la necesidad o no de imprimir, de los temas ecológicos derivados, de la diferente aproximación de los nativos y los inmigrantes digitales a la lectura en los nuevos medios electrónicos. Esos otros temas son pertinentes, los hemos tocado y los seguiremos tocando en este blog, pero el tema central de hoy es en qué contexto es apropiado el uso formato PDF y, complementariamente, en qué contexto no lo es.

¿Cuándo es apropiado el PDF?
El PDF es un formato apto para representar documentos que van a ser impresos en papel, pero es importante entender que, a pesar de que hay esquemas para crear mecanismos de navegación con él, este formato resulta poco adecuado como un sustituto de la exploración y la navegación directa en la Web.

¿Qué significa esto? Que el PDF no es un formato para presentar contenidos, para eso está el HTML, que es más rápido y versátil para adecuarse a las diversas pantallas. Por tanto, cada vez que en un sitio Web usemos el PDF para presentar un contenido en pantalla para su primera lectura por el usuario, nos estamos equivocando. Todos los sitios Web que así lo hacen, lo están haciendo mal. En primer lugar porque el PDF requiere un visor que generalmente está, pero no siempre, disponible. En segundo lugar porque cuando el visor está, es más lento ver los contenidos de esta forma y la Web en general es un mecanismo rápido de búsqueda de información. Finalmente, a pesar de que es posible representar enlaces y menús con el formato PDF, este no tiene las facilidades de adecuación y de navegación de las páginas formateadas en HTML.

¿Cuál es la recomendación?
Al desarrollar un sitio Web lo apropiado, en términos prácticos, es usar una arquitectura en la que se presenta la información usando HTML y se coloca un enlace de impresión que construye o descarga el mismo contenido que se mostró inicialmente en su versión en HTML, pero esta vez con una diagramación explicita para la impresión, en formato PDF. En ese contexto, cuando se visualiza un documento PDF es porque la decisión de imprimir el contenido se ha tomado, el usuario puede esperar un poco más y la rigidez de la navegación PDF no es un problema. Así debe hacerse para una mayor usabilidad. Es la recomendación general.

viernes, 23 de septiembre de 2011

Separar Contenidos, Estilos y Metadatos

Mucha de las interacciones que hacemos hoy día son posibles gracias
a que por detrás hay una comunicación de metadatos con XML
Hace 15 días comenzamos a hablar de formatos e hicimos la pregunta: ¿Por qué tantos formatos? La semana pasada ampliamos nuestra respuesta a esta pregunta explicando como cada formato está siempre vinculado a un aprendizaje por lo que, como consecuencia, en la medida en que como humanidad vamos a seguir aprendiendo a lidiar con la información vamos también a seguir produciendo nuevos formatos. Es inevitable. Viene junto. Una de las afirmaciones en esta conversación es que hoy día, contenidos, estilos y metadatos se distinguen y se tratan de manejar separados. Por ello un documento HTML de los inicios de la Web es muy diferente internamente de uno de los que se produce en la actualidad. Si la semana pasada hablamos de contenidos y estilos, ahora volvemos a la conversación para hablar incluir en ella el punto de los metadatos.

Metadatos
La mejor forma de separar los metadatos es a través de XML. Un formato del cual hemos hablado con detalles en varias oportunidades (ver, por ejemplo, Evolución de metadatos y XML y El Matrimonio de MARC con XML). El XML garantiza, como no puede hacerlo el HTML, la comunicación de metadatos: los campos internos o distinciones que hacemos en un documento. Si con el HTML podemos trasmitir contenidos a las personas, con el XML logramos un formato que nos permite la comunicación y el intercambio de metadatos entre los sistemas. Esto fue bien claro en las explicaciones que hicimos en el caso de la iniciativa de archivos abiertos y el protocolo OAI-PMH (ver La inciiativa de archvios abiertos: el nacimiento de la sencillez al compartir metadatos).

El XML es el formato que facilita el intercambio de metadatos, por excelencia. De hecho, todas las áreas del saber y del hacer tienen metadatos específicos pero, en general, se converge al uso de XML como el formato o lenguaje base que debe usarse para trasmitir contenidos en los cuales es importante distinguir detalles, campos, clasificadores, partes internas, en una palabra: metadatos.

La combinación de formatos
A la hora de almacenar documentos se usan adecuadamente las bases de datos, cada una con su formato específico. A la hora de intercambiarlos el XML es adecuado. Al momento de presentarlos, el XML se traduce a HTML y los estilos se escriben en forma separada en una hoja de estilos .CSS. Así es la historia, cada vez que consultamos muchos sitios Web modernos. Por eso tenemos muchos formatos y vamos a seguir teniéndolos, cada uno para un uso específico.

Lo interesante es que el usuario de un sitio Web dinámico lo que observa de todo este cuento es que cada vez los sitios Web proporcionan mejor la información, en forma más agradable, más personalizada y más útil. Todo el tema de formatos le es invisible. Así debe ser cuando todo esta funcionando y bien implementado. Con el aprendizaje de hoy entendemos que mucho de las mejoras tienen que ver con funcionalidades que se implementan gracias a la comunicación XML, un formato que permite distinguir detalles internos en un contenido.

El caso de la impresión
La impresión en papel de un contenido electrónico puede ser vista como un modo de presentación diferente, en otro tipo de soporte físico además. Para ello se ha venido usando el formato PDF, sin embargo, como veremos en nuestro próximo post hay uso y abusos del formato PDF. Como veremos, en contextos apropiados este formato puede ser muy bueno, pero como veremos también, usado inadecuadamente, en contextos inapropiados donde deberían usarse otras soluciones, el formato PDF puede ser muy malo.

viernes, 16 de septiembre de 2011

Aprendizajes y formatos

El sitio http://www.csszengarden.com ilustra el aprendizaje que hicimos
al inventar los estilos en la Web. Pueden verse varios ejemplos
que ilustran como hoy día se separan contenidos y estilos

Entre los profesionales de la información a veces produce desconcierto la gran cantidad de formatos con los que hay que lidiar. Pero efectivamente, como expusimos en nuestro post de la semana pasada, los aprendizajes que como humanidad tenemos en el camino se concretan en los nuevos formatos digitales que van apareciendo y desarrollándose. Cada uno nos sintetiza una lección. De modo que una de las respuestas a la pregunta que hacíamos la semana pasada: "¿Por qué tantos formatos?" es que cada formato encierra un aprendizaje. Veamos hoy como hicimos el aprendizaje de sumar estilos a nuestros textos e hipertextos digitales.

Separar contenidos de estilos
Una lección particularmente importante la obtuvimos cuando la WWW comenzó a crecer:  en todo lo posible, es conveniente separar los estilos de presentación de los contenidos textuales. Esto se logró en los documentos HTML con la introducción del concepto mismo de “estilo” o forma presentación de un contenido y la práctica recomendada de usar las llamadas “hojas de estilo”. Estas hojas no eran otra cosa que archivos (.CSS) con un formato que especificaba cómo debían, estéticamente, aparecer en la pantalla los diversos componentes de una página Web: los párrafos, títulos, tablas, etc., es decir, los “estilos” que debían usarse en la presentación de las salidas.

La mayoría de los documentos HTML que se producen hoy en día distinguen internamente contenidos, estilos y metadatos, si bien para el lector final estas distinciones internas pueden no ser visibles en un momento dado porque él, simplemente, ve un texto con una tipografía y una diagramación específica.

Un primer paso fue reconocer que la Web necesitába incorporar el concepto de estilo y un siguiente paso fue darse cuenta que estilos y contenidos debíamos manejarlos por separado. En efecto, después del primer paso teníamos contenidos y estilos mezclados, eran más difíciles los cambios de contenido y eran más difíciles los cambos de estilo. No siempre la persona que cambia uno es la misma que cambia el otro y es más complicado encontrar lo que se quiere cambiar si está todo en un mismo formato. El uso de estilos que hacemos hoy día en la Web permite cambiar con bastante sencillez el concepto estético con el que se presenta los textos, logrando apariencias muy diferentes sin afectar los contenidos de los documentos presentados. Suena evidente la necesidad, sin embargo, el aprendizaje fue paulatino: Cuando comenzamos con la Web, no usábamos estilos y luego textos y estilos estaban todos mezclados en los documentos HTML. Veamos la historia.

La historia de cómo aprendimos a trabajar con estilos
Al principio, cuando no habíamos inventado el concepto de estilo y de archivos .CSS los hipertextos los escribíamos en documentos HTML donde no se explicaba cómo “formatearlos”: colores, tipos de letras, alineación, etc. eran simplemente aspectos que no podían definirse y por eso la primera Web era un poco plana visualmente, algo que muchos no recuerdan (20 años no es un día) y que los nuevos nativos digitales no vivieron.

En los primeros hipertextos sólo marcábamos donde comenzaba y donde terminaba cada párrafo y donde comenzaba y terminaba cada título o subtítulo. Esto alejaba las posibilidades de la Web de la riqueza de la presentación que se lograba en los medios impresos. Por ello, con la especificación versión 3.2 de HTML se introdujeron etiquetas para establecer tipos de letras y colores. Esto aumentó la riqueza visual pero también la complejidad del manejo. Colocar este tipo de información estética en cada documento era largo, complejo y sujeto a error.

Se había creado una posibilidad, se satisfacía mejor una necesidad, pero había que solucionar mejor el cómo hacerlo. Es decir, se requería un nuevo formato. Y este vino: El Consorcio de la WWW (http://www.w3c.org) creó posteriormente, con el HTML versión 4.0, las hojas de estilo .CSS que definen en forma condensada como deben presentarse estéticamente los elementos (párrafos, encabezados, imágenes, tablas) de un hipertexto HTML. La historia a partir de allí fue otra. La calidad estética de la Web mejoró y se comprobó, una vez más, que cada formato encierra un aprendizaje…

viernes, 9 de septiembre de 2011

¿Por qué tantos formatos?

Los nuevos medios digitales permiten nuevas interacciones
y nos traen nuevos formatos

Uno de los méritos del papel como mecanismo de soporte de contenidos de información es su relativamente fácil preservación. Los especialistas saben que hay varios temas relacionados: temperatura y humedad de los lugares donde se hace el resguardo, acidez de los mecanismos de impresión, insectos y otras plagas, por ejemplo. Pero más allá de los detalles, es indudable que la buena conservación por centenares de años de muchos impresos, documentos, libros y revistas, habla de la relativa facilidad de la preservación en papel y de los mecanismos para apreciarla y asegurarla. Este tema es más sofisticado y no está completamente resuelto en el mundo digital, por la evolución constante de los soportes y de los formatos y la invisibilidad de lo que se almacena hasta que no se presenta. Hemos conocido casos de universidades que creyeron poder preservar las versiones digitales de las tesis de sus estudiantes solicitándoles una copia que, con los años, simplemente dejó de poder ser leída. La WWW tiene una historia de cerca de veinte años y, en este breve espacio de tiempo ha habido y va a seguir habiendo evolución en los formatos. ¿Qué es lo que cabe esperar hacia adelante?

La diversidad de formatos digitales está vinculada con la diversidad de funcionalidades y modos de presentación
En el medio digital la variedad es más rica que en el medio impreso: un mismo contenido puede tener distintos modos de presentación, cada uno con sus ventajas. Algunas de estas presentaciones pueden tener funcionalidades específicas, por ejemplo notas de los usuarios. Esto no ocurría en la cultura del papel donde una vez impreso el libro formaba un todo prácticamente indivisible con el soporte físico, la funcionalidad y el formato de presentación unidos. Ahora, en cambio, tenemos en el mundo digital formatos adecuados para almacenar la información, formatos para presentarla en un medio, formatos para presentarla en otros, formatos para compartir mediante protocolos de intercambio, formatos para los nuevos dispositivos móviles e incluso, formatos para llevar la información digital al papel.

La World Wide Web evoluciona para mantenerse y aumentar su utilidad
El HTML como lenguaje para presentar hipertextos y el HTTP como protocolo de comunicación son las piedras angulares de la WWW y en gran medida, de la Internet de hoy, donde la mayoría de las interacciones ocurren a través de la Web, a diferencia de la Internet de antes del 2000 donde las interacciones ocurrían, sobre todo, en el correo electrónico.

En términos técnicos, internamente, la Web ha ido evolucionando con aportes coordinados por el consorcio institucional que la regula: el World Wide Web Consortium (http://www.w3.org). Del HTML llevamos ya cuatro ediciones y la quinta en curso, con aportes importantes (lo que implica diferencias) en cada una de ellas, si bien una de las ventajas de esa evolución es la llamada “compatibilidad hacia atrás”: el hecho de que las nuevas versiones de las herramientas de visualización nos permiten ver documentos hipertextos formados con las técnicas que disponíamos en los comienzos de los años noventa.

Uno de los méritos de las tecnologías alrededor del HTML usado en la Web es que los documentos grabados inicialmente con este lenguaje siguen, en general, pudiendo ser trasmitidos y presentados en los servidores y exploradores modernos que tenemos en la Internet de hoy. Pero esto no significa que los documentos HTML de la actualidad sean parecidos a los de 15 años atrás. Internamente han cambiado mucho. Interesantemente, los cambios entre los documentos de hoy y los de las pasadas décadas reflejan aprendizajes por lo que dedicaremos algunos de nuestros próximos post a exponer esta relación entre aprendizajes y formatos para entender cómo, en la medida en que vamos a seguir aprendiendo como comunidad internacional que produce y comparte información con las nuevas tecnologías, vamos a seguir, inevitablemente, produciendo nuevos formatos digitales para lidiar con la información en forma cada vez más útil, con una mezcla paradójica de felicidad, sencillez y complejidad.

jueves, 1 de septiembre de 2011

La ciencia y la generación digital

A las nuevas generaciones de académicos les corresponde hacer un
cambio que tendrá tracendencia: llevar de un modo más integral la cultura
digital a las prácticas científicas de manejo de información
Los actuales estudiantes universitarios son todos nativos digitales. Sólo por excepción no lo son. Hay diferencias, claro está, derivadas de las oportunidades que han tenido o que se han labrado gracias a los contextos culturales y las redes humanas en las que se han formado, pero a fin de cuentas es evidente su comportamiento social de nativos digitales. Los Profesores titulares de las Universidades y una cantidad importante de los bibliotecarios que administran sus bibliotecas todavía son, en promedio, inmigrantes digitales, formados con la cultura del papel y reciclados a la producción industrial de información y conocimiento del mundo en que vivimos. Un mundo en el que por cierto, las redes digitales no sólo habilitan la difusión de los contenidos sino que empoderan y crean nuevas formas de participación y de interacción, un fenómeno que se expresa en lo que hoy llamamos Web 2.0 para distinguirla de la primera Web, la Web hoy 1.0, mucho más unidireccional en la manera de crecer sus contenidos. ¿Qué pasa con los repositorios académicos en este contexto?
Ese es el tema de hoy.

La Ciencia aún tiene que cambiar sus prácticas
Recientemente hemos hecho un par de post, uno para prestar atención a un hito histórico: los 20 años de arXiv.org y otro para señalar como arXiv.org tenía en su concepto una semilla Web 2.0, si bien algunos de sus genes estaban limitados culturalmente, como expresamos al final del segundo post. Queremos esta vez insistir con algunas reflexiones adicionales inspiradas en la última parte del artículo de Paul Ginsparg, arXiv at 20, que comentamos parcialmente en estos últimos post. En resumen: La Ciencia ha creado las herramientas, pero las nuevas generaciones de académicos aún tienen que cambiar las prácticas de la institucionalidad científica, ya que ésta aún está signada por la cultura del papel.

La generación digital no ha llegado a la Ciencia
Como Ginsparg comenta, a pesar de que la vida actual hay numerosos servicios en línea, motores de búsqueda globales y que los estudiantes actuales están habituados a usar mecanismos de compartir fotos, videos y actualizaciones de estatus, todavía se usan (incluyendo a la generaciones de académicos jóvenes en la afirmación) las técnicas de reunir información científica de los científicos tradicionales. Los estudiantes todavía siguen árboles de citas, buscan por palabras claves, consultan con pares y mentores para eliminar las fuentes no confiables. Todo esto sucede aunque en otros aspectos de sus vidas estas personas se comporten diferentes, usando más ampliamente las nuevas posibilidades de descubrimiento, interacción y participación.

Los filtros en los repositorios científicos deben evolucionar
No cabe duda que en el presente las cantidades de contenidos que se producen son mucho mayores que nuestra capacidad de lectura y estudio y que por ello se hace claro que necesitamos ser selectivos. En otras palabras, disponer de buenos filtros conviene: Navegar cantidades crecientes de data inevitablemente lleva a problemas de sobrecarga de información. El problema señalado es que un filtro de información inadecuado puede ser peor que ningún filtro. Por ejemplo, sistemas de recomendación basados en medidas pasivas de popularidad pueden ampliar las opciones de lectura individual, pero al ampliar a cada quien en la misma dirección, restringen la diversidad en la comunidades donde están los individuos.

Menciona Ginsparg que en arXiv se han podido apreciar los efectos adversos de la ausencia de filtros adecuados en la ingestión de información por parte de las comunidades de investigación global, derivado de consumos de la misma información dado el hecho de que todos usan las mismas interfases sobre una base diaria. Muy concreto uno de sus ejemplos: El orden en el cual los nuevos preprint se suben y se presentan en las alertas diarias afecta las lecturas de éstos y, sorprendentemente, dejan una traza en las citas seis años más tarde. Es obvio que este resultado no armoniza con la pretensión de objetividad de la Ciencia.

Los filtros que enfatizan los materiales populares sobre períodos de tiempo largo exacerban este efecto. De allí que en los repositorios científicos se requieren filtros diferentes, personalizados a las preferencia e intereses individuales. Actualmente, comenta Ginsparg, se están haciendo experimentos con este tipo de sistemas y se espera que entren en producción en uno o dos años. Indudablemente alentador.

viernes, 26 de agosto de 2011

arXiv, Web 2.0 antes de la Web 2.0

La Universidad de Cornell hospeda actualmente el servicio de arXiv
(foto)

La semana pasada nos referimos a los 20 años de arXiv, un servicio pionero que revolucionó la manera de acreditar el valor de un aporte científico en muchas áreas del saber. Hoy queremos hacer algunas reflexiones adicionales sobre méritos que deben atribuírsele a arXiv, servicio que de alguna forma inventó la Web 2.0 antes de que esta se inventara, dado que la célebre lista, nacida en el Laboratorio Nacional de los Álamos y patrocinada luego por la Universidad de Cornell, se inició en 1991, en la época de la Web (que hoy llamamos 1.0) y muchos años antes que la Web 2.0.

Web 2.0
La Web 2.0 se gestó en la segunda mitad de los años 90 y se hizo consciente a partir de la conocida conferencia realizada en San Francisco en el 2004, que definió los cuatro principios básicos de las aplicaciones Web 2.0:

  • La Web es la plataforma.
  • La información y la comunicación es lo que mueve la Internet.
  • Los efectos más importantes de la red se crean por la participación de los usuarios.
    Los contenidos y el valor surgen de esta participación.
  • Los servicios están en un punto beta perpetuo. Nada está completamente terminado.

arXiv y la Web 2.0
Sobre arXiv.org hablamos la semana pasada (ver), como un servicio de publicación extraordinariamente exitoso que se convirtió en muy poco tiempo en un repositorio de centenares de miles de documentos de valor científico y que numerosas comunidades de investigadores de todo el mundo lo hicieron suyo subiendo contenidos y descargando a la tasa sin precedentes, en un sitio Web académico de esta neturaleza, de un millón de documentos semanales.

Cuando revisamos cómo y por qué creció arXiv, nos damos cuenta de que lo esencial estuvo desde el comienzo en la participación de los usuarios, en su reconocimiento temprano de que la Web era la plataforma (arXiv comenzó antes que la Web), pero por sobre todo, que creó el concepto adecuado para concretar la participación, el servicio interpretó la necesidad subyacente en numerosas comunides académicas. Estas comunidades lo reconocieron al punto de que con su aceptación como estándar de facto naciera natural la reevaluación de las reglas de la acreditación científica, como expresamos en nuestro post de la semana pasada.

Esto es interesante porque arXiv no se menciona normalmente entre los pioneros de las Web 2.0. Quizá porque se trata de un servicio que no está orientado al amplio público, sino a comunidades científicas. Pero la observación muestra que en varios de los pioneros de la Web, hoy 1.0, estaba la semilla de lo que después devendría en sitios en los que posteriormente reconoceríamos cualidades diferentes y que llamaríamos Web 2.0.

¿Qué atributos Web 2.0 aún le falta a arXiv?
En su artículo arXiv at 20 Paul Ginsparg escribe: “algunos usuarios han requerido que se soporte la realización de comentarios directos a los papers publicados en el sitio, mientras otros prefieren que se mantenga sin añadidos lo publicado por el autor. Yo simpatizo por más interactividad: en la Web social de hoy, un canal unidireccional parece un anacronismo”. Este comentario refleja que aún al medio académico y a un pionero tan avanzado como arXiv le falta madurar y que hay una discusión abierta que señala la distancia entre los repositorios académicos de hoy y las referencias icónicas de la Web 2.0 (ver).

Cuando ese anacronismo que comenta Ginsparg se cambie en arXiv.org, lo que cambiará será algo mucho mayor. Será la última estocada para el mecanismo de discusión privada como criterio para certificar el valor dentro de la Ciencia, algo cuyo sentido se seguirá diluyendo en la medida en que se siga industrializando la producción de conocimiento científico.

martes, 16 de agosto de 2011

La lista de los Álamos 20 años más tarde

http://arXiv.org es un hito histórico en la historia
de la Ciencia Moderna y un embriom de lo que hoy conocemos
en el ámbito de información como crowdsourcing
En el medio científico sería casi impensable que alguien no conociera la lista de los Álamos. Entre los profesionales de la información y entre los de informática es también frecuente que la gente tenga referencias, más cercanas o más lejanas según sus relaciones con la academia. La lista de los Álamos, hoy conocida como arXiv, es un hito histórico. Pero quizá muchos no se enteraron que muy recientemente, el 14 de agosto del presente, se cumplieron 20 años de un acontecimiento trascendente: La puesta en producción de este célebre servicio, con la llegada del primer correo a la lista. Un experimento de gestión de información que trasciende la gestión de la información, un archivo de prepublicaciones científicas que cambió el curso de los acontecimientos y abrió una nueva era para las ciencias. Podría interpretarse, sin lugar a dudas, como un hito en la construcción de una manera diferente de hacer Ciencia y de hacer gestión de información en la sociedad del conocimiento. La iniciativa histórica fue liderada por físicos, pero sus aportes e implicaciones van, claramente, mucho más allá de la Física.

Paul Ginsparg y arXiv
En otra ocasión hablamos de Paul Ginsparg y de sus compañeros, Richard Luce y Herbert Von de Sompel, como los impulsores de un cambio en la manera de compartir metadatos que dio origen a la Iniciativa de Archivos Abiertos (OAI, por sus siglas en Inglés). La intención de Ginsparg en el Laboratorio Nacional de Los Álamos en Nuevo México, hace 20 años, fue, precisamente, facilitar el intercambio de manuscritos o preprints, es decir, de documentos escritos por sus autores pero aún en proceso oficial de publicación. Incluso el alcance inicial era bien limitado al área de trabajo de Ginsparg: la Física de Altas Energías.

Ginsparg creó un repositorio para compartir este tipo de información aprovechando las tecnologías que recién comenzaban a desplegarse. Lo que ocurrió luego fue un éxito que trascendía todo lo que había hasta la fecha. En unos pocos años el servicio evolucionó para convertirse en un recurso Web (http://arXiv.org) con cerca de 700.000 documentos en texto completo, 75.000 nuevos cada año y sobre el que se realizan cada semana cerca de un millón de descargas en texto completo por unos 400.000 usuarios diferentes. Los contenidos trascendieron la física para incluir trabajos de matemáticas, computación estadísticas y biología (Puede verse muchos más detalles en el documento arXiv at 20, del propio Paul Ginsparg ). El servicio fue trasladado de Laboratorio de Los Álamos a la Univerisdad de Cornell y su crecimiento sigue llevando a sus autores a buscar salidas para su financiación.

Una revolución en la manera de certificar la Ciencia
Las lecciones aprendidas de arXiv son muchas, todas importantes y más aún, trascendentes, históricamente. Los profesionales de la información, para los cuales escribimos, están obligados a conocer la historia.

Toda la Ciencia ha descansado tradicionalmente sobre un mecanismo de calidad llamado evaluación de pares: cuando algún científico hace algún aporte a la Ciencia, en algún área del saber, escribe un documento que somete a la consideración de sus pares, científicos especializados en el mismo dominio de conocimientos, enviando su trabajo con la intención de que sea publicado por alguna revista especializada. Si se trata de un aporte científico real, personas de conocida reputación por sus conocimientos en el área en cuestión deben tener criterios para emitir un juicio, actuando como árbitros de la revista a la cual el autor envió su trabajo. Se parte de la premisa que si varios de estos árbitros, debidamente reconocidos, opinan que hay un aporte, sin duda lo hay y se autoriza la publicación en la revista científica. El trabajo es publicado y a partir de allí el autor y el aporte pueden ser citados con esa publicación. Los árbitros deben cuidar el prestigio del cual dependen en su hacer cotidiano, y por eso, el mecanismo de calidad funciona.

Sin embargo, como puede notarse, el proceso descrito es artesanal y con los volúmenes de información que maneja arXiv y la gran cantidad de personas que actualmente elaboran conocimientos, es clara la necesidad de un cambio en el mecanismo de certificación del contenido científico de una publicación. Este es el gran debate que arXiv abrió al convertirse en el recurso primario diario para comunidades mundiales de investigadores. Como la publicación en arXiv es la primera referencia de autoría en muchas áreas de la Ciencia, se convierte, en la práctica, en la principal referencia en cada comunidad científica participante al momento de atribuir autoría a ideas, teorías y conocimientos. Pero como en ArXiv se publica sin arbitraje, es claro que se trata de una revolución en el mecanismo de calidad de la producción científica. El crowdsourcing del que se habla ahora comenzó a gestarse en el ámbito científico con arXiv. No todos lo vieron, incluso ahora no todos lo ven, pero con arXiv comenzó a hacerse evidente el cambio inevitable en los mecanismos de validación de la ciencia moderna.

sábado, 13 de agosto de 2011

Catálogos colectivos con Z39.50


Trinity College Library Dublin es una biblioteca legendaria
con una historia que se remonta al año 1592. Es la biblioteca
más grande de Irlanda. Hoy día, como cualquier biblioteca
moderna, tiene su catálogo disponible a través de un servicio Z39.50,
lo que le permite ser consultada a su vez desde otros catálogos colectivos

Hemos estado trabajando el tema de los catálogos colectivos bibliotecarios bajo los nuevos esquemas que, después del año 2000, se desarrollaron bajo la Iniciativa de Archivos Abiertos (OAI). Pero, como es fácil constatar, ésta no es la única manera en que actualmente se crean catálogos colectivos. También se han desarrollado y se continúan desarrollando catálogos colectivos bibliotecarios usando el protocolo Z39.50, una aproximación anterior, pero sobre todo diferente. Lo que es importante para el profesional de la información, el director o gerente de servicios de información, es conocer las diferencias entre un tipo de catálogo colectivo y otro y en qué condiciones se puede preferir cada uno, así cómo y por qué se pueden implementar los dos simultáneamente. Dedicamos a esta conversación nuestro escrito de hoy.

Z39.50
Z39.50 es un protocolo al que le hemos dedicado varios post (Ver por ejemplo: El protocolo Z39.50 ). Es un protocolo que data de finales de los años 80 pero que se desarrolló ampliamente en los años 90. Una de sus principales virtuales es la interconexión de sistemas bibliotecarios heterogéneos en tiempo real. Como mostramos en las conversaciones sobre el desarrollo de nuevas alternativas que surgieron en la década de los 2000 (Ver La evolución del Z39.50 al OAI), su principal virtud, el tiempo real, se convirtió, en la práctica, también en su principal limitación.

Por qué puede ser bueno un catálogo colectivo en tiempo real
Un catálogo colectivo generado en tiempo real ofrece la ventaja de que apenas un item es cargado en cualquier unidad de información participante, el item está disponible inmediatamente en el catálogo colectivo. No hay retrasos asociados. Cuando un usuario consulta el catálogo, en ese instante se exploran todas las bases de datos de cada una de los nodos integrantes, por lo que la respuesta no se elabora a partir de una copia, sino siempre sobre los datos originales. Es por diseño fidedigna y actualizada.

Otras ventajas de un catálogo colectivo con Z39.50
El uso de Z39.50 para la implantación de catálogos colectivos tiene también otras ventajas, como lo es la interfaz unificada con el servicio local que presenta el catálogo colectivo al usuario final y el uso de un esquema de base de metadatos prolijo en términos bibliotecarios, como el MARC.

Por qué puede no ser bueno un catálogo colectivo en tiempo real
El problema de preparar la respuesta a partir de los datos originales, en tiempo real, es esencialmente práctico. Se requiere que todas las unidades integrantes del catálogo colectivo tengan buenas conexiones a Internet y que respondan rápidamente. Lo que ocurre en la práctica es que la respuesta colectiva tiene a ir al ritmo del nodo más lento y cuando se están consultando simultáneamente más de cinco bases de datos en tiempo real, todas participantes de un mismo catálogo colectivo, el tiempo de la más lenta suele pesar excesivamente en la calidad del servicio global.

Catálogos híbridos
Como Z39.50 y OAI-PMH son protocolos complementarios, en no pocos casos se implementan catálogos colectivos duales, en los que conviven los dos tipos de protocolos. Ésta puede ser una solución razonable para servicios de mediano tamaño donde las conexiones de todos los nodos son razonablemente rápidas. Sin embargo, cuando se piense en implementar este tipo de catálogos híbridos se debe tomar en cuanta la complejidad intrínseca de este tipo de solución. En algunos sistemas integrados el tener ambas alternativas es fácil y estandarizado, mientras que en los sitios donde las capacidades que definen el servicio se logran articulando módulos de software de distinto origen, el trabajo de implementación puede ser más complicado.

viernes, 5 de agosto de 2011

Calidad de las conexiones y calidad de la información

OAI-PMH puede usarse para conformar bibliotecas
virtuales o catálogos colectivos de redes
de bibliotecas pequeñas,
así como en pequeñas redes de bibliotecas.

Hace 15 días, expusimos el tema de los catálogos colectivos universitarios en el contexto de Iniciativa de Archivos Abiertos (OAI). La semana pasada, en ocasión de contestar las preguntas que se generaron acerca del uso del protocolo OAI-PMH para cosechar metadatos y armar catálogos colectivos universitarios, nos referimos como ésta solución es apropiada en el caso de catálogos grandes, con millones de registros provenientes de centenares de repositorios. Pero como mencionamos ese día en la introducción, algunas de las preguntas que recibimos solicitan aclaratorias sobre un problema opuesto ¿Es el uso de OAI una solución conceptualmente válida y funcionalmente práctica en el caso de instituciones pequeñas y redes de pequeñas bibliotecas? ¿Qué pasa en los lugares donde las conexiones son lentas y a veces sin una completa garantía de continuidad, como ocurre en numerosos casos latinoamericanos? Trabajamos en este post las respuestas a estas otras situaciones.

¿Es ésta una solución válida en redes de pequeñas bibliotecas?
OAI-PMH es un protocolo válido en grandes redes y grandes servidores porque es eficiente en el manejo de volúmenes de datos, por el esquema de cosechas y por el mecanismo de control de flujo que incorpora. Pero es interesante observar también, que por lo liviano y simple de su concepción, su aplicación se adecua a pequeñas bibliotecas y pequeñas redes de bibliotecas y a redes de pequeñas bibliotecas, como puede ser el caso de bibliotecas escolares. Otros esquema para la integración de redes, como el Z39.50, son más exigentes en su implementación y eso los hace menos aptos para el caso de servicios de información de pequeño tamaño.

Para pequeños centros de documentación y pequeñas bibliotecas el OAI-PMH tiene como virtud que se puede implementar en servicios de bajo costo y requiere relativo poco mantenimiento.

¿Qué pasa en los lugares donde las conexiones son lentas y a veces sin una completa garantía de continuidad?
Una de las características de las conexiones en muchos lugares de Latinoamérica es la baja velocidad de las conexiones que se disponen en algunas unidades educativas. La buena noticia es que precisamente OAI-PMH es una buena solución y trabaja bien en estos ambientes heterogéneos donde hay disimilitud en la velocidad de las conexiones y en la calidad del servicio. El esquema de cosechas reúne en el servidor local los metadatos de los distintos proveedores y por eso poco importan para él las capacidades de los servidores de origen, ya que el valor agregado no se hace en tiempo real sino en tiempo diferido, después que se han reunidos consistentemente todos los metadatos en un único sitio.

El protocolo es simple y liviano al operar. Los registros pueden ser producidos en unidades de información de conexiones lentas y cosechados a servidores de mayores capacidades residentes en lugares mejor conectados. Esto hace que con OAI-PMH se pueda disponer de servicios de valor agregado eficientes a pesar de las limitaciones de muchos nodos de la red.

Conclusión
En conclusión, OAI-PMH es una excelente alternativa para formar bibliotecas virtuales o catálogos colectivos provenientes de cualquier tipo de proveedores de metadatos, entidades homogéneas o heterogéneas, grandes o pequeñas, con conexiones rápidas o lentas, con servicios regulares o de prestaciones inconstantes. Se puede decir que mientas más heterogéneo sean los nodos proveedores de contenidos que alimentan un servicio recolector de metadatos, más importante es el aporte del OAI-PMH al desarrollo de un catálogo colectivo.

martes, 26 de julio de 2011

El tamaño de los catálogos colectivos

El Catálogo Colectivo de de las Colecciones de Mapas,
Planos y Dibujos de los Archivos Estatales Españoles

son una muestra interesante del uso del OAI-PMH
para construir catálogos colectivos.
La semana pasada estuvimos hablando de los catálogos colectivos universitarios. Un caso de aplicación interesante del tema de metadatos y protocolos que hemos venido trabajando en los últimos meses y cuya facilidad de construcción actual no tiene nada que ver con las dificultades que había para este tipo de soluciones en el pasado. Nos llegaron a nuestro buzón algunas preguntas, por lo que atendemos en este post algunas de las dudas que nos plantearon nuestros lectores y, por razones de espacio, dejaremos para uno siguiente algunas otras. En este nos concentraremos en atender las dudas sobre el desarrollo de redes de relativo gran tamaño, con muchas decenas de nodos. Atendemos pues preguntas como ¿Cuántas bibliotecas pueden ser reunidas en un catálogo colectivo con OAI-PMH? o ¿Dónde están los limites que los directores de servicios de información debemos tener en cuenta? y dejaremos para la siguiente oportunidad preguntas sobre el caso de las bibliotecas pequeñas, las redes de las instituciones escolares y el tema de los escasos presupuestos.

¿Cuántas bibliotecas pueden ser consolidadas con catálogos colectivos construidos con OAI?
Una de las ventajas del protocolo OAI-PMH es el uso de un control sencillo del flujo de información en cada cosecha. Este control de flujo permite que, sin intervención humana, los sistemas dosifiquen automáticamente sus comunicaciones y la recolección de metadatos cuando los volúmenes a cosechar son grandes. Una vez definido el proceso adecuadamente con las herramientas de OAI, el software proveedor de metadatos y el software cosechador de metadatos sincronizan la recolección sin que ninguna persona tenga que intervenir y sin degradar los servicios de ninguna de las partes. La cosecha de metadatos ocurre detrás de los bastidores de la red sin que los usuarios de ninguna biblioteca tengan que darse por enterados.

Por otro lado la cosecha de metadatos se realiza normalmente en forma incremental, es decir, se cosecha en cada ciclo sólo lo que se ha cambiado (incorporado, modificado o borrado) en el proveedor de metadatos desde la última vez que el recolector lo cosechó, haciendo innecesario mover volúmenes muy grandes de información cotidianamente.

Adicionamente OAI-PMH está preparado para manejar sin problemas muchos repositorios de metadatos, por lo que su uso es adecuado para catálogos colectivos de numerosas bibliotecas o unidades de información. Hay servicios de catálogos colectivos en el mundo que albergan millones de registros provenientes se centenares de unidades de información contribuyentes, lo cual prueba que efectivamente con OAI-PMH se pueden desarrollar catalogos colectivos muy grandes (Ver OAISter).

Limitaciones físicas
Sin menoscabo de lo anterior, si es importante a tomar en cuenta, en el caso de servicios de relativo gran tamaño, las características del servidor físico que debe manejar el catalogo consolidado, ya que finalmente tendrá que trabajar con tantos registros como la suma de los registros de todas las unidades de información participantes en el catálogo colectivo.

Además de la cantidad de registros está el tema de la cantidad de consultas. Si los servicios llegan a ser interesantes para un público numeroso, pudiera darse el caso de que la cantidad de consultas también lo fuera, lo que debe llevar también a evaluar el dimensionamiento adecuado del servidor que proveerá el servicio consolidado.

Finalmente es importante cuidar el tema de las conexiones der servidor que centraliza la cosecha de información y provee el servicio de valor agregado. Si bien, OAI-PMH permite que la calidad de las conexiones a Internet de cada unidad de información individual no sea un tema relevante, la calidad de la conexión a Internet del servidor recolector si lo es.