Этот документ является неофициальным переводом исходной английской версии. Может содержать неточности и ошибки.
© PhD Щербак Сергей (ontolog[@]gmail.com). Редактор перевода Алик Кириллович, 2009.
Комментарии к переводу оставляйте здесь! или на форуме|| На главную

W3C

Язык запросов SPARQL для RDF

Рекомендация W3C, 15 января 2008

Текущая версия:
http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/
Последняя версия:
http://www.w3.org/TR/rdf-sparql-query/
Предыдущая версия:
http://www.w3.org/TR/2007/PR-rdf-sparql-query-20071112/
Редакторы:
Эрик Прудхоммоукс, W3C <eric@w3.org>
Энди Сиборн, Hewlett-Packard Laboratories, Бристоль <andy.seaborne@hp.com >

Обращайтесь к списку опечаток, где могут быть приведены нормативные исправления к текущему документу.

Также смотрите переводы.


Резюме

RDF — это формат данных (в виде ориентированного маркированного графа) для представления информации в всемирной паутине. Настоящая спецификация определяет синтаксис и семантику языка запросов SPARQL для RDF. SPARQL используется для представления запросов к разнообразным источникам данных, независимо от того, хранятся эти данные непосредственно в RDF либо представляются в виде RDF с помощью промежуточного программного обеспечения (middleware). SPARQL обладает возможностями формирования запросов к обязательным и необязательным графовым шаблонам вместе с их конъюнкциями и дизъюнкциями. SPARQL также поддерживает тестирование расширенного значения и ограничение запросов посредством исходного RDF-графа. Результаты запросов SPARQL могут быть представлены результирующими наборами или RDF-графами.

Статус текущего документа

Настоящий раздел описывает статус текущего документа на момент его публикации. Документ может быть заменен другими. Перечень текущих публикаций W3C и последних изменений этого технического отчета можно найти посредством указателя технических отчетов на странице http://www.w3.org/TR/.

Этот документ является рекомендацией W3C.

Документ пересмотрен членами W3C, проверен разработчиками программного обеспечения и другими заинтересованными сторонами и группами W3C, одобрен директором как рекомендация W3C. Документ является неизменным и может быть использован в качестве ссылки или цитаты из другого документа. Создавая рекомендацию, W3C стремится привлечь внимание к спецификации и содействовать ее широкому распространению, что расширяет функциональность и интероперабельность Web.

Комментарии касательно данного документа могут быть отправлены по адресу public-rdf-dawg-comments@w3.org, список рассылки архив сообщений. Вопросы и комментарии по SPARQL, не имеющие отношения к данной спецификации, в том числе расширения и дополнительные функции, могут обсуждаться в рассылке public-sparql-dev@w3.org, (архив сообщений).

Настоящий документ создан рабочей группой доступа к RDF-данным, деятельность которой осуществляется в рамках W3C Semantic Web Activity. Первая публикация документа в виде рабочего проекта датируется 12 октября 2004, после чего рабочая группа получила ряд комментариев и замечаний . После публикации предполагаемой рекомендации в ноябре 2007 года внесены две правки, которые отражены в логе.

Отчет рабочей группы по применению протокола SPARQL (SPARQL Query Language For RDF Implementation Report) показал, что задачи интероперабельности, поставленные в июне 2007 года (возможная рекомендация), были успешно решены.

Рабочая группа по доступу к данным (DAWG) отложила реализацию 12 замечаний, в том числе, аггрегированные функции, и операции обновления.

При создании данного документа рабочая группа руководствовалась патентной политикой W3C от 5 февраля 2004. W3C поддерживает публичный список открытых патентов, сформированный совместно с членами группы. На этой странице также представлены инструкции по раскрытию патента. Лица, обладающие актуальной информацией о патенте, который удовлетворяет основным требованиям, должны раскрыть эту информацию согласно пункту 6 патентной политики W3C.


Содержание

Приложения


1 Введение

RDF является форматом данных (в виде ориентированного маркированного графа) для представления информации во всемирной паутине. Довольно часто RDF используется для представления, кроме всего прочего, личной информации, социальных сетей, метаданных о цифровых артефактах, а также для предоставления средств интеграции несопоставимых источников информации. Настоящая спецификация определяет синтаксис и семантику языка запросов SPARQL для RDF.

Язык запросов SPARQL для RDF предназначен для удовлетворения требований и соответствия вариантам использования, которые заданы рабочей группой, занимающейся доступом к RDF-данным, в документе Доступ к данным RDF: варианты использования и требования [UCNR].

Язык запросов SPARQL тесно связан с нижеперечисленными спецификациями:

1.1 Краткий обзор документа

Если в заголовке раздела не установлено иного, все разделы и приложения этого документа являются нормативными

Настоящий раздел документа, раздел 1, вводит читателя в курс спецификации языка запросов SPARQL. Здесь описана общая организация документа, а также приянтые в его рамках соглашения.

В разделе 2 данной спецификации приведен ряд примеров запросов с результатами их выполнения, что позволит читателю непосредственно ознакомиться с языком запросов SPARQL. В разделе 3 продолжается описание языка SPARQL-запросов. Здесь представлено больше примеров, демонстрирующих возможности SPARQL по заданию ограничений RDF-терминов.

Раздел 4 содержит подробности по синтаксису языка запросов SPARQL. Это дополнение к полному описанию грамматики языка. Здесь определены грамматические конструкции для представления IRI, безымянных вершин, литералов и переменных. Раздел 4 также определяет значения нескольких грамматических конструкций, которые играют роль синтаксического сахара для более многословных выражений.

Раздел 5 знакомит с основными и групповыми графовыми шаблонами, которые являются строительными блоками для более сложных шаблонов SPARQL-запросов. В 6, 7 и 8 разделах представлены конструкции, объединяющие графовые шаблоны SPARQL в более масштабные графовые шаблоны. В частности, в разделе 6 рассказывается о том, как сделать части запроса необязательными. В разделе 7 представлены возможности выражения дизъюнкции альтернативных графовых шаблонов. В разделе 8 содержится информация по ограничению частей запроса определенными исходными графами. Здесь также приведен механизм SPARQL по определению исходных графов для запроса.

Раздел 9 определяет конструкции, которые влияют на решения запроса, — упорядочение, slicing (разделение на слои), проекция, ограничение и удаление повторов из последовательности решений.

Раздел 10 определеяет четыре типа SPARQL-запросов, которые порождают результаты в разных формах

Раздел 11 описывает средства тестирования расширенных значений SPARQL. Здесь также представлены функции и операторы, которые могут применяться для ограничения значений, которые появляются в результатах запроса.

Раздел 12 является формальным определением оценки графовых шаблонов SPARQL и модификаторов решений.

Приложение A содержит нормативное определение синтаксиса языка запросов SPARQL согласно грамматике, выраженной в нотации EBNF (расширенная форма Бэкуса-Наура).

1.2 Принятые в документе соглашения

1.2.1 Пространства имен

Примеры данного документа предполагают следующие привязки префикса пространства имен, если не оговорено иного:

Префикс 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#

1.2.2 Описания данных

Для наглядного представления каждого триплета в данном документе используется формат Turtle [TURTLE]. Turtle позволяет ввести сокращения для IRI с помощью префиксов:

@prefix dc:   <http://purl.org/dc/elements/1.1/> .
@prefix :     <http://example.org/book/> .
:book1  dc:title  "SPARQL Tutorial" .

1.2.3 Описания результатов

Результирующие наборы представлены в табличном виде.

x y z
"Alice" <http://example/a>      

'Привязка' представлена парой (переменная, RDF-термин). В этом результирующем наборе имеется три переменных: x, y и z (показаны заголовками столбцов). Каждое решение - это строка таблицы. В данном случае решение будет единственным, где переменная x связана с "Alice", переменная y - с <http://example/a>, и переменная z не связана с RDF-термином. Переменные не обязательно связаны в решении.

1.2.4 Терминология

Язык SPARQL включает IRI — подмножество ссылок RDF URI (RDF URI References), которые опускают пробелы. Обратите внимание, что все IRI в запросах SPARQL являются абсолютными; они могут включать или не включать идентификатор фрагмента [RFC3987, раздел 3.1]. IRI включают URI [RFC3986] и URL. Сокращенные формы (относительные IRI и префиксные имена) синтаксиса SPARQL позволяют генерировать абсолютные IRI.

Следующие термины определены документом RDF: концепции и абстрактный синтаксис [CONCEPTS] и используются в SPARQL:

2 Создание простых запросов (Informative)

Большая часть запросов SPARQL включает набор шаблонов триплетов, который называется основным графовым шаблоном. Шаблоны триплетов похожи на RDF-триплеты, за исключением того, что каждый субъект, предикат и объект может быть переменной. Основной графовый шаблон соответствует подграфу RDF-данных, когда RDF-термины этого подграфа могут быть заменены переменными, а результат является RDF-графом, эквивалентным подграфу.

2.1 Написание простого запроса

Пример ниже демонстрирует SPARQL-запрос, позволяющий определить название книги из заданного графа данных. Запрос состоит из двух частей: условие SELECT задает переменные, которые должны отображаться в результатах запроса, а условие WHERE предоставляет основной графовый шаблон, которому должны соответсвовать графовые данные. В этом примере основной графовый шаблон состоит из одного шаблона триплета с единственной переменной (?title) на месте объекта.

Данные:

<http://example.org/book/book1> <http://purl.org/dc/elements/1.1/title> "SPARQL Tutorial" .

Запрос:


SELECT ?title
WHERE
{
  <http://example.org/book/book1> <http://purl.org/dc/elements/1.1/title> ?title .
}    

Этот запрос, выполненный над вышеприведенными данными, имеет единственное решение:

Результат запроса:

title
"SPARQL Tutorial"

2.2 Множественные соответсвия

В результате запроса получаем последовательность решений с данными, соответствующими графовому шаблону запроса. Запрос может обуславливать получение одного или множества решений, либо вообще отсутствие решений.

Данные:

@prefix foaf:  <http://xmlns.com/foaf/0.1/> .

_:a  foaf:name   "Johnny Lee Outlaw" .
_:a  foaf:mbox   <mailto:jlow@example.com> .
_:b  foaf:name   "Peter Goodguy" .
_:b  foaf:mbox   <mailto:peter@example.org> .
_:c  foaf:mbox   <mailto:carol@example.org> .

Запрос:

PREFIX foaf:   <http://xmlns.com/foaf/0.1/>
SELECT ?name ?mbox
WHERE
  { ?x foaf:name ?name .
    ?x foaf:mbox ?mbox }

Результат запроса:

name mbox
"Johnny Lee Outlaw" <mailto:jlow@example.com>
"Peter Goodguy" <mailto:peter@example.org>

Каждое решение дает единственный способ связи переменных с RDF-терминами, обеспечивая таким образом соответствие данных шаблону запроса. Результирующий набор предоставляет все возможные решения. В вышеприведенном примере следующие два подмножества данных обуславливают два соответствия.

 _:a foaf:name  "Johnny Lee Outlaw" .
 _:a foaf:box   <mailto:jlow@example.com> .
 _:b foaf:name  "Peter Goodguy" .
 _:b foaf:box   <mailto:peter@example.org> .

Это соответствие основному графовому шаблону: все переменные, задействованные в шаблоне запроса, должны быть связаны в каждом решении.

2.3 Установление соответствия RDF литералам

Следующие данные содержат три 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 .

Обратите внимание, что в Turtle, "cat"@en является RDF литералом с лексической формой "cat" и языком en; "42"^^xsd:integer - типизированным литералом с типом данных (datatype), соответствующим http://www.w3.org/2001/XMLSchema#integer; и "abc"^^dt:specialDatatype - типизированным литералом с типом данных, соответствующим http://example.org/datatype#specialDatatype.

Эти RDF-данные являются графом данных для примеров запросов, приведенных в разделах 2.3.1–2.3.3.

2.3.1 Соответствие литералов тегам языка

Теги языка в SPARQL выражаются с помощью @ и собственно тега языка, как описано в документе Лучшие общие практики 47 [BCP47].

Следующий запрос не имеет решения, так как "cat" не является тем же RDF литералом, что и "cat"@en:

SELECT ?v WHERE { ?v ?p "cat" }

   v    

однако следующий запрос все-таки найдет решение, где переменная v связана с :x, потому как тег языка определен и соответствует исходным данным:

SELECT ?v WHERE { ?v ?p "cat"@en }
v
<http://example.org/ns#x>

2.3.2 Соответствие литералам с числовыми типами

Целые числа в запросе SPARQL соответствуют типизированным RDF литералам с типом данных xsd:integer. Скажем: 42 - это сокращенная форма от   "42"^^<http://www.w3.org/2001/XMLSchema#integer>.

Шаблон в следующем запросе имеет решение с переменной v, связанной с :y.

SELECT ?v WHERE { ?v ?p 42 }
v
<http://example.org/ns#y>

Раздел 4.1.2 определяет сокращенные формы SPARQL для xsd:float и xsd:double.

2.3.3 Соответствие литералам с произвольными типами данных

Следующий запрос имеет решение с переменной v, связанной с :z. Обработчик запросов вовсе не должен иметь какое-либо представление о значениях в пространстве типа данных, так как лексическая форма и тип данных IRI соответствуют литералам.

SELECT ?v WHERE { ?v ?p "abc"^^<http://example.org/datatype#specialDatatype> }
v
<http://example.org/ns#z>

2.4 Метки безымянных вершин в результатах запроса

Результаты запроса могут содержать безымянные вершины. Безымянные вершины в результирующих наборах примера данного документа записываются начиная с символов "_:" за которыми следует метка безымянной вершины.

Метки безымянных вершин имеют область действия, ограниченную результирующим набором (как описано в документе "SPARQL Query Results XML Format"), либо результирующим графом, который получается после выполнения запроса CONSTRUCT. Использование идентичных названий в результирующем множестве предполагает одинаковые безымянные вершины.

Данные:
@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"

Вышеприведенные результаты могли быть получены с тем же успехом при других метках безымянных вершин, потому как метки в результатах лишь указывают на то, одинаковы или нет RDF-термины в решениях.

x name
_:r "Alice"
_:s "Bob"

Эти два результата содержат одну и ту же информацию. Безымянные вершины, используемые для установления соответствия запросу, отличаются в обоих решениях. Нет необходимости в наличии каких-либо отношений между меткой _:a в результирующем наборе и безымянной вершиной в графе данных с той же меткой.

Разработчику приложения не стоит связывать метки безымянных вершин в запросе с определенными безымянными вершинами в данных.

2.5 Построение RDF-графов

В SPARQL есть несколько форм запросов. Форма запроса SELECT возвращает привязки переменных. Форма запроса CONSTRUCT возвращает RDF-граф. Граф строится на базе шаблона, который применяется для генерации RDF-триплетов на основе результатов соответствия графовому шаблону запроса.

Данные:

@prefix org:    <http://example.com/ns#> .

_:a  org:employeeName   "Alice" .
_:a  org:employeeId     12345 .

_:b  org:employeeName   "Bob" .
_:b  org:employeeId     67890 .

Запрос:

PREFIX foaf:   <http://xmlns.com/foaf/0.1/>
PREFIX org:    <http://example.com/ns#>

CONSTRUCT { ?x foaf:name ?name }
WHERE  { ?x org:employeeName ?name }

Результаты:

@prefix org: <http://example.com/ns#> .
      
_:x foaf:name "Alice" .
_:y foaf:name "Bob" .

которые могут быть сериализованы в RDF/XML следующим образом:

<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>

3 Ограничения RDF-термина (информативный)

Установление Соответствие графовому шаблону приводит к последовательности решений, где каждое решение имеет набор привязок переменных к RDF-терминам. SPARQL-фильтры (FILTER) накладывают ограничения на эти решения, пропуская лишь те решения, при которых значение выражения фильтра принимает значение TRUE.

Данный раздел представляет собой информативное введение в фильтры SPARQL (FILTER); их семантика определена в Разделе 11. Тестирование значений. Примеры этого раздела используют один исходный граф:

Данные:
@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 .

3.1 Ограничение строковых значений

Функции SPARQL-фильтров, например, regex, позволяют тестировать RDF-литералы. Функция regex соответствует только простым (plain) литералам без тега языка. Эта функция может применяться для сооветствия лексическим формам других литералов, используя функцию str .

Запрос:

PREFIX  dc:  <http://purl.org/dc/elements/1.1/>
SELECT  ?title
WHERE   { ?x dc:title ?title
          FILTER regex(?title, "^SPARQL") 
        }

Результат запроса:

title
"SPARQL Tutorial"

Соответствие регулярного выражения можно сделать чувствительными к регистру при помощи флага "i" flag.

Запрос:

PREFIX  dc:  <http://purl.org/dc/elements/1.1/>
SELECT  ?title
WHERE   { ?x dc:title ?title
          FILTER regex(?title, "web", "i" ) 
        }

Результат запроса:

title
"The Semantic Web"

Язык регулярных выражений описан в XQuery 1.0 и XPath 2.0 функции и операторы и основан на регулярных выражениях XML-схемы.

3.2 Ограничение числовых значений

Фильтры SPARQL могут накладывать ограничения на арифметические выражения.

Запрос:

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 . }

Результат запроса:

title price
"The Semantic Web" 23

После введения ограничений на переменную price, запросу стала удовлетворять только :book2, т.к. только у :book2 стоимость меньше 30.5, что требуется условием фильтра.

3.3 Другие ограничения термина

Кроме числовых типов, SPARQL поддерживает xsd:string, xsd:boolean и xsd:dateTime (см. раздел 11.1 Типы данных операнда). 11.3 Операторное преобразование приведен набор тестовых функций( в том числе BOUND, isLITERAL и langMATCHES) и средств доступа, включая STR, LANG и DATATYPE). В разделе 11.5 Функции конструктора перечислен набор функций конструктора XML-схемы, которые присутствуют в языке SPARQL и позволяют переводить значения из одного типа в другой.

4 Синтаксис SPARQL

В данном разделе раскрыт синтаксис, используемый в SPARQL для RDF-терминов и шаблонов триплетов. Полное описаниеграмматики приведено в приложении A.

4.1 Синтаксис RDF-термина

4.1.1 Синтаксис IRI

