从本体到可信数据查询：RDF、SPARQL 与受控 SQL 实践

“谁当前参与远山正在进行的项目？”看上去只需几次 JOIN。真正写下查询前，却要先确定“远山”指哪个客户，“正在进行”是项目状态还是参与有效状态，“当前”以哪一天为准，员工按什么标识去重。任何一项没有说清，查询都可能顺利执行，却回答了另一道题。

本篇沿着一个合成项目管理案例，把问题拆成语义定义、RDF实例与 SPARQL 查询，再追到受控计划和参数化 SQL，最后讨论歧义、冲突、口径变更以及三种数据访问路线。示例中的人名、项目、金额和投入均为教学数据，不代表实际组织记录。

1. 先定义问题：谁、哪种关系、哪一天

本文先把问句拆成业务条件，再用同一组样本逐步构造 SPARQL；随后对照关系库中的受控 SQL，检查两条路线如何处理歧义、日期口径、数据快照与规则变更。文中的结果只覆盖合成样本，不代表生产查询效果。

案例数据库保存客户、员工、项目、项目参与记录和任务。项目负责人、参与某项目的员工、具体任务的执行人都可能被口语概括成“项目的人”，但它们是三种不同关系。

本例问题明确为“谁当前参与远山正在进行的项目？”，其语义可以逐项列出：

这些规则来自本案例业务词典，而不是从字段名自动推出来的。尤其是 left_on IS NULL：本例约定把它视为开放结束日期用于查询，不代表业务系统已经证明这段参与永远不会结束。

查询跑通只能说明语法和执行路径可用；答案是否正确，还取决于别名、关系、日期和去重口径。

这条分解也告诉我们应怎样核验结果：先确认别名、关系和日期口径，再查看查询计划及SQL，最后将返回人员与固定样本对照。SQL语法正确、查询执行成功和业务答案正确，是三个不同检查点。

2. 三种材料各自负责什么：本体、RDF 与查询

2.1 RDF实例是什么

RDF用主语、谓语、宾语三部分表达一条事实，常称三元组。例如：

<https://example.org/work/participation/1002>
    <https://example.org/work/employee>
    <https://example.org/work/employee/2> .

它表示参与记录1002关联员工2。主语和对象可以是用IRI标识的资源；宾语也可以是字面量，例如整数60、字符串“林晓”或带 xsd:date 类型的日期。IRI是资源标识符；ex:、schema:这样的前缀只是长IRI的缩写，不是数据库地址，也不会因为中文标签相同就合并两个资源。

RDF图是一组三元组。图里可以同时存放本体结构和具体实例，但两者作用不同：ex:Participation是类定义，participation/1002是具体参与记录。查询具体人员和投入，要查实例事实，而不是只看类关系图。

2.2 SPARQL如何匹配图模式

SPARQL是面向RDF图的查询语言。最常见的 SELECT ... WHERE { ... } 查询会在图中匹配一组带变量的三元组模式，并返回满足条件的变量绑定。变量通常以问号开头；同一个变量在多个模式中重复出现，就要求匹配到同一个RDF项。分号表示同一主语继续列出谓语，句点结束一组Turtle风格的三元组模式；a是 rdf:type 的简写。

例如，下面只寻找姓名为林晓的员工：

PREFIX ex: <https://example.org/work/>
PREFIX schema: <https://schema.org/>

SELECT ?员工 WHERE {
  ?员工 a ex:Employee ;
        schema:name "林晓" .
}

例如，若图里有两个模式分别匹配到 ?员工 = employee/2 和 ?员工 = employee/3，它们不能拼成一行结果，因为同名变量要求绑定值相同。这里“绑定”就是查询为变量记下的匹配值，像把 ?员工 暂时记为员工资源2。

这不是自然语言理解。它要求图中确实存在 ex:Employee 类型和 schema:name 字面量“林晓”，前缀、大小写、语言标签与名称谓语都必须匹配。

2.3 Fuseki负责什么

Apache Jena Fuseki是通过HTTP提供RDF数据服务的应用，能暴露SPARQL查询端点；TDB2是Jena的持久化RDF存储。把RDF文件加载到Fuseki/TDB2后，查询针对的是已加载的数据集。它不会因为源数据在PostgreSQL更新，就自动替你刷新图。

LinkML在本案例中用于描述领域类、属性和关系；domain.yaml是领域模型。semantic-contract.yaml则是案例自定义的映射与业务规则文件，并非LinkML标准。查询计划把一句问题整理为有限字段，例如意图、关系、日期和输出粒度。受控执行器再把计划交给程序维护的SQL模板，并将动态值作为参数传入数据库。

