在更广泛的XML词汇表中重用元数据

日期： 2008-08-17 作者：David Mertz 来源：TechTarget中国 英文

　　Dublin Core Metadata Initiative（Dublin核心元数据计划，DCMI）是用于处理关于文档信息的标准词汇表。总的来说，DCMI词汇表定义描述文档用途、上下文和出处（而非文本自身）的术语层次系统。David说明了如何将DCMI提供的一组元数据指令重用于（通过名称空间）范围更广的XML词汇表，比如RSS的变体。DCMI吸收了多种的不同的标准，包括ISO标准和NISO标准。


　　我首先要警告的是：Dublin核心元数据计划 实际上对XML没有做什么。实际上，DCMI最广泛的应用可能是在名称空间增强的XML文档中，但是一般来说（或者专门就这一组元素而言），元数据完全没有要求底层的数据采用XML编码。相反，DCMI是一种通用的框架，描述关于各种类型文档的有用信息集。使用DCMI描述的某个文档可以使用XML编码，也可以使用其他多数电子或者物理格式，其主题可以是人类创造的任何成果。


　　DCMI是一种谈论文档的词汇表，其术语的含义和用法有定义良好（相对而言）的语法。DCMI中的术语被划分成最小化的基本元素集和对这些基本元素细化的可选集。


　　DCMI的主要好处是标准化了元数据术语的拼写方式和这些术语的值的格式。比方说，可以用“作者”、“艺术家”、“创作者”、“制造者”或者“创建者”这些近义词来标识一部著作，DCMI标准化了该角色的名称，“创建者（creator）”，以便能够用一致的方法来比较作者可能相同的文档。自然，可能成为创建者的人或者组织的名称可以是各种各样的，比较不同的创建者时，DCMI应用程序可能希望在DCMI推荐标准的规定之外进一步标准化姓名的格式（比如“名，姓”）。


　　除了标准化元数据术语之外，DCMI还提供了根据枚举或者模式规范选择值的建议。比方说，“date”一词显然是可供选择的元数据术语，但是日期有不同的格式。DCMI建议采用W3C Date and Time Formats说明所规定的ISO 8601子集表示日期值。在其他一些方面，如“coverage”（定义为“资源内容的区域或范围”），DCMI建议采用Thesaurus of Geographic Names中的枚举名称（庞大但是有限）。


　　描述文本


　　作为具体使用DCMI元数据的一个例子，可以看一看文档“DCMI Metadata Terms”，大概是按照DCMI的原理精心设计的一个实例。顺便说一下，DCMI词汇表术语是大小写不敏感的，因为常常被用于大小写不敏感的上下文，如HTML（即XHTML的前身）。


　　“DCMI Metadata Terms”文档以几种不同的方式编码元数据，至少包括HTML版本。这种冗余性很有意义，因为它说明了DCMT应用中可能遇到的三种最重要的编码风格：


　　·无格式文本
　　·HTML中的元标签
　　·RDF中的元数据


　　无格式文本


　　第一种风格可以称为文档元数据的 无格式文本编码。在线版本中，下面的信息放在一个HTML表格中，并以不同的背景颜色表示，但是如果打印成一本书或者印成封面（或者像下面这样格式化）就没有明显的效果了。具体而言，使用DCMT的非电子版材料必须使用类似下面这样的格式：


　　DCMI元数据术语


　　创建者：DCMI应用公告板


　　标识符：http://dublincore.org/documents/2004/06/14/dcmi-terms/


　　发表日期：2004-06-14


　　最新版本：http://dublincore.org/documents/dcmi-terms/


　　替换：http://dublincore.org/documents/2003/11/19/dcmi-terms/


　　翻译：http://dublincore.org/resources/translations/


　　文档状态：这是一份DCMI推荐标准。


　　说明：该文档是Dublin核心元数据计划所维护的元数据术语的更新规范，包括元素、元素细化、编码方案和词汇表术语（DCMI Type Vocabulary）。


　　有效期：2004-06-14


　　每个斜体字段名称都是关于所依附的文档的元数据，虽然这里没有列出整个文档，但是要注意 标识符（Identifier）字段是一个URI，如果可用的话就可以定位相关的文档。


　　无格式文本头部中给出的几个元数据字段，Creator、 Identifier和Description属于DCMI的15种基本元素。其他字段Replaces、Date Issued和Date Valid是元素的细化，一般而言就是说这些元素继承自基本元素（但不是字面意义上的OOP风格的继承）。但其他的字段似乎并不属于DCMI，而是为这种应用自己添加的成分，其他应用如果不能识别这些字段通常可以忽略。


　　HTML中的元标签