Продукция (нетерминал в русском переводе терминологии BNF) IRIref обозначает набор IRI [RFC3987]; IRI представляют собой обобщение URI [RFC3986] и полностью совместимы с URI и URL. Продукция PrefixedName обозначает префиксное имя. Ниже описано преобразование префиксного имени в IRI. Ссылки IRI (относительные и абсолютные IRI) определяются продукции IRI_REF, где ограничители '<' и '>' не формируют частей ссылки IRI. Относительные IRI соответсвуют ссылки irelative-ref, согласно разделу 2.2 ABNF для IRI ссылок и IRI из [RFC3987] и разрешены для IRI, как описано ниже.

Правила грамматики:
[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

Набор RDF-терминов, определенный документом "RDF: концепции и абстрактный синтаксис", включает ссылки RDF URI, тогда как SPARQL-термины включают IRI. Ссылки RDF URI, содержащие "<", ">", '"' (двойные кавычки), пробелы, "{", "}", "|", "\", "^", и "`" не являются IRI. Поведение SPARQL-запросов по отношению к RDF-утверждениям, составленным из таких ссылок RDF URI, не определено.

Префиксные имена

Ключевое слово PREFIX связывает метку префикса с IRI. Префиксное имя представляет собой метку префикса с локальным элементом (local part), разделенными двоеточием ":". Префиксное имя преобразовывается в IRI путем конкатенации IRI, связанного с префиксом, и локального элемента. Метка префикса либо локальный элемент могут быть пустыми. Обратите внимание, что локальные имена SPARQL могут начинаться с цифры, в то время как локальные имена XML нет.

Относительные IRI

Относительные IRI составлены из базовых IRI, в соответствии с документом Uniform Resource Identifier (URI): общий синтаксис [RFC3986], используя лишь основной алгоритм в разделе 5.2. Не выполняются нормализации, описанные в разделах 6.2.2 и 6.2.3 RFC3986: ни на основе синтаксиса (Syntax-Based Normalization), ни на основе схемы (Scheme-Based Normalization). Дополнительно разрешенные символы в ссылках IRI обрабатываются аналогично незарезервированным символам в ссылках URI, согласно разделу 6.5 документа Internationalized Resource Identifiers (IRIs) [RFC3987].

Ключевое слово BASE определяет базовый IRI, используемый для разрешения относительных IRI согласно разделу 5.1.1 "Базовый URI, встроенный в контент " RFC3986. Раздел 5.1.2, "Базовый URI от инкапсулированной сущности " определяет, как базовый IRI может поступать от инкапсулированного документа, как например, SOAP envelope с директивой xml:base или многосоставной документ mime (mime multipart document) с заголовком, определяющим местоположение контента (Content-Location header). Описанный в разделе 5.1.3 "Полученный URI", "Базовый URI из полученного URI" — это URL, откуда был получен определенный запрос SPARQL. Если ничто из вышеперечисленного не определяет базового URI, используется базовый URI по умолчанию (раздел 5.1.4, "Базовый URI по умолчанию").

Следующий фрагмент демонстрирует несколько способов написания одного и того же IRI:

<http://example.org/book/book1>
BASE <http://example.org/book/>
<book1>
PREFIX book: <http://example.org/book/>

book:book1

4.1.2 Синтаксис литералов

Общий синтаксис литералов представляет собой строку (заключенную либо в двойные, либо в одинарные кавычки - "...", или, '...'), либо с необязательным тегом языка (который начинается с @), либо с необязательным типом данных (datatype) IRI или префиксным именем (которое начинается с ^^).

Для удобства целые числа можно записывать непосредственно (без кавычек и явных типов данных IRI). Они интерпретируются как типизированные литералы со значением datatype, равным xsd:integer. Десятичные числа — в которых присутствует дробная часть, отделенная '.', но не представленные в экспоненциальной форме — интерпретируются как xsd:decimal. А числа, представленные в экспоненциальной форме — как xsd:double. Значения типа xsd:boolean можно записать как true или false.

Для облегчения записи значений литералов, которые сами по себе содержат кавычки или являются настолько длинными, что содержат символы перевода строки, SPARQL предлагает дополнительную конструкцию с кавычками, в которой литералы заключены в три одинарные или двойные кавычки.

Ниже приведены примеры синтаксиса литералов в SPARQL:

Правила грамматики:
[60]   RDFLiteral   ::=   String ( LANGTAG | ( '^^' IRIref ) )?
[61]   NumericLiteral   ::=   NumericLiteralUnsigned |
NumericLiteralPositive |
NumericLiteralNegative
[62]   NumericLiteralUnsigned   ::=   INTEGER | DECIMAL | DOUBLE
[63]   NumericLiteralPositive   ::=   INTEGER_POSITIVE |
DECIMAL_POSITIVE |
DOUBLE_POSITIVE
[64]   NumericLiteralNegative   ::=   INTEGER_NEGATIVE |
DECIMAL_NEGATIVE |
DOUBLE_NEGATIVE
[65]   BooleanLiteral   ::=   'true' | 'false'
[66]   String   ::=   STRING_LITERAL1 | STRING_LITERAL2 |
STRING_LITERAL_LONG1 | STRING_LITERAL_LONG2
[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 )* '"'

Символы, соответствующие продукциям INTEGER, DECIMAL, DOUBLE и BooleanLiteral, эквивалентны типизированному литералу с лексическим значением символа и соответствующим типом данных: xsd:integer, xsd:decimal, xsd:double, xsd:boolean.

4.1.3 Синтаксис переменных запроса

Переменные запроса в SPARQL-запросах имеют глобальную область действия. Использование заданного имени переменной где-либо в запросе указывает на одну и туже переменную. переменные могут иметь только префиксы "?" или "$"; "?" или "$" не являются составными частями имени переменной. $abc и ?abc обозначают в запросе одинаковые переменные. Допустимые имена для переменных приведены в грамматике 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] )*

4.1.4 Синтаксис безымянных вершин

Безымянные вершины в шаблонах графа воспринимаются как неизвестные переменные, а не как ссылки на отдельные безымянные вершин в данных, к которым выполняется запрос.

Безымянные вершины обозначаются либо с помощью меток, например,"_:abc", либо посредством сокращенной формы "[]". Безымянная вершина, которая используется в синтаксисе запроса только один раз, может обозначаться с помощью []. Уникальная безымянная вершина будет использоваться для формирования шаблона триплета. Метки безымянных вершин записываются как "_:abc" ( для безымянной вершины с меткой "abc"). Одинаковые метки безымянных вершин не могут быть использованы в двух различных основных графовых шаблонах в одном и том же запросе.

Конструкция[:p :v] может быть использована в шаблонах триплетов. Она создает метку безымянной вершины, которая в свою очередь применяется в качестве субъекта для всех заключенных внутри пар предикат-объект. Созданная безымянная вершина может также использоваться в последующих шаблонах триплетов на месте субъекта и объекта.

Следующие две формы

[ :p "v" ] .
[] :p "v" .

задают уникальную метку безымянной вершины (в данном случае "b57"), что эквивалентно записи:

_:b57 :p "v" .

Заданная метка вершины может быть использована в качестве субъекта или объекта для последующих шаблонов триплетов. Например, в качестве субъекта:

[ :p "v" ] :q "w" .

эквивалентного двум триплетам:

_:b57 :p "v" .
_:b57 :q "w" .

и объекта:

:x :q [ :p "v" ] .

эквивалентного двум триплетам:

:x  :q _:b57 .
_:b57 :p "v" .

Сокращенный синтаксис безымянных вершин может быть совмещен с другими сокращенными формами для общих субъектов и общих предикатов.


  [ foaf:name  ?name ;
    foaf:mbox  <mailto:alice@example.org> ]

Для некоторой уникально заданной метки безымянной вершины "b18" с равным успехом можно записать следующий основной графовый шаблон:

  _:b18  foaf:name  ?name .
  _:b18  foaf:mbox  <mailto:alice@example.org> .
Правила грамматики:
[39]   BlankNodePropertyList   ::=   '['PropertyListNotEmpty']'
[69]   BlankNode   ::=   BLANK_NODE_LABEL | ANON
[73]   BLANK_NODE_LABEL   ::=   '_:' PN_LOCAL
[94]   ANON   ::=   '[' WS* ']'

4.2 Синтаксис шаблонов триплетов

Шаблоны триплетов записываются в виде разделенного пробелами списка: субъект, предикат и объект. Существуют варианты сокращенной записи некоторых простых конструкций шаблонов триплетов.

Следующие примеры демонстрируют один и тот же запрос:

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 |
TriplesNode PropertyList
[33]   PropertyListNotEmpty   ::=   Verb ObjectList ( ';' ( Verb ObjectList )? )*
[34]   PropertyList   ::=   PropertyListNotEmpty?
[35]   ObjectList   ::=   Object ( ',' Object )*
[37]   Verb   ::=   VarOrIRIref | 'a'

4.2.1 Списки предикат-объект

Шаблоны триплетов с простым субъектом могут быть записаны таким образом, что субъект упоминается в записи лишь единожды и используется для более чем одного шаблона триплета. Для этих целей применяется нотация ";".

    ?x  foaf:name  ?name ;
        foaf:mbox  ?mbox .

Это эквивалентно записи шаблонов триплетов:

    ?x  foaf:name  ?name .
    ?x  foaf:mbox  ?mbox .

4.2.2 Списки объектов

Если шаблоны триплетов используют общий и субъект, и предикат, объекты могут быть отделены посредством ",".

    ?x foaf:nick  "Alice" , "Alice_" .

Это эквивалентно записи шаблонов триплетов:

   ?x  foaf:nick  "Alice" .
   ?x  foaf:nick  "Alice_" .

Списки объектов могут быть объединены со списками предикат-объект:

   ?x  foaf:name ?name ; foaf:nick  "Alice" , "Alice_" .

что эквивалентно следующей записи:

   ?x  foaf:name  ?name .
   ?x  foaf:nick  "Alice" .
   ?x  foaf:nick  "Alice_" .

4.2.3 RDF-коллекции

RDF-коллекции могут быть записаны в виде шаблонов триплетов, используя синтаксис "(element1 element2 ...)". Форма "()" является альтернативной для IRI http://www.w3.org/1999/02/22-rdf-syntax-ns#nil. При использовании с элементами коллекции ( скажем,(1 ?x 3 4), для коллекции назначаются шаблоны триплетов с безымянными вершинами. безымянная вершина в заголовке коллекции может использоваться как субъект или объект в других шаблонах триплетов. Безымянные вершины, расположенные внутри синтаксиса коллекции, не могут встречаться в каких-либо других частях запроса.

(1 ?x 3 4) :p "w".

Данная запись является синтаксическим сахаром (т.е. эквивалентной, но более удобной для человека формой записи) для нижеприведенного (обратите внимание, что b0, b1, b2 и b3 больше нигде в теле запроса не встречаются):

    _: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" . 

RDF-коллекции могут быть вложенными и включать другие синтаксические формы:

(1 [:p :q] ( 2 ) ) .

является синтаксическим сахаром для:

    _: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* ')'

4.2.4 rdf:type

Ключевое слово "a"может быть использовано в качестве предиката в шаблоне триплета и является альтернативой для IRI  http://www.w3.org/1999/02/22-rdf-syntax-ns#type. Данное ключевое слово чувствительно к регистру

  ?x  a  :Class1 .
  [ a :appClass ] :p "v" .

является синтаксическим сахаром для:

  ?x    rdf:type  :Class1 .
  _:b0  rdf:type  :appClass .
  _:b0  :p        "v" .

5 Графовые шаблоны

SPARQL основан на установлении соответствия графовому шаблону. Более сложные графовые шаблоны могут быть сформированы путем объединения меньших шаблонов. Существуют различные способы компоновки графовых шаблонов:

В этом разделе мы описываем две формы компоновки шаблонов при помощи конъюнкции: основные графовые шаблоны, которые объединяют шаблоны триплетов, и групповые графовые шаблоны, которые объединяют все остальные графовые шаблоны.

Внешний графовый шаблон в запросе называется шаблоном запроса. Грамматически он определяется посредством GroupGraphPattern в

[13]   WhereClause   ::=   'WHERE'? GroupGraphPattern

5.1 Основные графовые шаблоны

Основные графовые шаблоны представлены наборами шаблонов триплетов. Соответствие графовому шаблону SPARQL определено в терминах объединения результатов соответствия основным графовым шаблонам.

Последовательность шаблонов триплетов, ограниченных фильтром, составляет единый основной графовый шаблон. Любой графовый шаблон в конце концов представляется в виде основного графового шаблона.

5.1.1 Метки безымянных вершин

При использовании безымянных вершин в виде _:abc,  область действия меток безымянных вершин ограничивается основным графовым шаблоном. В любом запросе метка может применяться лишь в одном основном графовом шаблоне.

5.1.2 Расширение соответствия основному графовому шаблону

SPARQL предназначен для нахождения соответствия RDF-графам с простым следованием. SPARQL может быть расширен до поддержки других форм следования с помощью ввода определенных условий (ограничений),описанных ниже.

5.2 Групповые графовые шаблоны

Групповой графовый шаблон в строке запроса SPARQL ограничен фигурными скобками: {}. Например, запросный шаблон этого запроса представлен групповым шаблоном запроса, состоящим из одного основного графового шаблона.

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

5.2.1 Пустой групповой шаблон

Групповой шаблон:

{ }

соответствует любому графу (в том числе и пустому графу) с одним решением, которое не связывает какие-либо переменные. Например:

SELECT ?x
WHERE {}

соответствует одному решению, где x является фиктивной переменной.

5.2.2 Область действия фильтров

Ограничение, выраженное с помощью использования ключевого слова FILTER, накладывает определенные рамки на решения. Действие ограничения распространяется на всю группу, в которой присутствует фильтр. Все следующие шаблоны имеют одинаковые решения:

 {  ?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 .
 }

5.2.3 Примеры группового графового шаблона

  {
    ?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 .
  }

Это группа из трех элементов: основного графового шаблона с одним шаблоном триплета, пустая группа и еще один основной графовый шаблон с одним шаблоном триплета.

6 Включение необязательных значений

Основные графовые шаблоны позволяют приложениям формировать запросы, полные шаблоны которых должны соответствовать, чтобы существовало решение. Для каждого решения запроса, содержащего лишь групповые графовые шаблоны с хотя бы одним основным графовым шаблоном, каждая переменная связана с RDF-термином в решении. Однако обычные законченные структуры не могут быть допущены во всех RDF-графах. Полезными оказываются такие запросы, которые позволяют добавить информацию к решению, где эта информация доступна, однако не отменять решение из-за того, что некоторая часть шаблона запроса не соответствует. Необязательное соответствие обеспечивает такую возможность: если необязательная часть не соответствует, просто не создается связей, но само решение не исключается.

6.1 Соответствие необязательному шаблону

Необязательные составляющие графового шаблона могут быть определены синтаксически при помощи ключевого слова OPTIONAL, применимого к графовому шаблону:

pattern OPTIONAL { pattern }

Синтаксическая форма:

{ OPTIONAL { pattern } }

эквивалентна следующей записи:

{ { } OPTIONAL { pattern } }
Правило грамматики:
[23]   OptionalGraphPattern   ::=   'OPTIONAL' GroupGraphPattern

Ключевое слово OPTIONAL является левоассоциативным:

pattern OPTIONAL { pattern } OPTIONAL { pattern }

что эквивалентно записи:

{ pattern OPTIONAL { pattern } } OPTIONAL { pattern }

При необязательном соответствии либо необязательный графовый шаблон соответствует графу (таким образом, определяя и добавляя привязки к одному или большему числу решений), либо он оставляет решение неизменным, не добавляя никаких дополнительных привязок.

Данные:

@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:alice@example.com> .
_:a  foaf:mbox       <mailto:alice@work.example> .

_: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 }
       }

Учитывая вышеприведенные данные, результат запроса будет следующим:

name mbox
"Alice" <mailto:alice@example.com>
"Alice" <mailto:alice@work.example>
"Bob"

В решении отсутствует значение mbox там, где name равно "Bob".

Данный запрос находит имена людей в исходных данных. Если существует триплет с предикатом mbox и тем же субъектом, то решение будет содержать также объект этого триплета. В необязательной части запроса вышеприведенного примера задан лишь единственный шаблон триплета. Однако в общем случае необязательная часть запроса может быть представлена любым графовым шаблоном. Полный необязательный графовый шаблон должен соответствовать необязательному графовому шаблону для воздействия на решение запроса.

6.2 Ограничения в необязательном шаблоне

Ограничения могут быть заданы в необязательном графовом шаблоне. Например:

@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

Значение price для книги с title, соответствующим "SPARQL Tutorial", не отображается, потому как необязательный графовый шаблон не приводит к решению, которое бы содержало переменную "price".

6.3 Множественные необязательные графовые шаблоны

Графовые шаблоны определяются рекурсивно. Графовый шаблон может содержать ноль или более необязательных графовых шаблонов, а любая часть шаблона запроса может иметь необязательную часть. В этом примере предлагается два необязательных графовых шаблона.

Данные:

@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:bob@work.example> .
Запрос:
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 }
       }

Результат запроса:

name mbox hpage
"Alice" <http://work.example.org/alice/>
"Bob" <mailto:bob@work.example>

7 Соответствие альтернативам

SPARQL предлагает средства компоновки графовых шаблонов так, чтобы поиск соответствия мог вестись для нескольких альтернативных графовых шаблонов. Если более одной альтернативы соответствуют, то находятся все возможные решения шаблонов.

Альтернативы шаблонов синтаксически определяются при помощи ключевого слова 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 } }

Результат запроса:

title
"SPARQL Protocol Tutorial"
"SPARQL"
"SPARQL (updated)"
"SPARQL Query Language Tutorial"

Данный запрос находит все названия (title) книг из исходных данных, где эти названия записаны с помощью свойств Dublin Core версии 1.0 или 1.1. Для того, чтобы определить, как именно была записана информация, запрос должен использовать различные переменные для двух альтернатив:


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"

Это вернет результаты с переменной x, связанной с решениями из левой части от UNION, и y, связанной с решениями из правой части. Если ни одна часть шаблона UNION не соответствует, тогда графовый шаблон соответствовать не будет.

Шаблон UNION объединяет графовые шаблоны; каждая альтернатива в принципе может содержать более одного шаблона триплета:

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"

Этот запрос будет соответствовать книге лишь в том случае, если ее предикаты, обозначающие как автора, так и название, будут взяты из одной версии Дублинского ядра.

Правило грамматики:
[25]   GroupOrUnionGraphPattern   ::=   GroupGraphPattern
( 'UNION' GroupGraphPattern )*

8 Набор данных RDF

Модель данных RDF выражает информацию в виде графов, содержащих триплеты с субъектом, предикатом и объектом. Большинство хранилища данных RDF поддерживают множественные RDF-графы и записывают информацию о каждом графе, позволяя приложению создавать запросы, которые включают информацию из более одного графа.

Запрос SPARQL выполняется над набором данных, которые представляют собой коллекцию графов. Набор данных RDF содержит один граф без имени (граф по умолчанию) и ноль или более поименованных графов, где каждый поименованный граф определяется посредством IRI. Запрос SPARQL может соответствовать различным частям шаблона запроса разных графов, в соответствии с разделом 8.3 Выполнение запросов к набору данных.

В наборе данных RDF могут отсутствовать поименованные графы. Набор данных RDF всегда содержит один граф по умолчанию. Запросу вовсе не обязательно соответствовать графу по умолчанию; запрос может просто соответствовать поименованным графам.

Граф(GRAPH), используемый для соответствия основному графовому шаблону, называется активным графом. В предыдущих разделах все приведенные запросы выполнялись над одним графом, графом по умолчанию для набора данных RDF, выступающего активным графом. Ключевое слово GRAPH применялось для того, чтобы сделать активный граф одним из всех поименованных графов в наборе данных для части запроса.

8.1 Примеры наборов данных RDF

Определение набора данных RDF не ограничивает отношений между поименованными графами и графами по умолчанию. Информация может повторяться в разных графах; отношения между графами могут быть открытыми (Exposed). Два полезных мероприятия:

Пример 1:
# 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:bob@oldcorp.example.org> .

# Named graph: http://example.org/alice
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

_:a foaf:name "Alice" .
_:a foaf:mbox <mailto:alice@work.example.org> .

В этом примере граф по умолчанию содержит имена авторов публикаций двух поименованных графов. Здесь триплеты поименованных графов являются невидимыми в графе по умолчанию.

Пример 2:

Данные RDF могут быть скомпонованы при помощи объединения RDF-графов [RDF-MT]. В качестве возможной меры упорядочивания графов в наборе данных RDF можно назвать представление графа по умолчанию в виде RDF-объединения некоторой или всей информации поименованных графов.

В данном примере поименованные графы содержат те же триплеты, что и ранее. Набор данных RDF включает RDF-объединение поименованных графов в графе по умолчанию, повторное назначение меток пустым вершинам для сохранения их индивидуальности.


# Default graph
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

_:x foaf:name "Bob" .
_:x foaf:mbox <mailto:bob@oldcorp.example.org> .

_:y foaf:name "Alice" .
_:y foaf:mbox <mailto:alice@work.example.org> .

# Named graph: http://example.org/bob
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

_:a foaf:name "Bob" .
_:a foaf:mbox <mailto:bob@oldcorp.example.org> .
# Named graph: http://example.org/alice
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

_:a foaf:name "Alice" .
_:a foaf:mbox <mailto:alice@work.example > .

При RDF-объединении безымянные вершины объединенного графа не используются совместно с безымянными вершинами объединяемых графов.

8.2 Определение наборов данных RDF

Запрос SPARQL может определять набор данных, используемый при поиске соответствий. Для описания набора данных RDF используются условия FROM и FROM NAMED. Если запрос предоставляет подобное описание набора данных, тогда он применяется на месте любого набора данных, который может быть использован службой запросов, когда не задано никакого описания набора данных в запросе. Набор данных RDF может быть также задан в запросе протокола SPARQL. В таком случае описание протокола перекрывает любые описания в самом запросе. Сервис запросов может отклонить запрос, если описание набора данных не допустимо для сервиса.

Ключевые слова FROM и FROM NAMED позволяют запросу определить набор данных RDF по ссылке. Эти ключевые слова указывают на то, что набор данных должен включать графы, полученные из представлений ресурсов, определенных посредством заданных IRI (т. е. абсолютная форма заданных IRI-ссылок). Набор данных, полученный в результате из нескольких условий FROM и FROM NAMED, является:

Если нет условия FROM, однако есть одно или более условий FROM NAMED, тогда набор данных включает пустой граф для графа по умолчанию.

Правила грамматики
[9]   DatasetClause   ::=   'FROM' ( DefaultGraphClause | NamedGraphClause )
[10]   DefaultGraphClause   ::=   SourceSelector
[11]   NamedGraphClause   ::=   'NAMED' SourceSelector
[12]   SourceSelector   ::=   IRIref

8.2.1 Задание графа по умолчанию

Каждое условие FROM содержит IRI, который определяет граф, используемый для формирования графа по умолчанию, что вовсе не предполагает использования поименованного графа.

В этом примере набор данных RDF содержит единственный граф по умолчанию и не содержит поименованных графов:

# 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:alice@work.example> .
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT  ?name
FROM    <http://example.org/foaf/aliceFoaf>
WHERE   { ?x foaf:name ?name }
name
"Alice"

Если запрос предусматривает более одного условия FROM,предоставляя более одного IRI для обозначения графа по умолчанию, тогда граф по умолчанию основывается на RDF-объединении графов, полученных из представлений ресурсов, определенных по заданным IRI.

8.2.2 Задание поименованных графов

С помощью условия FROM NAMED запрос может поддерживать IRI для поименованных графов в наборе данных RDF. Каждый IRI используется для обеспечения одного поименованного графа в наборе данных RDF. Использование одинаковых IRI в двух или более условиях FROM NAMED приводит к появлению в наборе данных одного поименованного графа с таким IRI.

# Graph: http://example.org/bob
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

_:a foaf:name "Bob" .
_:a foaf:mbox <mailto:bob@oldcorp.example.org> .
# Graph: http://example.org/alice
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

_:a foaf:name "Alice" .
_:a foaf:mbox <mailto:alice@work.example> .

...
FROM NAMED <http://example.org/alice>
FROM NAMED <http://example.org/bob>
...

Синтаксис FROM NAMED предполагает, что IRI определяет соответствующий граф, однако отношение между IRI и графом в наборе данных RDF является непрямым. IRI определяет ресурс, представленный графом (или если быть более точным, то документом, который сериализует граф). Для получения более подробной информации см. [WEBARCH].

8.2.3 Комбинирование FROM и FROM NAMED

Условия FROM и FROM NAMED могут быть задействованы в одном запросе.


# 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:bob@oldcorp.example.org> .
# Named graph: http://example.org/alice
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

_:a foaf:name "Alice" .
_:a foaf:mbox <mailto:alice@work.example.org> .

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 }
}

Для этого запроса набор данных RDF содержит граф по умолчанию и два поименованных графа. Ключевое слово GRAPH описано ниже.

Требуемые для создания набора данных действия определяются не только описанием набора данных. Если в описании набора данных IRI задан дважды (либо посредством двух условий FROM, либо с помощью условия FROM и условия FROM NAMED), тогда вовсе не означает, что предпринимается именно одна или конкретно две попытки получения RDF-графа, связанного с этим IRI. Следовательно, ни о каких предположениях касательно идентичности безымянных вершин в триплетах, полученных из двух мест в описании наборов данных, не может быть и речи. В общем случае нельзя сделать никаких предположений об эквивалентности графов.

8.3 Выполнение запросов к набору данных

При выполнении запросов к коллекции графов используется ключевое слово GRAPH для соответствия шаблонам поименованных графов. GRAPH может позволять IRI выбирать один граф либо использовать переменную, которая будет распространяться на IRI всех поименованных графов в наборе RDF-данных запроса.

Применение ключевого слова GRAPH меняет активный граф для соответствия основным графовым шаблонам внутри части запроса. Если GRAPH не используется, в таком случае граф по умолчанию используется для соответствия основным графовым шаблонам.

Следующие два графа будут задействованы в примерах:

# 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:alice@work.example> .
_:a  foaf:knows    _:b .

_:b  foaf:name     "Bob" .
_:b  foaf:mbox     <mailto:bob@work.example> .
_: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:bob@work.example> .
_: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

8.3.1 Получение доступа к именам графов

Следующий запрос соответствует графовому шаблону каждого поименованного графа в наборе данных и формирует решения, куда входит переменная src, связанная с IRI соответствующего графа. Графовый шаблон соответствует активному графу, каждый из которых является поименованным графом в наборе данных.


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:bob@work.example> .
      ?x foaf:nick ?bobNick
    }
  }

В результате запроса получаются имена графов, в которых была найдена информация, и значения nick для Боба:

src bobNick
<http://example.org/foaf/aliceFoaf> "Bobby"
<http://example.org/foaf/bobFoaf> "Robert"

8.3.2 Ограничение с помощью графового IRI

Запрос может запретить соответствие, применяемое к определенному графу, путем предоставления графового IRI. Такой подход позволяет установить граф, названный по IRI активным графом. Следующий запрос ищет значения nick Боба, как задано в графе http://example.org/foaf/bobFoaf.


PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIXДанные: <http://example.org/foaf/>

SELECT ?nick
FROM NAMED <http://example.org/foaf/aliceFoaf>
FROM NAMED <http://example.org/foaf/bobFoaf>
WHERE
  {
     GRAPHДанные:bobFoaf {
         ?x foaf:mbox <mailto:bob@work.example> .
         ?x foaf:nick ?nick }
  }

что приводит к единственному решению:

nick
"Robert"

8.3.3 Ограничение возможных IRI графа

Переменная, используемая в условии GRAPH, может также применяться в другом условии GRAPH или в графовом шаблоне, соответствующем графу по умолчанию в наборе данных.

В следующем запросе для поиска документа профиля Боба используется граф с IRI http://example.org/foaf/aliceFoaf. После чего он соответствует другому шаблону графа. Шаблон во втором условии GRAPH находит безымянную вершину (переменную w) для человека с тем же электронным адресом (заданным переменной mbox), который определен в первом условии GRAPH (переменная whom), потому как безымянная вершина, используемая для соответствия переменной whom из файла FOAF Алисы, не идентична безымянной вершине в документе профиля (они находятся в разных графах).

PREFIX Данные:  <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Данные:aliceFoaf
  {
    ?alice foaf:mbox <mailto:alice@work.example> ;
           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:bob@work.example> "Robert" <http://example.org/foaf/bobFoaf>

Любой триплет файла FOAF Алисы, содержащий nick Боба, не используется для предоставления nick для Боба, так как шаблон, который включает переменную nick, ограничен ppd лишь к определенному Personal Profile Document.

8.3.4 Поименованные графы и графы по умолчанию

Шаблоны запросов могут включать как граф по умолчанию, так и поименованные графы. В следующем примере агрегатор считал Web-ресурс при двух разных обстоятельствах. Каждый раз при считывании графа агрегатором, локальная система назначает графу IRI. Графы практически одинаковы, однако изменился электронный адрес для "Bob".

В данном примере граф по умолчанию используется для записи исходной информации, а фактически считанные RDF-данные сохраняются в двух отдельных графах, каждому из которых система назначает разные IRI. Набор данных RDF состоит из двух поименованных графов и информации о них.

Набор данных 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:alice@work.example> .

_:b foaf:name "Bob" .
_:b foaf:mbox <mailto:bob@oldcorp.example.org> .

# 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:alice@work.example> .

_:b foaf:name "Bob" .
_:b foaf:mbox <mailto:bob@newcorp.example.org> .

Запрос находит адреса электронной почты, выделяя также имя человека и дату получения информации.

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 }
  }

Результаты указывают на изменение адреса электронной почты для "Bob".

name mbox date
"Bob" <mailto:bob@oldcorp.example.org> "2004-12-06"^^xsd:date
"Bob" <mailto:bob@newcorp.example.org> "2005-01-10"^^xsd:date

IRI для типа данных date сокращен в результатах для большей ясности.

9 Solution Sequences and Modifiers

Шаблоны запроса генерируют неупорядоченную коллекцию решений. Каждое решение является частичной функцией переменных от RDF-терминов. Впоследствии с этими решениями оперируют, как с последовательностью (последовательностью решений), исходно неупорядоченной. Любые модификаторы последовательности впоследствии используются для создания другой последовательности. И, наконец, эта последняя последовательность применяется для генерации одного из результатов формы запроса SPARQL.

Модификатор последовательности решений является:

Последовательность применения модификаторов совпадает с последовательностью вышеприведенного списка.

Правила грамматики
[5]   SelectQuery   ::=   'SELECT' ( 'DISTINCT' | 'REDUCED' )? ( Var+ | '*' ) DatasetClause* WhereClause SolutionModifier
[14]   SolutionModifier   ::=   OrderClause? LimitOffsetClauses?
[15]   LimitOffsetClauses   ::=   ( LimitClause OffsetClause? | OffsetClause LimitClause? )
[16]   OrderClause   ::=   'ORDER' 'BY' OrderCondition+

9.1 ORDER BY

Условие ORDER BY устанавливает порядок последовательности решений

За условием ORDER BY расположены компараторы последовательности, состоящие из выражения и необязательного модификатора последовательности (ASC() либо DESC()). Каждый компаратор последовательности является либо восходящим (ascending), — обозначается модификатором ASC() или отсутствием модификатора — либо нисходящим (descending) — обозначается модификатором 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)

Оператор "<" operator (см. раздел Операторное преобразование и 11.3.1 Операторная расширяемость) определяет относительный порядок пар чисел, простых литералов, строковых значений (xsd:strings), булевых значений(xsd:booleans) и xsd:dateTimes. Пары IRI упорядочиваются путем их сравнения с простыми (simple) литералами.

SPARQL также устанавливает порядок между некоторыми видами RDF-терминов, которые не будут упорядочены иначе:

  1. (Самый нижний) в данном решении не присвоено значение переменной или выражению.
  2. Безымянные вершины
  3. IRI
  4. RDF литералы

1. Простой (plain) литерал ниже, чем RDF литерал типа xsd:string той же лексической формы.

SPARQL не задает общий порядок всех возможных RDF-терминов. Здесь представлено несколько примеров пар терминов, для которых не определен относительный порядок:

Ниже приведен перечень привязок переменных в порядке возрастания:

RDF-терминПричина
Несвязанные результаты отсортированы первыми.
_:zБезымянные вершины следуют за несвязанными.
_:aНе существует относительного упорядочивания безымянных вершин.
<http://script.example/Latin>IRI следуют за безымянными вершинами.
<http://script.example/Кириллица>Символ на 23-й позиции, "К", имеет unicode codepoint, равный 0x41A, что больше чем 0x4C ("L").
<http://script.example/漢字> Символ на 23-й позиции, "漢", имеет unicode codepoint, равный 0x6F22, что больше чем 0x41A ("К").
"http://script.example/Latin"Простые (simple) литералы следуют за IRI.
"http://script.example/Latin"^^xsd:stringxsd:string следуют за простыми (simple) литералами.

Восходящий порядок следования двух решений по отношению к компаратору упорядочения устанавливается путем замены привязок решений на выражения и сравнения их с оператором "<". Нисходящий порядок следования является обратным к восходящему.

Относительный порядок двух решений является относительным порядком двух решений касательно первого компаратора упорядочения в последовательности. Для решений, где замены привязок создают тот же RDF-термин, порядок следования является относительным порядком двух решений по отношению к следующему компаратору упорядочения. Относительный порядок двух решений не определен, если отсутствие упорядоченного выражения, оцененное для двух решений, порождает уникальные RDF-термины.

Упорядочение последовательности решений всегда приводит к последовательности с тем же числом решений.

Применение ORDER BY для последовательности решений в запросах CONSTRUCT или DESCRIBE не имеет прямого эффекта, потому как только SELECT возвращает последовательность результатов. Использование ORDER BY в комбинации вместе с LIMIT и OFFSET позволяет возвратить результаты, сгенерированные из разных слоев последовательности решений. Запрос ASK не включает ORDER BY, LIMIT или OFFSET.

Правила грамматики
[16]   OrderClause   ::=   'ORDER' 'BY' OrderCondition+
[17]   OrderCondition   ::=   ( ( 'ASC' | 'DESC' ) BrackettedExpression )
| ( Constraint | Var )
[18]   LimitClause   ::=   'LIMIT' INTEGER
[19]   OffsetClause   ::=   'OFFSET' INTEGER

9.2 Проекция

Последовательность решений может быть преобразована в одно, которое включает лишь подмножество переменных. Для каждого решения в последовательности формируется новое решение путем определенного выбора переменных с помощью запроса SELECT.

Следующий пример демонстрирует запрос, который извлекает только имена людей, описанных в RDF-графе посредством свойств FOAF.


@prefix foaf:        <http://xmlns.com/foaf/0.1/> .

_:a  foaf:name       "Alice" .
_:a  foaf:mbox       <mailto:alice@work.example> .

_:b  foaf:name       "Bob" .
_:b  foaf:mbox       <mailto:bob@work.example> .
PREFIX foaf:       <http://xmlns.com/foaf/0.1/>
SELECT ?name
WHERE
 { ?x foaf:name ?name }
name
"Bob"
"Alice"

9.3 Повторные решения

При отсутствии модификаторов запроса DISTINCT или REDUCED повторные решения останутся в последовательности решений.

@prefix  foaf:  <http://xmlns.com/foaf/0.1/> .

_:x    foaf:name   "Alice" .
_:x    foaf:mbox   <mailto:alice@example.com> .

_:y    foaf:name   "Alice" .
_:y    foaf:mbox   <mailto:asmith@example.com> .

_:z    foaf:name   "Alice" .
_:z    foaf:mbox   <mailto:alice.smith@example.com> .

PREFIX foaf:    <http://xmlns.com/foaf/0.1/>
SELECT ?name WHERE { ?x foaf:name ?name }
name
"Alice"
"Alice"
"Alice"

Модификаторы DISTINCT и REDUCED влияют на наличие повторений в результатах запроса.

9.3.1 DISTINCT

Модификатор решений DISTINCT позволяет ликвидировать повторные решения. В частности, каждое решение, которое связывает одинаковые переменные и одинаковые RDF-термины в качестве еще одного решения, ликвидируется из набора решений.

PREFIX foaf:    <http://xmlns.com/foaf/0.1/>

SELECT DISTINCT ?name WHERE { ?x foaf:name ?name }
name
"Alice"

Обратите внимание, что согласно порядку модификаторов последовательности решений, повторные решения ликвидируются перед применением limit или offset.

9.3.2 REDUCED

Тогда как модификатор DISTINCT обеспечивает элиминацию повторных решений из набора решений, REDUCED просто разрешает ликвидацию этих решений. Кардинальность любого набора привязок переменных в наборе решений REDUCED является, по крайней мере, одной и не более, чем кардинальность набора решений без модификатора DISTINCT или REDUCED. Например, используя вышеприведенные данные, следующий запрос

PREFIX foaf:    <http://xmlns.com/foaf/0.1/>
SELECT REDUCED ?name WHERE { ?x foaf:name ?name }

может содержать одно, два (как показано в данном случае) или три решения:

name
"Alice"
"Alice"

9.4 OFFSET

OFFSETпозволяет сгенерированным решениям начинаться после определенного числа решений. Равенство OFFSET нулю не возымеет никакого эффекта.

Использование LIMIT и OFFSET для выбора разных подмножеств решений запроса не имеет никакого смысла, если последовательность решений не предсказуема и не применен модификатор ORDER BY.

PREFIX foaf:    <http://xmlns.com/foaf/0.1/>

SELECT  ?name
WHERE   { ?x foaf:name ?name }
ORDER BY ?name
LIMIT   5
OFFSET  10

9.5 LIMIT

Условие LIMIT задает верхнюю границу числа возвращаемых решений. Если фактическое число решений превышает лимит, то число возвращаемых решений не превысит заданный лимит.

PREFIX foaf:    <http://xmlns.com/foaf/0.1/>

SELECT ?name
WHERE { ?x foaf:name ?name }
LIMIT 20

Равенство LIMIT 0 не возвратит никаких результатов. Значение LIMIT не может быть отрицательным.

10 Формы запросов

В SPARQL существует четыре формы запросов. Эти формы запроса используют решения исходя из соответствия шаблону для формирования результирующих наборов или RDF-графов. Ниже приведены эти формы запроса:

SELECT
Возвращает все или подмножество переменных, связанных c соответствующим шаблоном запроса.
CONSTRUCT
Возвращает RDF-граф, созданный путем замены переменных в наборе шаблонов триплетов.
ASK
Возвращает булево значение, которое указывает, соответствует ли шаблон запроса.
DESCRIBE
Возвращает RDF-граф, описывающий найденные ресурсы.

XML-формат результатов привязки переменных SPARQL может использоваться для сериализации результирующего набора запроса SELECT или булевого результата запроса ASK.

10.1 SELECT

Форма SELECT возвращает переменные и их привязки непосредственно. Синтаксис SELECT * является сокращением, и позволяет выбрать все переменные в запросе.

@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"

Результирующие наборы могут быть доступны через локальный API, а также могут быть сериализованы либо в XML или в RDF-граф. Формат XML описан в XML-формат результатов SPARQL-запросов, и используется в следующем примере:

<?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+ | '*' )
DatasetClause* WhereClause SolutionModifier

10.2 CONSTRUCT

Форма запроса CONSTRUCT возвращает один RDF-граф, определенный графовым шаблоном. В результате получается RDF-граф, сформированный путем взятия каждого решения запроса в последовательности решений, замены на переменные в графовом шаблоне и объединения триплетов в единый RDF-граф посредством объединения множества.

Если любая такая реализация производит триплет, который содержит несвязанную переменную или запрещенную RDF-конструкцию (например, как литерал на месте субъекта или предиката), тогда этот триплет не включается в выходной RDF-граф. Графовый шаблон может содержать триплеты без переменных (известные как основные (ground) или явные (explicit) триплеты). Они также отображаются в выходном RDF-графе, возвращаемом запросом CONSTRUCT.

@prefix  foaf:  <http://xmlns.com/foaf/0.1/> .

_:a    foaf:name   "Alice" .
_:a    foaf:mbox   <mailto:alice@example.org> .

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 }

создает свойства vcard из информации FOAF:

@prefix vcard: <http://www.w3.org/2001/vcard-rdf/3.0#> .

<http://example.org/person#Alice> vcard:FN "Alice" .

10.2.1 Шаблоны с безымянными вершинами

Шаблон может создать RDF-граф, содержащий безымянные вершины. Область действия меток безымянных вершин распространяется в пределах шаблона для каждого решения. Если одна и та же метка фигурирует в шаблоне дважды, тогда для каждого решения запроса будет создана одна безымянная вершина, однако разные решения запроса сгенерируют разные безымянные вершины для триплетов.

@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 } .
 }

создает свойства vcard в соответствии с информацией 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" .

Использование переменной x (которая в данном примере будет связана с безымянными вершинами с метками _:a и _:b в данных) в шаблоне обуславливает различные метки безымянных вершин (_:v1 и _:v2) в результирующем RDF-графе.

10.2.2 Получение доступа к графам в наборе данных RDF

С помощью CONSTRUCT можно извлекать части или целые графы из целевых наборов данных RDF. Этот первый пример возвращает граф (если он находится в наборе данных) с меткой IRI http://example.org/aGraph; в противном случае возвращается пустой граф.

CONSTRUCT { ?s ?p ?o } WHERE { GRAPH <http://example.org/aGraph> { ?s ?p ?o } . }

Доступ к графу может быть основан на другой информации. Например, если граф по умолчанию содержит метаданные о поименованных графах в наборе данных, тогда запрос наподобие следующего может извлечь один граф на основе информации о поименованном графе:

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 ) .
 }

где app:customDate определяет функцию расширения для перевода формата данных в xsd:dateTime RDF-термин.

Правило грамматики:
[6]   ConstructQuery   ::=   'CONSTRUCT' ConstructTemplate
DatasetClause* WhereClause SolutionModifier

10.2.3 Модификаторы решений и CONSTRUCT

Модификаторы решений запроса влияют на результаты запроса CONSTRUCT. В этом примере выходной граф шаблона CONSTRUCT формируется лишь из двух решений из соответствия шаблону запроса. Запрос выводит граф с именами людей двух сайтов, пользующихся успехом. Триплеты в RDF-графе не упорядочены.

@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" .

10.3 ASK

Приложения могут использовать форму ASK для тестирования, имеет ли шаблон запроса решение. Никакая информация о возможных решениях запроса не возвращается, просто выполняется проверка наличия решения.

@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:bob@work.example> .

PREFIX foaf:    <http://xmlns.com/foaf/0.1/>
ASK  { ?x foaf:name  "Alice" }

yes

The XML-формат результатов SPARQL-запросов этого результирующего множества:

<?xml version="1.0"?>

<sparql xmlns="http://www.w3.org/2005/sparql-results#">
  <head></head>
  <results>
    <boolean>true</boolean>
  </results>

</sparql>

С теми же данными следующий запрос возвращает отсутствие соответствия, так как mbox Алисы не упоминается.


PREFIX foaf:    <http://xmlns.com/foaf/0.1/>
ASK  { ?x foaf:name  "Alice" ;
          foaf:mbox  <mailto:alice@work.example> }
no
Правило грамматики:
[8]   AskQuery   ::=   'ASK' DatasetClause* WhereClause

10.4 DESCRIBE (информативный)

Форма DESCRIBE возвращает единственный результирующий RDF-граф, который содержит RDF-данные о ресурсах. Эти данные не предписаны запросом SPARQL, где клиенту запроса необходимо знать структуру RDF в источнике данных. Однако вместо этого данные определены обработчиком SPARQL-запроса. Шаблон запроса используется для создания результирующего набора. Форма DESCRIBE берет каждый из ресурсов, установленных в решении, вместе с любыми ресурсами, непосредственно названных по IRI, и формирует единый RDF-граф, взяв описание (description), которое может поступить из любой доступной информации, в том числе и из целевого набора данных RDF. Описание определяется сервисом запросов. Синтаксис DESCRIBE * является сокращением и обозначает все переменные в запросе.

10.4.1 Явные IRI

Условие DESCRIBE само по себе может взять IRI для определения ресурса. Самый простой запрос DESCRIBE представляет собой просто IRI в условии DESCRIBE:

DESCRIBE <http://example.org/>

10.4.2 Идентификация ресурсов

Ресурсы, которые необходимо описать, могут быть взяты из привязок к переменной запроса в результирующем наборе. Это делает возможным описание ресурсов, каким бы образом они ни были определены (с помощью IRI или безымянных вершин в наборе данных):

PREFIX foaf:   <http://xmlns.com/foaf/0.1/>
DESCRIBE ?x
WHERE    { ?x foaf:mbox <mailto:alice@org> }

Свойство foaf:mbox определено как свойство обратной функции в словаре FOAF. Таким образом, этот запрос возвратит информацию максимум об одном человеке. Однако, если шаблон запроса имеет множество решений, тогда RDF-данными для каждого будет объединение всех описаний RDF-графов.

PREFIX foaf:   <http://xmlns.com/foaf/0.1/>
DESCRIBE ?x
WHERE    { ?x foaf:name "Alice" }

Может быть дано более одной переменной или IRI:

PREFIX foaf:   <http://xmlns.com/foaf/0.1/>
DESCRIBE ?x ?y <http://example.org/>
WHERE    {?x foaf:knows ?y}

10.4.3 Описания ресурсов

Возвращаемые RDF-данные определяются тем, кто публикует информацию. Это та полезная информация о ресурсе, которой обладает сервис. Она может включать информацию о других ресурсах: скажем, RDF-данные для книги могут также содержать сведения об авторе.

Такой простой запрос

PREFIX ent:  <http://org.example.com/employees#>
DESCRIBE ?x WHERE { ?x ent:employeeId "1234" }

может возвратить описание работника и некоторые другие потенциально полезные детали:

@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#> .
@prefix rdf:    <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 .

которые включают закрытие безымянных вершин для словаря vcard vcard:N. Другие варианты механизмов принятия решений о том, какую информацию необходимо возвратить, включают Concise Bounded Descriptions [CBD].

Такой словарь, как FOAF, где ресурсами являются в основном безымянные вершины, предназначен для возврата достаточной информации для определения вершины, как, например, InverseFunctionalProperty foaf:mbox_sha1sum, а также информации, как имя и другие записанные подробности. В этом примере было возвращено соответствие условию WHERE, что не является обязательным.

Правило грамматики:
[7]   DescribeQuery   ::=   'DESCRIBE' ( VarOrIRIref+ | '*' )
DatasetClause* WhereClause? SolutionModifier

11 Тестирование значений

Фильтры SPARQL (FILTER) ограничивают решения соответствия графовому шаблону ввиду заданого выражения. В частности, ключевые слова FILTER элиминируют любые решения, которые при замене на выражение либо приводят к эффективному булевому значению false, либо порождают ошибку. Эффективные булевы значения описаны в разделе 11.2.2 Эффективное булево значение, а ошибки определены документом XQuery 1.0: язык XML-запросов [XQUERY] в разделе 2.3.1, 2.3.1 Виды ошибок. Эти ошибки не имеют воздействия вне оценки фильтра. SPARQL restrict the solutions of a graph pattern match according to a given выражения.

RDF литералы могут иметь тип данных 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> .

Объект первого триплета dc:date не содержит информации о типе. Тип данных второго — xsd:dateTime.

Выражения SPARQL составляются в соответствии с грамматикой и обеспечивают доступ к функциям (обозначаемых по IRI) и операторным функциям (вызываемым с помощью ключевых слов и символов грамматики SPARQL). Операторы SPARQL могут быть использованы для сравнения значений типизированных литералов:


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 ) }

Операторы SPARQL перечислены в разделе 11.3 и связаны с соответствующими продукциями в грамматике.

Кроме того, SPARQL обеспечивает возможность вызова произвольных функций, в том числе и подмножество функций приведения XPath, которые перечислены в разделе 11.5. Эти функции вызываются внутри SPARQL-запроса по имени (IRI). Например:

... FILTER ( xsd:dateTime(?date) < xsd:dateTime("2005-01-01T00:00:00Z") ) ...

В этом разделе используются следующие типографские соглашения:

11.1 Типы данных операнда

Функции и операторы SPARQL работают с RDF-терминами и переменными SPARQL. Подмножество этих функций и операторов взято из Функции и операторы XQuery 1.0 и XPath 2.0 [FUNCOP], имеет аргументы типизированных значений XML-схемы и возвращает типы. Типизированные литералы RDF (typed literals), передаваемые в качестве аргументов этим функциям и операторам, преобразуются в типизированные значения XML-схемы со строковым значением лексической формы (lexical form) и элементарным типом данных (atomic datatype), соответствующим типу данных IRI. Возвращаемые типизированные значения преобразуются обратно в typed literals тем же образом. XQuery 1.0 and XPath 2.0 Functions and Operators [FUNCOP]

В SPARQL есть дополнительные операторы, которые работают с определенными подмножествами RDF-терминов. При ссылке на тип, следующие термины обозначают типизированный литерал ( typed literal) с соответствующим типом данных схемы XML [XSDT] IRI:

Следующие термины определяют дополнительные типы, используемые в тестах значений SPARQL:

Следующие типы получены из числовых типов и являются действительными аргументами функций и операторов, принимающих числовые аргументы:

Расширения языка SPARQL могут обращаться с дополнительными типами как с типами, полученными из XML-схемы.

11.2 Оценка фильтра

SPARQL предоставляет набор функций и операторов, определенных в XQuery Операторное преобразование. В разделе 2.2.3 Обработка выражений XQuery 1.0 описан вызов функций XPath. Следующие правила согласовывают различия в данных и моделях исполнения XQuery и SPARQL:

Ниже приведена таблица истиности для логического И и логического ИЛИ, где true (T), false (F), и error (E):

ABA || BA && B
TTTT
TFTF
FTTF
FFFF
TETE
ETTE
FEEF
EFEF
EEEE

11.2.1 Вызов

SPARQL определяет синтаксис для вызова функций и операторов на основе перечня аргументов. Вызов осуществляется следующим образом:

Если любой из этих шагов выполняется некорректно, вызов генерирует ошибку. Последствия ошибок раскрыты в разделе Оценка фильтра.

11.2.2 Эффективное булево значение (Effective Boolean Value, EBV)

Эффективное булево значение используется для подсчета аргументов логических функций logical-and, logical-or, и fn:not, а также для оценки результата выражения FILTER.

Правила Эффективного булевого значения XQuery основаны на определении fn:boolean в XPath. Следующие правила отражают принципы для fn:boolean, применимые для типов аргумента в запросах SPARQL:

EBV, равный true, представлен типизированным литералом с типом данных xsd:boolean и лексическим значением "true"; EBV, равный false, представлен типизированным литералом с типом данных xsd:boolean и лексическим значением "false".

11.3 Операторное преобразование

Грамматика SPARQL определяет набор операторов (например, &&, *, isIRI) используемых при создании ограничений. Следующая таблица связывает каждую из этих грамматических продукций с соответствующими операндами и операторной функцией, заданной посредством либо Функции и операторы XQuery 1.0 и XPath 2.0 [FUNCOP] либо операторами SPARQL, определенными в разделе 11.4. При выборе определения оператора для заданного набора параметров используется определение с наиболее специфическими параметрами. Например, при оценке xsd:integer = xsd:signedInt, используется определение для = с двумя параметрами numeric, скорее чем с двумя RDF-терминами. Таблица упорядочена таким образом, что верхний вариант является наиболее специфическим. Операторы, вызванные без соответствующих операндов, приводят к ошибке типа.

SPARQL придерживается схемы XPath для повышений (promotion) числовых типов и замены подтипов аргументов на числовые операторы. Правила Операторного преобразования XPath для числовых операндов (xsd:integer, xsd:decimal, xsd:float, xsd:double, и типов, полученных из числовых) также применимы к операторам SPARQL (см. определения повышений (promotion) числового типа и XML Path Language (XPath) 2.0 [XPATH20] for defintions of повышений (promotion) числового типа и замены (substitution) подтипа в XML Path Language (XPath) 2.0 [XPATH20]). Некоторые операторы связаны с выражениями вложенных функций, например, fn:not(op:numeric-equal(A, B)). Обратите внимание, что согласно определениям XPath, fn:not и op:numeric-equal приведут к ошибке, если их аргумент является ошибочным.

Сравнение (collation) для fn:compare определено посредством XPath и установлено в http://www.w3.org/2005/xpath-functions/collation/codepoint. Это сравнение позволяет сопоставить string на основе значений codepoint. Эквивалентность string codepoint можно протестировать с помощью эквивалентности RDF-термина.

Унарные операторы SPARQL
Оператор Тип(A)ФункцияТип результата
Унарные операторы SPARQL
! A xsd:boolean (EBV)fn:not(A)xsd:boolean
+ A numericop:numeric-unary-plus(A)numeric
- A numericop:numeric-unary-minus(A)numeric
Тесты SPARQL, определенные в разделе 11.4
BOUND(A) variablebound(A)xsd:boolean
isIRI(A)
isURI(A)
RDF termisIRI(A)xsd:boolean
isBLANK(A) RDF termisBlank(A)xsd:boolean
isLITERAL(A) RDF termisLiteral(A)xsd:boolean
Аксессоры SPARQL, определенные в разделе 11.4
STR(A) literalstr(A)simple literal
STR(A) IRIstr(A)simple literal
LANG(A) literallang(A)simple literal
DATATYPE(A) typed literaldatatype(A)IRI
DATATYPE(A) simple literaldatatype(A)IRI
Бинарные операторы SPARQL
Оператор Тип(A)Тип(B)ФункцияТип результата
Логические соединения, определенные в разделе 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
Тесты XPath
A = B numericnumericop:numeric-equal(A, B)xsd:boolean
A = B simple literalsimple literalop:numeric-equal(fn:compare(A, B), 0)xsd:boolean
A = B xsd:stringxsd:stringop:numeric-equal(fn:compare(STR(A), STR(B)), 0)xsd:boolean
A = B xsd:booleanxsd:booleanop:boolean-equal(A, B)xsd:boolean
A = B xsd:dateTimexsd:dateTimeop:dateTime-equal(A, B)xsd:boolean
A != B numericnumericfn:not(op:numeric-equal(A, B))xsd:boolean
A != B simple literalsimple literalfn:not(op:numeric-equal(fn:compare(A, B), 0))xsd:boolean
A != B xsd:stringxsd:stringfn:not(op:numeric-equal(fn:compare(STR(A), STR(B)), 0))xsd:boolean
A != B xsd:booleanxsd:booleanfn:not(op:boolean-equal(A, B))xsd:boolean
A != B xsd:dateTimexsd:dateTimefn:not(op:dateTime-equal(A, B))xsd:boolean
A < B numericnumericop:numeric-less-than(A, B)xsd:boolean
A < B simple literalsimple literalop:numeric-equal(fn:compare(A, B), -1)xsd:boolean
A < B xsd:stringxsd:stringop:numeric-equal(fn:compare(STR(A), STR(B)), -1)xsd:boolean
A < B xsd:booleanxsd:booleanop:boolean-less-than(A, B)xsd:boolean
A < B xsd:dateTimexsd:dateTimeop:dateTime-less-than(A, B)xsd:boolean
A > B numericnumericop:numeric-greater-than(A, B)xsd:boolean
A > B simple literalsimple literalop:numeric-equal(fn:compare(A, B), 1)xsd:boolean
A > B xsd:stringxsd:stringop:numeric-equal(fn:compare(STR(A), STR(B)), 1)xsd:boolean
A > B xsd:booleanxsd:booleanop:boolean-greater-than(A, B)xsd:boolean
A > B xsd:dateTimexsd:dateTimeop:dateTime-greater-than(A, B)xsd:boolean
A <= B numericnumericlogical-or(op:numeric-less-than(A, B), op:numeric-equal(A, B))xsd:boolean
A <= B simple literalsimple literalfn:not(op:numeric-equal(fn:compare(A, B), 1))xsd:boolean
A <= B xsd:stringxsd:stringfn:not(op:numeric-equal(fn:compare(STR(A), STR(B)), 1))xsd:boolean
A <= B xsd:booleanxsd:booleanfn:not(op:boolean-greater-than(A, B))xsd:boolean
A <= B xsd:dateTimexsd:dateTimefn:not(op:dateTime-greater-than(A, B))xsd:boolean
A >= B numericnumericlogical-or(op:numeric-greater-than(A, B), op:numeric-equal(A, B))xsd:boolean
A >= B simple literalsimple literalfn:not(op:numeric-equal(fn:compare(A, B), -1))xsd:boolean
A >= B xsd:stringxsd:stringfn:not(op:numeric-equal(fn:compare(STR(A), STR(B)), -1))xsd:boolean
A >= B xsd:booleanxsd:booleanfn:not(op:boolean-less-than(A, B))xsd:boolean
A >= B xsd:dateTimexsd:dateTimefn:not(op:dateTime-less-than(A, B))xsd:boolean
Арифметика XPath
A * B numericnumericop:numeric-multiply(A, B)numeric
A / B numericnumericop:numeric-divide(A, B)numeric; but xsd:decimal if both operands are xsd:integer
A + B numericnumericop:numeric-add(A, B)numeric
A - B numericnumericop:numeric-subtract(A, B)numeric
Тесты SPARQL, определенные в разделе 11.4
A = B RDF termRDF termRDFterm-equal(A, B)xsd:boolean
A != B RDF termRDF termfn:not(RDFterm-equal(A, B))xsd:boolean
sameTERM(A) RDF termRDF termsameTerm(A, B)xsd:boolean
langMATCHES(A, B) simple literalsimple literallangMatches(A, B)xsd:boolean
REGEX(STRING, PATTERN) simple literalsimple literalfn:matches(STRING, PATTERN)xsd:boolean
Тринарные операторы SPARQL
Оператор Тип(A)Тип(B)Тип(C)ФункцияТип результата
Тесты SPARQL, определенные в разделе 11.4
REGEX(STRING, PATTERN, FLAGS) simple literalsimple literalsimple literalfn:matches(STRING, PATTERN, FLAGS)xsd:boolean

Аргументы xsd:boolean с меткой "(EBV)" приводятся к xsd:boolean путем оценки эффективного булевого значения этого аргумента.

11.3.1 Операторная расширяемость

Расширения языка SPARQL могут обеспечивать дополнительные связи между операторами и операторными функциями, что приводит к добавлению строк в вышеприведенную таблицу. Никакой дополнительный оператор не может воспроизвести результат, который бы заменил любой из результатов (кроме ошибки типа), описанных с помощью вышеприведенной семантики. Из этого правила следует, что расширения SPARQL приведут, по крайней мере, к тем же решениям, что и нерасширенная реализация, а для некоторых запросов может получиться больше решений.

Дополнительные преобразования оператора '<' предполагают контроль относительного упорядочения операндов, в частности при использовании в условии ORDER BY.

11.4 Определения операторов

Этот раздел определяет операторы, предлагаемые языком запросов SPARQL. Примеры демонстрируют поведение операторов при их вызове соответствующими грамматическими конструкциями.

11.4.1 bound

 xsd:boolean   bound (variable var)

Возвращает true, если var связан со значением. В противном случае возвращает false. Переменные со значением NaN либо INF считаются связанными.

Данные:

@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) ) }

Результат запроса:

givenName
"Bob"

Тестирование может показать, что графовый шаблон не выражен путем определения графового шаблона OPTIONAL, который предлагает переменную, и тестирования, при котором переменная оказывается не связанной (not bound). В логическом программировании это называется отрицанием, как неудача (Negation as Failure).

Этот запрос отбирает людей с name, но без выраженной date:

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)) }

Результат запроса:

name
"Alice"

Значение dc:date для Боба известно, поэтому "Bob" не является решением запроса.

11.4.2 isIRI

 xsd:boolean   isIRI (RDF term term)
 xsd:boolean   isURI (RDF term term)

Возвращает true, если term является IRI. В противном случае возвращает false. Альтернативный вариант написания оператора isIRI — isIRI.

@prefix foaf:       <http://xmlns.com/foaf/0.1/> .

_:a  foaf:name       "Alice".
_:a  foaf:mbox       <mailto:alice@work.example> .

_:b  foaf:name       "Bob" .
_:b  foaf:mbox       "bob@work.example" .

Этот запрос отбирает людей с name и mbox в виде IRI:

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?name ?mbox
 WHERE { ?x foaf:name  ?name ;
            foaf:mbox  ?mbox .
         FILTER isIRI(?mbox) }

Результат запроса:

name mbox
"Alice" <mailto:alice@work.example>

11.4.3 isBlank

 xsd:boolean   isBlank (RDF term term)

Возвращает true, если term является пустой вершиной. В противном случае возвращает false.

@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".

Этот запрос отбирает людей с dc:creator, где используются предикаты из словаря FOAF для выражения имен.

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)
       }

Результат запроса:

given family
"Bob" "Smith"

В этом примере было два объекта, выраженных предикатами foaf:knows, и лишь один (_:c) — пустой вершиной

11.4.4 isLiteral

 xsd:boolean   isLiteral (RDF term term)

Возвращаетtrue, если term является литералом. В противном случае возвращает false.

@prefix foaf:       <http://xmlns.com/foaf/0.1/> .

_:a  foaf:name       "Alice".
_:a  foaf:mbox       <mailto:alice@work.example> .

_:b  foaf:name       "Bob" .
_:b  foaf:mbox       "bob@work.example" .

Этот запрос похож на тот, что представлен в разделе 11.4.2, за исключением того, что он отбирает людей с name и mbox. Электронный адрес представлен литералом. Такой подход может использоваться для поиска ошибочных данных (foaf:mbox должен иметь в качестве объекта только IRI).

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?name ?mbox
 WHERE { ?x foaf:name  ?name ;
           foaf:mbox  ?mbox .
         FILTER isLiteral(?mbox) }

Результат запроса:

name mbox
"Bob" "bob@work.example"

11.4.5 str

 simple literal   str (literal ltrl)
 simple literal   str (IRI rsrc)

Возвращает лексическую форму (lexical form) литерала ltrl; возвращает представление codepoint для rsrc (IRI), что полезно для проверки частей IRI, например, имени хоста.

@prefix foaf:       <http://xmlns.com/foaf/0.1/> .

_:a  foaf:name       "Alice".
_:a  foaf:mbox       <mailto:alice@work.example> .

_:b  foaf:name       "Bob" .
_:b  foaf:mbox       <mailto:bob@home.example> .

Этот запрос выбирает набор людей, которые используют свой адрес work.example в своем профиле 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") }

Результат запроса:

name mbox
"Alice" <mailto:alice@work.example>

11.4.6 lang

 simple literal   lang (literal ltrl)

Возвращает тег языка (language tag) для ltrl при наличии такового. Если тег языка для ltrl отсутствует, возвращается "". Обратите внимание, что модель данных RDF не содержит литералы с пустым language tag.

@prefix foaf:       <http://xmlns.com/foaf/0.1/> .

_:a  foaf:name       "Robert"@EN.
_:a  foaf:name       "Roberto"@ES.
_:a  foaf:mbox       <mailto:bob@work.example> .

This query finds the Spanish foaf:name and 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" ) }

Результат запроса:

name mbox
"Roberto"@ES <mailto:bob@work.example>

11.4.7 datatype

 IRI   datatype (typed literal typedLit)
 IRI   datatype (simple literal simpleLit)

Возвращает datatype IRI для typedLit; возвращает xsd:string, если параметр является простым (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 .

Этот запрос находит foaf:name и foaf:shoeSize всех, у кого размер обуви (shoeSize) является целым числом:

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 ) }

Результат запроса:

name shoeSize
"Bob" 42

11.4.8 logical-or

 xsd:boolean   xsd:boolean left || xsd:boolean right

Возвращает логическое OR для left и right составляющих. Заметьте, что logical-or оперирует с эффективным булевым значением своих аргументов.

Внимание: см. раздел 11.2, Оценка фильтра, где представлена информация по обработке ошибок оператора ||.

11.4.9 logical-and


 xsd:boolean   xsd:boolean left && xsd:boolean right

Возвращает логическое AND для left и right составляющих. Заметьте, что logical-and оперирует с эффективным булевым значением своих аргументом.

Внимание: см. раздел 11.2, Оценки фильтра, где представлена информация по обработке ошибок оператора && .

11.4.10 RDFterm-equal

 xsd:boolean   RDF term term1 = RDF term term2

Возвращает TRUE, если term1 и term2 являются одинаковыми RDF-терминами согласно документу Resource Description Framework (RDF): концепции и абстрактный синтаксис [CONCEPTS]; приводит к ошибке типа, если оба аргумента являются литералами, однако не являются одинаковыми RDF-терминами *; в противном случае возвращает FALSE. term1 и term2 одинаковы, если следующее истинно:

@prefix foaf:       <http://xmlns.com/foaf/0.1/> .

_:a  foaf:name       "Alice".
_:a  foaf:mbox       <mailto:alice@work.example> .

_:b  foaf:name       "Ms A.".
_:b  foaf:mbox       <mailto:alice@work.example> .

Этот запрос находит людей с множественными триплетами 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)
       }

Результат запроса:

name1 name2
"Alice" "Ms A."
"Ms A." "Alice"

В этом запросе к документам, которые были аннотированы в новый год (2004 или 2005), RDF-термины не одинаковы, однако имеют эквивалентные значения:

@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/>

* Вызов RDFterm-equal для двух типизированных литералов позволяет выполнить тестирование на эквивалентность значений. Расширенная реализация может иметь поддержку дополнительных типов данных. Реализация, которая обрабатывает запрос по тестированию на эквивалентность неподдерживаемых типов данных (и неидентичной лексической формы и типа данных IRI), возвращает ошибку, указывающую на невозможность определения эквивалентности значений. Например, нерасширенная реализация приведет к ошибке при тестировании либо "iiii"^^my:romanNumeral = "iv"^^my:romanNumeral либо "iiii"^^my:romanNumeral != "iv"^^my:romanNumeral.

11.4.11 sameTerm

 xsd:boolean   sameTerm (RDF term term1, RDF term term2)

Возвращает TRUE если term1 и term2 являются одинаковыми RDF-терминами согласно Resource Description Framework (RDF): концепции и абстрактный синтаксис [CONCEPTS]; в противном случае возвращает FALSE.

@prefix foaf:       <http://xmlns.com/foaf/0.1/> .

_:a  foaf:name       "Alice".
_:a  foaf:mbox       <mailto:alice@work.example> .

_:b  foaf:name       "Ms A.".
_:b  foaf:mbox       <mailto:alice@work.example> .

Этот запрос находит людей с множественными триплетами 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))
       }

Результат запроса:

name1 name2
"Alice" "Ms A."
"Ms A." "Alice"

В отличие от RDFterm-equal, sameTerm может использоваться для тестирования неэквивалентных типизированных литералов с неподдерживаемыми типами данных:

@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"

Тестирование коробок с одинаковым весом может быть также проделано с помощью оператора '=' (RDFterm-equal) Так, например, тест "100"^^t:kilos = "85"^^t:kilos приведет к ошибке, элиминирующей такое потенциальное решение.

11.4.12 langMatches


 xsd:boolean   langMatches (simple literal language-tag, simple literal language-range)

Возвращает true, если language-tag (первый аргумент) соответствует language-range (второму аргументу) согласно основной схеме фильтрования (basic filtering scheme), описанной в [RFC4647] в разделе 3.3.1. language-range — это основная область языка (basic language range) согласно документу Соответствие тегов языка [RFC4647], раздел 2.1. language-range "*" соответствует любой непустой строке language-range.

@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" .

Этот запрос использует langMatches и lang (описанных в разделе 11.2.3.8) для поиска французского заголовка шоу 70-х, известного на английском как "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" ) }

Результат запроса:

title
"Cette Série des Années Soixante-dix"@fr
"Cette Série des Années Septante"@fr-BE

Идиома langMatches( lang( ?v ), "*" ) не будет соответствовать литералам без тега языка, а lang( ?v ) возвратит пустую строку, потому


PREFIX dc: <http://purl.org/dc/elements/1.1/>
SELECT ?title
 WHERE { ?x dc:title  ?title .
         FILTER langMatches( lang(?title), "*" ) }

в результате получатся все заголовки с тегом языка:

title
"That Seventies Show"@en
"Cette Série des Années Soixante-dix"@fr
"Cette Série des Années Septante"@fr-BE

11.4.13 regex

 xsd:boolean   regex (simple literal text, simple literal pattern)
 xsd:boolean   regex (simple literal text, simple literal pattern, simple literal flags)

Вызывает функцию XPath fn:matches для соответствия text регулярному выражению pattern. Язык регулярных выражений определен документом Функции и операторы XQuery 1.0 и XPath 2.0 в разделе 7.6.1 Синтаксис регулярных выражений [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") }

Результат запроса:

name
"Alice"

11.5 Функции конструктора

SPARQL импортирует подмножество функций конструктора XPath, которые определены в Функции и операторы XQuery 1.0 и XPath 2.0 [FUNCOP], раздел 17.1 17.1 Приведение примитивных типов к примитивным типам. Конструкторы SPARQL включают все конструкторы XPath для типов данных операнда SPARQL плюс дополнительные типы данных, обусловленных моделью данных RDF. Приведение (casting) в SPARQL осуществляется посредством вызова функции конструктора для целевого типа над операндом исходного типа.

XPath определяет лишь приведение одного типа данных XML-схемы в другой. Остальные приведения определены следующим образом:

Следующая таблица резюмирует операции приведения, которые всегда разрешены (Y), никогда не разрешены (N), зависят от лексического значения (M). Например, операция приведения xsd:string (первая строка) к xsd:float (второй столбец) зависит от лексического значения (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 = simple literal

From \ To 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

11.6 Тестирование расширенного значения

Правило грамматики PrimaryExpression может вызывать функция расширения, которая идентифицирована по IRI. Функция расширения берет некоторое количество RDF-терминов в качестве аргументов и возвращает RDF-термин. Семантика этих функций определяется по IRI, которые эти функции идентифицирует.

Запросы SPARQL, в которых используются функции расширения, скорее всего, имеют ограниченную интероперабельность.

В качестве примера, предположим, осуществлен вызов функции func:even:

 xsd:boolean   func:even (numeric value)

Эта функция будет вызвана внутри фильтра:

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)) }

Для второго примера, допустим, есть функция aGeo:distance, которая подсчитывает расстояние между двумя точками и используется здесь для поиска мест возле Гренобля:

 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 ) .
      }

Функция расширения может быть использована в целях тестирования типов данных приложения, которые не поддерживаются базовой спецификацией SPARQL. Может выполняться преобразование форматов данных, скажем, переход в XSD dateTime из какого-либо другого формата, обозначающего дату.

12 Определение SPARQL

Этот раздел определяет корректное поведение для оценки графовых шаблонов и модификаторов решений с помощью строки запроса и набора данных RDF. Вовсе не подразумевается, что реализация SPARQL должна использовать определенный здесь процесс.

Результат выполнения SPARQL описан набором этапов, начиная от запроса SPARQL в виде строки, преобразуя эту строку в форму абстрактного синтаксиса, а затем этот абстрактный синтаксис в абстрактный запрос SPARQL, включающий операторы SPARQL-алгебры. Этот абстрактный запрос впоследствии оценивается на наборе данных RDF.

12.1 Исходные определения

12.1.1 RDF-термины

SPARQL определен в терминах IRI [RFC3987]. IRI — это подмножество ссылок RDF URI, которые опускают пробелы.

Определение: RDF-термин

Пусть I - набор всех IRI.
RDF-L набор всех RDF-литералов
RDF-B - набор всех безымянных вершин в RDF-графах

Набор RDF-терминов, RDF-T - это I объединение RDF-L объединение RDF-B.

Данное определение RDF-термина соединяет несколько основных идей из модели данных RDF, однако обновлено с точки зрения рассмотрения IRI, вместо ссылок RDF URI.

12.1.2 Набор данных RDF

Определение: Набор данных RDF

Набор данных RDF — это множество:
{ G, (<u1>, G1), (<u2>, G2), . . . (<un>, Gn) }
где G и каждое Gi - графы, а каждое <ui> - IRI. Каждое <ui> уникально.

G называется графом по умолчанию. (<ui>, Gi) - поименованные графы.

Определение: Активный граф

Активный граф это граф из набора данных, который используется для соответствия основному графовому шаблону.

12.1.3 Переменные запроса

Определение: Переменная запроса

Переменная запроса - это элемент множества V, где V - бесконечное множество, отдельное от RDF-T.

12.1.4 Шаблоны триплетов

Определение: Шаблоны триплетов

Шаблон триплета - элемент множества:
(RDF-T объединение V) x (I объединение V) x (RDF-T объединение V)

Это определение шаблона триплета включает субъекты литералов, что было отмечено в RDF-core.

""[Рабочая группа ядра RDF] отметила, что нет причин, по которым литералы не могут быть субъектами, и при менее строгой хартии рабочая группа могла бы расширить синтаксис, разрешив литералы в виде субъектов утверждений."

Так как RDF-графы не могут содержать субъекты литералов, любой шаблон триплета SPARQL с литералом на месте субъекта не сможет соответствовать ни одному RDF-графу.

12.1.5 Основные графовые шаблоны

Определение: Основной графовый шаблон

Основной графовый шаблон - это набор шаблонов триплетов.

Пустой графовый шаблон - основной графовый шаблон, который является пустым множеством.

12.1.6 Преобразование решений

Преобразование решений представляет собой преобразование набора переменных в набор RDF-терминов. Мы используем термин 'решение' там, где это уместно.

Определение: Преобразование решений

Преобразование решения, μ, это частичная функция μ : V -> T.

Домен μ, dom(μ), - это подмножество V, где определен μ.

Определение: Последовательность решений

Последовательность решений - это перечень решений, возможно, неупорядоченных.

12.1.7 Модификаторы последовательности решений

Определение: Модификатор последовательности решений

Модификатор последовательности решений - это один из следующих модификаторов:

12.2 Запросы SPARQL

Этот раздел определяет процесс преобразования графовых шаблонов и модификаторов решений, расположенных в строке SPARQL-запроса, в выражение SPARQL-алгебры.

После анализа строки SPARQL-запроса и применения аббревиатур для IRI и шаблонов триплетов, приведенных в разделе 4, существует абстрактное синтаксическое дерево, составленное из:

Шаблоны Модификаторы Формы запроса
RDF terms DISTINCT SELECT
triple patterns REDUCED CONSTRUCT
Basic graph patterns PROJECT DESCRIBE
Groups ORDER BY ASK
OPTIONAL LIMIT  
UNION OFFSET  
GRAPH    
FILTER    

В результате преобразования такого абстрактного синтаксического дерева получаем SPARQL-запрос, который использует следующие символы в SPARQL-алгебре:

Графовый шаблон Модификаторы решений
BGP ToList
Join OrderBy
LeftJoin Project
Filter Distinct
Union Reduced
Graph Slice

Slice комбинация OFFSET и LIMIT. mod - любой из модификаторов решений.

ToList используется там, где присутствует преобразование результатов графового шаблона в последовательности.

Определение: Запрос SPARQL

A Абстрактный запрос SPARQL это кортеж (E, DS, R), где:

12.2.1 Преобразование графовых шаблонов

Этот раздел описывает процесс перевода графовых шаблонов SPARQL в выражение SPARQL-алгебры. После перевода синтаксических аббревиатур для IRI и шаблонов триплетов, выполняется рекурсивная обработка синтаксических форм в выражения алгебры:

Рабочая группа отмечает, что подход, применяемый на этапе упрощения, приводит к неопределенной трансформации запросов, включая дважды вложенный фильтр и шаблон в:
OPTIONAL { { ... FILTER ( ... ?x ... ) } }..

Это проиллюстрировано в двух ненормативных вариантах тестов:

Сначала, расширьте аббревиатуры для IRI и шаблонов триплетов, представленных в разделе 4.

WhereClause состоит из GroupGraphPattern, который включает следующие формы:

Каждая из форм переводится в соответствии со следующей процедурой:

Transform(форма синтаксиса)

Если форма представлена TriplesBlock

Результатом является BGP(список шаблонов триплетов)

Если форма представлена GroupOrUnionGraphPattern

Пусть A := неопределено

Для каждого элемента G из GroupOrUnionGraphPattern
    If A неопределено
        A := Transform(G)
    Else
        A := Union(A, Transform(G))

Результатом является A

Если форма представлена GraphGraphPattern

If форма является GRAPH IRI GroupGraphPattern
    Результатом является Graph(IRI, Transform(GroupGraphPattern))
If форма является GRAPH Var GroupGraphPattern
    Результатом является Graph(Var, Transform(GroupGraphPattern))

Если форма представлена GroupGraphPattern

Мы вводим следующие обозначения:

Пусть FS := пустое множество
Пусть G := пустой шаблон, Z, основной графовый шаблон, который является пустым множеством.

Для каждого элемента E в GroupGraphPattern
   If E представлен в форме FILTER(expr)
       FS := FS объединение множеств(set-union) {expr}
   If E представлен в форме OPTIONAL{P}
   Then
       Пусть A := Transform(P)
       If A представлен в форме Filter(F, A2)
           G := LeftJoin(G, A2, F)
       else 
           G := LeftJoin(G, A, true)
   If E представлен в любой другой форме:
      Let A := Transform(E)
      G := Join(G, A)
   
  
If FS не пустое множество:
  Пусть X := Конъюнкция выражений в FS
  G := Filter(X, G)

Результатом является G.

Этап упрощения:

Группы из одного графового шаблона (не фильтра) становятся join(Z, A) и могут быть заменены на A. Пустой графовый шаблон Z является тождеством для join:

Замена join(Z, A) by A
Замена join(A, Z) by A

12.2.2 Примеры преобразованных графовых шаблонов

Вторая форма переделанного примера — это первая, где удалены пустые групповые объединения (join) на этапе упрощения.

Пример: группа с основным графовым шаблоном, состоящим из единственного шаблона триплета:

{ ?s ?p ?o }
Join(Z, BGP(?s ?p ?o) )
BGP(?s ?p ?o)

Пример: группа с основным графовым шаблоном, состоящим из двух шаблонов триплетов:

{ ?s :p1 ?v1 ; :p2 ?v2 }
BGP( ?s :p1 ?v1 .?s :p2 ?v2 )

Пример: группа, состоящая из объединения (union) двух графовых шаблонов:

{ { ?s :p1 ?v1 } UNION {?s :p2 ?v2 } }
Union(Join(Z, BGP(?s :p1 ?v1)),
      Join(Z, BGP(?s :p2 ?v2)) )
Union( BGP(?s :p1 ?v1) , BGP(?s :p2 ?v2) )

Пример: группа, состоящая из объединения объединения и основного графового шаблона:

{ { ?s :p1 ?v1 } UNION {?s :p2 ?v2 } UNION {?s :p3 ?v3 } }
Union(
    Union( Join(Z, BGP(?s :p1 ?v1)),
           Join(Z, BGP(?s :p2 ?v2))) ,
    Join(Z, BGP(?s :p3 ?v3)) )
Union(
    Union( BGP(?s :p1 ?v1) ,
           BGP(?s :p2 ?v2),
    BGP(?s :p3 ?v3))

Пример: группа, состоящая из основного графового шаблона и необязательного графового шаблона:

{ ?s :p1 ?v1 OPTIONAL {?s :p2 ?v2 } }
LeftJoin(
    Join(Z, BGP(?s :p1 ?v1)),
    Join(Z, BGP(?s :p2 ?v2)) ),
    true)
LeftJoin(BGP(?s :p1 ?v1), BGP(?s :p2 ?v2), true)

Пример: группа, состоящая из основного графового шаблона и двух необязательных графовых шаблонов:

{ ?s :p1 ?v1 OPTIONAL {?s :p2 ?v2 } OPTIONAL { ?s :p3 ?v3 } }
LeftJoin(
    LeftJoin(
        BGP(?s :p1 ?v1),
        BGP(?s :p2 ?v2),
        true) ,
    BGP(?s :p3 ?v3),
    true)

Пример: группа, состоящая из основного графового шаблона и необязательного графового шаблона с фильтром:

{ ?s :p1 ?v1 OPTIONAL {?s :p2 ?v2 FILTER(?v1<3) } }
LeftJoin(
     Join(Z, BGP(?s :p1 ?v1)),
     Join(Z, BGP(?s :p2 ?v2)),
     (?v1<3) )
LeftJoin(
    BGP(?s :p1 ?v1) ,
    BGP(?s :p2 ?v2) ,
   (?v1<3) )

Пример: группа, состоящая из объединенного графового шаблона и необязательного графового шаблона:

{ {?s :p1 ?v1} UNION {?s :p2 ?v2} OPTIONAL {?s :p3 ?v3} }
LeftJoin(
  Union(BGP(?s :p1 ?v1),
        BGP(?s :p2 ?v2)) ,
  BGP(?s :p3 ?v3) ,
  true )

Пример: группа, состоящая из основного графового шаблона, фильтра и необязательного графового шаблона:

{ ?s :p1 ?v1 FILTER (?v1 < 3 ) OPTIONAL {?s :p2 ?v2} } }
Filter( ?v1 < 3 ,
  LeftJoin( BGP(?s :p1 ?v1), BGP(?s :p2 ?v2), true) ,
  )

12.2.3 Преобразование модификаторов решений

Этап 1 : ToList

ToList преобразует мультимножество в последовательность с одинаковыми элементами и кардинальностью. В последовательности не подразумевается какая-либо упорядоченность; дубликаты не должны располагаться рядом.

Пусть M := ToList(Шаблон)

Этап 2 : ORDER BY

Если строка запроса имеет условие ORDER BY

M := OrderBy(M, список компараторов последовательности)

Этап 3 : Projection

M := Project(M, vars)

где vars — набор переменных, упомянутых в условии SELECT, либо все поименованные переменные запроса (если использовалась форма SELECT *).

Этап 4 : DISTINCT

Если запрос содержит DISTINCT,

M := Distinct(M)

Этап 5 : REDUCED

Если запрос содержит REDUCED,

M := Reduced(M)

Этап 6 : OFFSET и LIMIT

Если запрос содержит "OFFSET start" или "LIMIT length"

M := Slice(M, start, length)

start по умолчанию равен 0

length по умолчанию равна (size(M)-start).

Общий абстрактный запрос будет M.

12.3 Основные графовые шаблоны

При соответствии графовым шаблонам возможные решения из мультимножества [multiset] также известны, как bag. Мультимножество — это неупорядоченная коллекция элементов, где каждый элемент может встречаться более одного раза. Мультимножество описывается набором элементов и функцией кардинальности, задавая встречаемость каждого элемента множества в мультимножестве.

Запись μ соответствует преобразованиям решений,

Запись μ0 - такому преобразованию, что dom(μ0) является пустым множеством.

Запись Ω0 соответствует мультимножеству, состоящему только из пустого преобразования μ0, с кардинальностью 1. Это тождество объединения.

Запись μ(?x->t) соответствует преобразованиям решений переменной x в RDF-термин t : { (x, t) }

Запись Ω(?x->t) соответствует мультимножеству, состоящему только из μ(?x->t), то есть { { (x, t) } } с кардинальностью 1.

Определение: Совместимые преобразования

Два преобразования решений μ1 и μ2 совместимы, если для каждой переменной v в dom(μ1) и в dom(μ2), μ1(v) = μ2(v).

Если μ1 и μ2 совместимы, тогда μ1 объединение множеств μ2 также являются преобразованием. Запись merge(μ1, μ2) соответствует μ1 set-union μ2

Запись card[Ω](μ) соответствует кардинальности преобразований решений μ в мультимножестве преобразований Ω.

12.3.1 Соответствие основному графовому шаблону SPARQL

Основные графовые шаблоны формируют фундамент для соответствия шаблонам SPARQL. Основной графовый шаблон соответствует активному графу для определенной части запроса. Основной графовый шаблон можеть быть представлен заменой и переменных, и безымянных вершин терминами, что дает две категории экземпляров. Замена безымянных вершин осуществляется с помощью преобразования RDF-экземпляров,  σ, из безымянных вершин в RDF-термины; переменные заменяются преобразованием решений из переменных запроса в RDF-термины.

Определение: Преобразование экземпляра шаблона

Преобразование экземпляра шаблона, P, - это комбинация преобразования RDF-экземпляров, σ, и преобразований решений, μ. P(x) = μ(σ(x))

Любое преобразование экземпляра шаблона определяет уникальное преобразование решений и уникальное преобразование RDF-экземпляров, полученные путем ограничения до переменных запроса и безымянных вершин соответственно.

Определение: Соответствие основному графовому шаблону

Пусть BGP - основной графовый шаблон, а G -RDF-граф.

μ это решение для BGP из G, когда существует преобразование экземпляра шаблона P такое, что P(BGP) - это подграф G, а μ ограничение P переменных запроса BGP.

card[Ω](μ) = card[Ω](число уникальных преобразований экземпляра шаблона RDF-экземпляров, σ,а таких что P = μ(σ) - преобразование экземпляра шаблона, а P(BGP) - подграф G).

Если основной графовый шаблон является пустым множеством, тогда решением будет Ω0.

12.3.2 Обработка безымянных вершин

Это определение позволяет преобразованиям решений выполнить привязку переменной основного графового шаблона, BGP, к безымянной вершине в G. Тогда как SPARQL обрабатывает идентификаторы безымянных вершин в документе согласно XML-формат результатов SPARQL-запросов, они не могут восприниматься как идентифицирующие вершины в активном графе набора данных. Если DS является набором данных запроса, шаблонные решения, следовательно, воспринимаются не из активного графа DS самого, а из RDF-графа, называемого областью видимости графа (scoping graph), который эквивалентен активному графу DS, однако не разделяет безымянных вершин с DS или с BGP. Таже область видимости (scoping graph) используется для всех решений одного запроса. Область видимости — чисто теоретическая конструкция. На практике эффект достигается просто за счет соглашений, регламентирующих область действия документов, для идентификаторов безымянных вершин.

Потому как безымянные вершины RDF позволяют идентифицировать многие избыточные решения для многих шаблонов, может быть бесконечно много шаблонных решений (полученных путем замены безымянных вершин другими безымянными вершинами). Поэтому необходимо каким-то образом разграничить решения для основного графового шаблона. SPARQL использует критерий соответствия подграфа для определения решений основного графового шаблона. Существует одно решение для каждого уникального преобразования экземпляра шаблона из основного графового шаблона в подмножество активного графа.

Оптимизация выполнена для простоты вычислений, скорее чем элиминации избыточности, что позволяет результатам запроса содержать избыточность, даже когда активный граф набора данных является lean, а также позволяет логически эквивалентным наборам данных приводить к различным результатам запроса.

12.4 Алгебра SPARQL

Для каждого символа абстрактного запроса SPARQL мы определяем оператор для оценки. Операторы алгебры SPARQL используются для оценки вершин абстрактного запроса SPARQL согласно описанию, представленному в разделе "Семантика оценки".

Определение: Filter

Пусть Ω - мультимножество преобразований решений, а expr - выражение(expression). Определим:

Filter(expr, Ω) = { μ | μ в Ω и expr(μ) является выражением с эффективным булевым значением true }

card[Filter(expr, Ω)](μ) = card[Ω](μ)

Определение: Join

Пусть Ω1 и Ω2 - мультимножество преобразований решений. Определим:

Join(Ω1, Ω2) = { merge(μ1, μ2) | μ1 в Ω1и μ2 в Ω2, и μ1 и μ2 - совместимы }

card[Join(Ω1, Ω2)](μ) =
    для каждого merge(μ1, μ2), μ1 в Ω1и μ2 в Ω2 такое что μ = merge(μ1, μ2),
        сумма по (μ1, μ2), card[Ω1](μ1)*card[Ω2](μ2)

Возможно, что преобразование решений μ внутри Join может появиться в разных преобразованиях решений, μ1и μ2 в объединенных мультимножествах. Кардинальность  μ - это сумма кардинальностей всех возможностей.

Определение: Diff

Пусть Ω1 и Ω2 мультимножества преобразований решений. Определим:

Diff(Ω1, Ω2, expr) = { μ | μ в Ω1 такое что для всех μ′ в Ω2, либо μ и μ′ несовместимы, либо μ и μ' совместимы и expr(merge(μ, μ')) имеет эффективное булево значение false }

card[Diff(Ω1, Ω2, expr)](μ) = card[Ω1](μ)

Diff используется внутри для определения LeftJoin.

Определение: LeftJoin

Пусть Ω1 и Ω2 - мультимножества преобразований решений, а expr - выражение (expression). Определим:

LeftJoin(Ω1, Ω2, expr) = Filter(expr, Join(Ω1, Ω2)) объединение множеств (set-union) Diff(Ω1, Ω2, expr)

card[LeftJoin(Ω1, Ω2, expr)](μ) = card[Filter(expr, Join(Ω1, Ω2))](μ) + card[Diff(Ω1, Ω2, expr)](μ)

Полная запись выглядит следующим образом:

LeftJoin(Ω1, Ω2, expr) =
    { merge(μ1, μ2) | μ1 в Ω1and μ2 в Ω2, и μ1 и μ2 совместимы и expr(merge(μ1, μ2)) является true }
set-union
    { μ1 | μ1 в Ω1и μ2 в Ω2, и μ1 и μ2 - несовместимы }
set-union
    { μ1 | μ1 в Ω1 и μ2 в Ω2, и μ1 и μ2 совместимы expr(merge(μ1, μ2)) является false }

Все они уникальны, кардинальность LeftJoin соответствует кардинальности этих отдельных компонентов определния.

Определение: Union

Пусть Ω1 и Ω2 - мультимножества преобразований решений. Определим:

Union(Ω1, Ω2) = { μ | μ в Ω1 или μ в Ω2 }

card[Union(Ω1, Ω2)](μ) = card[Ω1](μ) + card[Ω2](μ)

Запись [x | C] соответствует последовательности элементов, где C(x) - true.

Запись card[L](x) соответствует кардинальности x в L.

Определение: ToList

Пусть Ω - мультимножество преобразований решений. Определим:

ToList(Ω) = последовательность преобразований μ в Ω в любом порядке с card[Ω](μ) встречаемостью μ

card[ToList(Ω)](μ) = card[Ω](μ)

Определение: OrderBy

Пусть Ψ - последовательность преобразований решений. Определим:

OrderBy(Ψ, условие) = [ μ | μ в Ψ и последовательность удовлетворяет условию упорядочения]

card[OrderBy(Ψ, условия)](μ) = card[Ψ](μ)

Определение: Project

Пусть Ψ - последовательность преобразований решений, а PV - набор переменных.

Для преобразования μ, запись Proj(μ, PV) соответсвует ограничению μ переменных в PV.

Project(Ψ, PV) = [ Proj(Ψ[μ], PV) | μ in Ψ ]

card[Project(Ψ, PV)](μ) = card[Ψ](μ)

Последовательность Project(Ψ, PV) должна сохранять любой порядок следования, заданный с помощью OrderBy.

Определение: Distinct

Пусть Ψ - последовательность преобразований решений. Определим:

Distinct(Ψ) = [ μ | μ in Ψ ]

card[Distinct(Ψ)](μ) = 1

Последовательность Distinct(Ψ) должна сохранять любой порядок следования, заданный посредством OrderBy.

Определение: Reduced

Пусть Ψ — последовательность преобразований решений. Определим:

Reduced(Ψ) = [ μ | μ в Ψ ]

card[Reduced(Ψ)](μ) находится между 1 и card[Ψ](μ)

Последовательность Reduced(Ψ) должна сохранять любой порядок следования, заданный посредством OrderBy.

Огранинченный модификатор последовательности решений не гарантирует определенную кардинальность.

Определение: Slice

Пусть Ψ - последовательность преобразований решений. Определим:

Slice(Ψ, start, length)[i] = Ψ[start+i] for i = 0 to (length-1)

12.5 Семантика оценки

Определим eval(D(G), графовый шаблон) как оценку графового шаблона относительно набора данных D с активным графом G. Исходно активный граф является графом по умолчанию.

D : набор данных
D(G) : набор данных D с активным графом G (которому соответствуют шаблоны )
D[i] : Граф с IRI i в наборе данных D
D[DFT] : граф по умолчанию D
P, P1, P2 : графовые шаблоны
L : последовательность решений
Определение: Оценка Filter(F, P)
eval(D(G), Filter(F, P)) = Filter(F, eval(D(G),P))
Определение: Оценка Join(P1, P2)
eval(D(G), Join(P1, P2)) = Join(eval(D(G), P1), eval(D(G), P2))
Определение: Оценка LeftJoin(P1, P2, F)
eval(D(G), LeftJoin(P1, P2, F)) = LeftJoin(eval(D(G), P1), eval(D(G), P2), F)
Определение: Оценка основного графового шаблона
eval(D(G), BGP) = мультимножество преобразований решений

См. раздел 12.3 Основные графовые шаблоны

Определение: Оценка шаблона Union
eval(D(G), Union(P1,P2)) = Union(eval(D(G), P1), eval(D(G), P2))
Определение: Оценка графового шаблона
if IRI - имя графа в D
eval(D(G), Graph(IRI,P)) = eval(D(D[IRI]), P)
if IRI не является именем графа в D
eval(D(G), Graph(IRI,P)) = пустое мультимножество
eval(D(G), Graph(var,P)) =
     Пусть R пустое мультимножество
     для каждого IRI i в D
        R := Union(R, Join( eval(D(D[i]), P) , Ω(?var->i) )
     в результате получится R

Для оценки графа используется оператор алгебры SPARQL, union. Кардинальность преобразования решений является суммой кардинальностей преобразований решений внутри каждой опреации join.

Определение: Оценка ToList
eval(D, ToList(P)) = ToList(eval(D(D[DFT]), P))
Определение: Оценка Distinct

eval(D, Distict(L)) = Distinct(eval(D, L))
Определение: Оценка Reduced
eval(D, Reduced(L)) = Reduced(eval(D, L))
Определение: Оценка Project
eval(D, Project(L, vars)) = Project(eval(D, L), vars)
Определение: Оценка OrderBy
eval(D, OrderBy(L, condition)) = OrderBy(eval(D, L), condition)
Определение: Оценка Slice
eval(D, Slice(L, start, length)) = Slice(eval(D, L), start, length)

12.6 Расширение соответствия основному графу

SPARQL предназначен для работы с запросами, которые предполагают более продуманный порядок следования, нежели простое следование, что достигается путем перезаписи условий соответствия для основных графовых шаблонов. Так это открытая исследовательская проблема — установка подобных условий в единой общей форме, применимой ко всем формам следования и оптимально элиминирует ненужную или неуместную избыточность — этот документ лишь предоставляет необходимые условия, которым должно удовлетворять любое решение. Это требует расширения до полных определений для каждого конкретного случая.

Основные графовые шаблоны точно так же относятся к шаблонам триплетов, как RDF-графы к RDF-триплетам. К ним применима практически та же терминология. В частности, два основных графовых шаблона считаются эквивалентными, если существует взаимно однозначное соответствие M между терминами шаблонов триплетов, которые преобразуют безымянные вершины в безымянные вершины, преобразуют переменные, литералы и IRI в самих себя так, что триплет ( с, п, о ) находится в первом шаблоне тогда и только тогда, когда триплет ( M(s), M(p) M(o) ) находится во втором. Это определение распространяется для эквивалентности RDF-графа основным графовым шаблонам посредством сохранения имен переменных в эквивалентных шаблонах

Режим следования(entailment regime) определяет

  1. подмножество RDF-графов, которое называется правильно сформированным для режима
  2. отношение следования между подмножествами правильно сформированных графов и правильно сформированными графами

Примеры режимов следования включают простое (simple) следование [RDF-MT], RDF-следование [RDF-MT], RDFS-следование [RDF-MT], D-следование [RDF-MT] и OWL-DL следование [OWL-Semantics]. Из всех их, только следование OWL-DL ограничивает набор правильно сформированных графов. Если E — режим следования, тогда мы будем говорить о E-следовании, E-согласованности и так далее, согласно данному соглашению по именованию.

Некоторые режимы следования могут категоризовать кое-какие RDF-графы, как противоречивые. Например, RDF-граф::

_:x rdf:type xsd:string .
_:x rdf:type xsd:decimal .

является D-противоречивым, когда D содержит типы данных XSD. Результат запроса над противоречивым графом не раскрыт в данной спецификации, однако должен быть определен отдельным расширением SPARQL.

Расширение SPARQL по E-следованию должно удовлетворять следующим условиям.

1 -- Область вилимости графа, SG, соответствующий любому активному графу AG, является уникально определенным и E-эквивалентным AG.

2 -- Для любого основного графового шаблона BGP и преобразования шаблонных решений P, P(BGP) является правильно сформированным для E.

3 -- Для любой области определения графа SG и ответов {P1 ... Pn} основного графового шаблона BGP, где {BGP1 .... BGPn} набор основных графовых шаблонов, эквивалентных BGP, ни один из которых не разделяет какие-либо безымянные вершины с любыми другими или с SG

E-следования SG (SG union P1(BGP1) union ... union Pn(BGPn))

Эти условия полностью не определяют набор возможных решений, так как RDF разрешает неограниченную избыточность, поэтому должно выполняться следующее условие.

4 -- Каждое расширение SPARQL должно предусматривать условия по наборам ответов, которые гарантируют, что каждый BGP и AG имеет ограниченный набор ответов, уникальных вплоть до эквивалентности RDF-графа.

Заметки

(a) SG будет зачастую эквивалентен AG, однако ограниченение до E-эквивалентности допускает некоторые формы нормализации, например, элиминацию семантической избыточности исходных документов перед выполнением запросов.

(b) Конструкция в условии 3 гарантирует, что любые безымянные вершины, приведенные при преобразовании решений, используются способом, который внутренне совместим с использованием безымянных вершин, встречающихся в SG. Такой подход гарантирует, что идентификаторы безымянных вершин встречаются в более, чем одном ответе в наборе ответов только тогда, когда таким образом определенные безымянные вершины действительно идентичны в SG. Если расширение не разрешает привязки ответов к пустым вершинам, тогда данное условие может быть упрощено к следующиму:

E-следования SG P(BGP) для каждого шаблонного решения P.

(c) Эти условия не предполагают соответствие требованию SPARQL касательно того, что SG не разделяет безымянных вершин с AG или BGP. В частности, это позволяет SG фактически быть AG; разрешены протоколы запросов, в которых идентификаторы безымянных вершин сохраняют свои значения между запросом и исходным документом либо во всех множественных запросах. Однако такие протоколы не поддерживаются текущей спецификацией SPARQL-протокола.

(d) Так как 1–3 — лишь необходимые условия для ответов, условие 4 разрешает варианты, где набор правильных ответов может быть ограничен разными способами. Например, текущее положение дел в запросах OWL-DL концентрирует внимание на тех вариантах, где запрещены привязки ответов к пустым вершинам. Отметим, что эти условия разрешают даже патологический 'без ответный' вариант, когда каждый запрос имеет пустой набор ответов.

(e)Ни одно из этих условий не ссылается явно на преобразования экземпляров безымянных вершин в BGP. Для некоторых режимов следования существующая интерпретация безымянных вершин не может быть полностью охвачена существованием единственного преобразования экземпляра. Эти условия позволяют таким режимам дать пустым вершинам в шаблонах запросов 'полностью существующее'('fully existential') чтение.

Очевидно, что SPARQL удовлетворяет этим условиям для варианта, где E — простое (simple) следование, а условие SPARQL по SG граф-эквивалентно AG, однако не разделяет безымянных вершин с AG или BGP (что удовлетворяет первому условию). Единственное нетривиальное условие — это (3).

Где Pi является ограничением преобразований решений SPARQL-экземпляра Mi, такого что Mi(BGPi) - это подграф SG. Так как BGPi и SG зачастую не имеют безымянных вершин, диапазон Mi не содержит безымянных вершин из BGPi. Следовательно, компоненты Mi - преобразование решений Pi и преобразование RDF-экземпляров Ii - взаимозаменяемы. Таким образом, Mi(BGPi) = Ii(Pi(BGPi)). Поэтому

M1(BGP1) union ... union Mn(BGPn)
= I1(P1(BGP1)) union ... union In(Pn(BGPn))
= [ I1 + ... + In]( P1(BGP1) union ... union Pn(BGPn) )

так как домены преобразований экземпляров Ii являются взаимоисключаемыми. Потому они также исключены из SG,

SG union [ I1 + ... + In]( P1(BGP1) union ... union Pn(BGPn) )
= [ I1 + ... + In](SG union P1(BGP1) union ... union Pn(BGPn) )

т.е.

SG union P1(BGP1) union ... union Pn(BGPn)

имеет экземпляр, который является подграфом SG, потому он просто иницируется SG согласно лемме об интерполяции RDF [RDF-MT].

A. Грамматика SPARQL

A.1 Строка SPARQL-запроса

Строка SPARQL-запроса представляет собой строку символов Unicode (согласно разделу 6.1 Строковые концепции из [CHARMOD]) на языке, определенном следующей грамматикой, начиная с продукции Query. Для совместимости с последующими версиями Unicode, символы в строке могут включать Unicode codepoint, которые не были заданы на момент публикации этого документа (см. Идентификатор и синтаксис шаблонов [UNIID], раздел 4, Синтаксис шаблонов). Для продукций с классами запрещенных символов (например, [^<>'{}|^`]), символы исключаются из диапазона #x0 - #x10FFFF.

