📚 课程目录第4章协议描述语言概览

4. 协议描述语言概览

在机器可读实验协议工程中，协议描述语言承担的是“把实验意图、参数约束、执行步骤与结果判据写成机器能解析、能校验、能交换的形式”这一职责。但不同语言的设计目标差异极大：JSON 追求轻量与通用解析，YAML 追求人类可读，XML 追求严格结构与命名空间，RDF 追求三元组式的开放语义，OWL 追求逻辑推理能力，SHACL 则专注于对 RDF 图施加约束校验。选型时若只看“能不能写”，很容易在后期遇到校验缺失、语义歧义或工具链断裂的问题。

一、从“数据交换”到“语义约束”的谱系

可以把这些语言放在一条从“纯语法”到“强语义”的谱系上理解。JSON 与 YAML 属于语法层：它们只规定键值、数组、嵌套等结构，不规定某个字段在实验语境中意味着什么。XML 通过 DTD、XSD 提供结构约束，但仍不表达“某参数必须大于另一参数”这类领域规则。RDF 把信息拆成“主语—谓语—宾语”三元组，使不同来源的协议片段可以合并成一张图。OWL 在 RDF 之上加入类、属性、等价、不相交等公理，支持推理。SHACL 则反过来，用形状（Shape）描述“一张 RDF 图应当满足什么条件”，用于校验而非推理。

因此，选型的第一问不是“哪种语言更流行”，而是“本实验协议最需要机器替我们做什么”：是跨系统搬运参数，还是自动检查参数组合是否合法，还是让多个实验室的协议片段能自动对齐概念。目标不同，答案就不同。

二、各语言的适用边界

JSON 的优势是解析器无处不在、与编程语言映射直接。它适合描述“一次实验运行”的扁平参数集，例如温度、时长、样本编号。但 JSON 没有注释、没有类型系统、没有引用机制，当协议需要表达“步骤 B 依赖步骤 A 的输出”时，只能靠约定字段名，机器无法自动检查依赖是否成环。

YAML 在 JSON 基础上增加了注释、锚点与引用，可读性更好，适合人工维护的配置型协议。但 YAML 的缩进敏感和隐式类型转换（如 on 被解析为布尔值）是常见陷阱，且解析器实现差异较大，不建议作为跨系统交换的唯一格式。

XML 配合 XSD 可以表达元素顺序、出现次数、数据类型和命名空间，适合需要严格结构契约的场景，例如仪器厂商之间的协议交换。代价是冗长，且 XSD 难以表达“参数 A 与参数 B 的联合约束”。

RDF 把协议拆成三元组，天然支持多来源合并。例如实验室 A 用 ex:temperature，实验室 B 用 ex:tempC，可通过 owl:sameAs 或映射声明对齐。RDF 本身不校验，需要配合 SHACL 使用。

OWL 适合定义实验本体：样本类型、仪器类别、参数之间的层级与不相交关系。推理机可据此发现“某样本同时被声明为两种互斥类型”这类矛盾。但 OWL 推理复杂度高，不适合承载高频变化的运行时数据。

SHACL 是 RDF 的“校验层”。它用形状描述节点必须满足的条件，例如“每个 ex:Step 必须恰好有一个 ex:duration，且值为正整数”。校验失败时返回结构化报告，指明违规节点与约束，便于自动拦截不合规协议。

三、选型决策与组合策略

实际工程中很少只用一种语言。一个可落地的组合是：用 OWL 定义实验本体与概念层级，用 RDF 承载具体协议实例，用 SHACL 对实例做提交前校验，用 JSON 或 YAML 作为面向操作人员的编辑与传输格式，再通过映射脚本转换为 RDF。这样既保留了人工可读性，又获得了语义校验能力。

下面给出一个简化的 SHACL 形状示例，用于约束“每个实验步骤必须有唯一编号和正数时长”：

@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix ex: <http://example.org/protocol#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

ex:StepShape a sh:NodeShape ;
  sh:targetClass ex:Step ;
  sh:property [
    sh:path ex:stepId ;
    sh:minCount 1 ;
    sh:maxCount 1 ;
    sh:datatype xsd:string ;
  ] ;
  sh:property [
    sh:path ex:duration ;
    sh:minCount 1 ;
    sh:datatype xsd:decimal ;
    sh:minInclusive 0 ;
  ] .

若某步骤缺少 ex:duration，或时长为负，SHACL 校验器会输出类似 Violation: ex:Step1 sh:minCount 1 on ex:duration 的报告。工程上可把该报告作为协议入库的门禁条件，而不是等到实验执行阶段才发现参数缺失。

选型时建议先写出一份“协议必须被机器检查的 5 条规则”，再对照各语言能力表判断：JSON/YAML 只能检查语法，XML+XSD 能检查结构，RDF+SHACL 能检查语义约束，OWL 能检查逻辑一致性。规则越靠近语义，越需要后两者。

四、常见误用与边界提醒

用 JSON 承载语义关系：把“步骤依赖”写成字符串数组，机器无法验证依赖是否存在、是否成环，后期只能靠人工审查。
用 OWL 做运行时校验：OWL 推理面向分类与一致性，不适合逐条检查“时长必须大于 0”这类数值约束，应交给 SHACL。
用 YAML 做跨系统交换：不同解析器对锚点、合并键、隐式类型的处理不一致，容易在边界场景产生歧义。
忽略命名空间治理：RDF/OWL 中同一概念若出现多个 URI，合并后会产生重复节点，需提前约定本体前缀与映射规则。

总结来看，JSON/YAML 解决“写得快、读得懂”，XML 解决“结构契约”，RDF 解决“可合并”，OWL 解决“可推理”，SHACL 解决“可校验”。选型依据应回到实验协议本身：需要机器替我们搬运、检查、对齐还是推理，答案就落在谱系的不同位置上。