Wikidata/Technical proposal/zh-hans

Other languages:

维基数据Wikidata项目旨在创建一个同样可供人类和机器读取和编辑的,关于世界的自由知识库。 它将采用维基媒体项目的所有语言来提供数据,并且允许采用像维基共享资源对待多媒体文件那样方式来集中存取数据。

维基数据目前已被建议作为一个由维基媒体主持和维护的项目。本文档重点关注的是该项目启动和发展所必需的初期开发工作,并将对长期的结果加以论述。

本文档提出的是一种分三阶段走的方法:

  • 第一阶段(跨维基链接)的内容是为维基媒体项目创建一个实体库(entity base)。这将为当前的跨语言链接系统提供一种届时将已经链接到维基百科当中的备选手段。
  • 第二阶段(信息框)旨在为某个实体子集采集第一手与信息框相关的数据,并且其明确的目标就是利用来自data.wikimedia.org的数据对当前广泛采用的信息框予以增强。
  • 第三阶段(列表)是初期开发工作的最后一个阶段,旨在对那些信息框相关属性之外的那套属性加以扩充,并且提供若干用于在维基媒体项目内外对这些数据加以利用的方式。

后续小节将对每个阶段加以详细论述:这些小节将首先对相应的阶段加以概述;接着将描述特定阶段所需实现的技术需求以及相应的原因; 将确定特定阶段在技术、组织以及社区三个方面的主要挑战; 将定义每个阶段所要经过的里程碑; 将明确列出此项目将不会去做的事情以及原因; 将列出根据项目决策而所希望的,可予以添加的可选需求。

分为三个阶段并不意味着,将会只有三次代码部署或者说版本更新。反而,我们将遵循“早发布,勤发布”的信条,以便使我们能够对用户反馈做出迅捷的反映,并对该系统加以持续改进。

第一阶段:跨维基链接 edit

在第一阶段当中,将会在最终的地址上启动Wikidata。 该维基站点将为维基百科语言版本之一当中的某篇文章所描述的每个实体分别提供一个页面。该页面将包含下列信息:

  • 指向描述特定页面相应实体的,不同语言版本之中的那些相应文章的链接。每个维基百科仅可包含一篇此类文章。
  • 每个此类实体的标签以及简短描述。每种所支持的语言均备有一个标签和简短描述。
  • 每个实体的别名。在每个所支持的语言当中,每个实体可拥有若干别名。

数据将采用不同的格式进行导出,尤其是采用RDF、SKOS以及JSON。 Wikidata还将提供一个用于编辑内容的应用编程接口(API)。 维基源代码(wiki source text)将不会像文本那样可以直接加以编辑,而是只能借助于“Add source”(添加来源/引用信息)或“Remove label”(删除标签)专用的API调用来编辑。Wikidata将为Wikidata API提供一个或多个用户界面。Wikidata并不提供维基文章的全文,而仅仅是其数据内容,因此我们在此并不需要完整的维基文本处理能力。将会采用一种更为健全的语法对数据页面加以重新定义,并且把JSON确定为最为看好的候选格式。 此外,将会采用适合于结构化数据的存储后端来直接存储信息。从长远来看,我们将调查研究是否可以彻底摒弃基于文本的存储。

此项目将实现一项要在各个维基百科当中使用的MediaWiki扩展,从而允许这些维基百科就跨维基链接来查询Wikidata,而不是去使用本地定义的跨维基链接。 这将需要一种能够依据维基百科的需求进行伸缩的后端,并且将需要认真考虑如何去处理高速缓存,即在每个维基百科之中,或者是在Wikidata之上,还是在两者之中。

技术需求与基本原理 edit

