Beneficios de la AI para expertos en información

FUENTE: HIPERBIBLIOTECAS.ORG




La semana pasada hablamos de cómo la Arquitectura de Información (AI) se traducía para el usuario final en una mejor experiencia en el manejo de la información. En efecto, normalmente la AI mejora la exploración, búsqueda, encontrabilidad, recuperación y navegación de un sitio Web, en cualquier ámbito de conocimiento, en cualquier nivel de profundidad y en cualquier aproximación funcional. Ahora bien, en la acera del frente, ¿Qué beneficios trae la AI para los gerentes de información, desarrolladores de sitios de contenidos o líderes institucionales? Ese es el tema de hoy.

Para las personas que están en estos roles los beneficios son varios y variados:

Comunicación con sus usuarios
El primero, lograr una mejor comunicación con los usuarios.
Con la Web 2.0 se habla de Arquitecturas de participación. Hay un énfasis fuerte en la comunicación con el usuario y en el logro de que éste encuentre maneras sencillas, efectivas y motivadoras de subir sus contenidos a los sistemas de información. Esta Arquitectura de participación requiere, para ser posible, de una AI muy bien definida.

Sitios que soportan el crecimiento y se adaptan a los cambios
Una de las ventajas de una AI bien definida es poder soportar el crecimiento y adaptarse a los cambios. Cuando comparamos lo que la puesta en escena de algunos de los sitios Web líderes en el mundo son actualmente con lo que ellos eran hace 10 años, notamos el enorme crecimiento y los cambios, tanto cuantitativos como cualitativos, que han tenido lugar. Esta capacidad de adaptarse a volúmenes de información crecientes y a cambios de entorno es ayudada, sin duda, por una AI bien diseñada e implantada.


Métodos para determinar contenidos, contextos y funcionalidades
La perspectiva funcional de la AI, donde se busca atender las necesidades de información de instituciones y usuarios es transdisciplinaria y puede aportar métodos para determinar la necesidad de nuevos contenidos, explicitar contextos de uso adecuados a los distintos perfiles y requerimientos funcionales dirigidos a mejorar la usabilidad del sitio Web en el que se trabaja.

Uso de “taxonomías” entendibles
Uno de los elementos claves en la construcción de un buen sitio Web es el uso de una taxonomía alineada con todas las necesidades e interrelaciones prácticas. Muchas veces los problemas de usabilidad se originan en el hecho de que los esquemas de clasificación que usamos son racionales y alineados con el conocimiento establecido, enriquecidos con el aporte de las Ciencias de la Información, pero no fácilmente utilizables por nuestros usuarios. Pero si éstos no entienden las categorías que empleamos para organizar la información tendrán dificultades para moverse en los mapas funcionales de nuestro sitio Web. Por ello, la AI hace un énfasis especial en lograr esquemas de clasificación y de organización de la información que resulten adecuados tanto para la institución como para el usuario.

Navegación intuitiva
Como hemos hablado en otras oportunidades, la navegación efectiva es una de las capacidades difíciles para desarrollar e implantar y es crítica para el éxito de un sitio Web. Siendo ésta una de las dimensiones de trabajo de la AI el desarrollador o equipo responsable de un proyecto se beneficia cuando trabaja con un marco conceptual que le ayuda a trazar un mapa de navegación que resulta adecuado a las necesidades y personalidades de usuarios e instituciones.

Credibilidad
En una palabra, el resultado más importante que un Gerente de información obtiene cuando incorpora AI en el sitio Web bajo su responsabilidad es credibilidad. Su trabajo, su obra, será reconocida por los usuarios y la institución.

Arquitectura de Información

Tomado de: Hiperbibliotecas.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.

Lo bueno, lo malo y lo feo del formato PDF

FUENTE: hiperbibliotecas.org

Lo bueno, lo malo y lo feo del formato PDF

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.

Biblioteca de la Facultad de Ingeniería de la Universidad Central en Línea

Gracias al apoyo de las autoridades de la Facultad de Ingeniería, Ciencias físicas y Matemáticas, sumado al trabajo permanente del personal de la Biblioteca de la Facultad, y al apoyo técnico de la Unidad de Informacón de la Universidad Central en colaboracion con MULTISOLUTIONS, han hecho posible que se pueda conocer todo el acervo bibliográfico en línea con el que aporta esta importante Biblioteca, se puede aceder desde el link:

