3. 机器可读协议的核心元数据
一份机器可读实验协议（Machine-Readable Protocol, MRP）如果只有操作步骤，它仍然只是一段“可被解析的文本”，而不是“可被信任、可被复用、可被追溯”的协议资产。真正让协议具备工程价值的，是包裹在步骤之外的一层结构化元数据。元数据回答的是：这份协议是谁的、是哪个版本、允许谁用、依赖什么、在什么条件下成立、以及它从何而来。本节围绕七类核心元数据展开，说明它们的规范化描述方式与落地写法。
一、七类核心元数据及其作用
在协议工程实践中，元数据可分为“身份类”“权利类”“关系类”“条件类”“历史类”五组。身份类包括标识符与版本；权利类包括作者与许可；关系类包括依赖关系；条件类包括适用条件；历史类包括溯源信息。它们共同构成协议的“可信外壳”。
| 元数据类别 | 字段示例 | 核心作用 | 缺失后果 |
|---|---|---|---|
| 标识符 | protocol_id、DOI、UUID | 全局唯一定位 | 无法引用、无法去重 |
| 版本 | version、revision、date | 区分迭代、支持回滚 | 结果不可复现 |
| 作者 | author、affiliation、ORCID | 责任归属与联系 | 无法追责与协作 |
| 许可 | license、SPDX、usage_scope | 明确使用边界 | 法律与合规风险 |
| 依赖关系 | depends_on、requires | 声明前置协议/资源 | 执行时缺件失败 |
| 适用条件 | applicability、constraints | 界定有效范围 | 误用导致无效结果 |
| 溯源信息 | provenance、derived_from | 记录来源与演化 | 无法审计与复现 |
二、标识符与版本：身份与迭代
标识符应满足“全局唯一、稳定不变、可解析”三个要求。推荐采用分层策略：内部使用 UUID v4 保证唯一性，对外发布时注册 DOI 或使用带命名空间的 URI，例如 urn:mrp:lab-a:proto:cell-viability-001。标识符一旦发布不应随内容修改而改变，内容变化应通过版本字段体现。
版本建议采用语义化版本 MAJOR.MINOR.PATCH：MAJOR 表示不兼容的步骤或参数变更，MINOR 表示向后兼容的新增，PATCH 表示文字或注释修正。同时应记录 version_date 与 changelog，使读者能判断“我手上的版本是否与文献一致”。
三、作者、许可与依赖关系
作者字段不应只写姓名，而应包含机构、角色（如 protocol_author、reviewer）与持久标识（ORCID）。许可字段推荐使用 SPDX 标识符，如 CC-BY-4.0、MIT、CC0-1.0，并补充 usage_scope 说明是否允许商业使用、是否允许修改后再分发。依赖关系需区分“协议依赖”与“资源依赖”：前者指向其他协议标识符及版本约束，后者指向试剂、设备、软件及其版本。
>=1.2.0,<2.0.0，而不是模糊的“最新版”。这样执行器才能在加载时自动校验并给出明确报错。四、适用条件与溯源信息
适用条件用于界定协议“在什么情况下成立”，常见维度包括样本类型、设备型号、环境温湿度、生物安全等级、时间窗口等。溯源信息则记录协议的来源：是原创、改编自某文献，还是由某旧版本迁移而来，并保留 derived_from、contributors、review_status 等字段。
下面给出一个可直接参考的元数据片段示例（YAML 形式，字段值为教学示例）：
protocol_id: urn:mrp:lab-a:proto:cell-viability-001
version: 1.3.0
version_date: 2025-03-11
authors:
- name: 张明
affiliation: 示例生物实验室
orcid: 0000-0002-1825-0097
role: protocol_author
license:
spdx: CC-BY-4.0
usage_scope: 允许非商业使用与修改，需署名
depends_on:
- id: urn:mrp:lab-a:proto:cell-culture-002
version: ">=2.1.0,<3.0.0"
- id: urn:mrp:lab-a:resource:plate-reader-abs
version: "==4.2.1"
applicability:
sample_type: 贴壁细胞
biosafety_level: BSL-2
temperature_c: 37±0.5
provenance:
derived_from: urn:mrp:lab-a:proto:cell-viability-000
review_status: peer_reviewed
changelog: 修正孵育时间，补充设备版本约束
五、元数据之间的关系与校验
七类元数据并非孤立字段，而是相互约束的关系网络：版本约束依赖标识符，适用条件约束依赖资源的可用性，溯源信息又反过来解释版本差异。下图展示了它们之间的结构化关系，可作为协议加载器的校验依据。
从图中可以看到，标识符与版本共同构成协议的身份锚点，作者与许可界定权利边界，依赖关系与适用条件约束执行前提，溯源信息则记录协议的来龙去脉。一个健壮的协议加载器应依次校验：标识符是否可解析、版本是否满足引用方约束、许可是否允许当前用途、依赖是否齐备、适用条件是否与当前环境匹配、溯源链是否完整。
六、规范化描述的落地建议
- 字段命名统一：采用小写加下划线，避免同一含义出现多种拼写。
- 必填与选填分离：标识符、版本、作者、许可为必填；依赖、适用条件、溯源在发布级协议中应尽量完整。
- 机器可校验：为每类元数据提供 JSON Schema 或 SHACL 约束，使错误在加载阶段暴露，而非执行中途。
- 人机双读：元数据既要能被程序解析，也要能生成人类可读的协议封面页。
proto-001-v2），导致同一协议的不同版本被当成不同协议，破坏溯源链。正确做法是标识符保持稳定，版本单独成字段。掌握这七类元数据的规范化写法，是后续实现协议注册、检索、依赖解析与自动校验的基础。只有当元数据完整且一致时，机器可读协议才真正具备可发现、可复用、可审计的工程属性。