印象中以前数据库的”字段”，现在都称为元数据了，各行各业都在研制元数据，电子商务、企业信息、政务资源、统计指标、档案管理、电子公文、信用信息……。原来生成/修改日期、访问权限之类计算机文件的”属性”，也变成了元数据，如MP3文件的元数据ID3，定义了作曲家、词作者、演唱/演奏者等数十个属性；更有数码相片文件的元数据复杂到了定义拍摄的经纬度和海拔。
曾以为Google的关键词检索只需要人工智能分析词间关系，组成一个词表（或许是语义网、本体什么的？），不需要元数据。但看着Google近半年接两连三地推出各种专类检索工具/功能，学者Google Scholar的引文、电视Google Video的节目预报、地图Google Maps的企事业单位信息、电影（movie:命令）的影评与影院信息，以及最近引起广泛争议的Google工具条的网页自动链接AutoLink功能，终于明白其实在Google简洁检索界面的背后，肯定蕴藏着极其复杂的元数据，用以组织机器搜集到的看似无序的信息。
我们的机读目录MARC有差不多40年历史了，或许可称得上元数据的前辈。定义了那么多字段、子字段，虽然不是都要用，看上去也很烦。于是不满意MARC者设计出都柏林核心元数据DC，来代替烦琐的MARC，只用十多个元素就够了，很爽。可渐渐发现不够用，于是加修饰词，先是标准修饰词，然后又可以自定义修饰词，现在弄得跟MARC也相去不远了。
其实当深入到事物的内部，必然越分析越细致，需要的元素也就越多，就好象前面所举MP3和数码相片元数据的例子。看出版商描述图书信息的元数据ONIX，近200个元素(tag)，与MARC相比，其烦琐程度可说是有过之而无不及。
看来，在今后相当长的一个时期里，综合描述各类文献元数据的MARC还是很安全的――不会被淘汰。或许磁带时代顺序读取的产物2709格式，会因与时俱进而被XML或别的什么格式所代替，但MARC的基本字段、子字段应该不会有太大的变化。