因此，RDF/SPARQL与关系型SQL是两种不同的访问路径。前者匹配图中的资源和谓语；后者经表、列和连接访问关系数据。语义模型可以帮助两条路径使用一致的业务含义，却不会自动把一种查询语言转换成另一种。

图1：两条路径可以共享业务定义，但数据访问位置与刷新责任各自存在。

3. 从一名员工开始：逐步构造 SPARQL 查询

3.1 从数据库记录到RDF资源

进入查询前，先看数据库中的一行如何变成图中的资源。案例把员工整数主键2映射为 https://example.org/work/employee/2，把参与记录1002映射为 https://example.org/work/participation/1002。这些IRI把数据库行变成可在图中引用的资源。实例中可见：

@prefix ex: <https://example.org/work/> .
@prefix schema: <https://schema.org/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<https://example.org/work/employee/2> a ex:Employee ;
    schema:name "林晓" .

<https://example.org/work/participation/1002> a ex:Participation ;
    ex:id "https://example.org/work/participation/1002"^^xsd:anyURI ;
    ex:employee <https://example.org/work/employee/2> ;
    ex:project <https://example.org/work/project/101> ;
    ex:allocation_pct 60 ;
    ex:joined_on "2026-01-01"^^xsd:date .

对齐脚本做的不是“把IRI改得好看”，而是把三类具体差异消掉：

初始实例有192条三元组。替换类型不增加条数；21个枚举值各多一条类型事实，33个实体各补一条ID，得到 192 + 21 + 33 = 246 条。这是表示转换的账，不是新增了54条业务事件。譬如项目状态active转换后类似：

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

<https://example.org/work/project/101>
    ex:status <https://example.org/work/project/101/value/status> .
<https://example.org/work/project/101/value/status>
    a <https://example.org/work/ProjectStatus#active> .

因此，直接写 ?项目 ex:status "active" 不会匹配这份对齐图。枚举值也不能只凭屏幕上的显示文字猜写法。

其中 schema:name 值得特别核对。领域OWL把公共名称属性生成成了本地 ex:name，而对齐后的实例仍将姓名写在 https://schema.org/name，所以不能只看模型标签就假定查询应使用哪个谓语。若查询 ex:name "林晓"，它不会匹配这里的明确名称事实。本例查询沿用实例实际出现的 schema:name。类URI、名称谓语、枚举值节点和显式ID都属于实例对齐的范围；只改类型，不检查属性和取值表示，仍可能得到空结果。

3.2 从单个员工扩展到参与记录

SPARQL 查询由带变量的事实模式组成；变量名前的问号表示“这里需要匹配一个值”。相同变量在不同模式中复用，就要求这些模式连接到同一个资源。先确定员工资源，再沿 ex:employee 找参与记录。这里的 ex:employee 是一条有方向的关系：从参与记录指向员工。

PREFIX ex: <https://example.org/work/>
PREFIX schema: <https://schema.org/>

SELECT ?参与 ?比例 WHERE {
  ?员工 a ex:Employee ; schema:name "林晓" .
  ?参与 a ex:Participation ;
        ex:employee ?员工 ;
        ex:allocation_pct ?比例 .
}

这里变量名称用中文便于阅读，变量名本身不会映射到中文业务概念。真正决定含义的是前缀展开后的IRI和字面量。查询找到参与记录1002的60，以及参与记录1007的40。

例如，两个模式都写 ex:employee ?员工，就要求参与记录1002和1007的 ex:employee 指向同一个员工资源。样例中，这个绑定是 https://example.org/work/employee/2，其姓名事实是“林晓”。变量绑定是查询过程中的“这个位置匹配到了哪个RDF项”；它不是把变量名翻译成姓名，也不是按姓名文本把不同员工合并。

图2：记录1002与1007沿同一变量找到员工2，再分别保留各自项目和投入比例；这是本案例实例的结构示意。

接着连接项目，并读取项目名称。完整查询还要检查有效期：

PREFIX ex: <https://example.org/work/>
PREFIX schema: <https://schema.org/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

SELECT ?项目 ?投入比例 WHERE {
  ?员工 a ex:Employee ; schema:name "林晓" .
  ?参与 a ex:Participation ;
        ex:employee ?员工 ;
        ex:project ?项目节点 ;
        ex:allocation_pct ?投入比例 ;
        ex:joined_on ?开始 .
  OPTIONAL { ?参与 ex:left_on ?结束 }
  FILTER(?开始 <= "2026-11-03"^^xsd:date)
  FILTER(!BOUND(?结束) || ?结束 >= "2026-11-03"^^xsd:date)
  ?项目节点 schema:name ?项目 .
}
ORDER BY ?项目

逐项看它怎样工作：

