GoodRelations

GoodRelations es una alternativa al modelo centralizado de agregación de datos para e-commerce, utilizando RDFa y un esquema OWL. Un ejemplo de la opción centralizada es google base, que expone su propio esquema y diferentes formatos para publicar los datos.

Mi primera impresión al ver el esquema de goodrelations fue que era muy grande (27 clases, 62 propiedades, 43 individuales). Con el pasar de los meses, el esquema aparece cada vez más, primero por los asistentes del meetup, luego un par de entradas en el sitio de rdfa: primero bestbuy luego oreilly.

Utilizando el RDFa Distiller sobre la página de oreilly se obtienen el siguiente diagrama, donde existe un amplio uso de nodos blancos.



Uno de los beneficios de publicar los datos usando goodrelations es que se pueden aprovechar herramientas como SearchMonkey de Yahoo!


Clases y Prototipos

No sólo le costaba comprender que
el símbolo genérico perro abarcara tantos individuos
dispares de diversos tamaños y diversa forma;
le molestaba que
el perro de las tres y catorce (visto de perfil)
tuviera el mismo nombre que
el perro de las tres y cuarto (visto de frente).

Funes el memorioso
Jorge Luis Borges - 1944

Al igual que en muchos lenguajes de programación orientados a objetos (OOP), los vocabularios y ontologías RDF se modelan basados en clases, donde se distingue entre clase e individual. Existe otra forma de modelar, basada en prototipos, donde no se hace tal distinción y sólo existen objetos.

Como se señala en la documentación de javascript, en OOP un lenguaje basado en prototipos tiene la noción de un objeto prototipo, un objeto utilizado como una plantilla de la cual se obtienen las propiedades iniciales de un nuevo objeto. Cualquier objeto puede especificar sus propias propiedades, ya sea cuando se crea o en tiempo de ejecución. Además, cualquier objeto puede ser asociado como el prototipo de otro objeto, permitiendo que el segundo objeto comparta las propiedades del primer objeto.

Las ventajas de usar clases en la descripción de ontología y vocabularios son muchas, entre ellas:
  • Definir cardinalidad, rango y dominio de propiedades.
  • Definir reglas lógicas, como son: transitividad, simetría y equivalencia de propiedades.
  • Definir operadores de conjuntos, como son: unión, intersección, complemento, disjunción de clases.
En la práctica, todo lo anterior se obtiene al utilizar RDFS y OWL.

También existen desventajas al momento de modelar usando clases, ya que como se describe en "Classes vs. Prototypes - Some Philosophical and Historical Observations (1996)" se tendrá:
  • 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 compartido 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 en diferenciar entre colores con mayor detalle.

Es debido a la última de las desventajas de usar clases (donde se deduce que ningún vocabulario es estático), que se tiene la necesidad de replantear la forma en que se diseñan los identificadores de los vocabularios. Se propone que todas las propiedades se identifiquen en un archivo separado, como es el caso de Dublin Core, donde por ejemplo, se tienen las siguientes propiedades:
  • http://purl.org/dc/elements/1.1/Title
  • http://purl.org/dc/elements/1.1/Creator
La idea de prototipos para las ontologías no es nada nuevo, Sowa define la existencia de dos tipos de ontologías, las axiomatizadas y las basadas en prototipos. Muchas veces la creación de ontologías basadas en prototipos son generadas mediante técnicas de Machine Learning y se asocian a la Identificación de Entidades.

Resulta paradojal que durante gran parte del desarrollo de la tesis, estuve preocupado de como modelar "basado en clases" las implementaciones en javascript (un lenguaje OOP basado en prototipos) sin preocuparme que justamente la forma de modelar basado en prototipos debía llevarse al desarrollo de vocabularios. RDF, en su esencia, permite la descripción de Recursos sin necesidad de contar con una jerarquía de clases, el mejor ejemplo es el mismo Dublin Core, donde sólo se tienen propiedades aplicables a cualquier Recurso. Lo único que le faltaría a RDF, para hacer la equivalencia con los lenguajes de programación basados en prototipos, es "la realización de la conducta" (behavior reuse, a.k.a. herencia), se propone el uso de prototype:behaviorReuse para especificar "herencia al estilo de los lenguajes OOP basados en prototipos", así por ejemplo se podría tener el siguiente triple, donde se dice que un ipod hereda las propiedades del RioPMP300.
equipment:ipod prototype:behaviorReuse equipment:RioPMP300 .
Igualmente se deben considerar los antecedentes respecto a "sobre-escribir" valores de las propiedades y su eventual efecto en los razonadores.

