Desarrollo de una infrestructura para la resolución distribuida de algoritmos de colonias de hormigas basados en espacios de búsqueda semánticos dinámicos

Ingeniero Informático Para optar a la titulación de / per a optar a la titulació de Víctor Manuel Martínez Valero Presentado por / presentat per: Dr. Francisco Javier Jaén Martínez José Antonio Mocholí Agües València, 14 de diciembre de 2010. Dirigido / tutorizado por dirigit / tutoritzat per UNIVERSITAT POLITÈCNICA DE VALÈNCIA Escola Tècnica Superior d’Enginyeria Informàtica PROYECTO FIN DE CARRERA / PROJECTE FI DE CARRERA Desarrollo de una infraestructura para la resolución distribuida de algoritmos de colonias de hormigas basados en espacios de búsqueda semánticos dinámicos Índice 1 ˁ Índice 2 Agradecimientos A Javi por ayudarme a desarrollar este proyecto desde la primera idea hasta la última. A José Antonio y Alejandro por su inestimable ayuda en el aspecto técnico y los buenos ratos pasados en el laboratorio. A Mar y Juan porque me hicieron terminar el proyecto. A Elena y Álex porque me hicieron terminar la carrera. A mis padres y mi hermano porque me han hecho.  Índice 3 Índice AGRADECIMIETOS ................................................................................................................................... 2 ÍDICE ............................................................................................................................................................. 3 ÍDICE DE FIGURAS .................................................................................................................................... 5 CAPÍTULO 1. ALGORITMOS EVOLUTIVOS BASADOS E COLOIAS DE HORMIGAS ............ 6 1.1. D ESCRIPCIÓN DEL PROBLEMA .......................................................................................................... 6 1.2. O PTIMIZACIÓN BASADA EN COLONIAS DE HORMIGAS ....................................................................... 7 1.3. P ROBLEMAS R ESOLUBLES MEDIANTE OCH ..................................................................................... 8 1.4. H ORMIGAS ARTIFICIALES ................................................................................................................. 9 1.5. M ODELOS DE OCH ........................................................................................................................ 10 1.5.1. El Sistema de Hormigas .......................................................................................................... 10 1.5.2. El sistema de colonias de hormigas......................................................................................... 12 1.6. A LGORITMOS DE OCH PARALELOS ................................................................................................ 14 1.7. C ONCLUSIONES .............................................................................................................................. 14 CAPÍTULO 2. U MODELO SEMÁTICO PARA LA GEERACIÓ DE ESPACIOS DE BÚSQUEDA .................................................................................................................................................... 15 2.1 W EB SEMÁNTICA .................................................................................................................................... 15 2.2. R ESOURCE D ESCRIPTION F RAMEWORK ................................................................................................. 15 2.3. E SCRIBIENDO SENTENCIAS SOBRE RECURSOS ........................................................................................ 16 2.3.1. Conceptos básicos ........................................................................................................................ 16 2.3.2. El modelo RDF............................................................................................................................. 17 2.4. S INTAXIS PARA RDF: RDF/XML .......................................................................................................... 18 2.5. SQL ITE .................................................................................................................................................. 20 2.6. S EM W EB ............................................................................................................................................... 20 2.7. RDF EN UNA BASE DE DATOS SQL ITE ................................................................................................... 22 2.8. C ONSULTAS Y CREACIÓN DEL ESPACIO DE BÚSQUEDA ........................................................................... 25 2.8.1 Consultas sobre la base de datos SQLite ................................................................................. 25 2.8.2. Creación de los nodos .............................................................................................................. 26 2.8.3. Funciones de evaluación ......................................................................................................... 26 2.8.4. Obtención del Score ................................................................................................................. 27 2.8.5. Generación del espacio de búsqueda ...................................................................................... 28 2.8.6. Modelo de clases ...................................................................................................................... 28 CAPÍTULO 3. U MODELO DISTRIBUIDO PARA LA RESOLUCIÓ DE ALGORITMOS OCH 32 3.1. A RQUITECTURA DEL SISTEMA ................................................................................................................ 32 3.1.1. Funcionamiento del sistema ........................................................................................................ 32 3.2. M ULTIMEDIA Q UERIER .......................................................................................................................... 33 3.2.1. Funcionamiento del MultimediaQuerier .................................................................................... 33 3.3. M ASTER Q UEEN S ERVICE ........................................................................................................................ 33 3.3.1. Funcionamiento del MasterQueenService .................................................................................. 34 3.3.2. Modelo de clases........................................................................................................................... 34 3.3.3. Métodos del servicio web .............................................................................................................. 35 3.4. H IVE C LIENT .......................................................................................................................................... 37 3.4.1. Funcionamiento del HiveClient................................................................................................... 37 3.4.2. Modelo de clases........................................................................................................................... 37 CAPÍTULO 4. CASO DE ESTUDIO ........................................................................................................... 41 4.1. U NA BASE DE DATOS DE DISCOS ............................................................................................................ 41 竸љ Índice 4 4.2. D EFINICIÓN DE LOS METADATOS ........................................................................................................... 41 4.2.1. El metadato género ....................................................................................................................... 43 4.2.2. El metadato artista ........................................................................................................................ 44 4.2.3. El metadato año ............................................................................................................................ 45 4.3. E VALUACIÓN DEL SISTEMA .................................................................................................................... 46 4.3.1. Consulta: Folk = 100 .................................................................................................................... 47 4.3.2. Consulta: Trance = 100 ................................................................................................................ 49 4.3.3. Consulta: Folk = 50; Trance = 50 ................................................................................................ 51 4.3.4. Consulta: Folk = 80; Trance = 20 ................................................................................................ 55 4.3.5. Consulta: Folk = 50; Javier Krahe = 50 ...................................................................................... 59 4.3.6. Consulta: Folk = 80; Javier Krahe = 20 ...................................................................................... 63 4.3.7. Consulta: Folk = 50; Armin Van Buuren = 50 ............................................................................. 67 4.3.8. Consulta: Folk = 80; Armin Van Buuren = 20 ............................................................................. 71 CAPÍTULO 5. COCLUSIOES ................................................................................................................ 76 5.1. D ESARROLLO DEL PROYECTO ................................................................................................................ 76 5.2. C ONCLUSIONES DEL TRABAJO REALIZADO ............................................................................................. 76 5.3. T RABAJOS FUTUROS .............................................................................................................................. 77 BIBLIOGRAFÍA ............................................................................................................................................ 78  Índice de figurasP r o y e c t o d e f i n d e c a r r e r a | 5 Índice de figuras Figura 1. Varias sentencias sobre un recurso ....................................................................... 17 Figura 2. Tabla rdf_entities .................................................................................................. 22 Figura 3. Tabla rdf_literals ................................................................................................... 23 Figura 4. Tabla rdf_statements ............................................................................................. 24 Figura 5. Modelo de clases ................................................................................................... 29 Figura 6. Modelo de clases de las consultas ......................................................................... 30 Figura 7. Modelo de clases de los nodos .............................................................................. 31 Figura 8. Modelo de clases de MasterQueenService ............................................................ 34 Figura 9. Modelo de clases de HiveClient ............................................................................ 38 Figura 10. Frecuencia. Consulta: Folk = 100 ....................................................................... 47 Figura 11. Saturación. Consulta: Folk = 100 ........................................................................ 48 Figura 12. Frecuencia. Consulta: Trance = 100 ................................................................... 50 Figura 13. Saturación. Consulta: Trance = 100 .................................................................... 51 Figura 14. Frecuencia. Consulta: Folk = 50; Trance = 50 .................................................... 52 Figura 15. Saturación. Consulta: Folk = 50; Trance = 50 .................................................... 53 Figura 16. Frecuencia. Consulta: Folk = 50; Trance = 50 .................................................... 54 Figura 17. Saturación. Consulta: Folk = 50; Trance = 50 .................................................... 55 Figura 18. Frecuencia. Consulta: Folk = 80; Trance = 20 .................................................... 56 Figura 19. Saturación. Consulta: Folk = 80; Trance = 20 .................................................... 57 Figura 20. Frecuencia. Consulta: Folk = 80; Trance = 20 .................................................... 58 Figura 21. Saturación. Consulta: Folk = 80; Trance = 20 .................................................... 59 Figura 22. Frecuencia. Consulta: Folk = 50; Javier Krahe = 50 ........................................... 60 Figura 23. Saturación. Consulta: Folk = 50; Javier Krahe = 50 ........................................... 61 Figura 24. Frecuencia. Consulta: Folk = 50; Javier Krahe = 50 ........................................... 62 Figura 25. Saturación. Consulta: Folk = 50; Javier Krahe = 50 ........................................... 63 Figura 26. Frecuencia. Consulta: Folk = 80; Javier Krahe = 20 ........................................... 64 Figura 27. Saturación. Consulta: Folk = 80; Javier Krahe = 20 ........................................... 65 Figura 28. Frecuencia. Consulta: Folk = 80; Javier Krahe = 20 ........................................... 66 Figura 29. Saturación. Consulta: Folk = 80; Javier Krahe = 20 ........................................... 67 Figura 30. Frecuencia. Consulta: Folk = 50; Armin Van Buuren = 50 ............................... 68 Figura 31. Saturación. Consulta: Folk = 50; Armin Van Buuren = 50 ................................ 69 Figura 32. Frecuencia. Consulta: Folk = 50; Armin Van Buuren = 50 ................................ 70 Figura 33. Saturación. Consulta: Folk = 50; Armin Van Buuren = 50 ................................ 70 Figura 34. Frecuencia. Consulta: Folk = 80; Armin Van Buuren = 20 ................................ 72 Figura 35. Saturación. Consulta: Folk = 80; Armin Van Buuren = 20 ................................ 72 Figura 36. Frecuencia. Consulta: Folk = 80; Armin Van Buuren = 20 ................................ 73 Figura 37. Saturación. Consulta: Folk = 80; Armin Van Buuren = 20 ................................ 74  Capítulo 1. Algoritmos evolutivos basados en colonias de hormigasP r o y e c t o d e f i n d e c a r r e r a | 6 Capítulo 1. Algoritmos evolutivos basados en colonias de hormigas En este capítulo trataremos de describir el uso de algoritmos basados en colonias de hormigas para la resolución de problemas de optimización como el de la orientación o similares. Definiremos el problema que, en esencia, nuestro trabajo quiere resolver, que no es otro que el de encontrar soluciones con puntuación máxima, sin superar ciertas restricciones. Este problema suele describirse como el problema de la orientación, si bien su uso no se restringe sólo a este ámbito. Describiremos qué es una colonia de hormigas y qué podemos extraer de ellas para realizar nuestra tarea. Mostraremos cómo creamos hormigas artificiales a partir del comportamiento de estas colonias. Todo ello para poder solucionar problemas en contextos fijos, que trabajarán con unos datos fijos cuya descripción será tratada en el siguiente capítulo. 1.1. Descripción del problema Como hemos comentado, el problema que trataremos de resolver en nuestro estudio suele ser conocido como el problema de la orientación, ya que es originario de las carreras deportivas dónde un grupo de participantes recorre un espacio desconocido con la ayuda de un mapa. Debido a que no sólo es importante en este problema el tiempo empleado en la llegada a la meta, sino también los puntos de control recorridos, se debe encontrar un balance entre la velocidad y las estaciones visitadas. El ámbito de uso del problema es amplio, pudiendo trasladarse a la generación de itinerarios, listas de reproducción, etc. Su formulación es como sigue. Dado un grafo no dirigido G(V,A), con |V| = n nodos en el espacio Euclídeo donde cada nodo tiene asociado un determinado beneficio S i , S i >0 excepto los nodos v 1 y v n (inicial y final) que tienen asociado un beneficio S 1 =S n =0; cada nodo puede ser visitado como máximo una vez; y cada arista (v i , v j ) v i , v j ∈ V tiene asociado un coste >0 el objetivo es encontrar un camino de beneficio máximo donde el coste asociado a dicho camino no supere un determinado valor máximo . Formulación matemática: ∗     Manteniendo las restricciones:    =    =1 ˁ Capítulo 1. Algoritmos evolutivos basados en colonias de hormigasP r o y e c t o d e f i n d e c a r r e r a | 7    =   ≤1, =2,…,−1 ∗     ≤ ∈!0,1", #,$=1,…, En nuestro caso, los elementos representados mediante nodos no vienen fijados previamente, sino que serán fijados por el usuario final de nuestra componente. Esto permitirá la resolución del problema expuesto en cualquiera de los ámbitos referidos. 1.2. Optimización basada en colonias de hormigas Las colonias de hormigas, como otros tipos de sistemas provenientes de la naturaleza, son sistemas con una organización social perfectamente estructurada en las que existen mecanismos de coordinación que hacen que las mismas puedan realizar en conjunto tareas que posiblemente no podrían ser abordadas por ellas de forma individual. Un ejemplo de esta coordinación está relacionado con la percepción visual de muchas de las especies de hormigas, muy poco desarrollada, lo cual hace que gran mayoría de sus mecanismos de comunicación se basen en el intercambio de feromonas, unas sustancias químicas producidas de forma natural. Concretamente, en las colonias de hormigas tienen una importancia vital las feromonas de rastreo “trail feromones” que algunas especies como la “Lasius 8iger” o la “Iridomyrmex humilis” utilizan para marcar químicamente caminos en el terreno que recorren que le conduzcan desde su hormiguero hasta los lugares en los que haya alimentos. Mientras las hormigas se van desplazando desde el hormiguero hasta la fuente de alimento, van depositando feromonas en el terreno que recorren. Si una hormiga en su camino no encuentra rastro alguno de feromona, ésta se moverá de forma aleatoria; en cambio, si detecta dicha sustancia, tenderá a seguir con una mayor probabilidad el rastro detectado. Existen gran cantidad de experimentos que han demostrado que las hormigas terminan tomando aquellos caminos que tienen una mayor concentración de feromonas y que, en la práctica, cuando hay varios caminos bifurcados, las hormigas terminan eligiendo qué camino tomar basándose en la intensidad de feromonas. De esta manera, al depositar estas mismas hormigas a su vez feromonas en el camino que acaban de elegir, se convierte este mecanismo en un proceso de refuerzo que termina construyendo caminos intensamente marcados. Este proceso tiene una razón de ser dado que, como han demostrado los experimentos del puente doble de Deneubourg, el mecanismo de autorefuerzo conduce a la selección de los caminos más cortos debido a la evaporación de las feromonas. Deneubourg diseñó un puente doble con dos caminos (un el doble de largo que el otro) que conectaban a un hormiguero de la especie Iridomyrmex humilis con una fuente de alimento. En los experimentos realizados por Deneubourg, éste pudo observar consistentemente que  Capítulo 1. Algoritmos evolutivos basados en colonias de hormigasP r o y e c t o d e f i n d e c a r r e r a | 8 tras cierto periodo de tiempo transitorio en el cual las hormigas escogían ambos caminos aleatoriamente siguiendo un proceso que podíamos denominar de exploración, las hormigas terminaban intensificando el camino más corto. Basándose en el comportamiento de las hormigas a penas descrito, Dorigo y sus colaboradores introdujeron por primera vez la optimización basada en colonias de hormigas (OCH) con el objetivo de resolver problemas de optimización combinatoria. La formulación de Dorigo se basa en la existencia de un modelo de hormiga artificial, agentes software que trabajan de forma cooperativa comunicándose mediante rastros de feromonas también artificiales. Se traslada al mundo de la computación el estudio del sistema natural descrito. Para entender de una forma sencilla el funcionamiento de los algoritmos de OCH debemos ver el proceso de resolución como un ejercicio constructivo en el que, en cada iteración, cada hormiga construye una solución recorriendo el grafo subyacente al problema. Este proceso constructivo puede verse como un proceso de decisión en el que cada hormiga debe decidir individualmente a qué nuevo nodo dirigirse desde el último nodo del grafo que ya haya visitado. Para poder tomar estas decisiones, el algoritmo mantiene dos tipos de información, heurística y de rastros de feromonas. La información heurística mide la atracción (o el grado de preferencia) de moverse desde un nodo origen a un nodo destino. Dicha atracción no se modifica a lo largo de la ejecución del algoritmo. En cambio, la información de feromonas artificiales mide la atracción aprendida de moverse entre dos nodos y actúa como una especie de memoria a largo plazo. Esta atracción aprendida imita a las feromonas naturales y por tanto dicha información va siendo modificada a lo largo de la ejecución del algoritmo siguiendo unos criterios que serán detallados más adelante. 1.3. Problemas Resolubles mediante OCH Los problemas resolubles mediante OCH pertenecen a la categoría de problemas de camino mínimo que están caracterizados por los siguientes aspectos: • Un conjunto de restricciones posiblemente dependientes del tiempo Ω&'( • Un conjunto finito de componentes )= *,,…,+ , - Los estados del problema se definen en términos de secuencias = .,,…,/,…0 de longitud finita sobre los elementos de C. El conjunto de todos los posibles estados se denota como 1. • Un conjunto de soluciones candidatas  ⊆1. • Un conjunto de estados posibles 13⊆1 definidos mediante un test que es dependiente del problema que verifica que no es imposible completar una secuencia ∈13 en una solución que satisfaga las restricciones Ω. • Un conjunto no vacío de soluciones óptimas ∗⊆13 y ∗⊆.  Capítulo 2. P r o y e c t o d e f i n d e c a r r e r a | 15 Capítulo 2. Un modelo semántico para la generación de espacios de búsqueda 2.1 Web semántica La web semántica es una extensión de la web actual, a la que dota de un mayor significado, tomando como objetivo una mejor definición de la información que facilitará la obtención de la misma por parte del usuario. Al añadir a la web metadatos semánticos se pueden obtener soluciones a problemas habituales en la búsqueda de información gracias a la utilización de una infraestructura común mediante la que se comparte, procesa y transfiere información haciendo, en cierto sentido, razonar a la propia web. Estos metadatos se proporcionan formalmente para que las máquinas de procesamiento puedan evaluarlos automáticamente. Para lograr todo esto, la web semántica hace uso de varios componentes, de los cuales podemos destacar como esenciales RDF, SPARQL y OWL, mecanismos destinados a convertir a la web en una infraestructura global dónde todos los datos sean reutilizables e interpretables por un gran número de aplicaciones. La función de cada componente es la siguiente: • RDF: se encarga de proporcionar información descriptiva sobre los recursos existentes en la web. Hablaremos más a fondo de RDF a continuación. • SPARQL: es el lenguaje de consulta sobre las sentencias de RDF, facilita las búsquedas sobre los recursos de la web semántica. • OWL: es un mecanismo de desarrollo de vocabularios específicos para algunos de estos recursos. OWL proporciona un lenguaje de definición de ontologías. 2.2. Resource Description Framework El Marco de Descripción de Recursos (a partir de ahora RDF, del inglés Resource Description Framework) es un lenguaje de representación de información acerca de recursos en la Web. En especial está orientada a la representación de metadatos sobre recursos web, tales como el título, autor y fecha de modificación de una página web, derechos de autor e información de la licencia de un documento en la red, o el calendario de disponibilidad de un recurso compartido. En cualquier caso, generalizando el concepto de “recurso web”, RDF puede usarse también para representar información sobre cosas que pueden ser identificadas en la red, incluso cuando no pueden ser recuperadas directamente de ella. Algunos ejemplos podrían ser información al respecto de artículos disponibles en instalaciones de compras on-line, o la descripción de las preferencias de envío de un usuario de las mismas.  Capítulo 2. P r o y e c t o d e f i n d e c a r r e r a | 16 RDF está pensado para situaciones en las cuales esta información tiene que ser usada por aplicaciones, en lugar de ser únicamente vista por gente. RDF provee un marco común para expresar esta información para que pueda ser intercambiada por aplicaciones sin pérdida de significado. Como es un marco común, los diseñadores de aplicaciones pueden habilitar la disponibilidad de parses y herramientas de procesado de RDF comunes. La habilidad de intercambiar información entre distintas aplicaciones significa que la información puede ponerse a disposición de aplicaciones para las que no fue creada. RDF se basa en la idea de identificar las cosas usando identificadores web (llamados Uniform Resource Identifiers o URIs), y describir los recursos en forma de propiedades simples y valores de las propiedades. Esto permite a RDF representar sentencias simples sobre recursos en forma de grafos de nodos y aristas representando los recursos y sus propiedades y valores. RDF también proporciona una sintaxis basada en XML (llamada RDF/XML) para almacenar e intercambiar estos grafos, que es la que usaremos para transformar en SQLite. Un ejemplo de esta sintaxis con datos de nuestro corpus sería el siguiente: <?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdfsyntax-ns#" xmlns:music="http://www.example.org/music#"> <rdf:Description rdf:about="Ten"> <music:genre>Grunge</music:genre> <music:artist>Pearl Jam</music:artist> <music:year>1991</music:year> </rdf:Description> </rdf:RDF> 2.3. Escribiendo sentencias sobre recursos 2.3.1. Conceptos básicos Como hemos dicho antes, RDF se usa para proporcionar una forma simple de crear sentencias sobre recursos de red, como páginas web. Esta sección describe las ideas básicas que explican la forma en que RDF proporciona estas habilidades. RDF se basa en la idea de que las cosas descritas tienen propiedades que tiene valores, y que los recursos pueden ser descritos mediante sentencias, similares a las de arriba, que especifican esas propiedades y valores. RDF usa una terminología particular para hablar de las distintas partes de las sentencias. Específicamente, la parte que identifica la cosa de la  Capítulo 2. P r o y e c t o d e f i n d e c a r r e r a | 17 que habla la sentencia se llama sujeto. La parte que identifica la propiedad o característica del sujeto que especifica la sentencia se llama el predicado, y la parte que identifica el valor de esa propiedad se llama el objeto. 2.3.2. El modelo RDF Las sentencias se pueden modelar en RDF como nodos y arcos en un grafo. Según el modelo de grafos de RDF, una sentencia se representa mediante un nodo para el sujeto y el objeto y un arco dirigido desde el nodo sujeto al nodo objeto para el predicado. La figura 1 muestra el grafo correspondiente al trozo de código XML/RDF de la sección anterior. http://www.example.org/ music#Ten http://www.example.org/music#genre http://www.example.org/music#artist http://www.example.org/music#year 1991 Grunge http://www.example.org/ music#Pearl_Jam Figura 1. Varias sentencias sobre un recurso Las URIrefs (URI reference) que representan las elipses del grafo, son URIs junto con unos identificadores al final. Las URIrefs son la forma habitual de representar sujeto, predicado y objeto de una sentencia. Como se puede ver en la figura anterior, dos de los nodos objeto figuran como rectángulos en lugar de elipses. Esto se debe a que esos nodos tienen valores constantes (llamados literales) que son representados por cadenas de caracteres. Los literales no pueden ser usados como sujetos o predicados en RDF. Cuando no es conveniente el uso de grafos para escribir sentencias se pueden usar tripletas. En esta notación cada sentencia del grafo se escribe como una simple tripleta de sujeto, predicado y nodo. 컀؃ Capítulo 2. P r o y e c t o d e f i n d e c a r r e r a | 18 <http://www.example.org/music#Ten><http://www.example.org/ music#genre>”Grunge” <http://www.example.org/music#Ten><http://www.example.org/ music# year>”1991” <http://www.example.org/music#Ten><http://www.example.org/ music#artist><http://www.example.org/music#Pearl_Jam> La notación completa en tripletas requiere que las URIrefs se escriban completamente, entre los símbolos ‘<’ y ‘>’, lo cual puede hacer, como se observa en el ejemplo anterior, que se escriban líneas muy largas en una página. Para mejorar esto, se suele usar una forma más corta de escribir tripletas (que también es usada en otras especificaciones, como veremos más adelante). Estas abreviaciones sustituyen un nombre cualificado XML (qualified name o Q8ame, en inglés) sin los símbolos ‘<’ y ‘>’ por una abreviación de la URIref completa. Un Q8ame contiene un prefijo que se asigna previamente a una URI de un espacio de nombres, dos puntos y un nombre local. Algunos ejemplos de Q8ames muy extendidos serían: El prefijo rdf: para la URI del espacio de nombres: http://www.w3.org/1999/02/22-rdf-syntax-ns# El prefijo rdfs: para la URI del espacio de nombres: http://www.w3.org/2000/01/rdf-schema# El prefijo ex: para la URI del espacio de nombres: http://www.example.org/ 2.4. Sintaxis para RDF: RDF/XML Como se comentó en el punto anterior, el modelo conceptual de RDF es un grafo. RDF proporciona una sintaxis XML para la escritura e intercambio de grafos RDF, llamada RDF/XML. Al contrario que las tripletas, que son una especie de notación taquigráfica, RDF/XML es la sintaxis normativa para RDF. El código de la página 18 nos da un ejemplo del uso de RDF/XML. En este caso, los nodos de la Figura 1 están también representados en él. Lo reproduciremos de nuevo a continuación para poder comentar sus componentes. <?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdfsyntax-ns#" xmlns:music="http://www.example.org/music#"> <rdf:Description rdf:about="Ten"> <music:genre>Grunge</music:genre> 冰؁ Capítulo 2. P r o y e c t o d e f i n d e c a r r e r a | 19 <music:artist>Pearl Jam</music:artist> <music:year>1991</music:year> </rdf:Description> </rdf:RDF> En la primera línea tenemos la declaración de XML, que indica básicamente que el código está escrito en XML, y la versión del mismo usada. La segunda línea comienza con un elemento rdf:RDF. Esto quiere decir que el contenido XML que viene a continuación y que terminará con el </rdf:RDF> de la última línea trata de representar RDF. Justo después del rdf:RDF, en la misma línea hay una declaración de un espacio de nombres XML, representada como un atributo xmlns de la etiqueta inicial rdf:RDF. Esta especificación viene a significar que todas las etiquetas de este contenido que tengan el prefijo rdf: son parte de un espacio de nombres identificado por el URIref http://www.w3.org/1999/02/22-rdf-syntax-ns#. Las URIrefs que empiezan con http://www.w3.org/1999/02/22-rdf-syntax-ns# son usadas como términos del vocabulario RDF. Después de esa expresión, hay otra también representada como un atributo un atributo xmlns de la etiqueta inicial rdf:RDF, y especifica que el URIref http://www.example.org/music# se asociará con el prefijo music:. Los URIrefs que empiezan con la cadena http://www.example.org/music# se usan en nuestro caso para los términos de la base de datos que usaremos de ejemplo. El “>” al final de la línea indica el final de la etiqueta inicial rdf:RDF. Estas dos primeras líneas son necesarias para indicar que el contenido es RDF/XML y para identificar el espacio de nombres usado dentro de este contenido RDF/XML. Las líneas de la tercera a la séptima proporcionan el código RDF/XML para las sentencias representadas en la Figura 1. Una forma sencilla de hablar de una sentencia RDF es decir que es una descripción, y que trata del sujeto de la sentencia (en este caso, trata de http://www.example.org/music#Ten), y esta es precisamente la forma en que RDF/XML representa las sentencias. La etiqueta inicial rdf:Description en la tercera línea indica el inicio de una descripción de un recurso, y continúa identificado el recurso acerca del cual trata la sentencia (que es el sujeto de la sentencia) usando el atributo rdf:about para especificar el URIref del recurso sujeto. La cuarta, quinta y sexta línea proporcionan un elemento de propiedad distinto cada uno, con los Q8ames music:genre, music:artist y music:year respectivamente como sus etiquetas, para representar el predicado y el objeto de la sentencia. El Q8ame music:genre se elige de forma que al agregar el nombre local genre a la URIref del prefijo music: (http://www.example.org/music#) obtenemos la URIref del predicado de la sentencia http://www.example.org/music#genre. El contenido de este elemento de propiedad es el objeto de la sentencia, en este caso el literal Grunge (el valor de la propiedad género del recurso sujeto). El elemento de propiedad se anida dentro del elemento contenedor rdf:Description, que indica que esta propiedad se aplica al 컀؃ Capítulo 2. P r o y e c t o d e f i n d e c a r r e r a | 20 recurso especificado en el atributo rdf:about del elemento rdf:Description. Esto se puede aplicar para cada una de las líneas de la cuarta a la sexta. La séptima línea indica el final de este elemento rdf:Description. Para terminar, la octava línea indica el final del elemento rdf:RDF comenzado en la segunda línea. Una base de datos puede por tanto describirse mediante RDF/XML creando un segmento rdf:Description para cada uno de los elementos que pueda contener esta base de datos. Cada línea dentro de esa etiqueta rdf:Description contendrá a su vez un atributo del elemento en cuestión así como el valor de ese atributo para el elemento tratado. 2.5. SQLite Para facilitar el uso de los datos provenientes de archivos RDF/XML en nuestra componente, se decidió, como primer paso, la transformación de esos archivos en una base de datos relacional. El tener una base de datos relacional nos permite el uso de librerías ya fácilmente incorporables en el Framework .8ET para acceder a los datos. De entre los distintos sistemas de gestión de bases de datos relacionales sobre los cuales puede trabajar .8ET, se decidió el uso de SQLite. SQLite, que es un proyecto de dominio público creado por Richard Hipp [2], está contenido en una librería en C de aproximadamente 500 kb, pudiendo llegar a bajar de 250 kb. Al contrario que la mayoría de los sistemas de gestión de bases de datos, SQLite no tiene un proceso servidor separado, sino que lee y escribe directamente en archivos. Una base de datos SQL completa, con múltiples tablas, índices, disparadores y vistas, se contiene en un solo archivo. Además el formato del archivo que contiene la base de datos es independiente de la plataforma en que se use, motivos estos por los cuales se tomó este sistema para la creación de nuestra base de datos. El hecho de que en su tercera versión se puedan usar bases de datos de hasta dos Terabytes de tamaño y se permita la inclusión de campos de tipo BLOB, no hace más que reforzar nuestra decisión. 2.6. SemWeb Para poder almacenar en una base de datos SQLite nuestros datos, contenidos inicialmente en un archivo RDF/XML, formato visto más arriba, tratamos de buscar una herramienta, a ser posible de código libre, que pudiese ser incorporada en aplicaciones creadas en .8ET como nuestra componente, y tuviese la suficiente potencia como para poder procesar bases de datos de un tamaño relevante. Y justo esto es lo que SemWeb nos ofrece. ѝ Capítulo 2. P r o y e c t o d e f i n d e c a r r e r a | 21 SemWeb [3] es una librería creada para Web Semántica/RDF y escrita en C# para .8ET 1.1/2.0. Esta librería puede ser usada para leer y escribir RDF (tanto en XML, como en una notación llamada 83), almacenar de forma persistente RDF (en memoria, mediante MySQL, mediante SQLite, como sucederá en nuestro proyecto, etc.), hacer consultas a estos almacenamientos persistentes mediante equiparación de grafos y SPARQL (que es una recomendación para crear un lenguaje de consulta dentro de la Web semántica), y para hacer consultas SPARQL a terminales remotas. En nuestro caso, hacemos uso tan sólo de una pequeña porción de esta librería, como hemos indicado previamente, aquella que se encarga del almacenado de RDF de forma persistente. Para la creación de la base de datos nos bastará con hacer uso del siguiente método: Store store = Store.Create(”sqlite:rdf:Uri=file:music.sqlite;version=3”); El método Create es usado para crear varios tipos de orígenes de datos, como pueda ser, en este caso, una base de datos SQLite. Si bien la implementación de un almacén (store) en SQLite se encuentra en el ensamblado SemWeb.SqliteStore.dll, una vez se hace uso de Create basta con tener este ensamblado disponible en tiempo de ejecución, no hace falta referenciarlo en tiempo de compilación. Una vez ha sido creada la base de datos, se pueden añadir fácilmente sentencias RDF (que serán incluídas en varias tablas, como se verá posteriormente) mediante el método Store.Add, como se verá a continuación (si bien nuestra aplicación hará primero un análisis sintáctico del archivo XML/RDF que posteriormente incluirá en variables auxiliares de tipo Literal o Entity, para facilitar la comprensión del uso de los métodos hemos incluido la parte de creación de las mismas variables): const string URI = “http://www.example.org/music#”; static readonly Entity genre = URI + “genre”; store.Add(new Statement(“Ten”,genre, (Literal)”Grunge”)); La primera línea del código anterior sirve sólo para facilitar la vista de la URIref usada. En la segunda línea se crea un objeto Entity, una entidad RDF de valor http://www.example.org/music#genre”, que como se dijo anteriormente, son las únicas que pueden ser utilizadas como sujeto o predicado. En la tercera línea se añade al almacén una nueva sentencia, creada in situ, que tiene por sujeto la entidad “Ten”, como predicado la entidad genre creada en la línea anterior, y como objeto el literal )”Grunge”, creado en la misma línea a partir de la cadena de caracteres. ௰؁ Capítulo 2. P r o y e c t o d e f i n d e c a r r e r a | 22 Para cada una de las sentencias incluidas en el archivo RDF/XML de que se disponga, se ejecutará el presente método. Una vez ya se han terminado de añadir campos, la base de datos deberá ser cerrada mediante el método: store.Dispose(); 2.7. RDF en una base de datos SQLite La creación de bases de datos relacionales en SQLite a partir de SemWeb no sólo es sencilla, sino que el resultado obtenido es de muy fácil interpretación, lo cual facilitará nuestras consultas posteriores. Una base de datos SQLite con contenido RDF obtenida a partir del código SemWeb explicado en la sección anterior consta de tres tablas, una para las entidades, otra para los literales, y otra para las sentencias. Las siguientes figuras, obtenidas a partir del SQLite Database Browser [4] facilitarán la explicación de la base de datos. Figura 2. Tabla rdf_entities 節љ Capítulo 2. P r o y e c t o d e f i n d e c a r r e r a | 23 En la Figura 2 se puede observar la tabla de entidades (rdf_entities). En esta tabla se añade una nueva entrada por cada nuevo objeto de tipo Entity que es añadido en el store correspondiente a la base de datos. La tabla de entidades tiene dos campos. El campo value contiene el valor de la entidad correspondiente, que son las URIrefs de cada uno de las entidades de la base de datos. El campo id es un identificador dentro de la base de datos, que se usa para asociar entidades y literales a las sentencias, sin necesidad de repetir URIrefs o cadenas de caracteres respectivamente. El id es asignado a medida que se añade una nueva entidad o literal a la base de datos y es único. Puesto que la asignación del id es la misma para entidades y literales, un id dado puede identificar o bien a un literal, o bien a una entidad, y sólo a una. Figura 3. Tabla rdf_literals En la Figura 3 se puede observar la tabla de literales (rdf_literals). En esta tabla se añade una nueva entrada por cada nuevo objeto de tipo Literal que es añadido en el store correspondiente a la base de datos. La tabla de literales tiene cinco campos, si bien son los dos con valores idénticos a la tabla rdf_entities aquellos que realmente nos interesan y de los cuales haremos uso en nuestra componente. El campo id tendrá el mismo uso que en la tabla rdf_entities y como hemos dicho será único tanto en la tabla, como en el conjunto de las tablas rdf_entities y rdf_literals. El campo value en este caso contendrá la cadena de caracteres correspondiente al valor del literal, que se habrá introducido como objeto para una, o varias, sentencias de la ѓ Capítulo 2. P r o y e c t o d e f i n d e c a r r e r a | 24 base de datos. Los otros tres campos los omitimos, pues no serán utilizados en nuestra componente. Figura 4. Tabla rdf_statements En la Figura 4 se observa la tabla de sentencias (rdf_statements). En esta tabla se añade una nueva entrada por cada nuevo objeto de tipo Statement que es añadido en el store correspondiente a la base de datos. La tabla de sentencias tiene cinco campos de los cuales tan sólo tres van a ser utilizados por nuestra componente. Los campos subject, predícate y object representan respectivamente el sujeto, predicado y objeto de la sentencia a la que hacen referencia. Cada uno de estos tres campos tiene un valor numérico que se corresponderá con el valor id de alguna entrada, bien en la tabla rdf_entities, bien en la tabla rdf_literals. Como habíamos dicho antes no puede haber un literal y una entidad que compartan valor de id, por tanto, el valor de cada uno de los campos corresponderá a un solo valor en una de las dos tablas. Pongamos por ejemplo que queremos recuperar la sentencia a la que hace referencia la primera entrada de la tabla rdf_statement. Como vemos tiene los valores 2, 3, y 4 para los campos subject, predícate y object respectivamente. Si miramos las tablas rdf_entities y rdf_literals, vemos que el valor de id 4 se encuentra en la tabla rdf_literals, mientras que los valores 2 y 3 se encuentran en la tabla rdf_entities. Para 2 el valor del campo value es “Ten”, para 3 el valor es “http://www.example.org/music#genre” y para 4 vemos en la tabla rdf_literals 節љ Capítulo 2. P r o y e c t o d e f i n d e c a r r e r a | 31 Figura 7. Modelo de clases de los nodos Las distintas clases presentadas son:  5ode. Esta clase representa los nodos del espacio de búsqueda del problema. Un nodo es creado por cada sujeto en la base de datos RDF, y cada uno de ellos tendrá un beneficio (o score) asociado; calculado como hemos visto anteriormente.  Criterium. Esta clase representa, como hemos explicado anteriormente los valores de los objetos, pero en este caso no de las consultas, sino de cada uno de los nodos (sujetos) para cada valor distinto de predicado que tengan.  CriteriumType. Esta clase representa, como hemos explicado anteriormente los distintos valores de los predicados de la base de datos RDF. Cada Criterium de uno nodo, tendrá su CriteriumType asociado.  Distance. Esta clase representa, para dos Criterium distintos, el valor de la distancia que hay entre ambos, medido de cero a cien.  EvaluationFunction(s). Estas clases representan las distintas funciones de evaluación que el usuario proporcione para una base de datos determinada. Si bien las funciones de evaluación deberán seguir una interfaz ya definida, cada una podrá obtener los resultados de cualquier forma, ya que esto es transparente a nuestra componente. 踠؃ Capítulo 3. P r o y e c t o d e f i n d e c a r r e r a | 32 Capítulo 3. Un modelo distribuido para la resolución de algoritmos OCH 3.1. Arquitectura del sistema Nuestro sistema consta de tres partes diferenciadas, cuyas funciones e interconexión trataremos de explicar en profundidad en el transcurso del presente capítulo. La primera de las componentes de nuestro sistema es el MultimediaQuerier, que será el encargado de leer la base de datos RDF y las consultas del usuario, creando así, con la ayuda de las funciones de evaluación de los criterios y del peso los nodos que formarán el espacio de búsqueda del sistema. Siendo la esencia del capítulo anterior, ya fue explicada en éste, y aquí tan solo referenciaremos aquello que ya comentamos anteriormente. La segunda es el MasterQueenService, servicio web que será utilizado por ambas componentes, de forma transparente al usuario, y que hará las veces de comunicador entre el MultimediaQuerier y todos los HiveClient activos. Además está pensado este servicio web para gestionar el uso de los distintos HiveClient cuando el tamaño de espacio de búsqueda sea tan grande que una partición del mismo se haga necesaria para mejorar la calidad y la eficiencia en el cálculo de las soluciones mejores mediante el algoritmo OCH que usaremos. La tercera componente es el HiveClient, se trata de procesos clientes que serán los encargados de aplicar el algoritmo OCH al espacio de búsqueda que le proporcionará el servicio web MasterQueenService. El número de clientes HiveClient dependerá del usuario de nuestro sistema, y el uso de los mismos dependerá del tamaño del espacio de búsqueda, y de la disponibilidad de cada uno en el momento de la solicitud de trabajo por parte del servicio web. 3.1.1. Funcionamiento del sistema Como hemos comentado en el punto anterior, nuestro sistema consta de tres componentes diferenciadas que interactúan entre sí en lo que sería el transcurso de una ejecución del mismo. Las consultas son en sí la esencia de nuestro sistema, puesto que es la creación de una nueva consulta la que lanzará todo el proceso posterior de interactuación entre las distintas componentes para obtener una solución final a la consulta que sea computacionalmente satisfactoria. Una vez las funciones de evaluación y de cálculo del peso ya se encuentran en el directorio de ejecución correspondiente, y hemos transformado mediante SemWeb el archivo RDF/XML en una base de datos SQLite podremos empezar, a través del MultimediaQuerier la ejecución de nuestra aplicación. La consulta que queramos realizar se deberá introducir término a término siguiendo la estructura explicada en el segundo capítulo del presente trabajo. Una vez esta consulta sea 扠> Capítulo 3. P r o y e c t o d e f i n d e c a r r e r a | 33 definida deberá lanzarse la ejecución, que comenzará por la búsqueda en la base de datos de los sujetos relevantes para la consulta. Una vez se tengan estos sujetos se procederá a la creación de los nodos correspondientes. Todo esto dentro del MultimediaQuerier. Una vez tengamos toda la estructura de nodos, que no es más que el espacio de búsqueda del problema representado mediante la consulta, se procederá a la creación de un grafo que pueda ser interpretado por nuestro algoritmo OCH. Este grafo será almacenado en un archivo de texto, para facilitar su almacenamiento. Una vez este grafo haya sido creado se llamará a un método del servicio web MasterQueenService para registrar la localización del archivo (o archivos en caso de que el problema tenga una tamaño considerable); para terminar por hacer una llamada a otro método del servicio web que será el que se encargue de obtener el camino final. En este momento el control pasará al servicio web MasterQueenService. Este servicio tiene dos funciones principales. Por una parte se encarga de la gestión de todas las instancias de HiveClient que puedan estar en ejecución en cada momento. Por otra parte será también quien envíe solicitudes a estos clientes de obtención de soluciones a los problemas que haya podido recibir de distintas instancias de MultimediaQuerier, devolviendo a posteriori a estos mismos las mejores soluciones obtenidas. HiveClient contiene la implementación del algoritmo de hormigas. Son estos clientes los encargados del cálculo y obtención de las soluciones del problema. Han sido programados de forma que puedan trabajar de forma distribuida, cada uno de ellos con el mismo problema, distintos problemas, o distintas secciones de un mismo problema, para aquellos espacios de búsqueda de mayor tamaño. 3.2. MultimediaQuerier 3.2.1. Funcionamiento del MultimediaQuerier Como hemos contado más arriba el MultimediaQuerier se encargará de la creación del grafo que contendrá el espacio de búsqueda asociado a cada consulta que se le realice sobre la base de datos RDF/XML previamente convertida a SQLite. La estructura y funcionamiento del mismo ha sido explicada con extensión en el segundo capítulo, a la hora de describir nuestro modelo independiente de datos, con lo cual no repetiremos aquí el contenido del mismo. 3.3. MasterQueenService 皠 Capítulo 3. P r o y e c t o d e f i n d e c a r r e r a | 34 3.3.1. Funcionamiento del MasterQueenService El servicio web MasterQueenService realiza las funciones de comunicación entre el MultimediaQuerier, que definirá la consulta a realizar y por tanto el espacio de búsqueda, y los distintos clientes HiveClient, que serán los encargados de obtener una solución mediante OCH a esa consulta expuesta; también pondrá a disposición de cada una de estas dos componentes aquellos métodos que, para la facilitación de la comunicación recién comentada, sean necesarios. Así, por lo tanto, MasterQueenService proporcionará a MultimediaQuerier un método de registro de los espacios de búsqueda obtenidos a partir de las consultas realizadas, y otro método de solicitud de obtención de una solución a partir de estos mismos espacios de búsqueda. Por otro lado MasterQueenService proveerá a cada uno de los clientes HiveClient los métodos necesarios para su registro en la súper-colonia de hormigas que hará de “contenedor virtual” de los clientes en el servicio web; para el envío de los comandos a realizar por los clientes de manera independiente; para la posible devolución posterior de los resultados que los clientes pudiesen obtener; y para la desvinculación final de los clientes con el servicio web una vez su labor se haya dado por terminada. Además de estas funciones, el servicio web tendrá, en la figura de las súper-reinas (SuperQueen) una clase que se encargará de la posible integración de las soluciones otorgadas por los clientes asociados a ellas en el caso de que éstos, por ejemplo, trabajasen con distintas secciones de un problema de mayor envergadura. 3.3.2. Modelo de clases Figura 8. Modelo de clases de MasterQueenService Las distintas clases presentadas son: • SuperHive. Esta clase representa una estructura de súper-colmena, encargada de gestionar los distintos clientes HiveClient asociados al servicio web ﾀѝ Capítulo 3. P r o y e c t o d e f i n d e c a r r e r a | 35 MasterQueenService. Además contendrá también información de todas las súperreinas del sistema, las cuales serán asignadas a un conjunto de clientes cada una. • Hive. Esta clase representa las colmenas que serán en nuestra aplicación cada uno de los clientes HiveClient que hayan sido registrados en la súper-colmena SuperHive. Ellos recibirán la información relativa al espacio de búsqueda y resolverán el problema aplicando el algoritmo OCH descrito. • SuperQueen. Esta clase representa la estructura de súper-reina que estará asociada a un conjunto de clientes registrados bajo su identificador. Su labor será la de integrar las distintas soluciones proporcionadas por cada uno de los clientes en una solución global que el servicio web pueda devolver a aquél proceso que realizase la consulta correspondiente. 3.3.3. Métodos del servicio web Los métodos que el servicio web MasterQueenService proporciona son seis, y son utilizados por las otras dos componentes de nuestro sistema. El uso que del servicio hacen ambas componentes es bien diferenciado, y por tanto los métodos del mismo no serán nunca usados por ambas componentes. Los primeros cuatro servicios hacen referencia a la comunicación del servicio web MasterQueenService con los clientes HiveClient. Tratarán de establecer una secuencia de actuación a la hora de trabajar con esto clientes, y su funcionamiento queda reflejado en las siguientes líneas:  hiveAlive. Éste es el primer método utilizado por los clientes, HiveClient. La llamada al método se hace por parte de estos clientes en el momento en que quieren registrarse al servicio web MasterQueenService como clientes disponibles para posibles consultas. El método devuelve un entero, identificador del cliente en la súper-colmena (sHive) que se encarga de gestionar los clientes en el servicio web. Este identificador será único para cada uno de los HiveClients registrados en el servicio web, y será utilizado por otros métodos del servicio.  hiveReady. El método hiveReady es utilizado por los clientes cuando, una vez ya registrados en el servicio web mediante hiveAlive, quieren solicitarle al mismo la secuencia de comandos que deben llevar a cabo durante su ejecución. Estos comandos habrán sido introducidos en la cola de comandos correspondiente al identificador del cliente en cuestión, de aquí la necesidad del uso del identificador, y serán transferidos al cliente para que pueda interpretarlos y ejecutarlos secuencialmente. 節љ Capítulo 3. P r o y e c t o d e f i n d e c a r r e r a | 36 En caso de que el cliente en cuestión no tenga comandos asociados en su cola, un comando nulo será transferido al mismo.  hiveCommandsDone. El método hiveCommandsDone es utilizado por los clientes cuando quieren avisar al servicio web de que todos los comandos que previamente, mediante hiveReady le habían llegado, han sido ya realizados. Este método tiene dos parámetros. Por un lado se le dirá qué reina está asociada al cliente que haga la llamada y por otro lado se le dará la solución (en caso de haberla) que haya obtenido el cliente al aplicar el algoritmo de colonias de hormigas, que será facilitado a esa reina (SuperQueen), para una posible integración en el caso de tener un espacio de búsqueda lo suficientemente grande como para que haya sido fraccionado entre distintos clientes.  hiveDead. El método hiveDead es el último de los métodos del servicio web MasterQueenService que será utilizado por los clientes HiveClient. Éste método servirá para avisar al servicio web de la muerte del proceso cliente. Este aviso hará que el cliente correspondiente, marcado por su identificador numérico, sea eliminado de la cola de colmenas que manejará el servicio web en su clase SuperHive. Evitando así que posibles nuevos comandos sean añadidos a la cola de este cliente, y por tanto se queden sin ejecutar. Una vez estudiados los métodos del servicio web MasterQueenService que serán utilizados por los clientes HiveClient pasaremos a ver los dos métodos que serán utilizados por la componente MultimediaQuerier. En este caso los métodos tratarán de solventar la localización de los grafos correspondientes al espacio de búsqueda del problema y la posterior solicitud del MultimediaQuerier de obtención de una solución para la consulta que haya sido formulada. Una explicación del funcionamiento de ambos métodos viene a continuación:  registerGraph. El método registerGraph es un método del servicio web MasterQueenService utilizado por la componente MultimediaQuerier. Es la forma en la cual el Querier comunica al servicio web la localización del (o de los) grafo que contiene el espacio de búsqueda. Esta información es almacenada por la clase SuperHive dentro de un diccionario al que accederá en el momento en que facilite a cada cliente información al respecto de dónde se encuentra el grafo del problema sobre el que debe aplicar el algoritmo de colonias de hormigas.  obtainPath. El método obtainPath es un método del servicio web utilizado por la componente MultimediaQuerier para enviar al servicio la solicitud de obtención de un resultado. 顀 Capítulo 3. P r o y e c t o d e f i n d e c a r r e r a | 37 Esta solicitud se hará proporcionando el nodo inicial y el final, el TMax, que es el coste máximo al que puede llegar la solución y el identificador del espacio de búsqueda que habrá devuelto la llamada al método registerGraph. La llamada a obtainPath hará que SuperHive asigne a esa llamada una SuperQueen, que será la encargada de añadir a la cola de comandos aquellos que hagan que los clientes asociados a la SuperQueen realicen la ejecución del algoritmo de colonias de hormigas con los datos adecuados. Para terminar obtainPath devolverá a la componente MultimediaQuerier la solución obtenida y seleccionada por la SuperQueen encargada. 3.4. HiveClient 3.4.1. Funcionamiento del HiveClient HiveClient representa cada uno de los clientes distribuidos de los que puede hacer uso el servicio web MasterQueenService a la hora de resolver las consultas que hayan sido formuladas en la componente MultimediaQuerier. La función principal de cada uno de los clientes HiveClient será la de poner en ejecución cierta cantidad de hormigas durante un número determinado de iteraciones (que llamaremos generaciones) cada una de las cuales obtenga mediante un algoritmo OCH una solución para el problema representado por el espacio de búsqueda. Después de cada generación, la reina (Queen) del cliente deberá seleccionar la mejor solución de entre las obtenidas para todas las hormigas y sobre esa solución realizar la actualización offline correspondiente. Una vez todas las generaciones a realizar hayan terminado, el mejor resultado final será el que devuelva el cliente al servicio web. 3.4.2. Modelo de clases 節љ Capítulo 3. P r o y e c t o d e f i n d e c a r r e r a | 38 Figura 9. Modelo de clases de HiveClient Las distintas clases presentadas son:  Hive. Esta clase representa el núcleo de las aplicaciones cliente HiveClient. Por un lado es la encargada de la generación de las llamadas a los métodos del servicio web MasterQueenService en relación al registro del cliente y de la posterior solicitud de comandos a realizar. Una vez estos comandos sean recibidos, es función también de la clase Hive la interpretación de los mismos, realizando, dependiendo del comando en cuestión, la acción prevista asociada a éste. Como pueda ser la ejecución del algoritmo OCH implementado. También se encargará Hive de realizar la llamada a los métodos del servicio web MasterQueenService asociados con la entrega de resultados una vez terminado el cálculo de los mismos y de la desvinculación del cliente con el servicio web una vez toda su labor haya sido llevada a cabo exitosamente.  Queen. Esta clase representa la reina de la colmena que es el proceso HiveClient. Su función principal será la de comparar las distintas soluciones dadas por cada una de las hormigas de la colmena en una generación dada, y extraer de ellas aquella que sea mejor. 踠؃ Capítulo 3. P r o y e c t o d e f i n d e c a r r e r a | 39  Ant. Esta clase representa la esencia de nuestro trabajo. Las hormigas de la colmena formada por cada proceso cliente HiveClient. Ellas serán las encargadas de aplicar el algoritmo OCH propuesto para obtener soluciones sobre el espacio de búsqueda proporcionado a cada uno de los clientes. Cada una de las hormigas trabajará en paralelo en hilos distintos dentro de la ejecución del programa cliente. Será la clase Hive la encargada de poner en ejecución cada una de las instancias de Ant que vayan a ser lanzadas. El número de hormigas en acción vendrá dado por una variable de Hive llamada 8UMA8TS. La comunicación de la solución al hilo principal se hará a través de un Delegate desde cada uno de los hilos Ant.  5ewGraph. Esta clase representa el grafo del espacio de búsqueda del problema a resolver por el cliente HiveClient correspondiente. Contendrá este espacio de búsqueda en una matriz simétrica (además de en una lista de nodos) que habrá creado a partir del archivo de texto creado por MultimediaQuerier y cuya localización le habrá sido proporcionada por el servicio web MasterQueenService. Además de la creación del grafo del espacio de búsqueda inicial, una instancia de 8ewGraph deberá contener en todo momento el grafo actual utilizado por cada instancia de Ant, siendo este modificado por cada hormiga mediante las actualizaciones offline y online. También dentro de esta clase se obtendrá el tipo de transición que una hormiga deberá dar en un momento dado a partir de un nodo para alcanzar otro dentro de una solución, ya sea esta por exploración o por explotación.  5ode. Esta clase representa cada uno de los nodos del espacio de búsqueda del problema o de la sección del problema asignada al cliente HiveClient correspondiente. 扠> Capítulo 3. P r o y e c t o d e f i n d e c a r r e r a | 40 皠 Además de mostrar los datos duración de los álbumes adelante, la duración resulta proporcionadas por el sistema. 4.3.1. Consulta: Folk = 100 La primera consulta que realizamos consta de un solo factor, relevancia de 100 . Cabe destacar que la relevancia sólo es significativa cuando hay más de un factor en la consulta y por tanto los resultados son de idéntica índole sea cual relevancia señalada en una Figura Como comprobamos en la Figura 10 como en el Rango 5059 que la frecuencia no sea mayor para aquellos álbumes que tienen un que la cantidad de álbumes de promedio de álbumes devueltos por las soluciones (más de 20). Con lo cual es imposible que la frecuencia para esta consulta del nueve entre veinte. Sí es cierto que puest o que las 17 ocurrencias de discos con nueve de Rango 0 hacen un total de álbumes superior al total d la frecuencia con la que los álbumes devueltos pertenecen a alguno de estos dos rangos supera el 80% no es todo lo grande que ésta podía ser Por último, de la gráfica se desprende también que, como era de esperar, a medida que aumenta el rango, la frecuencia con que álbumes de llegando a un 0% para el Rango 90 Capítulo 4. P r o y e c t o d e f i n d e c a r r e r a Además de mostrar los datos citados , en las gráficas también aparecerán los promedios de duración de los álbumes separados por rango puesto que, como comentaremos más la duración resulta un factor relevante a la hora de estudia proporcionadas por el sistema. Folk = 100 La primera consulta que realizamos consta de un solo factor, genre = folk . Cabe destacar que la relevancia sólo es significativa cuando hay más de factor en la consulta y por tanto los resultados son de idéntica índole sea cual una consulta de un solo factor. Figura 10. Frecuencia. Consulta: Folk = 100 la Figura 10 , la frecu encia es muy similar tanto en el 59 y es en a mbos casos ligeramente superior al 40% que la frecuencia no sea mayor para aquellos álbumes que tienen un Rango 0 que la cantidad de álbumes de Rango 0 (nueve en este caso) es muy inferior al número promedio de álbumes devueltos por las soluciones (más de 20). Con lo cual es imposible que la frecuencia para esta consulta del Rango 0 supere el 45% que resulta de dividir o que las 17 ocurrencias de discos con Rango 50 hacen un total de álbumes superior al total d evuelto por las soluciones, la frecuencia con la que los álbumes devueltos pertenecen a alguno de estos dos rangos no es todo lo grande que ésta podía ser . Por último, de la gráfica se desprende también que, como era de esperar, a medida que aumenta el rango, la frecuencia con que álbumes de éste aparece será mucho menor, Rango 90 -100. P r o y e c t o d e f i n d e c a r r e r a | 47 , en las gráficas también aparecerán los promedios de por rango puesto que, como comentaremos más un factor relevante a la hora de estudia r las soluciones genre = folk y tiene una . Cabe destacar que la relevancia sólo es significativa cuando hay más de factor en la consulta y por tanto los resultados son de idéntica índole sea cual sea la encia es muy similar tanto en el Rango 0 mbos casos ligeramente superior al 40% . El hecho de Rango 0 es debido a en este caso) es muy inferior al número promedio de álbumes devueltos por las soluciones (más de 20). Con lo cual es imposible que resulta de dividir Rango 50 -59 sumadas a las evuelto por las soluciones, la frecuencia con la que los álbumes devueltos pertenecen a alguno de estos dos rangos , que Por último, de la gráfica se desprende también que, como era de esperar, a medida que aparece será mucho menor,   La línea que marca el peso promedio en este rango no las grandes diferencias se encuentran en rangos muy alejados del criterio mostrado sí que podría haber esta misma situación ayudado a que los rangos finales desa la solución. Figura En lo que a la saturación respecta, varias conclusiones pueden sacarse una de ellas es bastante importante ya que la veremos reflejada en Como vemos la saturación para el pesar de haber sólo 9 discos de este rango y obtener soluciones con el doble de álbumes. Esto se debe a que uno de los álbumes del género la del resto de álbumes del mismo género. El problema con la duración, que viene a ser el peso para el algoritmo de hormigas, es qu la hora de calcular el itinerario (lista de reproducción en nuestro caso) de mejor puntuación un disco que doble en duración a otros dos sólo tendrá preferencia con respecto a estos otros dos si su puntuación es mayor que la suma de las puntuaciones de los dos discos con la mitad de duración. Así si tenemos un disco con duración 120 y con una pun disco con una duración de 60 y una puntuación de 2500 y un tercero de duración igual a 60 también y de puntuación 2600, aunque el primer disco supera en prácticamente el doble la puntuación de los otros dos, el algoritmo tom de dar la solución por encima del de 120 ya que con igual duración conjunta, los discos de una hora tienen una puntuación combinada de 5100, superior a los 5000 del disco de dos horas. Una vez esto está claro, no es de extrañar que en algunas soluciones el disco de mayor duración de folk , que supera el promedio de duración de los discos en casi un 90%, no Capítulo 4. P r o y e c t o d e f i n d e c a r r e r a línea que marca el peso promedio en este rango no parece relevante por el hecho de que las grandes diferencias se encuentran en rangos muy alejados del criterio mostrado sí que podría haber esta misma situación ayudado a que los rangos finales desa Figura 11. Saturación. Consulta: Folk = 100 En lo que a la saturación respecta, varias conclusiones pueden sacarse viendo la Figura 11 bastante importante ya que la veremos reflejada en posteriores resultados. Como vemos la saturación para el Rango 0 sobrepasa el 90%, pero no llega al 100% a pesar de haber sólo 9 discos de este rango y obtener soluciones con el doble de álbumes. Esto se debe a que uno de los álbumes del género folk tiene una duración muy superior a la del resto de álbumes del mismo género. El problema con la duración, que viene a ser el peso para el algoritmo de hormigas, es qu la hora de calcular el itinerario (lista de reproducción en nuestro caso) de mejor puntuación un disco que doble en duración a otros dos sólo tendrá preferencia con respecto a estos otros dos si su puntuación es mayor que la suma de las puntuaciones de los dos discos con Así si tenemos un disco con duración 120 y con una pun tuación, pongamos de 5000, otro disco con una duración de 60 y una puntuación de 2500 y un tercero de duración igual a 60 también y de puntuación 2600, aunque el primer disco supera en prácticamente el doble la puntuación de los otros dos, el algoritmo tom aría a los dos discos de 60 minutos a la hora de dar la solución por encima del de 120 ya que con igual duración conjunta, los discos de una hora tienen una puntuación combinada de 5100, superior a los 5000 del disco de dos no es de extrañar que en algunas soluciones el disco de mayor , que supera el promedio de duración de los discos en casi un 90%, no P r o y e c t o d e f i n d e c a r r e r a | 48 relevante por el hecho de que las grandes diferencias se encuentran en rangos muy alejados del criterio mostrado , aunque sí que podría haber esta misma situación ayudado a que los rangos finales desa parezcan de viendo la Figura 11 y posteriores resultados. sobrepasa el 90%, pero no llega al 100% a pesar de haber sólo 9 discos de este rango y obtener soluciones con el doble de álbumes. una duración muy superior a El problema con la duración, que viene a ser el peso para el algoritmo de hormigas, es qu e a la hora de calcular el itinerario (lista de reproducción en nuestro caso) de mejor puntuación un disco que doble en duración a otros dos sólo tendrá preferencia con respecto a estos otros dos si su puntuación es mayor que la suma de las puntuaciones de los dos discos con tuación, pongamos de 5000, otro disco con una duración de 60 y una puntuación de 2500 y un tercero de duración igual a 60 también y de puntuación 2600, aunque el primer disco supera en prácticamente el doble la aría a los dos discos de 60 minutos a la hora de dar la solución por encima del de 120 ya que con igual duración conjunta, los discos de una hora tienen una puntuación combinada de 5100, superior a los 5000 del disco de dos no es de extrañar que en algunas soluciones el disco de mayor , que supera el promedio de duración de los discos en casi un 90%, no 節љ Capítulo 4. P r o y e c t o d e f i n d e c a r r e r a | 49 esté presente, dando lugar a una saturación cercana al 100%, pero no exactamente del 100%. El resto de la gráfica vuelve a demostrar que los resultados que podrían ser intuidos han sido obtenidos, dando así una saturación muy inferior, cercana al 50% a los discos de Rango 50-59, y menor aún en el resto de los casos. 4.3.2. Consulta: Trance = 100 La segunda consulta sobre la que hemos trabajado consta también de un solo factor, genre = Trance con relevancia 100. Hemos hecho dos consultas tan similares con el fin de demostrar empíricamente la relevancia que tiene el peso (duración) de los álbumes en el cálculo de las listas de reproducción. Como se puede comprobar en la Figura 12, los álbumes pertenecientes al rango 0 tienen una duración promedio cercana a los 120 minutos, muy por encima del resto de rangos que fluctúan entre los 40 y los 60 y pocos minutos. Esto significa que en promedio un álbum del rango 0 dura el doble que uno del resto de rangos, y por lo tanto el score debe ser el doble para que a efectos de interés para el algoritmo sea mejor que dos álbumes de los otros rangos. El número de álbumes de trance es de ocho, y el promedio de álbumes de las soluciones es de 17, con lo cual la relación entre número de álbumes del género y el total de álbumes de las soluciones es prácticamente idéntica al de la consulta folk = 100, por esto podemos intuir que el motivo por el que la frecuencia baje más de un 5% será seguramente debido al aumento del peso de los álbumes para el rango 0. En cualquier caso el comportamiento continúa siendo similar al comportamiento en la consulta anterior, si bien el rango 70-79 que apenas participaba de las soluciones para folk, sí que tiene más de un 10% de representación en las soluciones de trance = 100, seguramente debido al hecho de que sea el rango con menor peso de todos. Un total del 70% de los álbumes de la solución pertenece a los dos primeros rangos, un 12% menos que para la consulta anterior, pero aún un porcentaje bastante alto de la solución. Con el estudio de estas dos consultas podemos por tanto confirmar la relevancia de la duración, puesto que la media para trance es 118 y para folk de tan solo 55.   Figura En lo que a la saturación se refiere peso se muestra con más intensidad si cabe. Mientras que la sa de la consulta de folk era de un 94%, para esta consulta el porcentaje baja drásticamente hasta un 72%, 22 puntos. De los ocho discos del género, en las consultas con mejores resultados sólo aparecen seis, siendo en los peores caso forman parte de la solución. Además son los discos con mayor duración los que más se resisten a la hora de aparecer en las soluciones. Es tanto el descenso de la saturación, que para el rango siguiente, índice de saturación es sólo un punto menor, 71%, y para el resto de rangos la saturación siempre es mayor a la saturación de la consulta anterior. Capítulo 4. P r o y e c t o d e f i n d e c a r r e r a Figura 12. Frecuencia. Consulta: Trance = 100 En lo que a la saturación se refiere , viendo la Figura 13, comprobamos que peso se muestra con más intensidad si cabe. Mientras que la sa turación para el era de un 94%, para esta consulta el porcentaje baja drásticamente hasta un 72%, 22 puntos. De los ocho discos del género, en las consultas con mejores resultados sólo aparecen seis, siendo en los peores caso s sólo el 50% de ellos los que forman parte de la solución. Además son los discos con mayor duración los que más se resisten a la hora de aparecer en las soluciones. Es tanto el descenso de la saturación, que para el rango siguiente, rango 50 de saturación es sólo un punto menor, 71%, y para el resto de rangos la saturación siempre es mayor a la saturación de la consulta anterior. P r o y e c t o d e f i n d e c a r r e r a | 50 comprobamos que la relevancia del turación para el rango 0 era de un 94%, para esta consulta el porcentaje baja drásticamente hasta un 72%, 22 puntos. De los ocho discos del género, en las consultas con mejores s sólo el 50% de ellos los que forman parte de la solución. Además son los discos con mayor duración los que más se rango 50 -59, el de saturación es sólo un punto menor, 71%, y para el resto de rangos la saturación 節љ Figura 4.3.3. Consulta: Folk = 50; Trance = 50 A partir de esta tercera consulta, las factores. En la primera consulta hemos tratado de comprobar qué sucede cuando elegimos dos factores sobre el mismo criterio para realizarla, y además le damos la ambos. En este caso los factores han sido elegidos sobre el tipo de criterio género y sus valores son los dos valores utilizados en las consultas anteriores, con una relevancia de 50. Estos dos géneros han sido elegi géneros más representados en nuestra base de datos con 9 ocurrencias para ocurrencias para trance . El segundo es su disimilitud. La distancia entre ambos es de 95, por lo tanto los álbumes de un género estarán en el género. El tercer motivo es ver, si cabe una vez más, cómo el hecho de que una duración promedio que dobla la de como su saturac ión se vea afectada negativamente respecto a la del otro género. Para estudiar los resultados mostraremos las mismas gráficas que en las consultas anteriores, pero haciendo una gráfica de secuencia y otra de saturación distinta para cada uno de los factore s de las consultas. Así veremos primero los resultados desde el punto de vista del género folk , para posteriormente desde el punto de vista del género Capítulo 4. P r o y e c t o d e f i n d e c a r r e r a Figura 13. Saturación. Consulta: Trance = 100 4.3.3. Consulta: Folk = 50; Trance = 50 A partir de esta tercera consulta, las siguientes seis que hemos realizado ya constan de dos En la primera consulta hemos tratado de comprobar qué sucede cuando elegimos dos factores sobre el mismo criterio para realizarla, y además le damos la En este caso los factores han sido elegidos sobre el tipo de criterio género y sus valores son los dos valores utilizados en las consultas anteriores, folk Estos dos géneros han sido elegi dos por varios motivos. El primero de ellos es que son los géneros más representados en nuestra base de datos con 9 ocurrencias para . El segundo es su disimilitud. La distancia entre ambos es de 95, de un género estarán en el rango 90-100 de la gráfica del otro género. El tercer motivo es ver, si cabe una vez más, cómo el hecho de que una duración promedio que dobla la de folk hace que su frecuencia en las soluciones, así ión se vea afectada negativamente respecto a la del otro género. Para estudiar los resultados mostraremos las mismas gráficas que en las consultas anteriores, pero haciendo una gráfica de secuencia y otra de saturación distinta para cada s de las consultas. Así veremos primero los resultados desde el punto de , para posteriormente contrastarlos con los resultados obtenidos desde el punto de vista del género trance. P r o y e c t o d e f i n d e c a r r e r a | 51 seis que hemos realizado ya constan de dos En la primera consulta hemos tratado de comprobar qué sucede cuando elegimos dos factores sobre el mismo criterio para realizarla, y además le damos la misma relevancia a En este caso los factores han sido elegidos sobre el tipo de criterio género y sus y trance. Ambos dos por varios motivos. El primero de ellos es que son los géneros más representados en nuestra base de datos con 9 ocurrencias para folk y 8 . El segundo es su disimilitud. La distancia entre ambos es de 95, de la gráfica del otro género. El tercer motivo es ver, si cabe una vez más, cómo el hecho de que trance tenga hace que su frecuencia en las soluciones, así ión se vea afectada negativamente respecto a la del otro género. Para estudiar los resultados mostraremos las mismas gráficas que en las consultas anteriores, pero haciendo una gráfica de secuencia y otra de saturación distinta para cada s de las consultas. Así veremos primero los resultados desde el punto de resultados obtenidos ، Si observamos la frecuencia desde el punto de vista d vemos resultados similares a los obtenidos cuando en la consulta tan solo teníamos al género folk , con una única, pero importante excepción. Ha habido una disminución importante en la frecuencia de los rangos más cercanos al mismo rango, que ha sufrido una disminución en frecuencia de un 0.5%, el ha bajado un 6,3% y el rango 60 frecuencia que ha ido prácticamente en su totalidad (un 19 100 , que es dónde se sitúa el género trance con respecto al género Así podemos concluir que los resultados son satisfactorios en la medida que el añadir un segundo factor del mismo tipo de criterio sólo influye en soluciones anteriormente de forma relevante en los rangos en los que se sitúa el nuevo criterio de búsqueda. Seguramente el hecho de que el rango en el que se encuentra el segundo factor sea, con diferencia, aquél que más peso tiene en promedio, ha hecho qu finalmente sea de menos de un 20%, pudiendo haber sido mayor si los promedios de pesos fuesen similares. Figura 14 Cuando tomamos la saturación como muestra la Figura 15, obtenidos para la consulta aquellas observadas al estudiar la frecuencia. Es cierto que folk sigue teniendo una saturación alta, sólo cinco puntos por debajo de la saturación del rango 0 en la consulta una gran caída debido a la aparición de tantos discos pertenecientes al Así el rango 50-59 tiene una caída del 9.4%, el Capítulo 4. P r o y e c t o d e f i n d e c a r r e r a Si observamos la frecuencia desde el punto de vista d el género folk vemos resultados similares a los obtenidos cuando en la consulta tan solo teníamos al , con una única, pero importante excepción. Ha habido una disminución en la frecuencia de los rangos más cercanos al rango 0 . Empezando con este mismo rango, que ha sufrido una disminución en frecuencia de un 0.5%, el rango 60 -69 un 12,9%. Un total de un 19,7% de disminución en frecuencia que ha ido prácticamente en su totalidad (un 19 ,4%) a parar al , que es dónde se sitúa el género trance con respecto al género folk Así podemos concluir que los resultados son satisfactorios en la medida que el añadir un segundo factor del mismo tipo de criterio sólo influye en soluciones anteriormente de forma relevante en los rangos en los que se sitúa el nuevo criterio de Seguramente el hecho de que el rango en el que se encuentra el segundo factor sea, con diferencia, aquél que más peso tiene en promedio, ha hecho qu e la frecuencia del rango finalmente sea de menos de un 20%, pudiendo haber sido mayor si los promedios de pesos 14 . Frecuencia. Consulta: Folk = 50; Trance = 50 Cuando tomamos la saturación vista desde el criterio folk , comprobamos para empezar como muestra la Figura 15, que hay grandes variaciones con respecto a los resultados obtenidos para la consulta folk = 100 , variaciones mucho más significativas que aquellas observadas al estudiar la frecuencia. sigue teniendo una saturación alta, sólo cinco puntos por debajo de la en la consulta folk = 100 , pero los rangos cercanos sufren una gran caída debido a la aparición de tantos discos pertenecientes al tiene una caída del 9.4%, el rango 60-69 del 21.1% y el P r o y e c t o d e f i n d e c a r r e r a | 52 folk en la Figura 14, vemos resultados similares a los obtenidos cuando en la consulta tan solo teníamos al , con una única, pero importante excepción. Ha habido una disminución . Empezando con este mismo rango, que ha sufrido una disminución en frecuencia de un 0.5%, el rango 50-59 un 12,9%. Un total de un 19,7% de disminución en ,4%) a parar al rango 90folk . Así podemos concluir que los resultados son satisfactorios en la medida que el añadir un segundo factor del mismo tipo de criterio sólo influye en soluciones obtenidas anteriormente de forma relevante en los rangos en los que se sitúa el nuevo criterio de Seguramente el hecho de que el rango en el que se encuentra el segundo factor sea, con e la frecuencia del rango finalmente sea de menos de un 20%, pudiendo haber sido mayor si los promedios de pesos . Frecuencia. Consulta: Folk = 50; Trance = 50 , comprobamos para empezar , hay grandes variaciones con respecto a los resultados , variaciones mucho más significativas que sigue teniendo una saturación alta, sólo cinco puntos por debajo de la , pero los rangos cercanos sufren una gran caída debido a la aparición de tantos discos pertenecientes al rango 90-100. del 21.1% y el rango 覀љ 70-79 del 5%. El hecho de que ver exclusivamente con el bajo número de álbumes que tiene este rango, tan sólo 3, con lo qu e su saturación es alta aún teniendo en promedio menos álbumes en las soluciones que el rango 60-69. En el lado positivo de la balanza la situación del segundo factor de la consulta 90-100 ). El último rango alto peso promedio. Además el Figura 15 Cuando cambiamos la perspectiva y nos centramos en el género trance encontramos con la confirmación de todo aquello que habíamos visto desde el folk. El hecho de que el peso promedio para el cualquier otro rango ha hecho que la frecuencia se quede por debajo del 15%. Menos de uno de cada cinco discos de la solución era de de folk. La solución promedio tenía alrededor de 20 disco rango 0 fue de cuatro. Completamente opuesta es la situación para el rango más grande, el que se encuentra el género folk en todas nuestras pruebas. Capítulo 4. P r o y e c t o d e f i n d e c a r r e r a del 5%. El hecho de que el rango 70-79 tenga mayor representación tiene que ver exclusivamente con el bajo número de álbumes que tiene este rango, tan sólo 3, con lo e su saturación es alta aún teniendo en promedio menos álbumes en las soluciones que el lado positivo de la balanza se sitúan los rangos más lejanos, que se ven influidos por la situación del segundo factor de la consulta (como ya hemos mencionado ). El último rango pasa de tener un 0% de saturación a tener un 17.3%, alto peso promedio. Además el rango 80-89 sube hasta el 5%, justo el doble. 15 . Saturación. Consulta: Folk = 50 ; Trance = 50 Cuando cambiamos la perspectiva y nos centramos en el género trance confirmación de todo aquello que habíamos visto desde el El hecho de que el peso promedio para el rango 0 sea prácticamen te el doble que el de cualquier otro rango ha hecho que la frecuencia se quede por debajo del 15%. Menos de uno de cada cinco discos de la solución era de trance , mientras que casi la mitad lo eran La solución promedio tenía alrededor de 20 disco s, de los cuales, el máximo de discos del Completamente opuesta es la situación para el rango más grande, rango 90 género folk y que representa entre 9 y 10 discos de la solución P r o y e c t o d e f i n d e c a r r e r a | 53 tenga mayor representación tiene que ver exclusivamente con el bajo número de álbumes que tiene este rango, tan sólo 3, con lo e su saturación es alta aún teniendo en promedio menos álbumes en las soluciones que el los rangos más lejanos, que se ven influidos por mencionado en el rango pasa de tener un 0% de saturación a tener un 17.3%, pese a su sube hasta el 5%, justo el doble. ; Trance = 50 en la Figura 16, nos confirmación de todo aquello que habíamos visto desde el género te el doble que el de cualquier otro rango ha hecho que la frecuencia se quede por debajo del 15%. Menos de , mientras que casi la mitad lo eran s, de los cuales, el máximo de discos del rango 90 – 100 en y que representa entre 9 y 10 discos de la solución ، Capítulo 4. P r o y e c t o d e f i n d e c a r r e r a | 54 Figura 16. Frecuencia. Consulta: Folk = 50; Trance = 50 Pasamos a la saturación de la Figura 17 para ver mejor si cabe cómo ha afectado el peso del rango 0 en la solución. Tenemos sorprendentemente que el único rango que tiene una saturación superior al 50% es el rango 70 – 79. Aquí es donde el problema del peso del rango 0 ha hecho desvirtuarse más si cabe la solución. Y es que estos datos pueden parecer bastante malos si no somos conscientes de que en realidad, simplemente la balanza se inclina más hacia los rangos más lejanos por la influencia de la distancia con el folk. Al tener el rango 90 – 100 treinta y un discos, es imposible ver en la saturación el volumen de este, que ya vimos en la frecuencia, y nos tenemos que quedar con una gráfica claramente desequilibrada hacia el centro. ، Figura 17 4.3.4. Consulta: Folk = 8 0; Trance = En la siguiente consulta realizada decidimos, partiendo de la consul el verdadero peso de la relevancia en los resultados obtenidos. Si en la anterior consulta tanto ocasión hemos decidido dar al primer género una relevancia cuatro veces mayor a la segundo término (80 frente a balanza del lado del folk A l tomar la frecuencia vista desde el término folk nos damos cuenta de que efe ésta ha subido considerablemente para los rangos más cercanos al género con mayor relevancia. La frecuencia del rango 0 era del 40,8% cuando ambos criterios compartían relevancia, pero ahora, el rango que determina los discos de género Folk sube puntos que le dejan muy cerca de la mitad de los discos de la solución. El siguiente rango, el más cercano a Folk pero sin serlo sube también una cantidad similar, un 4.0% hasta el 38.7% mientras que el gran perjudicado es sin du rango en el que se encuentra el género Trance, cuya disminución en relevancia le hace pasar de una frecuencia del 19.4% a una frecuencia del 4.3%, más de 15 puntos perdidos al pasar de 50 a 20 en relevancia. Capítulo 4. P r o y e c t o d e f i n d e c a r r e r a 17 . Saturación. Consulta: Folk = 50; Trance = 50 0; Trance = 20 En la siguiente consulta realizada decidimos, partiendo de la consul ta anterior, comprobar el verdadero peso de la relevancia en los resultados obtenidos. Si en la anterior consulta tanto Folk como Trance tenían una relevancia de ocasión hemos decidido dar al primer género una relevancia cuatro veces mayor a la frente a 20 ) con la esperanza de que esto decante más si cabe la que, recordemos, ya se beneficiaba de su menor peso promedio. l tomar la frecuencia vista desde el término folk nos damos cuenta de que efe ésta ha subido considerablemente para los rangos más cercanos al género con mayor La frecuencia del rango 0 era del 40,8% cuando ambos criterios compartían relevancia, pero ahora, el rango que determina los discos de género Folk sube hasta el 46.2%, casi seis puntos que le dejan muy cerca de la mitad de los discos de la solución. El siguiente rango, el más cercano a Folk pero sin serlo sube también una cantidad similar, un 4.0% hasta el 38.7% mientras que el gran perjudicado es sin du da el rango 90 rango en el que se encuentra el género Trance, cuya disminución en relevancia le hace pasar de una frecuencia del 19.4% a una frecuencia del 4.3%, más de 15 puntos perdidos al en relevancia. P r o y e c t o d e f i n d e c a r r e r a | 55 . Saturación. Consulta: Folk = 50; Trance = 50 ta anterior, comprobar tenían una relevancia de 50, en esta ocasión hemos decidido dar al primer género una relevancia cuatro veces mayor a la del ) con la esperanza de que esto decante más si cabe la que, recordemos, ya se beneficiaba de su menor peso promedio. l tomar la frecuencia vista desde el término folk nos damos cuenta de que efe ctivamente ésta ha subido considerablemente para los rangos más cercanos al género con mayor La frecuencia del rango 0 era del 40,8% cuando ambos criterios compartían relevancia, hasta el 46.2%, casi seis El siguiente rango, el más cercano a Folk pero sin serlo sube también una cantidad similar, da el rango 90 -100, rango en el que se encuentra el género Trance, cuya disminución en relevancia le hace pasar de una frecuencia del 19.4% a una frecuencia del 4.3%, más de 15 puntos perdidos al 躈؃ Figura 18 Similares son los resultados del rango de Trance en lo que a saturación se refiere. Si antes se incluía en la solución casi uno de cada cinco discos del rango máximo de separación con respecto a Folk (un 17,2%), ahora esta cifra cae en picado hasta el 3,6%, ligeramente menos de 15 puntos perdidos. La cara de la moneda es folk, el género que ya contaba con un 88,9% de saturación la lleva ya hasta el 95,6%. De los nueve discos del género, en más de la m queda ninguno fuera de la solución final. Aumentar la relevancia a folk ha hecho que el género haya aumentado de una forma muy notable, casi diríamos que drástica, su presencia en la solución en detrimento del género que baja su re levancia hasta una cuarta parte de la de folk, el Trance. Vamos ahora a ver ambas gráficas desde el punto de vista del género que ha sufrido las pérdidas, para ver si efectivamente son tan desoladoras como el rango 90 hacen intuir. Capítulo 4. P r o y e c t o d e f i n d e c a r r e r a 18 . Frecuencia. Consulta: Folk = 80; Trance = 20 Similares son los resultados del rango de Trance en lo que a saturación se refiere. Si antes se incluía en la solución casi uno de cada cinco discos del rango máximo de separación con (un 17,2%), ahora esta cifra cae en picado hasta el 3,6%, ligeramente menos de 15 puntos perdidos. La cara de la moneda es folk, el género que ya contaba con un 88,9% de saturación la lleva ya hasta el 95,6%. De los nueve discos del género, en más de la m itad de las ocasiones no queda ninguno fuera de la solución final. Aumentar la relevancia a folk ha hecho que el género haya aumentado de una forma muy notable, casi diríamos que drástica, su presencia en la solución en detrimento del género levancia hasta una cuarta parte de la de folk, el Trance. Vamos ahora a ver ambas gráficas desde el punto de vista del género que ha sufrido las pérdidas, para ver si efectivamente son tan desoladoras como el rango 90 P r o y e c t o d e f i n d e c a r r e r a | 56 . Frecuencia. Consulta: Folk = 80; Trance = 20 Similares son los resultados del rango de Trance en lo que a saturación se refiere. Si antes se incluía en la solución casi uno de cada cinco discos del rango máximo de separación con (un 17,2%), ahora esta cifra cae en picado hasta el 3,6%, ligeramente La cara de la moneda es folk, el género que ya contaba con un 88,9% de saturación la lleva itad de las ocasiones no Aumentar la relevancia a folk ha hecho que el género haya aumentado de una forma muy notable, casi diríamos que drástica, su presencia en la solución en detrimento del género Vamos ahora a ver ambas gráficas desde el punto de vista del género que ha sufrido las pérdidas, para ver si efectivamente son tan desoladoras como el rango 90 -100 sobre Folk ◌، Figura 25 . Saturación. Consulta: Folk = 50; Javier Krahe = 50 4.3.6. Cons ulta: Folk = 80; Javier Krahe = 20 Volvemos a repetir aquello que hicimos para la consulta cuyos términos eran Folk y Trance para la consulta actual, modificando las relevancias para que éstas dejen de ser idénticas. En esta ocasión hemos decidido volver a este caso, de Javier Krahe. Con esto, la presencia del artista Javier Krahe puede verse perjudicada, pero el género Folk debería tener una presencia aún mayor en las soluciones de la que tenían en la anteri la gráfica de frecuencia del término. Y esto es lo primero que comprobamos con dicha gráfica, la gráfica de frecuencia de la consulta vista desde el valor Folk. Es curioso, al estudiar la gráf Krahe = 50, ver que hay dos desplazamientos de frecuencia en la misma. Por una parte, y como habíamos previsto, la frecuencia del rango 0 se dispara, superando el 50% para terminar con un 51.9%. género Folk. Y parece que es sencillamente el rango 50 que ahora son de Folk, ya que baja de un 39.0% a un 29.6%, casi un 10% que concuerda prácticamente con el 8% que El otro desplazamiento de frecuencias ha sido curiosamente hacia el rango 60 rango ha subido del 11.0% hasta el 16.0%, cinco puntos que básicamente se deben a la práctica desaparición (más si cabe) de los rangos posteriores 0.0% y 1.2% a tener un 2.5%, 0.0% y 0.0% respectivamente. En cualquier caso este 16% sigue estando muy por debajo del 29.6% del rango 50 claramente mayor. Capítulo 4. P r o y e c t o d e f i n d e c a r r e r a . Saturación. Consulta: Folk = 50; Javier Krahe = 50 ulta: Folk = 80; Javier Krahe = 20 Volvemos a repetir aquello que hicimos para la consulta cuyos términos eran Folk y Trance para la consulta actual, modificando las relevancias para que éstas dejen de ser idénticas. En esta ocasión hemos decidido volver a dar a Folk la mayor relevancia en detrimento, en este caso, de Javier Krahe. Con esto, la presencia del artista Javier Krahe puede verse perjudicada, pero el género Folk debería tener una presencia aún mayor en las soluciones de la que tenían en la anteri or consulta. Haciendo por tanto decantarse más hacia el rango 0 la gráfica de frecuencia del término. Y esto es lo primero que comprobamos con dicha gráfica, la gráfica de frecuencia de la consulta vista desde el valor Folk. Es curioso, al estudiar la gráf ica y compararla con aquella de la consulta Folk = 50; Javier Krahe = 50, ver que hay dos desplazamientos de frecuencia en la misma. Por una parte, y como habíamos previsto, la frecuencia del rango 0 se dispara, superando el 50% para terminar con un 51.9%. Más de la mitad de los discos de la solución son de género Folk. Y parece que es sencillamente el rango 50 - 59 aquel que ha perdido los discos que ahora son de Folk, ya que baja de un 39.0% a un 29.6%, casi un 10% que concuerda prácticamente con el 8% que ha mejorado el rango 0. El otro desplazamiento de frecuencias ha sido curiosamente hacia el rango 60 rango ha subido del 11.0% hasta el 16.0%, cinco puntos que básicamente se deben a la práctica desaparición (más si cabe) de los rangos posteriores que pasan de tener un 4.9%, 0.0% y 1.2% a tener un 2.5%, 0.0% y 0.0% respectivamente. En cualquier caso este 16% sigue estando muy por debajo del 29.6% del rango 50 - 59, que tiene una presencia P r o y e c t o d e f i n d e c a r r e r a | 63 . Saturación. Consulta: Folk = 50; Javier Krahe = 50 Volvemos a repetir aquello que hicimos para la consulta cuyos términos eran Folk y Trance para la consulta actual, modificando las relevancias para que éstas dejen de ser idénticas. dar a Folk la mayor relevancia en detrimento, en este caso, de Javier Krahe. Con esto, la presencia del artista Javier Krahe puede verse perjudicada, pero el género Folk debería tener una presencia aún mayor en las soluciones or consulta. Haciendo por tanto decantarse más hacia el rango 0 Y esto es lo primero que comprobamos con dicha gráfica, la gráfica de frecuencia de la ica y compararla con aquella de la consulta Folk = 50; Javier Krahe = 50, ver que hay dos desplazamientos de frecuencia en la misma. Por una parte, y como habíamos previsto, la frecuencia del rango 0 se dispara, superando el Más de la mitad de los discos de la solución son de 59 aquel que ha perdido los discos que ahora son de Folk, ya que baja de un 39.0% a un 29.6%, casi un 10% que concuerda El otro desplazamiento de frecuencias ha sido curiosamente hacia el rango 60 -69. Este rango ha subido del 11.0% hasta el 16.0%, cinco puntos que básicamente se deben a la que pasan de tener un 4.9%, 0.0% y 1.2% a tener un 2.5%, 0.0% y 0.0% respectivamente. En cualquier caso este 16% 59, que tiene una presencia 踠؃- Figura 26 . Frecue Si ya estábamos muy satisfechos en la consulta anterior con la saturación del término Folk, que había llegado hasta un 80%, gracias al aumento de su relevancia conseguimos alcanzar una saturación aún mucho mayor Folk aparecieron en el 40% de las soluciones obtenidas, mientras que en ninguna de las soluciones faltaron dos o más discos de este género. En lo que al resto de los rangos se refiere, vemos resultados satisfactorios que en la consulta anterior, muestra del aumento en relevancia también. Nos referimos a que la saturación siempre desciende a medida que nos alejamos del rango 0. Cosa que no sucedía en el caso anterior donde el rango 6 rango 7079, al igual que el rango 80 En este caso las saturaciones a partir del rango 50 13.3% 0.0% y 0.0%. Capítulo 4. P r o y e c t o d e f i n d e c a r r e r a . Frecue ncia. Consulta: Folk = 80; Javier Krahe = 20 Si ya estábamos muy satisfechos en la consulta anterior con la saturación del término Folk, que había llegado hasta un 80%, gracias al aumento de su relevancia conseguimos alcanzar una saturación aún mucho mayor . Nada menos que un 93.3%. Los nueve discos del género Folk aparecieron en el 40% de las soluciones obtenidas, mientras que en ninguna de las soluciones faltaron dos o más discos de este género. En lo que al resto de los rangos se refiere, vemos resultados que nos resultan más satisfactorios que en la consulta anterior, muestra del aumento en relevancia también. Nos referimos a que la saturación siempre desciende a medida que nos alejamos del rango 0. Cosa que no sucedía en el caso anterior donde el rango 6 069 tenía menor saturación que el 79, al igual que el rango 80 - 89 tenía menor saturación que el 90 En este caso las saturaciones a partir del rango 50 - 59 son respectivamente 28.2%, 21.7%, P r o y e c t o d e f i n d e c a r r e r a | 64 ncia. Consulta: Folk = 80; Javier Krahe = 20 Si ya estábamos muy satisfechos en la consulta anterior con la saturación del término Folk, que había llegado hasta un 80%, gracias al aumento de su relevancia conseguimos alcanzar . Nada menos que un 93.3%. Los nueve discos del género Folk aparecieron en el 40% de las soluciones obtenidas, mientras que en ninguna de las que nos resultan más satisfactorios que en la consulta anterior, muestra del aumento en relevancia también. Nos referimos a que la saturación siempre desciende a medida que nos alejamos del rango 0. 69 tenía menor saturación que el 89 tenía menor saturación que el 90 -100. 59 son respectivamente 28.2%, 21.7%, 狐 Figura 27 . Saturación. Consulta: Folk = 80; Javier Krahe = 20 Una vez ya hemos comprobado los beneficios que la modificación de la relevancia ha tenido sobre el término Folk, tenemos que comprobar los perjuicios que pueda haber sufrido el término Javier Krahe. Y lo cierto es que ya desde inicio se comprueba que estos perjuicios han sido más bien nulos. De hecho, para el rango 0, la consulta ha aumentado su frecuencia con respecto a aquella que tenía idéntica relevancia en 1.5 puntos. El hecho de que, al contrario ocasión los resultados no suponen pérdidas para el término desfavorecido, aunque sí que suponen mejoras para el término favorecido, nos hace intuir que el tener una consulta con términos relacion ados (como ya hemos comentado, todos los discos del autor Javier Krahe pertenecen al género folk) es mucho más importante de cara a la adecuación de la solución final a aquello esperado. Algo que por otro lado es lógico, pues si nuestra consulta es heterog énea, la lista de reproducción que resulte de aplicar nuestro algoritmo lo será igualmente. Capítulo 4. P r o y e c t o d e f i n d e c a r r e r a . Saturación. Consulta: Folk = 80; Javier Krahe = 20 Una vez ya hemos comprobado los beneficios que la modificación de la relevancia ha tenido sobre el término Folk, tenemos que comprobar los perjuicios que pueda haber sufrido el término Javier Krahe. lo cierto es que ya desde inicio se comprueba que estos perjuicios han sido más bien nulos. De hecho, para el rango 0, la consulta ha aumentado su frecuencia con respecto a aquella que tenía idéntica relevancia en 1.5 puntos. El hecho de que, al contrario de lo que sucediese en la consulta de folk y trance, en esta ocasión los resultados no suponen pérdidas para el término desfavorecido, aunque sí que suponen mejoras para el término favorecido, nos hace intuir que el tener una consulta con ados (como ya hemos comentado, todos los discos del autor Javier Krahe pertenecen al género folk) es mucho más importante de cara a la adecuación de la solución final a aquello esperado. Algo que por otro lado es lógico, pues si nuestra consulta es énea, la lista de reproducción que resulte de aplicar nuestro algoritmo lo será P r o y e c t o d e f i n d e c a r r e r a | 65 . Saturación. Consulta: Folk = 80; Javier Krahe = 20 Una vez ya hemos comprobado los beneficios que la modificación de la relevancia ha tenido sobre el término Folk, tenemos que comprobar los perjuicios que pueda haber lo cierto es que ya desde inicio se comprueba que estos perjuicios han sido más bien nulos. De hecho, para el rango 0, la consulta ha aumentado su frecuencia con respecto a de lo que sucediese en la consulta de folk y trance, en esta ocasión los resultados no suponen pérdidas para el término desfavorecido, aunque sí que suponen mejoras para el término favorecido, nos hace intuir que el tener una consulta con ados (como ya hemos comentado, todos los discos del autor Javier Krahe pertenecen al género folk) es mucho más importante de cara a la adecuación de la solución final a aquello esperado. Algo que por otro lado es lógico, pues si nuestra consulta es énea, la lista de reproducción que resulte de aplicar nuestro algoritmo lo será ،ڸ Figura 28 . Frecuencia. Consulta: Folk = 80; Javier Krahe = 20 Al comprobar la saturación de esta consulta nos damos realmente cuenta de q sucedido. En absolutamente todas las soluciones que hemos obtenido han aparecido los cuatro discos cuyo autor es Javier Krahe, sin excepción. Así, se han obtenido las frecuencias y saturaciones máximas para el rango 0 por primera vez en nuestro estud io, a pesar de que el término que ha conseguido esto tuviese una relevancia cuatro veces inferior al término dominante. Puede surgir la duda de por qué esta frecuencia/saturación máxima no ha sucedido cuando los dos términos de la consulta tenían la misma La explicación seguramente venga del hecho de que, mientras que el rango 0 visto desde el término Javier Krahe contiene solo 4 de 9 discos de género Folk, el rango 0 desde el término Folk sí contiene los 4 discos de autor Javier Krahe. Capítulo 4. P r o y e c t o d e f i n d e c a r r e r a . Frecuencia. Consulta: Folk = 80; Javier Krahe = 20 Al comprobar la saturación de esta consulta nos damos realmente cuenta de q sucedido. En absolutamente todas las soluciones que hemos obtenido han aparecido los cuatro discos cuyo autor es Javier Krahe, sin excepción. Así, se han obtenido las frecuencias y saturaciones máximas para el rango 0 por primera io, a pesar de que el término que ha conseguido esto tuviese una relevancia cuatro veces inferior al término dominante. Puede surgir la duda de por qué esta frecuencia/saturación máxima no ha sucedido cuando los dos términos de la consulta tenían la misma relevancia. La explicación seguramente venga del hecho de que, mientras que el rango 0 visto desde el término Javier Krahe contiene solo 4 de 9 discos de género Folk, el rango 0 desde el término Folk sí contiene los 4 discos de autor Javier Krahe. P r o y e c t o d e f i n d e c a r r e r a | 66 . Frecuencia. Consulta: Folk = 80; Javier Krahe = 20 Al comprobar la saturación de esta consulta nos damos realmente cuenta de q ué ha sucedido. En absolutamente todas las soluciones que hemos obtenido han aparecido los Así, se han obtenido las frecuencias y saturaciones máximas para el rango 0 por primera io, a pesar de que el término que ha conseguido esto tuviese una Puede surgir la duda de por qué esta frecuencia/saturación máxima no ha sucedido cuando La explicación seguramente venga del hecho de que, mientras que el rango 0 visto desde el término Javier Krahe contiene solo 4 de 9 discos de género Folk, el rango 0 desde el   Figura 29 . Saturación. Consulta: Folk = 80; Javier Krahe = 20 4.3.7. Consulta: Folk = 50; Armin Van Buuren = 50 Pasamos a la última consulta, de la cual veremos dos variaciones de nuevo basadas en la relevancia. Se trata de una consulta la categoría autor, como en la ocasión anterior. En este lugar la diferencia es que el autor es Armin Van Buuren, autor cuyos discos figuran en el género Trance, que se encuentra en el rango 90 En esta consulta esperamos por tanto resultados similares a los que tuvimos para la consulta Folk = 50; Trance = 50, con la diferencia de que Armin Van Buuren apenas cuenta con tres discos de los ocho con los que cuenta el género Trance. Adem ás, si el género Trance ya contaba con un peso promedio de alrededor de 120, en esta ocasión aún va a más este factor con un peso promedio de casi 150. La primera cosa que cabe destacar de los resultados de esta consulta es que con respecto a la variante q ue incluía a Folk y a Trance hemos pasado a incluir 22.2 discos en la solución promedia, por 19.6. Esto, unido al aumento descarado del peso promedio del rango 0 del término Armin Van Buuren nos hace prever en cierto modo el camino que tomarán las soluciones obtenidas. La frecuencia del 37% del rango 0 del término Folk no tiene que confundirnos comparada con el 41% para la consulta con que lo estamos comparando, y es que el aumento en tres puntos del número de discos de la solución ha hecho que esta frecuen pesar de haberse aumentado la cantidad de discos de Folk en la solución promedia. Capítulo 4. P r o y e c t o d e f i n d e c a r r e r a . Saturación. Consulta: Folk = 80; Javier Krahe = 20 4.3.7. Consulta: Folk = 50; Armin Van Buuren = 50 Pasamos a la última consulta, de la cual veremos dos variaciones de nuevo basadas en la relevancia. Se trata de una consulta con dos términos, uno de la categoría género y otro de la categoría autor, como en la ocasión anterior. En este lugar la diferencia es que el autor es Armin Van Buuren, autor cuyos discos figuran en el género Trance, que se encuentra en el rango 90 -100 res pecto a Folk. En esta consulta esperamos por tanto resultados similares a los que tuvimos para la consulta Folk = 50; Trance = 50, con la diferencia de que Armin Van Buuren apenas cuenta con tres discos de los ocho con los que cuenta el género Trance. ás, si el género Trance ya contaba con un peso promedio de alrededor de 120, en esta ocasión aún va a más este factor con un peso promedio de casi 150. La primera cosa que cabe destacar de los resultados de esta consulta es que con respecto a ue incluía a Folk y a Trance hemos pasado a incluir 22.2 discos en la solución promedia, por 19.6. Esto, unido al aumento descarado del peso promedio del rango 0 del término Armin Van Buuren nos hace prever en cierto modo el camino que tomarán las La frecuencia del 37% del rango 0 del término Folk no tiene que confundirnos comparada con el 41% para la consulta con que lo estamos comparando, y es que el aumento en tres puntos del número de discos de la solución ha hecho que esta frecuen cia sea menor, aun a pesar de haberse aumentado la cantidad de discos de Folk en la solución promedia. P r o y e c t o d e f i n d e c a r r e r a | 67 . Saturación. Consulta: Folk = 80; Javier Krahe = 20 Pasamos a la última consulta, de la cual veremos dos variaciones de nuevo basadas en la con dos términos, uno de la categoría género y otro de En este lugar la diferencia es que el autor es Armin Van Buuren, autor cuyos discos figuran pecto a Folk. En esta consulta esperamos por tanto resultados similares a los que tuvimos para la consulta Folk = 50; Trance = 50, con la diferencia de que Armin Van Buuren apenas cuenta con tres ás, si el género Trance ya contaba con un peso promedio de alrededor de 120, en esta La primera cosa que cabe destacar de los resultados de esta consulta es que con respecto a ue incluía a Folk y a Trance hemos pasado a incluir 22.2 discos en la solución promedia, por 19.6. Esto, unido al aumento descarado del peso promedio del rango 0 del término Armin Van Buuren nos hace prever en cierto modo el camino que tomarán las La frecuencia del 37% del rango 0 del término Folk no tiene que confundirnos comparada con el 41% para la consulta con que lo estamos comparando, y es que el aumento en tres cia sea menor, aun a pesar de haberse aumentado la cantidad de discos de Folk en la solución promedia. 슰؁ El rango 90100, en el que se encuentran los discos del otro término también sufre una disminución de su frecuencia, en este caso mucho más importante, p puntos estamos hablando de 12 puntos menos. Figura 30 . Frecuencia. Consulta: Folk = 50; Armin Van Buuren = 50 Al ver la saturación comprobamos como efectivamente los resultados de la frecuencia del rango 0 no tenían que preocuparnos. Esta ha aumentado hasta el 91.1%. Un pequeño aumento, pero no obstante un aumento. El resto de los rangos, con la excepción de los dos últimos también aumentan su saturación, además de forma considerable, con 11, 21 y 13 puntos rango 90100 también baja en esta ocasión un total de 10 puntos. Todos estos datos del rango 90 encima del doble del peso medio, nos hacen prever que el segundo tér va a verse gravemente dañado en esta ocasión. Capítulo 4. P r o y e c t o d e f i n d e c a r r e r a 100, en el que se encuentran los discos del otro término también sufre una disminución de su frecuencia, en este caso mucho más importante, p ues en lugar de cuatro puntos estamos hablando de 12 puntos menos. . Frecuencia. Consulta: Folk = 50; Armin Van Buuren = 50 Al ver la saturación comprobamos como efectivamente los resultados de la frecuencia del no tenían que preocuparnos. Esta ha aumentado hasta el 91.1%. Un pequeño aumento, pero no obstante un aumento. El resto de los rangos, con la excepción de los dos últimos también aumentan su saturación, además de forma considerable, con 11, 21 y 13 puntos respectivamente, mientras que el 100 también baja en esta ocasión un total de 10 puntos. Todos estos datos del rango 90 - 100 unidos al peso de los discos de Armin Van Buuren, por encima del doble del peso medio, nos hacen prever que el segundo tér va a verse gravemente dañado en esta ocasión. P r o y e c t o d e f i n d e c a r r e r a | 68 100, en el que se encuentran los discos del otro término también sufre una ues en lugar de cuatro . Frecuencia. Consulta: Folk = 50; Armin Van Buuren = 50 Al ver la saturación comprobamos como efectivamente los resultados de la frecuencia del no tenían que preocuparnos. Esta ha aumentado hasta el 91.1%. Un pequeño El resto de los rangos, con la excepción de los dos últimos también aumentan su saturación, respectivamente, mientras que el 100 unidos al peso de los discos de Armin Van Buuren, por encima del doble del peso medio, nos hacen prever que el segundo tér mino de la consulta ،ڱ Figura 31 . Saturación. Consulta: Folk = 50; Armin Van Buuren = 50 Y efectivamente nos encontramos con un panorama que seguramente supera aquello que habíamos podid o llegar a pensar. El peso de los discos que tienen como autor a Armin Van Buuren es un factor negativo tan relevante que la presencia en las soluciones de los discos en cuestión es nula. Ninguno de los tres discos aparece en ninguna de las soluciones obte punto tan extremo del peso promedio de un rango hace que éste, a pesar de formar parte de la consulta, no aparezca. De aquí que sea tan importante darle el valor necesario al peso a la hora de definir un ámbito de trabajo. Es mejor i consulta si estos discos tienen un peso que no sea tan prohibitivo. Así, para el rango 5059, ya tenemos una frecuencia del 8.1%, gracias a que su peso promedio baja más de 60 puntos, un 40% Capítulo 4. P r o y e c t o d e f i n d e c a r r e r a . Saturación. Consulta: Folk = 50; Armin Van Buuren = 50 Y efectivamente nos encontramos con un panorama que seguramente supera aquello que o llegar a pensar. El peso de los discos que tienen como autor a Armin Van Buuren es un factor negativo tan relevante que la presencia en las soluciones de los discos Ninguno de los tres discos aparece en ninguna de las soluciones obte nidas. punto tan extremo del peso promedio de un rango hace que éste, a pesar de formar parte de De aquí que sea tan importante darle el valor necesario al peso a la hora de definir un ámbito de trabajo. Es mejor i ncluir, en este caso, discos de rangos cercanos al rango 0 de la consulta si estos discos tienen un peso que no sea tan prohibitivo. 59, ya tenemos una frecuencia del 8.1%, gracias a que su peso promedio baja más de 60 puntos, un 40% aproximadamente. P r o y e c t o d e f i n d e c a r r e r a | 69 . Saturación. Consulta: Folk = 50; Armin Van Buuren = 50 Y efectivamente nos encontramos con un panorama que seguramente supera aquello que o llegar a pensar. El peso de los discos que tienen como autor a Armin Van Buuren es un factor negativo tan relevante que la presencia en las soluciones de los discos nidas. La llegada a un punto tan extremo del peso promedio de un rango hace que éste, a pesar de formar parte de De aquí que sea tan importante darle el valor necesario al peso a la hora de definir un ncluir, en este caso, discos de rangos cercanos al rango 0 de la 59, ya tenemos una frecuencia del 8.1%, gracias a que su peso ˁ Figura 32 . Frecuencia. Consulta: Folk = 50; Armin Van Buuren = 50 Al enfocar la saturación vemos cómo el peso en esta consulta ha tenido realmente una relevancia que va mucho más allá de hacer desaparecer al ran Podemos comprobar cómo, en cierto punto la gráfica de saturación tiene una curvatura casi simétrica a la del peso hasta que llegamos al rango 70 consigue una saturación del 74.5%. A partir de ahí las saturaciones a ambos lados se asemejan algo, con el rango 60 rango 8089 saturando en un 31.1% y 29.6% respectivamente y los rangos 50 un 13.8% y un 17.5% respectivamente. Figura 33 . Saturación. Consulta: Fol Capítulo 4. P r o y e c t o d e f i n d e c a r r e r a . Frecuencia. Consulta: Folk = 50; Armin Van Buuren = 50 Al enfocar la saturación vemos cómo el peso en esta consulta ha tenido realmente una relevancia que va mucho más allá de hacer desaparecer al ran go 0 de la solución. Podemos comprobar cómo, en cierto punto la gráfica de saturación tiene una curvatura casi simétrica a la del peso hasta que llegamos al rango 70 - 79 que, a pesar de tener 11 discos, consigue una saturación del 74.5%. saturaciones a ambos lados se asemejan algo, con el rango 60 89 saturando en un 31.1% y 29.6% respectivamente y los rangos 50 un 13.8% y un 17.5% respectivamente. . Saturación. Consulta: Fol k = 50; Armin Van Buuren = 50 P r o y e c t o d e f i n d e c a r r e r a | 70 . Frecuencia. Consulta: Folk = 50; Armin Van Buuren = 50 Al enfocar la saturación vemos cómo el peso en esta consulta ha tenido realmente una go 0 de la solución. Podemos comprobar cómo, en cierto punto la gráfica de saturación tiene una curvatura casi 79 que, a pesar de tener 11 discos, saturaciones a ambos lados se asemejan algo, con el rango 60 -69 y el 89 saturando en un 31.1% y 29.6% respectivamente y los rangos 50 -59 y 90-100 k = 50; Armin Van Buuren = 50 躈؃ Capítulo 4. P r o y e c t o d e f i n d e c a r r e r a | 71 4.3.8. Consulta: Folk = 80; Armin Van Buuren = 20 Terminamos finalmente nuestras consultas con la realizada en el punto 4.3.8 aplicando las modificaciones que hemos venido usando en las consultas anteriores. Esto es, dar a Folk una relevancia de 80 a la vez que rebajamos la relevancia de Armin Van Buuren hasta 20. Si el peso de los discos de Armin Van Buuren ya hizo que perdiese toda presencia el autor en la consulta con relevancia idéntica, no esperamos mejora alguna en esta situación con la nueva consulta. Todo lo contrario, queremos ver cuánto más favorecido aparece el género Folk en esta consulta. Comparándolo también con los resultados obtenidos para la consulta Folk = 80; Javier Krahe = 20 y Folk = 80; Trance = 20. Presumiblemente esta tercera consulta tendrá mejores resultados que la que implicaba a Trance debido al mayor peso de los discos de autor Armin Van Buuren. Cabe también ver si el tener un acompañante favorable en la consulta (como es Javier Krahe, cuyos discos son de género Folk) será mejor para el género que el tener una competencia claramente desfavorecida como sucede en este caso. En el caso de la frecuencia. Vemos que los resultados del rango 0 son muy similares a los de la consulta Folk = 80; Trance = 20. Pero las soluciones cuentan con 1.2 discos más en promedio. Así, el resultado obtenido es cuantitativamente mejor en esta consulta. Si bien queda algo lejos del 51.9% de frecuencia para la consulta Folk = 80; Javier Krahe = 20, tener dos de cada cinco discos en la solución en el rango 0 es satisfactorio. Más si cabe cuando vemos que el rango 50-59 es favorecido más aún que en la consulta con Javier Krahe. Con idéntica frecuencia al rango 0, entre ambos tienen un 86.8% de los discos de la solución. Este número es el mayor que hemos visto hasta ahora, comparemos con otras tres consultas: • Consulta Folk = 80; Trance = 20. Frecuencia de los rangos 0 y 50-59: 84.9% • Consulta Folk = 80; Javier Krahe = 20. Frecuencia de los rangos 0 y 50-59: 81.5% • Consulta Folk = 50; Armin Van Buuren = 50. Frecuencia de los rangos 0 y 50-59: 75.6% La cruz de la moneda es el rango 90-100, en el que se encuentran, entre otros, los discos que tienen a Armin Van Buuren por autor. La frecuencia es cero, o lo que es lo mismo, no solo ningún disco de Armin Van Buuren ha hecho aparición en ninguna de las pruebas que hemos realizado, sino que los otros discos de rango 90-100, discos con género completamente opuesto al Folk, han estado ausentes también. Vemos, por tanto que la frecuencia de los dos primeros rangos es la mayor obtenida hasta ahora. Continuemos pues con la saturación y comparemos de nuevo los resultados obtenidos. ،ک Figura 34 . Frecuencia. Consulta: Folk = 80; Armin Van Buuren = 20 Resultado tremendo el que o consulta Folk = 80; Trance = 20 a una saturación del 95.6%, además también tenemos saturación máxima para el rango 50 consulta con relevancias idénticas Obviamente la saturación para el resto de rangos baja o se mantiene con respecto a la consulta con relevancia 50 para ambos términos. Y, como ya veíamos al observar la frecuencia, la peor parte de esta bajada se la ha llevado el rang desaparecido completamente de las soluciones obtenidas. Figura 35 . Saturación. Consulta: Folk = 80; Armin Van Buuren = 20 Capítulo 4. P r o y e c t o d e f i n d e c a r r e r a . Frecuencia. Consulta: Folk = 80; Armin Van Buuren = 20 Resultado tremendo el que o btenemos de la saturación. Volvemos, como hicimos en la consulta Folk = 80; Trance = 20 a una saturación del 95.6%, además también tenemos saturación máxima para el rango 50 - 59 con un 50.6% (resultado idéntico esta misma consulta con relevancias idénticas para ambos términos). Obviamente la saturación para el resto de rangos baja o se mantiene con respecto a la consulta con relevancia 50 para ambos términos. Y, como ya veíamos al observar la frecuencia, la peor parte de esta bajada se la ha llevado el rang desaparecido completamente de las soluciones obtenidas. . Saturación. Consulta: Folk = 80; Armin Van Buuren = 20 P r o y e c t o d e f i n d e c a r r e r a | 72 . Frecuencia. Consulta: Folk = 80; Armin Van Buuren = 20 btenemos de la saturación. Volvemos, como hicimos en la consulta Folk = 80; Trance = 20 a una saturación del 95.6%, además también tenemos 59 con un 50.6% (resultado idéntico esta misma Obviamente la saturación para el resto de rangos baja o se mantiene con respecto a la consulta con relevancia 50 para ambos términos. Y, como ya veíamos al observar la frecuencia, la peor parte de esta bajada se la ha llevado el rang o 90-100 que ha . Saturación. Consulta: Folk = 80; Armin Van Buuren = 20   BibliografíaP r o y e c t o d e f i n d e c a r r e r a | 79