PLATAFORMA DE INTEGRACIÓN DE RECURSOS EDUCACIONALES EN LA WEB CHILENA TESIS PARA OPTAR AL GRADO DE MAGÍSTER EN CIENCIAS, MENCIÓN COMPUTACIÓN

Transcripción

1 UNIVERSIDAD DE CHILE FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN PLATAFORMA DE INTEGRACIÓN DE RECURSOS EDUCACIONALES EN LA WEB CHILENA TESIS PARA OPTAR AL GRADO DE MAGÍSTER EN CIENCIAS, MENCIÓN COMPUTACIÓN ERNESTO JUAN KRSULOVIC MORALES PROFESOR GUÍA: CLAUDIO GUTIÉRREZ GALLARDO MIEMBROS DE LA COMISIÓN: ROSA ALARCÓN CHOQUE PABLO BARCELÓ BAEZA SERGIO OCHOA DELORENZI SANTIAGO DE CHILE DICIEMBRE 2010

2 RESUMEN DE LA TESIS PARA OPTAR AL GRADO DE MAGÍSTER EN CIENCIAS, MENCIÓN COMPUTACIÓN POR: ERNESTO KRSULOVIC MORALES FECHA: 15/12/2010 PROF. GUÍA: CLAUDIO GUTIÉRREZ GALLARDO PLATAFORMA DE INTEGRACIÓN DE RECURSOS EDUCACIONALES EN LA WEB CHILENA La Web está evolucionando desde una red documental a una red de datos. La investigación desarrollada trata sobre la publicación de datos distribuidos en esta Web de datos, mediante RDF (Resource Description Framework, estándar del Consorcio de la Web). Utilizando este modelo se tienen los datos enlazados y estructurados, lo que facilita la recuperación, reutilización e integración de la información. Los desafíos enfrentados en la tesis dicen relación con las dificultades de trabajar con la tecnología RDF, debido a la necesidad de modelar los esquemas, transformar los datos y definir métodos de publicación en este nuevo modelo de datos. Para cada una de esas necesidades, en la investigación se desarrolla una solución: implementando herramientas que permiten modelar vocabularios, generando procesos de recolección de datos y definiendo convenciones para direcciones (URL) y estrategias de publicación. En el marco teórico se pone énfasis en la problemática de modelamiento, donde se describen los aspectos relevantes a considerar cuando se generan taxonomías y vocabularios. La contribución novedosa de la tesis dice relación con la implementación de estas ideas a nivel nacional, al tomar como casos de estudio sitios chilenos. Los casos desarrollados son dos: el primero en el ámbito de las organizaciones educacionales, con los datos de las Escuelas de Chile, usando información del sitio infoescuela.cl. El segundo caso es sobre los organismos gubernamentales, con los datos de Transparencia Activa que debe publicar en su sitio Web cada órgano del Estado. En los casos de estudio se presentan soluciones y se enfatiza el registro de problemas encontrados. Se presentan también algunos desarrollos nuevos, implementando herramientas que facilitan el modelamiento de vocabularios mediante aplicaciones Web. La contribución adicional tiene que ver con la difusión del marco conceptual que sirve de base a esta investigación. Para ello, durante el período de la tesis se mantuvo en paralelo una bitácora de trabajo en la Web, mediante el blog donde además se encuentran disponibles los enlaces a las herramientas desarrolladas. La principal conclusión de la tesis es la validación de una cadena de producción aplicada en los casos de estudios, donde primero se modelan los datos, luego se recolectan y finalmente se publican en formato RDF. Se presenta también una propuesta de infraestructura necesaria para implementar esta solución en los datos del Estado. Por último se detallan iniciativas de trabajo futuro, para continuar con los desarrollos iniciados durante el transcurso de la investigación.

3 dedicado a mi padre que ya no está y a mi hijo que ya está 3

4 Índice general I Introducción Marco Teórico Evolución de la Web Web Datos Vinculados Modelamiento de Taxonomías Problemas, Objetivos, Metodología y Contribuciones Problemas Objetivos Metodología Metodología de Modelamiento Contribuciones II Desarrollo Editor RDF Trabajos Relacionados Implementación

5 4. Editor Compartido de Vocabularios Trabajos Relacionados Implementación Casos de Uso Vocabulario Visual Trabajos Relacionados Propuesta Ejemplos III Casos de Estudio Escuelas Chilenas Fuente de Datos Diseño Publicación Transparencia Chilena Fuente de Datos Diseño Publicación IV Conclusiones Resultados y Discusión 57 5

6 9. Trabajo Futuro Publicación de Datos del Estado Continuación del Desarrollo Bibliografía 63 6

7 Índice de figuras 1.1. Componentes de la Web Semántica Representación gráfica de triples RDF Niveles de modelamiento conceptual Componentes del editor RDF Ejemplo RDF donde fallan los parsers javascript Componentes del editor de vocabularios Ordenamiento topológico Vocabulario Time Elementos del vocabulario visual Conexiones de elementos en el vocabulario visual Ejemplo: triples Ejemplo: propiedad con anotación Ejemplo: anotaciones e instancias Tratamiento de datos abiertos Vocabulario Escuela Vocabulario para describir datos de contacto

8 6.3. URL para vocabularios URL para recursos Esquema para los datos de transparencia Esquema para describir dotación Instancia en el vocabulario visual Script para importar datos en virtuoso CLI para importar datos en Virtuoso Contexto del trabajo realizado Enlaces a sitios con resultados de la Tesis

9 Índice de cuadros 3.1. Características de editores de diagramas Características de editores de vocabularios Evaluación de alternativas para casos de estudios Clases de un vocabulario mínimo para crear esquemas Propiedades de un vocabulario mínimo para crear esquemas Porcentaje de instancias para cada clase Información de dotación nominal y recolectada

10 Parte I Introducción 10

11 Capítulo 1 Marco Teórico Los primeros años de la Web estuvieron llenos de estudios asociados a las Ciencias de la Computación: hipertextos, recuperación de la información, sistemas distribuidos, entre otros. No fue hasta hace unos pocos años cuando la Web se convierte en una rama de estudio, donde no sólo se tratan temas computacionales, sino que también económicos, psicológicos, legales, socio-culturales, etc. Frente a esto, surgen nuevas líneas de investigación, como la recientemente denominada Ciencias de la Web, cuyo objeto de estudio se centra en los sistemas de información distribuidos, tema sobre el que trata el presente documento. Como se describe en "A Framework for Web Science" [43] resultado de un workshop llamado "Web Science", realizado en Londres el mes de septiembre del 2005 "La Ciencia de la Web no trata sólo de métodos para modelar, analizar y entender la Web en distintos niveles, trata también sobre cómo administrar protocolos e infraestructura, de asegurar que exista un calce entre la infraestructura y la sociedad que lo aloja. La Ciencia de la Web debe coordinar la ingeniería con una agenda social; políticas con restricciones y alternativas técnicas; análisis con síntesis." Los protocolos e infraestructura de la Web están delineados por el Consorcio de la Web W3C (World Wide Web Consortium) institución dirigida por el creador de la Web, Tim Berners Lee, quien a fines de la primera década de existencia de la Web impulsó lo que se conoce como Web Semántica y pasó la segunda década buscando lo que se denominó "killer application", a objeto de impulsar y difundir los principios de la Web Semántica. Fue justamente uno de estos principios, proveniente de la rama de estudios de Metadatos y Base de Datos, los que hoy podemos considerar como la "aplicación matadora", que dice relación con la publicación de datos en la Web, o lo que se denomina "Linked Data". 11

12 La investigación desarrollada se debe revisar como un ejercicio de la práctica relativa a la publicación de datos distribuidos en la Web (linked data), entendiendo por práctica la repetición de una metodología preconcebida. La contribución novedosa de esta Tesis dice relación con la implementación a nivel nacional, al tomar como objeto de estudio sólo sitios Chilenos y pone especial énfasis en el registro de los problemas encontrados. Además, se presentan algunas propuestas novedosas, todas relacionadas con una plataforma para facilitar el modelamiento de vocabularios. La rápida evolución es lo que ha caracterizado el comportamiento de la Web en los últimos años, ante esto, es importante hacer un breve análisis de los aspectos y conceptos fundamentales en el desarrollo de esta investigación, de manera tal que facilite la comprensión al lector Evolución de la Web La Web se inventó con una metáfora documental, que puede considerarse como una réplica de un llamado de acción al mundo científico de la posguerra, realizado en 1945 por Vannevar Bush [44], con el objeto de acelerar el acceso a la inmensidad de artículos científicos disponibles. El trabajo documental se ha desarrollado por años en el mundo de la bibliotecología y la archivística, y es desde ese mundo de donde provienen las ideas para las primeras aplicaciones en la Web, como índices, catálogos y buscadores. En el intertanto, la Web desató potencialidades que debido a limitaciones tecnológicas estaban ocultas. Una de ellas, la posibilidad de interacción social rompiendo las barreras geográficas, ha surgido con tal potencia, que muchos han creído ver en ella una nueva etapa de la Web, llamándola Web 2.0 [55]. Las redes sociales con diferentes objetivos, como facebook, delicious, youtube, etc., los blogs, el fenómeno twitter, han dado a la interacción social una dimensión antes desconocida. Sin embargo, el siguiente estadio natural de la Web es el paso de una Web de documentos a una Web de datos. La idea se origina con la denominada Web Semántica, una iniciativa para agregar significado y razonamiento a la información en la Web. Con el correr del tiempo, de esta iniciativa surgió una visión más modesta, cuyo objetivo era lograr al menos un primer nivel de relacionamiento de la información, que puede considerarse una suerte de razonamiento básico, llamado Linked Data (datos vinculados). Esta iniciativa es particularmente relevante para los mayores productores de datos en el mundo actualmente, las investigaciones científicas y los gobiernos. Al igual que en la posguerra, hoy existe un desafío común en el mundo científico, 12

13 que hace un llamado a acelerar el acceso a los datos científicos para resolver los grandes problemas que afectan a la humanidad, como son la búsqueda de cura a enfermedades y el cambio climático [51] Web 2.0 En la primera generación de la Web el servicio fundamental era buscar recursos basándose en patrones, materia que ha sido de amplio estudio por la disciplina de recuperación de la información. Una implementación de referencia para este tipo de servicios es Google. Es en la segunda generación de la Web, la llamada Web2.0 [54], donde encontramos que a la búsqueda inicial de recursos se agregan diversas opciones, tales como: Colaborar en los recursos, utilizando ambientes de edición distribuida. El ejemplo más claro es el de los wiki, siendo Wikipedia el más difundido. Cada vez más la opción de edición distribuida se agrega a las aplicaciones Web, como es el caso del conjunto de herramientas de oficinas que presenta Google docs. Compartir los recursos, los cuales pueden ser enviados por en una primera etapa de implementación, opción que se presenta al final de una noticia o artículo en los administradores de contenidos, se incluye luego en los servicios centralizados de blogs, para después permitir el envío no sólo a sino que también a redes sociales, micro contenidos o sistemas de mensajería instantánea. Clasificar los recursos, mediante el uso de etiquetas (o "tags"), lo que es equivalente al uso de palabras claves o "keywords" en los sistemas de clasificación bibliográfica. A diferencia de estos no se maneja mediante un vocabulario controlado sino que con un vocabulario que se deja a discreción del usuario. Al utilizar estas etiquetas se puede clasificar en múltiples categorías un recurso, lo que es mejor que clasificar en una estructura de directorio, como fue el inicio de yahoo o dmoz. Existen múltiples servicios que permiten esta opción y depende del tipo de recurso que se está clasificando, por nombrar algunos: delicious [5]; citeulike [3]; flickr [12]. Las herramientas de administradores de contenidos y blogs incorporan esta opción con mayor frecuencia. En los últimos años se ha llamado folksonomías al conjunto de etiquetas que describen un tipo de recursos y se ha presentado como una opción a la creación distribuida y automática de ontologías [53]. Comentar los recursos, incorporando hilos de discusión. En una primera instancias estos hilos se implementaron directamente en los sistemas de administración de contenidos, 13

14 luego pasaron a los sistemas de blogs centralizados para luego incorporarlos en sistemas de recursos especializados (al estilo de delicious, flickr, citeulike, etc). Hoy se presentan también opciones para tener esta funcionalidad desde un sistemas centralizado de comentarios, como son disqus, jskit o el reciente sidewiki de google. Calificar los recursos, agrupando en una lista de favoritos (una valoración binaria) o bien calificando en un rango de notas (al estilo del rango de estrellas para una película). Ejemplos de estas opciones, son los servicios de bookmarks sociales (delicious es uno), y marcar con una estrella en los servicios de google (google code, google reader, google mail e incluso en el administrador de bookmarks de browser google chrome). La calificación con una escala de valores, es una funcionalidad ofrecida con mayor frecuencia por los sistemas de administradores de contenido y blogs centralizados. Sitios como Digg presentan un modelo de calificación distribuida para ordenar los recursos. Conservar los recursos, se debe a que no es suficiente enlazar un recursos mediante una referencia link, sino que se hace necesario mantener copias distribuidas de recursos. La necesidad parte primero por el requerimiento de procesar y analizar grupos de recursos, pero también para garantizar la disponibilidad de los servicios. Servicios a fines a esta opción son: el cache de google, el internet archive, concentradores rss, concentradores y aplicaciones basadas en microcontenidos de twitter, direcciones URL permanentes. Cada opción de trabajo basada en los recursos, es un patrón utilizado en la Web2.0. Hoy no existe una implementación de todas las funcionalidades descritas de forma conjunta, quizás lo que más se parece es el servicio diigo [8], que se define como una red de información social. La última opción hace referencia a Componer, donde se "utiliza información y/o funcionalidad complementaria desde múltiples sitios". Ejemplos de composiciones son los ambientes que utilizan google maps para presentar ubicación geográfica de datos, o el uso de Yahoo Pipes para procesar información. Si bien las composiciones son propias de la Web2.0 [54], se encuentra en la frontera con la siguiente generación de la Web, ya que es una opción para trabajar directamente con datos del recurso (que son lo llamados metadatos), y no con el recurso directamente. Para la composición se utilizan diferentes API, que rescatan y publican información estructurada en XML o JSON vía AJAX. 14

15 1.3. Datos Vinculados Recordemos que la primera generación de la Web permite publicar y consultar documentos, vimos como la Web 2.0 entrega opciones colaborativas, pero ahora el problema es: cómo agregar datos en la Web?, entendiendo por agregar una visión de integración de información, que implica recolectar y reconciliar los datos y esquemas, tarea que hasta ahora se resuelve de dos maneras: 1. Se generan o cargan los datos en un servicio central que mantiene el esquema y concentra los datos. 2. Se realiza una agregación manual de los datos. La idea en linked data es utilizar un modelo común (RDF) y vocabularios para publicar los datos en la Web, siguiendo una parte de las recomendaciones del Consorcio de la Web. Si bien parte de la infraestructura ya está resuelta, como son el modelo de datos y vocabularios RDF(S), el modelo de ontologías OWL y el lenguaje de consulta SPARQL, queda aún por definir soluciones en las áreas de reglas, lógica, prueba, criptografía, confianza e interfaz de usuario y aplicaciones. Todos estos componentes forman parte de la Web Semántica, que se ilustran en la figura 1.1, que es un diagrama obtenido en [30]. RDF es un modelo sencillo de datos para describir recursos o información en la Web, se basa en sentencias del tipo sujeto-predicado-objeto denominados triples RDF. En un triple RDF el sujeto puede ser un URI o un nodo anónimo (llamados blank nodes o BNODE), el predicado es un URI (descrito en un esquema RDFS u ontología OWL), por último el objeto puede ser un URI, un BNODE o un literal (tipo de datos string u otro definido en los tipos de datos de XML). El ejemplo de la figura 1.2, tomado desde [27], muestra una representación gráfica de triples RDF. Los datos vinculados (linkeddata) se pueden revisar dentro del concepto de dataspaces o espacio de datos, que se define como una colección de distintas fuentes de datos para un dominio específico, estas fuentes de datos se denominan participantes y son diferentes en esquema y modelo. En un dataspace se modelan relaciones entre uno o más participantes, por ejemplo que un participante es una vista o réplica de otro; especificar la equivalencia de esquema entre dos participantes; etc. El concepto de dataspace es un trabajo en desarrollo [48], y al igual que en bases de datos, en general se refiere al sistema que lo implementa, que en este caso se denominan plataforma de soporte de espacio de datos (DSSP). Entre los desafíos de investigación en el área 15