El descubrimiento de estos antecedentes, me permiten entender de mejor manera algunos issues enfrentados al momento de modelar vocabularios y sobre el uso de la tecnología asociada, entre ellos se destacan:
  • ¿Cuando se de debe usar una clase y cuando una instancia?
    existe otra opción, que es usando prototipos.

  • ¿Existen distintos tipos de relaciones semánticas para establecer jerarquías?
    la relación parte-todo (part-whole) es sólo un tipo de estas relaciones, pero no siempre aplica un tipo de relaciones.

  • ¿Por qué sparql no utiliza clases?
    no es necesario cuando no se modela con clases.

  • ¿Cuando "liberar" un vocabulario?
    Ahora, ya que nunca se tendrá una versión perfecta y debe iterarse sobre la misma para llegar a un consenso.

  • ¿Por qué el vocabulario/ontología no es importante en el movimiento linked data?
    La visión de linked data es una visión tabular de la información, lo importante son las propiedades no las clases. En cierta forma se trata cada esquema o planilla como un prototipo.

Preservación

Hace un par de meses que en mi cabeza ronda la idea de "la necesidad de una infraestructura centralizada para la preservación de los datos gubernamentales". Quizás porque el proyecto subyacente es una mezcla de mis dos especialidades: Infraestructura + Datos. Luego de lanzar la idea, sin mucho desarrollo, una respuesta fué que esta problemática es la misma que los libros, donde la solución es asegurar la preservación mediante la distribución en distintas bibliotecas. Nada más cierto, ese es el modelo que se debe seguir, veamos que es lo que dice el "otro DCC" al respecto.


El "Digital Curation Centre" (DCC en UK): "El objetivo del centro es proporcionar un enfoque nacional para la investigación y el desarrollo en cuestiones de preservación y promover conocimientos y buenas prácticas, tanto nacionales como internacionales, para la gestión de todos los resultados de la investigación en formato digital". Partes de las problemáticas que se deben tratar con la preservación digital están: Obsolescencia tecnológica, Conservación, Autenticidad y Confianza. El enfoque que tiene el DCC es sobre los datos generados para materias científicas y académica. Pensemos que los datos gubernamentales serán de interés para alguna de las ramas científicas, como por ejemplo para los estudios sociológicos.

El DCC propone un modelo para manejar el ciclo de vida de preservación, que en parte se refleja en la figura presentada arriba en esta entrada. Sobre una eventual propuesta de infraestructura centralizada para alojar los datos el DCC publicó un Estudio de Infraestructura Nacional de Datos, donde luego de revisar la realidad de distintos países, se destacan algunos antecedentes:

1.- No existen ni políticas ni infraestructura centralizada a nivel nacional
2.- Las políticas son institucionales y de organismos de financiación de investigación
3.- Las soluciones nacionales se plantean como distribuidas, entregando el ambiente requerido
4.- Los costos y la provisión de infraestructura son temas abiertos

Podemos concluir entonces, que más que una "infraestructura centralizada" lo más conveniente es implementar un modelo distribuido para asegurar la preservación de los datos, al estilo de The Dataverse Network Project, que se asemeja a "una red de bibliotecas" para datos académicos/científicos.

Es importante notar que el mundo de los datos generados desde las áreas académicas y científicas están concentrando la atención, como es el caso del libro recientemente publicado por Microsoft Research "The Fourth Paradigm: Data-Intensive Scientific Discovery". Esta área de interés, el dominio científico/académico, pudo ser uno de los evaluados para los casos de estudio desarrollados en la tesis y quizás quedaba fuera por "presentar demasiados datos y no tener la infraestructura para alojarlos".


