Crawler para la web semántica Arachne

Texto completo

(1)CRAWLER PARA LA WEB SEMANTICA “ARACHNE”. PAOLA ANDREA ORTIZ CLAVIJO. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERIA DEPARTAMENTO DE INGENIERIA DE SISTEMAS Y COMPUTACION JULIO DE 2004.

(2) CRAWLER PARA LA WEB SEMANTICA “ARACHNE”. PAOLA ANDREA ORTIZ CLAVIJO. Trabajo presentado como requisito parcial para optar al título de Ingeniera de Sistemas y Computación.. Asesor: Dr. JOSE ABASOLO Profesor Titular. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERIA DEPARTAMENTO DE INGENIERIA DE SISTEMAS Y COMPUTACION JULIO DE 2004. 2.

(3) A mis papás por haber estado siempre conmigo y haberme brindado todo su apoyo y comprensión, a Camilo por su constante apoyo y cariño, sin ellos este trabajo no habría sido posible.. 3.

(4) AGRADECIMIENTOS. El autor expresa sus agradecimientos a: Dr. José Abasolo, profesor titular del Departamento de Sistemas y Computación, por su comprensión, atención y sobre todo sus valiosas orientaciones y concejos para poder realizar este trabajo. Ingeniero Edison Castaño Henao, que con sus aportes y conocimientos ayudó inmensamente al desarrollo del trabajo. A mis Padres y a Camilo, con su constante apoyo me fue posible cumplir con el objetivo de convertirme en profesional. A mis amigos que siempre me acompañaron en el camino.. 4.

(5) TABLA DE CONTENIDO. Pág. INTRODUCCIÓN. 11. 1. PRESENTACIÓN DEL PROYECTO………………………………….. 14. 1.1. ANTECEDENTES………………………………………………………. 14. 1.2. JUSTIFICACIÓN……………………………………………………….... 14. 1.3. OBJETIVOS DEL PROYECTO………………………………………... 15. 1.3.1. OBJETIVO GENERAL…………………………………………... 15. 1.3.2. OBJETIVOS ESPECIFICOS……………………………………. 15. 1.4. ALCANCE………………………………………………………………... 16. 2. MARCO TEÓRICO…………………………………………………………... 17. 2.1. WEB SEMANTICO…………………………………………………….... 17. 2.1.1. ONTOLOGÍA…………………………………………………….... 19. 2.1.2. MOTORES DE BÚSQUEDA……………………………………. 21. 2.1.2.1.. RECOLECCION (CRAWLING)…………………………. 21. 2.1.2.2.. PROCESAMIENTO DE LOS DOCUMENTOS……….. 22. 2.1.2.3.. PROCESAMIENTO DE LA CONSULTA………………. 24. 2.1.2.4.. FUNCIÓN DE BÚSQUEDA Y EMPAREJAMIENTO…. 25. 2.1.3. ARQUITECTURA DE CAPAS DE LA WEB SEMÁNTICA…… 2.1.3.1.. 26. CAPA DE CODIFICACION……………………………... 27. 2.1.3.1.1. URI……………………………………………………... 27. 2.1.3.1.2. UNICODE…………………………………………….... 27. 2.1.3.2.. CAPA DE SINTAXIS……………………………………... 28. 2.1.3.2.1. XML…………………………………………………….. 28. 2.1.3.2.2. XML-SCHEMA………………………………………... 28. 2.1.3.2.3. NAMESPACE………………………………………….. 29. 2.1.3.3.. CAPA DE DATOS……………………………………….... 30. 5.

(6) 2.1.3.3.1. RDF……………………………………………………... 30. 2.1.3.3.2. RDF-SCHEMA……………………………………….... 30. 2.1.3.4.. CAPA DE ONTOLOGÍA………………………………….. 31. 2.1.3.4.1. DAML……………………………………………………. 31. 2.1.3.4.2. OWL…………………………………………………….. 32. 2.1.3.5.. CAPA DE LÓGICA………………………………………... 33. 2.1.3.5.1. RULEML………………………………………………... 33. 2.1.3.5.2. NOTACIÓN3……………………………………………. 34. 2.2. CRAWLERS……………………………………………………………….. 35. 2.2.1. LA WEB INVISIBLE……………………………………………….. 36. 2.2.2. VIOLACIÓN DE COPYRIGHT……………………………………. 37. 2.3. THE ROBOTS EXCLUSION ESTANDAR……………………………... 38. 2.3.1. ROBOTS.TXT………………………………………………………. 38. 2.4. LOGS DE SERVIDORES DE WEB……………………………………... 40. 2.4.1. LOG DE REFERRER…………………………………………….... 41. 2.5. PAGERANK……………………………………………………………….. 42. 2.5.1. STRUCTURE MINING…………………………………………….. 44. 3. ESTADO DEL ARTE………………………………………………………….. 45. 3.1. CRAWLERS……………………………………………………………….. 45. 3.1.1. RDF CRAWLER……………………………………………………. 45. 3.1.1.1.. CARACTERÍSTICAS………………………………………. 45. 3.1.1.2.. VISTA GENERAL DE LA ARQUITECTURA……………. 46. 3.1.2. DAML CRAWLER………………………………………………….. 47. 3.1.2.1.. CARACTERÍSTICAS………………………………………. 48. 3.1.2.2.. VISTA GENERAL DE LA ARQUITECTURA……………. 49. 4. ARACHNE – CRAWLER PARA LA WEB SEMANTICA…………………. 50. 4.1. EL ALGORITMO…………………………………………………………... 50. 4.2. ARQUITECTURA FUNCIONAL…………………………………………. 57. 4.3. PROTOTIPO………………………………………………………………. 61. 4.3.1. FUNCIONES DEL SISTEMA……………………………………... 61. 4.3.2. CASOS DE USO…………………………………………………... 62. 6.

(7) 4.3.2.1.. USUARIOS………………………………………………….. 63. 4.3.2.2.. DIAGRAMA DE CASOS DE USO………………………... 63. 4.3.2.3.. CASOS DE USO EXPANDIDOS…………………………. 63. 4.3.3. MODELO DE DATOS……………………………………………... 64. 4.3.3.1.. DOCUMENTOS……………………………………………. 64. 4.3.3.2.. URLBASICOS_ERRONEOS……………………………... 65. 4.3.3.3.. URL_LOG…………………………………………………... 66. 4.4. HERRAMIENTAS DE IMPLEMENTACIÓN…………………………….. 68. 5. CONCLUSIONES Y TRABAJO FUTURO………………………………….. 69. BIBLIOGRAFIA…………………………………………………………………….. 71. ANEXOS. 77. ANEXO A. EXPLICACIÓN DE LA ONTOLOGÍA SWRC ESCRITA EN. 77. DAML+OIL…………………………………………………………………………... 7.

(8) LISTA DE FIGURAS Pág. Figura 1.. Componentes de la ontología………………………………………... 20. Figura 2.. Archivo Invertido……………………………………………………….. 24. Figura 3.. Arquitectura de capas…………………………………………………. 27. Figura 4.. Arquitectura de DAML Crawler………………………………………. 49. Figura 5.. Ejemplo de PageRank………………………………………………... 53. Figura 6.. Arquitectura MOLOBUS………………………………………………. 57. Figura 7.. Arquitectura de Arachne…………………………………………….... 58. Figura 8.. Representación Grafica de la Ontología SWRC…………………... 78. 8.