1. 第一组模式找到类型为员工且 schema:name 等于“林晓”的资源。
2. 第二组要求有一条 Participation，其 employee 指向同一资源；项目、比例、开始日也必须存在。
3. OPTIONAL尝试读取退出日。没有这条三元组时，参与记录不会因此被删掉，而 ?结束保持未绑定。
4. 两个 FILTER落实本例含首尾日期的有效期规则。第一个保留已经开始的记录；第二个保留结束日未绑定或不早于参考日的记录。
5. 最后读取项目名称并排序。

这里还要注意引擎边界：xsd:date 是合法的类型化字面量，但 SPARQL 1.1 并不强制所有实现支持它的大小比较。本例的日期谓词有 RDFLib 7.6.0 的结果和历史 Jena/Fuseki 记录作依据；迁移引擎时应专门回归日期比较，不要把它当成对所有实现的可移植保证，也不要直接把日期与 xsd:dateTime 混比。业务上缺少结束日的含义同样来自查询契约，而不是 RDF 的缺失事实自动等同于 SQL NULL。

3.3 查询结果：两条参与记录，不等于两项负责人工作

对齐实例在该参考日得到：

这表示两条样本参与记录满足给定日期筛选，不能单凭结果说林晓对两个项目“负责”。负责人是 Project.owner，参与员工是 Participation.employee；两条事实需要沿不同关系查询。若要计算总投入，还要明确汇总的是哪些项目、是否只统计active项目，以及百分比是否可直接相加。本案例的另一个固定问题把有效参与记录投入相加，得到100%，但那不是OWL推理结果，而是SQL或SPARQL聚合加上约定口径的计算。

4. 在 Fuseki 查询：答案对应哪一份数据

本案例配置的数据集名为 work_demo，采用TDB2持久化。Fuseki 提供查询服务，TDB2 保存已载入的 RDF 数据；两者都不会自动把 PostgreSQL 的更新同步进来。历史导入的默认图包含521条本体三元组和246条对齐实例三元组，共767条。33个业务实体和24个 NamedEntity 子类实例，是另外两种对象计数，不要与三元组数混淆。

复现已配置数据集的查询过程如下：

1. 打开本机 Fuseki 工作台，进入 work_demo 的查询页面。
2. 将前一节完整查询粘贴到编辑区并执行。
3. 查看项目、投入比例两列，预期为客户数据治理40%、设备知识平台60%。
4. 记录数据集名、参考日、查询文本和结果；不要在更新接口中执行该查询。

Fuseki官方文档说明服务可提供SPARQL查询端点，TDB2与Fuseki配合保存RDF数据。实际运行时，以本地配置的服务地址和数据集为准。若从空数据集开始导入，应采用案例提供的配置与首次装载流程；不要对已经有数据的目录重复导入，以免重复内容或匿名节点造成难以解释的结果。完整启动、空图导入和排障步骤见案例工作台说明。

这里最重要的不是某个UI按钮，而是查询对象的身份：Fuseki读的是已载入TDB2的数据，不会直接访问PostgreSQL。此前保存的服务验证记录显示，当时在Fuseki 6.2.0中，767条计数、林晓两行结果和一个显式继承路径查询均通过；配置没有启用推理，也没有数据库同步。这个结果证明的是当时那一份数据集和查询，不是服务此刻仍在运行，也不证明更大数据量下的容量或性能。

4.1 更新数据后，哪一份答案才是“当前”

“当前”至少有两个时间坐标。业务参考日回答“哪一天的参与关系算有效”，例如本例固定用2026-11-03；数据快照或抽取时刻回答“查询时实际载入了哪一批事实”。两个时间不能互相替代：拿较新的快照按较早参考日查询，仍是在问历史业务状态；拿较早快照按今天的参考日查询，也可能缺少后来录入的事实。

图3：上轨是业务有效时间，下轨是事实可见时间；S仅为示意符号，不代表案例测得的快照时刻。

参考业务日决定“判断哪一天的参与状态”；数据快照决定“有哪些事实可供判断”；契约版本决定采用哪套边界规则。三者需要分别记录。

物化图谱要承担刷新责任。一个可复算的结果至少要附带：

源数据库发生更新，并不会自动改写TDB2里的RDF。若要求近实时，就要评估增量捕获、删除传播、失败重试、幂等和版本切换；若允许批次快照，就要把刷新周期和快照时间告诉使用者。767条教学数据不足以推断生产装载能力，不能用一个固定的“每行数据对应多少条三元组”的固定倍数代替真实负载测试。

5. 改走关系库：语义计划如何落到受控 SQL

5.1 先把问句变成明确的查询计划

同一问题也可以直接查询权威关系库。自然语言先整理成有限字段，避免执行器直接猜测连接路径和日期口径：

