Sopa de bits

Reflexiones sobre la información

By

Organización de la información personal II: Gestión documental vs archivística


Relevancia y Actividad

La gran diferencia entre centros de documentación (incluyo indistintamente bibliotecas aunque existan diferencias obvias) y archivos es el cómo y el por qué se gestionan unos tipos de documentos, y los criterios por los que se seleccionan para ser almacenados, tratados o retirados/eliminados.

Por un lado, los centros de documentación y las bibliotecas se centran en el criterio de relevancia: estos centros buscan satisfacer las necesidades de información que se presentan a sus usuarios, y por ello buscan documentos que cumplan esa función, con idependencia de la fuente (aunque se tiene en cuenta la fiabilidad).

Los archivos en cambio tienen objetivos esencialmente operativos. En la visión tradicional de los archivos, lo que se mantiene son aquellos documentos que han sido generados por la propia institución o por otras instituciones, fruto de la actividad de la primera. Es decir, los documentos del día a día.

Aunque poner en un par de frases estas ideas es mucho resumir, vale la pena incidir en esta diferencia: en el primer caso, lo importante es la relación entre la curiosidad-documento, mientras que en la segunda está la relación actividad-documento.

Ejemplos claros de documenos de uso personal que pueden entrar en cada tipo son:

  • Documentos para centros de documentación o bibliotecas:
    • Recortes de diarios sobre noticias de interés.
    • Fotografías (personales, institucionales, etc.).
    • Recetas de cocina (por hacer honor al nombre del blog…).
    • Partituras musicales.
    • Por lo general, documentos que no sean legales, contractuales, operativos (documentos de trabajo), y cuyo objetivo de guardar en nuestra colección sea estrictamente por el valor del contenido en sí y no por el contexto de uso.
    • Directorios o listas de contactos.
  • Documentos para archivos:
    • Recibos y Facturas vigentes.
    • Contratos de servicios (esto incluiría, por poner un ejemplo, una matrícula universitaria).
    • Documentos de contabilidad personal.
    • Escrituras oficiales y otros documentos notariales.
    • Documentación oficial en general.
    • Nuestra agenda o una lista de tareas pendientes (esto puede ser relativamente discutible pero en mi caso lo he incluído aquí y ha sido coherente).

El entorno electrónico presenta gran cantidad de casos ambiguos o que al menos nos plantean dudas razonables. Por ejemplo:

  • ¿este blog entraría en el apartado de gestión documental, o de archivo? Yo creo que las aportaciones individuales entran dentro de la gestión documental.
  • ¿Y el correo electrónico? Tengo configurado mi programa de correo para que utilice reglas de filtrado, que por lo general me permiten organizar automáticamente los correos electrónicos en base al remitente. Dados los criterios indicados anteriormente, esto introduce de lleno el correo electrónico en la gestión archivística. Define una relación entre mí y otros, y probablemente establece una relación entre el documento y mi actividad. Sin embargo, yo diferenciaría claramente entre correos de trabajo y correos personales. Los primeros tienen carácter archivístico y los segundos, carácter de gestión documental.

Para cada caso que se plantea, lo mejor es definir el objetivo por el que guardas el documento (como documento con contenido de interés, o como documento de archivo) y luego ya podrás concretar qué haces con él.

de lo útil y lo inútil

Con lo dicho hasta ahora, lo que está claro es que mi tarea de selección de documentos ha ido muy dirigida a algo necesario en esta era digital: descartar lo inútil.

¿Que tal si te tomas una pausa y echa un vistazo a la lista de tus correos electrónicos, documentos y demás… ¿A que quizá sobra algo?

Lo inútil llega a serlo por muchas razones, gran parte de las cuales están en tus manos definir. Lo inútil para mí es lo que no es relevante ni útil. Pero en general, lo inútil lo relaciono con aquello que no tiene ningún tipo de valor (no sólo económico).

Rehaciendo el dicho lo inútil no nace, se hace.

Es inútil todo aquello que ha superado su ciclo de vida a nuestro lado, y es importante que nos demos cuenta de cuándo sucede. Ese documento no siempre fue inútil, y puede que sea útil a terceros. Pero ha llegado el momento de moverlo a la lista de inútiles.

No hacerlo revierte en costes, que se convierten en pérdida de tiempo a nivel personal (con lo difícil que es a veces encontrar un rato para nosotros, y tener que pasarlo buscando entre documentos inútiles…) y de dinero a nivel profesional (se puede ver sumando el total de tiempo perdido, o viendo cómo se pierden clientes por no tener las cosas "a mano")

