无处不在的元数据

    印象中以前数据库的”字段”,现在都称为元数据了,各行各业都在研制元数据,电子商务、企业信息、政务资源、统计指标、档案管理、电子公文、信用信息……。原来生成/修改日期、访问权限之类计算机文件的”属性”,也变成了元数据,如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的基本字段、子字段应该不会有太大的变化。