[Proposal] OI Wiki Semantic Label for Paragraph

[sshwy]

概述

目前 OI Wiki 内容在各位好心人的贡献下已经涵盖大部分板块的内容，但不可否认，内容的质量参差不齐。这是贡献门槛低导致的必然结果。目前我们采用的是贡献者提交 pr，管理员审核的形式。但管理员的审核标准各不相同，贡献者的语言风格也千差万别，导致很多时候页面的组织没有逻辑统一。尽管有好心人会自发对页面进行格式统一化的工作，但终究难逃咕咕的结果，并且在 refactor 的过程中会掺杂贡献者本人的主观考量。不难想象，以后可能又有好心人把曾经 refactor 过的页面再按照自己习惯的逻辑结构再来 refactor。虽然OI Wiki的确是主要靠好心人发电走到今天，但我还是不得不说，我们需要减少无效贡献。这是这个提案的初衷。

每个人的阅读习惯是不同的，有人喜欢硬干精确的数学符号定义，有人喜欢循序渐进式的情景引入，有人不喜欢大篇公式符号，有人不喜欢大篇啰嗦文字。因此为了迎合大部分人的需求，很多时候我们会往一个算法的描述中加入许多解释，例题，拓展等。这也就导致了文章结构的破坏。如果想要重组逻辑，不可避免地要删去一些内容，但这又会带来争议，或者被后来的好心人再加回来。如何在不过度提高的贡献门槛也不“得罪”参与贡献的好心人的同时完成 Wiki 质量的提升？

既然线性的、系统性的逻辑结构难以维护，那么我们可以打破线性，打破系统性。OI Wiki 的每一篇文章本质上是一篇说明文，涉及到的表述方式无外乎说明文的表达方式。而读者的阅读习惯可以理解为对表达方式的偏好。那么我们就给段落标记对应的表达方式，让每个段落的作用变得确定——也就是“语义化段落”。这样一来就可以基于段落的标记实现页面内容的个性化调整，以更好地迎合多样化的需求。同时语义化段落既可以规范贡献内容，又不会给贡献者带来较大的制约，也可以更好地帮助管理员理解贡献者的内容，提出更客观的建议，减少无效贡献。

举例

接下来我以 快速傅里叶变换 为例分析一下页面中常见的表达方式。

文章以“本文将介绍一种算法”开头，到整个“概述”部分完，讲的是 FFT 的背景，显然是一个引入（Introduction）。

接下来是多项式的表示，首先以相对通俗的语言定义了系数表示法和点值表示法（Definition）。

接下来出现了一个“为什么用 n + 1 个点就能唯一地表示这个函数”。看起来它在解释上述两种定义的合理性，或者说正确性。但一个定义是无所谓合不合理的，比如许多抽象的数学定义就不能理喻。因此更确切地说，这个部分其实是上述两个定义的前置条件，原本的逻辑顺序是，先理解了“用 n + 1 个点就能唯一地表示这个函数”，再去看这两个定义。而本质上这个前置条件是一个定理（Theory），其中也包含了定理的证明（Proof）。

接下来“通俗地说”这一段看起来是在上述两个定义的基础上对FFT的解释。但实际上它是FFT在本文中的定义，因为文中找不到其他更标准的定义了。

然后进入单位复根章节。首先做了一个引入，然后下了单位复根的定义，然后用 $n=4$ 的单位复根作为例子来辅助说明，这部分是对定义的解释（Explanation）。

接下来描述了单位复根的性质（Property），其实质上是关于单位复根的定理。

然后就是 FFT 的算法描述。这部分的语义比较复杂。首先它不是解释，因为 FFT 的算法有很多种，算法不等于对一个定义的解释。它也不是定义，因为 FFT 我们已经定义过了。如果我们给这一段的标题换成“Cooley-Tukey Algorithm”，那么这一段可以理解为该算法的定义。但实际上说是定义也不确切，看到“定义”，我们潜意识里会想是一个关于对象的抽象表达，但算法的本质更接近于过程，而不是对象。因此我们就将它划分为过程（Procedure），代表一类段落间有较强逻辑关联的过程性描述。不过考虑到 OI Wiki 的绝大多数过程性描述都是算法，也可以考虑 Algorithm 作为关键字。

