Este documento es una traducción al castellano de la nota del grupo de trabajo del W3C "SKOS Simple Knowledge Organization System Primer", publicada el 18 de agosto de 2009. La presente traducción se concluyó el 20 de noviembre de 2009.
La versión original en inglés es el único documento válido y se
encuentra en: http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/
Puede ver la última versión del documento en inglés en: http://www.w3.org/TR/rdf-sparql-query/
Se ha tratado de respetar al máximo el contenido del documento original en inglés, adaptando la expresión al español para ayudar a una mejor comprensión del mismo. Por tanto, esta traducción puede contener errores, en ningún caso achacables a sus autores originales. Cualquier sugerencia de corrección, duda o comentario sobre la misma puede realizarse dirigiéndose a alguno de sus autores: Juan Antonio Pastor Sánchez y Pedro Manuel Díaz Ortuño.
Consulte la sección de erratas de este documento, en la que se pueden incluir algunas correciones normativas.
Vea también la sección de traducciones.
Copyright © 2006-2007 W3C® (MIT, ERCIM, Keio), Todos los derechos reservados. Son aplicables las normas del W3C sobre obligaciones, marcas registradas y uso de documentos.
RDF es un formato de datos para grafos dirigidos y etiquetados para
representar la información en la Web. Esta especificación define la
sintaxis y la semántica del lenguaje de consulta SPARQL para RDF. SPARQL
se puede utilizar para expresar consultas que permiten interrogar
diversas fuentes de datos, si los datos se almacenan de forma nativa
como RDF o son definidos mediante vistas RDF a través de algún
sistema middleware. SPARQL contiene las capacidades para la consulta de
los patrones obligatorios y opcionales de grafo, junto con sus
conjunciones y disyunciones. SPARQL también soporta la ampliación o
restricciones del ámbito de las consultas indicando los grafos sobre los
que se opera. Los resultados de las consultas SPARQL pueden ser
conjuntos de resultados o grafos RDF.
Esta sección describe el estado de este documento en el momento de su publicación. Otros documentos pueden reemplazar este documento. Una lista delas publicaciones vigentes del W3C y la última revisión de este informe técnico se puede encontrar en el índice de informes técnicos del W3C en http://www.w3.org/TR/.
Esta es una Recomendación del W3C.
Este documento ha sido revisado por miembros del W3C, por desarrolladores de software y por otros grupos del W3C y partes interesadas, y ha sido remitido por el Director como una Recomendación del W3C. Se trata de un documento estable y puede ser utilizado como material de referencia o citado por otro documento. El papel del W3C en la elaboración de la Recomendación es atraer la atención sobre la especificación y promover un amplio despliegue de la misma. Todo ello mejora la funcionalidad y la interoperabilidad de la Web.
Los comentarios sobre este documento pueden ser enviados a [email protected], una lista de distribución de correo electrónico. Las preguntas y comentarios sobre SPARQL que no estén relacionadas con esta especificación, incluyendo extensiones y características, pueden discutirse en la lista de distribución [email protected], (archivo público).
Este documento fue elaborado por el Grupo de Trabajo sobre el Acceso a Datos RDF, que es parte de la Actividad para la Web Semántica del W3C. La primera versión de este documento fue un borrador de trabajo del 12 de octubre de 2004, y el grupo de trabajo ha considerado los problemas y comentarios recibidos desde entonces. Dos cambios han sido realizados y registrados desde la publicación de la Recomendación de noviembre de 2007.El grupo de trabajo, en su Informe sobre la Implementación del Lenguaje de Consulta SPARQL para RDF desmuestra que se han alcanzado los objetivos para implementaciones interoperables, establecidos en la Recomendación Candidata de junio de 2007.
El grupo de trabajo ha pospuesto 12 problemas, incluyendo las funciones de agregación, y el lenguaje de actualización (mantenimiento) de datos.
Este documento fue elaborado por un grupo que opera en el marco de la Política de Patentes del W3C del 5 de febrero 2004. El W3C mantiene una lista pública de cualquier patente divulgada realizada en coordinación con la difusión de los resultados del grupo de trabajo; dicha página también incluye instrucciones para la divulgación de una patente. Una persona que tenga conocimiento actual de una patente que considere que contiene la(s) reivindicación(es) esencial(es) debe revelar la información de conformidad con el artículo 6 de la Política de Patentes del W3C.
RDF es un formato de datos para grafos dirigidos etiquetados, que permite representar información en la Web. Normalmente, RDF se utiliza, entre otros usos, para representar información personal, redes sociales, metadatos sobre objetos digitales, así como para proporcionar un medio para la integración de fuentes de información dispares. Esta especificación define la sintaxis y la semántica de SPARQL, un lenguaje de consulta para RDF.
El lenguaje de consulta SPARQL para RDF está diseñado para cumplir con los casos de uso y necesidades identificadas por el Grupo de Trabajo de Acceso a Datos RDF incluidos en el documento Casos de Uso y Requisitos de acceso a datos RDF [UCNR].
El lenguaje de consulta SPARQL está estrechamente relacionado con las siguientes especificaciones:
A menos que se indique lo contrario en el epígrafe correspondiente, todas las secciones y anexos de este documento son normativas.
En esta sección del documento, la sección 1, se realiza una introducción a la especificación de lenguaje de consulta SPARQL. Se presenta la organización de este documento de esta especificación, así como las convenciones utilizadas en la misma.
La sección 2 es una introducción al lenguaje de consulta SPARQL en sí, a través de una serie de ejemplos y resultados de consultas. La sección 3 continúa con la introducción a este lenguaje con más ejemplos que demuestran la capacidad de SPARQL para expresar las restricciones sobre los términos RDF que aparecen en los resultados de una consulta.
La sección 4 presenta los detalles de la sintaxis del lenguaje de consulta SPARQL. Se trata de un acompañamiento a la gramática completa del lenguaje y define cómo las construcciones gramaticales representan IRIs, nodos en blanco, literales y variables. Esta sección también define el significado de varias construcciones gramaticales que sirven como simplificación sintáctica de expresiones más verbosas.
La sección 5 muestra los patrones de grafo básicos y de grupo, que son los componentes elementales a partir de los que se construyen patrones de consultas SPARQL más complejas. Las secciones 6, 7 y 8 presentan las construcciones que combinan patrones de grafo SPARQL para crear patrones de grafo más grandes. En particular, la sección 6 muestra la capacidad de hacer partes de una consulta opcional, la sección 7 presenta la capacidad de expresar la disyunción de los patrones de grafos alternativos, y la sección 8 introduce las posibilidades de limitar las porciones de una consulta a grafos fuente concretos. La sección 8 también presenta el mecanismo de SPARQL para la definición de los grafos fuente para una consulta.
La sección 9 define los constructores que afectan a las soluciones de una consulta para ordenar, extraer, proyectar, limitar y eliminar duplicados de una secuencia de soluciones.
La sección 10 define los cuatro tipos de consultas SPARQL que producen resultados de diferentes formas.
La sección 11 define el marco de comprobación de valores extensibles de SPARQL. También muestra las funciones y operadores que pueden usarse para limitar los valores que aparecen en los resultados de una consulta.
La sección 12 es una definición formal de la evluación de patrones de grafo SPARQL y de los modificadores de soluciones.
El apéndice A contiene la definición normativa de
la sintaxis de SPARQL, en forma de una gramática expresada en notación
EBNF.
En este documento, a menos que se indique lo contrario se asumen los siguientes vínculos de prefijos de espacios de nombres:
Prefijo | IRI |
---|---|
rdf: |
http://www.w3.org/1999/02/22-rdf-syntax-ns# |
rdfs: |
http://www.w3.org/2000/01/rdf-schema# |
xsd: |
http://www.w3.org/2001/XMLSchema# |
fn: |
http://www.w3.org/2005/xpath-functions# |
Este documento utiliza el formato de datos Turtle [TURTLE] para mostrar de forma explícita cada tripleta. Turtle permite abreviar IRIs mediante el uso de prefijos:
@prefix dc: <http://purl.org/dc/elements/1.1/> . @prefix : <http://example.org/book/> . :book1 dc:title "SPARQL Tutorial" .
Los conjuntos de resultados se muestran en forma de tablas.
x | y | z |
---|---|---|
"Alice" | <http://example/a> |
Un 'vínculo' es un par (variable, término
RDF). En este conjuto de resultados, hay tres variables: x
,
y
, z
(mostradas en los encabezados de las
columnas). Cada solución se muestra como una file en el cuerpo de la
tabla. En el ejemplo hay una única solución, en el que la variable x
esta vinculada a "Alice"
, la variable y
está
vinculada con <http://example/a>
, y la variable z
no está vinculadas a ningún término RDF. En una solución, la variables no
tienen por qué estar vinculadas obligatoriamente.
El lenguaje SPARQL incluye IRIs, un subconjunto de Referencias URI RDF que omiten los espacios. Debe tenerse en cuenta que en las consultas SPARQL todas las referencias a IRIs son absolutas; pueden o no incluir un identificador de fragmento [RFC3987, sección 3.1]. Las referencias IRI include a las referencias URI [RFC3986] y URL. En la sintaxis de SPARQL, las formas abreviadas (referencias IRIs relativas y nombres con prefijos) se resuelven para producir IRIs absolutas.
Los siguientes términos son definidos en el documento sobre Conceptos y Sintaxis abstracta de RDF [CONCEPTS] y empleados en SPARL:
RDF URI
reference
" en el documento sobre Conceptos y Sintaxis abstracta
de RDF)datatype URI
" en el documento sobre Conceptos y Sintaxis
abstracta de RDF)La mayoría de las formas de consulta en SPARQL contienen un conjunto de patrones de tripleta (triple patterns) denominadas patrón de grafo básico. Los patrones de tripleta son similares a las tripletas RDF, excepto que cada sujeto, predicado y objeto puede ser una variable. Un patrón de grafo básico concuerda con un subgrafo de datos RDF cuando los términos RDF (RDF terms) de dicho subgrafo pueden ser sustituidos por las variables y el resultado es un grafo RDF equivalente al subgrafo en cuestión.
El siguiente ejemplo muestra una
consulta SPARQL para encontrar el título de un libro en el grafo de
datos dado. La consulta consta de dos partes: la cláusula SELECT
identifica las variables que aparecen en los resultados de la consulta,
y la cláusula WHERE
proporciona el patrón de grafo básico
para la concordancia con el gráfo de datos. El patrón de grafo básico de
este ejemplo consiste en un único patrón de tripleta con una sola
variable (?title
) en la posición del objeto.
Datos:
<http://example.org/book/book1> <http://purl.org/dc/elements/1.1/title> "SPARQL Tutorial" .
Consulta:
SELECT ?title WHERE { <http://example.org/book/book1> <http://purl.org/dc/elements/1.1/title> ?title . }
Esta consulta, efectuada sobre los datos indicados anteriormente, tiene una solución:
Resultado de la consulta:
title |
---|
"SPARQL Tutorial" |
El resultado de una consulta es una secuencia de solución, correspondiente a las distintas posibilidades de concordancia del patrón del grafo de la consulta con los datos. Puede haber ninguna, una o múltiples soluciones a una consulta.
Datos:
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Johnny Lee Outlaw" . _:a foaf:mbox <mailto:[email protected]> . _:b foaf:name "Peter Goodguy" . _:b foaf:mbox <mailto:[email protected]> . _:c foaf:mbox <mailto:[email protected]> .
Consulta:
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name ?mbox WHERE { ?x foaf:name ?name . ?x foaf:mbox ?mbox }
Resultados de la consulta:
name | mbox |
---|---|
"Johnny Lee Outlaw" | <mailto:[email protected]> |
"Peter Goodguy" | <mailto:[email protected]> |
Cada solución proporciona una manera de vincular las variables seleccionadas a los términos RDF para los que el patrón de consulta concuerda con los datos. El conjunto de resultados proporciona todas las posibles soluciones. En el ejemplo anterior, los dos subconjuntos de datos mostrados a continuación proporcionan ambas concordancias.
_:a foaf:name "Johnny Lee Outlaw" . _:a foaf:box <mailto:[email protected]> .
_:b foaf:name "Peter Goodguy" . _:b foaf:box <mailto:[email protected]> .
Esta es una concordancia de patrón de grafo básico; todas las variables utilizadas en el patrón de consulta deben estar vinculadas en cada solución.
Los datos siguientes contienen tres literales RDF:
@prefix dt: <http://example.org/datatype#> .
@prefix ns: <http://example.org/ns#> .
@prefix : <http://example.org/ns#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
:x ns:p "cat"@en .
:y ns:p "42"^^xsd:integer .
:z ns:p "abc"^^dt:specialDatatype .
Debe observarse que en Turtle "cat"@en
es un literal RDF
con una forma léxica "cat" y un idioma en
; "42"^^xsd:integer
es un literal tipado con el tipo de datos http://www.w3.org/2001/XMLSchema#integer
;
y "abc"^^dt:specialDatatype
es un literal tipado con el
tipo de datos
http://example.org/datatype#specialDatatype
.
Estos datos RDF constituyen el grafo de datos para las consultas de ejemplo de las secciones 2.3.1–2.3.3.
Las etiquetas de idioma en SPARQL se expresan usando @
y
la etiqueta de idioma, como se define en el documento Best Common Practice 47 [BCP47].
La siguiente consulta no tiene solución porque "cat"
no
es el mismo literal RDF que "cat"@en
:
SELECT ?v WHERE { ?v ?p "cat" }
v |
---|
sin embargo, la siguiente
consulta encontrará una solución, donde la variable v
se vincula a :x
porque la etiqueta de idioma se
especifica y concuerda con los datos del grafo:
SELECT ?v WHERE { ?v ?p "cat"@en }
v |
---|
<http://example.org/ns#x> |
Los enteros de una consulta SPARQL indican un literal RDF tipado con el tipo
de datos xsd:integer
. Por ejemplo: 42
es una
forma abreviada de "42"^^<http://www.w3.org/2001/XMLSchema#integer>
.
El patrón en la siguiente consulta tiene una solución con la variable v
vinculada a:y
.
SELECT ?v WHERE { ?v ?p 42 }
v |
---|
<http://example.org/ns#y> |
La sección
4.1.2 define formas abreviadas de SPARQL para xsd:float
y xsd:double
.
La siguiente consulta tiene una
solución con la variable v
ligada a :z
. El
procesador de consultas no tiene porqué tener conocimiento de los
valores en el espacio del tipo de datos. Debido a la correspondencia
tanto de la forma léxica como del tipo de datos del IRI, la consulta
encuentra una concordancia con el literal indicado.
SELECT ?v WHERE { ?v ?p "abc"^^<http://example.org/datatype#specialDatatype> }
v |
---|
<http://example.org/ns#z> |
Los resultados de una consulta pueden contener nodos en blanco. Los nodos en blanco, en los ejemplos de conjuntos de resultados de este documento, se escriben con la forma "_:" seguida de una etiqueta del nodo en blanco.
Las etiquetas de los nodos en blanco se aplican en el ámbito de un
conjunto de resultados (como se define en la especificación "Formato XML de los
resultados de consultas SPARQL") o en los grafos resultantes al
utilizar la forma de consulta CONSTRUCT
. El uso de la misma
etiqueta en un conjunto de resultados indica el mismo nodo en blanco.
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:b foaf:name "Bob" .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?x ?name WHERE { ?x foaf:name ?name }
x | name |
---|---|
_:c | "Alice" |
_:d | "Bob" |
Los resultados anteriores también podrían darse con diferentes etiquetas de nodos en blanco, debido a que las etiquetas en los resultados indican si los términos RDF de las soluciones son los mismos o no.
x | name |
---|---|
_:r | "Alice" |
_:s | "Bob" |
Estos dos resultados tienen la misma información: los nodos en blanco
utilizados para la concordancia con la consulta son diferentes en ambas
soluciones. No tiene que haber ninguna relación entre una etiqueta _:a
en el conjunto de resultados y un nodo en blanco en el grafo de datos con la
misma etiqueta.
Un programador de aplicaciones no debe esperar que las etiquetas de un nodo en blanco de una consulta hagan referencia a un nodo en blanco específico en los datos.
SPARQL tiene varias formas de consulta. La
forma de consulta SELECT
devuelve vínculos de variables. La
forma CONSTRUCT
devuelve un grafo RDF. El grafo se construye
sobre una plantilla que se usa para generar tripletas RDF basadas en los
resultados de la concordancia con el patrón de grafo de la consulta.
Datos:
@prefix org: <http://example.com/ns#> . _:a org:employeeName "Alice" . _:a org:employeeId 12345 . _:b org:employeeName "Bob" . _:b org:employeeId 67890 .
Consulta:
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX org: <http://example.com/ns#> CONSTRUCT { ?x foaf:name ?name } WHERE { ?x org:employeeName ?name }
Resultados:
@prefix org: <http://example.com/ns#> . _:x foaf:name "Alice" . _:y foaf:name "Bob" .
que pueden serializarse con RDF/XML del siguiente modo:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:foaf="http://xmlns.com/foaf/0.1/" > <rdf:Description> <foaf:name>Alice</foaf:name> </rdf:Description> <rdf:Description> <foaf:name>Bob</foaf:name> </rdf:Description> </rdf:RDF>
La concordancia con un patrón de grafo produce una secuencia de solución,
donde cada solución tiene un conjunto de vínculos de variables con
términos RDF. Los filtros (FILTERS)
SPARQL restringen las
soluciones a aquellas para las que la expresión del filtro se evalua como
verdadera (TRUE)
.
Esta sección proporciona una introducción informal a los filtros de SPARQL; su semántica se define en la sección 11. Comprobación de valores. Los ejemplos de esta sección utilizan un mismo grafo de entrada:
@prefix dc: <http://purl.org/dc/elements/1.1/> . @prefix : <http://example.org/book/> . @prefix ns: <http://example.org/ns#> . :book1 dc:title "SPARQL Tutorial" . :book1 ns:price 42 . :book2 dc:title "The Semántica Web" . :book2 ns:price 23 .
Las funciones de filtro de SPARQL, como regex
pueden comprobar el valor de literales RDF. regex
busca
concordancias entre literales planos sin etiqueta de lenguaje. regex
puede usarse para concordancias con formas léxicas de otros literales
utilizando la función str.
Consulta:
PREFIX dc: <http://purl.org/dc/elements/1.1/> SELECT ?title WHERE { ?x dc:title ?title FILTER regex(?title, "^SPARQL") }
Resultado:
title |
---|
"SPARQL Tutorial" |
Las concordancias entre expresiones regulares puede realizarse de
manera que sea insensibles a las mayúsculas mediante el indicador "i
".
Consulta:
PREFIX dc: <http://purl.org/dc/elements/1.1/> SELECT ?title WHERE { ?x dc:title ?title FILTER regex(?title, "web", "i" ) }
Resultado:
title |
---|
"The Semantic Web" |
El lenguaje de expresiones regulares está definido en el documento Funciones y Operadores de XQuery 1.0 y XPath 2.0 y se basa en las Expresiones regulares de XML Schema.
Los filtros de SPARQL pueden realizar restricciones sobre expresiones aritméticas.
Consulta:
PREFIX dc: <http://purl.org/dc/elements/1.1/> PREFIX ns: <http://example.org/ns#> SELECT ?title ?price WHERE { ?x ns:price ?price . FILTER (?price < 30.5) ?x dc:title ?title . }
Resultado:
title | price |
---|---|
"The Semantic Web" | 23 |
Al limitar el valor de la variable price
, únicamente :book2
satisface las condiciones de la consulta, ya que solo :book2
tiene un precio menor de 30.5
, tal como se indica en la
condición del filtro.
Además de los tipos de datos numéricos,
SPARQL soporta los tipos xsd:string
, xsd:boolean
y xsd:dateTime
(ver 11.1 Tipos
de datos de los operandos). En 11.3
Correspondencia de operadores se enumera un conjunto de funciones de
comprobación, incluyendo BOUND
, isLITERAL
y langMATCHES
y acceso, incluyendo STR
, LANG
y DATATYPE
.
En 11.5 Funciones constructor se incluye
una relación de funciones constructor de XML Schema para convertir valores
de un tipo de datos a otro.
Esta sección cubre la sintaxis utilizada por SPARQL para términos RDF (RDF terms) y patrones de tripletas (triple patterns). La gramática completa figura en el Anexo A (appendix A).
La producción IRIref designa el conjunto de IRIs [RFC3987]; los IRIs son una generalización de los URIs [RFC3986] y son totalmente compatibles con URIs y URLs. La producción PrefixedName designa un nombre prefijado. La correspondencia de un nombre prefijado a una IRI se describe a continuación. Las referencias IRI (IRIs absolutas o relativas ) son designadas por la producción IRI_REF, en la que los caracteres delimitadores "<" y ">" no forman parte de las referencias IRI. Los IRIs relativos se corresponden con la referencia irelative-ref de la Sección 2.2 ABNF para referencias IRI e IRIs en [RFC3987] y se resuelven a IRIs como se describe a continuación.
[67] |
IRIref |
::= | IRI_REF
| PrefixedName |
[68] |
PrefixedName |
PNAME_LN
| PNAME_NS |
|
[69] |
BlankNode |
::= | BLANK_NODE_LABEL
| ANON |
[70] |
IRI_REF |
::= | '<'
([^<>"{}|^`\]-[#x00-#x20])* '>' |
[71] |
PNAME_NS |
::= | PN_PREFIX?
':' |
[72] |
PNAME_LN |
::= | PNAME_NS
PN_LOCAL |
El conjunto de términos RDF definidos en la especificación Conceptos
y Sintaxis Abstracta de RDF [CONCEPT]
incluye referencias RDF URI mientras que los términos de SPARQL contienen
IRIs. Las referencias RDF URI que contienen los caracteres "<
",
">
", '"
' (comilla doble), espacio, "{
",
"}
", "|
", "\
", "^
", y
"`
" no son IRIs. No está definido el comportamiento de una
consulta SPARQL frente a las sentencias RDF compuestas de tales
referencias URI.
La palabra clave PREFIX
asocia una etiqueta de prefijo con
un IRI. Un nombre con prefijo está compuesto de una etiqueta de prefijo y
una parte local, separados por dos puntos ":
". Un nombre con
prefijo se correponde (mapped)
con un IRI mediante la concatenación del IRI asociado con el prefijo y la
parte local. La etiqueta de prefijo y la parte local pueden estar vacías.
Tenga en cuenta que los nombres
locales
SPARQL admiten dígitos iniciales, a diferencia de los nombres
locales
XML.
Los IRIs relativos se combinan con IRIs base conforme a la RFC Identificador de Recurso Uniforme(URI): Sintaxis Genérica [RFC3986], utilizando sólo el algoritmo básico de la Sección 5.2. No se llevan a cabo ni la normalización basada en sintaxis ni la normalización basada en esquema (descritas en las secciones 6.2.2 y 6.2.3 de la RFC 3986). Los caracteres adicionalmente permitidos en las referencias IRI son tratados de la misma manera en la que son tratados los caracteres no reservados en las referencias URI, tal y como se indica en el apartado 6.5 de Identificadores de Recursos Internacionalizados (IRIs) [RFC3987].
La palabra clave BASE
define la dirección IRI de base para
resolver las direcciones IRIs relativas, según la Sección 5.1.1, "URI de
base incorporadas al contenido" de la RFC 3986. La Sección 5.1.2, "URI de
base de la Entidad encapsulante", define cómo la IRI de base puede
provenir de un documento encapsulante, por ejemplo una envoltura SOAP con
una directiva xml:base o un documento MIME multiparte con un encabezado
Content-Location. La "URI de recuperación" identificada en el punto
5.1.3, "URI de base de la URI de recuperación", es la URL desde la que se
recuperó una consulta SPARQL en particular. Si ninguna de las anteriores
especifica la URI de base, se utiliza la URI de base por defecto (sección
5.1.4, "URI de base por defecto").
Los siguientes fragmentos son algunas de las diferentes formas deescribir la misma dirección IRI:
<http://example.org/book/book1>
BASE <http://example.org/book/>
<book1>
PREFIX book: <http://example.org/book/>
book:book1
La sintaxis general para literales es una cadena de caracteres (entre
comillas dobles, "..."
, o comillas simples, '...'
),
con
una etiqueta de idioma (antecedida por @
) o un tipo de
datos IRI o nombre prefijado (antecedido por ^^
)
opcionales.
Por comodidad, los enteros pueden escribirse directamente (sin comillas y
tipo de datos IRI explícito) y se interpretan como literales del tipo de
datos xsd:integer
; los decimales con '.' en el número pero
sin exponente se interpretan como xsd:decimal
; y los números
con exponente se interpretan como xsd:double
. Los valores
del tipo xsd:boolean
pueden también escribirse como true
o false
.
Para facilitar la escritura de valores literales que contengan comillas o que sean largos y contengan caracteres de salto de línea, SPARQL proporciona una construcción adicional con los literales entrecomillados entre tres comillas simples o dobles.
Ejemplos de sintaxis de literales SPARQL:
"chat"
'chat'@fr
con la etiqueta de idioma "fr""xyz"^^<http://example.org/ns/userDatatype>
"abc"^^appNS:appDataType
'''The librarian said, "Perhaps you would enjoy 'War and
Peace'."'''
1
, igual a "1"^^xsd:integer
1.3
, igual a "1.3"^^xsd:decimal
1.300
, igual a "1.300"^^xsd:decimal
1.0e6
, igual a "1.0e6"^^xsd:double
true
, igual a "true"^^xsd:boolean
false
, igual a "false"^^xsd:boolean
Los tokens correspondientes a las producciones INTEGER,
DECIMAL,
DOUBLE
y BooleanLiteral
son equivalentes a un literal tipado con el valor léxico del token y el
correspondiente tipo de datos (xsd:integer
, xsd:decimal
,
xsd:double
, xsd:boolean
).
Las variables de interrrogación en consultas SPARQL tienen alcance
global; el uso de un nombre de variable determinado en cualquier lugar de
una consulta identifica a la misma variable. Las variables son prefijadas
mediante "?" o "$"; la "?" o "$" que no forman parte del nombre de la
variable. En una consulta, $abc
y ?abc
identifican la misma variable. Los posibles
nombres para variables se proporcionan en la gramática
SPARQL.
[44] |
Var |
::= | VAR1
| VAR2 |
[74] |
VAR1 |
::= | '?' VARNAME |
[75] |
VAR2 |
::= | '$' VARNAME |
[97] |
VARNAME |
::= | ( PN_CHARS_U
| [0-9] ) ( PN_CHARS_U
| [0-9] | #x00B7 | [#x0300-#x036F] | [#x203F-#x2040] )* |
Los nodos en blanco en los patrones de grafo actúan como variables indistintas, no como referencias a nodos en blanco específicos en los datos consultados.
Los nodos en blanco se indican mediante la forma etiquetada, como "_:abc
",
o
la forma abreviada "[]
". Un nodo en blanco que se utiliza en
un solo lugar en la sintaxis de la consulta puede indicarse con []
.
Un único nodo en blanco se utiliza para formar el patrón de tripleta. Las
etiquetas de nodo en blanco se escriben de la misma forma que "_:abc
"
para un nodo en blanco con la etiqueta "abc
". El mismo nodo
en blanco no puede utilizarse en dos diferentes patrones de gráfo básicos
en la misma consulta.
La construcción [:p :v]
se puede utilizar en los patrones
de tripleta. Crea una etiqueta de nodo en blanco que sirve como sujeto a
todas las parejas predicado-objeto contenidas. El nodo en blanco creado
también se puede utilizar en otros patrones de tripleta en las posiciones
de sujeto y objeto.
Las siguientes dos formas
[ :p "v" ] .
[] :p "v" .
asignan una única etiqueta de nodo en blanco (aquí "b57
") y
son equivalentes a escribir:
_:b57 :p "v" .
Esta etiqueta de nodo en blanco asignada puede usarse como el sujeto u objeto de posteriores patrones de tripletas. Por ejemplo, como un sujeto:
[ :p "v" ] :q "w" .
que es equivalente a las dos tripletas:
_:b57 :p "v" .
_:b57 :q "w" .
y como un objeto:
:x :q [ :p "v" ] .
que es equivalente a las dos tripletas:
:x :q _:b57 .
_:b57 :p "v" .
La sintaxis abreviada para los nodos en blanco puede combinarse con otras abreviaturas para sujetos comunes y predicados comunes.
[ foaf:name ?name ;
foaf:mbox <mailto:[email protected]> ]
Es lo mismo que escribir el siguiente patrón de grafo básico para alguna
etiqueta de nodo en blanco asignada exclusivamente, "b18
":
_:b18 foaf:name ?name .
_:b18 foaf:mbox <mailto:[email protected]> .
[39] |
BlankNodePropertyList |
::= | '['PropertyListNotEmpty']' |
[69] |
BlankNode |
::= | BLANK_NODE_LABEL
| ANON |
[73] |
BLANK_NODE_LABEL |
::= | '_:' PN_LOCAL |
[94] |
ANON |
::= | '[' WS*
']' |
Los Patrones de Tripleta se escriben como una lista, separada por espacios, de sujeto, predicado y objeto; hay formas abreviadas para escribir algunas construcciones de patrones comunes de tripleta.
Los siguientes ejemplos expresan la misma consulta:
PREFIX dc: <http://purl.org/dc/elements/1.1/>
SELECT ?title
WHERE { <http://example.org/book/book1> dc:title ?title }
PREFIX dc: <http://purl.org/dc/elements/1.1/>
PREFIX : <http://example.org/book/>
SELECT $title
WHERE { :book1 dc:title $title }
BASE <http://example.org/book/>
PREFIX dc: <http://purl.org/dc/elements/1.1/>
SELECT $title
WHERE { <book1> dc:title ?title }
[32] |
TriplesSameSubject |
::= | VarOrTerm
PropertyListNotEmpty
| |
[33] |
PropertyListNotEmpty |
::= | Verb
ObjectList
( ';' ( Verb
ObjectList
)? )* |
[34] |
PropertyList |
::= | PropertyListNotEmpty? |
[35] |
ObjectList |
::= | Object
( ',' Object
)* |
[37] |
Verb |
::= | VarOrIRIref
| 'a' |
Los patrones de tripleta con un sujeto común pueden escribirse de forma
que el sujeto se escriba una sola vez y se use para más de unpatrón de
tripleta empleando la notación ";
".
?x foaf:name ?name ;
foaf:mbox ?mbox .
Es lo mismo que escribir los patrones de tripleta:
?x foaf:name ?name .
?x foaf:mbox ?mbox .
Si los patrones de tripleta comparten tanto el sujeto como el predicado,
los objetos pueden separarse mediante ",
".
?x foaf:nick "Alice" , "Alice_" .
es lo mismo que escribir los patrones de tripleta:
?x foaf:nick "Alice" .
?x foaf:nick "Alice_" .
Las listas de objetos pueden combinarse con listas predicado-objeto:
?x foaf:name ?name ; foaf:nick "Alice" , "Alice_" .
es equivalente a:
?x foaf:name ?name .
?x foaf:nick "Alice" .
?x foaf:nick "Alice_" .
Las colecciones RDF pueden escribirse como patrones de
tripleta usando la sintaxis "(elemento1 elemento2 ...)". La forma "()
"
es una alternativa para la IRI http://www.w3.org/1999/02/22-rdf-syntax-ns#nil
.
Cuando se usa con una colección de elementos, como en (1 ?x 3 4)
,
se asignan a la colección patrones de tripleta con nodos en blanco. El
nodo en blanco al principio de la colección puede usarse como un sujeto u
objeto en otros patrones de tripleta. Los nodos en blanco asignados por
la sintaxis de la colección no aparecen en otras partes de la consulta.
(1 ?x 3 4) :p "w" .
es azúcar sintáctico para (cabe señalar que b0
, b1
,
b2
y b3
no aparecen en otras partes de la
consulta):
_:b0 rdf:first 1 ;
rdf:rest _:b1 .
_:b1 rdf:first ?x ;
rdf:rest _:b2 .
_:b2 rdf:first 3 ;
rdf:rest _:b3 .
_:b3 rdf:first 4 ;
rdf:rest rdf:nil .
_:b0 :p "w" .
Las colecciones RDF pueden ser anidadas y pueden involucrar otras formas sintácticas:
(1 [:p :q] ( 2 ) ) .
es azúcar sintáctico para:
_:b0 rdf:first 1 ;
rdf:rest _:b1 .
_:b1 rdf:first _:b2 .
_:b2 :p :q .
_:b1 rdf:rest _:b3 .
_:b3 rdf:first _:b4 .
_:b4 rdf:first 2 ;
rdf:rest rdf:nil .
_:b3 rdf:rest rdf:nil .
[40] |
Collection |
::= | '(' GraphNode+
')' |
[92] |
NIL |
::= | '(' WS*
')' |
Se puede utilizar la palabra clave "a
" como un predicado en
un patrón de tripleta; es una alternativa para la IRI http://www.w3.org/1999/02/22-rdf-syntax-ns#type
.
Esta palabra clave es sensible a las mayúsculas.
?x a :Class1 .
[ a :appClass ] :p "v" .
es azúcar sintáctico para:
?x rdf:type :Class1 .
_:b0 rdf:type :appClass .
_:b0 :p "v" .
SPARQL se basa en la correspondencia entre patrones de grafo. Existen varios modos para formar patrones de grafo más complejos mediante la combinación de patrones más pequeños:
En esta sección se describen las dos formas de combinar patrones a partir de su conjunción: patrones de grafo básicos, que combinan patrones de tripleta, y patrones de grafo de grupo, que combinan todos los demás patrones de grafo.
El patrón de grafo más externo de una consulta se denomina patrón de
consulta. Gramaticalmente se identifica como GroupGraphPattern
en
[13] |
WhereClause |
::= | 'WHERE'? GroupGraphPattern |
Los patrones de grafos básicos son conjuntos de patrones de tripleta. La concordancia entre patrones de grafo SPARQL se define mediante la combinación de los resultados de concordancia de patrones de grafo básicos.
Una secuencia de patrones de tripleta interrumpidos por un filtro consta de un solo patrón de grafo básico. Cualquier patrón de grafo termina un patrón de grafo básico.
Al utilizar nodos en blanco con la forma _:abc
, las
etiquetas afectan al patrón de grafo básico. En cualquier consulta, una
etiqueta puede usarse solo en un patrón de grafo básico.
SPARQL ha sido definido para encontrar correspondencias entre grafos RDF con una vinculación simple. SPARQL puede ampliarse a otro tipo de vinculación si se dan ciertas condiciones tal y como se describe más adelante.
En una expresión de consulta SPARQL, un patrón de grafo de grupo se
delimitan mediante llaves: {}
. Por ejemplo, el siguiente
patrón de consulta es un patrón de grafo de grupo con un solo patrón de
grafo básico.
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name ?mbox WHERE { ?x foaf:name ?name . ?x foaf:mbox ?mbox . }
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name ?mbox WHERE { { ?x foaf:name ?name . } { ?x foaf:mbox ?mbox . } }
[20] |
GroupGraphPattern
|
::= | '{' TriplesBlock?
( ( GraphPatternNotTriples
| Filter ) '.'?
TriplesBlock? )* '}'
|
[21] |
TriplesBlock
|
::= | TriplesSameSubject
( '.' TriplesBlock?
)? |
[22] |
GraphPatternNotTriples |
::= | OptionalGraphPattern
| GroupOrUnionGraphPattern
| GraphGraphPattern
|
El patrón de grupo:
{ }
concuerda con cualquier grafo (incluido el grafo vacío) con una solución en la que no se vincula ninguna variable. Por ejemplo:
SELECT ?x WHERE {}
concuerda con una solución en la que variable x
no está
vinculada.
Una restricción, expresada con FILTER
, es es una
restricción de soluciones sobre el grupo completo en el que aparece el
filtro. Los siguientes patrones tienen todos las mismas soluciones:
{ ?x foaf:name ?name . ?x foaf:mbox ?mbox . FILTER regex(?name, "Smith") }
{ FILTER regex(?name, "Smith") ?x foaf:name ?name . ?x foaf:mbox ?mbox . }
{ ?x foaf:name ?name . FILTER regex(?name, "Smith") ?x foaf:mbox ?mbox . }
{ ?x foaf:name ?name . ?x foaf:mbox ?mbox . }
es un grupo de un patrón de grafo básico que consta de dos patrones de tripleta.
{ ?x foaf:name ?name . FILTER regex(?name, "Smith") ?x foaf:mbox ?mbox . }
es un grupo de un patrón de grafo básico y un filtro que consta de dos patrones de tripleta; los filtros no rompen el patrón de grafo básico en dos.
{ ?x foaf:name ?name . {} ?x foaf:mbox ?mbox . }
es un grupo de tres elementos, un patrón de grafo básico con un patrón de tripleta, un grupo vacío y otro patrón de grafo básico con un patrón de tripleta.
Los patrones de grafo básicos permiten que las aplicaciones realicen consultas donde todo el patrón debe concordar para obtener una solución. Para cada solución de una consulta conteniendo solo un patrón de grafo de grupo con al menos un patrón de grafo básico, cada variable está vinculada a un término RDF en una solución. Sin embargo, las estructuras completas regulares no pueden ser asumidas en todos los grafos RDF. Es útil poder disponer de las consultas que permitan añadir información a la solución donde la información esté disponible, pero sin rechazar la solución debido a que una parte del patrón de consulta no concuerde. Una concordancia opcional proporciona esta posibilidad: si la parte opcional no concuerda, no se crea ningún vínculo pero no se elimina la solución.
Puede especificarse sintácticamente partes opcionales de un patrón de grafo con la cláusula OPTIONAL aplicándose a patrones de grafo:
pattern OPTIONAL { pattern }
La forma sintáctica:
{ OPTIONAL { pattern } }
es equivalente a:
{ { } OPTIONAL { pattern } }
[23] |
OptionalGraphPattern |
::= | 'OPTIONAL'
GroupGraphPattern |
La cláusula OPTIONAL
es asociativa por la izquierda:
pattern OPTIONAL { pattern } OPTIONAL { pattern }
es equivalente a:
{ pattern OPTIONAL { pattern } } OPTIONAL { pattern }
En una concordancia opcional, el patrón de grafo opcional concuerda con un grafo, y en consecuencia definiendo y añadiendo vínculos a una o más soluciones, o conservando una solución sin cambios y por lo tanto sin añadir vínculos adicionales.
Datos:
@prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . _:a rdf:type foaf:Person . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:[email protected]> . _:a foaf:mbox <mailto:[email protected]> . _:b rdf:type foaf:Person . _:b foaf:name "Bob" .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name ?mbox WHERE { ?x foaf:name ?name . OPTIONAL { ?x foaf:mbox ?mbox } }
Con los datos anteriores, el resultado de la consulta es:
name | mbox |
---|---|
"Alice" | <mailto:[email protected]> |
"Alice" | <mailto:[email protected]> |
"Bob" |
No hay ningún valor de mbox
en la solución donde el nombre
es "Bob"
.
Esta consulta encuentra los nombres de personas en los datos. Si hay una
tripleta con predicado mbox
y el mismo sujeto, una solución
también contendrá el objeto de dicha tripleta. En este ejemplo, únicamente
se proporciona un patrón de tripleta en la parte opcional de la
concordancia de la consulta, sin embargo, por regla general, la parte
opcional puede ser cualquier patrón de grafo. Los patrones de grafo
opcionales deben concordar entre sí para que afecten a la solución de la
consulta.
Las restricciones pueden indicarse en un patrón de grafo opcional. Por ejemplo:
@prefix dc: <http://purl.org/dc/elements/1.1/> . @prefix : <http://example.org/book/> . @prefix ns: <http://example.org/ns#> . :book1 dc:title "SPARQL Tutorial" . :book1 ns:price 42 . :book2 dc:title "The Semantic Web" . :book2 ns:price 23 .
PREFIX dc: <http://purl.org/dc/elements/1.1/> PREFIX ns: <http://example.org/ns#> SELECT ?title ?price WHERE { ?x dc:title ?title . OPTIONAL { ?x ns:price ?price . FILTER (?price < 30) } }
title | price |
---|---|
"SPARQL Tutorial" | |
"The Semantic Web" | 23 |
No aparece el precio para el libro titulado "SPARQL Tutorial" debido a
que el patrón de grafo opcional no dio lugar a una solución con la
variable "price
".
Los patrones de grafo se definen de forma recursiva. Un patrón de grafo puede tener ninguno o más patrones de grafo, y cualquier parte de un patrón de consulta puede tener una parte opcional. En el siguiente ejemplo hay dos patrones de grafo opcionales.
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:homepage <http://work.example.org/alice/> . _:b foaf:name "Bob" . _:b foaf:mbox <mailto:[email protected]> .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name ?mbox ?hpage WHERE { ?x foaf:name ?name . OPTIONAL { ?x foaf:mbox ?mbox } . OPTIONAL { ?x foaf:homepage ?hpage } }
Resultados de la consulta:
name | mbox | hpage |
---|---|---|
"Alice" | <http://work.example.org/alice/> | |
"Bob" | <mailto:[email protected]> |
SPARQL proporciona un mecanismo para combinar patrones de grafo de modo que alguno de los patrones de grafo alternativos concuerden. Si más de una alternativa concuerda se obtienen todas las soluciones de patrones posibles.
Los patrones alternativos se especifican sintácticamente mediante la
clausula UNION
.
@prefix dc10: <http://purl.org/dc/elements/1.0/> . @prefix dc11: <http://purl.org/dc/elements/1.1/> . _:a dc10:title "SPARQL Query Language Tutorial" . _:a dc10:creator "Alice" . _:b dc11:title "SPARQL Protocol Tutorial" . _:b dc11:creator "Bob" . _:c dc10:title "SPARQL" . _:c dc11:title "SPARQL (updated)" .
PREFIX dc10: <http://purl.org/dc/elements/1.0/> PREFIX dc11: <http://purl.org/dc/elements/1.1/> SELECT ?title WHERE { { ?book dc10:title ?title } UNION { ?book dc11:title ?title } }
Resultados de la consulta:
title |
---|
"SPARQL Protocol Tutorial" |
"SPARQL" |
"SPARQL (updated)" |
"SPARQL Query Language Tutorial" |
Esta consulta busca los títulos de los libros en los datos, si el título se registra utilizando las propiedades Dublin Core de la versión 1.0 o la versión 1.1. Para determinar exactamente como se almacena la información, una consulta podría utilizar diferentes variables para las dos alternativas:
PREFIX dc10: <http://purl.org/dc/elements/1.0/> PREFIX dc11: <http://purl.org/dc/elements/1.1/> SELECT ?x ?y WHERE { { ?book dc10:title ?x } UNION { ?book dc11:title ?y } }
x | y |
---|---|
"SPARQL (updated)" | |
"SPARQL Protocol Tutorial" | |
"SPARQL" | |
"SPARQL Query Language Tutorial" |
Esto devolverá los resultados con la variable x
vinculada
a las soluciones de la parte izquierda de la UNION
, y con
la variable y
vinculada a las soluciones de la parte
derecha. Si ninguna parte del patrón de UNION
concuerda,
entonces el patrón de grafo no concordará.
El patrón de UNION
combina los patrones de grafo; cada
pattern combines graph patterns; cada posibilidad alternativa puede
contener más de un patrón de tripleta:
PREFIX dc10: <http://purl.org/dc/elements/1.0/> PREFIX dc11: <http://purl.org/dc/elements/1.1/> SELECT ?title ?author WHERE { { ?book dc10:title ?title . ?book dc10:creator ?author } UNION { ?book dc11:title ?title . ?book dc11:creator ?author } }
author | title |
---|---|
"Alice" | "SPARQL Protocol Tutorial" |
"Bob" | "SPARQL Query Language Tutorial" |
En esta consulta solo concuerda un libro si ambos predicados, título y creador, provienen de la misma versión de Dublin Core.
[25] |
GroupOrUnionGraphPattern |
::= | GroupGraphPattern
|
El modelo de datos RDF expresa la información como grafos formados de tripletas con sujeto, predicado y objeto. Muchos sistemas de almacenamiento de datos RDF mantienen múltiples grafos y registra información sobre cada uno ellos, permitiendo que una aplicación realice consultas que involucren más de un grafo.
Una consulta SPARQL se ejecuta en un Conjunto de datos RDF que representa una colección de grafos. Un conjunto de datos RDF comprende un grafo, el grafo por defecto (default graph), que no tiene un nombre, y cero o más grafos con nombre (named graph), donde cada nombre de grafo se identifica mediante una referencia IRI. Puede suceder que en una consulta SPARQL diferentes partes del patrón de consulta concuerdan con diferentes grafos, tal y como se describe en la sección 8.3 Consultas a conjuntos de datos.
Un conjunto de datos RDF puede contener cero grafos con nombre; un conjunto de datos RDF también puede contener un grafo por defecto. Una consulta no tiene que implicar necesariamente la concordancia con el grafo por defecto; la correspondencia de una consulta puede comprender únicamente a los grafos con nombre.
El grafo utilizado para la concordancia de un patrón de grafo básico se
denomina grafo activo. En la sección anterior todas las consultas
se ejecutaban frente a un único grafo, el grafo por defecto de un conjunto
de datos RDF es el grafo activo. La cláusula GRAPH
se
utiliza, como parte de la consulta, para definir como grafo activo a uno
de los grafos con nombre del conjunto de datos.
La definición del conjunto de datos RDF no limita las relaciones del grafo por defecto y de los grafos con nombre. La información puede estar repetida en diferentes grafos; pudiendo descubrirse relaciones entre grafos. Existen dos convenciones de utilidad:
# Default graph @prefix dc: <http://purl.org/dc/elements/1.1/> . <http://example.org/bob> dc:publisher "Bob" . <http://example.org/alice> dc:publisher "Alice" .
# Named graph: http://example.org/bob @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Bob" . _:a foaf:mbox <mailto:[email protected]> .
# Named graph: http://example.org/alice @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:[email protected]> .
En el ejemplo anterior, el grafo por defecto contiene los nombres de los editores de dos grafos con nombre. En este ejemplo, las tripletas en los grafos con nombre no son visibles en el grafo por defecto.
Ejemplo 2:
Los datos RDF pueden combinarse mediante la unión RDF [RDF-MT] de grafos. Una convención posible de los grafos en un conjunto de datos RDF es disponer de un grafo por defecto que sea el resultado de la unión RDF que incluya la información de algunos o todos los grafos con nombre.
En el siguiente ejemplo, los grafos con nombre contienen las misma tripletas que el ejemplo anterior. El conjunto de datos RDF incluye una unión RDF de los grafos con nombre en el grafo por defecto, re-etiquetando los nodos en blanco para distinguirlos.
# Default graph @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:x foaf:name "Bob" . _:x foaf:mbox <mailto:[email protected]> . _:y foaf:name "Alice" . _:y foaf:mbox <mailto:[email protected]> .
# Named graph: http://example.org/bob @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Bob" . _:a foaf:mbox <mailto:[email protected]> .
# Named graph: http://example.org/alice @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:[email protected]> .
En una unión RDF, los nodos en blanco en el grafo resultante no se comparten en los grafos originales.
Una consulta SPARQL puede especificar el conjunto de datos a utilizar en
la concordancia mediante las cláusulas FROM
y FROM
NAMED
para describir el conjunto de datos. Si una consulta
proporciona dicha descripción, entonces es usado en vez de cualquier
conjunto de datos que usaría el servicio de consulta si no se
proporcionara la misma. El conjunto de datos RDF también puede ser especificado en una petición del protocolo SPARQL, en
cuyo caso la descripción del protocolo anularía cualquier descripción de
la propia consulta. Un servicio de consulta puede rechazar una petición de
una consulta si la descripción del conjunto de datos no es aceptable para
el servicio.
Las cláusulas FROM
y FROM NAMED
permiten a la
consulta especificar el conjunto de datos mediante una referencia; indican
que el conjunto de datos debe incluir los grafos obtenidos a partir de las
representaciones de los recursos identificados por las referencias IRI
suministradas (por ejemplo, la forma absoluta de las referencias IRI
suministradas). El conjunto de datos resultante de aplicar las cláusulas FROM
y FROM NAMED
es:
FROM
, yFROM NAMED
.No se utiliza la cláusula FROM
, pero hay una o más
cláusulas FROM NAMED
, entonces el conjunto de datos incluirá
un grafo vacío para el grafo por defecto.
[9] |
DatasetClause |
::= | 'FROM' ( DefaultGraphClause | NamedGraphClause
) |
[10] |
DefaultGraphClause |
::= | SourceSelector |
[11] |
NamedGraphClause |
::= | 'NAMED' SourceSelector |
[12] |
SourceSelector |
::= | IRIref |
Cada cláusula FROM
contiene una referencia IRI que indica
el grafo que ha de utilizarse como grafo por defecto. Esta asignación no
se realiza considerando el grafo como un grafo con nombre.
En este ejemplo, el conjunto de datos RDF contienen un sencillo grafo por defecto y ningún grafo con nombre:
# Default graph (stored at http://example.org/foaf/aliceFoaf) @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:[email protected]> .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name FROM <http://example.org/foaf/aliceFoaf> WHERE { ?x foaf:name ?name }
name |
---|
"Alice" |
Si la consulta proporciona más de una cláusula FROM
,
proporcionando más de una referencia IRI para indicar el grafo por
defecto, entonces el grafo por defecto se basa en la unión RDF de los grafos obtenidos a partir de las
representaciones de los recursos identificados por las IRIs suministradas.
Una consulta puede proporcionar IRIs para grafos con nombre en el
conjunto de datos RDF utilizando la cláusula FROM NAMED
.
Cada IRI se utiliza para proporcionar un grafo con nombre al conjunto de
datos RDF. Usando la misma IRI en dos o más cláusulas FROM NAMED
tiene como consecuencia que un grafo con nombre con dicha IRI aparezca en
el conjunto de datos.
# Graph: http://example.org/bob @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Bob" . _:a foaf:mbox <mailto:[email protected]> .
# Graph: http://example.org/alice @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:[email protected]> .
... FROM NAMED <http://example.org/alice> FROM NAMED <http://example.org/bob> ...
La sintaxis de FROM NAMED
sugiere que las referencias IRI
identifican los grafos correspondientes, pero en un conjunto de datos RDF
la relación entre una IRI y un grafo es indirecta. La referencia IRI
identifica un recurso, y el recurso es representado por un grafo (o de un
modo más preciso: a través de un documento que serializa un grafo). For más detalles
véase [WEBARCH].
Las cláusulas FROM
y FROM NAMED
pueden usarse
en la misma consulta.
# Default graph (stored at http://example.org/dft.ttl) @prefix dc: <http://purl.org/dc/elements/1.1/> . <http://example.org/bob> dc:publisher "Bob Hacker" . <http://example.org/alice> dc:publisher "Alice Hacker" .
# Named graph: http://example.org/bob @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Bob" . _:a foaf:mbox <mailto:[email protected]> .
# Named graph: http://example.org/alice @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:[email protected]> .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX dc: <http://purl.org/dc/elements/1.1/> SELECT ?who ?g ?mbox FROM <http://example.org/dft.ttl> FROM NAMED <http://example.org/alice> FROM NAMED <http://example.org/bob> WHERE { ?g dc:publisher ?who . GRAPH ?g { ?x foaf:mbox ?mbox } }
El conjunto de datos RDF para esta consulta contiene un grafo por defecto
y dos grafos con nombre. La cláusula GRAPH
se describe más
adelante.
Las acciones requeridas para construir el conjunto de datos no son
determinadas únicamente por la descripción del conjunto de datos. Si se
proporciona dos veces una misma referencia IRI en una descripción de
conjunto de datos, The actions required to construct the dataset are not
determined by the dataset description alone. If an IRI is given twice in a
dataset description, ya sea usando dos cláusulas FROM
, o una
cláusula FROM
y una clásula FROM NAMED
,
entonces no se asume que se hagan únicamente uno o dos intentos para
obtener un grafo RDF asociado con la IRI. Por tanto, no se pueden hacer
suposiciones sobre la identidad del nodo en blanco en las tripletas que se
han obtenida a partir de las dos ocurrencias en la descripción del
conjunto de datos. En general, no se pueden hacer suposiciones acerca de
la equivalencia de los grafos.
Al consultar una colección de grafos, la cláusula GRAPH
se
utiliza para encontrar concordancias entre patrones y grafos con nombre.
La cláusula GRAPH
puede proporcionar una referencia IRI para
seleccionar un grafo o para usar una variable que se aplicará en las
referencias IRI de todos grafos con nombre del conjunto de datos de la
consulta.
El uso de la cláusula GRAPH
cambia el grafo activo para la
concordancia con patrones de grafo básicos que forman parte de la
consulta. Fuera del uso de la cláusula GRAPH
, se buscan
concordancias del patrones de grafo básicos con el grafo por defecto.
Los siguientes dos grafos se utilizarán en los ejemplos:
# Named graph: http://example.org/foaf/aliceFoaf @prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:[email protected]> . _:a foaf:knows _:b . _:b foaf:name "Bob" . _:b foaf:mbox <mailto:[email protected]> . _:b foaf:nick "Bobby" . _:b rdfs:seeAlso <http://example.org/foaf/bobFoaf> . <http://example.org/foaf/bobFoaf> rdf:type foaf:PersonalProfileDocument .
# Named graph: http://example.org/foaf/bobFoaf @prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . _:z foaf:mbox <mailto:[email protected]> . _:z rdfs:seeAlso <http://example.org/foaf/bobFoaf> . _:z foaf:nick "Robert" . <http://example.org/foaf/bobFoaf> rdf:type foaf:PersonalProfileDocument .
[24] |
GraphGraphPattern |
::= | 'GRAPH' VarOrIRIref GroupGraphPattern |
La siguiente consulta busca concordancias de patrones de grafo en cada
uno de los grafos con nombre del conjunto de datos, y forma las
soluciones que contienen la variable src
vinculada a las
referencias IRI de los grafos que concuerdan. El patrón de grafo
concuerda con el grafo activo que es cada uno de los grafos con nombre
del conjunto de datos.
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?src ?bobNick FROM NAMED <http://example.org/foaf/aliceFoaf> FROM NAMED <http://example.org/foaf/bobFoaf> WHERE { GRAPH ?src { ?x foaf:mbox <mailto:[email protected]> . ?x foaf:nick ?bobNick } }
El resultado de la consulta devuelve el nombre de los grafos donde se encontró la información, así como el valor del nick de Bob:
src | bobNick |
---|---|
<http://example.org/foaf/aliceFoaf> | "Bobby" |
<http://example.org/foaf/bobFoaf> | "Robert" |
La consulta puede restringir la concordancia a aplicar sobre un grafo
específico proporcionando la referencia IRI del mismo. De esta forma se
establece el grafo activo como el grafo nombrado por dicha IRI. La
consulta busca el nick de Bob, tal y como se indica, en el grafo http://example.org/foaf/bobFoaf
.
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX data: <http://example.org/foaf/> SELECT ?nick FROM NAMED <http://example.org/foaf/aliceFoaf> FROM NAMED <http://example.org/foaf/bobFoaf> WHERE { GRAPH data:bobFoaf { ?x foaf:mbox <mailto:[email protected]> . ?x foaf:nick ?nick } }
lo que devuelve una única solución:
nick |
---|
"Robert" |
Una variable utilizada en una cláusula GRAPH
puede usarse
también en otra cláusula GRAPH
o en el patrón de grafo
para la concordancia con el grafo por defecto del conjunto de datos.
La siguiente consulta usa el grafo con IRI http://example.org/foaf/aliceFoaf
para encontrar el documento de perfil para Bob; si es así concuerda otro
patrón con el grafo. El patrón en la segunda cláusula GRAPH
encuentra el nodo en blanco (variable w
) para la persona
con el mismo buzón de correo electrónico (indicado por la variable mbox
)
tal y como se encuentra en la primera cláusula GRAPH
(variable whom
), debido a que el nodo en blanco usado para
la concordancia con la variable whom
del fichero FOAF de
Alice no es el mismo que el nodo en blanco del documento de perfil (ya
que se encuentran en grafos diferentes).
PREFIX data: <http://example.org/foaf/> PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> SELECT ?mbox ?nick ?ppd FROM NAMED <http://example.org/foaf/aliceFoaf> FROM NAMED <http://example.org/foaf/bobFoaf> WHERE { GRAPH data:aliceFoaf { ?alice foaf:mbox <mailto:[email protected]> ; foaf:knows ?whom . ?whom foaf:mbox ?mbox ; rdfs:seeAlso ?ppd . ?ppd a foaf:PersonalProfileDocument . } . GRAPH ?ppd { ?w foaf:mbox ?mbox ; foaf:nick ?nick } }
mbox | nick | ppd |
---|---|---|
<mailto:[email protected]> | "Robert" | <http://example.org/foaf/bobFoaf> |
Cualquier tripleta del fichero FOAF de Alice, dando el nick
de Bob no se utiliza para proporcionar un nick para Bob, debido a que el
patrón en el que participa la variable nick
está restringida
por ppd
a un documento de perfil personal en particular.
Los patrones de consulta pueden involucrar al grafo por defecto y a grafos con nombre. En este ejemplo, un agregador ha leido un recurso web en dos ocasiones diferentes. Cada vez que el agregador lee un grafo, el sistema local proporciona una referencia IRI. Los grafos con casi iguales, pero la dirección de correo electrónico de "Bob" ha cambiado.
En este ejemplo, el grafo por defecto se utiliza para registrar la
información de procedencia y los datos RDF actualmente leídos se almacenan
en dos grafos separados, para los que el sistema proporciona IRIs
diferentes. El conjunto de datos RDF consiste en dos grafos con nombre y
la información sobre los mismos.
Conjunto de datos RDF:
# Default graph @prefix dc: <http://purl.org/dc/elements/1.1/> . @prefix g: <tag:example.org,2005-06-06:> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . g:graph1 dc:publisher "Bob" . g:graph1 dc:date "2004-12-06"^^xsd:date . g:graph2 dc:publisher "Bob" . g:graph2 dc:date "2005-01-10"^^xsd:date .
# Graph: locally allocated IRI: tag:example.org,2005-06-06:graph1 @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:[email protected]> . _:b foaf:name "Bob" . _:b foaf:mbox <mailto:[email protected]> .
# Graph: locally allocated IRI: tag:example.org,2005-06-06:graph2 @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:[email protected]> . _:b foaf:name "Bob" . _:b foaf:mbox <mailto:[email protected]> .
Esta consulta encuentra direcciones de correo electrónico, detallando el nombre de la persona y la fecha en la que se descubrió la información.
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX dc: <http://purl.org/dc/elements/1.1/> SELECT ?name ?mbox ?date WHERE { ?g dc:publisher ?name ; dc:date ?date . GRAPH ?g { ?person foaf:name ?name ; foaf:mbox ?mbox } }
Los resultados muestran que la dirección de correo electrónico para "Bob" ha cambiado.
name | mbox | date |
---|---|---|
"Bob" | <mailto:[email protected]> | "2004-12-06"^^xsd:date |
"Bob" | <mailto:[email protected]> | "2005-01-10"^^xsd:date |
La referencia IRI para el tipo de dato fecha (date) se ha abreviado en los resultados para mayor claridad.
Los patrones de consulta generarán una colección desordenada de
soluciones, siendo cada solución
una función parcial de las variables a los términos RDF. Estas soluciones
son tratadas entonces como una secuencia (una secuencia de solución),
inicialmente sin orden específico; los modificadores de secuencia son
aplicados entonces para crear otra secuencia. Finalmente, esta última
secuencia se usa para generar uno de los resultados de una forma
de consulta SPARQL..
Un modificador de secuencia de solución puede ser alguno de los siguientes:
Los modificadores se aplican en el orden dado por la lista anterior.
[5] |
SelectQuery |
::= | 'SELECT' (
'DISTINCT' |
'REDUCED' )? ( Var+
| '*' ) DatasetClause*
WhereClause SolutionModifier |
[14] |
SolutionModifier |
::= | OrderClause?
LimitOffsetClauses? |
[15] |
LimitOffsetClauses |
::= | ( LimitClause
OffsetClause? | OffsetClause
LimitClause? ) |
[16] |
OrderClause |
::= | 'ORDER' 'BY' OrderCondition+ |
La clausula ORDER BY
establece el orden de una secuencia de
solución.
Después de la cláusula ORDER BY
hay una secuencia de
elementos de comparación de orden, compuesta de una expresión y un
modificador de orden opcional (ASC()
o DESC()
).
Cada
comparador de orden es ascendente (indicado por el modificador ASC()
o por ningún modificador) o descendente (indicado por el modificador DESC()
).
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?name
WHERE { ?x foaf:name ?name }
ORDER BY ?name
PREFIX : <http://example.org/ns#>
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
SELECT ?name
WHERE { ?x foaf:name ?name ; :empId ?emp }
ORDER BY DESC(?emp)
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?name
WHERE { ?x foaf:name ?name ; :empId ?emp }
ORDER BY ?name DESC(?emp)
El operador
"<" (vea las secciones 11.3
Conversión de operadores y 11.3.1
Extensibilidad de Operadores) define el orden relativo de pares de numerics
,
simple literals
, xsd:strings
, xsd:booleans
y xsd:dateTimes
. Los pares de IRIs se ordenan comparándolos
como simple literals
.
SPARQL también establece un orden entre algunos tipos de términos RDF que no podrían ser ordenados de otra forma:
Un literal simple (plain literal) es inferior a un literal RDF con tipo xsd:string
de la misma forma léxica.
SPARQL no define un orden general de todos los posibles términos RDF. A continuación se incluyen algunos ejemplos de pares de términos para los que no está definido el orden relativo:
Esta lista de vínculos de variables es ascendente:
Término RDF | Razón |
---|---|
Los resultados no asignados son ordenados primeros. | |
_:z |
Los nodos en blanco siguen a los no asignados. |
_:a |
No hay un orden relativo de los nodos en blanco. |
<http://script.example/Latin> |
Los IRIs siguen a los nodos en blanco. |
<http://script.example/ Кириллица > |
El caracter en la 23º posición, "
|
<http://script.example/ 漢字 >
|
El caracter en la 23º posición, "漢 ", tiene un punto
decódigo Unicode 0x6F22, que es mayor que 0x41A ("
|
"http://script.example/Latin" |
Los literales simples siguen a los IRIs. |
"http://script.example/Latin"^^xsd:string |
Los tipos xsd:strings siguen a los literales simples. |
El orden ascendente de dos soluciones con respecto a un comparador de ordenación se establece mediante la sustitución de los vinculos de la solución en las expresiones y la comparación de ellas con el operador "<". El orden descendente es el inverso del orden ascendente.
El orden relativo de dos soluciones es el orden relativo de las dos soluciones con respecto al primer comparador de ordenación en la secuencia. Para soluciones en las que las sustituciones de los vinculos de soluciones producen el mismo término RDF, el orden es el orden relativo de las dos soluciones con respecto al siguiente comparador de ordenación. El orden relativo de las dos soluciones es indefinido si ninguna expresión de orden evaluada para las dos soluciones produce distintos términos RDF.
La ordenación de una secuencia de soluciones siempre da lugar a una secuencia con el mismo número de soluciones en ella.
La utilización del modificador ORDER BY
en una secuencia de
solución para una consulta del tipo CONSTRUCT
o DESCRIBE
no tiene efecto directo ya que únicamente SELECT
devuelve
una secuencia de resultados. Cuando se utiliza en combinación con los
modificadores LIMIT
y OFFSET
, ORDER BY
puede ser usado para devolver resultados generados desde una porción
diferente de la secuencia de soluciones. Una consulta ASK
no
incluye los modificadores ORDER BY
, LIMIT
u OFFSET
.
[16] |
OrderClause |
::= | 'ORDER' 'BY' OrderCondition+ |
[17] |
OrderCondition |
::= | ( ( 'ASC'
| 'DESC' ) BrackettedExpression
) |
[18] |
LimitClause |
::= | 'LIMIT' INTEGER |
[19] |
OffsetClause |
::= | 'OFFSET' INTEGER |
La secuencia de soluciones puede ser transformada en una secuencia que implica sólo un subconjunto de variables. Para cada solución de la secuencia, se forma una nueva solución con una selección determinada de las variables utilizando la forma de consulta SELECT.
El siguiente ejemplo muestra una consulta para extraer sólo los nombres de las personas descritas en un grafo RDF utilizando las propiedades FOAF:
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
_:a foaf:name "Alice" .
_:a foaf:mbox <mailto:[email protected]> .
_:b foaf:name "Bob" .
_:b foaf:mbox <mailto:[email protected]> .
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?name
WHERE
{ ?x foaf:name ?name }
name |
---|
"Bob" |
"Alice" |
Una secuencia de soluciones sin modificador de consulta DISTINCT
o REDUCED
conservará las soluciones duplicadas.
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
_:x foaf:name "Alice" .
_:x foaf:mbox <mailto:[email protected]> .
_:y foaf:name "Alice" .
_:y foaf:mbox <mailto:[email protected]> .
_:z foaf:name "Alice" .
_:z foaf:mbox <mailto:[email protected]> .
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?name WHERE { ?x foaf:name ?name }
name |
---|
"Alice" |
"Alice" |
"Alice" |
Los modificadores DISTINCT
y REDUCED
controlan si los duplicados se incluyen en los resultados de la
consulta.
El modificador DISTINCT
elimina soluciones duplicadas.
Específicamente, se elimina del conjunto de soluciones cada solución
que vincule las mismas variables con el mismo término RDF como otra
solución.
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT DISTINCT ?name WHERE { ?x foaf:name ?name }
name |
---|
"Alice" |
Obsérvese que, por el orden de modificadores de las secuencias de soluciones, los duplicados son eliminados antes de que se apliquen los modificadores limit u offset.
Mientras que el modificador DISTINCT
asegura la
eliminación de lassoluciones duplicadas del conjunto de soluciones, el
modificador REDUCED
simplemente les permite ser
eliminadas. La cardinalidad de unconjunto de vinculos de variables en un
conjunto de soluciones REDUCED
de al menos uno y no mayor
que la cardinalidad de los conjuntos desoluciones sin modificadores DISTINCT
o REDUCED
. Por ejemplo, utilizando los datosanteriores, la
consulta
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT REDUCED ?name WHERE { ?x foaf:name ?name }
puede tener uno, dos (aquí mostradas) o tres soluciones:
name |
---|
"Alice" |
"Alice" |
El modificador OFFSET
produce que las soluciones generadas
empiecen después de un número especificado de so luciones. El valor de
cero para OFFSET
no tiene efecto.
El uso de los modificadores LIMIT
y OFFSET
para seleccionar diferentes subconjuntos de soluciones de la consulta no
será útil a menos que el orden sea predecible mediante el modificador ORDER
BY
.
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?name
WHERE { ?x foaf:name ?name }
ORDER BY ?name
LIMIT 5
OFFSET 10
La cláusula LIMIT
establece un límite superior al número
de soluciones devueltas. Si el número de soluciones reales es mayor que el
límite, entonces como mucho serán devueltas el número límite de
soluciones.
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?name
WHERE { ?x foaf:name ?name }
LIMIT 20
El valor de cero para LIMIT
causaría que no se devolvieran
resultados. Un límite no puede ser negativo.
SPARQL tiene cuatro formas de consulta. Estas formas de consulta usan las soluciones que concuerdan con el patrón para formar los conjuntos de resultados o grafos RDF. Las formas de consulta son:
- SELECT
- Devuelve todo, o un subconjunto de las variables vinculadas en una concordancia con un patrón de búsqueda
- CONSTRUCT
- Devuelve un grafo RDF construido mediante la sustitución de variables en un conjunto de plantillas de tripleta.
- ASK
- Devuelve un valor booleano indicando si se encuentra o no una concordancia para un patrón de consulta.
- DESCRIBE
- Devuelve un grafo RDF que describe los recursos encontrados.
Puede usarse el Formato
XML de los resultados de variables vinculadas SPARQL para serializar
el conjunto de resultados de una consulta SELECT
o el
resultado booleano de una consulta ASK
.
La forma de los resultados de SELECT devuelve las variables y sus
vinculaciones directamente. La sintaxis SELECT *
es una
abreviación que selecciona todas las variables de una consulta.
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:knows _:b . _:a foaf:knows _:c . _:b foaf:name "Bob" . _:c foaf:name "Clare" . _:c foaf:nick "CT" .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?nameX ?nameY ?nickY WHERE { ?x foaf:knows ?y ; foaf:name ?nameX . ?y foaf:name ?nameY . OPTIONAL { ?y foaf:nick ?nickY } }
nameX | nameY | nickY |
---|---|---|
"Alice" | "Bob" | |
"Alice" | "Clare" | "CT" |
Se puede acceder a los conjuntos de resultados mediante una API local, pero también pueden serializarse tanto en XML como en un grafo RDF. El documento Formato XML de los resultados de consultas SPARQL describe un formato XML y proporciona este ejemplo:
<?xml version="1.0"?> <sparql xmlns="http://www.w3.org/2005/sparql-results#"> <head> <variable name="nameX"/> <variable name="nameY"/> <variable name="nickY"/> </head> <results> <result> <binding name="nameX"> <literal>Alice</literal> </binding> <binding name="nameY"> <literal>Bob</literal> </binding> </result> <result> <binding name="nameX"> <literal>Alice</literal> </binding> <binding name="nameY"> <literal>Clare</literal> </binding> <binding name="nickY"> <literal>CT</literal> </binding> </result> </results> </sparql>
[5] |
SelectQuery |
::= | 'SELECT' (
'DISTINCT' |
'REDUCED' )? ( Var+ | '*'
) |
La forma de consulta CONSTRUCT
devuelve un único grafo RDF
especificado por un plantilla de grafo. El resultado es un grafo RDF
formado al tomar cada solución de la consulta de la secuencia de solución,
sustituyendo las variables en la plantilla de grafo, y combinando las
tripletas en un único grafo RDF mediante la unión de conjuntos.
Si cualquier instancia produce una tripleta que contenga una variable no
vinculada o una construcción RDF no válida, como un literal en las
posiciones del sujeto o precidado, entonces esa tripleta no se incluye en
la salida del grafo RDF. La plantilla del grafo puede contener tripletas
sin variables (conocidas como base o tripletas explícitas), y éstas
también aparecen en la salida del grafo RDF devuelta por la forma de
consulta CONSTRUCT.
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:[email protected]> .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX vcard: <http://www.w3.org/2001/vcard-rdf/3.0#> CONSTRUCT { <http://example.org/person#Alice> vcard:FN ?name } WHERE { ?x foaf:name ?name }
crea las propiedades vcard para la información FOAF:
@prefix vcard: <http://www.w3.org/2001/vcard-rdf/3.0#> . <http://example.org/person#Alice> vcard:FN "Alice" .
Una plantilla puede crear un grafo RDF conteniendo nodos en blanco. Las etiquetas de de los nodos en blanco pertenecen al ámbito de la plantilla para cada solución. Si la misma etiqueta aparece dos veces en una plantilla, entonces existe un nodo en blanco creado para cada solución, pero al mismo tiempo hay diferentes nodos en blanco para las tripletas generadas por diferentes soluciones de la consulta.
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:givenname "Alice" . _:a foaf:family_name "Hacker" . _:b foaf:firstname "Bob" . _:b foaf:surname "Hacker" .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX vcard: <http://www.w3.org/2001/vcard-rdf/3.0#> CONSTRUCT { ?x vcard:N _:v . _:v vcard:givenName ?gname . _:v vcard:familyName ?fname } WHERE { { ?x foaf:firstname ?gname } UNION { ?x foaf:givenname ?gname } . { ?x foaf:surname ?fname } UNION { ?x foaf:family_name ?fname } . }
la anterior consulta crea propiedades vcard correspondiente a la información de FOAF:
@prefix vcard: <http://www.w3.org/2001/vcard-rdf/3.0#> . _:v1 vcard:N _:x . _:x vcard:givenName "Alice" . _:x vcard:familyName "Hacker" . _:v2 vcard:N _:z . _:z vcard:givenName "Bob" . _:z vcard:familyName "Hacker" .
El uso de la variable x
en la plantilla, que en este
ejemplo se vincula con los nodos en blanco con etiquetas _:a
y _:b
de los datos, produce diferentes etiquetas de nodos en
blanco (_:v1
y _:v2
) en el grafo RDF
resultante.
Empleando CONSTRUCT
, es posible extraer partes de la
totalidad de los grafos del conjunto destino de datos RDF. Este primer
ejemplo devuelve el grafo (si se encuentra en el conjunto de datos)
etiquetado con la referencia IRI http://example.org/aGraph
;
en caso contrario, devuelve un grafo vacío.
CONSTRUCT { ?s ?p ?o } WHERE { GRAPH <http://example.org/aGraph> { ?s ?p ?o } . }
El acceso al grafo puede estar condicionado por otra información. Por ejemplo, si el grafo por defecto contiene metadatos sobre los grafos con nombre en el conjunto de datos, entonces una consulta como la siguiente puede extraer un grafo basado en información sobre un grafo con nombre:
PREFIX dc: <http://purl.org/dc/elements/1.1/> PREFIX app: <http://example.org/ns#> CONSTRUCT { ?s ?p ?o } WHERE { GRAPH ?g { ?s ?p ?o } . { ?g dc:publisher <http://www.w3.org/> } . { ?g dc:date ?date } . FILTER ( app:customDate(?date) > "2005-02-28T00:00:00Z"^^xsd:dateTime ) . }
donde app:customDate
identifica una función
de extensión para transformar los datos al formato del término RDF xsd:dateTime
.
[6] |
ConstructQuery |
::= | 'CONSTRUCT'
ConstructTemplate |
Los modificadores de solución de una consulta afectan a los resultados de
una consulta CONSTRUCT
. En este ejemplo, el grafo de salida
de la plantilla CONSTRUCT
está formado a partir de dos de
las soluciones de la correspondencia del patrón de grafo. La consulta
produce un grafo con los nombres de las personas de los dos sitios web más
consultados. Las tripletas del grafo RDF no están ordenadas.
@prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix site: <http://example.org/stats#> . _:a foaf:name "Alice" . _:a site:hits 2349 . _:b foaf:name "Bob" . _:b site:hits 105 . _:c foaf:name "Eve" . _:c site:hits 181 .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX site: <http://example.org/stats#> CONSTRUCT { [] foaf:name ?name } WHERE { [] foaf:name ?name ; site:hits ?hits . } ORDER BY desc(?hits) LIMIT 2
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:x foaf:name "Alice" . _:y foaf:name "Eve" .
Las aplicaciones puede utilizar la forma ASK
para comprobar
si un patrón de consulta tiene solución. No se devuelve información alguna
sobre las posibles soluciones a la consulta, únicamente si existe o no una
solución.
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:homepage <http://work.example.org/alice/> . _:b foaf:name "Bob" . _:b foaf:mbox <mailto:[email protected]> .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> ASK { ?x foaf:name "Alice" }
yes
El Formato XML de los resultados de consultas SPARQL estructura estos resultados del siguiente modo:
<?xml version="1.0"?> <sparql xmlns="http://www.w3.org/2005/sparql-results#"> <head></head> <results> <boolean>true</boolean> </results> </sparql>
Sobre los mismos datos, la siguiente consulta no devuelve ninguna
concordancia al no mercionarse el mbox
de Alice.
PREFIX foaf: <http://xmlns.com/foaf/0.1/> ASK { ?x foaf:name "Alice" ; foaf:mbox <mailto:[email protected]> }
no
[8] |
AskQuery |
::= | 'ASK' DatasetClause*
WhereClause |
La forma DESCRIBE
devuelve como resultado un único grafo
RDF con datos sobre recursos. Estos datos no son prescritos por una
consulta SPARQL, donde el cliente que realiza la consulta tendría que
conocer la estructura RDF en la fuente de datos, pero, en cambio, está
determinado por el procesador de consultas SPARQL. El patrón de consulta
es usado para crear un conjunto de resultados. La forma DESCRIBE
toma cada uno de los recursos identificados en una solución, junto con
otros recursos directamente nombrados mediante una IRI, y construye un
único grafo RDF tomando una "descripción" que puede provenir de cualquier
información disponible, incluyendo el conjunto destino de datos RDF
objeto. La descripción está determinada por el servicio de consulta. La
sintaxis DESCRIBE *
es una abreviación que describe todas
las variables en una consulta.
La cláusula DESCRIBE
por sí misma puede tomar IRIs para
identificar recursos. Precisamente, la consulta DESCRIBE
más
simple es una referencia IRI en la cláusula DESCRIBE
:
DESCRIBE <http://example.org/>
Los recursos descritos también pueden obtenerse a partir de las vinculaciones de una variable de la consulta en el conjunto de resultados. Esto permite describir recursos identificados mediante IRI o nodo en blanco en el conjunto de datos:
PREFIX foaf: <http://xmlns.com/foaf/0.1/> DESCRIBE ?x WHERE { ?x foaf:mbox <mailto:alice@org> }
La propiedad foaf:mbox
se define como una propiedad
funcional inversa en el vocabulario FOAF. Si se trata como tal, esta
consulta devolverá información sobre más de una persona. Sin embargo, si
el patrón de consulta tiene múltiples soluciones, los datos RDF para cada
una es la unión de todas las descripciones de grafos RDF.
PREFIX foaf: <http://xmlns.com/foaf/0.1/> DESCRIBE ?x WHERE { ?x foaf:name "Alice" }
Se pueden proporcionar más de una IRI o variable:
PREFIX foaf: <http://xmlns.com/foaf/0.1/> DESCRIBE ?x ?y <http://example.org/> WHERE {?x foaf:knows ?y}
El RDF obtenido está determinado por la información del editor. Se trata de la información útil que el servicio dispone sobre un recurso. Puede incluir información sobre otros recursos: por ejemplo, los datos RDF de un libro también puede incluir detalles sobre su autor.
Un consulta sencilla como
PREFIX ent: <http://org.example.com/employees#> DESCRIBE ?x WHERE { ?x ent:employeeId "1234" }
podría devolver una descripción de los empleados y otros detalles potencialmente útiles:
@prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix vcard: <http://www.w3.org/2001/vcard-rdf/3.0> . @prefix exOrg: <http://org.example.com/employees#> . @prefixrdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix owl: <http://www.w3.org/2002/07/owl#>
_:a exOrg:employeeId "1234" ;foaf:mbox_sha1sum "ABCD1234" ;
vcard:N [ vcard:Family "Smith" ; vcard:Given "John" ] .foaf:mbox_sha1sum rdf:type owl:InverseFunctionalProperty .
que incluye el nodo en blanco determinado por el vocabulario vcard vcard:N. Otros posibles mecanismos para decidir qué información devolver incluyen las Descripciones Concisas Acotadas [CBD].
Para un vocabulario como FOAF, donde los recursos son típicamente nodos
en blanco, devolver suficiente información para identificar un nodo como
la propiedad funcional inversa foaf:mbox_sha1sum
así como
información como el nombre y otros detalles registrados podría resultar
apropiado. En el ejemplo, se devuelve una concordancia con la cláusula
WHERE, pero esto no es preciso.
[7] |
DescribeQuery |
::= | 'DESCRIBE'
( VarOrIRIref+ | '*'
) |
Las cláusulas FILTER
de SPARQL restringen las soluciones de
una concordancia de patrón de grafo conforme a una determinada expresión.
Específicamente, los términos FILTER
eliminan todas las
soluciones que, cuando se sustituye en la expresión, dan lugar a un valor
efectivo booleano de false
o producen un error. Los valores
booleanos efectivos se definen en la Sección 11.2.2
Valor booleano efectivo y los errores en el apartado 2.3.1 Tipos de errores de la especificación
XQuery 1.0: Un lenguaje de consulta XML [XQUERY].
Estos errores no tienen efectos fuera de la evaluación FILTER
.
Los literales de RDF puede tener un tipo de datos IRI:
@prefix a: <http://www.w3.org/2000/10/annotation-ns#> .
@prefix dc: <http://purl.org/dc/elements/1.1/> .
_:a a:annotates <http://www.w3.org/TR/rdf-sparql-query/> .
_:a dc:date "2004-12-31T19:00:00-05:00" .
_:b a:annotates <http://www.w3.org/TR/rdf-sparql-query/> .
_:b dc:date "2004-12-31T19:01:00-05:00"^^<http://www.w3.org/2001/XMLSchema#dateTime> .
El objeto del primer triplete dc:date
no tiene
información de tipo. El segundo tiene un tipo de datos xsd:dateTime
.
Las expresiones SPARQL se construyen de acuerdo a la gramática yproporcionan acceso a funciones (nombradas por la IRI) y operadores de funciones (invocadas mediante palabras clave y símbolos en la gramática SPARQL). Los operadores SPARQL pueden ser usados para comparar los valores de los literales tipados:
PREFIX a: <http://www.w3.org/2000/10/annotation-ns#>
PREFIX dc: <http://purl.org/dc/elements/1.1/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
SELECT ?annot
WHERE { ?annot a:annotates <http://www.w3.org/TR/rdf-sparql-query/> .
?annot dc:date ?date .
FILTER ( ?date > "2005-01-01T00:00:00Z"^^xsd:dateTime ) }
Los operadores SPARQL se listan el la sección 11.3 y se asocian con sus producciones en la gramática.
Además, SPARQL permite invocar funciones arbitrarias, incluyendo un subconjunto de las funciones de conversión (casting functions) de XPath, listadas en la sección 11.5. Estas funciones son invocadas por su nombre (un IRI) dentro de una consulta SPARQL. Por ejemplo:
... FILTER ( xsd:dateTime(?date) < xsd:dateTime("2005-01-01T00:00:00Z") ) ...
En esta sección se utilizan las convenciones de texto siguientes:
op:
.
Los operadores XPath no tienen ningún espacio de nombres; op:
es una convención de etiquetado.Las funciones y operadores SPARQL se aplican sobre términos RDF y
variables SPARQL . Un subconjunto de estas funciones y operadores se
toma del documento XQuery
1.0 y XPath 2.0 Funciones y Operadores [FUNCOP]
y tienen como argumentos y tipos de valor devuelto el valor
tipado de XML Schema.
Los literales tipados
RDF pasados
como argumentos a estas funciones y operadores se convierten a valores
tipados de XML Schema con un valor
de cadena
del tipo forma léxica
y un tipo
de datos atómico
correspondiente al tipo de datos IRI.
Los valores tipados devueltos se reconvierten de la misma forma a literales
tipados
RDF.
SPARQL tiene operadores adicionales que operan sobre los subconjuntos
específicos de términos RDF. En referencia a un tipo, los siguientes
términos denotan un literal tipado
con el correspondiente tipo de datos IRI
de XML
Schema [XSDT]:
Los siguientes términos identifican adicionalmente tipos usados en comprobaciones de valores en SPARQL:
literales
tipados
con tipos de datos xsd:integer
, xsd:decimal
,
xsd:float
, y xsd:double
. literal simple
sin etiqueta
de idioma
.IRI
, literal
,
y nodo en blanco
.Los siguientes tipos se derivan de los tipos numéricos y son argumentos válidos para funciones y operadores que acepten argumentos numéricos :
xsd:nonPositiveInteger
xsd:negativeInteger
xsd:long
xsd:int
xsd:short
xsd:byte
xsd:nonNegativeInteger
xsd:unsignedLong
xsd:unsignedInt
xsd:unsignedShort
xsd:unsignedByte
xsd:positiveInteger
Las extensiones de lenguaje SPARQL pueden tratar tipos adicionales como derivados de tipos de datos de XML Schema.
SPARQL proporciona un subconjunto de funciones definidos por XQuery en la sección Correspondencia de Operadores. La sección 2.2.3 Procesamiento de expresiones de la especificación XQuery 1.0 describe la invocación de funciones XPath. Las siguientes reglas describen lasdiferencias en los modelos de datos y ejecución entre XQuery y SPARQL:
xsd:boolean
usando las reglas
EBV de la sección 11.2.2.||
) o logical-and
(&&
)
que encuentre un error producirá ese error.La tabla de verdad de logical-and y logical-or para verdadero (T), falso (F), y error (E) es la siguiente:
A | B | A || B | A && B |
---|---|---|---|
T | T | T | T |
T | F | T | F |
F | T | T | F |
F | F | F | F |
T | E | T | E |
E | T | T | E |
F | E | E | F |
E | F | E | F |
E | E | E | E |
SPARQL define una sintaxis para la invocación de funciones yoperadores sobre una lista de argumentos. Estos se invocan de la siguiente forma:
Si cualquiera de estos pasos falla, la invocación genera un error. Los efectos de los errores se definen en la sección 11.2 Evaluación de filtro.
El valor efectivo booleano (effective boolean value), o valor EBV, se
utiliza para calcular los
argumentos de las funciones lógicas logical-and,
logical-or,
y fn:not,
y para evaluar el resultado de una expresión FILTER
.
Las reglas de Effective
Boolean Value de XQuery se basan en la definición de fn:boolean
de XPath. Las siguientes reglas reflejan las reglas las reglas para fn:boolean
aplicadas a los tipos de argumentos presentes en las consultas de SPARQL:
xsd:boolean
o numérico es falso si la forma
léxica no es válida para ese tipo de datos (por ejemplo
"abc"^^xsd:integer).xsd:boolean
,
el valor EBV es el valor de ese argumento.xsd:string
, el
valor EBV es falso si el valor del operando tiene una longitud cero; de
lo contrario, el valor EBV es verdadero.Un valor EBV true
se representa como un literal
tipado con un tipo de datos xsd:boolean
y un valor
léxico de "true"; un EBV false se representa como un literal
tipado con un tipo de datos xsd:boolean
y un valor
léxico de "false".
La gramática SPARQL identifica un conjunto de operadores (por ejemplo, &&, *, isIRI)
utilizados para la construcción de restricciones. La siguiente
tabla asocia cada una de estas producciones gramaticales con los operandos
apropiados y una función de operador definida en el documento XQuery 1.0 y XPath 2.0 Funciones and Operadores [FUNCOP]
o los operadores SPARQL especificados en la sección
11.4. En la selección de la definición del operador para un conjunto
dado de
parámetros, se aplica la definición con los parámetros más específicos.
Por ejemplo, en la evaluación de xsd:integer = xsd:signedInt
,
se aplica la definición para =
con dos parámetros numeric
,
en lugar de una con dos términos RDF.
La tabla está dispuesta de forma que el candidato más viable es el más
específico. Los operadores invocados sin los operandos
apropiados producirán un error de tipo.
SPARQL sigue el esquema de XPath para las promociones de tipo numéricoy
la sustitución de subtipo para los argumentos de los operadores
numéricos. Las reglas de convesión
de operadores de XPath para operandos numéricos
(xsd:integer
,
xsd:decimal
, xsd:float
, xsd:double
,
y tipos derivados de un tipo numérico)
se aplican también a los operadores SPARQL (véase la especificación XML Path Language (XPath) 2.0
[XPATH20]
para definiciones de promociones
de tipos numéricos
y sustitución
de subtipos). Algunos de los operadores se asocian con expresiones
de función anidadas, por ejemplo fn:not(op:numeric-equal(A, B))
.
Tenga en cuenta que de acuerdo con las definiciones de XPath, fn:not
y op:numeric-equal
producirán un error si su argumento es un
error.
La colación para la función fn:compare
se define mediante XPath y se
identifica mediante http://www.w3.org/2005/xpath-functions/collation/codepoint
.
Esta colación permite la comparación de cadenas basadas en valores de
punto de código. La equivalencia de puntos de código de cadenas se
puede probar con la equivalencia de término
RDF.
Operador | Tipo(A) | Función | Tipo del resultado | |
---|---|---|---|---|
Operadores Unarios XQuery | ||||
! A | xsd:boolean (EBV) | fn:not(A) | xsd:boolean | |
+ A | numérico | op:numeric-unary-plus(A) | numerico | |
- A | numérico | op:numeric-unary-minus(A) | numerico | |
Comprobaciones SPARQL, definidas en la sección 11.4 | ||||
BOUND(A) | variable | bound(A) | xsd:boolean | |
isIRI(A) isURI(A) |
término RDF | isIRI(A) | xsd:boolean | |
isBLANK(A) | término RDF | isBlank(A) | xsd:boolean | |
isLITERAL(A) | término RDF | isLiteral(A) | xsd:boolean | |
Descriptores de acceso SPARQL, definidos en la sección 11.4 | ||||
STR(A) | literal | str(A) | literal simple | |
STR(A) | IRI | str(A) | literal simple | |
LANG(A) | literal | lang(A) | literal simple | |
DATATYPE(A) | literal tipado |
datatype(A) | IRI | |
DATATYPE(A) | literal simple | datatype(A) | IRI |
Operador | Tipo(A) | Tipo(B) | Función | Tipo de resultado |
---|---|---|---|---|
Conectivas Lógicas, definidas en la sección 11.4 | ||||
A || B | xsd:boolean (EBV) | xsd:boolean (EBV) | logical-or(A, B) | xsd:boolean |
A && B | xsd:boolean (EBV) | xsd:boolean (EBV) | logical-and(A, B) | xsd:boolean |
Comprobaciones XPath | ||||
A = B | numérico | numérico | op:numeric-equal(A, B) | xsd:boolean |
A = B | literal simple | literal simple | op:numeric-equal(fn:compare(A, B), 0) | xsd:boolean |
A = B | xsd:string | xsd:string | op:numeric-equal(fn:compare(STR(A), STR(B)), 0) | xsd:boolean |
A = B | xsd:boolean | xsd:boolean | op:boolean-equal(A, B) | xsd:boolean |
A = B | xsd:dateTime | xsd:dateTime | op:dateTime-equal(A, B) | xsd:boolean |
A != B | numérico | numérico | fn:not(op:numeric-equal(A, B)) | xsd:boolean |
A != B | literal simple | literal simple | fn:not(op:numeric-equal(fn:compare(A, B), 0)) | xsd:boolean |
A != B | xsd:string | xsd:string | fn:not(op:numeric-equal(fn:compare(STR(A), STR(B)), 0)) | xsd:boolean |
A != B | xsd:boolean | xsd:boolean | fn:not(op:boolean-equal(A, B)) | xsd:boolean |
A != B | xsd:dateTime | xsd:dateTime | fn:not(op:dateTime-equal(A, B)) | xsd:boolean |
A < B | numérico | numérico | op:numeric-less-than(A, B) | xsd:boolean |
A < B | literal simple | literal simple | op:numeric-equal(fn:compare(A, B), -1) | xsd:boolean |
A < B | xsd:string | xsd:string | op:numeric-equal(fn:compare(STR(A), STR(B)), -1) | xsd:boolean |
A < B | xsd:boolean | xsd:boolean | op:boolean-less-than(A, B) | xsd:boolean |
A < B | xsd:dateTime | xsd:dateTime | op:dateTime-less-than(A, B) | xsd:boolean |
A > B | numérico | numérico | op:numeric-greater-than(A, B) | xsd:boolean |
A > B | literal simple | literal simple | op:numeric-equal(fn:compare(A, B), 1) | xsd:boolean |
A > B | xsd:string | xsd:string | op:numeric-equal(fn:compare(STR(A), STR(B)), 1) | xsd:boolean |
A > B | xsd:boolean | xsd:boolean | op:boolean-greater-than(A, B) | xsd:boolean |
A > B | xsd:dateTime | xsd:dateTime | op:dateTime-greater-than(A, B) | xsd:boolean |
A <= B | numérico | numérico | logical-or(op:numeric-less-than(A, B), op:numeric-equal(A, B)) | xsd:boolean |
A <= B | literal simple | literal simple | fn:not(op:numeric-equal(fn:compare(A, B), 1)) | xsd:boolean |
A <= B | xsd:string | xsd:string | fn:not(op:numeric-equal(fn:compare(STR(A), STR(B)), 1)) | xsd:boolean |
A <= B | xsd:boolean | xsd:boolean | fn:not(op:boolean-greater-than(A, B)) | xsd:boolean |
A <= B | xsd:dateTime | xsd:dateTime | fn:not(op:dateTime-greater-than(A, B)) | xsd:boolean |
A >= B | numérico | numérico | logical-or(op:numeric-greater-than(A, B), op:numeric-equal(A, B)) | xsd:boolean |
A >= B | literal simple | literal simple | fn:not(op:numeric-equal(fn:compare(A, B), -1)) | xsd:boolean |
A >= B | xsd:string | xsd:string | fn:not(op:numeric-equal(fn:compare(STR(A), STR(B)), -1)) | xsd:boolean |
A >= B | xsd:boolean | xsd:boolean | fn:not(op:boolean-less-than(A, B)) | xsd:boolean |
A >= B | xsd:dateTime | xsd:dateTime | fn:not(op:dateTime-less-than(A, B)) | xsd:boolean |
Aritmética XPath | ||||
A * B | numérico | numérico | op:numeric-multiply(A, B) | numérico |
A / B | numérico | numérico | op:numeric-divide(A, B) | numérico; pero xsd:decimal si ambos operandos son xsd:integer |
A + B | numérico | numérico | op:numeric-add(A, B) | numérico |
A - B | numérico | numérico | op:numeric-subtract(A, B) | numérico |
Tests SPARQL, definidos en la sección 11.4 | ||||
A = B | término RDF | término RDF | RDFterm-equal(A, B) | xsd:boolean |
A != B | término RDF | término RDF | fn:not(RDFterm-equal(A, B)) | xsd:boolean |
sameTERM(A) | término RDF | término RDF | sameTerm(A, B) | xsd:boolean |
langMATCHES(A, B) | literal simple | literal simple | langMatches(A, B) | xsd:boolean |
REGEX(STRING, PATTERN) | literal simple | literal simple | fn:matches(STRING, PATTERN) | xsd:boolean |
Operador | Tipo(A) | Tipo(B) | Tipo(C) | Función | Tipo de resultado |
---|---|---|---|---|---|
Tests SPARQL Tests, definidos en la sección 11.4 | |||||
REGEX(STRING, PATTERN, FLAGS) | literal simple | literal simple | literal simple | fn:matches(STRING, PATTERN, FLAGS) | xsd:boolean |
Los argumentos de función de tipo xsd:boolean marcados con "(EBV)" son forzados a xsd:boolean por la evaluación del valor booleano efectivo de ese argumento.
Las extensiones del lenguaje SPARQL pueden proporcionar conversiones adicionales entre operadores y operadores de funciones; esto equivale a agregar filas a la tabla anterior. Ningún operador adicional puede producir un resultado que sustituya a cualquier otro resultado, a excepción de un error de tipo, en la semántica definida anteriormente. La consecuencia de esta regla es que las extensiones SPARQL producirán al menos las mismas soluciones que una implementación no extendida, y pueden, en algunas consultas, producir más soluciones.
Las conversiones adicionales del operador '<' están destinadas a
controlar el orden relativo de los operandos, en particular, cuando se
utiliza en una cláusula ORDER
BY
.
Esta sección define los operadores introducidos por el Lenguaje deconsulta SPARQL. Los ejemplos muestran el comportamiento de los operadores que se invocan por las construcciones gramaticales apropiadas.
xsd:boolean
bound
(variable
var
)
Devuelve true
si var
está ligado a un valor.
Devuelve false en caso contrario. Las variables con el valor NaN o INF se
consideran ligadas.
Datos:
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
_:a foaf:givenName "Alice".
_:b foaf:givenName "Bob" .
_:b dc:date "2005-04-04T04:04:04Z"^^xsd:dateTime .
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX dc: <http://purl.org/dc/elements/1.1/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
SELECT ?name
WHERE { ?x foaf:givenName ?givenName .
OPTIONAL { ?x dc:date ?date } .
FILTER ( bound(?date) ) }
Resultado de la consulta:
givenName |
---|
"Bob" |
Podemos comprobar que un patrón de grafo no se expresa por la
definición de un patrón de grafo OPTIONAL
que introduce una variable y comprobar que la variable no está ligada (not
bound
).
Esto se llama "negación por fracaso" (Negation as Failure) en
programación lógica.
Esta consulta filtra las personas con un nombre (name
)
pero sin fecha (date
) expresada:
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX dc: <http://purl.org/dc/elements/1.1/>
SELECT ?name
WHERE { ?x foaf:givenName ?name .
OPTIONAL { ?x dc:date ?date } .
FILTER (!bound(?date)) }
Resultado de la consulta:
name |
---|
"Alice" |
Como la fecha (dc:date
) de Bob era conocida, "Bob"
no era una solución para la consulta.
xsd:boolean
isIRI
(RDF term
term
)
xsd:boolean
isURI
(RDF term
term
)
Devuelve true
si term
es un IRI.
Devuelve false
en caso contrario. isURI
es una alternativa ortográfica del operador isIRI
.
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
_:a foaf:name "Alice".
_:a foaf:mbox <mailto:[email protected]> .
_:b foaf:name "Bob" .
_:b foaf:mbox "[email protected]" .
Esta consulta filtra las personas con un nombre (name
) y
un buzón de correo (mbox
)
que es un IRI:
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?name ?mbox
WHERE { ?x foaf:name ?name ;
foaf:mbox ?mbox .
FILTER isIRI(?mbox) }
Resultado de la consulta:
name | mbox |
---|---|
"Alice" | <mailto:[email protected]> |
xsd:boolean
isBlank
(RDF term
term
)
Devuelve true
si term
es un nodo
en blanco. Devuelve false
en caso contrario.
@prefix a: <http://www.w3.org/2000/10/annotation-ns#> .
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
_:a a:annotates <http://www.w3.org/TR/rdf-sparql-query/> .
_:a dc:creator "Alice B. Toeclips" .
_:b a:annotates <http://www.w3.org/TR/rdf-sparql-query/> .
_:b dc:creator _:c .
_:c foaf:given "Bob".
_:c foaf:family "Smith".
Esta consulta filtra a las personas con un dc:creator
que usa predicados del vocabulario FOAF para expresar el nombre:
PREFIX a: <http://www.w3.org/2000/10/annotation-ns#>
PREFIX dc: <http://purl.org/dc/elements/1.1/>
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?given ?family
WHERE { ?annot a:annotates <http://www.w3.org/TR/rdf-sparql-query/> .
?annot dc:creator ?c .
OPTIONAL { ?c foaf:given ?given ; foaf:family ?family } .
FILTER isBlank(?c)
}
Resultado de la consulta:
given | family |
---|---|
"Bob" | "Smith" |
En este ejemplo, hay dos objetos de predicados foaf:knows
,
pero solo uno (_:c
) era un nodo en blanco.
xsd:boolean
isLiteral
(RDF term
term
)
Devuelve true
if term
is a literal.
Devuelve false
en caso contrario.
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
_:a foaf:name "Alice".
_:a foaf:mbox <mailto:[email protected]> .
_:b foaf:name "Bob" .
_:b foaf:mbox "[email protected]" .
Esta consulta es similar a la de la sección 11.4.2
excepto que filtra personas con un nombre (name
) y un
buzón de correo (mbox
) que es un literal. Podría usarse
para buscar datos erróneos. (foaf:mbox
puede tener sólo una IRI como su objeto).
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?name ?mbox
WHERE { ?x foaf:name ?name ;
foaf:mbox ?mbox .
FILTER isLiteral(?mbox) }
Resultados de la consulta:
name | mbox |
---|---|
"Bob" | "[email protected]" |
literal simple
str
(literal
ltrl
)
literal simple
str
(IRI
rsrc
)
Devuelve the forma lexica
de ltrl
(un literal); Devuelve la
representación de punto de código de rsrc
(una IRI).
Es
útil para examinar partes de una IRI, por ejemplo, el nombre del host.
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
_:a foaf:name "Alice".
_:a foaf:mbox <mailto:[email protected]> .
_:b foaf:name "Bob" .
_:b foaf:mbox <mailto:[email protected]> .
Esta consulta selecciona las personas que usan su dirección work.example
en su perfil foaf:
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?name ?mbox
WHERE { ?x foaf:name ?name ;
foaf:mbox ?mbox .
FILTER regex(str(?mbox), "@work.example") }
Resultados de la consulta:
name | mbox |
---|---|
"Alice" | <mailto:[email protected]> |
literal simple
lang
(literal
ltrl
)
Devuelve la etiqueta de idioma
de ltrl
,
si la tiene. Devuelve ""
si ltrl
no tiene etiqueta de idioma
.
Tenga en cuenta que el modelo de datos RDF no incluye literales con una
etiqueta de idioma
vacía.
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
_:a foaf:name "Robert"@EN.
_:a foaf:name "Roberto"@ES.
_:a foaf:mbox <mailto:[email protected]> .
Esta consulta encuentra el foaf:name
español y foaf:mbox
:
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?name ?mbox
WHERE { ?x foaf:name ?name ;
foaf:mbox ?mbox .
FILTER ( lang(?name) = "ES" ) }
Resultados de la consulta:
name | mbox |
---|---|
"Roberto"@ES | <mailto:[email protected]> |
IRI
datatype
(typed literal
typedLit
)
IRI
datatype
(literal simple
simpleLit
)
Devuelve el tipo de datos IRI
de
typedLit
; Devuelve xsd:string
si el parámetro
es un literal simple.
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix eg: <http://biometrics.example/ns#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
_:a foaf:name "Alice".
_:a eg:shoeSize "9.5"^^xsd:float .
_:b foaf:name "Bob".
_:b eg:shoeSize "42"^^xsd:integer .
Esta consulta encuentra el foaf:name
y el foaf:shoeSize
de cualquier persona con una talla de pie que sea un entero:
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX eg: <http://biometrics.example/ns#>
SELECT ?name ?shoeSize
WHERE { ?x foaf:name ?name ; eg:shoeSize ?shoeSize .
FILTER ( datatype(?shoeSize) = xsd:integer ) }
Resultados de la consulta:
name | shoeSize |
---|---|
"Bob" | 42 |
xsd:boolean
xsd:boolean
left
||
xsd:boolean
right
Devuelve un OR
lógico de left
y right
.
Tenga en cuenta que logical-or
opera
sobre el valor
booleano efectivo de sus argumentos.
Nota: véase la sección 11.2, Evaluación
de filtros,
para el tratamiento de errores del operador ||
.
xsd:boolean
xsd:boolean
left
&&
xsd:boolean
right
Devuelve un AND
lógico de left
y right
.
Tenga en cuenta que logical-and
opera
sobre el valor
booleano efectivo de sus argumentos.
Nota: véase la sección 11.2, Evaluación
de filtros,
para el tratamiento de errores del operador &&
.
xsd:boolean
RDF term
term1
=
RDF term
term2
Devuelve true
si term1
y term2
son el mismo término RDF según se define en Resource Description
Framework (RDF): Conceptos y sintaxis abstracta [CONCEPTS];
produce un error de tipo si los argumentos son ambos literales pero no son
el mismo término RDF *;
Devuelve false
en caso contrario. term1
y term2
son lo mismo si cualquiera de lo siguiente es cierto:
term1
y term2
son IRIs
equivalentes como se define en 6.4
RDF
URI References de [CONCEPTS].term1
y term2
son literales
equivalentes como se define en 6.5.1
Literal Equality de [CONCEPTS].term1
y term2
son el mismo nodo
en blanco como se describe en 6.6
Blank Nodes de [CONCEPTS].@prefix foaf: <http://xmlns.com/foaf/0.1/> .
_:a foaf:name "Alice".
_:a foaf:mbox <mailto:[email protected]> .
_:b foaf:name "Ms A.".
_:b foaf:mbox <mailto:[email protected]> .
Esta consulta encuentra las personas que tienen múltiples tripletas foaf:name
:
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?name1 ?name2
WHERE { ?x foaf:name ?name1 ;
foaf:mbox ?mbox1 .
?y foaf:name ?name2 ;
foaf:mbox ?mbox2 .
FILTER (?mbox1 = ?mbox2 && ?name1 != ?name2)
}
Resultados de la consulta:
name1 | name2 |
---|---|
"Alice" | "Ms A." |
"Ms A." | "Alice" |
En esta consulta de documentos que fueron anotados el día de Año nuevo (2004 o 2005), los términos RDF no son los mismos, pero tienen valores equivalentes:
@prefix a: <http://www.w3.org/2000/10/annotation-ns#> .
@prefix dc: <http://purl.org/dc/elements/1.1/> .
_:b a:annotates <http://www.w3.org/TR/rdf-sparql-query/> .
_:b dc:date "2004-12-31T19:00:00-05:00"^^<http://www.w3.org/2001/XMLSchema#dateTime> .
PREFIX a: <http://www.w3.org/2000/10/annotation-ns#>
PREFIX dc: <http://purl.org/dc/elements/1.1/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
SELECT ?annotates
WHERE { ?annot a:annotates ?annotates .
?annot dc:date ?date .
FILTER ( ?date = xsd:dateTime("2005-01-01T00:00:00Z") ) }
annotates |
---|
<http://www.w3.org/TR/rdf-sparql-query/> |
* La
invocación de RDFterm-equal sobre dos literales tipados evalúa la
equivalencia de valores. Una implementación extendida puede dar soporte
a tipos de datos adicionales. Una implementación que procese una consulta
que compruebe la equivalencia sobre tipos de datos no
soportados (y forma léxica no idéntica y tipo de datos IRI) devuelve un
error, indicando que es incapaz de determinar si los valores son o no
equivalentes. Por ejemplo, una implementación no extendida producirá un
error cuando evalúe tanto "iiii"^^my:romanNumeral
=
"iv"^^my:romanNumeral
como "iiii"^^my:romanNumeral
!=
"iv"^^my:romanNumeral
.
xsd:boolean
sameTerm
(RDF term
term1
,RDF term
term2
)
Devuelve true
si term1
y term2
son el mismo término RDF según se define en Resource Description
Framework (RDF): Conceptos y sintaxis abstracta [CONCEPTS];
devuelve false
en caso contrario.
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
_:a foaf:name "Alice".
_:a foaf:mbox <mailto:[email protected]> .
_:b foaf:name "Ms A.".
_:b foaf:mbox <mailto:[email protected]> .
Esta consulta encuentra las personas que tienen múltiples tripletas foaf:name
:
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?name1 ?name2
WHERE { ?x foaf:name ?name1 ;
foaf:mbox ?mbox1 .
?y foaf:name ?name2 ;
foaf:mbox ?mbox2 .
FILTER (sameTerm(?mbox1, ?mbox2) && !sameTerm(?name1, ?name2))
}
Resultados de la consulta:
name1 | name2 |
---|---|
"Alice" | "Ms A." |
"Ms A." | "Alice" |
A diferencia de RDFterm-equal
, sameTerm
puede ser usado para evaluar la no equivalencia de literales
tipados
con tipos de datos no soportados:
@prefix : <http://example.org/WMterms#> .
@prefix t: <http://example.org/types#> .
_:c1 :label "Container 1" .
_:c1 :weight "100"^^t:kilos .
_:c1 :displacement "100"^^t:liters .
_:c2 :label "Container 2" .
_:c2 :weight "100"^^t:kilos .
_:c2 :displacement "85"^^t:liters .
_:c3 :label "Container 3" .
_:c3 :weight "85"^^t:kilos .
_:c3 :displacement "85"^^t:liters .
PREFIX : <http://example.org/WMterms#>
PREFIX t: <http://example.org/types#>
SELECT ?aLabel1 ?bLabel
WHERE { ?a :label ?aLabel .
?a :weight ?aWeight .
?a :displacement ?aDisp .
?b :label ?bLabel .
?b :weight ?bWeight .
?b :displacement ?bDisp .
FILTER ( sameTerm(?aWeight, ?bWeight) && !sameTerm(?aDisp, ?bDisp) }
aLabel | bLabel |
---|---|
"Container 1" | "Container 2" |
"Container 2" | "Container 1" |
La comprobación de cajas con el mismo peso también puede hacerse con el
operador
'=' (RDFterm-equal)
puesto que la evaluación de 100"^^t:kilos = "85"^^t:kilos
producirá un error, eliminando esa potencial solución.
xsd:boolean
langMatches
(literal simple
language-tag
,literal simple
language-range
)
Devuelve true
si language-tag
(primer
argumento) se corresponde con language-range
(segundo
argumento) según el esquema básico de filtrado definido en [RFC4647]
sección 3.3.1. El argumento language-range
es un rango de
idioma de base según el documento sobre Concordancia de etiquetas de idioma [RFC4647]
sección 2.1. Un language-range
de "*" se corresponde con
cualquier cadena language-tag
no vacía.
@prefix dc: <http://purl.org/dc/elements/1.1/> .
_:a dc:title "That Seventies Show"@en .
_:a dc:title "Cette Série des Années Soixante-dix"@fr .
_:a dc:title "Cette Série des Années Septante"@fr-BE .
_:b dc:title "Il Buono, il Bruto, il Cattivo" .
Esta consulta usa langMatches
y lang
(descrito en la sección
11.2.3.8) para encontrar los títulos en francés para el
espectáculo conocido en inglés como "That Seventies Show":
PREFIX dc: <http://purl.org/dc/elements/1.1/>
SELECT ?title
WHERE { ?x dc:title "That Seventies Show"@en ;
dc:title ?title .
FILTER langMatches( lang(?title), "FR" ) }
Resultados de la consulta:
title |
---|
"Cette Série des Années Soixante-dix"@fr |
"Cette Série des Années Septante"@fr-BE |
El idioma langMatches( lang( ?v ), "*" )
no filtrará
los literales sin una etiqueta de idioma puesto que lang( ?v )
devolverá una cadena vacía, por lo que
PREFIX dc: <http://purl.org/dc/elements/1.1/>
SELECT ?title
WHERE { ?x dc:title ?title .
FILTER langMatches( lang(?title), "*" ) }
informará de todos los títulos con una etiqueta de idioma:
title |
---|
"That Seventies Show"@en |
"Cette Série des Années Soixante-dix"@fr |
"Cette Série des Années Septante"@fr-BE |
xsd:boolean
regex
(literal simple
text
,literal simple
pattern
)
xsd:boolean
regex
(literal simple
text
,literal simple
pattern
,literal simple
flags
)
Invoca la función fn:matches
de XPath para filtrar el argumento text
contra una expresión
regular pattern
. El lenguaje de expresiones regulares se
define en la especificación XQuery
1.0 y XPath 2.0 Funciones y operadores [FUNCOP],
sección 7.6.1
Sintaxis
de Expresiones Regulares [FUNCOP].
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
_:a foaf:name "Alice".
_:b foaf:name "Bob" .
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?name
WHERE { ?x foaf:name ?name
FILTER regex(?name, "^ali", "i") }
Resultados de la consulta:
name |
---|
"Alice" |
SPARQL importa un subconjunto de funciones constructoras de XPath definidas en XQuery 1.0 y XPath 2.0 Funciones y operadores [FUNCOP], sección 17.1 Conversión (casting) de tipos primitivos a tipos primitivos. Los constructores SPARQL comprenden todos los constructores XPath para los tipos de datos de operandos SPARQL más los tipos de datos adicionales impuestos por el modelo de datos RDFl. La conversión en SPARQL se realiza invocando a la función constructora para el tipo destino sobre un operando del tipo origen.
XPath define sólo las conversiones desde un tipo de datos XML Schema a otro. El resto de conversiones se definen de la siguiente forma:
xsd:string
produce un literal tipado con una forma
léxica de los puntos de código que comprenden la IRI, y un tipo
de datos de xsd:string
.xsd:string
con el valor
de cadena igual a la forma léxica del literal al tipo de datos
destino.La siguiente tabla resume las operaciones de conversión que siempre se
permiten (Y), nunca se permiten (N)
y dependen del valor de la froma léxica (M).
Por ejemplo, una operación de conversión desde un xsd:string
(la primera fila) a un xsd:float
(la segunda columna) es
dependiente del valor de la forma léxica (M).
bool = xsd:boolean
dbl = xsd:double
flt = xsd:float
dec = xsd:decimal
int = xsd:integer
dT = xsd:dateTime
str = xsd:string
IRI = IRI
ltrl =literal simple
Desde \ A |
str | flt | dbl | dec | int | dT | bool |
---|---|---|---|---|---|---|---|
str | Y | M | M | M | M | M | M |
flt | Y | Y | Y | M | M | N | Y |
dbl | Y | Y | Y | M | M | N | Y |
dec | Y | Y | Y | Y | Y | N | Y |
int | Y | Y | Y | Y | Y | N | Y |
dT | Y | N | N | N | N | Y | N |
bool | Y | Y | Y | Y | Y | N | Y |
IRI | Y | N | N | N | N | N | N |
ltrl | Y | M | M | M | M | M | M |
Una regla gramatical PrimaryExpression puede ser una llamada a una función de extensión nombrada por una IRI. Una función de extensión toma un cierto numero de términos RDF como argumentos y devuelve un término RDF. Las semánticas de estas funciones se identifican mediante la IRI que identifica la función.
La interoperabilidad de las consultas SPARQL que usan funciones de extensión será problamente limitada.
Como ejemplo, considere una función llamada func:even
:
xsd:boolean
func:even
(numeric
value
)
Esta función será invocada en un filtro (FILTER) como:
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX func: <http://example.org/functions#>
SELECT ?name ?id
WHERE { ?x foaf:name ?name ;
func:empId ?id .
FILTER (func:even(?id)) }
Como segundo ejemplo, considere una función aGeo:distance
que calcula la distancia entre dos puntos, que se usa aquí para encontrar
lugares cerca de Grenoble:
xsd:double
aGeo:distance
(numeric
x1
,numeric
y1
,numeric
x2
,numeric
y2
)
PREFIX aGeo: <http://example.org/geo#>
SELECT ?neighbor
WHERE { ?a aGeo:placeName "Grenoble" .
?a aGeo:location ?axLoc .
?a aGeo:location ?ayLoc .
?b aGeo:placeName ?neighbor .
?b aGeo:location ?bxLoc .
?b aGeo:location ?byLoc .
FILTER ( aGeo:distance(?axLoc, ?ayLoc, ?bxLoc, ?byLoc) < 10 ) .
}
Una función de extensión puede usarse para evaluar algunos tipos de datos de aplicación no soportados por la especificación base de SPARQL; podría ser una transformación entre formatos de tipos de datos, por ejemplo a un término RDF XSDdateTime desde otro formato de fecha.
Esta sección define el comportamiento correcto para la evaluación de los partrones de grafo y modificadores de solución, dadas una cadena de consulta y un conjunto de datos RDF. Esto no implica que una implementación de SPARQL deba utilizar el proceso definido aquí.
El resultado de una ejecución SPARQL se define por una serie de pasos, comenzando por la consulta SPARQL como una cadena, convirtiendo dicha cadena en una forma de sintaxis abstracta, y convirtiéndola a su vez en una consulta abstracta SPARQL que incluye los operadores del álgebra de SPARQL. Esta consulta abstracta es evaluada sobre un conjunto de datos RDF.
SPARQL está definido en términos de IRIs [RFC3987]. Las referencias IRIs son un subcojunto de las referencias URI RDF que omite los espacios.
Sea I el conjunto de todas las referencias IRIs.
Sea RDF-L el conjunto de todos los Literales RDF
Sea RDF-B el conjunto de todos los nodos en blanco de los grafos RDF
El conjunto de los Términos RDF, RDF-T, es la unión de I, RDF-L y RDF-B.
Esta definición de Término RDF recoge de forma conjunta varias nociones básicas del modelo de datos RDF, pero actualizada para referirse a IRIs en vez de referencias URI RDF.
Un conjunto de datos RDF es un conjunto:
{ G, (<u1>, G1), (<u2>, G2),
. . . (<un>, Gn) }
donde G y cada Gi son grafos, y cada <ui> es
una IRI. Cada <ui> es diferente.
G se denomina grafo por defecto. (<ui>, Gi) se denomina grafo con nombre.
El grafo activo es el grafo del conjunto de datos utilizado para la concordancia con patrones de grafo básicos.
Una variable de consulta es un miembro del conjunto V, donde V es infinito y disjunto con respecto a RDF-T.
Un patrón de tripleta es miembro del
conjunto:
(RDF-T unión V) x (I unión V) x (RDF-T unión V)
Esta definición de patrón de tripleta incluye sujetos literales. Esto ya ha sido señalado en los fundamentos de RDF
"[El grupo de trabajo sobre el núcleo de RDF] señala que no hay conocimiento de ninguna razón por la cual los literales no podrían ser sujetos y un futuro grupo de trabajo con un carácter menos restrictivo podría extender la sintaxis para permitir literales como subjetos de las declaraciones."
Debido a que los grafos RDF pueden no contener literales como subjetos, cualquier patrón de tripleta SPARQL con un literal como sujeto fallará en la concordancia sobre cualquier grafo RDF.
Un patrón de grafo básico es un conjunto de patrones de tripleta.
El patrón de grafo vacío es un patrón de grafo básico que consiste en el conjunto vacío.
Una correspondencia de solución es un correspondencia a partir de un
conjunto de variables con un conjunto de términos RDF. Se utiliza la
expresión "solución" allí donde está claro.
Una correspondencia de solución, μ, es una función parcial μ : V -> T.
El dominio de μ, dom(μ), es el subconjunto de V donde μ esté definida.
Una secuencia de solución es una lista de soluciones ordenadas posibles.
Esta sección define el proceso de conversión de patrones de grafo y modificadores de solución en una cadena para una consulta SPARQL mediante una expresión del álgebra de SPARQL.
Despues de analizar una cadena de una consulta SPARQL y aplicar las abreviaturas para IRIs y patrones de tripleta mostradas en la sección 4, hay un árbol de sintaxis abstracta compuesta de:
Patrones | Modificadores | Formas de consulta |
---|---|---|
Términos RDF |
DISTINCT | SELECT |
Patrones de tripleta |
REDUCED | CONSTRUCT |
Patrones de grafo básicos | PROJECT | DESCRIBE |
Grupos | ORDER BY | ASK |
OPTIONAL | LIMIT | |
UNION | OFFSET | |
GRAPH | ||
FILTER |
El resultado de la conversión como un arbol abstracto de sintaxis abstracta es una consulta SPARQL que usa los siguientes símbolos del álgebra SPARQL:
Patrón de grafo |
Modificadores de solución |
---|---|
BGP | ToList |
Join | OrderBy |
LeftJoin | Project |
Filter | Distinct |
Union | Reduced |
Graph | Slice |
Slice (porción) es la combinación de OFFSET y LIMIT. mod es cualquier de los modificadores de solución.
ToList es utilizado donde la conversión de los resultados del patrón de grafo concuerdan con las secuencias.
Una consulta abstracta SPARQL es una tupla (E, DS, R) donde:
Esta sección describe el proceso de traducir un patrón de grafo SPARQL en una expresión del álgebra SPARQL. Después de traducir las abreviaturas sintácticas para IRIs y patrones de tripleta, se procesarán recursivamente las formas sintácticas en expresiones algebráicas:
OPTIONAL
:
OPTIONAL { { ... FILTER ( ... ?x ... ) } }.
.
Esto es ilustrado por dos casos de prueba no normativos:
Primero, abreviaturas expandidas para IRIs y patrones de tripleta de la seccion 4.
WhereClause
consiste en un patrón de grafo de grupo, GroupGraphPattern
,
que está compuesto por las siguientes formas de sintaxis:
Cada forma está traducida por el siguiente procedimiento
Transform(forma de sintaxis)
Si la forma es
TriplesBlock
El resultado es BGP(lista de patrones de tripleta)
Si la forma es
GroupOrUnionGraphPattern
Sea A := indefinido Para cada elemento G en GroupOrUnionGraphPattern Si A es indefinido A := Transform(G) Si no Entonces A := Union(A, Transform(G)) El resultado es A
Si la forma es
GraphGraphPattern
Si la forma es GRAPH IRI GroupGraphPattern El resultado es Graph(IRI, Transform(GroupGraphPattern)) Si la forma es GRAPH Var GroupGraphPattern El resultado es Graph(Var, Transform(GroupGraphPattern))
Si la forma es
GroupGraphPattern
Se introducen los siguientes símbolos:
- Join(Pattern, Pattern)
- LeftJoin(Pattern, Pattern, expression)
- Filter(expression, Pattern)
Sea FS := el conjunto vacío Sea G := el patrón vacío, Z, un patrón de grafo básico que es el conjunto vacío Para cada elemento E en GroupGraphPattern Si E es de la forma FILTER(expr) FS := FS set-union {expr} Si E es de la forma OPTIONAL{P} Entonces Sea A := Transform(P) Si A es de la forma Filter(F, A2) G := LeftJoin(G, A2, F) Si no Entonces G := LeftJoin(G, A, true) Si E es de cualquier otra forma: Sea A := Transform(E) G := Join(G, A) Si FS no está vacío: Sea X := Conjunción de las expresiones en FS G := Filter(X, G) El resultado es G.
Paso de simplificación:
Grupos de un patrón de grafo (no un filtro) se convierten en join(Z, A) y puede sustituirse por A. El patrón de grafo vacío Z es la identidad para la unión:
Sustituir join(Z, A) por A Sustituir join(A, Z) por A
La segunda forma de un ejemplo de reescritura es como el primero, pero con los grupos vacíos unidos eliminados a través del paso de simplificación.
Ejemplo: grupo con un patrón de grafo básico que consiste en un único patrón de tripleta:
Ejemplo: grupo con un patrón de grafo básico que consiste en dos patrones de tripleta:
Ejemplo: grupo formado por la unión de dos patrones de grafo básicos:
Ejemplo: grupo formado por la unión de una unión y un patrón de grafo básico:
Ejemplo: grupo formado por un patrón de grafo básico y un patrón de grafo opcional:
Ejemplo: grupo que consiste en un patrón de grafo básico y dos patrones de grafo opcionales:
Ejemplo: grupo formado por un patrón de grafo básico y un patrón de grafo opcional con un filtro:
Ejemplo: grupo formado por la unión de un patrón de grafo y un patrón de grafo opcional:
Ejemplo: grupo formado por un patrón de grafo básico, un filtro y un patrón de grafo opcional:
Paso 1 : ToList
ToList transforma un multiconjunto en una secuencia con los mismos elementos y cardinalidad. Esto no implica la ordenación de la secuencia; los duplicados no tienen por qué ser adyacentes.
Sea M := ToList(Patrón)
Paso 2 : ORDER BY
Si la cadena de consulta tiene una cláusula ORDER BY
M := OrderBy(M, lista de comparadores de orden)
Paso 3 : Proyección
M := Project(M, vars)
donde vars es el conjunto de variables mencionadas en la cláusula SELECT o todas las variables mencionadas en la consulta se se utiliza SELECT * .
Paso 4 : DISTINCT
Si la consulta contiene la cláusula DISTINCT,
M := Distinct(M)
Paso 5 : REDUCED
Si la consulta contiene la cláusula REDUCED,
M := Reduced(M)
Paso 6 : OFFSET y LIMIT
Si la consulta contiene "OFFSET start" o "LIMIT length"
M := Slice(M, start, length)
El valor por defecto de "start" es 0
El valor por defecto de "length" es (size(M)-start).
La consulta abstracta final es M.
Cuando concuerdan patrones de grafo, las posibles soluciones forman un multiconjunto [multiset], también conocido como bag (saco). Un multiconjunto es una colección no ordenada de elementos en la que cada elemento puede aparecer más de una vez. Está descrito por un conjunto de elementos y una fución de cardinalidad que indica el número de ocurrencias de cada elemento en el multiconjunto.
Se utiliza μ para representar las correspondencias de solución y
Se utiliza μ0 para representar aquella correspondencia para la que dom(μ0) es el conjunto vacío.
Se utiliza Ω0 para representar el multiconjunto formado exactamente por la correspondencia vacía μ0, con cardinalidad 1. Esta es la identidad de la unión.
Se utiliza μ(?x->t) para representar la variable de correspondencia de la solución con el término RDF t : { (x, t) }
Se utiliza Ω(?x->t) para representar el multiconjunto formado exactamente por μ(?x->t), es decir, { { (x, t) } } con cardinalidad 1.
Dos correspodencias de solución μ1 y μ2 son compatibles si, para cada variable v en dom(μ1) y en dom(μ2), μ1(v) = μ2(v).
Si μ1 y μ2 son compatibles entonces la unión de conjuntos entre μ1 y μ2 es también una correspondencia. Se utiliza merge(μ1, μ2) para representar la unión de conjuntos entre μ1 y μ2.
Se utiliza card[Ω](μ) para la cardinalidad de la correspondencia de solución μ en un multiconjunto de correspondencias Ω.
Los patrones de grafo básicos forman la base de la concordancia de patrones SPARQL. Un patrón de grafo básico concuerda con un grafo activo para esa parte de la consulta. Los patrones de grafo básicos pueden ser instanciados sustituyendo tanto variables como nodos en blanco por términos, ofreciendo dos nociones de instancia. Los nodos en blanco son sustituidos usando una instancia RDF de correspondencia, σ, transformandolos en términos RDF; las variables son sustituidas por una correspondencia de solución, transformándolas en términos RDF.
Una correspondencia de instancia de patrón, P, es la combinación de una correspodencia de instancia RDF, σ, y una correspondencia de solución, μ. P(x) = μ(σ(x))
Cualquier correspondencia de instancia de patrón define una única correspondencia de solución y una única correspondencia de instancia RDF, obtenida mediante la restricción de las variables de consulta y de los nodos en blanco respectivamente.
Sea BGP un patrón de grabo básico y sea G un grafo RDF.
μ es una solución para BGP a partir de G cuando existe una correspondencia de instancia de patrón P, de tal manera que P(BGP) es un subgrafo de G y μ es la restricción de P para las variables de consulta en BGP.
card[Ω](μ) = card[Ω](número de correspondencias de instancias RDF distintas, σ, de tal manera que P = μ(σ) es una correspondencia de instancia de patrón y P(BGP) es un subgrafo de G).
Si un patrón de grafo básico es el conjunto vacío, entonces la solución es Ω0.
Esta definición permite a la correspondencia de solución vincular una variable en un patrón de grafo básico, BGP, con un nodo en blanco en G. Debido a que SPARQL trata los identificadores de nodos en blanco tal y como se indica en el documento Formato XML de los resultados de consultas SPARQL, no pueden entenderse como nodos identificados en el grafo activo del conjunto de datos. Si DS es el conjunto de datos de una consulta, se entiende que las soluciones de patrón no provienen del grafo activo de DS en sí, sino de un grafo RDF denominado grafo de ámbito (scoping graph), que es un grafo equivalente al grafo activo de DS pero que no comparte ningún nodo en blanco con DS o con BGP. El mismo grafo de ámbito es utilizado para todas las soluciones de una misma consulta. El grafo de ámbito es puramente una construcción teórica; en la práctica, el efecto es obtenido simplemente por las convenciones de ámbito de documento para identificadores de nodos en blanco.
Puesto que los nodos en blanco RDF permiten soluciones redundantes de infinitud de muchos patrones, pueden existir infinitas soluciones de patrones (obtenidas mediante la sustitución de nodos en blanco por otros diferentes). Es necesario, por tanto, delimitar de alguna manera las soluciones para un patrón de grafo básico. SPARQL utiliza el criterio de concordancia de subgrafo para determinar las soluciones de un patrón de grafo básico. Existe una solución para cada correspondencia distinta de instancia de patrón de grafo básico con el subconjunto del grafo activo.
Esto está optimizado para facilitar el cálculo en vez de eliminar la redundancia. Permite que los resultados de un consulta tenga redundancia, incluso cuando el grafo activo del conjunto de datos es reducido, permitiendo que se obtenjan diferentes resultados de un consulta a partir de conjuntos de datos lógicamente equivalentes.
Para cada símbolo de una consulta abstracta SPARQL, se define un operador de evaluación. Los operadores algebraicos de SPARQL del mismo nombre se utilizan para evaluar consultas abstractas SPARQL del modo en el que se describe en "Semántica de evaluación SPARQL".
Definición: Filter
Sea Ω un conjunto múltiple de soluciones de correspondencia y sea expr una expresión. Se define:
Filter(expr, Ω) = { μ | μ en Ω y expr(μ) como una expresión que tiene un valor efectivo booleano de verdadero }
card[Filter(expr, Ω)](μ) = card[Ω](μ)
Definición: Join
Sean Ω1 y Ω2 conjuntos múltiples de soluciones de correspondencia. Se define:
Join(Ω1, Ω2) = { merge(μ1, μ2) | μ1 en Ω1 y μ2 en Ω2, y μ1 y μ2 son compatibles}
card[Join(Ω1, Ω2)](μ) =
para cada merge(μ1, μ2), μ1 en Ω1
y μ2 en Ω2 tal que μ = merge(μ1, μ2),
sea la suma de (μ1, μ2), card[Ω1](μ1)*card[Ω2](μ2)
Es posible que una solución de correspondencia μ en un Join pueda plantearse en diferentes soluciones de correspondencia, μ1 y μ2 en los conjuntos múltiples objeto de la unión. La cardinalidad de μ es la suma de las cardinalidades de todas las posibilidades.
Definición: Diff
Sean Ω1 y Ω2 conjuntos múltiples de soluciones de correspondencia. Se define:
Diff(Ω1, Ω2, expr) = { μ | μ en Ω1 tal que para todo μ′ en Ω2, o bien μ y μ′ no son compatibles o μ y μ' son compatibles y expr(merge(μ, μ')) tiene un valor efectivo booleano de falso }
card[Diff(Ω1, Ω2, expr)](μ) = card[Ω1](μ)
Diff se emplea internamente para la definición de LeftJoin.
Definición: LeftJoin
Sean Ω1 y Ω2 multiconjuntos de soluciones de correspondencia y sea expr una expresión. Se define:
LeftJoin(Ω1, Ω2, expr) = Filter(expr, Join(Ω1, Ω2)) unión-conjunto Diff(Ω1, Ω2, expr)
card[LeftJoin(Ω1, Ω2, expr)](μ) = card[Filter(expr, Join(Ω1, Ω2))](μ) + card[Diff(Ω1, Ω2, expr)](μ)
Es decir, escrito en su forma completa:
LeftJoin(Ω1, Ω2, expr) =
{ merge(μ1, μ2) | μ1 en Ω1
y μ2 en Ω2, y μ1 y μ2 son
compatibles y expr(merge(μ1, μ2)) es verdadero }
unión-conjunto
{ μ1 | μ1 en Ω1 y μ2 en Ω2,
y μ1 y μ2 no son compatibles }
unión-conjunto
{ μ1 | μ1 en Ω1 y μ2 en Ω2,
y μ1 y μ2 son compatibles y expr(merge(μ1,
μ2)) es falso }
Puesto que son distintos, la cardinalidad de LeftJoin es la cardinalidad de los componentes individuales de la definición.
Definición: Union
Sean Ω1 y Ω2 multiconjuntos de soluciones de correspondencia. Se define:
Union(Ω1, Ω2) = { μ | μ en Ω1 o μ en Ω2 }
card[Union(Ω1, Ω2)](μ) = card[Ω1](μ) + card[Ω2](μ)
Se escribe [x | C] para denotar una secuencia de elementos donde C(x) es verdadero.
Se escribe card[L](x) para denotar la cardinalidad de x en L.
Sea Ω un multiconjunto de soluciones de correspondencia. Se define:
ToList(Ω) = secuencia de correspondencias μ en Ω en cualquier orden, con card[Ω](μ) que indica las ocurrencias de μ
card[ToList(Ω)](μ) = card[Ω](μ)
Sea Ψ una secuencia de soluciones de correspondencia. Se define:
OrderBy(Ψ, condición) = [ μ | μ en Ψ y la secuencia satisface la condición requerida]
card[OrderBy(Ψ, condición)](μ) = card[Ψ](μ)
Sea Ψ una secuencia de soluciones de correspondenciay PV un conjunto de variables.
Para la correspondencia μ, se escribe Proj(μ, PV) para denotar la restricción de μ a las variables en PV.
Project(Ψ, PV) = [ Proj(Ψ[μ], PV) | μ en Ψ ]
card[Project(Ψ, PV)](μ) = card[Ψ](μ)
El orden Project(Ψ, PV) debe preservar cualquier oden indicado por OrderBy.
Sea Ψ una secuencia de soluciones de correspondencia. Se define:
Distinct(Ψ) = [ μ | μ en Ψ ]
card[Distinct(Ψ)](μ) = 1
El orden de Distinct(Ψ) debe preservar cualquier oden indicado por OrderBy.
Sea Ψ una secuencia de soluciones de correspondencia. Se define:
Reduced(Ψ) = [ μ | μ en Ψ ]
card[Reduced(Ψ)](μ) esté comprendido entre 1 y card[Ψ](μ)
El orden de Reduced(Ψ) debe preservar cualquier orden indicado por OrderBy.
Un solución a la que se aplica el modificador de secuencia Reduced no garantiza una cardinalidad definida.
Sea Ψ una secuencia de soluciones de correspondencia. Se define:
Slice(Ψ, start, length)[i] = Ψ[start+i] for i = 0 to (length-1)
Se define eval(D(G), patrón de grafo) como la evaluación de un patrón de grafo con respecto a un conjunto de datos D que incluye el grafo activo G. El grafo activo es inicialmente el grafo por defecto.
D : un conjunto de datos D(G) : D un conjunto de datos con un grafo activo G (aquel cuyos patrones son comparados) D[i] : El grafo con IRI i en el conjunto de datos D D[DFT] : el grafo por defecto de D P, P1, P2 : patrones de grafo L : una secuencia de solución
eval(D(G), Filter(F, P)) = Filter(F, eval(D(G),P))
eval(D(G), Join(P1, P2)) = Join(eval(D(G), P1), eval(D(G), P2))
eval(D(G), LeftJoin(P1, P2, F)) = LeftJoin(eval(D(G), P1), eval(D(G), P2), F)
eval(D(G), BGP) = multiconjunto de soluciones de correspondencia
Véase sección 12.3 Patrones de Grafo Básico
eval(D(G), Union(P1,P2)) = Union(eval(D(G), P1), eval(D(G), P2))
Si IRI es un nombre de grafo en D eval(D(G), Graph(IRI,P)) = eval(D(D[IRI]), P)
si IRI no es un nombre de grafo en D eval(D(G), Graph(IRI,P)) = el multiconjunto vacío
eval(D(G), Graph(var,P)) = Sea R el multiconjunto vacío Para cada IRI i en D R := Union(R, Join( eval(D(D[i]), P) , Ω(?var->i) ) el resultado es R
La evaluación del grafo utiliza el operador de unión del álgebra de SPARQL. La cardinalidad de una solución de correspondencia es la suma de las cardinalidades de las soluciones de correspondencia de cada operación join.
eval(D, ToList(P)) = ToList(eval(D(D[DFT]), P))
eval(D, Distict(L)) = Distinct(eval(D, L))
eval(D, Reduced(L)) = Reduced(eval(D, L))
eval(D, Project(L, vars)) = Project(eval(D, L), vars)
eval(D, OrderBy(L, condition)) = OrderBy(eval(D, L), condition)
eval(D, Slice(L, start, length)) = Slice(eval(D, L), start, length)
El diseño general de SPARQL se puede utilizar para las consultas que conllevan una forma de inferencia más elaborada que una inferencia simple, reescribiendo las condiciones de comparaciones de los patrones de grafo básico. Puesto que se trata de un problema de investigación abierto al establecimiento de dicha condiciones en una única forma general aplicables a todas las formas de inferencia y elimina de manera óptima las redundancias innecesarias o inapropiadas, este documento sólo ofrece las condiciones necesarias que debe satisfacer cualquier solución. Éstas tendrán que ampliarse a las definiciones completas para cada caso en particular..
Los patrones de grafo básico tienen la misma relación con los patrones de
tripletas que a su vez tienen los grafos RDF con las tripletas RDF,
compartiendo gran parte de la terminología. En particular dos patrones de
grafo básico se dicen que son equivalentes si existe una biyección M entre
los términos de un patrón de tripletas que define las correspondencias
entre nodos en blanco o entre variables, literales e IRIs, tal y como una
tripleta (s, p, o) está en el primer patrón, si y solo si la tripleta (
M(s), M(p), M(o) ) está en la segunda. Esta definición amplía esto para
inferencias de grafos RDF con patrones de grafo básico, preservando los
nombres de variable entre patrones equivalentes.
Un régimen de inferencia especifica
Ejemplos de regímenes de inferencia incluyen la inferencia simple [RDF-MT], la inferencia RDF [RDF-MT], la inferencia RDFS [RDF-MT], D-inferencia [RDF-MT] y la inferencia OWL-DL [OWL-Semantics]. De éstos, solo la inferencia OWL-DL restringe el conjunto de grafos bien-formados. Si E es un régimen de inferencia entonces será posible referirse a E-implicación, E-consistencia, etc, siguiendo esta convención para los nombres.
Algunos regímenes de inferencia pueden categorizar algunos grafos RDF como inconsistentes. Por ejemplo, el siguiente grafo RDF:
_:x rdf:type xsd:string . _:x rdf:type xsd:decimal .
es D-inconsistente cuando D contiene los tipos de datos XSD. El efecto de una consulta sobre un grafo inconsistente no está cubierto por esta especificación, pero debe ser especificada por una amplicación SPARQL particular.
Una ampliación de SPARQL para E-inferencia debe satisfacer las siguientes condiciones.
1 -- El grafo de ámbito, SG, correspondiente con cualquier grafo activo consistente AG es especificado de manera única y es E-equivalente a AG.
2 -- Para cualquier patron de grafo básico BGP y solución de correspondencia de patrón P, P(BGP) está bien-formado para E
3 -- Para cualquier grafo de ámbito SG y conjunto de respuestas {P1 ... Pn}, para un patrón de grafo básico BGP, donde {BGP1 .... BGPn} es un conjunto de patrones de grafo básico, todos equivalentes a BGP, ninguno de los cuales comparten ningún nodo en blanco entre sí o con SG, se afirma que:
SG E-inferencia (SG union P1(BGP1) union ... union Pn(BGPn))
Estas condiciones no determinan totalmente el conjunto de posibles respuestas, puesto que RDF permite redundancias de forma ilimitada. Además, por tanto, debe cumplirse lo siguiente.
4 -- Cada ampliación SPARQL debe proporcionar condiciones sobre los conjuntos de respuestas que garanticen que cada BGP y AG tengan un conjunto finito de respuestas, el cual es único hasta la equivalencia del grafo RDF.
(a) SG será a menudo el gráfico equivalente a AG, pero restringiendo esto a E-equivalencia permite algunas formas de normalización, por ejemplo la eliminación de redundancias semánticas, que se aplicará a los documentos fuente originales antes de la consulta.
(b) La construcción de la condición 3 asegura que cualquier nodo en blanco introducido por la correspondencia de solución sea usado de forma que sea internamente consistente con el modo en el que aparecen los nodos en blanco en SG. Esto asegura que los identificadores de nodos en blanco aparezcan en una respuesta de un conjunto de respuestas solo cuando los nodos en blanco asi identificados sea efectivamente idénticos en SG. Si la ampliación no permite vincular respuestas con nodos en blanco, entonces esta condición puede simplicarse con esta otra:
SG E-inferencia P(BGP) para cada patrón de solución P.
(c) Estas condiciones no imponen el requisito SPARQL de que SG no comparta nodos en blanco con AG o BGP. En particular, permite que SG sea realmente AG. Esto permite protocolos de consulta en los que los identificadores de nodos en blanco mantienen su significado entre la consulta y el documento fuente original, o entre múltiples consultas. Sin embargo, dichos protocolos no son soportados por la especificación actual del protocolo SPARQL.
(d) Puesto que las condiciones 1 a 3 son únicamente necesarias en las respuestas, la condición 4 permite casos donde el conjunto de respuestas correctas pueda restringirse de varias formas. Por ejemplo, el estado actual de las consultas OWL-DL se centran en los casos donde los vínculos entre respuestas y nodos en blanco están prohibidos. Nótese que estas condiciones permiten incluso casos de 'silencio' patológicos donde cada consulta tiene un conjunto de respuestas vacías.
(e) Ninguna de estas condiciones se refieren explícitamente a instancias de correspondencias sobre nodos en blanco en BGP. Para algunos regímenes de inferencia, la interpretación de la existencia de nodos en blanco no puede ser totalmente capturada a través de la existencia de una única instancia de correspondencia. Estas condiciones permiten que dichos regímenes den a los nodos en blanco en los patrones de consulta una 'existencia plena' de lectura.
Es fácil demostrar que SPARQL satisface estas condiciones para el caso en el que E es una inferencia simple, dado que la condición SPARQL en SG indica que se trata de un grafo equivalente a AG con la salvedad de que no comparte nodos en blanco con AG o BGP (que satisfagan la primera condición). La única condición no trivial es (3).
Cada respuesta Pi es la restricción de correspondencia de
solución de una instancia SPARQL Mi tal que Mi(BGPi)
es un subgrafo de SG. Puesto que BGPi y SG no tienen nodos en
blanco en común, el rango de Mi no contienen nodos en blanco de
BGPi; por tanto, la correspondencia de solución Pi y
la instancia RDF objeto de la correspondencia Ii que componen Mi
son conmutativas, así pues Mi(BGPi) = Ii(Pi(BGPi)).
Por lo tanto
M1(BGP1) union ... union Mn(BGPn)
= I1(P1(BGP1)) union ... union In(Pn(BGPn))
= [ I1 + ... + In]( P1(BGP1)
union ... union Pn(BGPn) )
puesto que los dominios de todas las instancias Ii objeto de
la correspondencia son mútuamente excluyentes. Teniendo en cuenta que
también son excluyentes con respecto a SG,
SG union [ I1 + ... + In]( P1(BGP1)
union ... union Pn(BGPn) )
= [ I1 + ... + In](SG union P1(BGP1)
union ... union Pn(BGPn) )
por ejemplo
SG union P1(BGP1) union ... union Pn(BGPn)
tiene una instancia que es un subgrafo de SG, en consencuencia es una inferencia simple a partir de SG debido al Lema de interopación RDF [RDF-MT].
Una cadena
de consulta SPARQL es una cadena de caracteres Unicode (ver sección
6.1 Conceptos de cadena del documento [CHARMOD]) en
el lenguaje definido por la siguiente gramática que comienza con la
producción de una Consulta. Para asegurar la
compatibilidad con futuras versiones de Unicode, los caracteres en esta
cadena puede incluir puntos de código Unicode que están sin asignar en la
fecha de publicar la presente recomendación (ver Sintaxis de Patrones e Identificadores en la sección
4 Sintaxis de Patrones del documento [UNIID]). Para
producciones con clases de caracteres excluidos (por ejemplo [^<>'{}|^`]
),
los caracteres excluidos están en el rango #x0 - #x10FFFF
.
Una cadena de consulta SPARQL es procesada para buscar puntos de código de secuencias de escape antes de su análisis (parsing) a partir de la gramática definida a continuación en notación EBNF. Los puntos de código de las secuencias de escapepara una cadena de consulta SPARQL son:
Escape | Unicode code point |
---|---|
'\u' HEX HEX HEX HEX | Un punto de código Unicode en el rango que va de U+0 a U+FFFF inclusive, correspondiente al valor hexadecimal codificado. |
'\U' HEX HEX HEX HEX HEX HEX HEX HEX | Un punto de código Unicode en el rango que va de U+0 a U+10FFFF inclusive, correspondiente al valor hexadecimal codificado. |
donde HEX es un carácter hexadecimal
HEX ::= [0-9] | [A-F] | [a-f]
Ejemplos:
<ab\u00E9xy> # Codepoint 00E9 is Latin small e with acute - é \u03B1:a # Codepoint x03B1 is Greek small alpha - α a\u003Ab # a:b -- codepoint x3A is colon
Los puntos de código de secuencias de escape pueden aparecer en cualquier lugar de la cadena de consulta. Pueden ser procesados antes de su análisis (parsing) basándose en las reglas de la gramática y por tanto sustituidos por puntos de código con significado en dicha gramática, tales como ":" para marcar un nombre de prefijo.
Estas secuencias de escape no están incluidas en la siguiente gramática.
Únicamente se ofrecen las secuencias de escape para caracteres que podrían
ser legales en ese punto de la gramática. Por ejemplo, la variable "?x\u0020y
"
no es legal (\u0020
es un espacio y no se permite en el
nombre de una variable).
El Espacio en blanco (en producción WS
)
se utiliza para separar dos terminales que de otra forma podrían ser
reconocidos erroneamente como un único terminal. Las reglas de nombre
especificadas más adelante en mayúsculas indican cuando un espacio en
blanco es significativo; éstos constituyen una posible opción para los
terminales en la construcción de un parser SPARQL. Los espacios en blanco
son significativos en las cadenas.
Por ejemplo:
?a<?b&&?c>?d
es la secuencia de tokens para la variable '?a
', una IRI '<?b&&?c>
',
y una variable '?d
'; no se trata de una expresión que incluya
al operador '&&
' que conecte dos expresiones usando
'<
' (menor que) y '>
' (mayor que).
Los comentarios en las consultas SPARQL toman la forma de '#
',
fuera de una referencia IRI o una cadena, y continuan hasta el fin de la
línea (marcado por los caracteres 0x0D
ó 0x0A
)
o hasta el final del fichero si no hay un fin de línea después de la marca
de comentario. Los comentarios se tratan como si fueran espacios en
blanco.
El texto coincidente con la producción IRI_REF
y la producción PrefixedName
(tras la expansión del prefijo), después del procesamiento de los escapes,
deben ser conformes con la sintaxis genérica de referencias IRI descrita
en la sección 2.2 del documento RFC 3987 "ABNF para referencias IRI e
IRIs" [RFC3987]. Por ejemplo, la IRI_REF
<abc#def>
puede darse en una cadena de consulta SPARQL, pero la IRI_REF
<abc##def>
no
debe darse.
Las IRIs base declaradas con la palabra clave BASE deben ser IRIs absolutas. Un prefijo declarado con la palabra clave PREFIX no puede ser re-declarado en la misma consulta. Véase la sección 4.1.1, Sintaxis para IRI, para una descripción de BASE y PREFIX.
No puede utilizarse en una misma consulta sencilla la misma etiqueta de nodos en blanco en dos patrones de gráfico básicos diferentes.
Además de los puntos de código de secuencias de escape pueden aplicarse
los siguientes secuencias de escape en cualquier cadena
de production (por ejemplo, STRING_LITERAL1
,
STRING_LITERAL2
, STRING_LITERAL_LONG1
,
STRING_LITERAL_LONG2
):
Escape | Unicode code point |
---|---|
'\t' | U+0009 (tabulación) |
'\n' | U+000A (salto de línea) |
'\r' | U+000D (retorno de carro) |
'\b' | U+0008 (retroceso) |
'\f' | U+000C (salto de formulario) |
'\"' | U+0022 (comillas, comillas dobles) |
"\'" | U+0027 (apostrofe-comillas, comillas simples) |
'\\' | U+005C (barra diagonal inversa) |
Ejemplos:
"abc\n" "xy\rz" 'xy\tz'
La notación EBNF usada en la gramática está definida mediante lo indicado en la sección 6 (Notación) del documento de la recomendación de XML 1.1 [XML11].
La comprobación de las palabras clave se realiza sin diferenciar
mayúsculas y minúsculas con las excepción de la palabra clave 'a
'
la cual, en consonancia con Turtle y N3, se utiliza en lugar del IRI de rdf:type
(http://www.w3.org/1999/02/22-rdf-syntax-ns#type
en su forma completa).
Palabras clave:
BASE | SELECT | ORDER BY | FROM | GRAPH | STR | isURI |
PREFIX | CONSTRUCT | LIMIT | FROM NAMED | OPTIONAL | LANG | isIRI |
DESCRIBE | OFFSET | WHERE | UNION | LANGMATCHES | isLITERAL | |
ASK | DISTINCT | FILTER | DATATYPE | REGEX | ||
REDUCED | a | BOUND | true | |||
sameTERM | false |
Las secuencias de escape son sensibles a las mayúsculas.
Al escoger una regla para su comparación, se elige la coincidencia más larga.
Producciones para terminales:
[70] |
IRI_REF |
::= | '<'
([^<>"{}|^`\]-[#x00-#x20])* '>' |
[71] |
PNAME_NS |
::= | PN_PREFIX? ':' |
[72] |
PNAME_LN |
::= | PNAME_NS PN_LOCAL |
[73] |
BLANK_NODE_LABEL |
::= | '_:' PN_LOCAL |
[74] |
VAR1 |
::= | '?' VARNAME |
[75] |
VAR2 |
::= | '$' VARNAME |
[76] |
LANGTAG |
::= | '@' [a-zA-Z]+ ('-' [a-zA-Z0-9]+)* |
[77] |
INTEGER |
::= | [0-9]+ |
[78] |
DECIMAL |
::= | [0-9]+ '.' [0-9]* | '.' [0-9]+ |
[79] |
DOUBLE |
::= | [0-9]+ '.' [0-9]* EXPONENT
| '.' ([0-9])+ EXPONENT | ([0-9])+ EXPONENT |
[80] |
INTEGER_POSITIVE |
::= | '+' INTEGER |
[81] |
DECIMAL_POSITIVE |
::= | '+' DECIMAL |
[82] |
DOUBLE_POSITIVE |
::= | '+' DOUBLE |
[83] |
INTEGER_NEGATIVE |
::= | '-' INTEGER |
[84] |
DECIMAL_NEGATIVE |
::= | '-' DECIMAL |
[85] |
DOUBLE_NEGATIVE |
::= | '-' DOUBLE |
[86] |
EXPONENT |
::= | [eE] [+-]? [0-9]+ |
[87] |
STRING_LITERAL1 |
::= | "'" ( ([^#x27#x5C#xA#xD]) | ECHAR
)* "'" |
[88] |
STRING_LITERAL2 |
::= | '"' ( ([^#x22#x5C#xA#xD]) | ECHAR
)* '"' |
[89] |
STRING_LITERAL_LONG1 |
::= | "'''" ( ( "'" | "''" )? ( [^'\] | ECHAR
) )* "'''" |
[90] |
STRING_LITERAL_LONG2 |
::= | '"""' ( ( '"' | '""' )? ( [^"\] | ECHAR
) )* '"""' |
[91] |
ECHAR |
::= | '\' [tbnrf\"'] |
[92] |
NIL |
::= | '(' WS* ')' |
[93] |
WS |
::= | #x20 | #x9 | #xD | #xA |
[94] |
ANON |
::= | '[' WS* ']' |
[95] |
PN_CHARS_BASE |
::= | [A-Z] | [a-z] | [#x00C0-#x00D6] |
[#x00D8-#x00F6] | [#x00F8-#x02FF] | [#x0370-#x037D] |
[#x037F-#x1FFF] | [#x200C-#x200D] | [#x2070-#x218F] |
[#x2C00-#x2FEF] | [#x3001-#xD7FF] | [#xF900-#xFDCF] |
[#xFDF0-#xFFFD] | [#x10000-#xEFFFF] |
[96] |
PN_CHARS_U |
::= | PN_CHARS_BASE
| '_' |
[97] |
VARNAME |
::= | ( PN_CHARS_U
| [0-9] ) ( PN_CHARS_U | [0-9] |
#x00B7 | [#x0300-#x036F] | [#x203F-#x2040] )* |
[98] |
PN_CHARS |
::= | PN_CHARS_U |
'-' | [0-9] | #x00B7 | [#x0300-#x036F] | [#x203F-#x2040] |
[99] |
PN_PREFIX |
::= | PN_CHARS_BASE
((PN_CHARS|'.')* PN_CHARS)? |
[100] |
PN_LOCAL |
::= | ( PN_CHARS_U
| [0-9] ) ((PN_CHARS|'.')* PN_CHARS)? Note that SPARQL local names allow leading digits while XML local names do not. |
Notas:
AdditiveExpression
permite esto al cubrir ambos casos en una expresión seguida de un número
con signo. Estos producen una adición o sustracción del número sin signo
según proceda.Algunos ficheros con la gramática de algunas herramientas utilizadas comúnmente están disponibles aquí.
Véanse el apéndice A Gramática SPARQL al respecto de la conformidad de las cadenas de consulta SPARQL, and la sección 10 Formas de consulta para la conformidad de los resultados de la consulta. Véase el apéndice D. Tipos de medios en Internet para la conformidad con el tipo de medio application/sparql-query.
Esta especificación está desarrollada para su uso conjunto con el Protocolo SPARQL [SPROT] y el Formato XML de resultados de consultas SPARQL [RESULTS]. Véanse dichas especificaciones para ampliar información acerca de sus criterios de conformidad.
Nótese que el protocolo SPARQL describe tanto una interfaz abstracta como un protocolo de red, y la interfaz abstracta muy aplicarse tanto a APIs com a interfaces de red.
Las consultas SPARQL que usen FROM, FROM NAMED o GRAPH pueden causar que
las URIs especificadas sean dereferenciadas. Esto puede ocasionar un uso
adicional de los recursos de red, disco o CPU junto con efectos
secundarios asociados como la denegación de servicio. Deben tenerse en
cuenta los aspectos de seguridad tratados en la sección 7 del documento Identificador
Unificado de Recurso (URI): Sintaxis Genérica [RFC3986].
Además, en algunos casos los contenidos de las URIs file:
pueden ser accedidos, procesados y devueltos como resultados,
proporcionando no deseado a recursos locales.
El lenguaje SPARQL permite amplicaciones, las cuales pueden tener sus propias implicaciones de seguridad.
Múltiples IRIs pueden tener la misma apariencia. Los caracteres de diferentes escrituras pueden tener un aspecto similar (una "о" cirílica puede parecer similar a la letra latina "o"). Un carácter seguido de una combinación de caracteres pueden tener la misma representación visual que otro carácter (LA LETRA LATINA E MINÚSCULA, seguida de la COMBINACIÓN DE ACENTO AGUDO puede tener la misma representación visual que LA LETRA LATINA E MINÚSCULA CON ACENTO). Los usuarios de SPARQL deben tener en cuenta que las IRIs de las consultas deben coincidir con las IRIs de los datos. Puede encontrarse más información sobre la coincidencia de caracteres similares en Consideraciones de Seguridad de Unicode [UNISEC] y en la sección 8 de Identificadores Internacionalizados de Recursos (IRIs) [RFC3987].
El tipo de medio de Internet / Tipo MIME para el lenguaje de consulta SPARQL es "application/sparql-query".
Se recomienda que los ficheros de consultas SPARQL tengan la extensión ".rq" (en minúsculas) en todas las plataformas.
Se recomienda que los ficheros de consultas SPARQL almacenados en sistemas de fichero HFS de Macintosh se proporcione como un tipo de fichero "TEXT".
SPARQL Lenguaje de Consulta para RDF es un producto de todo el Grupo de Trabajo para el Acceso a Datos RDF del W3C, y agradecemos las discusiones, comentarios y revisiones a todos los miembros presentes y pasados.
Además, se han tenido comentarios y discusiones con muchas personas a través de los comentarios recibidos en la lista del grupo de trabajo. Todos los comentarios han ayudado a hacer un documento mejor. Andy agradece particularmente a Jorge Pérez, Geoff Chappell, Bob MacGregor, Yosi Scharf and Richard Newman por explorar aspectos concretos relacionados con SPARQL. Eric agradece la ayuda incalculable de Björn Höhrmann.
Este es un resumen de alto nivel de los cambios realizados en este documento desde su publicación el 14 de junio de 2007 como Recomendación Candidata:
application/sparql-query
fue
aprobado, por lo que el texto sobre el estado de dicha petición ha
sido eliminado.