UNIVERSIDAD DE CHILE FACULTAD DE CIENCIAS FISICAS Y MATEMATICAS DEPARTAMENTO DE CIENCIAS DE LA COMPUTACION
BÚSQUEDA Y VISUALIZACIÓN DE IMÁGENES EN MEMORIA CHILENA:
UN ENFOQUE SEMÁNTICO
MEMORIA PARA OPTAR AL TITULO DE INGENIERO CIVIL EN COMPUTACION
FELIPE IGNACIO SAAVEDRA CÉSPEDES
PROFESOR GUIA: CLAUDIO GUTIERREZ GALLARDO MIEMBROS DE LA COMISION: CARLOS HURTADO LARRAIN
SANTIAGO DE CHILE SEPTIEMBRE 2007 RESUMEN DE LA MEMORIA PARA OPTAR AL TITULO DE INGENIERO CIVIL EN COMPUTACION POR: FELIPE SAAVEDRA CESPEDES FECHA: 23/10/2007 PROF. GUIA: Sr. CLAUDIO GUTIERREZ.
BÚSQUEDA Y VISUALIZACIÓN DE IMÁGENES EN MEMORIA CHILENA: UN ENFOQUE SEMÁNTICO
La Web Semántica ha cambiado la forma de presentar los contenidos en la web. Ha logrado el desarrollo de nuevos estándares descriptores para los recursos presentados denominados metadatos, como también estructurarlos y relacionarlos. Esto ha permitido una ganancia en cuanto a expresividad de contenidos, a la vez de posibilitar su interacción tanto por la profundidad de las relaciones como por la interactividad lograda con el usuario. En la actualidad, se están utilizando metadatos principalmente como una manera de relacionar los recursos y almacenar mayor información descriptiva sobre recursos de distintas naturalezas (textos, multimediales, etc). Aún no resulta común encontrar aplicaciones que permitan al usuario interactuar directamente con las relaciones proporcionadas por el modelo de datos inherente de algún portal, y si se añade un interés especial en contenidos multimediales es aún menor. Un caso particular se encuentra en el sitio web de Memoria Chilena, cuyos contenidos presentan metadatos. En el siguiente trabajo se proporciona un enfoque para lograr explotar los metadatos y brindar mayor expresividad para el usuario final, con el motivo final de presentar recursos visuales que faciliten al usuario explorar contenidos y realizar búsquedas de contenidos. El trabajo se encuentra dividido en tres etapas de su desarrollo. En una primera instancia se presenta distintas soluciones para modelar los metadatos descriptivos de las imágenes presentadas de manera de permitir relaciones naturales existentes de la catalogación de estas. Luego se presenta una solución lógica para el manejo y la interacción de los metadatos, logrando ser lo más abstracto posible para obtener una solución generalizada. Finalmente se brinda la visualización de contenidos que interactúa con el modelo lógico anterior, mediante el uso de tecnologías neutrales. Resultado de este trabajo es posible concluir que el explotar los metadatos existentes en catalogaciones de contenidos, no tan sólo sirve para proporcionar un análisis general sobre ellos, sino también permite mediante tecnologías visuales, brindar mayor expresividad a estos contenidos, permitiendo encontrar conceptos de recursos relacionados que antes permanecían ocultos al usuario. Gracias a esto es posible no tan sólo reducir el tiempo de búsqueda para los usuarios, sino también cambiar la manera en que se realizan las búsquedas actualmente. ´Indice general
1. Introduccion´ 1
1.1. ConceptosB´asicos...... 4
1.1.1. MemoriaChilena ...... 4
1.1.2. ResourceDescriptionFramework(RDF) ...... 4
1.1.3. DublinCoreMetadataInitiative(DCMI) ...... 5
2. Problema 6
2.1. Motivaci´on...... 6
2.2.Impacto ...... 8
2.3. ObjetivosdelTrabajo ...... 9
2.3.1. ObjetivoGeneral ...... 9
2.3.2. ObjetivosEspec´ıficos ...... 9
2.4. PlandeTrabajo ...... 9
III ´INDICE GENERAL
3. Antecedentes 12
3.1. DatosGenerales...... 12
3.2. Estructuraci´onde datos enMemoriaChilena ...... 15
3.3. DublinCoreMetadataInitiative(DCMI) ...... 18
3.4. Visualizadores...... 20
3.5. Bibliotecas...... 21
3.5.1. JRDF...... 21
3.5.2. RDF2Go ...... 21
3.5.3. JENA...... 22
3.5.4. SESAME...... 22
4. Solucion´ Propuesta 23
4.1. AspectosGenerales ...... 23
4.2. ModeloL´ogicodeMetadatos ...... 24
4.2.1. ErroresaConsiderar ...... 25
4.2.2. EstructuradelosRecursos ...... 27
4.2.3. Definici´ondelModelo...... 28
4.3. Exploraci´ondeMetadatos ...... 38
IV ´INDICE GENERAL
4.3.1. LectorMetadatosRDF/XML ...... 39
4.3.2. ManejadorOntolog´ıaDublinCore ...... 40
4.3.3. ManejadordeModeloparaMemoriaChilena ...... 41
4.4. Visualizaci´ondeMetadatos ...... 41
4.4.1. Visualizaci´onEst´atica ...... 42
4.4.2. Interacci´onconExplorador ...... 43
5. Solucion´ Implementada 44
5.1. Obtenci´on y Creaci´on de Metadatos RDF/XML ...... 44
5.1.1. ModeloRDF/XMLImplementado ...... 46
5.1.2. CreadordeMetadatos ...... 52
5.2. ExploradordeMetadatos ...... 54
5.2.1. LectorMetadatosRDF/XML ...... 55
5.2.2. ManejadordeOntolog´ıaDublinCore ...... 55
5.3. VisualizadordeMetadatos ...... 58
5.3.1. Interacci´onconExplorador ...... 58
5.3.2. Visualizaci´on ...... 60
6. Resultados Obtenidos y Esperados 62
V ´INDICE GENERAL
7. Conclusiones y Trabajo Futuro 65
7.1. TrabajoFuturo...... 65
7.1.1. Visualizaci´on ...... 65
7.1.2. Exploraci´on ...... 66
7.1.3. OtrasMejoras ...... 66
7.2. Conclusiones ...... 67
VI ´Indice de cuadros
5.1. Relaci´on existente entre Metadatos y Atributos de TablasenBD...... 45
VII ´Indice de figuras
1.1. WebdeMemoriaChilena ...... 4
2.1. Puntosimportantesenunab´usqueda ...... 7
2.2. Visualizaci´on de una b´usqueda en Memoria Chilena ...... 8
2.3. Planificaci´ondeProyecto ...... 10
2.4. Planificaci´ondeProyectoModificada ...... 11
3.1. Modelo de b´usqueda cl´asico vs Modelo WIDE de b´usqueda ...... 12
3.2. EstructuradeMetadatosdeunaImagen ...... 16
4.1. EsquemadelaSoluci´on...... 24
4.2. Esquema de la Soluci´on: Detalle de Generador de Metadatos ...... 25
4.3. EstructuradeRecursosdeMemoriaChilena ...... 28
4.4. Modelo conceptual RDF de una Unidad Tem´atica ...... 29
VIII ´INDICE DE FIGURAS
4.5. Modelo conceptual RDF de unDetalleTem´atico ...... 29
4.6. ModeloconceptualRDFdeunaImagen ...... 30
4.7. SegundomodeloconceptualRDF ...... 34
4.8. TercermodeloconceptualRDF ...... 37
4.9. Esquema de la Soluci´on: Detalle de Explorador de Metadatos ...... 39
4.10.PosiblePresentaci´onVisualdeDatos ...... 42
4.11.Presentaci´onVisualdeDatosEsperada ...... 43
5.1. ModeloVisualactual ...... 61
6.1. Relaciones de pintores realistas chilenos por medio de im´agenes ...... 62
6.2. Secuencia de b´usqueda de relaciones de pintores realistaschilenos ...... 64
IX Cap´ıtulo 1
Introduccion´
La Web Sem´antica [TBLL01] es un concepto que ya lleva alg´un tiempo de vida y que ha ganado gran auge, siendo uno de los principales focos de inter´es para la implementaci´on futura de la web, y que ya en la actualidad, posee un gran n´umero de portales y aplicaciones adopt´ando sus est´andares.
B´asicamente, la web sem´antica pretende superar las limitaciones de la actual implementaci´onweb, y para ello, resulta necesario la descripci´onde los contenidos (recursos disponibles en l´ınea) junto con sus existentes relaciones. De manera de satisfacer esta necesidad se han utilizado lenguajes descriptivos denominados ontolog´ıas. Estas han permitido descripciones de conceptos, ideas y recursos disponibles en la web con naturalezas muy variadas.
Adicionalmente, resultado de la necesidad de automatizar y ser comprendidas por m´aquinas estas descripciones, se han generado est´andares para la descripci´onformal de recursos. Es as´ı, que el formato estandarizado en la actualidad se denomina RDF [Wor04a]. Este formato proporciona la estructura o sintaxis necesaria para la descripci´on sin ambig¨uedad, ya sea de recursos o relaciones.
Con esto, dichas descripciones dan nacimiento a los denominados metadatos sem´anticos1 o simplemente los denominados metadatos a lo largo de este trabajo, con los cuales nos referimos a la capa de informaci´ondescriptiva de recursos web.
1´Indices descriptivos de los recursos que se˜nalan, basados en alguna ontolog´ıa y descritos utilizando el formato RDF
1 Es as´ı como en la actualidad ya se encuentran disponibles en la web, portales, aplicaciones, herramientas, etc., que permiten el manejo, presentaci´ony utilizaci´onde estos recursos con sus respectivos metadatos.
Dentro de estos portales con metadatos descriptivos nos encontramos con Memoria Chilena2. Memoria Chilena es un sitio web, dependiente de la Biblioteca Nacional de Chile, que se encuentra dedicado a reunir la historia que conforma la identidad de nuestro pa´ıs. Dentro de la informaci´oncontenida por este portal, se encuentra una gran base de datos de im´agenes catalogadas, cuya descripci´onactualmente, puede ser rescatada en formato RDF y ser comprendida mediante la utilizaci´ondel lenguaje establecido por la entidad Dublin Core Metadata Initiative 3.
A pesar del gran entusiasmo existente en la implementaci´onde la web sem´antica, a´un es dif´ıcil encontrar aplicaciones que demuestren el gran potencial que es capaz de entregar. Siendo a´un aplicaciones muy experimentales y enfocadas principalmente a comprender la naturaleza de los datos. Es as´ıque las aplicaciones visuales existentes son raras y escasas, y si adem´as ponemos la limitaci´onde que funcione directamente sobre la web, reduce las posibilidades a´un en mayor grado. Esto es precisamente lo que ocurre en Memoria Chilena, que a pesar de haber adoptado la descripci´onde recursos mediante los est´andares definidos para la web sem´antica, a´un no son aprovechadas dichas descripciones.
Debido a estas razones, se pretende desarrollar una aplicaci´onweb que permita visualizar las im´agenes contenidas en Memoria Chilena y sus relaciones mediante la utilizaci´on de los metadatos existentes. La presentaci´on del contenido pretende ser intuitivo para el usuario, basado en una estructura relacional dada por la informaci´on obtenida en los metadatos. Con esto se pretende desplegar los recursos, resultados de b´usquedas proporcionadas por un usuario, brindando la posibilidad de explorar otros recursos directamente relacionados, de manera que el usuario pueda llegar de manera visual al recurso que deseaba conseguir.
Es as´ıque a lo largo de este trabajo se pretende brindar una aplicaci´onweb, que en vez de permitir la comprensi´ony naturaleza de los datos, permita lograr una exploraci´on de estos bas´andose en sus metadatos, con el objetivo de reducir los tiempos de b´usqueda por el uso de relaciones intuitivas que se pueden lograr expresar con un modelo adecuado de metadatos y una aplicaci´onque explote dicho modelo. Es as´ıque el siguiente trabajo se encuentra dividido en siete cap´ıtulos: Cap´ıtulo 1, con una breve descripci´ondel trabajo y conceptos utilizados; Cap´ıtulo 2, mencionando las actuales dificultades presentes y los objetivos que se desean alcanzar; Cap´ıtulo 3, describiendo las actuales tecnolog´ıas; Cap´ıtulo 4, describiendo en detalle la soluci´onplanteada en el trabajo; Cap´ıtulo 5, donde se detalla la soluci´onfinalmente implementada; Cap´ıtulo 6, explicando los resultados obtenidos por la soluci´on; y Cap´ıtulo 7, expresando conclusiones del trabajo y posibles
2www.memoriachilena.cl 3www.dublincore.org
2 mejoras.
3 1.1. CONCEPTOS BASICOS´
1.1. Conceptos Basicos´
1.1.1. Memoria Chilena
Memoria Chilena es un portal de contenidos culturales que ofrece investigaciones y documentos relativos a los temas claves que conforman la identidad de Chile, accesibles a trav´es de las ´areas de Historia, Literatura, Ciencias Sociales, M´usica y Artes Visuales.
Tambi´en es una biblioteca virtual, que pone al alcance de navegantes de todo el mundo los valiosos materiales que preserva la Biblioteca Nacional de Chile y otras instituciones de la Direcci´onde Bibliotecas, Archivos y Museos (DIBAM): libros, fotograf´ıas, cartas, manuscritos, Figura 1.1: Web de Memoria Chilena ilustraciones, mapas y registros sonoros.
Cada documento digitalizado cuenta con una p´agina de presentaci´on, donde se incluye informaci´oncatalogr´afica. Este material digital cuenta con metadatos en formato XML / RDF seg´un el est´andar Dublin Core. Estos datos se encuentran anexados a cada p´agina.
1.1.2. Resource Description Framework (RDF)
En la actualidad la web es una red de recursos relacionados. El contenido de estos recursos es desconocido para los computadores. Los navegadores muestran el contenido y los motores de b´usqueda funcionan buscando ocurrencias de alguna palabra sin entregar mayor entendimiento del contenido a la m´aquina. Debido a esto el formato RDF pretende entregar mayor conocimiento de los recursos existentes. Este modelo se basa en la idea de convertir las declaraciones de los recursos en expresiones con la forma sujeto-predicado-objeto (conocidas en t´erminos RDF como tripletes). El sujeto es el recurso, es decir aquello que se est´adescribiendo. El predicado es la propiedad o relaci´on que se desea establecer acerca del recurso. Por ´ultimo, el objeto es el valor de la propiedad o el otro recurso con el que se establece la relaci´on. La combinaci´on de RDF con otras herramientas como RDF Schema y OWL permite a˜nadir significado a las p´aginas, y es
4 1.1. CONCEPTOS BASICOS´ una de las tecnolog´ıas esenciales de la Web sem´antica. Informaci´onm´as detallada de este est´andar puede ser encontrada en RDF Primer [Wor04a].
1.1.3. Dublin Core Metadata Initiative (DCMI)
Dublin Core, como es llamada tambi´en, es una organizaci´onabierta dedicada al desarrollo de est´andares para metadatos, de manera que permitan la interoperaci´onen l´ınea de ellos y que soporten una gran gama de prop´ositos y modelos de negocios.
Para este fin, promueven la utilizaci´onde vocabularios especializados de metadatos para describir recursos que permitan sistemas con mayor expresividad e inteligencia frente a las b´usquedas de recursos.
El nombre viene por Dublin (Ohio, Estados Unidos), ciudad que en 1995 alberg´ola primera reuni´ona nivel mundial de muchos de los especialistas en metadatos y Web de la ´epoca.
5 Cap´ıtulo 2
Problema
2.1. Motivacion´
Memoria Chilena, posee una base de datos con informaci´onhist´orica cultural de Chile muy rica. Estos datos se encuentran relacionados entre s´ımediante un extenso trabajo por parte de los desarrolladores de Memoria Chilena, logrando una buena cohesi´onde los temas presentados, entregando as´ı, un buen motor de b´usqueda y una excelente herramienta para sus posibles usuarios.
Entre los datos presentados, se encuentran gran variedad de contenidos multimediales, sobre los cuales se posee una capa superior de metadatos estructurados en RDF/XML, por medio de los cuales se realizan las b´usquedas y se relacionan los temas.
Estos metadatos se encuentran estructurados seg´un la ontolog´ıa 1 creada por la organizaci´onDublin Core [Dub06].
Para entregar el mayor provecho al usuario del portal es necesario poder entregar gran expresividad y disponibilidad de la informaci´onalmacenada. Puntos importantes que ayudan a una b´usqueda pueden ser apreciados en la figura 2.1. Se puede mencionar que por parte del lenguaje, m´etodos de b´usqueda, la informaci´onutilizada para las b´usquedas y las relaciones, Memoria Chilena se encuentra realizando un buen trabajo, pero se presentan ciertas falencias dentro de lo que es la visualizaci´ony la navegaci´onde los resultados. A
1Modelo de datos que representa un determinado dominio y se utiliza para razonar sobre los objetos existentes en el dominio y las relaciones que existen entre ellos.
6 2.1. MOTIVACION´
Busqueda (Imágenes) Lenguaje (Keywords Utilizados) Resultados Navegación Visualización
Información Métodos de Utilizada Aprovechar Exceso de Relaciones Búsqueda Imágenes Información Escasas
Figura 2.1: Puntos importantes en una b´usqueda pesar del gran contenido multimedial y enfoc´andonos en las im´agenes, el despliegue de resultados no entrega directamente dicho material, sino m´as bien los t´ıtulos que poseen los datos(Ver Figura 2.2. Esto obliga al usuario a leer dichos t´ıtulos, relacionar la idea de lo buscado con dicho t´ıtulo, y una vez hecho esto acceder a la imagen. Si no resulto ser lo buscado obliga al usuario a devolverse y volver a repetir los pasos. Este proceso puede resultar muy engorroso y dif´ıcil de seguir por parte de un usuario poco frecuente. Adicionalmente es un proceso est´atico y sin gran interacci´on, perdiendo el enfoque central que se desea lograr con este tipo de aplicaciones.
De manera de ilustrar estas falencias se desear´ıa encontrar lo siguiente:
“Fotos de Bernardo O’Higgins”-¿No arroj´oresultados, la b´usqueda se tuvo que re-estructurar con Higgins.
“Fotos de la Esmeralda”-¿Se logra encontrar encontrar im´agenes de la corbeta y relacionarla con Lord Cochrane. Se pierde conexi´oncon combate.
“Im´agenes sobre el combate naval de Iquique”-¿Se encuentra informaci´on relacionada con combate y algunas l´aminas. Relaciones con Arturo Prat y la Armada del siglo XIX. No se puede vincular a la Esmeralda.
Estas b´usquedas simples, demuestran que a´un faltan relaciones dentro de los temas. Las relaciones de las im´agenes son s´olo por medio de los temas (Archivos de textos explicativos) que utilizan las im´agenes. Es decir si un tema no posee la imagen entonces no existe relaci´on.
A pesar de las falencias mencionadas, Memoria Chilena tiene una rica estructura en metadatos y una utilizaci´onde excelentes tecnolog´ıas. Explotando todas las capacidades que entregan dichas tecnolog´ıas se lograr´ıa entregar una soluci´ona lo mencionado.
7 2.2. IMPACTO
2.2. Impacto
(a) Presentaci´on de resultados de la b´usqueda (b) Visualizaci´on de un resultado
Figura 2.2: Visualizaci´on de una b´usqueda en Memoria Chilena
Actualmente Memoria Chilena presenta los resultados de b´usqueda de una manera cl´asica (Ver Figura 2.2), no permitiendo una mayor interacci´onentre el usuario y la aplicaci´onweb. Adicionalmente, en nuestro caso, los contenidos buscados son im´agenes, por lo que un usuario quisiera visualizar los resultados desplegados en vez del engorroso proceso de leer los encabezados para luego visualizarlos. Con lo planteado, se pretende mejorar la navegaci´onen un proceso de b´usqueda, permitiendo ser intuitiva por parte del usuario. Esto se lograr´amediante relaciones de conceptos conocidos entre las distintas im´agenes. Tambi´en al agregar un modelo de datos estructurados utilizando la existente capa de datos en RDF y explotando a´un m´as la ontolog´ıa entregada por Dublin Core, se podr´ıa entregar una mejor visualizaci´onde la informaci´ondesplegada al usuario.
As´ıpreguntas como pr´oceres de la patria relacionados por tiempo que actualmente no puede ser efectuada por la implicancia de conocer el nombre de cada uno, pueden ser resueltas al explotar relaciones de la ontolog´ıa Dublin Core como son la utilizaci´onde t´erminos como: IsPartOf, IsReferencedBy, Period, Point, entre otras permitir´ıa relacionar dichos contenidos sin tener que reformular una b´usqueda. As´ı el ejemplo mencionado puede ser resuelto al conocer un nombre en la b´usqueda por ejemplo Arturo Prat, y luego utilizando la relaci´onPeriod que entrega una relaci´on de tiempo, es posible relacionar dicha imagen con los distintos sucesos ocurridos en el mismo espacio de tiempo. Adicionalmente como los contenidos son visualmente entregados, es f´acil para el usuario navegar la b´usqueda una vez iniciado el proceso con un s´olo concepto “Arturo Prat”.
8 2.3. OBJETIVOS DEL TRABAJO
2.3. Objetivos del Trabajo
2.3.1. Objetivo General
Visualizar im´agenes aprovechando un modelo de metadatos estructurado en formato RDF, que permita no tan s´olo presentar una imagen est´atica de la red, sino que permita la exploraci´onde una b´usqueda en particular mediante la navegaci´on.
2.3.2. Objetivos Espec´ıficos
Obtener permisos y esquemas utilizados sobre los metadatos de Memoria Chilena.
Crear un modelo de datos estructurados en RDF basado en t´erminos y conceptos de la ontolog´ıa Dublin Core, de manera que permita responder las preguntas frecuentes realizadas sobre las im´agenes y relacione los metadatos existentes.
Crear heur´ıstica de b´usqueda basada en la utilizaci´onde algunos conceptos de la ontolog´ıa Dublin Core. Si resulta factible, desarrollar heur´ıstica de b´usqueda basada en ranking sobre relaciones sem´anticas.
Evaluar motores de b´usqueda para consultas sobre datos en formato RDF, para determinar cu´al se adapta de mejor manera a las necesidades de este proyecto.
Evaluar motores de visualizaci´onde redes, ya sean RDF o no, que puedan ser adaptadas al proyecto.
2.4. Plan de Trabajo
A continuaci´onla especificaci´onde los hitos a alcanzar:
1. Presentaci´onde proyecto a encargados de Memoria Chilena Biblioteca Nacional.
2. Investigaci´onde algoritmos de costos para redes sem´anticas.
3. Estudio de metadatos a incorporar.
4. Modelamiento de relaciones y red de datos RDF.
9 2.4. PLAN DE TRABAJO
5. Dise˜no de consultas gen´ericas a realizar.
6. Adaptaci´on, creaci´onde algoritmos de ranking para redes sem´anticas.
7. Adaptaci´on, creaci´onde visualizador.
8. Test, y an´alisis de resultados.
9. Generar documentaci´ony estudio sobre las tecnolog´ıas utilizadas y resultados obtenidos.
Algunos de los hitos mencionadas pretenden tenerse analizados antes de comenzar el proyecto. As´ıel desglose de estos ´ıtemes quedan expresados en la tabla de la Figura 2.3.
Figura 2.3: Planificaci´on de Proyecto
Debido a contratiempos fue necesario reajustar la planificaci´on para lo cual se tuvo que a˜nadir y quitar ciertas tareas por un replanteamiento de la soluci´on. As´ıel plan de trabajo se puede apreciar en la tabla de la Figura 2.4.
10 2.4. PLAN DE TRABAJO
Figura 2.4: Planificaci´on de Proyecto Modificada
11 Cap´ıtulo 3
Antecedentes
3.1. Datos Generales
Muchos estudios se han realizado para le recuperaci´onde informaci´onmultimedial para la web sem´antica y tambi´en para solucionar los problemas de visualizaci´on. Siendo un aspecto vital la forma en que se realizan las b´usquedas y se interact´uan con los resultados.
1 2 3 4 Explorar Presentación & Búsqueda Filtrado & Especificar Navegar
1 2 3 4 5 Especificar Búsqueda Filtrado Presentación Seleccionar 5 Resultados 1 de Re-Especificar ... Búsqueda (a) En el modelo de b´usqueda cl´asico se especifican 5 pasos: (b) En el modelo WIDE de b´usqueda ocurren 5 1 Especificar la b´usqueda por parte del usuario, 2 Buscar, pasos: 1 Especificar y Explorar, donde el usuario 3 Filtrar y 4 Presentar resultados por el computador, 5 ingresa la b´usqueda, 2 B´usqueda y 3 Filtrado Seleccionar es donde el usuario visualiza los resultados que de resultados por la m´aquina, 4 Presentar y pueden ser ´utiles. Estos pasos son repetidos especificando Explorar resultados, donde se retro-alimenta el nuevas b´usquedas por parte del usuario. buscador con la informaci´on ya utilizada sin necesidad de re-especificar la b´usqueda.
Figura 3.1: Modelo de b´usqueda cl´asico vs Modelo WIDE de b´usqueda
Dentro de los modelos de b´usqueda utilizados se pueden mencionar un modelo cl´asico y el modelo de recuperaci´onde informaci´onbasado en la arquitectura WIDE [cbi05]. Actualmente las b´usquedas se basan en el modelo cl´asico de recuperaci´onde la informaci´on (Ver Figura 3.1a) y es como lo realiza Memoria Chilena. Este m´etodo, presenta una serie de dificultades para el usuario, no permitiendo entregar de manera natural la informaci´on. Esto se debe a que por una parte, a pesar de que la b´usqueda se realiza con lenguaje natural, el usuario necesita conocer c´omo se encuentran ordenados los datos, y qu´ebuscar
12 3.1. DATOS GENERALES para lograr realizar una b´usqueda exitosa. Esto se debe a que no se puede distinguir qu´ees lo que el usuario realmente necesita, y c´omo debe el usuario pedir lo que desea para ser entendido. Para dejar claro este concepto en las b´usquedas realizadas en el portal de Memoria Chilena, se utilizan los t´ıtulos de los metadatos, es decir para buscar algo de manera certera es necesario conocer las relaciones t´ıtulo-imagen. Otro problema que presenta el modelo cl´asico, es que en cada b´usqueda que realiza el usuario, la informaci´on obtenida no se utiliza en b´usquedas posteriores, obligando al usuario a realizar un proceso de refinamiento manual. Esto genera desgaste por parte del usuario quien es el que finalmente recibe el costo de descubrir y aprender c´omo debe realizar la b´usqueda de manera que sea entendido y reciba la informaci´ondeseada.
Una manera distinta de realizar la b´usqueda es mediante el modelo basado en la arquitectura WIDE(Ver Figura 3.1b) de recuperaci´onde la informaci´on. Aqu´ıgracias a los metadatos incluidos y la estructuraci´onde los datos en un grafo relacionado se puede lograr una mejor interacci´onentre el usuario y el repositorio de contenidos, permitiendo realizar b´usquedas con mayor interacci´ony disponer de m´as relaciones entre los datos. Si adicionalmente se entrega una interfaz gr´afica para explorar las relaciones y los resultados, se logra una excelente combinaci´onpara explotar las capacidades de las herramientas. Ejemplo de esto y m´as detalles pueden ser hallados en A Semantic Web Based Approach to Multimedia Retrieval [cbi05], donde se describe un proceso de b´usqueda y presentaci´on de contenidos para una empresa automotriz con resultados positivos.
Otro punto a analizar es la presentaci´on visual de los resultados. Actualmente la tecnolog´ıa permite visualizar redes mediante herramientas basadas en algoritmos est´andares y heur´ısticas. Dentro de estos algoritmos se pueden mencionar el m´etodo circular, que consiste en dibujar los nodos en un contorno circular y a trav´es del c´ırculo sus relaciones, m´etodos de ubicaci´onaleatoria de nodos, y una variaci´onde este ´ultimo es el m´etodo de resortes que modela las relaciones como si fueran resortes y se presenta el grafo de menor energ´ıa [Sim96].
Todos los m´etodos mencionados y otros conocidos son capaces de visualizar redes. Pero como consecuencia del r´apido crecimiento de la informaci´ony de la complejidad de las redes existentes en la actualidad se presenta el problema de c´omo representar dicha informaci´onde forma ´util y visualmente entendible. Debido a esto, se han creado m´etodos de Ranking, y formas de evitar desplegar la totalidad de la red y enfocar la vista a ciertos nodos y relaciones en la red. As´ıse han implementado t´ecnicas de visualizaciones en fragmentos basados principalmente en distintas representaciones utilizando zoom [VD04]. As´ı, se representan enlaces con mayor peso en una vista amplia, agrupando nodos mediante conceptos de cartograf´ıa. A modo de ejemplo en un mapa electr´onico, se representan ciudades como puntos pero al ir acerc´andose estas ciudades son desplegadas entregando detalle de su contenido. En paralelo se puede presentar una red, mostrando mayor detalle a medida que se profundiza en la b´usqueda sobre el grafo.
13 3.1. DATOS GENERALES
LSDIS1 es una organizaci´onespecialmente enfocada a resolver estos problemas y ha desarrollado herramientas y metodolog´ıas para entregar buenos resultados frente a la visualizaci´onde extensas redes y algunos proyectos est´an especialmente enfocados al desarrollo de la web sem´antica y en especial a las redes RDF. Su objetivo se basa en capturar el inter´es del usuario en denominadas regiones que se obtienen mediante los contextos de b´usquedas entregadas por el usuario. Son capaces de realizar esto ´ultimo mediante sus propios esquemas RDF basadas en ontolog´ıas que han desarrollado para este prop´osito. Herramientas desarrolladas por LSDIS se encuentran SAV [sem06], SET [sem06], PGV [sem06]. Estas herramientas son visualizadores de grafos RDF que nos entregan ideas sobre lo que se puede lograr en b´usqueda y visualizaci´on. SAV [LD06], entrega una representaci´ongr´afica de los datos y tambi´en t´ecnicas de colapsamiento, basadas en algoritmos de ranking sobre relaciones sem´anticas [hal04]. Est´adise˜nado exclusivamente para contenidos multimediales, lo cual es lo que deseamos, pero necesita de un equipo potente para la visualizaci´onadem´as que no corre v´ıa web. PGV es muy similar a SAV, con la gran ventaja de que corre v´ıa web y es ligero en costos de computaci´ony visualiza relaciones seg´un la consulta ingresada, pero la visualizaci´ones muy b´asica, no apta para contenidos multimediales. Como ´ultimo punto en contra sobre estas herramientas, es que como se mencion´o,est´an basadas en una ontolog´ıa propia, y actualmente es un gran problema la compatibilizaci´onentre distintas ontolog´ıas, lo cual nos imposibilitar´ıa utilizar dichas herramientas en Memoria Chilena. Debido a este mismo problema no es posible encontrar herramientas que tengan buenos motores de b´usqueda sobre grafos RDF que puedan ser utilizadas, ya que para realizar buenas b´usquedas y eficientes es necesario conocer el dominio (la ontolog´ıa utilizada), y como se mencion´ono es posible compatibilizar los dominios.
Relajando los criterios en la herramientas perdiendo ciertas caracter´ısticas que entregan las redes RDF se pueden encontrar muchas herramientas de visualizaci´onde grafos, cada cual con sus ventajas y desventajas.
Otras herramientas para la representaci´onde redes en RDF, que incorporan t´ecnicas de visualizaci´onmencionadas,se pueden mencionar Longwell [W3C06], Welkin [W3C06]. Estas herramientas permiten desplegar y navegar sobre datos en RDF, cada cual manteniendo un enfoque separados sobre la visualizaci´on, pues resuelven objetivos diferentes. En Longwell, se debe tener informaci´ona priori sobre la estructura de datos a trabajar, lo cual no es tan grave, pero s´olo permite navegar los datos en forma de texto. Welkin, entrega una visualizaci´onm´as atractiva, permitiendo navegar la estructura mediante la representaci´ongr´afica de ´esta por una estructura de grafos, acerc´andose m´as a lo que necesitamos. Sin embargo, no permite escalabilidad, vale decir, t´ecnicas de colapsar y zoom, confundiendo al usuario con grafos con muchos datos, lo que es uno de los mayores problemas latentes en la representaci´onen grafos.
1Large Scale Distributed Information Systems Laboratory.http://lsdis.cs.uga.edu/
14 3.2. ESTRUCTURACION´ DE DATOS EN MEMORIA CHILENA
3.2. Estructuracion´ de datos en Memoria Chilena
Memoria Chilena consta de una base de datos en crecimiento, con m´as de 60.000 documentos publicados en el portal. Un detalle de los documentos publicados hacia Agosto del 2005 son:
422 Sitios Tem´aticos
6 Temas publicados en Chile para ni˜nos
421.922 p´aginas digitalizadas
183 minutos de audio digitalizados
Un detalle de los documentos digitalizados:
Tipo de material No Libros 1.357 Art´ıculos 54.222 Peri´odicos 112 Revistas 619 Manuscritos 30 Cartas 121 Im´agenes 6.952 Planos 84 Mapas 237 Partituras 12 Audio 117 Total documentos publicados 63.863
Como nuestro objetivo es trabajar sobre las im´agenes, se puede decir que nuestro conjunto de datos consta con aproximadamente 7.000 datos2
El material presentado por Memoria Chilena se encuentra ordenado a trav´es de los denominados Sitios Tem´aticos, que son separaciones del material seg´un describan procesos, hechos, personajes u obras relevantes del imaginario cultural e hist´orico de
2Los n´umeros presentados correspondes a Agosto del 2006. La pol´ıtica de Memoria Chilena es actualizar sus contenidos cada 2 meses, incrementando el n´umero de documentos digitalizados
15 3.2. ESTRUCTURACION´ DE DATOS EN MEMORIA CHILENA
Chile. Estos sitios tem´aticos, son la base estructural de Memoria Chilena, siendo estos los que relacionan el material mediante una presentaci´onde dicho tema, basado en un texto descriptivo, el cual posee hiper v´ınculos que permiten profundizar el material y visitar otros sitios tem´aticos. Tambi´en se debe resaltar que estos sitios tem´aticos son los que poseen los documentos audiovisuales digitalizados como material de apoyo.
Debido a la estructuraci´onmencionada, los documentos audiovisuales, y en el caso particular estudiado, las im´agenes no poseen ning´un tipo de relaci´onentre s´ım´as que la que se puede obtener por medio de los sitios tem´aticos que las utilizan.
Como hab´ıa sido mencionado, los documentos audiovisuales se encuentran estructurados en dos capas: los metadatos y los datos. A continuaci´on se mencionar´ael uso actual y la estructuraci´onde estos.
Figura 3.2: Estructura de Metadatos de una Imagen
Cada documento digitalizado, posee una capa de metadatos descritos en formato RDF (Ver Figura 3.2). La estructura usual de uno de estos archivos se compone usualmente de las siguientes t´erminos:
Description: Tag de apertura para toda descripci´on de recursos seg´un el
16 3.2. ESTRUCTURACION´ DE DATOS EN MEMORIA CHILENA
formato RDF. El valor m´as importante encontrado aqu´ı se expresa mediante el atributo correspondiente a la sintaxis de RDF descrita por la W3C con el nombre about. Este valor nos menciona el recurso que se va a describir a continuaci´on. En Memoria Chilena se utiliza existe un grave error en la utilizaci´on de este tag, por lo que su valor siempre queda expresado por: rdf:about=“http://dublincore.org/documents/dcmes-xml/”. Esto es un error bastante grave en la estructura RDF, ya que no nos permite distinguir sobre el recurso al cual pensamos describir.
identifier: un identificador utilizado por memoria chilena. Corresponde con la URL donde se puede encontrar dicho material.
title: representa al t´ıtulo con que se describe a la imagen. Proporcionada por Memoria Chilena.
creator: corresponde al autor de la imagen.
subject: descripciones de la imagen proporcionadas por Memoria Chilena. A cada imagen se le puede otorgar una o m´as descripciones dependiendo de la catalogaci´on dada por Memoria Chilena.
subject.categoria: descripci´on de una categor´ıa de clasificaci´on realizada por Memoria Chilena. Puede otorg´arsele una o m´as categor´ıas a cada imagen.
relation: siempre es expresada en pares. La primera parte del par se refiere al t´ıtulo de alg´un sitio tem´atico que contiene dicha imagen. La segunda parte del par se refiere a la URL donde se encuentra dicho sitio tem´atico. Estos pares pueden existir una o m´as veces, dependiendo del n´umero de sitios tem´aticos que utilicen dichas im´agenes. Es de inter´es mencionar, que esta estructura utilizada por Memoria Chilena, no conforma los est´andares descritos por DCMI, que debiera permitirnos distinguir la informaci´onsin importar el orden de los tags.
publisher: corresponde a la entidad o persona que public´ola imagen descrita. Como el portal y los contenidos pertenecen a Biblioteca Nacional de Chile, este elemento posee siempre ese valor.
W3CDTF: metadato contenedor para fechas (contexto que define un esquema para la codificaci´onde fechas). Representa reglas para codificar fechas y horas basadas en el est´andar ISO-8601.
date: fecha en la cual el documento fue digitalizado y subido como contenido dentro de Memoria Chilena.
type: describe que tipo de imagen es. Tipos son descriptores elegidos por Memoria Chilena. Estos tipos pueden ser: Image.L´amina-¿que describe que la imagen es una l´amina de alguna publicaci´ono bien un recuadro o pintura. Image.Fotograf´ıa -¿identifica a una imagen como si fuera una fotograf´ıa.
format: describe el formato o tipo de archivo en que se encuentra la imagen. Puede ser: Image/tipo-de-archivo. En el espacio muestral estudiado s´olo se encontr´oel tipo jpg, siendo todas las im´agenes pertenecientes al formato Image/jpg
17 3.3. DUBLIN CORE METADATA INITIATIVE (DCMI)
source.extraidodesde: pocas im´agenes contienen este metadato. Expresa el lugar f´ısico de donde se obtuvo la digitalizaci´onde la imagen. Metadato extraidodesde es una extensi´ondel elemento source y es original de Memoria Chilena.
language: corresponde al idioma y es descrito por 3 letras. Todos los documentos del espacio muestral corresponden al valor spa (espa˜nol). Al ser un sitio dedicado al patrimonio del pa´ıs, es probable que todos los documentos tengan el mismo valor para el idioma.
coverage: define un contexto espacial-temporal para la imagen descrita. Dentro de este contexto se pueden encontrar los metadatos temporal y spatial que describen tiempo y lugar geogr´afico respectivamente.
coverage.temporal: utilizado por Memoria Chilena para describir el Siglo en el cual se desarroll´oel hecho representado por la imagen. Posee los sub elementos inicio y t´ermino originales de Memoria Chilena. Estos representan el inicio y el t´ermino del hecho que representa la imagen respectivamente. Ambos sub elementos son expresados en a˜nos.
coverage.spatial: describe el lugar f´ısico donde se desarroll´oel suceso descrito por la imagen. Puede poseer uno o m´as de estos elementos describiendo el lugar. Por ejemplo se pueden utilizar Desierto de Atacama, Tarapac´a, Norte Grande, Iquique, como valores para este elemento en forma simult´anea.
rights: los derechos intelectuales a la que pertenece la imagen.
El sistema de b´usqueda se basa en b´usqueda de keywords sobre los Subject de los datos, y sobre el texto en los sitios tem´aticos. As´ıla ´unica manera de encontrar una imagen es conociendo el t´ıtulo que pudiera tener dicha imagen. De igual forma para conocer que relaci´onexiste entre im´agenes, es necesario visitar el sitio tem´atico que la contiene, para luego buscar entre los contenidos de apoyo y chequear si existe alguna relaci´on.
As´ı, los metadatos no constan de ninguna estructuraci´on. Tampoco constan de relaci´on alguna entre ellos m´as que la relaci´onindirecta ya mencionadas.
3.3. Dublin Core Metadata Initiative (DCMI)
Los metadatos de Memoria Chilena se encuentran basados en la ontolog´ıa descrita por la organizaci´onDublin Core Metadata Initiative. DCMI estructura los recursos mediante una serie de elementos o t´erminos que permiten expresar propiedades o cualidades de los recursos.
18 3.3. DUBLIN CORE METADATA INITIATIVE (DCMI)
En su estructura b´asica es posible distinguir 15 elementos descriptivos. Adicionalmente, DCMI se ha encargado de agregar m´as expresividad y relaciones de conceptos a˜nadiendo el uso de t´erminos a su vocabulario. Estos t´erminos pueden ser extensiones de los 15 elementos b´asicos, como tambi´en nuevos conceptos y est´andares para definir los valores de cada tag.
Actualmente Memoria Chilena utiliza t´erminos b´asicos para la descripci´onde sus recursos. Es de vital importancia que para que estos metadatos sean coherentes, tienen que cumplir con las reglas del modelo descrito por DCMI y como m´ınimo con las reglas de codificaci´onpara RDF/XML entregadas por la misma entidad.
No resulta de menor importancia destacar que mediante un uso exhaustivo de los t´erminos que entrega DCMI se puede lograr expresar cualidades y relacionar los distintos datos. Permitiendo as´ıuna mayor comprensi´onde la naturaleza de los datos, y abriendo las puertas a infinitas posibilidades para su posterior procesamiento y aprovechamiento de los recursos.
Finalmente en una revisi´onde los t´erminos de la ontolog´ıa se pueden destacar los siguientes:
isFormatOf: permite relacionar im´agenes seg´un su contenido intelectual, es decir, expresa lo mismo que otra imagen (misma materia).
isPartOf: relaciona el contenido como un subcontenido o submateria de otra m´as general.
isReferencedBy: la imagen es referenciada por otras im´agenes.
isReplacedBy: este contenido es reemplazado por otra.
isRequiredBy: la imagen es requerida por otra imagen (por ser contenida por la anterior).
references: la imagen referencia el siguiente recurso.
replaces: reemplaza a otro contenido.
requires: requiere otros contenidos.
tableOfContents: una lista de recursos que son sub unidades del recurso. Probablemente una mejor forma de expresar las relaciones actuales en Memoria Chilena (reemplazar el t´ermino references).
Box: permite identificar una regi´onespacial, delimitada por un contexto geogr´afico. (Una buena idea para relacionar contenidos de hechos que ocurrieron en el mismo lugar)
19 3.4. VISUALIZADORES
Period: permite identificar y relacionar contenidos seg´un su espacio temporal. Actualmente se utiliza el t´ermino coverage.temporal para expresar la misma idea y es el t´ermino utilizado para realizar b´usquedas por per´ıodos de tiempo. Una mejor idea para relacionar contenidos seg´un cuando ocurrieron.
Point: otra forma para expresar lugar geogr´afico, basado en coordenadas.
TGN: tesauro para expresar lugar geogr´afico. Una informaci´onque pudiera resultar bastante provechosa por parte de Memoria Chilena quien trabaja con una extensa enciclopedia de tesauros.
Con una primera revisi´onsobre el modelo y t´erminos proporcionados por DCMI, se preseleccionaron los mencionados. Esta preselecci´onfue realizada seg´un el criterio de responder a preguntas espec´ıficas que resultan ´util al momento de buscar relaciones entre distintos documentos. Hay que recordar que el portal es principalmente enfocado a material escolar y relacionados, por lo que b´usquedas que relacionen im´agenes seg´un espacio temporal o geogr´afico (hechos hist´oricos principalmente), o tambi´en seg´un la misma materia (relaci´onintelectual), facilitar´ıan en gran manera las b´usquedas efectuadas, permitiendo entregar m´as informaci´oncon una sola b´usqueda ingresada.
3.4. Visualizadores
En una primera instancia, se buscaron visualizadores para grafos RDF que adem´as solucionaran el problema de rankeo y b´usqueda sobre el grafo. Por eso se profundiz´oen las herramientas ya descritas estudiando su implementaci´on. Las herramientas para la visualizaci´onseleccionadas en primera instancia trabajaban bastante bien, pero en la revisi´onse not´oque se basaban en una ontolog´ıa propia basada en un otro proyecto de LSDIS [sem06], que era la base de su sistema de ranking. Tambi´en se lleg´oa la conclusi´on que para tener una herramienta con un buen sistema de rankeo debido a los algoritmos y herramientas de consulta utilizadas, resulta necesario tener un conocimiento a priori de la ontolog´ıa utilizada. Como se desea seguir utilizando la ontolog´ıa basada en DCMI, se lleg´oa la conclusi´onque ser´ıa necesario o bien dise˜nar el sistema de ranking para algunas consultas, o bien omitirlas.
Finalmente se opt´opor omitir el sistema de ranking sem´antico por factores de tiempo. Adicionalmente con el estudio de la estructura de DC, y con una revisi´onsuperficial de varias herramientas de visualizaci´on, se lleg´oa la conclusi´onde utilizar una buena herramienta de visualizaci´onde redes adaptada a las relaciones espec´ıficas de la ontolog´ıa DC. Esto permitir´ıa entregar una mejor usabilidad y visualizaci´onsin tener que aplicar algoritmos de ranking. De manera extra, un visualizador con los algoritmos de expansi´on y contracci´onde nodos permitir´ıa cubrir la falencia del sistema de ranking.
20 3.5. BIBLIOTECAS
Al existir una gran variedad de herramientas de visualizaci´onde redes, se decidi´ohacer una revisi´onexhaustiva sobre herramientas y c´odigo fuente dentro del proyecto siendo un hito incluido en la planificaci´on.
3.5. Bibliotecas
A continuaci´onse describir´an brevemente las principales bibliotecas utilizadas para el manejo y parseo de datos en RDF. Hay que mencionar que todas estas bibliotecas son relativamente nuevas con fechas de inicio de proyectos cercanas al 2002.
3.5.1. JRDF
Java RDF (JRDF) tiene como motivaci´onel crear un set de APIs y una base para la implementaci´onde tecnolog´ıas RDF usando Java. Un proyecto muy activo, teniendo su ´ultima actualizaci´onfechada el 04/06/2007.
El proyecto tuvo inicios en el a˜no 2003. Posee escaza documentaci´ony una API incompleta hasta el momento. A pesar de esto ha obtenido excelentes resultados [New06], gracias a sus optimizaciones en b´usqueda, reduciendo considerablemente los tiempos de exploraci´ondel grafo RDF.
3.5.2. RDF2Go
Es de importancia mencionar aunque no sea una biblioteca de manejo RDF en s´ı. Su visi´ones entregar al usuario una abstracci´onde bibliotecas para el uso de RDF. Para ello entrega una serie de APIs para el manejo RDF, las cuales est´an basadas en enmascarar la implementaci´ondel manejo en s´ı, de manera de permitir al usuario escoger la implementaci´onposteriormente y sin necesidad de cambiar completamente el c´odigo de la aplicaci´on, sino simplemente cambiando la configuraci´onentregada por el mismo set de APIs.
A la fecha soportan las siguientes bibliotecas:
21 3.5. BIBLIOTECAS
Jena 2.4
YARS
NG4J
Sesame
3.5.3. JENA
Jena es una estructura de trabajo para la construcci´onde Aplicaciones Web Sem´anticas. Provee un ambiente de programaci´onpara RDF, RDFS y OWL, SPQRQL e incluye un motor de inferencias basado en reglas. Tambi´en tiene posee la habilidad de ser usada como una base de datos RDF.
Su ´ultima actualizaci´onfechada se encuentra el 18/01/2007. Posee una amplia documentaci´on. Al ser m´as que una simple biblioteca proporciona una gran cantidad de posibilidades para su uso. Su desempe˜no es el normal para este tipo de aplicaciones, sin proporcionar una gran ventaja por este lado.
3.5.4. SESAME
Sesame es otro proyecto de c´odigo abierto, que proporciona b´asicamente una base de datos RDF con soporte para la inferencia y consultas mediante esquemas RDF. Proporciona una gran variedad de herramientas para los desarrolladores que permiten explotar las posibilidades de la utilizaci´onde datos RDF y RDFS.
Su ´ultima actualizaci´onfechada la encontramos el 05/07/2007. Un proyecto con gran documentaci´on, y se encuentra ampliamente utilizado. Poseen una versi´onestable y en la actualidad se encuentran trabajando en su versi´on2.x la cual est´aen un estado beta a´un. Nada notable frente al desempe˜no logrado que se encuentra dentro de los tiempos normales al igual que sus competidores m´as directos como lo es Jena y YARS.
22 Cap´ıtulo 4
Solucion´ Propuesta
A continuaci´on se muestra en detalle los procedimientos existes en la soluci´on propuesta, as´ı como tambi´en tuvo que variar esta soluci´ondebido a los detractores encontrados. Para ello se describir´ala estructura general de la soluci´ona implementar y como interact´uan las distintas partes de la soluci´on, luego se har´auna descripci´ondel modelo l´ogico de datos y posteriormente sus posibles visualizaciones. Hay que recordar que sobre el modelo l´ogico se pueden implementar distintas visualizaciones, pero por motivos de cotas temporales existentes para el presente trabajo, se profundizar´as´olo la visualizaci´ona implementar.
4.1. Aspectos Generales
La soluci´ona implementar se divide en 3 partes que tienen un objetivo espec´ıfico, y que en su interacci´onlogran el prop´osito del trabajo. De esta forma es posible dividir el trabajo en 3 capas que pueden resultar ser independientes entre s´ıy con objetivos espec´ıficos que deben realizar.
As´ıen la soluci´ona implementar se reconocen 3 aspectos que se deben considerar:
1. Modelo Logico´ de Datos RDF/XML: consistente en la recopilaci´ony generaci´onde los metadatos. Debe comunicarse con los datos proporcionados por Memoria Chilena y convertirlos en la estructura RDF/XML dada por el modelo definido.
23 4.2. MODELO LOGICO´ DE METADATOS
2. Explorador del Modelo: consistente en la lectura de los metadatos y su procesamiento. Debe comprender el modelo de datos y la ontolog´ıa utilizada. Permite el manejo del grafo RDF e interact´ua con la capa visualizadora, por lo cual es una aplicaci´onque se encuentra EN-L´INEA.
3. Visualizador del Modelo: consistente en interactuar con el explorador para proporcionar una visualizaci´oncomprensible por el usuario. Debe estar integrado con tecnolog´ıas WEB.
El esquema de esta soluci´onpuede ser apreciado en la figura 4.1. Una vez reconocidas las partes integrantes de la soluci´ony sus restricciones procederemos a realizar la descripci´onde cada parte.
WEB
BD Memoria Chilena Generador de Explorador de Visualizador de Metadatos Metadatos Metadatos
->Recupera y Genera Metadatos ->Permite el manejo y comprensión ->Otorga la capacidad de según el modelo dado del modelo. proporcionar una visualización ->Se ejecuta e interactúa en WEB comprensible de los datos al usuario. ->Debe permitir su uso en WEB
Figura 4.1: Esquema de la Soluci´on
4.2. Modelo Logico´ de Metadatos
El Objetivo de esta capa de la aplicaci´ones la recuperaci´onde los datos proporcionados por Memoria Chilena y convertirlos en archivos RDF/XML. Esta capa de la aplicaci´on, resulta ser completamente independiente y puede funcionar en un ambiente sin conexi´on. La idea de los recursos RDF/XML es que se encuentren disponibles EN-L´INEA y que sean generados a priori. Dadas estas condiciones, el resto de la aplicaci´onpuede recuperar los archivos RDF/XML como recursos WEB con sus correspondientes URL.
El detalle de esta capa puede ser apreciado en la Figura 4.2
Como se expresa en la figura, existe un generador del modelo RDF/XML, por lo cual se proceder´aa realizar la descripci´onde estos posibles modelos, pero previamente es necesario revisar ciertas consideraciones.
24 4.2. MODELO LOGICO´ DE METADATOS
Generador de Metadatos
ARCHIVOS DE DATOS ARCHIVOS RDF/XML DE MEMORIA CHILENA Lector Generador de Modelo Permite la Recibe los datos lectura y del Lector. recuperación de Devuelve los datos de Memoria archivos RDF/XML Chilena generados según Devuelve los el modelo datos relevantes predeterminado. para la generación del modelo de datos
Figura 4.2: Esquema de la Soluci´on: Detalle de Generador de Metadatos
4.2.1. Errores a Considerar
El modelo actual de metadatos proporcionado por Memoria Chilena presenta errores l´ogicos cr´ıticos que invalidan tanto la utilizaci´onconceptual de los metadatos seg´un los esquemas de la W3C como las reglas de codificaci´onproporcionadas por DCMI.
Dentro de lo que es la estructura b´asica para codificar metadatos en RDF/XML [Wor04b] se puede entregar entregar el siguiente esqueleto:
Seg´un la definici´onde la sintaxis, este ser´ıa un esqueleto b´asico para la descripci´onde cualquier recurso utilizando el formato RDF/XML. Uno de los puntos cr´ıticos que viola la descripci´onactual de Memoria Chilena, es el concepto “Esta descripci´on en rdf habla sobre ...”. Para ello la sintaxis utiliza dos m´etodos principales:
Utilizar el atributo rdf:about=“RECURSO DESCRITO” dentro del tag rdf:Description (Recomendado por W3C y DCMI)
Utilizar alg´un tag identificador dentro de la descripci´on
25 4.2. MODELO LOGICO´ DE METADATOS
Un error conceptual en la creaci´onde los metadatos, gener´oun valor por omisi´onde “rdf:about=”http://dublincore.org/documents/dcmes-xml/”
Otro intento fallido para la consistencia de los metadatos por parte de Memoria Chilena es la utilizaci´onde un tag identificador proporcionado por DCMI. El valor del tag dc:identifier entrega una url 1 que identifica al mismo recurso rdf, en vez de la imagen que se pretende describir. Claro seg´un DCMI es posible identificar a un recurso con este tag sin la utilizaci´onde una url si se entiende que el recurso no posee alguna url o posee otro tipo de identificaci´on, como ser´ıa por ejemplo el caso de que se quisiera identificar un libro que bien podr´ıa utilizarse su ISBN XX...X. Pero en nuestro caso es falso. De cierta forma el actual valor entregado por este tag por Memoria Chilena, podr´ıa ser utilizado como identificador si se conoce bien la conformaci´onde los datos de Memoria Chilena. Por ejemplo un valor para este tag podr´ıa ser “http://www.memoriachilena.cl/mchilena01/document.rdf.asp?id=MC0000187” que representa la url del documento RDF. Si se sabe que las im´agenes descritas poseen el mismo identificador por las aplicaciones de Memoria Chilena, vale decir “MC0000187”, se podr´ıa conocer que se refiere a una de las im´agenes con ese identificador que se encuentra en “alguna” parte de los servidores de Memoria Chilena, que como vemos, no entrega la expresividad que se podr´ıa lograr al poseer un error conceptual de su uso.
De esta forma no es posible identificar el recurso que se pretende describir sin entender la naturaleza y estructura de los datos con anterioridad.
El segundo error conceptual que presentan los metadatos, pasa a llevar un concepto de estructuraci´ondel uso del lenguaje descriptivo entregado por DCMI. Seg´un la descripci´on del uso proporcionado por DCMI se destaca el hecho de que no importa el orden en que se utilicen los tags. Esto no se cumple en la descripci´onde Memoria chilena, ya que se pueden encontrar las relaciones descritas de la siguiente manera:
1dc:identifier seg´un definici´on en DCMI, puede ser o no una url, pudiendo tener cualquier valor que lo identifique ´unicamente y sea entendido por la aplicaci´on
26 4.2. MODELO LOGICO´ DE METADATOS id_ut=bernardoohigginsriquelme(1778-1842)
Esta descripci´onpretende entregar un t´ıtulo a cada relaci´on, siendo primero el t´ıtulo y luego la url de la relaci´onexistente. Como se aprecia, si se desordenan los tags, las relaciones y sus nombres quedar´ıan completamente desechas.
4.2.2. Estructura de los Recursos
Antes de proporcionar un modelo final de datos, es necesario ver cual es la l´ogica existente en los recursos existentes en Memoria Chilena. Hay que recordar que los metadatos que describen a las im´agenes s´olo poseen relaciones o links, a sitios tem´aticos que las contienen, no existiendo actualmente ninguna relaci´onentre im´agenes.
Antes de continuar se mencionar´an los principales componentes que estructuran los contenidos de Memoria Chilena.
Unidades Tem´aticas: Consiste en un recurso que describe a un tema en particular. Posee insertos en su texto referencias a otras unidades tem´aticas (UT) por medio de hiper-v´ınculos, adicionalmente posee hiper-v´ınculos a temas m´as espec´ıficos que forman parte del contenido de la UT. Estos contenidos los denominaremos Detalles Tem´aticos (DT). Finalmente dentro de los contenidos de las UT se encuentran hiper-v´ınculos a im´agenes relacionadas con el tema. Detalles Tem´aticos: Muy similar a las UT, s´olo que no poseen hiper-v´ınculos a otros DT. Im´agenes: Son las im´agenes de los contenidos.
As´ıla estructura general de Memoria Chilena puede ser descrita como se aprecia en la figura 4.3.
27 4.2. MODELO LOGICO´ DE METADATOS
Sitio Temático Sitio Temático 0...n
0...n 0...n
Imagen 0...n
Imagen Detalle Temático 0...n
Imagen 0...4 Sitio Temático 0...n
Imagen Imagen
Detalle Temático 0...n
0...n Imagen
0...n 0...n
Sitio Temático Sitio Temático 0...n
Figura 4.3: Estructura de Recursos de Memoria Chilena
Aqu´ıse puede apreciar que:
1 UT puede poseer 0-N UT, 0-N DT, 0-4 Im´agenes directas (Im´agenes seleccionadas para ser mostradas al desplegar una UT, esto proviene de una restricci´onen los campos de la base de datos de donde se generan).
1 DT puede poseer 0-N UT, 0-N Im´agenes.
1 Imagen puede poseer 0-N UT en sus metadatos.
4.2.3. Definicion´ del Modelo
Dada la estructura actual existente en Memoria Chilena, y tomando en cuenta las consideraciones ya mencionadas, la idea que se pretende explotar para la realizaci´ondel modelo de datos RDF, es b´asicamente aprovechar al m´aximo el trabajo hecho por parte de los encargados de Memoria Chilena. Para esto se pretende rescatar la mayor informaci´on posible de la catalogaci´ony relaciones vigentes.
Con esta idea en mente se desarrollaron tres modelos que pretenden rescatar el modelo conceptual y estructuraci´on.
28 4.2. MODELO LOGICO´ DE METADATOS
Primer Modelo .
La idea m´as cercana al modelo existente y que adem´as permite crear una extensa estructura de red RDF, es no tan s´olo poseer metadatos descriptivos de las im´agenes, sino tambi´en, utilizando descripci´onde todos los recursos principales de la estructuraci´on de Memoria Chilena, vale decir, la creaci´onde metadatos descriptivos para Unidades Tem´aticas como tambi´en para los Detalles Tem´aticos, adicionalmente a la reestructuraci´on de los actuales metadatos proporcionados para las im´agenes.
Con esto se puede definir un modelo RDF como se ve en la figuras 4.4, 4.5, 4.6.
rdf:type rdf:Bag
dcterms:references rdf:_1 UT_id
rdf:_n
Unidad Temática UT_id
dcterms:hasPart dc:id rdf:type rdf:Bag dc:title ....
rdf:_1 DT_id
rdf:_n rdf:_n1 rdf:_n4 DT_id
Imagen Imagen
Figura 4.4: Modelo conceptual RDF de una Unidad Tem´atica
rdf:type rdf:Bag
dcterms:references rdf:_1 UT_id
rdf:Bag rdf:type dcterms:hasPart rdf:_n
rdf:_1 Detalle Temático UT_id Imagen
rdf:_n rdf:Bag dc:id rdf:type dc:title Imagen .... rdf:_1 UT_id dcterms:isPartOf rdf:_n
UT_id
Figura 4.5: Modelo conceptual RDF de un Detalle Tem´atico
Para lograr esto bastar´ıa tan s´olo transcribir la informaci´ony relaciones existentes utilizando los conceptos que expresen el tipo de relaci´onutilizando t´erminos extendidos
29 4.2. MODELO LOGICO´ DE METADATOS
rdf:type rdf:Bag
rdf:Bag rdf:type dcterms:references rdf:_1 dcterms:isReferencedBy UT_id rdf:_1 rdf:_n UT_id Imagen UT_id rdf:_n
rdf:Bag UT_id dc:id rdf:type dc:title ....
rdf:_1 DT_id dcterms:isPartOf rdf:_n
DT_id
Figura 4.6: Modelo conceptual RDF de una Imagen de Dublin Core como se aprecia. Este proceso queda formalizado con la ejecuci´onde los siguientes pasos:
1. Por cada Unidad Tem´atica.
a) Reconocer valores descriptivos del recurso. Obtener links a otras Unidades Tem´aticas, links a Detalles Tem´aticos, Im´agenes insertadas en la Unidad Tem´atica, T´ıtulo, Identificador, etc 2 b) Crear metadatos en RDF/XML con los tags correspondientes.
2. Por cada Detalle Tem´atico.
a) Reconocer valores descriptivos. Obtener links a otras Unidades Tem´aticas, Im´agenes insertadas, Titulo, Identificador, etc. b) Crear metadatos en RDF/XML.
3. Por cada imagen
a) Obtener metadatos. Rescatar tags bien utilizados, obtener relaciones a Unidades Tem´aticas. b) Reestructurar metadatos RDF/XML, para que conformen los est´andares de sintaxis descritos.
As´ıes posible escribir el siguiente esqueleto RDF/XML.
2Cualquier otro valor puede ser agregado de manera de tener una descripci´on m´as rica del recurso, pero s´olo los escenciales para la estructura del modelo han sido considerados.
30 4.2. MODELO LOGICO´ DE METADATOS
31 4.2. MODELO LOGICO´ DE METADATOS
32 4.2. MODELO LOGICO´ DE METADATOS
33 4.2. MODELO LOGICO´ DE METADATOS
Segundo Modelo .
Este es una variaci´ondel modelo anterior s´olo que en vez de crear metadatos para todos los componentes estructurales del actual modelo conceptual de Memoria Chilena, tan s´olo rescatamos las relaciones existentes entre los recursos y las dejamos expresadas en los metadatos de las im´agenes, que es escencialmente lo que deseamos.
Para ello, definimos que una imagen es parte de los Detalles Tem´aticos mediante el concepto “isPartOf” y que son referenciadas por Unidades Tem´aticas mediante el concepto “isReferencedBy”. Con estos dos conceptos m´as el modelo conceptual y la aplicaci´onque lo comprenda, es posible rescatar todas las relaciones existentes entre las im´agenes.
Para que este modelo capture toda la informaci´on, es necesario que las relaciones expresadas se˜nalen a nodos blancos que contengan un identificador de las UT y DT que debieran se˜nalar y su t´ıtulo que es la informaci´onb´asica necesitada.
Con esto el modelo resultante puede ser apreciado en la figura 4.7.
dc:id dc:title .... rdf:type rdf:Bag rdf:Bag rdf:type dcterms:isReferencedBy dcterms:isPartOf rdf:_1 rdf:_1
Imagen rdf:_n rdf:_n
DT_titulo dc:title
dc:title DT_titulo DT_id dc:id
dc:id DT_id rdf:type rdf:type
rdf:_1 rdf:_n rdf:_1 rdf:_n rdf:Bag
rdf:Bag Imagen Imagen Imagen Imagen
Figura 4.7: Segundo modelo conceptual RDF
Al ser una reestructuraci´ondel modelo anterior, los pasos para crearlo son exactamente muy similares, con la diferencia que al obtener las relaciones no se generan metadatos por cada UT/DT, sino que son agregados en forma de Tags a los metadatos reestructurados de las im´agenes. As´ıquedan expresados formalmente:
34 4.2. MODELO LOGICO´ DE METADATOS
1. Por cada Unidad Tem´atica. Reconocer valores descriptivos del recurso. Obtener links a otras Unidades Tem´aticas, Im´agenes insertadas en la Unidad Tem´atica, T´ıtulo, Identificador, etc. Obtener Im´agenes Insertadas en las Unidades Tem´aticas Referenciadas.
2. Por cada Detalle Tem´atico. Reconocer valores descriptivos. Obtener links a Im´agenes insertadas, Titulo, Identificador, etc.
3. Por cada imagen.
a) Obtener metadatos. Rescatar tags bien utilizados, obtener relaciones a Unidades Tem´aticas. b) Reestructurar metadatos RDF/XML, para que conformen los est´andares de sintaxis descritos. c) A˜nadir Tags de Relaciones obtenidas por las UT y DT.
As´ıes posible escribir el siguiente esqueleto RDF/XML.
35 4.2. MODELO LOGICO´ DE METADATOS
Con este modelo es posible abstraerse de la estructura que pueda tener los recursos, ya que es un modelo estrictamente de relaciones entre im´agenes, basado en las relaciones rescatadas, donde cada imagen se relaciona con otras im´agenes y adicionalmente es posible obtener dos grados de cercan´ıa entre ellas.
Tercer Modelo .
Una simplificaci´ondel modelo es tan s´olo obtener todas las relaciones entre im´agenes por medio de las relaciones entre Unidades y Detalles Tem´aticos. Para ello al igual que en los modelos anteriores, habr´ıa que explorar las Unidades Tem´aticas y relacionar las im´agenes que poseen los sitios entre s´ı, y adicionalmente agregar las im´agenes contenidas en otras Unidades Tem´aticas y Detalles Tem´aticos.
As´ıesta tercer modelo puede ser presentado como se muestra en la figura 4.8.
36 4.2. MODELO LOGICO´ DE METADATOS
rdf:type rdf:Bag
dcterms:isReferencedBy rdf:_1 Imagen
rdf:_n
dc:id dc:title ....
DT_titulo dc:title
DT_id dc:id
rdf:type
rdf:_1 rdf:_n rdf:Bag Imagen Imagen
Figura 4.8: Tercer modelo conceptual RDF
Para la obtenci´onde este modelo hay que realizar las siguientes iteraciones por imagen:
1. Dada una imagen, explorar sus actuales relaciones a UT.
2. Por cada UT obtenida en el punto anterior, obtener las im´agenes contenidas por esa UT y los DT relacionados con la UT.
3. Por cada DT obtenido, obtener las im´agenes contenidas.
4. Para cada imagen resultante del paso anterior, reescribir los metadatos para la imagen de 1 y a˜nadir las relaciones a las im´agenes encontradas con estos pasos eliminando repeticiones.
Siguiendo estos pasos es posible definir el esqueleto RDF/XML descrito por el siguiente c´odigo para los metadatos de cada imagen.
37 4.3. EXPLORACION´ DE METADATOS
4.3. Exploracion´ de Metadatos
Esta capa de la aplicaci´on, corresponde al manejador de recursos l´ogico. Su funci´ones brindar las herramientas necesarias para comprender y manejar el modelo proporcionado por la capa anterior.
Desde esta capa de la aplicaci´on, ya se comienza a pensar en una aplicaci´onque interactuar´acon la WEB. Esto debido a que proporcionar´ael manejo de grafos RDF a la capa visual que efectivamente trabaja sobre la WEB. En otras palabras, esta capa de la aplicaci´ones el aspecto l´ogico que realizar´ael trabajo y suministrar´alas capacidades necesarias para ser recuperadas por la ´ultima capa visualizadora. Debido a esto ´ultimo se hace necesario pensar desde esta capa de la aplicaci´onque se encuentra en un ambiente EN-L´INEA.
A diferencia de la capa anterior, y por su requerimiento de trabajar EN-L´INEA, esta parte de la aplicaci´onse ejecuta y procesa la informaci´ona medida que recibe feedback desde la capa visual que a su vez recibe el feedback del usuario.
38 4.3. EXPLORACION´ DE METADATOS
Para lograr con su cometido vamos a subdividir esta capa en tres funcionalidades como se puede apreciar en la Figura 4.9, y las cuales se explicar´an a continuaci´on.
Explorador de Metadatos RECURSOS EN-LÍNEA
RDFXMLParser MCHandler Permite la DCHandler Es el encargado lectura y Es el encargado de comprender el ARCHIVOS RDF/XML recuperación de de comprender el modelo de archivos RDFXML vocabulario metadatos que se Parsea su proporcionado por implementará en contenido y Dublin Core Memoria Chilena, entrega una Metadata como de representación Institute. interactuar con de Grafo del Recibe el grafo la capa Visual. archivo RDFXML, del documento Maneja Recursos permitiendo así RDF/XML ya RDF/XML su exploración. parseado. proporcionados La Proporciona una por un DCHandler. representación interfaz para Proporciona una de Grafo depende obtener los tags interfaz para exclusivamente de y sus valores y obtener los la posibles valores implementación relaciones bajo necesarios para del parser RDF un modelo Dublin la seleccionado. Core. visualización.
CAPA VISUALIZADORA
Figura 4.9: Esquema de la Soluci´on: Detalle de Explorador de Metadatos
4.3.1. Lector Metadatos RDF/XML
Aspectos Generales Su funci´ones la de convertir los metadatos RDF/XML, en algo m´as computable y manejable. Para ello es necesario la utilizaci´onde alguna biblioteca manejadora de recursos RDF. Se compone b´asicamente de un parser que para la aplicaci´on debe recibir recursos RDF/XML EN-L´INEA.
Clase RDFXMLParser Es la clase encargada de obtener los recursos EN-L´INEA y parsearlos en un grafo. Las bibliotecas RDF actuales se encargan de realizar este proceso, resultando esta clase ser una m´ascara para la utilizaci´onde la biblioteca RDF seleccionada para la aplicaci´on.
Esta clase, es la encargada tambi´en de recibir las URL a los descriptores de recursos, y ser la primera en reconocer cuando un recurso efectivamente se encuentra disponible, y si su descripci´onse encuentra correcta. Hay que recordar que las descripciones de recursos podr´ıan haber sido mal generados y no permitir su lectura como recursos RDF/XML, como tambi´en haber recibido una URL mal formada o a un recurso que ya no se encuentra disponible. Manejando estos posibles problemas permite la consistencia de la aplicaci´ony su estabilidad.
Retorna un grafo que permite la posterior exploraci´ondel recurso. La implementaci´on del grafo y su manejo dependen exclusivamente de la biblioteca RDF escogida para la implementaci´on.
39 4.3. EXPLORACION´ DE METADATOS
4.3.2. Manejador Ontolog´ıa Dublin Core
Aspectos Generales Tiene como objetivo proporcionar los m´etodos necesarios para comprender el vocabulario proporcionado por la entidad Dublin Core Metadata Institute, as´ı como las posibles relaciones entre recursos. Proporciona una interfaz que permite obtener los valores del vocabulario DC, as´ı como consultar sobre alguna relaci´onen particular.
A modo de destacar la importancia y las posibilidades de esta parte de la soluci´on, vale mencionar que no se encontr´oalguna soluci´onque manejara directamente la ontolog´ıa de DCMI, por lo cual ser´ıa interesante extender las funcionabilidades y lograr una abstracci´on de las bibliotecas de parseo RDF, para lograr una soluci´onque permita el manejo de la ontolog´ıa. M´as informaci´onde sus posibilidades referirse a la Cap´ıtulo 7.
Clase Vocabulary Esta clase recae la responsabilidad de conocer a completitud el vocabulario de la ontolog´ıa Dublin Core. Para ello posee una lista con todas las URI que componen las descripciones del vocabulario de la ontolog´ıa brindada por Dublin Core Metadata Institute.
Posee dos subclases que conforman la totalidad del vocabulario. DCElements que proporciona los 15 elementos descriptivos b´asicos de DCMI; DCTerms que entrega las extensiones del vocabulario.
Clase DCResourceHandler Es la encargada de brindar un manejo para los recursos RDF/XML que se encuentran descritos seg´un la ontolog´ıa DCMI. Trabaja directamente sobre el grafo entregado por el parser, brind´andole expresividad y m´etodos que permiten recuperar la informaci´onde sus tags descriptivos de manera m´as sencilla.
Como ´ultimo fin de esta clase debiera proporcionar la funcionabilidad necesaria para abstraerse de cualquier tipo de modelo. As´ıcomo tambi´en manejar errores de Recursos que siendo correctamente parseados como RDF/XML, no conformen una estructura para DCMI sin ambig¨uedades.
40 4.4. VISUALIZACION´ DE METADATOS
4.3.3. Manejador de Modelo para Memoria Chilena
Aspectos Generales Su objetivo es suministrar toda la interfaz para obtener los valores proporcionados por el modelo. Debe comprender la estructura del modelo y brindar los m´etodos necesarios para recorrerlo.
Esta parte de la soluci´ones la que interact´ua con la capa visual, por lo que debe proporcionar una interfaz ´util y sencilla para el intercambio de informaci´oncon la WEB.
Tambi´en interact´ua con el manejador de recursos DCMI, por lo que le da sentido a su uso para la aplicaci´on.
Clase MCResourceHandler Es la clase que recibe la responsabilidad de reconocer los recursos descriptivos de Memoria Chilena, suministrando una forma efectiva para la obtenci´onde los recursos y sus valores descriptivos.
Debe interactuar con la capa visualizadora, y brindar los valores requeridos por el usuario y para la visualizaci´on.
4.4. Visualizacion´ de Metadatos
La ´ultima capa de la aplicaci´ony la que realmente percibe el usuario es la presentaci´on y el manejo de informaci´onque se le pueda conceder.
Gracias al modelo l´ogico de datos, es posible lograr una presentaci´ony visualizaci´on al estilo de exploraci´onde redes. As´ı una de las posibles visualizaciones y lo que se pretend´ıa llegar en primera instancia era a una presentaci´oncomo la que se presenta en la Figura 4.10.
Para lograr esta visualizaci´on era necesario trabajar con m´etodos y t´ecnicas de visualizaci´onen redes, pero por motivos de complejidad y l´ımites de tiempo no fue posible lograr aprovechar dicha capacidad. Sus ventajas y una posible implementaci´onser´an descritas en la Cap´ıtulo 7. Debido a estas razones se cambi´oel enfoque de la soluci´on, permitiendo de todas formas proveer la visualizaci´onde las relaciones, pero de una forma
41 4.4. VISUALIZACION´ DE METADATOS m´as est´atica.
Dentro de los requisitos para esta capa, es que la visualizaci´onproporcionada debe ser WEB. Adecu´andose al requisito mencionado esta capa de la soluci´ondebe resultar ser una integraci´onde tecnolog´ıas b´asicamente WEB, con las herramientas necesarias para interactuar con la capa de Exploraci´on.
(a)
Esta capa de la soluci´on se puede subdividir en dos funcionalidades que debe cumplir.
4.4.1. Visualizacion´ Estatica´ (b) Figura 4.10: Posible Presentaci´on Visual de Datos
Esta es la parte de la soluci´on que percibe el usuario. Se compondr´a ´unicamente de tecnolog´ıas de visualizaci´onen la web. Ser´ala m´ascara de presentaci´on.
Cada recurso visualizado constar´ade sus metadatos relacionados, presentando los valores de los metadatos al usuario. Adicionalmente se presentar´an en forma visual todas aquellas im´agenes (recursos web) que se relacionan directamente con el recurso visualizado. Estas relaciones de primera instancia dispondr´an de sus metadatos m´as relevantes, y a su vez, para permitir una exploraci´oncon mayor expresividad y profundidad, se presentar´an los recursos directamente relacionados con estos (recursos de segunda relaci´oncon el recurso visualizado). La exploraci´on permitir´ade esta forma brindar relaciones de primer y segundo orden con el recurso visualizado, y permitir profundizar sobre estos.
A modo de ejemplo, la visualizaci´onque se pretende lograr y un caso de uso quedan expresados en la Figura 4.11.
42 4.4. VISUALIZACION´ DE METADATOS
(a) Visualizaci´on de Relaciones de Primer Orden
(b) Visualizaci´on de Relaciones de Segundo Orden
Figura 4.11: Presentaci´on Visual de Datos Esperada
4.4.2. Interaccion´ con Explorador
Para la interacci´onentre el explorador de contenidos y el visualizador (manejado por el usuario), es necesario poseer dos funcionalidades que ser´an exclusivas de dos clases en la implementaci´on.
Clase ContextListener Tendr´a a cargo la interacci´on directa con el explorador, permitiendo utilizar los recursos mediante la utilizaci´ondirecta de los manejadores de recursos, y proporcion´andoles visualizaci´ondentro del contexto web de la aplicaci´on.
Clase ContextFilter Tendr´aa cargo el adquirir los eventos y valores que ejecuta el usuario en la capa WEB, para procesarlos y proporcionarlos al contexto web.
43 Cap´ıtulo 5
Solucion´ Implementada
Dentro de esta Secci´onser´an descritas las tecnolog´ıas utilizadas en la implementaci´on de la aplicaci´ony los aspectos m´as relevantes, encontr´andose dividida en tres subsecciones. Subsecci´on 5.1, donde ser´a descrita la implementaci´on para obtener y generar los metadatos correspondientes a los modelos descritos en Cap´ıtulo 4. Subsecci´on5.2, se encontrar´an los detalles de la implementaci´onde la capa exploradora de los metadatos. Subsecci´on5.3, los detalles de la capa WEB.
5.1. Obtencion´ y Creacion´ de Metadatos RDF/XML
En una primera instancia, los datos recibidos fueron proporcionados por una base de datos SQLSERVER, sin relaciones.
Las tablas relevantes no proporcionaban la totalidad de la informaci´onrequerida para el modelo, por lo cual se tuvo que recortar su expresividad
Las tablas que entregaban informaci´on´util al modelo eran:
documentos: es la tabla que posee las descripciones de los documentos, o recursos, disponibles en el portal, vale decir, descripciones de im´agenes, archivos pdf, ilustraciones, etc.
44 5.1. OBTENCION´ Y CREACION´ DE METADATOS RDF/XML
doc tema: tabla pivote que permite realizar join entre documentos y temas.
tema: ´util s´olo para recuperar el tema del cual trata un documento.
utematicas: posee la descripci´onde una Unidad Tem´atica.
Como en los datos proporcionados no se encontr´oinformaci´oncapaz de brindar alguna conexi´ono forma de recuperar la descripci´onde un Destino Tem´atico, se opt´opor generar el modelo 3 con simplificaciones.
Para conservar los valores actualmente utilizados en la implementaci´onde metadatos por Memoria Chilena, es necesario relacionar aquellos valores con la base de datos. Con este fin, puede ser visualizado el Cuadro 5.1 que proporciona un esquema generalizado de los atributos y tablas de la base de datos, junto con sus relaciones a los nombres de los metadatos descritos por Dublin Core Metadata Institute utilizados en Memoria Chilena1.
Tabla en Base de Datos Atributo Metadato que lo utiliza * * Description documentos id identifier documentos titulo title documentos autor creator documentos materia subject tema nombre subject.categoria * * relation * * publisher documentos fecha ingreso date * * W3CDTF tipo nombre type * * format documentos Fuente source.extraidodesde documentos lang language documentos FechaInf coverage * * covarage.temporal * * coverage.espatial * * rights
Cuadro 5.1: Relaci´on existente entre Metadatos y Atributos de Tablas en BD
A continuaci´on, se describir´an toda la estructura de metadatos implementada, para luego dar paso a la descripci´ondel creador de Metadatos en s´ı.
1Para m´as informaci´on sobre los tag utilizados, referirse a la Cap´ıtulo 3
45 5.1. OBTENCION´ Y CREACION´ DE METADATOS RDF/XML
5.1.1. Modelo RDF/XML Implementado
Dentro de los valores utilizados por los tags DC en Memoria Chilena, existen algunos que poseen valores por omisi´one inmutables y que no son obtenidos de la base de datos. Tambi´en existen otros valores que fueron cambiados en el modelo, pero no en su significado. Finalmente el modelo se implement´ode tal forma de no perder informaci´on, y de ser lo m´as cercano posible al modelo recomendado por Dublin Core Metadata Institute, con tal de cumplir con los est´andares y posibilitar el intercambio de informaci´oncon otras aplicaciones ´utiles a futuro.
A continuaci´onse describir´ala implementaci´onde todos los metadatos mencionados en conjunto con los cambios realizados.
Description Como fue mencionado en la Cap´ıtulo 4, este tag, y principalmente su atributo rdf:about pose´ıa un valor incorrecto conceptualmente, por lo cual se utiliz´oel valor de la url del elemento a describir, como es la recomendaci´on. As´ıel tag finalmente queda descrito como se presenta en el C´odigo 1.
Codigo´ 1 Implementaci´onde Metadato “Description”
Como se est´an utilizando thumbnails de las im´agenes por una raz´onde optimizaci´on visual, la URL quedan determinadas por la f´ormula descrita en C´odigo 2.
Codigo´ 2 Detalle de URL URL: url-base-memoria-chilena+id-del-recurso+extensi´on con: url-base-memoria-chilena: "http://www.memoriachilena.cl/archivos2/thumb200/" id-del-recurso: obtenido de la tabla "documentos.id" extensi´on: "jpg". Cabe destacar que Memoria Chilena s´olo utiliza este formato.
identifier Resulta ´util utilizar este tag a pesar de que resulta completamente definido con la implementaci´onde Description, para la computaci´onde otras relaciones. Por ello la utilizaci´onde este tag qued´odefinida como se muestra en el C´odigo 3, siendo ID el valor obtenido al consultar “documentos.id”.
46 5.1. OBTENCION´ Y CREACION´ DE METADATOS RDF/XML
Codigo´ 3 Implementaci´onde Metadato “identifier”
title El t´ıtulo del documento obtenido de forma directa queda definido como se presenta en el C´odigo 4, con T´ITULO obtenido al consultar “documentos.title”.
Codigo´ 4 Implementaci´onde Metadato “title”
creator El autor o creador de la imagen, generalmente se refiere a pinturas. Por esta misma raz´onno todas las im´agenes poseen un valor para este tag. Queda implementado como se describe en C´odigo 5, donde AUTOR se obtiene al consultar “documentos.autor”.
Codigo´ 5 Implementaci´onde Metadato “creator”
subject La sub divisi´onde este tag “subject.categoria” fue eliminada por no otorgar mayor informaci´on, adem´as de no ser un tag perteneciente al vocabulario Dublin Core. De esa forma se unieron los valores de la implementaci´onactual, correspondientes a subject y subject.categoria, para dar paso al metadato subject que contiene todos los valores dentro de un contenedor sin orden descrito por rdf:Alt, permitiendo as´ıexpresar que su contenido puede ser entendido por cualquiera de los temas mencionados. Seg´un esto, la implementaci´onpara este tag queda definida como se presenta en C´odigo 6, siendo los SUBJECT1-SUBJECTN, los obtenidos al consultar por documentos.materia y al realizar los join de documentosXdoc temaXtema por el id del recurso en consulta y obteniendo el valor correspondiente a tema.nombre.
Codigo´ 6 Implementaci´onde Metadato “subject”
47 5.1. OBTENCION´ Y CREACION´ DE METADATOS RDF/XML relation El valor del metadato relation fue completamente desechado, dando paso a la implementaci´onde los t´erminos isReferencedBy, isPartOf. En la primera implementaci´on por un tema de que la base de datos no resultaba posible rescatar las relaciones hacia Detalles Tem´aticos, s´olo fueron consideradas las relaciones existentes entre Unidades Tem´aticas. Para comprender la metodolog´ıa utilizada para la obtenci´onde las relaciones, se debe comprender primero la implementaci´onl´ogica en la base de datos. Con esto la tabla utilizada para la descripci´onde una unidad tem´atica es “utematicas” y posee todos los atributos para el rescate y presentaci´onde una Unidad Tem´atica. Dentro de los atributos que es necesario rescatar son las im´agenes presentes en las unidades tem´aticas, las cuales est´an representadas por los atributos img, enumeradas de 1 a 4, el t´ıtulo de la unidad tem´atica y para completitud su identificador. Con estos atributos y utilizando la metodolog´ıa descrita en la Cap´ıtulo 4, se logr´oimplementar el tercer modelo con la excepci´onde que las im´agenes relacionadas por Detalles Tem´aticos no pudieron ser consideradas perdiendo dicha informaci´on. Finalmente el C´odigo representativo para las relaciones queda descrito en C´odigo 7, con los valores UT T´ITULO obtenido de ‘utematicas.titulo”, UT ID desde “utematicas.id” e IMAGEN ID rescatado al consultar por “utematicas.imgN”2 con N de 1 a 4.
Codigo´ 7 Implementaci´onde Metadato para Relaciones
publisher Metadato fijo, cuyo valor queda expresado por el valor “Biblioteca Nacional de Chile”. Con esto su implementaci´onqueda expresada por el C´odigo 8.
2El valor descrito en el atributo imgN es el id correspondiente a documentos.id ´unico para cada imagen.
48 5.1. OBTENCION´ Y CREACION´ DE METADATOS RDF/XML
Codigo´ 8 Implementaci´onde Metadato “publisher”
date & W3CDTF El metadato date y el formato para fechas definido por el metadato W3CDTF fueron fusionados para dar paso al metadato created ´unicamente. Este cambio fue realizado por motivos de representar m´as fielmente lo que se deseaba expresar con el valor proporcionado. El valor de este metadato queda definido al consultar por “documentos.fecha ingreso” en la base de datos, y su implementaci´onqueda definida en el C´odigo 9.
Codigo´ 9 Implementaci´onde Metadato “created”
type Este metadato desea expresar la naturaleza del recurso descrito, y actualmente su valor se basa en una composici´onde la recomendaci´onentregada por Dublin Core, y una extensi´onpropia de Memoria Chilena. As´ıel valor del metadato queda representado por la conjunci´onde los valores “Image” m´as el valor resultante de consultar “tipo.nombre” al realizar los join entre documentosXtipo mediante el atributo id. As´ıel valor TYPE descrito en el C´odigo 10 podr´ıa ser representado por “Image.L´amina”.
Codigo´ 10 Implementaci´onde Metadato “type”
format Valor estandarizado en Memoria Chilena. El formato de las im´agenes DEBE ser jpeg, por lo que el valor del tag format es invariante y queda definido por la estructura MIME “image/jpeg” como se representa en C´odigo 11.
Codigo´ 11 Implementaci´onde Metadato “format”
source.extraidodesde Su actual implementaci´ones una extensi´ondel metadato source descrito por DCMI, con un valor representante del lugar f´ısico de donde fue digitalizado el recurso. Como se aprecia, la extensi´on “extraidodesde” no aporta ning´un valor ni
49 5.1. OBTENCION´ Y CREACION´ DE METADATOS RDF/XML comprensi´onadicional al metadato, y lo que es m´as, el modelo pierde estandarizaci´onpara su posterior ampliaci´ono intercambio de informaci´oncon otras posibles aplicaciones. Por esta raz´onel metadato seleccionado fue s´olo el brindado por el vocabulario de DCMI. De esta forma la implementaci´onde este metadato se expresa en el C´odigo 12, resultando ser el valor de SOURCE, el retornado por consultar en la base de datos por “documentos.Fuente”.
Codigo´ 12 Implementaci´onde Metadato “source”
language Aunque no resulta ser un valor expresivo para im´agenes, todos los documentos en Memoria Chilena poseen un valor para el lenguaje descrito por el atributo lang en la tabla documentos. As´ıeste metadato queda implementado como se presenta en C´odigo 13, siendo LANG el valor de “documentos.lang”.
Codigo´ 13 Implementaci´onde Metadato “language”
coverage.temporal Su actual implementaci´onse encuentra separada en tres partes. Una es el metadato normal cuyo valor es el siglo al cual corresponde el hecho que representa el recurso, y dos extensiones de este metadato creados por Memoria Chilena, a saber “coverage.temporal.inicio” y “coverage.temporal.termino”. Como se observa en otras extensiones propias de Memoria Chilena definidas en la actual implementaci´on, es posible modificar el modelo para que sea conforme a los est´andares descritos por Dublin Core Metadata Institute. Debido a esto y para lograr el mismo grado de expresividad, se decide utilizar el t´ermino “temporal” con un valor codificado por DCMI expresado seg´un el esquema Period, donde designaremos al componente START el valor que expresaba “coverage.temporal.inicio”, al componente END el valor representado en “coverage.temporal.termino” y por ´ultimo al componente NAME el valor del tag “coverage.temporal”. De este modo es posible rescatar la misma expresividad, permitiendo al modelo ser conforme a los est´andares y recomendaciones descritas. Por ´ultimo resulta necesario destacar que el valor correspondiente para el componente “start” del metadato. Este se obtiene al consultar sobre la base de datos el valor de los atributos fecha1 a, fecha1 m y fecha1 d sobre la tabla documentos. Una vez obtenido estos valores, es compuesto el valor final del componente utilizando la codificaci´onest´andar del metadato3, definida por el formato yyyy-mm-dd, es decir, a˜no-mes-fecha, por lo que
3Este metadato al igual que todos los derivados de “date” pueden ser descritos por su codificaci´on est´andar definida por el esquema W3CDTF, sin resultar ser necesario especificar que el valor del metadato se encuentra en dicho formato.
50 5.1. OBTENCION´ Y CREACION´ DE METADATOS RDF/XML
el valor START finalmente resulta ser “fecha1 a-fecha1 m-fecha1 d”. De manera an´aloga el valor para el componente “end”, representado por END en la codificaci´onpresentada a continuaci´on, resulta ser la composici´on “fecha2 a-fecha2 m-fecha2 d”. Finalmente el valor representado por NAME en la codificaci´oncorresponde al atributo FechaInf de la misma tabla documentos. Con todo esto la codificaci´onresultante queda expresada en el C´odigo 14.
Codigo´ 14 Implementaci´onde Metadato “temporal”
coverage.spatial Como resultado de seguir las recomendaciones definidas por Dublin Core, es necesario tan s´olo expresar el metadato por el metadato spatial. El valor para este metadato no conforma un est´andar para las posibles esquemas de codificaci´ondescritas por DCMI, por lo que se prefiri´odejar el valor como un string solamente que sea comprensible por la aplicaci´on. Adicionalmente por falta de relaciones en la base de datos, no es posible relacionar la informaci´onde localidades con los documentos digitalizados descritos en la actual implementaci´on. Por ello, s´olo por dejar definido este metadato y cumplir con los est´andares se describe de manera fija con la siguiente codificaci´on.
Codigo´ 15 Implementaci´onde Metadato “spatial”
rights Al ser todos los contenidos y recursos propios del portal, el valor de este metadato queda definido e inmutable para todos los recursos descritos. Por ello la implementaci´on de este tag siempre quedara expresado como se presenta en C´odigo 16.
Conocida la estructura de los metadatos implementados y la manera de rescatarlos, se preceder´aa describir el proceso de creaci´on.
51 5.1. OBTENCION´ Y CREACION´ DE METADATOS RDF/XML
Codigo´ 16 Implementaci´onde Metadato “rights”
5.1.2. Creador de Metadatos
El implementador del modelo reci´en mencionado, se basa en una estructura modular de funciones y procedimientos almacenados escritos en transact-sql para SQLSERVER-2005.
La estructura de la soluci´onno tiene mayores complicaciones y puede esquematizarse como se muestra en la Figura
De esta manera los componentes relevantes de la implementaci´onson:
fn add¡METADATO¿, con METADATO variando seg´un el nombre del tag Dublin Core.
fn write2File
sp RDF Generator
fn addMETADATO Existe una funci´onpor cada metadato implementado y lleva el nombre del mismo metadato.
Estas funciones se encargan de recuperar los valores utilizados por los metadatos, para luego armar la implementaci´ondel mismo, seg´un lo descrito en la Subsecci´on5.1.1.
Una vez recuperado e implementado el orden estructural que describe al metadato, retorna dicho valor al llamador.
Siguiendo esta descripci´onse presenta su implementaci´onen pseudo-c´odigo como queda expresado en C´odigo 17, a manera de rescatar los aspectos m´as importantes de estas funciones. Para ver la implementaci´onfinal, favor referirse a los Anexos.
52 5.1. OBTENCION´ Y CREACION´ DE METADATOS RDF/XML
Codigo´ 17 Implementaci´onen pseudo-c´odigo de las funciones “fn add¡METADATO¿” FUNCTION fn_add
/* Par´ametros */ @rdf // varchar que representa la estructura del METADATO @myVar // representante de los atributos requeridos para el METADATO
/* Recuperaci´on de Informaci´on */ SELECT @myVar=atributo FROM tabla WHERE @id // condici´on que permite seleccionar los atributos // correspondientes al recurso pedido representado por @id
/* Armado de la Implementaci´on del METADATO * Se organiza la estructura RDF/XML seg´un el modelo y se agregan * los valores rescatados de la base de datos */ SET @rdf = ‘IMPLEMENTACION’´
/* Retorno del armaz´on RDF/XML */ RETURN @rdf
fn write2File Es la encargada de obtener la salida al sistema de archivos y con ello la creaci´onde archivos.
Recibe como par´ametros dos string, uno representando el nombre de archivo a crear, y el otro el contenido del archivo.
sp RDF Generator Es el procedimiento almacenado principal, encargado de armar la totalidad del archivo RDF.
Recibe como par´ametro el identificador del documento a describir en formato RDF/XML.
Genera el archivo RDF/XML descriptor del recurso pedido, para lo cual crea su correspondiente archivo nombrado seg´un el identificador del recurso. El archivo creado es en formato RDF que proporciona la descripci´oncompleta de los recursos seg´un lo expresado en la subsecci´on5.1.1.
Su implementaci´onen pseudo-c´odigo queda expresado en el C´odigo 18, y para revisar su implementaci´onfinal favor de referirse a los Anexos.
53 5.2. EXPLORADOR DE METADATOS
Codigo´ 18 Implementaci´onen pseudo-c´odigo de las funciones “sp RDF Generator” PROCEDURE sp_RDF_Generator (@id // identificador del documento a describir y generar )
/* Par´ametros */ @rdf // varchar representante de la estructura RDF/XML correspondiente // al recurso a ser descrito @metadato // varchar representante de la estructura RDF/XML de un // metadato particular
/* Setear Cabecera de archivo RDF/XML */ SET @rdf = ‘CABECERA_ESTANDAR’´
/* Por cada METADATO utilizado en el modelo */ SET @metadato = fn_add
/* Finalizar Descripci´on de recurso */ SET @rdf = ‘FIN_DE_ARCHIVO’
/* Crear y Escribir a archivo ‘‘@id.rdf’’ */ fn_write2File( @id, @rdf )
5.2. Explorador de Metadatos
Como puede se expres´oen la Secci´on4.3, en esta capa de la soluci´onya nos encontramos trabajando bajo un ambiente EN-L´INEA, por lo que para la implementaci´on se estim´oconveniente trabajar con un modelo J2EE 4. Tambi´en resulta necesario tomar decisiones en cuanto a las bibliotecas que se utilizar´an en la implementaci´ondado el lenguaje de programaci´ona utilizar. Con estos pre´ambulos en mente, y a modo de paralelizar con la soluci´onpropuesta, se detallar´aa continuaci´onesta capa de la implementaci´onsubdividiendola en sus 3 funcionalidades.
4Java 2 Platform Enterprise Edition. Plataforma de desarrollo para aplicaciones WEB basado en JAVA
54 5.2. EXPLORADOR DE METADATOS
5.2.1. Lector Metadatos RDF/XML
A estas alturas ya se poseen todos los metadatos descriptivos de las im´agenes en formato RDF/XML, los cuales podr´an ser accedidos EN-L´INEA. Para continuar con el procesamiento de la informaci´on, y con tal de aprovechar los trabajos realizados, se escogi´outilizar la biblioteca JRDF [New06], decisi´ontomada principalmente por la ventaja en velocidad con respecto a sus competidoras. Esta decisi´onse bas´oen la necesidad de presentar visualmente resultados en forma expedita para el usuario. Es as´ıcomo se implement´ola clase RdfXmlParser cuya implementaci´onen pseudo c´odigo se presenta en el C´odigo 19. Para m´as detalles dirigirse a Anexos.
Codigo´ 19 Implementaci´onen pseudo-c´odigo de “RdfXmlParser” public class RdfXmlParser { /* Implementaci´on de grafo rdf por biblioteca jrdf */ private Graph jrdfMemGraph_; /* Implementaci´on de parser por biblioteca jrdf */ private Parser rdfXmlParser_;
/* Parser del Grafo */ public RdfXmlParser ( URL ) { // Se intenta abrir URL try{ /* Se abre recurso y se parsea guardando su interpretaci´on en grafo */ } // Manejo de excepciones en caso de URL err´onea o recurso inexistente }
/* Retorna Grafo de recurso RDF/XML */ public Graph getGraph ()
}
5.2.2. Manejador de Ontolog´ıa Dublin Core
Ya recuperado el recurso y obtenido el grafo que permite explorarlo, es necesario comprender el vocabulario y los valores que presenta su descripci´onde manera tal que pueda ser visualizado.
55 5.2. EXPLORADOR DE METADATOS
Con el fin de comprender el vocabulario proporcionado por DCMI, se implementan las clases DCElements y DCTerms, cuyo fin es proporcionar las URI que describen los elementos y t´erminos existentes en DCMI. As´ısu implementaci´onen pseudo c´odigo queda determinada como se presenta en el C´odigo 20. Para m´as detalles referirse al Anexo.
Codigo´ 20 Implementaci´onen pseudo-c´odigo de Vocabulario public class DC
/* Definir URIs */ try{ TAG-NAME = new URI ( URI ) /* Instanciamos las URIs definidas por DCMI */ }// Nunca debiera fallar pues URIs no cambian
/* Constructor */ public DC
/* Retorno de URIReference por cada URI */ public URIReference TAG-NAME /* Retorna una referencia a la descripci´on del * recurso. Actualmente implementado por * biblioteca jrdf */ }
Con la comprensi´ondel vocabulario proporcionado por DCMI, se facilita la exploraci´on de un recurso, y con este fin se implementa la clase DCResourceHandler. Actualmente s´olo proporciona la capacidad de comprender la implementaci´ondel modelo que se est´atrabajando, y es as´ıcomo es presentado en pseudo c´odigo en el C´odigo 21. Para m´as detalles en su implementaci´onreferirse al Anexo.
En la actual implementaci´on, la clase DCResouceHandler, es la encargada tanto de conocer y manejar la estructura de recursos descritos utilizando la ontolog´ıa proporcionada por DCMI, como tambi´en de comprender el modelo implementado para los recursos en Memoria Chilena. Para esto ´ultimo utiliza la ayuda de las clases DCRelationsHandler que proporciona la comprensi´ony manejo de las relaciones descritas en el modelo seleccionado y la clase MCTools que proporciona valores propios del modelo y ubicaci´onde recursos. Resulta conveniente mencionar en pseudo c´odigo la clase DCRelationsHandler por lo que aparece en el C´odigo22.
Con la implementaci´onde estas clases es posible entregar la interfaz necesaria para
56 5.2. EXPLORADOR DE METADATOS
Codigo´ 21 Implementaci´onen pseudo-c´odigo “DCResourceHandler” public class DCResourceHandler {
/* Variables */ private URL url_; /* URL del recurso descrito */ private TripleFactory tripleFactory_; /* Fabrica de Triples RDF */ private Graph jrdfMemGraph_; /* Grafo RDF del representante del recurso */
private DCElements dcElements_; /* Vocabulario DC para elementos */ private DCTerms dcTerms_; /* Vocabulario DC para t´erminos */ private DCRelationsHandler dcRelationsHandler_; /* Manejador de Relaciones DC */
/* Constructores */ public DCResourceHandler () /* Constructor Nulo para instanciar recursos */ public DCResourceHandler (URL rdfXmlUri) /* Crea una instancia para el recurso * proporcionado en URL */
public DCResourceHandler( String rdfXmlUri) /* Crea una instancia para el * recurso proporcionado */
/* M´etodos */ /* Proporciona el nombre del recurso
/* Proporciona el t´ıtulo del recurso
/* Proporciona los nombres de los recursos relacionados con el recurso * descrito /* Actualiza el recurso descrito */ public int reload() /* Actualiza el actual recurso descrito al nuevo recurso proporcionado */ public int reload( String rdfXmlUri) } recuperar los datos del modelo descrito. Hay que recordar que esta capa es una mera interfaz para entregar las herramientas necesarias para facilitar la exploraci´onde los metadatos. La visualizaci´ones exclusiva de la siguiente capa y cuya implementaci´on ser´adescrita a continuaci´on. Tambi´en ser´aen la siguiente subsecci´ondonde se describir´an las relaciones y el flujo de datos entre la capa exploradora y visualizadora que son las que interact´uan entre s´ı. 57 5.3. VISUALIZADOR DE METADATOS Codigo´ 22 Implementaci´onen pseudo-c´odigo “DCRelationsHandler” public class DCRelationsHandler { /* Variables */ private static final int relationsType_; /* Tipo de relaci´on, actualmente de * acuerdo al modelo implementado private ClosableIterator isPartOf_; /* Iterador para relaci´on isPartOf */ private ClosableIterator isReferencedBy_; /* Iterador para relaci´on * isReferencedBY */ /* Constructor */ public DCRelationsHandler (Graph) /* Obtiene y genera los iteradores para el * recurso descrito */ /* M´etodos */ public String getNextRelationsName() /* Proporciona el nombre del pr´oximo * recurso recurso descrito */ /* Crea un nuevo manejador que describe al siguiente recurso relacionado en * iterador */ public DCResourceHandler getNextRelationsResource() } 5.3. Visualizador de Metadatos Como fue explicado en la Cap´ıtulo 4, la capa visualizadora se compone de dos funcionalidades que pueden ser divididas y comprendidas por separado para una mejor modularidad. Es as´ıcomo fue pensada e implementada esta ´ultima capa de la aplicaci´on, separando as´ı las funcionalidades y mejorando futuras actualizaciones sin tener que invertir costos innecesarios al intervenir en otras secciones del c´odigo. Utilizando este esquema, se proceder´aa explicar la implementaci´ondesde el interior (Capas L´ogicas mencionadas en las Subsecciones anteriores) hacia lo visible. 5.3.1. Interaccion´ con Explorador Esta es la ´ultima secci´onl´ogica de la aplicaci´on, y su funcionalidad consiste en intercambiar datos entre la capa exploradora y la capa visual. Para ello es necesario conocer la arquitectura de trabajo utilizada. 58 5.3. VISUALIZADOR DE METADATOS El lenguaje de implementaci´onseleccionado result´oser java por su compatibilidad y flexibilidad de trabajo. La arquitectura utilizada para desarrollo web por java es conocida como J2EE [Sun]. Como ayuda para la implementaci´onde aplicaciones web basadas en java, la organizaci´onApache Foundation Software ha desarrollado una arquitectura de trabajo conocida como Struts [Apa], con la cual fue finalmente implementada la aplicaci´on. Adicionalmente fue seleccionado como contendedor de servlets el servidor Tomcat 5, tambi´en perteneciente a la organizaci´onApache Foundation Software. Dentro de la estructura de trabajo, cada aplicaci´onweb est´acontenida dentro de un espacio conocida por el servidor como “contexto”. Sin necesitar profundizar m´as en la arquitectura, tan s´olo es necesario tener en conocimiento que es en el contexto donde se necesitan conocer las instancias a clases utilizadas por el explorador, y las variables necesarias para su interpretaci´one intercambio de informaci´oncon la m´ascara visual. Con esto en mente, las clases implementadas con este prop´osito resultan ser ContextListener y ContextFilter. ContextListener es la clase encargada de mantener y actualizar las variables de instancia utilizadas por la p´agina visualizada, y que permiten a la capa exploradora conocer lo que sucede en la p´agina visualizada y a su vez actualizar los valores necesarios para que ante un cambio en las selecciones en la p´agina visualizada el explorador pueda reaccionar y actualizar los valores y reflejarlos en la p´agina visualizada. Actualmente, la implementaci´onposee dos variables en el contexto, DCResourceHandler y currentResource, que permiten conocer cual es el actual recurso presentado y la exploraci´ondel recurso para realizar consultas sobre aquel. El resultado de esto queda expresado en el C´odigo 23. ContextFilter tiene la responsabilidad de obtener todos los cambios ingresados por el usuario y actualizar las variables del contexto para que de esa forma ContextListener pueda actualizar las variables de instancia y explorar los nuevos contenidos al contactarse con el explorador. Para cumplir con su prop´osito, la interacci´onentre las p´aginas web y ContextFilter se realiza a trav´es de cambios en formularios existentes en la p´agina web. As´ıContextFilter recibe los cambios de los valores en los formularios cada vez que son proporcionados por el usuario, actualizando as´ılos valores correspondientes para las variables de contexto. Lo parafraseado queda expresado en el C´odigo 24. 5http://tomcat.apache.org/ 59 5.3. VISUALIZADOR DE METADATOS Codigo´ 23 Implementaci´onen pseudo-c´odigo “ContextListener” public final class ContextListener implements ServletContextListener { /* Se inicializan variables del contexto */ public void contextInitialized (ServletContextEvent servletContextEvent) { //Obtener contexto de la aplicaci´on try { /* Crear variables instanciadas y relacionarlas con el contexto */ } catch (Exception e) { /* Manejar excepciones */ } } /* Cerrar variables al perder contacto con la aplicaci´on */ public void contextDestroyed (ServletContextEvent servletContextEvent) /* Obtener contexto, recuperar variables y removerlas del contexto */ } Codigo´ 24 Implementaci´onen pseudo-c´odigo “ContextFilter” public class ContextFilter implements Filter { private FilterConfig config = null; /* Se debe iniciar la clase para filtrar pedidos */ public void init /* Destructor de clase, utilizado por el servidor */ public void destroy /* Filtro de variables */ public void doFilter { /* Se obtiene el contexto y los par´ametros que se est´an enviando */ while ( Existan par´ametros ) { /* Obtener nombre y valor del par´ametro proporcionado por el formulario */ /* Por cada par´ametro recibido * Se filtra valor y se actualizan variables de contexto */ } /* Se actualiza hilo de ejecuci´on redibujando p´agina */ } } 5.3.2. Visualizacion´ Finalmente esta ´ultima secci´onde la implementaci´ones la que realmente percibe el usuario, y es la que recibe las respuestas proporcionadas por este brindando interactividad 60 5.3. VISUALIZADOR DE METADATOS con las capas l´ogicas. Est´acompuesta por p´aginas web implementadas en JSP, funcionalidades Javascript, estilos en CSS y por ´ultimo unas clases java que interact´uan con las p´aginas JSP. La aplicaci´onactualmente s´olo visualiza las relaciones de primer nivel, y para ello presenta de manera intuitiva la imagen visualizada con sus metadatos y junto a ella las im´agenes relacionadas y las unidades tem´aticas por las cuales est´an relacionadas. Esto ´ultimo puede ser apreciado en la Figura 5.1. Figura 5.1: Modelo Visual actual 61 Cap´ıtulo 6 Resultados Obtenidos y Esperados Finalmente por motivos de l´ımites de tiempo principalmente, no se logr´odesarrollar la aplicaci´onesperada, con exploraci´ony visualizaci´onde redes para las im´agenes, con todas los m´etodos y t´ecnicas de visualizaci´onpara redes actualmente desarrolladas. Pero sin duda se logra presentar una visualizaci´on, quiz´aalgo est´atica, pero que cumple con los objetivos planteados en el trabajo. A continuaci´on, a modo de ejemplificar los resultados se presentar´an una serie de fotos capturadas de la aplicaci´ony del portal para comparar la expresividad alcanzada. Figura 6.1: Relaciones de pintores realistas chilenos por medio de im´agenes Como puede ser apreciado en la Figura 6.2, para poder entablar una relaci´onentre los 62 pintores realista chilenos Baldomero Lillo, Blest Gana y Orrego Luco, en la actual aplicaci´on con las relaciones existentes, en el mejor de los casos resulta una b´usqueda en 3 pantallas y que adem´as no resulta intuitiva. Este es el caso hipot´etico en que el pintor que el usuario logr´orecordar fuese Orrego Luco, y necesitase otros retratos tanto de ese pintor como de sus relacionados. Ahora gracias a la implementaci´ony mejora del modelo de metadatos para la im´agenes, es posible relacionar con una sola b´usqueda a Luis Orrego Luco y sus temas relacionados como se puede distinguir en la Figura ??. En el ejemplo visualizado, las relaciones existentes para la imagen principal de Luis Orrego Luco, resultan ser su propia unidad tem´atica y la unidad tem´atica para el Realismo, sobre las cuales se pueden apreciar sus im´agenes de manera instant´anea en una sola potencial b´usqueda. Hay que mencionar que las relaciones presentadas en la implementaci´ones de un s´olo nivel, y que de esa manera logra ya rescatar relaciones entre im´agenes que se pierden en la actualidad, mejorando no tan s´olo la navegabilidad del portal, sino que tambi´en la usabilidad y sobrecarga tanto de infraestructura f´ısica por parte del portal, como de tiempo utilizado por el usuario que realiza la b´usqueda. Gracias a este simple ejemplo es posible rescatar la esc´enica de este trabajo, y presentar el ´exito logrado. Como se presentar´aen el Cap´ıtulo 7, a´un es posible ganar mucha m´as expresividad visualizando relaciones en segundo grado, permitiendo visualizar en una sola pantalla todas las im´agenes que se relacionan entre s´ı, y que en parte era lo que se deseaba llegar en primera instancia. A´un as´ıes satisfactorio haber logrado estos resultados en la soluci´onpresentada ya que alcanza a proporcionar la potencialidad latente del trabajo. 63 (a) Se ingresa b´usqueda por Orrego Luco. Al entrar al Sitio Tem´atico se percata que no se visualiza relaci´on con el tema “Realismo” (b) Revisando imagen se puede percibir relaci´on con tema “Realismo” (c) Al ingresar al tema “Realismo” se logra percibir relaciones de im´agenes Figura 6.2: Secuencia de b´usqueda de relaciones de pintores realistas chilenos 64 Cap´ıtulo 7 Conclusiones y Trabajo Futuro Se presenta a continuaci´on posibles mejoras que se podr´ıan realizar al trabajo presentado, ya sean por motivos de tiempo como otros aspectos que ser´ıa interesante desarrollar pero que no eran abarcadas por la tesis. Finalmente, son planteadas las conclusiones a la cuales se lleg´oen esta tesis. 7.1. Trabajo Futuro Sin duda, la soluci´onpresentada tiene gran potencial tanto en la visualizaci´oncomo en la exploraci´on. Mejorando estos puntos permitir´ıan entregar a´un m´as expresividad, es decir, mayor informaci´onvisual relacionada. Para aquello se pueden observar los puntos a continuaci´on. 7.1.1. Visualizacion´ Uno de los objetivos que no se logr´orealizar por l´ımites de tiempo, fue efectivamente la visualizaci´onde elementos como una presentaci´onen red. Actualmente es posible encontrar varios visualizadores de redes implementados en diversos lenguajes. La tesis no tiene como objetivo lograr mejores algoritmos o t´ecnicas de visualizaci´onen redes, por lo que no ser´ıa deseable implementar una nueva capa visualizadora que entregara dicha funcionalidad. Con el objetivo de mejorar este aspecto ser´ıa necesario implementar una 65 7.1. TRABAJO FUTURO capa intermedia de comunicaci´onque permitiera conectar alguna aplicaci´onvisualizadora o biblioteca externa con el modelo l´ogico implementado en la soluci´on. 7.1.2. Exploracion´ La soluci´onimplementada en la tesis trabaja directamente con las relaciones en el modelo de metadatos obtenido de la catalogaci´onrealizada por Memoria Chilena. Sobre este punto existen varias posibles mejoras que permitir´ıan obtener m´as relaciones y quiz´allegar de manera m´as directa al resultado buscado por el usuario. Una primera mejora y mencionada en el documento, es la implementaci´onde otro de los modelos presentada en la soluci´on, que por distintos problemas no se logr´oobtener la informaci´onnecesaria para implementarla a tiempo. Sin duda mientras mayor detalle proporcione el modelo, mayor va a resultar la expresividad si se explota de manera adecuada. Otra posible mejora que no fue presentada, es la implementaci´on de esquemas RDF que modelen las relaciones de los recursos utilizados por Memoria Chilena. Resulta intuitivo crear clases en RDFS que representen unidades tem´aticas, detalles tem´aticos, y documentos digitales, permitiendo a˜nadir al modelo nuevas relaciones resultantes del esquema y sin sobrecargar los metadatos de cada recurso. La soluci´onimplementada como fue descrita en la tesis, posee una capa que permite la comunicaci´oncon una biblioteca externa que proporciona la funcionalidad de parser RDF. Esta biblioteca, posee la habilidad de permitir generar consultas en SPARQL, vale decir, consultas directas sobre el modelo de metadatos. Explotando esta habilidad es posible generar un motor de b´usquedas que permitan contestar consultas interesante prefabricadas, como por ejemplo, que im´agenes se relacionan con la buscada seg´un cierto tema, o seg´un cierto per´ıodo de tiempo. As´ımismo es posible generar consultas sobre los metadatos en l´ınea, es decir, permitir al usuario crear su propio filtro para la visualizaci´ony relaciones entregadas. 7.1.3. Otras Mejoras Uno de las dificultades que se presentaron al momento de la implementaci´on, result´oser que no se encontraron bibliotecas que permitieran manejar la ontolog´ıa Dublin Core. En la b´usqueda por bibliotecas que permitieran el manejo de datos en 66 7.2. CONCLUSIONES RDF/XML, se lleg´oa la biblioteca RDF2GO 1, que es b´asicamente una m´ascara para las bibliotecas manejadoras de RDF m´as conocidas, permitiendo as´ıuna libre implementaci´on sin preocuparse posteriormente en tener que cambiar c´odigo para un cambio en la decisi´on de la biblioteca seleccionada para manejar RDF. De forma an´aloga, resultar´ıa interesante explotar la implementaci´ondel paquete mcviz/tools/dc que contiene todas las clases encargadas del manejo y comprensi´ontanto del vocabulario como de parsear un documento RDF expresado en la ontolog´ıa Dublin Core. As´ıse lograr´ıa proporcionar una biblioteca con una serie de rutinas que permitan al desarrollador parsear documentos RDF descritos con Dublin Core, y sin tener que preocuparse a priori sobre que biblioteca RDF utilizar para la aplicaci´on, permitiendo seleccionar varias sin un sobre-calentamiento al modificar c´odigo. 7.2. Conclusiones 1Mencionada en Cap´ıtulo 3 67 Bibliograf´ıa [Apa] The Apache Software Foundation. Apache Struts 2 Documentation. Documentaci´onpara utilizaci´onde arquitectura de trabajo basada en Struts. URL: http://struts.apache.org/2.0.9/docs/home.html. [cbi05] A Semantic Web based approach to multimedia retrieval, 2005. 2005 Fourth International Workshop on Content-Based Multimedia Indexing (CBMI05). Riga, Latvia, 21-23 June 2005. Proceedings of the conference. [Dub06] Dublin Core Metadata Initiative. Dublin Core Metadata initiative, 2006. Un foro abierto centrado en el desarrollo de interoperar en l´ınea est´andares de metadatos que soporten una gran variedad de prop´ositos y modelos de negocios. URL: http://dublincore.org. [hal04] Discovering and Ranking Semantic Associations over a Large RDF Metabase, 2004. C. Halaschek, B. Aleman-Meza, I.B. Arpinar, and A.P. Sheth. Discovering and Ranking Semantic Associations over a Large RDF Metabase (Demonstration Paper). In M. Nascimento, editor, Proceedings of VLDB 2004. Morgan Kaufman, 2004. [LD06] Boanerges Aleman-Meza Leonidas Deligiannidis, Amit P. Sheth. Semantic analytics visualization. 2006. (To Appear in) Proceedings of the IEEE International Conference on Intelligence and Security Informatics 2006 (ISI-2006), May 23-24, 2006, San Diego, CA, USA. [New06] Andrew Newman. Querying semantic web using a relational based sparql, 2006. [sem06] Semantic visualization, 2006. Herramientas para la visualizaci´oncomprensiva, b´usqueda interactiva e interfaces anal´ıticas para la explotaci´onde la Web Sem´antica. URL: http://lsdis.cs.uga.edu/projects/semvis. [Sim96] Susan Sim. Automated graph drawing algorithms, 1996. CSC2410F, Algorithms in Graph Theory. Academic Paper. URL: citeseer.ist.psu.edu/sim96automatic.html. [Sun] Sun Microsystems, Inc. The J2EETrademarked 1.4 Tutorial. Tutorial para el desarrollo de aplicaciones J2EE 1.4 basadas en Sun Java System Application 68 BIBLIOGRAF´IA Server Platform Edition 8.2. URL: http://java.sun.com/j2ee/1.4/docs/tutorial/doc/. [TBLL01] James Hendler Tim Berners-Lee and Ora Lassila. The semantic web. Scientific American, 2001. [VD04] Fernanda Vi´egas and Judith Donath. Social network visualization: Can we go beyond the graph?, 2004. Workshop on Social Networks for Design and Analysis: Using Network Information in CSCW. In CSCW 2004. [W3C06] W3C, MIT Libraries, and MIT CSAIL. Semantic Interoperability of Metadata and Information in unLike Environments, 2006. Sitio repositorio de proyectos open source, con el objetivo de poetenciar el desarrollo de la Web Sem´antica. URL http://simile.mit.edu. [Wor04a] World Wide Web Consoritum. RDF Primer, W3C Recommendation 10 February 2004, 2004. Descripci´on del est´andar RDF y sintaxis. URL: http://www.w3.org/TR/rdf-primer/. [Wor04b] World Wide Web Consoritum. RDF/XML Syntax Specification (Revised), 2004. Descripci´on de la sintaxis XML para RDF, denominada RDF/XML. URL: http://www.w3.org/TR/rdf-syntax-grammar/. 69