Web 系統的設計要點之一是內容和表示的分離，網站以HTML發布內容，對內容進行操作的服務也只能訪問 HTML。隨著表現形式各異的設備在大量地增加，也大大增加了網站針對不同表示格式的數量。同時，一些新的個人助理應用，例如google assitant，amazon的Alexa，已經開始為web提供接觸用戶的新渠道。

[[434879]]

此外，成熟的網絡應用程序，正越來越多地尋求使用結構化內容，以提供更豐富和更具交互性的體驗。這最終使得 Web 系統和開發人員能夠以可互操作的方式交換結構化數據變得至關重要。Schema.org 是一套基于現有標準語法的詞匯表，目前被 Web 系統上使用上的結構化數據所廣泛使用。

關于結構化數據標記的標準

在早期，結構化數據的標準在獨立的領域非常有用。一種方法是XML，試圖標準化語法。雖然 XML 最初只被認為是HTML的未來，但它為結構化數據找到了更多的實用工具，具有更豐富的數據互操作性場景。另一種方法是元內容框架 ，它將知識表示的思想引入到 Web 系統，并提出進一步使用一種通用的數據模型，即有向標記圖。元內容框架的愿景是創建關于實體的廣泛知識庫，其中不同的部分來自不同的網站。隨著時間的推移，這一愿景逐漸涵蓋了網絡上的各種智能數據處理。

在1997年和2004年之間，產生了結構化數據標記的各種標準(RDF、 RDFS 和 OWL)。許多詞匯都用于特定的垂直領域，其中一個被廣泛采用的就是 RSS ，它允許用戶用自己喜歡的新聞來源定制主頁。另一個是 vCard/hCard (通過 CSS class 屬性以 HTML 的微格式表示) ，用于在地址簿、電子郵件等程序之間交換信息。后來，hCalendar 也加入了這個項目，它同樣是一種微格式的 HTML，重新表達了現有 IETF的標準—— iCalendar。

在發布每一種結構化數據標準的時候，都會有一些應用程序會廣泛地使用它。那如果要創建一個跨越垂直領域的結構化數據標準，就要找到一個覆蓋面廣的應用程序，這個應用程序可能就是文本搜索。

網絡搜索不局限于搜索結果的排名，而是要提高搜索結果的質量。用一些結構化數據來標記網頁內容，可以優化用戶和網站站長的體驗。但是，大多數網站根本沒有為網站添加任何標記，另外，即使是添加了標記，仍然往往格式不正確。這種大量的不正確格式要求構建復雜的解析器，這些解析器能夠處理格式不正確的語法和詞匯表。

結構化數據的標記標準：schema.org

2011年，主要的搜索引擎 Bing、 Google 和 Yahoo 創建了 schema. org 來改善這種狀況。目標是提供一個涵蓋廣泛主題的模式，主題包括人、地點、事件、產品、提供等等，一個單一的模式涵蓋了這些主題，主要是為站長提供一個統一的詞匯表。

2011年后，許多不同公司的不同應用已經開始使用 schema.org 的詞匯表。其中包括:

• google將schema. org 中的注釋用作知識圖譜的數據源，提供關于知識實體的背景信息(例如 logo、 contact 和社會信息)。
• 基于 schema.org 的結構化數據標記正在電子郵件等地方使用。例如，確認酒店預訂的電子郵件、購買收據等都嵌入了帶有交易細節的 Schema.org 標記。這種方法使電子郵件的輔助工具能夠提取結構化數據，并通過移動通知、地圖、日歷等使其可用。
• Pinterest 使用 schema. org 為菜譜、電影、文章、產品或擺放物品提供豐富的依據。
• 蘋果的Siri使用 Schema.org 進行搜索功能，包括聚合評級、優惠、產品、價格、交互次數、組織、圖片、電話號碼和潛在的網站搜索操作，還在 RSS 中使用 Schema.org 進行新聞標記。

當然，衡量是否成功的一個關鍵是站長的采用程度。從 Google 索引中可知，大約31.3% 的頁面使用了 schema. org 標記。平均而言，每個包含這個標記的頁面都會引用多個實體，其中包含數十個邏輯判斷。需要注意的是，結構化的數據標記與 Web系統本身具有相同的數量級。在主要搜索引擎中，有超過四分之一的頁面使用了Schema.org 的廣義詞匯表。Schema.org 的成功很大原因在于它背后的設計決策。

schema.org中的一些設計

Schema.org 的驅動因素是讓站長可以輕松地發布他們的數據，設計決策將更多的努力放在了標記的使用者身上。

表達的語法

從一開始，schema. org 就在多種語法和向站長提供簡潔說明之間尋找平衡。隨著時間的推移，多重語法顯然是個好方法，包括 RDFa 和 JSON-LD ，數據的發布者可以自行選擇。

