元数据（metadata）本质上是关于数据的数据。当从iTunes音乐商店购买一首歌的时候，这首歌曲的文件本身（AAC文件）就是数据，而出现在音频播放器上面的歌曲信息（标题、歌手、专辑、歌曲时长，等等）则是元数据，这些信息以所谓的ID3格式存放在音频文件的起始处。如果正在使用Microsoft Word撰写论文，那么可以获取诸如页数、字数（包括或者剔除脚注）、字符数、段落数、行数之类的信息，论文是数据，而关于论文本身的信息则是元数据。
在HTML 中，有关HTML文档的元数据历史上被包含在<meta>元素中，放在文档的标题处。自从HTML2.0开始，这个元素就已经存在了，而且非常开放，它设计用来让作者在网页上包含各种元数据：指定一个属性（通过name属性，可以是任何想要的值）和一个值（通过content属性）。举例来说：
这里的属性是Author，值为Paul Haine。
还可以包含lang属性，这个属性定义了content属性值所用的语言，以便让任何能够读出<meta>内容的屏幕阅读设备适当地改变它的发音：
属性值的含义并非总是那么明显，但是有一个scheme属性可以用来提供进一步的信息。下面是HTML 4.01规范中的一个示例：
这能够帮助用户代理理解identifier属性表示的是一个ISBN编号，而不是一个随机字符串。但是，只有在用户代理理解ISBN编号的情况下这样做才有用，因此将这些值定义在一个外部纲要（profile）中，然后可以在<head>标签中作为属性值引用它：
对于纲要中应该放什么内容不应该放什么内容，HMTL规范并没有做出任何规定，因此，作者可以随意创建自己的属性和相关值。纲要可以是一份HTML文档；微格式（稍后将会讨论）使用标准的XHTML：类别名为profile的定义列表（http: //gmpg.org/xmdp/samplehtmlprofile.html）。都柏林核心元数据计划（稍后将加以讨论）是一个倡导采用可互操作元数据标准来描述文献的组织（http://dublincore.org/2003/03/24/dces），它的纲要使用的是RDF而不是XHTML，但它们底层的原理还是一样的：一个词语字典，每个词语都有各自的描述。
RDF表示资源描述框架（Resource Description Framework），它是一种按照三元组（triple）表达式（主—谓—宾）形式声明资源的元数据模型。在Wikipedia中关于主语的词条如下： “如果使用RDF三元组来表述‘The sky has the color blue’这个事实，那么主语是‘the sky’，谓语是‘has the color’，宾语是‘blue’。谓语是关于资源的某些特征和方面，它表达了主语和谓语之间的关系。”
最后，还有一个http-equiv属性可以代替name。HTTP服务器可以利用这个属性来收集用于HTTP响应消息头部的信息。如果使用Dreamweaver的话，很可能已经在网页中见过类似下面这样的内容：
上述的信息提醒用户代理这份文档是一份text/HTML，使用的字符集为ISO-8859-1。还有很多其他可用的值，但是有一个常见的值应该引起注意，因为人们认为它不是一个好的做法：
通过这种方法通知用户代理，它在5秒钟延迟之后应该试图加载http://newwebsite.com/（如果不设置URL的话，就表示这个页面每5秒钟要重新加载一次）。如果有用户访问那些已经被移到别处的内容，那么可以采用这种办法将用户的访问请求重定向到另一个位置，但事实证明这是一种快捷但质量不高的方法，并且最终无法让人满意，所以并不推荐使用它：它没有向浏览器或者搜索引擎提供任何反馈以便说明资源已经转移到一个新地方；它让用户的后退按钮失灵；而且可访问性不好，这是因为它不能让用户控制刷新的频率；也不能保证一定可行，因为用户可能已经禁用自动刷新。
更好的重定向方法也是推荐的方法是使用HTTP重定向（HTTP redirect），在服务器端进行重定向而不是在客户端进行。服务器通过发送HTTP状态码301或者307，分别用来通知用户代理所请求的资源已经被永久性地重定向或者临时重定向。
设置 HTTP重定向是一件比较费时的事情，但是它带来的好处更多。根据不同的服务器配置，设置HTTP重定向也有所不同，但在W3C质量保证网站（W3C Quality Assurance，www.w3.org/ QA/Tips/reback）上有一些针对最常见平台（Apache和微软IIS）的有用指南的链接。
这就是 <meta>元素，它只是一种用来在网页中包含元数据的标准方法。当然你很有可能正在使用其他一些方法：每个网页上的< title>是元数据；用来提供文档联系信息的<address>元素也是元数据；不管什么时候使用title属性、cite属性或者 datetime属性，都是在创建元数据。
但是， Web上的元数据曾经被不正确地使用，使它的名声不太好。如果name属性的值为keywords或者description，那么content属性的值就可以相应地提供与该文档内容相关的适当的关键字列表（关键字之间用逗号或者空格符隔开），和一份对于文档内容的精确总结。举例来说，如果撰写了一篇关于任天堂（Nintendo）历史的论文，就可以像下面这样使用<meta>元素：
在搜索引擎具体查看这篇论文的内容之前，这个元素将为搜索引擎提供有关该论文的信息，理论上有助于建立精度更高的搜索结果。即便是词语“任天堂（Nintendo）”没有出现在文章中，一款足够复杂的搜索引擎甚至可以了解到Gamecube和Game Boy是由任天堂制作的游戏机的名字。
但实际上，人们认识到，通过在<meta>元素中堆砌一些不适当的、带有误导性的关键字和描述，他们就可以欺骗搜索引擎，使自己在搜索排名中的位置得到提升，甚至对于一些与自己无关的搜索也同样有效。最终，搜索引擎完全终止了对<meta>关键字的引用，原因就是它们不可信赖。有些搜索引擎还在搜索结果页面中显示description属性的值，但通常只有在该值中包含搜索词的时候才会显示。
Cory Doctorow在文章Metacrap: Putting the torch to seven straw-men of the meta-utopia（www.well.com/~doctorow/metacrap.htm）中强调了7个问题，而蓄意使用不正确的元数据进行搜索引擎欺诈就属于其中之一，也就是说人们会撒谎。他对元数据所面临问题的分析会令人沮丧：人们不仅仅确实在撒谎，而且懒惰和愚蠢，这就进一步降低了准确度，拉大了元数据与真实内容之间的鸿沟。对元数据的收集要求人们，既要作为自己行为的观察者，又要作为自己行为的证明者，这就会让个人偏见和地区差异掺杂进来。对于准确的元数据由什么组成也有着不同的意见；那种认为存在一个能够对所有数据进行分类和描述的 “正确方法”的观点是错误的。
虽然元数据的前景看上去似乎有些黯淡，但是Doctorow并没有建议人们完全放弃元数据：“如果采集足够多的数据，那么元数据可以非常有用。‘元数据乌托邦（meta-utopia）’永远不会出现，但如果只是对流经因特网的信息进行粗略估计，那么元数据通常是一种好方法。”举例来说，Google确实就是这样做的——它根据有多少人链接到某个网站来确定该网站在与万维网剩余部分的关系中的重要性；链接到该网站的人数就是该网站的元数据。因此，尽管人们会撒谎，懒惰且愚蠢，而且意见不一，但是利用元数据还是能够获得有益的信息。
现在我们就来讨论在线元数据的“金童”——微格式。