(9) LISTA DE TABLAS Pág. Tabla 1.. Ejemplo XML………………………………………………………….. 28. Tabla 2.. Ejemplo XML – Schema……………………………………………... 29. Tabla 3.. Ejemplo Namespace…………………………………………………. 29. Tabla 4. Estructura Productor – Consumidor………………………………... 47. Tabla 5.. Código del Algoritmo de PageRank……………………………….... 56. Tabla 6.. Ontología SWRC……………………………………………………... 77. Tabla 7.. Restricciones Ontología SWRC…………………………………….. 80. 9.

(10) LISTA DE ANEXOS Pág. Anexo A. Explicación de la ontología SWRC escrita en DAML+OIL……….. 77. 10.

(11) INTRODUCCIÓN Aunque Internet es la más reciente forma de publicar información, es la que más rápido está creciendo. La cantidad de información que existe en el mundo de Internet (sólo en la parte visible) es de 167 terabytes en el 2002 [31] y la cantidad de información existente en la llamada Web Invisible es aún mayor. Por esto, encontrar una página Web es casi imposible sin conocer la dirección exacta o a través de un motor de búsqueda. La mayoría del contenido disponible en la Web se encuentra diseñada para ser interpretada por humanos, más no por máquinas, haciendo que los motores de búsqueda actuales sólo reconozcan aspectos estructurales de las páginas (títulos, links), sin poder procesar su semántica. Actualmente, estos motores dan la misma importancia a todas las páginas Web, sin importar la manera en la que tratan el tema, si son o no autoridades en el tema. Todo lo anterior hace de las búsquedas actuales una tarea tediosa y que necesita una reestructuración. Para tratar de solucionar esto, Tim Berners-Lee1 presenta la Web Semántica: un proyecto que pretende dotar a la información de la Web estructura y significado, para que esta pueda ser entendida tanto por humanos como por máquinas. Este proyecto se encuentra aún en las etapas tempranas de desarrollo pero ya se cuenta con buenas ideas y proyectos desarrollados bajo este concepto.. 1. http://www.w3.org/People/Berners-Lee/ 11.

(12) El sistema MOLOBUS (Motor Lógico de Búsqueda Semántica) [1], es un modelo para el desarrollo de un Motor de Búsqueda Semántica con la capacidad de entender y procesar la información contenida en los documentos Web y además pueda inferir nueva información a partir de la ya existente [1]. Los motores de búsqueda, incluso MOLOBUS, tienen un repositorio de páginas Web sobre las cuáles hacen sus búsquedas, pero no tienen la capacidad de encontrar las páginas por ellos mismos. Necesitan la ayuda de otro programa que haga esto por ellos. Los Crawlers (spiders o robots) son programas dedicados a buscar. páginas,. analizando. cada. una de. ellas. para. poderlas. indexar. posteriormente e ingresar sus resultados en el repositorio y que el motor de búsqueda pueda consultarlas y desplegar un resultado acerca de una consulta específica de un usuario. El fin de este documento es dar una propuesta para desarrollar un crawler que apoye el desarrollo del proyecto MOLOBUS, alimentando el repositorio lógico. El documento está organizado de la siguiente manera: En el capítulo 1 se hace la presentación del proyecto. Aquí se incluyen antecedentes, justificación, objetivos y alcance del proyecto. El capítulo 2 contiene el Marco teórico, en donde se explican algunos de los conceptos utilizados en el documento. En el capítulo 3 se encuentra el estado del arte en donde se mencionan los proyectos más importantes desarrollados en el momento alrededor del proyecto de la Web Semántica. En el capítulo 4 se presenta la propuesta del crawler para la Web Semántica. Finalmente se encuentran las conclusiones, trabajo futuro, anexos y referencias bibliográficas.. 12.

(13) 1. PRESENTACIÓN DEL PROYECTO. 1.1.. ANTECEDENTES. Actualmente existe un gran interés por parte de la academia en el tema de la Web Semántica. Y es un tema que ha ido creciendo, pero que aún se encuentra en una etapa temprana de su desarrollo. En el Departamento de Ingeniería de Sistemas y Computación ya ha comenzado a dar los primeros pasos en este tema. El trabajo presentado en [1] es una primera etapa de un proyecto que sienta las bases para la construcción de software que sirva como herramienta de laboratorio e investigación. En [1] se presenta una propuesta de un motor de búsqueda para la Web Semántica que pretende proporcionar a la Web un mecanismo de búsqueda eficiente y eficaz con capacidades de consulta superiores a las existentes en los sistemas actuales. Además, se quiere brindar al usuario la posibilidad de que él mismo pueda hacer sus consultas tan precisas como lo permitan sus conocimientos del tema de interés: un motor donde el usuario tenga el control de los datos presentados como resultado de su consulta. El desarrollo propuesto en este documento pretende ser un apoyo al proceso realizado por MOLOBUS, realizando una tarea necesaria para poder completar el proceso, más no es parte del proceso en si.. 14.

(14) 1.2.. JUSTIFICACIÓN. El principal objetivo de MOLOBUS es el de brindar búsquedas inteligentes a los usuarios. Para hacer esto, necesita tener un repositorio de anotaciones a partir de las cuáles poder hacer las búsquedas. Mantener este repositorio actualizado no es parte del trabajo del motor de búsqueda; para esto necesita de la ayuda de un programa que lo mantenga actualizado: un crawler. Actualmente este proceso lo está llevando a cabo un crawler muy básico, diseñado para satisfacer las necesidades más básicas del proyecto sin tener en cuenta la calidad de los documentos recolectados, pues desarrollar un crawler eficiente no era la meta del proyecto. MOLOBUS puede presentar mejores resultados si cuenta con páginas de calidad. El propósito de esta tesis es diseñar un mecanismo que mantenga actualizado el repositorio con páginas de calidad.. 1.3.. OBJETIVOS DEL PROYECTO. 1.3.1. OBJETIVO GENERAL. Diseñar e implantar mecanismos para alimentar un repositorio de conocimiento de apoyo a la Web Semántica. 15.

(15) 1.3.2. OBJETIVOS ESPECIFICOS. Diseñar e implantar un crawler para alimentar un repositorio con ontologías y anotaciones que sea compatible con la tecnología actual (MOLOBUS). Especificar un algoritmo de depuración de documentos encontrados durante el proceso de búsqueda para remitir solamente documentos de calidad al repositorio. Diseñar e implantar una herramienta de gestión de los Crawler. Hacer pruebas y evaluar eficacia y eficiencia de la herramienta a desarrollar.. 1.4.. ALCANCE. Como resultado de este trabajo se obtendrá lo siguiente: •. Propuesta de una solución informática que permita la recolección de páginas Web anotadas, extrayendo de cada una de ellas las anotaciones allí encontradas, dejando sus resultados en un documento XML para que luego MOLOBUS los procese y los ingrese al repositorio local.. •. Definición de un algoritmo, basado en PageRank [24], que sea adecuado a la Web Semántica y que permita calificar los resultados encontrados para poderlos clasificar y determinar qué páginas son consideradas de calidad.. 16.

(16) 2. MARCO TEORICO. 2.1.. WEB SEMANTICO. (Tomado literalmente de [1]) En la actualidad no existe una forma automática de establecer eficazmente el contenido de los documentos publicados en la Web, ya que estos en su mayoría carecen de una estructura formal, lo que dificulta su procesamiento. De hecho, los datos generalmente extractados de un documento, con el fin de conocer su contenido, se limita a un conjunto de palabras inconexas que dicen poco o nada de la información allí contenida. Como consecuencia de la escasa información extraída de los documentos, los sistemas de búsqueda actuales limitan sus estructuras de consulta a palabras claves unidas con conectores booleanos que generan una cantidad considerable de coincidencias erróneas. Además, no es posible plantear consultas donde el resultado dependa simultáneamente de más de un documento Web o donde se determinen algún tipo de restricciones o reglas aplicables al contenido del documento. Estas y muchas otras limitaciones motivaron a Tim Berners – Lee a proponer la Web Semántica, con el fin de mejorar las capacidades de procesamiento automático de la información en la Web. La Web Semántica puede entonces ser definida como una extensión de la Web actual donde la información se encuentra dotada de una sintaxis y semántica formal, de modo que puede ser entendida tanto por personas como por programas informáticos. [35] Para construir la Web Semántica es necesario adicionar a las páginas Web. 17.

