本体¶
本体是建立在数据模型之上的一套活的词汇。每个物理列都对应一个术语，含义相同的列共享一个术语，无论它们写法有多不同。每个术语都可以有定义、指向其他术语的类型化关系、一份领域专家名单，以及像 pii 这样的标签，具有该含义的每一列都会带上它。
它是一张由概念、概念的定义以及概念之间的关系构成的图。Provisa 把它映射到保存这些值的表和列上，因此能够回答关于你的数据的问题。术语在数据管家批准之前都是草稿，而它是否能到达数据，则由图推算得出。本体与指标是分开的：术语说明一个概念是什么，指标说明一个数字如何计算。
这套共享词汇把业务语言与物理数据连接起来。一个知道"customer"指代所有带客户标识符的列的 AI 智能体，不必去猜 cust_id、customerId 和 CUSTOMER_KEY 中哪一个才对。它们都对应同一个术语，而这个术语带着定义。
类、属性和概念¶
每个术语恰好有一个角色，由它锚定的对象推导而来。你永远不需要自己设置。
| 角色 | 锚定于 | 示例 |
|---|---|---|
| 类 | 一个或多个表或视图。它的实例就是这些表的行。 | customer，锚定 customers 和 crm_contacts |
| 属性 | 不是键的列。 | customer email，包含 customers.email |
| 概念 | 不直接锚定任何东西。它通过自己的关系到达数据。 | revenue，带有来自 order amount 和 refund amount 的 PART_OF 边 |
一个术语只能是其中一种。Provisa 拒绝把表锚定到包含非键列的术语上，也拒绝把非键列移到锚定于表的术语上。每次拒绝都会指出该术语以及它已经包含的内容。
每张有键的表都会提议一个类¶
保存一张有主键的表时，Provisa 会把它锚定到一个草稿类术语上，以表的概念命名：orders 提议 order，order_lines 提议 order line。同一概念的表共享一个类。没有主键的表不能成为类，锚定它会被拒绝，并指出该表。
你自己做的锚定，无论是在 UI 中、在配置中还是通过 Polly，都是经过策展的。同步从不移动它，把表锚定到经过策展的术语上会替换它的草稿提议。当一个概念已经是带有非键列的属性时，它的表不会得到提议；本体会改为把它们列在 待审核 下。
键属于类¶
主键没有自己的术语。它的每一列，包括复合键的各个部分，都把引用放在所属表的类上。
外键的做法相同。已声明关系中"多"的一侧的每一列，都把引用放在目标表的类上，无论该列叫什么名字。employees 上指回 employees 的 manager_id 落在 employee 上；"manager"这个角色体现在关系的名称里。没有已声明关系的列是属性，即使它的名字与某个类相同。
Provisa 只通过推导来放置键引用，时机是每次表同步、关系变化或表的类变化时。你不能手动移动键列，拒绝时会指出该列、它的表和它的类。把表锚定到另一个术语，它的键会立即跟过去。
同一实体出现在多张表中¶
来自不同表的实例在你另行说明之前都是不同的。当 customers 和 crm_contacts 描述的是同一个客户时，把连接它们的关系标记为 同一实体。它必须连接由同一个类锚定的两张表，一对一，基于每张表的一个键：主键或已声明的唯一约束。
只要一张表上存在同一实体关系，它的类就不能被撤回或替换。请先取消该关系的标记。
如果一个类锚定在多张表上，而同一实体关系没有把它们全部连起来，它会在 待审核 下被标记为 未关联的表。
术语如何推导¶
Provisa 使用一条确定性的规范化规则，自动从每个列名创建一个草稿术语：大小写统一、按分隔符和 camelCase 切分、展开缩写，以及去掉末尾的代理词元。
缩写展开 把常见的企业缩写映射为完整形式：cust → customer，txn → transaction，qty → quantity 等等。id 和 key 都展开为 identifier。这张表是固定且保守的。像 st、min 和 no 这样有歧义的缩写保持原样，以免猜错。
去掉代理词元 会移除末尾的 identifier、code、index 或 reference 词元。名为 cust_id 的列指的并不是标识符本身；它通过一个代理值指代某个客户。去掉代理词元后，cust_id 和 customerId 都落到术语 customer 上。只去掉末尾的词元，而且从不去掉最后剩下的那个，所以单独一个 id 列会展开为 identifier 并停在那里。
去重 才是目的。规则是确定性的，所以 cust_id、customerId 和 CUSTOMER_KEY 都得到 customer。每一列都在这一个术语上得到一个引用，策展只需要在一个地方添加定义，而不是三个。
键列跳过这条规则。它们的引用归到类上，如上所述。
通用短语¶
有些规范化后的短语太通用，单独不能构成一个概念。单独的 name、date 或 identifier 列指的是其所在表的概念的一个属性，离开那张表就不存在。员工有名字，产品也有名字，但它们不是同一回事。
当一个短语属于通用集合并且有表上下文可用时，术语会被限定为 <table concept> <phrase>：employees.first_name 规范化为 employee first name。
通用集合包括属性名词（name、date、status、type、amount、quantity）、审计追踪短语（created_at、modified_by、submitted_timestamp），以及其他几个几乎每张表都会出现的短语。
术语跟随业务名称¶
推导出的术语跟随列的 业务名称：建模者设置了别名时用别名，否则用物理名称。当 usr_nm 的别名是 user name 时，推导出的术语就是 user name，而展开 usr_nm 可能会得到 user number。
给列设置别名是更有力的修正。别名会传到每个读取该列的界面（SQL、GraphQL、AI 智能体、目录），因此模型在所有地方都能正确地描述自己。重命名术语只修正目录中的一个条目，下一个读者看到的列仍然是 usr_nm。UI 中的草稿横幅正是这么说的：先给列设置别名，只有当列名正确而词汇不对时才重命名术语。
重新设置列的别名会重新推导它的草稿术语，因此本体跟随模型，从不要求同一项修正做两次。一旦策展人为某个术语添加了定义、关系、专家或标签，修改别名就不会移动该列，因为那是策展人的工作，会被保留。
访问路径式表名¶
有些表名描述的是访问路径而不是概念：user_by_name 是通过按名称查找得到的用户，并不是另一种实体。Provisa 推导表的概念时，会在连接词处截断名称，因此 user_by_name 变成 user，orders_by_customer 变成 order。
如果不截断，user_by_name 会提议一个类 user name，与真正的属性 users.name 冲突。截断只适用于表的概念。在列名中，by 是复合名词的一部分，所以 pet_by_name 和 pet_name 规范化为同一个术语 pet name。
为什么批准和锚定很重要¶
智能体和其他自动化通过本体找到它们要处理的数据，并引用它。智能体从一个由人批准的术语出发。它沿着一条路径向下走到它能看到可信度的数据，这些数据要么已锚定，要么仍在等待批准。它到达的表和列，是它在自己角色的授权、行规则和掩码之下读取的。这条路径上的每一步都有一个名字，智能体可以把它写进引用。
因此，一个术语的两个事实决定了智能体能用它做什么。人设置它的 状态。Provisa 计算它的 锚定。页面把它们显示为两个独立的标记，你可以分别按它们筛选。
状态¶
术语的状态由人设置。一个术语同一时间只有一个状态。
| 状态 | 含义 | 如何进入该状态 |
|---|---|---|
| 草稿 | 尚未批准。 | 每个推导出的术语都从这里开始，你创建的每个术语也一样。 |
| 已批准 | 数据管家的决定：这是可以使用的词汇。 | 由数据管家批准。批准需要有定义。 |
| 已弃用 | 正在退出。 | 策展人弃用一个已批准的术语，或者一个经过策展的术语失去了最后一列。 |
| 已停用 | 不再使用，作为记录保留。 | 策展人停用它并指定一个继任者。 |
仅有定义并不会批准任何东西。当术语的定义说明了业务对它的理解时，再批准它。
锚定¶
锚定说明一个术语是否能到达数据。没有人设置它：每当图发生变化，Provisa 都会根据术语的关系把它推算出来。
一个术语的锚定沿着它自己通往数据的路径向下看。路径从该术语出发，经过它的关系，到达第一个包含列或表的术语：位于数据端、持有绑定的那个术语。只有严格位于两端之间的术语才计入。术语本身从不影响自己的锚定，它上方的任何东西也不会。
| 锚定 | 标记 | 含义 |
|---|---|---|
| 已锚定 | 绿色 ⏚ 图标 | 某条向下的路径在该术语和数据端之间没有草稿术语。 |
| 已锚定 · 路径待批准 | 灰色 ⏚ 图标 | 每条向下的路径中间都有草稿术语。将鼠标悬停在图标上，会显示"能到达数据，但只经过尚未批准的术语"。 |
| 未锚定 | 无 | 没有路径能到达数据。 |
这个图标是电气接地符号。它出现在术语列表中的列数旁边、术语页面上、图中术语名称之前，以及图例中。已锚定术语的悬停文字会说明它能到达多远，例如"已锚定：在 3 列中到达数据"；屏幕阅读器会读出同样的文字。
有几种情况直接由这条规则得出：
- 你在一条已批准的链上方起草的草稿概念是已锚定的。它的状态标记仍然显示草稿，它下方的术语不会改变。
- 从列推导出的术语是数据端的草稿。它从不让上方的链变成待批准。
- 唯一路径中间的一个草稿术语会让它上方的每个术语都变成灰色 ⏚。批准这一个草稿，就能锚定它们。
- 有第二条干净的路径就够了。旁边的草稿不会改变任何东西。
- 已弃用和已停用的术语会断开链。唯一路径经过这类术语的术语不再是已锚定的，它的标记和筛选器都会反映这一点。
智能体看到什么¶
MCP 术语搜索、SPARQL 的词汇以及其他所有面向智能体的界面，向智能体展示的是本体的同一部分：
- 位于通往数据路径上的已批准术语；
- 位于通往数据、且至少包含一个已批准术语的路径上的已定义草稿术语，并标记为草稿；
- 这类路径上的未定义术语，只作为匿名的一步出现，没有名称和定义。每一步保持独立，因此路径的形状不变。
除此之外，没有任何东西会到达智能体。没有已批准术语的链保持隐藏，到达不了数据的术语以及已弃用或已停用的术语也一样。人可以在本体页面上看到每个术语，以及它的状态和锚定。
每条搜索结果都带有术语的状态和锚定、它的列和表、它的专家，以及它通往数据的路径。路径上的每一步要么是有名称的术语，要么是匿名的一步，数据端会列出它绑定到什么。这条路径就是智能体遵循和引用的路径。
弃用术语¶
当一个已批准的术语正在退出时，弃用它。你需要给出原因，这是必填的，还可以选择一个计划停用日期，今天或之后。到了那一天，调度器会停用它。从你弃用它的那一刻起，已弃用的术语就会断开经过它的链，所以值得先看一下影响预览。
一个已到停用日期但仍包含列或表的术语不能按日期停用，因为只有继任者才能接手这些列和表。它会等待，待审核 会把它列为 停用受阻，直到你用继任者停用它。
一个经过策展的术语失去最后一列时，会被自动弃用并保留。它退出使用，保留编辑者提供的内容，如果同一列再次出现，它会回来。一个没有经过策展、也没有剩余列的术语会被删除。
停用术语¶
停用一个术语会把附属于它的一切移到一个 继任者 上，然后让它退出使用。
- 属性的列移到继任者上。继任者必须是属性或概念。
- 类的表移到继任者上，它们的键随之移动。继任者必须是类或概念。
- 概念不包含任何东西，所以它的继任者是可选的。
停用需要原因，并会写入一条从继任者指向被停用术语的 REPLACES 边。被停用的术语作为惰性记录保留：它的定义、标签、关系、专家和原因。它不传导任何东西。继任者保持自己的状态；停用从不批准它。
由于它的列现在属于继任者，被停用术语的面板会显示它 最后适用于 什么：即停用前那次提交中模型所记录的它的列和表。它的面板还会链接到替代它的术语。
恢复术语¶
恢复 撤销策展人所作的声明。已弃用的术语重新变为已批准。已停用的术语以空概念和草稿的形式回来，因为它的列已经归继任者所有，它的 REPLACES 边会被删除。
什么让术语成为经过策展的¶
由列规范化产生的术语一开始是空白的。只要它具有以下任一项，就成为经过策展的：
- 已保存的定义
- 一条关系边
- 一位已分配的领域专家
- 一个标签，例如
pii - 一次停用
经过策展的术语在其列离开时会被保留。同步从不把经过策展的术语的列重新推导到别处。
从表重新同步¶
每次保存或重新加载一张表时，Provisa 都会把该表的列与本体进行核对。新列会创建或关联术语，离开的列会放弃它们的引用，任何没有剩余引用的术语都会按上面的规则被删除或弃用。键列归到它们的类，没有类的有键表会提议一个类。
只有未经过策展的术语才会被重新推导。如果你给一列设置别名，它的草稿术语随之变化，该列会移到新术语上。如果术语是经过策展的，该列保持不动，因为修改别名不会推翻策展人的选择。
当删除一个术语会让某个概念失去通往数据的路径时，Provisa 会改为弃用该术语，这样你搭建的结构会保留下来，直到你重新连接它。
关系¶
术语通过类型化的边与其他术语相关联。
| 类型 | 含义 |
|---|---|
KIND_OF |
源术语是目标术语的一种。 |
PART_OF |
源术语是目标术语的组成部分。 |
SYNONYM_OF |
两个术语在这个领域中可以互换。 |
RELATED_TO |
两个相关但不同的主题，在没有其他类型适用时使用。它占位，不锚定。 |
VALID_VALUE_OF |
源是目标枚举或值域的一个允许值。 |
DERIVED_FROM |
源由目标计算得出或来源于目标。 |
REPLACES |
源取代目标。停用一个术语时，会从它的继任者写出一条这样的边。 |
PREFERRED_TERM_FOR |
相对于不推荐使用的目标，源是首选术语。 |
TRANSLATION_OF |
源是目标在某种语言或区域设置下的译文。 |
ANTONYM_OF |
源在语义上与目标相反。 |
关系是有方向的。UI 同时显示出边（本术语 → 另一个术语）和入边（另一个术语 → 本术语），并为每个方向标注各自的通俗说法。
这些边存放在一张声明为连接关系的关联表中。它的关系类型列是鉴别器，所以上面每种类型都是两个术语节点之间一种独立的 Cypher 关系类型。这里没有任何本体专用的东西：它的声明方式与你在自己的表上声明连接的方式一样，读取它的也是同一套代码。
构建能锚定的词汇表¶
只有已锚定的术语才对智能体有帮助，也就是说，要有某条关系路径从它通向一列或一张表。智能体只能看到这类路径上的术语，如 智能体看到什么 所述。已锚定的术语告诉你它的数据在哪里。未锚定的术语只给一个想法起了名字，找数据的事留给你自己。
你选择的关系类型决定这条路径是否存在。锚定从较宽的术语向下通往较窄的术语。revenue 能到达数据，是因为 order amount 是它的一部分，而 order amount 包含一列。锚定从不反向传递，所以 order amount 不会因为是 revenue 的一部分而得到任何东西。
选择类型之前先逐一检验¶
读一条边时，把它出发的术语看作 X，把它指向的术语看作 Y。然后按下面的顺序应用检验，取第一个通过的。
| 类型 | 检验 | 示例 | 锚定什么 |
|---|---|---|---|
| 是一种 | 每个 X 都是一个 Y。 | 每个企业客户都是一个客户。 | Y 到达 X 的数据。 |
| 是其一部分 | 一个 Y 有一个 X。 | 一个订单有一个订单金额。 | Y 到达 X 的数据。 |
| 是其有效值 | X 是 Y 的允许值之一。 | 白金是一个客户等级。 | Y 到达 X 的数据。 |
| 同义词 | X 和 Y 含义相同。 | 客户和顾客。 | 双方互相到达对方的数据。 |
| 相关于 | X 和 Y 是相伴出现的不同主题，彼此既不是对方的一种、一部分，也不是对方的值。 | 蛋糕和蜡烛。 | 什么都不锚定。 |
派生自、取代、是其首选术语、译自和反义于各自记录关于两个术语的一个事实。它们都不锚定。
描述一个概念的属性是这个概念的一部分。班次开始描述的是一个班次，所以它 是其一部分，属于班次覆盖。它从来不只是与之"相关"。
当你添加关系或更改其类型时，类型选择器会先列出"是一种"、"是其一部分"和"是其有效值"，每个下面都附有检验。"相关于"排在最后，附有它的检验以及它不锚定的提醒。选择器下方的 如何选择能锚定的关系 链接会打开本节。
"相关于"只是占位¶
"相关于"是最后的手段。由于它不锚定，一个所有链接都是"相关于"的术语无论有多少链接，都到达不了数据。把每条这样的链接都当作一个占位符，代表一对你还没有解决的术语。
要逐一处理这些占位符，请在术语列表上方 已弃用 和 待审核 旁边勾选 相关于。列表会缩小到至少有一条"相关于"链接（在任一端）的术语。复选框旁边的书本图标会打开本节。
一个到达不了数据、且只有"相关于"链接的术语，会在其页面上显示一条提示。提示说明这对术语可能缺少一个中间术语，并列出能解决它的形式。这只是指引。术语的任何操作都不会被阻止。
用一个新术语解决一对术语¶
大多数"相关于"术语对都缺少一个中间术语。一个新术语就能把占位符变成两条能锚定的边，有五种形式可以做到。下面以蛋糕和蜡烛为例，从最紧的开始：
| 形式 | 新术语 | 边 |
|---|---|---|
| 组成类型 | 蛋糕装饰 | 蜡烛 是一种 蛋糕装饰；蛋糕装饰 是其一部分 蛋糕 |
| 特化 | 生日蛋糕 | 蜡烛 是其一部分 生日蛋糕；生日蛋糕 是一种 蛋糕 |
| 共同整体 | 派对 | 蛋糕 是其一部分 派对；蜡烛 是其一部分 派对 |
| 共同类属 | 派对用品 | 蛋糕 是一种 派对用品；蜡烛 是一种 派对用品 |
| 共同枚举 | 派对物品类型 | 蛋糕 是其有效值 派对物品类型；蜡烛 是其有效值 派对物品类型 |
沿每一行向下追踪锚定。在前两种形式中，蛋糕通过新术语到达蜡烛的数据。在后三种形式中，新术语是两条边中较宽的一端，所以它到达两者的数据。蛋糕和蜡烛都到达不了对方的数据。
有时中间术语已经存在，只需要更改链接的类型。随附的收容所演示中有一个概念 shift coverage，定义为一名员工被排班工作的时间段和地点。它的组成部分 shift start、shift end 和 schedule location 各包含一列。当它们通过"相关于"相连时，shift coverage 到达不了数据。把这三者都链接为"是其一部分"指向 shift coverage 之后，它就通过这三列被锚定了。这是一个共同整体，而这个整体一直都在。
优先选择最紧的形式¶
新术语越宽，它的锚定告诉读者的就越少。派对连接蛋糕和蜡烛，和蛋糕装饰一样可靠。但这么宽的枢纽还位于宾客名单、场地和音乐之上，所以它的锚定不再说明哪些数据能回答关于蜡烛的问题。蛋糕装饰给智能体一条通往正确列的短路径。派对给它一条通往许多列的长路径。
从组成类型开始，只有当更紧的形式不适用时才往下选。当这对术语没有更窄的共同点时，再使用共同类属或共同枚举。
当你选择"相关于"时¶
为正在添加的链接选择 相关于 会打开一个对话框，例如"用"相关于"连接 蜡烛 和 蛋糕？"。把现有链接的类型改为"相关于"也会打开它。这种打断是有意的，因为此刻修正链接的代价最小。
对话框首先解释为什么"相关于"是最没用的边。它不锚定，所以术语仍然无法通过它到达数据。在此之下，它为你的两个术语画出五种形式，从最紧的开始。每种形式都显示一个新术语的名称，由你所在组织的 AI 模型建议，例如 蜡烛 → 蛋糕装饰 → 蛋糕。如果模型没有建议名称，对话框会说明原因，由你自己输入名称。
然后你从三个操作中选一个。
- 形式旁边的 开始 会打开新术语表单。建议的名称已填好，随之添加的关系 列出两条边。你可以重命名术语、添加定义和领域，然后点击 创建。创建会添加该术语。与你正在编辑的术语相连的那条边会加入你的表单，并随表单一起保存。另一条边会立即写入。
- 仍然添加"相关于" 一键添加该链接。它会加入 相关于 筛选器所列出的占位符中。
- 取消 不做任何更改。
关系助手如何选择¶
✨ 菜单中的 关系 会请你所在组织的 AI 模型为你的领域中的所有术语提出关系。模型的指令包含同样的检验。只要有一个适用，它就优先选择"是一种"、"是其一部分"和"是其有效值"，并用"是其一部分"把属性链接到它所描述的概念。只有当两个术语明显相伴、且没有其他类型适用时，它才提出"相关于"。
助手只链接已经存在的术语，从不添加术语。对于它添加的每条"相关于"，它会为每种适用的形式给出候选术语。完成后，待审查的"相关于"链接 会列出每一对这样的术语，附上从最紧开始排列的形式以及每种形式的候选。点击任一术语即可打开它。一对术语是否需要新术语、该叫什么名字，由你决定。
衡量词汇表¶
Ontology quality 报告根据模型衡量词汇表，按领域和按数据管家统计。请在 报告查看器 中打开它。它报告：
- 在用术语中已锚定的比例，完全锚定的与待批准的分开统计；
- 已批准且已锚定的比例，即智能体可以使用的术语；
- 未解决的占位符，即"相关于"链接，以及所有链接都是"相关于"的术语；
- 锚定精度，即每个术语到数据的步数，以及经过宽泛枢纽术语的路径数量；
- 仅通过草稿锚定的术语，每个都附上批准后能使其完全锚定的那个术语；
- 通往数据路径上的未定义术语；
- 漂移，即自上一周期以来失去或获得锚定的术语。
每一行都链接到它的术语，每个占位符行都链接到该术语的"相关于"链接以供审查。与所有报告一样，它以你的角色通过受治理的管道读取，你也可以导出它。
概念¶
概念没有自己的列或表。用它来表示一个跨越多个具体术语的业务想法，然后把它连接到确实包含数据的术语上。例如，revenue 可以是一个概念，带有来自 order amount、adjustment amount 和 refund amount 的 PART_OF 边。
一个无法通过关系图到达任何列或表的概念不指代任何数据。它不会出现在智能体的术语搜索中，也不会出现在元数据导出中，待审核 会把它列为 无数据。领域只适用于概念。其他术语的领域都来自它锚定的表或它包含的列。
按含义标记 PII¶
PII 是列的含义所具有的属性，所以 Provisa 让你在术语上标记一次，就能覆盖具有该含义的每一列，包括以后注册的列。
pii 标签放在列或属性术语上，从不放在源、表、类或概念上。术语必须已定义且未停用，才能接受它。标记草稿术语会被拒绝，提示"请先定义 术语 再标记"，而且在取消标记之前，你不能清除已标记术语的定义。
已标记术语的每一列都带有 pii，并同时带有 sensitive，凡是读取标签的地方都如此：治理、掩码、敏感度、导出和标签视图。不会向列复制任何东西。移到该术语上的列立即带上标签，移走的列则不再带有。每一列都会说明它的标签来自哪里：设置在列上的，附带原因；或者来自某个术语，并指出是哪个。
当你标记一个其术语是属性的列时，UI 会询问是否同时标记含义相同的其他列。
- 是 把标签放在术语上。
- 只标记这一列 只标记这一列，并询问原因。
通过术语而成为 PII 的列不能单独取消标记。请取消术语的标记，或者把该列移到与其内容相符的术语上。
会丢失标签的移动¶
把列移到另一个术语可能会让它失去标签：把 customers.email 从 customer email（带 pii 标签）移到一个没有标签的术语，会让电子邮件列失去保护。人做的每一次移动都会事先检查。这包括认领或移动列、停用术语，以及保存或删除会重新归属键列的关系。
当某列将完全不再带有 pii 时，移动会被拒绝，直到你作出决定。UI 会显示一份摘要，列出每个被移动的列失去和获得的内容，失去的排在前面。
- 移动 继续执行，并确认每个丢失的标签。
- 移动并标记 在同一次更改中，把丢失的标签带到列所移入的术语上。
- 取消 不移动任何东西。
靠自己的标记保留标签的列不需要确认。模型自己做的移动，例如重新推导草稿的列，从不改变继承来的标签。
待审核¶
本体以发现项的形式报告需要你关注的事项。任何有发现项的术语都处于 待审核，术语列表可以按此筛选。普通草稿不是发现项；草稿是本体的常态。只通过草稿到达数据的术语是发现项，因为一次批准就会把它呈现给智能体。
| 发现项 | 含义 | 修复方法 |
|---|---|---|
| 未关联的表 | 一个类锚定了多张表，而同一实体关系没有把它们全部连起来。 | 在它们之间标记同一实体关系。 |
| 类与属性 | 一个类包含不是其键的列，或者一张有键的表因为其概念是属性而没有类。 | 把这些列移到一个属性上，或者重新锚定该表。 |
| 标签放错类型 | 一个不是属性的术语带有只有属性才会传给列的标签。 | 取消该标签。 |
| 停用受阻 | 一个已弃用的术语已过计划停用日期，但仍包含列或表。 | 用继任者停用它。 |
| 无数据 | 一个草稿概念到达不了数据。 | 把它关联到一个包含数据的术语。 |
| 已批准但未锚定 | 一个已批准的术语到达不了数据，所以没有智能体能看到它。 | 把它关联到一个包含数据的术语。 |
| 已锚定 · 路径待批准 | 每条通往数据的路径都经过一个草稿。发现项会指出批准后能锚定该术语的那个草稿。 | 打开那个术语并批准它。 |
发现项只做报告；在你采取行动之前，它们不改变任何东西。
元数据导出¶
作为元数据导出的一部分，本体会发布到外部数据目录。已批准的术语会被发布，每个都带有它的锚定：grounded、grounded_pending 或 not_grounded。草稿永远不会离开 Provisa。导出用的锚定依据实际发布的列和表来判断。如果一个术语的列全部被排除在导出之外，原因是它们的表不是数据产品，或者被技术筛选器排除，该术语也会随之被排除。
一个已批准、但后来被策展人弃用的术语，会连同它的状态、原因和计划停用日期一起发布，以便每个目录把它映射到自己的弃用标记上。
只有当两端的术语都发布时，关系边才会发布。列资产独立导出，因此排除一个术语不会隐藏底层数据。
把术语排除在导出之外¶
有些列承载的是底层管道信息，例如 ETL 批次标识符、行版本和摄取时间戳。从这类列推导出的术语可能有准确的定义，但仍然不是业务词汇。从元数据导出中排除 控件会把该术语以及所有终止于它的关系边，排除在 Provisa 发布到的目录之外。列本身仍作为资产导出。
关键在于业务是否使用这个词。ETL 批次标识符有明确的含义，对工程师来说属于本体，但不属于与 customer 和 revenue 并列的业务目录。
使用本体¶
在导航栏中打开 本体。左侧面板列出每个术语，包括它的角色、它的状态（已批准时不显示）以及它的锚定标记。状态 和 锚定 筛选器分别按这两项缩小列表，已弃用 复选框显示或隐藏已弃用的术语，待审核 把列表缩小到有发现项的术语，相关于 把列表缩小到有"相关于"链接的术语。点击一个术语即可打开它的面板。
面板并排显示术语的角色、状态和锚定；对于属性，还会显示它的 PII 标记以及它覆盖的列数。灰色 ⏚ 的术语会列出批准后能锚定它的草稿。已弃用或已停用的术语会显示是谁更改了它的状态以及原因。有发现项的术语打开时会带有 待审核 部分：点击一个发现项，即可看到发现了什么以及修复它的操作。
管理摘要¶
没有打开任何术语时，面板显示管理摘要。它列出智能体能看到的术语、各自等待一次批准的灰色 ⏚ 术语（附上要批准的术语），以及到达不了数据的已批准术语。批准已定义且已锚定的草稿 列出每个有定义且已锚定的草稿；取消勾选定义不对的草稿，然后一起批准其余的。标题栏中的剪贴板按钮可以把摘要调回来。
先查看影响¶
批准、停用和绑定术语都会改变能到达数据的内容。在执行其中任何一项之前，页面会显示该操作将改变什么：多少术语会变成已锚定、灰色 ⏚ 或未锚定，以及智能体会获得或失去通往多少张表的路径。例如"批准 region 会让 3 个术语变为已锚定，并让智能体获得通往另外 2 张表的路径"。批准 会打开带有确认按钮的预览，停用 会在你选择的继任者下方显示预览，在编辑表单中锚定表时，则会在保存前于该表下方显示预览。
编辑 把整个术语作为一个表单打开。保存会把所有更改一起应用。
- 重命名 术语，可以改变它的措辞而不移动它的列。
- 添加定义：直接输入，或者点击 AI 草稿按钮，根据术语的名称、列和关系生成一个起点。在你保存表单之前，草稿不会被保存。
- 认领列：把其他术语的列移到这个术语上，或者在它自己的某一列旁边选择 移到术语。每一列只属于一个术语。键列跟随它们的类，不能移动。
- 锚定表 到一个类上，或者移除它们。
- 在属性上 标记 PII。
- 添加关系，并选择它的类型。就地更改现有边的类型，而不是删除后重新添加。
- 按用户 ID 分配专家，角色为
expert或author。
在"编辑"旁边，面板提供该术语允许的状态操作：批准 已定义的草稿，弃用 已批准的术语，停用 任何在用的术语，以及 恢复 已弃用或已停用的术语。
在 ✨ 菜单中，定义 一次性填写所有空白定义，从不覆盖人写的文字。关系 在整个术语列表中添加类型化的边；提到未知术语、同一个术语两次或无法识别的类型的提议会被丢弃。它添加的每条"相关于"都会列出以供审查，如 关系助手如何选择 所述。
术语上的 草稿 横幅会告诉你它是还需要定义（给列设置别名或添加一个定义），还是只需要你的批准。另一个横幅会在术语到达不了数据时提示你：把它关联到一个有数据的术语。
查询本体¶
本体是一个可以查询的模式，名为 ontology，与描述模型结构的 meta 模式并列。它的表都以下划线开头，因此类自己的表永远不会与其中任何一张重名。
| 表 | 每一行对应 |
|---|---|
_terms |
一个术语，带有它的状态、锚定、定义，以及它是类、属性还是两者兼是 |
_term_refs |
属性与列的一个绑定，带有该列的表和领域 |
_term_edges |
两个术语之间的一个关系 |
_domains |
术语所属的一个领域 |
_experts |
分配给术语的一位专家或作者 |
_axioms |
本体在 RDFS、OWL 和 SKOS 中的一条陈述 |
_closure |
一个术语，与它在任意深度上所属的每个术语配对，也与它自身配对 |
绑定把术语与 meta 模式中的列连接起来，所以你可以把 ontology._term_refs 与 meta.table_columns 和 meta.registered_tables 连接。本体的表是只读的。它们会随着你策展术语而变化。
只有当你能到达术语的某个领域时，你才能读取它。没有领域的术语对所有人可见，企业术语（*）也一样。当关系或公理的两个术语都可见时，它才可见。
SPARQL 中的本体¶
SPARQL 以标准词汇返回本体，因此 RDF 工具读取它的方式与读取任何 OWL 本体相同：
- 类是
owl:Class，类之间的"是一种"关系是rdfs:subClassOf； - 属性是
owl:DatatypeProperty，或者当它绑定的每一列都是指向有类的表的键时，是owl:ObjectProperty； - 属性的
rdfs:domain是它所绑定的列所在的每张表的类，它的rdfs:range是它的键所指向的类，或者是它的列的 XML Schema 类型； - 属性之间的"是一种"关系是
rdfs:subPropertyOf； - 每个术语的名称是
skos:prefLabel，定义是skos:definition。
术语以它的词汇 IRI 命名，即 <your Provisa address>/vocab/term/<name>，这个 IRI 为它所锚定的表中的行指定类型。已停用的术语不作任何陈述。
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
SELECT ?class ?parent ?label WHERE {
?class a owl:Class ; rdfs:subClassOf ?parent .
?parent skos:prefLabel ?label .
}
查询可以把本体与你读取的行连接起来。一个类的实例包括在任意深度上属于它的一种的每个类的实例：
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX term: <https://your-provisa/vocab/term/>
SELECT ?party ?class WHERE {
?party a ?class .
?class rdfs:subClassOf* term:Party .
}
属性的用法相同：?x ?p ?v . ?p rdfs:subPropertyOf* term:amount 读取每个属于 amount 的一种的属性的值。你得到的是你读取的表中的实例，所以一个你无法读取其表的类不会贡献任何实例。
同样的陈述在 SQL 中是 ontology._axioms 的行，而在任意深度上闭合的"是一种"配对是 ontology._closure 的行。GraphQL、Cypher 和其他查询语言不提供这两张表。
另请参阅¶
本体模式¶
ontology 系统模式让你可以通过 SQL、GraphQL、Cypher、REST 和 MCP 查询词汇，也就是你访问自己数据时所用的同一组界面。它与 meta 并列，后者保存模型的结构；ontology 保存它的含义。
该模式由两部分组成：定义视图和类表。
定义视图¶
五个视图展示词汇表的内容：
| 视图 | 内容 |
|---|---|
_terms |
每个术语：名称、角色（类、属性、概念）、定义、状态和锚定。 |
_term_refs |
每个术语与列的绑定：术语名称、源、表和列。 |
_term_edges |
每条关系边：源术语、边类型和目标术语。 |
_domains |
领域归属：术语名称及其所属的每个领域。 |
_experts |
专家分配：术语名称、用户 ID 和角色（expert 或 author）。 |
第六个视图 _axioms 保存该模式能表达的每一个 RDFS/OWL/SKOS 三元组，每个三元组一行，列为 subject、predicate、object、object_iri 和 object_literal。当对象是术语时，object 给出它的名称；当它是 IRI 时，由 object_iri 保存；当它是字面量时，由 object_literal 保存。每一行中，这三列里有一列保存值。偏好三元组而非表格行的工具从这里读取。
术语绑定，即绑定到列、记录在 _term_refs 中的术语，不同于命令绑定。术语绑定说明一列是什么含义；命令绑定则把一个函数接入查询管道。
类表¶
每个未停用的类术语都会成为 ontology 模式中以该术语命名的视图，空格替换为下划线。锚定在一张表上的类生成一个视图；锚定在多张表上的类生成这些表的并集。
在并集视图中，会出现每张源表的行。_source_table 列标识每一行来自哪张表：它保存表的限定名 domain.table。某张源表没有绑定的属性列，在该表的行中为 NULL。绑定到同一张表中多列的属性会成为数组列。
类视图中的每一列都对应一个已绑定的属性。该视图通过与其他任何读取相同的管道受到治理。
示例。 一个类 customer 锚定在 sales.customers 和 crm.contacts 上，带有一个绑定到 customers.name 和 contacts.full_name 的 name 属性，以及一个只绑定到 customers.segment 的 segment 属性：
-- rows from both tables; segment is NULL for crm.contacts rows
SELECT _source_table, name, segment
FROM ontology.customer
WHERE segment = 'enterprise';
读取权限¶
适用于你自己的表的治理规则同样适用于这里。
只有当你能到达术语的至少一个领域时，它才会出现在定义视图中。没有领域的术语对所有人可见。只有当绑定行的列提供给你时，该行才会出现。只有当边的两个术语都对你可见时，该边才会出现。只有当类视图中属性列的底层列都提供给你时，该属性列才会出现。
不需要特殊权限。如果你能查询一张表，就能查询锚定在它上面的类术语。
SPARQL¶
SPARQL 端点把 ontology 模式作为标准的 RDFS/OWL/SKOS 本体提供。每个类术语成为 owl:Class，每条"是一种"边成为 rdfs:subClassOf，每个属性术语成为带有 rdfs:domain 和 rdfs:range 的 owl:DatatypeProperty 或 owl:ObjectProperty，子属性边成为 rdfs:subPropertyOf，名称成为 skos:prefLabel，定义成为 skos:definition。同样的读取权限适用。
所有术语的基础 IRI 由 server.public_url 设置推导而来，位于 /vocab/term/ 路径下。名为 customer 的类术语的 IRI 是 {public_url}/vocab/term/customer。
本体专家会写的三个查询：
查找 Party 在任意深度上的所有子类型：
PREFIX : <{public_url}/vocab/term/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT ?c WHERE {
?c rdfs:subClassOf* :Party .
}
使用术语 IRI 查找有细分值的客户：
列出在 Customer 上声明的所有属性及其值域：
PREFIX : <{public_url}/vocab/term/>
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT ?p ?range WHERE {
?p rdfs:domain :Customer ;
rdfs:range ?range .
}
把 {public_url} 替换为你的部署在 server.public_url 中配置的公共地址。