关联数据和端点
为什么终点对查询的最终结果如此重要。
对于此查询：
SELECT ?episode,?chalkboard_gag WHERE {
?episode skos:subject
http://dbpedia.org/resource/Category:The_Simpsons_episodes%2C_season_12.
?episode dbpedia2:blackboard ?chalkboard_gag
}
"http://dbpedia.org/snorql" ("http://dbpedia.org/sparql", i am using jena also) produces 4 results, which is the correct, since only 4 of the episodes have blackboard information created.
Why the diferences?
Why does the end point matters so much to the end results of the query.
For this query:
SELECT ?episode,?chalkboard_gag WHERE {
?episode skos:subject
http://dbpedia.org/resource/Category:The_Simpsons_episodes%2C_season_12.
?episode dbpedia2:blackboard ?chalkboard_gag
}
The endpoint "OpenLink Virtuoso SPARQL protocol" returns 1 result.
"http://dbpedia.org/snorql" ("http://dbpedia.org/sparql", i am using jena also) produces 4 results, which is the correct, since only 4 of the episodes have blackboard information created.
Why the diferences?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
对于第一个端点，您的意思是 http://lod.openlinksw.com/sparql 吗？我没有看到它和 http://dbpedia.org/sparql 之间的不同结果。例如，这个查询在您的查询上扩展，似乎从两个端点返回相同的内容（如果它们确实是不同的服务器；我无法告诉）。
我知道会产生不同结果的一件事是查询超时。 Virtuoso 可以在查询运行一定时间后切断查询，并且当您尝试查询时，不同的端点可能处于不同的负载下，和/或配置了不同的超时。
顺便说一句，我注意到，如果此数据位于 Needle 中，并在 Thread 而不是 SPARQL 中查询，则此查询可以简单如下：
除了在 Needle 中，您可能实际上会像电视节目一样对电视节目进行建模，而不是依赖于通用 SKOS 主题/更广泛的抽象级别，因此实际上可能具有：
For the first endpoint, do you mean http://lod.openlinksw.com/sparql? I'm not seeing different results between that and http://dbpedia.org/sparql. For example, this query, expanding on yours, seems to return the same stuff from both endpoints (if indeed they're actually different servers; I can't tell).
The one thing I know of that would produce different results would be query timeouts. Virtuoso can cut off queries after they've been running for a certain amount of time, and your different endpoints might have been under different loads when you tried them, and/or configured with different timeouts.
I note, parenthetically, that if this data were in Needle, and queried in Thread instead of SPARQL, this query could be as simple as:
Except in Needle you'd probably actually model TV shows like TV shows, rather than relying on levels of generic SKOS subject/broader abstractions, and thus might actually have: