---
name: ontology-draft
description: 依 Ontology Development 101 的方法，替一個業務領域草擬本體（ontology）：它必須回答的能力問題（competency questions）、附白話定義的核心類別、含基數的屬性與關係、範例實例，以及命名規則，並用非工程師也能審閱的表格呈現。團隊要定義業務的核心概念、用白話設計資料模型、建立本體、分類體系（taxonomy）、知識圖譜的 schema，或釐清「我們追蹤哪些東西、它們之間有什麼關係」時使用。
---

# 本體草稿

本體是一份大家同意的清單：業務上談到的東西（類別）、我們為它們記錄什麼（屬性），以及它們之間的關係；定義要精確到兩個人會把同一件事歸到同一個地方。Noy 和 McGuinness 的 Ontology Development 101 先用能力問題設定領域和範圍，也就是本體必須能回答的問題；我們也這麼做，因為回答不了自己問題的本體一定缺了什麼，而回答沒人會問的問題的本體則太大了。

## 適用情境

- 在替單一領域建立知識圖譜、CRM 結構、資料倉儲或 RAG 系統之前。
- 不同團隊用同一個詞指不同的東西（「客戶」、「帳戶」、「使用者」）時。
- 試算表長出一堆沒人說得清楚的欄位時。
- 不適用於從既有文件中擷取事實：類別確定後，請用 knowledge-graph-extraction。

## 需要準備

- 領域和它的邊界（「B2B 訂閱，從報價到續約」，而不是「整個業務」）。
- 誰會使用這個本體、用來做什麼。
- 範例文件、試算表或系統欄位。如果沒有，就根據領域描述來做，並把類別標上「[提案]」。
- 團隊已經在用的既有標準（產業 schema、schema.org、CRM 的物件）。合用的地方就沿用它們的名稱。

## 步驟

1. **寫出 5 到 10 個能力問題。** 本體必須回答的真實問題：「哪些帳戶會在接下來 90 天內續約？各由誰負責？」這些問題界定工作範圍，最後也用來測試。
2. **列出詞彙。** 把問題和參考資料中的每個名詞和動詞都列出來，先不整理結構。
3. **挑出類別，每個用一句話定義。** 類別是一種有實例的東西。定義格式：「[類別] 是一種 [上層類別]，其特徵是 [區別特徵]。」把同義詞合併成一個類別，並記下同義詞。如果某個東西會進出某種狀態（「活躍客戶」），就把它做成屬性值，而不是類別。
4. **建立階層。** 每個子類別都必須「是一種」它的上層類別。避免只有一個子類別的類別，也避免超過大約十幾個直接子類別。不能共用實例的類別，標為互斥（disjoint）。
5. **加上屬性和關係。** 把每個屬性掛在擁有它的最上層類別上。每個屬性寫出：名稱、值的型別（文字、數字、日期、另一個類別），以及基數（剛好 1、0 或 1、1 或以上、0 或以上）。重要的關係加上反向關係（owns / owned_by）。
6. **每個核心類別建立 2 到 3 個範例實例。** 要貼近真實，但是虛構的。如果範例放不進去，就是類別或屬性錯了。
7. **用能力問題測試。** 每個問題都標出由哪些類別和屬性回答。回答不了的問題，代表缺了什麼；沒有任何問題用到的類別，是可以刪掉的候選。

本技能預設的命名規則：類別用單數的 UpperCamelCase（SalesOpportunity），屬性用 lower_snake_case，並以動詞或「has」開頭（has_owner、renews_on），不用縮寫，名稱中不放「class」或「type」之類的字。

## 輸出格式

```markdown
# 本體草稿 — [領域]
**範圍：** [邊界] · **使用者：** [誰、用來做什麼] · **狀態：** 草稿

## 能力問題
1. [問題]

## 類別
| 類別 | 上層類別 | 定義 | 同義詞（不使用） |
|---|---|---|---|

## 屬性與關係
| 屬性 | 所屬類別 | 值的型別 | 基數 | 反向 | 定義 |
|---|---|---|---|---|---|

## 範例實例
| 實例 | 類別 | 屬性值 |
|---|---|---|

## 問題涵蓋情形
| 問題 | 由什麼回答 |
|---|---|

## 命名規則
- [規則]

## 待決事項
- [需要決定的事、選項]
```