本阶段需要实现下列需求:

  • P1.1. 对MediaWiki加以扩展,从而允许有别于MediaWiki维基语法的内容类型,尤其是JSON,以便为内部用途而对数据加以序列化。这允许继续使用维基媒体基金会技术背景下所使用的那些基于MediaWiki的工具,尤其是对于那些服务的备份、恢复和维护。这项需求还包括对JSON格式内容进行解析并将其保存到P1.2所提供的后端。
  • P1.2. 实施一种用于存储数据的后端。请注意,尽管标准的基于SMW的后端可用于建立原型,但部署工作将需要若干新的,适合于第一阶段所采集的那种数据的实施。
  • P1.3. 定义和实现用于数据编辑与存取的Wikidata API。该API需要备以足够的文档,以便第三方可以依据其文档来构建应用程序。请注意,这并不是第一阶段所期望实现的。关于Wikidata API究竟可能是什么样子,Shortipedia则提供了一个可行的范例。
  • P1.4. 实现和测试基于Wikidata API之上的用户界面。请注意,这些用户界面全都实现了全面的国际化以及部分的本地化。这项工作将通过与致力于本地化的Translatewiki进行合作来完成。用户界面需要能够运行在维基百科所能运行的所有浏览器之上。用户界面需要便于获得。这些用户界面应当考虑到实体重命名、合并以及拆分的需要。Wikidata网站应当提供下列用户界面:
    • 一种无需JavaScript即可运行的,简单的HTML前端。
    • 一种适合于现代浏览器的,基于HTML5和JavaScript的富客户端。
  • P1.5. 实现一种针对用于Wikidata而进行优化的差异比较算法以及相应的呈现程序(渲染程序/输出程序)。一种差异比较机制如果基于采用所选JSON格式的每个实体的序列化,尽管这并没有错,但我们可以利用这种数据格式的语义并且提供智能得多的差异比较机制。
  • P1.6. 实现一种API以及一种可复用的控件(widget),从而允许从实体库这种选择一个实体。该控件应当允许在有用的情况下提供自动完成功能,并且还可以无缝地在移动设备上工作。在Freebase suggest和Shortipedia实体选择器那里可以见到类似的控件。
  • P1.7. 实现一项MediaWiki扩展,可就相关的跨维基链接对Wikidata加以查询,并且可将这些链接显示在相应的文章页面上。为了不破坏跨维基链接当前的使用,并且处理某些奇特问题(peculiarities)和特殊情况,可采用某一魔术字(magic word)来决定特定文章究竟是采用当前本地定义的跨维基链接还是采用新的全局定义的跨维基链接。显示形式当中还包含一个编辑链接,允许在Wikidata之上直接编辑跨维基数据。
  • P1.8. 实现、安装设置并测试一种合适的,能够在不牺牲跨维基链接之中新鲜程度的情况下,依据维基百科的请求数量进行伸缩的高速缓存机制以及数据流基础结构。

里程碑 edit

建立起了用于采用全局型跨维基链接取代本地型跨维基链接的基础结构,并且若干的维基百科版本也在使用相应的扩展,从而允许其编者利用某个魔术字以及基于Wikidata的系统来替换本地型跨维基链接。Wikidata已在其最终的URL上启动。

这将显著减少维基百科当中跨维基链接方面的维护工作负担,并且提供一个由维基媒体来支持的实体数据库。请注意,此里程碑并不具阻碍性,因为在Wikidata本身启动之前即可开始第二阶段。

本项目所不为 edit

此项目并不打算在启动第一阶段的时候造就大量的编辑。反而,我们期望的是一个小型的乐于表达意见的群体。 因此,目前维基百科社区范围内的广泛关注还没有什么意义。

本项目也不会自动创建文章之间的对应关系(alignments),也不会自动从各维基百科上采集它们。 这属于是社区的工作。社区早已非常积极地在利用机器人(bots)来对应跨维基链接,而为了让他们的机器人框架也能与Wikidata进行无缝的协作配合,我们将为他们提供帮助。本项目的目标并不是提供内容,而仅仅是提供技术基础结构,以便社区能够创建所期望的内容。

