检索在任意日期之前/之后最后更新的属性答案

【问题标题】：Retrieving properties last updated before/after arbitrary date检索在任意日期之前/之后最后更新的属性
【发布时间】：2020-05-12 20:08:49
【问题描述】：

我对检索 WikiData 项目的属性感兴趣，但前提是在某个日期之前或之后添加或修改了该属性。

所以我有这个SPARQL query，它可以获取 Q24 的所有属性。

SELECT ?itemLabel ?propLabel ?statement_property_objLabel
WHERE {

    VALUES (?item) {(wd:Q24)}

    ?item ?property [?statement_property ?statement_property_obj] .
    ?prop wikibase:claim ?property.
    ?prop wikibase:statementProperty ?statement_property.

    # Call label service.
    SERVICE wikibase:label { bd:serviceParam wikibase:language "en" }

} ORDER BY ?propLabel

现在，我只想保留在< 之前或> 之后任意日期（例如 2017 年 1 月 1 日）修改的那些属性。我知道有一个"last update" property P5017，但我不知道如何使用它与任意日期进行比较。

【问题讨论】：

我很确定 Wikidata SPARQL 端点只包含最新数据，也没有编辑每个语句的日期。去年还发表了一篇研究论文：thomas.pellissier-tanon.fr/papers/2019-ESWC-wikidatahistory.pdf - 您所指的属性 P5017 在 Wikidata 中以某种方式使用（运行select * {?s wdt:P5017 ?o} limit 10），但我认为这不是您想要的，因为这些值是直接附在实体上，而不是声明，甚至日期都是维基数据之前的。显然我可能错了，其他人更清楚。
@UninformedUser 概述的内容是正确的对于 RDF，而不是对于 SPARQL 端点，后者可以利用多种服务，包括 MediaWiki API，它可以根据mediawiki.org/wiki/Wikidata_Query_Service/User_Manual/MWAPI 访问修订信息。如果 OP 只对 Q24 或已知的项目组感兴趣，那么直接使用 MediaWiki API 或使用 SQL 可能会更好，例如通过quarry.wmflabs.org .
@DanielMiechen 我知道有机会通过 SPARQL 使用 MWAPI - 但是，我仍然想知道您如何获得在给定日期之前或之后修改的所有属性@ 987654331@。在这两种情况下，您都必须在 t1 之前或之后获取变更集中所有属性的联合 - 我很高兴学习新事物，尤其是关于 Wikidata，所以如果您可以向我展示 SPARQL 解决方案，我会非常高兴快乐
这是一个 MediaWiki API 调用，它获取所有修订及其各自的内容，然后可以通过特定属性的存在或不存在进行过滤：wikidata.org/w/…。不确定这在多大程度上可以通过 SPARQL 端点获得。

标签： sparql mediawiki wikipedia wikidata

【解决方案1】：

很遗憾，您可能无法使用 SPARQL 做到这一点。 SPARQL 唯一知道的事情是：

a) 使用schema:dateModified 编辑项目的最后日期（这为您提供了一个有效的“不迟于”日期，用于其中的任何声明）；
b) 声明中声明（或暗示）更新时间的任何具体日期。

对于 b)，理论上您可以使用 P813（检索日期信息）。 P5017 是“来源”的修订日期，而不是声明，并且可以是过去很久。

但是，这种方法依赖于存在的这些语句。大多数参考不使用这些 - Q24 只有一个使用 P813 的参考。也不能保证从那时起该声明就没有被编辑过——你可能会假设没有，但没有办法确定。它们不会自动应用或更新。

References 还可能包含 P577（发布日期），可用于推断更新数据 - 如果发布日期为 2020-02-01，则声明可能自 2 月初以来已被编辑，因为不太可能有人会引用未来出版日期的参考资料。但这有点脆弱，除非它恰好与您的测试日期匹配，否则不会非常有用。

在实践中，我认为您需要解析页面历史记录才能确定给定声明的最后编辑时间。几乎所有索赔编辑的编辑摘要都非常标准化，所以这应该是可行的，无需调查每个单独的修订，但也可能需要大量工作......

【讨论】：