数据模型

以下是关于 schema.org 使用的数据模型的讨论。

使用的数据模型非常通用，源自 RDF Schema（而 RDF Schema 又源自 CycL，详情请参阅历史部分…）。

1. 我们有一组类型，排列在一个多重继承层次结构中，其中每个类型可能是多个类型的子类。
2. 我们有一组属性：
   1. 每个属性可能有一个或多个类型作为其域。属性可用于这些类型的任何实例。
   2. 每个属性可能有一个或多个类型作为其范围。属性的值应是至少一个这些类型的实例。

允许多个域和范围的决定纯粹是实用的。虽然具有单个域和范围的系统的计算属性更容易理解，但在实践中，这迫使创建大量人工类型，这些类型纯粹是为了充当某些属性的域/范围而存在。

像许多其他系统一样，这里呈现的模式可以扩展（使用一些类型如 Class 和 Property，以及一些属性如 domainIncludes 和 rangeIncludes），以允许反射，即用自身术语表示模式。

schema.org 的规范机器表示是 RDF/Turtle。请参阅”开发者“页面以获取 schema.org 机器可读视图的更多信息。

此站点上呈现的类型层次结构并不旨在成为世界的”全局本体”。2011 年成立时，它严格专注于项目的创始人（Microsoft、Yahoo!、Google 和 Yandex）可以合理期望通过搜索引擎为其提供特殊处理的实体类型。随着项目演变，引入更多社区协作和扩展机制，其范围逐渐扩大。然而，schema.org 仍不打算作为通用本体。我们期望它与共享我们基本数据模型和我们使用底层标准（如 JSON-LD、Microdata 和 RDFa）的其他词汇一起使用。

符合性

虽然如果结构化数据标记总是非常严格地遵循 schema.org 可能对搜索应用程序有帮助，但在实践中这是不现实的。我们的模式也继续根据反馈、讨论和新数据应用而演变。在可能的情况下，我们修改现有定义，而不是为类似用例引入大量新属性。我们因此基于一个非常灵活的数据模型，并对符合性采取务实观点。

我们期望 schema.org 属性与新类型一起使用，既来自 schema.org 也来自外部扩展。我们还期望，通常，当我们期望属性值为 Person、Place、Organization 或其他 Thing 的子类时，我们会得到一个文本字符串，即使我们的模式没有正式记录这种期望。在”一些数据总比没有数据好”的精神下，搜索引擎通常会接受这种标记并尽力而为。类似地，一些类型如 Role 和 URL 可以与所有属性一起使用，我们鼓励数据消费者之间的这种实验。

工具制作者和模式作者的注意事项

本部分面向扩展作者和工具制作者，即创建消费、检查或转换基于 schema.org 的数据的应用程序的创建者。大多数发布者和网站管理员不必担心这些细节。

schema.org 的应用程序可以通过几种方式处理符合性。工具如验证器可以检查特定于应用程序的模式，例如某些特定功能所需的数据结构。它们还可以检查底层格式（JSON-LD、Microdata、RDFa 等）的符合性，或提供超出正式符合性的额外提示（例如，检查可读性问题或不可信数据）。

虽然此类检查器警告可能难以或模糊的已发布数据对消费者来说是适当和有用的，但它们不必将意外结构视为错误。schema.org 的底层数据模型本质上是灵活的，并为丰富结构化数据提供可扩展基础。我们鼓励发布者和消费者继续探索和分享新的词汇想法，以演变 schema.org。

schema.org 实体描述包括来自几个独立类型的属性不是错误，例如，某物可能同时是 Book 和 Product，并有用地使用来自两种类型的属性描述。包含相关类型在这种描述中是有用的但不是必需的。这种灵活性允许 schema.org 类型以某种分散方式开发，并以有用方式重用和组合词汇。当我们列出与属性关联的预期类型（或反之亦然）时，我们旨在指示这些术语在实践中将如何组合的主要方式。schema.org 的这一方面本质上是不完美的。例如，Volcano 的模式表明，由于火山是地点，它们可能有传真号码。类似地，我们列出了 Country 有”营业时间”的不太可能（但并非不可行）的可能性。我们不试图完善 schema.org 结构的这一方面，而是严重依赖于广泛的示例集合，这些示例捕获了 schema.org 术语的常见和有用组合。schema.org 的类型/属性关联更接近”指南”而不是正式规则，对指南的改进总是欢迎的。

另请参阅：Postel’s Law

映射到 RDFa Lite

我们对 Microdata 的使用很容易映射到 RDFa Lite，我们的许多示例现在显示了两种变体（与较新的 JSON-LD 语法一起）。所有 Schema.org 都可以与 RDFa Lite 语法一起使用。标记的 RDFa Lite 版本看起来几乎与 Microdata 版本同构。以下示例演示了使用 RDFa Lite 来标记 Product 类型示例：

