2. 实验数据建模与本体设计

实验数据知识图谱的根基不在图数据库,而在建模。若实体边界模糊、关系语义随意,后续无论用多强的推理机或图查询引擎,都只能得到一张“看起来像图”的表格集合。本节围绕实验领域最核心的四类实体——实验对象、实验条件、测量指标、结果数据——讨论如何识别它们、如何用 RDF Schema 与 OWL 表达约束,并给出一个可落地的本体设计案例。

一、四类核心实体的识别

实验对象(ExperimentalObject)指被研究、被处理或被观测的实体。它可以是材料样本、细胞系、器件批次、算法模型或仿真工况。识别要点是:它必须能被唯一标识,并且是实验条件与结果数据的共同承载者。例如“铝合金 6061-T6 试样 A03”是一个实验对象,而“铝合金”只是它的类别。

实验条件(ExperimentalCondition)描述对象在何种环境下被处理或观测,包括温度、压力、加载速率、试剂浓度、随机种子、设备型号等。条件通常以“参数名—数值—单位”三元组出现,因此建模时建议把条件抽象为可复用的参数化结构,而不是把每个条件都硬编码成一个类。

测量指标(MeasuredIndicator)是实验中被直接读取或计算得到的量,如抗拉强度、荧光强度、准确率、响应时间。它回答“测什么”,而结果数据回答“测到多少”。把指标与数据分离,是避免同一指标在不同实验中语义漂移的关键。

结果数据(ResultData)是具体观测值及其上下文,包括数值、单位、不确定度、采集时间、所属实验批次。结果数据必须能回溯到“哪个对象、在什么条件下、由哪个指标产生”,这条回溯链正是知识图谱的价值所在。

实验领域本体核心结构(RDFS/OWL 视角) 实验对象 ExperimentalObject 样本 / 器件 / 模型 实验条件 ExperimentalCondition 温度 / 压力 / 速率 测量指标 MeasuredIndicator 强度 / 准确率 / 响应 结果数据 ResultData 数值 / 单位 / 不确定度 实验批次 Experiment 时间 / 操作者 / 设备 hasCondition measures produces contains belongsTo instanceOf OWL 约束示例: ResultData ⊑ ∃hasValue.Decimal ∧ ∃hasUnit.Unit ∧ ∃derivedFrom.MeasuredIndicator ExperimentalCondition ⊑ ∃hasParameter.Parameter ∧ ∃hasValue.Literal

二、RDF Schema 与 OWL 的分工

RDF Schema 提供最基础的词汇:类(rdfs:Class)、子类(rdfs:subClassOf)、属性(rdf:Property)、定义域(rdfs:domain)和值域(rdfs:range)。它足以表达“实验对象有实验条件”“结果数据属于某个指标”这类轻量语义。例如:

ex:hasCondition rdfs:domain ex:ExperimentalObject ;
                rdfs:range  ex:ExperimentalCondition .
ex:produces     rdfs:domain ex:ExperimentalObject ;
                rdfs:range  ex:ResultData .

OWL 在此基础上增加逻辑约束与推理能力。实验领域最常用的三类构造是:基数约束(owl:cardinality)、存在约束(owl:someValuesFrom)和互斥类(owl:disjointWith)。例如要求每条结果数据必须且只能有一个数值、一个单位,并且结果数据与实验条件互斥,避免把“温度=25℃”误标成结果数据。

建模顺序建议:先用 RDFS 搭骨架,确认类与属性的定义域/值域无误,再逐步叠加 OWL 约束。一次性写满 OWL 公理会显著增加调试成本。

三、面向实验领域的本体设计案例

以“金属材料拉伸实验”为例,设计一个最小可用本体。类包括:MaterialSample(实验对象子类)、TensileTest(实验批次子类)、TemperatureCondition、StrainRateCondition(实验条件子类)、TensileStrength、Elongation(测量指标子类)、NumericResult(结果数据子类)。属性包括 hasCondition、measures、produces、hasValue、hasUnit、derivedFrom。

一条实例化数据可以写成:

ex:Sample_A03  a ex:MaterialSample ;
               ex:hasCondition ex:Cond_25C , ex:Cond_1e-3 ;
               ex:produces     ex:Result_UTS_A03 .

ex:Result_UTS_A03  a ex:NumericResult ;
                   ex:derivedFrom ex:TensileStrength ;
                   ex:hasValue    312.5 ;
                   ex:hasUnit     ex:MPa .

这条数据进入图数据库后,可以直接回答“哪些样本在 25℃、应变速率 1×10⁻³ s⁻¹ 下的抗拉强度超过 300 MPa”,而无需再解析原始表格。这正是本体设计带来的查询与推理收益。

四、常见建模陷阱

  • 把条件当结果:温度、速率是条件,不是测量指标。若混入结果数据类,后续统计会重复计数。
  • 单位硬编码:把“MPa”写进属性名(如 hasStrengthMPa),会导致单位换算和跨实验比较困难。应统一用 hasUnit 指向单位个体。
  • 忽略批次:同一对象多次实验若没有 Experiment 节点,结果数据将无法区分重复测量与不同条件测量。
  • 过度细分:为每个具体设备建一个类,会让本体迅速膨胀。设备更适合作为个体或条件参数值。
本体一旦发布并被多个实验组引用,修改成本很高。建议在 OWL 文件中保留版本号(owl:versionInfo),并对废弃类使用 owl:deprecated 标记,而不是直接删除。

完成本节的本体骨架后,下一阶段即可把实验记录、仪器导出文件和 LIMS 数据映射到这些类与属性上,形成可查询、可推理的实验数据知识图谱。