模式设计与语义约定

2.1 从问题与决策开始

模式设计从系统必须回答的问题，以及答案所支持的决策开始。能力问题是检验模型表达能力的具体问题。例如，研究证据图谱需要回答：“哪些研究支持方法M在数据集D上提高检索质量，这一结论适用于什么条件？”也需要回答：“哪些结论依赖一篇后来被更正的论文？”这些问题要求表达来源、主张、评价、版本和依赖关系，也立即说明为何只包含论文、作者与主题节点的图谱并不充分。

有用的设计讨论可以选择若干真实问题，写出每个答案所需的证据路径，再找出表达这些路径所需的最小概念集合。这能避免两种常见错误：尚未理解任务就导入庞大本体，以及画出方便实现却无法回答关键问题的模式。问题也应覆盖例外：撤回的主张、作者身份未知的记录、使用多个数据集的实验，以及未公开数值得分的结果。

不同利益相关者可能需要同一图谱的不同视图。图书馆员关心书目身份，研究者关心实验能否比较，管理者关心访问与归属。共享核心应包含各方能够达成一致的稳定概念；专门视图可以扩展核心，而不必迫使每位用户接受所有细节。将共同的身份约定与应用特定的呈现选择分开，通常更有利于维护。

2.2 选择正确的表示单位

建模粒度决定哪些对象获得独立身份。研究项目、论文、论文的某一版本，以及该版本中的一个段落，是不同对象。如果更正只改变一个段落，仅识别到论文层级的图谱便无法精确定位变化；若给每个字符都建立永久节点，维护又可能过于昂贵。合适粒度取决于检索和审计要求。段落通常可以存为有来源锚点的文本片段，而不必成为连接密集的领域实体。

一个实用规则是：对象需要独立身份、关系、生命周期或溯源时，就建立节点；某个值自然附属于一个对象，且无需独立连接时，则使用属性。发表日期通常可作为属性。机构通常应作为实体，因为作者、项目、合同和事件都可能指向它。研究方法起初可以只是文本属性，但若反复需要查询其版本、方法家族与评价，将它提升为节点便有充分理由。

事件与带有限定条件的关系尤其需要认真建模。“人物A曾为机构B工作”可能随时间变化。把任职表示为具有起止日期的Employment事件或关联，可以保留多个任职及相互冲突的记录。研究案例中的Evaluation承担类似作用，将属于同一评价的参与对象和条件联系起来。属性图中带多个属性的二元边有时已经足够；显式事件节点则能使这些属性独立建立连接，也更便于跨模型交换。

2.3 先明确身份再确定标签

显示名称变化时，标识符应保持稳定。论文标题不适合作主键，因为可能存在标点差异、更正、译名或重名。经过核验的DOI很有用，但系统还需要为没有DOI的文档提供本地标识。本地标识不应伪装成全球标识；明确命名空间，有助于日后对齐。

身份政策必须同时规定合并与拆分。合并意味着先前分开的记录现在被认为指向同一实体；拆分则撤销错误合并。如果下游边被复制后失去原始来源，拆分就会困难。研究证据图谱保留提及层面的来源，以及从提及到规范实体的版本化映射，因此能够通过修正身份连接处理错误，而不必删除原始文档或抹去出错历史。

名称应支持多语言使用。英文首选标签、中文首选标签、缩写与历史别名，都可能指向同一概念。SKOS提供了概念体系及标签的标准化词汇，包括上位和下位关系[11]。即便采用属性图，也可以借鉴这些区分。不过，应用仍应判断两个标签究竟是同一概念的译名，还是相关但不同概念的名称。翻译上的相似不能单独证明概念等价。

2.4 形式语义与操作验证

RDF Schema提供类、子类关系，以及属性的定义域和值域描述[6]。一个容易忽略的细节是，定义域和值域声明支持类型推断，并不等同于拒绝所有异常值的数据库检查。假如某属性的定义域是Person，而一项陈述对未知类型的主语使用了该属性，RDFS推理器可以推断该主语属于Person。预期系统自动拒绝输入的团队，可能因而得到不同于操作意图的行为。