Lo inútil (que en algunos casos también podemos denominar obsoleto) se puede equiparar a dos términos según las dos divisiones anteriores: lo irrelevante y lo inactivo. Lo irrelevante es todo aquel documento (sobre el cual aplicaríamos criterios de gestión documental) cuyo contenido no puede resolvernos dudas. Lo inactivo es todo aquel documento (sobre el cual aplicaríamos criterios archivísticos) cuyo contenido ha dejado de tener valor operativo.

Como anécdota, es posible que un documento que ha dejado de ser inactivo pueda ser relevante. por poner un caso: has redactado la documentación de un proyecto y te gusta cómo ha quedado. El proyecto acabó hace tiempo pero te gustó la estructura del documento y quieres reaprovecharlo: quizá sea relevante dejar el documento vacío del contenido original y mantener la estructura para posteriores tareas. Son casos aislados pero puede suceder.

Lo importante de estas dos visiones es que en mi caso ha valido mucho la pena diferenciar las dos tipologías documentales. Esto ha simplificado mucho la estructuración de los documentos en directorios, y además esta estructura ha sido más fácil de recordar y asimilar (con lo que luego es más fácil de utilizar para recuperar documentos).

Evaluación y selección: algunos criterios

Ahora que ya podemos ver la diferenciación entre los dos tipos principales de documentos, podemos entrar a valorar los criterios de selección y evaluación. En esencia son criterios simples que yo he utilizado. Presentan diferencias entre documentos generales y documentos de trabajo, ya que el factor de la relevancia aplicable en el primer caso tiene elementosmuy subjetivos, mientras que los criterios archivísticos de fuente del documento, cronología y tipología de documento es más sencillo de aplicar (incluso por terceros).

Lanzo aquí algunos factores clave que ya iré matizando en otros posts, si procede. Insisto en que son criterios propios y que, especialmente en los criterios de relevancia, vale la pena completar la lista indicada con criterios personales.

  • Criterios para establecer documentos relevantes e irrelevantes:
    • Irrelevante: El contenido ha dejado de ser un área de interés personal, o su nivel de complejidad ha sido superado.
    • Irrelevante: El documento forma parte de un conjunto mayor del que se tiene disponibilidad (en esencia, esto es un caso oculto de documento duplicado).
    • Irrelevante: El documento ha dejado de ser válido porque hay investigaciones o avances posteriores que lo desautorizan (en este caso incluyo documentos que tratan sobre versiones obsoletas de aplicaciones informáticas o lenguajes de programación).
    • Irrelevante: El documento está ampliamente disponible en la red (y por ello más actualizado).
    • Relevante: tiene un valor personal y sentimental que es implícito a su contenido (en este capítulo cabe poner las cartas de amor de relaciones presentes y pasadas, jeje…).
    • Relevante: el contenido es actual y necesario en mayor o menor medida como documento de consulta.
  • Documentos activos e inactivos:
    • El documento ha dejado de tener valor legal y se ha roto cualquier relación contractual con la entidad emisora del documento.
    • La fuente emisora del documento ha desaparecido. Opcionalmente, el documento ha sido sustituido por otro que se ajusta a la situación actual (la entidad ha cambiado de nombre, se ha fusionado con otra entidad, etc).
    • El valor del documento es simplemente de relevancia (aplicar los criterios anteriores).
    • Hemos abandonado la actividad a la que se refiere el documento.
    • Hemos perdido el objeto al que se refiere la factura y no tenemos esperanza de recuperarlo.
    • Concretamente en el caso de un contrato laboral, ha finalizado y ha quedado correctamente reflejado en los datos que envía el MTAS.

Desde luego puedo añadir más elementos a esta lista. Es probable que los vaya añadiendo a medida que avance en mi tarea de organización. Estaría bien saber si alguien que enlace esto tiene interés en poner su lista propia. En el fondo, la relevancia es una cuestión personal.

Continuaré en breve con esta serie, que tengo cosas en el tintero…

By

Organización de la información personal – I: eliminando archivos duplicados


Consideraciones previas

Una de las primera cosas que debo decir antes de entrar en detalle, es que la detección de duplicados no debe conducir al borrado indiscriminado de las copias aparentemente inútiles. Por poner mi caso, el proceso de borrado se ha limitado a documentos, hojas de cálculo y demás archivos de trabajo. Por lo tanto, no he intentado eliminar programas, bibliotecas dinámicas (SO en linux, DLL en Windows) ni otras utilidades. Me he centrado en archivos pasivos, que no forman parte de procesos ni programas, cosa que recomiendo a todo aquel que no tenga claras las consecuencias de borrar lo que no debe borrarse. Para eso existen otras herramientas y probablemente otros tutoriales.

