Escuela Politécnica Superior
Search! Búsqueda e integración de datos tabulares abiertos
aplicando técnicas de Inteligencia Artificial
Máster Universitario en Ciencia de Datos
Trabajo Fin de Máster
Autor:
Alberto Berenguer Pastor Tutores:
Jose Norberto Mazón López David Tomás Díaz
Septiembre 2021
Search! Búsqueda e integración de datos tabulares abiertos aplicando técnicas de
Inteligencia Artificial
Search!
Autor
Alberto Berenguer Pastor Tutores
Jose Norberto Mazón López
Departamento de Lenguajes y Sistemas Informáticos David Tomás Díaz
Departamento de Lenguajes y Sistemas Informáticos
Máster Universitario en Ciencia de Datos
Escuela Politécnica Superior
ALICANTE, Septiembre 2021
Preámbulo
Uno sabe dónde empieza, pero no dónde acaba. En mi caso, aquí estoy, elaborando el trabajo de fin de máster, otra etapa de mi vida que se cierra, y una nueva que se abre. Por un motivo o por otro la vida me ha llevado a estudiar, y esperemos trabajar, en el mundo de los datos, un mundo lleno de luces y sombras, pero que, sin embargo, parece ser que será una de las herramientas clave para el futuro (y presente).
La idea de este trabajo surge de una propuesta de mi tutor de TFG, José Norberto a raíz de una de sus investigaciones. Cuando me contó de que se trataba, por dentro pensé Why not?, era una buena idea, original y me hubiera resultado de gran utilidad en muchas ocasiones a lo largo del máster, así qué, ¿porque no intentar llevarla a cabo? y a ver que sale.
Sin embargo, las ideas están muy bien, se te pueden ocurrir cosas increíbles en una fracción de segundo, pero eso no lo es todo. Ya que una buena idea, sin una buena ejecución/desarrollo se queda en nada. Y ese iba a ser mi reto para este trabajo, tratar de transformar la idea propuesta en un buen proyecto y posteriormente comprobar la efectividad de esta, viendo si realmente merecería la pena o no, llevar esta idea a un nivel más alto como una investigación más compleja o incluso un producto comercial.
Resumen
Los datos son un recurso muy preciado hoy en día, dónde cada vez se es más y más cons- ciente de la importancia que tiene su utilización, pudiendo marcar muchas veces la diferencia entre empresas, aplicaciones móviles o investigaciones. Uno de los tipos de datos más utili- zados, son los datos tabulares, es decir, aquellos conjuntos de datos que están constituidos por tablas, y que se pueden encontrar comúnmente en formatos como CSV, Excel o tablas HTML. Este tipo de datos, tiene multitud de aplicaciones, desde practicar la minería de datos, alimentar el entrenamiento de modelos de inteligencia artificial, contrastar hipótesis científicas o simplemente para realizar el informe anual de ventas de una tienda.
Muchas organizaciones trabajan con sus propios datos, pero en ocasiones, se requiere de datos externos para poder llevar a cabo ciertas tareas o complementar cierta información.
En estos casos, juegan un papel importante los datos abiertos, aportados por instituciones y empresas que ofrecen sus datos en portales de datos abiertos para ser reutilizados por cualquier persona.
Para cualquiera de las tareas antes mencionadas, el primer paso, es la búsqueda de datos, siendo este un paso tan importante como el propio análisis de los datos, y en el que reducir el tiempo de búsqueda y proporcionar facilidades para encontrar los datos más afines a nuestras necesidades es fundamental para garantizar unos mejores resultados. Los métodos de búsqueda que utilizan hoy en día en los buscadores de los portales de datos abiertos se basan principalmente en los metadatos de los conjuntos, sin embargo, este tipo de búsqueda puede no ofrecer siempre los mejores resultados, ya que depende de la calidad con la que hayan sido definidos esos metadatos, tarea que es realizada manualmente por las personas que aportan los datos, y también de la capacidad de esos metadatos de representar correctamente el conjunto.
Este trabajo propone una nueva técnica para realizar la búsqueda de datos, de forma que no sea dependiente únicamente de los metadatos sino del propio contenido, que es, al fin y al cabo, lo que es realmente importante. Esta técnica está basada en modelos de words embeddings, que son modelos que ofrecen representaciones vectoriales de las palabras, estos modelos han sido entrenados con grandes cantidades de texto proveniente de internet, y dónde cada vez más, grandes empresas relacionadas con la IA, sacan modelos cada vez más grandes, más precisos e incluso disponibles para diversos idiomas.
La obtención de los words embeddings proveniente del contenido de cada conjunto de datos permiten realizar una búsqueda diferente, que además, se puede ser realizada de tal forma, que la búsqueda sea en función la tarea para la que queremos los datos row extension o column extension.
En este trabajo de fin de máster, se ha desarrollado un buscador que hace uso de esta nueva técnica para realizar las búsquedas, además de proveer de una interfaz de búsqueda diferente a la que estamos acostumbrados, estando orientada a la búsqueda de datos tabulares.
Adicionalmente, se provee de una interfaz de integración entre datos tabulares, que ofrece al usuario una forma sencilla y efectiva de realizar un primer procesamiento de los datos. Los
vii
viii Resumen
datos utilizados para ser buscados se obtuvieron desde diferentes portales de datos abiertos alrededor del mundo y que servirán para realizar las pruebas pertinentes a la eficacia de este proyecto.
Para probar si realmente es útil este buscador, se realizó un experimento con un grupo de 44 personas, y se les propuso realizar búsquedas de datos en 4 escenarios diferentes, en las que dado un conjunto de datos X, se pretendía que buscarán otro conjunto de datos Y para complementarlo. La mitad de las personas harían uso de los portales de datos abiertos con buscadores convencionales de datos y la otra mitad haría uso del buscador desarrollado en este trabajo. Tras finalizar el experimento y examinar los resultados, la mitad que utilizó el buscador de este trabajo obtuvo búsquedas más rápidas y precisas. Por lo tanto, esta técnica de búsqueda logra mejorar en medida los resultados que se obtienen respecto a buscadores convencionales.
Abstract
Nowadays data is a valuable resource, the world is aware of the importance of its use, it can make the difference between apps for mobile phones, enterprises, or investigations. Tabular data is one of the most used, it is made up of many rows of data and we can find it in formats such as CSV, Excel or HTML tables. These types of data are frequently used by researchers during data mining, deep learning models training, hypothesis contrast, and more.
A lot of organizations work with is own data, but sometimes, they need some external resources to do some tasks. In this cases, open data it’s a very important thing, data contri- buded by organizations who offers his data on open data portals to everyone.
To work with data, the first step to be able to accomplish these tasks is to search the data, this step has the same importance as the data analysis part, where the principal goal is to reduce the search time and make it easier to find the data. Using this method we can achieve better results. Nowadays methods are based on dataset metadata, however this search type could not obtain the best results because it depends on the quality of metadata description, a task provided by data publishers, and the ability of the meta data to represent the dataset.
This research pretends to find a new search technique, one that is not metadata dependent and allows data content to play a role on the search, because it is the real important thing.
This technique is based on word embeddings models, these models offer vectorials represen- tations of the words and were trained with a big quantity of textual information from the internet, where each day, more and more important tech enterprises are training big models with high accuracy and also it is available in different languages.
Get word embeddings from the dataset content provide a new way to search the data. Also the search can be focused on a specific task, like row extension or column completion.
In this research, I have been developing a search engine which uses the word embedding technique. Also, it provides a new search interface focused on tabular search. Furthermore, a table integration interface is provided, which allows the user to obtain a first processing process in an effective and simple way. The data used on this project is provided from open data portals around the world and it serves to realize the pertinent experiments to check the efficiency of the approach.
To check the utility of this search engine, an experiment has been performed, 44 students have been challenged to resolve four questions about data retrieval, they received a data- set X and they have to find another dataset Y to complement it. The half part have used the current search engines from open data portals and the other part have used the search engine developed in this research. The experiment’s results have shown that the search en- gine developed here helps to obtain fast and better results. Consequently, this approach can significantly improve the search results from traditional search engines.
ix
Agradecimientos
En primer lugar, agradecer a mi familia y a mi pareja todo su apoyo y su confianza depositada en mí.
Sin ellos no sería nada.
Agradecer también a mis tutores José Norberto y David por su ayuda, por aportar sus conocimientos y por su paciencia.
También a mis amigos y compañeros por darme sus ideas, opiniones y sobretodo sus ánimos para acabar este trabajo.
Es a ellos a quien dedico este trabajo.
The scientist is not a person who gives the right answers, he’s one who asks the right questions.
Claude Levi-Strauss.
xiii
Índice general
Resumen vii
Abstract ix
1. Introducción 1
2. Objetivos 5
3. Marco Teórico 7
3.1. Búsqueda de datos abiertos tradicional . . . 7
3.1.1. Búsqueda de datos tabulares . . . 9
3.2. Buscadores . . . 10
3.2.1. Centralizados . . . 11
3.2.2. Descentralizados . . . 11
3.3. Introducción a los word embeddings . . . 11
3.3.1. ¿Qué son los embeddings? . . . 11
3.3.2. ¿Como se obtienen los embeddings? . . . 12
3.4. Uso de word embeddings para búsqueda e integración de datos . . . 13
4. Análisis y especificación 17 4.1. Descripción general . . . 17
4.1.1. Funciones del producto . . . 17
4.1.2. Características de los usuarios . . . 17
4.1.3. Dependencias . . . 17
4.2. Requisitos funcionales . . . 18
4.3. Requisitos no funcionales . . . 19
5. Diseño 21 5.1. Arquitectura conceptual . . . 21
5.2. Arquitectura tecnológica . . . 22
5.2.1. Almacenamiento . . . 22
5.2.2. Microservicio Python . . . 23
5.2.3. Crawler . . . 23
5.2.4. Aplicación web . . . 24
5.2.5. Modelos . . . 24
5.2.6. API . . . 24
5.3. Estructura de los datos almacenados . . . 25
5.4. Diseño del API . . . 25
5.5. Diseño Web App . . . 27
5.5.1. Logotipo . . . 27
xv
xvi Índice general
5.5.2. Colores . . . 27
5.5.3. Tipografías e iconos . . . 28
5.5.4. Mockups web . . . 29
6. Desarrollo 33 6.1. Entorno de desarrollo . . . 33
6.2. Preparación del almacenamiento . . . 33
6.3. Obtención de datos . . . 34
6.4. Microservicio . . . 35
6.4.1. Obtención de embeddings . . . 36
6.4.2. Comparación de tablas . . . 37
6.4.3. Búsqueda . . . 38
6.5. La API . . . 41
6.6. La Web App . . . 42
7. Pruebas y validación 47 7.1. Test rendimiento . . . 47
7.1.1. Rendimiento web . . . 47
7.1.2. Rendimiento consultas . . . 48
7.2. Test API . . . 48
8. Experimentación 51 8.1. Resultados . . . 51
8.1.1. Discusión de resultados . . . 53
9. Conclusiones 55 9.1. Estado actual . . . 55
9.2. Trabajo futuro . . . 55
9.3. Limitaciones . . . 57
9.4. Nociones aprendidas . . . 57
9.5. Conclusión final . . . 58
Bibliografía 59 A. Anexo I 61 A.1. Preguntas portales de datos abiertos . . . 61
A.2. Preguntas buscador . . . 61
Índice de figuras
3.1. Modelo conceptual DCAT . . . 8
3.2. Motivos de búsqueda . . . 10
3.3. Embedding de la palabra ’king’, representada por un vector de 50 dimensiones. 12 5.1. Esquema conceptual del sistema propuesto. . . 21
5.2. Esquema conceptual del sistema propuesto. . . 22
5.3. Logotipo Search! . . . . 27
5.4. Color principal . . . 27
5.5. Colores secundarios . . . 27
5.6. Ejemplo de texto con Maven Pro . . . 28
5.7. Ejemplo de iconos ofrecidos por Font Awesome . . . 28
5.8. Página principal de la web . . . 29
5.9. Página resultado de la búsqueda . . . 30
5.10. Página resultado de integración de datos . . . 30
5.11. Página con información sobre el proyecto . . . 31
5.12. Página sobre los componentes que han participado en el proyecto . . . 31
5.13. Página con los datos de contacto . . . 32
6.1. Esquema resumen del proceso de búsqueda . . . 39
6.2. Página principal de la aplicación web . . . 43
6.3. Tooltip que muestra la funcionalidad de un botón . . . 44
6.4. Página principal con ”Take a tour” activado . . . 44
6.5. Página de resultados de búsqueda . . . 45
6.6. Preview de los datos de un resultado . . . 45
6.7. Página de integración de datos . . . 46
7.1. Resultados obtenidos en https://developers.google.com/speed/pagespeed/ insights/ . . . 47
7.2. Tiempo de respuesta ofrecido por la herramienta para desarrolladores del na- vegador . . . 48
7.3. Colección de llamadas guardadas en Postman para el testeo de funcionalidades 49 8.1. Cantidad de aciertos totales para cada pregunta (Portales vs Buscador) . . . 52
xvii
Índice de tablas
4.1. Requisito funcional para cargar datos (RF-1) . . . 18
4.2. Requisito funcional para buscar (RF-2) . . . 18
4.3. Requisito funcional para previsualziar datos (RF-3) . . . 18
4.4. Requisito funcional para descargar datos (RF-4) . . . 18
4.5. Requisito funcional para integrar datos (RF-5) . . . 18
4.6. Seguridad en la comunicaciones (RNF-1) . . . 19
4.7. Concurrencia (RNF-2) . . . 19
4.8. Rendimiento (RNF-3) . . . 19
4.9. Eficiencia (RNF-4) . . . 19
4.10. Buenas prácticas (RNF-5) . . . 19
4.11. Velocidad búsquedas (RNF-6) . . . 19
5.1. Datos almacenados en Solr de cada conjunto de datos . . . 25
5.2. Especificación API - Generación de embeddings . . . 25
5.3. Especificación API - Comparación de tablas . . . 26
5.4. Especificación API - Búsqueda . . . 26
5.5. Especificación API - Obtención URL . . . 26
5.6. Especificación API - Guardar logs . . . 26
5.7. Especificación API - Obtener preview . . . 26
6.1. Resumen de las especificaciones de cada máquina. . . 33
8.1. Resultados del experimento . . . 52
8.2. Resultado t-student : Tiempo invertido en buscar los conjuntos de datos . . . 53
8.3. Resultado t-student : Aciertos en la búsqueda de conjuntos de datos . . . 53
xix
Índice de Códigos
6.1. Código del endpoint ’/getComparison’ . . . 41 6.2. Código del endpoint ’/getPreview’ . . . 41 6.3. Código del endpoint ’/saveLog’ . . . 41
xxi
1. Introducción
La importancia de los datos esta cada vez más presente en nuestra sociedad, cada día se generan millones de datos provenientes de sensores, dispositivos móviles, aplicaciones, webs, etc. (Álvarez, 2014). Muchos de estos datos que se generan, se almacenan en forma de datos tabulares o tablas (en este documento se usará indistintamente el término tabla para referirnos a los conjuntos de datos tabulares).
Estos datos tabulares son un tipo de dato de especial importancia, siendo unos de los tipos de datos más usados en los portales de datos abiertos gubernamentales(46.4%) (Neumaier y cols., 2016) y cuyo predominio y prioridad en los portales de datos destaca en recientes estudios de la comisión europea (Comission, 2019) y la organización para la co-operación económica y desarrollo(OECD, 2018).
Estos datos tabulares son frecuentemente encontrados en internet en portales de datos, dispuestos por organizaciones que los generan y que los ofrecen a disposición de la ciudadanía en forma de datos abiertos, es decir, datos que cualquiera sea libre de utilizar, reutilizar y redistribuir, con el único límite, en su caso, del requisito de atribución de su fuente o reconocimiento de su autoría.
Los datos abiertos suelen pasar por un ciclo de vida formado por 2 fases, la publicación y el consumo. La primera fase, como hemos dicho es la publicación, típicamente realizada a través de un portal de datos abiertos dónde la administración encargada de producir o recolectar los datos los hace accesibles al público y proporcionar funcionalidades de búsqueda. La segunda fase, es el consumo. Muchos estudios califican el consumo de los datos abiertos disponibles en estos portales un catalizador para la innovación, permitiendo crear productos de valor y servicios que beneficien a los ciudadanos (Enríquez-Reyes y cols., 2021). De este consumo de datos también se va a beneficiar este trabajo, ya que hará uso de estos datos para indexarlos y proporcionar facilidades a los usuarios para que puedan buscarlos y reutilizarlos para sus necesidades.
Los datos abiertos se pueden utilizar en multitud de tareas. Por ejemplo, personas empren- dedoras que empiezan a desarrollar una aplicación para testearla (producto mínimo viable) como es el ejemplo de Yuka https://yuka.io/ que empezó usando datos abiertos de open food fact1 o periodistas de datos que quieren contar una historia sobre los últimos hechos acontecidos alrededor de una temática concreta y que hacen uso de datos abiertos disponibles en páginas como https://www.epdata.es o incluso personas expertas en ciencia de datos que quieren crear un modelo de inteligencia artificial y que buscan en https://www.kaggle.com los datos. Sin embargo, es muy frecuente no disponer de los datos adecuados o, incluso, no encontrarlos aún cuando existen.
Cuando recurrimos a herramientas de búsqueda para obtener esos datos que necesita- mos, generalmente se hacen desde buscadores convencionales como www.google.com o espe- cializados como https://data.mendeley.com/research-data/ o https://datasetsearch
1https://world.openfoodfacts.org/
1
2 Introducción
.research.google.com/, pero estos tienen un factor en común, y es que para realizar sus búsquedas hacen uso de keywords Chapman y cols. (2019). Es decir, palabras claves rela- cionadas con los datos que buscamos. Sin embargo, quizá esta no sea la mejor manera de realizar la búsqueda de los datos que queremos, ya que esas keywords son dependientes de la calidad de los metadatos, como que estén todos rellenados, que sean descritos correctamente, que sean capaces de representar el conjunto de datos etc. Además el uso de keywords no corresponde con la naturaleza tabular de los datos que queremos buscar, por el hecho de que las búsquedas con keywords están pensadas para documentos textuales y cuando pretende- mos usar esto para buscar una tabla es difícil describirla mediante palabras, por ejemplo, si queremos una tabla con información de ciudades de Alicante y sus respectivas localizaciones, como keywords para buscarlas utilizaríamos por ejemplo, ”ciudades Alicante”, probablemente exista esa información en algún portal de datos abiertos, no obstante, las keywords por las que se pueda encontrar no sean ”ciudades” ni ”Alicante”, quizá exista en un conjunto de datos cuyas keywords sean ”Turismo” y ”Comunidad Valenciana”, en la que sí que existan estos datos que buscamos, pero que no los podamos encontrar por no haber tenido suerte a la hora de pensar la keywords o porque el conjunto de datos donde esté, use unas keywords que no son representativas, con esto se pretende mostrar que aún existiendo los datos, depende mucho de la habilidad de la persona que etiquete los metadatos para que sean realmente represen- tativos. Además, como hemos dicho, es difícil buscar tablas haciendo uso de keywords que las traten de representar, para el ejemplo anterior, una opción interesante sería dar ejemplos de esos datos tabulares para indicar, de manera más natural, datos tabulares similares a los que el buscador debe encontrar.
Otro aspecto importante es que, cuando una persona quiere buscar datos, suele ser con la intención de usarlos junto con datos ya existentes y que por lo tanto es necesario que los datos que encuentre se puedan integrar con los que tiene. Así pues, la búsqueda con keywords no se adapta a este escenario y sería más lógico buscar con los propios datos de una persona, datos similares que se puedan integrar.
Por este motivo, se proponen nuevas fórmulas de búsqueda e integración, basada en el propio contenido del conjunto de datos, es decir, se sustituye la búsqueda basada en keywords, por una búsqueda basada en las propias tablas, ya que podría ser una forma más acertada de realizar las búsquedas, permitiendo al usuario ahorrar tiempo y esfuerzo en buscar los datos que necesita. Este mismo tipo de búsqueda será la que se pretenda desarrollar en este proyecto para así poder contrastarla con los métodos de búsqueda convencionales.
La IA esta cada vez más presente en el día a día y como no podía ser de otra forma también esta incluida en los motores de búsqueda que utilizamos habitualmente. Una de estas técnicas que esta muy de moda, sobre todo en el tratamiento de texto, es el uso de word embeddings, una forma de representar numéricamente las palabras de forma que puedan se procesadas por algoritmos (Almeida y Xexéo, 2019). A su vez, empresas como OpenAI y Facebook, invierte mucho dinero y recursos en crear modelos entrenados con una cantidad ingente de recursos textuales para hacer sistemas IA cada vez más “inteligentes” (Rus, 2020) que, sin duda, podrán ayudar a realizar grandes avances tecnológicos en el futuro. En este trabajo se aplica esta técnica de words embeddings para desarrollar una herramienta de búsqueda e integración de datos, proporcionando así una aproximación novedosa en línea con las últimas investigaciones en este campo.
Pero no solo se ha trabajado en tratar de incorporar nuevas técnicas, sino que además, se
3
ha tenido que desarrollar interfaces novedosas de búsqueda e integración orientadas a tablas, derivadas de ir más allá de las keywords, ofreciendo una interfaz natural para el tipo de dato con el que se va a trabajar. Y teniendo en cuenta, que tras indagar en el estado de la cuestión, se puede afirmar que es la primera vez que se realiza este tipo de interfaces, suponiendo todo un reto en cuanto al diseño y a usabilidad.
Añadir además, que el proyecto se ha tratado de desarrollar pensado no solamente en la experimentación que se podría realizar con él a pequeña escala, sino que se ha tratado de diseñar de tal forma, que pueda ser llevado a producción como un producto comercial. Para ello, se ha procurado usar las tecnologías más eficientes y escalables que proporcionaran un producto profesional y viable a la larga.
La verificación del éxito de esta aproximación frente a otras, ha residido en la evaluación del proyecto por parte de usuarios reales mediante el desarrollo de un experimento, donde se ha usado el buscador desarrollado en este trabajo de fin de máster.
2. Objetivos
El objetivo principal de este trabajo de fin de máster es la creación de una herramienta que permita la búsqueda de datos tabulares similares a una tabla de entrada, y que además, proporcione una interfaz de integración rápida con los resultados de búsqueda. Este objetivo principal se podría dividir en los siguientes sub-objetivos:
• La recolección e indexación de datos tabulares disponibles en portales de datos abiertos, mediante scripts automatizados.
• El desarrollo e implementación de un algoritmo que permita medir la similitud entre dos conjuntos de datos tabulares diferentes.
• El diseño de una infraestructura tecnológica que pueda dar soporte a un buscador que permita integrar datos de forma efectiva.
• La creación de una Web App sencilla e intuitiva con la que puedan interactuar los usuarios y obtener el resultado esperado.
– Interfaz de búsqueda basada en datos tabulares y no en keywords como estamos acostumbrados.
– Interfaz de integración, que permita fusionar rápidamente el resultado de la bús- queda con los datos de entrada, mediante la operación correspondiente (join o union).
• Desarrollo de un microservicio para el cálculo de embeddings y la carga de modelos.
• La creación de una API que será utilizada por la web y que se conectará con el micro- servicio.
• Despliegue del proyecto en un servidor para habilitar su disponibilidad en la red.
• La realización de pruebas para poder determinar la efectividad del proyecto con usuarios reales.
5
3. Marco Teórico
En este capítulo, se pone en contexto algunos de los conceptos clave utilizados en el desa- rrollo de la solución, de esta forma lograremos una mejor comprensión del problema que nos atañe.
3.1. Búsqueda de datos abiertos tradicional
Como sabemos el uso de datos está en auge, y gracias a los datos abiertos cada vez se tiene una mayor disponibilidad de ellos.
Existen grandes comunidades como Wikidata1 que se encargan de obtener y mantener esos datos para que los desarrolladores puedan utilizarlo en sus aplicaciones, también, existen otros muchos datos que son compartidos entre organizaciones para obtener beneficio mutuo.
Existen muchos datos disponibles y a cada minuto que pasa se generan muchos más, pero, para poder utilizarlos la primera tarea que nos concierne es buscarlos, tarea la cual ha sido investigada por décadas, y de la cual existen todavía muchos problemas abiertos sin resolver, como la desconexión entre conjuntos de datos, la capacidad de atender a las necesidades del usuario, la disponibilidad y la fiabilidad de estos (Chapman y cols., 2019).
Los organizaciones encargadas de publicar los de datos generalmente aportan informació- n/metadatos sobre sus conjuntos de datos, como el título, la descripción, los nombres de las columnas, los tipos de datos, el autor, la fecha de creación o el lenguaje. Para ello, pueden usar herramientas como DCAT2el estándar de catalogación que contiene todos los metadatos necesarios para publicar los datos.
En concreto el catálogo DCAT, esta formado por el modelo conceptual que se muestra en (figura 3.1) en el que se ve como se relaciona cada elemento del modelo y que está compuesto por 6 clases principales:
1. dcat:Catalog representa el catálogo de datos y que cada objeto individual que contiene representa unos metadatos que describen un recurso. Su objetivo es ser una colección de metadatos de los conjuntos de datos o servicios disponibles.
2. dcat:Resource representa un conjunto de datos o un servicio o cualquier otro recurso que pueda ser descrito con metadatos. Esta clase no se usa directamente, pero es la clase padre de dcat:Dataset, dcat:DataService y dcat:Catalog
3. dcat:Dataset representa un conjunto de datos. Un conjunto de datos es una colección de datos publicado por un único agente.
4. dcat:Distribution representa una forma accesible del conjunto de datos, como por ejem- plo un archivo descargable.
1https://www.wikidata.org/wiki/Wikidata:Main_Page
2https://www.w3.org/TR/vocab-dcat-2/
7
8 Marco Teórico
5. dcat:DataService representa un servicio de datos, como una colección de operaciones disponibles por la API.
6. dcat:CatalogRecord representa un objeto de metadatos en el catálogo, principalmente en lo que respecta a la información de registro, como quién agregó el artículo y cuándo.
Figura 3.1: Modelo conceptual DCAT
El vocabulario aportado por herramientas como DCAT es utilizado por portales de datos abiertos que utilizan plataformas de publicación de datos como CKAN3 o Socrata4. Estas plataformas facilitan la publicación de los datos por parte de las administraciones, permitien- do ofrecer un catálogo de datos para su reutilización. Además, deben permitir el acceso a los datos a través de APIs, pudiendo realizar búsquedas y clasificar los conjuntos de datos.
Cuando se buscan datos, la mayoría de las búsquedas se realizan mediante keywords o CQL(Contextual Query Language) sobre los metadatos de los conjuntos de datos. También encontramos interfaces de búsqueda subyacentes basadas en SQL para consultar los datos o
3https://ckan.org
4https://www.tylertech.com/products/socrata
3.1. Búsqueda de datos abiertos tradicional 9
herramientas de filtrado para los metadatos. Uno de los grandes problemas de la búsqueda basada en metadatos es que los metadatos son establecidos por las personas que publican los datos y depende de su conocimiento del conjunto de datos y de su capacidad para describirlo la efectividad de estos sistemas de búsqueda. Algunos estudios (Pimplikar y Sarawagi, 2012) exploran la forma de usar el propio contenido de los conjuntos de datos como palabras clave a la hora de realizar la búsqueda. Otros tratan de solventar el problema de los metadatos, con la fusión semántica de algunos de ellos que ya han sido previamente definidos como los que forman el vocabulario del DCAT (Heyvaert y cols., 2015). O intentando utilizar información auto-categorizada a la hora de realizar las búsquedas (Kunze y Auer, 2013).
Otro tema que tratar y que encontramos en la búsqueda de datos es cómo devolvemos los resultados los resultados. Hay aproximaciones que establecen el ranking mediante las keywords(Zhang y Balog, 2018), otros establecen rankings más sofisticados usando técnicas de aprendizaje supervisado(Gysel y cols., 2017).
3.1.1. Búsqueda de datos tabulares
El tipo de datos que nos concierne en este proyecto son los datos tabulares. Es decir, aquellos datos que están almacenados en forma de tabla. Y el objetivo que se tiene es la búsqueda de este tipo de datos para poder interactuar y realizar operaciones sobre ellos. Generalmente, la búsqueda de este tipo de datos se suele realizar por varios motivos principales (figura 3.2) (Zhang y Balog, 2020):
• Extensión de columnas(Column extension): En el que dada una tabla inicial con datos, se desea buscar otra, que pueda extender esta misma, mediante la agregación de nuevas columnas, comúnmente conocido en base de datos como la operación join.
Distingue entre limitado y no limitado. Si es limitado, significa que la extensión se hace bajo nombres de columna previamente definidas, por el contrario, sería no limitado.
• Completar datos(Data completion): Se tiene una tabla inicial en la que faltan algunos datos, el objetivo es de descubrir esos datos faltantes para completar la tabla.
• Extensión de filas(Row extensión): Dada una tabla inicial incompleta, se trata de buscar tablas que puedan ser unidas y así completar la tabla, comúnmente conocido en base de datos como la operación union. Al igual que en Column extension, medir la similitud entre tablas es un proceso clave en esta tarea y puede ser vista como una tarea de completar una lista, dado un conjunto de items iniciales.
10 Marco Teórico
Figura 3.2: Motivos de búsqueda
Como hemos visto la búsqueda de datos se ha basado tradicionalmente en la utiliza- ción de keywords que buscan en la descripción de los datos o se busca teniendo en cuen- ta los valores de algunos otros metadatos que ofrece DCAT (como el formato o la licen- cia) pero no se ofrecen buscadores que tengan en cuenta el contenido de los datos tabula- res, como por ejemplo, si buscamos en el portal de datos abiertos de la ciudad de chicago https://data.cityofchicago.org/ datos sobre criminalidad, este portal buscará entre los metadatos de todos sus conjuntos de datos, mirando títulos, descripciones, tags etc, para encontrar los conjuntos de datos relacionados con criminalidad, pero estos metadatos en mu- chas ocasiones pueden no contener la información que un usuario necesita para determinar si un conjunto de datos es apto o no para sus necesidades, por tanto, esta limitación puede impactar notablemente en la calidad de los sistemas de recuperación de información.
Por otra parte, estudios como (Koesten y cols., 2019) demuestran la necesidad de interac- ción de los usuarios con los datos, ya que, solo con los metadatos mostrados en los resultados de búsqueda no suele ser suficiente para para comprobar si un conjunto de datos se atañe o no a sus necesidades para extender las filas(union) o las columnas(join). También, existen estudios tratando de averiguar cual es la mejor forma de que los usuarios interactúen con los conjuntos de datos para entenderlos mejor (Thomas y cols., 2015), algunas de las propuestas estudiadas basadas en búsquedas más sofisticadas como usar un conjuntos de datos como entrada de la búsqueda para obtener conjuntos de datos similares o permitir seguir entidades entre diferentes conjuntos de datos. Pero además, no solo el contenido de un conjunto de datos es importante a la hora de elegirlo, sino también algunos de sus metadatos como el tamaño, el formato o el lenguaje.
3.2. Buscadores
En la actualidad podemos encontrar multitud de buscadores enfocados en la búsqueda de conjuntos de datos y que se pueden dividir en varios tipos.
3.3. Introducción a los word embeddings 11
3.2.1. Centralizados
Por un lado, tenemos portales de datos abiertos institucionales, que permiten a los usua- rios buscar por los metadatos y que en muchos casos suelen estar basados en software como CKAN5, Socrata6 o OpenDataSoft7. Mediante este software se pretende facilitar la publica- ción de datos y unificar la forma en la que se expresan, facilitando a los usuarios las búsquedas.
No obstante, esta forma de búsqueda de estas herramientas limita las capacidades de búsque- da, ya que se basan únicamente en los metadatos y en ocasiones, los metadatos no son capaces de describir correctamente todo el potencial de los datos, ya que al final, las descripciones puestas en los metadatos están escritas por personas.
También tenemos portales de datos científicos como Elsevier8 o Figshare9 que funcionan de una forma muy similar a la anterior, basándose también en la búsqueda mediante palabras clave sobre los metadatos.
Finalmente, tenemos mercados de datos como Windows Azure Marketplace https://azure .microsoft.com/es-es/marketplace/ que contiene más de 100 fuentes de datos a la venta o Xignite https://www.xignite.com que tiene datos financieros. Lugares como estos ofrecen sus datos a cambio de un incentivo económico. Sus búsquedas se basan en la descripción de los datos y su principal reto es que el usuario pueda calcular el valor de los datos antes de adquirirlos.
3.2.2. Descentralizados
En los buscadores descentralizados, encontramos por ejemplo, los datos enlazados entre sí por la web y se que van descubriendo mientras se realiza la búsqueda mediante el seguimien- to de hipervínculos. También existen buscadores como GoogleDataSearch10 en el que se ha utilizado crawlers para buscar e indexar conjuntos de datos que usan schema.org o DCAT.
Al igual que este, existen otros centrados en un dominio específico. Como por ejemplo Data- Med11, que posee un crawler que identifica e indexa conjuntos de datos científicos de carácter biomédico.
3.3. Introducción a los word embeddings
En este apartado se va a realizar una introducción sobre qué son los word embeddings y como se obtienen, para así, tener una idea de como se podrían aplicar este concepto a soluciones tecnológicas.
3.3.1. ¿Qué son los embeddings?
El concepto de words embeddings (Mikolov y cols., 2013) es una de las ideas más utilizadas en el procesamiento del lenguaje natural, también conocido como PLN. Software que utiliza-
5https://ckan.org
6https://dev.socrata.com
7https://www.opendatasoft.com/es/
8https://www.elsevier.com/es-es/
9https://figshare.com
10https://datasetsearch.research.google.com
11https://datamed.org
12 Marco Teórico
mos día a día, como Google Translate, Siri, Alexa o incluso la predicción de texto del teclado de nuestro móvil, hace uso de este concepto para llevar a cabo su tarea.
Los embeddings no son más que representaciones vectoriales de las palabras. Estos vecto- res que representan las palabras son de una longitud x, dependiendo del modelo utilizado, por ejemplo, Word2Vec, que es uno de los modelos más famosos, utiliza un vector de 300 dimensiones.
Figura 3.3: Embedding de la palabra ’king’, representada por un vector de 50 dimensiones.
Cada una de estas dimensiones representa una característica de la palabra, aunque esta característica es a priori desconocida. Sabiendo esto, palabras similares, tendrán vectores similares. Por ejemplo, el vector de perro y de gato, tendrán bastantes de los componentes de su embeddings muy parecidos, y algunos no tanto. En la figura 3.3, podemos ver un ejemplo de ello, en este caso la representación vectorial de la palabra king.
Para calcular la similitud entre palabras, una forma muy común de calcularla es mediante la similitud del coseno (Alammar, 2019).
cos(θ) = A· B
∥A∥ · ∥B∥ =
∑n
i=1AiBi
√∑n
i=1A2i√∑n
i=1Bi2
(3.1)
Siendo A y B los dos vectores, cada uno representativo de una palabra.
Una de las propiedades curiosas de los embeddings son las analogías. Podemos realizar operaciones con los embeddings de diferentes palabras para obtener embeddings de palabras distintas. Un ejemplo clásico que encontramos en la literatura es el siguiente: king - man + woman. Es decir, que, si al embedding de king le restamos el de man y le sumamos el de woman, nos obtendrá un embedding muy similar al de queen.
3.3.2. ¿Como se obtienen los embeddings?
Los modelos del lenguaje, tienen ventaja respecto a cualquier otro tipo de modelo, ya que para entrenarlos hace falta texto y desde el inicio de internet tenemos una abundante cantidad de texto fácil de conseguir, desde la Wikipedia, pasando por los artículos, páginas web, blogs y redes sociales, toda esta información puede ser usada para crear modelos de word embeddings, lo que diferenciará a un modelo de otro será la forma de entrenarlo.
Nos quedamos con esta cita de J.R. Firth ”You shall know a word by the company it keeps”.
La obtención de los embeddings de una palabra tiene mucho que ver con el contexto en el que se utiliza esta palabra. Una forma de entrenar un modelo de embeddings, podría ser, dado un texto, crear un conjunto de entrenamiento basado en n-gramas, por ejemplo, de tres palabras y dado el embedding de las primeras dos palabras tratar de predecir la siguiente. Una mejora respecto a esto se podría conseguir, no solo teniendo en cuenta las palabras de atrás para la predicción sino las siguientes palabras, ya que así se obtienen una mejor visión del contexto, esta técnica es llamaba ’bolsa de palabras continua’.
3.4. Uso de word embeddings para búsqueda e integración de datos 13
Una vez se tiene una arquitectura seleccionada, lo que se hace es entrenar el modelo, realizando las predicciones y ajustando el modelo en función de cómo de precisos sean los resultados. Una vez finaliza el entrenamiento, se extraen los embeddings del modelo y ya pueden ser usados en cualquier otra aplicación de PLN, como el análisis de sentimiento, la clasificación de documentos o la creación de resúmenes automáticos, ya que el conocimiento adquirido por el modelo se “transfiere” a la nueva tarea, donde estas representaciones se ajustan (fine-tunning) para el objetivo concreto que se quiera conseguir.
Para entrenar un modelo como Word2Vec, lo primero que se hace es preprocesar el texto y obtener un vocabulario, formado por todas las palabras diferentes que componen el texto.
Al empezar la fase de entrenamiento, el modelo tendrá dos matrices, la matriz embeddings y la context cada una de ellas tendrá una fila para cada palabra del vocabulario y luego una columna para cada dimensión del embedding. Al principio estadas dos matrices se inicializan con valores al azar, al empezar el entrenamiento se van actualizando los valores de estas dos matrices en función del error que se vaya obteniendo para cada palabra en el proceso de entrenamiento. Cuando finaliza este proceso se descarta la matriz contexto y nos quedamos con la matriz embeddings siendo el vector de cada fila representativo de la palabra.
Existen otras alternativas a Word2Vec, algunas de ellas son FastTex12o GloVe13. FastTex es una extensión de Word2Vec que hace un cambio respecto a los datos de entrada en el entrenamiento y es que, en vez de utilizar palabras completas utiliza n-gramas de las palabras, de tal modo que si tenemos por ejemplo, la palabra ’artificial’ y se utiliza un n-grama de n=3, usará <ar, art, rti, tif, ifi, fic, ici, ial, al> , dónde los símbolos de > y < indicarán el principio o final de palabra. De esta forma se ayuda a capturar el significado de palabras cortas y de los prefijos y sufijos de las palabras. Se ha demostrado que fastTex funciona bien con palabras poco frecuentes. GloVe, abreviatura de Global Vectors, es una aproximación en la qué, en vez de extraer los embeddings de una red neuronal entrenada en tareas de predicción, calcula los embeddings basándose en técnicas de factorización matricial en la matriz word-context.
3.4. Uso de word embeddings para búsqueda e integración de datos
En el mundo real, las personas que trabajan con datos requieren de bastante tiempo y esfuerzo para buscar e integrar la información de forma manual, por ello, una propuesta muy interesante para hacer uso los embeddings en la búsqueda e integración de datos es la encontrada en el artículo (González Mora y cols., 2020) la cual se ha inspirado este proyecto.
Tanto para la determinación de las operaciones correspondientes de integración como para la búsqueda, se propone hacer uso de la similitud semántica de las columnas de los conjuntos de datos mediante mecanismos de word embeddings, consiguiendo así, superar los problemas que acarrea usar aproximaciones léxicas. De forma qué, aún siendo las palabras “ciudad” y
“localización” muy distantes a nivel léxico, son similares a nivel semántico y esa información es realmente interesante en el desarrollo de soluciones de búsqueda e integración.
Cuando se trata con tablas, una buena forma de hallar la similitud entre dos tablas es trabajar con sus columnas para descubrir su similitud, y en las que hay que tener en cuenta
12https://fasttext.cc
13https://nlp.stanford.edu/projects/glove/
14 Marco Teórico
dos elementos, el nombre de la columna y el contenido en sí, es decir, las filas de datos que conforman esa columna.
El proceso para determinar la similitud entre columnas se puede dividir en los siguientes pasos:
• Normalización: El texto debe ser normalizado, aquellas palabras que hacen uso del estilo de escritura camelCase o que incorporen guiones para separar, se separan por espacios, también se aplica la eliminación de signos de puntuación y la transformación a minúsculas de todas las letras.
• Vectorización: Se utilizan modelos de words embeddings para obtener dos vectores por cada columna, uno representa el nombre de la columna y otro el contenido. Como los vectores representan palabras, en el caso de que un nombre de columna contenga dos palabras o más, se calcula la media de sus embeddings, siendo esta una de las técnicas más utilizadas para combinar embeddings, esta misma técnica es aplicada al contenido de la columna.
• Cálculo de la similitud de las columnas: Se aplicará el método comentado ante- riormente (fórmula 3.1), siendo uno de los más utilizados, la similitud por coseno, que nos proporcionará una valor de similitud entre 0 y 1, significando el 0 que no tiene ninguna similitud y el 1 que tienen la máxima similitud. Se puede dar el caso en el que una de las palabras de las que se quiera sacar el embedding del modelo no exista en el modelo utilizado, por ello se puede utilizar como método auxiliar alguna técnica como la distancia de Levenshtein 14 a la que además se le aplicaría una normalización, para que su valor quede también entre 0 y 1.
• Similitud final: Para el cálculo final de similitud se tiene en cuenta la siguiente fórmula:
sim(c1, c2) = α· sim(cn1, cn2) + (1 − α) · sim(cc1, cc2) (3.2) dónde sim(cn1, cn2) es la similitud entre los nombres de las columnas y sim(cc1, cc2) la del contenido y siendo α un parámetro en 0 y 1 que aporta cuanto peso tiene cada parte (nombre de columna y contenido) a la hora de calcular la similitud final.
• Selección: En el caso de que este proceso se haya utilizado para la integración, una vez calculadas las similitudes entre todas las columnas, se comprueba qué operación es más compatible de realizar. Para el caso de una operación join, debe de existir al menos una columna usada como clave candidata con un valor de similitud superior a un umbral específico. Los pares de columnas que superen este umbral serán usadas como columnas clave que servirán pare realizar el join. Para la operación union, se necesitaría que todas las columnas del conjuntos de datos tuvieran un nivel de similitud que superara cierto umbral, y aquellas que no lo superen sean eliminadas. Si un conjuntos de datos tiene gran parte de sus columnas superando este umbral, será apto para realizar el union.
14https://es.wikipedia.org/wiki/Distancia_de_Levenshtein
3.4. Uso de word embeddings para búsqueda e integración de datos 15
Respecto a la recuperación de información se podría utilizar fórmulas como la ecuación 3.3, que hace uso del proceso de cálculo de similitud de columnas previamente mencionado.
Dado un conjunto de tablas T , la similitud sim(t1, t2) para cada pareja de tablas t1, t2∈ T :
sim(t1, t2) =
∑i≤n,j≤m
i=1,j=i sim(c1i, c2j)
|C1||C2| (3.3)
dónde C1 = c11, c12...c1n y C2 = C21, C22...C2m es el conjunto de columnas de t1 y t2. La similitud entre las dos tablas se obtiene a partir de la media de similitud entre sus columnas.
Los word embedding están especialmente pensados para datos textuales (palabras), sin embargo, no siempre nos vamos a encontrar únicamente este tipo de datos en las tablas.
Puede que existan valores numéricos, pero se podría solucionar simplemente devolviendo únicamente la similitud del nombre de la columna, además existen modelos como fastText que cubren cierta cantidad de valores numéricos, lo cual es bastante interesante.
Experimentos realizados con este sistema demuestra que modelos con mayor cobertura de palabras como fastText proporcionan mejores resultados en tareas de búsqueda e integración.
Otro factor que también parece influir en la precisión de estos sistemas es el peso que se le da a cada parte en la ecuación 8.2, resultando ser de mayor importancia el contenido que el nombre de la columna en este tipo de aproximaciones.
Uno de los problemas más importantes que tiene este tipo de aproximaciones es el tiempo de ejecución que requieren, no obstante, existen soluciones que tratar de paliar este problema, como el uso de muestras representativa de la tabla que consiguen reducir drásticamente el tiempo de procesamiento de grandes conjuntos de datos.
4. Análisis y especificación
En esta sección se definirán las funcionalidades y requisitos que deberá cumplir el proyecto derivadas de los objetivos planteados en el capítulo 2. También se hablará de hacia qué usuarios está enfocado y si existen dependencias con otros productos.
4.1. Descripción general
Para la definición de los requisitos se utilizará el estándar de especificación de requisitos IEEE 8301. Este estándar nos proporcionará un modelo a seguir para definir el proyecto y nos ayudará a asegurarnos de que se abordarán todas las áreas requeridas, analizando todos los aspectos que involucran al proyecto y que lo ayudarán a convertirse en un producto completo con el que competir con los buscadores de portales de datos abiertos.
4.1.1. Funciones del producto
El producto tiene tres funcionalidades principales:
• La recolección de datos de los portales de datos abiertos y su posterior indexación en el buscador.
• La funcionalidad de búsqueda de datos, siendo esta el punto fuerte del producto y la cual lo diferencia de otros buscadores convencionales no solo por el tipo de datos con el que trata, ni por la interfaz que utiliza, sino por la forma en la que lo hace.
• La función integración que permite realizar una primer paso en la integración de los datos de forma sencilla y rápida en función de la necesidad de los usuarios.
4.1.2. Características de los usuarios
Los usuarios de este producto generalmente no van a ser usuarios corrientes que buscan información en internet, sino que van a ser usuarios que trabajan con datos en su día a día, investigadores, ingenieros o estudiantes que busquen datos para realizar sus trabajos.
4.1.3. Dependencias
En este producto existen dependencias de terceros, como es principalmente la calidad de los modelos de embeddings, que son un factor clave para el buen funcionamiento del buscador o por la parte de integración podemos hablar de la utilización de las librerías de terceros para procesar los conjuntos de datos, siendo su optimización y robustez los que permitan que se tenga una buena experiencia en la interfaz de integración. Para la indexación de los
1https://www.fdi.ucm.es/profesor/gmendez/docs/is0809/ieee830.pdf
17
18 Análisis y especificación
embeddings también dependemos de la librería Faiss y su capacidad para ser ejecutada en entornos con GPU o CPU.
4.2. Requisitos funcionales
En esta sección se especificará cuáles serán los requisitos funcionales del proyecto, es decir, aquellas funcionalidades que tendrá el sistema. Cada requisito queda reflejado en una pequeña tabla que constará de un identificador, una prioridad en cuanto a importancia para el sistema, un título y una breve descripción.
Identificador RF-1 Prioridad Alta
Título Introducción de datos de búsqueda
Descripción El usuario podrá cargar sus datos o escribirlos manualmente Tabla 4.1: Requisito funcional para cargar datos (RF-1) Identificador RF-2
Prioridad Alta
Título Búsqueda de conjuntos de datos
Descripción El usuario podrá buscar conjuntos de datos para su tarea concreta Tabla 4.2: Requisito funcional para buscar (RF-2)
Identificador RF-3 Prioridad Alta
Título Previsualización de los datos
Descripción El usuario podrá previsualizar los datos de los conjuntos de datos que aparezcan en los resultados de búsqueda
Tabla 4.3: Requisito funcional para previsualziar datos (RF-3) Identificador RF-4
Prioridad Alta
Título Descarga de los datos
Descripción El usuario podrá descargar los datos de los conjuntos de datos que aparezcan en los resultados de búsqueda
Tabla 4.4: Requisito funcional para descargar datos (RF-4) Identificador RF-5
Prioridad Alta
Título Integración de los datos
Descripción El usuario podrá integrar sus datos con los datos de la búsqueda, ya sea para extender o completar su dataset
Tabla 4.5: Requisito funcional para integrar datos (RF-5)
4.3. Requisitos no funcionales 19
4.3. Requisitos no funcionales
En esta sección se especificará cuales serán los requisitos no funcionales del proyecto, es decir, aquellos que no se refieren directamente a las funciones específicas que ofrece el sistema, sino a las propiedades emergentes de éste, como la fiabilidad, la respuesta en el tiempo y la seguridad. Al igual que en el apartado anterior, se dispondrán en forma de tabla todos estos requisitos, indicando el identificador, la prioridad y una breve descripción.
Identificador RNF-1 Prioridad Alta
Descripción El sistema garantizará una comunicación entre el cliente y servidor segura HTTPS (instalación de certificados SSL/TLS).
Tabla 4.6: Seguridad en la comunicaciones (RNF-1) Identificador RNF-2
Prioridad Alta
Descripción El sistema garantizará la capacidad de poder atender a un gran número de peticiones simultaneas.
Tabla 4.7: Concurrencia (RNF-2) Identificador RNF-3
Prioridad Alta
Descripción Optimizar los servicios para asegurar el mayor rendimiento de las in- fraestructuras.
Tabla 4.8: Rendimiento (RNF-3) Identificador RNF-4
Prioridad Alta
Descripción Utilización de la tecnología más eficiente para el almacenamiento y procesado de la información.
Tabla 4.9: Eficiencia (RNF-4) Identificador RNF-5
Prioridad Media
Descripción Garantizar la escalabilidad de producto y su mantenimiento. Uso de patrones en el código, comentarios, correcto tabulado...etc.
Tabla 4.10: Buenas prácticas (RNF-5) Identificador RNF-6
Prioridad Alta
Descripción Garantizar la obtención de los resultados de búsqueda en un tiempo razonable para un software de estas características.
Tabla 4.11: Velocidad búsquedas (RNF-6)
5. Diseño
Aquí trataremos de abarcar los diferentes diseños de las partes que componen el proyecto desde la arquitectura del sistema hasta el diseño de la interfaz. Explicando cada punto con todo detalle y cumpliendo con los requisitos establecidos en el análisis previo, de una manera sencilla y eficaz.
5.1. Arquitectura conceptual
El diseño y esbozado de cómo quedará la arquitectura del sistema conceptualmente y qué elementos formarán parte de ella, nos brinda una visión mucho más clara de cómo estará compuesto y facilitar así el desarrollo. El sistema que se ha desarrollado está compuesto por la siguiente arquitectura:
Figura 5.1: Esquema conceptual del sistema propuesto.
A grandes rasgos podemos definir parte de los elementos del sistema y cuál será su fun- cionamiento. El sistema se divide en dos partes principales: la primera, sería la búsqueda e indexación de conjuntos de datos por parte del crawler que se conectará a una serie de por- tales de datos abiertos predefinidos y extraerá la información de los conjuntos de datos para indexarlo en un motor de búsqueda propio e índices de embeddings especiales. La segunda
21
22 Diseño
parte, es la que concierne más al usuario, y se trata de una aplicación web que permita buscar entre los conjuntos de datos indexados por el crawler a través de la API, pero de una for- ma diferente a la que estamos acostumbrados, es decir, usando tablas en lugar de keywords.
También existe un microservicio, que carga unos modelos y posee unas funciones utilizadas por el crawler y por el buscador.
5.2. Arquitectura tecnológica
En esta sección se muestra como se relacionan las diferentes tecnologías utilizadas en este proyecto, además de describirlas brevemente.
Figura 5.2: Esquema conceptual del sistema propuesto.
5.2.1. Almacenamiento
Para el almacenamiento de los metadatos de los conjuntos de datos se ha usado el motor de búsqueda Solr1 versión 8.8.0, el cual tiene mucha relevancia en el mundo de los sistemas de recuperación de información. Es open source y funciona como una capa superior de Lu- cene2. Tiene características muy potentes como la búsqueda de texto distribuida, faceting, indexación en tiempo real, alta disponibilidad, funciones NoSQL, integración con Hadoop3 y la habilidad de poder tratar con documentos enriquecidos como Word o PDF.
1https://solr.apache.org
2https://lucene.apache.org
3https://hadoop.apache.org
5.2. Arquitectura tecnológica 23
La otra parte del almacenamiento correspondiente a los vectores es llevada a cabo con Faiss4, que es una librería que contiene varios métodos para la búsqueda de embeddings por similitud. Asume que las instancias que indexa son vectores identificados por un id numérico, y que pueden ser comparados por la distancia euclídea (L2) o por su producto. Los vectores con mayor similitud al vector de búsqueda tienen una menor L2 o un mayor valor si se utiliza el producto de vectores. También soporta el coseno de vectores, que es el producto de los vectores normalizados y siendo este el que se utilizará en este proyecto.
Muchos de los métodos que utiliza Faiss utiliza una representación binaria más óptima de los vectores, por ello, no almacena el vector original. Esto tiene un coste en cuanto a la precisión, no obstante, gana por otro lado, ya que permite almacenar billones de vectores en un solo servidor. Además, posee soporte para CPU y GPU, siendo esta última más rápida.
5.2.2. Microservicio Python
Uno de los componentes más importantes, es el microservicio encargado de cargar los modelos de embeddings para poder realizar operaciones con ellos, como el cálculo de nuevos embeddings y la indexación de estos. Para realizar estas tareas, al basarme en un código previamente programado en Python, el usar un microservicio basado en este mismo lenguaje era lo más sencillo. Por ello se utilizó Flask5, Flask es un microframework para Python basado en Werkzeug que permite crear aplicaciones web de todo tipo rápidamente. Debido a su sencillez y facilidad para poder crear API’s con él, lo consideré una buena opción para este proyecto. Además de que existen muchas extensiones para este framework como Flask-Restful y Flask-Marshmallow que hacen el API mucho más robusta y más fácil de evolucionar cuando esta crece en complejidad.
5.2.3. Crawler
El crawler, es el componente encargado de recolectar la información de determinados por- tales de datos abiertos.
Gracias a la existencia de plataformas de datos abiertos como CKAN o Socrata se facilita enormemente la publicación y el acceso a las colecciones de datos, y a lo que se le suma el valor de seguir un vocabulario estándar como DCAT que facilite el desarrollo de aplicaciones, como es el crawler usado en este proyecto, que hace uso de este tipo de vocabularios para guiarse en su extracción de metadatos.
Lo primero que se hace es hacer una consulta contra la plataforma de datos abiertos cuyo requisito sea, que la categoría del conjunto de datos sea ’Turismo’ o al menos se encuentre entre las palabras clave del conjunto. Esto nos devolverá una lista de conjuntos de datos que son los que se irán recorriendo, comprobando si su formato es CSV y preprocesando sus datos para que la información sea almacenada en el motor de búsqueda y en los índices Faiss. Para desarrollar esto se ha utilizado un script en Python, ya que es un lenguaje sencillo, moderno y apto para este tipo de tareas.
4https://faiss.ai/
5https://flask.palletsprojects.com/en/2.0.x/
24 Diseño
5.2.4. Aplicación web
En el desarrollo de la interfaz web, se han usado las tecnologías clásicas HTML5, CSS3 y JavaScript, sin tratar de recurrir a la utilización de ningún framework, para evitar añadir la dificultad y coste que supondría aprender a utilizarlo, y no viendo necesario su uso al no ser esta parte del proyecto demasiado compleja. No obstante, para la parte visual, sí que se han usado librerías de apoyo como Boostrap6 para facilitar el diseño, EnjoyHint7 para la creación de tutoriales interactivos muy visuales, Font Awesome8 para añadir iconos, y Danfo.js9 para tratar datos tabulares. La web estará disponible bajo un servidor Apache10.
5.2.5. Modelos
El modelo de word embeddings utilizado es uno de los disponibles en https://fasttext .cc/docs/en/english-vectors.html, en concreto el llamado crawl-300d-2M, un modelo que contiene 2 millones de vectores y fue entrenado con datos provenientes de la web. Entrenar un modelo de estas características requiere de unos recursos que poca gente tiene, por ello, el utilizar uno de los existentes en internet es una buena opción para hacer uso de esta tecnología sin el esfuerzo de entrenarla desde cero.
5.2.6. API
La API utilizada por la aplicación web utiliza Node.js11 una herramienta diseñada para crear aplicaciones network escalables, muy utilizada en el mundo del desarrollo web. Esta herramienta dispone de muchas librerías para facilitar el desarrollo de API’s como Express12, existe mucha documentación y tiene una gran comunidad detrás. Por ello, es una buena elección para realizar esta parte del proyecto.
6https://getbootstrap.com
7https://xbsoftware.com/products/enjoyhint/
8https://fontawesome.com
9https://danfo.jsdata.org
10https://www.apache.org
11https://nodejs.org/es/
12https://expressjs.com
5.3. Estructura de los datos almacenados 25
5.3. Estructura de los datos almacenados
Cuando el crawler encuentra un conjunto de datos, trata de obtener sus metadatos y contenido, con el que realiza una serie de procesos y que almacena en el motor de búsqueda con el formato que se ve en la tabla 5.1.
Nombre Descripción
solr_columns Array con los nombres de columna del conjunto de datos
solr_norm_columns Array con los nombres de columna del conjunto de datos normalizadas faiss_id_columns Array con los ids del índice faiss correspondientes a cada nombre columna faiss_id_content Array con los ids del índice faiss correspondientes al contenido de las columnas dcat_identifier ID del recurso
dcat_title Título del conjunto de datos dcat_desciption Descripción el conjunto de datos
solr_source Url en la que se encuentra el conjunto de datos dcat_theme Categoría del conjunto de datos
dcat_download_url Url de dónde poder descargar el recurso dcat_mediaType Formato del recurso, por defecto csv
dcat_modified Última fecha en la que se modificó el conjunto de datos dcat_license Tipo del licencia de la que dispone el conjunto de datos solr_preview Muestra con las 20 primeras filas del conjunto de datos
Tabla 5.1: Datos almacenados en Solr de cada conjunto de datos
5.4. Diseño del API
Para comunicar los diferentes servicios del proyecto se han desarrollado 2 APIs, una de ellas en Python y otra en JavaScript. La de Python nos va a servir para cargar el modelo del embeddings y así tenerlo ya en memoria, ya que el tiempo de carga es bastante alto. También contendrá varias funciones clave del proyecto. Y la de JavaScript servirá para ofrecer las funcionalidades desarrolladas, a la aplicación web.
Entre las llamadas disponibles de las APIs tenemos:
Ruta /getEmbeddings
Método GET
Parámetros JSON con el contenido de una tabla
Descripción Obtiene los embeddings de una tabla, tanto de los nombres de cada columna,
como de su contenido.
Tabla 5.2: Especificación API - Generación de embeddings
26 Diseño
Ruta /compare
Método GET
Parámetros JSON con el contenido de una dos tablas
Descripción Obtiene la similitud entre las columnas de dos tablas.
Tabla 5.3: Especificación API - Comparación de tablas
Ruta /search
Método GET
Parámetros JSON con la tabla que se desear buscar
Descripción Obtiene los ids de cada y el % de similitud de las columnas similares a las con que se ha hecho la búsqueda
Tabla 5.4: Especificación API - Búsqueda
Ruta /getDatasetData
Método GET
Parámetros Id del recurso
Descripción Obtiene la url dónde está disponible el conjunto de datos.
Tabla 5.5: Especificación API - Obtención URL
Ruta /saveLog
Método GET
Parámetros Cadena de texto con los datos que se quieren guardar
Descripción Procesa los datos de las operaciones realizadas y las guarda en un ar- chivo de log.
Tabla 5.6: Especificación API - Guardar logs
Ruta /getPreview
Método GET
Parámetros Id del recurso
Descripción Obtiene los datos para realizar la previsualización de un conjunto de datos.
Tabla 5.7: Especificación API - Obtener preview
5.5. Diseño Web App 27
5.5. Diseño Web App
Este apartado suele estar infravalorado, pero existen casos en los que suele marcar la diferencia entre el éxito o no de un proyecto, ya que el éxito no depende solamente de lo bien que funcione todo, si no de que también sea atractivo visualmente para el usuario y fácil de usar.
5.5.1. Logotipo
Para este proyecto se ha pretendido diseñar de logotipo simple y minimalista, que transmita confianza para los usuarios. Se compone de un cerebro, acompañado de unas barras laterales y el nombre del proyecto. La idea de usar un cerebro es que es un símbolo muy usado para representar proyectos de inteligencia artificial y me pareció una buena idea usarlo junto a la palabra search, ya que refleja muy bien lo que es el proyecto en sí.
Figura 5.3: Logotipo Search!
5.5.2. Colores
Como colores se han elegido los siguientes, por ser colores no muy saturados y agradables a la vista.
Figura 5.4: Color principal
(a) (b)
(c)
Figura 5.5: Colores secundarios
28 Diseño
5.5.3. Tipografías e iconos
La tipografía elegida para el diseño ha sido Maven Pro obtenida de Google fonts13, ya que es una fuente moderna y bastante agradable a la vista, facilitando así la lectura.
Figura 5.6: Ejemplo de texto con Maven Pro
En cuanto a iconos, se usará los proporcionados por la librería Font Awesome14, que pro- porciona una gran cantidad de iconos de forma gratuita, y es fácilmente incorporable al proyecto, dotándolo de mayor profesionalidad y usabilidad para los usuarios.
Figura 5.7: Ejemplo de iconos ofrecidos por Font Awesome
13https://fonts.google.com/specimen/Maven+Pro
14https://fontawesome.com
