我正在尝试查询DBPedia以获取与本体中给定类相关的属性列表,但由于人类可读的“标签”并不总是清晰,我还想提供一个示例来自数据库。问题是,虽然我想选择所有不同的属性,但我只想要每个属性的一个例子。 Here's我的查询如何在不捕获示例的情况下查看:
SELECT DISTINCT ?prop ?title WHERE {
?thing ?prop [].
?thing a <http://dbpedia.org/ontology/Currency>.
?prop rdf:type rdf:Property.
?prop rdfs:label ?title.
} ORDER BY DESC(COUNT(DISTINCT ?thing))
LIMIT 100
如果我在this way中更改它,我会开始为?prop:
获取重复值SELECT DISTINCT ?prop ?title ?example WHERE {
?thing ?prop ?example.
?thing a <http://dbpedia.org/ontology/Currency>.
?prop rdf:type rdf:Property.
?prop rdfs:label ?title.
} ORDER BY DESC(COUNT(DISTINCT ?thing))
LIMIT 100
我一般都非常习惯使用SPARQL和数据库查询,因此我不清楚如何执行此操作。理想情况下,我有类似DISTINCT(?prop)?title?example的内容,它为prop选择每个唯一值,并返回其标题和示例。
答案 0 :(得分:8)
在您的第二个查询中,distinct应用于?prop
?title
和?example
的值组合。因此,您没有获得任何重复项,例如在第二个查询中获得的以下两行:
dbpedia2:subunitName "subunit name "@en "cent"@en
dbpedia2:subunitName "subunit name "@en "centavo"@en
它们不重复,因为第三行?example
有两个不同的值"cent"@en
和"centavo"@en
解决此问题的一种可行方法是使用GROUP BY
和MIN
来获得?label
和?example
的最低排名值,即:
SELECT ?prop MIN(?title) MIN(?example) WHERE {
?thing ?prop ?example.
?thing a <http://dbpedia.org/ontology/Currency>.
?prop rdf:type rdf:Property.
?prop rdfs:label ?title.
} GROUP BY ?prop
答案 1 :(得分:4)
以下是使用子查询实现所需内容的另一种方法:
SELECT ?prop ?title ?example
WHERE
{
?thing a <http://dbpedia.org/ontology/Currency>.
?prop rdf:type rdf:Property.
{ SELECT ?title ?example WHERE { ?thing ?prop ?example . ?prop rdfs:label ?title. } LIMIT 1 }
}
LIMIT 100
这样做的优点是符合SPARQL 1.1标准,正如我在评论中所述,标准不允许通过聚合进行排序,因此您使用的是特定于供应商的扩展,这将限制查询的可移植性。
如果您确实希望以跨越SPARQL 1.1实现的方式通过聚合值进行排序,那么您必须首先对其进行预测:
SELECT ?s (COUNT(?p) AS ?predicates) WHERE
{
?s ?p ?o
} GROUP BY ?s ORDER BY DESC(?predicates)
答案 2 :(得分:1)
如果您不在乎示例,但在乎速度,那么SAMPLE
可能比GROUP BY
快很多
SELECT ?prop (SAMPLE(?title) AS ?title) (SAMPLE(?example) AS ?example)
WHERE {
?thing ?prop ?example.
?thing a <http://dbpedia.org/ontology/Currency>.
?prop rdf:type rdf:Property.
?prop rdfs:label ?title.
} LIMIT 100
由于dbpedia缓存查询结果,因此您可能不会注意到dbpedia的区别,但是我注意到使用其他端点时有很大的区别。
我在创建查询多个sparql端点的自动完成服务时遇到了同一个问题。我需要找到一个与搜索词相关的链接,该链接本身并不是很重要,但是查询的速度非常很重要。