16 Figura 1.1: Componentes de la Web Semántica. de dataspaces están algunos que provienen de los servicios de base de datos, como son: almacenar; indexar; consultar. Asimismo, existen otros desafíos notables, relacionados con descubrir participantes, reutilizar la interacción humana y garantizar la corrección. A modo de ejemplo, es posible mencionar un administrador de información personal (PIM), un administrador de datos científicos, etc Modelamiento de Taxonomías Todos los modelos son inexactos, pero algunos modelos son útiles. George Box. Un anhelo recurrente para las comunidades es lograr un modelo único y compartido, ojalá lo más reducido posible, como es el caso de las teorías unificadas en física. Es el vocabulario del lenguaje natural el que constituye un primer modelo compartido, el cual es estudiado por las ciencias cognitivas y, según Jerry Fodor [47], permite traducir los conceptos que comunicamos mediante este lenguaje natural a un lenguaje primario, que es denominado mental y que es el lenguaje del pensamiento. A lo largo de la historia, filósofos, científicos y otros estudiosos han 16

17 Figura 1.2: Representación gráfica de triples RDF. nombrado y organizado los elementos más destacados del mundo. A menudo, hay insatisfacción con los conceptos elegidos, con la granularidad con la que están representados los conceptos y con la estructura jerárquica o de relación en la que los conceptos han sido colocados [52]. Habitualmente nos vemos enfrentados a tareas relacionadas con clasificaciones de los objetos que nos rodean, agrupamos la ropa en un closet; separamos los vegetales en un refrigerador; organizamos los muebles de una habitación; dividimos las secciones de un documento; seleccionamos las personas para un proyecto. En función de nuestra experiencia, el medio ambiente y nuestras necesidades, utilizamos distintos niveles de detalle para realizar estas tareas habituales. Lo que está detrás de cada una de estas acciones es una taxonomía de clasificación. Según David Weinberger [58], existen tres niveles de ordenación, el primero dice relación con aquellas tareas habituales (orden de las cosas), el segundo con el catálogo de las cosas y el tercero con el orden en el ámbito digital. Los primeros dos niveles tienen restricciones físicas, ya que las cosas utilizan espacio y éste se encuentra muy acotado. No es igual en el mundo digital, donde la restricción de espacio físico no existe. Las taxonomías constituyen un primer paso de modelamiento conceptual, al agregar relaciones jerárquicas a un vocabulario, los siguientes niveles son los tesauros y ontologías, esquematizado en la figura 1.3. Al modelar una taxonomía, es necesario considerar algunos aspectos relevantes, que a continuación se detallan: Agrupadores versus Divisores. Los primeros modelos de clasificaciones nacen al alero de las ciencias biológicas, con los taxonomistas de las ciencias de historia natural, cuyo objetivo es estudiar las relaciones de parentesco entre los organismos y su historia evolutiva. En este contexto y revisando un articulo reciente de la revista Science [46], encontramos uno 17

18 Figura 1.3: Niveles de modelamiento conceptual. de los primeros aspectos a considerar al momento de modelar y dice relación con cuando debemos agrupar un concepto o cuando debemos dividirlos. Top-Down versus Botton-Up. Hay dos estrategias básicas para construir taxonomías: Top- Down (arriba hacia abajo) o Botton-Up (abajo hacia arriba). Una estrategia de arriba hacia abajo generalmente se desarrolla en forma manual ofrece control de los conceptos mas generales que se encuentran en la taxonomía de los niveles más alto. Una estrategia de abajo hacia arriba utiliza tecnologías automáticas para extraer los conceptos básicos y hacer generalizaciones acerca de ellos. Facetas. En la bibliotecología se han desarrollado distintos sistemas de clasificación, todos específicos para los libros, uno de los cuales se llama Clasificación Colonada, desarrollada por S. R. Ranganathan y se conoce como la primera clasificación de facetas, ya que divide los campos o disciplinas científicas según distintos puntos de vista o facetas. La Clasificación Colonada se ideó para clasificar las distintas ramas del saber humano; divide al conocimiento en 47 clases principales, divididas a su vez en 10 subclases y está compuesta por cinco categorías fundamentales, a saber, personalidad, energía, materia, espacio y tiempo. Partes del Todo. Uno de los tipos de jerarquía son las relaciones del tipo partes del todo, en A taxonomy of part-whole relations [59] se detallan seis tipos de meronimias: 1) Componente/Objeto (e.g. mango-taza); 2) Miembro/Colección (e.g. árbol-bosque); 3) Porción/Masa (e.g. grano-sal); 4) Material/Objeto (e.g. acero-bicicleta); 5) Característica/Actividad (e.g. Pagar-Ir de compras); 6) Lugar/Área (e.g. Oasis-Desierto). Una me- 18

19 ronimia corresponde a una relación semántica del tipo inclusión, dentro de las cuales también están las relaciones espaciales y las de clases. Clases y Prototipos. Al modelar un dominio de interés utilizando una visión Orientada a Objetos (OO) es natural identificar las clases a la cual pertenecen los instancias. Existe otra forma de modelar, basada en prototipos, donde no se hace tal distinción y sólo existen objetos. También existen desventajas al momento de modelar usando clases, ya que como se describe en [57], no todos los conceptos se pueden modelar con clases, no existe una jerarquía de clases óptima, los diseños son basados en consensos, los modelos son sólo lo suficientemente buenos, el proceso de construcción de la jerarquía de clases es inherentemente iterativo. En el mismo documento, junto con describir los hechos filosóficos que justifican modelar usando prototipos, se plantean ejemplos notables que recalcan estos puntos. Un ejemplo de un concepto que es difícil de definir en términos de propiedades compartidas es "obra de arte". Ya que nadie puede definir límites claros para lo que es arte y qué no lo es, no hay ninguna clase general "obra de arte", que comparta propiedades comunes. La definición es subjetiva y depende en gran medida de la situación o el punto de vista. Algunas personas viviendo cerca del Ecuador no pueden distinguir entre hielo y nieve, mientras los esquimales tienen numerosas palabras para distinguir entre distintos tipos de nieve. Los Dani, de Nueva Guinea, tienen sólo dos términos de colores básicos: mili (oscuro / frió) y mola (luminoso / cálido) que cubre el espectro completo y tienen una gran dificultad para diferenciar entre colores con mayor detalle. 19

20 Capítulo 2 Problemas, Objetivos, Metodología y Contribuciones 2.1. Problemas La investigación aborda el problema de publicar datos estructurados en la Web, que en términos concretos equivale a trabajar con datos modelados en RDF. Como una vista previa, los problemas tratados en la Tesis son los siguientes: Qué herramientas utilizar para modelar en RDF(S)? Cómo obtener y convertir datos a RDF? Cómo nombrar los recursos (URI) y publicar los datos? Cuál es el flujo de producción para publicar datos en la web? Cuáles son los aspectos mínimos a considerar en una plataforma general de publicación de datos? Para acotar el trabajo desarrollado, existen también problemáticas que no son abordadas en esta investigación, en particular los temas de privacidad, procedencia y visualización de los datos. 20

