我做了相当多的研究，但我不能理解这三者之间的确切关系。另外，既然W3C已经正式认可了RDFa，考虑到它与微数据的特性相匹配，你会推荐它吗?
非常简单:
- 微格式一种使用html页面作为人类可读文档和机器可读数据的方法，而无需重复(例如在head元素中粘贴CSV)。
- RDF为web设计的数据模型。无模式，使用url命名类型和关系。
- RDFa一种在html中编码(编写)RDF的方法，遵循微格式的风格(即最小化重复)。
- 微数据 RDFa的替代品，使用不同的属性和不同的数据模型。
更简单地说，RDF来自于使数据"网络化"的尝试。甚至还有一个插件用于浏览RDF的前身MCF(奇怪的是，来自苹果)。数据模型的设计使您可以编写您想要的内容，而不必预先安排如何与web上的其他人一起使用列名或关键字含义。RDF是使用XML标准编写(序列化)的(尽管还有其他更令人愉快的格式可用)。
所以在这个世界上，你可能有一个可读的主页(me.html)和一个数据主页(me.rdf)供机器抓取。这些机器不会理解<p>I live in <a href="http://example.com/Chicago">Chicago</a></p>的含义，但如果它们查找"livesIn"，它们可能能够使用:me ex:livesIn <http://example.com/Chicago>。
微格式也试图使数据'webby'，或者可能应该是web 'data-y'。这里的见解是，网页中有很多数据，在散文之间。如果您有一些提示，机器可以计算出上面的html片段基本上是一个地址。这些提示就是微格式。通常，他们使用html类名周围的约定来表明内容不仅仅是文本。
所以微格式不需要为机器单独的网页。但是由于微格式的工作方式，它只能覆盖一些类型的数据(地址、朋友链接、位置……)。每一个都是需要达成一致的特定公约。如果不小心使用，它们也会混在一起。
RDFa试图同时获得RDF的灵活性和微格式的简单性。微数据是对RDFa的响应，但使用了不同的数据模型(大致是数组和哈希，而不是关系模型)。与微格式不同的是，它们既不能规定提供什么类型的信息，也不能规定如何对信息进行编码。
为了弥补缺失，我们现在有schema.org，这是一个由大型搜索引擎(谷歌，必应，雅虎，Yandex)发起的索引网络数据的倡议。org对这些含义进行协调，以便搜索引擎知道，比如说，事件具有位置。微数据最初由schema.org使用，但现在微数据和RDFa都支持。
现在我会忽略微格式，而选择schema.org。我个人喜欢RDFa编码，但无论是RDFa编码还是微数据编码都可以正常工作。
我建议完全忽略语义网。搜索引擎不会因此给你带来更多的访问者。相反，他们会使用完美组织的数据来提供答案，而不会给你发送访问者。
今天你可以在下面的"movie box"例子中看到这个问题:https://www.google.com/search?q=The +教父
显示IMDb和烂番茄评分。维基百科的一个片段。对用户来说是好事，对网站来说是坏事。或者你过去和现在访问IMDb的频率是多少?
别忘了。显示的数据不仅仅来自IMDb或烂番茄。日期、导演、奖项、音乐、图片等已从其他网站收集。例如，一个搜索引擎可以很容易地在它的数据库中搜索"教父"+"导演"，如果100个网站中有99个包含"弗朗西斯·福特·科波拉"这个名字，它很容易验证答案，而不需要任何人工交互。
最后，搜索引擎能够建立自己的内容，而无需付费或提及作者。有了语义分类，你将使他们更容易。
这三种方法都是为了让网页内容更具语义性。
rdfa面临许多进入壁垒;它与XML (rdfa是基于XML的)在web的早期经历了同样的成长痛苦，只是可能更重要，因为参与的开发人员更少。
我对rdfa的了解还不足以推荐它胜过微数据。我偏向于微数据，因为谷歌、雅虎!微软(现在的必应)联合创建了它。Rdfa正在开发中，微格式提案已经完成。此外，微格式已经在网络上大量生产和消费。因此，三大巨头决定串通一气，推出了微数据。我有点厌倦了，我想是因为我根本不明白为什么微格式被抛弃了。听起来像是一堆障眼法。
所以我推荐所有的微格式。它们太简单了。太棒了。你能用微数据实现什么用微格式做不到的?
说……我会选择微数据而不是rdfa，因为它们同样简单。数据属性远优于HTML类。事实上，也许这才是最大的奖励?数据属性?就像你的研究一样，我花了很长时间努力寻找微数据背后的原因，但我能找到的都是普通的千篇一律的帖子。