http://biblioteca.fing.uce.edu.ec/

Además dento del Campus Universitario se puede aceder a otras Bibliotecas que van caminando hacia e mismo objetivo, entre ellas, la Biblioteca Central y de las Facultades de Arquitectura, Economía, Psicología, y otras más que se están modernizando y trabajando colaborativamente para conformar el Sistema Integrado de Bibliotecas de la Universidad Central.

Invitamos a conocer este espacio, que en corto plazo pasarán a formar parte del Portal:

http://www.bibliotecasdelecuador.com/

Att,

Ramiro Almeida
Coordinador del Portal
http://www.bibliotecasdelecuador.com/

Catálogos colectivos universitarios

Catálogos colectivos universitarios

Desde el advenimiento de la Iniciativa de Archivos Abiertos (OAI), es relativamente sencillo para una institución universitaria consolidar todas sus referencias en un catálogo colectivo que integre a todas las unidades de su sistema bibliotecario distribuido. No es necesario que las bibliotecas estén todas operadas con un mismo software o que residan en un mismo servidor. No es necesario que todas tengan conexiones de alta velocidad. No es necesario ni siquiera que el sistema de catalogación bibliotecario sea exactamente el mismo para que la idea funcione. Basta con convenir que el catálogo colectivo se implemente mediante el uso de un protocolo internacional de cosecha de metadatos, eficiente y flexible, como OAI-PMH, y definir los servicios que se desean prestar desde el catálogo colectivo. Explicamos en este post el cómo hacerlo en un lenguaje claro para directores de bibliotecas y responsables de servicios.

Cómo participa una biblioteca en un catálogo colectivo bajo OAI?

Para integrar un catálogo colectivo con la información de múltiples bibliotecas, cada biblioteca que desee participar en el catálogo colectivo debe habilitar en su sistema bibliotecario la publicación de metadatos según el protocolo internacional OAI-PMH. Este, como hemos estado exponiendo en las últimas semanas, es un protocolo sencillo cuyas especificaciones son abiertas y están publicadas en el sitio http://www.openarchives.org. Habilitar este protocolo es normalmente una opción que está disponible en los sistemas bibliotecarios de calidad internacional, por lo que sólo hay que preguntar al proveedor cómo se realiza. Una vez que se activa el OAI-PMH, el siguiente paso es registrar la biblioteca como un repositorio de metadatos en el sitio http://www.openarchives.org. Esto se hace para que cualquier servicio de integración de metadatos pueda saber qué tipo de información está disponible y, al mismo tiempo, ofrecer garantías de que el software OAI-PMH está bien implementado.

Cómo se crea el catálogo colectivo

Con las distintas bibliotecas registradas como repositorios de metadatos, el catálogo colectivo se crea en un servidor que implementa la pieza complementaria: un recolector de metadatos OAI-PMH. Este cosechador recogerá periódicamente los metadatos producidos en las distintas bibliotecas y los reunirá en una única base de información.

En forma adicional al protocolo, la clave para mezclar apropiadamente los datos cosechados es el uso de un esquema de metadatos común. Bajo OAI-PMH este esquema común es normalmente, pero no necesariamente, Dublin Core. Una ventaja de Dublin Core es su sencillez y la otra que permite reunir en forma apropiada metadatos de orígenes diferentes. Por ejemplo, la información de bibliotecas puede reunirse consistentemente con la información de archivos, centros de documentación y otras unidades de información que no son bibliotecas.

Una vez reunidos los metadatos procedentes de distintas fuentes en una base de información local (para el servidor que cosecha), el proveedor de servicios puede proporcionar valor agregado estadístico, de búsqueda, de exploración, de clasificación temática, etc.

Qué tipo de catálogos colectivos pueden crearse

Pueden crearse distintos tipos de catálogos colectivos, por ejemplo institucionales, uniendo en un mismo catálogo la información de todas las bibliotecas de la institución. También pueden crearse catálogos temáticos, uniendo en un mismo catálogo todas las referencias procedentes de distintas unidades de información que tengan contenidos en un determinado tema, por ejemplo, Energía. Del mismo modo, puede usarse el protocolo OAI-PMH para crear catálogos interinstitucionales, con referencias de múltiples instituciones.

