欢迎您来到 数字平台。 您尚未登录。[登录] [注册新用户]
当前位置: 论坛首页 / 栏目 产品与服务 / 文章 703

点击:17174[回复顶层] [树状] [详细]
[回复留言] [回复(需要先登录)] [引用(需要先登录)]普通文章第 1 楼
文章id: 703
关于编目系统两点紧急需求的情况说明

作者: shenming

摘要: 请务必分清“原编数据”与“修改数据”的工作量信息

关键词: 工作量统计


关于编目系统两点紧急需求的情况说明

我们在实际的使用中,目前有两点需求非常紧迫,请你们务必尽快给予解决。

1、关于工作量的统计

现在的日志统计窗里,编目员的工作量统计是分为“新建”、“修改”、“删除”和“另存 四项内容,其中“另存”我不清楚是统计什么,“删除”目前也没有什么问题,关键在“新建”和“修改”这两项上问题比较大。现在的“新建书目”和“修改书目”只是一个简单的计数器,是一个点击“保存(F2)”按钮和“另存(F3)”按钮的计数器,并不能真正统计到是原编了多少条书目记录或者修改了多少条书目记录。同一条数据,我另存到某个库里边一次,就会计为一条“新建书目”,再存到另一个库里边一次,就又会计为一条“新建书目”。打开某一条数据,我可以不做任何修改,点一次保存,就会计为一条“修改书目”,点十次保存,就能计为十条“修改书目”。这样的话,我们的编目员都能虚报自己的工作量,甚至可以一整天什么事情都不做,打开一条数据后点击1000F2键,那他当天的工作量也会有1000条的“修改书目”。

从十月份开始,我部门已经实行了新的薪酬制度,按件计算编目员的工资,分为“原编”和“修改”两种类型。也就是说,他从头到尾原编一条数据,能拿到多少钱,对一条数据进行了某些字段的修改,或者说添加了几个馆藏字段,又能拿到多少钱,这两种操作的标准是不一样的,而且相隔比较大。涉及到每个人的工资发放,和他们的切身利益密切相关,所以,现在我们必须要对编目员的工作量进行精确的统计。只有在一条数据从无到有,所有字段完全为编目员全新创建的情况下,才能统计为原编,至于修改,则最好能分出个程度,只做一两处简单的修改,和对整条数据做了多处修改,应予区分为妥。只有这样,才能真正做到统计的科学和公平,否则的话,付出辛勤劳动的编目员得不到应有的报酬,经常偷懒但会钻空子的编目员却能不劳而获,这是很难想象的。

2、关于在导入数据时增添“覆盖”功能

我们的一个原则是所有为学校做过的数据,都会导入源书目库,以便下次有另外学校需要相同数据时,可以直接套录出来使用,减少原编量。现在往库里边批量导入数据的时候,只能选择查重或者不查重,选择前者,则系统判定为重复的数据就不会入库,选择后者,则所有数据全部入库,库里边有可能出现重复的数据。但在实际操作中,经常会遇到这样一种情况:例如我们要完成某个学校的100条数据,这其中有80条可以从源书目库套录出来,另20条做原编处理。但这80条套录的数据里有10条不准确,缺少了一两个字段,这时候我就需要抽取这10本样书,像做原编一样将这些字段补齐。整批数据制作完成后,应该将这100条数据导进源书目库,为了避免重复,当然选择查重,但这样的话,这其中的10条经过我补充完整的数据也会被当做重复数据无法入库,而库里边留存的任然是原来那10条缺少字段的不完整数据,当下次再有学校还是需要这10条数据的时候,我还是得抽取样书补充字段。所以,在使用批处理程序导入数据的时候,除了具备“查重”选项外,应该增加一项“覆盖”选项。如选中此项,当数据不重复时,会直接进入源书目库,若为重复数据时,则以当前的数据覆盖掉库中已有的数据,这样就能保证新的完整的数据替换掉库里旧的不完整的数据,从而不断提高源书目库里数据的质量,避免我们的重复劳动。

以上两点需求甚为紧急,盼火速解决。如有疑问,可随时与我联系。



发表时间: 2011-11-28 14:46:16
[回复留言] [回复(需要先登录)] [引用(需要先登录)]普通文章第 2 楼
文章id: 705
回复: 关于编目系统两点紧急需求的情况说明

作者: xietao


上周末小马已经把这个文字转发给我了,下面我提出一些自己的想法,供讨论和参考。

一、工作量统计

直到现在我对工作量统计的核心问题有了比较明确的认识,就是工作量统计结果是要和工作人员的薪酬挂钩的。认识到这一点,一方面可以把这个问题放到一个新的高度来看待;另外一方面也给我一个启发,就是可能日志统计的方向不一定合适,我们需要用新的方向来思考问题。

