| 创造者: | 黛安。Hillmann |
|---|---|
| 创造者: | 斯图亚特·a·萨顿 |
| 贡献: | 托马斯•贝克 |
| 发行日期: | 2006-02-13 |
| 标识符: | //www.voudr.com/usage/documents/2006/02/13/process/ |
| 替换: | //www.voudr.com/usage/documents/2003/02/07/process/ |
| 取而代之的是: | 不适用 |
| 最新版本: | //www.voudr.com/usage/documents/process/ |
| 文档的状态: | 这是一个DCMI过程文档． |
| 描述文档: | 本文档描述了DCMI使用委员会达成并记录决策的过程。本文件中的过程描述旨在指导UB履行其职责，以确保“都柏林核心™元数据计划维护的元数据术语的有序演变”。过程声明会不时地修改，以反映使用委员会不断演变的作用。如有不符之处，则由DCMI章程控制。 |
1．１．成员资格。使用委员会将由DCMI理事会任命的至少7人和不超过11人(9人是理想的)组成。
1．2.的责任。使用委员会的任务是确保由Dublin Core™元数据计划维护的元数据术语的有序发展。用法委员会根据语法原则、语义清晰度、有用性以及与现有术语的重叠程度来评估新术语(或对现有术语的更改)的建议。对于被接受的建议，它指定一个特定的地位。使用委员会还评估使用DCMI术语的构造，例如应用程序概要文件。
1．３．选择和任命过程。成员的选择基于以下标准:了解DC元素集的开发历史和用途及其与整个元数据世界的关系;与与DCMI相关的元数据社区相关;愿意并能够将时间和精力投入到UB的工作中;能用英语进行口头和书面交流，能够准备文件，并在团队中讨论复杂的问题;成员的地理和领域分布是相关的，但不会凌驾于其他标准之上。DCMI理事会将从其中一名成员中任命UB主席。DCMI理事会可以向使用委员会提议任命无表决权的联络成员。联络成员可以代表DCMI附属机构或发起人，或在开发Dublin Core™语义规范中有利害关系的其他组织。
1．4．条款。使用委员会成员的任期为两年，可续期。他们随时可以自行决定辞职。
1．5．决策过程。用法委员会力求达成一致意见，以原则和经验实践两方面为其决定和解释辩护。一项提案需要超过50%的赞同票数和少于25%的反对票数才能获得通过。重要的决策将被分配一个编号以供引用，并记录在DCMI网站上。乌兰巴托的决定将提交给DCMI理事会进行认可和批准。
1．6．沟通和文档。对于内部通信，UB使用一个封闭的邮件列表。这些消息被存档并公开。会议每年至少举行一次。该会议安排在年度区议会一般研讨会/会议期间。可以安排进一步的会议，最好是在其他会议的附近，以便使尽可能多的成员出席方便。日程安排要提前足够长的时间，以便尽可能多的成员出席。
1.7。报告。使用委员会主席负责准备会议和电话会议的报告并提交给DCMI理事会。根据这份报告，在使用委员会的决定得到认可之后，常务董事将决定传达给DCMI社区。关于语义的决策包含在DCMI网站的参考文档中。
２．１．UB会议日历将在UB DCMI主页的显著位置公布，并在DC-General邮件列表中公布。
2．2．布法罗联盟成员定期出席会议的经费应尽可能得到DCMI的支持。联络人出席乌兰巴托会议的经费应由其所属院校提供。
2．3.UB主席维持议程，其中引用了相关支持文件的链接，包括JISCMAIL的帖子。议程中考虑的所有材料都合并在PDF简报册中，并以电子方式分发给UB成员和联络人。在会议结束时，PDF简报书成为会议审议事项的正式记录。重要的决策将被分配一个编号以供引用，并记录在DCMI网站上。
２.４.布法罗主席可酌情安排布法罗通过电话会议举行的其他会议。
2．5．布法罗大学的主席负责分配建议的牧羊人。议程项目应包括UB成员的姓名，负责引导提案通过UB程序。议程应在网页上提供DCMI使用委员会会议开会前几周。
2.6。会员必须在一年中至少参加一次会议，以保持会员良好的信誉。连续缺席两次会议的议员可由区议会首长级委员接替。
2.7。除乌兰巴托成员和联络人外，任何乌兰巴托会议的出席都是受到邀请的。有兴趣参加会议的人应通过UB主席或常务董事提出邀请。鼓励任何有关方面参与讨论建议。
符合(URI//www.voudr.com/usage/documents/process/#conforming]．元素、元素细化和应用程序概要文件可以被指定为符合状态。被指定为符合状态的元素和元素细化是指实现社区对其具有证明的需求，并且符合DCMI抽象模型的元素和元素细化。
推荐(URI//www.voudr.com/usage/documents/process/#recommended]．符合DCMI抽象模型的元素、元素细化和DCMI维护的词汇表术语(例如，DCMI类型词汇表的成员术语)，并且在语义上不与DCMI名称空间中的其他术语重叠(例如，http://purl.org/dc/elements/1.1/和http://purl.org/dc/terms/)可被指定为“推荐”。
过时了(URI//www.voudr.com/usage/documents/process/#obsolete]．已被取代、弃用或已过时的元素和元素细分。这些术语将保留在注册表中，用于解释遗留元数据。
注册(URI//www.voudr.com/usage/documents/process/#registered]．用于词汇编码方案和语言翻译，DCMI为它们提供信息，但不一定是特定的建议。
支持(URI//www.voudr.com/usage/documents/process/#endorsed]．非DCMI断言可以被指定为“背书”状态:(1)术语由DCMI以外的注册机构管理，并且断言该术语符合DCMI抽象模型;或(2)该术语由DCMI以外的注册机构管理，并且断言该术语与DCMI术语具有属性或子属性关系。
4．1.作业的牧羊人每一份即将提交的提案和申请资料应由布法罗主席在布法罗会员中尽早分配一名负责人。牧羊人应该了解提案问题或应用程序概要文件域。
- 监督有关名单的讨论(在审议提案期间，牧羊人应是有关区议会工作组名单的成员，并鼓励他们参与讨论，以确保所有相关问题在讨论期间被暴露)。
- 在会议上口头或在会议前以书面形式总结评议期间的讨论和关于UB的建议的争论点(最好)。在提案讨论期间和作出决定后，担任与相关工作小组或社区的联络员。准备一份UB关于提案的正式决定草案，供UB审查和批准。
- 一般来说，向工作组或领域提供关于良好做法、抽象模型和影响制定提案或应用概要过程的其他问题的建议和专门知识。牧童应在适当时将所关心的问题告知布法罗。
4．3．为公众意见期做准备．完成的提案将提交给DCMI总经理或UB主席。DCMI常务董事和UB主席对提案的完整性进行初步审查。如果提案完成且不需要修改，则将提案分发给UB成员，并由常务董事宣布征求公众意见。从决定是否完整到公开宣布建议的日期之间将允许有两个星期的时间，以便有时间编写供公众传播的辅助材料。如果建议书不完整或需要修改，则将建议书退还给发稿人，并要求修改或补充资料。
4.4。宣布公众评议期．在宣布公众评议期之前，提案必须转移到DCMI网站，并给出DCMI页面标题和“拟议”状态。公开征求意见期的公告应由UB负责人在DC-General邮寄名单上公布。公告应包括提案链接;其他有关资料的连结;评论的最后期限;用于提交评论的电子邮件地址。(一般来说，关于提案的评论可以寄给WG的相关邮件列表，DC-General邮件列表或者私下寄给牧羊人。)公告还可以包括关于讨论提案的UB会议的信息，包括地点、时间和如何请求参加邀请;指定牧羊人的姓名和联系方式。 The announcement should ask specifically for communications supporting the proposal in order to gauge the level of community support.
4.5。管理公众意见期．建议的评议期应列入DC-General清单。评议期必须至少一个月，并在UB会议前至少6周开始，在会议上采取行动。在公众评论期间，应在DC-General或公告中指定的其他工作组邮件列表上对布法罗相关问题进行公开讨论。公开讨论必须在乌兰巴托会议之前至少六周开始，在乌兰巴托会议上讨论这些问题。
沟通责任表 什么 在哪里 谁 评论 建议草案发布 WG列表,DC-General WG椅子 提案加入UB议程 UB网站，UB名单 乌兰巴托的椅子 提案宣布征求公众意见 DC-General DCMI理事会 使用委员会决定宣布 DC-General DCMI理事会
4.7。投票的提案．投票应限于预定的会议和公开宣布的电话会议。投票应限于出席会议或电话会议并能够参与讨论的UB成员。无法出席会议的UB成员可以在会议前以书面形式提出支持或反对提案的理由(这不构成投票)。不能出席的UB成员可以与主席探讨其他选择，如果他们不能出席一个重要的投票。在所有情况下，未出席有关讨论的成员均不得投票。
4.8。记录使用委员会的决定．牧羊人将及时撰写一份文件，解释UB关于提案的决定，并由UB批准。该决定将包括发布建议的简要声明和布法罗不发布建议决定的详细解释。联合大学的决定将采用联合大学决定的形式，并为引用目的连续编号。UB的决定必须有充分的文件记录，以便决定的理由清晰，并有助于指导未来提案的发展。在决定拒绝一项提案或建议采取进一步行动时尤其如此。
4.9。宣布和发布使用委员会的决定．决策发布在Web页面上DCMI使用委员会的决定．UB主席将在DCMI的官方文件中增加新的术语。
5.1。应用程序概要需要审查．来自DCMI战略活动的应用程序概要可以由使用委员会审查。元数据实施者(已建立的项目、社区或研究小组)也可以请求审查，但须经UB主席批准。在可用时指出有关DCMI战略活动的信息。
5.2。申请概要文件．应用程序概要文件必须为每个术语提供定义它的元素集的标识符，理想的形式是单个术语的uri。如果应用程序概要文件中的术语描述的不是通用的“资源”(都柏林核心的典型域)，那么应用程序概要文件必须明确这一点。如果应用程序概要文件基于描述多个资源类(如代理或集合)的数据模型，则这一点尤其重要。建议使用指南来编写应用程序概要文件“Dublin Core™应用简介指南”．
5.3。关于应用程序概要文件的上下文信息．每个应用程序概要文件的文档必须提供——或指向描述——应用程序概要文件使用或可能使用的上下文和目的;参与其发展的组织或个人及其简要历史;以及关于应用程序概要文件的未来开发和维护的任何安排、策略或意图。
5.4。评估应用程序概要中的术语．与Dublin Core™相关的术语的使用(例如对Dublin Core™元素的改进，或针对特定上下文受到约束的Dublin Core™元素)将从语义一致性、语法原则(例如，“dumb-down”)、清晰度和良好实践的角度进行评估。注意:重新审视这个问题。
5.5。状态“符合”的转让．通过审核的申请简介将被指定为合格状态。合格状态表示使用委员会对申请简介提交审核之日的评估。对于已经符合要求的应用程序概要的变更，使用委员会需要根据5.1至5.3节中概述的流程和标准，对应用程序概要进行整体或部分的进一步审查。
5.6。使用委员会对应用程序概要的评论的出版．对于“通过”审查的应用程序概要文件，使用委员会将在Web页面上发布应用程序概要文件的审查。每次评审将至少包括:使用委员会对应用程序概要的任何评论;指针指向最初提交的本地存档的应用程序概要文件副本，以及(如果有必要)随后根据使用委员会的意见进行的修改;指向由其维护者持有的应用程序概要文件的“最新版本”的指针(带有适当的免责声明)。
6．1.新条款的评估．在评估应用程序概要文件本身之前，必须评估出现在应用程序概要文件提交中的新术语是否符合DCMI抽象模型。
6.2。DCMI术语uri和状态的分配．认为符合DCMI抽象模型的新术语可以在DCMI名称空间中提供uri，并分配状态为符合．
6.3。一致性的标准．关于建议的术语是否符合DCMI抽象模型的决定将使用符合dcm的术语决策树．
7.1。在评估应用程序概要文件本身之前，必须评估应用程序概要文件中使用的其他名称空间中的现有术语，以确保符合DCMI抽象模型。
8.1。建议修改．更改DCMI名称空间中的术语的请求可能产生于使用委员会内部或外部。使用委员会成员将被指派起草一份变更建议。由使用委员会临时批准的变更将在最终批准前一个月传阅DC-General讨论清单以征求一般性意见。在没有重大反对的情况下，任期变更的最终批准可以通过电子邮件或电话会议投票。
8.2。正式标准化术语的更改．从名称空间http://purl.org/elements/1.1/要求变更相关标准:ISO标准15836-2003(2003年2月)和NISO标准Z39.85-2001(2001年9月)。
8．4．驻留在DCMI托管的名称空间上的应用程序概要文件术语将受到与其他DCMI术语相同的更改过程的影响，但由负责术语的实体管理。驻留在非dcmi名称空间上的应用程序概要文件术语将受主机实体的术语策略的约束。
8.5。对于已经“符合标准”的应用程序概要的变更，使用委员会需要根据前几节概述的流程和标准，对整个或部分应用程序概要进行进一步的审查。对DCMI注册的“符合”应用程序概要文件的更改将根据DCMI名称空间策略进行版本控制。