En segundo término, es importante aclarar que aunque se traten de dos documentos idénticos, hay que tener en cuenta el por qué se borran unos u otros, y si es necesario. Al revés del refrán, vale más la pena tener cien documentos duplicados a mano que uno volando. Eso siempre que tengas claro qué es lo bueno y qué es lo malo.

Una vez dicho eso, sólo quiero añadir que mi uso más intensivo se ha centrado a las utilidades de Linux, aunque he echado un vistazo y he testeado una utilidad en Windows sin incidencias remarcables.

Conceptos base para la detección de duplicados

LA gestión de archivos: Unix y Windows

Existen varias utilidades posibles para la detección y eliminación de duplicados. Sólo hay que pensar que UNIX es un sistema operativo más pensado desde sus inicios para el uso en grandes servidores, con gran cantidad de datos y por lo tanto con más dificultades en la gestión y administración de sistemas.

Dentro de esta gestión de sistemas se encuentran las utilidades de copia de seguridad, integridad del sistema de archivos y demás. La detección de archivos duplicados es una tarea accesoria que se puede realizar puntualmente, pero que desde luego toma su tiempo llevar a cabo sin las herramientas básicas.

Windows, por su lado, ha ido mejorando la estructura de directorios para poder diferenciar las ubicaciones de los archivos de programas y los documentos de trabajo del usuario. Sin que se haya conseguido concienciar más a una parte de usuarios que se obcecan en montar murales de documentos en su escritorio, lo cierto es que algo han conseguido. Por otro lado, las utilidades de gestión del sistema se han ido introduciendo con el tiempo. Me reservo mi opinión, porque entre otras cosas, no me considero un experto en sistemas, y mucho menos de Windows.

Optimización del proceso de comparación

Comparar dos archivos byte a byte sería una verdadera locura. Encontrar archivos duplicados en una lista de 10000 implicaría efectuar hasta (10000*9.999)/2=49.995.000 de revisiones en los archivos, lo que es computacionalmente muy ineficiente.

También es cierto que cuando se identifica un duplicado nos ahorramos recorrer tantas veces los archivos, pero en el caso que no hubiera ni un solo archivo idéntico en todo el sistema, recorrerías todas esas veces los archivos. Al final del proceso, además de tener claro que no tienes duplicados, quizá también debas plantearte un cambio de disco duro… Vamos, que no van por ahí los tiros.

Para identificar la duplicidad de archivos, el método pasa por establecer algoritmos que de generen una clave única de tales archivos, y así pueda compararse archivo por archivo, si las claves coinciden. Este es un procedimiento mucho más eficiente que el anterior, porque como máximo hay que recorrer 10000 veces los archivos (lo cual reduce en 9999 veces el volumen máximo de tareas a realizar).

A pesar de esto, es probable que en la mayoría de casos con leer pequeños bloques de unos cuantos bytes de un archivo ya se pueda descartar candidatos a duplicados, con lo que aún nos ahorramos el recorrer gran parte de los archivos (y eso es importante si los archivos son grandes).

Como se ve, existen varios trucos basados en el muestreo que permiten agilizar el proceso sin perder coherencia en el proceso. Como siempre que se realiza un proceso de muestreo, lo importante es la representatividad y no el tamaño de la muestra. Si con un byte tuviéramos suficiente, no sería necesario coger dos.

Algoritmos de generación de claves de resumen

Los métodos básicos para la detección de archivos duplicados es el cálculo de las claves de tipo resumen (o digest), como por ejemplo los algoritmos MD5, ó SHA1. Son casos concretos y hay bastantes más. El más utilizado es el MD5, especialmente debido a su popularidad y grado de implantación. Aunque ya no sirve como algoritmo criptográfico, es más que suficiente para la detección e indexación fiable de archivos.

Las claves de tipo digest asignan un valor de clave en base al contenido del archivo. Esta clave, a efectos prácticos, es única. Digo que lo es a efectos prácticos porque aunque se han detectado coincidencias (lo que se llama comúnmente colisiones) en la generación de claves, es prácticamente imposible que dos archivos coincidan en su clave. Por ejemplo, la clave MD5 consta de 32 dígitos hexadecimales (valores 0..F): considerando que se trata de variaciones con repetición, nos da un total de 1.208925819614629175e+24 combinaciones posibles, si no me equivoco (no, no lo he hecho mentalmente…).

Un ejemplo de clave md5 sería: 5a948ab8f80483be4e495c8c8fba39cd

Si tuvieras 1 millón de archivos a comparar, existiría una probabilidad de 1 entre 1018 de que dos de tus archivos tuvieran esta misma clave MD5, sin que fueran idénticos en contenido. La probabilidad es teórica (si el algoritmo fuera perfecto), pero en cualquier caso creo que quedan claras las proporciones, así que doy por hecho que entiendes que es difícil que dos archivos diferentes pasen por idénticos, a no ser que esa sea tu intención.

