有没有办法将 Hibernate Session 读取为 RDF 三元组？
我需要根据 WHERE 子句的相关数据位于链接开放数据云中的条件，查询本地 Hibernate 托管数据存储中的持久对象。
有没有办法将 Hibernate Session 读取为 RDF？ 如果是这样，我至少可以使用组合数据集来决定从 Hibernate 检索哪些对象。
最好的解决方案是将 Hibernate 会话暴露在耶拿内部，因为我很熟悉它。 此外，我还需要 RDFS 推理和 SPARQL 的支持以进行检索。
I need to query my local Hibernate managed datastore for persisted objects based on criteria where the relevant data for the WHERE clause is in the Linked Open Data cloud.
Is there a way to read a Hibernate Session as RDF? If so, I can at least use the combined Dataset to decide what objects to retrieve from Hibernate.
Preferably the solution would expose the Hibernate Session as inside Jena as I'm familiar with it. In addition I'll need support for RDFS inferencing and SPARQL for retrieval.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
由于您将使用 Jena（和 ARQ）来执行 SPARQL 查询，因此您可以使用自定义
FileManager来解析 Hibernate 对象/图形（假设您希望每个对象都由图形表示）。Jena 有一个关于使用
FileManager的简短的 HOWTO定位模型，以及 ARQ RDF 数据集教程（请参阅“描述数据集”部分）可能会给出一些关于如何将图形 URI（以及这些图形的内容作为 RDF 数据集）到现有 Hibernate 管理的数据进行更定制的映射的提示。另一个选择可能是创建一个映射到现有 Hibernate 架构的自定义 SDB 布局 。 我不知道SDB在这方面的灵活性如何。
Since you will be using Jena (and ARQ) to execute your SPARQL query, you could use a custom
FileManagerto resolve the Hibernate objects/graphs (assuming you want each object to be represented by a graph).Jena has a short HOWTO on using a
FileManagerto locate models, and the ARQ RDF dataset tutorial (see the "Describing Datasets" section) may give some hints as to how to do a more customized mapping of graph URIs (and the contents of those graphs as RDF datasets) to your existing Hibernate-managed data.Another option might be creating a custom SDB layout which maps to your existing Hibernate schema. I don't know how flexible SDB is in this regard.
以下是我发布问题后发现的内容：
没有现有的工具可以专门将 Hibernate 会话三重化。 要自己实现一个，我需要实现 Graph< /a> 也许使用 GraphBase作为基础，或者StageGenerator。 因此问题的答案是“没有”，所以我接着考虑如何实现。
我需要决定是否将会话中已有的对象（即已被某些早期查询访问过）三倍化，依赖于访问数据库或两者都进行。 如果要访问数据库，我还需要决定是加载整个对象，然后将其附加到会话，还是使用投影来节省将额外数据引入堆的时间，而代价是额外的往返。
使用 Graph 显然对于支持推理至关重要，尽管它比使用 ARQ 慢 StageGenerator 因为它可以查询一组三元组模式，但这使得必须始终使用 SPARQL，这似乎有点不灵活。
到目前为止，最佳解决方案似乎是：
图表 - 说“HibernateGraph”
Hibernate PersistenceContext 对象
并在 an 的头部返回三元组
自定义迭代器。
使用来自数据库的数据
标准接口。
URI 将 URI 映射到列并使用
紧密投影，否则加载
整个对象并迭代
getter，将 getter 名称映射到
URI。
使用自定义执行的 SPARQL
舞台生成器。
内置于 StageGenerator 中。
对除 a 之外的图的查询
HibernateGraph 的链向上
内置于 StageGenerator 中。
没有优化的
解决方案，例如任何一组模式。
已实现，运行适当的
标准函数并映射
结果逐个细胞变为三倍
前。
还有另一个名为 OpExecutor 的 SPI 可能有助于推送 FILTER解析到数据库中，从而进一步提高性能。
目前我已将其作为一个业余项目，我很可能将其作为 LGPL 软件发布。
Here's what I've found since posting the question:
There is no existing tool to triplify the Hibernate Session specifically. To implement one myself I need to implement Graph perhaps using GraphBase as a basis, or StageGenerator. The answer to the question is therefore "there isn't one", so I went on to consider how to implement it.
I need to decide whether to triplify objects already in the session (i.e. already accessed by some earlier query), rely on accessing the database or do both. If going to the database I also need to decide whether to load whole objects which will then be attached to the session or use projection to save bringing extra data into the heap at the expense of additional round-trips.
Using Graph is apparently essential for supporting inferencing, though its slower than using ARQs StageGenerator since that can query a set of triple patterns, however this makes it essential to always use SPARQL which seems a bit inflexible.
So far, the optimum solution appears to be:
Graph - say "HibernateGraph"
Hibernate PersistenceContext object
and return triples at the head of an
custom iterator.
of data from the database using the
Criteria interfaces.
URI map the URI to a column and use a
tight projection, otherwise load the
whole object and iterate over
getters, mapping the getter name to a
URI.
SPARQL to be performed with a custom
StageGenerator.
built in StageGenerator.
queries on graphs other than a
HibernateGraph up the chain to the
built in StageGenerator.
for which there is no optimised
solution e.g any set of one pattern.
achieved, run the appropriate
Criteria functions and map the
results cell-by-cell to triples as
before.
There is another SPI called OpExecutor which may help to push FILTER resolution into the database, therefore improving performance further.
At the moment I've taken this on as a side project, which I may well release as LGPL software.