UNIVERSIDAD
REY JUAN CARLOS
ESCUELA SUPERIOR DE INGENIERÍA INFORMÁTICA INGENIERÍA INFORMÁTICA
Curso Académico 2010/2011
Proyecto de Fin de Carrera
MÉTODO PARA LA GENERACIÓN, PUBLICACIÓN Y VISUALIZACIÓN DE INFORMACIÓN EN FORMATO
LINKED DATA
Autor: Míguel Ángel García Delgado
Tutor: Alberto Fernández Gil
Resumen
El objetivo de este proyecto final de carrera es describir los pasos que deben realizarse para la generación, publicación y visualización de información en formato Linked Data de una manera sencilla y rápida.
Para lograr este objetivo, se explicará:
• qué es Linked Data y cuáles son sus principios
• que formatos se utiliza para publicar la información
• que herramientas se pueden utilizar para la generación de los datos a formato Linked Data
• que herramientas se pueden utilizar para la publicación de los datos en formato Linked Data
• que herramientas se pueden utilizar para la visualización gráfica de los datos en formato
Para ilustrar los puntos anteriores, se desarrollará el proceso que se describa desde el principio hasta el final, con datos referentes a festivales de música. Se partirá de una pequeña BBDD que se convertirá a formato Linked Data, se publicará y se podrá visualizar gráficamente.
1. Introducción ... 7
1.1 Introducción a Linked Data ... 7
1.2 El auge de la publicación de los datos mediante Linked Data ... 8
1.3 Iniciativas desarrolladas ... 11
1.4 Información preliminar ... 12
2. Objetivos ... 15
2.1 Desarrollo de un método para publicar datos en formato RDF cumpliendo con los principios de Linked Data ... 15
2.2 Desarrollo de un prototipo en el que se utilizará el método desarrollado ... 16
3. Descripción del método ... 17
3.1 Estudio de las fuentes de datos ... 18
3.2 Selección de las herramientas para la generación de la información en formato RDF .. 23
3.3 Selección de las herramientas para la publicación de la información en formato RDF . 31 3.4 Selección de las herramientas para la visualización de la información en formato RDF ... 35
4. Aplicación del método en nuestro prototipo... 40
4.1 Selección del modelo de datos ... 40
4.2 Creación de los ficheros RDF ... 43
4.3 Publicación de los ficheros RDF ... 47
4.4 Visualización de los ficheros RDF ... 51
4.5 Visualización gráfica de los datos utilizando la herramienta map4rdf ... 54
5. Conclusiones ... 58
6. Bibliografía ... 60
Anexo I ontología desarrollada para expresar las relaciones performanceOf y performedIn ... 62
Anexo II fichero configuración de OBD ... 64
Anexo III fichero de mappings r2o utilizado en OBDI ... 65
Anexo IV Fichero de configuración de Pubby ... 69
Anexo V Fichero de configuración de map4rdf ... 71
1. Introducción
1.1 Introducción a Linked Data
Según Linked Data (.org) [1]: “Linked Data is about using the Web to connect related data that wasn't previously linked, or using the Web to lower the barriers to linking data currently linked using other methods. More specifically, Wikipedia defines Linked Data as a term used to describe a recommended best practice for exposing, sharing, and connecting pieces of data, information, and knowledge on the Semantic Web using URIs and RDF”.
Linked Data se puede definir como una serie de buenas prácticas para publicar, compartir y conectar conjuntos de datos, información y conocimiento en la Web Semántica utilizando URI's y RDF.
Tim Berners-Lee definió cuatro principios que deben caracterizar la información en Linked Data [2]:
1. Use URIs as names for things / Utilizar URIs para identificar los recursos 2. Use HTTP URIs so that people can look up those names / Aprovechar el
HTTP de la URI para que la gente pueda localizar y consultar los recursos.
3. When someone looks up a URI, provide useful information, using the standards (RDF*, SPARQL) / Proporcionar información útil acerca del recurso cuando se consulte la URI mediante los estándars (RDF*, SPARQL) 4. Include links to other URIs. so that they can discover more things / Incluir
enlaces a otras URIs, de forma que se potencie el descubrimiento de información en la Web.
Para aplicar estos principios, se utilizan una serie de componentes que aparecen en la definición de los principios:
• Uniform Resource Identifier (URI): cadena de caracteres corta que identifica unívocamente un recurso.
• Resource Description Framework (RDF): es un framework para metadatos en la World Wide Web desarrollado por el World Wide Web Consortium (W3C)
• SPARQL Protocol and RDF Query Language (SPARQL): lenguaje para la consulta de datos RDF.
1.2 El auge de la publicación de los datos mediante Linked Data
La Web de Datos (Web of Linked Data en inglés) “is about using the Web to connect related data that wasn't previously linked, or using the Web to lower the barriers to linking data currently linked using other methods”. Dicho de otra manera, pretende facilitar el acceso, publicación y reutilización de los datos a través de la Web, así como el desarrollo de aplicaciones en torno a dichos datos. No sólo se centra en la publicación y reutilización de los datos, sino también en la generación de aplicaciones que hagan uso de los mismos. Este punto es importante ya que diferencia la Web de Datos de la actual Web, puesto que no se basa en documento sino en datos que se pueden utilizar de diferentes formas en diferentes aplicaciones.
Parte del auge de la publicación de datos en la nueva Web de Datos habría que atribuírselas a las iniciativas desarrolladas dentro de la Open Government Data. Estas iniciativas abogan por la publicación de una gran variedad de datos públicos disponibles de diferentes agencias gubernamentales. Entre las más importantes iniciativas hasta la fecha, se pueden indicar las desarrolladas por el gobierno de los Estados Unidos [3], por el gobierno del Reino Unido [4], el gobierno de Francia [5]. A nivel nacional, cabe destacar las realizadas por el gobierno del Principado de Asturias (Datos Asturias) [6], por el gobierno de Euskadi (Open Data Euskadi) [7] y por la Generalitat de Catalunya (Datos Abierto Gencat) [8].
Otras iniciativas que han impulsado el desarrollo de la Web de Datos a destacar serían la plataforma ePSI (european Public Sector Information) [9], para la publicación de catálogos de datos de información del sector público, la publicación de contenidos realizada por la BBC [10], con sus iniciativas BBC Programmes y BBC Music, recogidas en LinkedData.org.
A nivel español, cabe desatacar la iniciativa GeoLinkedData.es, desarrollada por el Ontology Engineering Group (OEG) [11] para publicar la publicación de diversas fuentes de información procedentes del Instituto Geográfico Nacional (IGN) en las que ha participado el alumno.
Para ilustrar el desarrollo de la Web de Datos, se mostrarán a continuación la evolución gráfica de los datasets recogidos en LinkedData.org. En estas figuras, se muestra la evolución en el número de datasets desde el año 2007 hasta el septiembre de 2010. En las figuras se puede observar diferentes datasets, cada burbuja, y sus relaciones, flechas que unen los datasets. Como se puede observar en las imágenes (fig. 1.1 a fig. 1.4), las flechas pueden ser unidireccionales, el dataset del que parte hace referencia al dataset destino, o bidireccionales, ambos datasets se referencian mutuamente.
Fig. 1.1: 28 datasets a finales de 2007 (10-11-2007).
Fig. 1.2: 45 datasets en 2008 (18-09-2008)
Fig. 1.3: 95 datasets en 2009 (14-07-2009)
Fig. 1.4: 203 datasets en 2010 (22-09-2010)
1.3 Iniciativas desarrolladas
Entre las iniciativas desarrolladas hasta el momento, se pueden citar las siguientes:
• Dbpedia [12]: “is a community effort to extract structured information from Wikipedia and to make this information available on the Web”. Este proyecto está realizado por la Universidad de Leipzig, Universidad Libre de Berlín y la compañía OpenLink Software. En la base de datos se describen más 3.380.000 entidades, contiene 1.460.000 enlaces a imágenes, 5.543.000 enlaces a páginas externas, 4.878.000 enlaces a datasets externos y 415.000 categorías Wikipedia.
• GeoNames [13]: base de datos geográfica que contiene más de 10 millones de nombres geográficos que corresponden a más de 7,5 millones de lugares existentes.
Estos nombres están organizados en 9 categorías y 645 subcategorías. Entre otros datos, incluye información como la latitud, longitud, altitud, población, etc.
• Data.gov: desarrollada por el gobierno de los Estados Unidos dentro de la Open Goverment Data Initiative. Su propóstio es “to increase public access to high value, machine readable datasets generated by the Executive Branch of the Federal Government.” (referencia a Data.gov). Esta iniciativa contiene 3281 conjuntos de datos a fecha de mayo de 2011.
• Open Data Euskadi: iniciativa del gobierno del País Vasco, cuyo compromiso es
“exponer los datos públicos que obran en su poder de forma reutilizable, con el fin de que terceros puedan crear servicios derivados de los mismos”. (referencia a Open Data Euskadi). Esta iniciativa contiene más de 1401 catálogos de datos diferentes a fecha de mayo de 2011.
• GeoLinkedData.es [14]: es una iniciativa abierta del Ontology Engineering Group (OEG) destinada al enriquecimiento de la Web de los Datos con datos geoespaciales del territorio nacional español. Esta iniciativa se ha puesto en marcha con la publicación en la Web de Datos de diversas fuentes de información procedentes del Instituto Geográfico Nacional. Las fuentes de datos utilizadas, hasta el momento, en GeoLinkedData.es pertenecen al Instituto Geográfico Nacional de España (IGN) y al Instituto Nacional de Estadística (INE): BCN200, BTN25, NGCE y NOMGEO.
• WebenemasunoLinkedData.es [15]: dataset con la información de las guías de viaje y blogs de El Viajero: Guías de Viajes de El País. Información disponible: guías de El Viajero, blogs, posts y fuentes de geolocalización de las guías. Este catálogo de datos es un ejemplo de colaboración entre instituciones académicas, el Ontology Engineering Group de la UPM, y empresas privadas, Grupo Prisa.
1.4 Información preliminar
Antes de explicar los siguientes puntos de la memoria, se deben explicar una serie de conceptos básicos:
HTTP (Hypertext Transfer Protocol): protocolo sin estado, no guarda información sobre conexiones anteriores, que define la sintaxis y la semántica que utilizan los elementos software de la arquitectura web (clientes, servidores, proxies) para comunicarse. El protocolo HTTP es importante en Linked Data como bien se define en uno de los principios básicos
“aprovechar el HTTP de la URI para que la gente pueda localizar y consultar los recursos”.
URI (Uniform Resource Identifier): es una cadena de caracteres corta que identifica inequívocamente un recurso (servicio, página, documento, dirección de correo electrónica, etc). Las URIs de los recursos en Linked Data se pueden representar de dos maneras:
• URIRefs (Unique Resource Identifiers References): una URI y el un identificador opcional separado de la URI por el símbolo #: http://www.ontology.org/people#Person
• URIs completas: http://xmlns.com/foaf/0,1/Person
RDF (Resource Description Framework) [16]: modelo de datos para el intercambio de datos en la Web. Permite describir los recursos mediante expresiones del tipo “sujeto- predicado-objeto”, también conocidas como tripletas. El sujeto representa el recurso y el predicado representa aspectos de los recursos y expresa una relación entre el sujeto y el objeto. Por ejemplo, si tenemos la frase “Madrid es la capital de España”, en RDF se podría representar de la siguiente forma: “Madrid” (sujeto) “esCapital” (predicado) “España”. Esta información también se puede representar de manera gráfica mediente grafos, donde los nodos representarían el sujeto y objeto y una flecha que los une el predicado. Para el ejemplo anterior, su representación sería la siguiente:
Fig. 1.5: representación en forma de grafo RDF se pueden expresar en diferentes formatos:
− RDF/XML: sintaxis XML para representar RDF
− RDFa: conjunto de extensiones de XHTML propuestas por el W3C para introducir semántica en los documentos
− N3: serialización no-XML de modelos RDF
− Turtle: formato de serialización para grafos RDF
− JSON: formato ligero para el intercambio de datos
Por ejemplo, el recurso http://geo.linkeddata.es/resource/Municipio/Madrid, con una etiqueta en la que se representa el nombre de la ciudad, podría representarse mediante una tripleta “sujeto-predicado-objeto”:
<http://geo.linkeddata.es/resource/Municipio/Madrid> <http://www.w3.org/2000/01/rdf-schema#label> "Madrid".
O en formato RDF/XML:
<rdf:RDF
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#">
<rdf:Description rdf:about="http://geo.linkeddata.es/resource/Municipio/Madrid">
<rdfs:label>Madrid</rdfs:label>
</rdf:Description>
</rdf:RDF>
La información anterior, ampliada con la información del recurso http://geo.linkeddata.es/resource/Municipio/Madrid, se podría representar mediante un grafo de la siguiente manera:
Fig. 1.6: representación en forma de grafo del recurso http://geo.linkeddata.es/resource/Municipio/Madrid
RDFs (RDF Schema) [17]: extensión semántica de RDF que proporciona los elementos básicos para la descripción de vocabularios.
Ontología: especificación explícita de una conceptualización, es decir proporciona una estructura y contenidos de forma explícita que codifica las reglas implícitas de una parte de la realidad, independientemente del fin y del dominio de la aplicación en el que se usarán o reutilizarán sus definiciones.
OWL (Web Ontology Language) [18]: lenguaje de marcado para publicar y compartir datos usando ontologías. Está construido sobre RDF y codificado en XML. Existen tres variantes de OWL: OWL Lite (la más básica), OWL DL y OWL Full (la más completa).
Existen dos versiones de OWL, OWL 1 (de 2004) y OWL 2 (de 2009). OWL 2 añade nueva funcionalidad respecto a OWL 1, tales como una nueva sintáxis, OWL 2 Manchester Syntax, cadenas de propiedades, enriquecimiento de los tipos de datos y de los rangos de datos, etc.
2. Objetivos
Los objetivos de este proyecto final de carrera son dos:
1. Explicar los pasos básicos para publicar información en formato RDF 2. Desarrollo de un prototipo en el que se aplicará el método
2.1 Desarrollo de un método para publicar datos en formato RDF cumpliendo con los principios de Linked Data
El primer objetivo de este proyecto es el conseguir describir el método, o pasos básicos y necesarios que se deben realizar, para generar datos en formato RDF cumpliendo con los principios de Linked Data que se explicaron en la introducción. Nuestro método se desarrollará mediante los siguientes pasos:
1. Estudio de las fuentes de datos.
2. Selección de las herramientas para la generación de la información en formato RDF.
3. Selección de las herramientas para la publicación de la información en formato RDF.
4. Selección de las herramientas para la visualización de la información en formato RDF.
2.2 Desarrollo de un prototipo en el que se utilizará el método desarrollado
El prototipo que se realizará será la puesta en práctica de los cuatro pasos que se describirán en los apartados 3 desde el punto 3.1 hasta el punto 3.4.
Para la aplicación de los pasos 3.1 a 3.4, se utilizará un conjunto de datos que ilustrarán de una manera concreta el uso de las herramientas en cada uno de los pasos. El conjunto de datos estará centrado en el dominio de la música, centrado en festivales musicales de ámbito nacional. Por cada uno de los elementos, dispondremos de la siguiente información:
• Nombre del festival
• Enlace a su página web
• Grupos cabeza de cartel que hayan participado en su última edición
• Punto geográfico (latitud y longitud)
Con estos datos, se podrá poner en práctica el modelado de los datos en formato RDF.
También se mostrará como modelar relaciones entre los datos, así como la representación de datos geoespaciales. Dichos datos se irán transformando en cada paso, hasta obtener datos publicados en formato RDF y visibles mediante la aplicación map4rdf. Este último paso, la visualización de los datos mediante la aplicación map4rdf se añade para ilustrar como los datos generados pueden ser utilizados en un aplicación real que se está utilizando en proyectos reales.
3. Descripción del método
En este apartado de la memoria, se van a describir de manera detallada los pasos necesarios que se deben aplicar para, a partir de las fuentes de datos, publicar los datos en formato RDF de una forma fácil y rápida.
Fig. 3.1: Pasos del método
Como se puede ver en la imagen (fig. 3.1), el método está compuesto por cuatro pasos.
Los tres primeros son básicos y necesarios. A partir de las fuentes de datos originales, se deben obtener datos en formato RDF que estén disponibles para su consulta y uso. El cuarto paso es opcional pero más que recomendable para tener una visualización más “amigable” de los datos. Si nos quedamos en el paso 3, los datos estarán disponibles en formato RDF pero sólo accesibles mediante consultas SPARQL. Para acceder a los datos, se tendrían que realizar consultar, por lo que utilizar herramientas que nos permiten ver los datos de una manera más amigable, es más que recomendable.
3.1 Estudio de las fuentes de datos
En este punto se van a describir los pasos que se deben realizar:
• identificación de las fuentes de datos que se van a transformar y publicar
• identificación de los tipos de datos/información que representan los campos que se transformarán
• elección del modelo de datos que se va a utilizar en la transformación de los datos Identificación de las fuentes
En este paso se deben identificar las fuentes de datos a publicar. A la hora de realizar la identificación de los datos que se van a publicar, se debe tener en cuenta dos cuestiones básicas:
1. se deben publicar datos útiles
2. se deben publicar los datos en formatos reutilizables
El punto 1 no deja lugar a dudas, la publicación de los datos debe responder a criterios de utilidad ya que uno de los principios de Linked Data es la reutilización de los datos.
Publicar datos con poca posibilidad de ser reutilizados en otros catálogos o en aplicaciones desarrolladas para utilizarlos, a parte del aspecto informativo, no aportan nada a la Web de Datos. Datos de administraciones públicas, información de la Wikipedia que se puede utilizar en aplicaciones, así como información geográfica, se han demostrado de gran interés.
El punto 2 es igual de importante que el anterior. Se deben utilizar formatos de datos estructurados y fácilmente reutilizables como pueden ser: RDF/XML, RDFa, N3, Turtle, JSON. Cuanto más se utilicen estos formatos estructurados, mayor difusión tendrán y más rápidos serán adoptados por la comunidad. Publicar datos en formatos difícilmente reutilizables, no beneficia a la difusión de los mismos. Por ejemplo, un organismo público puede hacer accesible cierta información en formato PDF. La información está disponible, si, pero este formato hace difícil su reutilización ya que si se quiere utilizar la información contenida en los documentos, debería realizarse inicialmente un procesamiento del fichero para extraer la información.
Otros puntos que deben tenerse en cuenta a la hora de publicar los datos, y que no siempre se tienen en cuenta, son:
• autoría de los datos: se deben publicar datos de acceso público, de los que seamos propietarios o, en caso de no serlo, tengamos autorización del autor(es) de los mismos.
• licencias de los datos: se debe tener en cuenta la licencia de los datos que se van a publicar. Se debe indicar el tipo de licencia que se utiliza en su publicación.
Algunas de las licencias que se pueden utilizar en este caso son Creative
Commons, en cualquiera de sus opciones, GNU Free Documentation License, etc.
• sensibilidad de los datos que se pueden publicar: se debe tener en cuenta a la hora de la publicación de los datos, el carácter de los mismos. No se deben publicar datos que entren en conflicto con la Ley Orgánica de Protección de Datos de Carácter Personal (LOPD).
Identificación de los tipos de datos/información que representan los campos que se transformarán
Una vez identificados los campos de las fuentes de datos que se van a publicar, hay que identificar los tipos de datos originales de los campos que se van a transformar. Además, no sólo se debe conocer el tipo de dato, sino que también es importante identificar la información que representan dichos campos en las fuentes de datos. Se explicarán estos dos puntos mediante una serie de ejemplos sencillos.
Por ejemplo, se tiene un campo de tipo “VARCHAR” en una base de datos. Dicho campo podríamos representarlo como un rdfs:label, como rdfs:comment. Con este ejemplo, se demuestra que existe una gran variedad de formas de representar la información y que no es un asunto trivial.
Otro ejemplo. Se tiene un campo “DATE” que podría representarse directamente con un campo rdfs:label, ya que no deja ser una cadena de texto. Sin embargo, sería más apropiado utilizar algún tipo de dato fecha como http://www.w3.org/2001/XMLSchema#date.
El último ejemplo, sirve para ejemplificar que no sólo es importante saber el tipo del dato sino también lo que representan. Si se tienes dos campos FLOAT que representan latitud y longitud. Se podrían representar como xsd:double. Pero si sabemos que existe un vocabulario llamado WGS84 utilizado para representar geoposicionamiento, podríamos representar los datos como http://www.w3.org/2003/01/geo/wgs84_pos#lat y http://www.w3.org/2003/01/geo/wgs84_pos#lat y agruparlos en un recurso de tipo http://www.w3.org/2003/01/geo/wgs84_pos#Point.
Elección del modelo de datos que se va a utilizar en la transformación de los datos Una vez identificados los campos y la información que representan, sólo queda identificar el/los vocabulario(s) que se utilizará(n) para la representación de los datos. Para hacer la información compatible con los clientes existentes y fácilmente integrables con otros conjuntos de datos, se deben reutilizar los vocabularios más conocidos para representar términos que estén términos ya existentes. Sólo se deben definir nuevos términos cuando los vocabularios existentes no sean adecuados.
Existe un vocabulario definido en la especificación de RDF que se puede utilizar como base a la hora de definir los tipos de datos que se utilizarán en nuestro modelo. En este vocabulario se definen clases (rdfs:Resource, rdfs:Class, rdfs:Literal, rdfs:Datatype, rdfs:XMLLiteral, rdfs:Property) y propiedades (rdfs:range,rdfs:domain, rdfs:type, rdfs:subClassOf, rdfs:subPropertyOf, rdfs:label, rdfs:comment).
Existen más vocabularios que se pueden utilizar para describir los campos de las fuentes de datos. Algunos de los vocabularios más importantes:
• OWL (Web Ontology Language): lenguaje de marcado para publicar y compartir datos usando ontologías. Está construido sobre RDF y codificado en XML. OWL tiene tres sublenguajes. OWL Full, OWL DL y OWL Lite. OWL Full y OWL DL soportan el mismo conjunto de constructores del lenguaje OWL. OWL Lite es un sublenguaje de OWL DL que soporta sólo un subconjunto de constructores.
Permite describir clases, propiedades, instancias de elementos, tipos de datos y anotaciones.
• Dublin Core [19]: desarrollado por The Dublin Core Metadata Initiative que busca proporcionar un vocabulario base de estándares para la industria para describir recursos. Existen dos niveles: Simple y Qualified. Simple Dublin Core define 15 elementos (Title, Creator, Subject, Description, Publisher, Contributor, Date, Type, Format, Identifier, Source, Language, Relation, Coverage y Rights).
Qualified Dublin Core define tres elementos más (Audience, Provenance y RightsHolder).
• FOAF (Friend of a Friend) [20]: es un vocabulario/ontología para describir personas, sus actividades y expresar sus relaciones con otras personas y objetos.
Define elementos como Person, name, mbox, homepage, nick, etc.
• Simple Knowledge Organization System (SKOS) [21]: proporciona una forma estándar para representar los sistemas de organización del conocimiento. SKOS trabaja en el desarrollo de especificaciones y estándares para soportar el uso de sistemas de organización del conocimiento como tesauros, esquemas de clasificación, etc en el marco de la Web Semántica.
• Vocabulary of Interlinked Datasets (VoID) [22]: vocabulario RDFS para expresar metadatos acerca de conjuntos de datos RDF. Define 4 clases y 27 propiedades diferentes.
• Basic Geo Vocabulary [23]: vocabulario mínimo para representar puntos con latitud, longitud y altitud.
• Open Provenance Model [24]: es un modelo de provenance (origen de datos) independiente de dominio que permite definir equivalencias o mappings entre vocabularios.
• Semantic-Interlinked Online Communities (SIOC) [25]: proporciona una ontología para la Web Semántica para describir los principales conceptos y propiedades de comunidades online como blogs, foros o listas de correos.
• Biographical Information (BIO) [26]: vocabulario para describir información biográfica de las personas.
• MPEG-7 Ontology [27]: es una transformación del standard MPEG-7 a OWL- Full, permitiendo descripciones de los detalles de una imagen, video o archivo de audio: tamaño, duración, descomposición en segmentos, etc.
• DBpedia Ontology: una ontología llana, entre dominios, creada manualmente basada en los términos más comunes utilizados en los infoboxes de Wikipedia.
Actualmente cubre más de 272 clases y está descrita por 1300 propiedades diferentes.
Como se puede observar, existe una gran variedad de vocabularios que nos permiten modelar los datos en función del tipo del tipo de información que vamos a publicar. Estos vocabularios se pueden utilizar de manera combinada para crear modelo de datos más ricos que nos permiten representar la información de una manera más completa.
El modelo de datos de GeoLinkedData.es nos va a servir como ejemplo del uso de diferentes vocabularios combinados para representar información de recursos geoespaciales de España. En este caso, se ha desarrollado una red de ontologías para dicha representación de los datos. Ontologías desarrolladas y/o reutilizadas:
• Statistical Core Vocabulary (SCOVO) [28]: vocabulario para representar información estadística en la web.
• FAO geopolitical ontology [29]: desarrollada por la Organización de las Naciones Unidas para la Agricultura y la Alimentación (FAO) para facilitar el intercambio y distribución de datos de manera estandarizada entre sistemas de gestión de información sobre países y/o regiones.
• HydrOntology [30]: ontología para describir fenómenos hidrográficos. Intenta cubrir la mayor parte de los conceptos del dominio hidrográfico así como armonizar fuentes de información heterogéneas.
• GML Ontology [31]: ontología para la representación de información estructurada de acuerdo con la OGC Geography Markup Language (GML3.0).
• WGS84 Vocabulary: vocabulario para representar latitud, longitud y altitud.
• Time Ontology [32]: ontología de conceptos temporales para describir contenido temporal de páginas web y propiedades temporales de servicios web. Proporciona un vocabulario para expresar hechos sobre relaciones topológicas entre instantes e intervalos, junto con información sobre duraciones e informaciones sobre fecha y hora.
En la siguiente imagen (fig. 3.2), se puede observar una figura sobre la red de ontologías de Geo.linkeddata.es.
Fig. 3.2: Red de ontologías de Geo.Linkeddata.es
3.2 Selección de las herramientas para la generación de la información en formato RDF
Una vez elegido la representación de los datos, se debe elegir la herramienta para generar la información en formato RDF. A continuación se presentarán una serie de herramientas que se pueden utilizar. La lista de herramientas que se van a presentar son:
• R2O y ODEMapster
• OBDI
• NOR2O
• Jena
• geometry2rdf
• D2RQ Platform
• Triplify
• Ultrawrap
En este listado de herramientas, hay dos enfoques diferentes para trabajar con las fuentes de datos:
• aquellas que realizan el volcado de los datos directamente a ficheros en formato RDF. Las herramientas que trabajan de esta manera son R2O y ODEMapster, OBDI, NOR2O, Jena, geometry2rdf.
• herramientas que generan la información en formato RDF en tiempo de ejecución, D2RQ Platform, Triplify y Ultrawrap.
R2O y ODEMapster
R2O y ODEMapster [33] han sido desarrollados por miembros del Ontology Engineering Group de la Facultad de Informática de la Universidad Politécnica de Madrid.
R2O y ODEMapster son un marco integrado para la expresión formal, evaluación, verificación y explotación de mapeos semánticos entre ontologías y bases de datos relacionales. Está formado por:
• R2O: lenguaje declarativo basado en XML que permite la descripción arbitraria de expresiones de mapeo complejas entre elementos ontológicos (conceptos,
atributos y relaciones) y elementos de relacionales (relaciones y atributos).
• Procesador ODEMapster: genera instancias de la Web Semántica a partir de instancias relacionales basados en la descripción de los mapeos expresados en un documento R2O.
La creación de ficheros RDF se realizaría en dos pasos:
1. se genera el fichero R2O que define las correspondencias entre los elementos de la base de datos y la ontología.
2. Ejecutamos el procesador ODEMapster, que a través del fichero de mapeos definido en el paso anterior, realiza la transformación de los datos de la base de datos a elementos en formato RDF.
Existe un plugin desarrollado para el editor de ontologías NeOn Toolkit (NTK). Este plugin está integrado dentro de la herramienta y ofrece a los usuarios una interfaz gráfica para crear, ejecutar o consultar mapeos R2O. Funciona con bases de datos MySQL y Oracle.
R2O y ODEMapster ha sido utilizado por la FAO, la empresa iSOCO, los proyectos SemSorGrid4Env (europeo), Web n+1 (nacional), GIS4GOV (nacional) y la iniciativa GeoLinkedData.es.
Ontology Based Data Integration (OBDI) del OEG
Desarrollado miembros del Ontology Engineering Group de la Facultad de Informática de la Universidad Politécnica de Madrid.
OBDI [34] es una librería para la generación de ficheros RDF a partir de la información contenida en bases de datos MySQL y Oracle. A pesar de lo que se pueda deducir por su nombre, no se necesita una ontología para utilizar OBDI. Aunque se recomienda que la generación de los ficheros se base en vocabularios/ontologías para representar la información.
Para realizar la generación de los ficheros, sólo se necesita un fichero de mapeos en formato R2O y disponer de conexión con la base de datos con la que se va a trabajar.
NOR2O
Desarrollado por Boris Villazón-Terrazas, miembro del Ontology Engineering Group (OEG) de la Facultad de Informática de la Universidad Politécnica de Madrid.
NOR2O (Non-Ontological Resources to Ontologies) [35] es una librería que realiza un proceso ETL (Extract, Transform and Load) para transformar recursos no ontológicos en ontologías. Recursos no ontológicos son recursos que no han sido formalizados mediante una ontología. Un recurso ontológico puede ser una BBDD, un fichero XML, XLS, etc. En la siguiente figura (fig. 3.3) se muestran los módulos de los que se compone la librería:
Fig. 3.3: Módulos que componen NOR2O
NOR Connector: carga los esquemas de clasificación, tesauros y lexicones modelados con sus correspondientes modelos e implementaciones. Se encarga de cargar las fuentes de datos que se utilizan como entrada del proceso.
Transformer: realiza la transformación según la secuencia de actividades incluida en los patrones. Interactúa con el Semantic Relation Disambiguator.
Semantic Relation Disambiguator: encargado de obtener la semántica entre dos elementos NOR. Interactúa con el External Relation Disambiguator.
External Relation Disambiguator: se encarga de la interacción con recursos externos para obtener las relaciones semánticas entre dos elementos NOR. Utiliza WordNet para realizar este proceso.
OR Connector: genera la salida de todo el proceso descrito. La salida puede ser una ontología OWL o un fichero RDF.
Jena
Jena (Semantic Web framework) [36] pertenece a Hewlett-Packard Development Company, LP, Talis Systems Ltd. y Epimorphics Ltd.
Jena es un marco de trabajo java para la construcción de aplicaciones Web Semánticas.
Proporciona una API para extraer/insertar información en grafos RDF. Estos grafos son representaciones abstractas de un modelo. Los modelos se pueden generar desde cero, con información de ficheros, bases de datos, URLs,etc. La lectura y escritura de RDF en formatos RDF/XML, N3 y N-triples. Jean también permite la consulta de los modelos mediante SPARQL.
geometry2rdf
geometry2rdf [37] ha sido desarrollado por miembros de la iniciativa geo.linkeddata.es, entre los que se encuentra el alumno, desarrollada por el Ontology Engineering Group de la Facultad de Informática de la Universidad Politécnica de Madrid.
geometry2rdf es una librería para generar ficheros RDF a partir de información geométrica de bases de datos. La información geométrica puede estar disponible en GML (Geography Markup Language) o WKT (Well-know text markup language).
En la siguiente imagen (fig. 3.4) se muestra el proceso de creación de los ficheros RDF utilizando la librería geometry2rdf:
Fig. 3.4: Proceso de ejecución de geometry2rdf
Una vez recuperada la información geoespacial de la base de datos, mediante GeoTools (librería open source para el tratamiento de datos geoespaciales) se realiza el tratamiento de los datos geoespacial. Después, mediante Jena (Semantic Web Framework) se generan los ficheros RDF.
geometry2rdf genera los ficheros siguiendo el modelo geométrico definido en geo.linkeddata.es. Este modelo soporta geometrías simples, puntos, o geometrías compuestas, linestring (líneas) o polígonos (polygon).
D2RQ Platform
D2RQ Patform [38] ha sido desarrollado por el Web-based Systems Group de la Freie
Universität Berlin.
D2RQ Platform es un lenguaje declarativo para describir mappings entre esquemas de bases de datos relacionales y ontologías OWL/RDFS. Mediante los mappings, permite acceder a una vista RDF de una base de datos no RDF. El acceso a los datos puede realizarse mediante la API de Jena, Sesame o mediante consultas SPARQL.
D2RQ Platform se compone de:
• D2RQ Mapping Language: leguaje declarativo para describir las relaciones entre una ontología y un modelo de datos relacional.
• D2RQ Engine: plugin para Jena y Sesame que permite el acceso a los datos en la base de datos: Rescibe las llamadas de las API de Jena y Sesame a consultas SQL para la base de datos y devuelve los resultados en el formato correspondiente.
• D2R Server: servidor HTTP que permite acceder a los datos a través de la Web como cualquier otro servidor de aplicaciones. Se hablará con más detalle de este elemento en el apartado 3.3.
En la siguiente imagen (fig. 3.5) se representa la estructura de la D2RQ Platform. En la imagen se representan los tres elementos aunque en este apartado nuestra atención se centra en la parte inferior de la imagen.
Fig. 3.5: Estructura de la D2RQ Platform
D2RQ Engine se implementa como un grafo de Jena que encapsula la base de datos generando un grafo virtual RDF. Dicho grafo virtual es sólo de lectura por lo que no se permiten cambios en él. Como se ha comentado anteriormente, las peticiones que se realizan mediante las APIs de Jena y Sesame se transforman en consultas SQL. El resultado de las consultas SQL se transforman a tripletas RDF o a resultados de SPARQL,
Triplify
Triplify [39] ha sido desarrollado por el grupo Agile Knowledge and Semantic Web (AKSW) del Department of Business Information Systems del Institute for Computer Science de la Universität de Leipzig.
Triplify es un plugin para aplicaciones web que, basándose en la definición de consultas a bases de datos relacionales para una aplicación web específica, recupera la información, convirtiendo los resultados de las consultas en RDF, JSON y Linked Data.
Para generar en formato Linked Data la información de una aplicación web, se utiliza un fichero de configuración triplify que se utiliza para realizar la conversión de los datos contenidos en la base de datos. Existen ficheros de configuración triplify para diferentes aplicaciones web como Drupal, Wordpress, Joomla!.
El proceso para generar el fichero triplify de una aplicación web consiste en la definición de un número de consultar SQL que recojan la información que se quiere publicar.
Para poder realizar este paso, se necesita que los resultados de las consultas cumplan una estructura concreta:
1. La primera columna debe contener un identificador que pueda usarse para generar las URIs de las instancias.
2. Los nombres de las columnas se utilizarán para generar las URIs de las propiedades. Se pueden renombrar las columnas de las tablas de la base de datos (por ejemplo, SELECT id,name AS 'foaf:name' FROM users) para reutilizar propiedades de vocabularios existentes como Dublin Core, FOAF, etc.
3. Las celdas individuales del resultado de una consulta contienen valores de los datos o referencias a otras instancias y, eventualmente, constituirán los objetos de otras tripletas resultantes.
Fig. 3.6: Creación de tripletas a partir de una tabla en la base de datos
Triplify tiene una serie de limitaciones:
• sólo está implementado en PHP
• no soporta SPARQL
• necesita acceso directo a la base de datos relacional, bien por un objeto PDO (conexión entre PHP y un servidor de base de datos) o el driver estándar de MySQL.
• para publicar RDF como Linked Data, Triplify se basa en el URL rewritting, proporcionado por Apache's mod_rewrite. Para JSON y RDF estándar, no es necesario el URL rewritting.
Ultrawrap
Ultrawrap [40] ha sido desarrollado por The Miranker Lab del Department of Computer Science de The University of Texas en Austin.
Ultrawrap permite realizar vista virtual RDF de bases de datos. El funcionamiento de Ultrawrap se representa en la siguiente imagen (fig. 3.7):
Fig. 3.7: Esquema de funcionamiento de Ultrawrap
Los pasos son los siguientes:
1. A partir del esquema de la base de datos, se genera una ontología putativa. Dicha ontología es el resultado de la transformación sintáctica del esquema de una base de datos relacional.
2. A partir de dicha ontología putativa, se genera la vista virtual RDF que representa toda la información de la base de datos mediante tripletas.
3. Se puede acceder a la vista virtual RDF mediante consultas SPARQL.
4. Mediante el SQL Query Optimizer, las consultas SPARQL se transforman a consultas optimizadas SQL. El resultado de la ejecución de las consultas se devuelve como RDF.
3.3 Selección de las herramientas para la publicación de la información en formato RDF
Una vez elegido la representación de los datos y generada la información en formato RDF, se debe elegir la herramienta para publicar la información. A continuación se presentarán una serie de herramientas que se pueden utilizar:
• Virtuoso Open Source Edition
• D2R Server
• AllegroGraph RDFStore
• Joseki
Virtuoso Open Source Edition
Virtuoso Open Source Edition [41], así como su versión comercial, han sido desarrollados por OpenLink Software. Esta descripción se centrará en la edición Open Source.
Virtuoso es un Object-Relational Database Management System (ORDBMS) así como un servidor de aplicaciones híbrido (también conocido como Universal Server) que proporciona gestión, acceso e integración de datos. Las principales características de Virtuoso son:
• Gestión de Datos Relacionales
• Gestión de Datos RDF
• Gestión de datos XML
• Gestión de Contenidos de texto libre e indexación completa de texto
• Servidor Web de documentos
• Servidor de Linked Data
• Servidor de aplicaciones web
• Despliegue de servicios web (SOAP o REST)
En esta memoria nos centraremos en los aspectos centrados en la publicación de la información en formato RDF. Virtuoso ofrece directamente un SPARQL endpoint que permite la consulta de los recursos contenidos en dicho servidor.
Virtuoso proporciona una herramienta de gestión mediante una interfaz web, Virtuoso Conductor, desde la que se tiene completo acceso a todas las funcionalidades disponible:
• Administración del sistema: seguridad, cuentas de usuario, monitor de la aplicación, etc
• Bases de datos
• Opciones de replicación, sólo disponible en la versión comercial.
• Servidor de aplicaciones web
• Gestión de la bases de datos XML
• Gestión de los servicios web
• Gestión de las bases de datos RDF
En la siguiente imagen (fig. 3.8) se puede ver la apariencia de la interfaz web Virtuoso Conductor:
Fig. 3.8: Interfaz Virtuoso Conductor D2R Server
D2R Server [42] forma parte de D2RQ Platform que ha sido desarrollado por el Web- based Systems Group de la Freie Universität Berlin.
Como recordatorio, D2RQ Platform está compuesto por D2RQ Mapping Language, D2RQ Engine y D2R Server. Su funcionamiento se representa a continuación (fig. 3.9):
Fig. 3.9: Esquema funciomaniento D2R Server
D2R Server es una herramienta para publicar bases de datos relaciones en formato RDF. Permite una visualización RDF y HTML para navegar por el contenido de la base de datos y también permite a las aplicaciones consultar la base de datos mediante consultas SPARQL.
D2R Server está compuesto de:
• Linked Data Interface: permite que las descripciones RDF de los recursos sean accesibles mediante el protocolo HTTP. Se puede acceder a la descripción del recurso directamente con la URI del mismo.
• SPARQL Interface: permite la consulta y búsqueda del contenido de la base de datos mediante el lenguaje SPARQL.
• HTML Interface: permite un acceso web a los datos mediante los navegadores tradicionales.
AllegroGraph RDFStore
AllegroGraph RDFStore [43] ha sido desarrollado por la empresa Franz Inc.
AllegroGraph RDFStore es una base de datos y marco de aplicaciones que permite almacenar datos y metadatos como tripletas, consultar dichas tripletas mediante SPARQL y Prolog. También permite aplicar razonamiento RDFS++, soporte para consultas federadas, análisis de redes sociales, capacidades geoespaciales y razonamiento temporal.
Joseki
Joseki [44] ha sido desarrollado por Hewlett-Packard.
Joseki es un servlet que proporciona una interfaz web para la ejecución de consultas SPARQL sobre grafos RDF. Las características de Joseki son:
• los grafos RDF pueden estar en ficheros o bases de datos.
• Implementación HTTP (GET y POST) del protocolo SPARQL.
3.4 Selección de las herramientas para la visualización de la información en formato RDF
Una vez elegido la representación de los datos, generada la información en formato RDF y publicados los datos en un servidor, se acabarían los pasos “obligatorios” de nuestro método. Nuestro objetivo final es la publicación de los datos en formato RDF de manera que puedan ser reutilizados por otro conjunto de datos. Este objetivo se consigue en el paso tres, ya que estarían accesibles, al menos, mediante consultas SPARQL. Pero en nuestro método se quiere ir un paso más allá para facilitar la compresión a los usuarios de los datos contenidos en el dataset, utilizando herramientas que permiten la visualización de los recursos de una manera más “amigable” o comprensible para los usuarios.
Para ilustrar la importancia de este punto, se va a utilizar un ejemplo. Se utilizará el recurso de DBpedia que representa el Festival Internacional de Benicàssim, http://dbpedia.org/resource/Festival_Internacional_de_Benic%C3%A0ssim. Si realizamos una consulta SPARQL al SPARQL endpoint de DBpedia solicitando los datos del recurso, el resultado será el siguiente:
Fig. 3.10: Resultado consulta SPARQL
Esta representación, aunque comprensible, no es cómoda de utilizar ya que no está
DBpedia utiliza Pubby que representa la misma información de la siguiente manera:
Fig. 3.11: Representación recurso mediante Pubby
Se muestra toda la información completa del recurso en una única pantalla, con enlaces a otros elementos, permitiendo la navegación en cadena entre elementos relacionados.
Esta representación es más estructurada y comprensible para las personas.
A continuación se presentarán una serie de herramientas que se pueden utilizar para realizar la visualización de los datos RDF publicados en un servidor:
• Pubby
• SNORQL
• Disco – Hyperdata Browser
Pubby
Pubby [45] ha sido desarrollado por Richard Cyganiak y Chris Bizer de la Freie Universität Berlin.
Pubby se puede definir como una interfaz web para SPARQL endpoints. Las principales características son:
• interfaz Linked Data para navegadores RDF
• interfaz HTML para los navegadores convencionales
• se encarga de la resolución de las URIs de los recursos
• compatible con Tomcat y Jetty
• posibilidad de añadir metadatos a los datos proporcionados
• soporte a más de un SPARQL endpoint en la misma instalación El funcionamiento de Pubby se muestra en la siguiente figura (fig. 3.12):
Fig. 3.12: Esquema funcionamiento Pubby
Una vez instalado Pubby en un servidor, se encarga de resolver las peticiones de los recursos realizadas por medio de las URIs. Cuando se configura Pubby para un SPARQL endpoint concreto, se configura un mapeo que permite resolver las peticiones que se realizan al servidor devolviendo la información contenida en el SPARQL endpoint. Estos mapeos se especifican en un fichero de configuración llamado config.ttl.
SNORQL
SNORQL [46] has sido desarrollado por Richard Cyganaik de la Freie Universität Berlin.
SNORQL es un aplicación front-end desarrollada en AJAX que permite explorar el contenido de SPARQL endpoints siempre que estos soporte JSON. SNORQL permite realizar consultas SPARQL mediante el cuadro de búsqueda, así como navegar directamente utilizando los enlaces de los resultados de las mismas.
Fig. 3.13: Interfaz de SNORQL
En la imagen (fig. 3.13), se pueden apreciar dos zonas diferenciadas. El cuadro superior permite realizar búsquedas. Los resultados de las consultas se muestran en el parte inferior. Los resultados, al mostrarse como enlaces, permiten navegar de unos recursos a otros.
Para utilizar SNORQL, simplemente hay que desplegar el directorio contenido en la distribución en un servidor y modificar el fichero snorql.js para indicar el SPARQL endpoint con el que se trabajará. Se pueden modificar algunos parámetros más en este fichero.
Disco - Hyperdata Browser
Disco – Hyperdata Browser [47] ha sido desarrollado por Chris Bizer y Tobias Gauss de la Freie Universität Berlin.
Disco – Hyperdata Browser es un navegador simple para navegar por la Web Semantica. El navegador muestra en una página HTML toda la información que puede encontrar sobre un recurso específico en la Web Semántica. La descripción del recurso contiene enlaces que permiten la navegación entre diferentes recursos. Mientras el usuario va moviéndose de recursos en recurso, el navegador recupera dinámicamente la información de los nuevos recursos.
El navegador no necesita instalación ya que se puede utilizar directamente desde su página web (referencia). Para empezar a utilizarlo, sólo se tiene que introducir una URI en el cuadro correspondiente y pulsar en el botón Go! La estructura del navegador es la siguiente:
Fig. 3.14: Interfaz de Disco – Hyperdata Browser La ventana está compuesta de los siguientes elementos:
• cuadro de búsqueda para introducir la URI
• tabla con los resultados, organizada en tres columnas para mostrar el nombre de la propiedad, el valor y la fuente de dicha información
• listado de las fuentes de las que se han recuperado los datos que se muestran en el listado.
• en último lugar, aparece un enlace en el que se pueden ver todos los grafos RDF que en la caché de nuestra sesión.
4. Aplicación del método en nuestro prototipo
Una vez explicados en detalle los pasos del método, se desarrollará un prototipo en el que se desarrollarán los pasos uno a uno. La entrada de este prototipo será una base de datos con información relativa a festivales musicales de ámbito nacional y la salida será la misma información pero publicada en formato RDF.
4.1 Selección del modelo de datos
Primero se describirán las bases de datos con las que se va a trabajar. Como se comentó en el apartado 2 de la sección Objetivos, el prototipo se centrará en la migración de datos referentes a festivales de música de ámbito nacional así como los artistas cabeza de cartel que han actuado en cada festival.
No se ha encontrado una base de datos que contenga la información que se quiere utilizar para el ejemplo, así que se ha creado una base de datos que contenga la información que se quiere utilizar en el prototipo.
Las tablas contenidas en dicha base de datos son tres:
• festivales: contiene la información general del festival de música, nombre del festival, enlace a la página web del festival y localización geográfica donde se desarrolla el festival. Los campos que la componen son: Nombre VARCHAR(200) (Primary Key), Latitud DOUBLE, Longitud DOUBLE y Enlace VARCHAR(200).
• artistas: contiene la información básica sobre los artistas, nombre del artista (artista solitario o grupo musical) y enlace a la página web del artista. Los campos que la componen son: Nombre VARCHAR(200) (Primary Key) y Enlace VARCHAR(200).
• actuaciones: contiene, para cada festival, los artistas cabeza de cartel que han actuado en él. Los campos que la componen son: Festival VARCHAR(200) (Primary Key y Foreign Key) y Artista (Primary Key y Foreign Key).
Una vez detalladas las bases de datos, se debe elegir cómo se va a representar la información. En este caso, se generarán dos tipos de recursos, festivales y artistas, así como una relación entre ambos. Para representar la información se van a utilizar los siguientes vocabularios:
• Music Ontology
• RDF-schema
• Foaf
• WGS84 Vocabulary
• Una ontología que se basa en Music Ontology
Music Ontology se utilizará para los recursos festival y artista. Para representar los recursos de tipo Festival se utilizará la clase http://purl.org/ontology/mo/Festival. Para los recursos de tipo Artista se utilizará la clase http://purl.org/ontology/mo/MusicArtist. Esta clase se puede utilizar para representar artistas en solitario o grupos musicales. Existen especializaciones de esta clase para artistas en solitario, http://purl.org/ontology/mo/SoloMusicArtist, y grupos musicales, http://purl.org/ontology/mo/MusicGroup. Se podrían utilizar estas clases para representar los recursos de tipo Artista pero como el ejemplo se centra en los festivales y no en los artistas, se utilizará la clase que engloba ambos campos.
Los nombres tanto del festival como de los artistas se representarán como etiquetas mediante el tipo http://www.w3.org/2000/01/rdf-schema#label.
La representación de los enlaces de los festivales y de los artistas se realizará mediante la propiedad http://xmlns.com/foaf/0.1/homepage.
Para representar la información geoespacial, latitud y longitud, se podrían usar diferentes tipos, por ejemplo con http://www.w3.org/2000/01/rdf-schema#label, pero debemos tener en cuenta la información que representan y su posterior uso. En este caso, ambos campos representan la localización geoespacial de los recursos de tipo Festival. Por lo que el vocabulario debe seleccionarse dentro de dicho dominio. Además, los datos se utilizarán para su posterior visualización con la aplicación map4rdf, por lo que debemos representar dicha información de una forma compatible con dicha aplicación. map4rdf soporta dos modelos geométricos, el de DBpedia y el de geo.linkeddata.es. Para decidir qué modelo utilizar, el alumno se ha basado en la experiencia que ya tiene para elegir como representación el modelo geo.linkeddata.es. Según este modelo, cada recurso festival, tiene una geometría formada en este caso por un punto simple. Los recursos de tipo punto se definirán de tipo ttp://www.w3.org/2003/01/geo/wgs84_pos#Point, con su correspondiente latitud,
http://www.w3.org/2003/01/geo/wgs84_pos#lat, y longitud,
http://www.w3.org/2003/01/geo/wgs84_pos#long. La relación geometría entre un festival y un punto se representa así http://www.w3.org/2003/01/geo/wgs84_pos#geometry.
Para representar que en un festival ha actuado un artista, y su relación inversa, un artista actuó en un festival, se ha creado una ontología para expresar dicha propiedad de una manera apropiada. En Music Ontology no se define ninguna relación entre festivales y artistas. Lo más parecido serían las relaciones performed_in y su inversa performance_of pero relaciona actuaciones (Performance) y obras musicales (MusicalWork y Score). Para solucionar este problema, se genera una mini ontología en la que se desarrollan las relaciones performanceOf y su inversa performedIn, utilizando como base Music Ontology. La relación entre festival y artista se representará de la siguiente forma:
Festival performanceOf MusicArtist MusicArtist performedIn Festival
Dicha relaciones se representarán con http://localhost/ontology/mo/performanceOf y http://localhost/ontology/mo/performedIn.
Resumen de la representación de los datos:
• Festival: http://purl.org/ontology/mo/Festival
• Artista: http://purl.org/ontology/mo/MusicArtist
• Nombres: http://www.w3.org/2000/01/rdf-schema#label
• Enlaces: http://xmlns.com/foaf/0.1/homepage
• Latitud: http://www.w3.org/2003/01/geo/wgs84_pos#lat
• Longitud: http://www.w3.org/2003/01/geo/wgs84_pos#long
• Relación geometría: http://www.w3.org/2003/01/geo/wgs84_pos#geometry
• Relación festival-artista: http://localhost/ontology/mo/performanceOf
• Relación artista-festival: http://localhost/ontology/mo/performedIn
Se incluye la ontología desarrollada para añadir las relaciones performanceOf y performedIn en el anexo I de esta memoria.
4.2 Creación de los ficheros RDF
En nuestro prototipo, la generación de la información en formato RDF se realizará volcando el contenido de la base de datos a un fichero RDF. Para la generación de los ficheros RDF a partir de las bases de datos descritas en el apartado 1 de esta memoria, se utilizará OBDI. La elección se ha basado en los siguientes aspectos:
• funciona para el tipo de base de datos con la que se va a trabajar, MySQL.
• no es necesario basarse en una ontología, aunque en nuestro caso se han utilizado para la definición de los datos.
• el alumno ya ha trabajado en la generación de datos en RDF con dicha herramienta.
Para generar la información en formato Linked Data mediante OBDI, se trabaja con dos ficheros:
1. Fichero de propiedades
En este fichero se definen todas las propiedades de configuración de la herramienta:
• r2o.file.path: localización del fichero de mappings
• output.file.path: dónde se guardará el resultado de la ejecución
• jena.mode.type: cómo se almacenarán los datos durante la ejecución de la herramienta, en memoria, en una base de datos hsql o en TDB
• split_output_per_concept: si se quiere generar un único fichero con los resultados o generar un fichero por cada tipo de recurso definido en el fichero r2o.
• database connection: datos de conexión a la base de datos con la que se trabajará El fichero de configuración empleado para el desarrollo del prototipo se incluye en el anexo II de esta memoria.
2. Fichero de mappings r2o
En este fichero, se definen los mapeos necesarios para convertir la información de la base de datos a ficheros RDF con la estructura definida en el punto anterior. Este fichero de mappings, en lenguaje r2o, es un fichero XML del que se explicará su estructura. El siguiente código muestra la estructura básica para definir el mapping entre elementos de una tabla y los recursos que se van a generar.
<conceptmap-def name="http://purl.org/ontology/mo/Festival" identified-by="Festival">
<has-table name="pfc.festivales" alias="festivales"></has-table>
<uri-as encodeURI="true">
...
</uri-as>
<described-by>
<attributemap-def name="http://www.w3.org/2000/01/rdf-schema#label">
...
</attributemap-def>
<dbrelationmap-def name="http://www.w3.org/2003/01/geo/wgs84_pos#geometry"
to-concept="Point1" identified-by="pp01">
...
</dbrelationmap-def>
</described-by>
</conceptmap-def>
Los elementos que forman esta estructura son:
• conceptmap-def: se utiliza para definir el tipo de recurso que se va a generar. En el código anterior, se genera un recurso de tipo http://purl.org/ontology/mo/Festival, como se indica en el parámetro name.
• has-table: define la tabla de la que se extraerán los datos. Se puede definir un alias para no tener que indicar siempre el esquema, nombre de tabla y columna. En vez de poner siempre pfc.festivales.nombre, utilizaremos festivales.nombre.
• uri-as: para definir la estructura de la URI que representará el recurso. Se puede indicar si se debe codificar en formato UTF-8 o no. Si el campo que se va a utilizar para generar la URI contiene caracteres no permitidos en una url, debe codificarse dicha parte. Ejemplo: en nuestro prototipo, tenemos el campo nombre de la tabla festivales que contiene el valor “Festival Internacional de Benicàssim”. Este valor contiene caracteres que no son válidos en una url, como espacios y vocales con tilde. En nuestro ejemplo, las URIs se formarán como la concatenación de la base http://localhost/resource/Festival/”nombre del festival”. Si no indicásemos que se debe codificar la uri, el resultado sería http://localhost/resource/Festival/Festival Internacional de Benicàssim que no es válido. Al indicar que la uri se debe
codificar, el resultado final es
http://localhost/resource/Festival/Festival%20Internacional%20de%20Benic%C3
%A0ssim que si es resolvible por los navegadores. En nuestro caso, las uris que se generen por cada recurso serán completas y se crearán siguiendo el patrón http://localhost/resource/Festival/+”nombre del recurso”. Esto se indica mediante el siguiente código:
<operation oper-id="concat">
<arg-restriction on-param="string1">
<has-value>http://localhost/resource/Festival/</has-value>
</arg-restriction>
<arg-restriction on-param="string2">
<has-column>festivales.nombre</has-column>
</arg-restriction>
</operation>
• described-by: en este apartado del código, se definen los atributos y relaciones con otros recursos que formarán parte del recurso que se está definiendo.
• attributemap-def: sirve para definir un atributo del recurso que se está definiendo.
En el campo name se define el tipo de atributo que se genera y, opcionalmente, de puede indicar el datatype del mismo. En el siguiente ejemplo, se generar un atributo de tipo http://xmlns.com/foaf/0,1/homepage cuyo datatype es http://www.w3.org/2001/XMLSchema#anyURI.
<attributemap-def name="http://xmlns.com/foaf/0.1/homepage"
datatype="http://www.w3.org/2001/XMLSchema#anyURI">
<selector>
<aftertransform>
<operation oper-id="constant">
<arg-restriction on-param="const-val">
<has-column>festivales.enlace</has-column>
</arg-restriction>
</operation>
</aftertransform>
</selector>
</attributemap-def>
• dbrelationmap-def: sirve para definir una relación entre el recurso que se está definiendo y otro recurso definido en el fichero r2o con el que se está trabajando.
En este elemento, se define el nombre de la relación que se va a definir y el recurso destino. En el siguiente ejemplo, se define una relación de tipo http://www.w3.org/2003/01/geo/wgs84_pos#geometry entre el recurso Festiva y un punto identificado como Point1.
<dbrelationmap-def name="http://www.w3.org/2003/01/geo/wgs84_pos#geometry"
to-concept="Point1" identified-by="pp01">
<joins-via joins-type="left">
<condition oper-id="equals">
<arg-restriction on-param="value1">
<has-column>festivales.nombre</has-column>
</arg-restriction>
<arg-restriction on-param="value2">
<has-column>pp1.nombre</has-column>
</arg-restriction>
</condition>
</joins-via>
</dbrelationmap-def>
Con estos elementos básicos, se puede definir los mappings entre los elementos de las tablas en la base de datos y los recursos que se generan. En la bibliografía se añade una referencia a un manual completo sobre r2o.
El fichero r2o empleado para el desarrollo del prototipo se incluye en el anexo III de esta memoria.
Al final, con este fichero r2o, los recursos generados tienen la siguiente estructura:
• Festival
<rdf:Description
rdf:about="http://localhost/resource/Festival/Festival%20Internacional%20de%20Benic%C3%A0ssim">
<j.3:performanceOf rdf:resource="http://localhost/resource/ArtistaMusical/Gorillaz"/>
<j.2:geometry rdf:resource="http://localhost/resource/wgs84/40.04755_0.047432"/>
<j.0:homepage rdf:datatype="http://www.w3.org/2001/XMLSchema#anyURI">
http://fiberfib.com/</j.0:homepage>
<rdfs:label xml:lang="es">Festival Internacional de Benicàssim</rdfs:label>
<rdf:type rdf:resource="http://purl.org/ontology/mo/Festival"/>
</rdf:Description>
• Point
<rdf:Description rdf:about="http://localhost/resource/wgs84/40.04755_0.047432">
<j.2:long rdf:datatype="http://www.w3.org/2001/XMLSchema#double">0.047432</j.2:long>
<j.2:lat rdf:datatype="http://www.w3.org/2001/XMLSchema#double">40.04755</j.2:lat>
<rdf:type rdf:resource="http://www.w3.org/2003/01/geo/wgs84_pos#Point"/>
</rdf:Description>
• MusicArtist
<rdf:Description rdf:about="http://localhost/resource/ArtistaMusical/Gorillaz">
<j.3:performedIn
rdf:resource="http://localhost/resource/Festival/Festival%20Internacional%20de%20Benic%C3%A0ssim"/>
<j.0:homepage rdf:datatype="http://www.w3.org/2001/XMLSchema#anyURI">
http://gorillaz.com/</j.0:homepage>
<rdfs:label xml:lang="es">Gorillaz</rdfs:label>
<rdf:type rdf:resource="http://purl.org/ontology/mo/MusicArtist"/>
</rdf:Description>