¿Y qué haces si te sucede? Bueno… pues dado lo poco probable del asunto, y que la máquina ya te reduce el trabajo, siempre puedes abrir los dos archivos y comparar. Pero vamos, yo he hecho el tratamiento sobre más de 150.000 archivos y no ha habido errores de este tipo.

Herramientas de búsqueda de duplicados en Linux

En Linux he testeado dos: la primera, llamada fslint, es una utilidad a nivel de escritorio que además de detectar duplicados, permite identificar otros problemas del sistema de archivos (datos colgando, partes corruptas del disco, etc).

Por mi familiaridad con la línea de comandos, descarté fslint en el momento de conocer de la existencia de fdupes, aunque si tenéis más interés en utilizar fslint os recomiendo que lo utilicés para hacer revisiones de volúmenes de datos no muy grandes: si se pasa mucho rato comparando, a veces se queda colgado.

:~# fdupes -r . > duplicados.txt
Progress [0/154304] 0%

El resultado de fdupes se guarda en el archivo duplicados.txt, que contiene una lista de resultados con un formato parecido al siguiente:

archivo1.txt
archivo2.txt

archivoN.txt
[espacio]
archivo1.dat
archivo2.dat
[espacio]

Cada grupo de archivos (los que no se separan por una línea en blanco) son archivos duplicados. Cuantos más archivos en cada bloque, más duplicaciones.

La tarea sucia está hecha y ahora nos queda a nosotros hacer una parte de tarea manual. Para ello será necesario abrir el archivo duplicados.txt y dejar sólo los archivos que queremos eliminar. Es decir, debemos borrar de la lista de archivo todas aquellas entradas que queremos conservar.

Una vez hecho esto, sólo nos queda invocar a nuestro querido awk para que convierta cada entrada en una línea de comando del shell:

# awk '{gsub(/ |\(|\)/,"\\\&");print "rm "$0}' < duplicados.txt | sh

Es decir, para cada línea del archivo duplicados.txt (< duplicados.txt) creo una línea que empiece por rm e incluya todo el contenido de la línea (print "rm "$0), enviando el resultado a ejecutar al shell (… | sh).

Con esto, se ejecuta línea por línea todos los archivos a eliminar. El comando gsub "escapa" los caracteres especiales que el shell podría malinterpretar como parte del comando a ejecutar y no como parte del nombre del archivo. Por ejemplo, los nombres que incluyen paréntesis o los que incluyan espacios, incluirán contrabarras para evitar ambigüedades al shell.

Con este proceso, que en mi caso, con 150.000 archivos (muchos pequeños) duró unas dos horas entre fdupes, procesado manual del archivo y limpieza final, hemos eliminado los archivos duplicados.

Duplicados en sistemas windows

Como ya he dicho antes, mi testeo en sistemas Windows ha sido muy limitado, por lo que os refiero al artículo de Techrepublic sobre limpieza de duplicados que habla sobre la instalación y ejecución del programa que he testeado: Dupfinder.

Esta aplicación funciona, cómo no, con interficie gráfica. Eso lo hace mucho más amena para los usuarios no muy dados a la línea de comandos. El funcionamiento es esencialmente el mismo, aunque es imposible decir si el criterio utilizado para detectar si dos archivos son duplicados es exactamente el mismo o no que en casos como fdupes.

Conclusiones

Hasta aquí la primera parte de mis tareas de reorganización de la información personal. Espero que te haya servido de ayuda toda esta información. En mi caso pude liberar un 10% de mi espacio en disco (es mucho, principalmente debido a copias de seguridad no comprimidas y archivos de gran tamaño), aunque lo más importante es que esto me permite reducir tiempo para las tareas posteriores de reorganización de los archivos existentes.

En mi opinión, lo importante es cargarse de paciencia e ir avanzando. Si no puedes cerrar la limpieza en un solo día, no pasa nada: continúa en otro momento. Lo importante es que al acabar tengas los archivos necesarios, ni más ni menos.

By

jLibrary: gestor documental open source


Enfoque de jLibrary

Según su autor, jLibrary es un gestor documental que puede ser útil tanto para uso personal como corporativo. Yo creo que como sistema de uso personal pueden existir otras soluciones más sencillas y efectivas como por ejemplo herramientas de búsqueda en el escritorio. Teniendo en cuenta que jLibrary funciona en base a repositorios, lo que se tiene es un sistema que obliga a almacenar dos copias de un mismo documento en el propio PC: El que se guarda en jLibrary, y el que se tiene en el propio sistema de directorios. A pesar de poder ser útil, quizá sea un poco excesivo.

