Получение сопоставления пустых узлов

В настоящее время моя группа разрабатывает интерфейс «укажи и щелкни» для навигации и извлечения информации из графиков RDF. В рамках этого мы подключаемся к различным конечным точкам тройного хранилища, используя метод sparqlservice от Jena. Чтобы переместить точку, на которую в данный момент смотрит пользователь, пользователь может выбрать узел и сделать его центром. Затем программа выбирает соседей этого узла, используя выражение, показанное ниже:

CONSTRUCT {
<URI> ?p ?o .
?s ?p <URI> .
} WHERE {
{<URI> ?p ?o .}
UNION
{?s ?p <URI> .}
} LIMIT N

Где URI — это узел, который выбрал пользователь (мы делаем что-то немного другое для литералов). Затем это выражение выполняется следующим образом:

Query myQuery = QueryFactory.create(_query);
QueryExecution qexe = QueryExecutionFactory.sparqlService(this.myURL, myQuery);
Model resultModel = qexe.execConstruct();
return resultModel;

Проблема, с которой мы сталкиваемся, связана с пустыми узлами. Когда Jena получает пустой узел от конечной точки, ему немедленно присваивается идентификатор Jena bNode. Этот идентификатор не будет совпадать с идентификатором, представленным конечной точкой, и если пользователь выбирает пустой узел на стороне клиента в качестве нового центра, это, очевидно, вызывает проблемы.

Поэтому мой вопрос: есть ли способ сохранить исходный идентификатор конечной точки в Jena? Просматривая внутренности Jena, я вижу, что несколько классов ResultSet используют класс для обработки сопоставления между идентификаторами конечной точки и Jena, который называется LabelToNodeMap. Есть ли способ получить это сопоставление? Или, в качестве альтернативы, запретите Jena использовать собственную схему идентификаторов и вместо этого используйте конечные точки.


person Elipson    schedule 20.03.2014    source источник


Ответы (1)


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

Во-первых, различные спецификации результатов SPARQL на самом деле не требуют, чтобы хранилища отправляли свои внутренние идентификаторы как пустые идентификаторы узлов. Например, в спецификации SPARQL Results XML говорится следующее:

Примечание. Пустая метка узла I относится к XML-документу набора результатов и не должна иметь никакой связи с пустой меткой узла для этого термина RDF в графе запроса.

И даже с запросами CONSTRUCT ситуация похожая, почти все форматы RDF говорят, что пустая метка узла относится только к документу. Итак, если у меня есть _:id и _:id в двух отдельных запросах, семантически говоря, у меня есть два разных пустых узла.

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

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

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

Обходной путь

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

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

person RobV    schedule 20.03.2014
comment
Расширение запроса в диапазоне, а затем локальная обработка результата будет более дорогостоящей, но должно быть выполнимо. Большое спасибо за ваш подробный пост RobV. - person Elipson; 21.03.2014