(17) información estructurada en forma de anotaciones. Las anotaciones permiten describir de manera formal el contenido o datos relevantes de la página Web o algún otro documento relacionado que se quiera mencionar. Las anotaciones referencian conceptos de uso frecuente dentro del dominio del conocimiento al que pertenecen. Las referencias se llevan a cabo por medio de direcciones URI’s que apuntan al documento donde se describen los conceptos, con ellos se garantiza que exista una definición única de los mismos. Los documentos a los cuales hacen referencia las anotaciones son conocidos como ontologías. Las ontologías describen conceptos, relaciones y reglas de una manera formal para un dominio del conocimiento. De la anterior definición es fácil establecer la similitud de una ontología con el esquema de una base de datos relacional donde las tablas equivalen a conceptos de la ontología, las llaves foráneas y tablas de relación son equivalentes a las relaciones y las restricciones equivalen a reglas, en ese orden de ideas, las anotaciones vendrían siendo los registros de las tablas y lo que tendríamos sería una base de datos distribuida donde la estructura de la misma se altera de forma dinámica mediante la adición de ontologías. De ahí, que la Web Semántica puede ser considerada como una gran base de conocimiento distribuida, donde las ontologías y anotaciones se encuentran escritas en lenguajes de representación del conocimiento. Ya que las ontologías pueden ser desarrolladas de forma independiente por cualquier usuario de la Web, debe existir la posibilidad de combinar información contenida en diversas fuentes. Este proceso es trivial en el caso que la información de un dominio haga referencia a una misma ontología, de lo contrario, si la información hace referencia a diferentes ontologías, con conceptos equivalentes nombrados de forma diferente, debe existir un mapeo previo para poder combinar la información. El mapeo se encarga de establecer los conceptos que son equivalentes de dos o más ontologías a través de una nueva ontología. Para procesar el conocimiento distribuido en la Web Semántica se requiere de. 18.

(18) programas capaces de entender y procesar la información contenida en las anotaciones y ontologías, estos programas son conocidos como agentes. Cada uno de los agentes cumple con funciones específicas conocidas como servicios automatizados, los cuales son descritos formalmente al igual que las anotaciones, permitiendo a otros agentes entender y utilizar estos servicios. De esta forma durante una consulta un agente puede solicitar información a un servicio de búsqueda automatizado ofrecido por otros agentes, quienes tendrían la posibilidad de desplazarse a través de las páginas recopilando y procesando información para dar cumplimiento a la solicitud. Este proceso describe una especie de cadena de valor, donde la información solicitada es la sumatoria de las informaciones parciales recopiladas por los agentes. En una etapa posterior de la Web Semántica, los servicios automatizados permitirán describir la funcionalidad de objetos del mundo real como televisores, equipos de sonido, DVD, hornos microondas, computadores, etc. La descripción de la funcionalidad en forma de servicios hará posible que los agentes interactúen con objetos reales de forma directa, realizando las tareas requeridas por los usuarios o por otros agentes.. 2.1.1. ONTOLOGÍA Para explicar el término ontología, se tiene que hacer uso de la definición dada por Gruber [36] que la describe como “una especificación explícita formal de una conceptualización compartida”. La conceptualización debe ser entendida como una vista abstracta del mundo que se desea representar. También se habla que una ontología es una especificación debido a que representa la conceptualización de una forma concreta generalmente a través del uso de lenguajes de representación del conocimiento. Es explícita y formal debido a que todos los conceptos y restricciones usados son explícitamente definidos de modo que sean entendibles y procesables para las máquinas. Además, es compartida porque. 19.

(19) contiene conocimiento consensual para una comunidad de usuarios. A continuación se explicaran los elementos fundamentales que forman parte de una ontología, como son la taxonomía y las reglas (Figura 1) La taxonomía define los conceptos o clases y las relaciones que los unen, ya sea dentro de la representación actual o haciendo referencia a alguna otra representación. Cada una de las clases tiene un conjunto de propiedades que describe sus características o atributos conocidos como slots. Además, las clases aplican el concepto de herencia por lo cual las subclases que son especificaciones de una clase superior, conservan las propiedades de la clase padre. Por ejemplo, en una ontología de vinos se puede definir una clase vino que posea una propiedad fecha_cosecha y dos subclases vino_blanco y vino_tinto, quienes heredan este atributo o propiedad de la clase vino.. Figura 1. Componentes de la Ontología. Las reglas que generalmente aparecen consignadas en una ontología son del estilo “X es padre de Y” y “Y en hermano de Z”, con las cuales un programa capacitado para realizar inferencia puede concluir por ejemplo que “X es padre de Z”. Adicionalmente las reglas son también utilizadas para plantear restricciones sobre las clases, estas reciben el nombre de facetas [35]. Una simple noción de ontología a la que se pueda hacer referencia es un glosario de términos de una jerga en particular, donde cada palabra tiene un significado expresado en lenguaje natural de una forma no ambigua.. 20.

(20) 2.1.2. MOTORES DE BÚSQUEDA. Un motor de búsqueda es un servidor o colección de servidores dedicados a recolectar, procesar y almacenar el contenido de páginas Web, tendiente a satisfacer los requerimientos de información de sus usuarios. Los resultados de las consultas son organizados de acuerdo a condiciones como el número de apariciones de una determinada palabra dentro del documento, cohesión entre las palabras de búsqueda y otros. Para explicar con mayor detalle la estructura y funcionamiento de los motores de búsqueda, se tomará como base el artículo “How a Search Engine Works” [37] publicado por la profesora Elizabeth Liddy, a partir del cual se puede establecer una división del motor de búsqueda en cuatro funciones: •. Recolección (Crawling). •. Procesamiento de los Documentos. •. Procesamiento de la Consulta. •. Función de Búsqueda y Emparejamiento. Se explicará cada una brevemente a continuación:. 2.1.2.1.. RECOLECCIÓN (CRAWLING). La recolección es la fase inicial del proceso de búsqueda en la cual un programa llamado crawler visita los sitios Web leyendo el código de las páginas y extrayendo información con la cual se crean entradas en el índice del motor de búsqueda. El crawler debe contar con un conjunto de direcciones para las cuales se realiza las. 21.