A.2 Codepoint Escape-последовательности

В строке SPARQL-запроса выполняется поиск codepoint escape-последовательностей перед разбором при помощи грамматики, описанной далее в EBNF. Ниже приведены codepoint escape-последовательности для строки SPARQL-запроса:

Escape Unicode code point
'\u' HEX HEX HEX HEX A Unicode code point в диапазоне U+0 до U+FFFF, содержащий соответствующее кодированное шестнадцатеричное значение.
'\U' HEX HEX HEX HEX HEX HEX HEX HEX Unicode code point в диапазоне от U+0 до U+FFFF, содержащий соответствующее кодированное шестнадцатеричное значение.

где HEX шестнадцатеричный символ

HEX ::= [0-9] | [A-F] | [a-f]

Примеры:

<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

Codepoint escape-последовательности могут появляться в любом месте строки запроса. Они обрабатываются до разбора на базе правил грамматики, поэтому могут быть заменены на codepoint со значимостью в грамматике, например, на ":".

Эти escape-последовательности не включены в нижеприведенную грамматику. Могут быть приведены лишь escape-последовательности для символов, которые будут правомерными в таком случае в грамматике. Скажем, переменная "?x\u0020y" неправомерна (\u0020 — это пробел, и его нельзя использовать в имени переменной)

