Resumen Actualmente, cada vez son ma´s los gobiernos que publican sus datos siguiendo la doctrina de Gobierno Abierto. Si bien existen varias propuestas de co´mo realizar dicha publicacio´n, ninguna de ellas es completa y, por lo tanto, no pueden ser fa´cilmente replicadas. En este trabajo se presenta una estrategia para el poblado y persistencia de datos basados en un modelo sema´ntico utilizando el lenguaje de mapeo D2RQ y el Triple Store Jena TDB.
Hoy en d´ıa, la publicaci´on de datos ha tomado importancia, siendo ´esta, junto con
la bu´squeda de informaci´on, los objetivos principales de Internet. Si se relacionan
los datos y adem´as se les agrega interpretaci´on, entonces se puede hablar no s´olo
de la publicaci´on de informaci´on sino tambi´en de conocimiento [
Por otro lado, ha surgido un nuevo modelo de gobierno llamado Gobierno
Abierto, el cual se basa en la premisa de que todos los datos que produce el
gobierno son pu´blicos [
En este u´ltimo sentido existen diferentes arquitecturas y metodolog´ıas
basadas en modelos sem´anticos compuestos por ontolog´ıas. Por ejemplo, en [
El objetivo de este trabajo es presentar una estrategia que permita la
persistencia y poblaci´on de grandes ontolog´ıas para dar soporte a aplicaciones de
Datos Abiertos siguiendo los principios de Datos Enlazados. Dicha estrategia se
defini´o luego de realizar varias iteraciones, siguiendo los lineamientos del m´etodo
Investigaci´on en Acci´on [
Pasos para Poblar y Persistir un Modelo Sem´antico En esta secci´on se presentan los pasos de una estrategia para la poblaci´on y persistencia de un modelo sem´antico que ser´a utilizado para la publicaci´on de datos de gobierno. El objetivo de dicha estrategia es generar las tripletas necesarias para poblar las ontolog´ıas del modelo sem´antico a partir de los datos almacenados en una base de datos (BD), cumpliendo con los requerimientos especificados en el Documento de Especificaci´on de Requerimientos del Modelo Sem´antico (DERMS) que se desea poblar y las correspondencias entre los datos en las tablas de las BD y los elementos del modelo. Dichas correspondencias se encuentran especificadas en el Documento de Correspondencias entre la BD y las Ontolog´ıas (DCBDO) que se debe recibir como entrada.
Se considera como caso de estudio, para presentar la estrategia, la poblaci´on
y persistencia del modelo sem´antico del personal del Gobierno de la Provincia
de Santa Fe [
Figura 1. Diagrama entidad-relacio´n simplificado para poblar la ontolog´ıa Lugares 2.1.
Los objetivos de este paso son: (1) preparar las BDs origen para la extracci´on de los datos para generar las tripletas necesarias para poblar el modelo, y (2) analizar el modelo sem´antico para comprenderlo y definir las URLs a usar. Analizar las fuentes de informacio´n. La informaci´on primaria se encuentra en una BD ORACLE de gran porte. Para independizar esta fuente de la publicaci´on de datos, se hizo una r´eplica de la informaci´on a publicar en una BD de c´odigo abierto, MySQL, denominada “personto” (dicha BD cuenta con 47 tablas y un total de 7.439.605 registros) y se cre´o un archivo de texto plano conteniendo las sentencias SQL necesarias para la creaci´on de las tablas y posterior carga de los datos. Para disponer de una BD operativa fue necesario montar un servidor de BD en los equipos de desarrollo, y configurar y poner en marcha el servicio.
Dado que no todas las tablas de la BD se usaron para la generaci´on de tripletas, result´o de gran utilidad hacer diagramas de entidad-relaci´on simplificados para cada una de las ontolog´ıas del modelo en los que s´olo se desplegaron aquellas tablas que intervendr´ıan en su poblaci´on. Esta fragmentaci´on surgi´o de los requerimientos definidos en el DERMS. A manera de ejemplo, se muestra en la Figura 1 el diagrama de tablas de Lugares que luego se utilizar´a en los ejemplos.
tripletas fue necesario realizar las siguientes tareas sobre los datos de la BD: Tarea 1: Anonimizar datos. Con el fin de no hacer referencia a personas reales, se reemplazaron sus nombres y apellidos por datos ficticios para lo cual se cre´o una rutina en lenguaje Java y se la ejecut´o sobre la BD “personto”.
Tarea 2: Tratar valores especiales. Un aspecto importante a tener en cuenta es la existencia de valores nulos (NULL) en la BD. En algunos casos un valor nulo en un campo de una tabla significa ausencia o desconocimiento del dato. Por ejemplo, el campo que almacena el nu´mero de tel´efono de una persona.
En otros casos, al momento de elaborar el modelo sem´antico se le di´o un significado espec´ıfico a ese valor nulo. Por ejemplo, el modelo sem´antico estudiado define la propiedad funcionamiento para la clase OrganismoEnSARH, que se origina a partir del campo CLAUSURA de la tabla organismos. Los valores almacenados en este campo son los caracteres S y T, que se traducen a los valores En Funcionamiento y Cerrado Temporalmente de la propiedad para las instancias de la clase. El modelo sem´antico, adem´as de esta interpretaci´on de los datos, agrega un tercer posible valor Cerrado que deber´a utilizarse para los casos en que el valor del campo CLAUSURA sea NULL. Las herramientas adoptadas no dan soporte para este tipo de transformaci´on con valores nulos, por lo que fue necesario modificar una serie de registros en la BD para incluir un nuevo valor al campo CLAUSURA en aquellos registros donde era nulo.
una URL para cada ontolog´ıa del modelo. Para publicar datos en la Web,
los elementos de un dominio de inter´es primero deben ser identificados[
La URL http://www.frsf.utn.edu.ar/personto/ identifica globalmente al modelo sem´antico estudiado. Las dem´as URL definidas son las siguientes: - Agentes: http://www.frsf.utn.edu.ar/personto/ontoagentes# - Cargos: http://www.frsf.utn.edu.ar/personto/ontocargos# - Lugares: http://www.frsf.utn.edu.ar/personto/ontolugares# - Organismos http://www.frsf.utn.edu.ar/personto/ontoorganismos#
pectivas URLs. Cada clase definida en un modelo sem´antico da origen a una serie de recursos, sus instancias. Los recursos de una misma clase se agrupan en una colecci´on. Para identificar estos recursos es necesario adoptar un criterio respecto de los nombres a asignar a las colecciones y, adem´as, construir una cadena de texto que identifique de manera un´ıvoca a cada recurso.
Para la nominaci´on de colecciones se utiliz´o el plural del sustantivo que da nombre a la clase a la cual corresponden los recursos. As´ı, por ejemplo, las instancias de la clase Provincia se agruparon dentro de la colecci´on provincias.
Para generar los identificadores se usaron los valores correspondientes a las claves primarias de las tablas desde las cuales se extraen los datos, asegurando as´ı su unicidad. En los casos donde la clave primaria estaba compuesta por m´as de un campo, se concatenaron sus valores.
La estructura de la URI correspondiente a cualquier recurso del modelo es: <http://www.frsf.utn.edu.ar/personto/colecci´on/id recurso>
Algunos ejemplos de las correspondencias entre cada clase del modelo y la URI de la colecci´on en la cual se agrupan sus instancias son: - Pais: http://www.frsf.utn.edu.ar/personto/paises/ - Departamento: http://www.frsf.utn.edu.ar/personto/departamentos/ - Provincia: http://www.frsf.utn.edu.ar/personto/provincias/ 2.2.
Cada elemento de la ontolog´ıa tendr´a una correspondencia, directa o no, con elementos de las BDs. A partir de las BDs y en base a las definiciones establecidas en las ontolog´ıas, primero se deben establecer las correspondencias que permitan generar las tripletas necesarias para representar las definiciones de clases, instancias y sus propiedades, y las relaciones entre las instancias de esas clases.
actividad consiste en identificar qu´e grupos de tripletas se deben generar segu´n los elementos que componen la ontolog´ıa dada. Para cada ontolog´ıa, se necesitan tripletas para la declaraci´on e instanciaci´on de cada una de sus elementos.
objeto de las tripletas de cada grupo. Partiendo de los grupos establecidos en la actividad anterior se procedi´o a especificar de qu´e manera deb´ıan estar compuestas las tripletas para cada grupo.
Declaraci´on de clases. Para la declaraci´on de clases se debe generar una tripleta que identifique a la clase como tal y dos tripletas opcionales para agregar comentarios y etiquetas, siguiendo los patrones que se muestran a continuaci´on: <URI CLASE> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/2000/01/rdf-schema#Class>. <URI CLASE> <http://www.w3.org/2000/01/rdf-schema#label>“ETIQUETA” . <URI PROPIEDAD> <http://www.w3.org/2000/01/rdf-schema#comment>“COMENTARIO” .
Cuando existe herencia de clases, para cada una de las subclases se debe incluir una tripleta extra indicando la relaci´on, como se muestra a continuacin: <URI SUBCLASE> <http://www.w3.org/2000/01/rdf-schema#subClassOf> <URI SUPERCLASE>.
Instanciaci´on de clases Por cada instancia de clase se debe generar una tripleta segu´n el siguiente patr´on: <URI INSTANCIA> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <URI CLASE>. Declaraci´on de propiedades de instancias. Las propiedades se declaran con una tripleta que identifique la propiedad como tal y, opcionalmente, dos o m´as para agregar comentarios y etiquetas, con los patrones que se muestran a continuaci´on. <URI PROPIEDAD><http://www.w3.org/1999/02/22-rdf-syntaxns#type><http://www.w3.org/1999/02/22-rdf-syntax-ns#Property>. <URI PROPIEDAD><http://www.w3.org/2000/01/rdf-schema#label>“ETIQUETA” . <URI PROPIEDAD><http://www.w3.org/2000/01/rdf-schema#comment>“COMENTARIO” .
En los casos en que el dominio de la propiedad est´a integrado por m´as de una clase, se genera una u´nica tripleta para identificar a la propiedad, las tripletas de etiqueta y comentario para cada clase incluida en el dominio. Instanciaci´on de propiedades de instancias. Se debe generar una tripleta por cada propiedad de cada instancia de cada clase siguiendo el siguiente patr´on: <URI INSTANCIA><URI PROPIEDAD>“VALOR PROPIEDAD” .
Declaraci´on de relaciones entre instancias. Se debe generar una tripleta que identifique cada relaci´on como tal y, opcionalmente, dos o m´as para agregar comentarios y etiquetas. Los patrones para estas tripletas son: <URI RELACION><http://www.w3.org/1999/02/22-rdf-syntaxns#type><http://www.w3.org/1999/02/22-rdf-syntax-ns#Property>. <URI RELACION><http://www.w3.org/2000/01/rdf-schema#label>“ETIQUETA” . <URI RELACION><http://www.w3.org/2000/01/rdf-schema#comment>“COMENTARIO” . Instanciaci´on de relaciones entre instancias. Se debe generar una tripleta por cada par de instancias relacionadas segu´n el siguiente patr´on:
<URI INSTANCIA SUJETO><URI RELACION><URI INSTANCIA OBJETO>. Calcular la cantidad de tripletas a generar para cada grupo en base a consultas SQL a las BD de origen. Se debe obtener, para cada grupo de tripletas y teniendo en cuenta los patrones necesarios para cada grupo, la cantidad exacta de tripletas que se deben generar para la declaraci´on de todas las clases y propiedades del modelo sem´antico y la extracci´on de todas las instancias almacenadas en las BDs. Para estos c´alculos se debe tener en cuenta lo siguiente: - cada subclase en una relaci´on de herencia requiere una tripleta adicional; - la instanciaci´on de una propiedad de una clase depende de la cantidad de valores no nulos en el campo origen de dicha propiedad; - las propiedades con n clases en su dominio (n ≥ 2) requieren 3 + 2 × (n − 1) tripletas
generar los lotes correspondientes de forma automatizada. Mediante el
uso de un lenguaje espec´ıfico, D2RQ Mapping Language, se pueden escribir
bloques de c´odigo que establecen la asociaci´on entre los campos de las tablas en las
BDs y los elementos definidos en las ontolog´ıas, como clases y propiedades [
Declaraci´on de prefijos. Los archivos de mapeo comienzan con la declaraci´on de los prefijos necesarios, incluyendo uno para la URI base del modelo, uno para cada URI de las diferentes ontolog´ıas que lo forman y uno para cada colecci´on de instancias. Tambi´en, se deben incluir una serie de prefijos de espacios de nombres de uso comu´n, como el de D2RQ y OWL. No es necesario incluir todos los prefijos espec´ıficos del modelo, sino s´olo aquellos que se utilizan localmente. Conexi´on a BDs. Se deben establecer las conexiones a las BDs con las que se va a trabajar para la extracci´on de tripletas. Para ello, un objeto d2rq:Database define una conexi´on JDBC a una BD relacional local o remota. Un archivo de mapeo D2RQ puede contener m´as de un objeto d2rq:Database, permitiendo el acceso a mu´ltiples BDs diferentes. Una vez declarado este objeto, cualquier acceso a la BD se realizar´a haciendo referencia al mismo.
Mapeo de clases y sus instancias. D2RQ abarca las definiciones de clases y sus instancias con un solo bloque de c´odigo, a trav´es de un objeto d2rq:ClassMap. Por ejemplo, el bloque de c´odigo siguiente realiza el mapeo entre la tabla paises y la clase Pais de la ontolog´ıa Lugares, mediante la definici´on del mapeo map:Paises. map:Paises a d2rq:ClassMap; d2rq:dataStorage map:persontoDB; d2rq:uriPattern “paises/@@paises.COD PAIS—encode@@”; d2rq:class ontolugares:Pais; d2rq:classDefinitionLabel “Pais”; d2rq:classDefinitionComment “Representa el pa´ıs de nacimiento de un Agente.”; .
Este mapeo da origen a las tripletas de definici´on de la clase Pais, una etiqueta (d2rq:classDefinitionLabel ) y comentario (d2rq:classDefinitionComment ) para la misma. La propiedad d2rq:dataStorage especifica que el objeto obtendr´a datos de la BD definida anteriormente por el objeto map:persontoDB.
Cada registro de la tabla dar´a origen a una instancia de la clase, que estar´a identificada y ser´a posible acceder a la misma por medio de la URI compuesta por el infijo paises/, correspondiente a la colecci´on, seguido del c´odigo del pa´ıs. Esto se logra haciendo uso de la propiedad d2rq:uriPattern. En tiempo de ejecuci´on, a toda URI generada a partir de un mapeo D2RQ se le an˜ade un prefijo global correspondiente a la URL base que identifica al modelo. Mapeo de propiedades y sus instancias. El objeto D2RQ, que hace posible el mapeo de Data Properties y Object Properties es d2rq:PropertyBridge.
Una Data Property puede generarse de varias formas. El valor de la misma puede obtenerse, por ejemplo, a partir de un valor simple de una columna de la misma tabla desde la cual se origin´o la instancia, una columna de otra tabla, un patr´on generado a partir de la concatenaci´on de varias columnas o una correspondencia entre valores enumerados. La definici´on de un d2rq:PropertyBridge est´a compuesta por la especificaci´on del d2rq:ClassMap, que da origen a las instancias a las cuales agrega propiedades mediante la propiedad d2rq:belongsToClassMap, la propiedad RDF que est´a generando, especificada por la propiedad d2rq:property, y el valor asignado.
Las Object Properties se extraen generalmente de alguna relaci´on entre tablas y se mapean generando un bloque de tipo d2rq: PropertyBridge con el agregado de una o m´as propiedades d2rq:join, que fijen la relaci´on de igualdad entre campos de tabla. Adem´as, teniendo en cuenta la definici´on de una object property como una tripleta sujeto-propiedad-objeto, la propiedad d2rq:belongsToClassMap indica el mapeo que da origen a las instancias sujeto, mientras que d2rq:refersTo ClassMap indica las instancias objeto. Los signos < y > se utilizan para indicar, mediante la punta de flecha, cu´al de los lados de la condici´on de igualdad corresponde a una clave primaria. Esto permite al motor D2RQ optimizar el mecanismo interno de resoluci´on de consultas SQL, reduciendo los tiempos de procesamiento requeridos para la transformaci´on de los datos.
En ciertos casos, el valor que de una propiedad puede estar incluido en una enumeraci´on de posibles valores, por lo cual el rango de la propiedad corresponde a un tipo de datos enumerado. Pueden existir, adem´as, casos en los que los valores almacenados en campos de tablas que dan origen a propiedades de instancias contengan valores que por disen˜o del modelo sem´antico deban ser traducidos o convertidos a otro formato al momento de la generaci´on de las tripletas. Para estos casos se emplean caracter´ısticas particulares del lenguaje D2RQ. Para cada ontolog´ıa, generar un volcado de tripletas serializadas en formato n-triples. Una vez redactado el archivo de mapeo para cada ontolog´ıa, se generan volcados de tripletas para cada mapeo. La herramienta dump-rdf de la plataforma D2RQ permite generar estos volcados de tripletas serializadas en formato n-triples. Se utiliza este formato por ser el m´as adecuado para persistir, en el proceso siguiente, los lotes generados en un T-Store, ya que su procesamiento requiere menores niveles de recursos de CPU y memoria.
Verificar si se generaron las cantidades de tripletas correctas. Las herramientas de l´ınea de comandos grep y wc5 permiten contar la cantidad de l´ıneas en un archivo que contengan un patr´on de texto especificado. Dado que bajo el formato de serializaci´on n-triples cada l´ınea del archivo de volcado corresponde a una tripleta, si se define correctamente el patr´on de texto a buscar mediante el uso de expresiones regulares, se puede saber con exactitud la cantidad de ocurrencias de un modelo de tripleta que responden a cada uno de los grupos particulares que existen en el volcado. 2.3.
El objetivo es generar un repositorio persistente en el que se encuentre almacenado el modelo sem´antico junto con las instancias generadas anteriormente, listo para ser consultado. Este proceso consta de las tres actividades siguientes. Crear un Triple Store. Para crear la Triple Store se seleccion´o la combinaci´on de las herramientas D2RQ y el Framework Jena. Para la selecci´on de dichas herramientas se busc´o alcanzar el mayor grado de interoperabilidad entre ellas, teni´endose en cuenta, adema´s, la disponibilidad de documentacio´n y madurez de los proyectos de desarrollo correspondientes. De los dos repositorios ofrecidos por Jena, SDB y TDB6, se eligio´ el segundo, debido a que SDB ya no se encuentra en desarrollo activo, y adem´as presenta mayor eficiencia y escalabilidad.
gesti´on del repositorio y el acceso al mismo pueden realizarse programa´ticamente mediante una serie de m´etodos ofrecidos por la API del framework Jena, o mediante el uso de herramientas de l´ınea de comando provistas por la plataforma. Para la carga masiva de datos, la segunda alternativa resulta m´as eficiente.
La herramienta de l´ınea de comandos tdbloader permite la carga masiva de archivos RDF al almac´en Jena TDB, y genera con cada carga los ´ındices necesarios para optimizar el acceso a los datos. Se deben tener en cuenta dos restricciones de esta herramienta. En primer lugar, las ontolog´ıas a cargar deben encontrarse serializadas en formato RDF/XML. La segunda restricci´on es que tdbloader no es transaccional, lo que implica el bloqueo del repositorio durante las operaciones de carga, deneg´andose el acceso simult´aneo desde otro proceso.
de carga se lleva a cabo con la herramienta tdbloader, la cual primero realiza la carga de tripletas al almac´en para luego pasar a la fase de indexado. 2.4.
Para cada una de las preguntas de competencia planteadas en el DERO para el
modelo sem´antico estudiado[
Finalmente, sobre el repositorio Jena TDB se ejecut´o cada una de las consultas SPARQL. Esta tarea se puede llevar a cabo ejecutando la herramienta de l´ınea de comandos tdb-query de la plataforma Jena TDB. Otra forma de resolver consultas SPARQL es utilizando el motor de ejecuci´on de consultas ARQ mediante la API provista por el framework Jena. Este m´etodo brinda mayor flexibilidad, a costas de un mayor consumo de recursos y tiempos de respuesta.
Lecciones Aprendidas y Trabajos Futuros
En este trabajo se present´o una estrategia para persistir y poblar grandes
ontolog´ıas para dar soporte a aplicaciones de Datos Abiertos siguiendo los principios
6 https://jena.apache.org/documentation/tdb/
de Datos Enlazados. La misma se prob´o en dos tesis de maestr´ıa que requer´ıan
la poblaci´on de ontolog´ıas con datos almacenados en sistemas de gobierno. De
estas pruebas se pudo concluir que la estrategia es u´til cuando la BD origen
est´a compuesta por varias tablas y los mapeos entre los elementos de la BD y
los del modelo sem´antico no son directos. Cuando hay pocas tablas, con
muchos registros, y la herramienta de ontology learning permite crear de forma
directa el modelo sem´antico y sus instancias, puede resultar m´as adecuada una
herramienta como RDB2Onto [
La estrategia definida requiere contar con desarrolladores con conocimientos en tecnolog´ıas sem´anticas y definir un gran nu´mero de tripletas (en el caso presentado se definieron m´as de 50.000.000 de tripletas). Por ello, se desarroll´o un prototipo de aplicaci´on que gu´ıa en la implementaci´on de la estrategia definida, el cual est´an fuera del alcance de este trabajo.
La estrategia propuesta est´a basada en D2RQ y el T-Store Jena TDB, sin embargo podr´ıa extenderse a otros lenguajes y T-stores.
Otro tema para trabajo futuro es la actualizaci´on de datos. En los casos estudiados los mismos se modifican una vez al mes siendo necesario realizar los pasos definidos para actualizarlos. En otros casos, el tema de la actualizaci´on debe reveerse.