Именованные графы и объединенные конечные точки SPARQL - PullRequest
Новая
       71

Именованные графы и объединенные конечные точки SPARQL

4 голосов
/ 18 февраля 2011

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

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

С учетом следующего запроса: 

SELECT ?something
FROM NAMED <http://www.vw.co.uk/models/used>
FROM NAMED <http://www.autotrader.co.uk/cars/used>
WHERE {
    ...
}

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

  1. Проверьте, существует ли указанный граф локально

  2. Если он не выполнит следующую операцию (в случае вышеупомянутого запроса я буду использовать второй именованный граф)

    GET / sparql /? Query = EncodedQuery HTTP / 1.1 Ведущий: www.autotrader.co.uk Пользователь-агент: my-sparql-client / 0.1

Если EncodedQuery включает только второй именованный граф в предложении FROM NAMED, а в предложение WHERE внесены соответствующие изменения в отношении предложений GRAPH (например, если используется GRAPH <http://www.vw.co.uk/models/used> {...}).

Только если он не может выполнить вышеуказанное , выполните любое из следующих действий: 

GET /cars/used HTTP/1.1
Host: www.autotrader.co.uk

или 

LOAD <http://www.autotrader.co.uk/cars/used>
  1. Вернуть соответствующие результаты поиска.

Очевидно, могут быть некоторые дополнительные соображения относительно OFFSET и LIMIT '

Я также помню, как читал где-то давно в далекой галактике, что граф по умолчанию любой конечной точки SPARQL должен быть именованным графом в соответствии со следующим соглашением:

Для: http://www.vw.co.uk/sparql/ должен быть именованный граф: http://www.vw.co.uk, представляющий граф по умолчанию, и поэтому с помощью приведенной выше логики уже должно быть возможно объединить конечные точки SPARQL с использованием именованных графов.

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

1 Ответ

1 голос
/ 26 октября 2017

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

Например, у вас может быть два источника данных, каждый из которых указывает, что ?movie has-rating ?x, и вы можете захотеть узнать, какой источник указывает какой рейтинг, в этом случае вы можете использовать два именованных графика, связанных с двумя источниками (например, http://www.example.com/rotten-tomatoes и http://www.example.com/imdb). Если вы храните оба набора данных в одном и том же тройном хранилище, возможно, вы захотите использовать NG, а удаленные конечные точки - это другое. Кроме того, URL именованного графа можно использовать со словарями, такими как VoID , чтобы описать набор данных в целом (например, имя набора данных, откуда и когда импортируются тройки, кто является сопровождающим, пользовательская лицензия). Это еще одна причина для разделения вашего тройного магазина на NG.

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

Более того, реальная проблема в федеративных запросах состоит в том, чтобы предлагать прозрачные для конечных точек запросы, делая механизм запросов достаточно умным для анализа запроса и понимания, как его разбить и выполнять частичные запросы на правильных конечных точках (а затем объединить результаты, эффективным способом). В настоящее время проводится много исследований, один из наиболее значимых результатов (насколько мне известно) - FedX , который был использован для реализации нескольких оптимизаций распределения запросов ( пример ).

Последнее, что нужно добавить, я смутно помню соглашение, которое вы упоминаете о $ url, $ url / sparql. Существует несколько подходов (например, LOD cloud ). Тем не менее, в большинстве современных тройных хранилищ (например, Virtuoso) запросы, которые не указывают именованный граф (не используют GRAPH), работают не так, как в случае графа по умолчанию, они фактически запрашивают объединение всех именованные графы в хранилище, что обычно гораздо полезнее (когда вы не знаете, где что-то указано, или хотите интегрировать кросс-графические данные).

...