Jena/ARQ: разница между моделью, графикой и набором данных

Я начинаю работать с Jena Engine, и я думаю, что я понял, что такое семантика. Однако я с трудом понимаю различные способы представления кучки троек в Jena и ARQ:

Первое, на что вы натыкаетесь при запуске, - Model, а в документации указано имя Jenas для графиков RDF.
Однако существует также Graph, который, казалось, был необходимым инструментом, когда я хочу запросить объединение моделей, однако, похоже, он не имеет общего интерфейса с Model, хотя можно получить Graph из Model
Тогда в ARQ есть DataSet, который также представляет собой набор троек некоторого рода.

Конечно, афер, оглядывающийся в API, нашел способы как-то конвертировать из одного в другой. Однако я подозреваю, что для него есть более чем 3 разных интерфейса.

Итак, вопрос в том, каковы ключевые отличия в дизайне этих трех? Когда следует использовать какой? Особенно: когда я хочу держать отдельные пучки троек, но запрашиваю их как одну большую группу (объединение), какую из этих структур данных я должен использовать (и почему)? Кроме того, я "теряю" что-либо, когда "конвертирует" из одного в другое (например, model.getGraph() содержит меньше информации каким-то образом, чем Model)?

Ответ 1

Jena делится на API, для разработчиков приложений и SPI для системных разработчиков, таких как люди, создающие механизмы хранения, аргументы и т.д.

DataSet, Model, Statement, Resource и Literal являются интерфейсами API и обеспечивают множество возможностей для разработчиков приложений.

DataSetGraph, Graph, Triple, Node являются интерфейсами SPI. Они довольно спартанцы и просты в реализации (как вы надеетесь, если вам нужно реализовать вещи).

Широкий спектр операций API полностью разрешает вызовы SPI. Чтобы привести пример, Model interface имеет четыре разных метода contains. Внутри каждого из них вызывается вызов:

Graph#contains(Node, Node, Node)

таких как

graph.contains(nodeS, nodeP, nodeO); // model.contains(s, p, o) or model.contains(statement)
graph.contains(nodeS, nodeP, Node.ANY); // model.contains(s, p)

Что касается вашего вопроса об утрате информации, Model и Graph вы не (насколько я помню). Более интересным является Resource по сравнению с Node. Resources знать, к какой модели они принадлежат, поэтому вы можете (в api) написать resource.addProperty(...), который в конце концов станет Graph#add. Node не имеет такого удобства и не связано с конкретным Graph. Следовательно, Resource#asNode является убыточным.

Наконец:

Когда я хочу держать отдельные пучки троек, но запрашиваю их как одну большую связку (объединение), какую из этих структур данных я должен использовать (и почему)?

Вы явно обычный пользователь, поэтому вам нужен API. Вы хотите сохранить тройки, поэтому используйте Model. Теперь вы хотите запросить модели как один союз: вы могли:

Model#union() все, что скопирует все троек в новую модель.
ModelFactory.createUnion() все, что создаст динамический союз (т.е. нет копирования).
Сохраните ваши модели в качестве названных моделей в хранилище данных TDB или SDB и используйте опцию unionDefaultGraph.

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

Ответ 2

Короткий ответ: Model - это просто оболочка без апатии с множеством удобных методов вокруг Graph. ModelFactory.createModelForGraph(Graph) обертывает граф в модели. Model.getGraph() получает завернутый граф.

Большинство прикладных программистов будут использовать Model. Лично я предпочитаю использовать Graph, потому что это проще. У меня возникли проблемы с запоминанием всех трещин в классе Model.

Dataset представляет собой набор из нескольких Model s: одна "модель по умолчанию" и ноль или более "именованных моделей". Это соответствует понятию "набора данных RDF" в SPARQL. (Технически говоря, SPARQL не является языком запросов для "графиков RDF", а для "наборов данных RDF", которые могут быть наборами названных графиков RDF плюс график по умолчанию.)