A.3 Пробел (White Space)

Пробел - продукция WS) - используется для разделения двух терминалов, которые в противном случае будут (некорректно) распознаны как один терминал. Нижеприведенные названия правил, написанные с заглавных букв, определяют места, в которых важны пробелы. Это позволяет выбрать терминалы для создания анализатора SPARQL. Пробелы в строках важны.

Например:

?a<?b&&?c>?d

Эта последовательность символов содержит переменную '?a', IRI '<?b&&?c>', и переменную '?d', а не выражение с оператором '&&', соединяющим два выражения со знаками '<' (меньше) и '>' (больше).

A.4 Комментарии

Комментарии в SPARQL-запросах имеют вид '#', вне IRI или строкового значения, и продолжаются до конца строки (отмеченной символами 0x0D или 0x0A) либо до конца файла, если нет окончания строки после маркера комментария. Комментарии обрабатываются как пробелы.

A.5 Ссылки IRI

Текст, соответствующий продукции IRI_REF и PrefixedName (после расширения префикса) после обработки escape, должен быть согласован с общим синтаксисом ссылок IRI, раздел 2.2 RFC 3987 "ABNF для ссылок IRI и IRI" [RFC3987]. Например, в строке Sparql-запроса может встретиться IRI_REF <abc#def>, однако IRI_REF <abc##def> не должно.