<div vocab="https://schema.org/" typeof="Product">
  <img property="image" src="dell-30in-lcd.jpg" />
  <span property="name">Dell UltraSharp 30" LCD Monitor</span>

  <div property="aggregateRating"
    typeof="AggregateRating">
    <span property="ratingValue">87</span>
    out of <span property="bestRating">100</span>
    based on <span property="ratingCount">24</span> user ratings
  </div>

  <div property="offers" typeof="AggregateOffer">
    <span property="lowPrice">$1250</span>
    to <span property="highPrice">$1495</span>
    from <span property="offerCount">8</span> sellers
  </div>

  Sellers:
  <div property="offers" typeof="Offer">
    <a property="url" href="save-a-lot-monitors.com/dell-30.html">
     Save A Lot Monitors - $1250</a>
  </div>
  <div property="offers" typeof="Offer">
    <a property="url" href="jondoe-gadgets.com/dell-30.html">
     Jon Doe's Gadgets - $1350</a>
  </div>
  ...
</div>

更具体地说：

1. itemprop 被替换为 property。
2. itemscope 被删除。
3. itemtype 被替换为 typeof。

此外，属性值对 vocab="https://schema.org/" 被添加到 body 或其他包围标签中。

背景笔记

以下部分为 schema.org 的一些更一般/抽象术语提供额外信息。

mainEntityOfPage 属性

关于 mainEntityOfPage / mainEntity 属性的背景信息。

mainEntityOfPage “指示此事物是其主要实体的页面（或其他 CreativeWork）。”

许多（但不是所有）页面都有一个相当明确的主题，一些实体或事物页面描述。例如，餐厅的主页可能主要关于该餐厅，或事件列表页面可能代表单个事件。mainEntity 和 mainEntityOfPage 属性允许您明确表达页面与主要实体之间的关系。

相关属性包括 sameAs、about 和 url。

sameAs 和 url 属性都类似于 mainEntityOfPage。url 属性应保留用于引用更官方或权威的网页，例如项目的官方网站。sameAs 属性也将事物与间接识别它的页面相关联。而 sameAs 强调知名页面，mainEntityOfPage 属性更多地用于澄清该页面的几个实体中哪个是主要的。

mainEntityOfPage 可用于任何页面，包括那些不被视为该实体的权威页面。例如，对于产品，sameAs 可能引用制造商官方网站上带有产品规格的页面，而 mainEntityOfPage 可能用于各种零售商站点上的页面，这些页面为同一产品提供详细信息。

about 类似于 mainEntity，有两个关键差异。首先，about 可以引用多个实体/主题，而 mainEntity 应仅用于主要的。其次，一些页面有一个主要实体，该实体本身描述一些其他实体。例如，一个网页可能显示关于特定人的新闻文章。另一个页面可能显示特定产品的产品评论。在这些情况下，页面的 mainEntity 应分别引用新闻文章或评论，而 about 将更恰当地引用人或产品。

“identifier” 属性

关于”identifier”属性及其子属性的背景信息。

identifier 属性及其子属性主要在内容表示为文本字符串的情况下有用。越来越多地，每个都有规范的 URL/URI 表示。所有 schema.org 语法已经为 URI 和 URL 内置了表示，例如在 Microdata 中 ‘itemid’，在 RDFa 1.1 中 ‘resource’，在 JSON-LD 中 ‘@id’。一般来说，除非有特定要求明确说明标识符的种类，或提供额外/替代标识符（例如 DOI），否则最好使用这些。这种要求常见，例如对于科学数据集描述。

在某些情况下，identifier 属性的值指示一组（某种程度上）可互换的实体，而不是单个独特的现实世界实体。这种集合可以被视为对应于类，但我们在这里不探索这种可能性。例如 sku 和各种产品相关的 GTIN 代码。然而，identifier 不打算涵盖更广泛的分类和分类机制。例如，虽然 isicV4 属性具有在某种意义上标识符的值，我们不将 isicV4 视为 identifier 的子属性，因为它用于标识类别而不是单个事物（具体来说，Person）。类似地，非常多的 schema.org 属性可以具有写为 URL 的值，但我们不将这些属性视为 identifier 的特殊化。

在最复杂的情况下，有时需要表示标识符的类型。在这种情况下，当标准 URI 形式的标识符不可用时，可以使用 PropertyValue 对（’name’, ‘identifier’）。我们目前没有推荐的标识符方案标识符方案，但在大多数情况下，大多数标识符方案都有一个约定短名称（应以小写形式使用）。

历史

以前的相关工作：

• RDF Schema
• Meta Content Framework (MCF) Using XML（和教程）。
• MCF 白皮书、规范 和基本词汇。
• 另请参阅维基百科上的语义网络文章。