了解正确的数据类型schema.org JSON 表示的结构 [英] Understanding the right data type & structure for schema.org JSON representation
问题描述
我一直在查看 schema.org,对于一个为几种常见类型的数据实体(人、地点、事物、书籍、电影等)建模模式的公共项目,这似乎是一个好主意.
I've been looking at schema.org and it seems like a great idea for a public project that models the schema for several common types of data entities (Person, Place, Thing, Book, Movie, etc...).
我无法理解有关数据类型和结构的两个概念
I'm having trouble understanding two concepts regarding the data types and structure
我将使用 Recipe
架构作为示例,特别是 (简化)来自该页面底部的原始 JSON 表示:
I'll use the Recipe
schema as an example, specifically the (simplified) raw JSON representation from the bottom of that page:
{
"@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 只是将其表示为字符串(约翰·史密斯").另一方面,nutrion
字段的类型为NutritionInformation
但它表示为一个完全结构化的对象(即不仅仅是一个字符串).在什么情况下我们应该使用前者与后者?如果不需要更多细节,是否假设每个对象都可以选择性地精简为一个简单的字符串?
The
author
field should be of typeOrganization
orPerson
, but the above JSON simply represents it as a string ("John Smith"). On the other hand, thenutrion
field is of typeNutritionInformation
but it's represented as a fully structured object (i.e. not just a string). In what situations should we use the former versus the latter? Is it assumed that each object can optionally be distilled down to a simple string if more detail is not needed?
recipeIngredient
字段是一个项目列表/数组,但规范文档中没有提到它应该是一个列表.它也可以只是一个元素吗?我们如何知道何时使用列表与单个元素?
The recipeIngredient
field is a list/array of items, but nothing in the specification document mentions that it should be a list. Can it also just be a single element? How do we know when to use a list versus a single element?
推荐答案
预期类型
每个 Schema.org 属性可以有一个Text
¹,一个URL
¹ 或 Role
值,即使它们未列在应为这些类型之一的值"下.
Expected types
Every Schema.org property can have a Text
¹, a URL
¹, or a Role
value, even if they are not listed under "Values expected to be one of these types".
引自数据模型文档:
我们也经常期望,在我们期望类型为 Person、Place、Organization 或其他一些 subClassOf Thing 的属性值的地方,我们会得到一个文本字符串,即使我们的模式没有正式记录该期望.本着有些数据总比没有好"的精神,搜索引擎通常会接受这种标记并尽力而为.同样,某些类型(例如 Role 和 URL)可以与所有属性一起使用,我们鼓励数据消费者进行此类实验.
We also expect that often, where we expect a property value of type Person, Place, Organization or some other subClassOf Thing, we will get a text string, even if our schemas don't formally document that expectation. In the spirit of "some data is better than none", search engines will often accept this markup and do the best we can. Similarly, some types such as Role and URL can be used with all properties, and we encourage this kind of experimentation amongst data consumers.
如果 Text
未列为预期类型,通常最好提供预期类型之一而不是 Text
.在您的示例中,使用预期类型至少会传达 author
是 Person
还是 Organization
,它会给你提供一个 @id
值的机会,它允许其他人对这个配方的作者发表声明,或者理解两个作者是相同的.
In case Text
is not listed as expected type, it’s usually better to provide one of the expected types instead of Text
. In your example, going with an expected type would at least convey whether the author
is a Person
or an Organization
, and it would give you the chance to provide an @id
value, which allows others to make statements about the author of this recipe, or to understand that two authors are the same.
每个属性可以有多个值.这是 Schema.org 支持的所有三种语法(JSON-LD、Microdata、RDFa)的核心功能.
Every property can have multiple values. This is a core feature in all three syntaxes supported by Schema.org (JSON-LD, Microdata, RDFa).
除非属性定义另有说明,否则不应将多个值放入一个属性值中,尤其是因为没有分隔符被定义为.因此,不为 recipeIngredient
使用数组是不正确的,因为该属性需要单一成分".
Unless the property’s definition says otherwise, you should not put multiple values into one property value, not least because no delimiter is defined. So, not using an array for recipeIngredient
would be incorrect, as this property expects "A single ingredient".
¹ 因为 Text
和 URL
是 的子类型DataType
,这些类型不应该被指定.如果是字符串值,则为 Text
类型;如果是 @id
值,则它的类型为 URL
.
¹ As Text
and URL
are subtypes of DataType
, these types should not be specified. If it’s a string value, it’s of type Text
; if it’s an @id
value, it’s of type URL
.
这篇关于了解正确的数据类型schema.org JSON 表示的结构的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!