En el mismo tema de preservación, pero ahora relacionado con "linkeddata" y datos de gobierno, es justamente en UK, donde siguiendo los pasos de EEUU, Australia y Nueva Zelanda están lanzando su plataforma para exponer datos en la Web, pero esta vez asesorados por TBL, uno de sus primeros documentos generados dice relación con el diseño de URI para el sector público, donde se destaca las siguientes recomendaciones novedosas:
  • "El conjunto de URI (URI set, ver figura arriba en esta entrada) que se promueven para la reutilización deben ser diseñados para durar al menos 10 años" (final de la página 3).

  • "Sobre el dominio de un Conjunto de URI que se promueven para la reutilización: ... se mantenga a perpetuidad; No contenga el nombre del departamento o agencia ... ya que puede ser reasignada" (punto 3 en la página 6).
El hecho de colocar como primer lineamiento el de Diseño de URI no es casualidad, claramente se está siguiendo el stack de la Web Semántica.


Caracterizando la implementación de Gobierno Transparente


La implementación para cumplir la "Ley N° 20.285 - sobre Acceso a la Información Pública", denominada "Gobierno Transparente", tiene un sabor a "linkeddata". La opción tradicional implicaba implementar un sistema centralizado, donde se cargan los datos y permite consultar. Recordemos que la forma de cumplir con la normativa de publicar los datos en la web, se implementó con un modelo distribuido pero asistido, pasando por el siguiente flujo para cada servicio:

- Bajar las planillas desde http://www.gobiernotransparente.cl/

- Llenar las planillas con los datos respectivos (*)

- Utilizar los asistentes disponibles para generar las páginas con los datos, url (**) e índices

- Subir la información a cada sitio web (***)


Las particularidades corresponden a los puntos con asteriscos, que presentan una similitud con el modelo de datos linkeados en la web (linkeddata):

(*) Lo que se está haciendo al llenar una planilla es "crear instancias de una clase", asi cada fila de la planilla es una "instancia de la clase que define la planilla" con las "propiedades detalladas en el encabezado de la hoja". En la práctica, la planilla es "el esquema".
(**) Algunas url están "linkeando" a otros sistemas, que luego pueden extenderse con más información, ver por ejemplo listado de urls de "chileclic", y listado de urls del "Registros Ley N° 19.862".

(***) Al publicar las páginas en cada sitio, se da libertad para "ajustar" el formato de las páginas y urls.

Al utilizar un modelo distribuido, se tienen problemáticas similares a las de "linkeddata":

- Se requiere tipos de datos estrictos (e.g. para fecha, valores)

- Existe una evolución de vocabulario (e.g. cambio de planilla para dotación entre años)

- Es necesario contar con taxonomias para realizar agregación automática (e.g. nombre de servicios/instituciones, tipo de pagina)

Existen pocas soluciones de este tipo y quitando el antecedente del formato en que se serializan los datos, se tiene una oportunidad, ya que "conceptualmente el problema es el mismo que si tuvieramos los datos con RDF", en particular están incluidos los problemas listados anteriormente. Bajo este análisis y convencido cada vez más que la fuente de datos del "Gobierno transparente" puede ser explotada ahora, he comenzado con una serie de tareas que permitan caracterizar mejor los sub-sitios que mantiene cada servicio. Estas tareas son:

1.- Construir un listado de instituciones con páginas de transparencia

2.- Implementar un "sistema asistido" para: clasificar las páginas y rescatar los esquemas

3.- Presentar opciones de consulta que permita caracterizar cada sub-sitio


Construir un listado de instituciones con páginas de transparencia

Anteriormente ya se tenía un listado de instituciones, ahora se presenta el listado actualizado, con mas antecedentes y con opciones de filtrado (ofrecidos por exhibit). El listado es mantenido en una hoja de google spreadsheets.

Ver listado.

La información del listado proviene del sitio chileclic y se puede complementar con la información existente en la Dirección de Presupuesto, del Ministerio de Hacienda.

Implementar un "sistema asistido" para: clasificar las páginas y rescatar los esquemas

Mediante un sistema de bookmarklet y gracias a que cada página de los sub-sitios mantienen un formato estandarizado, es posible rescatar la siguiente información: url, institución, clase, periodo, actualización y esquema. Los datos son presentados para que puedan ser editados (funciona como una ventana de delicious o un bookmarklet de diigo) y luego son enviado mediante un formulario a una hoja de google spreadsheets.

