本體¶
本體是建立在數據模型之上的一套活的詞彙。每個實體欄位都對應一個術語，含義相同的欄位共用一個術語，無論它們寫法有多不同。每個術語都可以有定義、指向其他術語的類型化關係、一份領域專家名單，以及像 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 中設定的公開地址。