#geolocation #sparql #endpoint #dbpedia #geo
#геолокация #sparql #конечная точка #dbpedia #гео
Вопрос:
У меня есть онтология OWL с довольно большим количеством мест: города, нации, штаты, районы и конкретные сайты, такие как бизнес или церковь. Я хочу использовать SPARQL для запроса некоторого внешнего источника данных (я предполагаю, что конечная точка SPARQL), найти подходящее место и скопировать данные long и lat в мою онтологию. Моя онтология имеет дело с пандемией Covid и называется CODO. Итак, я пробовал такие вещи, как:
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX codo: <http://www.isibang.ac.in/ns/codo#>
PREFIX geo: <http://www.w3.org/2003/01/geo/wgs84_pos#>
PREFIX dbo: <http://live.dbpedia.org/>
INSERT {?c codo:long ?long.
?c codo:lat ?lat.}
WHERE {?c a codo:City.
?c rdfs:label ?l.
?dbpc a dbo:City.
?dbpc rdfs:label ?l.
?dbpc geo:long ?long.
?dbpc geo:lat ?lat.}
Я получил эти конкретные пространства имен из примеров, которые я нашел в Интернете. У меня нет предпочтений относительно того, где я получаю данные, геонимы, DBpedia, не имеет значения. Я думаю, что часть проблемы заключается в том, что я не совсем понимаю, когда / как использовать сервис и / или ИЗ ключевых слов.
Комментарии:
1. для удаленных конечных точек вы всегда используете
SERVICE
ключевое слово.FROM
в основном используется для добавления графиков к графику по умолчанию, используемому при оценке запроса.SERVICE
Ключевое слово просто переносит нужный вам шаблон графика из удаленной конечной точки, напримерconstruct {?c geo:long ?long ; geo:lat ?lat } where {?c a codo:City ; rdfs:label ?l. SERVICE <http://dbpedia.org/sparql> {?s a dbo:City; rdfs:label ?l ; geo:lat ?lat ; geo:long ?long}}
, — дляINSERT
запроса он работает так же2. — обратите внимание, реализация
SERVICE
предложения иногда расплывчата, т. Е. Неясно, встроены ли данные из «внешнего» запроса или нет, но это, очевидно, необходимо, чтобы избежать получения всех данных и выполнения соединения локально. Например, с помощью Apache Jena if будет выполняться один удаленный запрос на локальную привязку. Просто имейте это в виду, удаленная служба может быть заблокирована, если слишком много запросов происходит за короткое время с одного и того же IP-адреса.3. Альтернативой вашей задаче может быть i) просто загрузить данные DBpedia lat / long или ii) написать запрос, в который вы загружаете только данные для ваших местных городов, т. Е.
CONSTRUCT{?l geo:long ?long ; geo:lat ?lat.} WHERE {VALUES ?l {"city1label" "city2label" ... "citynlabel"} ?c a dbo:City ; rdfs:label ?l ; geo:long ?long ; geo:lat ?lat.}
— это приведет к одному возможному большому запросу, но должно быть более эффективным (не забывайте языковые теги при сравнении меток!)4. @UninformedUser Большое спасибо за предложения. Это помогает. Мне нравится идея просто загрузить данные DBpedia, но я бы предпочел не загружать данные для наших городов, потому что, если я правильно понимаю ваше предложение, это означает перечисление каждого города (также штата, района, нации и т. Д.), И у нас их много, и мы будем добавлять еще больше по мере расширения нашей работыза пределами Индии.
5. Я понимаю. Хорошо, тогда вам следует использовать федеративные запросы через
SERVICE
ключевое слово.CONSTRUCT
Запрос в моем первом комментарии — это всего лишь набросок, но, по крайней мере, он работает — протестировал его с помощью Apache Jena из командной строки и некоторых фиктивных данных.
Ответ №1:
Я разобрался с проблемой. С помощью механизма запросов, который я использую (Gruff в Allegrograph от Franz Inc.), мне даже не нужно использовать ключевое слово SERVICE, все, что мне нужно сделать, это подключиться к конечной точке, используя один из параметров файла в Gruff. Я уже делал это, но я использовал неправильный IRI для мест в DBpedia. Теперь работает следующее:
PREFIX dbo: <http://dbpedia.org/ontology/>
PREFIX geo: <http://www.w3.org/2003/01/geo/wgs84_pos#>
SELECT ?City ?long ?lat where {?City a dbo:City; geo:lat ?lat ; geo:long ?long}
limit 200
Теперь, когда это работает, должно быть проще связать места в нашей онтологии и скопировать необходимые данные. Спасибо UninformedUser и моему коллеге Biswanath_Dutta за то, что помогли мне разобраться в этом.