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

Question

Недавно я наткнулся на рабочий проект для расширений федерации 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>

3. Вернуть соответствующие результаты поиска.

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

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

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

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

Answer 1

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

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

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

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

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