Базовые IRI, задекларированные с помощью ключевого слова BASE, должны быть абсолютными IRI. Префикс, заданный посредством ключевого слова PREFIX, не может быть передекларирован в том же запросе. См. раздел 2.1.1,, Синтаксис IRI-терминов с описанием BASE и PREFIX.

A.6 Метки безымянных вершин

Одинаковые метки безымянных вершин нельзя использовать в двуз разных основных графовых шаблонах в одном запросе.

A.7 Escape-последовательности в строках

В дополнение к codepoint escape-последовательностям, нижеприведенные escape-последовании применяются в продукциях string (например, STRING_LITERAL1, STRING_LITERAL2, STRING_LITERAL_LONG1, STRING_LITERAL_LONG2):

Escape Unicode code point
'\t' U+0009 (tab)
'\n' U+000A (line feed)
'\r' U+000D (carriage return)
'\b' U+0008 (backspace)
'\f' U+000C (form feed)
'\"' U+0022 (quotation mark, double quote mark)
"\'" U+0027 (apostrophe-quote, single quote mark)
'\\' U+005C (backslash)

Примеры:

"abc\n"
"xy\rz"
'xy\tz'

A.8 Грамматика

Используемая в грамматике нотация EBNF определена в Extensible Markup Language (XML) 1.1 [XML11],раздел 6 Нотация.