　　通过印刷方式使用无格式文本编码的DCMI元数据在某种程度上是针对所处理的作品的。事实上，许多非电子化的作品不可能真正直接编码元数据。比如，音乐作品或者油画都没有能够列出这些元素的封面或者标题页。即使是撰写的作品如果不允许创建新的编辑内容，也不能直接附加这类无格式文本。显然，诸如此类情况下元数据只能存在于某种附属的或者包装用的文档中。这些内容完全可以写在作品的包装上，比如包扎古籍的收缩包装或者油画所配的包装盒上。


　　对于电子格式，附加元数据稍微容易点。特别是HTML有一个标签可以放在其<head>元素中，即<meta>元素，这个元素看起来像是临时拼凑的。DCMI Metadata Terms的HTML版本就用这种方式编码了几种基本DCMI元素。 清单1给出了完整的<head>元素：


　　清单1. DCMI Metadata Terms HTML版本的Head元素
　　<head>
　　<title>DCMI Metadata Terms</title>
　　<link rel=”schema.DC” href=”http://purl.org/dc/elements/1.1/” />
　　<meta name=”DC.title” content=”Dublin Core Metadata Terms” />
　　<meta name=”DC.description” content=”This document is an up-to-date
　　  specification of all metadata terms maintained by the Dublin Core
　　  Metadata Initiative, including elements, element refinements,
　　  encoding schemes, and vocabulary terms (the DCMI Type Vocabulary).” />
　　<meta name=”DC.publisher” content=”Dublin Core Metadata Initiative” />
　　<meta content=”text/html; charset=iso-8859-1″ http-equiv=”Content-Type” />
　　<link href=”index.html.rdf” rel=”meta” />
　　<link type=”text/css” href=”/css/default.css” rel=”stylesheet” />
　　</head>
 
　　清单1中有几点要注意。HTML文档中的标准<title>也是一种元数据，但是因为缺乏其他伴随的术语用处不是很大。HTML头部给出了到schema.DC的<link>，为了明确表示在其他<meta>标签中使用的是DCMI术语，通常都这样做。当然，HTML规范本身和多数HTML处理应用程序（如Web浏览器）都不知道如何处理，但是它们应该得体地忽略并保留这些内容。


　　术语DC.title、DC.description和DC.publisher是DCMI的基本元素，并使用伪名称空间限定。publisher元素在无格式文本版本中没有给出（但也许不应该遗漏这个元素）。title不仅仅被明确地标为字段，而且所有的DCMI文档都将该字段作为文档的第一项内容，并放在<h1>标签中。将其看作标志字段title是完全合理的，尽管其标记和其他字段不同。


　　和很多HTML文档一样，DCMI Metadata Terms也包括一个非DCMI Content-Type元数据标签。并非所有元数据都是DCMI，因此DCMI应该能够和外部的元数据标签很好的协作。


　　RDF中的元数据


　　我还没有提及HTML文档中的另一个元素，啊，是两个元素。 样式表链接是HTML的一种外部资源，这里无需赘述，尽管也可以看作是某种元数据，关于文档最佳表示的元数据。更有趣的外部资源是到index.shtml.rdf的<link> 。看一看清单2：


　　清单2. 通过DCMI Metadata Terms链接的RDF资源
　　<?xml version=”1.0″?>
　　<rdf:RDF
　　         >
　　<rdf:Description
　　     rdf_about=”http://dublincore.org/documents/dcmi-terms/”>
　　<dc:title>Dublin Core Metadata Terms</dc:title>
　　<dc:description>This document is an up-to-date specification of all
  metadata terms maintained by the Dublin Core Metadata Initiative,
  including elements, element refinements, encoding schemes, and
  vocabulary terms (the DCMI Type Vocabulary).</dc:description>
　　<dc:publisher>Dublin Core Metadata Initiative</dc:publisher>
　　</rdf:Description>
　　</rdf:RDF>
 
　　也许能够找到DCMI术语的最常见的地方就是嵌入在RDF中。XML名称空间对这种嵌入有很好的支持：DCMI术语存在于dc: 名称空间中，RDF本身存在于rdf: （或者作为默认的名称空间）中。这样就为嵌入其他的词汇表留了余地，如xhtml: 。


　　不过，dc:名称空间不是DCMI推荐的唯一名称空间。DCMI 15个基本元素通常放在dc:名称空间中，但是追加的术语和细化通常放在dcterms:名称空间中。namespace. dcterms:名称空间中细化存放的位置是早期推荐版本的修订，祖先术语使用dc:名称空间限定。比如，DCMI Metadata Terms的RDF文件现在可以使用下面的元素加以改进：


　　<dcterms:issued>2004-06-14</dcterms:issued>
 
　　当然要正常工作，根元素<rdf:RDF>中还必须添加一个名称空间规范 。


　　可能还会遇到更老的RDF文件，使用类似的限定的祖先元素：


<dc:date.issued>2004-06-14</dc:date.issued>
 