针对第一阶段的可选扩展 edit

  • O1.1. 某第三方依据Wikidata API的文档开发出一个用户界面。该用户界面表明Wikidata API文档是足够的,而且可以在Wikidata之上建立诸多的界面。
  • O1.2. 提供一种外部跨维基链接工具,让编者能够在其中轻松地进行那些对应关系。该系统可从各维基百科上收集跨维基链接,检查它们的对应关系情况,提供一种用于简单地删除具体文章之中的跨维基链接界面,采用相应的魔术字取代它们,并且为Wikidata添加这些链接。尽管编辑是自动完成的,但每次的编辑仍需编者人工来启动。
  • O1.3. 对系统加以扩展,以便存储指向其他数据集合的外部标识符,如Linked Open Data Cloud URIs、ISBNs、IMDB标识符、Eurostat标识符、UN标准、PID等等。预计这将显著增加来自第三方数据提供方的支持。
  • O1.4. [依赖于O1.3] 提供一种外部工具,用于查找那些可自动通过O1.3加以保存的对应关系。实际的对应关系需要编者人工加以确认。

第二阶段:信息框 edit

在第二阶段当中,能够利用事实(属性/取值对)及其来源和其他的限定成分(qualifiers),来充实Wikidata之中的实体。事实要么是实体之间的具型链接(typed links),要么是具有具型取值(typed values)的属性-取值对。

实体库之中备有相应的标签,因而可以采用多语言的方式来促进实体之间的联系。 这也将增强命名实体以及创建那些没有直接相应维基百科文章的实体的动力【从而将超越现行的关注度规则(notability rules),且需要新的关注度规则】。

实体页面这时能够包含关于该实体的任意信息,对新建的用户自定义属性加以实例化。 每项事实均可采用一条引用信息来加以实例化,从而降低争论的概率,而这一点在多语言环境下可能会存在问题。 将采用不同的格式,尤其是RDF和JSON,对数据进行完整的导出。 Wikidata还将会提供一种用于编辑扩充内容的API。 本项目将实现一个旨在各个维基百科之中使用的MediaWiki扩展,从而允许编者利用来自Wikidata的数据充实信息框模板。 高速缓存事项与第一阶段相同,因而在本阶段当中,我们可以全力集中关注新的,关于创建一种增强语法(augmentation syntax)的主要技术挑战,而这种语法则可以应对Wikidata的多样性和能力。

技术需求与基本原理 edit

第二阶段需要实现下列需求:

  • P2.1. 对Semantic MediaWiki的类型体系加以定制,以便其适合于Wikidata。其中包括为带有计量单位的取值提供线性转换(linear transformation)支持(此类取值需要一定的精度,否则转换可能会过于精确)以及为取值提供国际化支持的能力。一些基础数据类型并不适合于线性转换(如时间、空间、温度以及货币),必须对它们加以正确的实施。
  • P2.2. 开发并实现一个允许为事实添加来源以及其他限定成分的系统。来源远不止是URL(就像在Shortipedia当中那样),但同时也允许离线来源、来源的结构描述(在Wikidata本身之中)以及如果现成可用的话,还有支持某个来源的实际文本片段(text snippet)。
  • P2.3. 为来自信息框的数据选择和建立一种后端存储。应当在同时考虑P3.2的情况下来完成这项需求,但并不将其作为一项需求。可能的情况就是,基准评估(benchmarking)导致拥有两个不同的系统,分别针对的是第二阶段当中的文档式存取(document-like access)以及第三阶段当中的基于图形的查询(graph-based querying)。
  • P2.4. 对Wikidata API加以扩展,以允许编辑自定义属性,尤其是来源。应当对这些方面加以充分的描述,以便让外部的第三方能够在Wikidata的基础之上开发用户界面,尤其是可选需求之中所描述的游戏式界面(game-like interfaces)。
  • P2.5. 开发并实现那些用于编辑和浏览Wikidata的用户界面。所需的这些用户界面乃是P1.4之中所开发的那些工件的延续,并且将采用P1.6之中所开发的控件。
  • P2.6. 实现采用相关格式,尤其是JSON和RDF,导出数据的功能。同时,要保证除该维基站点的XML转储外,整个数据集还有采用RDF和JSON格式的及时转储。某些类型,如时间、带有计量单位的取值等等,还将需要一些进一步的规范。
  • P2.7. 开发并实现一种MediaWiki扩展,从而允许在MediaWiki型站点之中,尤其是在维基百科里的信息框模板当中,使用来自Wikidata的数据。这需要考虑在特定的维基百科条目当中覆盖Wikidata取值以及依据来源进行优先次序排定和筛选的可能性该扩展还允许为那些在特定语言当中没有文章的实体创建信息框小作品(stub infoboxes)。 这方面必须考虑到来自维基百科方面的保护及保护传播的问题(另见O2.5)。