不同的語法適用于不同的工具和數據模型， JSON-LD是將其中的結構化數據表示為一組 javascript 風格的對象。這對于使用JavaScript 生成的站點以及個性化的電子郵件非常有用，因為在這些電子郵件中，數據結構可能更加冗長。JSON-LD 允許嵌入式的成員在 Schema.org 中攜帶結構化數據。有時候，可以將這種情況理想化為機器友好格式和人機友好格式之間的權衡。RDF 和 XML 等格式的設計主要為了機器使用，而微格式則明確表示人類優先。

領域的多態

許多知識表示的系統，對每個關系都有一個域和范圍。這導致了許多不直觀的表達，一個關系的唯一作用可能是某種關系的域或范圍，這也使得重用現有關系而不改變類層次結構變得更加困難。允許多個域和范圍的決定可能會改善這一問題。例如，schema. org 中有各種類型(Events，reservation，Offers) ，它們的實例都可以接受 startDate 屬性，但是多態性使我們避免使用通用的超類型來對它們進行分組。

實體的引用

對于大多數站點來說，協調數以萬計的實體與其他站點之間的實體引用太困難了。schema. org 堅持使用惟一的 uri，鼓勵數據的發布者向每個實體添加盡可能多的額外描述，以便數據的消費者可以使用此描述進行實體協調。雖然這給來自多個 Web 數據的應用程序帶來了額外成本，但它極大地減輕了站長的負擔。。

增量的復雜性

通常，如果表示過于簡單，會使構建一些更復雜的應用程序變得困難。通常情況下，一旦構建了簡單的應用，詞匯表也獲得了低程度的采用，應用的開發者和站長就會要求使用更具表現力的詞匯表，這相當于添加一些更多的描述性屬性或子類型。添加新類型的操作或事件是擴展 Schema.org 表達能力的一種強大方法。然而，在許多情況下，很少有正確的答案，Schema. org 的方法不會因為追求完美模式而改變。

清除與擴展

每隔一段時間，可能會引入一些沒有意義的詞匯，盡管可能會很容易處理，但最好還是把它們清除掉。

Web 底層的結構化數據是多樣的，schema. org 最多只能為最常見的主題提供核心詞表。即使是對于一個相對常見的主題，比如汽車，也可能需要數百個屬性才能從各種網站上找到各種汽車規格的詳細信息。schema. org的策略是為這樣的主題提供一個小的核心詞匯表，并依靠擴展來覆蓋長尾問題。

擴展主要有兩大類， 一類是由 Schema.org 社區創建的，另一類是僅在“民間”實現。2015年的時候，引入了托管擴展的概念，然而，分層機制的設計是為了讓專家和專業組織有更大的自主權。另外是外部擴展的概念，它們是參考 Schema.org 的核心詞匯表設計的，期望在核心詞匯表的基礎上進行構建。

結構化數據標記的其他發展

2006年以來，“鏈接數據(linked data)”將 W3C RDF 社區的重點從語義網本體論和規則語言轉向開放數據和實用數據共享。關聯數據聯盟已經成功地從各種公共部門和開放數據來源獲得了大量RDF表示的開放數據，但RDF 的數據發布做法在網絡中還沒有被采用。

鏈接數據的目標更高，網上數據來源的數量很少，但質量往往很高。這為結合這兩種方法提供了許多機會，例如，專業團隊發布的關聯數據往往可以權威地描述來自 schema. org 描述中提到的實體。

使用標識 uri 和獨立模式的無約束組合，鏈接數據可以被視為一個設計極限，另一端的極限可能是知識圖譜。在2012年由谷歌提出了知識圖譜的概念，作為一個統一的圖數據集，用于搜索和相關應用。這個基本思想建立在與鏈接數據和 schema. org 共享的公共元素之上: 一個具有命名屬性類型化實體的圖數據模型。知識圖譜特別強調前期的實體管理，以確保新數據被整合，且與現有記錄相聯系。基于共享，用 Schema.org 表示的結構化數據是集成到知識圖的自然信息來源。沒有人愿意閱讀冗長的規范，大多數開發人員傾向于復制和編輯示例。隨著時間的推移，復雜性逐步增加，平臺/標準中的每一層復雜性只有在采用了更基本的層之后才能添加。

小結

網絡基礎設施需要結構化的數據機制來描述實體和現實世界中的關系，這個想法一直存在。與其尋求創建“智能代理的語言”，不如從網絡搜索中解決具體的場景，人工輔助的結構化數據標記可能是最佳的實用途徑。

schema.org 已經開發了更多的詞匯，并以更加分布的方式進行。從汽車到產品細節等一系列的主題擴展，提供了一個統一的詞匯表和必要的討論空間。在web系統中，大數據的應用越來越廣泛，使得對通用模式的需求越來越重要，探索數據驅動的價值，從不同來源收集數據的需求，對共享詞匯的需求在增加，或許這是 schema.org 的價值之一。