Claro que esto es una opinión personal, porque no he instalado jLibrary en mi PC. Pero sí he instalado otras aplicaciones con intenciones similares y al final no ha resultado todo lo efectivo que desearía.

En el momento que se quiere utilizar jLibrary como herramienta de colaboración, el funcionamiento se basa en un arquitectura cliente-servidor. En el servidor se instala un repositorio, al cual los usuarios pueden tener acceder según los permisos de acceso que establezca el administrador del sistema.

A partir de ese momento, jLibrary te ofrece una serie de funcionalidades muy interesantes:

  • Si te decides utilizarlo para uso personal, puedes combinar repositorios locales y remotos.
  • Web crawling y web browsing: Almacena páginas web externas.
  • Se comunica bien con repositorios JSR-170, WebDAV, y además tiene un buen grado de interoperabilidad, porque puede incorporar Web Services, facilitando el loose coupling.
  • Categorización, metadatos, y anotaciones.
  • Gestión de versiones de documentos. Esto tiene su cara y su cruz: almacenar versiones anteriores requiere espacio adicional en disco, con lo que no está de más configurar estas opciones al gusto.
  • Un aspecto muy interesante: puedes definir relaciones entre documentos. Me parece especialmente interesante porque creo que tiene mucho sentido aportar una funcionalidad que nunca podrán aportar las herramientas de búsqueda full-text de uso general. Relacionar documentos implica establecer relaciones orgánicas y no sólo de contenido.
  • Gestión de permisos de accesos en base a roles de los usuarios

Desde luego, la mayor utilidad que le encuentro a la aplicación es implantarla en empresas con sedes geográficamente dispersas pero con gestiones compartidas entre los diferentes centros. Ni que decir tiene que cuando se va arriba y abajo, tener a mano la llave de la biblioteca de la empresa no está nada mal. Seguramente podréis echar un vistazo a los temas relativos a la seguridad.

Para ir haciendo boca, aquí pongo los enlaces a los videotutoriales que me parecen más interesantes:

También están las versiones de estos tutoriales en formato de documento.

By

Cadena trófica: Fagocitar, rumiar y digerir información


Metáfora

Sucede pocas veces, eso de salir de un examen habiendo aprendido algo sobre la materia, ¿verdad? Mientras saboreo una cerveza para celebrar el fin de curso, recuerdo el concepto que he indicado de forma totalmente espontánea, casi por serendipia.

Y es que la metáfora me ha parecido sugerente. Recuerdo hace años que alguien soltó la expresión "fagocitar apuntes". El acto de cacería que se da a final de trimestre en los pasillos de la facultad, buscando alumnos asistentes a clase con apuntes veraces y bien estructurados es un acto más bien con muchas prisas y poco criterio, una recuperación de información con tanta esperanza como poca evaluación de la relevancia. Se trata de engullir… el término fagocitar parece apropiado. Es sabido que existen verdaderos lobos depredadores que buscan gacelas rumiadoras de apuntes. Incluso hay ocasiones en las que el asalto es el propio día del examen… Uf! Que carnicería ;-).

Digerir y rumiar

Todo esto viene por lo que sugiere incorporar este concepto al tratamiento de la información. Digerir es un acto que no sólo sucede en el estómago, sino también en la cabeza. Extraer conocimiento de la información forma parte de ese proceso de di-gestión.

Por utilizar una definición informal, el proceso adquisicion de conocimiento se basa en asimilar una serie de informaciones que, combinadas con los conocimientos que tiene el individuo, permite crear un nivel de conocimiento mayor sobre el objeto estudiado. El tiempo que transcurre entre la ingestión de la información y su digestión final es un factor crítico.

En el reino animal, ese tiempo de ingestión afecta a la disponibilidad del animal para volver a correr y defenderse en condiciones. Es por eso que muchos depredadores consumen poco y a menudo: necesitan mantener su forma física para correr más que sus presas. Eso les mantiene prácticamente activos toda la jornada, como adictos. Pero no se trata de eso, sino de mantener el tono.

Las características inmateriales de la información son un factor diferencial a una cadena trófica tradicional, donde el consumo del nivel inferior coincide con la muerte de éste. Vamos que, casi que por definición, si el lobo se come el cordero, éste desaparece. En cambio, si el cordero toma apuntes y el lobo se los lee, pues aquí paz y después gloria, siempre que haya una fotocopiadora cerca.

Eso sí, hay por lo menos dos aspectos que se pueden aplicar a una ecología de la información: los diferentes roles de consumo dentro de la cadena trófica, y las características de la digestión, que pueden ser consideradas como una base para la relevancia.

Los diferentes roles que adoptan los participantes en la cadena trófica acaban desarrollando una cultura corporativa del consumo y producción de información en una organización, que es algo a tener en cuenta cuando se desarrolla una Intranet o un entorno de gestión documental. A eso respondía en el examen: me preguntaban en definitiva si montar una red social corporativa no sería intoxicar a los usuarios, y mi respuesta, en definitiva, ha sido "que coman menos y mejor", seleccionando el quién y el dónde.

Lo que pasa actualmente es que buscar información se ha convertido en algo fácil de iniciar pero difícil de finalizar, especialmente por la poca información sobre la fiabilidad las fuentes. Pero en una red corporativa, eso es factible, debido a que el dominio es mucho más limitado e incluso es fácil que los usuarios se conozcan.

No quiero profundizar más por ahora. Es un post cortito en relación a lo que acostumbro a publicar. Es intencionadamente abierto. Buscaba, más que otra cosa, sugerir ideas.

Puedes encontrar más cosas en Google sobre la ecología de la información. Podrás encontrar entradas en el profesional de la información y otros sitios, con diferencias de significado respecto a lo que yo comento (esencialmente, la ecología en la producción de contenidos, o en su consumo).

By

Google Mashups: El contraataque a Yahoo! Pipes


Parecidos razonables, diferencias significativas

Google Mashups recoge mucha parte de la filosofía de su marca madre: un entorno sencillo (y mucho más ligero que el entorno de Pipes), ágil, y con un enfoque que busca más la complicidad de los desarrolladores. En esencia, no se trata de un editor visual que permite combinar y enlazar cajas como lo hace Yahoo!, sino de programar mediante el lenguaje de marcado del propio del sistema.

Lo que es interesante, es que el lenguaje de marcado utiliza tags XHTML para el diseño de la interficie de uso, y la interacción y gestión de eventos propios de Javascript. En resumen, me recuerda muchísimo al XUL de Mozilla o al MXML de Flash-Flex. No son los únicos lenguajes de marcado para interficies, aunque son los que conozco.

Por lo tanto, en lo referente a forma de uso, Google Mashups parece dirigirse a usuarios con más habilidad para la programación utilizando XML, Javascript y CSS, mientras que Yahoo! Pipes deja de lado todos los aspectos relacionados con el diseño de la interacción con el usuario, resumiendo la salida a un RSS.

En el capítulo de parecidos, las fuentes de datos son las que proporciona Internet: resultados de búsqueda, RSS y demás fuentes estructuradas. Google ha hecho lo mismo que hizo Yahoo! pero con sus correspondientes servicios: ha integrado su calendario y sus tareas, y los mapas. Eso en esencia no es muy diferente de lo que proporciona Yahoo!, pero desde luego potencia mucho la integración para alguien que no quiera pelearse con las APIs: hay que pensar que el XML, a pesar de ser algo árido para quien no esté acostumbrado, es mucho más fácil de tratar que el código a pelo.

Funcionamiento de Google Mashups: un ejemplo sencillo

Del mismo modo que ya hice con Yahoo! Pipes (o Y!P), voy a hacer un pequeño ejemplo con Google Mashups. El ejemplo incluirá los RSS, que es lo que más me atrae, pero trataré de utilizar otros servicios. Para empezar, accedemos al editor de Google Mashups. El entorno se puede ver en la siguiente imagen:

Vemos tres pestañas, que presentan el editor del mashup, el editor de feeds y el entorno de ejecución de prueba (Sí, ya sé que es una forma de indicar que se trata de un entorno de pruebas seguro, pero anda que llamarse Sandbox tratándose de Google…).

Empiezo echando un vistazo al lenguaje de referencia de Google Mashups, y la primera impresión que recibo es que se han esforzado en integrar las propias herramientas, pero que han aportado pocos sistemas de tratamiento de los datos, como por ejemplo lo proporcionan las cañerías de la competencia. Eso es un punto en contra para referencistas y documentalistas en general, aunque es un guiño a los programadores, que podrán echar mano de bibliotecas de Javascript y otras historias para aplicar tratamientos sobre los datos.

Como ejemplo, empiezo desarrollando un grupo de dos pestañas, que se desarrollan utilizando una combinación de las etiquetas gm:tabs (el grupo de pestañas), gm:container (una pestaña concreta) y el contenido que corresponda. Las pestañas tendrán el siguiente contenido:

  • Pestaña 1: Un feed.
  • Pestaña 2: Un calendario.

Para cuando empiezo con la pestaña de los feeds, ya echo en falta algo: la capacidad de agregación, filtro y ordenación que tenía Y!P. Lo que son las cosas, utilizo la documentapipe que desarrolló Beukis utilizando la herramienta de Yahoo!

Esto permite poner la pipe dentro de un contenedor (que a su vez irá dentro de una gm:section y de un gm:tab, como veremos después).

