То, что вы здесь делаете, - это обновляет объект графа в памяти, который содержит копию содержимого вашей онтологии, которую вы изначально извлекли из http://localhost:8080/webdav/elearning
.Эта копия отличается от документа, размещенного на сервере приложений, расположенном на порте 8080, поэтому неудивительно, что вы не видите изменений в исходном документе, размещенном на сервере приложений.
Существует четыре основных способа.Вы можете сделать следующее:
Вместо обычного веб-сервера (такого как Tomcat или Jetty) у вас есть RDF-специфичный сервер данных, такой как Fuseki .Затем, при правильной настройке, он сможет отвечать на запросы обновления SPARQL напрямую - вместо того, чтобы копировать документ в локальный график, вы обновляете график in-situ .
Вы можете сделать то, что делаете сейчас, а затем, когда вы закончите обновлять график, вы можете организовать HTTP POST для обновления графика обратно на сервер приложений через порт 8080. Для этого потребуется настроить маршрут дляобновление (например, http://localhost:8080/webdav/elearning/update
) и подходящий обработчик, но это вполне выполнимо.
Вместо того, чтобы обращаться к вашей онтологии с веб-URL, вы могли бы вместо этого получить доступ к файлу в вашей файловой системе.Опять же, однако, как только вы закончите обновление, вам придется сохранить содержимое обновленного графика обратно в файловую систему.
Вместо доступа к вашей онтологии с веб-URL, вы могли бывместо этого загрузите его в постоянное хранилище, такое как TDB .При таком подходе вы открываете Jena Dataset
, который подключается напрямую к магазину, и запускаете запросы и обновления SPARQL для этого.Нет необходимости сохранять что-либо отдельно: все обновления будут идти непосредственно в экземпляр TDB.
В исходном примере используется Pellet в качестве механизма рассуждения.Если это важно для вашего приложения, то для эффективности вам действительно нужна копия данных в памяти.Таким образом, второе и третье решения, приведенные выше, будут более подходящими, чем другие.