OWL增加了类限制、属性特征等更丰富的逻辑描述构件。它并不假定名称不同的个体必然不同；许多结论取决于是否明确声明了不等关系[7]。在实现规划中，OWL配置子语言为不同推理需求和计算权衡提供受限制的语言片段[12]。如果选择了表达力很强的语言，却没有相应推理策略，项目可能留下许多实际上没有任何已部署组件执行的声明。

SHACL描述用于验证RDF数据图的约束[8]。例如，应用可以要求每项已接受的Evaluation都具有数据集引用，以及采用合适数据类型的数值得分，验证报告则列出不符合形状定义的记录。这样的验证判断的是记录是否遵守声明的契约，不能证明得分被诚实测量，也不能证明实验设计良好。因此，研究证据图谱将验证状态与科学可信程度分别记录。

在属性图实现中，唯一性约束可以防止标识符重复，更复杂的要求则可由应用逻辑检查。Neo4j文档列出了受版本与产品版本条件限制的多种约束类型[45]。可迁移的设计应先规定必须保持的性质，再明确它由数据库、导入服务、批量审计还是人工审核执行，避免让模式图暗示那些实际只存在于文档注释中的保护措施。

2.5 时间 不确定性与溯源

时间建模区分有效时间与记录时间：前者表示陈述在被建模世界中何时适用，后者表示系统何时记录该信息。假设3月发布的一项更正指出某段任职关系已在1月结束；任职的有效区间从1月改变，而图谱在3月才获知变化。同时保留两类时间，才能分别询问系统在过去某日相信什么，以及现在如何看待同一个过去时期。

不确定主张需要的不只是一个置信度数值。抽取置信度估计系统是否正确理解了来源，来源可靠性涉及陈述的出处，经验不确定性涉及测量或统计结果，另一维度则可能涉及结论能否迁移到新人群。把这些合并成一个没有说明的分数，会破坏有用信息。图谱可以分别存储，并要求应用解释哪些维度影响其决策。

溯源把记录连接到来源、活动与责任主体。PROV-O为实体、活动、行动者及其关系提供词汇[10]。本报告建议实现时记录文档版本、证据片段、抽取运行、模型版本、审核者和接受决策。这些操作性扩展属于设计建议，并非声称PROV-O强制要求所有字段；目的在于让陈述能够在错误实际发生的层级被复现和修正。

2.6 模式演化与治理

当用户发现重要的新区别时，模式就需要变化。项目起初可能把论文之间的全部关系都视为CITES，随后才需要区分SUPPORTS、CRITIQUES、REPLICATES与USES_DATA_FROM。若不重新检查来源就把全部旧引用替换成更细类别，就会制造知识。较好的迁移方式是保留原有宽泛关系，仅在有依据时增加专门关系，并标记哪些记录已按新模式审核。

版本管理应覆盖模式、映射规则、验证形状与查询模板。迁移计划需要解释旧记录如何继续被理解，以及如何测试依赖它们的应用。弃用一种关系不应悄悄改变它的历史含义。团队可以引入新关系，在规定期限内维护兼容视图，并记录语义差异，以保护依赖旧导出文件或缓存分析结果的用户。

模式治理不仅是技术仓库，也是一种决策过程。领域专家判断两个概念是否有实质区别，数据管理员负责身份与溯源政策，工程人员验证约束执行与迁移可行性。在小型个人研究图谱中，一人可以兼任三职，但三类问题依然不同。记录建模选择的理由，可以避免数月后再次重复同样的争论。

最终模式应既小到能够解释清楚，又丰富到足以回答能力问题。可以通过代表性记录、含糊案例与对抗性示例检验质量。审核时应检查：每类节点是否有清晰的身份政策，每种关系是否具有明确方向与含义，每项关键约束是否有执行位置。一旦这些约定稳定，抽取与存储便更容易评价。