知識圖譜

在實踐中

要抓住這個行業一直含混過去的區別，最乾淨的說法是：本體是 schema，知識圖譜是按這個 schema 裝滿了的實例資料。本體說的是「工單掛在裝置上、裝置屬於客戶」；知識圖譜裝的是那幾百萬條真實的工單、裝置、客戶，以及它們之間的邊。工程上，圖要麼存成 RDF 三元組、上面覆一層 OWL 本體，要麼存成 Neo4j 這類引擎裡的屬性圖；而大量生產環境的圖跑在一套從來沒被寫下來的本體上——這正是同一張圖裡兩個團隊對「客戶」給出互不相容定義的由來。

在「關係形狀」的問題上，知識圖譜是對的工具，而且沒有別的東西能接近它。欺詐團伙、實際受益人鏈條、供應鏈依賴、跨網路的影響面分析、跨十幾個源系統的實體歸併，以及任何形如「離這裡四跳的是什麼」的問題，對圖來說是母語，用關係型 join 寫則從彆扭一路走到不可能。如果你的問題是這個，答案就是一個圖資料庫，沒有哪個應用平臺可以替代。

它和語義層共有的那道限度是同一道：知識圖譜壓倒性地是一個讀結構。它記錄「這些東西連著」，但不宣告誰可以改動它們、允許哪些操作、以及一次改動留下什麼審計記錄。ObjectStack 是從另一端處理這些連線的——關係被宣告為物件上的型別化欄位，就寫在應用自己的後設資料裡，於是業務的那張圖是應用賴以執行的那份定義的自然結果，而不是另一個需要同步的儲存；又因為這份定義是你倉庫裡的檔案，它是一份開放的業務本體，而不是別人平臺裡的一張圖。這是關於所有權與治理的主張，不是關於圖分析的：ObjectStack 不是圖資料庫，也不打算去贏深度多跳遍歷。