基本概念

如果您是 Freebase 新手，本節將介紹瞭解 Freebase 運作方式所需的基本術語和概念。

  1. 圖表
  2. 主題
  3. 類型和屬性
  4. 網域和 ID
  5. 複合值類型
  6. 主題 MID
  7. 命名空間、金鑰和主題 ID
  8. 資源相關資訊
  9. 摘要

圖表

Freebase 資料會儲存在稱為「圖形」的資料結構中。圖表由邊緣連接的節點組成。在 Freebase 中，節點是使用 /type/object 定義，邊緣則使用 /type/link 定義。Freebase 將資料儲存為圖表，因此可快速遍歷主題間的任意連結，並輕鬆新增結構定義，不必變更資料結構。

主題

Freebase 包含超過 3, 900 萬個主題，涵蓋人物、地點和事物等實體。由於 Freebase 資料是以圖表呈現，這些主題會對應到圖表中的節點。不過，並非每個節點都是主題。請參閱CVT 一節，瞭解非主題的節點範例。

Freebase 中可找到的主題類型範例：

有些主題之所以重要，是因為包含大量資料 (例如沃爾瑪)，有些則是因為連結到許多其他主題 (可能位於不同資訊領域) 而備受矚目。舉例來說，愛情、貧窮、騎士精神等抽象主題沒有太多相關聯的屬性，但經常出現在書籍、詩集、電影等的主題中，因此更為顯著。

類型和屬性

任何主題都可以從許多不同角度來看，例如：

  • 巴布狄倫是詞曲作家、歌手、表演者、作家和電影演員；
  • 李奧納多．達文西是畫家、雕塑家、解剖學家、建築師、工程師，
  • 愛是書籍、電影、戲劇、詩歌的主題，
  • 任何城市都是一個地點，可能是旅遊目的地，也是公務員的雇主。

為掌握許多主題的多面向特性，我們在 Freebase 中導入「型別」概念。Freebase 中的主題可以指派任意數量的類型。Bob Dylan 的主題會指派多種型別，例如詞曲作家、作曲家、音樂藝人 (歌手)、作家等。每種型別都有一組與該型別相關的屬性。舉例來說，

  • 音樂藝人型別包含一個屬性，列出 Bob Dylan 製作的所有專輯，以及他擅長的所有樂器；
  • 書本作者類型包含的屬性會列出 Bob Dylan 撰寫或編輯的所有書籍，以及他的寫作思想或運動；
  • 公司類型包含許多屬性，可列出公司創辦人、董事會成員、母公司、部門、員工、產品，以及逐年營收和利潤記錄等。

因此，類型可視為屬性的概念容器，最常用於描述資訊的特定層面。(您可以將型別視為類似關聯式資料表，而每個「型別」資料表都有一個外鍵，可進入唯一定義每個主題的「身分」資料表)。

網域和 ID

如同屬性會分組為類型，類型本身也會分組為「網域」。網域就像您喜愛報紙中的各個版面：商業、生活風格、藝術與娛樂、政治、經濟等。每個網域都有 ID (識別碼)，例如：

網域 ID 看起來像檔案路徑，或是網址中的路徑。

每種型別也會獲得 ID，且 ID 是根據所屬網域而定。舉例來說，「公司」類型屬於「商家」網域，並獲得 ID /business/company。其他例子包括：

就像類型會沿用網域的 ID 開頭一樣，屬性也會沿用所屬類型的 ID 開頭。舉例來說，公司類型 (用於指定公司所屬產業) 的「產業」屬性會獲得 ID /business/company/industry。其他例子包括：

因此，即使 Freebase 中的型別並未依階層排列，網域、型別和屬性也會獲得 ID，並以類似檔案目錄的階層概念排列。

複合值類型

複合值類型是 Freebase 中的類型，用於表示每個項目包含多個欄位的資料。複合值類型 (CVT) 用於 Freebase，代表複雜資料。一開始可能會有點難以理解，但 CVT 是 Freebase 結構定義中非常重要的一環，可讓系統更準確地模擬主題間的複雜關係。

