拾页偶有所得，随手记下
首页/文章

知识图谱（二）：建模

知识图谱 / RDF / 本体2026.10.0915 分钟阅读

概念模型、实体标识、属性图与 RDF，以及来源、时间和数据约束的表示方法。

概念模型与本体

概念模型规定一个领域中有哪些对象、对象具有什么特征，以及对象之间存在什么关系。模式将这些约定表达为数据可以遵循的结构；本体则进一步强调概念和关系的明确语义，可能包含类层次、同一性或逻辑约束。

软件依赖分析的最小模型包含 Service、PackageVersion、Team 和 Advisory 四种类型。order-api 是 Service 的实例，parser 1.4 是 PackageVersion 的实例。Service 通过 DEPENDS_ON 使用某个版本，版本也可以依赖另一个版本；OWNED_BY 连接服务与团队，AFFECTS 连接公告与版本。

每种关系都需要定义起点、终点、方向和含义。DEPENDS_ON 固定从使用者指向被使用者，并区分 runtime 与 test 作用域；AFFECTS 表示公告对影响范围的声明。若只有关系名称而没有解释，不同接入程序可能写出方向相反或语义不一致的边，查询结果将失去统一含义。

模式项约定错误数据的后果
Service.id稳定业务标识，名称单独保存改名后被当成新服务
PackageVersion.id包含生态、命名空间、名称和版本的身份规则不同生态中的同名组件被合并
DEPENDS_ON方向明确，区分 runtime 与 test把开发测试依赖报成生产风险
OWNED_BY允许按时间表达归属历史事件被归责给当前团队
AFFECTS来自公告的断言，保留条件将版本命中直接等同可利用

模式设计应与查询逐项对应。查询影响范围需要版本与依赖，查询责任需要团队归属，查询依据需要证据关联。不参与当前问题的复杂概念可以暂缓引入，关系名称和方向应定义清楚。

实体粒度与标识设计

实体粒度决定哪些差异需要独立表示。parser 组件与 parser 1.4 版本具有不同身份：组件可以跨版本共享名称与维护者，而依赖和影响范围通常落实到具体版本。若只建立一个 parser 节点，受影响版本与已修复版本的依赖就会混在一起。

服务与部署也需要按任务区分。静态快照可以把服务直接连到组件版本。服务同时运行生产、灰度和回滚版本时，可以增加 Deployment 或 Build 实体，记录每条依赖对应的环境和发布。

标识应独立于显示名称。订单服务可以改名，svc:order-api 的引用仍应有效。组件标识还要包括生态、命名空间和版本，防止不同组织的同名包被合并。示例用 pkg:parser:1.4 简写版本标识。版本比较也应采用生态规则，不能把 1.10 当作浮点数与 1.9 比较。

别名表达同一实体的不同名称，同一性声明表达两个标识指向同一对象，两者都需要证据。在 RDF 中，owl:sameAs 表示严格同一，不适合描述“疑似重复”。候选匹配应单独保存分值与审核状态；确认合并时保留旧标识、映射依据和受影响关系，才能在误合并后恢复。

身份与同一性语义：OWL 2 Primer

属性图与 RDF

属性图使用带标签的节点和有类型、有方向的关系表示数据，并允许节点与关系携带属性。Cypher 用图模式描述节点及其关系：圆括号表示节点，Service 和 PackageVersion 是标签，DEPENDS_ON 是关系类型，花括号内为属性。图模式不能独立执行，需要置于 MATCH、CREATE 或 MERGE 等语句中。

(order:Service {id: "svc:order-api"})
  -[:DEPENDS_ON {scope: "runtime", evidenceId: "build-order-1"}]->
(checkout:PackageVersion {id: "pkg:checkout-sdk:2.1"})

RDF 使用三元组表达资源描述。IRI 用于命名资源和谓词；字面量表示字符串、数值或日期等值，可以具有数据类型或语言标签；空白节点表示没有显式全局名称的资源。RDF 图是三元组集合，Turtle 则是它的一种文本写法，不是另一种图模型。

@prefix ex: <https://example.org/kg/> .

ex:order-api a ex:Service ;
    ex:dependsOn ex:checkout-2-1 ;
    ex:ownedBy ex:commerce-team .

ex:checkout-2-1 a ex:PackageVersion ;
    ex:name "checkout-sdk" ;
    ex:version "2.1" ;
    ex:dependsOn ex:parser-1-4 .

ex:parser-1-4 a ex:PackageVersion ;
    ex:name "parser" ;
    ex:version "1.4" .

代码中的 @prefix 为 IRI 定义缩写，ex:order-api 展开为 https://example.org/kg/order-api。a 是 rdf:type 的简写，声明资源的类型；分号表示后续三元组沿用同一主体；句点结束这一组陈述。带引号的 "1.4" 是字符串值，ex:parser-1-4 则是可被其他三元组引用的版本资源，二者不能互换。

