以下是引用 阿甲 于 2013/3/28 10:38:50 发表的文字:
上面的用户设置还在测试阶段，没有真正启用，启用时我会考虑先尽可能少开放，不够了再新增。
delete的确不是必要的，加上去是体验完全的权限：）
905字段我不太能理解其具体的应用，名为馆藏信息，是否可以开放给分馆做相关的记录？不理解先关闭。
关于较高的权限和自由的操作，可以专门设定一个练习库，反正在里面大家可以随便创建记录，删除了也不要紧。
905字段我这里介绍一下。美国最早出现了 USMARC 格式，其实是 USMARC 第二版的时候才得到图书馆界的认可。欧洲觉得很好，搞了个 UNIMARC，但字段名重新设计了，和 USMARC 不一样、不兼容。我国台湾制定了一个大约叫做 CMARC 的格式，基本是 UNIMARC 翻译过来的；大陆制定了一个 CNMARC，也是从 UNIMARC 翻译过来的，增加了少量字段，其中 690 等是增加的，905 是增加的。
在 UNIMARC 的结构惯例中，什么什么 9 字段就是用于国际不同地区扩展的。
但 905 字段有个致命伤，就是它居然没有弄清书目的一种和图书的实体册之间的关系。所以 905 无法描述一种图书里面的各种册的复杂情况，例如不同的册价格(上中下)，不同的索取号(因为卷册不同的缘故)，还有期刊有各期的年代也不同。所以 905 字段是个怪物。
我从 1992年左右开始设计第一代图书馆软件，最早试图用 905 满足图书馆的借还等业务需求，发现根本不能用。较早的一两代产品，试图在 MARC 里面扩充字段描述册特有的信息，核心是重复子字段并且这些子字段内在有一种成组的关系。这就是 906/986 等扩充字段的来历。2006年开始设计的 dp2 系统，则完全在 MARC 书目数据库以外单独存放册记录信息。总之 905 字段是在系统中废掉了，基本等于无用。
纵观国内的图书馆系统，在我的印象里，没有哪家是用 905 实现借还等功能的。
但为了维护 CNMARC 标准这个局部的“规定”，许多系统依然在转出为 ISO2709 记录也就是 MARC 格式的时候，可以把系统内部的格式转换为 905 字段输出。当然，限于 905 字段结构的先天缺陷，转出的时候也是削脚适履，比如，假如一种图书里面的各个册的索取号不一样，那么大抵只能取第一册的索取号来聊以安放，蒙混过去。
CNMARC 格式的主要制定者，当时北京图书馆的朱岩老师，我和他还有几面之缘，从时代的角度，他从事了这么了不起的开创的事情，我表示敬仰；但这个 905 字段的败笔，似乎也要算到他头上。当然，这是后面评价历史了，不一定公平。后期代表北图参加各种国际活动的周升恒老师，我们也有过密切的交流，总体来说，后面参与的人对国际标准的理解力在增强(简单可以认为后来的人英文能力更强一些)，也得到不少老外的反馈，站的角度和层次比第一代参与者更有利，当然这也是某种不太公平的比较因素吧，念及此，更应该理解第一代参与者的不易。
我有过直接听取老外意见的机会，他们一般看见CNMARC中 200 等字段的 $A 字段都会很吃惊，听完我们说这是拼音字段，都会连连摇头。后来，这里被修改为 $9，当然这里有不少国内人士呼吁的原因， CALIS 等机构的应用和促进，也是很重要的原因。
总结一下，对于红泥巴数字平台中心来说，书目库中的 905 字段基本无用。如果导出的 ISO2709 记录中因为上述某些原因需要具备 905 字段，可以在输出的时候由软件添加。或者直接说，把 905 字段删除都是可以的。
为什么现在很多单位的书目库里面都有 905 字段呢？大抵是因为我们的系统很宽容，能让它呆在里面，但不起作用，也无害。但也可能成为“垃圾”，影响视线。这个“呆在”里面，曾经是一个很重要的系统设计思路，因为 MARC 字段数量很多，很多不一定对系统的业务流程发生什么直接作用，但存储它们是完全应该的，因为不清楚要存储它们的用户单位是什么意图，并且，在我们的系统中，可以随时为书目库增添新的检索点，这些暂时不是检索点的字段将来可能变成检索点。鉴于早年一些图书馆系统只能让规定的字段进入系统(存储上就设计死了)，从我看来这简直就是假的支持 MARC 的系统，所以我们自己的系统就格外强调，让字段们进去吧，不要妨碍它们先进去，只是进去。
但现在观念早已成熟，反过来把一些不要的字段清理干净也许更重要...。我的意见，仅供参考。实在不行还是留着这些字段吧？