#sparql #wikidata
#sparql #викиданные
Вопрос:
У меня есть ряд простых, но исчерпывающих запросов SPARQL. Их выполнение против общедоступной конечной точки SPARQL викиданных приводит к тайм-аутам. Настройка локального экземпляра викиданных была бы серьезной инвестицией, не стоящей этого времени. Итак, я начал с простого решения:
- Я использую конечную точку SPARQL WikiData для изучения данных, настройки запроса и оценки его результатов. Я использую ОГРАНИЧЕНИЕ 100, чтобы избежать тайм-аутов
- Как только я настроил свой запрос, я перевожу его вручную в набор серий запросов путей JSON, фильтров Python и т. Д. чтобы запустить их через мой локальный дамп викиданных.
- Я запускаю их локально. Для последовательной обработки всего дампа требуется время, но это работает.
Второй шаг подвержен ошибкам и отнимает много времени. Существует ли автоматическое решение, которое может выполнять запросы SPARQL (или, скорее, подмножество SPARQL) через локальный дамп без настройки базы данных?
Мои запросы SPARQL довольно просты: они извлекают сущности на основе их свойств и значений. Я не строю большие графики, я не использую никаких транзитивных свойств.
Комментарии:
1. как второй шаг должен быть быстрее без базы данных? Я имею в виду, что действительно загрузка дампа JSON и затем выполнение запросов будут работать. Но для каждого запроса весь файл должен быть отсканирован или нет? Цель баз данных и даже MongoDB или чего-то еще для дампа JSON — использовать индексацию для последующего запроса. Даже если ваш запрос работает с одной строкой в дампе JSON, которая фактически описывает один объект Викиданных, вам все равно придется пройти через весь файл.
2. что вы могли бы сделать, так это взглянуть на некоторые существующие подходы к обработке викиданных, например github.com/usc-isi-i2/kgtk — Хотя я не могу сказать так много об этом инструменте
3. Действительно, вы также можете делать что угодно с помощью bash-скрипта и некоторого инструмента json. Как описано здесь: lucaswerkmeister.de/posts/2017/09/03/wikidata dgsh
4. @UninformedUser Я не сказал, что t будет быстрее. Я имею в виду тайм-ауты возврата общедоступных конечных точек в случае исчерпывающих запросов, чтобы избежать DDOS-атак и таких пользователей, как я. Общедоступные конечные точки больше предназначены для изучения викиданных, а не для получения из них всех данных.
5. это правда. Я имел в виду, что загрузка его в базу данных в конечном итоге может быть более эффективной, в зависимости от сложности вашего запроса, наверняка будет учитывая, что подход, на который я ссылался, выполнялся
jq
только в одной строке, что означает единый объект. Но на самом деле вы знаете свою рабочую нагрузку лучше меня, и да, загрузка викиданных занимает много времени — я делал это несколько раз.