如何评价元数据标准?

美国图书馆协会的“图书馆馆藏和技术服务协会”/“图书馆和信息技术协会”下属“元数据标准委员会”( ALCTS/LITA Metadata Standards Committee),正在制订一个“评价元数据标准”的文件,目的在于供图书馆、档案馆和博物馆(LAM)界开发、维护、治理、选择、使用和评估元数据标准。这里的“元数据标准”指结构标准(字段表、属性),不包括内容标准和取值词表。

文件最初名为“评价元数据标准的检查清单”,2015年1月20日发布草案,供委员会在2015年ALA仲冬会议期间讨论。检查清单共10项:
DRAFT Checklist for Evaluating Metadata Standards, BY JENNIFER LISS · JANUARY 20, 2015
1. The future of metadata is in the network 元数据的未来在网络中
2. Metadata should only be created where there is value 元数据应当只在有价值的地方创建
3. Metadata and metadata standards should be open and re-usable 元数据和元数据标准应当是开放而可重用的
4. New metadata standards should support new research methods 新元数据标准应当支持新的研究方法
5. A metadata schema without a maintenance community is of little enduring value 没有维护社区的元数据格式鲜有持续价值
6. Metadata standards of the future should be web-enabled by default 未来的元数据标准应当默认支持web的
7. Standards should be extendable with properties/classes/elements from other communities/standards 标准应当可以由来自其他社区/标准的属性/类/元素来扩展
8. Standards should be applicable to multiple communities and support selective adoption 标准应该可用于多个社区,支持选择性采用
9. Standards should support aggregation, exchange, automation, and computational analysis 标准应该支持集成、交换、自动化和计算分析
10. Metadata schema should follow the rules of “graceful degradation ” and “responsive design” 元数据格式应当遵循“柔性降级”和“响应式设计”规则

委员会讨论结果于3月1日发布:
Discussion notes: Draft Checklist for Evaluating Metadata Standards, BY JENNIFER LISS · MARCH 1, 2015

10月发布的新版草案吸收了不少讨论建议,由10点合并为7点,名称修改为“评价元数据标准的原则”(讨论曾建议用“声明”或“宣言”代替“检查清单”):
DRAFT Principles for Evaluating Metadata Standards, BY JENNIFER LISS · OCTOBER 27, 2015
1. Metadata and metadata standards should be part of the network 元数据和元数据标准应当是网络的一部分
2. Metadata and metadata standards should be open and reusable 元数据和元数据标准应当开放、可重用
3. Metadata creation should benefit user communities 元数据创建应当使用户社区得益
4. Metadata standards should support new research methods 元数据标准应当支持新的研究方法
5. Metadata standards should have an active maintenance and governance community 元数据标准应当有一个积极维护和治理的社区
6. Standards should be extensible, embeddable, and interoperable 标准应该可扩展、可嵌入、可互操作
7. Metadata standards should follow the rules of “graceful degradation” and “responsive design”元数据标准应当遵循“柔性降级”和“响应式设计”的规则

2016年ALA仲冬会议期间将有两场针对新版草案的报告。与年初草案博文下无人响应相比,新草案博文下已经有了7个评论,Diane Hillmann更是写了一篇博文逐点评论——可惜基本是负面的:
Metadata Matters: Review of: DRAFT Principles for Evaluating Metadata Standards, by Diane Hillmann, December 14, 2015

看完博文,首先感觉是元数据领域术语之缺乏共识,甚至对“元数据结构”“内容标准”“取值词表”竟然都被认为还需要定义来确定范围;至于如何评价元数据标准,更缺乏共识,这也是BIBFRAME讨论中常有的感觉。
Diane Hillmann在谈到互操作性时称:“互操作性尤其是我们应该都牢记的,但尽管很好,互操作性在实践中很少成功,因为不同模型实际上的不兼容。DC、MARC21、BIBFRAME、RDA和Schema.org就是例子——尽管它们“模块化”,总体上它们不能简单地用作“模块”,因为在模型背后的思考和各自的受众不同。”——也许是这样,但这不应该影响“互操作”作为元数据标准的追求目标或评价原则吧?
无论如何,Diane Hillmann的结论是,“评价元数据标准”很重要,但该文件目的未能在文件中达成,应该看看NISO的书目路标项目(NISO Bibliography Roadmap),暂停当前工作,先做个术语表。
对于本文件缺乏术语定义这一点,前述委员会讨论中也有提及。在共识缺乏的元数据领域,做一个术语表作为附录看来确实有必要。

关于NISO书目路标,参见:NISO发布新计划:开发书目词表交换标准(2015年3月19日)

《Web注释数据模型》对注释的分类

《Web注释数据模型》的W3C工作草案于2015年10月15日发布,该模型基于较早的社区草案《开放注释数据模型》,其自定义类和属性仍采用后者的命名空间(oa:) 。
Web Annotation Data Model (W3C Working Draft 15 October 2015)
Open Annotation Data Model (Community Draft, 08 February 2013)

