样式指南

概述

本文档作为使用schema.org数据的指南，以及设计新的或修改的模式的指南。它包含模式设计原则、编写和命名约定以及消费模式的可用性约定信息。目前不涉及建模设计模式。有关Schema.org社区成员共享的更多材料，请参阅项目GitHub仓库的wiki区域。

Schema.org术语

在schema.org数据模型中有三种schema.org术语：类型、属性和枚举值。所有schema.org数据都以图结构表示，其中实体通过命名属性相互关联。

类型

• TitleCase用于大小写格式（所有单词大写，全为一个字符串）。
  • 例如：FoodEstablishment。
• 类型具有关联的属性。
  • 例如：FoodEstablishment具有属性servesCuisine。
  • 有一个技术术语”domain”和”range”在设计讨论和机器可读文件中使用，但不打算广泛使用。例如，我们说”alumni”的domain包括EducationalOrganization，其range包括”Person”。
• 类型也从其父类型（即超类型）获取其关联属性。
  • 例如，FoodEstablishment具有来自其父类型LocalBusiness的属性openingHours，以及来自其父级的父级Organization的属性address。

属性

• 属性名称必须使用lowerCamelCase格式（第一个单词小写，后续单词大写，全为一个字符串）。
  • 例如：servesCuisine。
• 属性必须具有预期的类型。
  • 例如，属性servesCuisine具有预期的类型FoodEstablishment。
• 属性可能具有多个预期的类型。
  • 例如，属性acceptsReservations具有预期的类型Boolean或Text或URL。
• 属性可以在多个类型上使用。
  • 例如，属性starRating可以在FoodEstablishment或LodgingBusiness上使用。
• 属性不能获取属性。

枚举

• 待办：描述枚举数据模型
• 待办：添加示例

命名约定

• 不要为类型和属性赋予相同的名称。
  • 注意，schema.org有一些遗留情况，在过去这样做了。这种做法应该避免。
  • 例如，避免同时创建ContactPoint和contactPoint。
• 术语名称应该只使用单数命名，即使语义需要复数。
  • 例如：parent而不是parents，即使对于每个类型，属性parent将始终有多个值。
• 介词应该放在类型或属性名称之后。
  • 例如：reservationFor。
• 缩写：创建新类型时，要拼写出缩写，除非结果过于冗长。
  • 由于遗留条目，有时某些单词在schema.org中可能缩写或不缩写。由于缺乏一致性，在查找模式术语时应该搜索两者。
  • 例如：numTracks作为遗留属性存在于schema.org中。如果我们现在创建此属性，它将是numberOfTracks（或者更好的是，将其命名为trackCount以与其他计数属性语义对齐）。
• 拼写：必须使用美国拼写。
  • 例如：color而不是colour。

附加说明

关于schema.org定义的一些附加说明。

• Schema.org类型具有超出单词本身可能含义的特定语义含义；消费应用程序不能仅仅因为名称合适就使用类型。
  • 例如，作为类型的Physician意味着医师办公室，而不是作为医师的人。
• 避免使用”类型”这个词，除非指的是类型或类的技术概念。
• 现有的schema.org类型和属性应该在语义已经存在时重用。该项目经常调整定义（措辞或类型/属性关联）以促进这一点；请参阅发布页面以获取示例。
• Schema.org使用开放世界哲学：声明的省略不应被视为否定：如果未提及属性，这并不意味着它是假的。而是意味着我们不知道它是真还是假。
  • 例如，餐厅，petsAllowed是LodgingBusiness的布尔属性（T/F），但如果未设置petsAllowed，则不知道是否允许宠物。