问题标签 [blazegraph]

我已经将披萨本体加载到 Stardog 和 Blazegraph 中，以及我编写的一些三元组，包括一个有四个配料的披萨。正如@AKSW 建议的那样，我试图使浇头与众不同。

比萨本体将有趣的比萨定义为具有至少三种配料的比萨。我很确定我启用了 OWL 推理，但Triplestore 都没有说我的披萨很有趣。

任何人都可以向我展示在任何免费提供的三元存储中启用此推断的设置，或者指出我的三元存储做错了什么吗？特别是，我是否应该能够推断出披萨实例、披萨类或两者都是“有趣的”？

有趣的披萨定义：

我的额外三倍：

查询有关具有五种不同浇头的披萨实例的任何知识：

Stardog 的结果 （我手动将完整的 URI 替换为前缀 URI）：

Stardog推断我的披萨有配料（因为它有配料），我的披萨是一种食物，甚至我的披萨也很辣，因为它有马克的墨西哥胡椒作为配料。但它并没有推断出有趣的比萨课的成员资格。

这是我的 Stardog 推理设置：

Blazegraph 是否支持迭代大型查询结果集？例如，给定一个 200GB 的 Blazegraph 数据库，不断运行多个入站更新程序，是否可以运行可能返回几 GB 数据的复杂 SPARQL 查询？

我使用此处的说明创建了 wikidata api 的本地版本，并且我想指定自定义超时以覆盖官方 api中的 60 秒超时。我没有找到任何东西RWStore.properties，但也许我错过了一些东西。

我想在 rdf 数据库（Blazegraph）中存储大量整数。这些值需要用新数据更新（增加），或者如果丢失，则创建。在 sparql 1.1 中最好的方法是什么？如果我在 SQL ( MySQL/MariaDB ) 中编写它，假设数据库一开始是空的，并且表的唯一键设置为 "s,p" （主题和谓词），它将是这样的：

生成的 RDF 数据：

下一次运行：

生成的 RDF 数据：

所以问题是 - 如何构建一个 SPARQL 查询来根据现有数据和增量进行批量 UPSERT，并使其高效。

在 SPARQL 中，我可以执行以下查询以检索一个查询结果中的字段和总数：

它返回类似这样的内容（s 字段与我在查询中提供的特定谓词和过滤器匹配）：

我想对全文搜索查询做同样的事情，可以按如下方式使用?s bds:search “something” . 但是，用与前一个相同的结构组成一个查询是行不通的：

即使这些子查询分别返回正确的结果。

我正在尝试使用 blazegraph 工作台的“更新”选项卡将数据插入到 blazegraph 中。下面是一个示例代码片段：

我用@ 符号指定语言标签。但是，它会引发以下异常：

org.openrdf.query.MalformedQueryException：第 8 行第 49 列出现词汇错误。遇到：“u”（117），之后：“_”

似乎它不允许将下划线作为语言标记的一部分。如果尝试仅使用“en”，则效果很好。

为什么呢？下划线是这里的特殊字符吗？如果是这样，有什么办法可以逃脱呢？

使用下载页面中的简单步骤无法在 Windows 10 上运行Blazegraph（Java RDF 三重存储） 。

我有一台安装了 Java JDK 9 的 Windows 10 机器（请参阅下面的版本检查）。我下载了最新的 Blazegraph 可执行 jar，然后运行“java -server -Xmx4g -jar blazegraph.jar”。它报告 NullPointerException，如下所示。如果有帮助，下面的错误引用StandaloneNanoSparqlServer.java:142，github显示为"System.setProperty("jetty.home", jettyXml.getClass().getResource("/war").toExternalForm());".

Windows 管理员 CMD 提示符下的命令/响应：

我正在使用相对较小的有向图（~10 个节点），每个有~10,000 个简单的路径和循环。我想维护一个总成本的排序列表，以遍历所有这些简单的路径和周期。我的边有几个不同的权重，但聚合函数对于所有这些都是可交换的/关联的（例如总和和乘积）。

现在，我正在使用 rethinkdb（一个 nosql 数据库）和 python。我正在预先计算所有可能的简单路径，将它们存储在哈希图中，并且每次更新边缘权重时，只需蛮力重新计算遍历就会花费它们。我的哈希图将给定的边（其权重刚刚更新）指向它所属的所有简单路径和循环。然后我去重新计算每一个的遍历成本。

好吧，我发现这非常慢并且无法扩展！我知道这是一个难题，但希望它适用于我相对较小的图表。

我最初的方法的一个低效率似乎在于每条路径的浪费冗余计算，即使有些是彼此的聚合。例如，A→B→C→D→E 的成本是 A→B→C 和 C→D→E 的组合。那么为什么不巧妙地计算它们呢？我想出了一种方法来做到这一点，但它似乎没有一点帮助，这让我觉得我真的需要退后一步。

所以我上网搜索了一下，偶然发现了这篇很有帮助的文章： https ://blog.blazegraph.com/?p=628 。它说：

大图反模式是“将所有内容放入大图中，然后使用为我们提供水平缩放以解决其他问题的相同工具：map/reduce 和键值存储。”</p>

令我震惊的是，这正是我一直在做的（错误的）。

似乎 GPU 是文章中提到的内存带宽问题的正确解决方案......除了我不确定如何并行处理这个问题。

问题：

1. 如何并行处理这个问题？收集-应用-分散是正确的方向吗？以前在哪里做过？

2. 我如何在不并行的情况下有效地优化当前方法？

作为参考，这是我当前算法的草图：

1. 枚举我的图表中的所有简单路径和循环

2. 保留边缘及其权重的字典。例如，如果('A','B') 是从节点A到节点的边B，

   /li>

3. 保留每条边所涉及的所有简单路径和循环的字典，例如：

   /li>

4. 此外，初始化路径字典及其成本：

   /li>

5. 更新边缘时：

   一世。更新其权重edges_weights

   ii. 查找包含这条边的所有简单路径并更新它们：

   /li>

显然有很多嵌套循环和查找正在发生......但我正在努力了解如何以不同的方式做事。

运行以下命令时出现此错误：

见https://github.com/wikimedia/wikidata-query-rdf/blob/master/docs/getting-started.md

我已经按照此处的说明在本地安装了 wikidata 和 blazegraph：https ://github.com/wikimedia/wikidata-query-rdf/blob/master/docs/getting-started.md

.munge 在 data/split 中为我提供 424 个文件为“wikidump-000000001.ttl.gz”

当我尝试在 blazegraph 上加载一个文件时，出现错误：

错误：uri=[file:/mnt/d/thomas/wikidata/dist/target/service-0.2.1/data/split/wikidump-000000001.ttl.gz], context-uri=[] java.util.concurrent .ExecutionException: org.openrdf.rio.RDFParseException: 此处应为 RDF 值，找到 '' [第 1 行]