后面的代码实现是 OI 领域说明文特色，那么就标记为实现（Implementation）。甚至可以不做显示标记，自动将代码块标记为实现。

然后是一个关于时间复杂度的段落，同样是 OI 领域说明文特色，似乎很多人倾向于把时间复杂度的描述单独成段。这里又比较复杂，可以有多种理解。有的算法时间复杂度不显然，作者花了篇幅去证明时间复杂度，那么这样的段落就是证明。由此观之，对时间复杂度的说明似乎该理解为定理，因为只有定理才需要证明。但总感觉这样理解显得别扭，就好像描述了一个定理却不给证明（虽然证明显然，但是就连“证明显然”这样的字眼也没有）。如果理解为 Cooley-Tukey 算法本身的性质，似乎稍微可以接受，因为看到性质我们潜意识里会认为是对象的属性，是客观存在的事实。不过如果将这一段的内容改为“从代码中可以看出，本算法的复杂度为 O(nlogn)”，那么我们就可以简单理解为对算法的一个解释，或者说附注。

接下来是关于“位逆序置换”的内容，是关于算法的优化。首先做了位逆序置换的引入和定义，并给出第一种实现，然后描述更优的位逆序算法过程，给出第二种实现。

接下来是逆变换的内容，里面出现了典型的证明段落。

最后是一个关于 NTT 的引入，或者说拓展延伸。

总结

总结一下，FFT 页面中出现了以下的表达方式：

• Introduction
• Definition
• Theory/Property
• Proof
• Explanation
• Implementation
• Procedure/Algorithm

而这只是粗略的语义划分。例如有的 Explanation 与定义的联系较为紧密，有的则只是一个附注，可以忽略。而有的段落具有多重语义。并且我们发现有的文章需要调整段落顺序和文章结构以适应上述语义化段落系统。Procedure 里可能嵌套有 Explanation，或者说一个段落里开头是过程性描述，后面紧跟了对其的解释。

有了这个系统，我们可以做什么？

管理员的工作量可以降低，贡献者的内容会变得规范，这是最直接的。

我们可以按语义折叠内容了！例如可以提供“折叠所有证明”的选项，让页面更简洁。

我们可以按语义替换内容了！比如我们可以发展 definition.brief、definition.detailed 语义标签。按照用户的偏好设置选择展示简洁的符号定义还是易于理解的通俗定义，或者提供选项卡，任意切换。这样某种程度上我们也可以允许不同语言风格的描述同时存在，尽量保留好心人的贡献。

我们可以制定相应的规范了！在没有语义化标签以前，其实文章的组织规范是很难制定的，稍不注意就会拉高贡献门槛。但是有了标签，就提供了一个台阶。对于没有写标签的贡献，我们可以先让贡献者完善语义标签（这个工作并不复杂，只受制于贡献者写作水平）。而在完善标签之后就可以接入相应的规范。因为标签一定程度固化了段落的作用，而且一般是贡献者自己加的，因此可以减少众说纷纭的情况，让大家大体都在同一个理解层面上。至于有的人觉得这个算法复杂度不需要证明，有的人觉得算法描述过于啰嗦，在施加了相应标签之后，也就没有讨论的意义了。

以上是我不成熟的想法，提出来希望大家提提建议，从实用性、实现难度或者规则本身的细化角度等等都可以。在得到一致认可前肯定不会开工（目前也没时间开工）。

注：本提案暂不涉及标签语法的实现具体方案，以及前端的表现形式/新功能，重点落在将段落的作用固定化所带来的门槛和好处。

[ouuan]

关于这个 RFC 有更多讨论吗？这个 issue 怎么是空的 🤔

[codewasp942]

资瓷，这样阅读体验会好很多，可以把 #1037 的 reference 也整合进来，让页面更加整齐

[Great-designer]

注：这个例子已经不太合适了。按照现在的情形看来，单位复根和NTT不太适合出现在FFT页面。