(21) operaciones de recolección de información. Estas direcciones se obtienen de los propietarios de páginas que envían propuestas para incluir o actualizar sus páginas en los índices y además de procesos de recolección anteriores. Una vez se cuentan con las direcciones se visita cada una de ellas. y se extraen los. vínculos a otras paginas que son almacenados y posteriormente utilizados para nuevos procesos de recolección hasta que todas las paginas se hayan leído. Los crawler son también llamados “Spider” por que ellos normalmente visitan muchos sitios en paralelo y sus “piernas” abarcan una gran área de la Web. Algunos crawler se adhieren a reglas de comportamiento para spiders, que se especifican. en la Norma para Exclusión de Robot (SRE) que se explicará. posteriormente (sección 2.4). Una práctica muy habitual entre los crawler es la utilización de mecanismo para prevenir la congestión del servidor donde se esta realizando la recolección de información, siendo para ello empleados algoritmos especiales que someten sus requerimientos a las cargas de trabajo del servidor.. 2.1.2.2.. PROCESAMIENTO DE LOS DOCUMENTOS. Una vez el crawler ha recolectado los documentos, empieza a operar el módulo para procesamiento de documentos quien se encarga de extraer la información necesaria del documento y de llevarla a la base de datos de modo que se facilite las búsquedas futuras. El procesamiento inicia con la estandarización de documentos que provienen de diversas fuentes y que se encuentra en diversos formatos de modo que se facilite los procesos posteriores. Teniendo ya un único formato para el documento, el proceso siguiente consiste en identificar las palabras potencialmente indexables del documento, que se adicionan a una lista de palabras.. 22.

(22) En este punto se realiza el análisis de palabras de parada que consiste en identificar y excluir de la lista de palabras aquellas que aportan poco significado. Entre las que no se indexan se tienen. artículos (a), conjunciones (y),. interjecciones (pero), preposiciones (en), pronombres (el) y formas especiales de verbo (es, son). Una vez excluidas las palabras de parada se realiza un análisis morfológico tendiente a ubicar la raíz de cada una de las palabras. Por ejemplo las palabras "computación", "computado", "computar" y "computador" tienen una raíz común que es “computa”. El análisis morfológico se encarga de agrupar y reemplazar todas las palabras por su raíz dentro de la lista de palabras. Por último, lo que se hace es asignarles pesos a cada una de las palabras de la lista a indexar de acuerdo a su importancia (mayor peso a palabras que aparecen con poca frecuencia en los documentos almacenados). Con esta información y la recolectada de los procesos anteriores se construye un índice o archivo invertido. Por ejemplo, una implementación de un archivo invertido (Figura 2) podría contemplar un léxico (LEXICON) que contiene las palabras indexadas (WORD). A estas palabras se les contabiliza el número de apariciones dentro de todos los documentos (NDOCS), siendo la información de cada uno de estos accedida a través de un puntero (PTR) a otra estructura. Esta es llamada índice de palabras y almacenan el ID del documento (DOCID) que corresponde a un valor numérico secuencial. Adicionalmente, para cada documento se almacena el número de apariciones de la palabra (OCURR) y la lista de las posiciones donde aparece (POS1, POS2) dentro del documento. Las posiciones se contabilizan de forma secuencial entre las palabras escogidas como indexables. Además, se podría incluir en esta estructura el peso asignado a cada palabra dentro del documento. Para ilustrar la forma como se vería un archivo invertido se presenta la siguiente figura:. 23.

(23) Figura 2. Archivo Invertido. 2.1.2.3.. PROCESAMIENTO DE LA CONSULTA. Un aspecto determinante en las consultas es el tiempo de procesamiento, ya que, en algunos casos, entre mayor sea este mejor será la calidad de los resultados. Uno de los problemas de la mayoría de los sistemas de búsqueda actuales es el detrimento de la calidad en los resultados a cambio de la disminución en tiempos de respuesta en las consultas. El procesador acepta consultas de usuario habitualmente construidas como un conjunto de términos que pueden estar unidos por operadores booleanos. Luego, divide la consulta, en términos y operadores, aplicando a la lista de términos los análisis de palabras de parada y morfológico de igual manera que en el procesamiento del documento.. 24.

(24) Ya que es crítico en el resultado de una consulta las palabras utilizadas en la misma, algunos motores emplean algoritmos de expansión de consulta. Estos algoritmos lo que hacen es reemplazar las palabras seleccionadas en la lista de términos por aquellos sinónimos mas comunes dentro de los documentos almacenados por el motor. Por ultimo, se le asignan pesos a los términos de la lista que determinan la importancia de cada una de las palabras dentro de la consulta. En ese sentido los motores de búsqueda presentan diferentes estrategias para asignar pesos a las palabras involucradas en las consultas. Una de las estrategias es contemplar el orden en que las palabras fueron organizadas y darle mayor prioridad o peso a las primeras palabras de la consulta; una forma mas avanzada de asignar los pesos seria determinando dentro de la base de datos cuales de las palabras involucradas en la consulta son menos comunes y a esas darles mayor peso.. 2.1.2.4.. FUNCIÓN DE BÚSQUEDA Y EMPAREJAMIENTO. Una vez procesados los documentos y la consulta, se utilizan algoritmos de recuperación de información para establecer la similitud de cada uno de los archivos invertidos de los documentos con respecto a la consulta. Los modelos de recuperación de datos más populares son el booleanos y los jerárquicos. El modelo booleano se caracterizan por darle al usuario mayor control sobre la consulta sin que sea determinante el orden en que los datos son presentados. Básicamente en este modelo se ubica los conjuntos de documentos que contienen alguno de los términos de la consulta. Luego se aplica los operadores booleanos a los conjuntos de documentos obteniendo un único conjunto que cumple con las condiciones de la consulta. [53]. 25.

(25) Los modelos jerárquicos tienen la particularidad de permitirle al usuario hacer consultas en lenguaje natural y durante el proceso de búsqueda asignan una puntuación a los documentos sobre los cuales se realiza el emparejamiento (computo de similitud), con el fin de mostrar los datos en orden de importancia al usuario. Entre los modelos que forman parte de este grupo se tiene el VectorEspacio y el Probabilístico. [53]. 2.1.3. ARQUITECTURA DE CAPAS DE LA WEB SEMANTICA. La explicación de las tecnologías y estándares actualmente desarrollados para la Web Semántica se realizó con base en la arquitectura de capas propuesta por Tim Berners – Lee durante la charla dada en la conferencia XML World 200 en Boston. La estructura de capas de la Web Semántica reduce la cantidad de estandarización requerida e incrementa el re-uso. De hecho, las dos primeras capas del modelo son heredadas de la Web actual. Dentro de la capa de codificación se encuentra el unicode para representar caracteres de los lenguajes y los URI’s para la localización de cualquier objeto. En la capa de sintaxis se encuentran XML, el namespace y el XML – Schema, quienes representan, jerárquicamente, datos estructurados en una sintaxis de marcaje común. La capa de datos comprende RDF, quien soporta la representación de grafos por medio de tripletas <sujeto, predicado, objeto>. En la capa de ontología se encuentran DAML y OWL, representando relaciones y reglas complejas. Luego aparece la capa de lógica que aún está en una etapa temprana de desarrollo y cuyo objetivo es representar el conocimiento a través de reglas que soporten la inferencia. Finalmente, las últimas dos capas de prueba y confianza aún se encuentran en discusión.. 26.

(26) Figura 3. Arquitectura de Capas (Tim Berners – Lee, XML World 2000). 2.1.3.1.. CAPA DE CODIFICACION. 2.1.3.1.1.. URI. Un URI (Uniform Resource Indicator) [38] es, cómo lo dice su nombre, un identificador de recursos. Los URL (Uniform Resource Locator) son el subconjunto más conocido de URI, que proporciona el mecanismo para identificar de forma inequívoca cualquier recurso en la Web.. 2.1.3.1.2.. UNICODE. El unicode [39] permite independizar de la plataforma y del lenguaje el número ASCII para todo caracter, permitiendo a cualquier lenguaje ser representado en cualquier plataforma. Hay tres formatos para codificar caracteres unicode que son UTF-8, UTF-16 y UTF-32, quienes son convertibles entre sí. 27.