21 2.2. Objetivos El objetivo central de esta investigación consiste en probar las tecnologías RDF para publicar los datos en la Web. La necesidad obedece al paso de una Web de documentos, donde existen múltiples plataformas probadas y validadas, a una Web de datos, donde no existen experiencias a nivel local. En particular se presentan los siguientes objetivos específicos: Desarrollar herramientas de apoyo a la publicación de datos Implementar casos de ejemplo Se identifica el hecho que con las herramientas existentes, el énfasis debe estar en herramientas que faciliten la tarea de modelar los vocabularios necesarios para publicar los datos en la Web. En el área de almacenamiento y consulta existen diversas opciones para seleccionar un sistema administrador de base de datos con soporte SPARQL estándar. El desarrollo de heramientas de modelamiento se justifica debido a la dificultad existente al escribir datos y modelos en RDF. Además, se tiene la necesidad de contar con una representación visual para ser usado por personas, que apoye la divulgación y validación de los modelos construidos. Una vez desarrollados los objetivos se tendrán como resultados ejemplos, herramientas y una propuesta de infraestructura general. Estos resultados permitirán demostrar las ventajas de publicar los datos en la Web. Se destacan dos beneficios inmediatos, primero obtener un completo acceso a la información; segundo la oportunidad de generar nuevas aplicaciones a partir de los datos publicados Metodología La metodología empleada en el desarrollo de esta Tesis dice relación con: 1. Desarrollar herramientas de apoyo a la publicación de datos en la Web: diseñar e implementar las herramientas que apoyen el modelamiento de vocabularios. 2. Implementar casos de ejemplo: codificar los vocabularios, identificar fuentes de datos, recolectar y reconciliar datos, publicar vocabularios y datos agregados. 21

22 La metodología presentada para la publicación de datos en la Web es la propuesta por el Consorcio de la Web (W3C), donde se requieren dos pasos importantes, a saber, generar un vocabulario y publicar en la Web los datos en formato RDF. El énfasis está dado por la problemática de modelar un vocabulario. Para la publicación de los datos la metodología seguida es básicamente la misma de publicar documentos en la Web (dividir en páginas). El énfasis a continuación se pondrá en la problemática del primer paso, que es modelar un vocabulario Metodología de Modelamiento Una taxonomía es una lista jerárquica de términos que permiten realizar clasificaciones y particiones conceptuales. Asimismo una ontología se define como una formalización de una conceptualización compartida [50]. En el ámbito de la Web una taxonomía se formaliza con el mismo lenguaje que una ontología, este lenguaje es OWL (Web Ontology Language). Existen diferentes métodos para el desarrollo de modelos. En el marco teórico se presentaron los puntos a considerar al momento de crear una taxonomía. Para el caso de las ontologías [20] el método utilizado durante el trabajo de Tesis es la metodología de Uschold y King, que permite la creación de ontologías en base a otras ya existentes. Recomienda los siguientes pasos: 1) identificar el propósito para el cual se construye la ontología, 2) capturar los conceptos y las relaciones entre ellos, 3) codificar la ontología, 4) evaluar la ontología, 5) documentar la ontología Contribuciones La contribución novedosa de la Tesis dice relación con la implementación de estas ideas a nivel nacional, al tomar como casos de estudio sitios Chilenos. En los casos se presentan soluciones y se enfatiza el registro de problemas encotrados. Se presentan también algunos desarrollos nuevos, implementando herramientas que facilitan el modelamiento de vocabularios mediante aplicaciones Web. Una última contribución es la validación de una cadena de producción, aplicada en los casos de estudios de la tesis, donde primero se modelan los datos, luego se recolectan y finalmente se publican en formato RDF. 22

23 Parte II Desarrollo 23

24 Capítulo 3 Editor RDF El apartado presenta la herramienta desarrollada, un editor RDF, que permite generar modelos RDF mediante una aplicación Web. La necesidad de tener esta herramienta dice relación con la facilidad que presta tener en la Web estos diagramas, a diferencia de tenerlos en una aplicación de escritorio. Esta sección se aborda el estudio de diferentes herramientas similares, sus principales características, objetivos y problemáticas asociadas a la implementación. El diagrama es una representación simbólica de información destinado esencialmente a ser visualizado por personas. En "No tengo palabras para decirlo..." [22] es posible encontrar una descripción de los diagramas y su uso cuando se considera como "lenguaje de modelamiento y herramienta". Los diagramas son sistemas-sígnicos concebidos por la mente humana para propósitos de imaginación, modelamiento, diseño técnico, comprensión social, comunicación y pensamiento. En tanto sean considerados lenguajes, se pueden emplear para exteriorizar de manera gráfica las intuiciones o percepciones manifestadas en el procesamiento mental de las personas o como parte de las operaciones de distinción. En este caso, se constituyen en lenguajes de modelamiento, con el fin de conocer y construir realidades y, por tanto, herramientas a disposición de los observadores Trabajos Relacionados Existen múltiples implementaciones de aplicaciones que permiten crear diagramas a nivel de escritorio. En el caso de la Web existen también opciones que se diferencian en la tecnolo- 24

25 gía utilizada para su implementación, siendo las predominantes implementaciones realizadas con tecnología flex y java. En el caso de javascript existen al menos dos iniciativas notables: oryx editor [24] y www sql designer [42]. Oryx es un proyecto que nace desde el mundo de la academia y está orientado al modelamiento BPM. El caso de www sql designer es una iniciativa personal de Ondřej Žára y está orientado al modelamiento de estructuras de bases de datos relacionales. Se presenta en el cuadro 4.1 una comparativa del Editor RDF con las iniciativas mencionadas. oryx www sql designer editor RDF Requiere server si no no Implementa undo-redo si no si Importa desde modelo si no si GUI multilenguaje si si si Opciones de colaboración si no no Cuadro 3.1: Características de editores de diagramas Implementación Para la implementación del editor se deben considerar algunos requerimientos específicos, que tienen relación con las siguientes funcionalidades: 1. Permite crear dos tipos de triples, el primero donde todos los componentes son recursos y el segundo donde el objeto es un literal. 2. Los recursos pueden abreviarse por espacio de nombre 3. Los literales tienen lenguaje y tipo de datos. 4. Se presenta la opción de exportar RDF serializado en XML y Notation3. 5. El editor debe funcionar en un browser contemporáneo estándar, sin requerir addons o plugins adicionales. 6. La GUI del editor se implementa en multilenguaje, al menos español e inglés. 7. Permite importar triples desde RDF serializado. 25

26 Figura 3.1: Componentes del editor RDF. Cumplidas las especificaciones antes descritas, es posible realizar la implementación del editor, como una aplicación javascript, la cual no tiene componentes por el lado del servidor. Los componentes implementados y sus relaciones se muestran en la figura 3.1. A continuación se presenta uno de los principales problemas durante la implementación de este desarrollo, además de una prueba de concepto de una posible solución. Problemática: parser RDF en javascript Para implementar la funcionalidad de "importar triples" en el Editor RDF, es necesario utilizar un parser de documentos RDF, ya que no existe esta opción en la API base del lenguaje javascript. La primera problemática asociada al parser es la inmensidad de serializaciones existentes para los modelos RDF, sólo para nombrar algunos: xml, xml-abbrev, n3, ntriple, json, trix, trig, turtle. Tomando sólo el caso de XML, que por ser el primero debiera estar más avanzado, se encuentra que existen al menos cuatro parser disponibles 1. En todos estos parser falla, al menos, el ejemplo presentado en la figura parser.js de Simple RDF parser (iniciativa personal de Jim Ley); rdfparser.js de Tabulator (iniciativa de mitw3c) ; rdf.js de OAT (Iniciativa de openlink) ; rdfxml.js de Hercules (Iniciativa de arielworks) 26

