Schema.org中的网页结构的隐含性 [英] Implicity of web page structure in Schema.org

问题描述

在阅读了数千篇帖子，问题，博客文章和观点之后，我仍然对如何用微数据标记网页感到困惑。如果微数据的主要目的是为了帮助搜索引擎更好地理解网页的内容（并且隐式假设网页），那么从body元素中的itemtype网页开始，然后继续标记剩余的定义哪一个是主要实体的嵌套元素，还是最好从itemtype开始，该类型理想地是网页的主要主题并且在顶层关联属性，或者最好在顶层具有不同的itemtype（即网页，博客文章和页面的主题）？

一个例子会解释我的问题：如果我必须标记一个包含关于特定主题的博客文章的网页（让我们来谈谈无线技术），顶级产品应该是什么？应该是网页，博客还是无线技术？ $ b $越多越好（有例外） b

在结构化数据方面，准则应该是：越好越好。如果您提供更多结构化数据（即，您将事情明确化而不是隐含），那么消费者找到可以使用的东西的机会就越大。

不遵循此准则的原因可能包括：

• 您确切知道要支持哪些消费者，以及他们寻找什么，并不关心其他（例如，未知或新的）消费者。


• 您知道消费者被窃听的方式无法应对某些结构。 b $ b
• 您需要保存尽可能多的字符（带宽/性能）。


• 提供额外的结构化数据太复杂/昂贵。


• 结构化数据对任何可想象的消费者来说都是无用的。

> WebPage offer



所以除非你有理由不这样做，否则提供< a href =http://schema.org/WebPage =n ofollow noreferrer> WebPage 键入 ... if 可以提供可能有趣的数据。例如：






• 它允许您为页面和页面上的事物提供不同的URI，或者该页面就像一个人，一座建筑物等一样（请参阅为什么这可能有用和一个稍微更具技术性的答案与细节）。

href =http://schema.org/hasPart =nofollow noreferrer> hasPart 允许您连接可能是顶级的项目物品，对于这些物品，它们并不一定清楚。 c $ c> 允许你使这个 WebPage 成为别的东西的一部分（例如，如果你提供了 WebSite 项目或 CollectionPage ）。 该页面：使用 breadcrumb 表明它们代表这个页面的面包屑。


• 您提供辅助功能信息：use accessibilityAPI ， accessibilityControl ， accessibilityFeature ， accessibilityHazard




• author / contributor / copyrightHolder / < a href =http://schema.org/editor =nofollow noreferrer> editor / funder / etc。的页面与作者 / ...不同。该页面的主要内容。

该页面有不同的 license 。

• 可以在页面上完成：使用 potentialAction 。
  

• ...







当然，还允许您使用 mainEntity ，但如果这是您只需要 WebPage 项目，您就可以使用反向属性 mainEntityOfPage 。





更具体网页


对于更具体的类型也是如此，这些类型给出了额外的信号：





• AboutPage 如果它是关于例如您或您的组织。


• CheckoutPage ，如果它是网店中的结帐页面。


• CollectionPage li>
  
• ContactPage if这是联系页面。


• ItemPage 。 ProfilePage eg用于用户配置文件。


• QAPage 如果它是......好的，这个页面。


• SearchResultsPage 为您的搜索功能的结果页。


• ...







您的例子





您的三种情况是：



 <！ -  A  - 只有主题 - > 
< div itemscope itemtype =http://schema.org/Thing> 
< span itemprop =名称>无线技术< / span> 
< / div> 
  





<！ - B - 博客文章+主题 - >
< div itemscope itemtype =http://schema.org/BlogPosting>
< div itemprop =aboutitemscope itemtype =http://schema.org/Thing>
< span itemprop =名称>无线技术< / span>
< / div>
< / div>






<！ - C - 网页+博客文章+主题 - >
< div itemscope itemtype =http://schema.org/ItemPage>
< div itemprop =mainEntityitemscope itemtype =http://schema.org/BlogPosting>
< div itemprop =aboutitemscope itemtype =http://schema.org/Thing>
< span itemprop =名称>无线技术< / span>
< / div>
< / div>
< / div>


传达：有一些名称为无线技术。

B表示：关于无线技术的博客文章。
C表达：有一个网页包含一个博客文章作为该网页的主要内容）关于无线技术。 我不推荐使用A，使用B非常好，可能足以满足大多数用例。虽然C已经提供了比B更多的细节（也就是说页面只是一个单一的东西，而这个东西就是博客文章，而不是其他的东西），但这可能不需要这么简单案件。但是只要你能提供更多的数据，这种情况就会发生变化，在这种情况下，我会使用C。




