OpenGraph或Schema.org?

只是想知道你们是否喜欢使用OpenGraph协议,如下所示:

<meta property="og:title" content="The Rock" /> <meta property="og:type" content="movie" /> <meta property="og:url" content="http://www.imdb.com/title/tt0117500/" /> 

或与Schema.org协议

 <div itemscope itemtype="http://schema.org/Product"> <span itemprop="name">Kenmore White 17" Microwave</span> <img src="kenmore-microwave-17in.jpg" alt='Kenmore 17" Microwave' /> <div itemprop="aggregateRating" itemscope itemprop="http://schema.org/AggregateRating"> 

我应该整合哪一个,我认为只有1是必要的? [你实际上只能整合一个吗?]

坦率地说,恕我直言 – 我认为OpenGraph对整个代码库“不那么干扰” – 因为它更容易实现部分视图[使用ASP.NET MVC],而Schema.org协议要求[至less在我看来]破坏性的HTML加载项在你的代码?

编辑:似乎我结束了两个 – 不知道这是否允许,但Schema.org上的文档不清楚。 值得注意的是, 这个链接并没有提供太多的信息

问: schema.org如何与Facebook Open Graph相关联?
Facebook Open Graph很好地满足了它的用途,但是它没有提供search引擎需要的详细信息来改善用户体验。

单个网页可能有很多组件,它可能会谈论不止一件事情。 如果search引擎了解页面的各个组成部分,我们可以改进我们的数据表示。 即使您使用Facebook Open Graph协议标记了您的内容,schema.org也提供了一种机制来提供有关页面上特定实体的更多详细信息。
例如,关于乐队的页面可能包括以下任何或全部内容:

  • 相册列表
  • 每张专辑的价格
  • 每张专辑的歌曲列表以及用于收听每首歌曲样本的链接
  • 即将到来的演出列表乐队成员的简历

所以我认为它们是一致的。

所以,从一些陈词滥调的隐喻开始 – 我们在谈论苹果和橙子,比较OG和Schema.org,当涉及到这个元数据时,它是马匹的课程。

正确的答案取决于你的意图,在你的页面添加元数据。 你希望获得什么? 这里的胜利是什么? 不同forms的元数据用于稍微不同的目的。

谷歌已经明确表示,它正在摆脱对微格式的关注,转而专注于Schema.org,以便为searchbuild立丰富的数据结果。 如果您想为Google优化,Bing和其他search引擎添加Schema.org标记。 这是HTML5已经介入的方向。

Facebook的OG标记将被添加,如果你想要的是从将你的内容转化为一个社交对象,并使其多点连接到Facebook社交图谱中获益。

根据我的经验,大多数人都希望从这两种方法中获益 – 尽可能地在search排名中做到这一点,并通过社交渠道增加覆盖面和分布。 所以,恕我直言,最好是尽可能的彻底添加Schema.org标记适合你的内容,并使用Open Graph元数据。 他们做了些微不同,但是免费的东西。

我们在这里谈论两个单独的概念: 语法词汇

Open Graph Protocol和Schema.org是词汇表 。 其他词汇例如是都柏林核心 , FOAF和SIOC 。

这些词汇表通常与特定的语法耦合。 如果您想用这样的词汇来描述HTML文档中的内容,则可以使用RDFa和/或Microdata 语法

我应该整合哪一个,我认为只有1是必要的? [你实际上只能整合一个吗?]

你的第一个例子使用Open Graph Protocol(= vocabulary)和RDFa(= syntax)。 你的第二个例子使用Schema.org(=词汇)和Microdata(=语法)。

你可以混合起来,只要你喜欢。 (你可以在同一页面上同时使用两种语法的词汇表,你可以只用一种语法来使用两个词汇表,你只能用两种语法或只用一种语法…)。 这完全取决于您的具体使用情况。

你想达到什么目的? 如果您对特定第三方parsing您的内容感兴趣,则应检查其文档。 它们通常只支持某些特定语法的词汇表。