日志统计的特点是,每日都有新鲜的工作量数据可以统计出来,不过,通常统计数据具有一定的“匿名性”,也就是说习惯上在计算一个人的创建新记录和修改记录操作量的时候,不会和具体的记录本身挂钩,所以出现了修改次数居高不下的问题(这令修改次数这个指标失去了应有的计算劳动量的意义),也出现了创建新记录可以作弊的问题(虽然和删除记录数结合起来看可以看出一定的破绽)。

如果我们换一个方向思考,假如管理人员在每个月考察员工薪酬的时候,能够逐一翻看每个员工创建的每一条MARC记录,那么作弊就无法得逞。当然这是一个极端的说法,管理人员不会有那么好的精力去检查每一条加工出来的数据记录,那么,我们退一步,可以用软件列出每一条记录的简明清单,每一条记录只需要显示其题名责任者等主要事项,然后把针对这每一条记录的创建和修改次数显示在另一栏,并且,按照题名之类的key来进行排序,这样,作弊的事儿就会暴露出来:你会看到某些记录修改的次数畸高,某些记录被删除了然后又重新多次创建。

从dp2circulation的统计窗类型来说,似乎可以考虑不要用目前思维定势的“日志统计窗”,而采用“书目统计窗”来设计新的统计方案。

二、重复利用源书目数据的问题

这个问题是个老生常谈的问题了,dp2系统给出了一种经过长年检验的好办法:创建一个中央库,然后把加工后的正式记录不断积累到其中。

而草率转入源书目库的记录,属于质量不确定的外部参考记录,在利用它转存后进一步加工成正规的书目记录后,就保存到了中央库。日后再进行查重,应当是针对源书目库和中央库两种目标的查重。如果查出一条记录在源书目库和中央库都存在,那么显然要转存利用中央库的那条记录。

所以,当书目记录加工好以后,要寻迹去覆盖源书目库里的那条记录(以便后面可以重复利用到“更高质量”的记录),是不必要的。或者说是一种比较原始的用法,属于突发奇想了。因为源书目库既然是这个名字,那就意味着它是一个外源数据的“垃圾堆”,没有人会真正去用心收拾打理它里面的记录,如果把本应是中央库的职责派给它,属于勉为其难了,效果必然不会太好。

不过,dp2batch的“一边查重一边转入”方案把加工好的记录灌入源书目库的功能中,增加发现重复的时候不是放弃而是覆盖的功能,原则上说是可以的。不过,要解决一些概念问题:如果查重发现一条即将转入的记录,和数据库中多条记录相重,到底覆盖哪一条呢?这就是一笔糊涂帐了,这也就是上面说的“垃圾堆”的深刻含义。

所以我的建议是,增加查重目标,调整数据库结构为正规的模式,这是彻底解决问题的办法。希望不要采用把加工好的记录转入源书目库的办法。

以下是引用 shenming 于 2011-11-28 14:46:16 发表的文字:

关于编目系统两点紧急需求的情况说明

我们在实际的使用中,目前有两点需求非常紧迫,请你们务必尽快给予解决。

1、关于工作量的统计

现在的日志统计窗里,编目员的工作量统计是分为“新建”、“修改”、“删除”和“另存 四项内容,其中“另存”我不清楚是统计什么,“删除”目前也没有什么问题,关键在“新建”和“修改”这两项上问题比较大。现在的“新建书目”和“修改书目”只是一个简单的计数器,是一个点击“保存(F2)”按钮和“另存(F3)”按钮的计数器,并不能真正统计到是原编了多少条书目记录或者修改了多少条书目记录。同一条数据,我另存到某个库里边一次,就会计为一条“新建书目”,再存到另一个库里边一次,就又会计为一条“新建书目”。打开某一条数据,我可以不做任何修改,点一次保存,就会计为一条“修改书目”,点十次保存,就能计为十条“修改书目”。这样的话,我们的编目员都能虚报自己的工作量,甚至可以一整天什么事情都不做,打开一条数据后点击1000F2键,那他当天的工作量也会有1000条的“修改书目”。

从十月份开始,我部门已经实行了新的薪酬制度,按件计算编目员的工资,分为“原编”和“修改”两种类型。也就是说,他从头到尾原编一条数据,能拿到多少钱,对一条数据进行了某些字段的修改,或者说添加了几个馆藏字段,又能拿到多少钱,这两种操作的标准是不一样的,而且相隔比较大。涉及到每个人的工资发放,和他们的切身利益密切相关,所以,现在我们必须要对编目员的工作量进行精确的统计。只有在一条数据从无到有,所有字段完全为编目员全新创建的情况下,才能统计为原编,至于修改,则最好能分出个程度,只做一两处简单的修改,和对整条数据做了多处修改,应予区分为妥。只有这样,才能真正做到统计的科学和公平,否则的话,付出辛勤劳动的编目员得不到应有的报酬,经常偷懒但会钻空子的编目员却能不劳而获,这是很难想象的。