La parte novedosa de esta herramienta consiste en utilizar un algoritmo de similaridad de strings (levenshtein) para buscar y normalizar el nombre de la institución, para ello es mandatorio contar con la lista de instituciones (descrita en el punto anterior).

Copiar el bookmarklet ClasificadorTransparencia a la barra de marcadores.



Presentar opciones de consulta que permita caracterizar cada sub-sitio

Utilizando opciones de filtrado y facetas (ofrecidos por exhibit), es posible "recorrer" el listado de páginas y esquemas recolectados con la herramienta del "sistema asistido", permitiendo caracterizar el número de páginas por institución, categoría, año y tipo.

Consultar características de páginas para 20+ instituciones.

Los pasos siguientes son:

1.- agregar opciones avanzadas para detectar clase (tipo de página), la consecuente categoría y parsear mejor el periodo

2.- permitir actualizar la clasificación de una página y dar opciones de colaboración

3.- recolectar las instancias de cada página, para ello ya se tiene un prototipo para el bookmarklet de DatosTransparencia

4.- presentar opciones para caracterizar y consular las instancias


Día 3 y Día 4

El día miércoles pude dedicar poco tiempo al trabajo de tesis, principalmente revisando alguna solución para generar RDF y publicarlos.

El día jueves se dedicó a generar RDF desde los datos parseados de transparencia, el trabajo estuvo acotado a los datos de Dotación (el 80-20 de los datos). Gran parte del esfuerzo fue destinado a clasificar los datos, particionando las tablas según los siguientes criterios:
  • Tipo de dotación (planta, contrata, honorario, otra)
  • Fecha (el año al que corresponden los datos)
El principal problema encontrado fue la cantidad de esquemas distintos que se publican para cada tipo de datos, entendiendo que los headers de las tablas representan el esquema. Para muestra, y luego de normalizar las etiquetas, se encuentran los siguientes 31 esquemas:
  1. contrato|estamento|paterno|materno|nombres|grado|funcion|region|nombreregion|ingreso|ini|fin|obs|
  2. dotacion|estamento|paterno|materno|nombres|grado|funcion|region|ini|fin|obs|
  3. estamento|paterno|materno|nombres|grado|funcion|region|ini|
  4. estamento|paterno|materno|nombres|grado|funcion|region|ini|fin|obs|
  5. estamento|paterno|materno|nombres|grado|funcion|region|ini|fin|obs|estab|
  6. estamento|paterno|materno|nombres|grado|funcion|region|ini|fin|obs|ley afecto|
  7. estamento|paterno|materno|nombres|grado|funcion|region|renta|ini|fin|
  8. estamento|paterno|materno|nombres|grado horas|funcion|region|ini|fin|obs|
  9. estamento|paterno|materno|nombres|obs|grado|region|ini|fin|
  10. estamento|rut|dv|corr|paterno|materno|nombres|obs|grado|region|ini|fin|
  11. n|estamento|paterno|materno|nombres|grado|
  12. n|estamento|paterno|materno|nombres|grado|region|ini|fin|obs|
  13. n|estamento|paterno|materno|nombres|obs|funcion|calificacion|region|ini|fin|estab|
  14. n|estamento|paterno|materno|nombres|obs|grado|region|ini|fin|
  15. n|estamento|paterno|materno|nombres|obs|grado|region|ini|fin|estab|
  16. n|estamento|paterno|materno|nombres|obs|grado|region|ini|fin|n res.|
  17. n|n|estamento|paterno|materno|nombres|obs|grado|region|ini|fin|
  18. n|paterno|materno|nombres|funcion|calificacion|
  19. n|paterno|materno|nombres|funcion|calificacion|grado|region|um|honorario|ini|fin|obs|
  20. n|paterno|materno|nombres|funcion|calificacion|region|ini|fin|
  21. n|paterno|materno|nombres|funcion|calificacion|region||ini|fin|estab|obs|
  22. n|paterno|materno|nombres|obs|funcion|calificacion|region|ini|fin|
  23. n|paterno|materno|nombres|obs|grado|region|ini|fin|
  24. n|planta|estamento|corr|paterno|materno|nombres|grado|region|ini|fin|obs|
  25. n|planta|estamento|corr|paterno|materno|nombres|region|grado|ini|fin|estab|funcion|profesion|obs|
  26. n|planta|estamento|paterno|materno|nombres|region|grado|ini|fin|estab|funcion|profesion|obs|
  27. paterno|materno|nombres|funcion|calificacion|grado|region|um|honorario|ini|fin|obs|
  28. paterno|materno|nombres|funcion|calificacion|region|um|honorario|ini y fin|obs|
  29. paterno|materno|nombres|funcion|grado|region|um|remuneracion|ini|fin|obs|
  30. paterno|materno|nombres|obs|funcion|calificacion|region|ini|fin|
  31. paterno|materno|nombres|obs|funcion|profesion|region|ini|fin|
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.