請參考以下範例：城市人口會隨著時間而變化。也就是說，每當您查詢 Freebase 的人口數時，至少會隱含要求特定日期的人口數。這項作業會用到兩個值：人數和日期。以下是 CVT 極為實用的情況。如果沒有主題，您就必須建立主題 (例如「1997 年溫哥華的人口」)，並在該主題中提交資訊，才能建立人口資料模型。

CVT 可視為不需要顯示名稱的主題。與一般主題一樣，CVT 也有 GUID，可供獨立參照。不過，Freebase 用戶端處理這些項目時，與主題的處理方式大不相同。在大多數情況下，CVT 的每個屬性都應是消歧屬性。

主題 MID

主題可能可透過命名空間/金鑰 ID 識別，也可能無法識別，但一律可透過 MID (機器 ID) 識別，MID 由 /m/ 後接以 32 為底的專屬 ID 組成。系統會在建立主題時指派 MID，並在主題的整個生命週期內進行管理。當主題合併或分割時，這些 ID 扮演重要角色，可讓外部應用程式追蹤邏輯主題，即使實體 Freebase ID (主題的 GUID) 可能會變更，也不受影響。機器產生的 ID 與其他可供使用者辨識的 Freebase ID (由「id」屬性傳回) 不同，因為：

  • 保證存在
  • 機器生成
  • 支援離線比較
  • 並非用來向人類傳達意義
  • 短 (可能為固定長度)
  • 非常適合在外部系統和元件之間快速交換金鑰 (外部、交換)

建議使用 MID 做為 Freebase 主題的 ID

命名空間、金鑰和主題 ID

網域、類型和屬性 ID 的檔案目錄式階層，只是更一般概念的應用：命名空間和鍵。命名空間就像檔案目錄，而金鑰就像檔案名稱。如同特定檔案目錄中的所有檔案名稱不得重複，特定命名空間中的所有鍵也不得重複。

以更具體的例子來說，/business 是對應商家網域的命名空間。其中，與商家相關的類型會獲得鍵 (例如 company)，且彼此不得重複。每個型別的 ID 都是在命名空間的 ID 後方附加其鍵 (例如 /business/company)。

除了對應網域和型別的命名空間之外，還有幾種命名空間。最重要且最常遇到的就是 /en 命名空間。這是英文命名空間，其中大部分知名主題都可以獲得專屬鍵，形成使用者可判讀的英文 ID。舉例來說，多產的 Bob Dylan 相當知名，因此他在 Freebase 中的主題會獲得 /en 命名空間中的 bob_dylan 鍵，主題 ID 為 /en/bob_dylan。有了這個 ID，您就能透過簡單的網址，在網頁版用戶端存取他的主題

房源詳細資訊

最後要討論的基本概念，是 Freebase 屬性與關聯資料庫技術中類似屬性 (即關聯資料表欄) 的主要差異。每個資料列的關聯資料表欄位只能保留一個值。舉例來說，假設有一個典型的「書籍」關聯式資料表，其中包含名為「作者」的資料欄。在「book」表格中，每一列的「author」欄只能保留一個「author」表格的外鍵。如果一本書有多位作者，這個簡單的關聯結構定義設計就不適用，我們必須建立新表格來模擬著作權。也就是說，我們需要一個「書籍」資料表、一個「作者」資料表，以及一個「著作」資料表，用來儲存書籍與作者之間的 n 對 n 關係。從一種結構定義設計切換到另一種時，資料的擷取方式也會有大幅改變。

與傳統資料庫技術不同，Freebase 認為多值屬性在模擬實際資料時非常實用，因此預設支援多值屬性。也就是說，建立 /book/written_work/author 屬性時，系統會假設每本書允許多位作者，因此您查詢多值屬性和單值屬性的方式完全相同。您不必考慮是否需要加入可模擬 n 對 n 關係的第三個表格。

摘要

  • 類型是相關屬性的概念容器，通常用於說明主題的特定面向。
  • 主題可指派一或多個類型 (預設類型為 /common/topic)
  • 屬性會匯集成類型，類型則會匯集成網域。
  • 系統會在命名空間/鍵層級中為網域、型別和屬性指派 ID。
  • 常見的知名主題會在 /en 命名空間中獲得 ID，這些 ID 是使用者可判讀的英文字串。
  • Freebase 會使用 GUID 唯一識別主題。
  • 屬性預設為多值，多值屬性和單值屬性的查詢方式相同。