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

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

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

Учитывая следующий запрос:

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

or

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

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

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

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

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


sparql semantic-web federated-queries named-graphs
person William Greenly    schedule 18.02.2011    source источник
comment
Именованные графы и федеративные запросы — довольно ортогональные функции. Думайте об именованных графах как о конкретных подмножествах (локальных) троек. Для запросов к удаленным конечным точкам используется ключевое слово SERVICE. Насколько я знаю, Jena Assembler позволяет сопоставлять именованные графы с локальными файлами, и, возможно, другие хранилища триплетов позволяют сопоставлять именованные графы с удаленными тройками, но эти решения зависят от поставщика. Что касается имен по умолчанию для графиков по умолчанию, эта спецификация в настоящее время не содержит что-то в этом роде.   -  person Stanislav Kralin    schedule 15.10.2017
comment
Похоже, что функция, о которой вы говорите, специфична для Virtuoso, см. e. грамм. stackoverflow.com/questions/22409110/   -  person Stanislav Kralin    schedule 21.10.2017

Ответы (1)


arrow_upward
1
arrow_downward

Именованный граф и 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). Тем не менее, в большинстве современных тройных хранилищ (например, Virtuoso) запросы, которые не указывают именованный граф (не используют GRAPH), работают иначе, чем попадая в случай графа по умолчанию, они фактически запрашивают объединение всех именованные графики в хранилище, что обычно гораздо полезнее (когда вы не знаете, где что-то указано, или хотите интегрировать данные кросс-графа).

person zakmck    schedule 26.10.2017