Luego, al tener los esquemas de cada archivo procesado normalizado, la generación de RDF es directa, ver en el update del repositorio los cambios en el código con los script de generación.

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 siguiente esquema:


Una instancia de dotación, se describe de la siguiente forma con el vocabulario visual:
Lo que viene es dejar todos los datos en un triplestore y presentar por facetas.

Día 2

Ayer fue el segundo día full time en la universidad. El trabajo realizado estuvo centrado en parsear los datos de transparencia para los tres ministerios seleccionados, a recordar: educación, justicia y salud. Previamente se almacenó el resultado de crawlear los sitios de transparencia en cada ministerio.

Ver en el update del repositorio los cambios en el código. Entre los problemas encontrados durante el parser están:
  • El Servicio Médico Legal (SML) tiene los links con javascript, por eso el crawler no trajo datos.
  • De un total de 5466 páginas ( 141 educación, 277 justicia, 5048 salud ) en 47 (aprox. un 1%) existió un fallo del parser por errores de sintaxis en el html, a esas páginas se les aplicó tidy para arreglar los problemas, lo que no resultó para 7 de estos documentos.
  • El ministerio de salud, y sus organizaciones, 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 2009, 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 siguientes resultados de interés:

Item Data
Auditoría 0,05%
Vínculo 0,12%
Subsidio 0,28%
Participación 0,35%
Remuneración 0,38%
Tramite 1,07%
Compra 3,51%
Normativa 5,03%
Transferencia 10,59%
Dotación 78,62%

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 recursos humanos en el sector publico, vemos que los datos corresponden, al menos en el orden de magnitud.


estudio crawler
educación 12k 5k
justicia 19k 22k
salud 85k 80k

Queda por validar que ocurre con el ministerio de educación, donde solo se encontró la mitad de las personas, quizás falta incluir alguna organización dependiente. El detalle de organismos crawleados es el siguiente:

Ministerio Nombre Alias
Justicia Servicio de Registro Civil e Identificación srcei
Justicia Superintendencia de Quiebras squiebras
Justicia Servicio Medico Legal sml
Justicia Servicio Nacional de Menores sename
Justicia Gendarmería de Chile gendarmeria
Justicia Defensoría Penal Pública dpp
Salud Central de Abastecimiento cenabast
Salud Fondo Nacional de Salud fonasa
Salud Instituto de Salud Pública isp
Salud Servicios de Salud Arica SSARICA
Salud Servicios de Salud Iquique SSIQUIQUE
Salud Servicios de Salud Antofagasta SSANTOFAGASTA
Salud Servicios de Salud Atacama SSATACAMA
Salud Servicios de Salud Coquimbo SSCOQ
Salud Servicios de Salud Aconcagua SSACONCAGUA
Salud Servicios de Salud Viña del Mar Quillota SSVQ
Salud Servicios de Salud Valparaíso San Antonio SSVSA
Salud Servicios de Salud Metropolitano Norte SSMETRONORTE
Salud Servicios de Salud Metropolitano Central SSMC.
Salud Servicios de Salud Metropolitano Oriente S.S.M.O.
Salud Servicios de Salud Metropolitano Sur SSMETROSUR
Salud Servicios de Salud Metropolitano Sur Oriente SSMETROSURORIENTE
Salud Servicios de Salud Metropolitano Occidente SALUD OCCIDENTE
Salud Servicios de Salud Libertador B. O'Higgins SSOHIGGINS
Salud Servicios de Salud del Maule SSMAULE
Salud Servicios de Salud Ñuble SSNUBLE
Salud Servicios de Salud Concepción SSC
Salud Servicios de Salud Arauco SSARAUCO
Salud Servicios de Salud Talcahuano SSTALCAHUANO
Salud Servicios de Salud Bio Bio SSBIOBIO
Salud Servicios de Salud Araucanía Norte SSARAUCANIANORTE
Salud Servicios de Salud Araucanía Sur SASS
Salud Servicios de Salud Valdivia SSVALDIVIA
Salud Servicios de Salud Osorno SSOSORNO
Salud Servicios de Salud del Reloncaví SSDELRELONCAVI
Salud Servicios de Salud Chiloé SSCHILOE
Salud Servicios de Salud Aysén SSAYSEN
Salud Servicios de Salud Magallanes SSMagallanes
Salud Seremi de Salud Región de Arica y Parinacota SEREMI15
Salud Seremi de Salud Región de Tarapacá SEREMI1
Salud Seremi de Salud Región de Antofagasta SEREMI2
Salud Seremi de Salud Región de Atacama SEREMI3
Salud Seremi de Salud Región de Coquimbo SEREMI4
Salud Seremi de Salud Región de Valparaíso SEREMI5
Salud Seremi de Salud Región Metropolitana SEREMI13
Salud Seremi de Salud Región de O'Higgins SEREMI6
Salud Seremi de Salud Región del Maule SEREMI7
Salud Seremi de Salud Región del Bio Bio SEREMI8
Salud Seremi de Salud Región de la Araucanía SEREMI9
Salud Seremi de Salud Región de Los Ríos SEREMI14
Salud Seremi de Salud Región de Los Lagos SEREMI10
Salud Seremi de Salud Región de Aisén SEREMI11
Salud Seremi de Salud Región de Magallanes y Antártica Chilena SEREMI12
Salud Establecimiento Experimental Centro de Referencia de Salud de Maipú CRS MAIPU
Salud Establecimiento Experimental CRS Cordillera Oriente CRSCO
Salud Establecimiento Experimental Hospital Padre Hurtado HPADREHURTADO


Día 1

Ayer fue el primer día de trabajo full time en la universidad. Lo mejor de todo fue trabajar desconectado de la red, realmente fue provechoso. El avance estuvo por el lado del editor rdf, el que permitirá integra las figuras del Vocabulario Visual, con lo que se podrá anotar vocabularios owl con rdf. Ayer quedaron listos las figuras para cada componente, y además se puede agregar propiedades a una clase. Falta administrar el rango-dominio de una propiedad, crear los conectores de tipo herencia y el de individual.

Ver en el update del repositorio los cambios en el código. Para muestra un screenshot de como está quedando el editor.



Vocabulario visual para anotar vocabularios rdf

Se presenta una serie de figuras que permiten describir un vocabulario rdf y sus anotaciones.


La necesidad de este vocabulario visual es la falta de un estándar para los diagramas de vocabularios, en general se tienden a utilizar dos tipos de diagramas:
  1. ovalos, flechas etiquetadas y cajas para documentos rdf
  2. diagrama de clases, al estilo uml, para esquemas rdf y ontologías owl
La solución presentada cumple con el requerimiento de integrar en un mismo diagrama vocabularios en rdfs + owl con anotaciones rdf. Su elaboración se basa en "Un vocabulario visual para describir arquitectura de información y diseńo de interacción" , donde se decriben 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.

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.
A continuación se tienen algunos ejemplos con el uso de este vocabulario visual.

Ejemplo 1) triples (sujeto, predicado, objeto), arriba: el objeto es un literal, abajo: el objeto es un recurso.
Ejemplo 2) propiedad con anotación. La propiedad title de dublin core con un comentario rdfs.
Ejemplo 3) sección de un vocabulario con anotaciones e instancias.
Queda pendiente incluir las figuras que representen taxonomías en skos.


Historia de cambios
  • 20 de Octubre del 2009: se cambia la figura para un recurso, pasa de un avalo a un rectángulo con esquinas curvas.
  • 18 de Octubre del 2009: primera versión.

Diagramas

Un diagrama es una representación simbólica de información destinado esencialmente a ser visualizado por personas. En "No tengo palabras para decirlo ..." encontramos una descripción de los diagrama 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.

Así, como lenguaje de modelamiento permite y ayuda a:

- hablar de aquello 'a mi' y a otros, comunicando información;
- tratar de aquello, especificando, minimizando y/o abstrayendo algo;
- reflexionar sobre aquello, analizando, evaluando, contrastando y pensando sobre ese algo;
- indagar acerca de aquello, descubriendo, explorando y/o analizando las particularidades de las cosas; y/o,
- cambiar aquello, innovando, mejorando, rehaciendo, diseñando lo que se ve, no se ve o se desea alcanzar en aquello.

Mientras, como herramienta de trabajo, tiene usos diversos orientados a ayudar en:

- soportar y transmitir memes (*);
- comunicar información, como una presentación aislada (en una presentación pública o disertación) o como parte de un texto (dentro de un texto de estudio);
- solucionar problemas, como representaciones externas que apoyan a la memoria de trabajo y permiten expresar restricciones de manera relativamente eficiente; y,
- descubrir, generar y/o explorar soluciones alternativas a problemas, potenciando la creatividad.

(*) Un meme es un patrón de información, que se tiene en la memoria de un individuo, el cual es capaz de ser copiado a la memoria de otro individuo (Heylighen, 2000).

data(set|base|source|space)


"Al procesar los datos nace la información,
al hacer un uso correcto se tiene conocimiento
y su aplicación frecuente se convierte en sabiduría."


Data (datos) es una representación simbólica con números, palabras, imágenes, etc. Los datos se aceptan tal como están dados.

Ejemplo: nombre Ernesto, edad 31 años, etc.

Dataset (conjunto de datos) utilizado en el mundo estadístico para indicar una muestra, hoy también se refiere a los datos que están en una hoja de planillas de calculo.

Ejemplo: presión arterial/hora 118-82/18:00, 117-87/18:15, 127-84/18:30, 126-87/18:45, 123-89/19:00, 121-83/19:15, 126-92/19:30, 124-83/19:45, 125-89/20:00.

Database (base de datos) es una colección de registros conectados lógicamente, para un propósito específico. En general se refiere a los sistemas administradores de base de datos (DBMS), los que prestan servicios como: almacenar; indexar; consultar.

Ejemplo: base de datos que mantiene cuentas corrientes, venta de productos, etc.

Datasource (fuente de datos) se refiere a una colección de datos con un modelo y formato común, en particular un base de datos es una fuente de datos, pero estas no se limitan a los base de datos tradicionales, sino que incluyen también a los datos no estructurados como son los textuales o multimediales (imágenes, sonidos, vídeos), datos semi estructurados en modelos jerárquicos como son xml o ldap, y datos estructurados en modelos de grafo como son owl o rdf.

Ejemplo: una carpeta compartida con manuales, un web service para agregar nuevos clientes, documentos rdf que describen personas.

Dataspace (espacio de datos) es 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 mas participantes (por ejemplo: que un participante es una vista o replica de otro; especificar la equivalencia de esquema entre dos participantes). El concepto de dataspace es un trabajo en desarrollo, y al igual que en database, 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 de dataspace están algunos que provienen de los servicios de base de datos, como son: almacenar; indexar; consultar, también existen otros desafíos notables, como son: descubrir participantes, reutilizar la interacción humana y garantizar la corrección.

Ejemplo: administrador de información personal (PIM), administrador de datos científicos.

Pasando de una B a siete C

En la primera generación de la web el servicio fundamental era la Búsqueda de 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 donde encontramos que a la búsqueda se agregan mas opciones:

Colaborar los recursos, utilizando un 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.
Alias: wiki

Compartir los recursos, los cuales pueden ser enviados por e-mail 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 e-mail sino que también a redes sociales, micro contenidos o sistemas de mensajería instantánea.
Alias: share

Clasificar los recursos, mediante el uso de etiquetas (o "tags"), esta opción 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 de 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 multiples servicios que permiten esta opción y depende del tipo de recurso que se está clasificando, por nombrar algunos: delicious; citeulike; flickr. Cada vez más las herramientas de administradores de contenidos y blogs incorporan esta opción. 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.
Alias: tag, anotar, marcar, highlight

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, 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 incorporar esta funcionalidad desde un sistemas centralizado de comentarios, como es jskit o el reciente sidewiki de google.
Alias: comment

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 que cada vez más ofrecen sistemas de administradores de contenido y blogs centralizados. Sitios como digg presentan un modelo de calificación distribuida para ordenar los recursos.
Alias: favorite, bookmark, valorar, ranking, relevancia