但是,如果您想在不考虑特定用例的情况下使用语义元数据标记您的内容,则可以坚持使用一种语法,并使用适合您的内容的词汇表。 就个人而言,我会selectRDFa( 精简版 )。 它基于RDF ,与HTML以外的格式一起工作。 这是一个W3C推荐标准(Microdata不是)。 大部分词汇你会发现在RDF(S)中定义。 看到我对RDFa和Microdata的未来的回答。

他们都可以安全地一起使用。 目前,这两个努力使用不同的语法来编码HTML(W3C RDFa或Microdata)中的数据,但W3C正在积极讨论这些devise的最终融合。 或者至less有更好的兼容性。 Schema.org和OGP之间在词汇层面是否会趋同,还是两者兼顾的服务还有待观察。 但与此同时,它们既增值又可以安全地结合在一起。

所有这一切都取决于您是否试图将您的网站标记为社交世界(Facebook)或search引擎。 这两个build议,但如果你只有一个时间,然后优先考虑公司的营销重点。 OGP对Facebook来说是巨大的,但在SEO中没有一分之一的用处。 Seo完全依赖于微观数据,是创buildHTML5的正确方法。

Microdata上的HTML5Doctor http://html5doctor.com/microdata/

Google在讨论标记: http : //www.google.com/support/webmasters/bin/answer.py?answer=1211158

Bing谈论标记: http : //onlinehelp.microsoft.com/en-us/bing/hh207238.aspx


更新

对于find这个答案的人来说,自从我第一次发布以来,发生了很多变化。 Schema.org被所有主要的search引擎广泛使用,然后一些,但现在的标记是JSON-LD。 来自SEO Skeptic的大文章概述了Google所做的更改。

Google结构化数据提供了JSON-LD中的文档,尽pipeRDFa和微数据仍受到部分支持,但受到了极大的鼓励。

JSON-LD应该与任何社交渠道结合使用,您试图将目标locking为Facebook的OGP,Twitter的Twitter卡等

Google确实倾向于模式,开放图更适合与社交媒体相关的网页内容。 您的示例代码看起来不错,但不要忘记包含前缀

 < html prefix="og: http://ogp.me/ns#" > 

在每个页面的头部有ogp。

您可以通过使用丰富的片段testing工具来检查以确保ogp或模式工作

http://www.google.com/webmasters/tools/richsnippets

为什么不使用json-ld进行标记? 我正在考虑实施基于json-ld的schema.org标记。 这样,它不会侵入。 我的鬼博客使用它。 不知道它是否得到了search引擎的支持。 但是,schema.org上的所有示例现在都包含了json-ld的实现。 看到这里http://schema.org/WebPage

我所有的应用程序都使用twitter卡,fb opengraph标签和微格式标签,比如rel和结构化schema.org元数据。 而且我发现实施schema.org元数据最具影响力。 所以用json-ldreplace这最后一点,并保持代码清洁是很好的。 太多的标签,并build议保持您的HTML小;)

RDFa og作为一种统一的方式,可以在embedded到创build时不预测的容器中时更好地被REST识别内容。 如果容器被预先确定为search结果,那么schema.org微数据就被search机器人很好的理解了。 随着呈现是容器发布者的责任,这样的质量自由可能即兴的search排名,而schema.org将在内容创build者的意图的背景下即兴search结果的可理解性。 与竞争性语义标记技术一起使用时,词汇表通常会被忽略,因此最好只将schema数据与仅使用schema.org的微数据和仅使用RDFa的og数据结合使用。 微数据和RDFa可以在同一个文件中共存。

rdfa(opengraph)和微数据(schema)不能在同一个html页面上使用

“3)我们将继续支持现有的丰富网页摘要标记格式,如果您已经使用微格式或RDFa在网页上进行了标记,我们将继续支持它。使用新的schema.org标记或继续使用现有的微格式或RDFa标记,应该避免在同一个网页上混合使用这些格式,因为这会混淆我们的parsing器。

SRC: http : //googlewebmastercentral.blogspot.in/2011/06/introducing-schemaorg-search-engines.html