Альтернативы запросу SPARQL с большим количеством UNION

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

Мой запрос построен программно и выглядит так:

SELECT DISTINCT ?graph (count(DISTINCT ?match) as ?matches)
WHERE {
  GRAPH ?graph {
    {?match rdf:label "term 1"} 
     UNION {?match rdf:label "term 2"} 
     UNION {?match rdf:label "term 3"}
     ...
  }
}
ORDER BY DESC(?matches)

Каждый термин становится еще одним предложением UNION.

Есть лучший способ сделать это? Запрос быстро становится длинным и уродливым, и Virtuoso жалуется, когда терминов слишком много.


person heyitsbmo    schedule 23.02.2013    source источник


Ответы (3)


(это rdfs:метка)

Альтернативный способ записи:

{ ?match rdfs:label ?X . FILTER (?x in ("term 1", "term 2", "term 3")) }

или (SPARQL 1.0)

{ ?match rdfs:label ?X . FILTER ( ?x = "term 1" || ?x = "term 2" || ?x = "term 3" )  }
person AndyS    schedule 23.02.2013
comment
Альтернативой является использование новых VALUES SPARQL 1.1. Не уверен, что это было доступно при ответе, но, возможно, стоит обновить ответ. - person Nick Bartlett; 26.11.2013

В SPARQL 1.1 есть значения. пункт, который может помочь в этом. Это позволяет вам писать:

select ?match where {
  values ?label { "term 1" "term 2" "term 3" }
  ?match rdfs:label ?label
}
person Joshua Taylor    schedule 20.02.2015
comment
Это решение также быстрее, чем FILTER. Например, в Викиданных VALUES в 15 раз быстрее. Хотя количество возвращаемых строк отличается на несколько процентов. - person Anton Tarasenko; 24.05.2020

Решение со значениями является еще более мощным, поскольку оно позволяет использовать UNDEF следующим образом (например):

VALUES (?s ?p ?o) { (<http://abc#X> <http://abc#P1> UNDEF)
                    (UNDEF <http://abc#P2> <http://abc#Y>) }

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

person Hubert Schumacher    schedule 20.11.2016