==========
以下是引用 Harry 于 2009-2-28 18:51:24 发表的文字:
谢老师，rms里面查重的我还没试验，单对batch这里，您的设置还是不能完全解决问题，比如以下两种情况：
1.一套书共用ISBN,比如金庸的《鹿鼎记》，出版商把它做成五本，ISBN（80）、题名（20）、作者（20）都一样，加起来就120了，重了。200$h不一样，就不能算重！这种情况十分普遍，上下册共用ISBN的太多了。
2.一本书有很多作者，有很多超过五六个的，论文这种情况就很普遍了（一个导师写篇文章恨不得把他的学生全带上，论文不做MARC，但是电子化收录是有，查重也要用到），200字段一般只著录三个，而702字段却要全部著录上，这个老师领导他的学生写的第二篇论文就极有可能不能被系统收录，加权算法把它判重了，哪怕一个学生重复就给10分权重。
MARC书目里面影响因素太多，更改设置可能对这批书有效，换一批就无效了。真的要用加权算法，那恐怕真的要一位数学家仔细研究MARC后设置一个比较好的权重分配体系，这样就不像您说的是一种简单的查重实现方法了。
是否可以参考人判断一本书是否重复的思维模式呢。
人在判断两个复杂事物，比如书目，是否相同的时候，肯定不会给一个点设置分值，然后边比较边在脑子里加分。在逐点比较的时候，人会每比较一个点就做出一次综合判断：要么相似则继续比较；要么得出结论不相似，退出；人的判断往往最准确，这就是一种是非关系，计算机就用0、1就可以模拟了。
设置key=0(不重复)
1、先比较ISBN,相同则key=1,继续；(否则，key=0,退出，判不重，ISBN不同的书不可能重复，至少我询问的有经验的编目员说不可能，除非著录错误)
说明：ISBN相同的未必就重，200$h未必相同。
2、比较200$h,重复key=1,继续；(否则，key=0，判不重)
说明：到这里200$h重了未必就重，可能是再版书，再版书有可能用前一版的ISBN(这样可能给出版商省钱吧)。
3、比较205字段或200$e,重复key=1,继续；(否则key=0,判不重)
按说，到此应该结束了，但是为了防止盗版书盗用别人ISBN（200$h和205及200$e均为空），再继续比较。
4、题名重复,key=1,（不重复，key=0,退出）
5、第一责任者（很重要，只比较第一责任者，第二责任者参考价值不大）也一样，key=1，那重复可能性太大了；（若不重复，key=0,退出）
6、再看看出版社，出版社也一样,key=1。（否则key=1,退出）
7、再比较出版年（不比较月份，很多Marc不著录月份），相同ke=1,(否则key=0,退出)
结束，key=1 重复，key=0不重复。
可能不是很严谨，就是表达一个意思，这样的算法很简单，也不太容易犯错，给老师参考。
==========
> 1.一套书共用ISBN,比如金庸的《鹿鼎记》，出版商把它做成五本，ISBN（80）、题名（20）、作者（20）都一样，加起来就120了，重了。200$h不一样，就不能算重！这种情况十分普遍，上下册共用ISBN的太多了。
上次没有来得及说200$h的事情。200$h按照一般惯例是不进入检索点的。道理很简单，和页码不进入检索点一样。
因此，在目前这个查重体系下，200$h不能参与运算。为查重而增加一个200$h的检索点，我觉得不值。
目前这个查重算法，有一个很好的思想，就是尽量利用现有的编目检索点。编目检索点是为了通用，为了大部分用途而设立的，不一定是为了查重的某种特殊需要而设立。
当然，不是检索点的200$h内容，可以在已经(通过其他检索点)命中的结果集中参与进一步的过滤(或者称为二次检索)运算。
另外，上下册应当怎样著录？原则上是尽量著录在一条编目记录中。我接触编目多年，有很多资深的编目员朋友，这点常识我还是有的。至于，许多单位把上下册分开著录，往往是因为每册有单独的价格或者ISBN号(这后者属于不正常的情况)，在一些不合格的编目软件产品中，过分强调畸形的全部信息相同才能算一种的概念，而册信息单薄、没有价格例外等措施，这样操作是可以理解的，但是违背编目的基本思想。
现在dp2系统则很强调种的聚集、册的例外信息描述，册记录面有单独的价格字段，单独的卷期册字段，上述分开著录的办法可以休矣。正因为册信息里面能容纳不同，所以种能够“和”，和而不同。所以，在200$h不同的记录之间算不算重，我和你恰恰有相反的结论。从编目员的角度，如果要著录下册，而套录到了上册的数据，这已经算达到目的了，稍微修改一点就可以用(而且是一条上下册通用的书目记录)。这怎么就不算命中呢？你给我个理由先！
在极端情况下，如果编目员非要给一套丛书仅作一个编目记录的“综合著录记录”跟随所有册记录，dp2系统也能游刃有余。
我再举一个例子，探讨一点所谓编目意识。如果两种编目记录，完全是同样一种书，在所谓“一边查重一边转入”过程中，后面一条记录因为前面已经有了，就没有转入。这是一种正常的行为么？不见得正常。举例来说，如果第二条记录的编目质量较高，特别是有高质量的主题词和分类号字段内容，那实际上应该用第二条覆盖第一条才对。否则就成了武大郎开店，高的反而进不去了。
这里面，实际上包含了一个评估两条已经重了的记录的质量的课题，或者说，即便在手工操作下，有一个取长补短的字段合并课题，不是谁覆盖谁，而是两条记录各自抽取一些内容然后合并。手工操作下，这问题很好解决，人来判断就可以了；而迷信软件自动去操作，就像现在的机器翻译课题一样，是一个非常难的问题，实用化程度很低。dp2系统在这个方面，小心地平衡各种因素，今后还将提供一些技术进步和新设施。不过要谨慎，这里面水很深，不可小瞧。
鉴于您现在的身份，在图书公司工作，基于给用户提供立竿见影的低质量的服务(抱歉，我说了实话)，管它什么数据，弄个软件三七二十一合并了给用户就行了，数据来源本身是盗版，负责合并的人更没有专业知识，也没有那个海量处理的精力。主要目的是卖书赚钱，数据是团体客户要数据，书店本不喜欢弄什么数据，无奈用户提出了要求，不得不随便弄一点。从这个角度，江汇泉的“畏难”情绪并不是一种低级的情绪，而是我们长期素养的一种体现。对这类急功近利的需求，我们多数时候退了几步，给出了一定空间，而不去硬来，这恰恰是一种成熟的态度。
所谓各自的角度不同，自然态度不同。我目前倒是乐于接受外来的新鲜思路，对于图书公司的实用化的追求也抱有积极配合的态度。但是我们不能丢了西瓜捡芝麻，而要向您曾说过的 -- 继承，继承的基础上发展，理论水平不降低，然后提高实践水平。这方面确实需要实际用户的推动，包括来自图书公司的推动。有项目做才是硬道理！公司不是研究机构，需要实际的推动才行。
> 2.一本书有很多作者，有很多超过五六个的，论文这种情况就很普遍了（一个导师写篇文章恨不得把他的学生全带上，论文不做MARC，但是电子化收录是有，查重也要用到），200字段一般只著录三个，而702字段却要全部著录上，这个老师领导他的学生写的第二篇论文就极有可能不能被系统收录，加权算法把它判重了，哪怕一个学生重复就给10分权重。
这个问题难不倒我。如果从要维护现有的权重体系的角度，我会给题名99分，著者1分。题名和一个著者重复，100分，够阈值了吧？而要题名不同而著者相同达到阈值，岂不是要100个著者相同才行？如果我把阈值改为1000分，题名999，著者1分呢？那就再多的著者也不怕了。不要低估了这套加权体系的灵活空间。
搞软件开发的玩的就是智商和逻辑推理。请重视一下我说出的话：现有的体系空间很大，你能找出不利的理由，我能找出有利的理由。你不妨多从两方面都想一下。反对以前，给出分量足一点的案例。当然，这属于设计、思辨层面的攻防模拟，不属于真刀真枪的开发行为。但是常思考、善思考总是没有坏处的。
而如果从改进这个体系的角度，我把楼上的新思路实现了就可以了，重复著者再也不会成为烦恼，过两天您看看新版本再说吧。我觉得我已经太周到了，两边都讲到了。讨论也应该有进步，不应该还停留在前两天没有改进方案时候的情绪中。
> MARC书目里面影响因素太多，更改设置可能对这批书有效，换一批就无效了。真的要用加权算法，那恐怕真的要一位数学家仔细研究MARC后设置一个比较好的权重分配体系，这样就不像您说的是一种简单的查重实现方法了。
不是这样的。一种权重体系，完全可以设计成对大部分情况都有效。检验的方法很简单，让软件查重，然后人工核对甄别。依靠统计数据，逐渐提高配置方案的表现和质量。这是一个体力活。只是我们目前没有太多精力做这样的事情。
我们提出的加权体系提供了一个很好的平台，但是没有能力给出一个非常好的权重分数例子。这好比word给出了排版的完全自由，但是可能没有预先携带某些现成的模板，容易造成用户对它的可能空间的轻看。我觉得我们这配置体系已经不错了，您完全可以稍微研究一下，弄出较好的分数方案，算是各出一半力气，得个好结局。您现在是破坏性思维模式，力图要证明它不好。其实如果反过来，您力图要证明它好，很快就会找到很好的分数方案。应用性的领域，倾向性是很重要的，所谓理论思维不要走极端。
“要一位数学家仔细研究MARC后设置一个比较好的权重分配体系”，这有点夸张了。稍微积累一点经验，多一点样本数据测试，就可以弄好的。要不然我们打赌，您出钱，我找人给你马上弄？实践领域，最怕来真的。一来真的，原先的顾虑的那些就都没有了。好比我那一段潜心核对著者号码表数据，找出每一个错误，我自就是一个校对员，有什么干不了的呢！一个星期很快就弄完了，不用求什么打字员数据录入员。
~~~
感谢您提出的判断流程。
我这里给您讲讲我开发生涯多年来悟出的一些门道。从产品角度，您已经看到产品了，和我看到的基本一样。但是从结构上，从思路上，我的眼睛和思路是X光机，透视看到的图像和角度可能和您感觉的差异很大，甚至面目全非。
加权查重的体系，可贵就可贵在它是一个彻底对称和自构的方案，特别符合计算机的基本算法的原则。不要轻看它，即便是找到了少量反对的案例。
打个比方，乐高的基本拼插部件，仅仅是少数几个基本形状。通过拼接，可以构造出复杂的形状。当然，也存在一些预先就是复杂形状预制件，但是这些预制件的可重用性不强，或者说生产的批量不够大。也好比我们砌墙的砖头，都是一个形状。有人问，我要一百米的墙怎么办？砌到一百米就行了，不必要造一块一百米长的专用砖头。
当然，这样的方法有时候会有缺点，比如乐高的基本部件虽然可以拼接为复杂形状，但是容易坑坑洼洼的，一看就是拼起来的，不如专用部件形状那么贴切。
从我的角度，如果属于对称和自构的方案，有少量缺点，但是实践表明缺点不足以否定对称和自构的强大优点，那我就还是用对称和自构的简单方案，而尽量不用专用的方案。这里面有成本因素、可维护因素等多方面的考量。
您提出的判断流程，仅仅是对特定的图书类型的一种判断流程，不是通用的。和上述权置体系不在一个层面。如果我要实现，比方说在现有的查重窗上加上C#脚本代码实现(为一个特定的二次开发方案)，我在软件一次开发固件方面要做的事情仅仅是提供一些函数，而具体的流程和相关代码永远是一个一个具体的案例，属于用户的部分，而不是属于我们这个平台系统的部分。也就是说，虽然我们的系统对中文图书库缺省提供的题名和责任者的检索点，但是本质上来说我们什么也没有提供，题名和责任者仅仅是那个具体的配置文件的事儿，还到不了系统层次。从系统层次，它仅仅看到一个一个抽象的字段，并不偏爱其中任何一个，不在一次开发代码里面固化任何一个。
也好比我们做裁缝，永远是客人来了量体裁衣，而不是做大批成衣、均码。我们准备的只能是布料，客人来了以前，我们没法预知他的身高的胖瘦。
从我们的体系结构讲，什么东西要进入一次开发的代码，那是非常严格的。您看看，连上述的题名和责任者有关信息都是进不了一次开发代码的，永远在外围配置体系中。所以，您提出的思路，只能在二次开发中实现(即便可能是由我们来编写)。从目前来讲，还没有推广的必要，仅仅作为您自己的、或者您单位的特定做法。
而加权体系可以进入一次开发的代码。当然，具体的分数方案进不了一次开发的代码。
如果您把自己提出的方案改变为一个通用的算法(而具体几步的流程可以作为一个案例来表述)，那另当别论。Microsoft最近一两年增加了一些流程灵活定义处理的通用设施，这方面也有可能在将来作出一些努力，有实现的可能。
~~~
最后要说一点，编目领域关于查重和去重，乃至记录合并，有不少误区，包括许多专业人员都存在认识误区。
我这里给你出一个思考题：编目数据查重不良，也就是说时有重复，会对图书馆业务系统带来什么具体的负面的影响？这个题目没有标准答案，但是我的答案肯定会让别人感到一定程度的意外，而且随着年头变长，我的答案有不断变简单的倾向。