元資料/元資料形式
< 元資料
某些社群（例如資料庫管理員）更關注另一種型別的元資料：結構化元資料。這種型別的元資料記錄了資料如何構建和儲存。
例如，一家商店可能會保留一個數據庫來跟蹤客戶在雜貨上花費了多少錢。在這種情況下，我們知道客戶姓名將始終是字元字串，並且他們花費的金額將始終是正數。知道這一點，我們就可以建立一個更有效地儲存資料的資料庫。在建立資料庫時，他們可能會發出類似以下的命令
CREATE TABLE purchases(
purchase_id UNSIGNED INTEGER,
customer_name VARCHAR(50),
amount_spent UNSIGNED INTEGER,
purchase_date TIMESTAMP,
PRIMARY KEY (customer_id)
);
這為我們的資料庫表建立了一個模式 - 一組約束。以下是一些約束
purchase_date必須以 SQL 的timestamp格式。如果有人嘗試輸入Last Tuesday作為交易的purchase_date，資料庫將丟擲錯誤，但會接受2020-02-14 09:22:15。- 客戶在購買期間不能花費負數，因為
amount_spent列只允許具有UNSIGNED INTEGER型別的值，這些值必須為正數。 - 由於
VARCHAR(50)型別在customer_name列中僅允許 50 個字元的資料，因此名稱很長的客戶可能會發現他們的姓名在資料庫中被縮短。
資料庫使用一段時間後，我們可能在表中看到以下內容
| purchase_id (UNSIGNED INTEGER) | customer_name (VARCHAR(50)) | amount_spent (UNSIGNED INTEGER) | purchase_date (TIMESTAMP) |
|---|---|---|---|
| 1 | Ashok Kumar | 2784 | 2020-02-14 09:22:15 |
| 2 | 洪吉東 | 3516 | 2020-02-14 09:30:02 |
| 3 | Joe Borg | 499 | 2020-02-14 09:31:43 |
| 4 | 以色列以色列 | 2495 | 2020-02-15 09:00:04 |
就其本身而言，值499、洪吉東、4和2020-02-14 09:22:15毫無意義。但是，我們輸入的結構化元資料使我們能夠定義、解釋、維護和有效地儲存表中的資料。
令人困惑的是，結構化元資料有第二個定義。在數字圖書館社群，術語結構化元資料經常用於指代一種特定型別的描述性元資料，即描述特定通訊的物理和/或邏輯結構的元資料。例如，如果一個數字圖書館專案建立了某本書所有頁面的數字影像，那麼結構化元資料將記錄頁面的順序，以及可能記錄每個章節或部分從哪一頁開始。