首先,什么是注释?制订本规范的目的是什么?以下译自其摘要:
– 注释典型地用于表达有关资源的信息或者资源间联系。简单例子包括对单个网页或图像的评论或标签,或有关新闻报道的一篇博文。
– Web注释数据模型规范,描述一个结构化的模型和格式,使注释能跨软硬件平台被分享和复用。通用案例可用简单方便的方式建模,与此同时,可有更复杂的需求,包括链接任意内容到特定数据点或定时多媒体资源的片断。
– 本规范提供适应这些使用案例的概念模型,以及表达它的术语词表。为方便创建和消费注释,推荐特定的JSON格式。

本模型有三个主要成分:注释(Annotation)、主体(Body)、目标(Target)。简单地说,注释关联主体与目标,提供主体“关于(about)”目标的信息。
annotation
主体和目标是Web资源(有URI,但主体可以是文字),也可以是资源的片断(如文本被高亮选中的部分、地图的特定区域、视频的某一段),而主体和目标还可以包含在注释中(嵌套)。
“注释”、“主体”和“目标”有各自的属性和关系,比如创建(如谁、何时)和描述信息(比如语言、文件格式)。创建者除了个人机构,还可以是软件

“注释”有一个重要属性是创建的理由,被称为“动机(Motivation)”资源。动机的实例(Instance),可视为注释的类别,目前有13种。
———- Motivation 动机———-
bookmarking 书签
classifying 分类(确定类别)
commenting 评论
describing 描述
editing 编辑(修改)
highlighting 强调/高亮
identifying 标识(给URI)
linking 链接
moderating 评分
questioning 提问
replying 回复
reviewing 评介(评估,而非简单评论,如书评)
tagging 加标签

———- 题外话:BIBFRAME的“封面”在哪里? ———-
BIBFRAME 2.0取消了“注释”类,理由大致是可以直接采用《Web注释数据模型》。
如果拿BIBFRAME 1.0的注释类型对照的话,上述列表中没有对图书来说很重要的“封面”(Cover Art)。虽然我当初就有点疑惑,封面难道不是资源本身的特征?作为“注释”或许本来就可斟酌?不过原方案是考虑用户上传封面图片等情况,把封面作为外部资源的。
《Web注释数据模型》 附录D“扩展动机”称,本规范中的动机表衍生自注释领域的扩展调查,但许多场合需要或者希望更准确的定义;在这种情况下,推荐创建新的“动机”资源,关联到一个或多个已有(动机),作为下位关系
看上述清单,大概只有“描述”勉强可以。BIBFRAME 2.0会如何处理“封面”?

媒体(影音)资源元数据格式大全

Ontology for Media Resources 1.0, W3C Recommendation 09 February 2012
W3C的《媒体资源本体》提供描述媒体资源属性的核心词表,以及核心词表与Web上发布的媒体资源元数据格式的映射,目的在于提供元数据表达,以可互操作的方式描述媒体资源的特征与行为,使不同应用能共享和复用这些元数据。
元数据格式(18种):cableLabs 1.1, DIG35, Dublin Core, EBUCore, EXIF 2.2, ID3, IPTC, LOM 2.1, Media RSS, MPEG-7, OGG, QuickTime, DMS-1, TTML, TV-Anytime, TXFeed, XMP, YouTube Data API Protocol
元数据容器格式(6种):3GP, FLV, QuickTime, MP4, OGG, WebM
描述属性核心集(核心词表,28个属性[红色为dc元素,方括号内为dc标签])
Identification 标识4种identifier, title, language, locator
Creation 创作4种contributor, creator, date, location [coverage]
Content description 内容描述4种description, keyword [subject], genre [type], rating
Rational 关系2种relation, collection [source]
Rights 权利2种copyright, policy
Distribution 发布2种publisher, targetAudience
Fragment 片断2种:fragment, namedFragment
Technical Properties 技术属性8种:frameSize, compression, duration, format, samplingRate, frameRate, everageBitRate, numTracks

附:PBCore 2.1
《媒体资源本体》 号称收录所有在Web公开发布的元数据格式,但PBCore并未包含在内。或许因为是XML格式?
PBCore(维基百科)是声音和动态图像的元数据规范,起源于2001年“公共广播公司”(Public Broadcasting),宣称是基于都柏林核心的扩展(从名称上也可以看出)。2015年8月发布的2.1版定义有80多个元素(Elements),为向下兼容先前格式,仍定义有约50个特性(Attributes),而不是定义为独立的元素。PBCore目前正共同维护《媒体资源本体》中的EBU(欧洲广播联盟元数据规范)。
特别有参考价值的,是2011年PBCore在开放元数据注册网站(OMR)上注册的30个左右取值词表,用于影音资源的描述,相当丰富。
通用的如:创作者职能(21个),贡献者职能(146个),出版者职能(5个),受众层次(15个)
专业的如:载体(269个),代(182个),屏幕长宽比、位深、帧大小、采样率等。