## 範例

**輸入：** 「領域：我們的 SaaS 訂閱。我們賣給公司；每家公司可以有好幾個工作區；每個工作區有一個方案和席次。大家會把公司叫做『帳戶』或『客戶』。我們需要知道誰在什麼時候續約、每筆續約由誰負責，以及哪些工作區超過了席次上限。」

**輸出：**

```markdown
# 本體草稿 — SaaS 訂閱
**範圍：** 公司、工作區、訂閱、續約 · **使用者：** 客戶成功和財務團隊，用來追蹤續約 · **狀態：** 草稿

## 能力問題
1. 哪些訂閱會在接下來 90 天內續約？每筆續約由誰負責？
2. 哪些工作區使用的席次超過方案上限？
3. 每家公司有幾個工作區？

## 類別
| 類別 | 上層類別 | 定義 | 同義詞（不使用） |
|---|---|---|---|
| Company | — | 購買或可能購買我們產品的法人 | 帳戶、客戶、組織 |
| Workspace | — | 公司的使用者登入的、我們產品中一個獨立的區域 | 執行個體、租戶 |
| Subscription | — | 某個工作區在一段期間內使用某個方案的付費協議 | 合約、授權 |
| Plan | — | 有名稱、價格和席次上限的方案組合 | 等級 |
| Person | — | 我們記錄的一個人 | 聯絡人、使用者 |

## 屬性與關係
| 屬性 | 所屬類別 | 值的型別 | 基數 | 反向 | 定義 |
|---|---|---|---|---|---|
| has_workspace | Company | Workspace | 1 或以上 | belongs_to | 公司付費使用的工作區 |
| has_subscription | Workspace | Subscription | 剛好 1（目前的） | covers | 目前的付費協議 |
| on_plan | Subscription | Plan | 剛好 1 | — | 購買的方案 |
| renews_on | Subscription | 日期 | 剛好 1 | — | 目前這一期結束的日期 |
| has_renewal_owner | Subscription | Person | 0 或 1 | owns_renewal | 我們這邊負責續約的人 |
| seat_limit | Plan | 數字 | 剛好 1 | — | 方案的席次上限 |
| seats_used | Workspace | 數字 | 剛好 1 | — | 目前使用中的席次 |

## 範例實例
| 實例 | 類別 | 屬性值 |
|---|---|---|
| 北峰股份有限公司 | Company | has_workspace：北峰-台北、北峰-新竹 |
| 北峰-台北 | Workspace | seats_used：48；has_subscription：SUB-1042 |
| SUB-1042 | Subscription | on_plan：Team；renews_on：2026-03-31；has_renewal_owner：吳欣怡 |
| Team | Plan | seat_limit：40 |

## 問題涵蓋情形
| 問題 | 由什麼回答 |
|---|---|
| 1 | Subscription.renews_on、has_renewal_owner |
| 2 | 透過 Subscription.on_plan，比較 Workspace.seats_used 和 Plan.seat_limit |
| 3 | Company.has_workspace（計數） |

## 命名規則
- 類別：單數 UpperCamelCase。屬性：lower_snake_case，以動詞或「has」開頭。不用縮寫。

## 待決事項
- 試用期是價格為 0 的 Subscription，還是獨立的類別？會影響問題 1。
```

## 寄出前檢查

- [ ] 每個能力問題都對應到具名的類別和屬性。
- [ ] 每個類別都有一句話的定義，寫出上層類別和區別特徵。
- [ ] 同義詞都合併成一個類別並列出，而不是建成不同的類別。
- [ ] 每個屬性都有值的型別和基數。
- [ ] 每一條「是一種」的連結，對子類別的每個實例都成立。

## 常見錯誤

- 把狀態做成類別（「ChurnedCustomer」）。改用狀態屬性；東西會進出狀態。
- 把業務上提過的每樣東西都建模。做到能力問題需要的程度就停。
- 定義只是把類別名稱換句話說（「客戶就是客戶」）。要寫出它和別的東西有什麼不同。