没有LIMIT子句,SPARQL查询将不起作用 [英] SPARQL queries doesn't works without LIMIT clause

查看:172
本文介绍了没有LIMIT子句,SPARQL查询将不起作用的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

当我在诺贝尔奖数据库中执行此语句时,避免使用 LIMIT 子句。

When I execute this sentence in the nobel prize database I got error when I avoid use LIMIT clause.

下一个查询有效,因为它具有 LIMIT 子句:

The next query works, because it has the LIMIT clause:

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX nobel: <http://data.nobelprize.org/terms/>
PREFIX cat: <http://data.nobelprize.org/resource/category/>
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX dbo: <http://dbpedia.org/ontology/>
PREFIX dbp: <http://dbpedia.org/property/>
PREFIX dbr: <http://dbpedia.org/resource/>
PREFIX owl: <http://www.w3.org/2002/07/owl#>

SELECT DISTINCT ?parentName ?childName 
WHERE {
  ?child owl:sameAs ?personChild ;
      foaf:name ?childName .

  SERVICE <http://dbpedia.org/sparql> {
    { ?personParent dbp:children ?personChild .  }
    UNION
    { ?personChild dbp:parents ?personParent . }
  }

  ?parent owl:sameAs ?personParent ;
      foaf:name ?parentName .
} LIMIT 2

这很奇怪,因为当我删除该查询时,相同的查询不起作用 LIMIT 子句,而不是结果,我得到下一条错误消息:

It's bizarre because the same query doesn't works when I remove the LIMIT clause and instead of the result I got the next error message:

错误500:HTTP 400错误的查询:错误的请求

此行为的原因是什么?我做错了吗?

What is the reason of this behavior? Am I doing something wrong?

谢谢。

推荐答案

我有将三元组的一小部分从您的Fuseki 1加载到我的Fuseki 2中,并分析了网络日志。

I have loaded small part of triples from your Fuseki 1 into my Fuseki 2 and have analyzed network logs.

执行您的查询后,Fuseki(或ARQ)向DBpedia发送许多有关这种类型(实际上,前缀会扩展):

Executing your query, Fuseki (or rather ARQ) sends to DBpedia many queries of this kind (actually, prefixes are expanded):

SELECT  *
WHERE
  {   { ?personParent dbp:children  viaf:58991016 }
    UNION
      { viaf:58991016 dbp:parents  ?personParent }
  }

突然,Fuseki发送以下查询:

Suddenly, Fuseki sends this query:

SELECT  *
WHERE
  {   { ?personParent  dbp:children  <Barack Obama> }
    UNION
      { <Barack Obama>  dbp:parents  ?personParent }
  }

上面查询中的这个奇怪的URI无效。您可以自己检查,在此页面

This strange URI in the query above is not valid. You can check this yourself, clicking "Barack Obama" on this page.

Virtuoso返回错误,Fuseki停止执行。

Virtuoso returns an error and Fuseki stops execution.

如果不省略 LIMIT 子句,那么幸运的是,Fuseki从DBpedia中检索到足够数量的结果(并且在没有错误的情况下停止执行)在发送错误的上述查询之前。

If the LIMIT clause is not omitted, then, having some luck, Fuseki retrieves from DBpedia sufficient number of results (and stops execution without an error) before sending the erroneous above query.

我建议为您的查询添加一些过滤条件:

I suggest to add some filtering conditions to your query:

PREFIX afn: <http://jena.hpl.hp.com/ARQ/function#>

SELECT DISTINCT ?parentName ?childName 
WHERE {
  ?child owl:sameAs ?personChild ;
      foaf:name ?childName .
  FILTER (afn:namespace(?personChild) = str(dbpedia:))

  SERVICE <http://dbpedia.org/sparql> {
    { ?personParent dbpprop:children ?personChild .  }
    UNION
    { ?personChild dbpprop:parents ?personParent . }
    FILTER (isIRI(?personParent))
  }

  ?parent owl:sameAs ?personParent ;
      foaf:name ?parentName .
}

运行它!

结果应为:

+-------------------------------+----------------------+
|          parentName           |      childName       |
+-------------------------------+----------------------+
| "Marie Curie, née Sklodowska" | "Irène Joliot-Curie" |
| "Pierre Curie"                | "Irène Joliot-Curie" |
| "Karl Manne Georg Siegbahn"   | "Kai M. Siegbahn"    |
+-------------------------------+----------------------+

在上面的查询中:


  • PREFIX afn:< http://jena.hpl.hp.com/ARQ/function#> afn:前缀声明

FILTER(afn:namespace(?personChild)= str(dbpedia :)) —过滤出不正确的URI(以及非DBpedia URI,从而减少了查询数量);

FILTER (afn:namespace(?personChild) = str(dbpedia:)) — filters out incorrect URIs (and also non-DBpedia URIs, reducing the number of queries);

FILTER(isIRI(?personParent)) —过滤掉偶尔出现的属性文字值,从而略微减小了DBpedia的响应大小。

FILTER (isIRI(?personParent)) — filters out occasional literal values of properties, reducing slightly DBpedia response size.

现在我明白了,为什么不直接使用有关Nobel奖的DBpedia数据。 DBpedia数据质量的Scylla和Virtuoso的Charybdis的7个错误之间的最短路径似乎是:

Now I understand, why you do not use DBpedia data about Nobel awards directly. The shortest path between Scylla of DBpedia data quality and Charybdis of Virtuoso 7 bugs seems to be the following:

SELECT DISTINCT ?dbpediaChild ?dbpediaParent {
    VALUES (?award2) { (dbr:Nobel_Prize_in_Chemistry)
                       (dbr:Nobel_Prize_in_Physics)
                       (dbr:Nobel_Peace_Prize)
                       (dbr:Nobel_Prize_in_Physiology_or_Medicine)
                       (dbr:Nobel_Prize_in_Literature) }
    VALUES (?award1) { (dbr:Nobel_Prize_in_Chemistry)
                       (dbr:Nobel_Prize_in_Physics)
                       (dbr:Nobel_Peace_Prize)
                       (dbr:Nobel_Prize_in_Physiology_or_Medicine)
                       (dbr:Nobel_Prize_in_Literature) }
    ?award1 a dbo:Award .
    ?award2 a dbo:Award .
    ?dbpediaChild  dbo:award/(dbo:wikiPageRedirects*)  ?award1 .
    ?dbpediaParent dbo:award/(dbo:wikiPageRedirects*)  ?award2 .
    ?dbpediaChild dbp:parents|^dbp:children ?dbpediaParent .
}

运行它!

但是,结果只会是:

+-------------------------+--------------------+
|      dbpediaChild       |   dbpediaParent    |
+-------------------------+--------------------+
| dbr:Kai_Siegbahn        | dbr:Manne_Siegbahn |
| dbr:Irène_Joliot-Curie  | dbr:Marie_Curie    |
+-------------------------+--------------------+

这篇关于没有LIMIT子句,SPARQL查询将不起作用的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