Introducción a las bases de datos RDF

Introducción a las bases de datos RDF
Renzo Angles
[email protected]
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.