【问题标题】:dbpedia sparql query for Deathplace someonedbpedia sparql 查询 Deathplace 某人
【发布时间】:2021-12-02 11:22:52
【问题描述】:

我正在尝试获得死亡之地以获得一种独特的语言。我的查询是这样的,但我有错误...

SELECT ?place ?placeLabel
     WHERE {
         <https://dbpedia.org/page/Alfonso_XII> rdfs:label ?person
         ?place dbo:deathPlace ?person; 
          rdfs:label ?placeLabel.

        FILTER (LANG(?placeLabel) = "en")    
    }

【问题讨论】:

  • 什么错误?你能把这个发布到这个问题中吗?

标签: sparql dbpedia


【解决方案1】:

此查询存在一些问题。

  1. 您使用的是资源的 URL,而不是 URI
  2. 死亡地点将人与地点联系起来,而不是相反。
  3. deathPlace 的正确 URI 前缀是 dbp:
  4. 地点确实应该是资源,但在 DBpedia 中这是一个强有力的假设
  5. 由于您不要求人员级别,因此您在查询中似乎不需要它
SELECT ?place ?placeLabel
     WHERE {
          dbr:Alfonso_XII dbp:deathPlace ?place .
OPTIONAL  {?place rdfs:label ?placeLabel .
                    FILTER (LANG(?placeLabel) = "en") }
    }

【讨论】:

  • 对不起,我把这个作为一个例子,因为我之前确实需要找人,但我不想把所有的事情都做好。就我而言,我想放置一个名为 my_query 的 python 变量,并在 ''' 之后以 uri 结尾。像 " ''' %(uri)。在这种情况下 dbpedia.org/page/Alfonso_XII> 真的是 。
  • @dev2win 没关系,您可以将来自 Ivo 的查询与您的 Python 字符串插值一起使用。尽管如此,URL 仍然是错误的,它是http://dbpedia.org/resource/Alfonso_XII。 IT 总是http 作为协议(不是https),总是/resource/ 作为DBpedia(不是/page/
  • @Ivo :一般来说,应该更喜欢dbo: 前缀而不是dbp,因为这是基于映射的属性命名空间。不幸的是,在当前示例中没有这样的数据,但这也导致dbp: 相关事实不是强类型的,这里只是一个普通的字符串,这很奇怪,因为它使获取附加数据变得更加困难例如关于一个人的死亡地点。我会简单地得到两者并使用coalesce 优先使用基于dbo: 的属性
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2023-03-17
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2013-03-15
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多