Visuse: un meta-buscador visual

José Luis López Pino

4 de julio de 2010

Tutor: Juan Julián Merelo Guervós

Índice general

1. Introducción 4

2. De�nición de objetivos y especi�caciones 5

2.1. Estado del arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.1. Proyectos similares . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.2. Distribución de imágenes . . . . . . . . . . . . . . . . . . . . . . . 6

2.2. ¾Buscador o meta-buscador? . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4. Especi�caciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.5. Software y documentación libre . . . . . . . . . . . . . . . . . . . . . . . . 8

3. Desarrollo del proyecto propiamente dicho 10

3.1. Descripción del funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . 103.2. Herramientas y tecnologías utilizadas . . . . . . . . . . . . . . . . . . . . . 10

3.2.1. Del lado del cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2.2. Del lado del servidor . . . . . . . . . . . . . . . . . . . . . . . . . . 123.2.3. Comunicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.3. Módulos para búsquedas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.3.1. Desarrollo de un módulo . . . . . . . . . . . . . . . . . . . . . . . . 143.3.2. Estructura de un módulo . . . . . . . . . . . . . . . . . . . . . . . 143.3.3. Puntuación de resultados . . . . . . . . . . . . . . . . . . . . . . . 153.3.4. Módulos desarrollados . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.4. Visualización de los resultados . . . . . . . . . . . . . . . . . . . . . . . . . 163.5. Carga de los resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.6. Determinar la posición de los resultados . . . . . . . . . . . . . . . . . . . 18

3.6.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.6.2. Algoritmo voraz utilizado . . . . . . . . . . . . . . . . . . . . . . . 183.6.3. Aplicación del enfriamiento simulado . . . . . . . . . . . . . . . . . 20

3.7. Comunicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4. Evaluación y conclusiones 23

4.1. Evaluación de la disposición de imágenes . . . . . . . . . . . . . . . . . . . 234.2. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

A. Instrucciones de utilización 28

B. Dependencias de los módulos 29

2

Índice general

Bibliografía 30

3

1. Introducción

Visuse es un acrónimo de VISUal Search Engine, ya que el proyecto consiste en unmeta-buscador que clasi�ca y muestra los resultados obtenidos de distintos buscadoresy sitios web de forma visual, centrándose sobre todo en contenidos multimedia comoimágenes, vídeo y audio.La forma de mostrar los resultados de muchos servicios de búsqueda no permiten

buscar diversos contenidos al mismo tiempo y ofrecen una navegación incómoda paravisualizarlos. Mostrar los resultados de una forma visual aprovechando la totalidad de lapantalla resulta más cómodo para los usuarios, además de resultar muy útil para niños,personas que tengan problemas para leer, personas con un bajo nivel de alfabetización odispositivos en los que sea incómodo leer.El desarrollo del proyecto tiene dos partes principales: el desarrollo de la parte del

servidor, que se comunica con los buscadores para trabajar con los resultados, y la partedel cliente, que se encarga de la visualización de dichos resultados.

4

2. De�nición de objetivos yespeci�caciones

2.1. Estado del arte

2.1.1. Proyectos similares

Si consultamos cualquier lista de sitios más visitados de la red, encontramos que laclasi�cación está encabezada por buscadores, redes sociales y sitios de contenidos multi-media tal y como se puede apreciar en http://www.alexa.com/topsites. Los buscadoresllevan indexando la red y ayudando a los usuarios a encontrar recursos desde 1993 y enla última década, ayudado por el aumento de la velocidad de acceso de los usuarios, loscontenidos multimedia han inundado la red.Es lógico que en todo este tiempo hayan surgido distintos buscadores especializados

en contenidos multimedia y los buscadores tradicionales también hayan desarrollados susversiones centradas en dichos contenidos. Sin embargo, estos buscadores siguen mostrandolos resultados de forma similar a los resultados de texto, organizándolos en páginas conmuy pocos resultados y añadiéndoles pequeños thumbnails, haciendo la búsqueda delusuario lenta e incómoda.Recientemente ha habido algunos intentos para mejorar estas interfaces:

El buscador Bing añadió un servicio llamado Visual Search (http://www.bing.com/visualsearch), cuyo objetivo es sustituir las tradicionales búsquedas de tex-to por búsquedas a través de imágenes clasi�cadas en categorías y subcategorías,para ello diseñaron una nueva interfaz utilizando Silverlight. Sin embargo, el obje-tivo de este servicio no es encontrar imágenes u otros contenidos multimedia, sinoreemplazar las tradicionales búsquedas de texto por otras visuales.

oSkope (http://www.oskope.com/) por su parte es otro buscador que permite,mediante Flash, visualizar de distintas maneras los resultados de otros buscadorescomo Google Images o Youtube. Sus principales desventajas son que no nos per-mite combinar los resultados de distintos buscadores, no ordena por puntuaciónlos resultados en el mural y no permite visualizar los contenidos multimedia en elpropio buscador.

El servicio Spezify (http://spezify.com/) sí que permite combinar resultados dedistintos buscadores multimedia y visualizarlos en el propio buscador, sin embargo,no realiza ninguna ordenación según la importancia de los resultados y su distri-bución en un gran mural por el que tenemos que ir desplazándonos y en el que haygrandes huecos; todo esto hace muy difícil encontrar los resultados que deseamos.

5

2. De�nición de objetivos y especi�caciones

Como se puede apreciar, ninguno de los buscadores existentes ha trabajado la disposiciónde las imágenes en función de su importancia ni la disposición óptima de los resultadospara formar un muro que no desaproveche espacios.

2.1.2. Distribución de imágenes

Ha habido múltiples intentos para conseguir una distribución óptima de elementossobre una página, problema que se conoce como 'layout optimization' (optimización dela distribución). Sin embargo, como veremos, ninguno es igual al que en este proyecto hetratado.En 1979, Daniel Selator[13] ya se planteaba un problema similar, al que llamaba 'pac-

kage in two dimensions' (empaquetamiento en dos dimensiones), utilizando un inteligentemétodo que consistía en colocar primero las piezas más grandes.Existen diversos trabajos que plantean el mismo problema con la intención de aplicarlo

a periódicos y anuncios. En todos estos casos se ciñen a la estructura de columnas y lostamaños de los anuncios no eran modi�cables, lo que no sucede en este proyecto:

Ramesh Johari y otros (1997)[10] aplicaron enfriamiento simulado para resolver elproblema de la colocación de anuncios en las guías telefónicas.

J. González y J. J. Merelo[4] también aplican enfriamiento simulado para buscarla mejor distribución de artículos en un periódico web, intentando minimizar eltamaño medio de los huecos.

Charles Jacobs y otros[9] utilizan diseños basados en rejilla para optimizar la dis-posición en periódicos y revistas.

Más recientemente, en 2007, Gen Hattori y otros[6] aplican los mismos conceptosa la adaptación de sitios web para dispositivos móviles.

En 2001 Joe Geigel y Alexander Loui[2] utilizan algoritmos genéticos para realizar ladistribución automática de un álbum de imágenes. Sin embargo, ellos intentaba optimizarel diseño de la página y permitían transformaciones como rotaciones en las imágenes ydebían estudiar la superposición de las imágenes.Analizando todos los trabajos anteriores, nuestro problema tiene dos características

que lo hacen exclusivo: la posibilidad de redimensionar los contenidos pero respetandolas proporciones de la imagen y la necesidad de que tengan tamaños distintos en funciónde su importancia. Además también hay que intentar que no haya superposición deimágenes o que sea mínima.

2.2. ¾Buscador o meta-buscador?

Un meta-buscador es un buscador que, en vez de indexar contenidos, realiza consultasa otros buscadores y los clasi�ca y muestra como una única lista (en el caso de Visuse,de forma visual), lo cual tiene distintas ventajas y desventajas.

6

2. De�nición de objetivos y especi�caciones

Un meta-buscador permite al usuario obtener los resultados de distintos buscadoresde una forma homogénea, sin tener que acceder independientemente a cada uno de losbuscadores y disponiendo de esa forma de un número mayor de resultados con una únicabúsqueda. Desde el punto de vista del administrador también es muy cómodo, ya que esmuy difícil indexar la web, que se expande a un ritmo enorme, y que supone desarrollar ymantener una gran cantidad de software, desarrollar una araña web (o web crawler) queinspeccione la web repetitivamente, evitar técnicas poco éticas usadas por algunos desa-rrolladores como el cloaking, el espacio de almacenamiento para las páginas indexadas,etc.Por otra parte, desde el punto de vista del administrador del buscador supone otra serie

de problemas, muchos de ellos debidos a las restricciones que ponen los buscadores queincorporemos: no podemos personalizar y elegir la información con la que trabajamos,podemos ser bloqueados indiscriminadamente por los buscadores, hemos de cumplir laslimitaciones que ellos nos imponen, debemos cachear resultados para que no ocurra loanterior, tenemos que lidiar con distintos sistemas de comunicación para cada uno delos buscadores, la homogeneizar la información recibida puede ser difícil, tenemos que�ltrar o gestionar los operadores utilizados por los distintos buscadores (+, and, or,site: ), nos genera una gran cantidad de consultas salientes de las que debemos obtenerrespuesta de una forma rápida, etc. Sin embargo, un meta-buscador no supone ningunadesventaja para el usuario, excepto que en ocasiones puede resultar un poco más lentoque un buscador normal.La decisión tomada tras evaluar las ventajas y desventajas de las dos opciones fue

desarrollar un meta-buscador, esto es debido a que se pueden obtener resultados másrápidamente para poder desarrollar también el el front-end de la aplicación (las consultasal buscador, la organización de resultados, la visualización de resultados, etc.).Sin embargo, aunque el desarrollo del proyecto incluye un meta buscador con distintos

sistemas de búsqueda, el front-end de la aplicación no depende de él en absoluto y puedeser fácilmente adaptado para trabajar con un buscador corriente.

2.3. Objetivos

En primer lugar se debe lograr la intercomunicación con los distintos buscadores paraobtener los resultados relacionados con la búsqueda, para lograr este objetivo se handesarrollado diversos módulos que se encargan de la comunicación de un buscador, debidoa la heterogeneidad de formas a los resultados que nos imponen los distintos buscadores.En segundo lugar se encuentra la organización de la información proveniente de los

buscadores. Cada buscador nos facilita ciertas informaciones básicas de los resultadoscomunes a todos como la dirección donde se encuentra el recurso o especí�cos del tipode resultado como un thumbnail en el caso de imágenes, además de otra informaciónheterogénea en función del buscador con que estemos trabajando que es importanteobtener y almacenar para tener más criterios con los que organizar los resultados.También son objetivos del proyecto la puntuación de los distintos resultados que, como

comentamos, dependerá de la información que nos facilite el buscador del que procede y

7

2. De�nición de objetivos y especi�caciones

deberán establecerse los criterios con cuidado para conseguir una visualización interesantepara los usuarios, premiando los resultados más relevantes en función principalmente desu relación con la búsqueda y castigando aquellos que no estén relacionados.Una vez obtenidos los resultados y estando estos organizados y puntuados es el momen-

to de realizar la mejor visualización para dichos resultados, siendo importante mostrarprimero y en mayor tamaño los resultados mejor puntuados y al mismo tiempo intentandodejar el mínimo de huecos posibles.

2.4. Especi�caciones

Una vez establecidos unos objetivos claro para el proyecto, era necesario también es-tablecer una serie de especi�caciones que se respetasen durante la consecución de estos.Una necesidad básica es intentar que funcione en la mayor cantidad de navegadores

posible, aunque esto para el desarrollador web siempre supone un compromiso entre crearaplicaciones que funcionen en navegadores obsoletos tecnológicamente o utilizar nuevaspropiedades y tecnologías que permiten crear mejores aplicaciones con impresionantesfuncionalidades (como HTML5).En la parte de la visualización de resultados, también resulta indispensable que éstos

sean mostrados adecuándose a las dimensiones de la ventana del navegador con la queel usuario está visitando el sitio web, ya que todos los navegadores nos facilitan estainformación y debemos adaptarnos al máximo a la heterogeneidad de resoluciones quehoy en día utilizan los usuarios, cada vez más grandes en los equipos de escritorio y almismo tiempo cada vez en pantallas más pequeñas con la proliferación de dispositivosmóviles. Por contra, esto nos supone la imposibilidad de almacenar (cachear) la formade disposición de los resultados, ya que será distinta para cada usuario.Por otra parte, la visualización de los resultados también tiene que ser rápida. La carga

de muchos recursos es lenta, pero no podemos tener al usuario esperando a que carguentodos los recursos para que pueda navegar, debemos intentar que carguen y que seanusables por el visitante lo antes posible.Por último, los buscadores y las formas de comunicación que ponen a disposición

de los desarrolladores cambian rápidamente, por lo que también es necesaria la fácilextensión mediante módulos que se encarguen de obtener y puntuar los resultados de unbuscador. De esta forma, cualquier persona con bajos conocimientos sobre cómo funcionala aplicación puede ampliar la cantidad de resultados ofrecida de una forma sencillaincorporando nuevos buscadores o actualizando los existentes.

2.5. Software y documentación libre

Todo el software desarrollado está liberado, bajo la licencia GPLv3[1], al igual quetoda la documentación sobre este proyecto. Esto signi�ca que cualquiera puede usarlopara cualquier propósito, compartirlo, estudiar su funcionamiento, modi�carlo y com-partir esas modi�caciones. Pero el software libre no signi�ca únicamente una serie de

8

2. De�nición de objetivos y especi�caciones

libertades para el usuario, también es bene�cioso para el propio proyecto: recibe visibi-lidad (publicidad), logra mejoras gracias a la retroalimentación de los usuarios y recibela colaboración de otros usuarios.La liberación del software y la documentación también permite la transferencia de

conocimientos y la innovación tecnológica, haciendo que el proyecto no quede estancadouna vez que �nalice, sino que pueda servir para cubrir futuras necesidades continuan-do su desarrollo o integrándose en el de otro proyecto. Este proyecto, además, se basacompletamente en estándares abiertos y herramientas libres, por lo que es también unaobligación moral devolver a la comunidad lo recibido, además de que algunas licenciasobligan a liberar los desarrollos derivados.El proyecto no ha sido únicamente liberado, sino que ha sido desarrollado en un proce-

so completamente abierto, siendo accesibles todos los avances del desarrollo en una forja(https://forja.rediris.es/projects/cusl4-visuse/) y publicando información so-bre él en un blog. El desarrollo ha permitido también la colaboración de los usuariosmediante el envío de sugerencias de mejoras y errores.Por último, el proyecto ha participado Concurso Universitario de Software Libre (http:

//www.concursosoftwarelibre.org) en el que ha recibido el 2º premio al Mejor Proyec-to Comunidad en el concurso nacional y Premio a la Difusión en el concurso granadino.

9

3. Desarrollo del proyecto propiamentedicho

3.1. Descripción del funcionamiento

El proyecto cuenta con dos partes claramente diferenciadas pero que deben estar per-fectamente comunicadas: un back-end que se encarga de obtener los resultados de losdistintos buscadores, organizarlos, puntuarlos y servirlos y un front-end (con el que in-teractúa el usuario) encargado de obtener dichos resultados, determinar cual es la mejordisposición posible a realizar y mostrarlos al usuario.Cuando el usuario indica al front-end que desea realizar la búsqueda de unos determi-

nados términos al usuario, éste realiza consultas asíncronas (tecnología conocida comoAJAX) que consisten en peticiones HTTP corrientes, una por cada buscador, y que recibeel back-end. Esta parte se encarga de retransmitir esa petición a los distintos buscadorespara obtener los resultados de clasi�cará y puntuará, devolviendo al front-end los resul-tados procesados de cada buscador en cada una de las peticiones. Se realiza el proceso depetición-respuesta utilizando JSON en distintas peticiones HTTP para que los buscado-res más lentos no provoquen que los resultados de los más rápidos se demoren en llegary se puedan devolver códigos de error cuando se produzcan errores en la obtención o elprocesamiento de los resultados de uno de los buscadores.Cuando el front-end recibe los resultados pasa a procesarlos, para lo cual los organiza

por importancia y determina la mejor forma de mostrarlos en función de la importanciade ellos e intentando dejar la menor cantidad de huecos en la pantalla. La ejecución deesta parte es particularmente importante, ya que los usuarios necesitan que se les empiecea mostrar la información lo más rápido posible, aunque aún no estén disponibles todoslos resultados o no sea óptima su disposición en la pantalla.

3.2. Herramientas y tecnologías utilizadas

Las herramientas y tecnologías escogidas para el desarrollo de un proyecto deben serescogidas cautelosamente, ya que pueden suponer el fracaso de éste o pueden aumentarsu complejidad, para lo cual deberemos conocer cuales son las distintas alternativas y lasnecesidades de nuestro proyecto. Además todas las tecnologías son libres y compatiblescon la licencia escogida para liberar el proyecto.

10

3. Desarrollo del proyecto propiamente dicho

Figura 3.1.1.: Ilustración del funcionamiento del proyecto

3.2.1. Del lado del cliente

En cuanto a ejecución de código en el navegador del usuario para determinar la dispo-sición de los resultados, las alternativas son básicamente dos: utilizar código JavaScripto una aplicación utilizando la tecnología de Adobe Flash. La primera alternativa estáhoy presente en la práctica totalidad de las navegadores y, aunque hay problemas porlas diferencias entre los distintos intérpretes, existe cierto grado de estandarización. Lasegunda nos permitiría evitar esas diferencias de ejecución en los distintos navegadoressi utilizamos la implementación o�cial, sin embargo las aplicaciones Flash son pesadasde cargar, su tecnología es privativa (lo que va en contra de la naturaleza abierta de laweb) y obligan al usuario a instalar un complemento a su navegador que muchas veces noestá disponible en todos los navegadores (como pasa en los de los dispositivos móviles).Iguales problemas que Flash presenta la tecnología Silverlight de Microsoft y además lacuota de navegadores en la que está presente es muy baja.Debido a la falta de estándar de JavaScript/ECMAScript es aconsejable la utilización

de una biblioteca que nos permita no tener que preocuparnos porque nuestros desarrollosse ejecuten de formas distintas en los diferentes navegadores. Además la utilización degrandes bibliotecas o framework simpli�can la manipulación del DOM (Documment Ob-ject Model), el tratamiento de eventos y la comunicación asíncrona. Dentro de la ampliavariedad de bibliotecas para JavaScript disponibles me decanté por el uso de jQuery porsu velocidad y simplicidad, porque tiene una baja curva de aprendizaje y cuenta conuna excelente documentación y porque pone a nuestra disposición una gran cantidad de

11

3. Desarrollo del proyecto propiamente dicho

extensiones.A la hora de hacer la disposición de resultados en la pantalla, una vez descartada la

tecnología Adobe Flash y Microsoft Silverlight por las razones comentadas, nos quedanbásicamente dos alternativas: la utilización de XHTML/HTML o de HTML5[7]. Paradisponer imágenes en un punto concreto de la página es su�ciente con la utilización deHTML en combinación con hojas de estilos indicando a las imágenes que se sitúen enposiciones absolutas, aunque sería más complicado lograr complejos efectos de animación(aunque no imposible, utilizándolo en combinación con JavaScript). En cambio, HTML5es aún un borrador, no aportaría demasiadas funcionalidades (únicamente la inclusión deefectos bonitos con la utilización del elemento canvas) y está aún en proceso de implan-tación, sólo disponible en las últimas versiones de los distintos navegadores y en algunoscasos parcialmente.

3.2.2. Del lado del servidor

Del lado del servidor, se eligió como lenguaje de programación Python debido a quese trata lenguaje de alto nivel que sin embargo no se puede considerar lento y que tieneuna importante presencia entre las aplicaciones web debido a su velocidad y la facilidadpara desarrollar en él. Además genera un código fácil de leer y su biblioteca estándarmuy completa, siéndome especialmente útil en la serialización de los objetos en JSON,mediante la biblioteca jsonpickle, para transmitirlos al lado del servidor.En comparación con otros framework, con Django es fácil desarrollar código más man-

tenible, nos facilita el manejo de los datos y su migración, está muy bien documentado,goza de una gran popularidad y está apoyado por una importante comunidad .[12]Además, Django[8] nos permite:

Rápida creación de sitios web complejos.

Fácil empleo del patrón M.V.C.

Desarrollo de sitios con estructuras modulares.

Uso simple de plantillas.

Fácil gestión de los accesos a bases de datos.

Creación de direcciones amigables.

Uso de cachés.

Utilización simple de extensiones.

3.2.3. Comunicación

En la comunicación, como se ha comentado, se hace uso de JSON (JavaScript ObjectNotation), un formato ligero para el intercambio de datos, frente a su principal alternativaXML[5], un lenguaje de marcado de propósito general. La elección de JSON se debe a la

12

3. Desarrollo del proyecto propiamente dicho

velocidad en que se procesa en JavaScript, a que resulta muy simple tanto para humanoscomo para máquinas, a que está orientado a las estructuras de datos de los lenguajes deprogramación modernos y a que no necesitamos la validación mediante esquemas de lasrespuestas.Realmente esta decisión no supone un gran compromiso, con unas simples modi�ca-

ciones la comunicación se podría realizar utilizando XML sin afectar a las dos partesinvolucradas en la comunicación.

Figura 3.2.1.: Ilustración resumen de las tecnologías utilizadas

3.3. Módulos para búsquedas

La estructura de módulos ha tenido que ser reestructurada en dos ocasiones, con el ob-jetivo de reorganizar cierta información, facilitar las pruebas sobre los módulos y facilitarla extensibilidad de la aplicación. El resultado �nal utiliza las herramientas facilitadaspor la programación orientada a objetos para crear un diseño de clases que se ajusteadecuadamente a las necesidades de organización de la información.La estructuración propuesta también mantiene la con�guración de los módulos sepa-

13

3. Desarrollo del proyecto propiamente dicho

rada de la lógica de funcionamiento de ellos, para que el servidor pueda ser administradopor cualquier persona sin que conozca el funcionamiento interno de los módulos. Lacon�guración de los módulos permite administrar aspectos como los módulos en funcio-namiento, las claves exigidas por algunos motores de búsqueda para realizar las consultaso el número de resultados obtenidos por cada buscador.Las pruebas desarrolladas se apoyan en el sistema de pruebas facilitado por Django

para simular peticiones a todos los módulos y comprobar que todos devuelven un códigode estado correcto.

3.3.1. Desarrollo de un módulo

El funcionamiento de un módulo consiste en cuatro sencillo pasos:

1. Obtener los datos del buscador (usando XML, JSON o lo que corresponda).

2. Crear una instancia de la clase por cada resultado.

3. Creamos una lista de resultados.

4. Establecer la puntuación de cada uno de los resultados.

Pero previamente al desarrollo del módulo, se debe encontrar la forma de comunicarsecon el buscador deseados, lo cual suele ser una tarea ardua debido a que los buscadoresimponen fuertes restricciones al uso de sus servicios y en algunas ocasiones ni ofreceneste servicio. Servicios de búsqueda como Bing no permiten que se mezclen sus resultadoscon los de otros buscadores y otros como Yahoo anuncian que la utilización de este tipode servicios pronto pasará a ser de pago. También suelen requerir que nos registremosen sus sitios como desarrolladores para facilitarlos una clave que deberemos incluir ensus descargas, e incluso algunos como el buscador del servicio de vídeos Vimeo requierela identi�cación de un usuario, aunque sea empleando el protocolo OAuth que evita quetengamos que facilitar nuestra contraseña.Una vez conseguida la forma de comunicarnos con el buscador, debemos considerar

los datos que nos facilitan, como mínimo debemos tener la dirección al recursos y unthumbnail para poder mostrarlo.

3.3.2. Estructura de un módulo

Cada módulo debe contener dos clases: una que almacena la la información relevantede los resultados obtenidos y otra que se encarga de realizar la búsqueda.La clase que almacena la información de los resultados obtenidos hereda de la super-

clase Result y si se trata de un resultado visual, también de ImageResult. Esta clasecontiene un constructor (__init__ en Python) que inicializa las variables y otra querealiza la estimación de a puntuación del resultado, para lo cual recibe como parámetroel término de búsqueda introducido.La clase que realiza la búsqueda hereda de SearchModule e implementa dos métodos

básicos: uno que realiza la comunicación para obtener los resultados del buscador y otro

14

3. Desarrollo del proyecto propiamente dicho

que obtiene los atributos correspondientes de un resultado y crea con ellos una instanciade la clase anteriormente descrita.Si hay algún parámetro de la búsqueda que debe ser con�gurable, debe ser declarado

en el �chero con�g.py. Para que los resultados del módulo desarrollado sean accesiblesúnicamente hay que añadir el nombre del módulo al diccionario de módulos de dicho�chero.

Figura 3.3.1.: Jerarquía de clases usando como ejemplo el módulo para Youtube

3.3.3. Puntuación de resultados

También es interesante obtener datos adicionales que nos permitan puntuar los resulta-dos de los módulos., como el título del recurso, la descripción, las etiquetas, el número deusuarios que lo han guardado como favorito, el número de visualizaciones o la puntuaciónque le dan a los usuarios.Una vez obtenida toda la información posible para puntuar los módulos debemos rea-

lizar una cali�cación entre 0 y 1 en la que 1 supondrá gran importancia y 0 muy bajaimportancia. Un sistema simple para evaluar la similitud entre dos textos es el métodoSequenceMatcher de la biblioteca de Python di�ib, que establece un valor también entre0 y 1 en función de la coincidencia entre dos cadenas de texto.A pesar de basarnos en distintos criterios, debemos intentar que los resultados homo-

géneos con el resto de módulos para que no sean castigados o premiados los resultadossimplemente por ser facilitados por un buscador. Si no tenemos criterios o provisional-mente no hemos desarrollado la puntuación, el módulo automáticamente heredará elmétodo de puntuación contenido por la superclase que dará una puntuación mínima alrecurso.Un ejemplo de puntuación puede ser el utilizado para el módulo de búsquedas en

15

3. Desarrollo del proyecto propiamente dicho

Youtube: se le asigna un valor entre 0 y 1 en función de la coincidencia de los términosde búsqueda introducidos con el título del vídeo y además un 0.2 más en función de lapuntuación de los usuarios y un 0.2 más según el número de visualizaciones del vídeo.

3.3.4. Módulos desarrollados

El proyecto cuenta con seis módulos desarrollados: cuatro de ellos para servicios deimágenes (Flickr, Picasa, GoogleImages y Wikicommons), otro para vídeos (Youtube)y otro para resultados de texto tradicionales (Yahoo Search). El módulo de resultadosde texto �nalmente nunca fue incorporado a la interfaz porque la intención es que laaplicación se centre en contenidos multimedia.Algunas empresas como Google ofrecen distintas formas de acceder a sus servicios,

en el caso de esta compañía podemos acceder a información de sus servicios mediantebibliotecas libres en Python desarrollados por ellos mismos (conocidas como GData) omediante JSON. En los módulos desarrollados se ha utilizado el primer método paraacceder a los resultados de Youtube y Picasa y el segundo para acceder a los de GoogleImages.En ocasiones, el acceso a determinada información no está disponible o es complejo de

obtener. En el caso de Flickr, para poder a la imagen del tamaño mayor posible se debíahacer una consulta para cada uno de los resultados obtenidos, lo cual es inviable por elcoste de tiempo que supone. Por otra parte, Wikicommons únicamente facilita el nombredel recurso, lo que hace muy difícil su puntuación.

3.4. Visualización de los resultados

Para la visualización de los resultados, como se ha indicado en la sección sobre las tec-nologías utilizadas, se emplea simplemente HTML y CSS. Combinando ambos, podemosmostrar en la ventana del navegador una imagen en las coordenadas deseadas empleadopara ello distancias absolutas.Cuando se realiza la visualización, se marcan todos los resultados mostrados como

usados y cuando el usuario decide avanzar de página, lo que realiza el código que se ejecutaen el cliente es descartar todos estos resultados y realizar una nueva visualización. Si elusuario decide volver atrás en los resultados, el buscador vuelve a considerar todos losresultados descartados la última vez que se avanzó la página. De esta forma de consigueuna navegación muy rápida para el usuario, en la que el único retardo que se produce esel de estimar la posición en la que se van a disponer los resultados.Durante la visualización, el usuario puede visualizar los resultados a un tamaño mayor

simplemente pulsando sobre éste. Para ello se ha utilizado el plugin de jQuery Ceebox,que permite mostrar un diálogo dentro de la página ajustado al tamaño de la ventana y laimagen o vídeo visualizado y que permite también navegar pasando los contenidos uno auno. Esto resulta muy cómodo para los usuarios y para el buscador, ya que estos no tienenque abandonar la página para consultar los resultados. La principal ventaja de Ceeboxcon respecto al resto de bibliotecas que hacen el mismo trabajo es que permite hacer

16

3. Desarrollo del proyecto propiamente dicho

sin modi�car los enlaces originales y puede trabajar con cualquier tipo de contenidos:imágenes, vídeos, otras páginas, etc.Para la visualización de resultados también se desarrollaron dos plantillas utilizando

el sistema de plantillas de Django para que el buscador contase con una página de inicioy una página de búsqueda. Las páginas de búsqueda también cuentan con una direcciónpermanente del tipo http://www.dominio.com/search/terminosdebúsqueda.

3.5. Carga de los resultados

Una de las especi�caciones del proyecto es la rápida carga de los resultados para me-jorar la experiencia del usuario que visite el buscador. El algoritmo voraz planteado, quedescribiré posteriormente, consigue una disposición muy rápida de los resultados; peroéste necesita que previamente hayan cargado todas las imágenes para ser ejecutado, yaque necesita conocer el ancho y alto de cada una de ellas.Del planteamiento inicial que se hizo del proyecto, se tuvieron que analizar importantes

problemas que hacían la carga de imágenes muy lenta:

1. Se comprobaba cada cada vez que se cambiaba de página si las imágenes habíancargado.

2. No se empezaban a descargar las imágenes hasta que los resultados de todos losbuscadores no habían llegado.

3. Los resultados sólo se visualizaban cuando terminaban de cargar todas las imágenes.

Para solucionar el tercero de los problemas, se implementó una forma de que los resul-tados se visualizasen cada vez que terminaban de cargar todos los resultados de unode los buscadores. Pero esta solución seguía siendo insu�ciente, por lo que se cambió elcomportamiento para que la actualización de las imágenes mostradas se realizase cadacierto tiempo, utilizando para ello un temporizador que en las pruebas fue �jado cada 2segundos.También se reestructuró todo el código para que no se volviesen a comprobar que

todas las imágenes hubiesen cargado cada vez que se cambiaba de página y para que lasimágenes empezasen a descargarse de los servidor en cuanto llega el resultado al cliente.Para esto me serví de que los resultados de cada uno de los buscadores se devuelven enpeticiones HTTP distintas.Para gestionar la carga de las imágenes se utilizan tres métodos:

1. El evento onload de la imagen, que ocurre cuando la imagen carga correctamente.

2. El evento onerror de la imagen, que ocurre cuando la imagen carga incorrectamente.

3. La propiedad complete, que indica si el navegador ha cargado ya la imagen.

17

3. Desarrollo del proyecto propiamente dicho

3.6. Determinar la posición de los resultados

3.6.1. Introducción

Conociendo ya la experiencia con problemas similares descrita en la introducción sobreel estado del arte, es necesario elegir una alternativa para la disposición de resultados.El principal factor a tener en cuenta es la velocidad, ya que un tiempo de carga bajo esfundamental para una aplicación web y, durante la carga de las imágenes, se desea llamarrepetidas veces al algoritmo, al tiempo que van llegando los resultados.En un principio, el planteamiento era utilizar un algoritmo genético[3], aunque se des-

cartó debido a que para obtener unos buenos resultados es necesaria una gran diversidady un número elevado de iteraciones. La alternativa elegida entonces para solucionar elproblema del tiempo fue utilizar un algoritmo 'greedy' (voraz o goloso) y, si la cantidadde huecos es muy elevada, realizar una búsqueda local para mejorar el resultado.Para la representación de la disposición de las imágenes existen dos alternativas: alma-

cenar las coordenadas en las que está situada la imagen o representar el espacio dispo-nible como una rejilla y almacenar en una matriz si cada posición está disponible o no.La segunda alternativa supone almacenar más información, sin embargo, es preferiblea la primera debido a que si únicamente almacenamos las coordenadas es muy difícilcomprobar los huecos para asignar las siguientes imágenes.En diciembre de 2009, James Padolsey (http://james.padolsey.com/javascript/

gapless-wall-of-images/) utiliza un algoritmo voraz para resolver un problema muysimilar al que yo estaba estudiando: él trata de crear un muro a partir de imágenes, redi-mensionándolas a partir de un tamaño mínimo y máximo. Para ello utiliza un algoritmovoraz cuyas principales desventajas son:

Que no se encuentra en absoluto documentado.

Los tamaños máximos y mínimos no son para cada imagen.

Las soluciones obtenidas en algunos casos se encontraban muy lejos de ser la óptima.

Debido a que todas estas desventajas eran fácilmente evitables y a que el trabajo estapublicado mediante una licencia libre, se parte del trabajo realizado para aplicarlo alproblema del proyecto.Para mejorar las soluciones obtenidas se plantea también aplicar la técnica del enfria-

miento simulado[11] (también conocido como 'simulated annealing' o 'recocido simulado')como posteriormente se explica. La ventaja que presenta el enfriamiento simulado frentea la búsqueda local es que evita �nalizar la ejecución en óptimos locales.

3.6.2. Algoritmo voraz utilizado

Como se ha comentado, se parte del trabajo de James Padolsey, que se adapta

Para que los tamaños vayan en función de la importancia del resultado, se toma lapuntuación del resultado para establecer un tamaño máximo y un tamaño mínimode la imagen.

18

3. Desarrollo del proyecto propiamente dicho

Utilización de dichos tamaños máximos y mínimos para cada imagen.

Organización de los resultados antes de empezar a utilizarlos.

Uso de las estructuras de datos necesarias.

Impedir la reutilización de imágenes, ya que no tiene mucho sentido mostrar resul-tados por duplicado.

Optimización del rendimiento.

El algoritmo consiste en los siguientes pasos:

Se ordenan los resultados según su importancia, para que primero sean consideradoslos más importantes.

Se inicia el punto más alto a 0,0.

De forma iterativa, hasta que no queden candidatos a punto más alto:

� Se toma el punto más alto y se elimina de la lista de candidatos a punto másalto. 1

� Se toma el siguiente resultado.2

� Se intenta colocar en la posición más alta, al máximo tamaño posible sin queexceda las dimensiones máximas.3

� Si no se alcanzan las dimensiones mínimas �jadas para el resultado, se descartay se pasa al siguiente.

� Si no se descarta, se insertan en la lista de candidatos a punto más alto lasesquinas inferiores de la imagen y la esquina superior derecha.

Los resultados obtenidos son muy satisfactorios ya que la carga de resultados es muyrápida. Analizando el tiempo de ejecución de todo el código JavaScript se puede apreciarque la mayor parte del tiempo se invierte trabajando con la matriz que determina lasposiciones ocupadas, por lo que quizás estos tiempos sean aún mejorables. En la �gura3.6.1 se puede apreciar el proceso de disposición de imágenes que se va siguiendo.

1La lista se ordena de candidatos a punto más alto se ordena considerando más alto como el punto cuya

posición el eje Y sea más bajo y, en caso de igualdad, aquel cuya posición en el eje X sea menor.2El siguiente resultado se toma de manera recursiva, de forma que puede que hayamos descartado

resultados en un primer recorrido de la lista pero, si se recorre toda la lista entera, se vuelven a

considerar los descartados.3Para conocer qué posiciones se encuentran libres y cuales ocupadas se utiliza una matriz en la cual

cada posición representa cada uno de los píxeles del espacio disponible y el valor 1 signi�ca que se

encuentra ocupado por una imagen y el 0 que está libre.

19

3. Desarrollo del proyecto propiamente dicho

3.6.3. Aplicación del enfriamiento simulado

El enfriamiento simulado consiste en una búsqueda por entornos que, a diferencia dela búsqueda local, permite aceptar soluciones peores en función de una probabilidad queva disminuyendo con el tiempo. De esta forma, al principio se realiza una búsqueda conmayor diversi�cación y al �nal se intensi�ca la búsqueda, al ser más difícil que se acepteuna solución peor.Para aplicar el enfriamiento simulado se adapta el código desarrollado por Jesús Gonzá-

lez Peñalver que optimiza la disposición de un periódico online[4] y que se encuentra dis-ponible en http://atc.ugr.es/~jesus/layout/. La temperatura inicial, que determinala probabilidad para aceptar soluciones peores, es iniciada según sugiere Kirkpatrick[11]y el algoritmo recibe como parámetros el número de iteraciones a realizar y cada cuántasiteraciones se modi�cará la temperatura.Como el resultado del algoritmo voraz depende de el orden en que se consideran las

imágenes, lo que se hace es aplicar la técnica del enfriamiento simulado sobre el ordende dichas imágenes de entrada, siendo inicialmente el orden de este de mayor a menorimportancia. Aplicar el enfriamiento simulado sobre la salida del algoritmo voraz seríamás complicado y no merecería la pena, ya que no sería muy difícil aplicar una mutaciónsobre el resultado que minimice el número de huecos dejados.El operador de mutación empleado consiste en intercambiar dos miembros distintos y

seleccionados al azar de la lista. La función de evaluación o �tness es el número de huecosque quedan tras aplicar el algoritmo voraz.

3.7. Comunicación

Como ya indicamos, el cliente y el servidor utilizan JSON para la comunicación de losresultados, aunque sería fácilmente extensible el código para que también se permita lacomunicación entre cliente y servidor mediante XML o cualquier otro método.Se ha decidido que todos los atributos que sean almacenados en la clase del lado

del cliente se trans�era al lado del servidor, esto debe a que, aunque en determinadomomento no utilicemos todos los atributos, puede ser interesante utilizar otro clientepara comunicarse con la interfaz que sí utilice estos datos. Además, toda la informacióncontenida es pública y no tiene sentido que esté oculta.Para que un objeto de Python se convierta a notación JavaScript se ha utilizado la

biblioteca jsonpickle (http://github.com/jsonpickle/jsonpickle), a la que simple-mente se le pasa el objeto y se obtiene el texto con el resultado.Del lado del cliente, al ser estar ya la respuesta del servidor en la misma notación que

el código que la procesa, simplemente hay que evaluar el código recibido.

20

3. Desarrollo del proyecto propiamente dicho

Figura 3.6.1.: Proceso de disposición de imágenes del algoritmo voraz

21

3. Desarrollo del proyecto propiamente dicho

Figura 3.6.2.: Ejemplo de disposición de resultados empleando el algoritmo voraz

22

4. Evaluación y conclusiones

4.1. Evaluación de la disposición de imágenes

Los tiempos de ejecución obtenidos mediante esta técnica no son demasiados bue-nos, para 10 iteraciones (un número muy bajo para el enfriamiento simulado) en uncomputador moderno tarda más de 10 segundos, lo que claramente es un rendimientoinaceptable. Analizando con un el 'pro�ler' de la extensión Firebug para Mozilla Firebugse detectan los principales cuellos de botella: más del 50% del tiempo es invertido encalcular el �tness de la solución, por lo que utilizando como función de evaluación elnúmero de espacios que quedan en la matriz no es factible aplicar el enfriamiento simu-lado. Podríamos utilizar otros como función de �tness el número de imágenes utilizado,pero puede utilizándose muchas imágenes el desaprovechamiento de la pantalla sea muygrande.Analizando también la calidad de la solución obtenida, llegamos a la conclusión de

que apenas existe diferencia entre aplicar el enfriamiento simulado unas pocas iteracio-nes y quedarnos con la primera solución de la que partíamos, como se puede observarcomparando las �guras 4.1.3 y 4.1.4.Para estimar cuántas iteraciones serían necesarias para obtener resultados que fuesen

apreciables se hace una ejecución de 50 iteraciones en la que se enfría la temperaturacada 5 y los resultados son los observados en la imagen 4.1.2, comparando el espacio quequeda ahora libre con el total disponible (�gura 4.1.5) ahora sí se aprecia una importantemejora. Sin embargo, debido al tiempo que tarda cada una de las ejecuciones no es viable.La razón por la que es difícil conseguir mejoras con respecto al algoritmo greedy inicial

puede ser debida a la ordenación de mayor a menor realizada al inicio de éste. Como yaestudió Daniel Selator[13], una buena técnica es empezar colocando las imágenes mayorespara después intentar rellenar los huecos dejados por ellas con las imágenes más pequeñas.Es obvio que si en último lugar consideramos las imágenes más grandes nos va a ser másdifícil conseguir una óptima distribución.Observando los resultados de muchas de las ejecuciones puede parecer que en ningún

momento se opta por tomar soluciones peores que la actual y por lo tanto los parámetrosdel enfriamiento simulado deberían ser reajustados o utilizar simplemente una búsquedalocal. sin embargo, como podemos apreciar en la �gura 4.1.6 sí que se adoptan peoressoluciones para evitar caer en óptimos locales. El mayor inconveniente es que una pequeñamutación da lugar a grandes cambios en la disposición, lo que hace que no haya nipequeñas mejoras ni pequeños empeoramientos, sino siempre cambios bruscos en el valordel �tness.

23

4. Evaluación y conclusiones

Figura 4.1.1.: Evolución del �tness de la solución en 10 iteraciones

4.2. Conclusiones

El proyecto ha logrado cumplir todos los objetivos básicos que se habían propuesto yrespetando las especi�caciones planteadas.Se han desarrollado buscadores para diferentes módulos que obtienen la información,

la organizan y la puntúan según distintos clientes. Todo esto se realiza utilizando unaestructura modular que permite una fácil extensibilidad de la aplicación, lo que ha permi-tido que terceras personas colaboren con el proyecto e implementen sus propios módulospara distintos buscadores y utilizando distintos sistema de comunicación con ellos, con-tando �nalmente el proyecto con media docena de módulos. Esta estructura modulartambién permite que los errores en unos módulos no afecten al resto.Por otra parte, del lado del cliente se ha creado una agradable a la par que simple

interfaz que muestra los resultados de una forma paginada y que da la sensación derapidez al ir mostrando los resultados conforme son recibidos del servidor. Esto permiteque la experiencia del usuario sea satisfactoria, además de que se le permite que no tengaque abandonar el buscador para consultar los resultados.El resultado ha sido probado en distintos navegadores modernos con satisfactorio re-

sultado, gracias a que ha sido desarrollado empleando estándares y tecnologías abiertas.Además, independientemente del navegador utilizado, los resultados se ajustan al espaciodejado libre por la ventaja del navegador.En cuanto a los métodos de disposición de los resultados en la pantalla se han es-

tudiando distintas alternativas, consiguiendo grandes resultados con el algoritmo vorazimplementado en un tiempo muy reducido, que además permite representar los resultadosmás interesantes (mejor puntuados) a un tamaño mayor y en las primeras páginas. Laaplicación del enfriamiento simulado no ha sido satisfactoria, pero su estudio ha permiti-do sacar interesantes conclusiones sobre la conveniencia de aplicar este tipo de búsqueda

24

4. Evaluación y conclusiones

Figura 4.1.2.: Evolución del �tness de la solución en 50 iteraciones

y sobre cómo aplicarla.Por último, la madurez del software desarrollado ha permitido que sea publicado

e instalado para el acceso público en http://visuse.com. El desarrollo del proyec-to también ha supuesto una interesante contribución a la comunidad de software li-bre, que puede reutilizar este trabajo para cualquier otro �n relacionado y que ha re-conocido dicha contribución. Todo el código del proyecto se encuentra disponible enhttps://forja.rediris.es/projects/cusl4-visuse/.

25

4. Evaluación y conclusiones

Figura 4.1.3.: Espacio ocupado y libre en la ventaja sin aplicar el enfriamiento simulado

Figura 4.1.4.: Espacio ocupado y libre en la ventaja tras aplicar el enfriamiento simuladodurante 10 iteraciones

26

4. Evaluación y conclusiones

Figura 4.1.5.: Espacio ocupado y libre en la ventaja tras aplicar el enfriamiento simuladodurante 50 iteraciones

Figura 4.1.6.: Otro ejemplo de 50 iteraciones en el que se 'escapa' de un óptimo local

27

A. Instrucciones de utilización

En todas las plataformas o sistemas operativos que dispongan de un intérprete Pythonse puede utilizar Visuse y en el repositorio del proyecto se incluyen unas instrucciones deinstalación.Las instrucciones básicas de instalación (incluyendo comandos para instalar en distri-

buciones Linux basadas en Debian) son:

1. Instalar paquete de Django: sudo apt-get install python-django

2. Instalar mysqldb : sudo apt-get install python-mysqldb

3. Ejecutar desde la carpeta visuse ./manage.py runserver

4. Acceder con el navegador a http://127.0.0.1:8000/ y comprobar que las bús-quedas funcionan.

Es posible que también se requiera de distintas bibliotecas para la comunicación conalgunos buscadores que se indicarán en la siguiente subsección.

28

B. Dependencias de los módulos

Las particularidades de cada uno de los módulos hacen necesaria la utilización dedistintas bibliotecas que no siempre están incluidas en las bibliotecas estándar o juntocon el código del módulo facilitado. Las dependencias de los módulos facilitados con elsoftware son:

1. urllib: en distribuciones basadas en debian se encuentra en el paquete python-m2crypto

2. Gdata: en algunas distribuciones basadas en debian se encuentra en el paquetepython-gdata y se puede encontrar en http://code.google.com/p/gdata-python-client/

3. Simple-JSON: es necesario si se tienen versiones de Python anteriores a la 2.6

29

Bibliografía

[1] FS Foundation. The GNU General Public License (GPL), pp. 1989.

[2] J. Geigel and A. Loui. Automatic page layout using genetic algorithms for electronicalbuming. Internet Imaging II, volume SPIE-4311, pages 79�90, 2000.

[3] D.E. Goldberg et al. Genetic algorithms in search, optimization, and machine lear-ning. Addison-wesley Reading Menlo Park, 1989.

[4] J. González, J. Merelo, P. Castillo, V. Rivas, and G. Romero. Optimizing web news-paper layout using simulated annealing. Engineering Applications of Bio-InspiredArti�cial Neural Networks, pages 759�768, 1999.

[5] E.R. Harold and W.S. Means. XML in a Nutshell. O'Reilly Media, Inc., 2004.

[6] G. Hattori, K. Hoashi, K. Matsumoto, and F. Sugaya. Robust web page segmen-tation for mobile terminal using content-distances and page layout information. InProceedings of the 16th international conference on World Wide Web, page 370.ACM, 2007.

[7] I. Hickson and D. Hyatt. HTML 5. The World Wide Web Consortium.(W3C WorkingDraft). Online: http://www.w3.org/TR/html5/, 25:2008, 2008.

[8] A. Holovaty and J. Kaplan-Moss. The De�nitive Guide to Django: Web DevelopmentDone Right. Springer, 2009.

[9] C. Jacobs, W. Li, E. Schrier, D. Bargeron, and D. Salesin. Adaptive grid-baseddocument layout. ACM Transactions on Graphics, 22(3):838�847, 2003.

[10] R. Johari, J. Marks, A. Partovi, and S. Shieber. Automatic yellow-pages paginationand layout. Journal of Heuristics, 2(4):321�342, 1997.

[11] S. Kirkpatrick, C.D. Gelatt Jr, and M.P. Vecchi. Optimization by simulated annea-ling. Science, 220(4598):671, 1983.

[12] J. Plekhanova. Evaluating web development frameworks: Django, Ruby on Railsand CakePHP. Institute for Business and Information Technology, 2009.

[13] D.D. Sleator. A 2.5 times optimal algorithm for packing in two dimensions. Infor-mation Processing Letters, 10(1):37�40, 1980.

30