使用委员会管理程序
DCMI使用委员会管理过程
| 创造者: | 黛安·希尔曼 |
|---|---|
| 创造者: | 斯图尔特·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.Board Membership[源自DCMI规章制度]。
1.1.成员资格。使用委员会将由DCMI理事会任命的至少七人，不超过十一人(理想的是九人)组成。
1.2.的责任。使用委员会的任务是确保由Dublin Core™metadata Initiative维护的元数据术语的有序演变。用法委员会根据语法原则、语义清晰度、有用性以及与现有术语的重叠程度来评估新术语(或对现有术语的修改)的建议。对于被接受的提案，它会赋予特定的地位。用法委员会还评估使用DCMI术语的结构，例如应用程序概要文件。
1.3.甄选及委任程序。成员的选择基于以下标准:了解DC元素集的发展历史和目的，以及它与整个元数据世界的关系;与DCMI相关的元数据社区相关;愿意并能够将时间和精力投入到UB的职能中;能够用英语进行良好的口头和书面交流，准备文件并在小组环境中讨论复杂问题;成员的地理和领域分布是相关的，但不会凌驾于其他标准之上。DCMI理事会将从一名成员中任命联合银行主席。DCMI理事会可以向使用委员会提议任命无表决权的联络成员。联络成员可以代表DCMI附属机构或赞助者，或与Dublin Core™语义规范的开发有利害关系的其他组织。
1.4.条款。使用委员会成员的任期为两年，可连任。他们可随时自行决定辞职。
1.5.决策过程。用法委员会力求达成协商一致意见，从原则和经验实践两方面证明其决定和解释的合理性。要获得批准，一项提案需要超过50%的指定投票赞成，少于25%的指定投票反对。重要的决定将被分配一个编号以供引用，并记录在DCMI网站上。联合委员会的决定将提交给DCMI理事会批准和批准。
1.6.沟通和文档。对于内部通信，UB使用一个封闭的邮件列表。这些消息被存档并公开提供。会议每年至少举行一次。本次会议安排在DC年度总研讨会/会议期间。可以安排进一步的会议，最好靠近其他会议，以便尽可能多的成员方便出席。日程安排要提前足够长时间，以便尽可能多的成员到场。
1.7.报告。使用委员会主席负责准备会议和电话会议报告，并提交给DCMI理事会。在此报告的基础上，在批准使用委员会的决定后，常务董事将决定传达给DCMI社区。关于语义的决定包含在DCMI网站上的参考文档中。
2.会议
2.1.会议日程将在UB DCMI主页的显著位置公布，并在DC-General邮件列表上公布。
2.2.为经常参加会议的布法罗成员提供的经费应尽可能得到DCMI的支持。联络员出席联合银行会议的经费应由其机构提供。
2.3.联合大学主席维护议程，其中引用了有关支助文件的链接，包括JISCMAIL的帖子。通过议程审议的所有材料都合并在PDF简报中，并以电子方式分发给布法罗成员和联络员。在会议结束时，PDF格式的简报成为会议审议事项的正式记录。重要的决定将被分配一个编号以供引用，并记录在DCMI网站上。
2.4.布法罗主席可自行决定安排布法罗通过电话会议召开的其他会议。
2.5.UB主席负责为提案分配牧羊人。议程项目应包括负责指导提案通过UB进程的UB成员的姓名。议程将在网页上公布DCMI使用委员会会议开会前几周。
2.6.会员必须在一年中至少出席一次会议，以保持良好的会员资格。连续缺席两次会议的委员可由区议会首长级代替。
2.7.除联合大学成员和联络员以外的人出席联合大学的任何会议都是由邀请参加的。有兴趣参加的人应通过UB主席或常务董事请求邀请。鼓励任何有兴趣的团体参与提案的讨论。
3.由使用委员会决定分配的状态
符合(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.动议建议的程序
4.1.牧童分配每个即将提出的提案和申请概要应由联合大学主席尽早从联合大学成员中指派一名负责人。牧羊人应该了解提案问题或应用程序配置文件领域。
- 监督相关清单上的讨论(在审议提案期间，牧羊人应该是相关DC工作组清单的成员，并鼓励他们加入讨论，以确保在讨论期间暴露所有相关问题)。
- 总结评议期讨论和UB提案的争论点，在会议上口头或在会议前以书面形式(首选)。在提案讨论期间和做出决定后，作为相关WG或社区的联络人。起草一份关于提案的UB正式决定草案，供UB审查和批准。
- 一般来说，向工作组或领域提供关于良好实践、抽象模型以及影响开发提案或应用程序概要过程的其他问题的建议和专业知识。在适当的时候，牧羊人应该把他们关心的问题提请牧羊委员会注意。
4.3.准备公众意见征询期。完成的提案将被转发给DCMI常务董事或UB主席。提案由DCMI常务董事和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相关问题的公众讨论应在DC-General或公告中指定的其他工作组邮件列表中进行。公众讨论必须在讨论这些问题的联合银行会议之前至少六周开始。
沟通责任表 什么 在哪里 谁 评论 建议草案已公布 WG名单，dc将军 WG椅子 提案添加到UB议程 UB网站，UB名单 乌兰巴托的椅子 提案公布以征求公众意见 DC-General DCMI理事会 土地用途委员会公布决定 DC-General DCMI理事会
4.7.对提案进行表决。投票应限于预定的会议和公开宣布的电话会议。投票应仅限于出席会议或电话会议并能够参与讨论的UB成员。不能出席会议的联合银行成员可在会议前以书面形式提出支持或反对某项提案的理由(这不构成投票)。不能出席重要投票的联合银行成员，如果不能出席重要投票，可以与主席探讨其他选择。在任何情况下，没有亲自或虚拟出席有关讨论的成员不得投票。
4.8.记录使用委员会的决定。一份解释关于提案的UB决定的文件将由主管及时撰写并由UB批准。该决定将包括关于提出建议的简要说明和布法罗决定不提出建议的详细解释。UB的决定将采用由UB确定的格式，并连续编号以供引用。联合行动处的决定必须有充分的文件记录，以便作出决定的理由清楚，并有助于指导今后建议的拟订。在决定拒绝某项提案或建议采取进一步行动时尤其如此。
4.9.宣布和发布使用委员会的决定。决定公布在网页上DCMI使用委员会的决定。新术语将由UB主席添加到官方DCMI文档中。
5.注册应用程序配置文件的建议
5.1.应用程序概要文件有待审查。来自DCMI战略活动的应用程序概要可以由使用委员会审查。元数据实施者(已建立的项目、社区或研究小组)也可以要求审查，但须经UB主席批准。指出有关DCMI战略活动的信息。
5.2.应用程序概要文件。应用程序概要文件必须为每个术语提供定义它的元素集的标识符，理想情况下为单个术语提供uri的形式。如果应用程序配置文件中的术语描述的不是通用的“资源”(Dublin Core的典型领域)，则应用程序配置文件必须明确这一点。如果应用程序概要文件基于描述多个资源类(如代理或集合)的数据模型，这一点尤为重要。建议使用指南准备应用程序概要文件“Dublin Core™应用概要指南”。
5.3.关于应用程序配置文件的上下文信息。每个应用程序概要文件的文档必须提供——或指向一个简短的文本来描述——应用程序概要文件被使用或可能被使用的上下文和目的;参与其开发的组织或个人及其简要历史;以及有关应用程序概要文件的未来开发和维护的任何安排、策略或意图。
5.4.评估应用程序概要中的术语。将从语义一致性、语法原则(例如“dumb-down”)、清晰度和良好实践的角度来评估与Dublin Core™相关的术语的使用(例如对Dublin Core™元素的改进，或对特定上下文进行约束的Dublin Core™元素)。注意:请重新访问。
5.5.状态“符合”的分配。通过审查的应用程序配置文件将被分配为合格状态。合格状态表示自提交审查之日起，使用委员会对应用程序配置文件的评估。对已经符合要求的应用程序配置文件的更改需要使用委员会根据第5.1至5.3节中概述的流程和标准对应用程序配置文件进行进一步的全部或部分审查。
5.6.出版使用委员会对应用程序概要的审查。对于“通过”审查的应用程序概要，用法委员会将在应用程序概要的Web页面上发布审查。每次审查将至少包括:使用委员会对应用程序配置文件的任何评论;指向最初提交的申请文件的本地存档副本，以及(如有必要)随后根据用法委员会的意见进行修改的副本;指向由其维护者持有的应用程序概要文件的“最新版本”的指针(带有适当的免责声明)。
6.与应用程序概要一起提出的新术语
6.1.新术语的评价。在评估应用程序概要文件本身之前，必须评估应用程序概要文件提交中出现的新术语是否符合DCMI抽象模型。
6.2.DCMI术语uri和状态的分配。被认为符合DCMI抽象模型的新术语可以在DCMI名称空间中被赋予uri，并被赋予状态符合。
6.3.一致性的标准。关于所提议的术语是否符合DCMI抽象模型的决定将使用符合dcmi的术语决策树。
7.在应用程序概要文件中使用的其他名称空间中背书术语的建议
7.1.在评估应用程序概要文件本身之前，必须评估其他名称空间中要在寻求审查的应用程序概要文件中使用的现有术语是否符合DCMI抽象模型。
8.修订现有的DCMI条款
8.1.修订建议。更改DCMI名称空间中的术语的请求可能来自Usage Board内部或外部。一名使用委员会成员将被指派起草变更提案。在最终批准之前，由使用委员会临时批准的变更将在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名称空间策略进行版本控制。