(27) 2.1.3.2.. CAPA DE SINTAXIS. 2.1.3.2.1.. XML. El XML (eXtensible Markup Lenguage) [40] es un meta lenguaje para crear lenguajes de marcaje que especifican una codificación sintáctica de documentos, permitiendo su intercambio entre aplicaciones. XML es un estándar que describe cómo declarar y usar las estructuras de datos basadas en árboles dentro de los documentos de texto plano. Un documento bien formado de XML define un árbol de conjuntos anidados de etiquetas abiertas y cerradas (Tabla 1), cada una de las cuales puede incluir varios pares de atributo-valor.. <estudiante> <nombre> Pepito </nombre> <facultad> Ingeniería </facultad> <nacimiento> 1979-06-23 <nacimiento> <email> [email protected] </email> </estudiante>. Tabla 1. Ejemplo XML. 2.1.3.2.2.. XML-SCHEMA. XML-Schema [41], al igual que el DTD, es usado como lenguaje para describir la estructura de los documentos XML. XML-Schema cuenta con un amplio rango de tipos de datos atómicos (entero, punto flotante, fecha, cadena, etc.) y la posibilidad de formar tipos de datos complejos. De hecho, el principal rol de XML-Schema en la Web Semántica consiste en soportar la definición de atributos con tipos de. 28.

(28) datos. atómicos. (Tabla. 2).. Además,. XML-Schema. también. posibilita. la. especificación de muchos tipos de restricciones que pueden llegar a ser de utilidad.. <estudiante rdf:ID=”Pepito”> <edad rdf:datatype=”http://www.w3.org/2001/XMLSchema#positiveInteger”>24</edad> </estudiante>. Tabla 2. Ejemplo XML-Schema. 2.1.3.2.3.. NAMESPACE. Un namespace [42] es una abreviación de un fragmento de URI, usada como prefijo en un documento XML. Generalmente, los namespace son declarados como atributo en la raíz del documento (Tabla 3). Cuando un documento XML que contiene namespace es parseado, todos sus namespace son reemplazados con los fragmentos de URI correspondientes, identificando nuevamente los elementos de forma única.. <rdf:RDF xmlns:rdf = “http://www.w3.org/1999/02/22-rdf-syntax-ns#” xmlns:rdfs = “http://www.w3.org/2000/01/rdf-schema#” xmlns:xsd = “http://www.w3.org/2001/XMLSchema#”. Tabla 3. Ejemplo Namespace Problemas y limitaciones: Los datos escritos en XML sólo se ven beneficiados por la sintaxis pero no por la semántica ya que aún no hay forma de definir el significado de las etiquetas.. 29.

(29) 2.1.3.3.. CAPA DE DATOS. 2.1.3.3.1.. RDF. El RDF (Resource Description Framework) [43] fue el primer lenguaje desarrollado para la Web Semántica. Es un lenguaje creado sobre la base de XML, define un modelo de datos para describir recursos mediante aserciones o sentencias. Una aserción es la más pequeña expresión de información útil organizada en tripletas de sujeto, objeto y predicado. El sujeto es la entidad sobre la cuál habla la aserción, el predicado es el atributo o propiedad del sujeto y el objeto es el valor del atributo. En las tripletas, el sujeto y el predicado son URI’s y el objeto puede ser un URI o un valor literal.. 2.1.3.3.2.. RDF-SCHEMA. RDF Schema [44] proporciona algunas primitivas de las redes semánticas para definir vocabulario de metadatos, de forma similar a los lenguajes orientados a objetos. El RDF Schema ejerce un control semántico sobre las aserciones hechas en RDF, de igual forma que el control ejerce en forma sintáctica el XML Schema con relación a XML. Entre las primitivas de RDF Schema [45] se tiene: •. Class: es un conjunto de individuos que permanecen juntos ya que comparten algunas características.. •. SubClassOf: almacena relaciones taxonómicas entre clases. Es por ello que este tipo de relación entre una superclase y una subclase da por sentado que la subclase tiene todas las características de la superclase.. •. Property: expresa relaciones entre individuos o de un individuo a un valor.. 30.

(30) •. SubProperty: almacena relaciones taxonómicas entre propiedad de forma similar a la SubClassOf.. •. Domain: limita los individuos a los cuales una propiedad puede ser aplicada.. •. Range: limita los posibles valores de una propiedad.. •. Individual: son propiedades y clases instanciadas.. Problemas y limitaciones: La principal deficiencia de RDF es su pobre definición de semántica. En RDFS no hay forma de declarar axiomas, de hecho, sólo es posible describir jerarquías en clases. En conclusión, RDFS no es lo suficientemente expresivo para representar ontologías de la complejidad requerida por la Web Semántica.. 2.1.3.4.. CAPA DE ONTOLOGÍA. 2.1.3.4.1.. DAML [46]. Es un lenguaje de ontologías escrito en RDF, donde se incorporan elementos adicionales a RDFS, que permite expresar clasificaciones y propiedades más sofisticadas. El lenguaje inicial, conocido como DAML-ONT que permite escribir ontologías en la Web, fue lanzado en Octubre de 2002, desarrollado por Jim Hendler, bajo la guía del comité de DAML. Una de las principales mejoras al lenguaje fue la adición de una capa de inferencia lógica para ontología conocida como OIL, que combina las primitivas modeladas de los marcos basados en la semántica formal y los servicios proveídos por la descripción lógica. Esta capa es compatible con RDF Schema (RDFS) e incluye una semántica precisa para la descripción de significados de términos.. 31.

(31) Entre las principales características del lenguaje DAML+OIL tenemos su capacidad para describir la estructura del dominio en términos de clases y propiedades, el amplio poder expresivo reflejado en el tipo de axiomas y de constructores de clases soportado y, finalmente, la facilidad para utilizar gran parte de la infraestructura existente para RDF. Para conocer un poco más del lenguaje, ver Anexo A.. 2.1.3.4.2.. OWL [45]. El lenguaje de ontologías Web (OWL) fue diseñado para ser utilizado por aplicaciones que necesitan procesar automáticamente información contenida en un documento. OWL incorpora las facilidades de XML para construir esquemas de tabulado personalizado y de RDF su flexibilidad para representar datos, además de reunir toda la experiencia adquirida por medio del diseño e implementación de su predecesor, DAML+OIL. Debido a la capacidad de OWL para representar ontologías, este tiene un enorme potencial de utilización en aplicaciones inteligentes que requieran procesamiento automático de información como las búsquedas semánticas, los agentes de software, soporte para decisiones, entendimiento del lenguaje natural, manejo de conocimiento bases de datos inteligentes y comercio electrónico. El lenguaje OWL ofrece tres sublenguajes cuya expresividad aumenta gradualmente para satisfacer las necesidades de comunidades específicas de desarrolladores y usuarios. Estos sublenguajes son el OWL Lite, OWL DL y el OWL Full.. 32.

(32) •. OWL Lite: utilizado por personas que necesitan una clasificación jerárquica y reglas simples. Este sublenguaje posee una buena combinación entre el poder expresivo y la complejidad.. •. OWL DL: utilizado por personas que necesitan la máxima expresividad manteniendo la integridad computacional y decibilidad. Este sublenguaje agrupa todas las construcciones de OWL, pero plantea restricciones sobre la forma en que pueden ser utilizadas.. •. OWL Full: utilizado por personas que necesitan la máxima expresividad y sintaxis libre pero con la seguridad que pueda ser procesado por medios computacionales. Entre las muchas libertades que ofrece este sublenguaje está la posibilidad de tratar una clase simultáneamente como la colección de individuos o como un único individuo.. Problemas y Limitaciones: la transformación OWL DL, es decir SHOIN(D), tiene una complejidad NEXPTIME completa, similar a la transformación de OWL Lite, conocida como SHIF(D), que tiene una complejidad EXPTIME para problemas especiales de inferencia, lo que las hace computacionalmente no tratables. Por otra parte, OWL Full es computacionalmente no decidible [47].. 2.1.3.5.. CAPA DE LOGICA. 2.1.3.5.1.. RULEML [48]. El RuleML pretende ser un lenguaje Web canónico para reglas usando tabulación XML y semántica formal. Este lenguaje apunta a ser fácilmente convertible en otros sistemas de reglas. En él se pueden identificar varias categorías de reglas, entre ellas las reglas de reacción, las restricciones de integridad, las reglas de derivación y los hechos.. 33.

