medida de la similitud estructural entre documentos...
TRANSCRIPT
Proyecto de Fin de Carrera Ingeniería de Telecomunicación
Medida de la similitud estructural entre documentos XML
Autora: Julia del Carmen Olivares Nadal Tutora: Isabel Román Martínez
2 Noviembre 2004
A mi abuela
1
Agradecimientos Este proyecto es el culmen de seis años de trabajo, con sus alegrías y sofocones, sus ilusiones y decepciones… Seis años es un largo camino, un camino que he compartido con muchas personas que en algún momento me tendieron una mano amiga, me apoyaron, me escucharon y me infundieron el ánimo y la confianza suficiente como para seguir adelante. Por esa razón este trabajo que aquí presento va dedicado a ellos, a todos los que me han ayudado y querido, aunque ya no estén a mi lado. Quiero no obstante mostrar un especial agradecimiento a: Al Lehrstuhl für Datenbanken de la Facultad de Informática de la Universidad Técnica de Dresden (Alemania) por todas las facilidades ofrecidas para poder realizar este proyecto. Quiero agradecer especialmente al Prof. Dr.-Ing. Wolfgang Lehner que a pesar de no ser estudiante de informática, ni tener conocimientos previos sobre la materia ni soltura con el idioma me aceptó como alumna para realizar el proyecto y me proporcionó un lugar de trabajo en el departamento. Quiero destacar también, con especial cariño, al Dr.-Ing. Bernd Keller, quien fue más que un simple compañero de despacho durante mi estancia en Dresden. Gracias por su paciencia, su cariño, las correcciones, por las charlas a la vuelta del Medak y por enseñarme tanto sobre la DDR. A Isabel Román Martínez por su apoyo en todo momento, su disponibilidad y amabilidad, por su confianza, su ayuda, su respeto y sobre todo por su calidad como persona. Quiero agradecer a todas las personas que hicieron mi vida en Alemania una experiencia fantástica e inolvidable, que me consolaron cuando era necesario y me dieron fuerzas para seguir adelante en un país extraño, que fueron mi familia cuando la mía estaba lejos. A mis vecinos del Wundtstr. 11 por su ayuda y cariño: Steffen, Ingo, Sebastian, Enrico, André, Kerstin, Bianka y Christiane. Gracias por vuestra paciencia, y por enseñarme tanto alemán. Gracias a Kerstin y Enrico por corregirme un capítulo del proyecto. A Christiane y Bianka por su amistad y muy especialmente a Sebastian Goll por hacerme sentir en casa y “für seine mentale unterstützung”. Quiero agradecer también a mis compañeros Erasmus y en especial a María, Irene, Andrés y Nieves todos los buenos ratos que pasamos juntos así como sus palabras de apoyo y consuelo cuando más las necesitaba. Para René y Susanne que me acogieron, me corrigieron texto y me ayudaron siempre que lo necesité no tengo palabras suficientes para agradecerles todo lo que hicieron por mí. A mis compañeros de clase por compartir tantos momentos de risas y llantos. En especial a Laura y Lupe. A mis amigos por darme su apoyo cuando lo he necesitado y aguantar mis malos humores.
A Ale por las estrellas y mucho más. A Eva por llevar una sonrisa a mi vida. Gracias por escucharme, consolarme, quererme y aguantarme cuando me pongo insoportable. Gracias por ser mi amiga.
2
A mi familia por confiar siempre en mis posibilidades. En especial a mi abuelo, al que quiero y admiro profundamente. A mi abuela (in memoriam), por sus rezos y oraciones, por su cariño sin límites. Por tener siempre palabras de ánimo o consuelo, por su confianza plena en mí. A mis hermanas Ana y Alba por ser la alegría de mi vida. Por quererme tanto, por su paciencia y comprensión, por aguantarme. A mis padres, porque a ello se los debo todo. Gracias por la cantidad de sacrificios que han hecho por mi, por quererme y enseñarme tanto, por apoyarme en todo momento y respetar mis decisiones. Gracias por todo.
3
Índice de contenidos 1 Introducción......................................................................................................................5
1.1 Motivación..................................................................................................................5 1.2 La situación actual y su problemática.........................................................................6
1.2.1 Bases de datos ..................................................................................................7 1.2.2 Aplicaciones Web ............................................................................................7 1.2.3 Máquinas de búsqueda .....................................................................................7
1.3 Objetivos ....................................................................................................................8 1.4 Fases del proyecto ......................................................................................................9 1.5 Herramientas utilizadas ............................................................................................10 1.6 Estructura del documento .........................................................................................10
2 Campos de aplicación.....................................................................................................12 2.1 Data Cleansing..........................................................................................................12 2.2 Descubrimiento de conocimiento .............................................................................13 2.3 Integración de información.......................................................................................13 2.4 Comercio electrónico................................................................................................14 2.5 Máquinas de búsqueda .............................................................................................15 2.6 Publicación Web.......................................................................................................15
3 Estado del arte ................................................................................................................17 3.1 Similitud en bases de datos relacionales...................................................................17 3.2 Similitud entre documentos XML............................................................................18
3.2.1 Métodos basados en la estructura arbórea .....................................................18 3.2.2 Métodos basados en eventos ............................................................................21
3.3 Resumen ...................................................................................................................23 4 Tecnologías utilizadas ...................................................................................................24
4.1 Java ...........................................................................................................................24 4.1.1 El API JAXP ..................................................................................................24 4.1.2 SAX ...............................................................................................................25 4.1.3 DOM ..............................................................................................................29 4.1.4 Comparativa entre SAX y DOM .....................................................................33 4.1.5 La clase Math y clase Random ........................................................................34
4.2 Plataforma Eclipse....................................................................................................35 4.2.1 Instalación ......................................................................................................36 4.2.2 Interfaz ...........................................................................................................37 4.2.3 Crear un nuevo proyecto .................................................................................38 4.2.4 Escribir un programa .......................................................................................43 4.2.5 Ejecutar y depurar un programa ......................................................................46
5 Soluciones experimentales .............................................................................................50 5.1 Programa para el cálculo de la similitud ..................................................................50
5.1.1 Handler.java......................................................................................................51 5.1.1.1 Clase Handler .........................................................................................51 5.1.1.2 Clases StackObject y MyStack...............................................................51 5.1.1.3 Clases TypesVector y TypesVectorObject.............................................52 5.1.1.4 Clases LevelVector y LevelObject .........................................................53
5.1.2 XMLStructuralSimilarity.java..........................................................................55 5.1.2.1 Analizar un documento XML.................................................................55 5.1.2.2 Estimación de similitudes.......................................................................55 5.2 Modificación de un documento XML ......................................................................57
4
5.2.1. Funcionamiento del programa ..........................................................................57 5.2.1.1 Modificación del nombre del elemento ..................................................57 5.2.1.2 Duplicación.............................................................................................58 5.2.1.3 Borrado ...................................................................................................58
5.2.2 Clases RandomProperties y RandomStack ......................................................58 5.2.3 Escritura de un documento XML .....................................................................59
5.2.3.1 Normalización ........................................................................................59 5.2.3.2 Espaciado................................................................................................59 5.2.3.3 Configuración de la E/S..........................................................................59
5.2.4 Zusammenfassung ............................................................................................61 6 Experimentos ..................................................................................................................62
6.1 Escenarios.................................................................................................................62 6.2 Experimento 1 ..........................................................................................................63
6.3 Experimento 2 ..........................................................................................................65 6.4 Experimento 3 ..........................................................................................................66
6.4.1 pbbDuplication .................................................................................................66 6.4.2 pbbChange........................................................................................................67 6.4.2 pbbRemoval......................................................................................................68
6.5 Resumen ...................................................................................................................69 7 Síntesis .............................................................................................................................70 Código de los programas........................................................................................................72 Índice de figuras y tablas .......................................................................................................89 Bibliografía y referencias.......................................................................................................90 Anexo: Proyecto original en alemán .....................................................................................91
5
Capítulo 1
Introducción
El lenguaje XML (Extensible Markup Language) es un formato de textos muy flexible y simple derivado de SGML (ISO 8879). XML goza actualmente de una gran popularidad debido al número y variedad de aplicaciones donde juega cada vez un papel más importante, ya sea para describir metacontenidos como para el intercambio y publicación de datos, llegando a ser ampliamente conocido como el estándar de intercambio de datos del futuro, gracias, sobre todo, a la posibilidad de representar datos procedentes de fuentes muy distintas.
1.1 Motivación
El lenguaje XML se encuentra en pleno desarrollo, cada día son más las aplicaciones que incorporan la posibilidad de trabajar con esta tecnología. Los campos donde XML juega un papel importante son muchos y variados, apareciendo en casi todas las situaciones en las que sea necesario un intercambio de información a través de la Web, juega un papel fundamental en el mundo de las bases de datos e incluso es utilizado para representar información de origen muy diferente al textual, como pueden ser archivos de imagen o sonido, usándose esta característica en métodos de comparación de imágenes y sonidos basados en la búsqueda de patrones en los textos que representan a dichas imágenes o sonidos.
Para poder llevar a cabo estas aplicaciones es necesario, en un gran número de
ocasiones, realizar comparaciones entre los documentos XML, como pueda ser el caso de aplicaciones de clustering (agrupamiento) o data-cleansing (“limpieza de datos”), sin embargo, poder cuantificar la similitud entre documentos XML no es tarea fácil debido a que estos documentos no son planos, su estructura es en forma de árbol. De la misma forma se complica la situación cuando hablamos de bases de datos XML en lugar de bases de datos relacionales, donde las tuplas son objetos atómicos, pudiéndose calcular fácilmente la semejanza entre sus contenidos con valores numéricos o de otro tipo. En el mundo XML, sin embargo, la estructura arbórea de los documentos XML hace terriblemente costoso el cálculo de la similitud entre documentos. Incluso documentos procedentes de la misma DTD (Document Type Definition) pueden poseer estructuras de árbol diferentes debido a la posibilidad de elementos opcionales o múltiples. De la misma forma, y cada vez más frecuentemente, existen documentos, en especial aquéllos procedentes de HTML, que no disponen de DTD alguna, de forma que es imposible tener una referencia externa que nos de algún indicio sobre la similitud existente entre los distintos documentos XML.
La búsqueda por similitud es un tema de investigación de bastante incidencia en
la actualidad, pudiéndose definir como sigue: Dado un conjunto de objetos de naturaleza desconocida, una función de
distancia definida entre ellos que mide cuán diferentes son, y otro objeto llamado
6
consulta, encontrar todos los elementos del conjunto suficientemente similares a la consulta.
Varios de los problemas que hemos mencionado, entre otros, se pueden
convertir en problemas de espacios métricos:
1. encontrar imágenes o secuencias de audio o video "cercanas" a una consulta de muestra;
2. búsqueda aproximada en texto; 3. en recuperación de información, donde se define una similitud entre documentos
y se quiere recuperar los más similares a una consulta; 4. en aplicaciones de inteligencia artificial, para etiquetado usando el punto
conocido más cercano; 5. en reconocimiento de patrones y agrupamiento (clustering); 6. en compresión con pérdida (audio, imágenes, video) para encontrar rápidamente
el marco (frame) más parecido visto antes; etc.
En la actualidad se han implementado aplicaciones capaces de obtener la DTD de un documento XML y se están desarrollando técnicas capaces de obtener una medida en la similitud estructural entre documentos XML, basadas en su mayoría en la estimación de la distancia entre árboles, mecanismo muy costoso y que implica la utilización de la interfaz DOM, el cual requiere unos requisitos de memoria que lo hace inviable para trabajar con documentos de gran tamaño, cada vez más abundantes en bases de datos XML. En documentos de pequeño tamaño la similitud puede calcularse fácilmente por métodos directos, son los documentos del tamaño del orden de MBytes los que suponen un gran problema, ya que tanto los métodos directos como los basados en DOM resultan inservibles por su alto coste de recursos.
Esto hace que exista una carencia de métodos sencillos, capaces de obtener una la
semejanza entre documentos de gran tamaño sin necesidad de gastos de memoria excesivos o tiempos de cómputo elevados. De esta manera, resulta necesario diseñar herramientas para trabajar con documentos extensos, pero lo suficientemente flexibles como para ser utilizados por documentos de cualquier longitud.
1.2 La situación actual y su problemática
Actualmente XML goza de una gran popularidad y sus campos de aplicación son ricos y variados. XML se está introduciendo cada vez más en diferentes ámbitos, apareciendo la necesidad de disponer de nuevas herramientas para el manejo y procesamiento de documentos XML.
Cada tipo de aplicación que utiliza XML tiene unas características y necesidades
diferentes. A continuación se presentan los ámbitos más destacados donde se hace uso de XML, comentando su situación actual y problemáticas más importantes.
7
1.2.1 Bases de datos
El uso de XML en el mundo de las bases se ha incrementado notablemente en los últimos años tanto para la representación de información, como para el almacenamiento de la misma, llegando a la aparición de bases de datos nativas de XML.
Todo este desarrollo hace necesaria la existencia de métodos útiles para una
gestión y mantenimiento eficientes de la base de datos en tareas típicas como puedan ser el clustering, detección de duplicados, integración de la información o búsqueda de joinpaths (“caminos del Join”), donde el concepto de similitud resulta fundamental, ya que en el corazón de estos problemas está la búsqueda de un conjunto de patrones dado en estructuras regulares. Actualmente, sin embargo, la mayoría de herramientas implementadas han sido diseñadas para bases de datos relacionales, basadas en el manejo de tuplas, lo que no las hace aplicables para bases de datos XML. Es necesario, por lo tanto, desarrollar nuevas técnicas para manejar y comparar documentos XML. 1.2.2 Aplicaciones Web
Ante el enorme flujo de información electrónica que se origina constantemente, cada vez son más necesarios nuevos mecanismos para detectar las novedades relevantes en dicho flujo, y posteriormente distribuirlas a los usuarios que puedan estar interesados. Esta tarea se conoce en la literatura como Publicación/Suscripción (P/S), y requiere vigilar las coincidencias que surgen entre el conjunto de peticiones de los usuarios (suscripciones), y la secuencia de novedades detectadas en el flujo de información (publicaciones). Actualmente existen numerosas aplicaciones relacionadas con la Web que requieren un sistema P/S, destacando el comercio electrónico y las bibliotecas digitales. En este tipo de aplicaciones es donde el uso de XML se está generalizando a una gran velocidad, gracias a que, al ser un lenguaje de definición de datos de carácter general, ofrece una mayor cohesión en el intercambio de datos B2B (business-to-business) o B2C (business-to-consumer), permitiendo a su vez la creación de nuevos lenguajes gracias a sus mecanismos de extensibilidad.
En aplicaciones de estas características resulta inevitable la necesidad de
comparar documentos XML, ya sea para detectar novedades en el flujo de información, averiguar la similitud existente entre los documentos encontrados con los requisitos de los subscriptores o incluso poder detectar y clasificar los mensajes B2B o B2C pertenecientes a una misma empresa o producto. Es necesario por ello la implementación de nuevas técnicas conscientes de la estructura de los documentos XML y capaces de lidiar con las dificultades que éstas presentan a la hora de comparar ficheros XML.
1.2.3 Máquinas de búsqueda
El uso generalizado de la Web ha convertido a HTML en un estándar de factor para intercambiar documentos. HTML es una simplificación de SGML, un lenguaje de especificación de texto estructurado diseñado originalmente con el objetivo de que fuera un lenguaje universal para intercambiar y manipular texto estructurado. Sin embargo, es XML quien está ganando espacio rápidamente en la comunidad, siendo bastante posible que XML reemplace a HTML en el futuro. Las máquinas de búsquedas actuales han
8
sido desarrolladas para trabajar con HTML, haciéndose necesarias máquinas capaces de trabajar con documentos XML, no sólo para la representación de información, si no desarrolladas específicamente para la búsqueda y devolución de los documentos XML que más se adecuen a una petición de búsqueda.
El problema de una búsqueda eficiente no se soluciona sólo con desarrollar
algoritmos rápidos y precisos para comparar cualquier tipo de información que sea expresada en un documento XML como puedan ser imágenes, audio, texto, etc. Dada una consulta, existirán millones de elementos posibles, por lo que no se van a poder comparar uno a uno. Más aún, las consultas pueden ser más complejas que sólo una medida de similitud, dado que pueden involucrar relaciones complejas entre varios objetos. De esta forma, ha de procurarse simplificar lo más posible este tipo de búsquedas, ya que corresponden sólo un primer paso para búsquedas más complejas.
Una búsqueda por similitud basada en documentos XML, capaces de representar
objetos de muy distinta naturaleza, resulta muy importante para buscar en la Web ya que:
1. permite indexar la Web para permitir búsquedas por imágenes y secuencias de audio similares;
2. permite recuperarse de la mala calidad de los textos que existen en la Web; 3. permite encontrar rápidamente páginas Web relevantes a una consulta; 4. permiten entender el contenido de las imágenes y la semántica de los textos para
obtener búsquedas más sofisticadas; 5. permite obtener mejor compresión de datos multimedia, lo que es esencial para
la transmisión por una red lenta como Internet. La búsqueda en espacios métricos es bastante nueva como área.
Esta clase de métodos se encuentran aún en un estado bastante inmaduro y abierto al desarrollo de nuevos algoritmos y aplicaciones.
1.3 Objetivos
Este proyecto surge como iniciativa del Lehrstuhl für Datenbanken, perteneciente al Institut Systemarchitektur de la Facultad de Informática de la Universidad Técnica de Dresde (Alemania). El objetivo principal con el que fue desarrollado este proyecto se basa en la adaptación a bases de datos XML, del trabajo desarrollado por los laboratorios AT&T denominado “Mining Database Structure; Or, How to Build a Data Quality Browser” [1], donde se presenta un nuevo método para detectar la estructura de una base de datos relacional. El objetivo inicial consistía en adaptar la técnica utilizada para medir la similitud entre tuplas presentada en este trabajo, para obtener una medida de la similitud entre documentos XML y poder ser aplicado a tareas de minería de la estructura de la base de datos y data-cleansing (o limpieza de datos), como puedan ser la detección de información heterogénea, búsqueda de joinpaths (posibles Joins) la detección de duplicados entre otras, ampliándose posteriormente su rango de acción a tareas fuera del ámbito de las bases de datos donde el cálculo de la semejanza de documentos XML juegue un papel importante.
Debido a que la mayor parte del tiempo utilizado durante procesos de minería de
datos se emplea en tareas de identificación y procesado de la información, acentuándose
9
dicho problema con la existencia de bases de datos extensas, el programa a realizar debe ser lo menos costoso posible en cuanto a tiempo de ejecución y a consumo de recursos se trata.
Por otra parte, en el mercado actual las soluciones ofrecidas se basan en la
medida de la distancia entre árboles, como ya se ha comentado con anterioridad, mecanismo muy costoso y alejado de la idea presentada en [1], donde la similitud va a verse representada como una variable aleatoria Binomial, dependiente tanto del número de coincidencias encontradas como del número de muestras tomadas. Esto implica la realización de un nuevo método para medir la semejanza entre documentos XML, muy diferente al empleado hasta ahora, donde se hace necesario incluir un grado de aleatoriedad en los cálculos, procurando adaptar lo más posible la idea original al mundo XML.
1.4 Fases del proyecto A continuación se presenta un pequeño esquema temporal donde queda reflejada
la evolución que ha seguido la realización de este proyecto:
Octubre 2003: Búsqueda del proyecto en la Universidad Técnica de Dresde. Asignación del mismo por parte del Lehrstuhl für Datenbanken, del Instituto de arquitectura de sistemas de la Facultad de informática. Octubre 2003-Diciembre 2003: Familiarización con la tecnología XML. Lectura del libro “XML&Datenbanken. Konzepte, Sprachen und Systeme” y estudio de tutoriales diversos por Internet. Enero 2004: Lectura del artículo “Mining Database Structure; Or, How To Build a Data Quality Browser”. Estudio a fondo de dicho artículo y explicación del mismo al resto del personal del departamento en dos sesiones, incluyendo explicación de la división polinómica. Febrero 2004-Marzo 2004: Recordatorio de programación en Java. Familiarización con la plataforma eclipse y realización de ejemplos en la misma. Profundización en la interfaz DOM y realización del programa para DOM con pruebas. El programa con DOM funcionaba sin problema para ficheros de pequeño tamaño, pero por decisión del tutor de proyecto alemán, tuve que trabajar con documentos de un tamaño bastante elevado. Al realizar las pruebas con este tipo de documentos el programa lanzaba un error grave por falta de memoria. Tras realizar tareas de depuración, el error fue localizado en la función parse, encargada de procesar el documento XML y crear la estructura de árbol del documento en memoria. Dicho error no implicaba un fallo en el diseño del programa que había realizado, sino una incompatibilidad de la tecnología escogida, DOM. Marzo 2004-Mayo 2004: Cambio de DOM a SAX. Profundización en SAX. Estudio del estado del arte. Diseño del programa XMLStructuralSimilarity. Mayo 2004: Búsqueda de información sobre trabajos realizados para modificar un documento XML. Realización del programa XMLModifier. Realización de
10
experimentos preliminares para estudiar el comportamiento del programa XMLStructuralSimilarity. Se comienza a escribir y corregir el documento en alemán. Junio 2004: Modificación del programa XMLStructuralSimilarity para introducir el concepto de similitud por nivel. Cambio del antiguo parámetro numNodes por el actual pbbChosenNodes, para indicar el tanto por ciento de elementos a comparar y no el número de comparaciones, haciéndolo de esta manera independiente del tamaño de los documentos. Se modifica la selección de elementos para que sólo puedan ser tomados una vez en la comparación y mejorar así los valores de la similitud obtenida. Se continúa escribiendo y corrigiendo el documento. Julio 2004: Se realizan los experimentos finales y se termina de escribir y corregir el proyecto. Es presentado el 28 de Julio. Septiembre 2004: Se entrega una copia del proyecto en alemán al departamento de telemática y se comienza la traducción del documento para obtener su convalidación.
1.5 Herramientas utilizadas
La realización del proyecto no sólo incluye trabajo y estudio. Para poder culminar la realización del mismo han sido necesarios medios materiales y herramientas software, sin las cuales no hubiera sido posible su realización. A continuación se van a presentar las herramientas más destacadas que se han empleado:
� PC Pentium 4 a 2.8GHz, 256MB de memoria RAM y 40GB de disco duro. � Plataforma eclipse. � Java jdk 1.4.2 � Parsers de Java SAX y DOM. � Ejemplos del proyecto XMLApache.
1.6 Estructura del documento
La información recogida en este documento va a ser estructurada en diferentes capítulos, siendo el primero y presente una introducción sobre la situación actual y motivos que impulsaron a la realización del proyecto, así como los objetivos que se pretenden cubrir, entre otras cosas.
En el segundo capítulo van a presentarse algunos de los campos en los que XML
tiene una aplicación directa, y donde, por lo tanto, un programa para medir la similitud entre documentos XML, como el desarrollado en este proyecto, puede tener un papel importante.
En el capítulo tercero va a explicarse de una manera resumida cómo se ha
resuelto el problema de la estimación de la similitud entre documentos XML usando otro tipo de técnicas o bien técnicas similares aplicadas a campos de acción diferentes a XML, en otras palabras, el estado del arte.
11
En el cuarto capítulo se va a realizar un realizar un desarrollo sobre las tecnologías utilizadas, razonando por qué han sido escogidas, explicando sus características más importantes.
En el quinto capítulo van a ser presentados los programas que han sido
implementados para la realización de este proyecto, explicando su funcionamiento y dando a conocer las clases y métodos más destacables de los mismos.
En el sexto capítulo se verán recogidos los resultados de los experimentos
realizados, donde se han hecho medidas para calibrar los efectos producidos por los distintos valores de los parámetros de ambos programas, demostrándose la eficiencia del programa XMLStructuralSimilarity y llegándose a conclusiones interesantes sobre cómo los diferentes cambios que pueden producirse en un documento XML afectan al valor de la similitud.
Por último, van a desarrollarse las conclusiones sacadas de la realización de este
trabajo, y se enunciarán posibles líneas de continuación para el mismo.
12
Capítulo 2 Campos de aplicación El Lenguaje de Marcaje Extensible (Extensible Markup Language, XML) es un lenguaje de metamarcaje (meta-markup) que proporciona un formato para describir datos estructurados. Esto facilita declaraciones más precisas de contenido y resultados de búsquedas con más significado entre muchas plataformas. Además, el XML habilitará una nueva generación de aplicaciones manipulación y visualización de datos basadas en Web.
Al proporcionar un estándar de datos capaz de codificar el contenido, la semántica y el esquema (schemata), van a hacer a XML un lenguaje con capacidad de acción en multitud de aplicaciones diferentes, desde las más simples a las más complejas, destacando, entre otras, las que se presentan a continuación.
2.1 Data Cleansing
Los datos relacionales representan sólo una pequeña parte de los datos actuales, esta es una de las razones por las que XML goza cada vez más de una mayor popularidad como estándar para la representación de datos, en especial para datos en la World Wide Web y para el intercambio de datos entre organizaciones. XML juega también un papel muy importante en el mundo de las bases de datos. Muchos sistemas de bases de datos comerciales (Oracle, IBM DB2…) proporcionan herramientas para representar la información con XML y almacenar datos XML, además, son ya muchas las bases de datos que han sido diseñadas para almacenar documentos XML, son las bases de datos nativas de XML.
Debido al nuevo desarrollo de las tecnologías XML se necesitan métodos basados
en la estructura XML, capaces de realizar una labor de data-cleansing o limpieza de datos eficiente en bases de datos XML. Data-cleansing contiene diferentes aspectos como la detección de duplicados o la búsqueda de joinpaths, donde el conocimiento sobre la similitud entre documentos XML resulta muy importante.
El problema de las entidades duplicadas que describen al mismo objeto es una
tarea de gran importancia en las labores de data-cleansing para mejorar la calidad de los datos. Unos de los problemas con los que se encuentran las bases de datos XML son la estructura a priori indefinida de los elementos dentro de un documento. En una base de datos relacional, las tuplas en una relación simple poseen la misma estructura definida, por el contrario, los elementos XML que describen al mismo tipo pueden poseer estructuras muy diferentes. Este problema puede encontrarse en distintos campos del data-cleansing, sin embargo, los algoritmos actuales han sido desarrollados en su mayoría para trabajar con datos relacionales, existiendo una gran cantidad de métodos que no están maduros todavía para trabajar con tecnologías XML, a pesar del gran desarrollo que han sufrido en los últimos años.
13
2.2 Descubrimiento de conocimiento El descubrimiento de conocimiento o Knowledge Discovery es un método de análisis basado en software que filtra y extrae la posible información útil de un conjunto de datos estructurados. La meta del Knowledge Discovery es descubrir relaciones ocultas, multidimensionales y no lineales en grandes conjuntos de datos. Una parte importante de los procesos KDD (knowledge Discovery in Databases) es lo conocido como Data Mining, donde se destaca, por su vital importancia, los procesos de clustering. El clustering se basa en clasificar los datos en diferentes categorías de forma (semi-)automática, de forma que el parecido entre objetos clasificados en el mismo cluster sea mayor que el parecido con otro objeto fuera del cluster, de esta forma, cada cluster agrupará objetos con características similares diferentes a los objetos pertenecientes a otro cluster. En el mundo XML, para poder clasificar la información en diferentes clusters, es necesario poder establecer un grado de similitud entre los distintos documentos XML, necesitándose para ello métodos capaces de medir el parecido existente entre los documentos. Los documentos XML que se encuentran en la Web aparecen normalmente sin DTD, en especial aquéllos procedentes de HTML. El conocimiento de la DTD de un documento es, sin embargo, muy importante a la hora de manipular o consultar dichos documentos. Existen actualmente trabajos que implementan algoritmos capaces de (re-) construir la DTD o Schema que describa la estructura de un conjunto de documentos XML. Para un conjunto de documentos XML con una DTD desconocida no resulta eficaz crear una DTD para cada documento, sin embargo, no carece de sentido crear una única DTD capaz de satisfacer a un grupo de documentos XML. Si se agrupan los distintos documentos XML en pequeños grupos donde los documentos posean entre sí un alto grado de similitud estructural, y por lo tanto, exista una alta probabilidad de que puedan proceder del mismo esquema generador, se podrá, con los métodos comentados anteriormente, crear una DTD para cada uno de estos grupos de documentos XML. Con la DTD se podrá ahora acceder a una pequeña parte de los datos, como pueda ser un tipo en concreto, con una mayor eficiencia, agilizando de manera notable la búsqueda. Para poder llevar esto a cabo es necesario poseer métodos capaces de calibrar la similitud a nivel estructural que poseen todos los documentos entre sí, lo que hace imprescindible que dichos métodos no supongan un consumo de recursos excesivos.
2.3 Integración de información La integración de información es la combinación de los contenidos de fuentes diferentes y heterogéneas almacenados de forma única y estructurada proporcionando una interpretación efectiva al usuario. La tecnología de integración de información hace posible el acceso integrado en tiempo real tanto a las fuentes de datos convencionales como a nuevas, preparando los datos para los analistas, así como los organiza bajo el criterio de eficacia, actualidad o disponibilidad. Con XML comenzó a describirse el concepto de integración de información en la Web. Gracias a este estándar pueden definirse propiedades con las que es posible estructurar y representar en forma de documentos datos de muy distinta naturaleza.
14
XML es capaz de diferenciar entre el contenido, estructura y layout del documento. La combinación de la información va a complicarse al aumentar el número de fuentes, así como la procedencia de las mismas, la integración de información no va a llevarse a cabo sólo con las fuentes habituales como puedan ser las bases de datos relacionales, debe también ser capaz de acceder a documentos XML, textos de datos simples, imágenes, videoclips, mensajes en vivo, correos electrónicos, contenidos Web y sistemas de almacenamiento especiales (tanto externos como internos), entre otros. Debido a las restricciones estructurales, como regla general, no se suelen replicar o consolidar en una única base de datos fuentes heterogéneas o distribuidas, sin embargo, gracias a la combinación y correlación de datos es posible encontrar informaciones escondidas. Cuando aumenta la heterogeneidad de las fuentes XML se presenta la necesidad inminente de organizar los documentos XML en relación con ciertas propiedades encontradas en su estructura. Como ya se comentó, este problema tiene aplicaciones muy interesantes para la gestión de datos Web. El descubrimiento de similitudes a nivel estructural entre documentos puede ayudar a diferenciar fuentes que generan informaciones del mismo tipo. De esta manera, los procesos de consulta en datos semiestructurados van a verse beneficiados al tener organizados los documentos según su estructura. Agrupar documentos según su homogeneidad estructural puede también ayudar a desarrollar nuevas técnicas de indexación para los documentos, capaces de optimizar la planificación de las consultas.
2.4 Comercio electrónico
El comercio electrónico (E-Business) se ha convertido actualmente en una palabra clave sobre la que todos los medios de comunicación quieren hablar, desde la prensa especializada en economía hasta publicaciones online, tratando sobretodo temas sobre eCommerce y Shopping-Systeme, que juegan un papel muy importante en las aplicacines de comercio electrónico.
Internet proporciona la posibilidad de comunicar a las empresas con otras
empresas colaboradoras o clientes, conceptos conocidos como B2B (Business to Business) o B2C (Businness to Consumer). La información transmitida no consta sólo de texto, puede incluir información de otra naturaleza como puedan ser imágenes y sonidos, es la economía digital. El concepto comercio electrónico se inició con las tiendas online que ofrecen una gran cantidad de artículos. Esta información es actualizada y presentada en Internet por medio de las páginas Web, sin embargo, esta oferta no puede realizarse utilizando simplemente páginas HTML, se acercan tiempos en los que las páginas Web sólo serán una ventana en color para mostrar el producto o realizar una presentación de la empresa. Cada vez cobra una mayor importancia toda la información que se envía a la Web, haciéndose necesario en muchos casos un estándar que gestione y agilice toda esta cantidad de transacciones que acometen las empresas, para lo que HTML no está preparado, siendo aquí donde XML entra en juego.
Por medio de XML puede estructurarse datos relativos al producto, descripción del mismo, precio o disponibilidad, siendo utilizado en la mayoría de los escenarios B2B principalmente como formato para el intercambio de datos. Pero la posibilidad que se tiene en XML para definir una DTD o Schema permite además crear lenguajes propios para las distintas aplicaciones de negocios. El secreto de XML no es que pueda
15
crear nuevas formas de comercio, aunque sea capaz de hacerlo, su valor añadido es que puede perfeccionar las existentes, aumentando la velocidad y fluidez de la gestión de la información, razón por la cual ha tenido una gran acogida entre las distintas organizaciones. Es incuestionable que XML juega en la actualidad un papel muy importante en el comercio electrónico, donde el intercambio de información en aplicaciones típicas, como B2B, se realiza mayoritariamente por medio de documentos XML. En este escenario se precisan métodos eficientes para procesar este tipo de documentos. El conocimiento de la similitud estructural entre documentos puede ayudar a identificar cuál es el producto que está siendo descrito o incluso a qué empresa pertenece, es por ello que es necesario implementar métodos capaces de calcular de una forma rápida la similitud entre documentos XML, agilizando así la gestión y clasificación de la información.
2.5 Máquinas de búsqueda Una máquina de búsqueda es un programa diseñado para encontrar documentos en un ordenador o red como por ejemplo la World Wide Web. Dada una determinada petición de consulta, la máquina de búsqueda devolverá una lista de posibles documentos o páginas Web que cumplen las restricciones impuestas en la consulta. Las respuestas a la consulta suelen representarse ordenadas de mayor a menor relevancia, aunque cada máquina de búsqueda puede definir sus propios criterios. Actualmente, cada vez son más los documentos XML que se pueden encontrar en la Web, sin embargo, los navegadores actuales han sido diseñados para HTML y no procesan correctamente la información en XML. Las máquinas de búsqueda deben adaptarse al desarrollo que ha sufrido XML en estos últimos años e incorporar mecanismos capaces de trabajar con documentos XML, o incluso deben desarrollarse máquinas de búsqueda directamente para XML. En las máquinas de búsqueda deben encontrarse documentos que tengan resultados similares a unos determinados parámetros de consulta, de esta forma, se hace necesaria la existencia de métodos capaces de estimar la similitud existente entre documentos XML.
2.6 Publicación Web Internet comenzó como un pequeño experimento y se ha convertido, gracias a HTML, en una de las mayores colecciones de información del mundo. El número de personas privadas y entidades que acceden a Internet y realizan transacciones a través de ella aumenta considerablemente, especialmente con la llegada del comercio electrónico. No estamos hablando sólo de las informaciones que se representan en las páginas Web, sino de la cantidad de información que intercambian las sucursales de las distintas empresas, transacciones financieras o el intercambio entre los datos médicos entre hospitales, médicos y seguros médicos. La mayoría de estas aplicaciones son, sin embargo, irrealizables con HTML, siendo posibles realizarlas gracias a la tecnología XML. El uso de la tecnología XML en las publicaciones Web supone un gran paso para el mayor aprovechamiento del potencial de Internet. La aceptación de XML es bastante grande, en especial en el campo del comercio electrónico y en la publicación Web (Web publishing).
16
Ante el enorme flujo de información electrónica que se origina constantemente, cada vez son más necesarios nuevos mecanismos para detectar las novedades relevantes en dicho flujo, y posteriormente distribuirlas a los usuarios que puedan estar interesados. Esta tarea se conoce en la literatura como Publicación/Suscripción (P/S), y requiere vigilar las coincidencias que surgen entre el conjunto de peticiones de los usuarios (suscripciones), y la secuencia de novedades detectadas en el flujo de información (publicaciones). Por medio de esta aplicación se pretende ahorrarle al usuario malgastar tiempo en la búsqueda de la información que le interesa entre todo el flujo de información. Estas informaciones están basadas en su mayoría en XML, por lo que es importante a la hora de identificar y encontrar un tipo de información determinada, métodos capaces de poder medir las semejanzas entre documentos XML.
17
Capítulo 3 Estado del arte El concepto de la similitud puede definirse en campos muy diferentes siendo muchas y variadas las aplicaciones que hacen uso de la misma. Puede ser utilizado por ejemplo para definir la semejanza entre dos informaciones genéticas o para comparar la semejanza estructural que existe en distintas el páginas Web, pudiéndose aplicar en campos tan distantes como el arte, química, informática o control de calidad. Este trabajo se va a centrar en estudiar la similitud que existe en la información almacenada en forma de un documento XML, estudiando cómo es posible estimar el grado de semejanza entre dos documentos XML, atendiendo a la estructura de los mismos. A continuación se van a presentar distintas soluciones implementadas para resolver el problema de la estimación de la similitud entre documentos XML. La mayoría de los métodos presentados utilizan técnicas distintas para medir la similitud entre documentos XML. Además, se va a explicar un trabajo realizado para bases de datos relacionales cuyo concepto de similitud es el que se ha tomado como base para la realización de este proyecto.
3.1 Similitud en bases de datos relacionales En las bases de datos relacionales de gran tamaño parece inevitable que se produzcan desórdenes a causa de la inserción incorrecta de datos o del uso inadecuado. Estas bases de datos desordenadas implican un coste importante debido a que tareas tan importantes como la minería, el análisis o planificación de los datos se ven frustradas por culpa de datos incorrectos o inexistentes. Es necesario, por lo tanto, conocer la estructura de la base de datos para poder lidiar de manera más eficiente con estos problemas.
En las bases de datos relacionales el cálculo de la similitud entre tuplas es una tarea de vital importancia para poder conocer la estructura de la base de datos. Para poder llegar a comprender dicha estructura es necesario entender cómo se relacionan unos campos con otros, para así determinar si dos campos pueden asociarse con una operación Join, buscar duplicados o identificar información heterogénea dentro de la base de datos.
La definición teórica de la similitud entre conjuntos ha sido explicada en [1], donde los laboratorios AT&T presentan Bellman, un navegador de calidad de datos. Este artículo representa la base sobre la cual se ha trabajado en este proyecto, adaptando al mundo XML el concepto de similitud presentado en este artículo para bases de datos relacionales. Según [1], la similitud existente entre dos conjuntos A y B puede definirse como: ρ=|A∩B| / |A∪B|. Sin embargo, y como novedad, en [1] podemos encontrar una nueva definición de la similitud entre los conjuntos A y B en función del concepto de signature o”signatura” de un conjunto. Sea U el universo de valores posibles para los elementos de A y B y sea h:U�N una aplicación que mapea uniforme y “aleatoriamente” elementos de U al conjunto N={0,1,2...}, entonces puede definirse el
18
concepto de signature como s(A)=mina∈A(h(a)). De esta forma Pbb [s(A)=s(B)]=�, lo que da lugar a la variable Indicador I[s(A)=s(B)] que es una variable de Bernoulli de parámetro �. Lo que se realiza es, por lo tanto, un experimento de forma que se transforman por medio de la aplicación h los valores de A y B, obteniéndose valores pertenecientes a los números naturales, comparándose si el menor de los valores de A y de B eran iguales, ya que se han transformado en el mismo elemento. Para poder entender el sentido del experimento se debe entender que la función h transforma un espacio complejo como pueda ser U en N, mucho más sencillo, de forma que tomando al azar un elemento, que se ha definido como el menor, éste pertenezca a la intersección. Como en todo experimento, una única muestra puede dar lugar a un resultado poco exacto. Para obtener una mejor estimación en el valor de la similitud va a repetirse el experimento un número de veces N : �
=
∧==
N
iii NBsAsI
1
/)]()([ρ donde (A)=mina∈A(hi(a)).
Esta variable se corresponde con una variable Binomial, ya que consta de una suma de variables de Bernouilli. Este nuevo conjunto de experimentos consiste en mapear con distintas funciones h los elementos de A y B y comprobar para cada una de ellas si las “signaturas” coinciden. En caso afirmativo la variable indicador tomará el valor de 1 y en caso contrario un valor nulo, permitiendo así calcular la similitud. Un cálculo muy interesante que se presenta en [1] es el calcular qué elementos de A no se encuentran en B y viceversa. Esto va a representarse por medio de las similitudes �A/B y �B/A que pueden calcularse con las expresiones |||/|/ BABABA �=ρ y
|||/|/ BAABAB �=ρ . Estas expresiones resultan de mucha utilidad cuando quiere conocer si uno de los conjuntos está contenido en una mayor o menor medida en el otro. Al igual que pasaba con �, pueden obtenerse una mejor estimación usando las
expresiones siguientes: �=
∧<=
N
iiiBA NBsAsI
1\ /)()([ρ y �
=
∧>=
N
iiiAB NBsAsI
1
\ /)()([ρ .
3.2 Similitud entre documentos XML Debido al desarrollo de la tecnología XML aparecen nuevas aplicaciones que utilizan XML. La estimación de la similitud entre documentos XML es una tarea bastante interesante y actual para todas estas nuevas aplicaciones. Por ello existen un gran número de artículos y trabajos que se han planteado resolver el problema de encontrar la similitud entre documentos XML y de los cuales se van a presentar los más interesantes. Los métodos para estimar la semejanza entre documentos XML pueden dividirse en dos grandes grupos según el tipo de parser al que estén orientados. El primer grupo va a basarse en DOM, serán métodos orientados a trabajar con la estructura de árbol del documento. El segundo grupo contará con los métodos orientados a eventos, lo que implica hacer uso de SAX. 3.2.1 Métodos basados en la estructura arbórea Los métodos que estiman la similitud existente entre dos documentos XML basándose en la estructura arbórea almacenada de los documentos se basan en el concepto de Tree-edit-distance (distancia de edición entre árboles) definida en “Tree-to-
19
tree correction problem” [2]. Este concepto se trata de una generalización de la distancia entre cadenas de caracteres. El problema principal que presentan estos métodos es que el cálculo de la distancia entre árboles es un mecanismo muy costoso en tiempo de ejecución. Para intentar solucionarlo, los distintos trabajos van a presentar métodos diversos para intentar reducir el tiempo de ejecución. Un documento XML puede modelarse como un árbol ordenado y etiquetado. Cada nodo del árbol es un elemento del documento donde la etiqueta tiene el nombre del elemento. La distancia de edición entre árboles es el número de operaciones de edición (edit operations) que son necesarias para transformar una estructura de árbol en otra. Aunque la mayoría de los métodos que utilizan las estructuras arbóreas se basan en el concepto de tree-edit-distance, el conjunto de operaciones de edición definidas en unos trabajos y otros pueden diferir. Las operaciones de edición definidas en [3,4] son: insertar un nodo, borrar un nodo y renombrar un nodo. En [5], sin embargo, se define además como operación de edición permitida el desplazamiento de subárboles. En el trabajo presentado en [3], “Approximate XML Joins”, se pretende descubrir el grado de similitud entre documentos XML para optimizar la operación de Join. Para intentar reducir el tiempo de ejecución que supone calcular la distancia de edición entre árboles va a introducir los conceptos de umbral superior e inferior. Estos umbrales son mucho más eficientes de calcular. Usando estos umbrales como base, se pretende desarrollar técnicas eficientes de filtrado que en ciertas ocasiones evitan tener que calcular la tree-edit-distance entre un par de documentos XML. Para el cálculo del umbral inferior se tiene lo siguiente: Sea T una árbol ordenado y etiquetado, post(T) el orden posterior transversal y pre(T) el orden anterior transversal. Para dos árboles T1,T2 puede definirse los siguientes lemas:
� Si pre(T1) � pre(T2) o post(T1) � post(T2), entonces T1 � T2. � Si los árboles se encuentran a una distancia de edición k, entonces la máxima distancia de edición entre su orden anterior transversal y orden posterior transversal es k. Basados en los lemas anteriores se pueden enunciar los teoremas siguientes: � Sean T1, T2 árboles ordenados y etiquetados y ed(a,b) la distancia de edición entre a y b, entonces max(ed(pre(T1),pre(T2)),ed(post(T1),post(T2)))�TDIST(T1, T2), donde TDIST representa la distancia entre T1 y T2. Calculando el umbral superior de la distancia de edición se restringe los grados de libertad del algoritmo para calcular la verdadera distancia de edición. En concreto, se van a introducir restricciones adicionales permitiendo reducir el espacio agilizando el algoritmo. � Sea tn[im] un nodo del árbol Tn y sea lca() la función del menor ancestro común (lowest common ancestor function), se pueden enunciar las reglas siguientes: � t1[lca(t1[i1],t1[i2])] es un verdadero ancestro de t1[i3] si y sólo si t2[lca(t2[j1],t2[j2])] es un verdadero ancestro de t2[j3]. � Existe un algoritmo O(n²) para calcular la el umbral superior de la distancia de edición, UBDIST, entre un par de árboles con O(n) nodos cada uno.
20
� Para un par de árboles T1, T2, TDIST(T1,T2)�UBDIST(T1,T2). Con estas operaciones se puede calcular la distancia entre el orden anterior transversal y el orden posterior transversal, que como se ha dicho va a ser menor o igual a la distancia entre árboles, no haciéndose necesario en muchos casos el cálculo de la misma. Sea � la distancia umbral para realizar una operación Join, cuando el umbral inferior es mayor que �, pueden descartarse ese par de documentos y no es necesario calcular la tree-edit-distance entre ambos. Si el umbral superior es menor o igual que �, el par puede incluirse en la respuesta final y no es necesario calcular la distancia con el método costoso. Sin embargo, si el valor de � se encuentra comprendido entre los valores del umbral inferior y el umbral superior, LBDIST(T1,T2)��< UBDIST(T1,T2), no se puede ni descartar el par ni incluirlo en el grupo final, siendo necesario realizar el algoritmo para calcular la distancia de edición entre árboles para esa pareja de documentos. Una solución menos complicada es la presentada en “Evaluating Structural Similarity in XML Documents” [4], a pesar de utilizar también el concepto de tree-edit-distance. Aquí no sólo se va a considerar como operaciones de edición la inserción, eliminación y renombrado de nodos, si no que se van a considerar también la inserción y eliminación de árboles. Se introduce el concepto de operaciones permitidas (allowables) que han de satisfacer las siguientes condiciones: � Un árbol P puede ser insertado sólo si P existe en el árbol origen A. Un árbol P puede ser borrado sólo si P existe en el árbol destino B. � A un árbol que ha sido insertado con la operación de inserción de árboles no se le pueden insertar nodos adicionales. De la misma forma, para que un árbol pueda ser borrado con la operación de borrado de árboles no se han podido eliminar nodos (hijos) con anterioridad. En [4] se va a calcular la distancia entre árboles en dos pasos. En el primer paso, para cada nodo v � B se calcula el coste de insertar el nodo v y cada uno de sus hijos. A esta suma se le da el nombre de d0. Se comprueba también si el árbol P, que es el subárbol con raíz en v, se encuentra en el árbol fuente A. Si está se calcula el coste de insertar P, llamando a esta suma d1. El coste mínimo va a ser el mínimo de d0 y d1. Otra posibilidad es hacerlo con las operaciones de borrado en lugar de inserción. En el segundo paso se va a calcular la distancia de edición entre árboles pero no con todos los nodos, si no sólo con los nodos resultado del primer apartado. En “Detecting Changes in XML Documents” [5] se pretenden encontrar los cambios existentes entre las distintas versiones de un documento. Se pretende obtener un algoritmo dic para XML. Lo interesante en este trabajo es la utilización de una nueva operación de edición: el movimiento de subárboles. Se van a buscar el mayor fragmento común que existe entre ambos documentos. Se va a registrar en una tabla de manera unívoca con una clave (valor hash) cada subárbol del documento D1. Luego, comenzando con el mayor subárbol de D2, se va a buscar uno idéntico en D1 analizando los registrados en la tabla. En “Tree-based Approach to Clustering XML Documents by Structure” [6] se presenta un método para agrupar documentos XML en clusters o grupos. En este trabajo se va a definir el concepto de la similitud entre documentos XML en función de los
21
coeficientes de Jaccard. Sea tag(t) el conjunto de los nombres de etiquetas de un árbol, entonces puede definirse la distancia de Jaccard entre los árboles t1 y t2 como:
La distancia puede definirse en función de los caminos en lugar de en función del nombre de las etiquetas:
{ }|)(||,)(|max|)()(|
1),(21
21
21
tpathtpathtpathtpath
ttdJ
∩−=
Sea path(ti) el conjunto de caminos en ti, entonces path(t1)�path(t2) representa el conjunto de caminos comunes entre t1 y t2. El método que presentan en [6] consiste en crear una inmensa matriz donde para cada par de elementos (vi � t1,wj � t2) se va a almacenar en la matriz [1�elemento(i,j)] si ambos elementos pueden emparejarse o [0�elemento(i,j)] si no. v y w pueden emparejarse fuertemente tanto v, w como sus ancestros tienen las mismas etiquetas. v y w pueden tener un emparejamiento múltiple cuando un nodo en un árbol puede emparejarse con más de un nodo en el otro árbol. Este último caso puede ser reconocido con facilidad observando la matriz de emparejamientos, ya que se encontrará en la fila correspondiente a dicho nodo más de un elemento con valor 1.
3.2.2 Métodos basados en eventos La estrategia presentada en “Detecting Structural Similarities between XML Documents” [7] es muy distinta a los trabajos descritos anteriormente. En este artículo se realiza una propuesta bastante novedosa que consiste en representar la estructura de un documento XML como una serie temporal. A cada evento producido a causa de una etiqueta del documento se le va a asociar un impulso. Analizando las frecuencias de la transformada de Fourier de las series se va a obtener el grado de similitud estructural entre documentos XML. Para el propósito descrito en [7] los documentos XML puede ser considerado como un árbol de elementos. El área del documento que contiene información asociada con un elemento va a venir delimitada por un par de etiquetas. Los elementos pueden contener otros elementos así como datos no estructurados (texto). Los atributos van a ser considerados como elementos adicionales (subelementos vacíos). Para poder comprender el desarrollo de la teoría presentada en este trabajo es necesario explicar los siguientes conceptos: � Sea d un documento XML, se define tags(d) como el conjunto de todas las etiquetas de d y tnames(d) como el conjunto de todos los nombres de etiquetas distintos de d. � Sea d un documento XML, se puede definir el esqueleto de d como la secuencia de etiquetas que aparecen en d, es decir, sk(d) es la secuencia [t0,t1,...,tn] tal que ti ∈ tags(d) ⇔ ti ∈ sk(d) y ti precede a tj en d si y sólo si i<j.
|)()(||)()(|
1),(21
21
21
ttagttagttagttag
ttdJ
∪∩−=
22
� Sea d un documento XML Dokument y t una etiqueta en él, se defiene nestd(t) como el conjuntos de las etiquetas de inicio els en d que ocurren antes de la etiqueta t y de las cuales no ha aparecido la etiqueta final ele que cierre a els. Se define también lt como el nivel de anidación (nesting level) de la etiqueta, lt=|nestd(t)|. � Sea D un conjunto de documentos, maxdepth(D) denota el mayor nivel de profundidad o anidamiento que hay en las etiquetas de d ∈ D. La idea principal de esta solución consiste en representar el esqueleto del documento como una serie temporal. Más concretamente se puede asumir que se va a visitar la estructura del documento XML en el orden que sigue un parser SAX. Cuando se visita un nodo del árbol se emite un impulso que contiene la información relevante de esa etiqueta. La señal resultante debe representar el documento original como una serie en el tiempo. Como consecuencia, la comparación de dos documentos va a hacerse comparando dichas secuencias. Para ello va a ser necesario realizar una serie de codificaciones para poder transformar la estructura del documento en una serie temporal para posteriormente definir cómo se va a realizar la estimación de la semejanza entre ambas señales. Se van a distinguir dos codificaciones diferentes, una codificación de etiquetas y otra del documento. Para la codificación de etiquetas, dado un conjunto de documentos D se construye una secuencia de diferentes etiquetas considerando un orden lineal (escogido aleatoriamente) de tnames(D). Dado un elemento el, la codificación directa de etiquetas asocia cada etiqueta els con la posición que tiene el nombre de la etiqueta en la secuencia. Para las etiquetas finales se consideran dos posibles versiones: simétrica o nula. Una función de codificación de etiquetas � es simétrica si y sólo si para cada documento d y para cada elemento el ∈ d se tiene �(ele)=- �(els). � es nula si �(ele)=0. La codificación del documento es esencialmente una función que asocia un documento XML con una serie temporal que represente la estructura del documento. Sea D el conjunto de todos los posibles documentos XML, una codificación del documento es una función que asocia cada d ∈ D con una secuencia de enteros positivos: enc(d)=h0,h1,...,hn. Tras analizar el documento con el parser se obtienen las señales hd(t). La comparación de estas señales puede resultar tan compleja como la comparación de los documentos originales, ya que comparar documentos con distintas longitudes supondría tener que combinar un cambio de tamaño y un alineamiento. Estirar o contraer la señal no soluciona tampoco el problema. Para medir la similitud entre las señales (y por consiguiente la de los documentos) resulta muy conveniente examinar la transformada de Fourier de las señales, ya que ésta nos proporciona información relevante sobre la distribución y el comportamiento de la señal en frecuencia. Se va a trabajar con la transformada discreta de Fourier o DFT ya que por el teorema de Parseval la energía de las señales no varía al realizar esta transformación. Se puede, por lo tanto, calcular la distancia entre dos documentos calculando la integral (sobre el rango de frecuencias dado) de la magnitud de la diferencia entre ambas señales. En la interpretación discreta de transformada de Fourier cada punto de la transformada se asocia con una frecuencia dada. Si dos documentos no tienen la misma longitud la DFT asociada a ambos documentos va a mostrar valores que corresponden a distintas frecuencia. Para aproximar la integral comentada con anterioridad es necesario interpolar los
23
correspondientes valores. En concreto se va a interpolar linealmente la transformada DFT para obtener una nueva transformada DFT’ con M=|tags(d1)|+|tags(d2)|-1 puntos.
De esta forma, se define la distancia DFT (Discrete Fourier Transform distance) de los documentos como la aproximación de la diferencia de magnitud de las dos señales, calculándose como sigue:
[ ] [ ]( )2/122/
1
2121 )()(')()('),(���
�
�
���
�
�−= �
=
M
K
khDFTkhDFTdddist
3.3 Resumen Un documento XML puede ser analizado con SAX o DOM. Con DOM se almacena en memoria la estructura arbórea del documento, mientras que con SAX se ejecuta un análisis del documento orientado a eventos. Para medir la similitud entre documentos XML existen diferentes métodos que utilizan la estructura de árbol almacenada o que se basan en técnicas orientadas a eventos. En el apartado 3.2.1 se han descrito técnicas que se basan en tener almacenada la estructura en árbol del documento para calcular el grado de similitud existente entre los mismos. La mayoría de este tipo de métodos utiliza para medir la similitud el concepto de la distancia de edición entre árboles, consistente en medir la distancia entre dos árboles en función del número de operaciones de edición necesarias para transformar un árbol en el otro. La diferencia principal existente entre los distintos métodos descritos radica en lo que se considera una operación de edición. El problema principal que presentan estos métodos es el coste de recursos como memoria y tiempo de ejecución. En el apartado 3.2.2 se ha presentado un método que utiliza los eventos que se producen al encontrar una nueva etiqueta durante el análisis del documento para medir la similitud. Este método no precisa almacenar la estructura en árbol del documento en memoria. Representa la estructura del mismo como una serie en el tiempo que, haciendo uso de la transformada de Fourier, va a comparar con otra señal para medir la similitud en estructura entre los documentos. Existen métodos para medir la similitud en bases de datos relacionales. Esto es lo que se ha explicado en el apartado 3.1 donde se ha presentado el trabajo que se ha tomado como base para la realización de este proyecto, adaptándolo a XML.
24
Capítulo 4 Tecnologías utilizadas Para poder llevar a cabo este proyecto ha sido necesaria la utilización de diferentes tecnologías. En este trabajo se ha decidido programar en Java por las facilidades que este lenguaje ofrece para trabajar con XML, esto ha implicado conocer con detalle sus numerosas API´s en clases e interfaces para el manejo de documentos XML, así como otras auxiliares que se han necesitado para la realización del programa. Por otra parte, para realizar los programas se ha hecho uso de la plataforma eclipse. Esta plataforma tiene la ventaja de ofrecer un interfaz de usuario de fácil manejo con editor de programa en colores entre otra muchas aplicaciones, haciendo más ameno y fácil el trabajo al programador.
4.1 Java
Java ofrece distintas APIs para trabajar fácilmente con documentos XML y permite escribir aplicaciones Web directamente en Java. Estas interfaces de Java pueden ser orientadas a documentos o a objetos.
� Orientadas a documento:
JAXP (Java API for XML Processing): Procesa documentos XML utilizando distintos analizadores o parsers. JAXB (Java Architecture for XML Binding): Mapea elementos XML a clases del lenguaje Java.
� Orientadas a procedimiento: JAXM (Java API for XML Messaging): Envía mensajes SOAP sobre Internet de forma estándar. JAXR (Java API for Registries): proporciona una forma estándar para acceder a registros de negocios que comparte información. JAX-RPC (Java API for XML-based Remote Process Communications): Define un mecanismo para el intercambio entre aplicaciones de mensajes basados en XML. El objetivo de este trabajo es recolectar información sobre un documento XML
para ser posteriormente utilizada en el cálculo de la similitud entre documentos XML. Esta es la razón por la que se ha utilizado la interfaz JAXP, ya que nos ofrece la oportunidad de procesar documentos XML.
4.1.1 El API JAXP JAXP es un programa de biblioteca de SUN para el procesamiento de documentos XML. Originalmente el parser provenía del proyecto Apache-XML (Crimson), siendo posteriormente ampliado por Sun. La versión actual es JAXP 1.1.
25
Generalmente es válido para procesar cualquier documento XML. Se comprobará si éste es un documento XML válido (por ejemplo comprobará si para cada etiqueta de inicio existe su correspondiente etiqueta final, entre otras cosas). Con JAXP se pueden procesar documentos con SAX 2.0 y DOM nivel 2 y ser transformados con XSLT a otro tipo de documentos como HTML.
SAX ofrece un servicio orientado a eventos, mientras que DOM construye la estructura en forma de árbol del documento, permitiendo su modificación, cosa imposible con SAX, que ha sido diseñado para procesamientos rápidos, sin almacenar la estructura del documento en memoria. De esta manera SAX ahorra tiempo y memoria siendo ideal para documentos de gran tamaño, perdiendo sin embargo la posibilidad de navegar por la estructura a placer. 4.1.2 SAX
SAX (Simple API for XML) es un interfaz dirigido a eventos donde los datos XML se leen como un flujo de datos en que el que el analizador invoca uno o más métodos suministrados por el llamador cuando ocurre un "evento de análisis". Los eventos incluyen tanto el reconocimiento de etiquetas XML como el encontrar errores, encontrar una referencia a una entidad externa o procesar una especificación DTD. Su funcionamiento puede describirse como sigue:
� Un analizador recorre secuencialmente el documento XML y genera llamadas
según detecta la ocurrencia de determinados eventos. � Las llamadas permiten procesar el documento teniendo en cuenta los eventos
que las han generado y los datos asociados a dichos eventos.
Las llamadas de retorno permiten insertar acciones en el flujo del programa y convertir el análisis de un documento XML en una aplicación que reacciona ante datos, elementos y atributos.
La principal desventaja asociada con SAX consiste en la imposibilidad de
acceder a un elemento en concreto de la estructura del documento sin un almacenamiento previo, ya que al analizar el mismo se lee el documento completo, sin almacenar su estructura.
El API SAX define diferentes interfaces y clases. En SAX 2.0 pueden
encontrarse las siguientes:
�javax.xml.parsers.SAXParserFactory: Define una interfaz factoría que permite configurar un conjunto de analizadores SAX. Con el método newInstance se obtiene un objeto SAXParserFactory con el que puede llamarse a otros métodos de la clase. La configuración de un parser perteneciente a esta factoría de parsers puede realizarse por medio de diferentes métodos como setNamespaceAware o setValidating. Con el método newSAXParser se obtiene un objeto SAXParser que permitirá crear el analizador SAX. �org.xml.sax.XMLReader: Analiza el documento y define métodos como setContentHandler para configurar manejadores de eventos y parse para analizar el documento.
26
�org.xml.sax.ContentHandler: Maneja los eventos lanzados durante la ejecución del documento. Implementa los métodos startDocument y endDocument a los que se invoca al recibir el evento de inicio y fin del documento respectivamente. Contiene a su vez los métodos startElement y endElement que son llamados cuando el parser reconoce, respectivamente, una etiqueta de inicio y una final. El analizador, al reconocer la etiqueta inicial, llamará al método startElement, pasándole como parámetros el nombre de dicha etiqueta y una lista con los atributos de dicho elemento. La implementación de este método está vacía, dejando al programador la libertad de manejar dicho evento de la manera más conveniente para sus propósitos. Análogamente, al reconocer el analizador una etiqueta final va a llamarse al método endElement. Por el contrario, si lo que reconoce el parser es un trozo de texto entre dos etiquetas, el evento que lanza el manejador es muy diferente, llamándose al método characters, y si lo que reconoce es una instrucción se llamará al método processingInstruction. Además de los métodos comentados anteriormente existen los métodos setDocumentLocator, con el que puede crearse un localizador (objeto Locator) de eventos dentro del documento, que puede, entre otras cosas, indicar la línea en la que se ha producido un evento determinado, y el método ignorableWhitespace, que recibe una notificación cuando el parser encuentra algún espacio en blanco ignorable. �org.xml.sax.ErrorHandler: Este manejador es encargado de controlar los errores surgidos durante el análisis del documento. Para ello consta de los métodos warning, error y fatalError, que son invocados cuando se produce un aviso, error (recuperable) o error grave (no recuperable), respectivamente, durante la lectura del documento.. La información relativa a estos errores va a encapsularse dentro de una excepción del tipo SAXParseException que se pasa como parámetro. Cuando un error se origina en uno de los métodos manejadores de eventos de la aplicación nos encontramos que estos métodos lanzan una excepción del tipo SAXException y no SAXParseException. Para solucionar esto y debido a la propiedad de que una SAXEXception puede encapsular a otra excepción, todos estos métodos lanzan una excepción SAXException donde irá recogida la información del error o aviso. �org.xml.sax.DTDHandler: Este manejador se utiliza cuando la aplicación SAX necesita conocer información sobre notaciones o entidades no analizadas. En ese caso, se llamará al método unparsedEntityDecl o notationDecl. �org.xml.sax.EntityResolver: El solucionador de entidades será necesario si el analizador detecta una referencia a datos externos, como puedan ser una DTD o un parámetro externos. El parser deberá llamar al único método disponible, resolveEntity, antes de abrir cualquier referencia externa. Este método toma un identificador pública (URN=Universal Resource Name) para obtener un identificador del sistema (URL=Universal Resource Locator). �org.xml.sax.DefaultHandler: Contiene la implementación de las cuatro últimas interfaces.
En la siguiente figura se ilustra cómo se estructura conceptualmente un
analizador SAX. Como puede verse se parte de una factoría de analizadores SAX de la que puede obtenerse un parser SAX. Este analizador puede contener diferentes manejadores para gestionar los diferentes eventos que se vayan produciendo durante el análisis del documento.
27
Fig. 1. Analizador SAX
Para poder entender mejor el funcionamiento de un analizador SAX se presenta a continuación un pequeño programa a modo de ejemplo. En él, dado un fichero XML, va a crearse y configurarse un analizador tipo SAX que lea dicho documento. Las funciones de DefaultHandler han sido implementadas de forma que se cuenten el número de elementos, atributos y espacios en blanco del documento. Este programa contiene dos ficheros distintos, uno con la función main, donde va a crearse el analizador y donde va a darse la orden para analizar el documento, y un segundo fichero donde se han definido las funciones pertenecientes a la clase DefaultHandler: import org.xml.sax.XMLReader; import javax.xml.parsers.SAXParser; import javax.xml.parsers.SAXParserFactory; public class min { public static void main(String argv[]) { try { SAXParserFactory factory = SAXParserFactory.newInstance(); factory.setNamespaceAware(true); factory.setValidating(true); SAXParser saxParser = factory.newSAXParser(); XMLReader xmlReader = saxParser.getXMLReader(); xmlReader.parse(argv[0]);
28
} catch (Exception e) { e.printStackTrace(System.err); } } }
import java.io.OutputStreamWriter; import java.io.PrintWriter; import java.io.UnsupportedEncodingException; import javax.xml.parsers.SAXParser; import javax.xml.parsers.SAXParserFactory; import org.xml.sax.Attributes; import org.xml.sax.SAXException; import org.xml.sax.SAXParseException; import org.xml.sax.XMLReader; import org.xml.sax.helpers.DefaultHandler; public class SAX2Count extends DefaultHandler { private long elements; /** Elementos */ private long attributes; /** Atributos */ private long characters; /** Caracteres */ private long ignorableWhitespace; /** espacios en blanco */ /** Prints the output from the SAX callbacks. */ public static void print(String uri) { try { System.out.println("Analizando: " + uri + "\n"); SAX2Count counter = new SAX2Count(); SAXParserFactory factory = SAXParserFactory.newInstance(); factory.setNamespaceAware(true); factory.setValidating(true); SAXParser saxParser = factory.newSAXParser(); XMLReader parser = saxParser.getXMLReader(); parser.setContentHandler(counter); parser.setErrorHandler(counter); parser.setFeature( "http://xml.org/sax/features/validation", false); parser.setFeature( "http://xml.org/sax/features/namespaces", true); long before = System.currentTimeMillis(); parser.parse(uri); long after = System.currentTimeMillis(); counter.printResults(uri, after - before); } catch (org.xml.sax.SAXParseException spe) { spe.printStackTrace(System.err); } catch (org.xml.sax.SAXException se) { if (se.getException() != null) se.getException().printStackTrace(System.err); else se.printStackTrace(System.err); } catch (Exception e) { e.printStackTrace(System.err); } } /** DocumentHandler methods */ public void startDocument() { elements = 0; attributes = 0; characters = 0; ignorableWhitespace = 0; } public void startElement(String uri, String local, String raw, Attributes attrs) {
29
elements++; if (attrs != null) attributes += attrs.getLength(); } public void characters(char ch[], int start, int length) { characters += length; } public void ignorableWhitespace(char ch[], int start, int length) { ignorableWhitespace += length; } /** ErrorHandler methods */ public void warning(SAXParseException ex) { System.err.println("[Aviso] "+getLoc(ex)+": "+ ex.getMessage()); } public void error(SAXParseException ex) { System.err.println("[Error] "+getLoc(ex)+": "+ex.getMessage()); } public void fatalError(SAXParseException ex) throws SAXException { System.err.println("[Error!] "+getLoc(ex)+": "+ex.getMessage()); } private String getLoc(SAXParseException ex) { StringBuffer str = new StringBuffer(); String systemId = ex.getSystemId(); if (systemId != null) { int index = systemId.lastIndexOf('/'); if (index != -1) systemId = systemId.substring(index + 1); str.append(systemId); } // str += ":" + ex.getLineNumber() + ":" + ex.getColumnNumber(); str.append(':'); str.append(ex.getLineNumber()); str.append(':'); str.append(ex.getColumnNumber()); return str.toString(); } /** Public methods */ public void printResults(String uri, long time) { // filename.xml: 631 ms (4 elems, 0 attrs, 78 spaces, 0 chars) System.out.println (uri+":"+time+"time ms (" +elements+" elems, "+attributes+" attrs, " +ignorableWhitespace+" spaces, "+characters+" chars)"); } public static void main(String argv[]) { print(argv[0]); } }
4.1.3 DOM
DOM (Document Object Model) es una interfaz para el procesamiento de documentos XML basada en la estructura de árbol. Cuando usamos DOM, el procesamiento de la entrada XML se hace al menos en dos ciclos: primero, el analizar DOM crea una estructura de datos tipo árbol que modela el documento fuente XML (árbol DOM), luego pasamos a través del árbol DOM, buscando información relevante para extraerla y procesarla posteriormente; este último ciclo se puede repetir tantas veces como sea necesario mientras el árbol DOM exista en memoria. La principal ventaja de tener la estructura almacenada en memoria es la posibilidad de tener un acceso aleatorio a cualquier parte del documento, por el contrario, el consumo de
30
memoria que requiere este método es elevado y puede hacerlo inviable para el procesamiento de documentos de gran tamaño.
En Java existe un paquete llamado org.w3c.dom que proporciona interfaces
para el Document Object Model (DOM) definido por el consorcio W3C para el procesamiento de documentos XML. Dicho paquete contiene un conjunto de interfaces y clases definidas en Java que permiten implementar un analizador DOM, así como funciones para navegar a través de la estructura de árbol y obtener información sobre los distintos elementos y atributos. Las principales interfaces de DOM son: �org.w3c.dom.Node: Es la interfaz básica de DOM. Representa a los nodos que constituyen la estructura en árbol del documento y define un conjunto de métodos para navegar por la citada estructura. Entre estos métodos cabe destacar los siguientes: getParentNode, que devuelve el nodo padre del nodo que ha invocado el método, getChildrenNodes, que devuelve una lista de nodos o NodeList con todos los nodos hijos, getNextSibling, que devuelve el siguiente nodo hermano, o getFirstChild, que devuelve el primer nodo hijo. Además existen métodos que permiten modificar la estructura del documento añadiendo o eliminando nodos con los métodos appendChild y removeChild, respectivamente, así como reemplazar un nodo por otro, haciendo uso del método replaceChild. �org.w3c.dom.Element: Representa a los elementos del documento, por lo que suele ser la interfaz más utilizada de DOM. Los métodos principales son: TagName, que devuelve el nombre del elemento, getAttribute, que devuelve el valor del atributo cuyo nombre se pasa como parámetro, getElementsByTagName, devuelve una lista de nodos o NodeList con todos los elementos descendientes cuyo nombre coincida con el indicado como parámetro y según el orden en el que se hayan encontrado en el árbol. �org.w3c.dom.Attr: Esta interfaz representa a un atributo de un elemento. Las funciones básicas que pueden realizarse sobre un atributo vienen reflejadas por los siguientes métodos: getName, que devuelve el nombre del atributo que invoca el método y getValue, que devuelve el valor de dicho atributo. �org.w3c.dom.Text: Representa a un nodo de texto. Estos nodos representan el contenido textual de un elemento o atributo, conocido en XML como CDATA. Los métodos principales de esta interfaz son: getData, que devuelve el texto y getLength, que devuelve la longitud del texto. �org.w3c.dom.Document: Esta interfaz representa al documento XML completo. Conceptualmente, es la raíz de la estructura de árbol del documento proporcionando el acceso primario a los datos del documento. Debido a que los elementos, nodos de texto, instrucciones, etc. No pueden existir fuera del contexto de un objeto tipo documento, Document, la interfaz contiene los métodos necesarios para crear estos objetos como createElement, que crea un elemento del tipo indicado en el parámetro, o createTextNode, que crea un nodo de texto con la cadena de caracteres pasada como parámetro. Para poder procesar un documento XML haciendo uso de un analizador DOM es necesario poder crear el analizador con anterioridad. Para ello es necesario importar también el paquete javax.xml.parsers donde se definen las clases
31
DocumentBuilderFactory, que permite crear y configurar un conjunto de analizadores capaces de obtener un árbol DOM de un documento XML, y la clase DocumentBuilder, que devuelve un objeto que implementa el interfaz Document W3C. La siguiente figura (Fig. 2) ilustra cómo trabaja conceptualmente un analizador DOM. Éste se crea haciendo uso de la clase DocumentBuilderFactory para crear una factoría de parsers con unas características especiales. Posteriormente el documento puede ser procesado haciendo uso de la instancia obtenida de la clase DocumentBuilder por medio del método parse, obteniéndose en memoria la estructura DOM del documento, por la que se puede navegar y modificar con los métodos explicados anteriormente.
Fig. 2. Analizador DOM
Para comprender mejor el funcionamiento de DOM se va a presentar a continuación un pequeño programa a modo de ejemplo. Con la intención de que sirva para poder comparar esta tecnología con SAX, en este programa también va a analizar un documento XML contando el número de elementos, atributos y espacios en blanco presentes en él. import java.io.OutputStreamWriter; import java.io.PrintWriter; import java.io.UnsupportedEncodingException; import javax.xml.parsers.DocumentBuilder; import javax.xml.parsers.DocumentBuilderFactory; import org.w3c.dom.Attr; import org.w3c.dom.Document; import org.w3c.dom.NamedNodeMap;
32
import org.w3c.dom.Node; import org.w3c.dom.NodeList; public class DOMCount { private long elements; /** Elements. */ private long attributes; /** Attributes. */ private long characters; /** Characters. */ private long ignorableWhitespace; /** Ignorable whitespace. */ /** Counts the resulting document tree. */ public static void count(String uri) { try { DOMCount counter = new DOMCount(); DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); factory.setNamespaceAware(true); factory.setValidating(true); DocumentBuilder parser = factory.newDocumentBuilder(); long before = System.currentTimeMillis(); Document document = parser.parse(uri); counter.traverse(document); long after = System.currentTimeMillis(); counter.printResults(uri, after - before); } catch (org.xml.sax.SAXParseException spe) { spe.printStackTrace(System.err); } catch (org.xml.sax.SAXNotRecognizedException ex ){ ex.printStackTrace(System.err); } catch (org.xml.sax.SAXNotSupportedException ex ){ ex.printStackTrace(System.err); } catch (org.xml.sax.SAXException se) { if (se.getException() != null) se.getException().printStackTrace(System.err); else se.printStackTrace(System.err); } catch (Exception e) { e.printStackTrace(System.err); } } /** Traverses the specified node, recursively. */ public void traverse(Node node) { if (node == null) return; // is there anything to do? switch (node.getNodeType()) { case Node.DOCUMENT_NODE: // print document elements = 0; attributes = 0; characters = 0; ignorableWhitespace = 0; traverse(((Document)node).getDocumentElement()); break; case Node.ELEMENT_NODE: {// print element with attributes elements++; NamedNodeMap attrs = node.getAttributes(); if (attrs != null) attributes += attrs.getLength(); NodeList children = node.getChildNodes(); if (children != null) { int len = children.getLength(); for (int i = 0; i < len; i++) traverse(children.item(i)); } } break; case Node.ENTITY_REFERENCE_NODE: {
33
NodeList children = node.getChildNodes(); if (children != null) { int len = children.getLength(); for (int i = 0; i < len; i++) traverse(children.item(i)); } } break; case Node.CDATA_SECTION_NODE: // print text characters += node.getNodeValue().length(); break; case Node.TEXT_NODE: characters += node.getNodeValue().length(); break; } } public void printResults(String uri, long time) { // filename.xml: 631 ms (4 elems, 0 attrs, 78 spaces, 0 chars) System.out.println (uri+":"+time+"time ms (" +elements+" elems, "+attributes+" attrs, " +ignorableWhitespace+" spaces, "+characters+" chars)"); } public static void main(String argv[]) { count(argv[0] ); //count uri } }
4.1.4 Comparativa entre SAX y DOM Como se ha podido ver en los apartados anteriores Java implementa las API’s del W3C para procesar un documento XML. Haciendo uso de estas clases de Java se pueden obtener dos analizadores o parsers a escoger para procesar un documento XML según las características de la aplicación. Con SAX obtenemos un análisis del documento basado en eventos, leyendo el documento como un flujo continuo de datos y sin posibilidad de tener un acceso aleatorio a una parte concreta del documento. SAX es ideal para aplicaciones rápidas y que precisen de un bajo consumo de recursos, o bien cuando se trabaja con documentos de gran tamaño. Con DOM el documento se procesa almacenando la estructura en árbol del mismo en memoria. Esto permite tener acceso a cualquier elemento del documento sin tener que procesar el documento otra vez. La siguiente tabla resume y compara las características principales de SAX y DOM:
SAX DOM Modelo basado en eventos Estructura de datos tipo árbol
Acceso serie (flujo de eventos) Acceso aleatorio (estructura de datos en memoria
Bajo uso de memoria (sólo se generan eventos)
Alto uso de memoria (todo el documento se carga en memoria
Para procesar partes del documento (capturar eventos importantes)
Para editar el documento (procesar la estructura de datos en memoria)
Para procesar el documento sólo una vez (flujo de eventos temporal).
Para procesar el documento múltiples veces (documento cargado en memoria).
Tabla I: Comparativa entre SAX y DOM
34
Para la realización de este proyecto se ha optado por utilizar la tecnología SAX en lugar de DOM. A pesar de las facilidades que ofrece este último para tener un acceso aleatorio a los elementos del árbol y para modificar el mismo, la necesidad de tener una aplicación que permitiera trabajar con documentos con un gran volumen de datos lo descarta para ser utilizado, optándose por SAX, complicándose notablemente el trabajo para poder realizar un estudio estadístico, así como para poder modificar el documento de forma aleatoria. 4.1.5 La clase Math y clase Random Para calcular el valor de la similitud existente entre dos documentos XML se va a realizar una serie de experimentos, como se explicará en el siguiente capítulo, donde es necesario obtener un cierto grado de aleatoriedad además de necesitarse el uso de otras funciones de carácter matemático. Afortunadamente, Java proporciona una librería con diferentes funciones matemáticas: java.lang.Math. Esta clase contiene métodos para la realización de operaciones numéricas básicas, así como exponenciales elementales, logaritmos, raíces cuadradas y funciones trigonométricas. Como complemento a la clase Math se puede hacer uso de la clase Random, java.lang.Random, que implementa un generador de números pseudo aleatorios de cualquier tipo numérico. Una instancia de esta clase se utiliza para crear un flujo de números pseudo aleatorios usando una semilla de 48 bits. Una propiedad de esta clase es que si dos instancias de Random son creadas con la misma semilla y ambas realizan una misma secuencia de llamadas a métodos, ambas generarán la misma secuencia de números. Para la realización de los programas XMLStructuralSimilarity y XMLModifier, sólo han sido necesarias la utilización de los siguientes métodos de la clase Math: min, max y random y el método nextInt de la clase Random. A continuación se muestran las características más importantes de los métodos mencionados: �java.lang.Math.min: Devuelve el menor de los dos valores pasados como parámetros. Este método está disponible para los tipos de datos entero, entero largo, punto flotante y doble precisión. Si ambos números son iguales devuelve el mismo valor y en el caso de los valores en punto flotante tanto de precisión simple como doble, si uno de ellos es NaN (Not a Number) la función devuelve NaN. �java.lang.Math.max: Devuelve el mayor de los dos valores pasados como parámetros. Este método está disponible para los tipos de datos entero, entero largo, punto flotante y doble precisión. Si ambos números son iguales devuelve el mismo valor y en el caso de los valores en punto flotante tanto de precisión simple como doble, si uno de ellos es NaN (Not a Number) la función devuelve NaN. �java.lang.Math.random: Devuelve un valor doble con signo positivo mayor o igual que 0.0 y menor que 1.0. Los valores devueltos son escogidos de forma pseudo aleatoria siguiendo (aproximadamente) una distribución uniforme en el rango indicado. Cuando se llama a este método por primera vez se crea un generador simple de números pseudo aleatorios al igual que si se creara un objeto Random (new java.util.Random). Este nuevo generador aleatorio será usado para las llamadas posteriores de este método, pero en ningún sitio más.
35
�java.lang.Random.nextInt: Devuelve un valor entero, entre 0 (incluido) y el valor entero pasado como parámetro (excluido), de forma pseudo aleatoria y uniformemente distribuida. Cada valor entero del rango especificado se produce (aproximadamente) con igual probabilidad. El método nextInt(int n) es implementado por la clase Random de la forma siguiente: public int nextInt(int n) { if (n<=0) throw new IllegalArgumentException("n must be positive"); if ((n & -n) == n) // i.e., n is a power of 2 return (int)((n * (long)next(31)) >> 31); int bits, val; do { bits = next(31); val = bits % n; } while(bits - val + (n-1) < 0); return val; }
Este método no obtiene enteros aleatoriamente dentro del rango, si no de forma pseudo aleatoria. Este algoritmo no es perfecto, elimina valores dependiendo del valor del parámetro n. El peor caso es para n=2^30+1, para el que la probabilidad de rechazo es del 50%. Este método no puede implementarse haciendo uso de Math.
4.2 Plataforma eclipse
Eclipse es un IDE (Integrated Development Environment) open source y extensible. El proyecto se lanzó originalmente en Noviembre de 2001, cuando IBM donó 40 millones de dolares del código fuente de Websphere Studio Workbench y formó el Eclipse Consortium para controlar el desarrollo continuado de la herramienta.
El objetivo de Eclipse era "desarrollar una plataforma industrial robusta, con todas las características y de calidad industrial para el desarrollo de herramientas altamente integradas". Al final, el Eclipse Consortium se había enfocado en tres proyectos principales:
1. The Eclipse Project es responsable de desarrollar el workbench (banco de trabajo) del IDE Eclipse (la "plataforma" que contiene las herramientas Eclipse), el JDT (Java Development Tools), y el PDE (Plug-In Development Environment) utilizado para ampliar la plataforma.
2. The Eclipse Tools Project se enfoca en la creación de herramientas para la plataforma Eclipse. Entre los subproyectos actuales se incluyen un IDE Cobol, un IDE C/C++, y una herramienta de modelado EMF.
3. The Eclipse Technology Project se enfoca en investigaciones tecnológicas, incubación y educación utilizando la plataforma Eclipse.
La plataforma Eclipse, cuando se combina con el JDT, ofrece muchas de las características que cabría esperar de un IDE de calidad comercial: editor con sintaxis coloreada, compilación incremental, un depurador que tiene en cuenta los threads a
36
nivel fuente, un nevegador de clases, un controlador de ficheros/proyectos, e interfaces para control estándar de código fuente, como CVS y ClearCase.
Eclipse también incluye varias características únicas, como la refactorización de código, la actualización/instalación automática de código (mediante Update Manager), una lista de tareas, soporte para unidades de test con JUnit, e integración con la herramienta de construcción de Jakarta: Ant.
A pesar del gran número de características estándar, Eclipse se diferencia de los IDEs tradicionales en varias cosas fundamentales. Quizás lo más interesante de Eclipse es que es completamente neutral a la plataforma y al lenguaje. Además de la mezcla ecléctica de lenguajes soportados por el Eclipse Consortium (Java, C/C++, Cobol), también hay otros proyectos para añadir a Eclipse el soporte de lenguajes tan diversos como Python, Eiffel, PHP, Ruby, y C#.
Con respecto a las plataformas, el Eclipse Consortium proporciona instalaciones binarias para Windows, Linux, Solaris, HP-UX, AIX, QNX, y Mac OS X. La mayoría de cosas interesantes que posee Eclipse se centran en la arquitectura de plug-ins y el API proporcionado por el Plug-in Development Environment para ampliarlo. Añadir soporte para un nuevo tipo de editor, una vista, o un lenguaje de programación, es remarcadamente fácil, con el API y los bloques de construcción que proporciona Eclipse.
Con cientos de proyectos de desarrollo de plug-ins en progreso, los gigantes de la industria como IBM, HP, y Rational, proporcionan recursos, y diseños de peso pesado como Erich Gamma helping para guiarnos en el proceso. 4.2.1 Instalación
Lo primero que se necesita hacer es asegurarse de que se tiene disponible un Java runtime (JRE) apropiado. Aunque Eclipse puede compilar código para las versiones 1.3 y 1.4 del JDK, las versiones actuales están diseñadas para una versión 1.3. Si no se tiene seguridad sobre dónde encontrar la JVM apropiada para su plataforma, puede encontrar más información en: http://www.eclipse.org.
Una vez que se tiene la JVM, ya se puede obtener Eclipse. Se debe acceder a la
página de descargas de Eclipsee (http://www.eclipse.org/downloads) y se escoge la última versión liberada para la plataforma en la que se quiera trabajar. Todas las versiones se entregan como ficheros .zip. Se debe descomprimir el archivo en un directorio apropiado y luego han de leerse todos los ficheros que estén presentes en el directorio readme. Realizando estos pasos puede darse por concluida la instalación. Si ésta se ha hecho apropiadamente y se han desempaquetado correctamente los archivos debe poderse ejecutar la aplicación sin problemas.
Todas las distribuciones binarias proporcionan una aplicación lanzadora en el directorio principal de Eclipse. El nombre de esa aplicación varía entre plataformas: eclipse.exe en Windows, eclipse en Solaris, etc. La primera vez que se ejecute Eclipse, completará algunas pocas tareas que quedan de la instalación (es decir, la creación del directorio workspace para almacenar los ficheros de proyecto) antes de que aparezca el entorno.
37
4.2.2 Interfaz Después de lanzar Eclipse por primera vez, debería ver una ventana como ésta:
Fig. 3. Ventana de inicio
Como puede verse, el IDE Eclipse tiene una barra de menú bastante estándar:
Fig. 4. Barra de menú
y una barra de herramientas:
Fig. 5. Barra de herramientas
38
También hay una ventana del editor con pestañas, que inicialmente muestra la página de Bienvenida:
Fig. 6. Página de bienvenida
4.2.3 Crear un nuevo proyecto Para comprender el funcionamiento de Eclipse, veamos cómo se puede crear un programa de una sencilla calculadora basada en Swing:
1. Se selecciona File->New->Project... para empezar a crear el primer proyecto Java. En el wizard que aparece, se selecciona Java y de la lista de posibles tipos de proyecto se selecciona Java Project, luego se pulsa el botón Next :
Fig. 7. Selección para crear un nuevo proyecto
39
2. Como nombre de proyecto, ponga Calculator, luego pulse de nuevo el botón Next.
Fig. 8. Dar nombre al proyecto
3. El paso final del wizard permite indicar dónde residirán el código fuente y los ficheros class, especificar cualquier sub-proyecto que se pudiera necesitar para el proyecto actual, y proporcionar cualquier librería necesaria para su construcción. Seleccione el botón de radio Use source folder contained in the project, luego pulse el botón Create New Folder.... Introduzca src como nombre de la nueva carpeta. Pulse Yes cuando Eclipse le pregunte si quiere actualizar la carpeta de salida del proyecto como Calculator/bin.
40
Fig. 9. Crear directorios
4. Pulse el botón Finish para hacer que Eclipse cree el nuevo proyecto. Una vez creado el proyecto, y tras aceptar la ventana que indica que este es un
proyecto Java, puede abrir la 'Perspectiva Java' para visualizarlo, podría observar que la distribución de las ventanas ha cambiado: la vista Outline se ha movido al lado derecho de la pantalla, el Navigator ha sido reemplazado por el Package Explorer, etc.
Fig. 10. Perspectiva Java
41
Una Perspectiva, en el lenguaje de Eclipse, es una distribución de ventanas que contiene cualquier número de editores y vistas diferentes. Eclipse viene con varias perspectivas por defecto (Resource, Java, Debug, etc.) que se pueden personalizar, o se pueden crear perspectivas completamente nuevas. Las perspectivas se manejan utilizando ítems del menú Window o desde la barra de herramientas de perspectivas situadas en la parte superior derecha de la ventana de Eclipse.
Fig. 11. Seleccionar perspectiva
El siguiente paso en la creación de un proyecto Java es crear los directorios que contendrán el código fuente. Se debe cambiar a la perspectiva Resource utilizando Window->Open Perspective->Resource. En la vista Navigator, se ha de expandir el árbol de carpetas hasta que se vea el nodo src. Se selecciona este nodo, luego se elige el menú File->New->Folder. En el diálogo que aparece, hay que asegurarse de que está seleccionado el directorio src, luego se introduce com en el campo Folder Name.
Crear muchas carpetas utilizando el diálogo New Folder puede ser un poco aburrido. Afortunadamente, Eclipse es tan bueno que permite hacer el trabajo utilizando su interface favorito al sistema de ficheros, ventana de comandos, Windows Explorer, etc. Utilice uno de estos métodos para crear dos carpetas llamadas devious y calculator bajo la carpeta com. Una vez que haya hecho esto, seleccione cualquier carpeta en el Navigator y luego seleccione en el menú File->Refresh. Eclipse examinará el sistema de ficheros y actualizará el proyecto adecuadamente. En este punto, el proyecto debería parecerse a esto:
Fig. 12. Árbol de directorios
42
Una forma mejor para crear las carpetas de los paquetes Java es utilizar los menús contextuales que aparecen al pulsar el botón derecho. Por ejemplo, se podría haber creado la ruta de directorios com/devious/calculator en un sólo paso si desde la perspectiva Java se hubiera pulsado el botón derecho sobre la carpeta src:
Fig. 13. Menús contextuales
Luego en la nueva ventana se pone el nombre completo del paquete incluyendo los puntos separadores (es decir com.devious.calculator):
Fig. 14. Crear un paquete
43
4.2.4 Escribir un programa
Ahora que ya se ha creado la estructura de directorios, se puede empezar a añadir código al proyecto. Para ello se va a comenzar a crear las clases que van a formar parte del programa. Eclipse dispone de una herramienta para crear clases en la que no va a ser necesario escribir a mano la declaración de la clase, evitando así posibles errores. Como se verá a continuación, usando la herramienta para crear clases sólo es necesario indicar el nombre, tipo, posible herencia e implementaciones de la clase para obtener una declaración correcta de la misma:
1. Para crear una clase se abre el Explorador de Paquetes pulse con el botón derecho sobre com.devious.calculator (paquete donde se va a crear la clase) y se �elecciona New > Class:
Fig. 15. Crear una clase
2. Aparecerá una nueva ventana donde se podrá definir todas las características que va a tener la nueva clase. En el caso de este ejemplo demostrativo el nombre de la clase a crear va a ser CalcPanel, que ha de escribirse en el espacio indicado para el nombre de la clase a crear, tal y como muestra la imagen siguiente:
44
Fig. 16. Pantalla para crear una clase
3. Para cambiar la superclase se pulsa sobre el botón Browse al lado de Superclase, Si queremos que extienda a Jpanel, en la ventana que aparece se debe introducir JP en el cuadro de texto superior y aparecerá una lista de clases que empiezan con esas letras, seleccionando Jpanel y pulsando OK:
Fig.17. Seleccionar una superclase
45
4. Para añadir las interfaces correspondientes, en este caso Observer y ActionListener, debe hacerse análogamente al punto anterior pero pulsando sobre el botón Add junto a Interfaces.
Fig. 18. Implementar una interfaz
5. Seleccione el resto de los botones de radio según la siguiente imagen y pulse Finish, después de uno segundos Eclipse mostrará este aspecto, donde se puede ver la clase recién creada en el editor Java:
Fig. 19. Clase creada
46
6. Una vez que ha aparecido en pantalla la declaración de la clase se puede continuar escribiendo el código de la misma. Cuando sea necesario crear otra clase puede repetirse el proceso.
Para poder explorar el código del programa con una mayor facilidad Eclipse ha
diseñado la perspectiva Java y Java Browsing como puede verse en la imagen siguiente:
Fig. 20. Perspectiva Java Browsing
4.2.5 Ejecutar y depurar un programa Hasta ahora se ha visto como descargar e instalar Eclipse, como crear un proyecto Java, como añadirle carpetas (y paquetes), y como crear clases y añadirle código. Ahora es el momento de ver la aplicación en funcionamiento. Para ello se va a ver a continuación cómo ejecutar el programa. Para completar los pasos necesarios para ejecutar la aplicación es necesario utilizar la perspectiva Java.
Para ejecutar el programa se debe pulsar sobre la flecha que hay a la derecha del icono del hombre corriendo y seleccione Run As > 2 Java Aplication (si se ha realizado un programa que maneje applets podrá hacerse uso de la función Java Applet) tal y como se muestra en la siguiente figura:
47
Fig. 21. Ejecutar una aplicación Java
Eclipse compilará automáticamente todas las clases del proyecto y nos mostrará la aplicación en ejecución:
Fig. 22. Resultado de la ejecución
48
Si se detecta algún problema en la ejecución puede ser necesario depurar el programa. Como ya se ha ejecutado la aplicación con anterioridad, debajo del botón con la araña (debug) aparecerá un lanzador para depurar la aplicación. Si no es así, siempre se puede seleccionar Debug As > 2 Java Aplication:
Fig. 23. Depurar una aplicación Java
Si Eclipse no cambia automáticamente a la perspectiva Debug puede hacerlo manualmente desde Window > Open Perspective > Other... y seleccionando Debug:
Fig. 24. Perspectiva de depuración
49
Para introducir un breakpoint en la ejecución del programa, puede utilizarse la vista Outline para seleccionar un método determinado de la clase y buscar así la línea de código donde se desea introducir dicho punto de ruptura. Si hace doble click en el margen izquierdo de esta línea, verá que Eclipse marca en ella un breakpoint.
Fig. 25. Breakpoint
Durante la nueva ejecución, una vez que el depurador alcanza el breakpoint, se pueden utilizar los botones de la barra de herramienta de la vista Debug para entrar, pasar o salir de los métodos:
Fig. 26. Botones de acción en la vista Debug
Se debe pulsar el botón Resume de la barra de herramientas de Debug para continuar la ejecución del programa. Si en lugar de pulsar el botón Resume se pulsaran los botones Debug o Run de la barra de herramientas principal, se lanzaría una nueva copia de la aplicación en lugar de continuar con la actual.
50
Capítulo 5 Soluciones experimentales En este proyecto se han implementado dos programas en Java: XMLStructuralSimilarity y XMLModifier. El objetivo del primer programa consiste en realizar una medida de la similitud entre documentos XML así como elaborar una estadística capaz de mostrar las características estructurales más significativas del documento analizado, como puedan ser el número de elementos de cada tipo, o el número medio de hijos por nodo según el tipo. Para documentos pequeños, puede hacerse la comparación utilizando métodos directos, sin embargo, en documentos de gran tamaño, resulta complicado descubrir la estructura del documento.
En estos programas se va a trabajar con SAX y no con DOM, como viene siendo habitual, debido a las necesidades de memoria de éste último. Con SAX se puede trabajar con documentos del tamaño de MBytes, ya que no es necesario guardar en memoria la estructura de árbol del documento como ocurre con DOM, que haría imposible el trabajo con archivos de este tamaño. En el segundo programa, XMLModifier, se va a tomar un documento XML como documento base al que se le van a realizar unas modificaciones según unos parámetros dados obteniéndose a la salida un nuevo documento XML resultado de ejecutar dichos cambios en el documento original.
5.1 Programa para el cálculo de la similitud Este programa procesa dos documentos XML sobre los que se realiza un estudio estadístico que resume las características más importantes de cada documento, mientras almacena la información necesaria tanto para la consecución de dicho estudio como para realizar un cálculo de la similitud estructural entre dichos documentos. Cada documento es procesado por un parser SAX que leerá el documento en cuestión, a la vez que comprueba la sintaxis del mismo, hasta reconocer una determinada estructura sintáctica, lo que conlleva a la invocación del método asociado a dicho evento, donde podrán realizarse operaciones de cálculo y almacenamiento necesarias para continuar seguidamente con la lectura del documento. Una vez concluido el procesamiento del mismo, toda la información recogida referente a los distintos elementos encontrados se encuentra almacenada en un vector de tipos (TypesVector). Para obtener la similitud entre los dos archivos XML es necesario comprobar si ambos poseen los mismos tipos, para ello se van a tomar aleatoriamente elementos del vector de tipos correspondiente a uno de los documentos y se va a buscar si dicho elemento existe en el vector de tipos del segundo documento. El grado de similitud va a venir marcado en función del número de ocurrencias encontradas en el análisis, de forma que a mayor número de tipos comunes, mayor será la similitud. A continuación veremos las clases diseñadas para realizar estas tareas:
51
5.1.1 Handler.java Este fichero contiene todas las funciones necesarias para analizar un documento XML usando un parser SAX. En la clase Handler se sobrescriben los métodos definidos para un parser SAX además de definirse nuevos objetos y métodos para un correcto almacenamiento y gestión de los datos recogidos durante el análisis. 5.1.1.1 Clase Handler Esta clase hereda de DefaultHandler todos los métodos a los que invoca el parser SAX durante la lectura del documento al encontrar una determinada estructura sintáctica. Por ejemplo, cuando el parser encuentra un nuevo elemento se invocará el método startElement, sin embargo, cuando el parser encuentra la etiqueta final de un elemento se invocará al método endElement. Como los métodos de DefaultHandler se encuentran vacíos, ha sido necesario sobrescribir dichos métodos para que realicen funciones de almacenamiento o cálculo de datos necesarios según el caso. 5.1.1.2 Clases StackObject y MyStack SAX es un parser orientado a eventos, esto significa que lee el documento de principio a fin proporcionando los eventos según las etiquetas que vaya encontrando y en igual orden. De esta forma, cuando el parser se encuentra con un nodo hijo, volverá a llamar al método startElement aun cuando el nodo padre no haya terminado. El problema se hace más latente cuando un nodo padre tiene más de un hijo y éstos a su vez un cierto número de hijos, ya que toda esta cantidad de nodos van a procesarse antes que el nodo padre en cuestión. Esto hace bastante complicado el almacenamiento de la información referente a un nodo en concreto, puesto que implica conocer cuál es el nodo activo en cada momento. Para poder subsanar este contratiempo se han implementado las clases StackObject y MyStack. La clase MyStack es la implementación de una pila de StackObjects que simulará el comportamiento de un parser SAX. Cuando éste encuentra un nuevo elemento, llama al método startElement y se crea un nuevo objeto StackObject que se almacena en la parte superior de la pila, mientras que cuando se encuentra la etiqueta que marca el final del elemento, se llama automáticamente al método endElement donde se ha de eliminar el elemento situado en la parte superior de la pila. Usando este mecanismo se asegura que el último elemento almacenado en la pila corresponde al nodo activo, con independencia de la complejidad de la estructura del documento, sin perder información sobre la relación padre-hijo entre nodos. Para la consecución de este cometido, esta clase implementa los métodos comunes para el manejo de una pila:
popElement(): saca el último elemento de la pila. pushElement(StackObject): inserta un nuevo elemento en la pila. peekElement(): devuelve el último elemento de la pila sin borrarlo. La clase StackObject define los objetos que serán almacenados por la pila MyStack. Estos objetos contienen información sobre el nombre del elemento visitado por el parser así como el número de hijos que posee. Esta información será de gran importancia para ciertas aplicaciones realizadas por otra parte del programa. Un objeto StackObject posee dos variables de instancia que son las siguientes:
52
name: variable de tipo String que almacena el nombre del elemento. children: variable de tipo entero que almacena el número de hijos que posee el elemento.
La siguiente figura muestra cómo puede simularse el funcionamiento de SAX
haciendo uso de una pila como la implementada en la clase MyStack.
M yStack M y S tack
M y S tack M y S tack
Fig. 27. MyStack y un parser SAX
5.1.1.3 Clases TypesVector y TypesVectorObject El parser SAX no construye la estructura en formal de árbol en memoria como hace DOM, por lo que, tras el análisis del documento XML con SAX, no queda almacenada ninguna información sobre el mismo. Con las clases siguientes se tiene la posibilidad de almacenar un resumen de los elementos analizados en un vector de tipos, donde cada elemento del mismo se corresponde con un tipo de elemento encontrado durante el análisis. La clase TypesVector define un vector donde se almacenan objetos del tipo TypesVectorObjects. Cada vez que se encuentra un nuevo tipo se crea un objeto TypesVectorObject que se almacena en el vector. Mientras que con DOM se tiene un gasto de memoria equivalente al número de elementos, con este mecanismo el gasto de memoria se reduce drásticamente, ya que el tamaño máximo del vector será el número de tipos diferentes y no el número de elementos. Este vector va a contener un resumen sobre la estructura del documento y puede ser utilizado para comparar documentos y calcular su similitud. Esta clase implementa los métodos siguientes:
add(TypesVectorObject): añade un nuevo elemento TypesVectorObject al final del vector.
53
contains(String): Toma como parámetro el nombre del tipo y busca si ya existe un elemento con ese nombre en el vector, devolviendo la posición del vector en la que se encuentra dicho elemento si existe o bien el valor -1 si no existe.
La clase TypesVectorObject define un objeto donde se almacena la información relativa a cada tipo. Por cada nuevo tipo encontrado por el parser va a añadirse un nuevo objeto TypesVectorObject en el vector de tipos, cuyas variables de instancia serán actualizadas cada vez que, durante el análisis del documento, se encuentre un elemento del mismo tipo. Las variables de instancias definidas para este objeto son:
typeName: Cadena de caracteres que contiene el nombre del tipo. vectorPosition: Variable entera que muestra la posición que ocupa este elemento dentro del vector numElems: Variable entera que contiene el número de nodos de este tipo encontrados. numChildren: Variable entera que lleva cuenta del número total de nodos hijos de elementos del tipo considerado. chose: Variable booleana que toma el valor false si el objeto no ha sido aun tomado para el cálculo de la similitud, o true si ya fue considerado para dicho cálculo. levelVector: Variable del tipo LevelVector que almacena información sobre los niveles en los que se encuentran elementos de este tipo.
5.1.1.4 Clases LevelVector y LevelObject Un nodo de un tipo determinado puede aparecer en cualquier nivel de la estructura arbórea del documento. Si se quiere tener una estimación adecuada sobre dicha estructura, así como obtener conclusiones interesantes sobre los diferentes tipos de elementos, es importante tener en cuenta, para cada tipo de nodo en particular, cómo se distribuyen en niveles los distintos elementos. Para ello se ha creado un vector que recogerá tanto el nivel en el que existe algún elemento del tipo tratado, así como el número de elementos de ese tipo encontrados en dicho nivel. La clase LevelVector define un vector de LevelObjects que será el encargado de guardar toda la información relativa a la distribución por niveles de los nodos. El tipo LevelVector sólo va a ser utilizado como variable de instancia del tipo TypesVectorObject, esto implica que para cada objeto del vector de tipos va a existir un vector de niveles diferente, de esta manera, el LevelVector sólo puede entenderse asociado al tipo al que pertenece. El vector de niveles será creado a la vez que el TypesVectorObject al encontrarse un tipo de elemento desconocido hasta ese momento, siendo actualizado cada vez que sea analizado un elemento del mismo tipo. Esta clase implementa los métodos siguientes:
levelExists(int): Busca si existe un objeto almacenado para el valor del nivel pasado como parámetro. Devuelve la posición del vector donde se encuentra el LevelObject asociado a ese nivel o -1 si no existe. getLevelObject(int): Devuelve el objeto LevelObject situado en la posición del vector indicada por el parámetro. whereToInsert(int): Los objetos de niveles son almacenados en el LevelVector siguiendo un orden creciente de niveles. Cuando es necesario introducir un
54
nuevo objeto en el vector de niveles es necesario conocer la posición en la que debe ser insertado. Para ello se hace uso de esta función que devuelve la posición donde se debe introducir el objeto o -1 si ha de situarse al final del vector. La clase LevelObject se utiliza para guardar la información referente a un cierto
nivel dentro del LevelVector. Dentro de cada vector de niveles no va a existir un LevelObject por cada nivel existente en el documento, ya que de esta forma sólo se va a almacenar un objeto de nivel cuando realmente exista un elemento del tipo especificado en dicho nivel. Esto supone un gran ahorro de memoria especialmente en documentos grandes o con mucha diversidad de tipos, en los que habitualmente cada tipo aparece sólo en un nivel concreto. Cada vez que se analiza un nodo de un cierto tipo, puede obtenerse fácilmente el nivel al que se encuentra midiendo el tamaño de la pila MyStack explicada en el apartado anterior; si dicho nodo es el primero de ese tipo en ese nivel, será creado un nuevo objeto LevelObject para ese nivel que será insertado en la posición que le corresponde dentro del LevelVector, gracias al uso del método whereToInsert explicado con anterioridad. Por el contrario, si ya ha existido un nodo del mismo tipo en ese nivel, cosa que puede conocerse analizando el valor devuelto por el método LevelExists, no será necesario crear un nuevo objeto para ese nivel, ya que éste fue creado anteriormente, si no simplemente incrementar en una unidad el número de elementos en ese nivel. Las variables de instancia definidas para un objeto LevelObject son:
level: Variable de tipo entero que indica el nivel en el que existe algún nodo del tipo considerado. num: Variable de tipo entero que indica el número de nodos del tipo considerado que aparecen en el nivel indicado por level. La siguiente figura muestra cómo se almacena la información recogida en el
análisis de documento y cómo se estructura la misma.
TypesVectorObject{ typeName
vectorPositionnumElemnumChildrenchoselevelVector
}
LevelObject{ num
level}
TypesVector
Fig. 28. TypesVectorObject
55
5.1.2 XMLStructuralSimilarity.java 5.1.2.1 Analizar un documento XML
Lo primero que necesitamos es el parser o analizador. Para ello deberemos de instanciar una factoría de parsers con la clase SAXParserFactory, con la cual se puede crear un conjunto de parsers y configurándolo para que todo analizador perteneciente a ese grupo tenga unas características determinadas. Una vez creada dicha factoría se crea un parser en concreto, perteneciente a la misma, para poder obtener el XMLReader que permita analizar el documento.
SAXParserFactory spf = SAXParserFactory.newInstance(); spf.setNamespaceAware(true); SAXParser saxParser = spf.newSAXParser(); XMLReader parser = saxParser.getXMLReader();
SAX es un parser que nos permite analizar documentos XML. Su característica
principal es que está basado en eventos. El conjunto de eventos posibles a manejar se deberán de agrupar en lo que SAX denomina Handler o Manejador. Handler handler = new Handler(); parser.setContentHandler(handler);
Por último, puede analizarse el documento XML por medio de la llamada al método parse.
parser.parse(file1); 5.1.2.2 Estimación de semejanzas
Tras analizar ambos documentos por medio del parser SAX, la información se encuentra recogida en los TypesVectors. Para estimar la similitud entre los dos documentos XML, es necesario comparar los vectores, para ello van a tomarse aleatoriamente elementos del vector de tipos correspondiente al primer documento, y va a comprobarse si dicho tipo existe o no en el segundo documento, cotejando si está recogido en el vector de tipos del segundo documento. El valor de la similitud va a ser proporcional al número de ocurrencias de tipos en ambos vectores, y por consiguiente en ambos documentos. Este procedimiento va a realizarse también en la dirección inversa, para poder obtener una visión más completa sobre la relación entre las estructuras de ambos ficheros.
Se han definido dos semejanzas distintas según se quiera medir sólo la similitud
en los nombres o bien tener en cuenta además la distribución por niveles de los elementos. La primera similitud, denominada semejanza de nombres, va a comparar únicamente los nombres de los distintos elementos, indiferentemente del lugar que ocupen en la estructura arbórea. La segunda similitud definida, denominada semejanza de nivel, va a comprobar, además del nombre del elemento, si los elementos de igual tipo estás situados al mismo nivel en ambos documentos. Para la primera aproximación, va a obtenerse un éxito u ocurrencia si al tomar un elemento A del vector de tipos del documento primero, al buscar dicho tipo A en el vector de tipos del segundo documento, éste es encontrado. Para la segunda aproximación existirá un éxito u ocurrencia si
56
tomado un nodo A que se encuentra en el nivel i del primer documento, al inspeccionar el vector de tipos del segundo documento, se encuentra un nodo A ubicado en el nivel i. De aquí puede deducirse fácilmente que una ocurrencia en el segundo método de cálculo implica necesariamente una ocurrencia en el cálculo de la primera semejanza, cosa que no ocurre a la inversa, ya que si tenemos un elemento A en el nivel i de la primera estructura y un mismo elemento A en el nivel j de la segunda, en el cálculo de la semejanza de nombres va a considerarse como un éxito, mientras que al calcular la semejanza de nivel como un fracaso.
La semejanza de nombres, �Name, puede calcularse según la expresión:
�=
=N
i
iName NI1
/ρ , donde iI es igual a uno si el nombre del elemento escogido existe en el
segundo documento, o cero si no existe. N representa el número de elementos comparados.
Para poder calcular la semejanza de nivel, �Level, es necesario conocer el número de nodos por nivel del tipo comparado. Esta información se encuentra recogida en el objeto LevelObject. Para el tipo de elemento escogido deben compararse cuántos nodos por nivel existen en cada documento. Para conseguirlo, por cada tipo de elemento seleccionado, va a almacenarse por cada nivel en las variables num1 y num2 el número de nodos existentes en dicho nivel en el documento primero y segundo respectivamente. Para cada tipo t y cada nivel n, puede obtenerse la semejanza parcial Ptn como sigue:
)2,1max()2,1min( numnumnumnumPtn = o toma el valor uno cuando num1=num2=0, ya que la ausencia de elementos del tipo seleccionado en un nivel en ambos documentos ha de considerarse como una coincidencia parcial del 100%. El valor de la semejanza de nivel puede calcularse como: � �= =
=T
t
N
ntnLevel TNP
1 1ρ , con T el número de tipos escogidos y
N el número total de niveles.
El valor de la semejanza entre documentos devuelto por el programa va a ser una media ponderada de los valores obtenidos de la semejanza de nombres y de nivel. Según el valor de los parámetros � y � definidos por el usuario, podrá dársele una mayor importancia a un tipo de semejanza con respecto a la otra para la obtención del valor final de la similitud de la forma: �=� �Name+� �Level, con �+�=1 y � y � con valores comprendidos entre cero y uno.
Para obtener el valor de la similitud estructural entre dos documentos XML se toman al azar un número de elementos del TypesVector del primer documento y se comparan con los elementos del TypesVector del segundo. El resultado de la comparación puede ser más o menos preciso según el número de elementos comparados, siendo el tiempo de ejecución del programa directamente proporcional al porcentaje de nodos comparados. Este porcentaje puede ser definido por el usuario haciendo uso del parámetro PbbChosenNodes.
Los cálculos de las similitudes van a realizarse en las dos direcciones, tomando
elementos de un primer documento y comparándolos con los del segundo, obteniéndose una semejanza total denominada �1. Seguidamente se repite la operación, esta vez tomando los elementos del segundo y comparándolos con los del primero, dando lugar a la semejanza final �2, que ya incluye los efectos de �Name y �Level. Esto puede ser interesante a la hora de comprobar el grado de contenencia de un documento con respecto a otro. Si un documento B está ampliamente contenido en A, la similitud
57
tomando elementos de A y comparándolo con B puede ser mayor o menor según el número de tipos de A que no existen en B, sin embargo, la similitud inversa, tomando en B y comparando con A va a ser muy alta, o incluso la unidad si el acoplamiento es perfecto.
5.2 Modificación de un documento XML Este programa, llamado XMLModifier, toma un documento XML de entrada, lo modifica según el valor de unos parámetros de entrada definidos por el usuario y devuelve un nuevo documento XML reflejando las modificaciones hechas en el documento base. Si no se hiciera ninguna modificación el fichero XML de entrada y salida serían idénticos. 5.2.1 Funcionamiento del programa El objetivo de este programa se basa en poder conseguir un documento XML con un valor conocido de semejanza con respecto al documento origen, para poder probar la eficiencia del cálculo de la similitud hecho por XMLSimilarity. Para conseguirlo van a introducirse una serie de modificaciones al documento base según el valor que tomen los distintos parámetros. En DOM existen funciones que permiten el acceso a un nodo en particular de la estructura de árbol, con SAX, sin embargo, es imposible acceder a un elemento aislado del documento sin una operación de almacenamiento intermedia, ya que el parser lee el documento XML como un flujo de datos, por lo tanto no va a poderse hacer una copia del documento y luego modificar los elementos seleccionados. La solución adoptada ha sido realizar la copia y modificación de los elementos a la vez que son leídos por SAX, de esta forma, cada vez que el parser encuentra un nuevo elemento va a decidirse, según unos parámetros estadísticos, si dicho elemento va a sufrir alguna modificación con respecto al formato original, en cuyo caso se acomete y se copia en el documento de salida, o si bien ha de ser simplemente copiado al documento final. Con este método es posible dar una aleatoriedad a la modificación de la estructura de un documento XML sin necesidad de utilizar la tecnología DOM, con el ahorro de memoria que eso conlleva. Sobre cada elemento van a poderse llevar a cabo tres operaciones de cambio distintas: modificación del nombre del elemento, creación de un duplicado de dicho elemento, modificándole el nombre, y el borrado del elemento. Para poder identificar qué operaciones van a realizarse sobre cada elemento, es necesario hacer uso de unas variables booleanas asociadas a cada operación que serán activadas cuando dicho elemento deba ser realizada alguna de las operaciones indicadas. 5.2.1.1 Modificación del nombre del elemento La probabilidad con la que el nombre de un elemento debe ser cambiado viene dada por el parámetro pbbChange, definido por el usuario. Para cada elemento analizado va a hacerse uso de la función azar, que, según el valor que marque el parámetro responsable del cambio de nombre, va a decidir si el nombre de dicho elemento va a ser modificado o no. En el caso que deba acometerse esta operación, el nombre que se va a transferir al documento final no será el nombre del elemento, sino
58
el devuelto por la función modify., consistente en el nombre original seguido de la cadena de caracteres “kkkkk”. 5.2.1.2 Duplicación El programa XMLStructuralSimilarity no es capaz de detectar un duplicado de un elemento, ya que sólo va a comparar el nombre de la etiqueta y no el contenido del elemento, por lo tanto sería absurdo crear un duplicado idéntico si no va poder detectarse como error, lo que no serviría para poder realizar las pruebas de dicho programa. Para poder detectarlo se va a crear un duplicado al que va a añadírsele al nombre original la cadena “zzzzz”. La creación de este nuevo nodo va a modificar la estructura arbórea del documento, cosa que no ocurría en el caso anterior, creando un nodo hermano al nodo considerado. 5.2.1.3 Borrado Cuando un elemento del documento debe ser borrado, la solución más sencilla consiste en simplemente no copiar dicho elemento al documento destino. Esto significa que todas las operaciones especificadas en startElement y endElement van a realizarse sólo cuando el elemento no deba ser borrado. 5.2.2 Clases RandomProperties y RandomStack El funcionamiento de la clase RandomStack es similar al de la clase MyStack perteneciente a XMLStructuralSimilarity. De nuevo, el uso de un parser SAX hace imposible el acceso a un elemento aislado de un documento XML. La problemática se complica si se tiene en cuenta que la modificación en el elemento no sólo ha de llevarse a cabo en la etiqueta de inicio del elemento, si no también en la etiqueta final del mismo. Es importante, por lo tanto, tener memorizadas las propiedades aleatorias que posee cada elemento así como poder asociar a qué elemento le corresponde el evento endElement lanzado, para así poder realizarle al elemento la operación que le corresponde, si procede. Para poder solucionar estas cuestiones se han creado las clases siguientes. La clase RandomStack implementa una pila en la que van a almacenarse objetos del tipo RandomStackObjects. La inserción y extracción de objetos en esta pila va a simular el trabajo del parser SAX, de forma que, como ya se pudo comprobar con MyStack, el elemento situado en la última posición de la pila corresponde siempre al elemento activo en ese determinado instante, y por lo tanto, si coincide con un evento endElement, el elemento que debe ser terminado. Los métodos implementados para el uso de una pila RandomStack son: pushElement, para insertar un elemento en la pila, popElement, para extraer el último elemento de la pila y peekElement, para poder ver la información del último elemento de la pila sin necesidad de extraerlo. La clase RandomStackObject crea un nuevo tipo de objeto con tres variables booleanas que indicarán si es necesario realizar alguna de las tres operaciones al elemento o no. Cada vez que se encuentra un nuevo elemento se llama a la función azar, que determinará los valores para estas variables booleanas del objeto RandomStackObject, se crea dicho objeto con el valor obtenido para sus variables de
59
instancia y se inserta en la pila. Las tres variables de instancia booleanas del objeto RandomStackObject son las siguientes:
duplicity: marca true cuando deba crearse un nuevo elemento con el nombre del elemento original más la cadena “zzzzz”. El nuevo elemento va a ser un elemento vacío a excepción de cuando el elemento posea atributos, en cuyo caso éstos serán copiados. change: marca true cuando deba modificarse el nombre del elemento, en cuyo caso se añadirá a dicho nombre la cadena “kkkkk”. removal: marca true cuando el elemento debe ser borrado.
5.2.3 Escritura de un documento XML Junto con los métodos propios que contiene la clase DefaultHander asociados a los eventos lanzados por el parser, que han sido sobrescritos para poder realizar las operaciones pertinentes en cada uno de ellos, se han creado algunos métodos nuevos que permitan copiar el documento XML, escribiéndolo en un nuevo documento XML válido. Los más destacados son los que se explican a continuación. 5.2.3.1 Normalización Un documento XML debe cumplir una serie de requisitos para que pueda considerarse un documento XML bien formado, donde para cada elemento que posea datos de tipo carácter debe tener una etiqueta de inicio y otra de fin, a excepción de los elementos vacíos y los valores de los atributos deben aparecer entrecomillados. Todos los ficheros XML deben poseer un elemento raíz que además sea único y del que cuelgan en resto de los elementos del documento, siguiendo un orden jerárquico de etiquetas finales idéntico al seguido por las etiquetas de inicio. Debe tenerse especial cuidado con ciertos caracteres que tienen un significado concreto en XML y cuya aparición el los datos puede llevar a confusiones, de esta forma, se escribirá &, <, " y ' para sustituir a los símbolos &, <, >, “ y ‘ respectivamente. Con el método normalize cada vez que se encuentre uno de los llamados caracteres especiales en los datos, va a normalizarlo añadiéndole el código que le corresponde y así poder obtener un documento XML normalizado. Esto es muy importante, ya que la comparación entre documentos XML ha de hacerse con documentos normalizados. 5.2.3.2 Espaciado Un mal formato de salida en un documento XML puede hacerlo ilegible. Para ayudar en la medida de lo posible a la legibilidad del texto se utiliza el método nl (acrónimo de new line), que inserta el carácter correspondiente a final de línea utilizado por el sistema actual, lo que permite utilizar el código con independencia del sistema utilizado. 5.2.3.3 Configuración de la E/S
Para hacer el programa más flexible, el usuario podrá definir los valores de los parámetros de funcionamiento del programa como los nombres de los ficheros de
60
entrada y salida, así como las probabilidades para que se realice una de las tres posibles operaciones de cambio en el documento de entrada. El funcionamiento del programa puede apreciarse como sigue:
Usage: java XMLModifier inputfile outputfile pbbDuplication pbbChange pbbRemoval
inputfile: Documento XML base. Será leído por SAX y modificado para obtener el documento de salida.
outputfile: Documento de salida donde quedarán recogidos los cambios hechos al documento de entrada. pbbDuplication: Valor entre 0 y 1 que indica la probabilidad para que se cree un nuevo elemento con el nombre del elemento considerado, al que se le añade la cadena “zzzzz”. pbbChange: Valor entre 0 y 1 que indica la probabilidad con la que debe modificarse el nombre de un elemento. pbbRemoval: Valor entre 0 y 1 que indica la probabilidad con la que debe eliminarse un elemento.
El método main recibe como parámetros cadenas de caracteres, lo que no supone ningún problema para los nombres de los ficheros XML, pero sí para los parámetros de probabilidad que almacenan valores de tipo double. La traducción de la cadena de caracteres a valores double no puede hacerse directamente, es necesario realizar un paso intermedio. Los parámetros van a ser traducidos en un primer paso a objetos Double, para posteriormente, haciendo uso del método doubleValue, perteneciente a la clase Double, obtener los valores de las probabilidades en variables de tipo double. Estas transformaciones quedan reflejadas en las líneas de código siguientes:
pbbDup=new Double(args[2]); pbbDupMod=pbbDup.doubleValue(); pbbCh=new Double(args[3]); pbbChange=pbbCh.doubleValue(); pbbRem=new Double(args[4]); pbbRemoval=pbbRem.doubleValue();
A la salida debe obtenerse un documento XML válido independiente del de la entrada, por lo es necesario crear y escribir un nuevo documento XML normalizado y bien formado. Este programa copia el documento de entrada en uno de salida en el que pueden realizársele modificaciones según los parámetros estadísticos definidos por el usuario y todo esto durante el funcionamiento del parser SAX. La solución adoptada para resolverlo consiste en que, ya que cada vez que se detecte la presencia de un nuevo elemento va a llamarse al método startElement, debe ser en ese momento en el que dicho elemento va a ser copiado en el documento de salida, realizándole alguna operación de cambio o no según el valor almacenado en las variables del objeto RandomStackObject asociado al elemento en cuestión. Cuando se detecta el final de un elemento va a llamarse al método endElement, en este momento habrá de terminar, por lo tanto, el elemento en el documento de salida, manteniendo las operaciones realizadas en la etiqueta de comienzo y tener así un documento consistente. Para poder dar al documento de salida el nombre indicado en el parámetro es necesario crear FileOutputStream. Para escribir la salida es necesario crear un objeto OutputStreamWriter, que escribirá la salida en el documento de salida por medio del FileOutputStream.
61
static private Writer out; FileOutputStream fout;
fout = new FileOutputStream ( args[1] ); out = new OutputStreamWriter(fout, "UTF8");
Durante la operación de escritura pueden ocurrir excepciones IOExceptions, sin embargo, los métodos de DefaultHandler no lanzan IOExceptions, si no sólo excepciones del tipo SAXExceptions. Por este motivo se utiliza el método emit para la escritura, ya que permite encapsular la IOException dentro de una SAXException.
5.3 Resumen Para la realización de este proyecto se han creado dos programas diferentes llamados XMLStructuralSimilarity y XMLModifier. El primero de ellos calcula la similitud existente entre dos documentos XML, presentando también una estadística de cada uno de ellos a base de obtener informaciones relevantes sobre la estructura y características de los documentos sin necesidad de observarlo directamente, lo que supone un gran ahorro en el caso de ficheros de grandes longitudes. El segundo programa va a tomar un documento XML y va a modificarlo según unos parámetros estadísticos definidos por el usuario, obteniéndose tras el proceso un nuevo documento XML válido. El objetivo principal de este programa consiste en obtener un documento con un grado de similitud conocido a priori con la intención de servir como herramienta de pruebas para comprobar la eficiencia del programa XMLStructuralSimilarity.
62
Capítulo 6 Experimentos Tras la descripción sobre el funcionamiento de los programas, resulta interesante poder analizar su comportamiento. Para todos los experimentos va a utilizarse un fichero XML como documento base, extraído de la base de datos: http://www.rcsb.org/pdb/, que es una base de datos de proteínas, donde se almacenan las características de cada proteína en concreto en documentos XML. La elección de dicha base de datos radica en que en ella pueden descargarse documentos XML que representen a diferentes proteínas y siendo posible apreciar la estructura en tres dimensiones de las distintas proteínas. Puede comprobarse de esa forma que documentos referentes a proteínas con características similares poseen no sólo un a estructura en tres dimensiones con visibles semejanzas, si no también una similitud mayor entre sus respectivos documentos XML que con el resto de proteínas. Otra cualidad importante consiste en que los documentos obtenidos de esa base de datos poseen tamaños varios, pero casi todos con un número bastante elevado de Bytes, lo que encaja perfectamente con las aplicaciones presentadas para estos programas. El documento escogido para los análisis se llama 1b2g.xml, de 519KBytes. Para conocer aspectos relevantes sobre el mismo se ha hecho uso del programa XMLStructuralSimilarity que presenta una estadística sobre el documento y de la que han destacado las propiedades de carácter general que se muestran a continuación:
Total number of nodes without leaves: 655 Total number of children: 9239.0 Average number of children pro node: 14.105344 Maximal depth: 4 Number of different types: 327
6.1 Escenarios En este proyecto se han desarrollado dos programas diferentes, en los que se reciben una serie de parámetros necesarios para la ejecución de los mismos. Durante todo este capítulo se van a plantear distintos escenarios en los que se van a analizar el efecto que produce la variación del parámetro o parámetros en cuestión en el resultado del programa. En el primer programa, llamado XMLStructuralSimilarity, éste recibe tres parámetros diferentes: �, � y pbbChosenNodes. Los dos primeros se necesitan para poder calibrar el grado de importancia que ha de darle a cada tipo de similitud, �Name, que sólo mide la coincidencia en el nombre de las etiquetas, �Level, que comprueba cuántos elementos coinciden además en el nivel al que se encuentran (ver Cap. 5), en el cálculo de la semejanza total �=� �Name+� �Level, con �+�=1 y � y � con valores comprendidos entre cero y uno. El parámetro pbbChosenNodes va a permitir controlar el tanto por ciento de elementos escogidos del vector de tipos para hacer los cálculos de la similitud.
63
Para el segundo programa, el llamado XMLModifier, van a tomarse tres parámetros: pbbDuplication, pbbChange y pbbRemoval, que van a marcar respectivamente las probabilidades de que se produzca una duplicación, una modificación en el nombre del elemento o que éste sea eliminado. Van a presentarse tres experimentos distintos. Para cada uno de ellos va a estudiarse el efecto de algún parámetro en particular, ejecutando el programa con distintos valores del parámetro en cuestión, mientras el resto de los parámetros toman un valor constante. En el primero de dichos experimentos va a modificarse el valor del parámetro pbbChosenNodes. En el segundo va a estudiarse conjuntamente el efecto de a y ß, ya que ambos se encuentras sujetos a la restricción de a+ß=1. Para el tercer experimento va a estudiarse el efecto de los parámetros del programa XMLModifier, realizándose tres pequeños experimentos según se quiera estudiar los efectos de pbbDuplication, pbbChange o pbbRemoval. Para todos los experimentos van a obtenerse las similitudes finales �1 y �2, que corresponden, respectivamente, a tomar elementos del vector de tipos del primer documento y compararlo con el segundo, y tomar elementos del vector de tipos del segundo documento para compararlos con el primero. Estos cálculos en dos direcciones son de mucha utilidad a la hora de detectar si un documento se encuentra contenido en otro, y como podrá verse en los experimentos siguientes, ambas similitudes van a tener valores y comportamientos diferentes.
6.2 Experimento 1
El experimento 1 muestra cómo afectan los distintos valores que puede tomar el parámetro pbbChosenNodes a la hora de la estimación de la similitud entre documentos. Calcular la semejanza entre documentos de pequeño tamaño utilizando todos los elementos del vector de tipos no resulta ningún problema. En documentos muy grandes resulta interesante estudiar con qué tanto por ciento de nodos analizados se obtiene un valor representativo de la semejanza entre los documentos para, de esta forma, ahorrar tiempo de cómputo. Cuanto mayor sea el valor del parámetro pbbChosenNodes, mejor va a ser la estimación obtenida en la similitud, en contra, sin embargo, del tiempo de ejecución del programa.
En este experimento van a permanecer todos los parámetros constantes, excepto
obviamente el que queremos estudiar. Va a tomarse como documento origen el fichero 1b2g.xml, que va a ser modificado con el programa XMLModifier, obteniéndose el fichero dirty1b2g.xml, donde sólo un cuarto de los nodos van a modificarse, sin duplicados o eliminación de elementos. Ambos documentos van a ser comparados por el programa XMLStructuralSimilarity. Esta comparación va a repetirse once veces en las que el parámetro pbbChosenNodes va a tomar valores comprendidos entre 0 y 1 a intervalos de 0.1. El valor de � y � va a permanecer constante con �=�=0.5, es decir, se le va a dar igual importancia tanto a �Name como a �Level durante las distintas ejecuciones que comprende este experimento. Por cada ejecución van a obtenerse dos valores distintos, uno de �1 (donde se compara 1b2g.xml con dirty1b2g.xml) y �2 (donde se compara dirty1b2g.xml con 1b2g.xml). En la siguiente figura (Fig. 29) se representan las curvas correspondientes a las similitudes �1 y �2 según los valores del parámetro pbbChosenNodes. Los resultados obtenidos en este experimento son dependientes de los nodos que hayan sido escogidos, para poder comprobar dicho efecto, se va a realizar el
64
experimento una segunda vez, cambiando el valor de la semilla en la función random y obteniéndose las curvas �1’ y �2’.
Como puede apreciarse en la gráfica, al aumentar el número de elementos
comparados, más cercano es el valor de la similitud obtenido al valor real de la similitud de los documentos, representado por las curvas real �1 y real �2. Como ya se había predicho, las curvas obtenidas al variar la semilla de random van a ser distintas, ya que se van a tomar distintos elementos en las comparaciones, pero a medida que aumenta el número de comparaciones puede apreciarse como ambas aproximaciones tienden al valor real de la similitud tanto para una dirección de comparación como para la otra, llegando a obtenerse para el cómputo del 100% de los elementos el mismo valor ya se hayan escogido los elementos en un orden u en otro, como era de esperar.
0,5
0,55
0,6
0,65
0,7
0,75
0,8
0,85
0,9
0 0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9 1
pbbChosenNodes
Sim
ilari
ty
p1p1´real p1p2p2´real p2
Fig. 29. Análisis del efecto de pbbChosenNodes
Como puede apreciarse, cuanto menor es el número de elementos del TypesVector tomados para realizar la comparación, mayor es el error que puede obtenerse en el valor de la similitud, por el contrario, cuanto menos elementos se toman para la realización de los cálculos, menor va a ser el tiempo de cómputo de la similitud, creciendo este linealmente con el tanto por cierto de elementos tomados, siendo esta medida dependiente del número de tipos de cada documento. Es interesante, en especial para documentos extensos, obtener el valor del parámetro pbbChosenNodes mínimo para obtener un resultado con un error absoluto por debajo de la cota de error deseada, disminuyendo así el tiempo de ejecución del programa. Esto puede parecer secundario a la hora de comparar dos documentos aislados, donde la diferencias de tiempos no van a ser excesivas, pero si la comparación ha de aplicarse a miles de documentos, este ahorro de tiempo va a ser de gran importancia.
65
6.3 Experimento 2 Como ya se comentó en el capítulo anterior, el programa XMLStructuralSimilarity calcula dos tipos de semejanzas, semejanza de nombres o �Name, que comprueba si el nombre del elemento escogido de un documento XML aparece también en el otro documento, y la semejanza de nivel o �Level, que no sólo analiza la coincidencia en los tipos de nodo analizados, si no para cada tipo, también el número de nodos que se encuentran en el mismo nivel de la estructura arbórea. Con los parámetros � y � puede controlarse la importancia que va a darse a cada tipo de similitud �Name y �Level en el cálculo de las semejanzas finales �1, �2 (según el sentido de la comparación) de la forma �=� �Name+� �Level, donde �+�=1. En el caso extremo con �=1(lo que supone �=0) se van a comparar, para los objetos TypesVectorObject tomados del vector de tipos, solamente la coincidencia o no en el nombre del tipo en cuestión. En el otro extremo, para �=1(�=0), va a calcularse la similitud calculando para cada elemento seleccionado no sólo el nombre del tipo, si no también la cantidad de nodos que además se encuentran en el mismo nivel. Para el resto de valores intermedios de � y � va a calcularse haciendo la media ponderada de ambas similitudes según el valor de estos parámetros. Para observar el efecto que se produce en la similitud total al variar los valores de los parámetros � y � se ha llevado a cabo este experimento, tomando como base el documento 1b2g.xml, al que se le han realizado una serie de cambios por medio del programa XMLModifier (pbbDuplication=0, pbbChange=0.25 y pbbRemoval=0). Este nuevo documento XML va a compararse once veces con el original, siempre con el valor pbbChosenNodes=1, pero variando los valores del par (�,�)desde �=1, �=0 hasta �=0, �=1 con pasos de 0.1. La siguiente gráfica (Fig. 30) muestra los valores de la similitud al variar los valores de � y �. En el eje X se van a representar conjuntamente estos dos parámetros (con � en la fila superior y � en la inferior), ya que ambos se encuentran ligados por la dependencia �+�=1. En el eje Y de la gráfica van a representarse los valores de �1 y �2.
0
0 ,1
0 ,2
0 ,3
0 ,4
0 ,5
0 ,6
0 ,7
0 ,8
0 ,9
0 0 ,1 0 ,2 0 ,3 0 ,4 0 ,5 0 ,6 0 ,7 0 ,8 0 ,9 1
1 0 ,9 0 ,8 0 ,7 0 ,6 0 ,5 0 ,4 0 ,3 0 ,2 0 ,1 0
a lp h a a n d b e th a
Sim
ilari
ty
p 1p 2
Fig. 30. Alfa y Beta
66
Como era de suponer, �1 es siempre mayor que �2, ya que representa los nodos
del documento original que coinciden con los del modificado. Si el nodo modificado en el segundo documento no es el único de ese tipo, al comparar del primer al segundo documento va a existir coincidencia, pero al comparar en la otra dirección, al tomarse el elemento modificado, no existirá ningún elemento de ese tipo en el original. Por otra parte, al darle una mayor importancia a la semejanza de nivel que a la de nombres, el valor de la similitud final va a disminuir, ya que una coincidencia en el tipo no implica coincidencia en los niveles en los que los nodos de dicho tipo se encuentran. 6.4 Experiment 3 En este experimento se quiere estudiar cómo afectan los distintos cambios que pueden producirse en un documento XML al valor de la similitud entre documentos XML. Para ello se va a crear un escenario en el que se van a mantener todos los parámetros constantes a excepción del cambio a realizar en el documento. Los parámetros del programa XMLStructuralSimilarity van a mantenerse constantes con unos valores de parámetros �= �=0.5 y pbbChosenNodes=1. Los parámetros del programa XMLModifier son los que van a ser estudiados a lo largo de este experimento, que se va a subdividir en tres experimentos para analizar las incidencias que produce cada uno de los parámetros indicativos de una operación de cambio como son pbbDuplication, pbbChange y pbbRemoval. 6.4.1 pbbDuplication Con el programa XLMModifier se tiene la posibilidad de duplicar elementos, pero como un duplicado con idéntico nombre no provoca ningún efecto en el valor de la similitud calculada por XMLStructuralSimilarity, va a crearse un duplicado al que se le modifica levemente el nombre. En este experimento va a llamarse al programa XMLModifier para crear distintos documentos XML. Para cada llamada al programa van a mantenerse constantes y a cero las probabilidades de realizar una operación de cambio que no sea la que cuyo efecto va a ser estudiada, de esta forma se fijarán los parámetros pbbChange= pbbRemoval=0, mientras que pbbDuplication va a irse variando desde 0 a 1 en pasos de 0.1, creándose un total de once documentos que serán comparados con el documento original, 1b2g.xml, por medio del programa XMLStructuralSimilarity para obtener los valores de similitudes expresados en la figura siguiente:
67
Duplication
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
1
1,1
0 0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9 1
PbbDuplication
Sim
ilari
ty
p1p2
Fig. 31. Efecto de la Duplicación de nodos en la similitud
En el eje X se representan los distintos valores que toma el parámetro
pbbDuplication, mientras que en el eje Y se muestran los valores tomados por la similitud �1 y la correspondiente a la otra dirección de comparación �2. En las distintas comparaciones puede apreciarse como el valor de �1 permanece constante a pesar de realizarse las duplicaciones, esto puede entenderse con facilidad si se considera que �1 marca la similitud entre los tipos tomados del documento base (sin modificar) con los del documento modificado. En este documento van a seguir apareciendo todos los elementos del documento original, al que se le van a añadir elementos nuevos, los duplicados, de esta forma cualquier tipo a comparar del vector de tipos del documento base va a existir en el vector de tipos del documento modificado, obteniéndose siempre el valor máximo de �1. De la misma forma, al tomar los elementos de los documentos modificados se tiene en un principio, para pbbDuplication=0, que ambos documentos son idénticos. Al ir aumentando el número de duplicados y por lo tanto el número de nodos con tipos que difieren del documento original, la similitud �2 va a ir disminuyendo hasta el valor límite de pbbDuplication=1, donde por cada nodo original va a tenerse un duplicado, duplicando el número de tipos diferentes del documento modificado y disminuyendo la similitud con respecto al original a un 50%.
6.4.2 pbbChange En este apartado va a estudiarse también el efecto producido en la similitud entre documentos XML cuando un solo parámetro del programa XMLModifier entra en juego. En este caso va a analizarse cómo se ven afectadas las similitudes �1 y �2 al variar el parámetro pbbChange, que marca la probabilidad con la que el nombre de un nodo debe ser modificado, de 0 a 1 en pasos de 0.1. Los resultados pueden verse reflejados en la gráfica siguiente (Fig. 32.):
68
Change
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
1
1,1
0 0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9 1
PbbChange
Sim
ilari
ty
p1p2
Fig. 32. Efecto de la modificación del nombre del nodo en la similitud
En el eje X se representa el valor del parámetro pbbChange, mientras que en el
eje Y se muestra el valor de las similitudes �1 y �2. Como era de suponer, cuanto mayor es el número de nodos modificados, menor va a ser la similitud entre los documentos y en ambos sentidos, hasta llegar al caso límite en el que todos los nodos del documento has sido modificados, obteniéndose una similitud nula tanto en una dirección como en la otra. 6.4.3 pbbRemoval
Como se ha llevado a cabo para los parámetros pbbDuplication y pbbChange,
puede también estudiarse el efecto de la eliminación de nodos. Cuanto mayor sea el valor del parámetro pbbRemoval, que tomará valores de 0 a 1 a pasos de 0.1, mayor será el número de nodos del documento base que serán eliminados y por lo tanto no aparecerán en el documento modificado. Para cada valor del parámetro pbbRemoval, va a obtenerse un documento con el programa XMLModifier, que será comparado con el documento original por medio del programa XMLStructuralSimilarity y cuyo resultado se representa en la figura siguiente (Fig. 33.):
69
Removal
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
1
1,1
0 0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9 1
PbbRemoval
Sim
ilari
ty
p1p2
Fig.33. Efecto de la eliminación de nodos en la similitud
Debido a la inexactitud propia de la función random de Java, cuando pbbRemoval=1, no son eliminados todos los nodos del documento, si no aproximadamente un 99%. Esto hace que el vector de tipos del documento modificado, en el caso extremo en el que todos los nodos deben ser borrados, no esté vacío y por lo tanto, al tomar los elementos del mismo y compararlos con el vector de tipos del documento original, la coincidencia esté asegurada, sin embargo, al realizar la comparación inversa, sólo se va a lograr coincidencia para un número muy reducido de elementos, ya que la mayoría de nodos han sido eliminados, obteniéndose una similitud prácticamente nula.
6.5 Resumen Los resultados de los experimentos son los esperados, el único cuyo comportamiento puede resultar extraño es el experimento 3.3, donde se analiza los efectos del parámetro pbbRemoval. Como ya se ha explicado, esta anomalía es debida a la inexactitud de la función random que hace que al requerirse la eliminación del 100% de los nodos, sólo un 99% sea eliminado, en concreto, en la realización del experimento, sólo un nodo del documento 1b2g.xml no fue borrado. La realización de estos experimentos, así como la obtención de los resultados teóricos, confirma la validez y exactitud obtenida por el programa XMLStructuralSimilarity para la estimación de la similitud existente entre dos documentos XML.
70
Capítulo 7 Síntesis El objetivo principal de este proyecto se basa en la implementación de una aplicación que permita estimar de manera fiable la similitud existente entre dos documentos XML de cualquier tamaño, aunque orientado en especial a documentos de gran tamaño, donde los métodos directos resultan demasiados costosos. La comparación de documentos XML no resulta una tarea tan sencilla como pueda ser la comparación de documentos planos, ya que los documentos XML poseen una estructura de datos en forma de árbol. Aun cuando los documentos proceden del mismo esquema generador, la estructura de los documentos puede diferir debido a la presencia de elementos opcionales o múltiples. Los métodos actuales para medir la similitud a nivel estructural entre documentos XML se basan, en su mayoría, en el cálculo de la distancia de edición entre árboles o tree-edit-distance. Este cálculo resulta muy costoso no sólo a nivel de gasto de memoria, ya que supone tener almacenada la estructura de árbol de los documentos en memoria, si no también en tiempo de ejecución. En este proyecto se va a presentar un método para calcular esta similitud ahorrando notablemente el tiempo de ejecución y el gasto de memoria. El programa XMLStructuralSimilarity va a ser el encargado de estimar la similitud entre dos documentos XML. Utiliza un analizador basado en eventos, SAX, por lo que no se va a almacenar ninguna estructura en árbol del documento en memoria. Para poder hacer la comparación, sin embargo, es necesario almacenar información sobre cada documento para poder ser comparada y estimar así la similitud. La solución adoptada en este proyecto consiste en almacenar en un vector de tipos, TypesVector, información referente a cada tipo de elemento encontrado durante el análisis del documento. Una vez procesados los documentos que se desean comparar se van a tomar aleatoriamente elementos de uno de los TypesVectors para comprobar si dicho tipo existe en el otro documento, y por consiguiente en el vector de tipos asociado al otro documento. Cada elección de un elemento del TypesVector puede entenderse como una variable de Bernoulli que toma el valor 1 si existe coincidencia de tipos en ambos documentos o 0 si no. Cuanto mayor sea el número de elementos tomados para realizar una comparación mejor será el valor de la similitud obtenida, aumentando, por el contrario, el tiempo de ejecución. Se van a calcular dos tipos de semejanzas distintas según se quiera comparar sólo la coincidencia existente entre los tipos de elementos en uno y otro elemento, indiferentemente del lugar que ocupan en la estructura, o bien si se quiere que el valor de la similitud refleje también la coincidencia en el nivel al que se encuentran los elementos en ambos documentos. El valor final de la similitud devuelto por el programa va a ser una media calibrada de estos dos tipos de similitud. La calibración puede ser controlada por el usuario gracias a los parámetros � y �, al igual que el tanto por ciento de tipos comparados, con el parámetro pbbChosenNodes. El programa va a ofrecer también una estadística sobre el documento desde un punto de vista general y también particularizando para cada tipo de nodo encontrado. Esta estadística muestra aspectos como el número de nodos, el nivel al que se encuentran los nodos de un determinado tipo, el número medio de hijos que poseen los nodos de un
71
tipo o el número total de nodos, entre otras cosas, permitiendo de esta forma tener un conocimiento aproximado de la estructura del documento sin necesidad de almacenarla en memoria, y todo obtenido en una única lectura del documento con el parser. La realización de este proyecto contiene la implementación de un segundo programa, XMLModifier, que permite modificar de forma aleatoria un documento XML. Este programa permite crear duplicados de elementos de un fichero XML, así como modificar el nombre del elemento o incluso eliminar un elemento respectivamente y de forma aleatoria según el valor de los parámetros pbbDuplication, pbbChange y pbbRemoval. Estas modificaciones dan lugar a un nuevo documento XML válido creado por el propio programa y cuyo nombre puede ser escogido por el usuario. XMLModifier ha sido creado para poder probar el funcionamiento de XMLStructuralSimilarity. XMLModifier trabaja de nuevo con SAX para poder ser aplicado a documentos de cualquier tamaño. Como puede apreciarse en el capítulo 6, donde se presentan los resultados de los experimentos realizados, XMLStructuralSimilarity nos da una estimación válida sobre la similitud estructural existente entre documentos XML. Gracias a la utilización de SAX, el gasto de memoria se presenta en función del número de tipos diferentes presentes en un documento XML, almacenándose un objeto por cada tipo distinto encontrado. Los métodos basados en DOM necesitan almacenar en memoria la estructura de todos los documentos XML que se quieran comparar, haciéndolo inviable para documentos de gran tamaño. Uno de los objetivos principales de este proyecto consistía en crear una herramienta para estimar la similitud entre documentos XML, orientada especialmente a documentos con grandes volúmenes de datos, en los que resulta más complicado establecer métodos directos para conseguirlo. En ese sentido, la aplicación realizada cumple perfectamente su objetivo, ya que permite procesar documentos XML de gran tamaño sin costes excesivos de tiempo o memoria. Además, gracias a la estadística sobre el documento ofrecida por XMLStructuralSimilarity, puede conocerse de manera aproximada la estructura del documento así como extraer conclusiones interesantes sobre sus elementos, profundidad del árbol o número medio de hijos sin necesidad de almacenar la estructura o tener que comprobarlo empíricamente. Desgraciadamente, para conseguir estas prestaciones en velocidad y bajo consumo de memoria se han tenido que sacrificar ciertos aspectos como el contenido de los elementos, ya que la comparación sólo se realiza en base al nombre de los mismos, sin considerar su contenido. Una de las posibles líneas de continuación para este proyecto podría ser la realización de una interfaz de usuario que facilitara el manejo del programa. Por otra parte, si se quiere tener una mejor estimación de la similitud obtenida, se podría tener un tercer tipo de similitud, ponderado con un parámetro tal que �+�+=1, que comparara el número de los valores de un tipo de elemento determinado que coinciden en ambos documentos. Es decir, va a comparar no sólo el nombre de los elementos, sino también el contenido de los mismos. Para ello podría crearse un nuevo vector de contenidos, semejante al vector de niveles, para cada tipo de elemento (existiría un vector de contenidos para cada elemento almacenado en el TypesVector). Al igual que para cada nombre de etiqueta diferente se tenía un vector de niveles que indicaba en qué niveles de la estructura aparecían elementos con dicha etiqueta, podría tenerse un vector de contenidos que indicara, para cada elemento con un nombre de etiqueta determinado, los distintos valores que poseen esos elementos. De esta forma, por cada contenido
72
diferente de un elemento de un mismo tipo se añadirá un nuevo elemento a este vector de contenidos, indicando el número de veces que dicho contenido ha aparecido (para detectar duplicados). Durante el proceso de selección aleatoria de elementos del vector TypesVector para el cálculo de la similitud, cuando ha sido seleccionado un tipo de elemento determinado, además de comprobar si existen elementos con ese nombre en el otro documento y comparar los niveles en los que se encuentran, habría que comparar para cada valor almacenado en el vector de contenidos cuáles coinciden en un documento y en otro. Todo esto implicaría un aumento notable en el espacio de almacenamiento necesario, pues supone almacenar un nuevo objeto por cada contenido diferente de un elemento en el documento (valor muy elevado ya que los duplicados van a ser escasos), disminuyendo el rango de documentos en los que sería aplicable esta herramienta. El tiempo de ejecución se vería también notablemente afectado, ya que para cada elemento a comparar va a ser necesario realizar un nuevo conjunto de operaciones, entre las que se encuentra recorrer los vectores de contenidos de ambos documentos.
73
Código de los programas XMLStructuralSimilarity.java /* * Created on 17.03.2004 */ /** * @author Julia del Carmen Olivares Nadal * * StatsWithSAX is a program designed to display statistical information * about a XML document using a SAX parser and obtain the similarity * between 2 XML documents. */ import org.xml.sax.*; import javax.xml.parsers.*; import java.util.*; import java.lang.Math; public class XMLStructuralSimilarity { /***************************** * Main function *****************************/ public static void main(String[] args)throws Exception { if (args.length !=5) { System.err.println ("Usage: java XMLStructuralSimilarity filename filename PbbChosenNodes alpha beta"); } else{ //filenames to compare String file1 = new String(args[0]); String file2 = new String(args[1]); Double times=new Double(args[2]); float procent=times.floatValue(); Float a=new Float(args[3]); float alpha=a.floatValue(); Float b=new Float(args[4]); float beta=b.floatValue(); if((alpha+beta)!=1){ System.err.println("Please alpha+beta=1"); System.exit(0); } //create a parser SAXParserFactory spf = SAXParserFactory.newInstance(); spf.setNamespaceAware(true); SAXParser saxParser = spf.newSAXParser(); XMLReader parser = saxParser.getXMLReader(); //create a handler. Handler handler = new Handler(); //assign the handler to the parser. parser.setContentHandler(handler);
74
//parse the document. parser.parse(file1); //copy the TypesVector in another one and clear the old one //in order to use it again for the second file. TypesVector doc1=new TypesVector(); doc1=(TypesVector) Handler.typesVector.clone(); Handler.typesVector.clear(); //create a new parser and a new handler //and parse the second document. XMLReader parser2= saxParser.getXMLReader(); Handler handler2= new Handler(); Handler.totalNumNodes=0; parser2.setContentHandler(handler2); parser2.parse(file2); //calculate the number of nodes to be picked int numTimes=Math.round(procent*doc1.size()); //print the similarity in both directions. double similarity=similarity(doc1,Handler.typesVector,numTimes,alpha,beta); System.out.println("p="+similarity); numTimes=Math.round(procent*Handler.typesVector.size()); similarity=similarity(Handler.typesVector,doc1,numTimes,alpha,beta); System.out.println("p2="+similarity); } } /***************************** * Utility methods *****************************/ //In this function is where the similarity is calculated. //It becomes the two TypesVectors, in which the type information //of the 2 documents is summarized. //The similarity is calculated by randomly picking a type of a //document and checking if it exist in the second document. public static double similarity(TypesVector doc1,TypesVector doc2,int numTimes, float alpha,float beta) throws ArrayIndexOutOfBoundsException{ Random iterator=new Random(); int next; int numConcurrences=0; int same; int exists=0; int existLev=0; int lev; int num1; int num2; int index=-1; String typeToCompare; double similarityProLevel []= new double[Handler.maxLevels+1]; //Initialize the arrays for(int i=0;i<Handler.maxLevels;i++) similarityProLevel[i]=0; //Pick randomly elements and calculate the similarity for(int i=0;i<numTimes;i++){ next=iterator.nextInt(doc1.size()); if(((TypesVectorObject)doc1.get(next)).chose==false) { ((TypesVectorObject)doc1.get(next)).chose=true; index++;
75
typeToCompare=((TypesVectorObject)doc1.get(next)).typeName; exists=doc2.contains(typeToCompare); numConcurrences=(exists==-1) ? (numConcurrences) : (numConcurrences+1); if (exists!=-1) //For every type that exists in the other document. { for(int j=1;j<Handler.maxLevels+1;j++) { lev=((TypesVectorObject)doc1.get(next)).levelVector.levelExists(j); if(lev!=-1) { num1=((TypesVectorObject)doc1.get(next)).levelVector.getLevelObject(lev).num; }else num1=0; existLev=((TypesVectorObject)doc2.get(exists)).levelVector.levelExists(j); if(existLev!=-1) num2=((TypesVectorObject)doc2.get(exists)).levelVector.getLevelObject(existLev).num; else num2=0; same=(num1==0&&num2==0)? 1 :Math.min(num1,num2)/Math.max(num1,num2); similarityProLevel[j-1]+=same; } } //To know which elements are compared in every iteration and //if there´s an occurrence please activate the next lines. //System.out.println("typeToCompare="+typeToCompare); //System.out.println("exists="+exists); //System.out.println("numOcurrences="+numConcurrences); } else numTimes++; } double similarity; double simNames; double simLev=0; for(int i=0;i<similarityProLevel.length;i++){ simLev+=similarityProLevel[i]; } simLev=simLev/((index+1)*Handler.maxLevels); System.out.println("Structural similarity pro level="+simLev); simNames=(double)numConcurrences/(index+1); System.out.println("Similarity in Names="+simNames); similarity=alpha*simNames+beta*simLev; return similarity; } }
76
Handler.java /* * Created on 17.03.2004 */ /** * @author Julia del Carmen Olivares Nadal * * This file contains all the methods inherited from * the DefaultHandler class, which the information * collected by parsing the document is stored in a * vector for a later statistical study. */ import org.xml.sax.*; import org.xml.sax.helpers.*; import java.util.*; /*********************** * Handler class ***********************/ public class Handler extends DefaultHandler{ public static MyStack stack = new MyStack(); public static TypesVector typesVector = new TypesVector (); public static int numChildren =0; public int numNodes =0; public static int totalNumNodes =0; public float totalNumChildren =0; public static int maxLevels=0; public float procent=0; // SAX calls this method when it encounters an element public void startElement(String namespaceURI, String localName, String qualifiedName, Attributes att) throws SAXException { int index; int nodeLevel; //General information //With the next line it is possible to check how works SAX. //System.out.println("startElement: " + qualifiedName); StackObject element = new StackObject (qualifiedName); stack.pushElement(element); nodeLevel=stack.size(); maxLevels=(stack.size()>maxLevels)?nodeLevel:maxLevels; //Information pro type index=typesVector.contains(qualifiedName); if(index!=-1){//Is not the first element of this type int indexLevelVector; ((TypesVectorObject)typesVector.get(index)).numElem++;//Another element more of this type //Update the LevelVector //Find out if there is more nodes of this type in this level
indexLevelVector= ((TypesVectorObject)typesVector.get(index)).levelVector.levelExists(nodeLevel); //There are more nodes of this types in this level.
77
if(indexLevelVector!=-1){ ((TypesVectorObject)typesVector.get(index)).levelVector.getLevelObject(indexLevelVector).num++; } else{//this is the first node of this type in this level. int insertIn; LevelObject newLevel=new LevelObject(nodeLevel); insertIn= ((TypesVectorObject)typesVector.get(index)).levelVector.whereToInsert(nodeLevel); if(insertIn!=-1){ ((TypesVectorObject)typesVector.get(index)).levelVector.add(insertIn,newLevel); } else //insert the object at the end of the vector ((TypesVectorObject)typesVector.get(index)).levelVector.addElement(newLevel); }//end else }//end if is not the first element of this type. else{//is the first element of this type found. //A new TypesVectorObject must be created,whose name will be the name of this element type. TypesVectorObject newType = new TypesVectorObject (qualifiedName); //Insert the new type at the end of the typesVector. newType.vectorPosition=typesVector.add(newType); //The level must be also updated. LevelObject newLevel=new LevelObject(nodeLevel); ((TypesVectorObject)typesVector.lastElement()).levelVector.add(0,newLevel); }//end if is the first element of this type found. }//end function startElement // SAX calls this method when it encounters an end tag. //If the node is not a leaf node,the number of nodes //must be increased and the number of children of //the parent node must also be increased. public void endElement(String namespaceURI, String localName, String qualifiedName) throws SAXException,EmptyStackException { //To observe how SAX works //System.out.println("endElement: /" + qualifiedName); //Pop the element and increase the number of nodes. StackObject poppedElement =stack.popElement(); totalNumNodes++; //the leaves must not be taken into account if(poppedElement.children!=0){ numNodes++; totalNumChildren +=poppedElement.children; } if(stack.empty()!=true){ StackObject parentNode =stack.peekElement(); parentNode.children++;//general count. //Pick out the name of the parent node and increase the //number of children of this type. int index=typesVector.contains(parentNode.name); //it is supposed that the type must be found,so index can´t be -1.
78
((TypesVectorObject)typesVector.get(index)).numChildren++; } } //When the document is over,the average values are calculated //and the information is displayed. public void endDocument()throws SAXException { System.out.println("Total number of nodes without leaves: "+numNodes); System.out.println("Total number of children: "+totalNumChildren); System.out.println("Average number of children pro node: " +totalNumChildren/numNodes); System.out.println("Maximal depth: "+maxLevels); System.out.println("Number of different types: "+typesVector.size()); for(int i=0;i<typesVector.size();i++){ System.out.println("Type: " +((TypesVectorObject)typesVector.get(i)).typeName); System.out.println("There are " +((TypesVectorObject)typesVector.get(i)).numElem+" nodes of this type"); System.out.println("That is the " +(float)((TypesVectorObject)typesVector.get(i)).numElem/totalNumNodes*100+"% of the total number of nodes."); procent+=(float)((TypesVectorObject)typesVector.get(i)).numElem/totalNumNodes*100; System.out.println("Average number of children pro node of this type: "+(float)((TypesVectorObject)typesVector.get(i)).numChildren/((TypesVectorObject)typesVector.get(i)).numElem); System.out.println("Distribution pro level: "); for(int j=0;j<((TypesVectorObject)typesVector.get(i)).levelVector.size();j++){ System.out.println("At level " +((TypesVectorObject)typesVector.get(i)).levelVector.getLevelObject(j).level+" there are "+((TypesVectorObject)typesVector.get(i)).levelVector.getLevelObject(j).num+" elements of this type."); }//End inner for }//End external for System.out.println("total%= "+procent); } } /***************************** * StackObject class *****************************/ //The class Stack stores objects from the class Object //I define a new type of object to be stored in the stack. class StackObject extends Object { String name; //Name of these type of node. int children; //Number of children. StackObject(){ name=""; children=0; } StackObject (String qName){ name=qName; children=0; } }
79
/***************************** * MyStack class *****************************/ //I´ve created a new class based on the methods //of Stack but taking into account the new properties //of StackObject. class MyStack extends Stack { MyStack(){ super(); } //Take out the last element of the stack public StackObject popElement () throws EmptyStackException{ StackObject poppedObject = new StackObject(); poppedObject=(StackObject)super.pop(); return poppedObject; } //Introduce a new element on the stack public StackObject pushElement (StackObject item){ StackObject pushedObject = new StackObject(); pushedObject=(StackObject)super.push(item); return pushedObject; } //return the last element of the stack without extracting it. public StackObject peekElement() throws EmptyStackException{ StackObject peekedObject = new StackObject(); peekedObject=(StackObject)super.peek(); return peekedObject; } } /***************************** * LevelObject class *****************************/ //Class to store the information of the level and number of nodes pro type class LevelObject extends Object{ int num; int level; LevelObject(int niveau){ num=1; level=niveau; } } /***************************** * LevelVector class *****************************/ //A Vector to store the different LevelObjects class LevelVector extends Vector{ LevelVector ()throws IllegalArgumentException { super(2,1); } LevelVector(int initialCapacity,int increment)throws IllegalArgumentException{ super(initialCapacity,increment); }
80
//This function run through the LevelVector looking for the existence of this //level and return the position in the vector if exists or -1 if not. public int levelExists(int niveau)throws ArrayIndexOutOfBoundsException{ boolean found=false; int comparation; int position=-1; for(int i=0;i<this.size();i++){ if(((LevelObject)this.get(i)).level==niveau) { position=i; found=true; }// end if }// end for position=(found)?position:-1; return position; }//end levelExists function public LevelObject getLevelObject(int i){ return (LevelObject)super.get(i); } //To have an order in the vector of levels, //this function is called to obtain the index of the vector //in which the updates must be done. //This return the index if the level exists or -1 when //a new object must be stored at the last position of the vector. public int whereToInsert(int nodeLevel){ int answer=0; int copy=0; boolean found=false; if(this.isEmpty()==false){ do{ for(int i=0;i<this.size();i++){ copy=i; if(nodeLevel<this.getLevelObject(i).level) { answer=i; found=true; }//end if }//end for if((copy==this.size()-1)&&(!found)){ found=true; answer=-1; } }while((!found)); } else answer=-1; return answer; }//end whereToInsert function. } /***************************** * TypesVectorObject class *****************************/ //I´ve created this object in order to store all the relevant information //of every type in the document.
81
class TypesVectorObject extends Object { String typeName; int vectorPosition; int numElem; int numChildren; boolean chose; LevelVector levelVector; TypesVectorObject(String name){ typeName=name; vectorPosition=-1; numElem=1;//When I create a new element of this type ist because I have found the first element. numChildren=0; chose=false; levelVector=new LevelVector(); } } /***************************** * TypesVector class *****************************/ //A vector of TypesVectorObjects class TypesVector extends Vector{ TypesVector ()throws IllegalArgumentException { super(2,1); } TypesVector (int initialCapacity,int increment)throws IllegalArgumentException { super(initialCapacity,increment); } //Compare the name of the new Type to the others existing types //and return the position in the vector if exists or -1 if not public int contains(String elem)throws ArrayIndexOutOfBoundsException{ boolean found=false; int comparation; int position=-1; for(int i=0;i<this.size();i++){ comparation=elem.compareTo(((TypesVectorObject)this.get(i)).typeName); if(comparation==0){ position=i; found=true; }// end if }// end for position=(found)?position:-1; return position; }//end contains function public int add(TypesVectorObject elem){ int position; super.addElement(elem); position=this.size()-1; return position; } }// end class TypesVector
82
XMLModifier /* * Created on 12.05.2004 */ /** * @author Julia del Carmen Olivares Nadal * * This program takes an XML document and introduce changes on it * according to 3 parameters, resulting a new XML document. */ import java.io.*; import java.util.*; import java.lang.Double; import org.xml.sax.*; import org.xml.sax.helpers.*; import javax.xml.parsers.SAXParserFactory; import javax.xml.parsers.SAXParser; public class XMLModifier extends DefaultHandler { public static double pbbChange; public static double pbbRemoval; public static double pbbDupMod; public static Double pbbCh; public static Double pbbRem; public static Double pbbDup; public static int numChanges=0; public static int numDupMods=0; public static int numRems=0; public static int numElems=0; public boolean ch; public boolean dup; public boolean rm; public boolean firstElement=true; public static RandomStack stack = new RandomStack(); AttributesImpl copy; static private Writer out; /*************************************** *Main function **************************************/ public static void main(String[] args)throws IOException { if (args.length != 5) { System.err.println("Usage: java XMLModifier inputfile outputfile pbbDuplication pbbChange pbbRemoval"); System.exit(1); } FileOutputStream fout; fout = new FileOutputStream ( args[1] ); //Transform the strings in double values. //It is necesssar to use intermediate Double variables. pbbDup=new Double(args[2]); pbbDupMod=pbbDup.doubleValue(); pbbCh=new Double(args[3]); pbbChange=pbbCh.doubleValue(); pbbRem=new Double(args[4]); pbbRemoval=pbbRem.doubleValue(); //Use an instance of ourselves as the SAX event handler DefaultHandler handler = new XMLModifier();
83
//Use the default (non-validating) parser SAXParserFactory factory = SAXParserFactory.newInstance(); try { //Set up output stream out = new OutputStreamWriter(fout, "UTF8"); //Parse the input SAXParser saxParser = factory.newSAXParser(); saxParser.parse( args[0], handler); } catch (Throwable t) { t.printStackTrace(); } System.exit(0); } /********************************************* * SAX DocumentHandler methods *********************************************/ //The documents starts. public void startDocument() throws SAXException { emit("<?xml version='1.0' encoding='UTF-8'?>"); nl(); } //the SAX parser calls this function when it founds the //last end tag public void endDocument() throws SAXException { try { nl(); out.flush(); } catch (IOException e) { throw new SAXException("I/O error", e); } System.out.println("numElems="+numElems); System.out.println("Number of duplicated elements="+numDupMods+" " +((float)numDupMods/numElems)*100+"%"); System.out.println("Number of changed elements="+numChanges+" " +((float)numChanges/numElems)*100+"%"); System.out.println("Number of removed elements="+numRems+" " +((float)numRems/numElems)*100+"%"); } //The SAX parser calls this function when an element starts. public void startElement(String namespaceURI, String lName, // local name String qName, // qualified name Attributes attrs) throws SAXException { numElems++; if(firstElement){ azar(); RandomProperties element = new RandomProperties (false,ch,false); firstElement=false; stack.pushElement(element); }else { azar(); RandomProperties element = new RandomProperties (dup,ch,rm); if(dup) numDupMods++;
84
if(ch) numChanges++; if(rm) numRems++; stack.pushElement(element); } if (stack.peekElement().duplicity) copy = new AttributesImpl(attrs); if(!(stack.peekElement().removal)) { String eName = lName; // element name if ("".equals(eName)) eName = qName; // namespaceAware = false if (stack.peekElement().change){ eName=modify(eName,"modification"); } emit("<"+eName); if (attrs != null) { for (int i = 0; i < attrs.getLength(); i++) { String aName = attrs.getLocalName(i); // Attr name if ("".equals(aName)) aName = attrs.getQName(i); emit(" "); emit(aName+"=\""+normalize(attrs.getValue(i))+"\""); } } emit(">"); } } //the SAx parser calls this function when the element finishes. public void endElement(String namespaceURI, String sName, // simple name String qName // qualified name ) throws SAXException { RandomProperties poppedElement =stack.popElement(); if(!(poppedElement.removal)){ if(poppedElement.change){ emit("</"+modify(qName,"modification")+">"); }else{ emit("</"+qName+">"); } } if(poppedElement.duplicity) { String eName = sName; // element name if ("".equals(eName)) eName = qName; // namespaceAware = false eName=modify(eName,"duplication"); emit("<"+eName); if (copy != null) { for (int i = 0; i < copy.getLength(); i++) { String aName = copy.getLocalName(i); // Attr name if ("".equals(aName)) aName =copy.getQName(i); emit(" "); emit(aName+"=\""+normalize(copy.getValue(i))+"\""); } copy.clear(); } emit(">"); emit("</"+modify(qName,"duplication")+">"); } } public void characters(char buf[], int offset, int len) throws SAXException { if(!(stack.peekElement().removal)){ String s = new String(buf, offset, len); emit(normalize(s));
85
} } //The SAX parser calls this function when it finds //a processing instruction. public void processingInstruction(String target, String data) throws SAXException{ emit("<?"); emit(target); if (data != null && data.length() > 0) { String space=new String(); space=" "; emit(space); emit(data); } emit("?>"); } // processingInstruction(String,String) /******************************* * Utility Methods *******************************/ //Normalizes the strings to obtain canonical XML documents. protected String normalize(String s) { StringBuffer str = new StringBuffer(); int len = (s != null) ? s.length() : 0; for (int i = 0; i < len; i++) { char ch = s.charAt(i); switch (ch) { case '<': { str.append("<"); break; } case '>': { str.append(">"); break; } case '&': { str.append("&"); break; } case '"': { str.append("""); break; } case '\'': { str.append("'"); break; } case '\r': case '\n': { str.append("&#"); str.append(Integer.toString(ch)); str.append(';'); break; } default: { str.append(ch); } } }
86
return str.toString(); } // normalize(String):String //Outputs SAX events in the Writer out. private void emit(String s) throws SAXException { try { out.write(s); out.flush(); } catch (IOException e) { throw new SAXException("I/O error", e); } } //Starts a new line private void nl() throws SAXException { String lineEnd = System.getProperty("line.separator"); try { out.write(lineEnd); } catch (IOException e) { throw new SAXException("I/O error", e); } } //Modifies element´s name depending on if there´s only //a modification or duplication. public String modify(String typeName,String modType){ if(modType.equals("modification")) typeName=typeName.concat("kkkkk"); if(modType.equals("duplication")) typeName=typeName.concat("zzzzz"); return typeName; } //Creates an empty node, which is a duplicate of the original element but modified. public void duplicate(String lName,String qName,Attributes attrs)throws SAXException{ String eName = lName; // element name if ("".equals(eName)) eName = qName; // namespaceAware = false eName=modify(eName,"duplication"); emit("<"+eName); if (attrs != null) { for (int i = 0; i < attrs.getLength(); i++) { String aName = attrs.getLocalName(i); // Attr name if ("".equals(aName)) aName = attrs.getQName(i); emit(" "); emit(aName+"=\""+normalize(attrs.getValue(i))+"\""); } } emit(">"); emit("</"+eName+">"); } //Implements an easy way to randomly obtain //the flags to remove,duplicate or remove //the element depending on the value of //probability parameters. public void azar(){
87
ch=(Math.random()<pbbChange)?true:false; dup=(Math.random()<pbbDupMod)?true:false; rm=(Math.random()<pbbRemoval)?true:false; } } /******************************************** * RandomProperties class *******************************************/ //Creates a new object to store the values of //the prameters for every element. class RandomProperties extends Object { public boolean duplicity; public boolean change; public boolean removal; RandomProperties(){ duplicity=false; change=false; removal=false; } RandomProperties(boolean dup,boolean ch,boolean rm){ duplicity=dup; change=ch; removal=rm; } } /******************************************** * RandomStack class *******************************************/ //It is necessary to create a stack with RandomProperties objects //to have an accurate knowledge of what element is active at the moment. class RandomStack extends Stack { RandomStack(){ super(); } //Pops an element. public RandomProperties popElement () throws EmptyStackException{ RandomProperties poppedObject = new RandomProperties(); poppedObject=(RandomProperties)super.pop(); return poppedObject; } //Pushes an element. public RandomProperties pushElement (RandomProperties item){ RandomProperties pushedObject = new RandomProperties(); pushedObject=(RandomProperties)super.push(item); return pushedObject; } //Returns the last element without removing it. public RandomProperties peekElement() throws EmptyStackException{ RandomProperties peekedObject = new RandomProperties();
88
peekedObject=(RandomProperties)super.peek(); return peekedObject; } }
89
Índice de figuras y tablas Fig.1 El analizador SAX.....................................................................................................27 Fig.2 El analizador DOM ...................................................................................................31 Fig.3 Ventana de inicio.......................................................................................................37 Fig.4 Barra de menú ...........................................................................................................37 Fig.5 Barra de herramientas................................................................................................37 Fig.6 Página de bienvenida.................................................................................................38 Fig.7 Selección para crear un nuevo proyecto....................................................................38 Fig.8 Dar nombre al proyecto.............................................................................................39 Fig.9 Crear directorios........................................................................................................40 Fig.10 Perspectiva Java ........................................................................................................40 Fig.11 Seleccionar perspectiva .............................................................................................41 Fig.12 Árbol de directorios...................................................................................................41 Fig.13 Menús contextuales ...................................................................................................42 Fig.14 Crear un paquete........................................................................................................42 Fig.15 Crear una clase ..........................................................................................................43 Fig.16 Pantalla para crear una clase .....................................................................................44 Fig.17 Seleccionar una superclase........................................................................................44 Fig.18 Implementar una interfaz ..........................................................................................45 Fig.19 Clase creada...............................................................................................................45 Fig.20 Perspectiva Java Browsing........................................................................................46 Fig.21 Ejecutar una aplicación Java .....................................................................................47 Fig.22 Resultado de la ejecución..........................................................................................47 Fig.23 Depurar una aplicación Java .....................................................................................48 Fig.24 Perspectiva de depuración.........................................................................................48 Fig.25 Breakpoint .................................................................................................................49 Fig.26 Botones de acción en la vista Debug.........................................................................49 Fig.27 MyStack y un parser SAX.........................................................................................52 Fig.28 TypesVectorObject....................................................................................................54 Fig.29 Análisis del efecto de pbbChosenNodes ...................................................................64 Fig.30 Alfa y Beta ................................................................................................................65 Fig.31 Efecto de la duplicación de nodos en la similitud.....................................................67 Fig.32 Efecto de la modificación del nombre del nodo en la similitud................................69 Fig.33 Efecto de la eliminación de nodos en la similitud.....................................................69 Tabla I Comparativa entre SAX y DOM...............................................................................33
90
Bibliografía y referencias [1] Mining Database Structure; Or, How to Build a Data Quality
Browser,Tamraparni Dasu, Theodore Johnson, S.Muthukrishnan, Vladislav Shkapenyuk, AT&T Labs-Research.
[2] Tree-to-tree correction problem, K.C. Tai, Journal of the ACM, 26:422-433, 1979.
[3] Approximate XML Joins, S. Guha, H.V. Jagadish, N. Koudas, D. Srivastava, Ting Yu, AT&T Labs-Research, University of Pennsylvania, University of Michigan, University of Illinois.
[4] Evaluating Structural Similarity in XML Documents, Andrew Nierman, H. V. Jagadish, University of Michigan.
[5] Detecting Changes in XML Documents, Grégory Cobéna, Serge Abiteboul, Amélie Marian, INRIA, (Rocquecourt France), Columbia University (U.S.A).
[6] A Tree-based Approach to Clustering XML Documents by Structure, G.Costa, G.Manco, R.Ortale, A.Tagarelli, Instituto di Calcolo e Reti ad Alte Prestazione, ICAR-CNR, Sede di Cosenza, Università degli Studi della Calabria, DEIS.
[7] Detecting Structural Similarities between XML Documents, S.Flesca, G.Manco, E.Masciari, L.Pontieri, A. Pugliese, DEIS, University of Calabria, ISI-CNR.
Programación en castellano (tutoriales sobre XML y eclipse): http://www.programacion.com/java Sun Microsystems, APIS Java: http://java.sun.com/j2se/1.4.2/docs/api W3C Group: http://www.w3.org The Eclipse Project: http://eclipse.org The Apache XML Project: http://xml.apache.org Galileo Computing (Para la documentación en alemán): http://www.galileocomputing.de/openbook/javainsel3/javainsel_130002.htm Diccionario de la real academia de la lengua española: http://www.rae.es Diccionario español-inglés: http://www.wordreference.com Diccionario español-alemán: http://pauker.at/deutsch/W%F6rterb%FCcher/Spanisch.html/ Diccionario alemán-inglés: http://www.leo.org/
ANEXO: PROYECTO ORIGINAL EN ALEMÁN
Fakultät Informatik
Institut Systemarchitektur Lehrstuhl für Datenbanken
Diplomarbeit
Strukturelle Ähnlichkeitsmessung
von XML Dokumenten
Bearbeiter: Julia del Carmen Olivares Nadal Betreuer: Prof. Dr.-Ing. Wolfgang Lehner
Abgabe: 28 Juli 2004
1
Inhaltsverzeichnis 1 Einleitung ..........................................................................................................................3 2 Anwendung .......................................................................................................................4
2.1 Data Cleansing............................................................................................................4 2.2 Knowledge Discovery ................................................................................................5 2.3 Informationsintegration ..............................................................................................5 2.4 E-Business ..................................................................................................................6 2.5 Search Engines ...........................................................................................................7 2.6 Web-Publishing ..........................................................................................................7
3 Theoretische Vorbetrachtungen......................................................................................9 3.1 Ähnlichkeit in der relationalen Datenbanken .............................................................9 3.2 Ähnlichkeit zwischen XML Dokumenten................................................................10
3.2.1 Baumstrukturbasierte Methoden ....................................................................10 3.2.2 Ereignisbasierte Methoden ...............................................................................12
3.3 Zusammenfassung ....................................................................................................13 4 Praktische Vorbetrachtung ..........................................................................................14
4.1 Das JAXP API..........................................................................................................14 4.2 SAX ..........................................................................................................................15 4.3 DOM.........................................................................................................................19
5 Experimentelle Lösungen ..............................................................................................23 5.1 Realisierung struktureller Ähnlichkeitssuche...........................................................23
5.1.1 Handler.java......................................................................................................23 5.1.1.1 Klasse Handler........................................................................................23 5.1.1.2 Klassen StackObject und MyStack ........................................................24 5.1.1.3 Klassen TypesVector und TypesVectorObject.......................................25 5.1.1.4 Klassen LevelVector und LevelObject...................................................25
5.1.2 XMLStructuralSimilarity.java..........................................................................27 5.1.2.1 Das Analysieren eines XML Dokuments ...............................................27 5.1.2.2 Bestimmung von Ähnlichkeiten .............................................................27 5.2 Änderung eines XML Dokuments............................................................................28
5.2.1. Die Funktionsweise des Programms ................................................................28 5.2.1.1 Änderung ................................................................................................28 5.2.1.2 Duplikation .............................................................................................29 5.2.1.3 Löschen...................................................................................................29
5.2.2 Klassen RandomProperties und RandomStack ................................................29 5.2.3 Das Schreiben eines XML Dokuments ............................................................30
5.2.3.1 Normalisieren .........................................................................................30 5.2.3.2 Das Formatieren der Ausgabe ................................................................30 5.2.3.3 Das Konfigurieren der I/O......................................................................30
5.2.4 Zusammenfassung ............................................................................................31 6 Experimente ....................................................................................................................32
6.1 Szenarien ..................................................................................................................32 6.2 Experiment 1 ............................................................................................................32
6.3 Experiment 2 ............................................................................................................33 6.4 Experiment 3 ............................................................................................................34
6.4.1 pbbDuplication .................................................................................................35 6.4.2 pbbChange........................................................................................................36 6.4.2 pbbRemoval......................................................................................................36
2
6.5 Zusammenfassung ....................................................................................................37 7 Zusammenfassung und Ausblick ..................................................................................38 Abbildungverzeichnis.............................................................................................................39 Literaturverzeichnis ...............................................................................................................40
3
Kapitel 1
Einleitung
Die XML Sprache (EXtensible Mark-up Language) wurde in weiten Kreisen als Datenaustauschstandard der Zukunft anerkannt, besonders wegen der Möglichkeit, Daten aus unterschiedlichen Quellen darzustellen. Es treten aber auch Integrationsprobleme auf, wenn Daten aus verschiedenen und heterogenen Quellen kombiniert werden.
Wenn eine Beziehung zwischen zwei XML Dokumenten gesetzt ist, muss man die damit auftretenden neuen Komplexitäten in der Dokumentenstruktur beachten. In relationalen Datenbanken sind die Tupel atomare Objekte, und die Ähnlichkeit zwischen Tupelwerten kann mit Zahlenwerten oder einem anderen Typ berechnet werden. In der XML Welt ist die Struktur eines XML Dokumentes ein Baum, in dem die Berechnung der Strukturenähnlichkeit nicht einfach ist. Wenn verschiedene Dokumente die selbe DTD (Document Type Definition) haben, müssen die daraus resultierenden Dokumente nicht die gleiche Baumstruktur besitzen, weil es im DTD die Möglichkeit von optionalen Elementen und Attributen gibt. Weiterhin gibt es viele Dokumente, ins besondere solche, die von HTML generiert wurden und keine DTD besitzen. Damit ist es notwendig, neue Methoden zu entwickeln, mit denen man die Ähnlichkeit zweier Dokumente berechnen kann. In gro�en Datenbanken können sehr verschiedene XML Daten gespeichert sein. Damit ein Join optimiert werden kann, es ist nötig zu wissen, wie ähnlich ein XML Dokument mit einem anderen ist. Alle diese Kenntnis macht, dass man die Reichweite der Abfrage vergrö�ern kann.
In dieser Diplomarbeit wird eine neue Methode vorgestellt, mit der die Ähnlichkeit zwischen XML Dokumente einfach berechnet werden kann, wenn man dafür den SAX Parser benutzt. Die gelieferte Information des Programms kann sehr wichtig sein, um eine erste Filterung der XML Dokumente zu machen oder die Struktur einer XML Datenbank festzustellen. Weiterhin gibt es ein kleines Modul, mit dem unterschiedliche Änderungen, gemäß Parameterwerten, in einem XML Dokument durchgeführt werden. Dieses Modul bietet die Möglichkeit, ein Dokument mit einer bestimmten Ähnlichkeit zu einem Basisdokument herzustellen. Dieser Modul wurde an vielen Experimenten getestet, um die Genauigkeit zu überprüfen und damit die optimalen Werte der Parameter festzustellen. In den folgenden Kapiteln wird erklärt, wie das Programm funktioniert, die gemachte Experimente,...etc. Diese Diplomarbeit fängt mit einer Erklärung der möglichen Anwendungen an , die für diese Arbeit nützlich sind. Im nächsten Kapitel werden theoretische Aspekte und Konzepte vorgestellt, auf denen diese Arbeit basiert. Danach, im Kapitel 4, kann man eine praktische Umsetzung finden. Es werden die wichtigsten Aspekte des Programms erläutert und wie sie konzipiert wurden. Im Kapitel 5 befinden sich die verschiedenen ausgeführten Experimente mit ihren Lösungen. Die Arbeit endet mit einer Zusammenfassung der wesentlichsten Punkte und Anhängen mit Extrainformationen.
4
Kapitel 2 Anwendung
XML steht für Extensible Markup Language und bezeichnet ein Dokumentenformat zur Darstellung semistrukturierter Daten. XML genießt zweifellos gegenwärtig eine große Popularität. Die Anwendungen sind vielfältig und reichen vom Zwischenformat zur Datenrepräsentation oder zum Datenaustausch bis hin zur Markup Sprache für Volltextdokumente. Datenbanken hingegen sind eine seit Jahrzehnten bewährte Technologie zur Speicherung und Anfrage von großen strukturierten Datenbeständen.
Aber gegenwärtig wird XML nicht nur in den Bereich der Datenbanken benutzt, sondern auch in jeder Lage wo ein Informationsaustausch existiert. Tatsächlich werden fast alle Web Anwendungen die Daten ins XML Format übersetzt. So ergeben sich viele die mögliche Anwendungen, die einen Vergleich zwischen XML Dokumenten brauchen.
2.1 Data Cleansing
Relationale Daten stellen nur einen kleinen Teil von den aktuellen Daten dar, in der Tat bekommt XML jedes Mal eine grö�ere Popularität für Datendarstellung, besonders für Daten ins World Wide Web und für den Datenaustausch zwischen Organisationen. XML spielt auch ein sehr wichtige Rolle in der Welt der Datenbanken. Viele kommerzielle Datenbankensysteme (Oracle, IBM DB2...) vermitteln Tools, um Information in XML darzustellen und XML Daten zu speichern, außerdem sind schon viele die Datenbanken, die um XML Dokumenten zu speichern entwerfet sind, die native XML Datenbanken.
Aufgrund dieser neuen Entwicklungen der XML Technologien benötigt man Methoden, die auf der XML Struktur beruhen, um ein effizientes data-cleansing in den XML Datenbanken herzustellen. Data-cleansing enthalt viele verschiedene Aspekte wie die Ermittlung von Duplikaten oder das Suchen von JoinPfaden, wo das Wissen über die Ähnlichkeit zwischen XML Dokumenten sehr wichtig ist. Das Problem von duplikate Entities, die das selbe Objekt beschreiben, ist eine wichtige data-cleansing Aufgabe, um die Datenqualität zu verbessern. Ein Problem ist die a priori undefinierte XML Elementstruktur innerhalb eines Dokumentes. In einer relationalen Datenbank heben die Tupeln in einer einfachen Relation die gleiche und definierte Struktur. Aber XML Elemente, die den gleichen Elementtyp beschreiben, können verschiedene Strukturen haben. Dieses Problem kann man auch in verschiedene Felder im data-cleansing finden. Aktuelle Algorithmen sind normalerweise für relationale Daten entwickelt, aber es gibt viele Methoden, die noch nicht für XML Technologien ausgereift sind, obwohl die XML Daten im Moment eine gro�e Rolle spielen.
5
2.2 Knowledge Discovery Knowledge Discovery ist eine softwarebasierte Analysemethode, die potenziell nützliches Wissen aus strukturierten Datensätzen herausfiltert. Das Ziel des „Knowledge Discovery“ ist das Entdecken versteckter, multidimensionaler und nicht-linearer Zusammenhänge in großen Datenbeständen, die nicht selten in einem unternehmensweiten Data Warehouse organisiert sind. Ein Teilschritt im KDD (knowledge Discovery in Databases)-Prozess ist das Data Mining, eine spezielle Form davon ist das Clustering. Ziel von Clusteringverfahren ist es, Daten (semi-)automatisch so in Kategorien einzuteilen, dass Objekte im gleichen Cluster möglichst ähnlich und Objekte aus verschiedenen Clustern möglichst unähnlich zueinander sind. XML Dokumente im Web werden normalerweise ohne DTD gefunden, besonders wenn sie aus HTML kommen. Die Kenntnis der DTD ist aber wichtig, um diese Dokumente abzufragen und zu manipulieren. Aktuelle Arbeiten beinhalten Algorithmen, um eine DTD, die die Struktur einer Menge von XML Dokumenten beschreibt, zu (re-)konstruieren. Bei einer Menge von XML Dokumenten mit unbekannter DTD ist es nicht sinnvoll, jeweils eine einzelne DTD für jedes Dokument zu konstruieren. Vielmehr wird die Menge der XML Dokumente in kleinere Sets mit ähnlichen Dokumenten geteilt und nur eine DTD für jedes Set erstellt. Mit einer DTD kann nun auf kleinere Teile der Datenmenge zugegriffen, damit eine größere Effizienz erreicht und die Anfragen optimiert werden. Um diese Sets mit ähnliche Merkmalen zu finden, benötigt man Methoden, die die Ähnlichkeit zwischen XML Dokumente schätzen.
2.3 Informationsintegration Informationsintegration ist die korrekte, vollständige und effiziente Zusammenführung von Inhalten verschiedener, heterogener Quellen zu einer einheitlichen und strukturierten Informationsmenge, die der effektiven Interpretation durch den Nutzer dient. Die Informationsintegrationstechnologie ermöglicht den integrierten Echtzeitzugriff auf herkömmliche und neue Datenquellen, bereitet Daten für Analysten auf und organisiert Datenbestände unter dem Aspekt der Leistung, der Aktualität und der Verfügbarkeit. Dies ermöglicht wiederum den schnellen, einheitlichen und einfachen Zugriff auf e-business-Systeme, mit denen der Endkunde direkt interagiert. Mit der extensible Markup Language (XML) wird ein möglicher Ansatz der Datenintegration speziell für das Web beschrieben. Durch den Dokumentenstandard können Merkmale definiert werden, mit denen die unterschiedlichen Daten strukturiert und in Form von Dokumenten zusammengefasst werden können. XML geht dabei richtigerweise bereits von der Trennung von Inhalt, Struktur und Layout eines Dokuments aus. Das Zusammenführen nützlicher Informationen wird darüber hinaus durch die Tatsache kompliziert, dass die wachsenden Datenbestände aus einer Vielzahl unterschiedlicher Informationsquellen stammen. Unternehmen müssen nicht nur auf herkömmliche Anwendungsquellen (relationale Datenbanken), sondern auch auf XML Dokumente, einfache Textdateien, eingescannte Bilder, Videoclips, Live-Nachrichten, Webcontent, E-Mails, multidimensionale Datenbestände und Spezialspeichersysteme (interne wie externe Systeme) zugreifen können. Aufgrund struktureller und betriebsbedingter Einschränkungen lassen sich heterogene und verteilte Quellen in der Regel nicht vollständig replizieren oder in einer einzigen Datenbank konsolidieren.
6
Doch durch die Zusammenführung und Korrelation von Daten können versteckte Informationen gefunden werden.
Wenn die Heterogenität von XML Quellen größer wird, besteht die anspruchvolle Notwendigkeit, XML Dokumente mit strukturellen Merkmale zu organisieren. Wie besagt, dieses Problem hat interessante Anwendungen für das Management von Web Daten. Das Finden von strukturellen Ähnlichkeiten zwischen Dokumenten kann helfen, das Problem verschiedener Quellen, die den gleichen Informationstyp haben, zu erkennen. Damit kann query processing in semistructured data von der neuen Dokumentenordnung, gemäß ihrer Struktur profitieren. Semistrukturierte Dokumente nach struktureller Homogenität zu gruppieren hilft, neue Indextechniken für diese Dokumente zu entwickeln und damit die Abfrageplanungen zu optimieren.
2.4 E-Business
E-Business ist das Schlagwort, das heute durch alle Medien geistert. Ob Wirtschaftspresse, Online-Medien oder Fachpublikationen: Alle berichten darüber - und viel zu oft wird das Thema auf den Aspekt eCommerce und Shopping-Systeme eingeengt. Sicher spielen sie einen wichtigen Part für bestimmte eBusiness-Anwendungen. Es gibt daneben jedoch wichtige Kernthemen, die abgedeckt werden müssen, um erfolgreiche eBusiness-Anwendungen zu etablieren – hier geht es vor allem um Inhalte und Prozesse.
Das Internet hat die Art und Weise, wie Unternehmen mit Kunden, Mitarbeitern und Geschäftspartnern kommunizieren, ein für allemal verändert. Nach wie vor werden Informationen zwar mit Tönen, Bildern und dem geschriebenen Wort kommuniziert, doch werden diese Informationen in der digitalen Ökonomie schneller als je zuvor verändert und wiederverwandt. Informationen werden im Internet auf Web Sites präsentiert und aktualisiert. Jedoch nähern sich die Zeiten, in denen Web Sites nur ein anderes buntes Schaufenster zur Produkt- und Firmenpräsentation sind, unaufhaltsam dem Ende. Ein immer größerer Teil der Informationen, die via Web eingegeben oder per eMail ausgetauscht werden, sind geschäftsrelevant. Derlei neuen Anforderungen müssen Unternehmen gerecht werden, nicht nur, um im Wettbewerb zu bestehen, sondern auch aus vertraglichen, finanziellen und auch rechtlichen Gründen.
Die Entwickler von solchen Online-Shops stellt das jedoch vor etliche Probleme. Da in einem Online-Shop alle Arten von Waren und hunderte von Artikeln angeboten werden sollen, kann dieses Angebot nicht über ganz normale HTML-Seiten realisiert werden. Das Bestreben hunderte von HTML-Seiten zu warten, Preise zu aktualisieren und neue Angebote in einen Shop zu integrieren, ist für Menschen nur mit immensen Personaleinsatz, wenn überhaupt, zu realisieren. Hier sind automatisierte Techniken gefragt, welche diese Arbeit dem Webdesigner ersparen.
Eine Möglichkeit hierfür stellt XML dar. Mittels XML lassen sich Daten, wie einzelne Produkte, nähere Beschreibungen zu dem Produkt, sein Preis, seine Verfügbarkeit und ähnliches, strukturiert erfassen. Im Internet existieren bereits etliche Editoren, die es dem Webdesigner ermöglichen, seine XML Dokumente auf recht bequeme Art zu verwalten. XML ist in den meisten B2B-Szenarien (business-to-business) nichts weiter als ein Format für den Austausch von Geschäftsdaten. Prinzipiell könnte auch ein anderes Format an diese Stelle treten. Durch die Möglichkeit, eigene DTDs (oder Schemata) zu definieren, bietet XML aber etwas Besonderes. Sie können mit XML eine eigene Sprache für Ihre Business-Applikationen
7
kreieren. Damit wird XML zu einem kleinen, aber sehr wichtigen Rädchen in den Geschäftsabläufen.
Es ist klar, dass XML eine gro�e Rolle im e-Business spielt. Der Datenaustausch im e-commerce Anwendungen wie B2B Informationsaustausch ist meistens mit XML Dokumenten gemacht. In diesen Szenario braucht man effizienten Methoden, um diese Dokumente durchzuführen. Die Strukturähnlichkeit zwischen Dokumente kann aufzeigen, welches Produkt beschrieben wird oder von welcher Firma es ist, so können Methoden, die die Ähnlichkeit zwischen XML Dokumente bestimmen, sehr nützlich sein.
2.5 Search Engines Eine Suchmaschine ist ein Programm zur Recherche von Dokumenten, die in einem Computer oder einem Computernetzwerk wie z.B. dem World Wide Web gespeichert sind. Nach Eingabe einer Suchanfrage liefert eine Suchmaschine eine Liste von Verweisen auf relevante Dokumente oder Webseiten, meist dargestellt mit Titel und einem kurzen Auszug des jeweiligen Dokuments. Die Darstellung der Suchergebnisse geschieht sortiert nach Relevanz, wofür jede Suchmaschine ihre eigenen, geheimen Kriterien heranzieht. Das können z.B. Häufigkeit und Stellung der Suchbegriffe im jeweiligen gefundenen Dokument, die Einstufung und Anzahl der zitierten Seiten, sowie die Häufigkeit von Verweisen anderer Dokumente auf das im Suchergebnis enthaltene Dokument sein. Gegenwärtig sind es mehr XML Dokumente, die sich im Web befinden, aber von manchen XML-Texten dürften Web-Surfer gar nichts merken, weil sie nur das in HTML gewandelte Ergebnis sehen. Suchmaschinen müssen neue Technologien benutzen, um mit XML Dokumenten zu arbeiten oder direkt XML-Suchmaschinen zu entwicklen. In den Suchmaschinen muss man Dokumente finden, die ähnliche Ergebnisse, gemä� die Suchanfrage, haben, so braucht man neue Methoden um Ähnlichkeit zwischen XML Dokumente zu schätzen.
2.6 Web-Publishing Das Internet ist aus einem kleinen Experiment einiger Naturwissenschaftler
entstanden und hat sich dank HTML zu einer der vermutlich größten Informationssammlungen der Welt entwickelt. Die Anzahl an Privatpersonen und Unternehmen, die dazu übergehen, geschäftliche Transaktionen über das Internet abzuwickeln, steigt. Mit dem Aufkommen dieses so genannten Electronic Business bzw. Electronic Commerce sind jedoch auch die Anforderungen an das Internet gestiegen. Es geht nicht mehr nur darum, Informationen auf Web-Seiten darzustellen, sondern beispielsweise die Kommunikation zwischen verschiedenen Niederlassungen eines Unternehmens, der Informationsaustausch über Finanztransaktionen und der Austausch medizinischer Daten zwischen Patienten, Krankenhäusern, Ärzten und Versicherungsgesellschaften. Die meisten dieser Anwendungen lassen sich mit HTML nicht realisieren; mittels XML hingegen sind sie umsetzbar. Der Einsatz von XML beim Web-Publishing ist ein großer Schritt in die Richtung, das Potenzial des Internets stärker auszuschöpfen. Die Akzeptanz von XML ist sehr groß. Besonders im Bereich des E-Commerce und der Schnittstellen kommt XML zum Einsatz, aber auch beim Web-Publishing.
Während die Informationen im Netz verbreitet werden, sind Web-Anwendungen nötig, die wichtige Neuigkeiten im Informationsstrom herausfinden und
8
dann zu möglichen interessierten Nutzern verbreiten. Das ist das in der Literatur so genannte Publication-Subscription. Es erfordert das existierte Zusammentreffen zwischen den Nutzerbestellungen (subscriptions) und den entdeckten Neuigkeiten im Informationsstrom (publications) zu bewachen. Mit dieser Anwendung, muss jetzt der Benutzer keine kostbare Zeit mehr für die Suche nach notwendigen Informationen verschwenden. Diese Informationen basieren jedes Mal mehr auf XML basiert, so ist es wichtig, das besagte Zusammentreffen herauszufinden und die Ähnlichkeit zwischen XML Dokumenten zu definieren und zu schätzen.
9
Kapitel 3 Theoretische Vorbetrachtungen Das Konzept der Ähnlichkeit kann in vielen Fällen definiert werden und es gibt viele Anwendungen, die es verwenden. Die Bereiche, in denen ähnliche Informationen eine wichtige Rolle spielen, sind viele und verschiedene, z.B. von genetischer oder chemischer Ähnlichkeit bis zur Strukturähnlichkeit in den Webseiten. In der Informatik kann man viele Informationen, wie man die Ähnlichkeit schätzen kann, finden und die möglichen Anwendungen, wie sie benutzt werden kann. In dieser Diplomarbeit wird eine Methode, um die Ähnlichkeit zwischen XML Dokumenten zu schätzen, präsentiert. Hier wird sich nur auf den Bereich der Informatik konzentriert. Es werden verschiedene Annäherungen an die Lösung des Problems der Schätzung der Ähnlichkeit vorgestellt. Die meisten von diesen werden unterschiedlichen Methoden sein, um XML Dokumente zu vergleichen, es wird aber auch eine Methode als Basis dieser Arbeit genommen, die das Konzept der Ähnlichkeit in den relationalen Datenbanken definiert.
3.1 Ähnlichkeit in den relationalen Datenbanken In relationalen Datenbanken ist die Ähnlichkeitsberechnung eine sehr wichtige Aufgabe in Data-cleanising, um die Struktur einer Datenbank zu kennen. Es ist im Rahmen einer Joinoperation wichtig zu wissen, ob eine Tabelle mit einer anderen Tabelle verbunden werden kann oder nicht. Weiterhin wird untersucht, ob eine Tabelle ganz verschiedener als die andere ist, um heterogene Information zu suchen. Die theoretische Definition der Ähnlichkeit zwischen Mengen wird erklärt in [1] und wurde benutzt als Basis für die Ähnlichkeitsschätzung zwischen XML Dokumenten, in denen eine Adaptation der relationalen Welt zur XML Welt durchgeführt wurde.
Gemäß [1] kann man die Ähnlichkeit zweier Menge A und B wie ρ=|A∩B| / |A∪B| definiert werden. Aber die Ähnlichkeit kann auch abhängig vom Konzept des Signatures beschrieben werden. Wenn U das Universum der Werte der Mengen A und B ist, und N={0,1,2...}, dann kann man die Signature wie s(A)=mina∈A(h(a)) schreiben, in dem h die Anwendung ist, die die Werte von U nimmt und sie zu N umformt. [1] behauptet, dass die Ähnlichkeit der Mengen wie die Wahrscheinlichkeit s(A)=s(B) ist. Sie ist ein Experiment, dass nur ja und nein bekommen kann. Dieses Experiment kann man wie eine Bernoulli Variable I: I[s(A)=s(B)] definieren. Das Problem ist, dass mit nur einer Stichprobe die Ergebnisse nicht richtig sein können. Um eine bessere Schätzung zu bekommen, kann man ein Stichprobenverfahren von N Samples durchführen: �
=
∧==
N
iii NBsAsI
1
/)]()([ρ , die eine binomiale Variable ist, weil die Summe
die Bernoulli Variablen berechnet. Jede Signature si(A) kann wie si(A)=mina∈A(hi(a)) definiert werden. Eine sehr interessante Berechnung der Ähnlichkeit, vorgestellt in [1], ist die zu wissen, welche Elemente in der Menge A und nicht in B sind und umgekehrt. Das wird repräsentiert mit �A/B und �B/A mit ||\|\ BABABA �=ρ . Wie zuvor mit � gezeigt, kann
10
man auch hier eine bessere Schätzung haben, wenn nicht nur eine Probe, sondern N Stichproben genommen werden. Das wird repräsentiert mit den folgenden Ausdrücken:
�=
∧<=
N
iiiBA NBsAsI
1\ /)()([ρ und �
=
∧>=
N
iiiAB NBsAsI
1
\ /)()([ρ . Es ist sehr wichtig zu wissen,
ob eine Menge in einer anderen enthalten ist, z.B. wenn ∧ρ und AB \
∧ρ groß sind, aber
BA \∧ρ klein ist, bedeutet es, dass A fast in B enthalten ist, aber B nicht in A.
3.2 Ähnlichkeit zwischen XML Dokumenten Wegen der Entwicklung der XML Technologie, gibt es viele neue Anwendungen, die XML benutzen. Die Schätzung der Ähnlichkeit zwischen XML Dokumenten ist im Moment eine sehr interessante und aktuelle Aufgabe für alle neuen XML Anwendungen. Deshalb existieren viele Artikel in der Literatur darüber, von den hier die wichtigsten und interessantesten vorgestellt werden. Im Grunde kann man die verschiedenen Methoden, um die Ähnlichkeit zu bestimmen, in zwei Gruppen teilen. Die eine Gruppe benutzt eine Baumstruktur nach DOM, die andere eine ereignisorientierte Lösung nach SAX. 3.2.1 Baumstrukturbasierte Methoden Die Methoden, die die Ähnlichkeit zwischen XML Dokumenten, basiert auf einer gespeicherten Baumstruktur, schätzen, vergleichen die Strukturen der Dokumente, um damit einen Grad von Ähnlichkeit zu liefern. Die Meisten benutzen das Konzept von Tree-edit-distance von [2], dass die Basis für die Berechnung der Ähnlichkeit darstellt. Es ist eine Verallgemeinerung der Entfernung zwischen Zeichenketten. Das wichtigste Problem ist, dass die Berechnung dieser Entfernung viel Zeit braucht. Um es zu lösen, suchen die verschiedenen Arbeiten unterschiedliche Methoden, um die verbrauchte Zeit zu reduzieren. Ein XML Dokument kann wie ein ordered und labeled Baum modelliert werden. Jeder Knoten des Baumes ist ein Element des Dokuments, wobei das Label den Elementtagnamen hat. Die Tree-edit-distance zwischen Bäumen ist die Anzahl von verwendeten edit Operationen, um eine Baumstruktur in eine andere umzuwandeln. Die definierten edit Operationen in [3,4] sind: einen Knoten einzufügen, einen Knoten zu löschen und einen Knoten umzubenennen. In [5] gibt es eine andere Operation, die wie eine edit Operation auftreten kann. Sie beinhaltet das Verschieben von Unterbäumen. [3] vermittelt, wie ähnlich zwei XML Documente sind, um Join Operationen zu entsprechen. Die Lösungsnäherung ist, die Berechnung der Entfernung nicht so teuer durchzuführen. Dabei bedient man sich der Idee von Ober- und Untergrenzen. die effizienter sind. Diese Grenzen können wie Filtern benutzt werden, um zu wissen, in welchen Dokumenten man die richtige Tree-edit distance anwenden muss. Um die Untergrenze zu bestimmen, sind folgende Konzepte zu erklären:
T ist ein ordered und labeled Baum, post(T) ist ein postorder traversal und pre(T) ist ein preorder traversal. Mit diesen Konzepten kann man drei Regeln aufstellen:
Wenn pre(T1) � pre(T2) oder post(T1) � post(T2), dann T1 � T2. Wenn die Bäume eine edit Entfernung von k haben, dann die maximale edit
Entfernung zwischen ihren postorder und preorder traversals ist wie maximal k.
11
Seien T1, T2 ordered und labeled Bäume und ed(a,b) die edit Entfernung zwischen a und b, dann max(ed(pre(T1),pre(T2)),ed(post(T1),post(T2)))�TDIST(T1, T2), in dem TDIST die Entfernung zwischen die Bäume T1 und T2 repräsentiert. Mit diesen Operationen kann man die Entfernung zwischen preorder traversal oder postorder traversal des Dokumentes bestimmen. Das ist gemä� 3) weniger oder gleich der Bäumentfernung und nicht zu aufwendig wie die Ermittelung der richtigen edit Entfernung. Wenn die Untergrenze größer als eine Schwelle � ist, kann man dieses Paar von Dokumenten unbesorgt wegschneiden, wenn nicht, dann braucht man den Wert für die Obergrenze. Wenn tn[im] der Knoten im Baum Tn ist und lca() der kleinste gemeinsame Stammvater der Funktion (lowest common ancestor function) ist, kann man die folgenden Regeln aufstellen.
t1[lca(t1[i1],t1[i2])] ist ein richtiger Stammvater von t1[i3] wenn t2[lca(t2[j1],t2[j2])] ein richtiger Stammvater von t2[j3] ist.
Es existiert einen O(n²) Algorithmus, mit dem die UBDIST Obergrenze zwischen einem Paar von Bäumen mit O(n) Knoten berechnen kann.
Für ein Paar von Bäumen T1, T2, TDIST(T1,T2)�UBDIST(T1,T2). Wenn UBDIST(T1,T2)�� ist, dann können beide Bäume mit einem Join verbunden werden ohne die Tree-edit-distance zu bestimmen. Dieser Weg ist einfacher als die Tree-edit-distance zu bestimmen. Wenn LBDIST(T1,T2)��< UBDIST(T1,T2), es ist nicht sicher, dass das Paar in die Schlusslösung enhalten ist. In diesem Fall muss die Tree-edit-distance berechnet werden. Eine unkompliziertene Näherung wird in [4] vorgestellt. Trotzdem wird auch die Tree-edit-distance benutzt. Dabei werden nicht nur edit Operationen wie Einfügen, Löschen und Umbennenen, andere Operationen auch wie edit Operationen aufgetretet: das Baumeinfügen und das Baumlöschen. Ein Konzept sind „erlaubten Operationen“. Die Regeln dafür sind wie folgt:
Ein Baum P darf nur einfügt werden, wenn P schon im Quellebaum A vorkommt. Ein Baum P darf nur gelösch werden, wenn P im Zielbaum B vorkommt.
In einem Baum dürfen keine zusätzlichen Knote eingefügt werden. Es dürfen auch kein Baum Baumlöschen gelöscht werden, wenn in diesem Baum schon Knoten gelöscht wurden. In [4] wird die Berechnung der Entfernung zwischen Bäumen in zwei Schritten durchgeführt. Im ersten Schritt werden von jedem Knoten v � B die Kosten berechnet. Darzu werden die ganze Kinderknoten von v einfügt. Die Summe ist d0. Die Kosten des Baumes von v werde in A einzufügen und ergeben die Summe d1. Das Kostenminimun ist entweder d0 oder d1. Eine andere Möglichkeit ist die Löschenoperation anstatt der Einfügenoperation. Im zweiten Schritt wird die Tree-edit-distance berechnet, aber nicht mit allen Knoten, sonder nur mit den Knoten der Ergebnisse vom ersten Schritt. In [5] wird versucht Änderungen in verschiedenen Versionen von einem Dokument zu finden. Es ist ähnlich wie ein diff Algorithmus für XML. Der interessanteste Aspekt in [5] ist eine neue edit Operation: die Unterbäumebewegung. Es werden die grössesten zussamenpassenden Teile der beiden Dokumente gesucht. Es wird ein eindeutiger Schlüsselwert (z.B. hash Wert) in einer Tabelle für jeden Unterbaum im Dokument D1 registriert. Mit dem grö�ten Unterbaum von D2 wird angefangen. Es wird versucht eine gleiche registrierten Baum von D1 zu finden. Die letzte Näherung, die hier vorgestellt wird, ist eine Methode, um XML Dokumente in clusters zu gruppieren. In [6] wird das Konzept von Ähnlichkeit zwischen XML Bäumen in der Funktion des Jaccard Koeffizientes. Wenn tag(t) das Set
12
vom Tagnamen in einem Baum ist, dann kann die Jaccard Entfernung zwischen den Bäumen t1 und t2 wie folgt defieniert werden:
Eine andere Definition beinhaltet auch die Pfade im Baum und nicht nur die Tagnamen:
{ }|)(||,)(|max|)()(|
1),(21
21
21
tpathtpathtpathtpath
ttdJ
∩−=
Wenn path(ti) das Set von den Pfaden in ti ist, dann wird path(t1)�path(t2) das Set von den gemeinsamen Pfaden zwischen t1 und t2 repräsentiert. Die Methode die hier benutzt wird ist eine große Matrix zu erstellen, in der, ein Paar von Elementen (vi � t1,wj � t2) zusammenpasst [1�(i,j)-Element] oder nicht [0�(i,j)-Element]. v und w können stark zusammenpassen, wenn v, w und die Stammväter das gleiche Label haben. v und w können vielfach zusammenpassen, wenn ein Knoten in einem Baum mit mehr als einem Knoten von einem anderen Baum zusammenpasst. Im letzen Fall, kann es einfach erkannt werden, weil in der Matrix mehr als ein Wert 1 in eine Reihe gefunden werden kann. 3.2.2 Ereignisbasierte Methoden Das Ziel und die Strategie die in [7] vorgestellt werden sind ganz anders als die Methoden, die im letzten Schritt erklärt werden. In diesem Artikel wird vorgeschlagen, die Struktur eines XML Dokumentes wie eine Zeitserie zu repräsentieren, in der jedes Ereignis aus Tags einen Impuls entspricht. Die Fourier Transformation dieser Zeitserie wird berechnet and mit dem Analisieren der Frequenzen wird die Ähnlichkeit in der Struktur von XML Dokumenten bestimmt. Um die ganze Entwicklung der Theorie zu verstehen, müssen folgende Konzepte erklärt werden: •Wenn d ein XML Dokument ist, kann tags(d) wie das Set von allen Tags in d definiert werden und tnames(d) wie das Set von allen unterschiedlichen Tagnamen in d. •Wenn d ein XML Dokument ist, kann man das Skelett von d wie die Tagsfolge in d definiert werden, d.h. sk(d) die Folge [t0,t1,...,tn] ist, in der ti ∈ tags(d) ⇔ ti ∈ sk(d) und ti geht tj in d voran, wenn nur i<j ist. •Wenn d ein XML Dokument ist und t ein Tag von ihm, kann nestd(t) wie das Set von Startstags els in d, die vor t angehen und kein Endtag ele existiert, die els zusammenpassten und vor t angeht, definiert werden. Weiterhin kann man lt wie das nesting level der Tags, d.h. lt=|nestd(t)|. •Sei D ein Set von Dokumenten, kann maxdepth(D) wie das maximale nesting level der Tags in d ∈ D definiert werden. Das Ziel von dieser Annäherung ist das Repräsentieren des Skeletts eines Dokuments wie eine Zeitserie. Es wird angenommen, dass die Baumstruktur des Dokuments in der Folge Tief-erst, links-zu-rechts durchgeführt wird. Wenn ein Knoten des Dokuments besucht wird, wird einen Impuls mit der wichtigsten Information des Tags emittiert. Das Zielsignal soll das originale Dokument wie ein Zeitserie repräsentieren. Deshalb wird der Vergleich von zwei Dokumenten durch Signale gemacht.
Es braucht trotzdem eine Codierung, die es erlaubt die Struktur eines Dokumentes in einer Zeitserie zu repräsentieren. Hier gibt es zwei verschiedene Codierungen, eine für die Tags und die andere für das Dokument. Die Tagscodierung
|)()(||)()(|
1),(21
21
21
ttagttagttagttag
ttdJ
∪∩−=
13
repräsentiert die Einschachtelung der Tags. Die Tagscodierung Kann symmetrisch sein, wenn das Endtag den selben Wert von dem Anfangstag mit verschiedenem Signum bekommt. Wenn das Endetag den Nullwert bekommt, ist die Tagscodierung null. Die Dokumentcodierung ist die Funktion, die ein XML Dokument mit einer Zeitserie, die die richtige Dokumentstruktur repräsentiert, verbindet, d.h. enc(d)=h0,h1,...,hn mit d für Dokument und hi für Koeffizienten der Zeitserie.
Nach dem Analysieren des Dokuments d mit dem Parser bekommt man das Signal hd(t). Das Vergleichen dieser Signale ist so kompliziert wie das Vergleichen der Originaldokumente. Es ist besser mit der Fourier Transformation zu arbeiten, weil gemä� Parseval Theorem die Energie der Signale nach die Transformation gleich bleibt. Da die Dokumente verschiedenen Grö�en haben können, die DFT (Discrete Fourier Transform) interpoliert, um eine neue DFT’ mit M=|tags(d1)|+|tags(d2)|-1 Punkte zu erstellen. Die Discrete Fourier Transform Entfernung zwischen Dokumenten kann wie folgt definiert werden:
[ ] [ ]( )2/122/
1
2121 )()(')()('),(���
�
�
���
�
�−= �
=
M
K
khDFTkhDFTdddist
3.3 Zusammenfassung Ein XML Dokument kann mit DOM oder SAX analysiert werden. Mit DOM wird die Baumstruktur des Dokuments gespeichert, wohingegen mit SAX ein ereignisbasiertes Analysieren durchgeführt wird. Um die Ähnlichkeit zwischen XML Dokumenten zu bestimmen, existieren unterschiedliche Methoden, die auf der Baumstruktur des Dokuments oder auf Ereignissen basieren. Baumstrukturbasierte Methoden wurden im Abschnitt 3.2.1 beschrieben. Fast alle benutzen das Konzept von tree-edit-distance, um die Ähnlichkeit zu schätzen. Diese Methode benötigt viel Speicher und Laufzeit. In 3.2.2 wurde eine ereignisbasierte Methode beschrieben. Sie speichert keine Baumstruktur, sondern sie repräsentiert die Dokumente wie Zeitserien und vergleicht sie mit der Fourier Transformation. Es existieren auch Methoden, die die Ähnlichkeit in relationalen Datenbanken bestimmen. Im Abschnitt 3.1 wurde eine Methode vorgestellt, die die Ähnlichkeit zwischen Tupeln berechnet, um Join-Pfade herauszufinden.
14
Kapitel 4 Praktische Vorbetrachtung Java bietet verschiedene APIs, um mit XML Dokumenten einfach zu arbeiten und Web-Anwendungen direkt in Java zu schreiben. Diese APIs können dokumentenorientiert oder methodenorientiert sein. � Dokumentenorientiert:
JAXP (Java API for XML Processing): Verarbeitet XML Dokumente unter der Nutzung von verschiedenen Parsern. JAXB (Java Architecture for XML Binding): Bildet XML Elemente auf Java Objekte ab.
� Methodenorientiert: JAXM (Java API for XML Messaging): Sendet SOAP Standardnachrichten über das Internet. JAXR (Java API for Registries): Ein Mechanismus, um auf Register zu zugreifen und damit Services zu suchen oder zu veröffentlichen. JAX-RPC (Java API for XML-based Remote Process Communications): Definiert einen Mechanismus für den Austausch von synchronen XML-basierten Nachrichten zwischen Anwendungen.
Das Ziel der Anwendung ist die Gewinnung von Informationen über ein XML Dokument, um zu weiteren Schlussfolgerungen zu kommen. In diesem Fall ist es verständlich, dass das ausgewählte API JAXP ist.
4.1 Das JAXP API JAXP ist eine Programmbibliothek von SUN für die Bearbeitung von XML Dokumenten. Ursprünglich stammt der Parser aus dem Apache-XML Projekt (Crimson), wurde aber von Sun erweitert. Die aktuelle Version ist 1.1, im JDK 1.4 soll das Package in die Enterprise Version eingefügt werden. Generell gilt für jede Bearbeitung eines XML-Files, dass es zuerst geparst werden muss. Dabei wird geprüft, ob das Dokument den Regeln für XML entspricht (bspw. jedes Tag hat ein dazugehöriges End-Tag). Ist dies der Fall, so spricht man von einem Well-Formed-Document. Mit JAXP können XML-Dokumente mit SAX 2.0 und DOM Level 2 bearbeitet und mit XSLT transformiert werden. SAX bietet eine ergebnisbasierte Bedienung, solange man mit DOM die Baumstruktur des Dokumentes bauen und auch ändern kann. SAX ist zum schnellen Verarbeiten der Daten entworfen worden. SAX ist im Gegensatz zu DOM nicht so speicheraufwendig, weil das XML-Dokument nicht vollständig im Speicher abgelegt ist, und daher auch für sehr große Dokumente geeignet.
15
4.2 SAX In SAX, dass auf einem Ereignismodell basiert, wird die XML-Datei wie ein Datenstrom gelesen, und für erkannte Elemente wird ein Ereignis ausgelöst. Dies ist aber mit dem Nachteil verbunden, dass wahlfreier Zugriff auf ein einzelnes Element nicht ohne Zwischenspeicherung möglich ist. Klassische Anwendungen für SAX sind: Darstellung der XML-Datei in einem Browser Suche nach bestimmen Inhalten Einlesen von XML-Dateien, um eine eigene Datenstruktur aufzubauen Das SAX-API stellt einen Mechanismus zur seriellen Verarbeitung von XML-Dokumenten zur Verfügung. Das heißt, dass ein Dokument Element um Element abgearbeitet wird. Die Kommunikation mit anderen Anwendungen wird dabei über sogenannte Handler abgewickelt, weshalb man auch von einem ereignisgesteuerten Protokoll spricht. Die folgende Grafik illustriert dies:
Abb. 1. SAX Parser
SAX API definiert unterschiedliche Interfaces und Klassen. Im SAX 2.0 kann man finden: �javax.xml.parsers.SAXParserFactory: Definiert eine factory API, die es erlaubt einen SAX Parser zu konfigurieren, und damit ein XML Dokument zu verarbeiten. Mit
16
der Methode newInstance bekommt man ein SAXParserFactory Objekt, mit dem man die andere Methode der Klasse anrufen kann. Die Konfiguration von den Parsern aus dieser factory kann man mit verschiedenen Methoden, wie setNamespaceAware oder setValidating, durchführen. Man kann mit newSAXParser ein SAXParser Objekt bekommen und einen SAX Parser zu erstellen. �org.xml.sax.XMLReader: Verarbeitet das Dokument und definiert Methoden wie setContentHandler, um Ereignistreiber zu konfigurieren und parse, um das Dokument zu verarbeiten. �org.xml.sax.ContentHandler: Dies ist der wichtigste Handler zur Verarbeitung überhaupt. In ihm werden die Methoden startDocument und endDocument implementiert, die jeweils zu Beginn und zum Ende eines Dokuments auftreten. Desweiteren gibt es die Methoden startElement und endElement, die aufgerufen werden, wenn der Parser ein einleitendes Tag bzw. ein schließendes Tag erkennt. Erkennt der Parser z.B. ein einleitendes Tag, wird die Methode startElement mit dem Namen des Tags und sämtlichen Attributwertpaaren als Parameter aufgerufen. In dieser Methode kann der Programmierer nun die Verarbeitung des Tags steuern, z.B. Name und Attribute des Tags ausgeben. Analog dazu wird die Methode endElement aufgerufen, wenn der Parser ein schließendes Tag erkennt. Erkennt der Parser hingegen freien Text, der zwischen Tags steht, wird die Methode characters aufgerufen, findet er eine Processing Instruction die Methode processingInstruction. Außerdem gibt es noch die Methode setDocumentLocator, mit der ein Locator-Objekt an den DocumentHandler übergeben wird. Dieser Locator gibt an, wo der Parser sich gerade im XML-Dokument befindet. Zur Behandlung von Whitespace gibt es die Methode ignorableWhitespace. �org.xml.sax.ErrorHandler: Dieser Handler behandelt alle Fehler, die beim Parsen auftreten. Dafür gibt es die Methoden warning, error und fatalError, die je nach Schwere des Fehlers beim Parsen aufgerufen werden. Als Parameter erhalten diese Methoden eine SAXParseException, in der nähere Angaben zur Art des Fehlers und der Position, an der er aufgetreten ist, gespeichert sind. Das SAX-API liefert zwar einen Default ErrorHandler in der DefaultHandler Klasse, dieser wirft aber nur Exceptions bei fatalErrors, andere Fehler ignoriert er. Um Fehler in XML-Dokumenten zu erkennen, sollte man hier also auf jeden Fall seinen eigenen ErrorHandler mit speziellen Fehlerbehandlungen schreiben und beim Parser registrieren. �org.xml.sax.DTDHandler: Dieser Handler kommt zur Anwendung, wenn der Parser in einer DTD auf ein unparsed entity, also Binärdaten mit einer zugehörigen Notation, trifft. Er ruft dann entweder die Methode unparsedEntityDecl oder notationDecl auf, in der der Programmierer seine eigene Behandlung der unparsed entities durchführen kann. �org.xml.sax.EntityResolver: Der EntityResolver wird benötigt, wenn der Parser auf Referenzen zu externen Dateien, z.B. DTD's trifft, und diese lesen muß. Der Parser ruft dann die einzige Methode dieses Handlers, resolveEntity auf, die aus einer öffentlichen ID (URN=Universal Resource Name) eine System ID (URL=Universal Resource Locator) macht.
17
�org.xml.sax.DefaultHandler: Inhalt einer Implementierung von den letzten vier Interfaces. Um alles zu verstehen, wird hier ein Beispiel vorgestellt, das zeigt, wie man einen SAX Parser benutzt Dieses kleine Programm zählt die Anzahl von Elementen, Attributen und Leerzeichen in einem XML Dokument. Das Programm enthält zwei Dateien, eine definiert die main Funktion, in der das Dokument analysiert wird, und die zweite Datei definiert die Funktionen des DefaultHandlers: import org.xml.sax.XMLReader; import javax.xml.parsers.SAXParser; import javax.xml.parsers.SAXParserFactory; public class min { public static void main(String argv[]) { try { SAXParserFactory factory = SAXParserFactory.newInstance(); factory.setNamespaceAware(true); factory.setValidating(true); SAXParser saxParser = factory.newSAXParser(); XMLReader xmlReader = saxParser.getXMLReader(); xmlReader.parse(argv[0]); } catch (Exception e) { e.printStackTrace(System.err); } } }
import java.io.OutputStreamWriter; import java.io.PrintWriter; import java.io.UnsupportedEncodingException; import javax.xml.parsers.SAXParser; import javax.xml.parsers.SAXParserFactory; import org.xml.sax.Attributes; import org.xml.sax.SAXException; import org.xml.sax.SAXParseException; import org.xml.sax.XMLReader; import org.xml.sax.helpers.DefaultHandler; public class SAX2Count extends DefaultHandler { private long elements; /** Elementos */ private long attributes; /** Atributos */ private long characters; /** Caracteres */ private long ignorableWhitespace; /** espacios en blanco */ /** Prints the output from the SAX callbacks. */ public static void print(String uri) { try { System.out.println("Analizando: " + uri + "\n"); SAX2Count counter = new SAX2Count(); SAXParserFactory factory = SAXParserFactory.newInstance(); factory.setNamespaceAware(true); factory.setValidating(true); SAXParser saxParser = factory.newSAXParser(); XMLReader parser = saxParser.getXMLReader(); parser.setContentHandler(counter); parser.setErrorHandler(counter); parser.setFeature( "http://xml.org/sax/features/validation", false); parser.setFeature( "http://xml.org/sax/features/namespaces", true); long before = System.currentTimeMillis();
18
parser.parse(uri); long after = System.currentTimeMillis(); counter.printResults(uri, after - before); } catch (org.xml.sax.SAXParseException spe) { spe.printStackTrace(System.err); } catch (org.xml.sax.SAXException se) { if (se.getException() != null) se.getException().printStackTrace(System.err); else se.printStackTrace(System.err); } catch (Exception e) { e.printStackTrace(System.err); } } /** DocumentHandler methods */ public void startDocument() { elements = 0; attributes = 0; characters = 0; ignorableWhitespace = 0; } public void startElement(String uri, String local, String raw, Attributes attrs) { elements++; if (attrs != null) attributes += attrs.getLength(); } public void characters(char ch[], int start, int length) { characters += length; } public void ignorableWhitespace(char ch[], int start, int length) { ignorableWhitespace += length; } /** ErrorHandler methods */ public void warning(SAXParseException ex) { System.err.println("[Aviso] "+getLoc(ex)+": "+ ex.getMessage()); } public void error(SAXParseException ex) { System.err.println("[Error] "+getLoc(ex)+": "+ex.getMessage()); } public void fatalError(SAXParseException ex) throws SAXException { System.err.println("[Error!] "+getLoc(ex)+": "+ex.getMessage()); } private String getLoc(SAXParseException ex) { StringBuffer str = new StringBuffer(); String systemId = ex.getSystemId(); if (systemId != null) { int index = systemId.lastIndexOf('/'); if (index != -1) systemId = systemId.substring(index + 1); str.append(systemId); } // str += ":" + ex.getLineNumber() + ":" + ex.getColumnNumber(); str.append(':'); str.append(ex.getLineNumber()); str.append(':'); str.append(ex.getColumnNumber()); return str.toString(); } /** Public methods */ public void printResults(String uri, long time) { // filename.xml: 631 ms (4 elems, 0 attrs, 78 spaces, 0 chars)
19
System.out.println (uri+":"+time+"time ms (" +elements+" elems, "+attributes+" attrs, " +ignorableWhitespace+" spaces, "+characters+" chars)"); } public static void main(String argv[]) { print(argv[0]); } }
4.3 DOM DOM ist eine baumartige Schnittstelle zum Bearbeiten von XML-Dokumenten.
Das DOM bietet die Möglichkeit, auf Informationen, die in einem XML-Dokument gespeichert sind, zuzugreifen. Für einige Anwendungen ist es erforderlich, die gesamte XML-Struktur im Speicher zu verarbeiten. Für diese Fälle ist eine Struktur, wie sie DOM bietet, notwendig:
Sortierung der Struktur oder einer Teilstruktur der XML-Datei Auflösen von Referenzen zwischen einzelnen XML-Elementen Interaktives Arbeiten mit der XML-Datei
In Java existiert ein Interface, namens Document Object Model API, welches den Zugriff und die Änderung der Informationen im document object, erstellt vom XML-Parser, erlaubt. DOM, das vom W3C definiert wurde, ist also eine Menge von Java Schnittstellen. Die folgende Grafik illustriet, wie die Java Schnittstellen arbeiten:
Abb. 2. DOM Parser
20
Nutzt man die Klasse javax.xml.parsers.DocumentBuilderFactory, um einen DocumentBuilder zu bekommen. Mit ihm kann man die DOM vom Dokument bauen. Die wichtigsten DOM-Interfaces sind: �org.w3c.dom.Node: Ist das Basis-Interface von DOM. Es repräsentiert einen allgemeinen Knoten im Parser-Baum und definiert im Wesentlichen Methoden zur Navigation im Baum wie getParentNode, die den Vaterknoten zurückliefert, getChildrenNodes, die ein NodeList, die alle Tochterknoten enthält, liefert, getNextSibling, die den in der Dokumentenreihenfolge nächsten Geschwisterknoten zurückliefert oder getFirstChild, die den ersten Tochterknoten zurückliefert. Weiterhin sind dort Methoden zum Einfügen und Löschen von Knoten, appendChild und removeChild, sowie zum Ändern der Daten eines Knotens vereinbart, replaceChild. �org.w3c.dom.Element: Repräsentiert einen Elementknoten und dürfte damit wohl das am häufigsten verwendete Interface von DOM sein. Die wichtigsten Methoden sind: TagName, die den Namen des Elements zurückliefert, das dieser Elementknoten repräsentiert, getAttribute, die den Wert des bezeichneten Attributs zurückliefert oder getElementsByTagName, die eine NodeList zurückliefert, die alle Elementknoten enthält, die rekursiv unter diesen Knoten liegen und den gegebenen Tag-Namen haben. �org.w3c.dom.Attr: Diese Schnittstelle repräsentiert ein einzelnes Attribut eines Elementknotens. Die wichtigsten Methoden sind: getName, die den Namen des repräsentierten Attributs zurückliefert und getValue, die den Wert des repräsentierten Attributs zurückliefert. �org.w3c.dom.Text: repräsentiert einen Textknoten. Textknoten enthalten die Zeichendaten von Elementen, deren Inhalt CDATA oder gemischter Inhalt ist. Die wichtigsten Methoden sind: getData, die den Text zurückliefert und getLength, die die Länge des Textes zurückliefert. Wie im letzten Schritt demonstriert, wird ein Beispiel vorgestellt, um das korrekte Benutzen eines DOM Parsers zu verstehen. Um die Unterschiede zwischen beiden Technologien festzustellen, zählt dieses Programm auch die Anzahl der Elemente, Attribute und Leerzeichen, aber mit DOM: import java.io.OutputStreamWriter; import java.io.PrintWriter; import java.io.UnsupportedEncodingException; import javax.xml.parsers.DocumentBuilder; import javax.xml.parsers.DocumentBuilderFactory; import org.w3c.dom.Attr; import org.w3c.dom.Document; import org.w3c.dom.NamedNodeMap; import org.w3c.dom.Node; import org.w3c.dom.NodeList; public class DOMCount { private long elements; /** Elements. */ private long attributes; /** Attributes. */ private long characters; /** Characters. */ private long ignorableWhitespace; /** Ignorable whitespace. */ /** Counts the resulting document tree. */ public static void count(String uri) { try { DOMCount counter = new DOMCount();
21
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); factory.setNamespaceAware(true); factory.setValidating(true); DocumentBuilder parser = factory.newDocumentBuilder(); long before = System.currentTimeMillis(); Document document = parser.parse(uri); counter.traverse(document); long after = System.currentTimeMillis(); counter.printResults(uri, after - before); } catch (org.xml.sax.SAXParseException spe) { spe.printStackTrace(System.err); } catch (org.xml.sax.SAXNotRecognizedException ex ){ ex.printStackTrace(System.err); } catch (org.xml.sax.SAXNotSupportedException ex ){ ex.printStackTrace(System.err); } catch (org.xml.sax.SAXException se) { if (se.getException() != null) se.getException().printStackTrace(System.err); else se.printStackTrace(System.err); } catch (Exception e) { e.printStackTrace(System.err); } } /** Traverses the specified node, recursively. */ public void traverse(Node node) { if (node == null) return; // is there anything to do? switch (node.getNodeType()) { case Node.DOCUMENT_NODE: // print document elements = 0; attributes = 0; characters = 0; ignorableWhitespace = 0; traverse(((Document)node).getDocumentElement()); break; case Node.ELEMENT_NODE: {// print element with attributes elements++; NamedNodeMap attrs = node.getAttributes(); if (attrs != null) attributes += attrs.getLength(); NodeList children = node.getChildNodes(); if (children != null) { int len = children.getLength(); for (int i = 0; i < len; i++) traverse(children.item(i)); } } break; case Node.ENTITY_REFERENCE_NODE: { NodeList children = node.getChildNodes(); if (children != null) { int len = children.getLength(); for (int i = 0; i < len; i++) traverse(children.item(i)); } } break; case Node.CDATA_SECTION_NODE: // print text characters += node.getNodeValue().length(); break;
22
case Node.TEXT_NODE: characters += node.getNodeValue().length(); break; } } public void printResults(String uri, long time) { // filename.xml: 631 ms (4 elems, 0 attrs, 78 spaces, 0 chars) System.out.println (uri+":"+time+"time ms (" +elements+" elems, "+attributes+" attrs, " +ignorableWhitespace+" spaces, "+characters+" chars)"); } public static void main(String argv[]) { count(argv[0] ); //count uri } }
Java bietet zwei Möglichkeiten, um ein XML Dokument zu analysieren. Einerseits wird mit dem SAX Parser die XML-Datei wie ein Datenstrom gelesen, und für erkannte Elemente wird ein Ereignis ausgelöst. Dies ist aber mit dem Nachteil verbunden, dass wahlfreier Zugriff auf ein einzelnes Element nicht ohne Zwischenspeicherung möglich ist. Andererseits wird mit dem DOM Parser die Baumstruktur des Dokuments gespeichert. Das DOM bietet die Möglichkeit, auf Informationen, die in einem XML-Dokument gespeichert sind, zuzugreifen, aber mit dem Benutzen von viel Speicherplatz. Für jede Anwendung muss man folglich entscheiden, welcher Parser geeignet ist.
23
Kapitel 5 Experimentelle Lösungen
Diese Arbeit enthält zwei Programme in Java: XMLStructuralSimilarity und XMLModifier. Das Ziel des ersten Programms sind eine Statistik über XML Dokumente und Berechnungsalgorithmen zur Ähnlichkeit zwischen zwei XML Dokumenten. Kleine Dokumente können mit direkten Methoden verglichen werden. Bei grö�eren Dokumenten sind Aspekte von der Dokumentenstruktur wie die Anzahl von Knoten, Anzahl von Kindern pro Knotentyp oder die maximale Tiefe schwerer zu ermitteln. Dieses Programm arbeitet mit SAX und nicht mit DOM, weil für gro�e Dokumente der benutzte Speicher mit DOM nicht ausreicht. Mit SAX kann man Dokumente mit einer Grö�e im Bereich von MBytes analysieren, weil SAX keine Baumstruktur zu speichern braucht. Im zweiten Programm werden Änderungen in einem BasisXMLDokument durchgeführt, um ein zweites XML Dokument zu bekommen.
5.1 Realisierung struktureller Ähnlichkeitssuche
Dieses Programm bearbeitet zwei XML Dokumente und liefert eine statistische Zusammenfassung für jedes Dokument und berechnet die Ähnlichkeit zwischen beiden. Der SAX Parser liest das XML Dokument und überprüft es syntaktisch. Beim Erkennen einer bekannten Syntaxkonstruktion, ruft der Parser eine Methode auf. Diese Ereignisse verwendet man, um verschiedene Berechnungen und Informationen zu speichern. Am Endes des Programms hat man eine Zusammenfassung von allen Typen jedes Dokuments in einem Vektor (TypesVector). Um die Ähnlichkeit zu schätzen, nimmt man willkürliche Elemente vom Vektor eines Dokuments und sucht, ob dieses Element im Vektor des anderen Dokuments existiert oder nicht. Je mehr Elemente übereinstimmen, desto grö�er ist die Ähnlichkeit. 5.1.1 Handler.java Diese Datei enthält alle die Funktionen, um ein XML Dokument zu analysieren. In der Klasse Handler werden alle die definierten Methoden eines SAX Parsers überschreiben, aber man benötigt auch neue Objekte zu definieren, um eine richtige Management und Speichern der gesammelte Information durchzuführen. 5.1.1.1 Klasse Handler Diese Klasse erbt aus DefaultHandler alle die Methoden, die der SAX Parser beim Finden einer bekannten Struktur vermittelt. Zum Beispiel, wenn der Parser den Tag eines neuen Elements verarbeitet, ruft er die Methode startElement auf, wenn er den Endtag des Elements findet, dann die Methode endElement. Alle die Methoden werden überschrieben, um verschiedene Informationen zu speichern oder wichtige Berechungen durchzuführen.
24
5.1.1.2 Klassen StackObject und MyStack Der SAX Parser ist ein ereignisbasierter Parser, das bedeutet, er liest das Dokument vom Anfang bis Ende und gibt die verschiedenen Ereignisse in der selben Ordnung wie die Tags im Dokument aus. Wenn ein Kinderknoten kommt, wird der Parser wieder startElement rufen, auch wenn der Vaterknoten noch nicht fertig ist. Also, wenn der Vater mehr als ein Kind hat oder die Kinder auch Kinder haben, werden alle diese Knoten davor verarbeitet. Das macht die Sammlung von Informationen schwerer, weil es bedeutet zu wissen, welcher Knoten im Moment aktiv ist. Damit dieses Problem einfach zu lösen ist, sind die Klassen MyStack und StackObject implementiert. Die Klasse MyStack ist die Implementierung von einem Stapel von StackObjects. Wenn der Parser ein neues Element trifft, ruft er die startElement Methode auf und ein neues Objekt StackObject ist erstellt und an der obersten Stelle im Stapel gespeichert. Wenn ein Endetag gefunden ist, muss man das letze Element vom Stapel eliminieren. Diese Klasse implementiert die häufigsten Methoden für das Benutzen von StackObjects:
popElement(): holt das oberste Element heraus. pushElement(StackObject): fügt ein neues StackObject in den Stapel ein. peekElement(): liefert das letzte Element zurück, ohne es zu löschen. Die Klasse StackObject definiert die Objekte, die im MyStack gespeichert werden. Sie enthalten Informationen über den Namen des Elements und die Anzahl von Kindern, die dieses Element hat. Mit diesen Informationen werden die anderen Teile des Programms verarbeitet. Dieses Objekt hat zwei Instanzvariablen: name: String Variable, die den Namen des Elements enthält. children: speichert die Anzahl von Kinderknoten, die dieses Element hat, in einem Integer-Feld.
M yStack M y S tack
M y S tack M y S tack
Abb. 3. SAX Parser und MyStack
25
5.1.1.3 Klassen TypesVector und TypesVectorObject Der SAX Parser baut keinen Baum wie DOM. Damit gibt es nach dem Verarbeiten des Dokuments keine gespeicherten Informationen über die Elemente. Mit den folgenden Klassen kann man eine Zusammenfassung von Elementen speichern und verarbeiten. Die Klasse TypesVector definiert einen Vektor, in dem verschiedene TypesVectorObjects gespeichert werden. Wenn ein neuer Typ gefunden wird, wird ein neues TypesVectorObject erstellt und in den Vektor gespeichert. Die maximale Größe des Vektors wird die Anzahl von Typen im Dokument und nicht ein gespeichertes Objekt pro Element im Dokument wie in DOM. Dieser Vektor enthält eine Zusammenfassung von der Dokumentstruktur und kann deshalb benutzt werden, um die Dokumente zu vergleichen und die Ähnlichkeit zu schätzen. Diese Klasse implementiert die folgende Methoden:
add(TypesVectorObject): fügt ein neues TypesVectorObject Element am Ende des Vektors hinzu. contains(String): Nimmt einen Typname als Parameter und sucht, ob ein Element mit diesem Namen im Vektor schon existiert. Wenn ja, liefert sie die Stelle des Vektors zurück, wo dieses Element gefunden ist, oder –1 wenn es nicht existiert.
Die Klasse TypesVectorObject definiert ein Objekt, in dem die Information jedes Typs gespeichert wird. Für jeden neuen Typ wird ein neuer TypesVectorObject in den TypesVector eingefügt. Durch die Verarbeitung des Dokuments werden die Informationen von jedem Typ in die Instanzvariablen des TypesvectorObjects von diesem Typ aktualisiert. Die definierten Instanzvariablen sind: typeName: String Variable, die den Namen des Typs enthält. vectorPosition: Die Stelle dieses Elements im Vektors. Integer Variable. numElems: Integer, das die Anzahl von Knoten von diesem Typ speichert.
numChildren: Integer Variable, die die Anzahl von Kinderknoten von allen Knoten dieses Typs hat. chose: Boolean Variable. Ist true wenn dieses Objekt schon genommen wurde und false wenn nicht. levelVector: LevelVector Variable. Speichert Informationen darüber, auf welchen Niveaus sich die Elemente von diesem Typ befinden.
5.1.1.4 Klassen LevelVector und LevelObject Ein Knoten von einem bestimmten Typ kann sich auf verschiedenen Niveaus befinden. Das ist ein wichtiger Aspekt, wenn man die Dokumentstruktur schätzen möchte. Um das zu schaffen, hat man einen Vektor kreiert, in dem die Ebenen, in welchen die Knoten von jedem Typ sind, gespeichert werden, auch mit der Anzahl von Knoten pro Niveau. Die Klasse LevelVector definiert einen Vektor von LevelObjects. Dieser Datentyp wird nur bei dem Typ TypesVectorObject benutzt. So gibt es nur einen LevelVector pro Typ. In jedem TypesVectorObject existiert ein LevelVector, in dem jedes Mal ein neues gefundenes Element von diesem Typ gespeichert ist. Wenn es das erste Element von diesem Typ auf diesem Niveau ist, wird ein neues LevelObject
26
erschaffen. Falls es nicht das erste Element von diesem Typ ist, wird die Anzahl von Knoten im LevelObject erhöht. Diese Klasse implementiert die folgenden Methoden:
levelExists(int): Sucht, ob das gegebene Niveau in dem LevelVector existiert oder nicht. Liefert die Stelle des Vektors, auf dem dieses Niveau existiert zurück oder –1, wenn nicht. getLevelObject(int): Liefert das LevelObject der Stelle, die im Parameter eingegeben ist. whereToInsert(int): Im LevelVector müssen die verschiedenen Niveaus mit ihre Reihenfolge gespeichert werden. Um das zu schaffen, ruft man diese Methode auf, die die Stelle, in der das LevelObject gespeichert werden muss, zurückliefert, oder -1, wenn man es am Ende speichert. Die Klasse LevelObject wird benutzt, um die Information von einem Niveau in
einem LevelVector zu speichern. Es gibt nicht ein LevelObject für jede Ebene im Dokument. Pro Typ, repräsentiert durch ein TypesVectorObject, wird es nur ein LevelObject pro Niveau geben, für das ein Element von diesem Typ existiert. Diese Implementierung spart Speicherplatz, weil keine unnötigen Variablen gespeichert sind. Die definierten Instanz Variablen von LevelObject sind:
level: Integer Variable, die zeigt, in welcher Ebene das Element existiert. num: Integer Variable, die die Anzahl von Knoten von diesem Typ im Niveau level zeigt.
TypesVectorObject{ typeName
vectorPositionnumElemnumChildrenchoselevelVector
}
LevelObject{ num
level}
TypesVector
Abb. 4. TypesVectorObject
27
5.1.2 XMLStructuralSimilarity.java 5.1.2.1 Das Analysieren eines XML Dokuments Um ein Dokument zu analysieren, muss man einen Parser erstellen. Mit einer Instanz der Klasse SAXParserFactory kann man die Eigenschaften konfigurieren, um eine Menge von Parsern zu erstellen. Danach kann man einen Parser erstellen, um ein XMLReader, der Dokument analysiert, zu bekommen. SAXParserFactory spf = SAXParserFactory.newInstance(); spf.setNamespaceAware(true); SAXParser saxParser = spf.newSAXParser(); XMLReader parser = saxParser.getXMLReader();
Um die verschiedenen Ereignisse zu analysieren, benötigt man in Verbindung mit dem Parser einen Handler: Handler handler = new Handler(); parser.setContentHandler(handler);
Abschließend kann das Dokument mittels Aufrufen der Methode parse analysiert werden: parser.parse(file1); 5.1.2.2 Bestimmung von Ähnlichkeiten Nach dem Analysieren der Dokumente durch den SAX Parser, ist die Information in den TypesVectors gespeichert. Um die Ähnlichkeit zu berechnen, nimmt man ein Element aus dem TypesVector vom ersten Dokument und sucht, ob dieses Element auch im TypesVector des zweiten Dokuments existiert. Der Wert der Ähnlichkeit wird bestimmt durch den Quotienten aus der Anzahl der Erfolge geteilt durch die Anzahl der verglichenen Elemente. Um eine bessere Schätzung der Ähnlichkeit zu bekommen, werden zwei Ähnlichkeitsberechnungen definiert. In der ersten werden nur die Elementnamen verglichen, egal wo sie sich im Dokument befinden. In der zweiten werden auch die Niveaus, in denen sich diese Elemente befinden, berücksichtigt. Die erste Näherung ist erfolgreich, wenn ein Element A in einem Niveau i im ersten Dokument einem Element A in j im zweiten Dokument entspricht, solange sie in der zweiten Näherung wie zwei verschiedene Knoten betrachten werden.
Die erste Ähnlichkeit, �Name, kann wie folgt berechnet werden: �=
=N
i
iName NI1
/ρ , in
dem iI eins ist, wenn der gewählte Elementname im zweiten Dokument existiert und null ist, wenn der gewählte Elementname im zweiten Dokument nicht existiert. N ist die Anzahl der verglichenen Knoten.
Um die zweite Ähnlichkeit, �Level , zu berechnen, muss man die Anzahl der Knoten von diesem Typ pro Niveau wissen. Diese Information ist im LevelObject gespeichert. Für jeden genommenen Elementtyp, muss man vergleichen wie viele Knoten pro Niveau in jedem Dokument existieren. Um das zu schaffen, wird pro Niveau die Anzahl der Knoten in beiden Dokumenten in num1 und num2 gespeichert. Für jeden Typ t und jedes Niveau n bekommt man eine Teilähnlichkeit wie folgt:
28
)2,1max()2,1min( numnumnumnumPti = oder eins wenn num1=num2=0. Der Wert der
zweiten Ähnlichkeit wird so berechnet: � �= ==
T
t
N
ntnLevel TNP
1 1ρ mit T der Anzahl der
genommenen Typen und N der Anzahl von Niveaus. Der Zielwert der Ähnlichkeit ist ein Mittelwert von beide Ähnlichkeiten. Gemä�
der Werte der Parameter � und �, kann man mehr oder weniger Wert auf eine Ähnlichkeit gegenüber der anderen legen. Um die Ähnlichkeit zwischen zwei XML Dokumenten zu bestimmen, wird willkürlich eine Anzahl von Elementen aus dem Vektor TypesVector des ersten Dokuments genommen und verglichen mit den Elementen des TypesVectors des zweiten Dokuments. Die Prozentzahl der verwendeten Knoten können die Nutzer mittels des Parameters PbbChosenNodes definieren. Die Ergebnisse der Vergleiche werden benutzt, um �Name und �Level zu berechnen. Den gegebenen Wert der Ähnlichkeit kann man mit den Programmparametern � und � nach dem folgenden Ausdruck berechnen: �=� �Name+� �Level, in dem �+�=1.
Die Berechnungen werden in zwei Richtungen durchgeführt. In einer, �1, werden die Elemente des ersten Dokuments genommen und in der anderen, �2, die Elemente des zweiten. Es ist interessant zu wissen, ob ein Dokument in einem anderen enthält ist oder nicht. 5.2 Änderung eines XML Dokuments Dieses Programm, namens XMLModifier, erhält ein XML Dokument und liefert ein neues XML Dokument zurück. Das liefernde Dokument ist das alte Dokument, in dem verschiedene Änderungen, gemä� gegebenen Parametern, vorgenommen werden. 5.2.1 Die Funktionsweise des Programms Das Ziel des Programms ist ein XML Dokument mit einer gegebenen Ähnlichkeit zum Basis XML Dokument zu bekommen. Um das zu schaffen, werden verschiedene Änderungen im Basis Dokument vorgenommen, entsprechend der Menge der eingegebenen Parameter. Mit DOM kann man auf ein bestimmtes Element in der Baumstruktur zugreifen, mit SAX ist jedoch wahlfreier Zugriff auf ein einzelnes Element nicht ohne Zwischenspeicherung möglich, weil der Parser die XML-Datei wie einen Datenstrom liest. Das Programm verarbeitet das Dokument und kopiert es in ein neues Dokument, in dem die Änderungen durchgeführt werden. Während SAX das Dokument verarbeitet, muss man entscheiden, welche Elemente geändert werden müssen. Man braucht Variable für jedes Element mit Booleschen Werten, für das Änderungen gemacht werden müssen. Für jedes Element unterscheidet man drei verschiedene Operationen: Elementname ändern, ein Duplikat von diesem Element, aber mit verschiedenen Namen, erstellen und das Element löschen. 5.2.1.1 Änderung Das Programm bekommt einen Parameter, der aussagt, mit welcher Wahrscheinlichkeit eine Änderung durchzuführen ist. Für jedes Element wird die Methode azar benutzt, die, gemä� dem Wert des Parameters sagt, ob dieses Element geändert werden muss. Falls eine Änderung vorzunehmen ist, muss man den Elementnamen wechseln und nicht den gelesenen Elementnamen schreiben, sondern
29
den Namen, der von der Methode modify geliefert wird, die „kkkkk“ in den Elementnamen eingefügt. 5.2.1.2 Duplikation Das Programm XMLStructuralSimilarity findet kein Duplikat, weil es die Elementensnamen vergleicht. Ein neues Element mit dem gleichen Name hat keinen Effekt in der gegebenen Ähnlichkeit. Die Duplikation im Kontext dieses Programes bedeutet, ein Duplikat von einem Element zu erstellen, in dem der Elementnamen des neuen Elementes geändert wird. Diese Änderung in der Dokumentstruktur repräsentiert eine Abnahme im Wert der Ähnlichkeit. Das duplikate Element wird sich im Zieldokument mit dem Name des Elementes mit der Kette „zzzzz“ am Ende befinden. 5.2.1.3 Löschen Wenn ein Element vom Dokument gelöscht werden muss, wird es einfach nicht in das Ergebnisdokument geschrieben. Das bedeutet, dass alle Operationen in startElement und endElement nur ausgeführt werden, wenn das Element nicht gelöscht werden muss. 5.2.2 Klassen RandomProperties und RandomStack Das Funktionieren der Klasse RandomStack ist ähnlich der Klasse MyStack in XMLStructuralSimilarity. Das nochmalige Benutzen eines SAX Parsers macht den Zugriff auf ein einzelnes Element im XML Dokument kompliziert. Wenn man das Element einer von drei möglichen Änderungen braucht, muss man nicht nur die gewünschte Operation auf den Anfangstag realisieren, sondern auch auf den Endtag. Damit ergibt sich die Schwierigkeit, dass willkürliche Eigenschaften für jedes Element gespeichert werden und die Notwendigkeit zu wissen, welchem Element das endElement Ereignis gehört. Diese sind die Aufgaben der Klassen, die im Weiteren erklärt werden. Die Klasse RandomStack implementiert einen Stapel, in dem die RandonStackObjects gespeichert werden. Das Hinzufügen und Löschen der Elemente in den Stapel simuliert die Aufgabe des Parsers, wobei das oberste Element immer das Element ist, das beenden muss. Die Methoden zum Benutzen des Stapels sind pushElement, popElement und peekElement. Die Klasse RandomStackObject enthält drei boolesche Variable, die angeben, welche Operationen über dieses Element durchzuführen sind. Immer wenn ein neues Element gefunden wird, ruft man die Methode azar auf, die die neuen booleschen Werte für das RandomStackObject festlegt. Das Programm erstellt ein neues RandomStackObject und fügt es in den Stapel hinein. Die drei booleschen Instanzvariablen dieses Objekts sind:
duplicity: ist true, wenn ein neues Element mit dem gleichen Elementnamen plus der Kette „zzzzz“ erstellt werden muss. Das neue Element wird ein leeres Element sein, außer es hat Attribute, die in diesem Fall kopiert werden. change: ist true, wenn der Elementname geändert werden muss. In diesem Fall wird die Kette „kkkkk“ am Ende des Elementnamen eingefügt. removal: ist true, wenn dieses Element gelöscht werden muss.
30
5.2.3 Das Schreiben eines XML Dokuments Neben dem DefaultHandler, der selbst Methoden enthält, gibt es weitere Methoden, um ein neues Dokument zu schreiben. Die wichtigsten sind. 5.2.3.1 Normalisieren Ein korrektes XML-Dokument muss einige Bedingungen erfüllen, damit es wohlgeformt ist. Wenn es nicht wohlgeformt ist, dann ist es auch kein XML-Dokument. Damit ein XML-Dokument wohlgeformt ist, muss jedes Element aus einem Anfangs- und einem End-Tag oder nur aus einem abgeschlossenen Tag bestehen. Hierarchische Elemente müssen in umgekehrter Reihenfolge ihrer Öffnung wieder geschlossen werden. Durch die Anordnung der öffnenden und schließenden Tags wird die Struktur des XML-Dokuments festgelegt. Jedes XML-Dokument muss ein Wurzelelement enthalten, das alle anderen Elemente einschließt. Man muss darauf achten, dass einige Zeichen in XML bestimmte Bedeutungen haben. Dazu gehören &, <, >, " und '. Sie werden im Text durch spezielle Abkürzungen, den Entitäten, abgebildet. Dies sind für die oben genannten Zeichen &, <, >, " und '. Diese Entitäten für die Sonderzeichen sind die Einzigen, die durch den Standard festgelegt sind. Mit der Methode normalize kann man diese speziellen Zeichen festlegen, damit ein XML Dokument normalisiert wird. Der Vergleich zwischen XML Dokumenten muss mit normalisierten XML Dokumenten durchgeführt werden. 5.2.3.2 Das Formatieren der Ausgabe Ein schlechtes Ausgabeformat eines XML Dokumentes kann dieses unlesbar machen. Die Methode nl (new line) ermöglicht Zeichen auf eine neue Zeile vorzusetzen. Im Laufe des Programmes wird es oft gebraucht. Damit hilft die Methode, einen einfacheren Kode zu haben. 5.2.3.3 Das Konfigurieren der I/O
Um das Programm flexibeler zu machen, bekommt es verschiedene Eingabeparameter, wie die Namen der Inputdateien oder die Wahrscheinlichkeit für die unterschiedlichen Änderungen im Ausgabedokument. Das Benutzen des Programmes geschieht wie folgt:
Usage: java XMLModifier inputfile outputfile pbbDuplication pbbChange pbbRemoval
inputfile: Base XML-Dokument, das gelesen und geändert wird. outputfile: Ausgabedokument. Es enthält die im Base Dokument gemachten Änderungen. pbbDuplication: Wert zwischen 0 und 1, der die Wahrscheinlichkeit zeigt, mit dem ein neues Element mit dem gleichen Namen plus „zzzzz“ eingefügt werden muss. pbbChange: Wert zwischen 0 und 1, der die Wahrscheinlichkeit zeigt, mit dem ein Element geändert werden muss. pbbRemoval: Wert zwischen 0 und 1, der die Wahrscheinlichkeit zeigt, mit dem ein Element gelöscht werden muss.
31
Die main Methode bekommt Parameter, die Zeichenketten sind. Das ist kein Problem für die Dateinamen, aber für die Wahrscheinlichkeitsparameter, die double Werte speichern. Um diesen Werte in double Variable zu übersetzen, braucht man einen Zwischenschritt. Die gegebenen Parameter werden in die Double Objekte übersetzt. Danach werden mit dem Benutzen der Methode doubleValue aus der Klasse Double, die Ergebnisse in die gewünschten double Variablen gespeichert.
pbbDup=new Double(args[2]); pbbDupMod=pbbDup.doubleValue(); pbbCh=new Double(args[3]); pbbChange=pbbCh.doubleValue(); pbbRem=new Double(args[4]); pbbRemoval=pbbRem.doubleValue();
Um ein Output zu bekommen, muss man ein neues XML Dokument schreiben.
Dieses Programm kopiert das Eingabedokument in ein Ausgabedokument, in dem die Modifikationen durch das Benutzen des SAX Parsers gemacht werden. Wenn der Parser ein neues Element findet, muss er die Methode startElement aufrufen. Diese Methode muss das neue Element im das Ausgabe Dokument schreiben, abhängig von den Werten der Variablen im RandomStackObject. Wenn das Endetag gefunden ist, ruft man die Methode endElement auf, wobei das Element im Ausgabedokument auch beendet werden muss, mit dem Erhalten der gemachten Modifikationen. Um ein XML-Dokument mit dem Namen der eingegebenen Parameter zu haben, braucht man ein FileOutputStream. Um alle Informationen in das Ausgabedokument zu schreiben, wird ein OutputStreamWriter Objekt erstellt, das über das FileOutputStream in das AusgabeXML Dokument die Ergebnisse schreibt.
static private Writer out; FileOutputStream fout;
fout = new FileOutputStream ( args[1] ); out = new OutputStreamWriter(fout, "UTF8");
Während des Schreibens können IOExceptions auftreten, aber die Methoden von DefaultHandler kennen keine IOExceptions, sonder nur SAXExceptions. Ein SAXException kann eine andere Exception umgeben. Um das zu bekommen, hat man die Ausgabe mit der definierten Methode emit.
5.3 Zusammenfassung In dieser Diplomarbeit wurden zwei verschiedene Programme, namens XMLStructuralSimilarity und XMLModifier, erstellt. Das ersten Programm berechnet die Ähnlichkeit zwischen XML Dokumenten und liefert eine Statistik über jedes analysierte Dokument. Das zweite Programm nimmt ein XML Dokument, ändert es gemäß der Werte der Parameter und liefert ein neues XML Dokument mit den durchgeführten Änderungen.
32
Kapitel 6
Experimente Nach der Beschreibung der Programme ist es interessant, das Verhalten von Beiden zu überprüfen. Für alle Experimente wird ein XML Dokument als Basisdokument benutzt. Dieses Basisdokument heiß 1b2g.xml und repräsentiert die Eigenschaften eines Proteins. Es kann auf der Webseite http://www.rcsb.org/pdb/ heruntergeladen werden. Mit dem Programm XMLStructuralSimilarity kann man eine Statistik über dieses Dokument bekommen. Hier werden die wichtigsten Aspekte dieser Statistik vorgestellt, genauso, wie das Programm sie liefert:
Total number of nodes without leaves: 655 Total number of children: 9239.0 Average number of children pro node: 14.105344 Maximal depth: 4 Number of different types: 327
6.1 Szenarien In der vorliegenden Diplomarbeit wurden zwei unterschiedliche Programme verwendet. Für jedes Programm erhält man verschiedene Parameter, die man zur Ableitung benötigt. An dieser Stelle wird ein Beispiel für jede Gruppe der Parameter vorgestellt. Beim ersten Programm, dem so genannten XMLStructuralSimilarity erhält man drei verschiedene Parameter: �, � und pbbChosenNodes. Die ersten Beiden benötigt man, um die Bedeutung von jeder Ähnlichkeitsart festzulegen . Über die pbbChosenNodes wird die Anzahl von Knoten kontrolliert, die in der Berechnung der Ähnlichkeit verglichen werden. Beim zweiten Programm, dem so genannten XMLModifier erhält man drei Parameter pbbDuplication, pbbChange und pbbRemoval, welche die Wahrscheinlichkeit angeben, ein Duplikat zu erzeugen, oder eine Änderung bzw. Löschen durchzuführen. Es werden nun drei Experimente vorgestellt. Bis auf den Parameter der im Experiment analysiert wird, sind die Parameter konstant. Im ersten Experiment wird pbbChosenNodes verändert, während die anderen Parameter konstant sind. Im zweiten Experiment werden a und ß verändert und im Dritten beobachtet man, wie sich die Ähnlichkeit des XMLDokumentes ändert. Die Beobachtungen werden anhand der Veränderung der Werte von den Parametern pbbDuplication, pbbChange und pbbRemoval beschrieben.
6.2 Experiment 1 Das Experiment 1 zeigt, wie sich anhand der Werte vom Parameter pbbChosenNodes die Ähnlichkeiten bestimmen lassen. Die Berechnung der Ähnlichkeit von kleinen Dokumenten, (mit allen Knoten) ist kein Problem. Interessanter ist die Frage, mit welcher Anzahl der Knoten eine repräsentative Schätzung der Ähnlichkeit
33
möglich ist. Je größer der Wert des pbbChosenNodes Parameters ist, desto genauer wird die Bestimmung der Ähnlichkeit. Die erhöhung der Laufzeit des Programms ist hierbei aber als größter Nachteil zu nennen. In diesem Experiment werden alle Parameter, außer jeweils einem Veränderlichen, als konstant festgelegt. Aus der XML Dokument 1b2g.xml wird mit dem Programm XMLModifier ein neues XML Dokument dirty1b2g.xml erstellt, in der nur ein Viertel der Knoten geändert wurden, ohne Elemente zu duplizieren oder zu löschen. Beide XML Dokumente werden mit dem Programm XMLStructuralSimilarity verglichen. Der Vergleich erfolgt über den Wert von pbbChosenNodes im Intervall von 0 bis 1 mit einer Schrittweite von 0.1. Die Werte für die Parameter � und � seien konstant �= �=0.5. Bei jedem Durchlauf des Programms mit den unterschiedlichen Werten von pbbChosenNodes erhält man die Ähnlichkeiten �1 (in der 1b2g.xml mit dirty1b2g.xml verglichen wird) und �2 (in der dirty1b2g.xml mit 1b2g.xml verglichen wird), welche in der nachfolgenden Abbildung (Abb. 5.) dargestellt werden. Die Knoten sind willkürlich ausgewählt. Die erhaltenen Werte sind natürlich vom gewählten Knoten abhängig. Um dies zu beweisen, wurde das Experiment mit unterschiedlichen Werten in der seed und in der random Funktion zwei Mal durchgeführt.
0,5
0,55
0,6
0,65
0,7
0,75
0,8
0,85
0,9
0 0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9 1
pbbChosenNodes
Sim
ilari
ty
p1p1´real p1p2p2´real p2
Abb. 5. Das Analysieren der Effekte von pbbChosenNodes
Wird die Anzahl der verglichenen Knoten erhöht, so nähert sich das gelieferte Ergebnis der Ähnlichkeit des eigentlichen Wertes an. Man kann ebenfalls beobachten, dass die Kurvengruppen �1, �2 und �1’, �2’ bei unterschiedlichen Knoten zwar unterschiedlich verlaufen, sich aber trotzdem tendenziell dem selben Wert annähern, real �1 und real �2.
6.3 Experiment 2 Das Programm XMLStructuralSimilarity kann zwei verschiedene Ähnlichkeiten berechnen, dabei muss aber derselbe Tagname des einen XML Dokumentes auch im
34
anderen verwendet worden sein. Die andere berechnete Ähnlichkeit kontrolliert die Anzahl von Knoten, die denselben Namen haben und sich auf dem gleichen Niveau befinden. Mit den Parameter � und � kann man auf �Name oder �Level mehr Werte ablegen: �=� �Name+� �Level, in dem �+�=1. Wenn �=1, werden nur die Elementnamen von � verglichen, und mit �=1 wird die Ähnlichkeit wie bei �Level berechnet. Für alle da zwischen liegenden Werte werden beide Möglichkeiten berechnet und von diesen der Durchschnitt gebildet. Um den Effekt der unterschiedlichen Werte von � und � zu beobachten, wird folgendes Experiment vorbereitet: Gegeben sei ein XML Dokument 1b2g.xml, in diesem werden kleine Änderungen mit dem XMLModifier (pbbDuplication=0, pbbChange=0.25 und pbbRemoval=0) vorgenommen. Das neue XML Dokument erhält den Namen dirty_Nummer.xml. Dieses neue XML Dokument wird nun mit dem XML Basisdokument mittels XMLStructuralSimilarity verglichen. Dieser Vergleich wird elf Mal durchgeführt, wobei der Parameter pbbChosenNodes=1 konstant bleibt, sich aber die Werte für (�,�)von �=1, �=0 bis �=0, �=1 in Schritten von 0,1 ändern. Die folgende Grafik (Abb. 6) stellt die Ähnlichkeitswerte nach � und � dar. Die X-Achse repräsentiert hierbei die Werte von � ,ß, wobei � in der ersten Zeile und � in der Zeile darunter steht. Auf der Y-Achse werden die Ähnlichkeitswerte in beide Richtungen �1 und �2 aufgezeigt.
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
0 0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9 1
1 0,9 0,8 0,7 0,6 0,5 0,4 0,3 0,2 0,1 0
alpha and betha
Sim
ilari
ty
p1p2
Abb. 4. Alpha und Beta
�1 zeigt die Ähnlichkeit, wenn die Knoten aus dem ersten Dokument genommen werden, und �2 zeigt die Ähnlichkeit aber in der anderen Richtung. Wie erwartet, ist die Zielähnlichkeit grö�er, wenn weniger Wert auf �Level gelegt wird.
6.4 Experiment 3 In diesem Experiment soll untersucht werden, wie sich die Änderungen eines XML Dokuments auf die Ähnlichkeit zwischen XML Dokumenten auswirkt. Dazu wird
35
ein neues Szenario mit identischen Parametern erstellt, in dem lediglich der zu untersuchende Parameter geändert wird.
Die Ausgangswerte zum folgenden Szenario sind: �= �=0.5 und pbbChosenNodes=1 Hierbei ist besonders darauf zu achtet, welchen Effekt die Änderung eines einzelnen Parameters auf die Ähnlichkeit hat. Es werden �1, und �2 berechnet. �1 zeigt die Ähnlichkeit, wenn die Knoten aus dem ersten Dokument genommen werden, um sie mit dem zweiten Dokument zu vergleichen, und �2 zeigt die Ähnlichkeit aber in der anderen Richtung.
6.4.1 pbbDuplication Mit dem XLMModifier ist es möglich ein Element zu duplizieren. Da ein Duplikat mit demselben Namen keinen Effekt in der Ähnlichkeit zeigen würde, wird der Name dabei geändert. In diesem Experiment wird das Programm XMLModifier aufgerufen, um verschiedene XML Dokumente zu erstellen. Bei jedem Aufruf wird der Parameter pbbChange= pbbRemoval=0 gesetzt, pbbDuplication jedoch mit Werten zwischen 0 und 1 in Schritten von 0,1 belegt. Es entstehen verschiedene XML Dokumente mit unterschiedlicher Duplikatenmenge, die mittels XMLStructuralSimilarity verglichen werden können. Diese Vergleiche ergeben wiederum die Ähnlichkeitswerte. Das folgende Schaubild (Abb.7) zeigt die Ergebnisse des Experiments.
Duplication
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
1
1,1
0 0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9 1
PbbDuplication
Sim
ilari
ty
p1p2
Abb. 7. Effekt der Duplikation von Knoten in der Ähnlichkeit
Auf der X-Achse sind die Werte von pbbDuplication aufgetragen, während die Y-Achse die Ähnlichkeit von �1 und �2 zeigt. Wenn es kein Duplikat gibt, ist das geänderte
36
Dokument mit dem Basisdokument identisch. Je größer der Wert des Parameters pbbDuplication ist, desto größer ist der Unterschied zwischen den zu vergleichenden XML Dokumenten. Bei pbbDuplication=1 befindet sich der maximale Unterschied, bei dem für jedes Element aus dem Basisdokument ein Duplikat mit anderem Namen existiert und damit der Wert von �2 auf �2=0.5 sinkt, während �1=1 konstant bleibt. Dies beruht auf der Tatsache, dass ein dem Basisdokument entnommener Elementtyp immer im duplizierten XML Dokument vorzufinden ist und beim Duplizieren weder Änderungen vorgenommen noch Elemente gelöscht werden. 6.4.2 pbbChange Wie im letzten Schritt beschrieben, wird auch hier der Effekt auf einzelne Parameter durch das Programm XMLModifier analysiert. Diesmal wird der Parameter pbbChange verändert. Die folgende Grafik (Abb. 8.) beschreibt die Ergebnisse dieses Experimentes.
Change
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
1
1,1
0 0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9 1
PbbChange
Sim
ilari
ty
p1p2
Abb. 8. Effekt der Änderung von Knotennamen in der Ähnlichkeit
Die X-Achse repräsentiert die Werte vom Parameter pbbChange. Je höher dieser Parameter ist, desto unterschiedlicher sind die Elemente im Zieldokument zu denen im Ausgangsdokument. Was eine Abnahme des Ähnlichkeitwertes zur Folge hat. 6.4.3 pbbRemoval
Wie bereits mit pbbDuplication und pbbChange aufgezeigt, kann man diesen
Effekt auch vor dem Löschen von Knoten analysieren. Je grö�er der Parameter
37
pbbRemoval ist, desto mehr Knoten aus dem Basisdokument werden im Zieldokument gelöscht. Auf Grund der Ungenauigkeit der ramdon Funktion werden nicht alle Knoten, sondern nur ca. 99% gelöscht. Auf Grund dessen ist keine Ähnlichkeit möglich, wie es eigentlich Vermutet werden könnte. Die folgende Abbildung (Abb.9) zeigt wie sich die Ähnlichkeitswerte ändern, wenn der Parameter pbbRemoval Werte von 0 bis 1 annimmt.
Removal
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
1
1,1
0 0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9 1
PbbRemoval
Sim
ilari
ty
p1p2
Abb.9. Effekt des Löschens von Knoten in der Ähnlichkeit
Es ist sehr interessant das unterschiedliche Verhalten der beiden Ähnlichkeiten zu beobachten.
6.5 Zusammenfassung
Die Ergebnisse der Experimente sind die erwarteten. Das einzige, was etwas überraschend aussieht, ist das Experiment, in den der Parameter pbbRemoval überprüft wird. Die willkürlichen Operationen basieren auf dem Benutzen der Java Funktion random, die nicht sehr genau ist. Das bedeutet, dass, wenn 100% der Knoten gelöscht werden müssen, nur 99% gelöscht werden. Im Experiment 3.3 gibt es nur einen Knoten, der nicht gelöscht wurde. Das benutzte Dokument, 1b2g.xml, hat im Durchschnitt 2 Knoten pro Typ, das bedeutet, dass, wenn nur ein Knoten verglichen wird, die liefernde Ähnlichkeit groß ist und eins, wenn nur ein Knoten von diesem Typ existiert. Das Experiment wurde noch einmal mit 1b2g.xml durchgeführt. Für pbbRemoval =1, ergab sich auch �2=1.
38
Kapitel 7 Zusammenfassung und Ausblick Die Aufgabenstellung der Diplomarbeit bestand im Entwurf und der experimentellen Implementierung eines Programms, mit dem die Ähnlichkeit zwischen zwei XML Dokumenten geschätzt werden kann. Der Vergleich zwischen XML Dokumenten ist nicht so einfache Aufgabe wie das Vergleichen zwischen Flachdokumenten, weil XML eine Struktur besitzen. Auch wenn die Dokumente das selbe Generatorschema haben, ist die Struktur von den Dokumenten nicht die gleiche, auf Grund der Existenz von freiwilligen oder mehrwertigen Elementen. Aktuelle Methoden, die die Ähnlichkeit zwischen XML Dokumenten bestimmen, basieren normalerweise auf der Berechnung der tree-edit-distance, die viel Laufzeit benötigt. In dieser Diplomarbeit wurde eine Methode vorgestellt, die die Ähnlichkeit zwischen XML Dokumenten berechnet und weniger Laufzeit braucht. Das Programm XMLStructuralSimilarity benutzt einen SAX Parser und speichert Informationen über jeden gefundenen Elementtyp in einem Vektor, dem so genannten TypesVector. Mit dieser Information berechnet das Programm die Ähnlichkeit zwischen zwei Dokumenten. Aus jedem Vektor wir eine Anzahl von Elementen genommen und gesucht, ob dieser Typ im anderen Vektor existiert oder nicht. Es werden zwei verschiedene Ähnlichkeiten berechnet, gemä�, ob nur die Namen oder auch das Niveau gleich sein muss. Die erhaltene Ähnlichkeit wird ein kalibrierter Mittelwert von beiden sein, gemä� der Parameter und �. Das Programm liefert auch eine Statistik über das Dokument, wie die Anzahl von Knoten pro Typ oder den Durchschnitt von Kindern pro Knoten und pro Knotentyp. Diese Diplomarbeit enthält weiterhin ein Programm, dem so genannten XMLModifier, der gemä� der Werte der Parameter pbbDuplication, pbbChange und pbbRemoval verschiedene Änderungen in einem XML Dokument einbringt. Um den Nutzen von XMLStructuralSimilarity zu überprüfen, werden mit XMLModifier verschiedene XML Dokumente erstellt. Danach werden sie mit dem Basisdokument durch XMLStructuralSimilarity verglichen. XMLModifier basiert auch auf SAX. Jedes Element bekommt ein Objekt mit den benötigten Änderungen. Eine Vorsetzung der Arbeit wäre die Erstellung von Nutzeroberfläche für eine effektiverer Arbeit.
39
Abbildungsverzeichnis Abb.1 SAX Parser ..................................................................................................................15 Abb.2 DOM Parser .................................................................................................................19 Abb.3 SAX Parser und MyStack ........................................................................................24 Abb.4 TypesVectorObject ...................................................................................................26 Abb.5 Das Analysieren der Effekte von pbbChosenNodes .................................................33 Abb.6 Alpha und Beta .........................................................................................................34 Abb.7 Effekt der Duplikation von Knoten in der Ähnlichkeit ...........................................35 Abb.8 Effekt der Änderung von Knotennamen in der Ähnlichkeit ....................................36 Abb.9 Effekt des Löschens von Knoten in der Ähnlichkeit ...............................................37
40
Literaturverzeichnis [1] Mining Database Structure; Or, How to Build a Data Quality
Browser,Tamraparni Dasu, Theodore Johnson, S.Muthukrishnan, Vladislav Shkapenyuk, AT&T Labs-Research.
[2] Tree-to-tree correction problem, K.C. Tai, Journal of the ACM, 26:422-433, 1979.
[3] Approximate XML Joins, S. Guha, H.V. Jagadish, N. Koudas, D. Srivastava, Ting Yu, AT&T Labs-Research, University of Pennsylvania, University of Michigan, University of Illinois.
[4] Evaluating Structural Similarity in XML Documents, Andrew Nierman, H. V. Jagadish, University of Michigan.
[5] Detecting Changes in XML Documents, Grégory Cobéna, Serge Abiteboul, Amélie Marian, INRIA, (Rocquecourt France), Columbia University (U.S.A).
[6] A Tree-based Approach to Clustering XML Documents by Structure, G.Costa, G.Manco, R.Ortale, A.Tagarelli, Instituto di Calcolo e Reti ad Alte Prestazione, ICAR-CNR, Sede di Cosenza, Università degli Studi della Calabria, DEIS.
[7] Detecting Structural Similarities between XML Documents, S.Flesca, G.Manco, E.Masciari, L.Pontieri, A. Pugliese, DEIS, University of Calabria, ISI-CNR.
Programación en castellano (Programmierung auf Spanisch): http://www.programacion.com/java Sun Microsystems, APIS Java: http://java.sun.com/j2se/1.4.2/docs/api W3C Group: http://www.w3.org The Eclipse Project: http://eclipse.org The Apache XML Project: http://xml.apache.org Galileo Computing: http://www.galileocomputing.de/openbook/javainsel3/javainsel_130002.htm