里程碑 edit

维基百科允许其编者利用来自Wikidata的数据充实信息框。 这将提高各个维基百科上的一致性,并且为小型语言版本的维基百科提供有用的小作品。 这将会大幅度减轻维基百科维护工作的负担。 这将能够在小型语言版本之中为许多实体显示来自Wikidata的数据,即使是它们一篇文章也没有。

本项目所不为 edit

本项目将不会自动利用从其他来源所提取的知识或者其他来源所提供的知识来充填数据。 关于决定究竟选择哪些来源以及如何导入数据,乃是社区的事情。

我们所创建的系统并不会像比如Shortipedia所做的那样,去自动发现、集成以及上载来自数据网(Web of Data)的链式开放数据(Linked Open Data)。 我们并不会提供针对外部词表或本体的自动映射或者去使用内部推理引擎。 我们也不会提供用于上载各种数据源的接口/界面。 Wikidata基于API的系统架构将允许此类接口/界面的轻松创建,而我们也期望此类接口/界面的创建,但预选和支持某些数据源并不是本项目的任务;不过,无论何时,只要我们实现适用于任何具体数据格式的导入功能时,必然会这么做。 本项目并不会定义那些可用的属性以及社区用于决定究竟要采用哪些属性的过程。 本项目本身并不会承担提供针对数据网(Web of Data)的映射的工作。 但是,本项目将会为他人构建这些映射提供一种基础结构。

针对第二阶段的可选扩展 edit

  • O2.1. 为事实和来源提供一种用于收集自动建议/提示的基础结构。机器人、学习系统及知识提取工具等均可提出此类建议/提示。此类建议/提示并未获得人类编者的确认,因而应当将其与那些已通过检查的事实分离开来。提供一种简单的用户界面,让人类编者确认或拒绝所提取出来的事实。
  • O2.2. [依赖于O2.1] 为数据和来源的检查创建游戏式界面(game like interfaces)和激励机制(incentives schemes),支持不经意式百科编纂(casual encyclopeding)。
  • O2.3. [依赖于O2.1] 对某个自动化知识提取系统加以扩展,以便其可将自己的数据直接加载到O2.1当中。可将此项作为一项挑战/难题加以组织。
  • O2.4. 依据关于所正在充填的属性和实体【如它们的领域(domain)和范围(range)】以及所正在编辑的实际实体等等的进一步的信息,对P1.6当中所开发的自动完成控件加以改进。
  • O2.5. 添加一种粒度更为细腻的,用于保护具体事实而不仅是整个实体的方法。
  • O2.6. 导出关于Wikidata之中事实的信任(trust)和出处(provenance)信息。目前,尚未制定相关的标准,因而在开展这项工作的时候,应当密切关于W3C出处工作组(W3C Provenance WG)。
  • O2.7. 开发一个导出程序,用于提供向特定RDF词表或者是向特定JSON投射形式(JSON projection)的实时转换(on-the-fly transformation)。
  • O2.8. 一个针对移动设备而加以优化的用户界面。移动设备提出了若干特殊的挑战。O1.1之中的用户界面将会在外部加以部署,而这种移动设备用户界面实际上将成为Wikidata的组成部分。
  • O2.9. 为特定领域开发一个丰富而又具有吸引力的用户界面,比如,关于2012年伦敦奥运会的。

第三阶段:列表 edit