intent: project_participants
customer_alias: 远山
relation: Participation.employee
membership_on: "2026-11-03"
project_status: active
output: distinct_employee

各字段都有具体职责：intent选择允许的查询类型；customer_alias要解析到唯一客户；relation锁定参与关系而非负责人；membership_on固定参考日期；project_status限定项目状态；output说明按员工去重。

案例由三个不同材料描述这条链路：

• domain.yaml描述业务类和属性，是LinkML模型。
• semantic-contract.yaml把对象、关系、别名、列映射和日期规则与冲突处理规则连到数据库，是本案例自定义契约，不是LinkML标准。
• query-plans.yaml保存经整理的示例计划；它不是在线通用意图解析器。

这些是预先整理、可供审阅的示例计划，不代表任意自然语言问题都已能自动解析。执行器按有限意图选择人工编写的模板、检查关系和输出类型，并把客户ID、状态和日期作为参数传入。契约在执行时实际提供的是别名；表列、连接和时间规则仍在执行器里硬编码。因此它展示的是受控查询模式，而不是通用语义编译器。

把契约中与Q03直接相关的部分抽出来，可以看到别名、关系、状态与日期分别放在哪里：

aliases:
  远山: { class: Customer, id: 1, canonical: 远山制造 }
relations:
  Participation.employee: { column: employee_id, target: Employee }
  Participation.project: { column: project_id, target: Project }
  Project.customer: { column: customer_id, target: Customer }
policies:
  participation_on_date:
    expression: joined_on <= reference_date AND (left_on IS NULL OR left_on >= reference_date)
    boundaries: inclusive
  active_project: { column: status_code, value: active }

这是契约的教学摘录，完整文件还保留来源证据字段。它能让审核者发现“词典说的是参与者，模板却连到了负责人”这类错配，但只有执行器真的消费或校验这些字段，定义才能成为运行约束。否则YAML与代码仍可能漂移。

5.2 固定 SQL 结构，只绑定动态值

Q03的PostgreSQL模板可整理为：

SELECT DISTINCT e.id, e.name
FROM projects AS p
JOIN project_memberships AS m ON m.project_id = p.id
JOIN employees AS e ON e.id = m.employee_id
WHERE p.customer_id = %s
  AND p.status_code = %s
  AND m.joined_on <= %s::date
  AND (m.left_on IS NULL OR m.left_on >= %s::date)
ORDER BY e.id;

程序绑定的值依次是：

(1, 'active', '2026-11-03', '2026-11-03')

SQL结构由程序模板控制；用户文本不会被拼进SQL字符串。参数占位符适用于值，不能用来替换表名或列名。若将来允许选择列或排序字段，应从代码白名单中选取标识符，而不是把未验证的用户输入拼进SQL。只读数据库权限、事务隔离、语句超时和结果行数限制也是不同控制；本执行器已有只读事务与五秒语句超时，但没有实现通用行数上限，不能把“参数化”说成完整安全方案。

例如模板中的 p.customer_id = %s 留出一个值的位置，参数列表首项 1 在执行时绑定到这里；整段 (1, 'active', '2026-11-03', '2026-11-03') 不会被拼成SQL文本。这里的“绑定”与SPARQL变量绑定用途不同，但共同点是把动态值放在结构已确定的位置。

在Psycopg2中，绑定发生在 execute 调用，而不是先把四个值插值成一段SQL：

params = (1, 'active', '2026-11-03', '2026-11-03')
conn.set_session(readonly=True, isolation_level='REPEATABLE READ')
with conn.cursor() as cur:
    cur.execute("SET LOCAL statement_timeout = '5s'")
    cur.execute(sql, params)
    rows = cur.fetchall()

这里的 conn 是已建立的案例连接，sql 是上面的固定模板。%s外不加引号，也不使用Python的 %、+ 或f-string把业务值拼进命令。%s::date 的类型转换由PostgreSQL处理；SQLite不接受这一驱动占位符和PostgreSQL写法，替代验证必须分别改为 ? 并说明日期存储约定。

有限计划也需要明确拒绝未知结构，最小的入口检查如下：

if plan['intent'] == 'clarification':
    return None, None
if plan['intent'] != 'project_participants':
    raise ValueError('unsupported intent')
if (plan['relation'] != 'Participation.employee'
        or plan['project_status'] != 'active'
        or plan['output'] != 'distinct_employee'):
    raise ValueError('unsupported semantics')

这只是Q03分支的教学片段；实际案例另有负责人、部门员工两个模板。它不等于完整计划schema验证：必填项、未知别名、日期格式、额外字段和授权范围仍需在调用边界验证。SQL参数绑定能隔离值与代码，不能替代这些业务检查。

5.3 执行结果如何回到业务问题