(33) •. Reglas de Reacción: se activan por cierto evento, luego chequean su condición y, en algunos casos, realizan una acción.. •. Restricciones de Integridad: son un caso de las reglas de reacción que denotan una inconsistencia en los datos.. •. Reglas de derivación: son un tipo de regla de reacción que producen nueva información si la premisa de la regla es verdadera.. •. Hechos: reglas con una premisa verdadera.. Actualmente, este lenguaje es muy similar a datalog. Las reglas son componentes similares a átomos, variables y relaciones son empotradas dentro de los elementos XML. Además, ya hay definida una posible sintaxis para el lenguaje [49]. Problemas y limitaciones. RuleML está concebido para ser un mecanismo que permita llevar las reglas a otros lenguajes y hasta ahora sólo ha sido implementado para un subconjunto de Datalog, por lo que se concluye que este lenguaje está aún sintáctica y semánticamente incompleto [50].. 2.1.3.5.2.. NOTACION3. Notación3 (N3) fue propuesto por Tim Berners – Lee como una notación alternativa para grafos y también para soportar reglas simples en la sintaxis. En este lenguaje se manejan como si presentaran cuantificadores existenciales en la cabeza de las reglas N3 por la introducción de constantes de skolem, de lo cual se puede concluir que la expresividad es similar a un datalog restringido a predicados ternarios. Hay algunos sistemas implementados como Euler [51] y CWM [52] que usan N3 como sintaxis para las reglas.. 34.

(34) Problemas y limitaciones: no existe hasta el momento una especificación formal del lenguaje. Por eso, son desconocidas sus propiedades computacionales [50].. 2.2.. CRAWLERS. Día a día, el contenido de Internet crece exponencialmente haciendo casi imposible localizar un documento sin saber el URL específico. Aunque los buscadores son la forma más efectiva de encontrar estos documentos, estos también necesitan una forma de encontrar los documentos. Existen tres tipos básicos de buscadores: los basados en crawlers, los basados en las páginas que las personas remiten y los que son la combinación de los dos anteriores.. Los primeros mandan los crawlers al ciberespacio. Estos visitan las páginas, leen la información allí contenida, leen los meta_tags y siguen todos los links encontrados en la página. Todos estos datos son enviados a un depósito central en donde son indexados para su posterior búsqueda. El crawler retornará periódicamente a los sitios a revisar si la información aún es consistente o hubo cambios. Como casi todas las páginas contienen links a otras, un crawler puede comenzar casi en cualquier página. Los segundos sólo mantienen en su base de datos las páginas que las personas han remitido, con los datos igualmente indexados. Los terceros son simplemente una combinación de los dos anteriores. Los buscadores más grandes usan varios crawlers en paralelo para poder abarcar la mayoría del contenido de Internet, sin embargo, se necesitarían cerca de 6 meses para cubrir toda la red, dando como resultado que las primeras páginas indexadas ya se encuentren desactualizadas al final de la búsqueda.. 35.

(35) Actualmente, los mayores problemas que enfrentan los crawlers son: •. La Web invisible. •. Violaciones de Copyright (plagio). 2.2.1. WEB INVISIBLE. Uno de los mayores problemas que encuentran los crawlers actualmente es el de la Web invisible: las grandes bases de datos de las compañías (itinerarios de vuelo, catálogos de tiendas, avisos clasificados y otros 91.850 [31] terabytes de información que nunca es encontrada a través de búsquedas normales). Dado que los crawlers son programas que lo único que pueden hacer es recoger información y seguir links, las páginas que son generadas dinámicamente o que necesitan un usuario y una contraseña para poder ingresar están negadas para estos programas. Las páginas que son generadas dinámicamente son plantillas que despliegan información específica en respuesta a una consulta. Los usuarios las prefieren sobre las estáticas, dado que les proporcionan acceso rápido a la información que necesitan. Estás páginas son de fácil mantenimiento, pues si los precios suben o el horario de un vuelo cambia, por ejemplo, el Web master sólo tiene que cambiar el dato en la base de datos y estos son actualizados en las página la próxima vez que sean consultadas. Es decir, sólo se cambia el dato en una parte (la base de datos) en vez de cambiarla en cientos de páginas Web.. Los crawlers tienen aún más problemas con éste tipo de páginas: algunos se quedan “atorados” dado que no pueden proporcionar la información necesaria para desplegarlas quedándose en un ciclo infinito, otros simplemente las evitan para no tener que tratar con este tipo de problemas.. 36.

(36) En una página dinámica la información es encontrada a través de consultas. Estas consultas pueden ser escritas en un campo de búsqueda por el visitante o estar de una vez en un link (la búsqueda queda predefinida en esta). Los crawlers no saben utilizar las herramientas ni qué tipo de preguntas pueden hacer, no cumplen los requisitos básicos para hacer la búsqueda (una cookie, un id, o una cadena de búsqueda) y por lo general no indexan la página. Cuando la consulta está en el link se ve de la forma: [26] http://shop.barnesandnoble.com/booksearch/isbnInquiry.asp?userid=2IMXLT5XN1 &mscssid=QEUFGRFF5X2G9H2UCMJQLAKJ8JV83FMD&isbn=0452269350 Los crawlers ven este tipo de links e inmediatamente dejan de buscar en esta página, pues hay una alta probabilidad de quedar atrapado en una trampa (un CGI mal escrito: una página que continúa pidiendo información para poder desplegar información.) Si el crawler continúa buscando en el sitio y queda atrapado no es malo sólo para el crawler sino también para el servidor pues la búsqueda está consumiendo recursos y puede llegar a dejarlo fuera de línea.. 2.2.2. VIOLACIÓN DE COPYRIGHT (PLAGIO) Cuando un crawler visita una página, revisan el todo documento, directamente al código de la página, esto por supuesto les da acceso a absolutamente toda la información allí publicada. Muchas personas utilizan los crawlers para reproducir información con copyright o para encontrar e-mails que luego incluyen en sus listas de spam. Estos problemas se pueden atacar en alguna medida con el archivo robot.txt que se explicará en el siguiente capítulo.. 37.

(37) 2.3.. THE ROBOT EXCLUSION STANDAR. En el capítulo anterior se explicó como los buscadores más grandes (como el de Google2, por ejemplo) utilizan crawlers para buscar páginas e indexarlas en sus bases de datos. Sin embargo, algunas veces los dueños de las páginas Web no quieren que algunas páginas o directorios sean indexados o no quieren que ciertos crawlers indaguen por sus páginas. Se definió The Robot Exclusion Standard (El estándar de exclusión de robots) para tratar de atacar estos y otros problemas. Básicamente existen dos formas de atacar el problema: •. El administrador de un sitio Web puede indicar qué partes del sitio pueden o no ser visitadas por un robot con un archivo especial en su sitio llamado robots.txt. •. El autor de una página Web puede indicar si su página puede o no ser indexada a través de la utilización de un tag especial en el encabezado de ésta (HTML META tag) o utilizando a través un usuario y una contraseña.. Estos métodos se basan en la cooperación de los crawlers para que funcione pues esta técnica no garantiza que funcione siempre o con todos los crawlers. Si se necesita mayor protección lo mejor es exigir una contraseña para ingresar a una página Web (que como ya se discutió en capítulos anteriores, detiene a los crawlers pues estos no pueden escribir). 2. http://www.google.com.co 38.