En la segunda pestaña, pongo un calendario, utilizando uno de los feeds de los calendarios de muestra que encuentro en la beta cerrada. Se puede ver en la URL que es posible indicar el orden de las entradas indicando los parámetros orderby y sortorder. Es de suponer que con estos recursos y otros que de momento no he encontrado, es posible aplicar algunos criterios más de organización de los datos.

Con esta combinación, el código fuente final del mashup es:

resultado del mashup

y el resultado:

Demo sandbox

Consideraciones finales

Con los dos servicios conseguiríamos un backend genial. Por ejemplo, echo en falta que en Google Calendar no se puedan mostrar los datos de los feeds agrupados por fechas. Eso permitiría conjugar, por ejemplo, los posts de este blog con los posts de otros blogs interesantes, para poder contextualizar mis informaciones. Si un feed lleva su fecha eso permitiría utilizarlo en un calendario, no?

En el capítulo beta-testing, la herramienta es ligera… pero no guarda los proyectos, con lo que las capturas que he puesto aquí son lo único disponible a fecha de hoy. Como en el caso de Y!P, los mashups pueden ser publicados, por lo que es de esperar que vayan surgiendo. También pueden ser definido como gadgets, pero eso ya es otro cantar.

La combinación de ambos servicios es interesante:

  • Y!P se caracteriza por un buen backend de agregación de contenidos que da como salida un grupo estructuralmente homogéneo de datos, en formato RSS. Cabe pensar que una combinación inteligente del lenguaje XML y el uso de enlaces nos proporciona un sistema muy ágil de interrelación de la información.
  • GM proporciona una interficie de presentación de los datos. La pena es que para ir más a fondo tenga uno que meterse a programar, que no deja de ser un cambio de mentalidad, y por lo tanto un enfoque de trabajo más planificado.

No se hacen sombra la una a la otra. Lo que sí proporcionan es una visión de hacia dónde va cada servicio. Es de esperar que ambas empresas continuen su progresiva evolución en el lanzamiento de servicios.

Y para acabar, sólo un apunte más: RSS es el presente y el futuro. Eso y los microformatos en general permitirán la progresiva dispersión de las redes sociales, que ya todo el mundo se empieza a oler, por aquello de "Tú haces todo el trabajo, ellos se quedan la pasta".

By

La veracidad de la información en Internet, a debate

Otro de los focos de polémica que he leído esta semana me ha llegado desde Apophenia, el blog de Danah Boyd, (muy recomendable para todos los aspectos relacionados con comunidades virtuales: vale la pena echar un vistazo a su listado de publicaciones y papers), que actualmente trabaja en Yahoo! y se encuentra muy implicada en los fenómenos Friendster y MySpace.

En su blog, Danah comenta un comentario de Michael Gorman, nada más y nada menos que el presidente de la American Library Association en los años 2005-2006, y primer editor de las AACR en 1978 (así que este es el responsable…). Los comentarios que hace McGorman son:

  • The sleep of reason, (parte I, parte II): Donde McGorman equipara los sueños de la razón de Goya a lo que sucede en Internet, argumentando sobre la falta de calidad de los procesos de producción electrónica actuales, y afirmando que lo necesario no es tanto el seguir manteniendo las publicaciones en papel, sino el incorporar en los procesos de publicación en Internet los criterios de fiabilidad del mundo editorial tradicional.
  • The siren song of the Internet (parte I, parte II): Expone cómo la sencillez de uso de herramientas como Google están dejando de lado aspectos importantes relativos a la propiedad intelectual, plagio, y a la mediocridad por el hecho de descartar todo aquello que no tiene un buen ranking en los resultados de búsqueda.
  • Jabberwiki, the educational response, (part I, part II): Comenta la relación entre los profesionales de la educación y su rigor o permisividad en el uso de fuentes de información, y la introducción de hábitos de búsqueda de información que incluyan recursos más especializados.

Los comentarios de los artículos son mucho más cortos de lo que merecería un buen resumen, pero no tenía esta intención, sino situar la respuesta de Danah Boyd, que no tiene pelos en la lengua. Resumiendo:

  • Empieza expresando su frustración por lo que su vida académica le ha acabado demostrando: que no todo catedrático o miembro de la comunidad académica es todo lo competente que se puede esperar. Ello incluye una crítica a la opinión que la cultura americana es meritocrática (en su opinión, no lo es).
  • Reconoce su pasión por Wikipedia, el placer que le supone hallar buenos artículos, y en especial la auto-aceptación del sitio en cuanto que está en continua evolución.
  • Argumenta que la información no puede ser congelada y servida para el consumo, tal como han tratado de defender las entidades editoriales.
  • También discute la figura de autoridad de publicación (quién decide qué, cómo y cuándo se publica).
  • Matiza en las razones del cambio: Internet es un medio, como el papel. Y por lo tanto es posible escribir basura tanto en Internet como en el papel. Lo que cambia son los criterios de producción y distribución, [y que eso es algo que no gusta a la industria editorial: no es una afirmación literal, sino un interpretación mía].
  • Concluye preguntándose el por qué todos los intelectuales que critican la Wikipedia no se ponen manos a la obra para mejorarla. También se pregunta cuáles son las razones por las que no se explica la dinámica de un sistema de colaboración tan amplio.

