在 Schema 中添加多个描述性属性的统一方式 [英] Uniform way to add multiple descriptive properties in Schema

问题描述

我们使用 Schema.org 的类型"和属性"来组织多种数据.该应用程序由 Schema.org 的词汇和结构驱动，而不是使用 schema.org 进行 SEO.应用程序构建和关联科学家、艺术家、作曲家等创意人士的已完成和未完成的作品.他们的努力不仅限于文章和艺术品等创意作品"，还包括由他们发起的组织、公司、活动和产品.

We use Schema.org 'types' and 'properties' to organize many kinds of data. The application is driven by the vocab and structure of Schema.org, rather than it uses schema.org for SEO. The application structures and relates finished and unfinished works of creative people like scientists, artists, composers etc. Their efforts are not limited to "Creative works" such as articles and artworks, but include also organizations, companies, events and products initiated by them.

从今年开始，我们使用 Schema.org，因为我们过去在语义结构化数据方面存在问题.现在我们正在使用 Schema.org，我们取得了很好的进展.

Starting this year, we use Schema.org because we had problems in semantic structuring our data in the past. Now we are using Schema.org we make good progress.

对于我们收集的每个项目，我们使用 name 和 description(Thing 属性)作为描述字段.为了更加方便，我们希望为我们存储在数据库中的每个项目添加 headline 和 alternativeHeadline 或类似的 Schema.org 词汇.

For each item that we collect we use name and description (Thing properties) as descriptive fields. To be even more elobarate we want to add headline and alternativeHeadline or a similar Schema.org vocab for each item we store in our database.

以下默认属性列表足以满足我们的应用程序处理的所有项目:

The following default property list would be adequate for all the items our application deals with:

• 姓名
• headline
• alternativeHeadline
• 描述
• 图片(非描述性)
• url(非描述性)

• name
• headline
• alternativeHeadline
• description
• image (non-descriptive)
• url (non-descriptive)

对于从 schema.org/CreativeWork 派生的所有类型，属性 headline 和 alternativeHeadline 匹配 schema.org，但是，例如，Event 或 Product 没有这些属性.我们可以使用Thing属性alternateName或about，但这些属性显然不是headline和的等价物>替代标题.

For all types derived from schema.org/CreativeWork the properties headline and alternativeHeadline match schema.org, but, for example, Event or Product do not have these properties. We could use the Thing properties alternateName or about, but these properties are obviously not equivalents of headline and alternativeHeadline.

简而言之:我们寻找一种统一的方法来为应用程序中的每个项目添加四个基本描述字段，而不管其type.最好的解决方案是什么?

In short: We look for a uniform way to add four basic descriptive fields to each item in our application, regardless its type. What would be the best solution?

推荐答案

我不建议只使用 Schema.org 词汇.为所有情况提供属性并不是 Schema.org 的目标.作者打算在需要时使用更具体的词汇.

I wouldn’t recommend to use only the Schema.org vocabulary. It’s not Schema.org’s goal to provide properties for all cases. It’s intended that authors use more specific vocabularies where needed.

基于 RDF，很容易为您的数据使用许多不同的词汇:schema:name 用于 Schema.org 的 name 属性，foaf:name 用于 FOAF 的 name 属性.

Being RDF-based, it’s easily possible to use many different vocabularies for your data: schema:name for Schema.org’s name property, foaf:name for FOAF’s name property.

这还允许您在找不到合适属性的情况下使用您自己的词汇.

And this also allows you to use your own vocabulary for cases where you don’t find a suitable property.

这个答案的其余部分假设您必须使用 Schema.org 来处理所有事情.

The rest of this answer assumes that you have to use Schema.org for everything.

我认为将 headline/alternativeHeadline 用于 Event 或 Organization 是没有意义的.公司的标题是什么?事件的替代标题是什么?虽然有些人可能有一个想法，但很可能没有广泛的共识，每个人都会以不同的方式使用它；因此消费者不知道会发生什么，从而使该属性无用.

I don’t think that using headline/alternativeHeadline for Event or Organization makes sense. What is the headline of a company? What is the alternative headline of an event? While some might have an idea, there would most likely be no broad agreement, everyone would use it differently; so consumers wouldn’t know what to expect, rendering this property useless.

从您的 Organization 示例中，我得到的印象是您将这些属性用于诸如标语/口号/格言/标语之类的内容.Schema.org 为这样的目的提供属性可能有意义也可能没有意义，但它不应该是 headline.

From your Organization example, I get the impression that you use these properties for something like a tagline/slogan/motto/catchphrase. It might or might not make sense for Schema.org to provide a property for such a purpose, but it shouldn’t be headline.

在没有这样合适的属性的情况下，我会说你使用 headline/alternativeHeadline 的内容应该是 name 的一部分> 或 描述.

In the absence of such suitable properties, I would say that the content you have used headline/alternativeHeadline for should be either part of name or description.

以Event为例:

• headline 可以成为 name 的一部分:纠缠的宇宙:人类心灵的非凡能力".
• alternativeHeadline 可以省略，因为它只是在散文中给出事件位置，而此信息已经通过 location 传达给消费者.如果句子真的必须是结构化数据的一部分(而不仅仅是显示在页面上)，那么它可以包含在描述中.

• The headline could become part of the name: "The Entangled Universe: The extraordinary capabilities of the humand mind".
• The alternativeHeadline could be omitted, because it just gives the event location in prose, while this information is already conveyed to consumers with location. If the sentence really has to be part of the structured data (and not just displayed on the page), then it could be included in the description.

使用旧扩展机制，您可以根据现有属性生成更具体的属性.但已弃用，我不建议发布具有此类属性的数据.但它对于内部使用可能仍然有用，因为它允许您使用单独的字段.例如，您可以使用 name/subtitle、description/where 或 description/slogan 等属性.

With the old extension mechanism, you could generate more specific properties based on existing properties. But it’s deprecated, and I wouldn’t recommend publishing data with such properties. But it might still be useful for internal use, as it allows you to use separate fields. For example, you could use properties like name/subtitle, description/where, or description/slogan.

这篇关于在 Schema 中添加多个描述性属性的统一方式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！