Introducción a las bases de datos RDF Renzo Angles renzoangles@gmail.com January 7, 2015 2 Indice 1 Introducción a La Web Semántica 5 2 RDF 2.1 El modelo de datos RDF . . . . . . . . . . . . . . . . . . . . . 2.2 Formatos de codificación para RDF . . . . . . . . . . . . . . . 2.3 Fuentes de datos RDF . . . . . . . . . . . . . . . . . . . . . . 11 12 16 18 3 RDF Schema 19 3.1 Vocabulario de RDF Schema . . . . . . . . . . . . . . . . . . . 20 3.2 Visualización de un esquema RDF . . . . . . . . . . . . . . . . 24 3.3 Ontology Web Language (OWL) . . . . . . . . . . . . . . . . . 24 4 SPARQL 4.1 Introducción a SPARQL . . . . . . . . . . . . . . 4.2 SPARQL 1.0 . . . . . . . . . . . . . . . . . . . . . 4.2.1 Patrones de grafo complejos . . . . . . . . 4.2.2 Patrones con condiciones de filtro . . . . . 4.2.3 Modificadores de solución . . . . . . . . . 4.2.4 Patrones para consultar grafos con nombre 4.3 SPARQL 1.1 . . . . . . . . . . . . . . . . . . . . . 4.3.1 Operadores agregados . . . . . . . . . . . 4.3.2 Sub-consultas . . . . . . . . . . . . . . . . 4.3.3 Negación de patrones de grafo . . . . . . . 4.3.4 Patrones de camino . . . . . . . . . . . . . 4.3.5 Creación de valores . . . . . . . . . . . . . 4.3.6 Consultas federadas . . . . . . . . . . . . . 4.3.7 Sobre el poder expresivo de SPARQL . . . 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 32 36 36 39 39 40 41 41 43 45 46 47 48 49 4 A Archivos ejemplo INDICE 55 Capı́tulo 1 Introducción a La Web Semántica La World Wide Web (“WWW” o simplemente web) es una plataforma tecnológica que ha cambiado la sociedad mundial en diferentes aspectos, como por ejemplo la forma de comunicación entre las personas o la manera en que se hacen negocios. Desde el punto de vista del área de gestión de datos, la web puede verse como una gran base de datos donde podemos compartir, publicar, explorar y consultar datos, información y conocimiento1 . Desafortunadamente, la mayor parte del contenido actual en la web esta diseñado para ser comprendido por los seres humanos pero no para ser manipulado de manera automática por los programas computacionales [18]. Si bien existen herramientas computacionales para extraer y procesar contenido desde páginas web, en general estas herramientas no son capaces de comprender las relaciones y semántica del contenido. En este contexto, la Web Semántica propone representar el contenido de las páginas web en una forma más auto-procesable, además del desarrollo de técnicas inteligentes que aprovechen dicha representación [17]. La Web Semántica (Semantic Web) propone una extensión de la web actual en la cual la información presenta un significado bien definido, facilitando 1 Un dato es una cosa o hecho que existe en el mundo real o abstracto (ej., “rojo”). Información se refiere a una colección de datos cuyo significado esta determinado por sus relaciones, además de otros aspectos como el contexto (ej., “auto color rojo”). El Conocimiento es la información extra que podemos obtener o deducir al procesar y/o analizar la información existente. Estos tres conceptos han sido estudiados en el contexto de la Ciencia de la Información [33] 5 6 CAPÍTULO 1. INTRODUCCIÓN A LA WEB SEMÁNTICA Figura 1.1: Diseño de capas de la Web Semántica [17]. la cooperación entre las personas y los computadores [18]. Más que recuperar páginas web desde los servidores web, la visión de la web semántica se concentra en el significado de la información e implica una manera de procesarla automáticamente. El desarrollo de la web semántica fue planteado en base a la creación de diversos lenguajes estándar, los cuales se organizan en capas o niveles. La Figura 1.1 muestra el diseño de capas de la web semántica. A continuación describiremos brevemente las tecnologı́as asociadas a cada capa. • Unicode [11] es un estándar de codificación para documentos de texto que permite codificar la mayorı́a de los sistemas de escritura del mundo. • URI (Uniform Resource Identifier [14]) es un estándar para crear identificadores de recursos web a través de cadenas compactas de caracteres. El uso de URIs permite un sistema de identificación única y localización automática de recursos web. Una URL (Uniform Resource Locator ) es un ejemplo popular de URI que identifica y referencia un recurso web, por ejemplo una página web. Por ejemplo, la URL http://socialdata.org/example#person1 puede ser usado para identificar a una persona en el dominio de datos de una red social. Adicionalmente, una IRI (Internationalized Resource Identifier [13]) es una generalización de una URI la cual extiende su sintaxis para permitir 7 un mayor número de identificadores. • XML (Extensible Markup Language [21]) es un formato de texto simple y flexible que permite escribir documentos semi-estructurados2 con un vocabulario definido por el usuario. XML se ha convertido en el formato estándar para serializar y compartir datos entre diferentes sistemas de información. Un archivo XML es muy similar a un archivo HTML en el sentido que su contenido se basa en el uso de etiquetas (ej., <head>), las cuales contienen atributos, otras etiquetas o datos. La diferencia principal es que los nombres de las etiquetas de un archivo XML son elegidas por el usuario (ej., <persona nombre="Luis">). • Los espacios de nombre XML (XML Namespaces [20]) definen una manera de calificar y agrupar los términos (etiquetas) empleados en un documento XML. Cada término es identificado por una URI, lo cual permite que el término sea único y universal en el contexto de la web. De esta manera, los espacios de nombre XML son usados para evitar ambigüedad entre documentos. Por ejemplo, si se define que el URI http: //socialdata.org/ es el espacio de nombres para los datos de una red social, entonces podremos usar la URI http://socialdata.org/amigo para identificar y referenciar al término que representa la relación de amistad entre dos personas. • RDF (Resource Description Framework [27]) es un modelo de datos estándar para describir recursos web. La noción de “describir” un recurso se refiere a declarar atributos (o propiedades) del recurso ası́ como sus relaciones con otros recursos. Por ejemplo, la expresión “Ross es amigo de Chandler“ se puede modelar y codificar en RDF de la siguiente forma: sn:persona1 sn:nombre "Ross" . sn:persona2 sn:nombre "Chandler" . sn:persona1 sn:amigo sn:persona2 . 2 Un documento semi-structurado contiene información que no sigue una estructura fija. En otras palabras, información del mismo tipo puede contener distinta estructura y/o datos. 8 CAPÍTULO 1. INTRODUCCIÓN A LA WEB SEMÁNTICA donde sn es una abreviatura (o prefijo) del espacio de nombres http: //socialdata.org/, por lo que sn:persona1 es equivalente a http: //socialdata.org/persona1. • RDF Schema (RDFS) [22] define un vocabulario estándar (es decir, un conjunto de términos con significado bien definido) que permiten describir clases de recursos y propiedades para un dominio de datos RDF. Además, RDF Schema permite definir relaciones de sub-clase y sub-propiedad. Por ejemplo, la declaración sn:pintor rdfs:subClassOf sn:artista . hace uso del término rdfs:subClassOf para establecer que la clase de los pintores es una sub-clase de la clase de los artistas. El vocabulario RDF Schema puede usarse para definir la estructura de dominio de datos RDF. • Una ontologı́a define un conjunto clases de entidades y relaciones, ası́ como distintos tipos de relaciones entre estas clases. RDF Schema es un lenguaje primitivo para describir ontologı́as. OWL (Web Ontology Language [12]) es una familia de lenguajes que permiten describir ontologı́as más complejas que RDF Schema. Por ejemplo, owl:intersectionOf es un término de OWL que permite declarar la intersección de dos clases de recursos. • La capa lógica (Logic layer) está pensada para ampliar las descripciones provistas por los lenguajes de ontologı́as. • La capa de la prueba (Proof layer) involucra los procesos deductivos ası́ como las representación y validación de pruebas formales sobre los lenguajes de las capas inferiores. • La capa de confianza (Trust layer) está vinculada a los estándares que aseguran que tanto los datos, la información y el conocimiento generado son confiables. La mayorı́a de los elementos de la web semántica han sido desarrollados como especificaciones formales (ej., XML, RDF and OWL), mientras que otros aún se encuentran en desarrollo. 9 Cabe mencionar que desde la estandarización de RDF se ha llevado a cabo mucha investigación en temas relacionados al desarrollo de sistemas para almacenamiento y consulta de datos RDF, denominados Triple Stores 3 . Inicialmente [28], la mayorı́a de estos sistemas estuvieron basados en almacenamiento en memoria primaria (RAM) o usando otros sistemas de gestión de bases de datos como back-end (ej. MySQL), y fueron usados principalmente con baja escala de datos. Con la introducción del concepto de base de datos RDF (RDF database), las técnicas de almacenamiento fueron mejoradas y los métodos de consulta optimizados. Los sistemas actuales implementan técnicas avanzadas como clustering o particionamiento vertical con el objetivo de mejorar la escalabilidad [30, 34]. Dentro de los RDF Store más conocidos y con mejores caracterı́sticas podemos mencionar OpenLink Virtuoso [10], AllegroGraph [2], OWLIM [4], Bigdata [3], Jena TDB [9], Jena SDB [6], 3store [1] y Sesame [7]. Por otra parte, la idea de una web semántica ha impulsado el desarrollo de diversos proyectos vinculados a la gestión de datos [26]. Por ejemplo, el término Datos Vinculados (Linked Data) se refiere a un conjunto de prácticas para publicar y conectar diversas fuentes de datos disponibles en la web [19, 5]. La adopción de estas prácticas en los últimos años, por un gran número de “proveedores de datos”, ha permitido que la web sea un espacio de datos global donde se mezclan información proveniente de diversos dominios, incluyendo personas, comunidades, compañı́as, gobiernos, academia, televisión, etc. [8]. En este sentido, la noción tradicional de una web de páginas HTML se transforma en una web de datos. La Web de Datos (Web of Data) es definida como una web de cosas en el mundo las cuales son descritas por los datos disponibles en la Web [19]. En este libro nos concentraremos en los aspectos fundamentales de las bases de datos RDF, en particular el modelo de datos RDF (Capı́tulo 2), el vocabulario RDF Schema (Capı́tulo 3), y el lenguaje de consulta SPARQL (Capı́tulo 4). 3 http://www.w3.org/wiki/LargeTripleStores 10 CAPÍTULO 1. INTRODUCCIÓN A LA WEB SEMÁNTICA Capı́tulo 2 RDF RDF (Resource Description Framework) es el modelo de datos estándar usado en la web semántica. Todos los datos de la web semántica se modelan usando el modelo RDF y todas las aplicaciones se desarrollan asumiendo este modelo. Actualmente existen muchas fuentes de datos RDF. En este capı́tulo usaremos como ejemplo algunos datos extraı́dos de DBpedia1 , la versión RDF de Wikipedia. El contenido de este capı́tulo puede complementarse con los siguientes recursos web: • Página Web de RDF.2 • La primera especificación de RDF publicada por la W3C (1999).3 • La especificación de RDF 1.1.4 • Tutorial de RDF (W3C Schools).5 • Especificación de N-Triples (N3).6 • Getting into RDF & Semantic Web using N3.7 1 http://dbpedia.org http://www.w3.org/RDF/ 3 http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/ 4 http://www.w3.org/TR/rdf11-concepts/ 5 http://www.w3schools.com/webservices/ws_rdf_intro.asp 6 http://www.w3.org/TR/2014/REC-n-triples-20140225/ 7 http://www.w3.org/2000/10/swap/Primer.html 2 11 12 CAPÍTULO 2. RDF • Especificación de RDF/XML.8 • RDF Translator - Herramienta web para validar y transformar archivos de datos RDF.9 • Apache Jena - Un framework abierto de libre uso para desarrollar aplicaciones para la web semántica.10 • Una introducción a RDF y Jena.11 2.1 El modelo de datos RDF El modelo de datos RDF se basa en la idea de describir recursos web de manera explı́cita. Informalmente, la descripción de un recurso consiste en declarar las propiedades del recurso (atributos o relaciones), las cuales vinculan al recurso con valores concretos u otros recursos. Por ejemplo, la expresión “La Mona Lisa es una pintura creada por el artista italiano de nombre Leonardo da Vinci” es una descripción en lenguaje natural que vincula al recurso “Mona Lisa” con el recurso “Leonardo da Vinci” a través de la relación “creador”, además de definir algunas propiedades de ellos como “tipo”, “nombre” y “lugar de nacimiento”. A continuación explicaremos como usar RDF para representar formalmente una descripción informal. Recursos. Un recurso (resource) puede ser definido como un objeto (o una “cosa”) que deseamos describir. Los recursos pueden ser personas, libros, páginas web, o cualquier otra cosa, real o abstracta. Cada recurso en RDF es identificado de manera única por un Identificador Uniforme de Recursos (URI). De esta manera, para hacer referencia a un recurso haremos uso del URI que lo identifica (aunque esto no necesariamente nos entrega acceso al recurso). Las URLs son un tipo especial de URIs empleados comúnmente en el contexto de RDF12 . Por ejemplo, las siguientes URLs son usadas en DBpedia para identificar a la pintura titulada “Mona Lisa” y a su autor, el pintor italiano “Leonardo da Vinci”, respectivamente: 8 http://www.w3.org/TR/rdf-syntax-grammar/ http://rdf-translator.appspot.com 10 http://jena.apache.org/index.html 11 http://jena.apache.org/tutorials/rdf\_api.html 12 En este texto usaremos los términos URI o URL de manera equivalente. 9 2.1. EL MODELO DE DATOS RDF 13 http://dbpedia.org/resource/Mona_Lisa http://dbpedia.org/resource/Leonardo_da_Vinci Adicionalmente, RDF permite el uso de recursos anónimos llamados nodos blancos. Un nodo blanco (blank node) es un tipo especial de recurso el cual no tiene un nombre intrı́nseco y suelen usarse para representar la existencia de algo. Un nodo blanco puede tener un identificador (node ID) el cual es válido únicamente dentro del contexto de un documento RDF. Dichos identificadores se suelen codificar como cadenas de la forma :bX donde X es reemplazado por un número. Propiedades. Una propiedad (property) se refiere a un atributo o una relación de un recurso. Un atributo consiste en una caracterı́stica propia de un recurso, la cual tiene un valor especı́fico (ej., un número o un texto). Una relación representa un vı́nculo del recurso con otro recurso. Por ejemplo, “nombre” y “fecha de nacimiento” son propiedades de una persona ya que estás asociadas a valores especı́ficos. Por otro lado, “autor” es una relación que vincula una obra con su creador. En RDF, las propiedades son consideradas tipos especiales de recursos, por lo tanto también se identifican usando URIs. Por ejemplo, los siguientes URIs son usados en BDpedia para identificar a las propiedades “tı́tulo” y “autor” respectivamente: http://dbpedia.org/property/title http://dbpedia.org/ontology/author Declaraciones (statements). Una descripción puede dividirse en varias expresiones atómicas denominadas declaraciones. Una declaración establece una afirmación precisa sobre alguna propiedad de un recurso. Por ejemplo, la expresión “El autor de la Mona Lisa es Leonardo da Vinci” es una declaración respecto a la propiedad “autor” del recurso “Mona Lisa”. En el modelo RDF, una declaración se representa usando una estructura especial denominada triple RDF. Un triple RDF (RDF triple) es una tupla de tres elementos: sujeto, predicado y objeto. El sujeto (subject) hace referencia al recurso que se esta describiendo, en nuestro ejemplo “Mona Lisa”. El predicado (predicate) hace referencia a la propiedad del sujeto que se está declarando, en este caso “autor”. Finalmente, el objeto (object) hace referencia al valor de la propiedad, en este caso “Leonardo da Vinci”. Por lo tanto, el triple resultante serı́a (informalmente): 14 CAPÍTULO 2. RDF “Mona Lisa” “autor” “Leonardo da Vinci” Codificación de RDF. Existen varias formas de codificar13 datos RDF en un archivo de texto plano (ver Sec. 2.2). Por ejemplo, si aplicamos el formato N3, el triple anterior se codificarı́a en un archivo de texto (con extension *.n3) de la siguiente manera: 1 2 3 <h t t p : / / dbpedia . o r g / r e s o u r c e / Mona Lisa> <h t t p : / / dbpedia . o r g / o n t o l o g y / author> <h t t p : / / dbpedia . o r g / r e s o u r c e / L e o n a r d o d a V i n c i > . Observe el uso de URIs para identificar al sujeto (lı́nea 1), al predicado (lı́nea 2) y al objeto (lı́nea 3) del triple RDF. Si bien un URI puede ser autodescriptivo, en el sentido que nos puede indicar el nombre del recurso (ej., “Leonardo da Vinci”) o algún otro atributo representativo, es mejor hacer uso de un triple especı́fico para esto. Por ejemplo, el siguiente triple hace explı́cito el tı́tulo de la Mona Lisa: 1 2 3 <h t t p : / / dbpedia . o r g / r e s o u r c e / Mona Lisa> <h t t p : / / dbpedia . o r g / p r o p e r t y / t i t l e > ”Mona L i s a ” . Observe que en este caso el objeto del triple es un valor especı́fico (una cadena de caracteres) que en RDF se denomina un literal. Un literal (RDF literal ) es un valor atómico (ej., número, cadena, o fecha) asociado a alguna propiedad de un recurso. Nótese que los triples que representan relaciones entre recursos siguen el patrón URI-URI-URI, mientras que los triples que representan atributos de un recurso tienen la forma URI-URI-Literal. Con la finalidad de facilitar la lectura de los datos, los formatos de codificación permiten una representación abreviada usando espacios de nombres y prefijos. Por ejemplo, la codificación de los dos triples anteriores se puede simplificar de la siguiente manera: 1 2 3 4 5 @ p r e f i x dbpedia : <h t t p : / / dbpedia . o r g / r e s o u r c e /> . @ p r e f i x dbpedia−owl : <h t t p : / / dbpedia . o r g / o n t o l o g y/> . @ p r e f i x dbpprop : <h t t p : / / dbpedia . o r g / p r o p e r t y > . dbpedia : Mona Lisa dbpedia−owl : a u t h o r dbpedia : L e o n a r d o d a V i n c i . dbpedia : Mona Lisa dbpprop : t i t l e ”Mona L i s a ” . 13 Un archivo con datos RDF, en cualquier formato, puede crearse usando un editor de texto plano tradicional como Notepad, TextEdit o Vi. 2.1. EL MODELO DE DATOS RDF 15 Figura 2.1: Ejemplo de grafo RDF. Los nodos ovalados representan recursos (URIs o nodos blancos), los nodos rectangulares representan literales (valores), y las aristas representan propiedades. Nótese el uso de prefijos para abreviar las URIs. Los términos dbpedia, dbpedia-owl y dbpprop se denominan prefijos, y permiten abreviar los URIs. Por ejemplo, el término dbpprop:title es equivalente al URI http://dbpedia.org/property/title. En la Sección 2.2 se explicará mejor el uso de prefijos. Representación gráfica de RDF. Finalmente, un conjunto de triples RDF puede representarse gráficamente como un grafo etiquetado donde los nodos representan recursos o valores y las aristas representan propiedades. La Figura 2.1 muestra un grafo RDF (RDF graph) que describe información sobre obras de arte y artistas, incluyendo los triples de nuestro ejemplo. No existe una forma estándar de representar grafos RDF gráficamente, por lo que usaremos el formato usado en la Figura 2.1. Es decir, usaremos nodos ovalados para representar recursos (URIs y nodos blancos), nodos rectangulares para representar literales, y las aristas representarán las propiedades. 16 CAPÍTULO 2. RDF 2.2 Formatos de codificación para RDF Junto al diseño del modelo RDF se trabajó en la definición de un formato estándar para codificar datos acorde con el modelo. Actualmente existen cinco formatos estándar para codificar datos RDF: RDF-XML14 , N-Triples (N3)15 , Turtle16 , N-Quads17 y TriG18 . En este documento usaremos el formato N3 debido a su sencillez y claridad. Considere la Figura 2.2, donde se muestra el contenido de un archivo en formato N3. Un documento N3 se inicia con cero o más declaraciones de prefijos (lı́neas 1-5). Un prefijo se declara con una expresión de la forma @prefix prefijo: <URI>. Como se mencionó anteriormente, los prefijos permiten abreviar las URIs con el fin de facilitar la legibilidad del documento. Por ejemplo, el término dbpedia:Michelangelo es la URI abreviada de <http://dbpedia.org/resource/Michelangelo>. Luego de los prefijos se declaran los triples RDF (lı́neas 7 a 27), uno por lı́nea. Cada declaración de triple sigue el formato sujeto predicado objeto, donde • un URI no abreviado deben ir entre signos menor y mayor (<URI>); • un URI abreviado debe seguir el formato prefijo:nombre; • un nodo blanco se codifica con : seguido de una serie de caracteres; y • los literales deben aparecen entre comillas. Nótese que cada declaración en N3, ya sea de prefijo o de triple RDF, debe terminar con un punto. No existe un conjunto de nombres de prefijos estándar. El uso de prefijos, ası́ como la elección de los nombres de los prefijos, es una decisión del creador de un documento N3. Por ejemplo, en lugar de usar el prefijo dbpedia podemos usar dp y el documento seguirá siendo válido. Sin embargo, en la práctica se suele reutilizar ciertos prefijos usados en fuentes de datos RDF relevantes, como es el caso de DBpedia. Ejemplo de esto, son los prefijos usados en el documento N3 de la Figura 2.2, donde: 14 http://www.w3.org/TR/2014/REC-rdf-syntax-grammar-20140225/ http://www.w3.org/TR/2014/REC-n-triples-20140225/ 16 http://www.w3.org/TR/2014/REC-turtle-20140225/ 17 http://www.w3.org/TR/2014/REC-n-quads-20140225/ 18 http://www.w3.org/TR/2014/REC-trig-20140225/ 15 2.2. FORMATOS DE CODIFICACIÓN PARA RDF 1 2 3 4 5 @prefix @prefix @prefix @prefix @prefix 17 r d f : <h t t p : / /www. w3 . o r g /1999/02/22 − r d f −syntax−ns#> . r d f s : <h t t p : / /www. w3 . o r g /2000/01/ r d f −schema#> . dbpedia : <h t t p : / / dbpedia . o r g / r e s o u r c e /> . dbpedia−owl : <h t t p : / / dbpedia . o r g / o n t o l o g y/> . dbpprop : <h t t p : / / dbpedia . o r g / p r o p e r t y/> . 6 7 8 9 dbpedia : L e o n a r d o d a V i n c i r d f : type dbpedia−owl : P a i n t e r . dbpedia : L e o n a r d o d a V i n c i dbpprop : name ” Leonardo da V i n c i ” . dbpedia : L e o n a r d o d a V i n c i dbpedia−owl : b i r t h P l a c e : b1 . 10 11 12 13 dbpedia : M i c h e l a n g e l o r d f : type dbpedia−owl : S c u l p t o r . dbpedia : M i c h e l a n g e l o dbpprop : name ” M i c h e l a n g e l o B u o n a r r o t i ” . dbpedia : M i c h e l a n g e l o dbpedia−owl : b i r t h P l a c e : b1 . 14 15 16 17 18 dbpedia : Mona dbpedia : Mona dbpedia : Mona dbpedia : Mona Lisa Lisa Lisa Lisa r d f : type dbpedia−owl : P a i n t i n g . dbpprop : t i t l e ”Mona L i s a ” . dbpedia−owl : a u t h o r dbpedia : L e o n a r d o d a V i n c i . dbpprop : type ” O i l on p o p l a r ” . 19 20 21 22 23 dbpedia : M a d o n n a o f dbpedia : M a d o n n a o f Stairs ” . dbpedia : M a d o n n a o f Michelangelo . dbpedia : M a d o n n a o f t h e S t a i r s r d f : type dbpedia−owl : S c u l p t u r e . t h e S t a i r s dbpprop : t i t l e ”Madonna o f t h e t h e S t a i r s dbpedia−owl : a u t h o r dbpedia : t h e S t a i r s dbpprop : type ” Marble ” . 24 25 26 27 : b1 r d f : type dbpedia−owl : P l a c e . : b1 dbpprop : commonName ” F l o r e n c e ” . : b1 dbpprop : c o u n t r y ” I t a l y ” . Figura 2.2: Ejemplo de datos RDF en formato N3. • rdf: referencia al espacio de nombres del modelo RDF;o • rdfs: referencia a los términos definidos por RDF Schema (ver Sección 3.1); • dbpedia: es usado para abreviar recursos de DBpedia; • dbpprop: es usado para abreviar propiedades de DBpedia. • dbpedia-owl: referencia a los términos definidos por el vocabulario OWL (ver Sección 3.3); y 18 CAPÍTULO 2. RDF En la Figura A.1 del Apéndice A se muestran los mismos datos de la Figura 2.2 pero en formato RDF/XML. 2.3 Fuentes de datos RDF Para terminar este capı́tulo, presentamos una lista de fuentes de datos RDF disponibles en la Web. Una lista más extensa puede consultarte en el sitio web del proyecto Linked Data19 . • DBPedia20 es la versión RDF de Wikipedia; • RKBExplorer21 permite acceder a información bibliográfica (artı́culos, autores, conferencias, y otros). • DBTune22 integrada diversos datos relacionados al mundo de la música. • Linked Movie Database23 contiene información sobre pelı́culas. • GeoNames24 contiene información geográfica sobre lugares. • LinkedGeoData25 contiene datos espaciales en RDF. • data-gov26 publica información del gobierno estadounidense en RDF. 19 http://linkeddata.org http://dbpedia.org 21 http://linkedmdb.org 22 http://dbtune.org 23 http://linkedmdb.org 24 http://www.geonames.org/ontology/documentation.html 25 http://linkedgeodata.org/About 26 http://data-gov.tw.rpi.edu/wiki 20 Capı́tulo 3 RDF Schema En el contexto general, una base de datos esta compuesta de un esquema y de una instancia. El esquema describe la estructura de los datos y la instancia se refiere a los datos en si. Por ejemplo, en una base de datos relacional el esquema se refiere a la estructura de las tablas que conforman la base de datos (es decir, el nombre y atributos de cada tabla), mientras que la instancia corresponde a las tuplas que conforman cada una de las tablas. En el contexto de una base de datos RDF, una instancia es un conjunto de grafos RDF, también llamado RDF Dataset. El esquema de la base de datos se describe usando un conjunto de términos definidos por RDF Schema. En este capı́tulo explicaremos dichos términos y mostraremos como diseñar un esquema de datos RDF. El contenido de este capı́tulo puede complementarse con los siguientes recursos web. • La especificación de RDF Schema publicada por la W3C.1 • Tutorial de RDF Schema (W3C Schools).2 • Página web de OWL 3 • La especificación de OWL publicada por la W3C.4 • Protege - un editor gráfico de esquemas RDF y ontologı́as OWL.5 1 http://www.w3.org/TR/rdf-schema/ http://www.w3schools.com/webservices/ws_rdf_schema.asp 3 http://www.w3.org/2001/sw/wiki/OWL 4 http://www.w3.org/TR/owl-features/ 5 http://protege.stanford.edu 2 19 20 CAPÍTULO 3. RDF SCHEMA 3.1 Vocabulario de RDF Schema En el contexto de RDF, un vocabulario se refiere a un conjunto de términos, donde cada término tiene un significado especı́fico. RDF Schema define un vocabulario que permite describir clases de recursos y sus propiedades para un dominio de aplicación particular. El vocabulario de RDF Schema puede dividirse en seis grupos de términos: clases estándar de recursos y propiedades, términos para describir relaciones entre clases de recursos y propiedades, términos para describir contenedores, términos para describir colecciones, términos para descripción explı́cita de triples (reification), y términos utilitarios. La lista completa de términos puede consultarse en la especificación W3C de RDF Schema. A continuación describiremos los términos más importantes de RDF Schema tomando como ejemplo el archivo mostrado en la Figura 3.1, el cual corresponde al documento instancia de la Figura 2.2. Siguiendo la filosofı́a RDF, un esquema RDF se describe a través de un conjunto de triples RDF, por lo tanto un esquema RDF también se puede codificar en un archivo, en el caso de la Figura 3.1 usando el formato N3. Antes que todo, debemos recordar que los prefijos rdf y rdfs serán usados en este documento como abreviación de los URIs http://www.w3.org/1999/02/22-rdf-syntax-ns\# y http://www.w3.org/2000/01/rdf-schema#, los cuales hacen referencia a los espacios de nombre de RDF y RDF Schema, respectivamente. Un esquema RDF contiene básicamente la descripción de las clases de recursos y propiedades que se usaran en un documento instancia RDF. Por ejemplo, el esquema de la Figura 3.1 define las clases de recursos Artist, Painter, Sculptor, Artwork, Painting y Sculpture, ası́ como las clases de propiedades author, birthPlace y dbprop:type. Nótese que la propiedad dbprop:type es distinta de la propiedad rdf:type ya que sus prefijos son distintos, y en consecuencia sus URIs. De hecho esta diferencia está parcialmente descrita en el esquema RDF: dbprop:type relaciona un Artwork con un Literal, mientras que rdf:type es una propiedad definida por RDF Schema para asociar un recurso con una clase. 3.1. VOCABULARIO DE RDF SCHEMA 21 Observe además que la descripción de un tipo de propiedad se basa en definir las clases de recursos que pueden ser vinculados por la propiedad. Especı́ficamente, el dominio corresponde a la clase de recursos que actuarán como sujeto de la propiedad, y el rango corresponde a la clase de recursos que actuarán como objeto de la propiedad. A continuación describiremos el significado de los términos usados en nuestro ejemplo. Clases estándar de recursos y propiedades. RDF Schema define el siguiente conjunto de clases estándar para RDF. • rdfs:Resource: la clase de los recursos (cualquier cosa). • rdfs:Literal: la clase de los literales (valores atómicos). • rdf:XMLLiteral: la clase de los valores XML literal. • rdfs:Class: la clase de todas las clases. • rdf:Property: la clase de las propiedades RDF. • rdfs:Datatype: la clase de los tipos de datos RDF. • rdf:Statement: la clase de las declaraciones o afirmaciones RDF. • rdfs:Container:la clase de las colecciones. • rdf:Bag: la clase de las colecciones de recursos no ordenados. Es una subclase de rdfs:Container. • rdf:Seq: la clase de las colecciones de recursos ordenados. Es una subclase de rdfs:Container. • rdf:Alt: la clase de las colecciones de recursos alternativos. Es una subclase de rdfs:Container. • rdfs:ContainerMembershipProperty: la clase de las propiedades que permiten describir los elementos de una colección (rdf: 1, rdf: 2,. . . ). • rdf:List: La clase de la listas RDF. 22 CAPÍTULO 3. RDF SCHEMA Términos para describir relaciones entre clases. RDF Schema define un conjunto de propiedades estándar para describir nuevas clases y/o propiedades personalizadas. Para cada término incluimos su declaración como triple RDF, su significado, y un ejemplo. • rdfs:Resource rdf:type rdfs:Class El sujeto es un recurso que es una instancia de una clase (objeto). Ej. dbpedia-owl:Artist rdf:type rdfs:Class • rdfs:Class rdfs:subClassOf rdfs:Class El sujeto es subclase del objeto. Ej. dbpedia-owl:Painter rdfs:subClassOf dbpedia-owl:Artist • rdf:Property rdfs:subPropertyOf rdf:Property El sujeto es una sub-propiedad del objeto Ej. dbpedia-owl:paints rdfs:subPropertyOf dbpedia-owl:creates • rdf:Property rdfs:domain rdfs:Class Indica que el objeto es el dominio de una propiedad (sujeto) Ej. dbpedia-owl:creates rdfs:domain dbpedia-owl:Artwork • rdf:Property rdfs:range rdfs:Class Indica que el objeto es el rango de una propiedad (sujeto) Ej. dbpedia-owl:creates rdfs:range dbpedia-owl:Artist • rdfs:Resource rdfs:label rdfs:Literal Un nombre comprensible (objeto) para un recurso (sujeto) Ej. dbpedia-owl:Artwork rdfs:label "A work of art" • rdfs:Resource rdfs:comment rdfs:Literal Una descripción (objeto) para un recurso (sujeto) Ej. dbpedia-owl:Artwork rdfs:comment "Obras de artes" Observe que RDF Schema permite declarar la noción de herencia a través de los términos rdfs:subClassOf y rdf:subPropertyOf. En el ejemplo de la Figura 3.2, se declara que Painter y Sculptor son subclases de Artist, y de manera similar, Painting y Sculpture son subclases de Artwork. Esta relaciones de subclase permiten inferir ciertas propiedades que no están declaradas explı́citamente. Por ejemplo, la declaración de author indica que es una propiedad de las obras de arte. Sin embargo, y gracias a la relación 3.1. VOCABULARIO DE RDF SCHEMA 23 de subclase entre Artwork y Painting, podemos asumir que una pintura es una obra de arte, por lo tanto inferir que la propiedad author también es una propiedad de una pintura (lo mismo aplica para las esculturas). La definición de sub-propiedades es un complemento interesante de la relación de subclase. Por ejemplo, en la Figura 3.2 se muestra una extensión del esquema RDF mostrado en el Figura 3.1, donde se agregan triples que hacen uso del término subPropertyOf. En este caso, se indica que paints y sculpts son sub-propiedades de creates. Tomando en cuenta las relaciones de sub-clase y sub-propiedad podemos asumir que pintar es similar a crear, por lo tanto inferir que un pintor es un artista y una pintura es una obra de arte. La posibilidad de inferir información adicional debido al significado de algunos términos es una caracterı́stica muy potente que puede implementarse sobre el modelo RDF. Actualmente existen algunas herramientas que explotan esta caracterı́stica, pero nosotros no la tratamos en este texto. Términos para describir contenedores. Un contenedor RDF es un recurso que es usado para representar una colección. RDF Scheme permite definir tres tipos de contenedores: rdf:Bag permite describir una lista de valores (permitiendo duplicados) sin orden especı́fico; rdf:Seq describe una lista ordenada de elementos (posiblemente repetidos); y rdf:Alt describe una lista de valores alternativos. A continuación se presenta un ejemplo de declaración y uso del contenedor rdf:Bag. 1 2 3 4 5 ex : ... ex : ex : ex : a r t i s t s r d f : type r d f : Bag . a r t i s t s r d f : 1 dbpedia : L e o n a r d o d a V i n c i . a r t i s t s r d f : 2 dbpedia : M i c h e l a n g e l o . a r t i s t s r d f : 3 dbpedia : D o n a t e l l o . Términos para para descripción explı́cita de triples. Los términos rdf:Statement, rdf:subject, rdf:predicate y rdf:object son definidos en RDF Schema para describir de manera explı́cita un triple RDF. La noción de una descripción explı́cita se denomina reification. Por ejemplo, el triple 1 dbpedia : Mona Lisa dbpedia−owl : a u t h o r dbpedia : L e o n a r d o d a V i n c i . puede describirse de manera explı́cita a través de los siguientes triples 1 2 : b2 r d f : type r d f : Statement . : b2 r d f : s u b j e c t dbpedia : Mona Lisa . 24 3 4 CAPÍTULO 3. RDF SCHEMA : b2 r d f : p r e d i c a t e dbpedia−owl : a u t h o r . : b2 r d f : o b j e c t dbpedia : L e o n a r d o d a V i n c i . Términos utilitarios. Adicionalmente, RDF Schema define los siguientes términos de uso general. • rdfs:Resource rdfs:seeAlso rdfs:Resource Información adicional sobre el sujeto. • rdfs:Resource rdfs:isDefinedBy rdfs:Resource Indica la definición del sujeto. • rdfs:Resource rdf:value rdfs:Resource Indica el valor de un recurso. 3.2 Visualización de un esquema RDF Actualmente no existe una forma estándar de representar gráficamente un esquema RDF. Si bien un esquema RDF puede dibujarse como un grafo RDF, dicha representación es complicada de realizar y entender. Por ejemplo, la representación de una clase de propiedad como un nodo el cual tiene una arista para indicar el dominio y otra para el rango no serı́a muy fácil de entender. Sin embargo, la forma de grafo estándar es fundamental para poder representar la relación de sub-propiedad. En la Figura 3.3 se muestra una representación gráfica simplificada para el esquema RDF presentado en la Figura 3.1. Observe que los nodos ovalados son usados para representar clases de recursos y los nodos rectangulares representan etiquetas (labels) de las clases. Las clases de propiedades se representan simplemente como aristas entre clases de recursos, sin indicar explı́citamente el dominio y rango. Nótese que esta forma de representar una propiedad es más fácil de visualizar, sin embargo no soporta la noción de sub-propiedad ya que tendrı́amos que incluir aristas entre aristas (lo cual no es natural en un grafo tradicional). 3.3 Ontology Web Language (OWL) En el contexto general, una ontologı́a (ontology) se refiere a la descripción exacta de entidades y sus relaciones. En el contexto de la web semántica, 3.3. ONTOLOGY WEB LANGUAGE (OWL) 25 una ontologı́a consiste en una descripción exacta de clases de recursos, clases de propiedades, y las relaciones entre dichas clases. OWL define un vocabulario más completo y complejo que RDF Schema para describir ontologı́as de un área o dominio de conocimiento particular. Por ejemplo, OWL permite definir relaciones entre clases (ej., unión), ası́ como restricciones y caracterı́sticas de propiedades (ej., simetrı́a). OWL se divide en tres sub-lenguajes: OWL Lite, que permite definir clasificación jerárquica y restricciones simples; OWL DL, que entrega mayor expresividad pero manteniendo completitud computacional (decibilidad) y resolubilidad (tiempo finito y razonable); y OWL Full, que entrega la máxima expresividad sin garantı́as computacionales. En esta sección presentaremos un breve introducción de OWL Lite. En adición a las clase estándar definidas por RDF Schema, OWL Lite define tres clases principales6 , owl:Class, owl:Thing y owl:Nothing. A continuación describiremos algunos términos interesantes de OWL Lite. • owl:class owl:equivalentClass owl:class Indica que dos clases son equivalentes. Ej. ex:Trabajador owl:equivalentClass ex:Empleado • rdf:Property owl:equivalentProperty rdf:Property Indica que dos propiedad son equivalentes. Ej. ex:trabaja para owl:equivalentProperty ex:labora para • rdfs:Resource owl:sameAs rdfs:Resource Indica que dos recursos representan a la misma entidad. Ej. dbpedia:Leonardo da Vinci owl:sameAs fbase:Leonardo da Vinci • rdfs:Resource owl:differentFrom rdfs:Resource Indica que dos recursos son distintos. • rdf:Property owl:inverseOf rdf:Property Define que una propiedad es la inversa de otra propiedad. Si se define que p1 es la propiedad inversa de p2 significa que, si existe un triple (x, p2 , y), entonces se puede inferir el triple (y, p1 , x). Ej. dbpedia-owl:author of owl:inverseOf dbpedia-owl:author 6 El espacio de nombres de OWL es http://www.w3.org/2002/07/owl# 26 CAPÍTULO 3. RDF SCHEMA • rdf:Property rdf:type owl:TransitiveProperty Indica que una propiedad es transitiva. Si p es una propiedad transitiva significa que, si se tienen los triples (x, p, y) e (y, p, z), entonces se puede inferir el triple (x, p, z). Ej. ex:descendiente rdf:type owl:TransitiveProperty Actualmente existen muchas ontologı́as OWL que modelan diversos dominios de aplicación para RDF, dentro de las cuales podemos mencionar7 : • FOAF8 permite describir personas, sus vı́nculos, y las cosas que hacen o crean. • Generations9 es una ontologı́a para relaciones familiares. • Countries10 contiene la lista de paı́ses en OWL. • Geographic Information Metadata11 es una ontologı́a para información geográfica. 7 La lista completa se encuentra disponible en http://protegewiki.stanford.edu/ wiki/Protege_Ontology_Library 8 http://xmlns.com/foaf/spec/index.rdf 9 http://protege.cim3.net/file/pub/ontologies/generations/generations. owl 10 http://www.bpiresearch.com/BPMO/2004/03/03/cdl/Countries 11 http://loki.cae.drexel.edu/~wbs/ontology/ 3.3. ONTOLOGY WEB LANGUAGE (OWL) 1 2 3 4 5 @prefix @prefix @prefix @prefix @prefix r d f : <h t t p : / /www. w3 . o r g /1999/02/22 − r d f −syntax−ns#> . r d f s : <h t t p : / /www. w3 . o r g /2000/01/ r d f −schema#> . dbpedia : <h t t p : / / dbpedia . o r g / r e s o u r c e /> . dbpedia−owl : <h t t p : / / dbpedia . o r g / o n t o l o g y/> . dbpprop : <h t t p : / / dbpedia . o r g / p r o p e r t y/> . 6 7 8 dbpedia−owl : A r t i s t r d f : type r d f s : C l a s s . dbpedia−owl : A r t i s t r d f s : l a b e l ” A r t i s t ” . 9 10 11 12 dbpedia−owl : P a i n t e r r d f : type r d f s : C l a s s . dbpedia−owl : P a i n t e r r d f s : l a b e l ” P a i n t e r ” . dbpedia−owl : P a i n t e r r d f s : s u b C l a s s O f dbpedia−owl : A r t i s t . 13 14 15 16 dbpedia−owl : S c u l p t o r r d f : type r d f s : C l a s s . dbpedia−owl : S c u l p t o r r d f s : l a b e l ” S c u l p t o r ” . dbpedia−owl : S c u l p t o r r d f s : s u b C l a s s O f dbpedia−owl : A r t i s t . 17 18 19 dbpedia−owl : Artwork r d f : type r d f s : C l a s s . dbpedia−owl : Artwork r d f s : l a b e l ”A work o f a r t ” . 20 21 22 23 dbpedia−owl : P a i n t i n g r d f : type r d f s : C l a s s . dbpedia−owl : P a i n t i n g r d f s : l a b e l ” P a i n t i n g ” . dbpedia−owl : P a i n t i n g r d f s : s u b C l a s s O f dbpedia−owl : Artwork . 24 25 26 27 dbpedia−owl : S c u l p t u r e r d f : type r d f s : C l a s s . dbpedia−owl : S c u l p t u r e r d f s : l a b e l ” S c u l p t u r e ” . dbpedia−owl : S c u l p t u r e r d f s : s u b C l a s s O f dbpedia−owl : Artwork . 28 29 30 31 32 dbpedia−owl : a u t h o r dbpedia−owl : a u t h o r dbpedia−owl : a u t h o r dbpedia−owl : a u t h o r r d f : type r d f : P r o p e r t y . r d f s : l a b e l ” author of ” . r d f s : domain dbpedia−owl : Artwork . r d f s : r a n g e dbpedia−owl : A r t i s t . 33 34 35 36 37 dbpprop : type dbpprop : type dbpprop : type dbpprop : type r d f : type r d f : P r o p e r t y . r d f s : l a b e l ” type ” . r d f s : domain dbpedia−owl : Artwork . r d f s : range r d f s : L i t e r a l . 38 39 40 41 42 dbpedia−owl : b i r t h P l a c e dbpedia−owl : b i r t h P l a c e dbpedia−owl : b i r t h P l a c e dbpedia−owl : b i r t h P l a c e r d f : type r d f : P r o p e r t y . rdfs : label ” place of birth ” . r d f s : domain dbpedia−owl : A r t i s t . r d f s : r a n g e dbpedia−owl : P l a c e . Figura 3.1: Ejemplo de esquema RDF en formato N3. 27 28 1 2 3 4 5 @prefix @prefix @prefix @prefix @prefix CAPÍTULO 3. RDF SCHEMA r d f : <h t t p : / /www. w3 . o r g /1999/02/22 − r d f −syntax−ns#> . r d f s : <h t t p : / /www. w3 . o r g /2000/01/ r d f −schema#> . dbpedia : <h t t p : / / dbpedia . o r g / r e s o u r c e /> . dbpedia−owl : <h t t p : / / dbpedia . o r g / o n t o l o g y/> . dbpprop : <h t t p : / / dbpedia . o r g / p r o p e r t y/> . 6 7 8 . . . . . . 9 10 11 12 13 dbpedia−owl : dbpedia−owl : dbpedia−owl : dbpedia−owl : creates creates creates creates r d f : type r d f : P r o p e r t y . rdfs : label ” creator of ” . r d f s : domain dbpedia−owl : A r t i s t . r d f s : r a n g e dbpedia−owl : Artwork . 14 15 16 17 18 19 dbpedia−owl : p a i n t s dbpedia−owl : p a i n t s dbpedia−owl : p a i n t s dbpedia−owl : p a i n t s dbpedia−owl : p a i n t s r d f : type r d f : P r o p e r t y . rdfs : label ” paints ” . r d f s : domain dbpedia−owl : P a i n t e r . r d f s : r a n g e dbpedia−owl : P a i n t i n g . r d f s : subPropertyOf dbpedia−owl : c r e a t e s . 20 21 22 23 24 25 dbpedia−owl : dbpedia−owl : dbpedia−owl : dbpedia−owl : dbpedia−owl : sculpts sculpts sculpts sculpts sculpts r d f : type r d f : P r o p e r t y . rdfs : label ” paints ” . r d f s : domain dbpedia−owl : S c u l p t o r . r d f s : r a n g e dbpedia−owl : S c u l p t u r e . r d f s : subPropertyOf dbpedia−owl : c r e a t e s . Figura 3.2: Ejemplo extendido de esquema RDF. 3.3. ONTOLOGY WEB LANGUAGE (OWL) 29 Figura 3.3: Representación gráfica de un esquema RDF. Los nodos ovalados representan clases de recursos, los nodos rectangulares representan etiquetas (labels) de las clases, y las aristas representan propiedades de las clases. 30 CAPÍTULO 3. RDF SCHEMA Capı́tulo 4 SPARQL Distintos lenguajes de consulta han sido propuestos para RDF, la mayorı́a de ellos basados en lenguajes de clásicos como SQL y OQL, y otros orientados a XML como XPath y XQuery. En la literatura podemos encontrar varios trabajos que revisan estos lenguajes [29, 31, 24, 16]. Actualmente, SPARQL es el lenguaje de consulta estándar para datos RDF. La especificación W3C de la primera versión de SPARQL, la cual denominaremos SPARQL 1.0 [32], fue publicada en Enero de 2008. Esta versión define los elementos fundamentales del lenguaje, principalmente la noción de patrones de grafo. En Marzo de 2013, se presentó SPARQL 1.1 [25] cuya especificación define operadores que permiten consultas más complejas como agregación, sub-consultas y consultas de caminos. En este capı́tulo presentaremos las principales caracterı́sticas de ambas versiones de SPARQL. El contenido de este capı́tulo puede complementarse con los siguientes recursos web: • La especificación de SPARQL 1.0 publicada por la W3C.1 • La especificación de SPARQL 1.1 publicada por la W3C.2 • Una introducción al uso de SPARQL (Search RDF data with SPARQL – by Phil McCarthy).3 • A Brief Tutorial on SPARQL.4 1 http://www.w3.org/TR/rdf-sparql-query/ http://www.w3.org/TR/sparql11-query/ 3 http://www.ibm.com/developerworks/xml/library/j-sparql/ 4 http://jena.apache.org/tutorials/sparql.html 2 31 32 CAPÍTULO 4. SPARQL • ARQ - A SPARQL Processor for Jena.5 • TDB - The Jena RDF Store.6 • Fuseki - Serving RDF data over HTTP.7 4.1 Introducción a SPARQL En esta sección describiremos los elementos fundamentales que definen el lenguaje SPARQL. Esto incluye una introducción básica a su sintaxis y semántica. SPARQL asume cuatro dominios de datos: (1) el dominio de los recursos RDF, el cual contiene entidades cada una identificada por un URI; (2) el dominio de los literales RDF, el cual incluye valores atómicos simples (ej. cadenas, números, fechas, etc.); (3) el dominio de los nodos blancos RDF, el cual contiene recursos anónimos (este dominio no es muy usado en la práctica); (4) el dominio de las variables, cada una de las cuales tiene un nombre de la forma ?V , y puede tener asignado un valor de algunos de los otros tres dominios. Como se describió en la sección relativa al modelo RDF, una colección de triples RDF es llamado un grafo RDF. Adicionalmente, SPARQL considera la noción de dataset RDF. Un dataset RDF es un conjunto de grafos representado como {G0 , hu1 , G1 i, . . . , hun , Gn i}, donde cada Gi es una grafo RDF y cada ui es un URI. G0 es llamado el grafo por defecto (default graph). Cada par hui , Gi i es llamado un grafo con nombre (named graph), donde ui es el nombre del grafo Gi . Cada dataset satisface que: (i) siempre contiene un grafo por defecto (el cual puede estar vacı́o); (ii) puede no tener grafos con nombre; (iii) cada nombre ui es distinto; y (iv) los grafos no tienen nodos blancos en común. Finalmente, si un grafo Gi es usado para consultar D entonces este se denomina el grafo activo de D. SPARQL se basa en buscar coincidencias de patrones de grafo (graph pattern matching) sobre múltiples fuentes de datos RDF. Por ejemplo, la expresión de la Figura 4.1 es una consulta SPARQL que retorna los nombres de personas cuya edad es mayor a 18. A continuación analizaremos cada uno de los elementos de la expresión. 5 http://jena.apache.org/documentation/query/index.html http://jena.apache.org/documentation/tdb/index.html 7 http://jena.apache.org/documentation/serving_data/index.html 6 4.1. INTRODUCCIÓN A SPARQL 1 2 3 4 5 6 7 33 PREFIX sn : <h t t p : / /www. s o c i a l n e t w o r k . o r g/> SELECT ?N FROM <h t t p : / /www. s o c i a l n e t w o r k . o r g / s n d a t a . r d f > WHERE { { ?X sn : type sn : Person . ?X sn : name ?N } . { ?X sn : age ?A . FILTER ( ?A > 1 8 ) } } ORDER BY ?N Figura 4.1: Ejemplo de consulta SPARQL. Una consulta SPARQL se representa sintácticamente por un bloque consistente de: • cero o más declaraciones de prefijos (ej. PREFIX . . . ), • un tipo de consulta (query form) (ej. SELECT . . . ), • cero o más clausulas de dataset (dataset clauses)(ej. FROM . . . ), • una clausula WHERE que contiene un patrón de grafo, y • modificadores de solución (solution modifiers)(ej. ORDER BY . . . ). Informalmente, la evaluación de una consulta SPARQL sigue el siguiente procedimiento: (1) construir un dataset RDF basado en las clausulas de dataset; (2) evaluar el patrón de grafo sobre el dataset, lo cual resulta en un multi-conjunto de soluciones (decimos multi-conjunto ya que se pueden tener soluciones repetidas); (3) organizar las soluciones según los modificadores de solución; y (4) construir el resultado final de acuerdo al tipo de consulta. Una declaración de prefijo permite asignar un prefijo (ej. sn) a un URI (ej. http://www.socialnetwork.org/data/). Nótese, que el uso de prefijos solo permite simplificar la representación de URIs en los otros elementos de la consulta (ej. sn:name). El conjunto de clausulas de dataset permiten definir el dataset que será usado en la consulta. Existen dos tipos de clausulas de dataset: FROM <uri> que permite agregar el grafo identificado por <uri> al grafo por defecto del dataset; y FROM NAMED <uri> que permite agregar un grafo con nombre huri, Gi al dataset. En nuestro ejemplo, la consulta construye un dataset cuyo grafo por defecto está compuesto del grafo RDF identificado por y disponible en http://www.socialnetwork.org/sndata.rdf. El contenido de este grafo se muestra en la Figura 4.2. 34 1 CAPÍTULO 4. SPARQL @ p r e f i x sn : <h t t p : / /www. s o c i a l n e t w o r k . o r g/> . 2 3 4 5 6 7 8 9 sn : p e r s o n 1 sn : p e r s o n 1 sn : p e r s o n 1 sn : p e r s o n 1 sn : p e r s o n 1 sn : p e r s o n 1 sn : p e r s o n 1 sn : type sn : Person . sn : name ” Ross ” . sn : age ”34” . sn : f r i e n d sn : p e r s o n 2 . sn : f r i e n d sn : p e r s o n 3 . sn : f r i e n d sn : p e r s o n 4 . sn : marriedWith sn : p e r s o n 2 . sn : p e r s o n 2 sn : p e r s o n 2 sn : p e r s o n 2 sn : p e r s o n 2 sn : p e r s o n 2 sn : p e r s o n 2 sn : p e r s o n 2 sn : type sn : Person . sn : name ” Rachel ” . sn : age ”26” . sn : f r i e n d sn : p e r s o n 1 . sn : f r i e n d sn : p e r s o n 3 . sn : f r i e n d sn : p e r s o n 4 . sn : marriedWith sn : p e r s o n 1 . sn : p e r s o n 3 sn : p e r s o n 3 sn : p e r s o n 3 sn : p e r s o n 3 sn : p e r s o n 3 sn : p e r s o n 3 sn : type sn : Person . sn : name ” Joey ” . sn : age ”30” . sn : f r i e n d sn : p e r s o n 1 . sn : f r i e n d sn : p e r s o n 2 . sn : f r i e n d sn : p e r s o n 4 . sn : p e r s o n 4 sn : p e r s o n 4 sn : p e r s o n 4 sn : p e r s o n 4 sn : p e r s o n 4 sn : p e r s o n 4 sn : type sn : Person . sn : name ” Phoebe ” . sn : age ”26” . sn : f r i e n d sn : p e r s o n 1 . sn : f r i e n d sn : p e r s o n 2 . sn : f r i e n d sn : p e r s o n 3 . 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Figura 4.2: Datos RDF sobre una red social. Los datos están codificados en formato N-Triple. El principal elemento en una consulta SPARQL es la expresión de patrón de grafo contenida en la clausula WHERE. La forma más básica de patrón de grafo es una patrón de triple (triple pattern), el cual extiende la definición de triple RDF permitiendo variables en el sujeto, predicato u objeto. Por ejemplo, {?X sn:name ?N} es un patrón de triple con variables ?X y ?N. Patrones de grafo más complejos pueden definirse a través de una combinación de patrones de triple y operadores especiales (estos serán descritos en la siguiente 4.1. INTRODUCCIÓN A SPARQL 35 sección). En nuestro ejemplo, la expresión { ?X sn:type sn:Person . ?X sn:name ?N } es un patrón complejo donde el punto denota el operador de reunión o join. La evaluación de un patrón de grafo se basa en solution mappings. Un solution mapping es una función µ que asocia un conjunto de variables a un conjunto de términos RDF (URIs, literales y nodos blancos). De esta manera, se usa µ(?N ) = “Ross” para denotar que la variable ?N está asignada con el literal “Ross”. De aquı́ en adelante, un solution mapping lo llamaremos simplemente “solución”. La evaluación de un patrón de triple T en un grafo G retorna un multiconjunto de soluciones, denotado Ω. Cada solución µ en Ω significa que en el grafo G existe un triple T 0 el cual se crea al reemplazar (o instanciar) las variables de T con los valores definidos por la solución µ. Por ejemplo, si consideramos que T es el patrón de triple {?X sn:name ?N}, tendremos que la evaluación de T sobre el grafo de la consulta retornará un multi-conjunto de cuatro soluciones µ1 , µ2 , µ3 y µ4 , donde: • µ1 (?X) = sn:person1 y µ1 (?N ) = “Ross” • µ2 (?X) = sn:person2 y µ2 (?N ) = “Rachel” • µ3 (?X) = sn:person3 y µ3 (?N ) = “Joey” • µ4 (?X) = sn:person4 y µ4 (?N ) = “Phoebe” El multi-conjunto de soluciones anterior también puede ser representado de forma tabular como se muestra en la Tabla 4.1. Más adelante mostraremos que la evaluación de una consulta SPARQL puede generar soluciones duplicadas, es decir que se puede tener un multi-conjunto de soluciones. SPARQL define varios modificadores de solución, los cuales pueden ser usados de manera opcional para restringir y organizar el multi-conjunto de soluciones obtenido luego de evaluar el patrón de grafo. En nuestro ejemplo, el operador ORDER BY permite ordenar los resultados de manera ascendente en base a los valores de la variable ?N , es decir por los nombres de personas. Finalmente, el tipo de consulta permite definir el formato de salida final de la consulta. SPARQL define cuatro tipos de consulta: • SELECT <W> permite proyectar las variables del multi-conjunto de soluciones en base al conjunto de variables <W>. Para retornar todas las variables se puede usar la abreviatura SELECT *. 36 CAPÍTULO 4. SPARQL ?X sn:person1 sn:person2 sn:person3 sn:person4 ?N “Ross” “Rachel” “Joey” “Phoebe” Tabla 4.1: Ejemplo de solución en formato de tabla para una consulta SPARQL. Cada fila representa un resultado (result set), el cual asigna un valor a cada una de las variables del encabezado de la tabla. • CONSTRUCT <T> permite retornar un grafo RDF el cual se construye en base a la plantilla de grafo (graph template) <T>, la cual consiste en un conjunto de patrones de triple los cuales son instanciados con los valores del multi-conjunto de soluciones. • ASK retorna un valor verdadero (true) si la consulta tiene al menos una solución, y falso (false) en caso contrario. • DESCRIBE <W> permite retornar una grafo RDF, el cual se construye con información disponible en el dataset sobre los recursos <W> identificados en la solución. Habiendo explicado los elementos básicos de una consulta SPARQL, en las siguientes secciones explicaremos otros elementos del lenguaje. 4.2 SPARQL 1.0 En la sección anterior hemos descrito los elementos principales del lenguaje SPARQL, en particular la noción de patrones de triple y su forma de evaluación. En esta sección describiremos otros tipos de patrones de grafo los cuales, combinados con otras caracterı́sticas del lenguaje, permiten expresar consultas más complejas. 4.2.1 Patrones de grafo complejos Un patrón de grafo complejo es una colección de patrones de triple conectados por operadores especiales. La evaluación de patrones complejos se basa en la noción de compatibilidad de soluciones. Decimos que dos soluciones µ1 y µ2 4.2. SPARQL 1.0 37 son compatibles, si para toda variable ?X en común entre ambas soluciones, se satisface que µ1 (?X) = µ2 (?X). Es decir, ambas soluciones asignan los mismos valores a las variables compartidas. Esto implica que dos soluciones compatibles pueden unirse en una nueva solución. Si asumimos que P1 y P2 son patrones de triple, estos pueden se combinados para generar los siguientes patrones de grafo complejos: • el patrón de reunión (o join), denotado {P1 . soluciones compatibles entre P1 y P2; P2}, permite unir las • el patrón de unión, denotado {P1 UNION P2}, permite unir los multiconjuntos de soluciones para P1 y P2. • el patrón opcional, denotado {P1 OPTIONAL P2}, permite retornar los resultados de P1 y P2 que son compatibles (los retorna unidos), ası́ como los resultados de P1 que no son compatibles con todo resultado de P2. SPARQL soporta composición de patrones, por lo tanto la definición anterior permite que P1 y P2 sean a su vez patrones de grafo complejos. A continuación presentamos ejemplos de estos patrones. Consulta: retornar el nombre de las personas que tienen un amigo llamado “Joey” (reunión de patrones). 1 2 3 4 5 PREFIX sn : <h t t p : / /www. s o c i a l n e t w o r k . o r g/> SELECT ?N FROM <h t t p : / /www. s o c i a l n e t w o r k . o r g / s n d a t a . r d f > WHERE { ?X sn : type sn : Person . ?X sn : name ?N . ?X sn : f r i e n d ?Y . ?Y sn : name ” Joey ” } ?N “Ross” Solución: “Rachel” “Joey” “Phoebe” Observe que en esta consulta los patrones de triple no se encuentran agrupados de dos en dos según la definición de patrón de reunión. Esta es una facilidad sintáctica que entrega SPARQL para expresar un conjunto de patrones usando el operador de reunión. Los operadores UNION y OPTIONAL si requieren del uso de llaves para separar los patrones a operar. 38 CAPÍTULO 4. SPARQL Consulta: retornar los nombres de los amigos de “Ross” más el nombre de su esposa (unión de patrones). 1 2 3 4 5 6 7 8 PREFIX sn : <h t t p : / /www. s o c i a l n e t w o r k . o r g/> SELECT ?N FROM <h t t p : / /www. s o c i a l n e t w o r k . o r g / s n d a t a . r d f > WHERE { { ?X sn : name ” Ross ” . ?X sn : f r i e n d ?F . ?F sn : name ?N } UNION { ?X sn : name ” Ross ” . ?X sn : marriedWith ?Y . ?Y sn : name ?N } } ?N “Rachel” Solución: “Joey” “Phoebe” “Rachel” Observe que esta consulta retorna el literal “Rachel” dos veces (por ser amiga de “Ross” y por ser su esposa), es decir tenemos explı́citamente un multi-conjunto de soluciones con valores repetidos. La creación de valores repetidos es una caracterı́stica propia del operador UNION. Consulta: retornar los nombres de personas, y en caso de ser casadas también retornar el nombre de su esposo/a (patrón opcional). 1 2 3 4 5 6 7 8 PREFIX sn : <h t t p : / /www. s o c i a l n e t w o r k . o r g/> SELECT ?N ?M FROM <h t t p : / /www. s o c i a l n e t w o r k . o r g / s n d a t a . r d f > WHERE { { ?X sn : type sn : Person . ?X sn : name ?N } OPTIONAL { ?X sn : marriedWith ?Y . ?Y sn : name ?M } } ?N “Ross” Solución: “Rachel” “Joey” “Phoebe” ?M “Rachel” “Ross” Observe que en esta consulta, debido a la definición de patrón opcional, la variable ?M no tiene valores para “Joey” y “Phoebe”. En este caso, se dice que ?M tiene valores indefinidos o unbounded (esto es equivalente al valor 4.2. SPARQL 1.0 39 NULL en SQL). La generación de valores indefinidos es una caracterı́stica del operador OPTIONAL. 4.2.2 Patrones con condiciones de filtro Los resultados de un patrón pueden filtrarse en base a condiciones especiales denominadas condiciones de filtro. SPARQL define condiciones de filtro simples y complejas. Las condiciones de filtro simples consisten en operadores matemáticos o funciones predefinidas aplicadas sobre variables de un patrón. Por ejemplo, ?A > 18, ?A = ?B y isIRI(?A) son condiciones simples. Para conocer la lista completa de condiciones simples se recomienda consultar la especificación de SPARQL. Las condiciones de filtro complejas permiten combinar condiciones simples usando los operadores booleanos AND, OR y NOT representados por los sı́mbolos &&, || y ! respectivamente. Ejemplos de condiciones complejas son (?A > 10 && ?A < 20) y !(isLiteral(?B). Si P es un patrón de grafo y C una condición de filtro, entonces la expresión { P FILTER C } se denomina patrón de filtro. A continuación presentamos un ejemplo. Consulta: retornar las personas cuya edad está entre 25 y 30. 1 2 3 4 PREFIX sn : <h t t p : / /www. s o c i a l n e t w o r k . o r g/> SELECT ?X FROM <h t t p : / /www. s o c i a l n e t w o r k . o r g / s n d a t a . r d f > WHERE { { ?X sn : age ?A } FILTER ( ?A > 25 && ?A < 3 0 ) } [] ?X Solución: <http://www.socialnetwork.org/data/person2> <http://www.socialnetwork.org/data/person4> Observe que en esta consulta, el resultado contiene los URIs que identifican a las personas que satisfacen la condición de filtro (estas son “Rachel” y “Phoebe”). 4.2.3 Modificadores de solución SPARQL 1.0 define diversos operadores para restringir y organizar el multiconjunto final de soluciones. Entre los principales modificadores de solución tenemos: 40 CAPÍTULO 4. SPARQL • ORDER BY, que permite poner las soluciones en un orden especı́fico. Este operador se acompaña de los operadores ASC() o DESC() para indicar un orden ascendente o descendente respectivamente. • DISTINCT, que permite eliminar las soluciones repetidas. Este operador acompaña al operador SELECT. • OFFSET, que permite definir un punto de inicio (en el multi-conjunto de soluciones) desde donde se extraerán las soluciones finales. • LIMIT, que permite restringir el número de soluciones. Consulta: aplicación de modificadores de solución. 1 2 3 4 5 6 7 PREFIX sn : <h t t p : / /www. s o c i a l n e t w o r k . o r g/> SELECT DISTINCT ?N FROM <h t t p : / /www. s o c i a l n e t w o r k . o r g / s n d a t a . r d f > WHERE { ?X sn : name ?N } ORDER BY ASC( ?N) OFFSET 3 LIMIT 2 ?N Solución: “Rachel” “Ross” Observe que luego de aplicar el operador ORDER BY, la lista de resultados contiene los literales en el orden “Joey”, “Phoebe”, “Rachel”, “Ross”. Luego, los operadores OFFSET y LIMIT permiten obtener las ultimas dos soluciones. Nótese además, que el operador DISTINCT no tiene ningún efecto en esta consulta ya que no se tienen resultados repetidos. 4.2.4 Patrones para consultar grafos con nombre Cuando el dataset de la consulta contiene grafos con nombre (o named graphs), es necesario usar el operador GRAPH para acceder a ellos. Existen dos formas de usar este operador: • { <uri> GRAPH { P } }, que permite evaluar el patrón P en el grafo con nombre <uri>. • { ?G GRAPH { P } }, que permite evaluar el patrón P en todos los grafos con nombre. Si una solución fué obtenida de un named graph, entonces dicha solución contendrá el URI del grafo en la variable ?G. 4.3. SPARQL 1.1 41 Consulta: consultar los nombres de grafos existentes en un dataset. 1 2 3 4 5 6 7 8 PREFIX sn : <h t t p : / /www. s o c i a l n e t w o r k . o r g/> SELECT DISTINCT ?G FROM <h t t p : / /www. s o c i a l n e t w o r k . o r g / s n d a t a . r d f > FROM NAMED <h t t p : / /www. s o c i a l n e t w o r k . o r g / g r a f o 1 . r d f > FROM NAMED <h t t p : / /www. s o c i a l n e t w o r k . o r g / g r a f o 1 . r d f > ... FROM NAMED <h t t p : / /www. s o c i a l n e t w o r k . o r g / grafoN . r d f > WHERE { GRAPH ?G { ?S ?P ?O } } ?G <http://www.socialnetwork.org/data/grafo1.rdf> Solución: <http://www.socialnetwork.org/data/grafo2.rdf> ... <http://www.socialnetwork.org/data/grafoN.rdf> Observe que el grafo <http://www.socialnetwork.org/sndata.rdf> no es parte del resultado ya que este forma parte del grafo por defecto. Además, nótese el uso del operador DISTINCT para eliminar los valores repetidos en ?G. 4.3 SPARQL 1.1 SPARQL 1.1 extiende SPARQL 1.0 con diversas funcionalidades avanzadas, entre las más importantes podemos mencionar: operadores explı́citos para expresar la negación de patrones de grafo, operadores para expresar consultas de caminos, operadores agregados, sub-consultas y consultas federadas. A continuación describiremos estas extensiones. 4.3.1 Operadores agregados Un operador agregado permite calcular ciertas operaciones sobre grupos de soluciones obtenidas luego de evaluar el patrón de grafo. SPARQL 1.1 define los siguientes operadores agregados: • COUNT, permite contar los valores en una lista de resultados. • SUM, permite sumar los valores de una lista de resultados. • MIN, permite obtener el valor mı́nimo de una lista de resultados. 42 CAPÍTULO 4. SPARQL • MAX, permite obtener el valor máximo de una lista de resultados. • AVG, permite calcular el valor promedio de una lista de resultados. • GROUP CONCAT, permite concatenar los valores de una lista de resultados. • SAMPLE, permite extraer un valor arbitrario de una lista de resultados. Por ejemplo, la siguiente consulta permite obtener la edad máxima en la red social presentada en la Figura 4.2: 1 2 3 4 PREFIX sn : <h t t p : / /www. s o c i a l n e t w o r k . o r g/> SELECT MAX( ?A) AS ?MaxAge FROM <h t t p : / /www. s o c i a l n e t w o r k . o r g / s n d a t a . r d f > WHERE { ?X sn : age ?A } Solución: ?MaxAge 34 Observe que un operador agregado, en este caso MAX, es parte de la clausula SELECT. Adicionalmente, podemos usar el operador AS para crear la variable ?MaxAge, la cual contendrá el valor calculado por el operador agregado. En el ejemplo anterior, el operador agregado se calcula sobre el multiconjunto de soluciones del patrón. Si deseamos, podemos usar el operador GROUP BY para agrupar los resultados y aplicar el operador agregado a cada grupo por separado. Por ejemplo, la siguiente consulta nos permite calcular la edad promedio de los amigos de cada persona (por separado): 1 2 3 4 5 6 7 PREFIX sn : <h t t p : / /www. s o c i a l n e t w o r k . o r g/> SELECT ?N, (AVG( ?A) AS ?AvgAge ) FROM <h t t p : / /www. s o c i a l n e t w o r k . o r g / s n d a t a . r d f > WHERE { ?X sn : name ?N . ?X sn : f r i e n d ?Y . ?Y sn : age ?A } GROUP BY ?X ?N “Ross” Solución: “Rachel” “Joey” “Phoebe” ?AvgAge 27.3 30 28.6 30 4.3. SPARQL 1.1 43 En complemento a los operadores agregados descritos anteriormente, se tiene el operador HAVING para aplicar condiciones en las soluciones agrupadas. Por ejemplo, al final de la consulta anterior podemos agregar la linea HAVING( AVG(?A) > 29 ) lo cual permite filtrar los resultados a aquellas personas cuyos amigos tienen una edad promedio mayor a 25 años, es decir “Rachel” y “Proebe”. 4.3.2 Sub-consultas El concepto de sub-consulta implica la posibilidad de insertar una consulta dentro de otra, lo cual resulta en un jerarquı́a o “anidamiento” de consultas. Si tenemos que Q es una consulta que contiene a otra consulta Q0 , entonces diremos que Q es la consulta externa (outer query) y Q0 es la consulta interna (inner query). Adicionalmente, si Q y Q0 tienen variables en común, podremos decir que existen variables correlacionadas, y por lo tanto Q y Q0 son consultas correlacionadas. Las variables correlacionadas pueden influir en la evaluación de la consulta interna, pero esto dependerá de la definición dada por el lenguaje (como veremos a continuación). SPARQL 1.1 permite dos tipos de sub-consultas las cuales describiremos a continuación. Sub-Select. Este tipo de sub-consulta consiste en la inserción de una consulta SELECT en cualquier lugar de otra consulta donde sea posible colocar un patrón de grafo. Por ejemplo, la siguiente expresión define una subconsulta sub-select para obtener la lista de personas más jóvenes en nuestra red social de ejemplo. 1 2 3 4 5 6 7 8 9 10 PREFIX sn : <h t t p : / /www. s o c i a l n e t w o r k . o r g/> SELECT ?N ?MinAge FROM <h t t p : / /www. s o c i a l n e t w o r k . o r g / s n d a t a . r d f > WHERE { ?X sn : name ?N . ?X sn : age ?AgeX . { SELECT MIN( ? AgeY) AS ?MinAge WHERE { ?Y sn : age ?AgeY } } . FILTER ( ? AgeX = ?MinAge ) } ?N Solución: “Rachel” “Phoebe” ?MinAge 26 26 44 CAPÍTULO 4. SPARQL Las sub-consultas permiten expresar consultas no soportadas por SPARQL 1.0. Por ejemplo, una sub-consulta permite usar los resultados obtenidos de la consulta interna, en particular cuando se incluyen operadores agregados. Observe que la consulta interna no incluye prefijos ni clausulas de dataset. Además, solo las variables proyectadas por la clausula SELECT de la consulta interna serán visibles fuera de esta, es decir, no existe correlación de variables entre la consulta interna y la consulta externa. EXISTS. El operador EXISTS permite verificar si un patrón de grafo retorna resultados o no. Dados dos patrones de grafo, P1 y P2, la expresión { P1 FILTER EXISTS P2 } retorna las soluciones de P1 tal que la evaluación de P2 tiene al menos una solución. Si los patrones P1 y P2 no tienen variables en común, es decir no están correlacionados, entonces pueden evaluarse de manera separada. En caso contrario, el patrón se evalúa según el siguiente procedimiento: (i) se evalúa el patrón P1; (ii) por cada resultado µ1 de P1: (a) se evalúa P2, reemplazando previamente las variables correlacionadas de P2 con los valores contenidos en µ1 ; (b) si la evaluación de P2 tiene al menos un resultado, entonces el resultado µ1 forma parte de la solución. Por ejemplo, la siguiente expresión permite obtener los nombres de personas que poseen la misma edad de otras personas. 1 2 3 4 5 6 7 8 PREFIX sn : <h t t p : / /www. s o c i a l n e t w o r k . o r g/> SELECT ?N FROM <h t t p : / /www. s o c i a l n e t w o r k . o r g / s n d a t a . r d f > WHERE { ?X sn : name ?N . ?X sn : age ?AgeX FILTER EXISTS { ?Y sn : age ?AgeY . FILTER ( ( ?Y != ?X) && ( ? AgeY = ?AgeX) ) } } ?N Solución: “Rachel” “Phoebe” Observe que las variables ?X y ?AgeX son variables correlacionadas, por lo tanto ambas variable influyen en la evaluación de la consulta interna, como se explicó anteriormente. La expresión anterior es equivalente a la siguiente consulta “plana” (es decir, sin sub-consultas): 1 SELECT DISTINCT ?N 4.3. SPARQL 1.1 2 3 4 5 6 45 FROM <h t t p : / /www. s o c i a l n e t w o r k . o r g / s n d a t a . r d f > WHERE { ?X sn : name ?N . ?X sn : age ?AgeX ?Y sn : age ?AgeY . FILTER ( ( ?Y != ?X) && ( ? AgeY = ?AgeX) ) } Observe que el operador DISTINCT es necesario para eliminar las soluciones repetidas. Es decir, la sub-consulta nos está permitiendo simular el operador DISTINCT. 4.3.3 Negación de patrones de grafo La especificación de SPARQL 1.0 menciona ([32], Sección 11.4.1) que la negación de patrones de grafo puede ser simulada a través de la combinación de un patrón opcional y una condición de filtro del tipo !bound(). Por ejemplo, la siguiente consulta nos permite obtener los nombres de personas que no son casadas. 1 2 3 4 5 6 7 PREFIX sn : <h t t p : / /www. s o c i a l n e t w o r k . o r g/> SELECT ?N FROM <h t t p : / /www. s o c i a l n e t w o r k . o r g / s n d a t a . r d f > WHERE { { ?X sn : name ?N . OPTIONAL { ?X sn : marriedWith ?Y } } . FILTER ( ! bound ( ?Y) ) } ?N Solución: “Joey” “Phoebe” Observe que la condición !bound(?Y) permite filtrar los resultados del patrón opcional cuya variable ?Y es unbounded, es decir, aquellas personas ?X que no tienen un valor para la propiedad sn:marriedWith. Esta forma implı́cita de expresar la negación en SPARQL tiene algunos problemas los cuales son estudiados en [15]. En SPARQL 1.1, la negación puede se expresada de manera explı́cita a través de los operadores MINUS y NOT EXISTS. Si asumimos que P1 y P2 son patrones de grafo, SPARQL 1.1 permite las siguientes expresiones: • { P1 MINUS P2 }, retorna las soluciones de P1 que no son compatibles con todas las soluciones de P2. 46 CAPÍTULO 4. SPARQL • { P1 FILTER NOT EXISTS P2 }, retorna las soluciones de P1 tal que la evaluación de P2 tiene al menos una solución. En caso de existir variables correlacionadas se sigue el procedimiento explicado para el operador EXISTS. De hecho, la condición NOT EXISTS P2 es equivalente a !(EXISTS P2). Por ejemplo, la consulta anterior (nombres de personas que no son casadas) puede expresarse a través de cualquiera de las siguientes expresiones: 1 2 3 4 5 6 1 2 3 4 5 6 7 PREFIX sn : <h t t p : / /www. s o c i a l n e t w o r k . o r g/> SELECT ?N FROM <h t t p : / /www. s o c i a l n e t w o r k . o r g / s n d a t a . r d f > WHERE { { ?X sn : name ?N } MINUS { ?X sn : marriedWith ?Y } } PREFIX sn : <h t t p : / /www. s o c i a l n e t w o r k . o r g/> SELECT ?N FROM <h t t p : / /www. s o c i a l n e t w o r k . o r g / s n d a t a . r d f > WHERE { ?X sn : name ?N . FILTER NOT EXISTS { ?X sn : marriedWith ?Y } } A pesar de parecer iguales, los operadores MINUS y NOT EXISTS pueden entregar resultados distintos, debido principalmente a la noción de compatibilidad de soluciones. Se recomienda revisar la especificación de SPARQL 1.1 ([32], Sección 8.3) para conocer en detalle estas diferencias. 4.3.4 Patrones de camino SPARQL 1.1 introduce la noción de property paths como una caracterı́stica para expresar consultas de caminos, es decir encontrar una ruta entre dos nodos en un grafo RDF. Un property path es una expresión de la forma {subject regex object } donde subject es el nodo origen del camino (URI o variable), object es el nodo destino del camino (URI, literal o variable), y regex es una expresión regular la cual representa un patrón de camino. La expresión regular más básica es un URI el cual referencia a una propiedad. Asumiendo que P y Q son expresiones regulares, se pueden producir recursivamente las siguientes expresiones regulares complejas: 4.3. SPARQL 1.1 47 • (P / Q) , selecciona la concatenación de caminos (P y Q). • (P | Q) , selecciona la alternancia de caminos (P o Q). • !(P) , selecciona la negación de caminos (no P). • (P)? , selecciona caminos que contienen P, cero o una vez. • (P)* , selecciona caminos que contienen P, cero o más veces. • (P)+ , selecciona caminos que contienen P, una o más veces. De esta manera, podemos incluir expresiones regulares complejas del tipo !(P / ( Q | R ) ). La evaluación de una consulta de camino intentará encontrar una conexión entre el nodo fuente y el nodo destino, de acuerdo con el patrón definido por la expresión regular (es decir, siguiendo propiedades especı́ficas, en un orden especı́fico, un número determinado de veces). Por ejemplo, la siguiente expresión retorna los nodos ?X que son “alcanzables” desde el nodo sn:Person1, siguiendo la propiedad sn:friend, una o más veces (+). 1 2 3 4 PREFIX sn : <h t t p : / /www. s o c i a l n e t w o r k . o r g/> SELECT ?X FROM <h t t p : / /www. s o c i a l n e t w o r k . o r g / s n d a t a . r d f > WHERE { sn : Person1 sn : f r i e n d+ ?X } La evaluación de una consulta de caminos no considera la generación de soluciones duplicadas. 4.3.5 Creación de valores Una caracterı́stica simple pero muy útil agregada en SPARQL 1.1. es la creación de valores. Esta caracterı́stica, denominada assigment, consiste en la creación de variables y valores de manera directa, sin necesidad de consultar los datos. De esta manera, las variables y valores creados pueden ser usados en la consulta y retornados en el resultado. Existen tres formas de crear soluciones en SPARQL 1.1: • BIND permite que un valor sea asignado a una variable desde un patrón de grafo o una expresión de camino. Por ejemplo, la siguiente expresión permite duplicar los valores cargados en una variable: { ?X :price ?V BIND (( ?V * 2 ) AS ?W)}} 48 CAPÍTULO 4. SPARQL • VALUES permite crear una secuencia de soluciones, la cual debe ser combinada con los resultados de otro patrón de grafo a través del operador de reunión. Por ejemplo, la siguiente expresión permite crear una secuencia de tres soluciones conteniendo dos variables: { VALUES (?X ?Y)(a 1)(b 2)(c 3) } • El operador AS permite agregar valores en la clausula SELECT, en particular al combinarse con operadores agregados. Por ejemplo: SELECT (MAX(?A) AS ?MaxAge) 4.3.6 Consultas federadas El término consulta federada (o búsqueda federada) está relacionado a la capacidad de consultar múltiples fuentes de información. Dicha capacidad es soportada en el contexto de RDF a través de los denominados SPARQL endpoints. Un SPARQL endpoint es un servicio Web que permite, a través de un protocolo de comunicación definido para SPARQL [23], ejecutar consultas en una base de datos RDF de manera remota. La identificación y el acceso a un SPARQL endpoint se realiza a través de una URL. Por ejemplo, la URL http://dbpedia.org/sparql permite acceder a los datos de DBPedia. SPARQL 1.1 permite la ejecución de consultas federadas a través del operador SERVICE. Este operador permite indicar explı́citamente que un fragmento de una consulta debe ejecutarse en un SPARQL endpoint. Por ejemplo, la siguiente consulta nos retorna todos los triples RDF relacionados a “Alan Turing” que están disponibles en DBPedia. 1 2 3 4 5 SELECT ?p ? o WHERE { SERVICE <h t t p : / / dbpedia . o r g / s p a r q l > { <h t t p : / / dbpedia . o r g / r e s o u r c e / Alan Turing Year > ?p ? o } } Observe que el operador SERVICE recibe dos parámetros: la URL que identifica al SPARQL endpoint; y una patrón de grafo que se ejecutará en el endpoint. Al momento de ejecutar esta consulta, el motor de evaluación del cliente envı́a la consulta al SPARQL endpoint, este ejecuta la consulta y retorna los resultados. La transferencia de la consulta y los resultados entre el cliente y SPARQL endpoint se realiza a través del protocolo de comunicación de SPARQL, el cual está basado en el protocolo HTTP. Aunque no se usa 4.3. SPARQL 1.1 49 en el ejemplo anterior, los resultados retornados por el SPARQL endpoint pueden ser combinados con el resto de la consulta. Tenga en cuenta que el operador SERVICE retornará todas las variables del patrón asociado. En el caso que la consulta retorne muchos datos, lo anterior puede resultar en un pésimo tiempo de respuesta. Una manera de evitar este problema puede ser el uso de sub-selects para filtrar los resultados retornados por el operador SERVICE (siempre y cuando el SPARQL endpoint soporte sub-consultas de SPARQL 1.1). A continuación presentamos un ejemplo de esta idea. 1 2 3 4 5 6 7 SELECT ∗ WHERE { SERVICE <h t t p : / / dbpedia . o r g / s p a r q l > { SELECT ? o WHERE { <h t t p : / / dbpedia . o r g / r e s o u r c e / Alan Turing Year > ?p ? o } } } 4.3.7 Sobre el poder expresivo de SPARQL La principal caracterı́stica de SPARQL es que permite expresar patrones de grafo complejos a través de una colección de patrones de triple cuyas soluciones pueden ser combinadas y restringidas usando diversos operadores. En [15], se demostró que SPARQL 1.0 tiene el mismo poder expresivo que el álgebra relacional bajo semántica de conjuntos (set semantics), es decir ambos lenguajes pueden expresar los mismos tipos de consulta siempre y cuando no se consideren resultados duplicados. Por otra parte, SPARQL es muy similar a SQL ya que operan bajo semántica de multi-conjuntos (bag semantics). Sin embargo, SPARQL es menos expresivo ya que no permite expresar la diferencia de multi-conjuntos la cual es soportada en ANSI SQL a través del operador DISTINCT ALL. A pesar de lo anterior, SPARQL 1.1 soporta operadores agregados y consultas de caminos (property paths). Esta última caracterı́stica, es soportada parcialmente por SQL a través de sub-consultas recursivas. 50 CAPÍTULO 4. SPARQL Bibliografı́a [1] 3store. http://threestore.sourceforge.net/. [2] AllegroGraph. http://www.franz.com/agraph/allegrograph/. [3] Bigdata. http://www.bigdata.com/. [4] BigOWLIM. http://www.ontotext.com/owlim/. [5] Linked data - connect http://linkeddata.org/. distributed data across the web. [6] SDB - A SPARQL Database for Jena. http://openjena.org/SDB/. [7] Sesame. http://threestore.sourceforge.net/. [8] SWEO Community Project - Linking Open Data sets. http://esw.w3.org/TaskForces/CommunityProjects/LinkingOpenData/DataSets. [9] TDB A SPARQL http://jena.sourceforge.net/TDB/. Database for Jena. [10] Virtuoso Universal Server. http://virtuoso.openlinksw.com/. [11] The Unicode Consortium. http://www.unicode.org/, 1991. [12] RxPath Specification Proposal. http://rx4rdf.liminalzone.org/RxPathSpec, 2004. [13] Internationalized Resource http://tools.ietf.org/html/rfc3987, 2005. Identifiers [14] RFC 3986 Uniform Resource http://tools.ietf.org/html/rfc3986, 2005. 51 Identifier (IRIs). (URI). 52 BIBLIOGRAFÍA [15] R. Angles and C. Gutierrez. The Expressive Power of SPARQL. In Proceedings of the 7th International Semantic Web Conference (ISWC), number 5318 in LNCS, pages 114–129, 2008. [16] Renzo Angles and Claudio Gutierrez. Querying RDF Data from a Graph Database Perspective. In Proceedings of the 2nd European Semantic Web Conference (ESWC), number 3532 in LNCS, pages 346–360, 2005. [17] Grigoris Antoniou and Frank van Harmelen. A Semantic Web Primer. The MIT Press, 2004. [18] Tim Berners-Lee, James Hendler, and Ora Lassila. The Semantic Web. Scientific American, May 2001. [19] Christian Bizer, Tom Heath, and Tim Berners-Lee. Linked data - the story so far. International Journal on Semantic Web and Information Systems (IJSWIS), 5(3):1–22, 2009. [20] Tim Bray, Dave Hollander, Andrew Layman, and Richard Tobin. Namespaces in XML 1.1, W3C Recommendation. http://www.w3.org/TR/2004/REC-177-names11-20040204/, 4 February 2001. [21] Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, and Francois Yergeau. Extensible Markup Language (XML) 1.0 (Third Edition), W3C Recommendation. http://www.w3.org/TR/2004/REC-17720040204/, 04 February 2004. [22] Dan Brickley and R.V.Guha. RDF Vocabulary Description Language 1.0: RDF Schema. W3C Recommendation 10 February 2004. http://www.w3.org/TR/2004/REC-rdf-schema-20040210/. [23] L. Feigenbaum, G. T. Williams, K. G. Clark, and E. Torres. Sparql 1.1 protocol. w3c recommendation. http://www.w3.org/TR/2013/RECsparql11-protocol-20130321/, March 21 2013. [24] Peter Haase, Jeen Broekstra, Andreas Eberhart, and Raphael Volz. A Comparison of RDF Query Languages. In Proceedings of the 3rd International Semantic Web Conference (ISWC), number 3298 in Lecture Notes in Computer Science, page 502. Springer-Verlag, November 7-11 2004. BIBLIOGRAFÍA 53 [25] S. Harris and A. Seaborne. SPARQL 1.1 Query Language - W3C Recommendation. http://www.w3.org/TR/2013/REC-sparql11-query20130321/, March 21 2013. [26] M. Hausenblas, W. Halb, Y. Raimond, and T. Heath. What is the Size of the Semantic Web? In Proc. of the International Conference on Semantic Systems (I-Semantics), 2008. [27] Graham Klyne and Jeremy Carroll. Resource Description Framework (RDF) Concepts and Abstract Syntax. http://www.w3.org/TR/2004/REC-115-concepts-20040210/, February 2004. [28] Ryan Lee. Scalability report on triple store applications. Technical report, Simile, July 2004. [29] Aimilia Magkanaraki, Grigoris Karvounarakis, Ta Tuan Anh, Vassilis Christophides, and Dimitris Plexousakis. Ontology Storage and Querying. Technical Report 308, Institute of Computer Science of the Foundation for Research and Technology - Hellas (ICS-FORTH), April 2002. [30] Michael Schmidt and Thomas Hornung and Norbert Küchlin and Georg Lausen and Christoph Pinkel. An Experimental Comparison of RDF Data Management Approaches in a SPARQL Benchmark Scenario. In Proc. of the 7th International Semantic Web Conference (ISWC), pages 82–97. Springer-Verlag, 2008. [31] Asunción Gómez Pérez. OntoWeb - A survey on ontology tools. Technical Report Deliverable 1.3, OntoWeb, Ontology-based information exchange for knowledge management and electronic commerce, May 2002. [32] Eric Prud’hommeaux and Andy Seaborne. SPARQL Query Language for RDF. W3C Recommendation. http://www.w3.org/TR/2008/REC115-sparql-query-20080115/, January 15 2008. [33] Jennifer Rowley. The wisdom hierarchy: representations of the dikw hierarchy. Journal of Information Science, 33(2):163–180, 2007. [34] W3C. Large Triple Stores. http://esw.w3.org/LargeTripleStores. 54 BIBLIOGRAFÍA Apéndice A Archivos ejemplo 55 56 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 APÉNDICE A. ARCHIVOS EJEMPLO <?xml v e r s i o n =”1.0” e n c o d i n g=”UTF−8”?> <r d f :RDF xmlns : dbpedia−owl=”h t t p : / / dbpedia . o r g / o n t o l o g y /” xmlns : dbpprop=”h t t p : / / dbpedia . o r g / p r o p e r t y /” xmlns : r d f =”h t t p : / /www. w3 . o r g /1999/02/22 − r d f −syntax−ns#” > <r d f : D e s c r i p t i o n r d f : nodeID=” f 9 6 2 2 3 1 d b 6 0 e d 4 5 c 2 b f c 4 9 8 3 d 0 3 f c 2 8 d 4 b 1”> <r d f : type r d f : r e s o u r c e =”h t t p : / / dbpedia . o r g / o n t o l o g y / P l a c e ”/> <dbpprop : country>I t a l y </dbpprop : country> <dbpprop : commonName>F l o r e n c e </dbpprop : commonName> </ r d f : D e s c r i p t i o n > <r d f : D e s c r i p t i o n r d f : about=”h t t p : / / dbpedia . o r g / r e s o u r c e / Mona Lisa”> <dbpprop : t i t l e >Mona L i s a </dbpprop : t i t l e > <r d f : type r d f : r e s o u r c e =”h t t p : / / dbpedia . o r g / o n t o l o g y / P a i n t i n g ”/> <dbpedia−owl : a u t h o r r d f : r e s o u r c e =”h t t p : / / dbpedia . o r g / r e s o u r c e / L e o n a r d o d a V i n c i ”/> <dbpprop : type>O i l on p o p l a r </dbpprop : type> </ r d f : D e s c r i p t i o n > <r d f : D e s c r i p t i o n r d f : about=”h t t p : / / dbpedia . o r g / r e s o u r c e / M a d o n n a o f t h e S t a i r s ”> <dbpedia−owl : a u t h o r r d f : r e s o u r c e =”h t t p : / / dbpedia . o r g / r e s o u r c e / M i c h e l a n g e l o ”/> <dbpprop : t i t l e >Madonna o f t h e S t a i r s </dbpprop : t i t l e > <r d f : type r d f : r e s o u r c e =”h t t p : / / dbpedia . o r g / o n t o l o g y / S c u l p t u r e ”/> <dbpprop : type>Marble </dbpprop : type> </ r d f : D e s c r i p t i o n > <r d f : D e s c r i p t i o n r d f : about=”h t t p : / / dbpedia . o r g / r e s o u r c e / M i c h e l a n g e l o”> <r d f : type r d f : r e s o u r c e =”h t t p : / / dbpedia . o r g / o n t o l o g y / S c u l p t o r ”/> <dbpedia−owl : b i r t h P l a c e r d f : nodeID=” f 9 6 2 2 3 1 d b 6 0 e d 4 5 c 2 b f c 4 9 8 3 d 0 3 f c 2 8 d 4 b 1 ”/> <dbpprop : name>M i c h e l a n g e l o B u o n a r r o t i </dbpprop : name> </ r d f : D e s c r i p t i o n > <r d f : D e s c r i p t i o n r d f : about=”h t t p : / / dbpedia . o r g / r e s o u r c e / L e o n a r d o d a V i n c i”> <r d f : type r d f : r e s o u r c e =”h t t p : / / dbpedia . o r g / o n t o l o g y / P a i n t e r ”/> <dbpprop : name>Leonardo da Vinci </dbpprop : name> <dbpedia−owl : b i r t h P l a c e r d f : nodeID=” f 9 6 2 2 3 1 d b 6 0 e d 4 5 c 2 b f c 4 9 8 3 d 0 3 f c 2 8 d 4 b 1 ”/> </ r d f : D e s c r i p t i o n > </ r d f :RDF> Figura A.1: Ejemplo de datos RDF en formato RDF/XML.