Q03在固定种子数据上的预期结果是四名不同员工：

这四人来自正在进行的远山项目101。远山的项目104状态为planned，不进入本题；即使项目104后来状态改变，仍需检查其参与记录和参考日。另一个查询Q02问的是“远山项目负责人”，沿 Project.owner 得到陈晨。两个问题结果有重合，却不是同一语义定义。

去重例子：员工林晓可能因项目101下有多条符合条件的参与记录，在连接结果中出现多行；SELECT DISTINCT e.id, e.name按员工ID和姓名组合去重后只输出一行。SQL不会替业务决定应按“员工”还是“参与记录”计数，粒度必须先说清。此例只解释查询去重规则，不增加新的案例记录。

在独立内存SQLite上按PostgreSQL模板适配占位符后，Q02、Q03和Q04三条计划分别得到陈晨、四名参与者及研发及下属四人，与固定基线一致；Q12返回澄清且未执行SQL，两个源码拒绝断言也通过。这是固定样例的关系查询替代验证，不是PostgreSQL实测或未见自然语言问题的准确率测试。

图4：问句解释决定查询什么，模板控制结构，参数传递值，结果仍须按业务口径核对。

6. 歧义、范围与冲突：哪些问题必须先澄清

6.1 先问“负责”指哪种关系

“林晓负责远山那边吗？”至少可能指项目负责人、项目参与者或任务执行人，也没有指定远山的哪个项目。案例计划把它标为 clarification，提出“你指项目负责人、项目参与者，还是某项任务的执行人？具体是远山的哪个项目？”并且不执行SQL。

图5：负责人、参与者和任务执行人分别沿不同关系查询；图中关系对应本案例模型。

这说明澄清不是把一个字段名猜得更像用户原话，而是识别会改变连接路径的歧义。若把 Participation.employee 当作 Project.owner，数据库仍会返回有效员工，却会把参与者错误描述成负责人。

6.2 “研发”要不要包含下属

部门结构中，平台组是研发部下属。只查直接部门得到陈晨和李悦两人；按案例词典把“研发”解释成研发部及下属部门，则增加林晓和王宁，共四人。

这里的层级展开既可以在SQL中用递归CTE，也可以在RDF图里沿父部门关系遍历。是否包含下属是业务约定，不是因为数据库有 parent_id 就自动成立。

6.3 60%与80%建议，80万与90万陈述

文本材料中的不同陈述要保留状态和来源，不能把最近出现的一句话当成更新后的数据库事实：

待审批的建议不是生效事实；查询应保留状态与来源，不能把“最近提到”当成“已经批准”。

80%既未获批也未到拟议生效日期，不能覆盖当前60%。90万元也不能因为出现在会议文本中就覆盖数据库80万元；反过来，数据库当前是结构化来源，也不证明它在所有业务争议中天然代表最终真相。查询系统应指出冲突，而不是默默选边。

6.4 空结果先分类，不自动放宽条件

空结果可能来自不同原因：实体别名没有解析到客户；实例缺少预期类型或谓语；项目状态筛选排除了记录；参考日边界不符合；或者业务上确实没有满足条件的人员。诊断顺序应先检查解析、图或表的范围、关系映射、口径过滤和数据新鲜度。不要为了“给出一个答案”自动删除状态或日期条件，因为那会改变原问题。

对读者可解释的结果，应至少说明问题解释、参考日期、实际关系、结果去重规则和冲突状态。数据快照、契约版本和来源证据可作为查询回执的一部分，供后续复算。

7. 用日期边界变更验证治理过程

在本例中，“当前参与”的边界是开始日和结束日都包含参考日，且空结束日按开放区间处理。假设业务Owner后来批准另一条规则：结束日当天不再计入当前参与。这个改动不是事实数据变化，而是口径变更；不必改写历史项目记录，却会改变边界日查询结果。

把它落实为一次可审查的变更：

1. 登记依据。 保存决策编号、批准角色、生效日期、旧规则和新规则。没有批准记录时不修改正式契约。
2. 更新契约版本。 将日期边界从 left_on >= reference_date 调整为 left_on > reference_date，记录新版本和生效时间；说明是否追溯重算历史报表。
3. 检查映射。 确认 left_on仍映射到同一源列，日期类型和NULL处理未被误改；校验字段与表映射与数据库结构一致。
4. 建立边界用例。 对开始日早于、等于、晚于参考日，以及结束日早于、等于、晚于参考日和NULL分别设预期。尤其要让“结束日等于参考日”的记录在旧版返回、新版排除。
5. 运行查询回归。 对负责人、参与者、研发范围、有效日期、80%未批准提案和预算冲突等固定题逐项回归，确保改动只影响声明范围。
6. 审核结果并发布。 业务Owner确认定义，数据及语义维护者审核映射，工程负责人检查查询和结果差异；记录版本、测试题、参数、执行时间和结果摘要。
7. 保留回退路径。 新版异常时将查询计划绑定回上一契约版本，并保留旧版结果快照，避免用新版规则解释旧结果。