Conservar los recursos, se debe a que no es suficiente enlazar un recursos (mediante una referencia link), sino que cada vez más es 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 como purl.org.
Alias: archivar

Cada opción de trabajo sobre los recursos, es un patrón utilizado en la web2.0. Hoy no existe una implementación de todas estas funcionalidades juntas, quizas lo que más se parece es el servicio diigo, que se define como una red de información social.

Hasta aquí llevamos seis de las siete opciones prometidas, la última hace referencia al de Componer (con los llamados "mashup"), 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, se encuentra en la frontera con la web3.0 ya que es una opción de los datos del recurso mediante el uso de diferentes API que rescatan y publican información estructurada en XML o JSON via AJAX.
Alias: Mashup

Datos abiertos de gobierno

Ocho principios de datos abiertos de gobierno

En diciembre del 2007 en Sebastopol, California, un grupo de treinta "defensores de gobierno abierto", entre los que destacan Tim O'Reilly (el mismo de los libros técnicos con portadas de animales), Adrian Holovaty (creador de django y everyblock, a todo esto, everyblock fue comprado por msnbc) y Aaron Swartz (un "viejo conocido"), se reunieron a desarrollar un conjunto de principios para datos abiertos de gobierno, los cuales se detallan a continuación:

  1. Completo: todos los datos públicos está disponible. Los datos público no contempla datos privados ni limitaciones de seguridad o privilegios.
  2. Primario: los datos son recolectados en la fuente de origen, con el nivel de granularidad mas 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 mas amplio de usuarios para el rango mas amplio de propósitos.
  5. Procesable por maquinas: los datos están estructurados razonablemente para permitir un procesamiento automático.
  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, patenté, marca registrada o regulaciones de acuerdo de secreto. Razonable privacidad, limitaciones de seguridad y privilegios están permitidos.

El cumplimiento debe ser revisable.

Definiciones
"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".

"data" 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 video. 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.

"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.

Modelo de datos abiertos

El modelo general para el tratamiento de datos abiertos se sintetiza de forma simple y clara en el sitio theinfo.org (iniciado por el mismo Aaron Swartz) y contempla tres niveles.

NivelObtenerProcesarVisualizar
Itemsscrapers
crawlers
phone calls
buyouts
conversions
queries
regressions
collaborative filtering
tables
graphs
maps
web sites


Acerca de este blog

El presente blog registra la bitácora de una Tesis de Grado de Magíster en Ciencias de la Computación y trata sobre una línea de investigación relativamente nueva, denominada Ciencias de la Web, que es la ciencia de sistemas de información distribuidos. Los primeros años de la Web estuvieron llenos de estudios asociados a las Ciencias de la Computación, entre ellos los de hipertextos, recuperación de la información, etc. Pero 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. (ver figura siguiente, fuente).



Como se describe en "A Framework for Web Science". que es el 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 como 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 alternativas y restricciones técnicas; análisis con síntesis."

Para delinear los protocolos e infraestructura de la Web, existe el consorcio de la Web, denominado W3C (World Wide Web Consortium). El consorcio es dirigida por el creador de la Web, Tim Berners Lee, quien durante finales de la primera década de existencia de la Web impulsó lo que se llamó la Web Semántica, y pasó la segunda década buscando lo que se denominó la "killer application", que ayude a impulsar y difundir los principios de la Web Semántica. Fue justamente uno de estos principios, que proviene de la rama de estudios de Metadatos y Base de Datos, los que hoy podemos considerar como la "aplicación matadora", se trata de publicar datos en la web, o lo que se denomina "Linked Data".

El trabajo expuesto en este blog se enmarca en el ámbito de la publicación de datos distribuidos en la Web. Se presentan avances en los siguientes ámbitos:
  • Marco teórico, metodología y marco de trabajo detrás de la idea planteadas en "linked data"
  • Desarrollo de un set de herramientas que facilitan el proceso de publicar datos en la Web
  • Casos de estudio sobre la datos abiertos del Estado Chileno.
En el siguiente esquema se muestra el detalle de herramientas, casos de estudio y línea de producción desarrollados.