两个表示都保存了“订单服务依赖 checkout-sdk 2.1”这一事实。属性图可以直接在依赖边上附加 scope 和 evidenceId；RDF 1.1 对关系本身的进一步描述通常需要断言节点等建模结构。RDF 有标准化的资源标识和语义体系，属性图的具体属性类型与约束能力则依赖实现。选型时应比较数据交换、查询、推理和维护需求。

RDF 基本数据模型与 Turtle 示例：W3C RDF 1.1 Primer

关系上下文与来源建模

业务关系常有额外参与者和条件。“公告声称 parser 1.4 在启用模板扩展时受影响”至少涉及公告、版本、条件和来源。这些信息应随 AFFECTS 关系一起保存。

一种通用做法是为断言建立独立身份，分别关联主体、谓词、客体以及来源。下列记录将公告影响表示为一项经过审核的断言，evidenceText 保存原文，condition 保存结构化条件。reviewed 表示断言已审核；服务配置需另行核查。

{
  "id": "claim:adv-demo-001:parser-1.4",
  "subject": "adv:ADV-DEMO-001",
  "predicate": "AFFECTS",
  "object": "pkg:parser:1.4",
  "source": "doc:advisory-demo:v1",
  "evidenceText": "parser 1.4 在启用模板扩展时受影响。",
  "condition": "template_extension_enabled",
  "status": "reviewed"
}

同一断言可以由多份材料支持，一份材料也可以支持多个断言。保存这种多对多关联后，撤回一个来源不一定要删除仍由其他有效材料支持的事实。证据应包含文档版本和定位信息，使审核者能恢复当时材料；仅保存一个会变化的网页地址通常不足以支持复核。PROV-O 可用于描述产物、处理活动及参与者之间的来源关系。

来源与处理过程：W3C PROV-O

RDF 1.2 进一步引入 triple term 和 reifier，用于描述与一个命题有关的陈述。引用命题不等于断言命题成立，因此能够表达“某来源声称此事”，同时保留对真实性的区分。所引 Concepts 文档是 2026 年 4 月 7 日候选推荐快照，使用前需确认工具支持。本文示例采用 RDF 1.1 语法。

标准状态与新增语义：W3C RDF 1.2 Concepts，2026-04-07 快照

时间建模

有效时间描述事实在业务中何时成立，事务时间描述这项记录何时成为系统中的有效记录。假设订单服务从 10 月 1 日起归交易团队负责，系统到 10 月 3 日才收到变更。按业务时间查询 10 月 2 日，团队应是交易团队；回放系统在 10 月 2 日所知道的信息，则可能仍得到旧的平台团队。

可以将有效区间保存为 validFrom、validTo，将系统记录区间保存为 recordedAt、supersededAt。采用左闭右开区间时，业务时刻 t 满足 validFrom ≤ t 且 t < validTo；回放认知还需对记录时刻应用同样的区间条件。没有终点的字段代表暂未记录结束时间，其持续有效性必须由数据接入约定支持。

归属记录业务有效区间系统可见区间
平台团队截至 10 月 1 日之前10 月 3 日纠正前，系统仍可能视为当前
交易团队从 10 月 1 日开始从 10 月 3 日开始

历史修正不应仅覆盖 updatedAt。例如十月五日才发现转交实际发生在九月三十日，需要调整有效区间，同时保留系统在十月三日曾记录了什么。保留两类时间，才能分别进行业务回溯和决策复盘。只查询当前状态的应用可以省去历史区间。

数据约束与 SHACL 校验

数据校验检查实例是否符合约定，例如组件版本必须具有版本字段，字段必须是字符串，并且只能出现一次。它与事实真实性不同：字符串 "9.9" 可以满足结构约束，但这个版本是否真的存在仍需来源支持。

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

ex:PackageVersionShape a sh:NodeShape ;
  sh:targetClass ex:PackageVersion ;
  sh:property [
    sh:path ex:version ;
    sh:minCount 1 ;
    sh:maxCount 1 ;
    sh:datatype xsd:string
  ] .

这个 SHACL 形状使用 sh:targetClass 选择显式或按验证环境可识别为 PackageVersion 的目标节点。sh:path 指定检查 ex:version；sh:minCount 1 要求至少一个值，sh:maxCount 1 要求至多一个值；sh:datatype xsd:string 要求值的数据类型为字符串。几个条件共同表达“恰有一个字符串版本值”。

示例资源 ex:parser-1-4 具有 ex:version "1.4"，符合这项约束。删除该属性会违反最小数量约束；增加另一个不同版本字符串会违反最大数量约束；将值改为数值 1.4 则不符合字符串类型。SHACL 验证报告应定位具体节点、属性和违反的规则，接入程序据此拒绝或隔离错误数据。

版本格式可以增加形状约束，真实发行记录、公告条件和依赖完整性则需要结合业务数据检查。

— 本页完 —
← 返回文章列表

搜索内容

输入关键词搜索文章、笔记与随笔。