La característica de conjuntos del OAI-PMH puede usarse para definir un catálogo, pero en ese caso si se requiere acuerdo en lo que se considera un conjunto determinado en cada unidad de información participante.

MULTISOLUTIONS

FUENTE:HIPERBIBLIOTECAS.ORG

Catálogos colectivos con Z39.50

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.






FUENTE: HIPERBIBLIOTECAS.ORG, YOUTUBE

MULTISOLUTIONS EN EXPOLIBRO 2011

NUESTROS AGRADECIMIENTOS A TODOS LOS COLEGAS GUAYAQUILEÑOS

POR SU ENORME Y SINCERA ACOGIDA.

FLACSO ANDES... Más que una Biblioteca Virtual

¿Qué es cosechar metadatos?

¿Qué es cosechar metadatos?

FUENTE: Hiperbiblioteca.org

En los últimos meses hemos estado hablando de metadatos y en las últimas semanas de la Iniciativa de Archivos Abiertos (OAI) y la recolección de metadatos. Ubicamos este movimiento internacional en un contexto histórico desde la perspectiva del profesional de Ciencias de la información. Queremos esta vez detenernos en un punto particular: El concepto de cosecha de metadatos, como fue definido formalmente en el protocolo OAI-PMH a comienzos del presente siglo. Por supuesto, orientaremos nuestra exposición a proporcionar, en un lenguaje natural, los conceptos fundamentales de lo que es cosechar metadatos, sin entrar en detalles excesivamente técnicos que aparten a los lectores que no los manejen. Las acciones que básicamente puede realizar un proveedor de metadatos y que por tanto pueden ser solicitadas por un recolector de metadatos son acciones que pueden explicarse en forma relativamente simple y es lo que pretendemos abordar.

Cosechar metadatos

Cosechar metadatos es traer los metadatos cultivados en otros servicios hasta un servidor local con el objeto de reunirlos con otros metadatos y prestar servicios de valor agregado.

Para cosechar metadatos en una forma estándar se requiere ciertos acuerdos entre el proveedor de metadatos y el cosechador. Estos acuerdos se condensan en el protocolo de cosecha que se esté usando, por ejemplo OAI-PMH.

Mientras más sencillos sean los términos de este acuerdo más fácilmente será implementar el protocolo para los proveedores de metadatos y para los recolectores de los mismos. Una de las virtudes del OAI-PMH es que definió el acuerdo básico en la posibilidad de realizar sólo seis acciones, definidas en el protocolo a través de seis verbos básicos.

Los seis verbos que bajo OAI-PMH el proveedor de metadatos debe poder entender y realizar se pueden clasificar en dos grupos: Acciones de información sobre el repositorio, a través de los cuales un servicio informa acerca de si mismo y Acciones de entrega de metadatos, a través de los cuales el servicio proporciona los registros de metadatos que almacena.

Información acerca del servicio

Bajo OAI-PMH un repositorio debe poder caracterizar su servicio para que cualquier cosechador sepa con quien está conversando. Así, un recolector que conoce la dirección de un proveedor de metadatos podrá preguntar: "¿Quién eres?" Y también: "¿Qué información puedes proporcionar?" Con la seguridad de poder ser entendido y de entender la respuesta.

Para ello un repositorio de metadatos debe poder 1) Identificarse como repositorio, 2) Enunciar los formatos que se reconocen, 3) Enumerar los conjuntos de registros con los que se trabaja.

Identificar el repositorio es entregar la información básica acerca de éste: su nombre, su dirección en Internet, la fecha más lejana en los registros que contiene.

Esta identificación es importante en una Internet llena de potenciales proveedores de metadatos en la que un servicio que desea producir valor agregado debe por lo menos poder enterarse en forma básica las características que definen cada uno de los repositorios que consulta.

Los pioneros de la cosecha de metadatos, sus motivaciones y sus ideas....