最小的查询回执可以记录：契约版本、模型与映射指纹、计划ID、查询模板版本、参数（按隐私要求脱敏）、数据库快照时间、执行身份、结果摘要、异常和审批依据。若只存一段自然语言答案，之后很难判断数字变化来自事实、映射、查询还是口径。

7.1 将变更压缩成可审核差异

版本差异不应只写“优化当前参与口径”，而应写出可执行表达式和影响：

# 教学变更记录，不代表真实审批
change_id: CURRENT-PARTICIPATION-002
previous_version: 1
next_version: 2
status: proposed
policy: participation_on_date
old_end_operator: ">="
new_end_operator: ">"
unchanged:
  start_operator: "<="
  null_end: open
  source_column: project_memberships.left_on
review_roles: [business_owner, semantic_maintainer, query_maintainer]

status: proposed意味着它只能用于候选版本演示。正式应用前，还要补实际审核身份、审批记录、生效时点和是否追溯。版本号不会因为测试通过就自动变成批准。

7.2 用独立边界样本检查影响

原始种子没有“在2026-11-03当天退出”的记录，因此只跑已有题目，很可能察觉不到差异。需要加入独立的回归夹具，而不是修改原业务样本：

下面的SQLite内存例子把两版谓词放在同一份夹具上执行。日期统一为合法、补零的 YYYY-MM-DD 字符串，因此本例的字典序与日历先后相同；这不是把SQLite字符串类型当作PostgreSQL日期类型的替身。

import sqlite3

db = sqlite3.connect(':memory:')
db.execute('CREATE TABLE boundary_cases(id TEXT, joined_on TEXT, left_on TEXT)')
db.executemany('INSERT INTO boundary_cases VALUES (?,?,?)', [
    ('before_end', '2026-11-01', '2026-11-02'),
    ('equal_end', '2026-11-01', '2026-11-03'),
    ('after_end', '2026-11-01', '2026-11-04'),
    ('open_end', '2026-11-01', None),
    ('equal_start', '2026-11-03', None),
    ('future_start', '2026-11-04', None),
])
base = '''SELECT id FROM boundary_cases WHERE joined_on<=?
          AND (left_on IS NULL OR left_on>=?) ORDER BY id'''
params = ('2026-11-03', '2026-11-03')
v1 = {row[0] for row in db.execute(base, params)}
v2 = {row[0] for row in db.execute(base.replace('left_on>=?', 'left_on>?'), params)}
assert v1 - v2 == {'equal_end'}
assert not (v2 - v1)

这次假设变更只移动“结束日等于参考日”这一条边界；测试通过不等于业务审批通过。

回归结果是v1保留4条，v2保留3条，唯一移除项为 equal_end。这里替换的是程序内部固定谓词，不接受任意SQL输入。与此并行，还要逐项核对契约中的表、主键、关系列和属性列仍存在，并重跑负责人、参与者、部门范围及原始事实断言。列存在只说明物理映射未悬空，不证明业务含义正确；60%与80%、预算来源冲突仍需要审阅证据状态。

完整审批、上线和回退仍属于治理设计；实际执行的部分是副本映射检查与内存查询回归，而不是生产治理平台。这样既能展示一条可运行的变更检验链，也不会把一个测试脚本说成组织流程已经落地。

图6：边界样本使规则差异可见；测试结果与业务审批承担不同责任。

8. 对照两种架构：受控分析模式与虚拟知识图谱

本案例中的语义定义要进入查询链路，至少要回答三个问题：如何选择与当前问题相关的业务概念，如何把受约束的计划交给确定性执行器，以及数据仍在关系库时怎样提供图接口。下面分别参考公开文章对分析模式的描述和Ontop官方文档对虚拟知识图谱的定义；它们用于理解实现分工，不是对本案例的独立效果背书。

8.1 先选择受约束的分析模式

Benjamin Wan Rothschild在Analytics at Meta发表的《Scaling AI-Native Analytics Patterns at Meta》描述一种分析工程路径：Analytics Libraries把重复测量模式封装为参数化实现，管道生成记录维度、指标和数据源的类型化YML模型；Agent理解问题并选择输入，确定性查询工具负责数据源选择和SQL生成。这些内部实践按作者公开文章中的自述引用，不视为本文独立复现实验。

这里有两个层次的“参数化”：