(38) 2.3.1. ROBOTS.TXT Cuando un crawler visita una página, primero revisa este archivo, es decir, si la página que se va analizar es http://www.ejemplo.com un crawler debe primero revisar el archivo http://www.ejemplo.com/robots.txt. Si encuentra este documento (porque no necesariamente se encuentra siempre) lo que se va a encontrar es un archivo de texto plano en el que sólo va a encontrar entradas del tipo: User-agent: * Disallow: / Para ver si está o no permitido ver el documento o carpeta. El campo Useragent: indica el nombre del crawler y el campo Disallow: indica el archivo o carpeta al que se quiere negar la entrada. En el ejemplo anterior, el asterisco (*) indica todos los crawlers y el slash (/) ningún documento, es decir, se excluyen todos los crawlers de todo el sitio Web Varias cosas se pueden indicar en este archivo: Si se quiere permitir el acceso de cualquier crawler a cualquier documento, en el archivo deben ir las líneas: User-agent: * Disallow:. Si lo que se quiere es proteger ciertas carpetas, lo que se debe poner es: User-agent: * Disallow: /cgi-bin/ Disallow: /tmp/ Disallow: /private/. O si sólo se desea excluir un crawler, se específica el nombre: User-agent: BadBot Disallow: /. 39.

(39) 2.4.. LOGS DE SERVIDORES DE WEB. Muchas de las personas, compañías y organizaciones que existen en la red publican su información por que quieren que sean vistas por el mundo, más aún si se tratan de compañías online. Todos desean que la mayor cantidad de personas posibles visiten sus páginas regularmente, que se sientan a gusto en ellas y que permanezcan en ellas el mayor tiempo posible. Si el tráfico aumenta a sus sitios, es muy posible que las ventas también aumenten. Pero, ¿Cómo hacen los dueños de las páginas para saber este tipo de información? Con los logs de los Servidores. En estos logs se encuentran las respuestas a muchas de las preguntas que un gerente se puede estar haciendo acerca de sus páginas. Todos los servidores de Web tienen la capacidad de registrar en uno o más logs la interacción con los usuarios. Independientemente de la plataforma del servidor, los logs son documentos planos (ASCII) en donde se registran todas las acciones de los usuarios, cada acceso en un renglón distinto de este archivo. Estos logs siguen un formato estándar diseñado por CERN y NCSA (National Center for Supercomputing Applications) [2]. Entre los datos almacenados en el log están: la dirección IP del usuario, fecha y hora del acceso, requerimiento, URL de la página accedida, etc. Existen 4 tipos básicos de logs de servidores de Web: •. Log de Accesos. •. Log de Error. •. Log de Referrer. •. Log de Agente. 40.

(40) Algunas veces, una transacción es registrada en más de un log. A veces se registra tanto en el log de Acceso como en el log de Error Para efectos de este trabajo, sólo el Log de Referrer es relevante. Para información acerca de los demás logs revisar [2].. 2.4.1. LOG DE REFERRER [2]. Este tipo de log sólo contiene dos campos: el URl de origen y el recurso donde fue el visitante desde el URL de origen. Un ejemplo de movimiento, desde una página a otra dentro de un sitio Web se muestra en un log de referred así: http://catalogo.uniandes.edu.co/html/index.html → /scripts/formato.css El visitante llega a la página principal de catálogos y desde allí accede a información específica sobre formatos. La información que se encuentra en los logs es muy valiosa para la compañía, pues de esto pueden depender decisiones y estrategias. Sin embargo, estos archivos pueden ser muy extensos y relativamente densos de analizar para una persona. Para esto, hay herramientas que analizan esta información y la reproducen de una forma que una persona pueda entenderlo. Actualmente existe un gran número de aplicaciones comerciales y no comerciales (gratuitas) para el análisis de estos logs [34]. En términos generales, se puede decir que estas herramientas generan reportes estadísticos y gráficos acerca del uso de los servidores. Como ya se dijo anteriormente, esta información es muy valiosa, pero no siempre es suficiente para un análisis completo y fiable. Algunos de los reportes más comunes son:. 41.

(41) •. Número de eventos ocurridos. •. Bytes transmitidos. •. Páginas más visitadas. •. El referred más popular. •. Browser más usado. 2.5.. PAGERANK. Existe un número increíble de páginas Web en el mundo y cuando un crawler empieza a examinar una página puede terminar recogiendo miles de páginas. Por ejemplo, si en una página se encuentran 10 links a otras páginas y se siguen y se analizan esas 10 páginas nuevamente y en cada una hay otros 10 links, ya se tendrán 110 páginas nuevas que analizar en un corto periodo de tiempo. Al final de proceso se pueden tener miles de páginas, de cualquier persona, casi de cualquier tema. Si todas estás páginas se remiten al motor de búsqueda, se puede terminar con demasiada “basura” dentro de nuestra base de datos. Con basura me refiero al hecho de que casi cualquier persona puede publicar una página Web (sólo tiene que contar con un dominio o un servidor y está listo para publicar sus artículos) acerca del tema que desee, de la longitud que desee, sea o no una persona educada en el tema tratado. Bien puede poner su propia versión de la bibliografía de Gabriel García Márquez y luego remitirlo a un motor de búsqueda para que éste lo indexe. Entonces, ¿Cómo se puede evaluar el contenido de una página Web? Google ha inventado un algoritmo para solucionar este problema. Una forma de entender el algoritmo utilizado por Google es entendiendo un sencillo ejemplo: En el mundo de los libros, una forma de medir la importancia de un autor es por medio de las citas con las que cuenta. No es suficiente haber publicado algo, también se necesita que alguien de hecho lo haya leído y le haya. 42.

(42) sido útil. Si a una persona le gusta y le pareció interesante, lo va a recomendar (puede ser de manera escrita en otro libro. Ej. “Para más información en el tema, consulte...”) Así, un autor se vuelve una autoridad en el tema que maneja si muchas personas lo recomiendan en sus obras. En la Web sucede algo similar. PageRank es un sistema de clasificación de páginas Web desarrollado por los fundadores Larry Page y Sergey Brin en la Universidad de Stanford. PageRank se basa en el mismo principio del ejemplo anterior: si en una página A se encuentra un link a la página B Google lo toma como un voto de la página A por la B. Pero no solamente se cuentan los votos que recibe una página. También se analiza la página que emite el voto, pues como ya se mencionó anteriormente, cualquier persona puede publicar una página y puede poner la cantidad de links que desee. En el ejemplo de los libros, si una persona que ya ha sido reconocida importante en el área recomienda a otra persona hace que la segunda se convierta en importante, el voto cuenta más que el voto de una persona sin rango. Los motores de búsqueda, como Altavista, están interesados en content mining mientras que Google, además de estar interesado en content mining, está interesado en structure mining, es decir, mientras que en una búsqueda de “jaguar” Altavista retornará todas las páginas que hablen de jaguar, Google retornará las páginas que son consideradas una autoridad en el tema. Sin embargo, el hecho de que sean consideradas una autoridad no significa que los resultados sean los esperados. Google puede retornar la página oficial de jaguar el carro y de jaguar el animal. Es por esto que Google combina PageRank con técnicas de búsqueda de texto para que sean tanto importantes y relevantes para la consulta. Con structure mining, no solamente se tiene en cuenta el número de veces que aparece un término en la página, también se tienen en cuenta el contenido de la página y de las páginas vinculadas para determinar si es una buena coincidencia.. 43.