27 <rdf:rdf xmlns:bibo= xmlns:rdfs= xmlns:rdf= xmlns:dcterms= xmlns:dc= > <rdf:description rdf:about=" <bibo:authorlist rdf:parsetype="collection"> <rdf:description rdf:about=" <rdf:value>michael C. Rea</rdf:value> </rdf:description> </bibo:authorlist> <dcterms:title>arguing About Metaphysics</dcterms:title> <dcterms:publisher>routledge</dcterms:publisher> <dcterms:issued>july 1, 2008</dcterms:issued> <dcterms:extent>559</dcterms:extent> <bibo:edition>1 edition</bibo:edition> <dc:subject>metaphysics</dc:subject> </rdf:description> </rdf:rdf> Figura 3.2: Ejemplo RDF donde fallan los parsers javascript. El error se presenta en la sección de Collection y ninguno de los parser logra generar los triples asociados de forma correcta. Una primera opción, para sobrepasar esta dificultad, es implementar un parche que soporte el ejemplo anterior, sobre alguno de los parser RDF/XML en javascript. Además, se puede validar contra los casos de prueba de RDF. Todo lo anterior requiere un esfuerzo no menor, el que puede ser inútil si no se mantiene en el tiempo. Otra opción es implementar el parser por el lado del servidor, utilizando un parser maduro como Raptor [26], pero es una complicación ya que el Editor RDF es una aplicación javascript sin componente de servidor. Solución: SPO Investigando en la línea de Raptor, se encuentra el servicio llamado triplr que permite generar triples RDF desde URL, este servicio es obra de Dave Beckett el mismo autor de Raptor. La forma de utilizar el servicio es simple y consiste en llamar una dirección de la forma siguiente: de salida>/<url del documento RDF, con opcional> Las opciones para el formato de salida son: html, json, n-triple, xml, turtle. Para el ejemplo que tiene problemas con los parser javascript y con una salida en html la forma de invocar el servicio es: rdf. En este caso la colección es identificada de forma correcta. Para utilizar este servicio en el Editor RDF se puede invocar con la salida de tipo json, y gracias al uso de yahoo pipe se puede 27

28 utilizar como jsonp para sobrepasar la política del mismo origen 2. Una vez resuelto el problema del parser, aún queda el problema de la multiplicidad de serializaciones, la solución está en el mismo triplr que soporta los siguientes tipos de documentos RDF: atom, grddl, n3, ntriples, rdf, rdfa, rss, trig, turtle. Como una prueba de concepto, se presenta la implementación de SPO que es un mashup donde se realiza la llamada del pipe que invoca triplr, el nombre SPO es una referencia a los triples en RDF que son: sujeto, predicado y objeto. 2 Es una medida importante de seguridad para scripts en la parte cliente (casi siempre javascript). Esta política viene del navegador Web Netscape 2.0, y previene de que un documento o script cargado en un "origen" pueda cargarse o modificar propiedades del documento desde un "origen" diferente. Se trata de uno de los conceptos de seguridad más importantes de los navegadores modernos. 28

29 Capítulo 4 Editor Compartido de Vocabularios En esta sección, se presenta un segundo desarrollo que dice relación con un editor compartido de vocabularios. Al respecto, este editor permite modelar un vocabulario mediante una aplicación Web, además de facilitar la referencia y publicación de los diagramas asociados a los vocabularios. Esta sección se aborda el estudio de diferentes herramientas similares, sus principales características, objetivos y casos de uso Trabajos Relacionados Se presentan como trabajos relacionados cuatro proyectos de Aplicaciones Web con funciones de colaboración y edición de ontologías: Web protege [40], Neologism [21], Freebase [13] y Knoodl [17]. Los dos primeros son iniciativas de la academia: Web Protege es la evolución de Protege que es un editor de ontologías, que se ejecuta en el escritorio y es la implementación de referencia para el modelamiento de ontologías; Neologism es una aplicación basada en el administrador de contenidos Drupal [10] y el alcance es justamente el modelamiento y documentación compartido de vocabularios. Los dos últimos editores son iniciativas comerciales: Freebase permite modelar esquemas y crear instancias bajo una infraestructura y lenguajes propietarios; Knoodl por su parte permite generar ontologías OWL e instancias de datos. Para caracterizar las diferencias, se presenta el cuadro 4.1 con una comparativa del Editor de Vocabularios (Vocab Editor) con las iniciativas mencionadas. 29

30 Web Protege Neologism Freebase Knoodl Vocab Editor Edición gráfica no no no no si Estándar (RDF-SPARQL) si si no si si Historial no no no no si 4.2. Implementación Cuadro 4.1: Características de editores de vocabularios. Para la implementación del editor de vocabularios, es necesario tener en cuenta las siguientes funcionalidades: 1. Modelar elementos de un vocabulario, como son: clases, propiedades e individual. 2. Administrar espacios de nombre y asociarlas a los elementos. 3. Asociar propiedades a una clase, tanto para especificar dominio como rango. 4. Asociar un individual (instancia) a una clase para especificar tipo. 5. Permitir grabar el trabajo realizado en el servidor. 6. Mantener un historial de cambios. 7. Permitir múltiples usuarios y roles. 8. Permitir exportar en RDF el vocabulario. La implementación consideró componentes en Google App Engine 1 (GAE), codificado en python y utilizando el GAE datastore para almacenar los datos y GQL [14] como lenguaje de consulta. Además, cada funcionalidad se expone como JSON 2 para ser integrada a un cliente javascript vía AJAX 3, también se implementan estos métodos en html para ser usados como back-end. La figura 4.1 muestra los componentes implementados y sus relaciones. 1 App Engine es un servicio de alojamiento de páginas Web que presta Google de forma gratuita hasta determinadas cuotas, este servicio permite ejecutar aplicaciones sobre la infraestructura de Google. Actualmente las aplicaciones Google App Engine se implementan mediante los lenguajes de programación Python y Java. 2 JSON, acrónimo de "JavaScript Object Notation", es un formato ligero para el intercambio de datos. JSON es un subconjunto de la notación literal de objetos de JavaScript que no requiere el uso de XML. 3 AJAX, acrónimo de Asynchronous JavaScript And XML (JavaScript asíncrono y XML), es una técnica de desarrollo Web para crear aplicaciones interactivas o RIA (Rich Internet Applications). 30

31 Figura 4.1: Componentes del editor de vocabularios. Roles Un vocabulario puede tener los siguientes estados: publicado, cerrado (sólo si está publicado), archivado (nada se elimina, sólo se oculta). Dependiendo del autor de un vocabulario este puede ser: anónimo, con autor. Los vocabularios anónimos pueden: ser visualizados por cualquiera, editados por cualquiera, archivados por autores conocidos. Al publicar un vocabulario: no se puede despublicar, cualquiera (menos un anónimo) puede "adueñarse" (editar, archivar y quedar como autor) del esquema, a menos que se encuentre cerrado. Por cada modificación del vocabulario, se almacena la versión anterior como resguardo. Sólo un autor autenticado puede ver los vocabularios archivados (tanto personales como públicos). Topological sorting Las relaciones de jerarquía en RDFS y OWL forman un grafo dirigido y acíclico (directed acyclic graph, DAG), por lo tanto se requiere validar que no existan ciclos al momento de referenciar una sub clase. Para esta validación se implementa el algoritmo de ordenamiento topológico [35], presentado en la figura

