了解 schema.org JSON 表示的正确数据类型和结构答案

【问题标题】：Understanding the right data type & structure for schema.org JSON representation了解 schema.org JSON 表示的正确数据类型和结构
【发布时间】：2019-07-26 08:08:55
【问题描述】：

我一直在查看 schema.org，对于为几种常见类型的数据实体（Person、Place、Thing、Book、Movie 等）建模模式的公共项目来说，这似乎是一个好主意.

我无法理解有关数据类型和结构的两个概念

我将使用 Recipe 架构作为示例，特别是该页面底部的（简化的）原始 JSON 表示：

{
  "@context": "http://schema.org",
  "@type": "Recipe",
  "author": "John Smith",
  "name": "Mom's World Famous Banana Bread",
  "nutrition": {
    "@type": "NutritionInformation",
    "calories": "240 calories",
    "fatContent": "9 grams fat"
  },
  "recipeIngredient": [
    "3 or 4 ripe bananas, smashed",
    "1 egg",
    "3/4 cup of sugar"
  ],
}

author 字段的类型应该是 Organization 或 Person，但上面的 JSON 只是将其表示为字符串（“John Smith”）。另一方面，nutrion 字段的类型为NutritionInformation，但它表示为一个完全结构化的对象（即不仅仅是一个字符串）。在什么情况下我们应该使用前者而不是后者？如果不需要更多细节，是否假设每个对象都可以选择性地提炼成一个简单的字符串？
recipeIngredient 字段是项目的列表/数组，但规范文档中没有提到它应该是一个列表。它也可以只是一个元素吗？我们如何知道何时使用列表而不是单个元素？

【问题讨论】：

标签： schema.org json-ld

【解决方案1】：

预期类型

每个 Schema.org 属性 can have、Text¹、URL¹ 或 Role 值，即使它们未列在“预期为这些类型之一的值”下。

引用自data model documentation：

我们还经常期望，在我们期望 Person、Place、Organization 或其他一些 subClassOf Thing 类型的属性值的地方，我们会得到一个文本字符串，即使我们的模式没有正式记录这种期望。本着“有数据总比没有数据好”的精神，搜索引擎往往会接受这种标记，并尽力做到最好。同样，某些类型（例如 Role 和 URL）可以与所有属性一起使用，我们鼓励在数据消费者中进行这种实验。

如果Text 未列为预期类型，通常最好提供预期类型之一而不是Text。在您的示例中，使用预期类型至少可以传达author 是Person 还是Organization，并且它会让您有机会提供@id 值，从而允许其他人发表声明关于这个食谱的作者，或者理解两个作者是相同的。

多个值

每个属性can have 多个值。这是 Schema.org 支持的所有三种语法（JSON-LD、Microdata、RDFa）的核心功能。

Unless the property’s definition says otherwise，您不应该将多个值放入一个属性值中，尤其是因为没有定义分隔符。因此，不为 recipeIngredient 使用数组是不正确的，因为该属性需要“单一成分”。

¹ 由于Text 和URL 是DataType 的子类型，因此不应指定这些类型。如果是字符串值，则为Text类型；如果它是一个@id 值，它的类型是URL。

【讨论】：