Método Práctico para la Población y Persistencia de un Modelo Semántico José A. Gilliard1 , Omar R. Perı́n1 , Mariela Rico1 , and Ma. Laura Caliusco1,2 1 Centro de Investigación y Desarrollo de Ingenierı́a en Sistemas de Información (CIDISI) - UTN - Fac. Regional Santa Fe, Lavaise 610 - S3004EWB - Santa Fe jgilliard@frsf.utn.edu.ar 2 Consejo Nacional de Investigaciones Cientı́ficas y Técnicas (CONICET) Resumen Actualmente, cada vez son más los gobiernos que publican sus datos siguiendo la doctrina de Gobierno Abierto. Si bien existen varias propuestas de cómo realizar dicha publicación, ninguna de ellas es completa y, por lo tanto, no pueden ser fácilmente replicadas. En este trabajo se presenta una estrategia para el poblado y persistencia de datos basados en un modelo semántico utilizando el lenguaje de mapeo D2RQ y el Triple Store Jena TDB. Keywords: modelo semántico, datos abiertos, D2RQ, Jena TDB 1. Introducción Hoy en dı́a, la publicación de datos ha tomado importancia, siendo ésta, junto con la búsqueda de información, los objetivos principales de Internet. Si se relacionan los datos y además se les agrega interpretación, entonces se puede hablar no sólo de la publicación de información sino también de conocimiento [9]. 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 go- bierno son públicos [1]. Un Gobierno Abierto es aquel que entabla una constante conversación con los ciudadanos con el fin de oı́r lo que ellos dicen y solicitan, que toma decisiones basadas en sus necesidades y preferencias, que facilita la colaboración de los ciudadanos y funcionarios en el desarrollo de los servicios que presta, y que comunica todo lo que hace de forma abierta y transparente [2]. Existen varias iniciativas de Gobierno Abierto que difieren en la estrategia seguida: mientras unas iniciativas, como la de Estados Unidos, se centraron en la publicación de la mayor cantidad de información en el menor plazo posible, volcando la información en crudo tal y como estaba disponible, otras, como el caso de Gran Bretaña y España, realizaron un tratamiento previo de los datos empleando tecnologı́as de la Web Semántica para modelar la información y es- tablecer relaciones explı́citas entre los distintos conjuntos de datos, siguiendo los principios de Datos Enlazados [5]: - Utilizar URIs (Uniform Resource Identifier ) como nombres únicos para los recursos. 3URFHHGLQJRI6$2$&RS\ULJKW‹KHOGE\WKHDXWKRU V  0pWRGR3UiFWLFRSDUDOD3REODFLyQ\3HUVLVWHQFLDGHXQ0RGHOR6HPiQWLFR - Incluir enlaces a otras URIs para localizar más Datos Enlazados. - Utilizar el protocolo HTTP (HyperText Transfer Protocol ) para nombrar y resolver la ubicación de los datos identificados mediante esas URIs. - Representar los datos en RDF3 y utilizar SPARQL4 , un lenguaje de consulta para RDF, como lenguaje de consulta de dichos datos. En este último sentido existen diferentes arquitecturas y metodologı́as ba- sadas en modelos semánticos compuestos por ontologı́as. Por ejemplo, en [8] se presenta un proceso para publicar datos enlazados de gobierno, pero cuando se quiere llevar a la práctica dicho proceso se carece de instrucciones detalladas sobre cómo hacerlo. El trabajo presentado en [7] se centra principalmente en el desarrollo de la ontologı́a en un contexto de datos enlazados y en la evaluación del producto obtenido según criterios de la Ingenierı́a Ontológica y los principios de Datos Enlazados, pero no se explicitan reglas claras para el poblado de esta ontologı́a. En [5] se presenta un framework de alto nivel para la publicación de datos basados en los principios de Datos Enlazados pero no se describe cómo aplicarlo. Estos inconvenientes hacen difı́cil replicar estas propuestas en otros casos, sobre todo cuando se deben manejar grandes volúmenes de datos pro- venientes de distintas fuentes de información y no existe una correspondencia directa entre los elementos de estas fuentes y los de las ontologı́as. El objetivo de este trabajo es presentar una estrategia que permita la per- sistencia y población de grandes ontologı́as para dar soporte a aplicaciones de Datos Abiertos siguiendo los principios de Datos Enlazados. Dicha estrategia se definió luego de realizar varias iteraciones, siguiendo los lineamientos del método Investigación en Acción [10]. 2. Pasos para Poblar y Persistir un Modelo Semántico En esta sección se presentan los pasos de una estrategia para la población y persistencia de un modelo semántico que será utilizado para la publicación de datos de gobierno. El objetivo de dicha estrategia es generar las tripletas ne- cesarias para poblar las ontologı́as del modelo semántico a partir de los datos almacenados en una base de datos (BD), cumpliendo con los requerimientos es- pecificados en el Documento de Especificación de Requerimientos del Modelo Semántico (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ón y persistencia del modelo semántico del personal del Gobierno de la Provincia de Santa Fe [6]. Se recibieron como entrada el DERMS, el DCBDO, el modelo semántico implementado en el lenguaje OWL y la BD de la cual se debı́an extraer los datos. El modelo semántico recibido como entrada está compuesto por cuatro ontologı́as modulares: Lugares, Cargos, Organismos y Agentes. 3 http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/ 4 http://www.w3.org/TR/2013/REC-sparql11-query-20130321/ 3URFHHGLQJRI6$2$&RS\ULJKW‹KHOGE\WKHDXWKRU V  0pWRGR3UiFWLFRSDUDOD3REODFLyQ\3HUVLVWHQFLDGHXQ0RGHOR6HPiQWLFR Figura 1. Diagrama entidad-relación simplificado para poblar la ontologı́a Lugares 2.1. Análisis de las Fuentes de Información Los objetivos de este paso son: (1) preparar las BDs origen para la extracción de los datos para generar las tripletas necesarias para poblar el modelo, y (2) analizar el modelo semántico para comprenderlo y definir las URLs a usar. Analizar las fuentes de información. La información primaria se encuentra en una BD ORACLE de gran porte. Para independizar esta fuente de la publi- cación de datos, se hizo una réplica de la información a publicar en una BD de código abierto, MySQL, denominada “personto” (dicha BD cuenta con 47 tablas y un total de 7.439.605 registros) y se creó un archivo de texto plano conteniendo las sentencias SQL necesarias para la creación 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ón de triple- tas, resultó de gran utilidad hacer diagramas de entidad-relación simplificados para cada una de las ontologı́as del modelo en los que sólo se desplegaron aque- llas tablas que intervendrı́an en su población. Esta fragmentación surgió 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á en los ejemplos. Preparar los datos para generar las tripletas. Para poder generar las 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ó una rutina en lenguaje Java y se la ejecutó 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 número de teléfono de una persona. 3URFHHGLQJRI6$2$&RS\ULJKW‹KHOGE\WKHDXWKRU V  0pWRGR3UiFWLFRSDUDOD3REODFLyQ\3HUVLVWHQFLDGHXQ0RGHOR6HPiQWLFR En otros casos, al momento de elaborar el modelo semántico se le dió un significado especı́fico a ese valor nulo. Por ejemplo, el modelo semántico 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ántico, además de esta interpretación de los datos, agrega un tercer posible valor Cerrado que deberá utilizarse para los casos en que el valor del campo CLAUSURA sea NULL. Las herramientas adoptadas no dan soporte para este tipo de transformación 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. Definir una URL base para el modelo semántico y, en base a ésta, una URL para cada ontologı́a del modelo. Para publicar datos en la Web, los elementos de un dominio de interés primero deben ser identificados[5]. Datos Enlazados utiliza sólo URIs HTTP por dos razones: 1. proporcionan una forma sencilla de crear nombres únicos globales de manera descentralizada 2. y sirven como medio de acceso a la información que describe la entidad identificada. La URL http://www.frsf.utn.edu.ar/personto/ identifica globalmente al mo- delo semántico estudiado. Las demás 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# Definir las colecciones para las instancias de cada ontologı́a y sus res- pectivas URLs. Cada clase definida en un modelo semántico da origen a una serie de recursos, sus instancias. Los recursos de una misma clase se agrupan en una colección. Para identificar estos recursos es necesario adoptar un crite- rio respecto de los nombres a asignar a las colecciones y, además, construir una cadena de texto que identifique de manera unı́voca a cada recurso. Para la nominación de colecciones se utilizó 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ón 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ás de un campo, se concatenaron sus valores. La estructura de la URI correspondiente a cualquier recurso del modelo es: 3URFHHGLQJRI6$2$&RS\ULJKW‹KHOGE\WKHDXWKRU V  0pWRGR3UiFWLFRSDUDOD3REODFLyQ\3HUVLVWHQFLDGHXQ0RGHOR6HPiQWLFR Algunos ejemplos de las correspondencias entre cada clase del modelo y la URI de la colección 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. Población del Modelo Semántico Cada elemento de la ontologı́a tendrá una correspondencia, directa o no, con ele- mentos 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 permi- tan generar las tripletas necesarias para representar las definiciones de clases, instancias y sus propiedades, y las relaciones entre las instancias de esas clases. Estas tripletas convierten la ontologı́a modelada en una ontologı́a poblada. Para cada ontologı́a, identificar grupos de tripletas a generar. Esta actividad consiste en identificar qué grupos de tripletas se deben generar según los elementos que componen la ontologı́a dada. Para cada ontologı́a, se necesitan tripletas para la declaración e instanciación de cada una de sus elementos. Definir los patrones que seguirán las componentes sujeto, propiedad y objeto de las tripletas de cada grupo. Partiendo de los grupos establecidos en la actividad anterior se procedió a especificar de qué manera debı́an estar compuestas las tripletas para cada grupo. Declaración de clases. Para la declaración de clases se debe generar una triple- ta que identifique a la clase como tal y dos tripletas opcionales para agregar comentarios y etiquetas, siguiendo los patrones que se muestran a continuación: . “ETIQUETA” . “COMENTARIO” . Cuando existe herencia de clases, para cada una de las subclases se debe incluir una tripleta extra indicando la relación, como se muestra a continuacin: . Instanciación de clases Por cada instancia de clase se debe generar una tripleta según el siguiente patrón: . 3URFHHGLQJRI6$2$&RS\ULJKW‹KHOGE\WKHDXWKRU V  0pWRGR3UiFWLFRSDUDOD3REODFLyQ\3HUVLVWHQFLDGHXQ0RGHOR6HPiQWLFR Declaración de propiedades de instancias. Las propiedades se declaran con una tripleta que identifique la propiedad como tal y, opcionalmente, dos o más para agregar comentarios y etiquetas, con los patrones que se muestran a continuación. . “ETIQUETA” . “COMENTARIO” . En los casos en que el dominio de la propiedad está integrado por más de una clase, se genera una única tripleta para identificar a la propiedad, las tripletas de etiqueta y comentario para cada clase incluida en el dominio. Instanciación de propiedades de instancias. Se debe generar una tripleta por cada propiedad de cada instancia de cada clase siguiendo el siguiente patrón: “VALOR PROPIEDAD” . Declaración de relaciones entre instancias. Se debe generar una tripleta que identifique cada relación como tal y, opcionalmente, dos o más para agregar comentarios y etiquetas. Los patrones para estas tripletas son: . “ETIQUETA” . “COMENTARIO” . Instanciación de relaciones entre instancias. Se debe generar una tripleta por cada par de instancias relacionadas según el siguiente patrón: . 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ón de todas las clases y propiedades del modelo semántico y la extracción de todas las instancias almacenadas en las BDs. Para estos cálculos se debe tener en cuenta lo siguiente: - cada subclase en una relación de herencia requiere una tripleta adicional; - la instanciación 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 Para cada ontologı́a, redactar un archivo de mapeo D2RQ que permita generar los lotes correspondientes de forma automatizada. Mediante el uso de un lenguaje especı́fico, D2RQ Mapping Language, se pueden escribir blo- ques de código que establecen la asociación entre los campos de las tablas en las BDs y los elementos definidos en las ontologı́as, como clases y propiedades [4]. El 3URFHHGLQJRI6$2$&RS\ULJKW‹KHOGE\WKHDXWKRU V  0pWRGR3UiFWLFRSDUDOD3REODFLyQ\3HUVLVWHQFLDGHXQ0RGHOR6HPiQWLFR contenido base de un archivo de mapeo D2RQ consiste en la definición de prefijos, conexiones a BDs, bloques d2rq:ClassMap, uno por cada clase de la ontologı́a, y bloques d2rq:PropertyBridge para generar propiedades entre las instancias de las clases. A continuación se detallan cada uno de ellos. Declaración de prefijos. Los archivos de mapeo comienzan con la declaración 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ón de instancias. También, se deben incluir una serie de prefijos de espacios de nombres de uso común, como el de D2RQ y OWL. No es necesario incluir todos los prefijos especı́ficos del modelo, sino sólo aquellos que se utilizan localmente. Conexión a BDs. Se deben establecer las conexiones a las BDs con las que se va a trabajar para la extracción de tripletas. Para ello, un objeto d2rq:Database define una conexión JDBC a una BD relacional local o remota. Un archivo de mapeo D2RQ puede contener más de un objeto d2rq:Database, permitiendo el acceso a múltiples BDs diferentes. Una vez declarado este objeto, cualquier acceso a la BD se realizará 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ódigo, a través de un objeto d2rq:ClassMap. Por ejemplo, el bloque de código siguiente realiza el mapeo entre la tabla paises y la clase Pais de la ontologı́a Lugares, mediante la definición 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ón de la clase Pais, una etique- ta (d2rq:classDefinitionLabel ) y comentario (d2rq:classDefinitionComment) para la misma. La propiedad d2rq:dataStorage especifica que el objeto obtendrá datos de la BD definida anteriormente por el objeto map:persontoDB. Cada registro de la tabla dará origen a una instancia de la clase, que es- tará identificada y será posible acceder a la misma por medio de la URI com- puesta por el infijo paises/, correspondiente a la colección, seguido del código del paı́s. Esto se logra haciendo uso de la propiedad d2rq:uriPattern. En tiempo de ejecución, a toda URI generada a partir de un mapeo D2RQ se le añ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ó la instancia, una columna de otra tabla, un patrón generado a partir de la concatenación de varias columnas o una corres- pondencia entre valores enumerados. La definición de un d2rq:PropertyBridge está compuesta por la especificación del d2rq:ClassMap, que da origen a las ins- tancias a las cuales agrega propiedades mediante la propiedad d2rq:belongsToClassMap, 3URFHHGLQJRI6$2$&RS\ULJKW‹KHOGE\WKHDXWKRU V  0pWRGR3UiFWLFRSDUDOD3REODFLyQ\3HUVLVWHQFLDGHXQ0RGHOR6HPiQWLFR la propiedad RDF que está generando, especificada por la propiedad d2rq:property, y el valor asignado. Las Object Properties se extraen generalmente de alguna relación entre tablas y se mapean generando un bloque de tipo d2rq: PropertyBridge con el agregado de una o más propiedades d2rq:join, que fijen la relación de igualdad entre cam- pos de tabla. Además, teniendo en cuenta la definición de una object property co- mo 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 indi- car, mediante la punta de flecha, cuál de los lados de la condición de igualdad corresponde a una clave primaria. Esto permite al motor D2RQ optimizar el mecanismo interno de resolución de consultas SQL, reduciendo los tiempos de procesamiento requeridos para la transformación de los datos. En ciertos casos, el valor que de una propiedad puede estar incluido en una enumeración de posibles valores, por lo cual el rango de la propiedad corresponde a un tipo de datos enumerado. Pueden existir, además, casos en los que los valores almacenados en campos de tablas que dan origen a propiedades de instancias contengan valores que por diseño del modelo semántico deban ser traducidos o convertidos a otro formato al momento de la generación 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ás adecuado para persistir, en el proceso siguiente, los lotes generados en un T-Store, ya que su procesa- miento requiere menores niveles de recursos de CPU y memoria. Verificar si se generaron las cantidades de tripletas correctas. Las he- rramientas de lı́nea de comandos grep y wc 5 permiten contar la cantidad de lı́neas en un archivo que contengan un patrón de texto especificado. Dado que bajo el formato de serialización n-triples cada lı́nea del archivo de volcado co- rresponde a una tripleta, si se define correctamente el patrón de texto a buscar mediante el uso de expresiones regulares, se puede saber con exactitud la can- tidad de ocurrencias de un modelo de tripleta que responden a cada uno de los grupos particulares que existen en el volcado. 2.3. Persistencia del Modelo Semántico El objetivo es generar un repositorio persistente en el que se encuentre almace- nado el modelo semántico junto con las instancias generadas anteriormente, listo para ser consultado. Este proceso consta de las tres actividades siguientes. 5 http://manpages.ubuntu.com/ 3URFHHGLQJRI6$2$&RS\ULJKW‹KHOGE\WKHDXWKRU V  0pWRGR3UiFWLFRSDUDOD3REODFLyQ\3HUVLVWHQFLDGHXQ0RGHOR6HPiQWLFR Crear un Triple Store. Para crear la Triple Store se seleccionó la combinación de las herramientas D2RQ y el Framework Jena. Para la selección de dichas herramientas se buscó alcanzar el mayor grado de interoperabilidad entre ellas, teniéndose en cuenta, además, la disponibilidad de documentación y madurez de los proyectos de desarrollo correspondientes. De los dos repositorios ofrecidos por Jena, SDB y TDB6 , se eligió el segundo, debido a que SDB ya no se encuentra en desarrollo activo, y además presenta mayor eficiencia y escalabilidad. Cargar al Store cada una de las ontologı́as del modelo semántico. La gestión del repositorio y el acceso al mismo pueden realizarse programáticamente mediante una serie de métodos ofrecidos por la API del framework Jena, o me- diante el uso de herramientas de lı́nea de comando provistas por la plataforma. Para la carga masiva de datos, la segunda alternativa resulta más eficiente. La herramienta de lı́nea de comandos tdbloader permite la carga masiva de archivos RDF al almacén Jena TDB, y genera con cada carga los ı́ndices ne- cesarios 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ón es que tdbloader no es transaccional, lo que implica el bloqueo del repositorio durante las operaciones de carga, denegándose el acceso simultáneo desde otro proceso. Cargar al Store cada uno de los lotes de tripletas generados. El proceso de carga se lleva a cabo con la herramienta tdbloader, la cual primero realiza la carga de tripletas al almacén para luego pasar a la fase de indexado. 2.4. Consulta al Modelo Semántico Persistido y Poblado Para cada una de las preguntas de competencia planteadas en el DERO para el modelo semántico estudiado[6], se realizó una traducción a consultas en lenguaje SPARQL. El texto de cada consulta SPARQL se guardó en un archivo de texto con extensión .sparql, para luego utilizarlo en la ejecución de la consulta. Finalmente, sobre el repositorio Jena TDB se ejecutó cada una de las con- sultas 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 resol- ver consultas SPARQL es utilizando el motor de ejecución de consultas ARQ mediante la API provista por el framework Jena. Este método brinda mayor flexibilidad, a costas de un mayor consumo de recursos y tiempos de respuesta. 3. Lecciones Aprendidas y Trabajos Futuros En este trabajo se presentó una estrategia para persistir y poblar grandes onto- logı́as para dar soporte a aplicaciones de Datos Abiertos siguiendo los principios 6 https://jena.apache.org/documentation/tdb/ 3URFHHGLQJRI6$2$&RS\ULJKW‹KHOGE\WKHDXWKRU V  0pWRGR3UiFWLFRSDUDOD3REODFLyQ\3HUVLVWHQFLDGHXQ0RGHOR6HPiQWLFR de Datos Enlazados. La misma se probó en dos tesis de maestrı́a que requerı́an la población de ontologı́as con datos almacenados en sistemas de gobierno. De estas pruebas se pudo concluir que la estrategia es útil cuando la BD origen está compuesta por varias tablas y los mapeos entre los elementos de la BD y los del modelo semántico no son directos. Cuando hay pocas tablas, con mu- chos registros, y la herramienta de ontology learning permite crear de forma directa el modelo semántico y sus instancias, puede resultar más adecuada una herramienta como RDB2Onto [3]. La estrategia definida requiere contar con desarrolladores con conocimientos en tecnologı́as semánticas y definir un gran número de tripletas (en el caso pre- sentado se definieron más de 50.000.000 de tripletas). Por ello, se desarrolló un prototipo de aplicación que guı́a en la implementación de la estrategia definida, el cual están fuera del alcance de este trabajo. La estrategia propuesta está 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ón 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ón debe reveerse. Referencias 1. Brys, C., Montes, A.: Gobierno Electrónico 3.0. Aplicaciones de la Web Semántica a la Administración Pública. In: Anales del SIE 2011, Simposio de Informática en el Estado, pp. 15–30 (2011) 2. Calderón, C., Lorenzo, S.: Open Government: Gobierno Abierto. Algón Editores, España (2010) 3. Cerbah, F.,: Learning highly structured semantic repositories from relational data- bases: the RDBToOnto tool. In: Proc. 5th European semantic web conference on The semantic web: research and applications, pp. 777–781 (2008) 4. Cyganiak, R., Bizer, C., Garbers, J., Maresch, O., Becker, C.: The D2RQ mapping language, http://d2rq.org/d2rq-language (2012) 5. Heath, T., Bizer, C.: Linked Data: Evolving the Web into a Global Data Space. Morgan & Claypool, 1st ed. (2011) 6. Lozano, A.: Enfoque Basado en Ontologı́as para Brindar Acceso a la Información del Personal del Gobierno de la Provincia de Santa Fe. Tesis de Maestrı́a, Universidad Tecnológica Nacional, Facultad Regional Santa Fe, Argentina (2013) 7. Póveda-Villalón, M.: A Reuse-based Lightweight Method for Developing Linked Data Ontologies and Vocabularies. In: Simperl, E., Cimiano, P., Polleres, A., Corcho, O., Presutti, V. (eds.) The Semantic Web: Research and Applications. LNCS, vol. 7295, pp. 833–8379. Springer, Heidelberg (2012) 8. Villazón-Terrazas, B., Vilches-Blázquez, L., Corcho, O., Gómez-Pérez, A.: Metho- dological Guidelines for Publishing Government Linked Data. In: Wood, D. (ed.) Linking Government Data, pp. 27–49. Springer New York (2011) 9. Zins, C.: Conceptual Approaches for Defining Data, Information, and Knowledge. J. Am. Soc. Inf. Sci. Technol. 58, 479–493 (2007) 10. Avison, D., Lau, F., Myers, M., Nielsen, P.: Action research. Commun. ACM 42, 94–97 (1999) 3URFHHGLQJRI6$2$&RS\ULJKW‹KHOGE\WKHDXWKRU V