Надежно запрашивайте конечные точки sparql и кешируйте результаты локально

  1. Когда мы запрашиваем наборы данных LOD Cloud (используя запросы SPARQL), мы можем столкнуться с проблемами подключения или сервера. Есть ли надежная стратегия, которая поможет нам правильно получать данные даже в таких ситуациях? Я ищу инструмент (в java), который помогает планировать задачи запросов, чтобы при возникновении прерывания задача снова запускалась повторно до получения запрашиваемых данных.
  2. Я использую библиотеку Jena для запроса удаленных конечных точек SPARQL, чтобы получить данные LOD Cloud и использовать их для некоторых вещей. Есть ли механизм для автоматического кеширования возвращаемых данных, чтобы при повторном запросе набора данных с тем же запросом данные извлекались из локального кеша, а не из конечной точки удаленного набора данных?

Я и мой коллега реализовали эти вещи поверх Apache Jena, см. здесь

UninformedUser 10.08.2018 18:55

@AKSW, спасибо. Я уже заглянул в этот репозиторий. Это отличная работа. Однако я думаю, что это еще не конец. Впереди еще есть над чем поработать; Можешь подтвердить ?

Nasreddine 10.08.2018 19:51

Что вы имеете в виду под «незавершенным»? Он периодически обновляется до последней версии Jena. Retry, Caching, Proxy, Delegating и т. д. Уже много лет являются стабильными уровнями.

UninformedUser 13.08.2018 07:32

Я видел несколько TODO в некоторых частях проекта; это то, что мешает мне его использовать.

Nasreddine 13.08.2018 10:02

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

UninformedUser 13.08.2018 11:03

@Nasreddine, вы можете опубликовать ответ самостоятельно, если ссылка на AKSW вам подходит. Этот пример кажется исчерпывающим ...

Stanislav Kralin 20.08.2018 08:46

@StanislavKralin У меня возникли проблемы с приведенным примером. Как только решу, поставлю ответ. Спасибо.

Nasreddine 20.08.2018 09:50
5
7
167
0

Другие вопросы по теме