DC词表的维护：实践、策略与模型，本文主要内容关键词为：词表论文,模型论文,策略论文,DC论文，此文献不代表本站观点，内容供学术参考，文章仅供参考阅读下载。
1 DCMI的实践模式
在过去的9年中，包含15个元素的都柏林核心已经成为数字世界的一个部分。它们被印在T恤衫上，被用在亿万条元数据记录中，并且已成为国际标准：ISO15836[6]。其发起者DCMI也由一个用户团体发展成为负责对它进行维护的网络组织[7]。
然而，在DCMI内部，讨论更多地集中在核心集外围元素集所带来的问题，而不仅仅是这个核心集。在1994年，讨论的问题还只是要不要在网页中嵌入描述符，如今，问题变成一大堆：技术上的体系结构、命名政策、还有维护一个标准要通过怎样的管理流程等等。很多讨论是为了弄清这些元素在不断变化发展的Web技术中怎样使用，从早年简单的HTML技术，到XML和XMLSchemas，再到资源描述框架RDF，以至于正在发展中的本体（Ontology）语言。语义Web（Semantic Web）这个模糊而又强有力的愿景驱动着很多这样类似的实践进展，在语义Web中，由明确定义的数据和元数据支撑的应用将变得更加自动化和智能化。
本文论述了应用DC的一些原则和实践，这里的DC不是仅仅指DC的15个元素，而是指整个都柏林核心元数据体系。具体地说，本文从语义Web词表管理的角度，探讨了四个方面的内容：
·DC的语法规则和抽象模型；
·对元数据术语（Metadata Terms）进行标识的政策；
·元数据术语的文档管理；
·元数据维护和管理的开放机制
总之，所有这些方面为在一般意义上声明和维护一个元数据词表提供了一种参考模型，DCMI的经验也会为不同领域和用于不同目的的词表的维护者们提供经验和教训。
2 基本原则
2.1 建立数据模型
DC的最初理念是一个一般化的，容易理解的简单元素集，可以满足简单描述的最基本需求，可以把它比作元数据的“洋泾浜”，但却是一本足以帮助“数字化旅行者们”在知识和文化多元化的因特网上的发现资源的词汇手册。DC的起草者们最初以图书馆的目录卡片作为对照，问他们自己：在一个查询表单中，用户最希望看到哪些元素？
然而早期的研究人员认为，必须建立相应的数据模型才能便于机器处理，这样，问题由“我们在屏幕上看到什么”变为“机器会如何理解它们”。于是，在1996年引入了“Warwick框架”，作为一种兼容各种相互替代或互为补充的不同元数据方案的容器。该框架既为限制DC本身的应用范围（局限于“资源发现”），也提供了一个可以把DC和其它词表统一起来的概念基础，以满足任何单一元数据方案无法满足的需求[22]。到了1997年，当万维网联盟（W3C）开始设计资源描述框架（RDF）的时候，工作组的部分出发点就是想为类似DC的描述性元数据词表提供一种形式化的“模式”（Schemas）定义机制，以及支持DC模块化和进一步修饰限定的需求[25]。
W3C对RDF的这个形式化模型的苦心经营，对形成DC简单而有限的数据模型产生了重要影响，这个模型有时也被称为“刺猬模型”：一个单一的实体（即“资源”）上丛生着多个属性（即“元素”），每个元素又有相应的字符串值，有时候被称为“特定文字”（appropriate literal）”。2002年，为满足用户在具体应用中对DC的特定需求，采用元素修饰词和编码体系对元素的值域和范围进行进一步限定的理念被引入[10]。虽然DCMI的术语体系有一些自己的特点，但DC模型还是从根本上与RDF保持一致的[2]：
·DC的“元素”在RDF中被称为“属性”。
·DC的“元素限定”（修饰词的一种）在RDF中是语义上更为狭窄的“属性”。例如：DCMI的元素限定“Date Created”在RDF中被定义为元素“Date”的子属性。
·DC的“编码体系”（另一种修饰词）为理解元素的值提供一种上下文环境，编码体系在RDF中被定义为“类”（classes）。例如：编码体系“DDC”用于表示一个元数据的值取自于“杜威十进分类法”（Dewey Decimal Classification）。
也许，像其它形式的人类语言一样，元数据也会不可避免地在简单化的需要和复杂化的驱动下步履维艰。要在一个通用词表的框架中进行扩展，同时不破坏或扩展“一个资源对多个属性”的“刺猬模型”，就必须尊崇人们所熟知的“向上兼容”（dumb-down）原则。根据这个原则，当一个资源的修饰描述应该能够经过简化而变得更为一般化，虽然这样会损失一些语义。例如：“Date Created”可以解释为更一般化的“Date”，虽然在这个过程中损失了特定的语义。
2.2 模型的简化与充实
用户从一开始就对刺猬模型及其修饰方式感到不满。该模型本身没有提供一种可以在统一框架中描述不同“刺猬”的方法。例如，不仅仅只描述一个信息资源的“属性”（如Creator，Title和Subject），还要描述“属性”的“属性”（如“Creator”的属性Name，Affiliation和Birthdate）。在具体的应用中会有无数的方法超越该模型的界限，但是，以一个更一般化的方法来解决问题总会面临失去上下文语境的挑战，而如果不以刺猬模型为基础，机器就根本无法理解或推导对于刺猬模型所作的任何事实上的扩展。
一个事实上的扩展方法是：把一个作者的各种属性（如Name，Affiliation，Fax Number）硬塞进“Creator”元素的字符串值中。对于那些能够解析该字符串而获得其各个组成部分的应用来说，有了这样一个“结构化值”，就可以从容地解决一个具体的问题。而对于那些把这样的元数据和从许多不同的其它的数据提供者那里收集来的元数据放在一起的应用来说，把外来的信息嵌入这样一个字符串中，会打乱原有的公共索引。
另一个方法是利用RDF这类更为复杂的数据模型所提供的表达能力，把一个字符串值（一个“标签”）和一个抽象的实体（一个“资源”）联系起来，而这个实体可以有一个任意的属性集。例如根据一种在RDF框架中表示DC的方式，一个“Creator”既可以模型化为一个实体和它自己的属性，如Birthdate和Affiliation等，同时它也可以把它看成是用其名字所表示的特定文字[21]。
Andy Powell在其提出的DC元数据抽象模型[23]的扩展中，提到刺猬模型的一个已知的局限及其解决办法。在实践中，元数据的创建者总是在众多的模型和技术的限制和假设下工作的。通过明确一个通用的包含完整特性的模型，比如在这个模型中包括但明确区分“资源”的属性值和“特定文字”的字串值，来提供一个认识的共同起点，而不至于被一些具体的技术和置标方案所固有的功能局限所误导。
正如目前提议的，采用RDF能够最大程度地实现DC元数据抽象模型。然而，就像人们长期以来所认识到的那样，由于HTML的META标签集缺乏区分多个实体（一个资源和它的创建者）的机制，所以，HTML不能支持该模型的一些具体功能，而另一些置标技术，如XML，则介于两个极端之间。
该抽象模型也为使用结构化值的指南提议提供了一个基础。根据对元数据记录的经验分析，结构化值常常包括：未标记字符串（Unlabelled Strings）（例如一个简单的日期格式），标记文本（例如一个用HTML或TeX标记过的文本），标记字符串（一个带有多个组件的vCard）。除这三种类型以外，还有由“相关资源描述”（Related Resource Descriptions）组成的结构化值，“相关资源描述”是一个属性集，这个属性集并不直接与被描述的资源相关，而是与被描述资源的属性实体相关。抽象模型要求：当用相互联系但逻辑独立的实体组成的“相关资源描述”来修饰元素时，这个元素的字串值必须适合于这个特定的元素。
都柏林核心元数据的方法和模型是元数据多样性世界的一个反映。既然互操作意味着存在一个相互比较和翻译的共同基础，那么抽象模型和基于这个模型的分析就可以用于在不同的元数据之间实现互操作。一个典型的例子是IEEE LOM，它是一个与DC规模相当而模型全然不同的元数据标准，在该标准成员的帮助下形成了目前这个抽象模型。正由于此，该模型也可以提供一个理解DC与其它元数据标准之间进行互操作的基础。
3 元数据术语的标识
3.1 DCMI的命名空间政策
因特网的革命性在于使来自不同网络服务器的信息资源能够在一个全球性的地址空间中被检索到。语义Web又使全球地址空间向全球标识空间前进了一步。Tim Berners-Lee（注：Tim Burners-Lee是Web的发明人，他发明了HTML置标语言和HTTP协议，写了第一个Web服务器和浏览器软件。目前任美国麻省理工学院研究员和万维网联盟主席。近年来致力于推进语义Web的研究和应用。）说：“统一资源标识符，或者说URI，是Web体系结构中最基础的规范，尽管它很简单。任何东西，尤其是Web上的任何东西，都必须由各不相同的字符串来标识，这是一个核心原则。[4]”
URI不仅可以唯一标识信息资源（如网页、科学报告预印本、卫星照片、视频剪辑等诸如此类的东西），还可以标识描述信息资源的元数据术语。由于这些简洁的字符串与某一领域的权威机构有关，因此URI可以独立地作为被其所指的元数据术语的一个权威说明。虽然所有的数据技术都可以应用这种机制，但最直接有用的还是与Web信息描述相关的技术领域，如KLink，Topic Maps和RDF。
DCMI于1997开始试验URI技术，2001形成正式的命名空间政策[13]。该政策声明了3个DCMI命名空间，它们分别是：
·http：//purl.org/dc/elements/1.1/
·http：//purl.org/dc/terms/
·http：//purl.org/dc/dcmitype/
它们分别指派给：15个元素的都柏林核心，核心集以外的其它元素和修饰词，DC类型元素（Type）的规范取值词表。一个DCMI术语的URI是由DCMI命名空间加上该术语的字符串名称而组成。例如：
·http：//purl.org/dc/elements/1.1/title
·http：//purl.org/dc/terms/extent
·http：//purl.org/dc/dcmitype/Image
分别标识“Title”（15个核心元素中的一个）“Extent”（一个元素限定）和“Image”（DCMI类型词表中的一个术语）。
除了核心元素的命名空间显示出其先于整个命名空间政策之前出现，DCMI的命名空间URI没有透露更多的版本信息。但是术语可能而且必然会随着时间而变化，该政策的焦点在于弄清楚唯一标识的变化会带来怎样的后果。虽然大量的小错误可以得到改正而不影响URI，然而，语义特性的改变，例如一条定义中用词的变化，可能导致一个新的术语和URI的诞生。为了支持未来对遗留元数据的解析，该命名空间政策要求维护所有具有URI的术语的正式文档，包括那些在将来可能被置于“废弃”状态的术语。
明确给出元数据术语出处的能力是开发跨标准的语义地图和互操作服务的前提。2002年9月，DCMI加入了“CORES解析”计划，这是在8个主要的语义元数据标准之间达成的协定，用URI标识它们各自的元数据元素。这8个标准是：Dublin Core，MARC21，UNIMARC，GILS.ONLX，CERIF，DOI和IEEE/LOM。该协定把不同标准的元素定义为“可以跟其它标准的元素进行比较和映射的意义单元”。该协定还呼吁这些标准的维护组织能够依据稳定性和持久性的要求清晰地阐明他们的政策，并且维护他们的URI[3]。
3.2 版本的标识
由于命名空间政策的限制，DCMI的词表会随着时间而不断增长和变化：新的术语加进来，使用说明引用的参考文献会被更新，术语被赋予的状态会变化，等等。如上文所述，包含15个元素的都柏林核心最初作为一个元素集而获得一个版本号“1.1”，但在DCMI命名空间的URI字符串中，很难嵌入这个版本号“1.1”。
到2000年7月，新发布术语的命名空间不再带有版本号，因为采用阶段性的、分批发布的版本标识看起来并不适合一个规模不断扩大的词表。但是，具备将一个术语集与一个给定的日期联系起来的能力，对于诸如图书馆自动化外包项目、DCMI术语的翻译以及以后对遗留元数据进行解释等需求，都具有潜在的价值。对这个问题有一个可行的解决方案，即既为单个术语给出版本信息，也为那些成批的术语文档网页给出版本信息。前者会按照不同的频率更新，而对于后者来说，只要增加一个术语或者术语集中有任何改变时，它都会跟着改变。
单个术语可以通过保存其相关属性改变前的快照，来给出版本信息，并给定一个URI，如下所示：
·http：//dublincore.org/usage/terms/history/#Image-002
·http：//dublincore.org/usage/terms/history/#Image-001
虽然，现在DCMI的命名空间政策并不支持这样的URI，但它们还是作为有效的标识符对术语的版本进行标识。目前，这些URI在Web文档中被解释为一个Web文档的“锚定”，一个文档可以包含一个DCMI术语从过去到现在所有版本信息的快照。
DCMI术语集的文档网页的版本管理方法，同样也是所有其它重要DCMI文档的管理方法，即同时给一个特定的历史版本和一个最新版本各一个URI标识，同时带有指针，指向与之最直接相连的一个版本。例如：DCMI元数据术语的2003年版本的文档的URI：
·标识符：
http：//dublincore.org/documents/2003/03/04/dcmi-terms/
·最新版本：
http：//dublincore.org/documents/dcmi-terms/
·被替代：
http：//dublincore.org/documents/2003/11/19/dcmi-terms/
“标识符”下的URI所指向的Web网页是永久保存不会变化的，“被替代”是其下一个版本，“最新版本”下的URI是DCMI网站上不断更新的指针，指向DCMI术语的最后更新版本。
3.3 注册受控词表
2000年7月通过的修饰词集合包含11个编码体系修饰词。在元数据记录中，编码体系修饰词用来表示一个DC元素的值取自一个受控词表，这种情况多见于“主题”（Subject）元素。元数据创建者们很早就要求DCMI提供简单高效的注册流程，有数十个经常用到的术语需要注册。于是DCMI开发了一个Web工具并制定了快速处理流程，对于元数据记录需要用到的术语，从提出到给定DCMI认可并维护的唯一名称（包括URI），给予有效的管理。
这个快速处理流程在2003年经过初步的试验运行，尽管存在一些问题，DCMI还是决定将它提升到第二阶段。DCMI的域名政策是否能不加修改地应用于编码体系修饰词的注册？必然面临其数量庞大而疏于管理的问题；实际操作中要花多大的代价兼顾新增术语的接收和遗留数据的维护上？受控词表本身也会置身于难以“受控”的状态，被各种各样的变更、改版和作废所困扰，有多少精力可以放在术语描述和Web链接的维护上？在对较小的DCMI术语集的管理中已经解决的唯一名称和URI问题，会在更大的名称空间中出现，例如：相互冲突的缩写词问题、术语翻译及由此带来的问题，以及普通名称（如“杜威十进制分类法”）相对于其专指版本（如“杜威十进制分类法1958年的第16版”）之间的问题等等。
同时，DC元数据中使用的编码体系词表越来越有可能被其维护代理机构声明URI。例如美国国会图书馆已经开始这样做了。为了更彻底地贯彻实施编码体系的注册机制，DCMI将实施“好邻居政策”，在DCMI维护的URI和新引入的非DCMI的URI之间进行相互参照，还需要开辟公布这种相互参照政策的渠道（例如通过网页和注册数据库），而且还需要为这些参照提供形式化表示的机制，例如用RDF Schemas。这样，在某些情况下，DCMI的编码体系注册就成了一种消除隔阂的措施，这种措施在编码体系拥有自己的URI之前，可以参考DCMI的受控词表。
为从根本上解决这个问题，最近提出了一个“info”URI计划[1]，设计了一个全球标识符空间，其中命名空间授权者能为标识自己的资源构造URI，而不指望把URI解析为Web上的一个资源或一个服务。这样URI能够应用于更广泛的资源范围，包括受控词表和词表中的术语。按照目前的计划，该“info”URI计划由一个公共注册机构通过轻量级的注册流程进行管理[19]。与DCMI编码体系的注册机制类似，这个“info”注册能够提供“一个轻量级的URI先期注册机制，在公共信息资产具有自己的URI或其他URN命名空间之前建立参照关系。”[1]
4 术语的文档管理
4.1 Schemas和Web网页
DCMI的命名空间政策规定，所有由URI标识的DCMI术语“在其命名空间内必须要有一个机器可处理的DCMI术语声明”[23]。2003年7月，DCMI术语的URI政策决定采用RDF Schemas文档描述专门的DCMI术语集[14]（这种方式对其它可能出现的命名空间解析方案会非常含糊，例如对W3C的技术体系工作组正在考虑的资源目录描述语言RDDL[24]）。RDF schema用一种机器可处理的形式表示了术语之间的语义关系，例如声明术语“Date Created”在语义上比术语“Date”狭窄（“subPropertyOf”）。这些Schema模型的技术规范是否符合W3C规范的要求，定期地在更大范围的Web和本体社区中进行讨论。
以RDF Schema形式公开声明DCMI术语并不能取代以普通Web页的形式发布DCMI术语。但同时保持这两种声明给工作流程带来了严重的问题。对一些小的术语集合来说，用XML编辑一个主数据文件，再用XSLT脚本阶段性地生成新版的Web页和RDF Schemas，是一个有效的方法。但要对那些正在发展中的比DC更庞大的词表进行多格式的文档管理，显然是一个挑战，DCMI还没有发现更好的词表管理工具，用一种更实用和对用户更友好的方式来管理这个流程。这需要大家共同努力。
4.2 应用纲要
应用的设计者们经常非常随意地拉出一个像DC这样的标准，选择一些可用术语的子集，制订一些规则来约束这些术语该怎样使用，例如，哪些元素是必需的，采用哪种日期格式。或者用一些不同出处的术语，如把DC的元素和IEEE/LOM标准的元素或者为具体的应用目的自定义的元素混在一起使用。为了对这样的应用文档进行管理，DCMI，DOI，MARC，and IEEE/LOM等许多标准团体都开发了相似的“纲要”或“应用纲要”。
在DCMI内部，应用纲要的想法是随着一种强烈而又难以表达清楚的需求而来的，这种需求要求对元数据方案进行文档化，并在一些有着共同兴趣的团体之间共享元数据。发展应用纲要的目的包括：从描述现存的记录结构到为要应用的格式拟定“最佳实践”指南。应用纲要帮助那些即将成为正式标准的词表进行语义规范。
欧洲标准委员会（CEN）的DC元数据工作组已经提出了DC应用纲要（DCAP）文档格式的指南[5、28]。该指南为使用没有URI标识的非DCMI术语提供了一些建议，并且对DC应用纲要用于描述基于元数据记录的、不清晰的、数据结构比刺猬模型更复杂或缺乏一致性的应用提出了一些建议。因此，相对于把一种元数据格式映射到另一种格式来说，起草一个DC应用纲要应该是一项无法仅仅靠自动化的方法来完成的智力劳动。
在这些工作的基础上，CEN工作组正在为DC应用纲要建立一个木器可处理的形式化模型。如果应用纲要需要应用于元数据自动转换或正规化（normalization），或者被并入注册系统的数据库（下文会讨论），建立形式化的模型是非常必要的。无论如何，通过综合各种规范并进行试验，看来还是能够取得具体的进展。DCMI正在发展其“抽象模型”，将提供一个模型基础，从而使我们最终走出刺猬模型的樊篱。
4.3 元数据注册
另一个发布元数据词表和应用纲要的方式是通过DCMI的“注册系统”，这是一个基于Web的多词表索引，能够响应外界的提问而提供元数据术语信息[9]。DCMI的注册系统是相互兼容、相互补充的整个注册体系中的一部分，这些注册体系中既有通用的，也有专门主题领域的[8、17]。
目前的许多注册系统除了都支持DCMI的句法规则和刺猬模型外，还有一个共同特点，那就是采用RDF这种技术。从原则上来说，RDF能够帮助用户更好地把握不同词表之间的相互倚赖关系，更好地设计语义映射和索引策略，更好地整合跨应用的元数据方案，还能更好地从经验应用中发现语义信息。通过开放的Web，可以直接从元数据的维护机构获得众多的术语声明、应用方案和受控词表等文档，他们都是以RDF Schemas形式存在的。
这种分布模型的支持者们面临着一个两难选择，这个模型要得到认可，词表维护者必须将他的词表交出来提供使用。然而，由于元数据词表缺乏很好的规则，从而妨碍了用户界面友好的工具的发展，反过来，这也使得词表提供者以RDF Schemas这样的形式化的结构来维护他们的词表变得非常困难。另一方面，一个有先天缺陷的Schema模型将会造成大量的遗留问题，成为发展过程中的一种累赘。这个分布模型的最终成功，有赖于制订一些稳定的、易于理解的Schema，如为术语声明而不是翻译，受控词表和应用纲要等制订RDF Schema，以及在更大的Web社区中得到大家的效仿。
5 开放流程
5.1 DCMI应用委员会
DCMI在从工作组发展为元数据维护机构的过程中，形成了正式的文档编辑流程。自2001年以来，对这个标准的扩展和解释都要经过一个9人应用委员会根据语法原则和有用性进行评估[15]。该委员会的每一个决定都会给定一个URI和指向该文档、决议文本以及受该决定影响的元数据术语及申明的链接[16]。该应用委员会的邮件列表，连同所有的会议资料都保留在开放的Web上。
这个正在成形的工作模式企图找到一种平衡，既要能满足民主参与和集体决议的需要——即所谓“所有人总比一个人聪明”，但同时必须承认，最有效的技术工作总是由少数专职的团队完成的。任何语义性的提议，例如提出新的术语或对已有术语使用的说明，都是在一个开放的工作组中成形的，然后再发送到DCMI的普通邮件列表，经过为期一个月左右的讨论阶段，最后再由应用委员会讨论是否批准。要通过正式批准，要求征得几乎所有人的同意（只允许一票反对票）[28]。而任何关于技术特性的提议，例如用XML对DC元数据进行置标的指南，由一到两个作者起草，反复修改，然后在开放邮件列表上得到完善，最后由DCMI指导委员会指定一个特别小组仔细地进行最终审查。
5.2 术语创建与重用
最近两年，应用委员会倾向于使由DCMI维护的词表尽可能相对较小，保持其一般性的特点。这样做的部分原因是避免复杂化的陷阱。不断地加入具体的术语以满足特定团体的需要，会牺牲简单性和一般化，而这简单性和一般化正是DC的核心主张。保持这种轻量化的检查审批模式，也有助于保证DCMI的词表能够被一个由忙碌的专家自愿组成的网络团体一直维护下去。
DCMI一直在考虑主持（Host）一个命名空间，根据其制订的政策维护URI，该政策允许用户创建的元数据术语无需通过任何讨论和审批程序就可以发布。原则上说，这能使新的术语一被创建马上就可以被参考或使用。同样可以在一个术语在征求评论阶段就指定一个DCMI名称或者URI，正式批准时可以只删除或提升这个术语的状态就可以了。
每个提议都有道理，然而都会有牵一发而动全身的影响。术语的空间会迅速扩大而且术语的长期维护会变得难以确定。如果DCMI要对在DCMI命名空间或由其主持的命名空间内语义重叠的术语进行交叉参照，那么这种任务很快就会变成一种负担。如果这项任务被看作是DCMI的责任，这些术语就会被认为已经通过了DCMI的批准。不论上述哪种方式，DCMI对于长期维护词表所应承担的义务和角色都没有被很好地理解。
为了保持一个小型词表，应用委员会说明了DCMI维护的词表怎样才能和其它专门词表结合起来使用，这些专门的词表是指那些由DCMI以外的专门领域内的专家所维护的词表。对于这一问题，DCMI已经开始和其它标准和词表的维护者讨论这个问题，并获得了支持，达成了一定的一致意见。例如，目前，DCMI正在和国会图书馆一起工作，提供一种声明MARC的“Relator（叙述者）”术语正式机制（例如Adaptor改编者，Artist艺术贡献者，Translator译者等）作为DC元数据元素“Contributor”的修饰词。目前的计划是，要求国会图书馆提出一个RDF Schema，声明每一个“Relator”术语是相对于DC“Contributor”的“子属性（subproperty）”；要求DCMI寻求适当的方式把DC用户指向MARC的Relator列表。如上所述，国会图书馆的“国会图书馆主题标目”在DCMI的编码体系修饰词中的URI是“LCSH”，后者同样也意味着DCMI对其词表的声明和维护为国会图书馆提供了一种参照。
5.3 总结
DCMI在前所未有、发展迅速的语义Web技术背景下，对于声明和维护元数据词表发展了一系列原则和实践。它的术语分类，它的“刺猬模型”，以及最近创立的“抽象模型”，提供了一种理论基础。基于这个基础，它的元数据规范可作为其它语言的语法规则。它的术语声明模型和应用纲要既以Web网页的形式发布，也以形式化的Schema的形式发布，这适应了日益增长的机器处理的需要。同时，在网络环境下对这些规范的讨论提供了一种低成本的工作模式。
DCMI的做法在建立一个核心标准与将维护责任分担给专业团体之间维持着必要的张力。责任的分解，不仅意味着共享技术模型和句法规则，还意味着共享约定，这些约定本质上是社会性的，如DCMI和其它词表维护者之间共同遵守的行为规则。无论DCMI是否找到理想的解决方案，未来的语义Web都需要一些共同的约定和政策，用来声明和维护它的潜在语义。如果没有DCMI的规范，诸如此类的模型和约定就需要重新创建，解决方案可能会不同，但同样的问题肯定会一样被认识到。