无处不在的元数据

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

 

都柏林核心走向死亡?

      上月中旬,DC-2004在上海图书馆召开,会议主题是”跨语言与文化的元数据”,会议发表的报告内容已经不限于都柏林核心元数据,而是广义的元数据了。今天又在Library Hi Tech News最新一期的目次上,见到一文题为:Dublin Core: An Obituary(都柏林核心讣告),真有点语不惊人势不休的意味。文章批评DC元数据缺乏专指性、没有标准的数据元素、互操作性差,进而断言DC将很快被”元数据对象描述框架”(MODS)所取代。

      实际上,从1995年的DC-1开始,DC发展至今已有近10年,从崇尚简洁一路走来,在语法上先是增加修饰词、后又允许自定义修饰词、进而允许自定义新元素,在语义上引入各种规范、还推荐自建词表,与简洁的初衷渐行渐远,其复杂程度已不下于MARC。与MARC相比,DC有不依赖特制程序阅读的优点,只是本来网络上采用DC的网页就不多,当搜索引擎不利用元数据建立其索引之后,其优点就不再突出了――毕竟元数据主要不是让”人”来阅读的,实际上还是要编制特定程序加以处理,与MARC的可读性相去并不太远。

 

    反观MARC,经过多年发展,已形成不同载体文献一体化格式,并有著录规则(如AARC2、ISBD等)、名称规范库、主题词表等相配套。MARC对普通人的障碍一是其定义的字段、子字段代号不直观,非专业人士无从理解其意;二是其2709格式无法阅读。这二点通过应用程序的转换,在图书馆联机公共目录显示格式中其实已经得到解决。 对图书馆界来说,与其开发、维护一个新的元数据,还不如改造已经成熟的MARC。

    美国国会图书馆的“元数据对象描述框架”MODS就是直接利用MARC的一个范例。MODS包含MARC 21的一个子集,以英语单词或短语代替MARC的字段和子字段,提供HTML/XML格式。从2002年6月公告试用1.2版以来,到2003年底已经发展到了3.0版。在2年多的发展中,已被一些数字图书馆项目建设所采用。或许真是元数据的明日之星?

    国内最关注DC的机构当属上海图书馆,在他们的主页上即有DC元数据中文网,收录了有关DC的各种有价值的内容。同时,他们也关注其他元数据的发展。MODS公开不久,他们的”数字图书馆研究资源门户”中就加入了其资源描述。同时,他们制定的多个元数据方案,都参考了MODS的标准。