Определение долготы и широты с помощью SPARQL

#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 за то, что помогли мне разобраться в этом.