After reading thousand of posts, questions, blog articles and opinions, I'm still a bit confused about how to markup a web page with microdata. If the main purpose of microdata is to help search engine to better understand the content of a web page (and web page is assumed implicitly), is it correct to start with itemtype Webpage in the body element, and then continue to markup the rest of nested elements defining which is the main entity, or is it better to start with an itemtype that is ideally the main topic of the web page and associate properties at the top level, or is better to have different itemtype at the top level (i.e. webpage, blog post and main topic of the page)?

An example will explain better my question: if I have to markup a webpage that contains a blog post about a specific topic (let's say about wireless technology), what should be the item at the top level? Should be webpage, blogposting, or wireless technology?

解决方案

The more the better (with exceptions)

When it comes to structured data, the guideline should be, in the typical case: the more the better. If you provide more structured data (i.e., you make things explicit instead of keeping them implicit), the chance is higher that a consumer finds something it can make use of.

Reasons not to follow this guideline might include:

• You know exactly which consumers you want to support, and what they look for, and you don’t care about other (e.g., unknown or new) consumers.
• You know that a consumer is bugged in a way that it can’t cope with certain structures.
• You need to save as many characters as possible (bandwith/performance).
• It’s too complex/expensive to provide additional structured data.
• The structured data is most likely useless to any conceivable consumer.
• …

What WebPage offers

So unless you have a reason not to, it’s probably a good idea to provide the WebPage type … if you can provide possibly interesting data. For example:

• It allows you to provide different URIs for the page and the thing(s) on the page, or what the page represents, like a person, a building, etc. (see why this can be useful and a slightly more technical answer with details).

• hasPart allows you to connect items which might otherwise be top-level items, for which it wouldn’t necessarily be clear in which relation they are.

• isPartOf allows you to make this WebPage part of something else (e.g., of the website if you provide a WebSite item, or of a CollectionPage).

• You have breadcrumbs on the page: use breadcrumb to make clear that they represent the breadcrumbs for this page.

• You provide accessibility information: use accessibilityAPI, accessibilityControl, accessibilityFeature, accessibilityHazard

• The author/contributor/copyrightHolder/editor/funder/etc. of the page is different from the author/… of e.g. the page’s main content.

• The page has a different license than some of the parts included in the page.

• You provide actions that can be done on/with the page: use potentialAction.

• …

Of course it also allows you to use mainEntity, but if this were the only thing you need the WebPage item for, you could as well use the inverse property mainEntityOfPage.

More specific WebPage types

And the same is true for the more specific types, which give additional signals:

• AboutPage if it’s a page about e.g. the site, you, or your organization.
• CheckoutPage if it’s the checkout page in a web shop.
• CollectionPage if it’s a page about multiple things (e.g., a pagination page listing blog posts, a gallery, a product category, …).
• ContactPage if it’s the contact page.
• ItemPage if it’s about a single thing (e.g., a blog posting, a photograph, …).
• ProfilePage e.g. for user profiles.
• QAPage if it’s … well, this very page.
• SearchResultsPage for the result pages of your search function.
• …

Your example

Your three cases are:

<!-- A - only the topic -->
<div itemscope itemtype="http://schema.org/Thing">
  <span itemprop="name">wireless technology</span>
</div>

<!-- B - the blog post + the topic -->
<div itemscope itemtype="http://schema.org/BlogPosting">
  <div itemprop="about" itemscope itemtype="http://schema.org/Thing">
    <span itemprop="name">wireless technology</span>
  </div>
</div>

<!-- C - the web page + the blog post + the topic -->
<div itemscope itemtype="http://schema.org/ItemPage">
  <div itemprop="mainEntity" itemscope itemtype="http://schema.org/BlogPosting">
    <div itemprop="about" itemscope itemtype="http://schema.org/Thing">
      <span itemprop="name">wireless technology</span>
    </div>
  </div>
</div>

A conveys: there is something with the name "wireless technology".
B conveys: there is a blog post about "wireless technology".
C conveys: there is a web page that contains a single blog post (as main content for that page) about "wireless technology".

While I wouldn’t recommend to use A, using B is perfectly fine and probably sufficient for most use cases. While C already provides more details than B (namely that the page is for a single thing, and that this thing is the blog post, and not some other item that might also be on the page), it’s probably not needed for such a simple case. But this changes as soon as you can provide more data, in which case I’d go with C.

这篇关于Schema.org中的网页结构的隐含性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！