Motor de recomendación construido sobre implicaciones

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA GRADO EN INGENIERÍA INFORMÁTICA Mención en Sistemas de Información MOTOR DE RECOMENDACIÓN CONSTRUIDO SOBRE IMPLICACIONES USING IMPLICATIONS TO BUILT A RECOMENDER SYSTEM Realizado por DAVID BARRIENTOS BRENES Tutorizado por CARLOS ROSSI JIMÉNEZ Co-tutorizado por MANUEL ENCISO GARCÍA-OLIVEROS Tutor coordinador CARLOS ROSSI JIMÉNEZ Departamento LENGUAJES Y CIENCIAS DE LA COMPUTACIÓN UNIVERSIDAD DE MÁLAGA MÁLAGA, Diciembre de 2014 Fecha defensa: El Secretario del Tribunal Resumen: Este Trabajo Fin de Grado (TFG) tiene como objetivo la creación de un framework para su uso en sistemas de recomendación. Se ha realizado por dos personas en la modalidad de trabajo en equipo. Las tareas de este TFG están divididas en dos partes, una realizada conjuntamente y la otra de manera individual. La parte conjunta se centra en construir un sistema que sea capaz de, a partir de comentarios y opiniones sobre puntos de interés (POIs) y haciendo uso de la herramienta de procesamiento de lenguaje natural AlchemyAPI, construir contextos formales ycontextos formales multivaluados. Para crear este último es necesario hacer uso de ontologías. El context formal multivaluado es el punto de partida de la segunda parte (individual), que consistirá en, haciendo uso del contexto multivaluado, obtener un conjunto de dependencias funcionales mediante la implementación en Java del algoritmo FDMine. Estas dependencias podrán ser usados en un motor de recomendación. El sistema se ha implementado como una aplicación web Java EE versión 6 y una API para trabajar con contextos formales multivaluados. Para el desarrollo web se han empleado tecnologías actuales como Spring y jQuery. Este proyecto se presenta como un trabajo inicial en el que se expondrán, además del sistema construido, diversos problemas relacionados con la creacion de conjuntos de datos validos. Por último, también se propondrán líneas para futuros TFGs. Palabras clave: Sistemas de recomendación, Descubrimiento de conocimiento, Procesamiento del lenguaje natural, Obtención de dependencias, Contexto formal multivaluado Abstract: The aim of this Degree Thesis (TFG) is to create and provide a framework to be used in recommendation systems. This TFG has been carried out by two students in a co-operation teamwork model. Tasks in this TFG are divided into two main parts. The first part was made jointly in collaboration by both students and the second part was made individually by each student. The aim of the collaborative part is to build a system that should be able to build formal contexts and multivalued formal contexts, from comments and suggestions about points of interest (POIs) and using the natural language processing tool AlchemyAPI. To build such a system, it is necessary to use ontologies. The many-valued context is the starting point for the second part of the individual TFG. This part consists on using the many-valued context to obtain a set of functional dependencies through the Java implementation of the algorithm FDMine. These dependencies might be used in a recommendation engine. The system has been implemented as Java EE version 6 Web Application and an API that supports many-valued contexts. Current technologies such as Spring and jQuery have been used for the web development. This project is presented (submitted) as a preliminary job in which several problems related to the creation of a valid set of data will be described, as well as the main system topics. Finally, some ideas will be also proposed for future TFG. Keywords: Recommender systems, Knowledge discovery, Natural language processing, Get dependencies, Many-Valued Context Índice 1. Introducción 9 2. Metodología 11 3. Requisitos 13 4. Fundamentos y estado del arte 17 4.1. Introducción................................... 17 4.2. Big data en sistemas de recomendación . . . . . . . . . . . . . . . . . . . . 17 4.3. Opiniones como eje principal de los sistemas de recomendación . . . . . . . 17 4.4. Sistemas de recomendación en el sector turístico . . . . . . . . . . . . . . . 18 4.5. Filtrado de información . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.6. Análisis Formal de Conceptos . . . . . . . . . . . . . . . . . . . . . . . . . 19 5. Análisis de requisitos 25 5.1. RF-01Subirontología ............................. 25 5.2. RF-02 Subir comentarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.3. RF-03 Obtener contexto formal multivaluado ................. 26 5.4. RF-04 Subir contexto formal multivaluado .................. 26 5.5. RF-05 Descargar contexto formal multivaluado ................ 27 5.6. RF-06 Obtener dependencias . . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.7. RF-07 Descargar dependencias . . . . . . . . . . . . . . . . . . . . . . . . . 27 6. Entorno tecnológico 29 7. Desarrollo 33 7.1. Aspectosbásicos ................................ 33 7.2. Estructura de los proyectos . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.2.1. FCAApplication............................. 33 7.2.2. FCAUtilitiesProject . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 7.3. Modelos ..................................... 36 7.3.1. CasosdeUso .............................. 36 7.3.2. Diagramas de Clases . . . . . . . . . . . . . . . . . . . . . . . . . . 38 7.3.3. Diagramas de Secuencia . . . . . . . . . . . . . . . . . . . . . . . . 40 7.4. Historiasdeusuario............................... 40 7.5. Pruebas ..................................... 43 7.6. Consideraciones................................. 44 7 8. Experimentos 45 8.1. Introducción................................... 45 8.2. Procesodeanálisis ............................... 46 8.2.1. Obtención de comentarios . . . . . . . . . . . . . . . . . . . . . . . 46 8.2.2. Análisis ................................. 46 8.2.3. Ontología ................................ 47 8.2.4. Contexto formal multivaluado . . . . . . . . . . . . . . . . . . . . . 47 8.2.5. Dependencias .............................. 47 8.3. Estudio de los experimentos . . . . . . . . . . . . . . . . . . . . . . . . . . 47 8.3.1. Análisis del hotel La Villa Marbella . . . . . . . . . . . . . . . . . . 48 8.3.2. Análisis de restaurantes . . . . . . . . . . . . . . . . . . . . . . . . 48 8.3.3. Análisis de un usuario . . . . . . . . . . . . . . . . . . . . . . . . . 49 8.3.4. Análisis del hotel Marriott’s Marbella . . . . . . . . . . . . . . . . . 49 8.3.5. Análisis del hotel La Fuente De La Higuera . . . . . . . . . . . . . . 50 8.3.6. Análisis del hotel Claude . . . . . . . . . . . . . . . . . . . . . . . . 51 8.4. Conclusión.................................... 52 9. Conclusiones y trabajos futuros 55 10.Anexo 57 10.1. Temporización del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 10.2.Ontología .................................... 57 10.2.1.OntologíaMarriot............................ 57 10.2.2. Ontología Higera . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 10.2.3.OntologíaClaude............................ 58 10.3. Contextos Formales Multivaluados . . . . . . . . . . . . . . . . . . . . . . 59 10.3.1. Contexto Formal Multivaluado Marriot . . . . . . . . . . . . . . . . 59 10.3.2. Contexto Formal Multivaluado Higera . . . . . . . . . . . . . . . . 59 10.3.3. Contexto Formal Multivaluado Claude . . . . . . . . . . . . . . . . 60 10.4.Manualdeusuario ............................... 60 10.4.1.Páginaprincipal............................. 60 10.4.2. Subir ontoloía o FCMV . . . . . . . . . . . . . . . . . . . . . . . . . 60 10.4.3.Comentarios............................... 60 10.4.4. Contexto formal multivaluado . . . . . . . . . . . . . . . . . . . . . 64 10.4.5.Dependencias .............................. 64 Bibliografía 67 8 1. Introducción Este es un Trabajo Fin de Grado (TFG) desarrollado en la línea de un Social CRM. Esta línea busca la creación de un sistema de recomendación, desde la extracción de la información de las fuentes de datos: comentarios, opiniones, reseñas, etc. hasta dar una recomendación al usuario. Principalmente se centra en recomendaciones para el sector turístico, uno de los sectores más importantes de Málaga. Es tal la importancia que han adquirido estos sistemas que existen numerosos grupos de investigación trabajando en estos temas, como puede ser el grupo SICUMA (Sistemas de Información Cooperativos de la Universidad de Málaga)[20]. Al tratarse de un trabajo fin de grado de la modalidad de equipo es importante destacar el reparto de las tareas a realizar. Una primera tarea fue desarrollada conjuntamente, mientras que las otras dos fueron realizadas por cada uno de los miembros de manera individual. Estas dos tareas individuales están bien diferenciadas pero relacionadas entre sí. En la parte común del TFG se estudió como, desde unas opiniones sobre puntos de interés (POIs), extraer información sobre atributos o características de los mismos. Esta información debía de ser tratada y recogida en una tabla binaria en la que se relacionasen a los autores de los comentarios (objetos) con las características más relevantes (atributos). A esta tabla se le denomina contexto formal. Posteriormente, fue necesario ampliar este concepto a contexto formal multivaluado o FCMV, donde la tabla pasa de ser binaria a tener múltiples valores. Para ello se empleó la teoría conocida como analisis formal de conceptos multivaluado oformal concept analysis many-valued (FCAMV). La parte específica del TFG presentada en esta memoria consistió en el descubrimiento de relaciones de dependencias entre las características de los POIs. Partiendo del contexto formal multivaluado se aplica un algoritmo denominado FDMine para obtener una serie de dependencias entre el conjunto de atributos. Estas dependencias serán interpretadas a posteriori para poder ser usadas en un sistema de recomendación. Ademas, dentro de este apartado, la fase de experimentos ha sido muy importante y es donde se interpreta los resultados y extraen las conclusiones sobre las dependencias obtenidas de un conjunto de POIs. Para ilustrar el objetivo de este TFG se expone el siguiente ejemplo: Supongamos que tenemos como objetos un conjunto de comentarios de distintos usuarios sobre un determinado hotel y como atributos una serie de características del mismo como: estación del año, medio de trasporte, servicios extra, con quien va acompañado, etc. Analizando estos comentarios, podríamos averiguar que por ejemplo, con conocer las caracterisiticas la estación del año ycon quien va acompañado, podemos saber cuál será el valor del servicio extra usado. Así, podríamos decir que si, por ejemplo, fue en verano y con la familia, el servicio extra buscado fue playa. De esta forma podríamos 9 reducir el número de datos que necesite introducir un usuario para poder darle una buena recomendación con sólo conocer algunas preferencias del usuario. Para la construcción de este sistema se ha realizado un desarrollo web aplicando la tecnología Java EE versión 6 haciendo uso de frameworks y librerías como Spring, jQuery, Bootstrap, etc. Además para la parte de minería de datos y obtención de atributos a partir de los textos se empleó la API de AlchemyAPI que funciona mediante un servicio web. En las posteriores secciones se desarrollarán todos los aspectos relativos al TFG. En la sección 2 se explica la metodología seguida durante todo el desarrollo del proyecto. A continuación, en la sección 3 se nombran los requisitos que debe de cumplir dicho sistema. Seguidamente, en la sección 4, se expondrá el estado del arte y los fundamentos teóricos necesarios para la construcción del sistema. En la sección 5 se analizarán uno a uno los requisitos enunciados en la sección 3. La sección 6 describe el entorno tecnológico del sistema y la sección 7 los aspectos relativos al desarrollo de la aplicación. A continuación se exponen y analizan una serie de experimentos desarrollados a partir del sistema construido (Sección 8). También se presentan unas conclusiones generales de todo el TFG (Sección 9). Además de estas secciones, en la memoria se incluye la bibliografía y una serie de anexos que se componen de: Un desglose a alto nivel del tiempo empleado en cada tarea del TFG (Sección 10.1), los contextos formales multivaluados (Sección 10.3) con sus ontologías (Sección 10.2 y un pequeño manual de usuario (Sección 10.4). 10 2. Metodología Para la realización de este trabajo fin de grado se ha seguido Se siguió el modelo de desarrollo ágil Scrum [17] por los dos miembros del equipo. A continuación se detallan algunas particularidades: Se definieron sprints de una semana de duración. De esta forma se conseguía un seguimiento más exhaustivo del proyecto. Al final de cada sprint se realizaba una reunión con los tutores , que harían las veces tanto de Scrum Master como de Product Owner. En esa reunión se realizaba el Sprint Review con los productos, pruebas y conclusiones obtenidos del anterior sprint, y el Sprint Planning en el que se decidían que historias de usuario entrarían en la siguiente iteración. Se hizo una primera versión del product backlog a partir de los requisitos. Generalmente se dividió cada sprint en cuatro fases: recolección de información y estudio, construcción y, verificación y pruebas. En las primeras iteraciones se dedicó un mayor esfuerzo en tareas de estudio, mientras que en las finales se trabajaron más las partes de construcción, verificación y pruebas. A continuación se explica brevemente cada una de estas fases. Recolección de información y estudio: Para cada historia de usuario del sprint se realizó un estudio previo del estado del arte. Para ello se revisaron artículos relacionados con la materia y páginas web dedicadas al tema en concreto. Construcción: Se desarrolló el código necesario para implementar las historias de usuario. Verificación y pruebas: Todo el código creado se testeó y se comprobó que los datos generados fueran correctos, empleando para ello una serie de casos de prueba. En la sección 7.4 se explicará con más detalle cómo fueron resueltas las historias de usuario. Además, en el anexo 10.1 se puede encontrar un resumen de la planificación temporal del proyecto. 11 3. Requisitos Para la creación del sistema se tuvieron en cuenta una serie de requisitos. A continuación se expondrán los requisitos relativos a la parte común del TFG: RNF-01 Desarrollo como aplicación web Tipo de requisito No Funcional Dependencias Descripción La aplicación debe de seguir una arquitectura web. Importancia Alta Prioridad Baja Asignado a: Christian Cintrano López y David Barrientos Brenes RNF-02 Interfaz sencilla Tipo de requisito No Funcional Dependencias Descripción La aplicación debe tener una UI minimalista y sencilla de usar. Importancia Baja Prioridad Baja Asignado a: Christian Cintrano López y David Barrientos Brenes RNF-03 Tiempo de respuesta Tipo de requisito No Funcional Dependencias Descripción La aplicación debe de tener un tiempo de respuesta respuesta bajo Importancia Baja Prioridad Baja Asignado a: David Barrientos Brenes RNF-04 Volumen de datos Tipo de requisito No Funcional Dependencias Descripción La aplicación solo debe trabajar correctamente con un volumen de datos pequeño. Importancia Baja Prioridad Baja Asignado a: David Barrientos Brenes 13 Mlas características de POIs. Irelación que se establece entre una opinión de un usuario (objeto) y las características (atributo) del POI sobre el que opina. Esta tupla puede ser representada como una tabla, siendo Glas filas, Mlas columnas y Iel valor 0 o 1 de una celda, según exista o no la relación. En el contexto podemos definir relaciones binarias entre los conjuntos G M llamadas Conexiones de Galois y son la base para la definición formal de concepto de un contexto formal. Un concepto es un conjunto de objetos y atributos con nombre y significado. Además poseen una estructura de retículo. Todo ello nos permite generar grupos de usuarios con los mismos intereses u opiniones. Para poder obtener todos los conceptos de un contexto formal existen diversos algoritmos, entre los cuales se destacan: NextClousure: Fue propuesto por el propio Ganter y fue el primero. Calcula de forma sencilla como obtener todos los conceptos de un contexto formal pero tiene muy poca eficiencia [24]. Titanic: Se basa en la obtención de una función de peso que reduce en gran medida el número de cierres a realizar. Titanic no reduce la complejidad del problema pero si lo vuelve más eficiente [33]. Gracias al FCA y a estos algoritmos, es posible emplear técnicas de recomendación, tales como el filtrado colaborativo, o descubrir tendencias en los gustos de los usuarios. Aun así, esta teoría posee una gran limitación, los valores del contexto formal son binarios; es decir, si observamos el contexto como una tabla las filas serían los objetos, los atributos las columnas y las celdas tomarían el valor de 0 o 1 según existiera la relación entre el objeto y el atributo correspondiente. En el mundo real, podemos encontrar que la mayoría de los datos son de carácter heterogéneo, como por ejemplo la meteorología, que puede tomar valores como soleado, lluvioso, nublado, etc. y con los que la teoría FCA no puede trabajar. Este problema es posible resolverlo de múltiples formas. Un modo posible es creando intervalos discretos de un atributo con múltiples valores [25]. Por ejemplo, el atributo de meteorología que puede tomar valores como lluvioso, soleado, nublado. Este método divide el atributo meteorología en una serie de valores. Así, obtenemos que meteorología ya no es un atributo, pero si lluvioso, soleado y nublado; y la relación sólo se establecerá con uno de esos atributos. Otra forma posible de solucionar dicho problema es considerar que la relación entre cierto objeto y atributo existe si dicho objeto toma un determinado valor. Este valor pertenece a un conjunto de valores llamados valores de verdad [23]. 20 Todas estas formas de homogeneizar los valores provocan la perdida de información. Por ello, la mejor forma de resolver dicho problema es creando una nueva teoría llamada análisis formal de conceptos multivaluado o Formal Concept Analysis Many-Valued (FCAMV)[34]. Con esta nueva teoría se persigue mantener las mismas propiedades que en FCA pero haciendo uso de múltiples valores en lugar de binarios. Para ello debemos de adaptar los conceptos de dicha teoría. Un contexto formal multivaluado (FCMV) es denotado por la tupla (G, M, W, I)donde Ges el conjunto de objetos, Mel conjunto de atributos, Wes el conjunto de valores de los atributos e Ies una relación ternaria entre G,MeItal que (I⊆G×M×W), o lo que es lo mismo para (g, m, w)∈Ipodemos afirmar el hecho de que el atributo mtoma el valor wpara el objeto g(también puede ser denotado por m(g) = w). El término retículo de conceptos también es adaptado en el FCAMV. Para ello se emplea el concepto de retículo de conceptos multivaluado: Dado un contexto MV (G, M, W, I)y un umbral θ∈[0,1] : dos objetos giygjen G comparte un atributo men Msi y sólo si m(gi) = wi,m(gj) = wj, y |wi−wj| ≤ θ. Asumiendo que wi≤wj,giygjcomparten m[wi, wj], el intervalo [wi, wj]es llamado intervalo de similaridad de mpara giygj, y wiywjse dice que son similares. Siendo Aun conjunto tal que A⊆Gde objetos que comparten un atributo m siempre que cualquier dos objetos en Acompartan m. El intervalo de similaridad de mpara Aes [ming∈A(m(g)), maxg∈A(m(g))] y el atributo mcompartido por los objetos en Aes denotado por m[ming∈A(m(g)),maxg∈A(m(g))]. Dado un contexto MV (G, M, W, I), un umbral θ∈[0,1] yIθel conjunto de todos los intervalos [α, β]tales que β−α≤θcon [α, β]⊆[0,1]: •Para un conjunto A⊆G:A0 θ={m[α, β]∈M×Iθtal que m(g) = y ∀gi, gj∈A, |m(gi)−m(gj)| ≤ θ, α =ming∈A(m(g)) yβ=maxg∈A(m(g))}. •Para un conjunto B⊆M×Iθ:Bθ={g∈Gtales que ∀m[α, β]∈B, m(g)∈ [α, β]}. Un concepto MV es un par A, B donde A⊆GyB⊆M×Iθtales que t Aθ=By B0 θ=A. Si A1B1yA2B2son conceptos MV, A1B1es un subconcepto de A2B2cuando A1⊆ A2(oB2⊆θB1). El conjunto ordenado de todos los conceptos MV de G, M, W, I es llamado retículo de conceptos multivaluado. Con esto, el FCAMV tiene las mismas propiedades que el FCA pero con la ventaja de poder usar datos heterogéneos. De este modo, podemos obtener mucha más información 21 aplicando ciertos algoritmos, como los algoritmos de obtención de dependencias funcionales. Una dependencia funcional (Funcional Dependency, FD) expresa una restricción de valor entre atributos en una relación [31]. Formalmente, para un esquema relacional R con X⊆RyA∈R, una dependencia funcional X→Apuede ser definida si para todo par de tuplas t1yt2sobre R, para todo B∈Xsi t1[B] = t2[B]entonces t1[A] = t2[A]. Gracias a esto podemos, por ejemplo, reducir enormemente el trabajo que debe realizar un motor de recomendaciones para poder realizar alguna recomendación a un usuario. Con conocer unos pocos datos de un usuario, podemos ir deduciendo los demás gracias a las dependencias y mostrarle en poco tiempo y eficazmente la recomendación. Para obtener estas dependencias funcionales, podemos hacer uso de varios algoritmos, como por ejemplo Tane [26]. Tane fue uno de los primeros algoritmos de obtención de dependencias funcionales de manera eficiente. Este algoritmo consiste en hacer particiones en conjuntos de filas según los valores de los atributos. Además, realiza rápidamente pruebas de validez de FD, incluso con una gran cantidad de filas. Posteriormente surgieron algoritmos que mejoran la eficiencia de Tane, a la vez que aumentan la cantidad de información que se puede obtener. Un ejemplo puede ser el algoritmo FUN [32]. Sin embargo, el algoritmo FD Mine [22] reduce significativamente el tiempo de ejecución y de consultas con respecto al Tane o FUN. Además nos proporciona un conjunto de claves y de equivalencias de atributos. Este algoritmo se basa en los axiomas de Armstrong que se fundamentan en tres reglas básicas: Regla de reflexibilidad: si Y⊆X, entonces X→Y Regla de argumentación: si X→Y, entonces XZ →Y Z Regla de transitividad: si X→Yy si Y→Z, entonces si X→Z Gracias a estas reglas es posible podar, en gran medida, las comprobaciones entre los diferentes conjuntos de atributos. Previamente es necesario definir estos cuatro conceptos: Candidato: conjunto de atributos que podrían tener alguna dependencia funcional con algún otro atributo. Equivalencia de candidatos: dado XeYdel conjunto de atributos, si X→Yy Y→X, entonces decimos que XeYson equivalentes, y se denota como X↔Y. Gracias a esta regla, y a otras que se deducen de ella, es posible calcular el conjunto de atributos equivalentes a la par que se reduce el número de comprobaciones de FD. Cierre no-trivial: dado un conjunto de dependencias funcionales Fsobre el conjunto de datos Dy un posible candidato X, el cierre del candidato Xrespecto a Fse denota como Clousure(X)y es definido como {Y|X→Ypuede ser deducido de F 22 por los axiomas de Armstrong}. El cierre no-trivial no es más que el cierre de Xsin el elemento X, o lo que es lo mismo, Closure0(X) = Closure(X)−X. Reglas de Poda: existen varias reglas de poda que son usadas para reducir la lista de candidatos a comprobar. Un ejemplo es: Si X, Y ∈Conjunto de Candidatos y X↔Y, entonces Ypuede ser borrada de dicho conjunto. El algoritmo FD Mine consta de varias fases: 1. Inicialización de las variables. El conjunto de candidatos inicialmente es el conjunto de atributos. 2. Mientras que el conjunto de candidatos sea diferente del vacío, repetir: a) Para todo el conjunto de candidatos, comprobar con cada atributo si existe una dependencia funcional. b) Cotejar si algún candidato es clave. c) Examinar si algún candidato es equivalente a otro candidato. d) Podar el conjunto de candidatos. e) Generar el siguiente nivel de candidatos, añadiendo a cada elemento un atributo más que no tuviera. 23 5. Análisis de requisitos En las siguientes secciones se analizarán cada uno de los requisitos funcionales enunciados en la sección 3, que llevaron hasta la solución elegida. 5.1. RF-01 Subir ontología Para obtener un contexto formal multivaluado es necesario prefijar cada atributo con sus diferentes posibles valores. Esto es necesario para que, analizando los comentarios, podamos obtener si un atributo ha sido nombrado y con qué valor. Por ello, es imprescindible contar con una ontología preparada por un experto. Dicha ontología puede representarse en forma de árbol en tres niveles, como se ilustra en la figura 1, tal que: Figura 1: Ejemplo de ontología de atributos Primer nivel: equivale al conjunto total de todos los atributos. Segundo nivel: este nivel contiene a todos los atributos, cada uno separado en una rama. Tercer nivel: las hojas son los diferentes valores que puede adoptar cada atributo. Sería deseable una ampliación de este árbol con un cuarto nivel extra: sinónimos. Como el tercer nivel representa los diferentes valores de un atributo, los sinónimos representarían las diferentes formas de hacer referencia a el mismo atributo. De este modo, la ontología sería mucho más potente y robusta, a la par que aumentaría la cantidad de información que podemos recibir de los comentarios de cada usuario. Sin embargo debido a su complejidad, queda fuera del alcance de este proyecto. Para la creación de la ontología se usará un fichero JSON [13] con cada atributo y sus diferentes valores. Se ha elegido JSON por su simplicidad y su sencilla pero potente 25 estructura de datos, que es fácilmente manipulable desde Java, el lenguaje seleccionado para el desarrollo de la aplicación. La estructura sería tal que así: " atribubte 1": {"valuetr1.1","valuetr1.2","valuetr1.3"}, " atribubte 2": {"valuetr3.2","valuetr2.2","valuetr2.3"}, 5.2. RF-02 Subir comentarios Un contexto formal multivaluado puede representarse en forma de tabla, siendo los atributos las columnas y los objetos las filas. El conjunto de atributos se consigue gracias a la ontología, en cambio, los objetos que rellenan la tabla se obtienen de los comentarios de los usuarios. Como fuente de información se ha usado los comentarios de TripAdvisor [19], captados manualmente. Aunque no entra en el caso de estudio de este TFG, sería deseable la integración con algún servicio web o API para automatizar este proceso. Para obtener información útil de los comentarios, es necesario que se analicen. Esta información puede definirse como el conjunto de keywords o conjunto palabras claves. Para conseguirlas, se investigó un gran amplio abanico de herramientas, tales como Gate [6] o R [16]. Todas ellas se desecharon ya que no cumplían con las expectativas. En cambio, y siendo ésta la herramienta elegida, AlchemyAPI [2] si nos proveía de un modo rápido y directo el conjunto de keywords de cada texto, generando un documento con los datos del análisis. Una vez obtenidos el conjunto de keywords de cada comentario, solo resta comprobar con cada keyword si adopta el de valor de algún atributo de la ontología. 5.3. RF-03 Obtener contexto formal multivaluado Con los comentarios y la ontología, se crea un contexto formal multivaluado, que será representado en forma de tabla, siendo la cabecera los atributos y las filas los valores posibles, reflejados en la ontología. El proceso de creación es simple: se analizan las palabras de un comentario y se obtienen las keyword. Seguidamente, comprueba con cada atributo si alguna keyword conincide con el valor de cada atributo. Si lo hace, se añade ese valor a la tabla. Así sucesivamente con todos los comentarios introducidos. 5.4. RF-04 Subir contexto formal multivaluado La aplicación permitirá subir un fcmv en formato csv. Este contexo será mostrado luego al igual que en requisito funcional 03, y deberá tener su mismo formato. 26 5.5. RF-05 Descargar contexto formal multivaluado Una vez creado el fcmv, podrá ser descargado para su posterior analisis. El archivo está en formado csv y formateado igual que la tabla presentada en el requisito funcional 03 y la subida en el requisito funcional 04. 5.6. RF-06 Obtener dependencias Existen diversos algoritmos de extracción de dependencias funcionales a partir de una tabla. Por ello, se realizó un estudio sobre que algoritmo usar. Para poder hacer uso de un contexto formal multivaluado, era necesario que aceptara cualquier conjunto de valores, no solo binarios. Primero se investigó Tane, uno de los primeros algoritmos de este tipo, y del cual nacen muchos otros algoritmos, tales como el FUN o FDMine. Después de un análisis sobre estos tres algoritmos, se decidió emplear FDMine. FDmine no disminuye la complejidad respecto a Tane o FUN, se mantiene en 2n, siendo nel numero de atributos. El numero de filas no influye en la complejidad. En cambio, si reduce en gran medida el número de comprobaciones de posibles dependencias funcionales, lo que le da una eficiencia aun mayor que los otros dos algoritmos. Además, aporta más información, como el conjunto de atributos equivalentes o el de claves primarias. 5.7. RF-07 Descargar dependencias Desde la aplicación se podrá descargar las dependencias obtenidas, una vez que sean analizadas. El fichero estará en formato csv, con la primer columna el conjunto de atributos separados por espacios, y en las siguientes columnas sus dependencias. 27 6. Entorno tecnológico Se ha desarrollado una aplicación web Java EE (antes conocido como J2EE) versión 6, implementada haciendo uso de los siguientes frameworks y librerías JBoss 6 [7]: Servidor de aplicaciones. Fue elegido debido a la familiaridad previa que se tenía con el mismo. Spring v4 [18]: Framework de desarrollo de entornos web. Es una de las mejores tecnologías de modelo vista-controlador. Es fiable, posee una gran cantidad de módulos fácilmente configurables y es fácil de usar. Se ha empleado como controlador de la aplicación web. Bootstrap 2.3.1 (look & feel) [4]: Hojas de diseños originalmente diseñada por Twitter. Se ha vuelto muy popular debido a los buenos resultados que se obtienen y a su sencillez. JSP: Para el diseño de la interfaz web. Son rápidos, potentes, dinámicos, sencillos y altamente extendidos. Su simplicidad fue la clave para su selección. JTLS: Etiquetas para JSP que añaden funcionalidad extra. Concretamente se han empleado para sentencias de control de flujo <c:if> y <c:forEach> además de acceso a los ficheros .properties para implementar el multilenguaje. Apache Ant (Solo en front-end) [3]: Librería para la compilación del código. Maven (Solo en back-end) [15]: Herramienta para el control de configuración. Ampliamente extendido, potente y fácil de usar. AlchemyAPI [2]: Librería para el procesamiento del lenguaje natural que ofrece una amplia gama de funcionalidades. Se usa bajo licencia de compra, aunque posee licencias de prueba y académica (limitada a un número máximo de peticiones). Además se han empleado una serie de plugins para mejorar la funcionalidad y la apariencia de la web. jQuery [8]: Biblioteca de JavaScript que permite simplificar la manera de interactuar con los documentos HTML, manipular el árbol DOM, manejar eventos, desarrollar animaciones y agregar interacción con la técnica AJAX a páginas web. Es la librería de JavaScript mas utilizada. Además de JQuery se hace uso de una serie de plugins concretos de su biblioteca. •JQuery BlockUI [9]: Bloquear la pantalla mientras se procesa la información. •jQuery jGrowl [11]: Mostrar alertas. 29 fca.context: paquete principal en el que se encuentran las clases básicas para trabajar con contextos formales multivaluados. fca.pruebas: en su interior se encuentran las clases de pruebas que se empleó en el desarrollo del back-end. 7.3. Modelos Todos los modelos realizados han sido creados usando la herrmanienta de modelado de UML MagicDraw. Todos estos modelos mostrados a continuación están adjuntados en la entrega del TFG. 7.3.1. Casos de Uso En la figura 5 se ilustran los casos de uso principales del sistema. Subir ontología: Subir una ontología en formato JSON. El usuario pulsa subir ontología, selecciona la que desea y pulsa el botón aceptar. Subir comentarios: Subir una serie de comentarios en formato txt. El usuario pulsa subir comentarios, selecciona los comentarios y pulsa el botón aceptar. Subir contexto formal multivaluado: Subir un contexto formal multivaliado con la extensión csv. El usuario pulsa subir contexto formal multivaluado, selecciona un contexto y pulsa el botón aceptar. Obtener un contexto formal multivaliado: Se crea una tabla que represente el contexto formal multivaluado a partir de la ontología y los comentarios. El usuario pulsa obtener contexto formal multivaliado, mostrándose una tabla que representa el contexto. Descargar contexto formal multivaliado: Descargar la tabla obtenida con formato csv. El usuario pulsa descargar contexto formal multivaliado, obteniendo un archivo que contenga dicho contexto. Obtener dependencias: Obtener el conjunto de dependencias a partir de un contexto formal multivaliado. El usuario pulsa obtener dependencias y éstas serán mostradas en forma de lista. Descargar dependencias: Descargar el conjunto de dependencias obtenidos, en formato csv. El usuario pulsa descargar dependencias, obteniendo un archivo que contenga dichas dependencias. 36 Figura 5: Diagrama con los casos de uso Figura 6: Diagrama de clases 37 7.3.2. Diagramas de Clases Para la implementación de FCAUtilitiesProject se desarrollaron diferentes clases, que se analizaran a continuación. Estas clases se ilustran en el diagrama de clases de la figura 6. FormalContextMV Esta clase representa a un contexto formal multivaluado y es la clase principal del proyecto. Se compone de una serie de constructores y métodos, los cuales se describen a continuación Constructores public FormalContextMV () ; public FormalContext ( File ontology , List <File > f i l e s ) ; // Constructor principal public FormalContext ( F i l e fcmv ) ; // Constructor p r i n c i p a l Los dos constructores principales son, en primer caso, para introducir una ontología en extensión JSON y una lista de comentarios en txt, y en segundo caso, para introducir un contexto formal multivaluado con extensión csv. Este primero realizará una llamada al codigo de AlchemyAPI para procesar los textos. Cabe destacar que el contexto multivaluado se rellena de la siguiente forma: Si el comentario contiene una keyword perteneciente a un atributo de la ontología, se colocara esa keyword en ese atributo. En caso contrario un "NA". Métodos sobre el contexto formal multivaluado Los métodos principales para interactuar con el contexto formal multivaluado son los siguientes: public List <List <String>> getFormalContextMV ( ) {}; public F i l e getFormalContextMVFile ( S tri ng fileName ) {} ; El primer método sirve para obtener el contexto formal multivaluado. El segundo método es usado para poder almacenar en un archivo csv dicho contexto. Métodos sobre las dependencias La parte específica del TFG trata sobre las dependencias funcionales. Estos son los métodos que proporcionan las funcionalidades necesarias: public ResultSet getDependecies ( ) {}; public F i l e g et De pen dec ies Fi le ( S tr in g fileName ) {} ; Estos métodos nos devuelven las dependencias en la clase ResultSet que será explicada más adelante. Ambos poseen llamadas a la implementación del algoritmo FDMine. 38 AlchemyAPIWordExtraction Esta clase es la encargada de realizar la extracción de las palabras claves de los textos que posteriormente serán cribadas para obtener los atributos del contexto multivaluado. Es una abstracción de la API de AlchemyAPI. FDmineAlgorithm Es una implementación directa del algoritmo FDmine. Consta de un único método público public s t a t i c ResultSet execute (Map<String , Integer > at ri bu te Pos it io n , List <List<String>> data ) {}; Este método recibe como entrada un mapa con el nombre de los atributos y su posición en la tabla del contexto formal multivaluado, y una lista de listas de String , que representa la tabla del contexto formal multivaluado. El resultado es un objeto de la clase ResultSet, que contendrá todas las dependencias que se obtienen. Para facilitar la lectura del código se mantuvieron tanto los nombres de los métodos como los de las variables que aparecen en la definición de FDMine. Estos métodos son: private s t a t i c void ComputeNonTrivialClosure ( Atribute ) {}; private s t a t i c void ObtaintFDandKey ( Atribute ) {}; private s t a t i c void ObtainEQSet ( Set<Atribute >) {}; private s t a t i c void PruneCandidates ( Set<Atribute >) {}; private s t a t i c Set<Atribute> GenerateNextLevelCandidates ( Set<Atribute >) {}; //Method to remove de dependencies of type X −> Y, XZ −> YZ private s t a t i c void isRedundant ( Atribute ) {}; Atribute Representa a un atributo o conjunto de atributos del algoritmo FDMine. Sus principales parámetros son: // Set of a t t r i b u t e s . Represent the a t tr ib u t e private Set<String > a t t r i b u t e ; // Clousure of the Attribute private Set<Attribute> c lousu re ; //The p a r t i t i o n o f the Attr ibu te private Set<List <String >> p a r i t i t i o n ; Además la clase cuenta con una serie de métodos para realizar operaciones con conjuntos. ResultSet Representa al conjunto que se obtiene al ejecutar el algoritmo FDMine. Sus principales parámetros son: // Represent the s e t of a t t r i b u t e and i t s dependencies private Map<Atribute , Set<Atribute>> dependency ; 39 Figura 7: Diagrama de secuencia del caso de uso Subir ontologias // Set of a t t r i b u t e that are equal private Map<Atribute , Atribute> equal ; // Set o f a t t r i b u t e that are primary key private Set<Atribute> key ; Además, esta clase cuenta con sus correspondientes getters and setters. 7.3.3. Diagramas de Secuencia Los diagramas de secuencia representados en las figuras 7, 8,9 , 10, 11, 12 y 13 incluidos en esta sección ilustran los comportamientos básicos y exitosos de los casos de uso descritos anteriormente. 7.4. Historias de usuario A continuación se describe como se fueron resueltas las historias de usuario. 1. Inicialmente se desarrolló el algoritmo FDMine con sus clases auxiliares. Se realizaron pruebas de cada función y pruebas completas de todo el sistema. 2. Tras analizar los resultados obtenidos por el algoritmo FDMine, se implementó una mejora del mismo, que eliminaba las dependencias del tipo: X→Y,XZ →Y Z 40 Figura 8: Diagrama de secuencia del caso de uso Subir comentarios Figura 9: Diagrama de secuencia del caso de uso Subir un contexto formal multivaluado 41 Figura 10: Diagrama de secuencia del caso de uso Obtener el contexto formal multivaluado Figura 11: Diagrama de secuencia del caso de uso Descargar contexto formal multivaluado Figura 12: Diagrama de secuencia del caso de uso Obtener dependencias 42 Figura 13: Diagrama de secuencia del caso de uso Descargar dependencias 3. El conjunto de clases del algoritmo FDMine fue integrado con la API de FCAUtilities existente, y se realizaron varias pruebas con comentarios reales obtenidos previamente. 4. Se creó la nueva API de FCAUtilities, contando con toda su funcionalidad anterior y añadiendo los puntos anteriores. 5. El desarrollo cambia del back-end al front-end, y se crea una versión beta de la web, sin centrarse en la visualización. En cambio, implementaba las funcionalidades básicas. 6. Se integró la parte web creada en el punto anterior con lo desarrollado previamente en el TFG de mi compañero. 7. Se cambió la plantilla o template de la aplicación web. 8. Se realizó una nueva versión de la web, en la que se definió visualmente el flujo de la aplicación, para que el usuario pudiera ver los pasos que tiene que hacer. 9. Se corrigieron pequeños fallos y se añadió el multi-idioma en la última parte desarrollada. 7.5. Pruebas Se realizaró una batería de cinco tipos de pruebas para API y una para la interfaz web. Las pruebas del código de back-end consistieron en: Pruebas de FDMine Se introdujeron manualmente en una clase de test los valores de un contexto formal multivaluado, constatando que las dependencias obtenidas eran 43 las esperadas. Esto se probó en unas ocho tablas con diferentes números de filas, columnas y valores. Pruebas de creación de tabla FCMV Se comprobó con un conjunto de datos controlados (entre 10 y 50 comentarios) y una ontología adecuada a ese conjunto, que se obtenía una tabla FCMV correcta. Pruebas de funcionamiento real Fueron repetidos los anteriores test con comentarios reales como inputs. De esa manera se aseguró el correcto funcionamiento de la API. La interfaz web fue testeada una vez que la API pasó toda su batería de pruebas. Para estas pruebas se emplearon directamente datos reales y se comprobó tanto su correcto funcionamiento como algunas situaciones anómalas, tales como: No introducir una ontología. No introducir comentarios. No introducir una tabla FCMV. No introducir los ficheros con la extensión correcta. 7.6. Consideraciones A continuación enumeramos algunas restricciones para el correcto funcionamiento de la aplicación: Los comentarios deben de estar en ficheros .txt. La primera línea de cada comentario debe de ser el nombre del usuario. Los comentarios deben de estar en inglés. Es recomendable que cada comentario aparezca en un fichero diferente. La ontología debe introducirse con formato JSON. El contexto formal multivaluado debe estar en formato csv. Emplear el sistema operativo Windows para ejecutar la aplicación. No se ha aplicado responsive design debido a que las funcionalidades del sistema no están pensadas para el uso en smartphones. Se debe seguir el flujo marcado en el manual (Sección 10.4), introduciendo los ficheros necesarios en cada parte. Sino, no se asegura su correcto funcionamiento. 44 8. Experimentos En esta sección se explica en profundidad todos los experimentos realizados y las conclusiones obtenidas. 8.1. Introducción El objetivo final de este TFG es aumentar la eficacia de un motor de recomendación. Para ello, se quiere reducir el número de parámetros que necesita conocer para poder llegar a dar una recomendación. De este modo, se pretende obtener un conjunto de dependencias con las que, conociendo ciertos valores, podamos conocer otros. Así, reduciríamos el número de datos que se debe conseguir para proveer de una recomendación. Para conseguir todo esto es necesario haber obtenido las dependencias entre los diferentes parámetros o atributos, y antes de eso, previamente ha de crearse un contexto formal multivaluado. Tener un buen conjunto de datos o data set es fundamental para crearlo. Si la base de donde queremos obtener conocimiento no es la adecuada, la información que adquiramos no será útil. Por ello, es necesario analizar en profundidad el conjunto de datos de donde se parte. En el contexto de este TFG, obtener un buen conjunto de datos nos permitirá obtener un buen FCMV. Para crear un FCMV son necesarios varios elementos: Fuente de información: De donde se obtiene la información. Puede ser de comentarios, tweets, valoraciones, etc. Cualquier objeto que nos proporcione la opinión de los usuarios. Principalmente, representada en lenguaje natural. Análisis: Es necesario analizar la fuente de información para convertir los datos en conocimiento. Para ello se pueden usar diferentes técnicas, como la obtención de keyword o palabras clave, análisis de sentimientos, sinónimos, etc. En este TFG se ha usado una herramienta llamada AlchemyAPI con la que se consiguen las palabras clave. Ontología: Para crear el contexto formal multivaluado es necesario contar con una ontología. Gracias a ella, se organizan los diferentes atributos con sus respectivos valores. La ontología deberá reflejar las características del objeto de estudio, por ello, es preciso que un experto en la materia cree la ontología, ya que se necesitan conocimientos específicos de ese área. El análisis de las fuentes de información es un problema sumamente complejo. Esto es porque la información recogida, al ser en lenguaje natural, es muy difícil de estudiar. En la sección 8.2 se muestra en detalle los elementos usados y el proceso seguido para realizar los experimentos. 45 transport room extras →time,drinks time environment extras →transport transport characteristics extras →company,drinks time environment company →transport,drinks transport company extras →characteristics,drinks environment transport characteristics →extras,time,company,room,drinks environment characteristics extras →company,drinks environment room extras →characteristics,time,transport,company,drinks environment transport extras →time transport characteristics room →company company room extras →drinks time characteristics drinks →company,room Al igual que en el caso anterior, el número de dependencias ha aumentado notablemente (casi el doble). También se denota en gran medida que el número de atributos dominante en la parte izquierda son tres, como en los casos anteriores. De estas dependencias podemos obtener un dato claro: existen muchas claves. De cinco conjuntos de tres atributos diferentes, podemos obtener los posibles valores de los demás. Además, analizándolo con más detalle, la parte izquierda de esos cinco conjuntos está formada por atributos similares. Así, éstos forman un conjunto de valores.{time, characteristics, extras, transport, environment, room}. Con casi cualquiera tres valores de ese conjunto, podemos conseguir todos los demás atributos de la ontología. Esto provee a un motor de recomendación con una potencia superior a lo citado en los experimentos anteriores. De este modo, un usuario sólo tendría que definir las 3 opciones que prefiriera para conseguir la recomendación. 8.4. Conclusión Tras este conjunto de análisis de casos de prueba, queda constatado que la base de donde obtengamos conocimiento ha de cumplir ciertas características para que sea válida y podamos obtener información de ella: Número de comentarios: 100 aproximadamente. Media de numero de palabras: 200 aproximadamente. 52 Similitud de terminología usada. Numero de características limitado. De este modo, se ha constatado que, obteniendo un buen contexto formal multivaluado, es posible obtener un conjunto de dependencias que ayude en gran medida a un motor de recomendación, evitando tediosas tareas al usuario. Ademas de estas conclusiones se añaden en el anexo 10.2 las ontologías usadas, junto con sus contextos en el anexo 10.3. 53 9. Conclusiones y trabajos futuros En este TFG se ha estudiado como aumentar la eficacia de un motor de recomendación. Para ello ha sido necesario realizar un estudio sobre la teoría de análisis formal de conceptos multivaluados. En lo que respecta al estudio de dicha teoría, fue una grata sorpresa al descubrir su simplicidad. El mayor problema de ella consistió en la creación de un contexto formal multivaluado. Aunque en un principio se predijo que esto podría ser un problema, no se pensó que su complejidad sería tan alta. Realmente era laborioso obtener un conjunto de comentarios y una ontología con que la poder trabajar, como se demostro en el apartado de experimentos 8. Todo ello debido a que cada usuario usa su propio vocabulario y es difícil obtener términos comunes. Otra parte fundamental son las dependencias. Inicialmente, se pensó en usar dependencias binarias (de un atributo a otro atributo) para usarlas en el motor de recomendación. En la práctica, no se obtuvo ese tipo de dependencias, sin embargo, sí que se obtuvieron datos interesantes: el conjunto de claves. Con los atributos clave, que son un pequeño conjunto de todos los atributos, es posible obtener el valor del resto. De todo el estudio que se ha realizado, se han descubierto posibles líneas futuras de TFGs relacionadas: Emplear alguna herramienta que automatice la obtención de comentarios. Aplicar técnicas de sinónimos. Aplicar analisis de sentimientos. Ampliar este desarollo con técnicas de big data. Emplear diferentes algoritmos para la obtención de dependencias. 55 10. Anexo 10.1. Temporización del trabajo A continuación se expone un desglose del tiempo empleado en cada tarea del TFG: Tarea Duración (en horas) Planificación y seguimiento 10 Diseño 5 Estudio y Aprendizaje 42 Desarrollo Beta de la aplicación 30 Desarrollo Final del sistema 57 Experimentos 100 Problemas y mejoras 35 Testing 12 Desarrollo de la memoria 75 Total 366 10.2. Ontología 10.2.1. Ontología Marriot { "time" : ["evening","morning"," night "], "company" : [" family ","friends"," couple "," marriage "], "environment" : [" location "," people "," atmosphere "," relaxing "] , " extras " : [" restaurant "," bars ","gym"," shops "," beach","pool ", "spa"], " transport " : ["parking","bus ","walk","car ","taxi"], "room" : [" bathroom ","balcony","tv","bed"], " services " : ["service"] } 10.2.2. Ontología Higera { "time" : ["evening","morning"," night "], "company" : [" family ","friends"," couple "," marriage "], " characteristics " : ["price"," luxury ","comfort"], 57 "environment" : [" location "," people "," atmosphere "," peace "], " extras " : [" restaurant "," bars ","gym"," shops "," beach","pool ", "spa"], "food" : [" breakfast "," dinner ","lunch "," brunch ","dinners"], " transport " : [" bus "," walk ","car","taxi "], "room" : [" bathroom ","balcony","tv","bed "," view ","air conditioning"], " services " : ["service"] } 10.2.3. Ontología Claude { "time" : ["night ","evening","morning"], "company" : [" family ","friends"," couple "," marriage "], " characteristics " : ["price"," luxury ","comfort"], "environment" : [" location "," people "," atmosphere "," relaxing "] , " extras " : ["restaurants","bars"," gym ","shops "," beach "," pool" ,"spa"], "food" : [" breakfast "," dinner ","lunch "," brunch "], " transport " : [" bus "," walk ","car","taxi "], "room" : [" bathroom ","balcony","tv","bed"], " drinks " : [" coffee "," cava ","wine","juice "], " services " : ["service"] } 58 10.3. Contextos Formales Multivaluados 10.3.1. Contexto Formal Multivaluado Marriot services time environment transport company room extras service NA location NA family NA restaurant NA NA relaxing NA couple balcony pool NA NA NA NA family balcony NA service morning NA car family NA restaurant NA NA NA NA family balcony pool service NA people taxi family bathroom beach service NA people NA family bathroom restaurant service NA NA NA family bed restaurant NA night NA taxi friends bathroom pool service NA location car family NA restaurant NA evening people NA NA balcony NA service evening location car family bed shop NA NA NA car family bathroom shop service NA location NA couple bed beach NA night NA NA family bathroom restaurant NA night location car couple NA beach 10.3.2. Contexto Formal Multivaluado Higera services time environment transport food company characteristics room extras service NA NA NA dinner couple NA NA pool NA evening location NA dinner NA NA balcony NA NA night atmosphere NA dinner NA comfort view restaurant NA NA people NA NA couple NA balcony pool service NA location NA NA NA NA view pool NA NA people car dinner NA NA bed restaurant service evening location car dinner NA comfort NA NA NA night location car lunch couple NA bed NA service NA location NA dinner family NA view pool NA night location NA NA NA NA view pool service evening location NA NA NA price NA NA service evening location NA lunch NA NA bathroom pool service evening location NA NA marriage NA balcony pool service night peace car dinner friends luxury NA NA service night location car breakfast family luxury NA NA 59 10.3.3. Contexto Formal Multivaluado Claude time environment transport company characteristics drinks room extras evening relaxing car NA NA NA NA beach night NA car NA NA coffee bathroom NA evening NA walk couple price wine NA restaurants night location walk marriage price NA bathroom NA NA location NA NA NA NA bathroom bars NA people car NA NA NA bathroom gym NA relaxing NA friends luxury NA balcony NA morning location taxi friends NA juice bed restaurants evening people NA couple NA wine NA restaurants NA NA walk NA NA coffee NA NA evening location walk couple comfort NA NA spa evening location walk NA luxury wine bathroom spa NA location NA NA comfort NA balcony NA morning NA NA couple price coffee bed NA morning location car NA NA coffee NA NA 10.4. Manual de usuario En esta sección se explican como usar la aplicación web. Se desarrollará paso por paso la secuencia que se debe seguir. 10.4.1. Página principal Para acceder a la pagina principal, es necesario que el archivo run haya sido ejecutado. Para acceder a la pagina principal debemos poner en nuestro navegador e ir a la dirección http://127.0.0.1:8080/Application/. Una vez accedamos a la pagina principal (ver figura 15, debemos pulsar en Nuevo Contexto Formal Multivaluado para empezar el proceso. 10.4.2. Subir ontoloía o FCMV En esta página (ver figura 16)se decide que camino usar. Si subimos una ontología, pasaremos al paso 2 (Sección 10.4.3). En cambio si decidimos subir un contexto formal multivaluado pasamos directamente al paso 3 (Sección 10.4.4). Una vez que subamos alguno de los, pulsamos el botón de siguiente para ir al siguiente paso. 10.4.3. Comentarios En este paso se suben los comentarios que se analizarán (ver figura 17). Para ello deben de añadirse pulsando el botón azul subir, o haciendo Drag and Drop. Una vez que se carguen todos los comentarios que queramos analizar, se debe de pulsar el botón superior de subir para que los archivos se suban. Finalmente se pulsa el botón siguiente para ir al siguiente paso. 60 Figura 15: Home Page 61 [24] Bernhard Ganter and Gerd Stumme. Methods and applications in computer science. Formal Concept Analysis, 46:1–117, 2002-2003. [25] Bernhard Ganter and Rudolf Wille. Formal concept analysis - mathematical foundations. Springer, 1999. [26] Ykä Huhtala, Juha Kärkkäinen, Pasi Porkka, and Hannu Toivonen. TANE: an efficient algorithm for discovering functional and approximate dependencies. Comput. J., 42(2):100–111, 1999. [27] José L. Leiva, Antonio Guevara, Carlos Rossi, and Andrés Aguayo. Realidad aumentada y sistemas de recomendación grupales. Estudios y Perspectivas de Turismo, 23:40–59, 2014. [28] Bing Liu. Opinion mining. pages 1–7. [29] Bing Liu. Sentiment analysis: A multi-faceted problem. IEEE Intelligent Systems, 2010. [30] Bing Liu and Lei Zhang. A survey of opinion mining and sentiment analysis. In Charu C. Aggarwal and ChengXiang Zhai, editors, Mining Text Data, pages 415– 463. Springer, 2012. [31] David Maier. The Theory of Relational Databases. Computer Science Press, 1983. [32] Noel Novelli and Rosine Cicchetti. Functional and embedded dependency inference: a data mining point of view. Inf. Syst., 26(7):477–506, 2001. [33] G. Stumme, R. Taouil, Y. Bastide, N. Pasqier, and L. Lakhal. Computing iceberg concept lattices with Titanic. J. Data and KnowledgeEngineering (DKE), 42(2):189– 222, 2002. [34] Nizar Messai Zainab Assaghir, Mehdi Kaytoue and Amedeo Napoli. On the mining of numerical data with formal concept analysis and similarity. 68