前者解决“重复分析如何复用”，后者解决“动态值怎样不变成SQL代码”。不能因为系统有 %s 参数，就说它已经拥有Meta所述分析库。反过来，分析模式有了治理模型，也仍需要安全绑定和执行权限。

文章也提醒，一次性探索不宜过早标准化，治理库需要持续维护。本例只有三个模板，加入新问题仍要修改执行器与测试；这既是受控范围，也是覆盖率与维护成本的来源。适合固化的是反复出现、定义稳定并有Owner的分析，而不是把每个临时问题都建成永久指标。

Meta文章描述的分析模式库与本例的白名单SQL模板处在相邻但不同的层次：前者强调把重复分析模式封装成可复用、可参数化的接口；本例当前只有少量固定意图与模板，用于展示如何将业务关系、筛选口径和参数绑定落实到确定性查询。它还不是成熟的分析模式库，也没有通过盲测证明能改善回答质量。

8.2 当调用方需要SPARQL、数据仍在关系库

Ontop官方文档将虚拟知识图谱描述为在关系数据库之上提供RDF/SPARQL视图，并把SPARQL查询改写为关系数据库查询。它保留源数据作为权威，不要求先物化一份完整的实例RDF图。要实际使用，仍需配置数据库到类、属性、主键IRI及连接关系的映射，并评估查询改写能力、性能、访问权限与运行时依赖。

这与本例的语义辅助SQL和物化RDF是不同路线：前者由应用将有限计划送入SQL模板；虚拟图谱提供SPARQL接口并在查询时改写；物化RDF则先抽取、转换并保存实例图。本例未部署Ontop，路线表是架构比较，不是性能排名。

三种路线都需要把业务含义与物理数据连接起来，但接口、数据位置和维护成本不同。应先用代表性查询和数据新鲜度要求评估，再决定是否增加图服务或RDF副本。

9. 怎样评估三种数据访问路线

9.1 三种访问路线

图7：三种路线对比的是查询入口、事实位置与持续维护责任，不是本案例的性能排名。

虚拟图谱不是“OWL直接变SQL”的魔法开关。它还需要关系到类和属性的映射、主键到IRI的规则、连接路径和过滤聚合的翻译能力。物化RDF同样不自动保证图中数据最新或OWL推理可用。应按数据新鲜度、查询形态、互操作需求、源库负载、维护能力及权限模型做选择。

对于当前小型只读案例，先测语义上下文与有限查询计划，再保留Fuseki作为图数据教学和查询对照，是一个可检验的起点；它不是对三种路线已有性能对比的结论。

9.2 怎样设计有解释力的效果评估

可以准备三种条件，固定数据快照、问题、模型版本、执行权限和时间口径：

B与C改变了执行接口，不能把所有差异都归因于“语义层”。若目标是独立测量语义上下文的贡献，必须保持执行接口一致；若比较整套系统，则应明确比较对象是组合方案。

题目集应分成开发题、验证题和未见测试题。将12条已知基线用于开发时，系统维护者已经看过预期答案，不能再把它们当盲测成绩。未见题需覆盖常规关联、重复记录去重、日期边界、下属范围、负责人和参与者混淆、待审批建议、来源冲突、空结果和越权或非法计划。由业务审阅者在测试前固定答案与澄清标准；无法确定的题目标为“应澄清”，不强迫造出唯一数值。

至少报告以下指标，并分题型展示，不只给一个总准确率：

• 结果正确性：实体集合、聚合值和单位是否正确。
• 口径正确性：关系路径、状态筛选、日期边界、去重和范围是否符合定义。
• 澄清与冲突处理：含糊题是否提出有效问题；冲突是否保留来源、拒绝静默裁决。
• 安全拒绝：未知意图、错配关系和不允许的参数是否被拒绝；SQL是否只能来自白名单模板。
• 覆盖与可用性：可回答题占比、合理拒绝率、失败类型和空结果诊断质量。
• 运行成本：延迟、查询扫描量与负载、模型调用与人工审核时间。
• 治理成本：新增别名、规则、模板、测试和变更回归需要多少维护工作。

测试前应约定目标阈值和不可接受的高风险错误类型。只有在相同题目、相同数据和权限下运行并保留逐题记录，才有可比较的依据。当前这些条件与指标是实验设计，不是已完成的性能或准确率结果。

10. 结语：让答案可以解释和复算

一条可信查询不是“把本体文件交给模型”就自然出现。它需要确认资源和名称谓语能对齐，明确业务关系与时间口径，选定实际执行数据的存储，再由受控程序完成SQL参数绑定或SPARQL图模式匹配。查询结果还需要带着来源、版本、快照和异常一起交付。