2、关于在导入数据时增添“覆盖”功能

我们的一个原则是所有为学校做过的数据,都会导入源书目库,以便下次有另外学校需要相同数据时,可以直接套录出来使用,减少原编量。现在往库里边批量导入数据的时候,只能选择查重或者不查重,选择前者,则系统判定为重复的数据就不会入库,选择后者,则所有数据全部入库,库里边有可能出现重复的数据。但在实际操作中,经常会遇到这样一种情况:例如我们要完成某个学校的100条数据,这其中有80条可以从源书目库套录出来,另20条做原编处理。但这80条套录的数据里有10条不准确,缺少了一两个字段,这时候我就需要抽取这10本样书,像做原编一样将这些字段补齐。整批数据制作完成后,应该将这100条数据导进源书目库,为了避免重复,当然选择查重,但这样的话,这其中的10条经过我补充完整的数据也会被当做重复数据无法入库,而库里边留存的任然是原来那10条缺少字段的不完整数据,当下次再有学校还是需要这10条数据的时候,我还是得抽取样书补充字段。所以,在使用批处理程序导入数据的时候,除了具备“查重”选项外,应该增加一项“覆盖”选项。如选中此项,当数据不重复时,会直接进入源书目库,若为重复数据时,则以当前的数据覆盖掉库中已有的数据,这样就能保证新的完整的数据替换掉库里旧的不完整的数据,从而不断提高源书目库里数据的质量,避免我们的重复劳动。

以上两点需求甚为紧急,盼火速解决。如有疑问,可随时与我联系。



发表时间: 2011-11-28 15:42:27
最后修改时间: 2011-11-28 17:14:28



[回复留言] [回复(需要先登录)] [引用(需要先登录)]普通文章第 3 楼
文章id: 706
998$t

作者: xietao


dp2图书馆集成系统,在dp2circulation前端的采购流程中,实现了单角色库和多角色库两种工作模式。

单角色库就是直接在中央库的记录中进行订购。而多角色库是在中央库之外设立了一种订购角色的书目库,订购操作的时候,会把复本订购的书目记录从中央库复制到订购书目库中,当验收的时候,又会把订购书目库中的书目记录合并回中央库中。

本来单角色库的模式就可以满足任何规模的图书馆的业务需求,但一些用户单位因为有dt1000的运作经验,可能想当然地以为多库是更“高级”的模式,所以我们也开发了多角色库的工作模式。不过,需要强调的是,实际上多角色库的模式增加了不少工作量,概念也比较复杂一些。所以,除非是满足某种心理需求,多角色库模式是没有必要的。

多角色库模式下,为了解决书目记录复制出来、然后合并回去的定位问题,系统在书目记录的998字段增设了一个$t子字段,用来记录“目标记录的路径”。书目记录从中央库复制到工作库之后,工作库的那条记录里面就被自动添加了一个998$t子字段,内容是中央库记录的路径。这样,当流程进行到后期,工作库的这条记录需要合并回中央库的时候,998$t中记载的路径就能发挥作用。

998$t这么一个小小的子字段,里面蕴含了很多东西。在多角色库模式下,工作人员决定把一条记录从中央库复制到工作库以便完成业务操作,必然是经历了一系列的辨认识别之后才操作的。虽然作为一种工具,软件本身并未参与这种复杂的辨认识别过程,但一旦工作人员决定下来,那么998$t就负责去记载两条记录之间的“正本-副本”关系。

记载这个“关系”非常重要。如果不记载这个关系,日后流程需要把工作库的记录合并回中央库的时候,就需要借助普通的查重操作,到时候工作人员又要费心费力去辨认记录之间的源流关系,这是一种浪费。因为在当初决定复制的时候,工作人员已经进行过一次辨认识别的脑力劳动,软件大可以记载下这第一次劳动的成果,免去日后合并回去时的又一次脑力劳动。

从事图书馆软件设计这么多年,我觉得一个比较难的问题就是查重问题,即辨别书目记录之间的源流关系的问题。很多朋友天真地以为软件能自动完成处理,但若干年的经验告诉我,软件至多是个不太合格的工具而已,在关键环节还是需要人的脑力介入。如果软件越俎代庖,形成结果可能是一片垃圾数据,工作人员不知道问题很严重了,或者明知道问题很严重但是故意不去想它。我认为,软件还是应该固守其擅长的“工具”地位,仅仅是在人工判断以后进行忠实地记录和还原,把这种表面上看起来并不算很高级的工作做好,总比连这个都做不好还要去做更难的事情来的更合适。

998$t的作用当然不仅仅是为订购流程服务,它实际上更多是为了编目流程服务。



发表时间: 2011-11-29 10:35:02



页 1 / 1
 

在线用户
访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客   访客访客
当前栏目在线用户数 35, 总在线用户数 54