Como presentamos en nuestro post más reciente, en el nuevo milenio se inició el desarrollo de protocolos sencillos para cosechar metadatos. Hacía poco más de una década que se había desarrollado el protocolo Z39.50, que fue un diseño hecho con la intención de resolver el problema idealmente. De alguna manera éste protocolo planteó una solución excelente, pero en la práctica algunos problemas se evidenciaron y se prefirió hacer entonces un viraje hacia una solución más pragmática, más humilde, pero mucho más práctica y sencilla de implementar: el OAI-PMH. Esta solución más sencilla no eliminó la necesidad del Z39.50, porque simplificó conceptos que aquel resolvía bien, pero si resolvió en forma concreta problemas que limitaban a muchos servicios de información pública. En este post contamos brevemente la historia de los pioneros del movimiento de archivos abiertos, para reconocerles en su contexto su gran mérito, pero también, para extraer lecciones de la historia, contada desde una perspectiva útil a los profesionales de la información. Eso nos permitirá entender mejor el presente y el futuro del intercambio de metadatos.

Los pioneros de la idea de archivos abiertos

Los pioneros detrás de la idea de archivos abiertos fueron Paul Ginsparg, Richard Luce y Herbert Von de Sompel. Son tres personas que para fines del milenio había hecho aportes muy interesantes en términos de soluciones para el almacenamiento y recuperación de información académica, que coincidieron en el tiempo y en el espacio en Los Álamos y tomaron una iniciativa que despegó internacionalmente el movimiento.

Paul Ginsparg comenzó en 1991 un servicio de auto archivo de documentos académicos que fue operado desde Los Alamos National Laboratory como un repositorio para pre prints de Física y que se hizo célebre como la “lista de los Álamos”. Por su éxito significativo, el servicio se expandió a otras áreas de la ciencias como las Matemáticas, las Ciencias de la computación, la Biología y las Estadísticas. Con los años, al ampliar su volumen y flexibilidad, la lista se convirtió en el servicio arXiv.org y comenzó a operarse desde la Universidad de Cornell. Este servicio tiene actualmente varios centenares de miles de artículos y recibe todos los meses varios miles de ellos.

Richard Luce fue director de la Biblioteca de Investigación en Los Alamos National Laboratory desde 1991 hasta el 2006, experiencia que le permitió hacer contribuciones sobre el papel de la publicación electrónica en la llamada eInvestigación y, particulamente, el papel de las bibliotecas de investigación en este proceso. En 1999 fue cofundador de la iniciativa de archivos abiertos y en el 2003 coorganizó la declaración de Berlin sobre Acceso abierto al conocimiento, un hito histórico para la humanidad. Sus contribuciones están en las áreas de innovación en Bibliotecas digitales y publicación electrónica.

Herbert Von de Sompel es un bibliotecario belga y científico de la computación que, con el beneficio de esta doble perspectiva, ha hecho contribuciones importantes en la Iniciativa de Archivos Abiertos, particularmente en el establecimiento y desarrollo de estándares tales como el OAI-PMH, para la cosecha de metadatos, el OpenURL, para servicios sensibles a contexto, y el OAI-ORE (Object Reuse and Exchange), para la descripción, intercambio y valor agregado de recursos existentes en la Web.

La idea de servicios universales de literatura académica auto archivada por los autores

La idea que motivo a los pioneros mencionados en los finales del milenio pasado era cómo cambiar el paradigma de la publicación científica y el acceso al conocimiento académico. El antecedente principal fue el enorme éxito que la lista de los Alamos había alcanzado para 1.999. Estas personas se encontraron y sincronizaron en el célebre laboratorio y desde allí convocaron un par de encuentros que catalizaron el desarrollo del OAI-PMH y que se realizaron en la ciudad de Santa Fe en octubre de 1.999 y Junio del 2.000. El protocolo nació con una primera edición preliminar en Septiembre del 2000, una par de versiones iniciales (Beta 1.0 y Beta 1.1) en el 2.001 y una versión de producción en Junio de 2.002.

Organizaciones importantes como la National Science Foundation (NSF) y la Digital Library Federation (DLF) apoyaron financieramente la iniciativa y personalidades de prestigio en el área se identificaron y soportaron el trabajo. Así la idea de cosechar metadatos que expusimos en nuestro post anterior (¿Por qué cosechar en lugar de buscar en tiempo real los metadatos que necesitamos?) concretó posibilidad de contar con un marco de referencia moderno y sencillo para compartir metadatos: el protocolo OAI-PMH.

FUENTE: HIPERBIBLIOTECAS.ORG