　　我不清楚为何改变了这种用法，初看起来，这种老的用法似乎更容易让我理解。不过我没有追踪关于作出这一决策的讨论，而假设有充分的理由。顺便说一下，您也可以在http://purl.org/dc/dcmitype/找到dcmitype:名称空间。


　　结束语：一般的XML用法


　　这期文章中说明如何在XML中尤其是RDF中使用DCMI。不过一般而言DCMI尤其适合于嵌入在XML中。不论多么棘手和困难（我的同事Uche Ogbuji曾经提到过一些，，名称空间都是组合XML词汇表的一种非常优雅的方式。


　　在XML而非HTML、无格式文本或者作品的不同包装形式中嵌入DCMI的主要优点是，DCMI元数据不仅可用于注释整个文档，还可用于说明特定的元素。


　　比方说，在以前的文章中，我曾经考察过DocBook/XML并用它来标记博士论文中的章节。我可能希望返回去并使用针对其研究成果的元数据注解该文档。很多特性是应用于整个文档的，比如我撰写了整篇文章。但是其他特性可能是针对不同章节的，比方说各个章节撰写的日期不同，在编篡时可以替换了不同的成分。


　　作为章节上下文的一个简要例子，下面我给出了高度缩减仅保留下DCMI注解的DocBook版本：


　　清单3. DCMI注解的DocBook/XML学术论文章节
　　<?xml version=”1.0″?>
　　<chapter
　　        
　　         >
　　  <dc:creator>David Mertz</dc:creator>
　　  <dc:identifier>http://gnosis.cx/publish/mertz/chap5.xml</dc:identifier>
　　  <dc:title>Hegemony, and Other Passing Fads</dc:title>
　　  <title>Hegemony, and Other Passing Fads</title>
　　  <sect1>
　　    <title>Forgotten AIDS Myths</title>
　　    <dc:title>Forgotten AIDS Myths</dc:title>
　　    <dc:date>1998-11</dc:date>
　　    <dcterms:replaces>
　　        http://gnosis.cx/publish/mertz/sex_wars.html</dcterms:replaces>
　　  </sect1>
　　  <sect1>
　　    <title>Day-Care Devil Worshipers</title>
　　    <dc:title>Day-Care Devil Worshipers</dc:title>
　　    <dc:date>1998-08</dc:date>
　　    <sect2><title>Remembering Events</title></sect2>
　　    <sect2><title>Forgetting Everything</title></sect2>
　　    <sect2><title>Motives, Right and Left</title></sect2>
　　    <sect2><title>Flashpoints</title></sect2>
　　    <sect2><title>Obtaining Outsidelessness</title></sect2>
　　    <sect2><title>Remembrance of Ideologies Past</title></sect2>
　　  </sect1>
　　  <sect1>
　　    <title>Tsars and Jihads</title>
　　    <dc:date>1997-10</dc:date>
　　    <dc:title>Tsars and Jihads</dc:title>
　　  </sect1>
　　</chapter>
 
　　我只留下了章节的标题，但是您可以从中看出如何使用DCMI术语像子文档那样注解每个章节元素。显然，除了这里所用的术语外，您还可以增加其他的术语。


　　关于作者


　　对于David Mertz来说，世界就是一个大舞台，他的职责就是专门提供临场指导。可以通过mertz@gnosis.cx和他联系，他的生活在http://gnosis.cx/publish/上有翔实的记录。欢迎对本文、过去和将来的文章提供意见和建议。看一看David所著的Text Processing in Python 。 

我们一直都在努力坚持原创.......请不要一声不吭，就悄悄拿走。

我原创，你原创，我们的内容世界才会更加精彩！

【所有原创内容版权均属TechTarget，欢迎大家转发分享。但未经授权，严禁任何媒体（平面媒体、网络媒体、自媒体等）以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

作者

David Mertz
David Mertz

相关推荐

  • 案例分析：多阶段元数据一致性分析在北京银行的应用

    还记得苦逼的程序员们在系统上线当天彻夜加班排查上线脚本问题的场景吗？我们给出的办法使用元数据对比分析场景来解决这类问题，那么北京银行科技部门是如何借助元数据管理工具实现IT运营效率的提升。

  • 三个场景玩转元数据应用

    很多企业也意识到了元数据重要性，并购买了元数据系统，但系统如何发挥价值，是需要考虑的问题。元数据到底应该管理哪些数据？分析哪些环节？看似抽象的系统的功能在企业IT、数据建设中有哪些应用场景？

  • 云存储和容量管理

    云存储听上去是如此简单。你只需为你所使用的支付费用，并且在任何时候，都很容易判断你使用的存储量。然而，经验丰富的IT专业人员都清楚，实施一项新技术或方法很少会如此简单。

  • BPM和元数据帮助你消除流程孤岛

    你的公司是否有四个以上的部门？是否已经成立超过了五年？大部分中层管理人员是不是不得不花很多时间工作？我敢打赌这些部门没有使用业务流程自动化系统来跨越部门障碍。