Ключевые слова не чувствительны к регистру, за исключением ключевого слова 'a', которое согласно Turtle и N3 используется вместо IRI rdf:type (полностью, http://www.w3.org/1999/02/22-rdf-syntax-ns#type).

Ключевые слова:

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

Escape-последовательности чувствительны к регистру.

При выборе правила используется самое длинное соответствие.

[1]   Query   ::=   Prologue
( SelectQuery | ConstructQuery | DescribeQuery | AskQuery )
[2]   Prologue   ::=   BaseDecl? PrefixDecl*
[3]   BaseDecl   ::=   'BASE' IRI_REF
[4]   PrefixDecl   ::=   'PREFIX' PNAME_NS IRI_REF
[5]   SelectQuery   ::=   'SELECT' ( 'DISTINCT' | 'REDUCED' )? ( Var+ | '*' ) DatasetClause* WhereClause SolutionModifier
[6]   ConstructQuery   ::=   'CONSTRUCT' ConstructTemplate DatasetClause* WhereClause SolutionModifier
[7]   DescribeQuery   ::=   'DESCRIBE' ( VarOrIRIref+ | '*' ) DatasetClause* WhereClause? SolutionModifier
[8]   AskQuery   ::=   'ASK' DatasetClause* WhereClause
[9]   DatasetClause   ::=   'FROM' ( DefaultGraphClause | NamedGraphClause )
[10]   DefaultGraphClause   ::=   SourceSelector
[11]   NamedGraphClause   ::=   'NAMED' SourceSelector
[12]   SourceSelector   ::=   IRIref
[13]   WhereClause   ::=   'WHERE'? GroupGraphPattern
[14]   SolutionModifier   ::=   OrderClause? LimitOffsetClauses?
[15]   LimitOffsetClauses   ::=   ( LimitClause OffsetClause? | OffsetClause LimitClause? )
[16]   OrderClause   ::=   'ORDER' 'BY' OrderCondition+
[17]   OrderCondition   ::=   ( ( 'ASC' | 'DESC' ) BrackettedExpression )
| ( Constraint | Var )
[18]   LimitClause   ::=   'LIMIT' INTEGER
[19]   OffsetClause   ::=   'OFFSET' INTEGER
[20]   GroupGraphPattern   ::=   '{' TriplesBlock? ( ( GraphPatternNotTriples | Filter ) '.'? TriplesBlock? )* '}'
[21]   TriplesBlock   ::=   TriplesSameSubject ( '.' TriplesBlock? )?
[22]   GraphPatternNotTriples   ::=   OptionalGraphPattern | GroupOrUnionGraphPattern | GraphGraphPattern
[23]   OptionalGraphPattern   ::=   'OPTIONAL' GroupGraphPattern
[24]   GraphGraphPattern   ::=   'GRAPH' VarOrIRIref GroupGraphPattern
[25]   GroupOrUnionGraphPattern   ::=   GroupGraphPattern ( 'UNION' GroupGraphPattern )*
[26]   Filter   ::=   'FILTER' Constraint
[27]   Constraint   ::=   BrackettedExpression | BuiltInCall | FunctionCall
[28]   FunctionCall   ::=   IRIref ArgList
[29]   ArgList   ::=   ( NIL | '(' Expression ( ',' Expression )* ')' )
[30]   ConstructTemplate   ::=   '{' ConstructTriples? '}'
[31]   ConstructTriples   ::=   TriplesSameSubject ( '.' ConstructTriples? )?
[32]   TriplesSameSubject   ::=   VarOrTerm PropertyListNotEmpty | TriplesNode PropertyList
[33]   PropertyListNotEmpty   ::=   Verb ObjectList ( ';' ( Verb ObjectList )? )*
[34]   PropertyList   ::=   PropertyListNotEmpty?
[35]   ObjectList   ::=   Object ( ',' Object )*
[36]   Object   ::=   GraphNode
[37]   Verb   ::=   VarOrIRIref | 'a'
[38]   TriplesNode   ::=   Collection | BlankNodePropertyList
[39]   BlankNodePropertyList   ::=   '[' PropertyListNotEmpty ']'
[40]   Collection   ::=   '(' GraphNode+ ')'
[41]   GraphNode   ::=   VarOrTerm | TriplesNode
[42]   VarOrTerm   ::=   Var | GraphTerm
[43]   VarOrIRIref   ::=   Var | IRIref
[44]   Var   ::=   VAR1 | VAR2
[45]   GraphTerm   ::=   IRIref | RDFLiteral | NumericLiteral | BooleanLiteral | BlankNode | NIL
[46]   Expression   ::=   ConditionalOrExpression
[47]   ConditionalOrExpression   ::=   ConditionalAndExpression ( '||' ConditionalAndExpression )*
[48]   ConditionalAndExpression   ::=   ValueLogical ( '&&' ValueLogical )*
[49]   ValueLogical   ::=   RelationalExpression
[50]   RelationalExpression   ::=   NumericExpression ( '=' NumericExpression | '!=' NumericExpression | '<' NumericExpression | '>' NumericExpression | '<=' NumericExpression | '>=' NumericExpression )?
[51]   NumericExpression   ::=   AdditiveExpression
[52]   AdditiveExpression   ::=   MultiplicativeExpression ( '+' MultiplicativeExpression | '-' MultiplicativeExpression | NumericLiteralPositive | NumericLiteralNegative )*
[53]   MultiplicativeExpression   ::=   UnaryExpression ( '*' UnaryExpression | '/' UnaryExpression )*
[54]   UnaryExpression   ::=     '!' PrimaryExpression
| '+' PrimaryExpression
| '-' PrimaryExpression
| PrimaryExpression
[55]   PrimaryExpression   ::=   BrackettedExpression | BuiltInCall | IRIrefOrFunction | RDFLiteral | NumericLiteral | BooleanLiteral | Var
[56]   BrackettedExpression   ::=   '(' Expression ')'
[57]   BuiltInCall   ::=     'STR' '(' Expression ')'
| 'LANG' '(' Expression ')'
| 'LANGMATCHES' '(' Expression ',' Expression ')'
| 'DATATYPE' '(' Expression ')'
| 'BOUND' '(' Var ')'
| 'sameTerm' '(' Expression ',' Expression ')'
| 'isIRI' '(' Expression ')'
| 'isURI' '(' Expression ')'
| 'isBLANK' '(' Expression ')'
| 'isLITERAL' '(' Expression ')'
| RegexExpression
[58]   RegexExpression   ::=   'REGEX' '(' Expression ',' Expression ( ',' Expression )? ')'
[59]   IRIrefOrFunction   ::=   IRIref ArgList?
[60]   RDFLiteral   ::=   String ( LANGTAG | ( '^^' IRIref ) )?
[61]   NumericLiteral   ::=   NumericLiteralUnsigned | NumericLiteralPositive | NumericLiteralNegative
[62]   NumericLiteralUnsigned   ::=   INTEGER | DECIMAL | DOUBLE
[63]   NumericLiteralPositive   ::=   INTEGER_POSITIVE | DECIMAL_POSITIVE | DOUBLE_POSITIVE
[64]   NumericLiteralNegative   ::=   INTEGER_NEGATIVE | DECIMAL_NEGATIVE | DOUBLE_NEGATIVE
[65]   BooleanLiteral   ::=   'true' | 'false'
[66]   String   ::=   STRING_LITERAL1 | STRING_LITERAL2 | STRING_LITERAL_LONG1 | STRING_LITERAL_LONG2
[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
[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.

Заметки:

  1. Грамматика SPARQL является LL(1), когда правила с именами, написанными прописными буквами, используются в качестве терминалов.
  2. 2. В числах со знаком (signed number) не разрешен пробел между знаком и числом. Правило грамматики AdditiveExpression разрешает это выполнить путем сокрытия двух составляющих выражения, за которым следует число со знаком, что приводит к прибавлению или вычитанию числа без знака, как и необходимо.

Некоторые файлы грамматики для часто используемых инструментов доступны здесь.

B. Соответствие

См. приложение Грамматика SPARQL для согласования по строкам запроса SPARQL, и раздел 10 Формы запросов для согласования результатов запросов. См. приложение E. Медиа-тип Интернета для согласования медиа-типа application/sparql-query.

Эту спецификацию предполагается использовать вместе со SPARQL-протоколом [SPROT] и XML-формат результатов SPARQL-запросов [RESULTS]. Обращайтесь к этим спецификациям для согласования.

Обратите внимание, что SPARQL-протокол описывает абстрактный интерфейс, также как и сетевой протокол, а абстрактный интерфейс можно применить к API и сетевым интерфейсам.

C. Размышления о безопасности (Информативный)

Запросы SPARQL, в которых используются ключевые слова FROM, FROM NAMED или GRAPH, могут обуславливать разыменование определенных URI. Это может стать причиной дополнительной нагрузки на сеть, диск или ресурсы процессора вместе с сопутствующими проблемами отказа сервиса. Следует учитывать проблемы безопасности Uniform Resource Identifier (URI): общий синтаксис [RFC3986], раздел 7. Кроме того, в некоторых случаях можно получить доступ к содержимому URI file:, обработать его и возвратить результаты, обеспечивая непреднамеренный доступ к локальным ресурсам.

Язык SPARQL разрешает расширения, которые предполагают собственную концепцию безопасности.

Различные IRI могут выглядеть одинаково. Символы в разных скриптах могут отображаться подобным образом ("о" кириллицы может выглядеть аналогично "o" в латинице). Комбинированные символы могут отображаться точно так же, как другие символы (например, МАЛЕНЬКАЯ ЛАТИНСКАЯ E, за которой следует символ тяжелого ударения, выглядит так, будто это МАЛЕНЬКАЯ ЛАТИНСКАЯ E с обычным ударением). Пользователи SPARQL должны создавать запросы с IRI, которые соответствуют IRI по данным. Дополнительную информацию по соответствию символов можно найти в Unicode Security Considerations [UNISEC] и Internationalized Resource Identifiers (IRIs) [RFC3987], раздел 8.

D. Медиа-тип Интернета, расширение файла и тип файла Macintosh

Контактное лицо:
Эрик Прудхоммоукс
См. также:
Как зарегистрировать медиа-тип для спецификации W3C
Регистриация медиа-типа Интернета, согласованность использования
Разработка TAG от 3 июня 2002 (исправлено 4 сентября 2002)

Медиа-тип Интернета / тип MIME для языка запросов SPARQL — "application/sparql-query".

Рекомендуется, чтобы файлы SPARQL-запросов имели расширение ".rq" (все буквы строчные) на всех платформах.

Рекомендуется, чтобы файлы SPARQL-запросов хранились в Macintosh с файловой системой HFS, а тип файла соответствовал "TEXT".

Имя типа:
application
Имя подтипа:
sparql-query
Обязательные параметры:
None
Необязательные параметры:
None
Размышления по поводу кодировки:
Синтаксис языка запросов SPARQL представлен в коде Unicode [UNICODE]. Кодировка всегда соответствует UTF-8 [RFC3629].
Unicode code point могут быть также выражены с помощью синтаксиса \uXXXX (ииот U+0 до U+FFFF) или \UXXXXXXXX (от U+10000 и далее) где X - шестнадцатиричная цыфра [0-9A-F]
Размышления о безопасности:
См. приложение C текущего документа, Размышления о безопасности, а также RFC 3629 [RFC3629], раздел 7 Размышления о безопасности.
Размышления касательно интероперабельности:
Нет изветсных проблем с интероперабельностью.
Опубликованная спецификация:
Текущая спецификация.
Приложения, которые используют этот медиа-тип:
Ни одно из известных приложений не применяет этот медиа-тип.
Дополнительная информация:
Магическое число(а):
Запрос SPARQL может содержать строковое значение 'PREFIX' (не зависит от регистра) где-то в начале документа.
Расширение(я) файла:
".rq"
Базовый URI:
SPARQL-термин 'BASE <IRIref>' может изменить текущий базовый URI на относительные IRIref в языке запросов, которые будут использоваться далее на протяжении всего документа.
Код типа файла Macintosh::
"TEXT"
Лицо и электронный адрес, с которым можно связаться для получения дальнейшей информации:
public-rdf-dawg-comments@w3.org
Предполагаемое использование:
COMMON (Обычное)
Ограничения по использованию:
нет
Автор/Контролер ща изменениями:
Спецификация SPARQL — это результат деятельности рабочей группы доступа к RDF-данным консорциума World Wide Web. W3C контролирует изменения этих спецификаций.

E. Ссылки

Нормативные ссылки

[CHARMOD]
Символьная модель для World Wide Web 1.0: основы, , Р. Ишида, Ф. Ергау, М. Дюрст, M. Вульф, T. Тексин, редакторы, рекомендация W3C, 15 февраля 2005, http://www.w3.org/TR/2005/REC-charmod-20050215/ . Последняя версия доступна на http://www.w3.org/TR/charmod/.
[CONCEPTS]
Resource Description Framework (RDF): концепции и абстрактный синтаксис,Дж. Клайн, Дж. Дж. Кэрролл, редакторы, рекомендация W3C, 10 февраля 2004, http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/ . Последняя версия доступна на http://www.w3.org/TR/rdf-concepts/ .
[FUNCOP]
XQuery 1.0 and XPath 2.0 Функции и операторы, Дж. Мелтон, A. Мальхотра, Н. Вольш, редакторы, рекомендация W3C, 23 января 2007, http://www.w3.org/TR/2007/REC-xpath-functions-20070123/. Последняя версия доступна на http://www.w3.org/TR/xpath-functions/ .
[RDF-MT]
Семантика RDF, Хейс, редактор, рекомендация W3C, 10 февраля 2004, http://www.w3.org/TR/2004/REC-rdf-mt-20040210/. Последняя версия доступна на http://www.w3.org/TR/rdf-mt/ .
[RFC3629]
RFC 3629 UTF-8, формат преобразования ISO 10646, Ф. Ергау, ноябрь 2003
[RFC4647]
RFC 4647 Соответствие тегам языка, A. Филлипс, M. Дэвис, сентябрь 2006
[RFC3986]
RFC 3986 Uniform Resource Identifier (URI): общий синтаксис, , T. Бернерс-Ли, Р. Фильдинг, Л. Мэсинтер, январь 2005
[RFC3987]
RFC 3987, "Internationalized Resource Identifiers (IRIs)", M. Дюрст , M. Сьюигнард
[UNICODE]
Стандарт Unicode, версия 4. ISBN 0-321-18578-1, время от времени обновляемый публикациями новых версий. Последняя версия стандарта Unicode и дополнительная информация о версиях стандарта и о символьной базе данных Unicode доступна на http://www.unicode.org/unicode/standard/versions/.
[XML11]
Extensible Markup Language (XML) 1.1, JДж. Коуан, Дж. Паоли, Э. Мэлер, К. M. Сперберг-Мак-Квин, Ф. Ергау, T. Брей, редакторы, рекомендация W3C, 4 февраля 2004, http://www.w3.org/TR/2004/REC-xml11-20040204/ . Последняя версия доступна на http://www.w3.org/TR/xml11/ .
[XPATH20]
Язык XML Path (XPath) 2.0, Берглунд, С. Боуг, Д. Чемберлин, M. Ф. Фернандес, M. Кэй, Дж. Роби, Дж. Симеон, редакторы, рекомендация W3C, 23 января 2007, http://www.w3.org/TR/2007/REC-xpath20-20070123/. Последняя версия доступна на http://www.w3.org/TR/xpath20/ .
[XQUERY]
XQuery 1.0: язык XML-запросов, С. Боуг, Д. Чемберлин, M. Ф. Фернандес, M. Кэй, Дж. Роби, Дж. Симеон, редакторы, рекомендация W3C, 23 января 2007, http://www.w3.org/TR/2007/REC-xquery-20070123/. Последняя версия доступна на http://www.w3.org/TR/xquery/ .
[XSDT]
XML-схема часть 2: типы данных вторая редакция, П. В. Бирон, A. Мальхотра, редакторы, рекомендация W3C, 28 октября 2004, http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/. Последняя версия доступна на http://www.w3.org/TR/xmlschema-2/ .
[BCP47]
Лучшие общие практики 47, П. В. Бирон, A. Мальхотра, редакторы, рекомендация W3C, 28 октября 2004, http://www.rfc-editor.org/rfc/bcp/bcp47.txt .

Информативные ссылки

[CBD]
CBD - Concise Bounded Description, Патрик Стиклер, Nokia, W3C Member Submission, 3 июня 2005.
[DC]
Выражение простого Дублинского ядра в RDF/XML Инициатива метаданных Дублинского ядра рекомендация 2002-07-31.
[Multiset]
Мультимножество, Википедия, Свободная энциклопедия. Статья, предложенная на 25 октября 2007, на http://en.wikipedia.org/. последняя версия этой статьи на http://en.wikipedia.org/wiki/Multiset.
[OWL-Semantics]
Язык Web-онтологий OWL: семантика и абстрактный синтаксис, Питер Ф. Патель-Шнайдер, Патрик Хейс, Ян Горрокс, редакторы, рекомендация W3C http://www.w3.org/TR/2004/REC-owl-semantics-20040210/ Последняя версия на http://www.w3.org/TR/owl-semantics/.
[RDFS]
Язык описания RDF-словаря 1.0: RDF-схема, Дэн Брикли, Р.В. Гуа, редакторы, рекомендация W3C, 10 февраля 2004, http://www.w3.org/TR/2004/REC-rdf-schema-20040210/ . Последняя версия на http://www.w3.org/TR/rdf-schema/ .
[RESULTS]
XML-формат результатов SPARQL-запросов, Д. Бэкетт, редактор, рекомендация W3C, 15 января 2008, http://www.w3.org/TR/2008/REC-rdf-sparql-XMLres-20080115/. Последняя версия доступна на http://www.w3.org/TR/rdf-sparql-XMLres/ .
[SPROT]
Протокол SPARQL для RDF, K. Кларк, редактор, рекомендация W3C, 15 января 2008, http://www.w3.org/TR/2008/REC-rdf-sparql-protocol-20080115/ . Последняя версия доступна на http://www.w3.org/TR/rdf-sparql-protocol/ .
[TURTLE]
Turtle - Terse RDF Triple Language, Дэйв Бэкетт.
[UCNR]
Доступ к данным RDF: варианты использвоания и требования, K. Кларк, редактор, рабочий проект W3C, 25 марта 2005, http://www.w3.org/TR/2005/WD-rdf-dawg-uc-20050325/ http://www.w3.org/TR/2005/WD-rdf-dawg-uc-20050325/ . Последняя версия доступна на http://www.w3.org/TR/rdf-dawg-uc/ .
[UNISEC]
Размышления о безопасности Unicode, Марк Дэвис, Майкл Сьюигнард
[VCARD]
Представление объектов vCard в RDF/XML, Ренато Яннелла, заметка W3C, 22 февраля 2001, http://www.w3.org/TR/2001/NOTE-vcard-rdf-20010222/ . Последняя версия. Последняя версия доступна на http://www.w3.org/TR/vcard-rdf .
[WEBARCH]
Архитектур World Wide Web, том первый, И. Якобс, Н. Вольш, редакторы, рекомендация W3C, 15 декабря 2004, http://www.w3.org/TR/2004/REC-webarch-20041215/. Последняя версия доступна на http://www.w3.org/TR/webarch/ .
[UNIID]
Идентификатор и синтаксис шаблонов 4.1.0,Марк Дэвис, Приложение №31 к стандарту Unicode, 25 марта 2005, http://www.unicode.org/reports/tr31/tr31-5.html . . Последняя версия доступна на http://www.unicode.org/reports/tr31/ .
[SPARQL-sem-05]
Реляционная алгебра для SPARQL, Ричард Сайгэник, 2005
[SPARQL-sem-06]
Семантиака SPARQL, Джордж Перес, Марчело Аренас и Клаудио Гутиеррес, 2006

F. Благодарности (Информативный)

Язык запросов SPARQL для RDF — это разработка рабочей группы W3C по доступу к RDF-данным. Наши благодарности за обсуждения, комментарии и рецензии всем текущим и бывшим членам.

Кроме того, получены комментарии и проведены дискуссии со многими людьми, перечень которых приведен в списке комментариев рабочей группы. Все комментарии направлены на улучшение документа. Энди хотел бы особенно поблагодарить Джорджа Переса, Джеффа Чеппелла, Боба Мак-Грегора, Еси Шарфа и Ричарда Ньюмана за исследование специфических вопросов, связанных со SPARQL. Эрик хотел бы поблагодарить Бьерна Хермана за бесценную помощь.

Лог изменений

Это краткое изложение внесенных в документ изменений с момента публикации возможной рекомендации 14 июня 2007:

Этот документ является неофициальным переводом исходной английской версии. Может содержать неточности и ошибки.
©  PhD Щербак Сергей, 2009. Комментарии к переводу оставляйте здесь!|| На главную || Перепечатка? Valid HTML 4.01 Transitional Valid CSS!