Prototipo de editor

Se presenta el primer prototipo de la GUI para el editor de ontologías colaborativo. Las funcionalidades habilitadas permiten solo hacer un diagrama, además se tienen habilitadas las primeras seis ontologías solamente. El objetivo del editor es tener una herramienta que permita componer esquemas, reutilizando ontologías existentes. Como un ejemplo, se presenta el intento de reconstruir parte del esquema FOAF.



Como se puede ver en el ejemplo, o bien utilizando el prototipo, existen solo dos tipos de relaciones:
  • La primera es una relación dirigida (con flecha), que une dos clases, para representar la propiedad sub-clase.
  • La segunda relación permite unir una propiedad con una clase y es para indicar el rango de una propiedad.

El dominio de una propiedad esta dada por el contexto de orden sobre una clase, el cual se debe implementar con algún tipo de restricción visual (enmarcando clase con sus propiedades, por ejemplo). Además, se deben agregar restricciones de cardinalidad para las propiedades.

Una lista de características que debiera tener la versión 0.1 del editor es la siguiente:
  • Permitir selección de múltiples elementos con draging options, operaciones de move y delete
  • Eliminar clases y propiedades del diagrama
  • Mostrar y ocultar propiedades y sus relaciones de rango
  • Agrupar propiedades "dentro" de una clase
  • Ingresar cardinalidad en relación de propiedades
  • Exportar e Importar el diagrama
  • Activar puntos sin conexión solo ante un MouseOver

Modelando ontologías con subclases

Buscando antecedentes sobre recomendaciones de utilizar o no subclases para modelar ontologías, encontré una discusión en la lista de correos de protege-owl, donde básicamente se concluye que el modelar o no con subclases estará dado por los requerimientos de uso de la ontología, validando el modelar con instancias si esto cumple con "la aplicación" del modelo.

En la discusión anterior se hace referencia a un paper llamado "A Taxonomy of Part-Whole Relations", donde se detallan seis tipos de meronimias (que trata sobre las partes) y revisan otros tipos de relaciones semánticas, entre las que está la relación de clases. Además se presentan unos ejemplos de silogismos inválidos, que tienen relación con el uso de distintos sub-tipos de meronimias. En el paper se destaca la siguiente clasificación parcial de las relaciones semánticas:

Como conclusión, se puede presentar que el uso de clases esta mas ligado a la Lógica Descriptiva que al de Linked Data (a.k.a. metadatos). Modelar sin subclases sigue la misma línea de trabajo que presentan vocabularios controlados, tesauros, taxonomías, etc.

Esquemas, clases y propiedades

En el siguiente diagrama se presenta un levantamiento de algunos de los esquemas RDF utilizados con mayor frecuencia, se presentan clases y propiedades para cada esquema.

Reunión de trabajo

En la reunión de hoy, revisamos el avance según lo comprometido para la data de infoescuela, quedando pendiente:
  • Generar sitio que publica vista con XHTML+RDFa y RDF
  • Publicar RDF
Además discutimos sobre las distintas formas de modelar algunos vocabularios controlados, enfocándonos en el uso o no de sub-clases y la idea de solo establecer relación entre conceptos, en la línea de mapa conceptual o mindmap. Sobre esta idea debo escribir un pequeño ensayo.

Por ultimo me comprometí a presentar un prototipo de una herramienta colaborativa para la edición de ontologías (que llamaré COLONED) para la próxima reunión que está fijada para el jueves 30 a las 16:00.

Javascript

Para la manipulación de rdf con javascript existen algunas soluciones destacadas:
  • PAC : permite crear formularios rdf
  • RDFQUERY : un plugin de JQUERY, donde se destaca el demo MARK IT UP!
  • TABULATOR: un browser generico para data en rdf, ver paper
  • OAT: una serie de herramientas AJAX de OpenLinkSW (los mismos de virtuosos)
  • DOJO DATA: una implementación para acceder un rdfstore
  • JALAVA: un editor de diagramas

Esquema de Escuela

Tengo una nueva revisión del modelo de InfoEscuela, donde se agregan y corrigen algunos datos.


Desarrollé una primera versión del esquema para una escuela, que contiene los campos subrayados en el esquema anterior. El esquema tiene solo trece propiedades para describir una escuela y se utiliza un sub-esquema de división administrativa junto a algunos de los esquemas presentados en la entrada anterior de este blog. La mayoría de las propiedades seleccionadas son mapeables con el esquema en Freebase.

1.- División Administrativa


2.- Escuela



Esquemas para datos de escuelas

Basado en el nombre de dominio DataEstado.cl y utilizando una instancia local de neologism, desarrolle ocho esquemas besicos para el marcado de los datos de escuelas.

Área Geográfica



Estado Establecimiento


Grupo Socioeconómico


Nivel Enseñanza


Nivel Escolar


Rama Enseñanza


Ramos SIMCE

DataEstado

Buscando un nombre de dominio para la implementación de referencia, se me ocurrieron los siguientes: chiledata, chiledb, ldow, infoestado y dataestado.

DataEstado.cl es el nombre de dominio seleccionado para la implementación de referencia, ya que es lo suficientemente amplio para aceptar tanto información de carácter educacional, como de municipal, transparencia, etc.

Agregador temporal para data gubernamental

Resulta interesante de revisar el sitio EveryBlock, en el se presenta un agregador de información por ciudades, donde se destaca la clasificación temporal. Entre los datos que se presentan están: patentes de negocios, permisos de construcción, transferencias de propiedad, etc. Además, por cada "tipo de información" se presenta una descripción. Por ejemplo, en esta pagina se muestra la descripción de la información relativa a Patentes de negocios para la ciudad de Chicago, donde se indica claramente cual es la fuente de la información.

Al parecer (ver el faq de EveryBlock), la información que sustenta el sitio es rescatada utilizando scrapers, al estilo del que estamos construyendo para InfoEscuela.

Creo que este es un excelente modelo para agregar la información relativa a transparencia en el gobierno.

Carwler InfoEscuela

En el repositorio esta disponible una primera versión del crawler para infoescuela, se basa en la solución propuesta en una entrada anterior. Al ejecutar el crawler se obtienen 3.7GB de datos en páginas html (con mas de 30 horas de ejecución). Luego, al ejecutar un proceso de scraping besico, sobre cada página, se logra un total de 117M en datos formateados (el proceso toma 8 horas de ejecución). El siguiente es un ejemplo de la data formateada para la escuela con RBD 9061.



De un total de 12114 colegios, existen 287 que presentaron problemas al momento de consultar por alguna de las páginas con información. Los problemas se concentran en solo dos paginas, 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 pagina 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 bug en la generación de las páginas en el sistema InfoEscuela.