El debate de la producción de contenidos

Como se ve, lo que por un lado se interpreta como el problema de la autoridad, por el otro se enfoca como una cuestión de poder de decisión en la publicación. Es un debate que entra de lleno en el derecho de copyright, el control bibliográfico, la producción y distribución, ISBN, IBSN, DOI,…

Personalmente estoy del lado de Danah Boyd. Me pregunto qué pasaría si yo quisiera publicar lo que he puesto aquí. En el fondo cada cual es libre de leerlo. Por las estadísticas de clicks y demás, veo claro que muchas veces se hace más uso a los enlaces que pongo a lo largo del texto, que al contenido en sí.

Pero eso no me preocupa: en esencia este blog es mi aportación, y como muchas publicaciones, puede quedarse aparcada. La diferencia es que en cualquier momento del día alguien puede hacer uso de esto. Sé que si alguien quiere profundizar el el tema que propongo, puede buscar en otra parte. Si algún día quiero publicar en una revista especializada, trataré de cumplir los criterios de calidad que me establezcan. La diferencia entre uno y otro no es la implicación por redactar algo bueno, sino los criterios de consenso para acceder a este documento.

Quizá porque en los últimos tiempos se ha visto triunfar el movimiento del software de código abierto, no hay que dejar pasar que la publicación tiene un coste. La Budapest Open Access Initiative lo deja muy claro: investigar y publicar cuesta tiempo y dinero, con lo que si no cobras al lector final de tu publicación, deberás buscar ingresos por otro lado. O eso, o te dedicas en tu tiempo libre.

En el momento de decidirse a publicar, la diferencia entre el control editorial y la no intermediación pasa por la disponibilidad y accesibilidad al documento: ¿tu blog estará siempre disponible? ¿Un artículo, tendrá siempre un mismo enlace? ¿Y las modificaciones?

Cuando se desea recibir una retribución por esta publicación y se quiere descartar todos los aspectos técnicos, lo mejor es delegar en terceros, sabiendo que probablemente se verificará la calidad del contenido. Décadas atrás, publicar autónomamente era impensable, y por eso el esfuerzo del peer reviewing, el editor y todo lo demás era un trámite para aumentar la visibilidad, pero hoy ya no necesariamente es así.

Identidad, referencia y fiabilidad

Google acertó en el Pagerank, no sólo por sus características matemáticas, sino porque explicita las relaciones de recomendación. El PR da autoridad a los sitios que reciben muchos enlaces: todo el mundo los conoce, y por ello se dan por buenos. En esa época, referencia podía equivaler a identidad.

A pesar de ello, Google apareció en una época en la que los weblogs eran un fenómeno prácticamente inexistente, y que los procesos de publicación aún pasaban por los grandes portales e ISPs, proveedores tradicionales de contenidos que iniciaban sus versiones electrónicas, y poca cosa más. En esa época el motivo de enlace no era significativamente diferente a los que introdujo la web social, pero el criterio estaba bajo un control editorial más tradicional.

Ahora esto ha cambiado, y el software social ha implicado mayor dispersión en la capacidad productiva de contenidos, mayor acceso por parte del público a recursos electrónicos (gratuítos, se entiende) y un alto ritmo de producción. Junto a esto, han aparecido sistemas de indexación no controlados que han introducido la visión personal en la organización de contenidos. Eso no es asimilable directamente por el PR, ya que no se basa en contenidos ni enlaces.

Y es por eso que ahora cabe esperar que la siguiente vuelta de tuerca la den las redes sociales, los microformatos y otros tipos de comunidades y sistemas estructurados de intercambio de información: toda la actividad que se lleve a cabo por usuarios podrá ser estudiada para extraer la relevancia con un valor más personalizado.

Mientras este momento no llega, Google trata de almacenar tanta información como puede sobre los usuarios, aunque desde mi visión más personal, creo que esta información es valiosa para extraer patrones, pero no es la clave para encontrar más productos de éxito.

Por hoy basta, espero que la larga lectura sea a amena y enriquecedora. Creedme si os digo que soy yo quien escribe ;-)