32 L <- Lista vacía que contendrá los elementos ordenados S <- Conjunto de nodos que no tienen arcos de llegada mientras S no este vacío hacer remover un nodo n desde S insertar n en L para cada nodo m con un arco e desde n a m hacer remover arco e desde el grafo si m no tiene otros arcos de llegada entonces insertar m en S si el grafo tiene arcos entonces mensaje de error (grafo tiene al menos un ciclo) Figura 4.2: Ordenamiento topológico. La implementación en javascript de este algoritmo resultó simple y se expone un método con la siguiente firma: boolean cycledetector(newfrom, newto). Existen optimizaciones al algoritmo implementado, que permiten realizar el calcular en línea, sin necesidad de recorrer todo el grafo en cada consulta [56] Casos de Uso La principal utilidad que se le da a la herramienta es con fines pedagógicos, en el sentido que puede ser utilizada por usuarios que se inician en el modelamiento de esquemas RDF. Asimismo, la herramienta se puede utilizar por usuarios avanzados, quienes necesiten transmitir mediante un diagrama parte o la totalidad de un vocabulario. A continuación, se presentan dos casos de uso de la herramienta. VoCamp [41] es una serie de eventos informales, donde un grupo de personas dedican un tiempo a crear "vocabularios sencillos" / "ontologías" para la "Web de datos" / "Web Semántica". El énfasis de los eventos no es crear la ontología perfecta en un dominio particular, sino en crear vocabularios que son suficientemente buenos para que la personas puedan comenzar a utilizarlos en la publicación de datos en la Web. La intención es seguir un formato de "primero en papel, segundo en laptop", donde los modelos son hechos inicialmente en papel y sólo al final son codificados. La idea de VoCamp esta influenciada por BarCamp, aunque el énfasis es diferente. Mientras que BarCamp se orienta a demos y presentaciones, VoCamps se orientan al trabajo técnico de hands on y resultados prácticos; cualquier presentación y demo debe ser corto, relacionado al proceso de desarrollo de vocabularios, y limitado en numero de presentaciones, para dejar el tiempo suficiente en el desarrollo de nuevos vocabularios. 32

33 Directorio de vocabularios para probar la herramienta se generó un pequeño directorio con vocabularios de uso general, incorporando 21 Esquemas Complejos (entiéndase con jerarquía de clases) BIO, COMMON TAG, CREATIVE COMMONS, DOAC, DOAP, EVENT, FOAF, GEO, IMAGE, LIFECYCLE, OWL, PIM CONTACT, RDF, RDFS, SCOVO, SIOC, SKOS, TIME, VCARD, VOID y WF. Además, se incorporaron 10 Esquemas Planos (sin clases, sólo propiedades) RELATIONSHIP, RSS 1.0, SYNDICATION, TRACKBACK, VANN, VOCAB STATUS, METAVOCAB, OPEN GUID, LABEL, DUBLIN CORE. A modo de ejemplo, en la figura 4.3, se ilustra la representación de un vocabulario utilizando la herramienta. Figura 4.3: Vocabulario Time. 33

34 Capítulo 5 Vocabulario Visual Como tercer desarrollo se presenta una propuesta de vocabulario visual para la descripción de vocabularios. A diferencia de los anteriores, este desarrollo no es de programación de un sistema. Se identifica la necesidad de generar este vocabulario visual debido a la falta de un estándar para los diagramas de vocabularios, en general se tiende a utilizar dos tipos de diagramas: óvalos, flechas etiquetadas y cajas para documentos RDFS; diagrama de clases, al estilo uml, para esquemas RDF y ontologías OWL Trabajos Relacionados La elaboración del vocabulario se basa en "Un vocabulario visual para describir arquitectura de información y diseño de interacción" [37], donde se describen algunos requerimientos claves que debe tener un vocabulario visual. Compatible con pizarra blanca: El vocabulario debería ser tan simple que los diagramas puedan ser dibujados rápidamente a mano. Los elementos del vocabulario debieran ser suficientemente distintos entre sí, para que un dibujo medianamente malo, no comprometa la claridad del diagrama. Independiente de herramienta: El vocabulario debiera estar diseñado de forma que no requiera de software especializado para construir diagramas. El vocabulario no debiera favorecer el uso de una herramienta particular de software, sino permitir a los arquitectos utilizar las herramientas más cómodas a ellos. 34

35 Pequeño y auto-contenido: Porque estos diagramas son usados por una amplia gama de audiencias con diferentes niveles de conocimiento (o incluso interés) en sistemas de diagramas usados en otras áreas de desarrollo técnico, el vocabulario no debiera requerir tal conocimiento o interés. El total de los elementos debe ser mantenido al mínimo posible, manteniendo una estricta relación uno-a-uno entre conceptos y símbolos, para que el vocabulario pueda ser aprendido y aplicado en forma rápida. Los conceptos expresados por el diagrama pueden ser arbitrariamente complejos; el medio de su expresión no debe serlo Propuesta La solución de vocabulario visual desarrollada, cumple con el requerimiento de integrar en un mismo diagrama vocabularios en RDFS + OWL con anotaciones RDF, como se puede apreciar en la figura 5.1. Figura 5.1: Elementos del vocabulario visual. 35

36 Con los elementos del vocabulario visual es posible realizar multiples conexiones, en la figura 5.2 se presentan algunas combinaciones posibles de relaciones. Figura 5.2: Conexiones de elementos en el vocabulario visual. 36

37 5.3. Ejemplos A continuación, se presentan algunos ejemplos relacionados con el uso de este vocabulario visual. En la figura 5.3 se presenta un ejemplo con triples (sujeto, predicado, objeto), arriba: el objeto es un literal, abajo: el objeto es un recurso. Figura 5.3: Ejemplo: triples. En la figura 5.4 se presenta una propiedad con anotación. La propiedad es title del vocabulario dublin core, al cual se le asigna un comentario en el vocabulario RDFS. Figura 5.4: Ejemplo: propiedad con anotación. En la figura 5.5 se presenta un ejemplo de la sección de un vocabulario, donde se encuentan anotaciones e instancias. El vocabulario descibe las clases Persona con dos sub clases Pesona- Juridica y PersonaNatural, se presentan dos anotaciones para la clase: primero una etiqueta en plural y luego un comentario en el vocabulario RDFS. Además se presentá una instancia de una persona natural y la propiedad de edad que tiene esta persona. 37

38 Figura 5.5: Ejemplo: anotaciones e instancias. 38

39 Parte III Casos de Estudio 39

40 Para la selección de los casos de estudio, se realizó una evaluación de distintas opciones que complementan el dominio de interés educativo. En el cuadro 5.1 se presentan las distintas opciones evaluadas. Dominio Volumen de datos Utilidad Impacto Escuelas medio alto alto Órganos del Estado alto alto medio Deportes bajo medio alto Medios bajo bajo alto Cuadro 5.1: Evaluación de alternativas para casos de estudios. Las variables a considerar fueron volumen de datos, utilidad e impacto, luego, al realizar la evaluación de las opciones para ser utilizadas en como casos de estudio, se seleccionan los datos estatales y los datos de escuelas, por ser de mayor utilidad. En diciembre del 2007 en Sebastopol, California, un grupo de treinta "defensores de gobierno abierto" [23], se reunieron a desarrollar un conjunto de principios [1] para datos abiertos de gobierno, los cuales se detallan a continuación: 1. Completo: todos los datos 1 públicos 2 están disponibles. Los datos públicos no contemplan datos privados ni limitaciones de seguridad o privilegios. 2. Primario: los datos son recolectados en la fuente de origen, con el nivel de granularidad más alto posible, no en forma agregada ni modificada. 3. Oportuno: los datos están disponibles tan rápido como sea necesario para preservar el valor de los datos. 4. Accesible: los datos están disponibles para el rango más amplio de usuarios para el rango más amplio de propósitos. 5. Procesable por máquinas: los datos están estructurados razonablemente para permitir un procesamiento automático. 1 "datos" significa: La información almacenada electrónicamente o grabada. Ejemplos de esto incluyen documentos, bases de contratos, transcripciones de audiencias, y eventos grabados en audio o vídeo. Mientras los recursos de información no electrónicos, tales como artefactos físicos, no están sujetos a los principios de datos abiertos de gobierno, siempre es alentador que esos recursos estén disponibles por vía electrónica a la medida de lo posible. 2 "público" significa: Los principios de datos abiertos de gobierno no apuntan a que los datos deban ser públicos y abiertos. La privacidad, seguridad y otros asuntos pueden legalmente (y de derecho) prevenir que un conjuntos de datos se compartan públicamente. Más bien, estos principios especifican las condiciones de que los datos públicos deben cumplir para ser considerado "abierto". 40