(43) 2.5.1. STRUCTURE MINING. En [3] se definen hubs como páginas que tienen links a varias autoridades y autoridades como páginas que son referidas por varios hubs. Los links que se encuentran en una página pueden revelar muchas cosas acerca de los objetos que estos conectan. En un lenguaje matemático, la Web es un grafo dirigido: cada página es un nodo y cada link es un arco. Es dirigido por que si existe un link de un sitio A un sitio B no necesariamente existe uno de B a A. Una búsqueda de structure mining comienza con una búsqueda de texto normal en donde se recogen un par de cientos de páginas que contengan la palabra. No serán las más importantes en el tema, pero seguro que contienen links a páginas importantes. Estas son examinadas y se trata de crear un grupo de páginas más grande a partir de las iniciales. Este segundo grupo ya tiene más estructura que el primero y a través del algoritmo de Google [3] se pueden determinar hubs y autoridades y brindar a la persona que hizo la consulta los resultados más relevantes.. 44.

(44) 3.. ESTADO DEL ARTE. La Web Semántica se haya en una etapa muy temprana de su desarrollo y las aplicaciones que se han hecho alrededor del tema son pocas. En este capítulo se reseñan los diferentes crawlers existentes para la Web Semántica, realizando un análisis de sus funcionalidades y presentando sus principales características.. 3.1.. CRAWLERS. 3.1.1. RDF Crawler [30]. El RDF crawler es una herramienta que descarga fragmentos interconectados de RDF del Internet y construye una base de conocimientos a partir de estos datos. En cada paso se mantiene tanto una lista de direcciones Web a ser recuperado como las condiciones de filtración (ejemplo: profundidad, sintaxis) que es observado mientras se descargan iterativamente los recursos que contienen RDF. Para permitir ser embebido en otras aplicaciones, el crawler provee una interfaz programable de alto nivel.. 45.

(45) 3.1.1.1.. CARACTERÍSTICAS. Esta herramienta se encuentra desarrollada en java y disponible como una aplicación por consola o para ser embebida dentro de otra aplicación. Existen planes para convertirla en una aplicación de Windows utilizando Java Swing.. Actualmente, ha sido probada únicamente para la plataforma Windows, utilizando la versión de Java 1.3. El RDF Crawler toma la página que un usuario remite y dos parámetros más: profundidad de la búsqueda y tiempo máximo de búsqueda. Es capaz de extraer RDF tanto de archivos puramente escritos en RDF (también soporta DAML y XML) como de archivos en HTML que contienen RDF embebido. Al final del proceso deja los resultados en la carpeta C:\temp y C:\temp\rdf. Estos resultados consisten en: los hechos encontrados (en un archivo RDF), un log con los resultados del proceso (en un archivo XML), un cache de los archivos descargados (en un archivo plano) y todos los archivos que se encontraron durante el proceso y que se pudieron descargar satisfactoriamente. Actualmente hace caso omiso del archivo robot.txt, explicado anteriormente.. 3.1.1.2.. VISTA GENERAL DE LA ARQUITECTURA. Dado que el desarrollo está hecho totalmente en Java, es tanto portable como mantenible y se puede aprovechar la facilidad de utilizar hilos (threads) para un mejor desempeño.. 46.

(46) Para hacer la codificación más sencilla y el resultado reusable, el RDF Crawler utiliza una estructura de productor – consumidor:. +---->+<-- [input from outside] | | | | | | | | | | | | | | | | | |. | URI requests with filtering conditions | Multithreaded download component | Pure RDF data or HTML with embedded RDF | SiRPAC (or similar) - RDF parsing component --> [Storing RDF data] | Stream of triples | Extract nonrepeating URIs | Stream of URIs | URI Filtering; forming new URI requests with new filtering conditions |. +<----+. Tabla 4. Estructura Productor – Consumidor Al comienzo del ciclo, se toma un URI con condiciones de filtrado. Se descarga este URI para ser analizado localmente con un parser (SiRPAC en este caso). Al final del proceso, por cada URI se extrae una lista de links encontrados en la página y extractos de RDF. Los links encontrados son alimentados nuevamente al proceso. Este se repite hasta que se encuentren links y la profundidad permitida y el tiempo no hayan sido alcanzados. Al final del proceso, se tiene un modelo con todos los hechos encontrados.. 47.

(47) 3.1.2. DAML CRAWLER [32]. El DAML Crawler es un programa que recolecta hechos en DAML atravesando la Web usando referencias y links. El programa tiene un conjunto inicial de URI’s guardado en una base de datos. El crawler corre periódicamente, manteniendo una lista de páginas por visitar y guarda el código y el DAML recolectado en archivos. El mapeo de URI/archivo y las estadísticas también son guardados en la base de datos y los resultados son publicados a través de una interfaz en la Web.. 3.1.2.1.. CARACTERÍSTICAS. Actualmente, el contenido es recogido y recolectado por sitio, donde sitio está definido por la tripleta protocolo://host:puerto. Las raíces de los contenidos son utilizadas para identificar sitios. Sólo los sitios identificados a partir de raíces de contenido son procesados. Se crea un hilo de java para cada sitio. Procesar un sitio significa: •. Guardar la dirección Web de la página para uso posterior de buscadores, etc.. •. Hacer una búsqueda sobre la página para recolectar enlaces a otras páginas. Estas son adicionadas a la lista de páginas asociadas. •. Búsqueda sobre la página utilizando el API de RDF para recolectar hechos en DAML.. 48.

(48) Los resultados son reportados por sitio. Consisten de: •. La lista de las raíces de contenido utilizados para identificar el sitio. •. La lista de páginas escritas en DML encontradas en el sitio.. •. La lista de las páginas que no tienen ningún contenido en DAML. •. La lista de los enlaces que no fueron encontrados o no pudieron ser resueltos.. 3.1.2.2.. VISTA GENERAL DE LA ARQUITECTURA. Figura 4. Arquitectura de DAML Crawler [32]. 49.

(49) 4. ARACHNE – CRAWLER PARA LA WEB SEMANTICA. Los crawlers descritos en el capítulo 3 (Estado del arte) son herramientas completamente desarrolladas y que brindan excelentes resultados, pero no son compatibles con MOLOBUS y no cumplen todos los requerimientos deseados, como por ejemplo hacer que los resultados sean persistentes o tratar con problemas de disponibilidad del servidor, entre otros. Con el fin de solucionar algunos de estos problemas y hacer una herramienta que sea un soporte al proyecto MOLOBUS, en este capítulo se diseña un crawler para la Web Semántica que busque documentos, extracte las anotaciones, guarde en una base de datos los resultados y que solucione otros problemas que se describirán más adelante, además debe ser compatible con MOLOBUS. De este capítulo también saldrá como resultado un algoritmo detallado basado en PageRank (descrito en el capítulo 2.5) que se adapte al problema en cuestión.. 4.1.. EL ALGORITMO. El algoritmo propuesto tiene como fin encontrar páginas importantes con las cuales poder alimentar el repositorio y obtener mejores resultados con MOLOBUS. Este algoritmo cuenta de varias partes: a) Crear un conjunto inicial de candidatos. b) Agrandar el grupo de candidatos. c) Identificar páginas importantes. En la primera etapa se toma la página remitida por el usuario y se examina en. 50.