本案例既能沿RDF实例用SPARQL查出林晓的40%和60%两条参与记录，也能沿有限查询计划在关系库中查出远山正在进行项目的四名参与者。前者适合观察图模式与IRI；后者展示如何把业务规则落实到受控SQL。这两题本身不能拿来证明跨语言等价；对林晓投入这一道相同问题，SQL与SPARQL返回的项目和比例逐项一致，才构成样本级对照。这仍不意味着任意本体都能自动编译成SQL。

下一次改动不应止于编辑一行YAML。业务Owner确认规则，维护者更新契约和映射，测试用例覆盖边界，执行器回归结果，发布记录保存版本与快照，才形成可追溯的治理闭环。是否使用虚拟图谱或物化RDF，也应以代表性查询和维护成本来验证，而不是由“本体”这个词预先决定。

附录：复现与阅读

本地 SPARQL 查询

若使用已有Fuseki数据集，在查询工作台选择 work_demo 并运行第3.2节的查询。把该查询保存为 example.rq 后，也可以只向查询端点发送读取请求：

curl --fail --silent --show-error \
  -H 'Accept: application/sparql-results+json' \
  --data-urlencode 'query@example.rq' \
  http://localhost:3030/work_demo/query

这是查询请求，不是导入或更新命令。服务地址须与已有配置一致；不能将失败的连接解释为“空结果”。如果数据装在命名图而非默认图，需要选择正确图或在查询中写 GRAPH <图IRI> { ... }，不要误把查询范围差异当作业务事实不存在。

进程内复现则可把 domain.owl.ttl、instances-aligned.ttl 和 example.rq 放在同一目录，在已安装RDFLib的Python环境中执行：

from pathlib import Path
from rdflib import Graph

graph = Graph()
graph.parse('domain.owl.ttl', format='turtle')
graph.parse('instances-aligned.ttl', format='turtle')
rows = [[str(value) for value in row]
        for row in graph.query(Path('example.rq').read_text())]
assert rows == [['客户数据治理', '40'], ['设备知识平台', '60']]
print(rows)

这验证的是文件加载和SPARQL匹配，不是Fuseki服务，也不是OWL推理。若查询 ?实例 a ex:NamedEntity 得到空结果，应检查实例是否只声明了更具体的类型；可以显式查询 ?实例 a ?类型 . ?类型 rdfs:subClassOf* ex:NamedEntity。其中属性路径 * 表示沿子类关系走零步或多步，这仍是图路径匹配，不是推理器为图补出了全部OWL蕴含。

本文样本的进程内复核得到246条实例、合并767条三元组和林晓两行结果；同题SQLite关系查询也得到相同项目与比例。Fuseki结果采用前述固定快照的服务记录，不能将离线核对冒充新一次服务执行。

受控 SQL 查询

已存在的PostgreSQL案例数据库可用只读执行器运行有限计划。不要在复现时重跑建表和种子脚本。没有PostgreSQL时，可在内存SQLite中装入等价教学样本，检查JOIN、日期谓词和结果断言；SQLite只能作为关系查询逻辑的替代验证，不能证明PostgreSQL驱动、事务或类型行为。

参考来源

1. W3C，《SPARQL 1.1 Overview》，2013-03-21，https://www.w3.org/TR/2013/REC-sparql11-overview-20130321/ 。
2. W3C，《SPARQL 1.1 Query Language》，2013-03-21，https://www.w3.org/TR/2013/REC-sparql11-query-20130321/ 。
3. Apache Jena，《Fuseki Documentation》，https://jena.apache.org/documentation/fuseki2/ 。
4. Apache Jena，《TDB2 - Use with Fuseki2》，https://jena.apache.org/documentation/tdb2/tdb2_fuseki.html 。
5. Apache Jena，《ARQ - Query》，https://jena.apache.org/documentation/query/ 。
6. PostgreSQL，《libpq - Command Execution Functions》，https://www.postgresql.org/docs/current/libpq-exec.html 。参数值与命令文本分离的机制及限制。
7. Benjamin Wan Rothschild，《Scaling AI-Native Analytics Patterns at Meta》，Analytics at Meta，https://medium.com/@AnalyticsAtMeta/scaling-ai-native-analytics-patterns-at-meta-b29162cb46bf 。文中Meta实践、管道规模和效果均为作者自述，未经本文独立核验。
8. Psycopg，《Basic module usage》，https://www.psycopg.org/docs/usage.html ，尤其是参数传递章节。
9. Ontop，《Ontop Guide》，https://ontop-vkg.org/guide/ 。关于虚拟知识图谱保留源数据、将SPARQL翻译为关系源SQL的定义。 案例数据、查询和历史验证信息来自本文配套的合成DDL、种子、RDF实例、查询计划及代码。它们只支持所列样本和检查范围，不构成生产系统效果或容量结论。