Jena / ARQ：模型，图形和数据集之间的差异
我开始使用Jena Engine，我想我已经掌握了语义是什么。 然而，我很难理解在Jena和ARQ中代表一堆三元组的不同方法：
- 你在开始时偶然发现的第一件事就是
Model和文档说明它的RDF图的Jenas名称。 - 然而，当我想查询模型联合时，还有
Graph似乎是必要的工具，但是它似乎没有与Model共享一个公共接口，尽管可以从Model中获取Graph - 然后在ARQ中有
DataSet，它似乎也是某种三元组的集合。
当然，有些人在API中查看，我找到了以某种方式从一个转换为另一个的方法。 但是我怀疑它还有3个不同的界面用于同样的事情。
所以，问题是：这三者之间的关键设计差异是什么？ 我什么时候应该使用哪一个？ 特别是：当我想要保持单个三元组但是将它们视为一大堆（联合）时，我应该使用哪些数据结构（以及为什么）？ 另外，当从一个“转换”到另一个时，我“松散”任何东西（例如， model.getGraph()以某种方式包含的信息少于model ）？
Jena分为用于应用程序开发人员的API和用于系统开发人员的SPI，例如制作存储引擎，reasoners等的人员。
DataSet ， Model ， Statement ， Resource和Literal是API接口，为应用程序开发人员提供了许多便利。
DataSetGraph ， Graph ， Triple ， Node是SPI接口。 它们非常简洁，易于实现（如果你必须实现这些东西，你希望如此）。
各种各样的API操作都可以解析为SPI调用。 举一个例子， Model接口有四种不同的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 #add。 Node没有这样的便利，并且与特定的Graph无关。 因此Resource#asNode是有损的。
最后：
当我想要保持单个三元组但是将它们作为一大堆（联合）查询时，我应该使用哪些数据结构（以及为什么）？
您显然是普通用户，因此您需要API。 你想存储三元组，所以使用Model 。 现在您要将模型作为一个联合查询：您可以：
-
Model#union()所有东西，它将所有三元组复制到一个新模型中。 -
ModelFactory.createUnion()所有东西，它将创建一个动态联合（即没有复制）。 - 将模型存储为TDB或SDB数据集存储中的命名模型，并使用
unionDefaultGraph选项。
最后一个最适合大量模型和大型模型，但设置起来要多一些。
简短回答： Model只是一个无状态包装器，在Graph周围有许多方便的方法。 ModelFactory.createModelForGraph(Graph)将ModelFactory.createModelForGraph(Graph)包装在模型中。 Model.getGraph()获取包装图。
大多数应用程序员都会使用Model 。 我个人更喜欢使用Graph因为它更简单。 我无法记住Model类中的所有内容。
Dataset是几个Model的集合：一个“默认模型”和零个或多个“命名模型”。 这对应于SPARQL中“RDF数据集”的概念。 （从技术上讲，SPARQL不是“RDF图”的查询语言，而是“RDF数据集”，它可以是命名的RDF图的集合加上默认图。）