41 6. No discriminatorio: los datos están disponibles a cualquiera, sin requerir un registro. 7. No propietario: los datos están disponibles en un formato sobre el cual ninguna entidad tiene un control exclusivo. 8. Libre de licencias: los datos no están sujetas a ningún derecho de autor, patente, marca registrada o regulaciones de acuerdo de secreto. Privacidad razonable, limitaciones de seguridad y privilegios están permitidos. El cumplimiento debe ser revisable 3. Figura 5.6: Tratamiento de datos abiertos. El modelo general para el tratamiento de datos abiertos se sintetiza de forma simple y clara en el sitio se presenta en la figura 5.6. El modelo contempla tres niveles: Obtener - Procesar - Visualizar. Es así como para obtener se incorporan tecnologías de crawler, scrapers, etc. Para procesar se utilizan herramientas de clustering, estadísticas, etc. Por último, para visualizar se tienen opciones de consulta gráfica, de navegación por facetas, etc. 3 "revisable" significa: Se debe designar una persona de contacto para responder a las personas que intenten usar los datos. Se debe designar Una persona de contacto para responder a las quejas sobre violaciones de los principios. Un tribunal administrativo o judicial debe tener la jurisdicción para examinar si los organismos han aplicado estos principios adecuadamente. 41

42 Capítulo 6 Escuelas Chilenas Una de las opciones seleccionadas como caso de estudio es la información de las escuelas, por su alto grado de impacto y utilidad. Este capítulo presenta el estudio desarrollado, que dice relación con llevar a la "Web de Datos" la información de las escuelas Chilenas, presente en InfoEscuela [15]. InfoEscuela es un sistema de información en línea, orientado a las familias, para conocer de manera directa las principales características de los establecimientos educacionales reconocidos por el Ministerio de Educación de Chile. Este portal reune y organiza la mayor cantidad de datos oficiales disponibles respecto de cada establecimiento subvencionado del país Fuente de Datos Tratando de implementar un screen scraper para InfoEscuela, se encuentra que la implementación del servicio hace muy difícil la automatización de consultas. Los problemas encontrados son: 1. El identificador de la Escuela seleccionada es almacenado como un estado de sesión en el servidor, lo típico es que ese id sea parte de un URL (al estilo app?id=18 o o se pase por un campo hidden de un formulario o bien se almacene en una variable cookie. 2. Los datos de una Escuela está distribuida en distintas páginas. 42

43 Por otra parte, y para ayudar a resolver los problemas anteriores, se puede utilizar la información disponible en otro sitio del Ministerio de Educación, se trata del Directorio de Establecimientos [9] donde esta disponible una fuente de datos de todos los establecimientos. Como un dato que se repite en los distintos sitios y fuentes de datos del Ministerio de Educación, encontramos el campo llamado RBD, que es un identificador único para cada establecimiento, este dato se puede utilizar para generar la URI de las Escuelas. Al ejecutar el crawler se obtienen 3.7GB de datos en páginas html (con más de 30 horas de ejecución). Luego, al ejecutar un proceso de scraping básico sobre cada página, se logra un total de 117M en datos formateados (el proceso toma 8 horas de ejecución). De un total de colegios, existen 287 que presentaron problemas al momento de consultar por alguna de las páginas con información. Los problemas se concentran en sólo dos páginas, la de datos sobre el SIMCE (58 casos) y la página de datos de profesores (229 casos). Por ejemplo, la Escuela con RBD 5421 presenta problemas en la página de datos del SIMCE y la Escuela con RBD 9813 presenta problemas con la página de datos de profesores. Es probable que estos problemas se deban a un error en el sistema InfoEscuela Diseño Esquema Para el esquema asociado a las escuelas, se propone utilizar owl:class / rdfs:subclassof, pero complementado con skos:concept / skos:broader, creando una taxonomía. La propuesta es tener una clase llamada Escuela y una taxonomía llamada TaxonomiaEscuela, el cual tiene cinco elementos principales, y cada uno es también una jerarquía de clases. El objetivo de usar clases es permitir propiedades con rdfs:range y el objetivo de utilizar SKOS [33], es enfatizar en que las relaciones de jerarquía dicen relación con clasificación más que con algún tipo de meronimia. KOS son los Sistemas de Organización del Conocimiento y son utilizado por los bibliotecarios. SKOS permite llevar a RDF+OWL, de manera Simple, cualquier tipo de vocabularios controlados: esquemas de clasificación, taxonomías, tesauros, etc. El vocabulario de SKOS, al igual que el de OWL tiene muchas clases y propiedades, sin embargo, para describir una taxonomía, sólo se necesita un subconjunto del vocabulario, y se puede crear siguiendo el siguiente patrón: 43

44 1. Escoger un nombre para el esquema (N) 2. Indicar que el esquema es de tipo conceptos (N rdf:type skos:conceptscheme) 3. Crear al menos un concepto principal, se puede tener más de uno (A skos:topconceptof N) 4. Jerarquizar los conceptos como específico (A skos:narrower B) o general (B skos:broader A) 5. Indicar el esquema al que pertenece cada concepto (A skos:inscheme N) Además, para el esquema de Escuela se utilizan algunos elementos de OWL: 1. Especificar distintos tipos de propiedades, diferenciando entre owl:datatype Property (que tienen como rango un literal tipado) y owl:objectproperty (que tienen como rango una instancia de una clase). 2. Detallar la cardinalidad que tiene cada propiedad (utilizando owl:cardinality, owl:maxcardinality y owl:mincardinality). Como caso general, se propone el "vocabulario mínimo" para crear esquemas, compuesto de las clases en el cuadro 6.1 y de las propiedades en el cuadro 6.2. OWL SKOS Clases owl:class owl:datatypeproperty owl:objectproperty skos:concept Cuadro 6.1: Clases de un vocabulario mínimo para crear esquemas. RDF RDFS OWL SKOS Propiedades rdf:type rdfs:domain rdfs:range rdfs:subclassof owl:cardinality owl:maxcardinality owl:mincardinality skos:topconceptof skos:broader skos:narrower skos:inscheme Cuadro 6.2: Propiedades de un vocabulario mínimo para crear esquemas. 44

45 Se propone incorporar este vocabulario mínimo, primero para ser agregados al vocabulario visual y luego para ser generados en el editor gráfico de esquemas, lo que permitiría proveer de un marco de trabajo para probar la metodología aquí planteada. Es así como el vocabulario de Escuelas queda de la forma presentada en la figura 6.1. Figura 6.1: Vocabulario Escuela. Además, se desarrolló el siguiente esquema de uso general, para la descripción de datos de contacto, representado en al figura 6.2. Figura 6.2: Vocabulario para describir datos de contacto. 45

46 Nomenclatura Para los nombres de clases y propiedades se sigue un esquema de camelcase, donde las palabra se separan por una letra mayúscula, además las propiedades comienzan con minúscula y clases con mayúscula. Tanto en la generación del esquema como en la selección de URL, existen problemas con los acentos o eñe, por lo que se decidió por normalizarlas y reemplazarlas por la letra sin tilde. Es importante que el URL sea accesible para poder rescatar información desde la fuente, esto se conoce como dereferenciable. En general, para vocabularios existen dos tipo de URL, los que terminan en # o los que terminan en /, la ventaja de utilizar el primero (un #) es que es una sección de un mismo documento, en cambio con un / se debe rescatar un documento separado. Sin embargo, para el manejo de release/versiones se identifica como una buena practica el uso de /, al menos para nombrar los elementos estáticos entre release como son los nombres de Clases o Propiedades. URL Existen dos tipo de URL que se deben diseñar, la primera tiene relación con el espacio donde se almacenarán los vocabularios y como se nombrarán las clases y propiedades. La segunda tiene relación con el espacio de nombres con los que se identifican las instancias. Diseño de URL para los vocabularios: modulo/ sección# ClassOrPropertyId \ / \--2--/ \---3--/ \ / Figura 6.3: URL para vocabularios. En la figura 6.3 se presta un ejemplo de URL para vocabularios, donde 1 representa la base de URL para los vocabularios creados en el proyecto; 2 representa el módulo que se describirá, por ejemplo: educación, geografía, etc.; 3 representa la sección del módulo que se esta describiendo en el vocabulario, por ejemplo Escuela o universidad; 4 es un identificador para las clases/propiedades o individuos del vocabulario. 46

47 Diseño de URL para los recursos: modulo/ tipo# recurso \ / \--2--/ \-3-/ \--4--/ Figura 6.4: URL para recursos. En la figura 6.4 se presta un ejemplo de URL para recursos, donde 1 y 2 al igual que el URL anterior corresponden a la base y modulo a describir; en 3 se tiene el tipo del recurso a describir (una clase del vocabulario); en 4 se tiene un identificador para el recurso Publicación Para realizar la publicación, es necesario revisar algunos aspectos, en primer lugar, el cómo se publican los vocabularios generados y en segundo lugar, el cómo se almacenan estos esquemas y sus instancias. Almacenamiento Para almacenar en disco los datos de las escuelas, se divide el conjunto de información en la siguiente estructura: <PATH DE PUBLICACION>/ index.rdf : contiene un listado de las instancias publicadas <PATH DE PUBLICACION>/ escuela / <rbd> : contiene un archivo para cada Escuela donde se presenta el detalle de propiedades asociadas a la Escuela Este esquema de almacenamiento es similar al que se realiza al publicar datos en html, donde existe un DIRECTORYINDEX que luego enlaza a las entradas siguientes. 47

48 Envío a buscador Los datos generados para las escuelas fueron enviados a un buscador semántico. Aquí podemos hacer la analogía de lo que ocurría en los primeros años de la Web, donde un Webmaster enviaba a los buscadores-directorios 1 la dirección y categoría de sus páginas. El buscador dónde los datos se enviaron fue sindice [32], una iniciativa asociada a DERI [7], para ello se envió solamente el archivo que contiene el listado de instancias, ubicado en: <PATH DE PUBLICACION>/ index.rdf. Al publicar los datos en este buscador se puede consultar mediante la interfaz de sig.ma [31], que presenta opciones novedosas en la integración de recursos. 1 como por ejemplo YAHOO 48

49 Capítulo 7 Transparencia Chilena La segunda opción escogida como caso de estudio es la información sobre transparencia del gobierno. Este capítulo presenta el desarrollo de llevar a la "Web de Datos" la información de transparencia del Gobierno de Chile. La ley Nº [18], sobre acceso a la información pública, tiene como objetivo central la publicidad de los actos y resoluciones de los órganos del Estado. En tal sentido, se basa en los siguientes principios: La transparencia de la función pública El derecho de acceso a la información de los órganos de la Administración del Estado Los procedimientos para el ejercicio del derecho y para su amparo Las excepciones a la publicidad de la información. Dadas las implicancias de esta normativa, a través de un instructivo presidencial se exige a cada Organismo del Estado mantener un subsitio Web con los datos relativos a la transparencia activa, que es aquella información que debe publicarse sin necesidad que sea solicitada explícitamente. Para cumplir con este objetivo se implementó una herramienta [36] de apoyo a la generación de los subsitios de manera semi-automática. 49

50 7.1. Fuente de Datos Para la aplicación en este caso de estudio se seleccionaron tres Ministerios, utilizando como criterio el número de empleados que tiene cada uno. Según el estudio Estadísticas de Recursos Humanos del Sector Público [11], los principales ministerios son: Educación, Justicia y Salud. Al crawlear y parsear los datos provenientes de los subsitios de transparencia de cada ministerio y sus organismos asociados, se encuentran algunos problemas: El Servicio Médico Legal (SML) tiene los enlaces a los documentos con javascript, por eso el crawler no pudo obtener los datos. De un total de 5466 páginas ( 141 educación, 277 justicia, 5048 salud ), en 47 (aproximadamente un 1 %) existió un fallo del parser por errores de sintaxis en el html. A esas páginas se les aplicó tidy [34] para arreglar los problemas, lo que no resultó para 7 de estos documentos (aproximadamente un 0.1 %). El ministerio de salud y sus organismos, presenta una copia de sus datos para distintos meses del año 2009 (al menos desde marzo). Existen cambios en los esquemas para el año En especial, afecta a las Transferencias, Compras y Dotación. Al aplicar el parser (proceso automático que tomó 3 horas) y particionar los datos (proceso manual que tomó 2 horas), se obtuvieron los datos presentados en el cuadro 7.1. Ítem Datos Auditoría 0,05 % Vínculo 0,12 % Subsidio 0,28 % Participación 0,35 % Remuneración 0,38 % Trámite 1,07 % Compra 3,51 % Normativa 5,03 % Transferencia 10,59 % Dotación 78,62 % Cuadro 7.1: Porcentaje de instancias para cada clase. Como se puede observar el 80/20 de los datos corresponde a información de dotación. Analizando el número de dotación crawleadas, con respecto a las que se tiene en el estudio de 50

51 recursos humanos en el sector público, vemos que los datos corresponden al menos en el orden de magnitud, como se muestra en el cuadro 7.2. Estudio Crawler Educación Justicia Salud Cuadro 7.2: Información de dotación nominal y recolectada Diseño Para diseñar el esquema aplicable a los datos de transparencia, se tomó como base la herramienta de apoyo a la publicación de subsitios, a través de los siguientes pasos: 1. Identificar las clases y sus relaciones jerárquicas 2. Para cada clase se agregan las propiedades desde formularios y planillas 3. Generar clases de uso general como son Persona, Período y Dinero 4. Se identifican los tipos de datos xsd:boolean, xsd:time y rdf:resource 5. Enlazar a vocabularios existentes, como es el caso de la clase Regiones que existe en el vocabulario de contacto desarrollado en el caso de estudios de Escuelas. Con los pasos anteriores se obtiene el esquema representado en la figura

52 Figura 7.1: Esquema para los datos de transparencia Publicación RDF Para generar RDF desde los datos parseados de transparencia, se acotó a los datos de Dotación (el de los datos). Gran parte del esfuerzo fue destinado a clasificar los datos, particionando las tablas según los siguientes criterios: 1. Tipo de dotación (planta, contrata, honorario, otra) 2. Fecha (el año al que corresponden los datos) El principal problema encontrado fue la cantidad de esquemas que se publican para cada tipo de datos, entendiendo que los headers de las tablas representan el esquema. Para muestra, y 52

53 luego de normalizar las etiquetas, se encuentran 31 esquemas, como muestra se presentan los siguientes 4 esquemas: 1. dotacion estamento paterno materno nombres grado funcion region ini fin obs 2. estamento paterno materno nombres grado funcion region ini 3. n estamento paterno materno nombres grado 4. paterno materno nombres funcion calificacion grado region um honorario ini fin obs La buena noticia, es que justamente una de las características de RDF es la flexibilidad en sus esquemas, por lo que sin importar que existan entidades que difieran en cantidad o tipos de atributos, esto no es un problema. Existe toda una línea de investigación que propone automatizar la extracción semántica a partir de tablas html [45], con lo que se evitaría parte del trabajo aquí presentado. Luego, al tener normalizados los esquemas de cada archivo procesado, la generación de RDF es directa. Al aplicar sobre 50M de datos tabulados, se generaron 300M de datos en RDF serializados en XML. Cada "entrada de dotación" se modeló con el esquema representado en la figura 7.2. Figura 7.2: Esquema para describir dotación. 53