Почему этот федеративный запрос SPARQL работает в TopBraid, но не в Apache Fuseki?

Обновленный (более простой) ответ

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

service <ex1> { ... }
service <ex2> { ... }

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

service <ex1> { values ?a { 1 2 3 } }
service <ex2> { values ?a { 2 3 4 } }

будет выполняться, и у вас будет два возможных значения для ? a во внешнем запросе (2 и 3). В вашем запросе вторая служба не может дать никаких результатов. Если взять:

?s ?p ?o .
FILTER(regex(str(?s), replace(?actorName, " ", "_"))) .

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

Оригинальный ответ

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

select * {
  { select ?x { ?x a :Cat } }
  ?x foaf:name ?name
}

Сначала найдет всех кошек, а затем найдет их имена. «Возможные» значения для? X сначала определяются подзапросом, а затем эти значения для? X становятся доступными для внешнего запроса. Теперь, когда есть два подзапроса, например,

select * {
  { select ?x { ?x a :Cat } }
  { select ?x ?name { ?x foaf:name ?name } }
}

первый подзапрос найдет всех кошек. Второй подзапрос находит все имена всего, что имеет имя, а затем во внешнем запросе результаты объединяются, чтобы получить только имена кошек. Значения? X из первого подзапроса недоступны во время выполнения второго подзапроса. (По крайней мере, в принципе, оптимизатор запросов может определить, что некоторые вещи следует ограничивать.)

Насколько я понимаю, блоки службы имеют такую ​​же семантику. В вашем запросе у вас есть:

SERVICE <http://data.linkedmdb.org/sparql> {
    <http://data.linkedmdb.org/resource/film/1> movie:actor ?actor .
    ?actor movie:actor_name ?actorName .
}
SERVICE <http://dbpedia.org/sparql?timeout=30000> {
    ?s ?p ?o .
    FILTER(regex(str(?s), replace(?actorName, " ", "_"))) .
}

Вы говорите, что трассировка показывает, что TopBraid выполняет

SELECT  *
WHERE
  { ?s ?p ?o
    FILTER regex(str(?s), replace("Paul Reubens", " ", "_"))
  }

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

Причина, по которой он, вероятно, «не работает» в Йене, заключается в том, что второй запрос на самом деле не связывает какие-либо переменные, поэтому в значительной степени необходимо просмотреть каждую тройку в данных, что, очевидно, это займет много времени.

Я думаю, что вы можете обойти это, вложив вызовы службы. Если все вложенные службы запускаются «локальной» конечной точкой (т. Е. Вложенный вызов службы не просит удаленную конечную точку выполнить другой удаленный запрос), то вы можете быть в состоянии сделать:

SERVICE <http://dbpedia.org/sparql?timeout=30000> {
    SERVICE <http://data.linkedmdb.org/sparql> {
      <http://data.linkedmdb.org/resource/film/1> movie:actor ?actor .
      ?actor movie:actor_name ?actorName .
    }
    ?s ?p ?o .
    FILTER(regex(str(?s), replace(?actorName, " ", "_"))) .
}

Это может дать вам ту оптимизацию, которую вы хотите, но все же кажется, что это может не сработать, если у DBpedia нет эффективных способов выяснить, какие тройки нужно получить, на основе вычисления replace < / сильный>. Вы просите DBpedia просмотреть все свои тройки, а затем сохранить те, в которых строковая форма темы соответствует определенному регулярному выражению. Вероятно, было бы лучше создать этот IRI вручную в подзапросе, а затем искать его. Т.е.,

SERVICE <http://dbpedia.org/sparql?timeout=30000> {
  { select ?actor {
      SERVICE <http://data.linkedmdb.org/sparql> {
        <http://data.linkedmdb.org/resource/film/1> movie:actor ?actor . 
        ?actor movie:actor_name ?actorName .
      }
      bind(iri(concat("http://dbpedia.org/resource",
                      replace(?actorName," ","_")))
           as ?actor)
    } } 
  ?actor ?p ?o 
}