就像最初所提出的那样,语义维基百科(Semantic Wikipedia)已经在第二阶段当中得到实现。 第三阶段允许提出更加复杂的查询,这些查询可以提供关于数据的聚合视图(aggregate views),并且可以进一步显著减轻维基百科的维护负担。第三阶段还允许此项目的正确完成,以便保证软件和数据及其周边过程高度的可维护性。 第三阶段将会密切监视属性的任意创建及其对系统性能的影响,并且密切关注那些查询数据的新的可能性的使用问题。而这则为利用嵌入式查询提供了一种可伸缩的的方式。嵌入式查询乃是Semantic MediaWiki最为引人且有用的功能特色之一。

技术需求与基本原理 edit

第三阶段将允许利用Wikidata创建列表和聚合视图(aggregated views)。

  • P3.1. 开发并实现一种可在特定维基站点之中查询Wikidata并呈现查询结果的扩展。此项扩展采取两种方式对当前的SMW查询加以扩展:首先,它允许查询另一个知识库;第二,它可处理Wikidata之中的多样性,即一个实体-属性对拥有几个合格取值(qualified values,有效取值)的可能性。此前,在本项目内部,已经解决了这两个问题(尤其是在P1.8P2.7当中)。请注意,查询语言的表现力可能会非常弱。
  • P3.2. 选择并建立一种后端,从而允许高效地执行P3.1之中所建立的那些查询。密切监视这些查询的性能并对它们的表现力加以重复(iterate on their expressivity)在其他阶段当中,这项任务将已经开始评价可加以采用的那些可能的实现形式。对于Wikidata之中的不同用途,尤其是对于信息框的增强以及列表的生成,可能的情况就是,将会同时采用几个后端。
  • P3.3. 与社区密切合作,为查询结果提供一套相关的格式化程序。尽可能复用来自Semantic Result Formats(语义结果格式)以及Spark的结果。否则,就需要依据来自社区的反馈意见,开发新的格式化程序。将在一个文档详尽的API的基础之上进行这些格式化程序的开发,以便第三方能够添加更多的格式化程序,如列表、图表、地图等等。
  • P3.4. 对当前的修理工具(curation tools)加以扩展和调整,以便其适用于Wikidata。其中包括发现未规定类型的属性、无效的取值、重复的属性以及未注明来源的声明。
  • P3.5. 对代码加以清理,以便可在Wikidata外部使用这些代码。将变更与Semantic MediaWiki重新合并起来,以便保留一个公共的代码库。发布那些为Wikidata所新开发的扩展。

里程碑 edit

维基百科允许其编者集成来自Wikidata的列表。将Wikidata的维护工作移交给维基媒体基金会。

本项目所不为 edit

本项目将不会在提供复杂信任计算方面开展研究与开发工作。所有的数据将均可导出,因而可以由第三方来开发此类机制,而如果在规模上可加以实施的话,则可考虑将来把它们用于Wikidata,但此项目本身并不会提供这些机制。

针对第三阶段的可选扩展 edit

  • O3.1. 开发并准备好通向数据的SPARQL端点。尽管通向数据的SPARQL端点要做到非常完备将很可能是不可能的事情,但我们依然可以提供一个SPARQL端点,且依据后端所支持的表现力,这种端点允许某些模式的查询。
  • O3.2. 开发一个直观而又功能丰富的数据查询编辑器。自动现成可用的是一种简单的基于文本的查询编辑器,而一种可支持智能自动完成,或许还允许用户对数据进行可视化查询的,功能丰富的编辑器,会使得这些知识易于更广泛得多的受众享用。
  • O3.3. [依赖于O3.2] 开发一种工具,允许轻松地将查询从查询编辑器复制到各维基百科,从而允许轻松地对文章加以丰富充实。
  • O3.4. 为Wikidata之中数据的查询以及可能的编辑开发一个移动应用程序。
  • O3.5. 实现一种基于关键词的智能搜索。其中,关键词查询被解释为针对数据的结构化查询,并且将显示查询结果。
  • O3.6. 根据查询及查询结果,自动选择一种合适的可视化形式。

资源 edit

参阅 edit