以下是引用 Harry 于 2009-2-27 17:48:21 发表的文字:
今天参照“数字平台系统的二次开发体验（一）——数据导入批查重方案”试验了一边倒入一边查重。
{
方案照做之后，有的人(我就是)可能出现“找不到cfgs/dup”错误，解决办法如下：
1.打开dp2内核管理——dp2manager；
2.右键单击服务器节点，在弹出菜单中选择“在下级创建目录或文件”，创建目录名为cfgs；
3.右键单击cfgs目录，在弹出菜单中选择“在下级创建目录或文件”，创建文件名为dup；
4.右键单击dup，在弹出菜单中选择“编辑配置文件”；
5.输入内容如下：
<?xml version="1.0" encoding="utf-8"?>
<root>
<project name="编目查重" comment="编目查重">
<database name="你的书目库名" threshold="100">
<accessPoint name="责任者" weight="50" searchStyle="" />
<accessPoint name="ISBN" weight="80" searchStyle="" />
<accessPoint name="题名" weight="20" searchStyle="" />
</database>
</project>
<default origin="你的书目库名" project="编目查重" />
</root>
}
试验导入了一些数据，功能看起来是正常的，但是仔细检查之后，发现有些书目被“误杀”了，没有重复的却被当成重复书目舍弃了。如下图（右边是查重导入后的）。
如上图左边的1-5，责任者相同，而题名、ISBN不同，被当成重复的，2-5全被舍弃了。
6，7，题名、责任者相同，ISBN不同，200$h不同，被当成重复的，7被舍弃了。
如上两条书目是一套丛书中的不同单册，题名、ISBN均不相同，仅责任者相同，得分也不过50，怎么会被判重了呢，查重过程中我发现有的得分会有200多，而dup中责任者+题名+ISBN才150分，所以可能除了dup文件中设置的查重点，系统内还会有其他查重点，其他重复点得分值加上责任者的分值，可能就超过阀值了。
如上两条书目，题名、责任者相同，ISBN不同，200$h不同，被判重（判断错误），看到这里，我觉得算法中忽略了200$h的权重。
以上两条书目：题名、责任者相同，ISBN，200$h不同，被判不重（判断正确），这下我糊涂了，到底是忽略了200$h的权重还是没有呢？
谢老师，以上的结果让我产生了两点怀疑：
1.是不是我的软件配置有问题，我觉得应该不是，如果没配置好，软件应该不能正常查重。软件查重功能正常，而且大部分结果正确。
2.加权查重算法有问题。
如果是查重算法的问题，那它很难通过重新分配权值来解决，而是加权查重这种算法本身的问题了。就拿200$h来说，该分配给他多重的权值呢，可能一套书题名、责任者、ISBN完全相同，就是分卷不同，他们不能被判重，200$h这一项就超过了题名+责任者+ISBN，而如果给200$h分配了很高的权值，那么两套不同书而200$h相同的书，就有可能被判重了。
加权查重极有可能产生“人多势众”的结果，多个弱权重的加在一起超过了那个掌握真理的少数“人”；
加权查重也有可能产生“以权谋私”的结果，过大的单一掌权者说了算，就损害整体利益了。
拿第一组例子来说，题名不同的书有可能是重吗？应该不算是重吧！但是加权就可能给他判重。
ISBN相同，一定就相同吗？一套书的不同册共用ISBN，就不能判重，一个ISBN给80分，随便加上根稻草，就超过阀值了。
如此组合起来，恐怕结果是n多种，通过预设权值能解决吗？很难吧。是否可以通过多重机制判重呢，可能您已经做了，就是我不知道罢了。
如果不是我的问题的话，这样的查重结果很难令人接受。
如果是我的问题，造成了查重结果出错，麻烦老师指正。
我用的ISO文件一并传上来。
测试.iso
另外，重复数据我选择了保存成gb2312格式,可是打开一看却是UTF8的。
首先感谢您对我们产品如此精心地研究。这够得上知音的水平，这里赞扬一句。
需要说明的是，您使用的dp2batch中一边导入一边查重的“方案”，这是属于内核层面的东西。所谓内核层面，就是rmsws内核，加上dp2manager/dp2batch/dp2rms几个前端。这些东西早在图书馆集成系统以前就开发出来了，是所谓数字资源管理系统的部件。
当年开发这个层面的查重功能的时候，心里有些矛盾，因为当时并没有图书馆系统。所以，有些把MARC“强加”到里面的意思，有点感到别扭。内核层面，XML数据处理是天经地义的东西，而MARC则是有点不靠谱了。好比一个专业面粉厂，做包子总是副业了。不过从产品角度倒是不必这么较真，因为东西堆起来可以用就行，用户才不太关系什么层次不层次的。
内核cfgs/dup配置文件，就是有些别扭的。因为在内核层次，只能这么去设计和安放。而后来有了图书馆应用服务器后，新开发了一套查重机制，配置参数就放在应用服务器数据目录的library.xml中了，这就顺当多了。
dp2batch里面通过C#脚本操纵的查重窗，和dp2rms里面的查重窗是一个东西。所以，建议你一般情况下并不要真通过dp2batch一边转入一边查重来进行测验，而是仅仅把数据全部转入某个数据库(不查重地全部转入)，而后用dp2rms，把每一条数据装入详细窗，然后用菜单“功能/查重”进行查重研判。在查重窗命中记录列表的每行上面，如果你把鼠标移动到“权值和”这一列，则会飞出一个tips窗口，显示权值的构成情况，非常方便。我今天就是这样进行研判的，而没有用dp2batch的一边转入一边查重方案 -- 我手边没有这个方案。
(建议不必用dp2catalog -- 这个属于后面层次的环境，而直接用dp2rms加上查重窗口进行操作就可以了。查重窗口是MDI子窗口，而不是模式对话框，可以保留它并且换到其它窗口，操作非常方便)
您说“是不是我的软件配置有问题，我觉得应该不是，如果没配置好，软件应该不能正常查重。软件查重功能正常，而且大部分结果正确”，用我上面说的dp2rms里面查重窗加上tips小窗口就应该容易做出明确判断。而不要用批处理的结果来猜测，那样太间接和模糊了。
我研究了“连环谜宫”这一记录。按照你的查重配置参数，命中三个120分，一个100分。原因确如您说的那样，这些记录之间，作者成套重复，但是题名却不一样，出现高分的原因，就是给作者的权重50太高。我没有修改您的阈值100分，而仅仅把作者的权重修改为20，查重结果就非常“合理”了。原来超过阈值的三个，现在就是60分了。
我修改后的权重配置如下：
<database name="中文图书" threshold="100">
<accessPoint name="责任者" weight="20" searchStyle="" />
<accessPoint name="ISBN" weight="80" searchStyle="" />
<accessPoint name="题名" weight="20" searchStyle="" />
</database>
我们来分析一下：就算责任者和题名都一样，如果ISBN不一样，还是仅仅40分，不能超过阈值。如果发生匹配的作者不止一个，例如两个、三个，也都不能超过阈值。我这样配还算合理吧？
用我的例子，我证明了目前这套加权体系算法还是好用的。用您的例子，证明了这套加权算法有不合理之处。那么，我们两个的说法，哪个对呢？哪个都对。我们的说法涉及到不同层面，互相不矛盾。
我的例子，表明了设计权重要有不少讲究。这等于暗示，如果权重设计“不合理”，则会出现非常“不讲理”的结果。
如果需要做出一个总结，就是，因为这种算法很简单，那么在权重设计上动一点脑筋，还是值得的。因为它简单，简单就是金不换。
感谢您给出的这么简单而明晰的例子，证明了作者多次命中后的可能结果。您也给出了改进的方向，就是抑制同一检索途径多次命中后的分数。我不好意思夸您“聪明”，因为这个改进方向是如此直白和简单，我怕夸奖了您以后您反而不高兴。不过这个思路还是您提出的，我不敢掠美，这点大家都可以看到。
目前这个加权配置体系，我觉得有两个地方可以做文章。我提前说一下，只看出一个地方的，就不如我了，提前表扬一下自己。
第一个地方，是weight属性。记得在我设计读者借阅权限参数的时候，要定义续借的借期。续借还可能好多次。我就这样定义，连同第一次借阅：60day,30day,15day,...。用意很直白。现在，可以类似地改进weight定义：50,20,1,0,...。随着命中的次数越多，加权的分数越来越低。
第二个地方，是searchStyle属性，已有的用途是放匹配方式精确一致还是前方一致等的，现在扩展一个新的style，例如可以叫做“only_first_hit”什么的，让程序知道，除了第一次命中，以后的命中都不加分。
当然，第二个地方的配置，相当于第一个地方的配置的极端情况：50,0,...。
从这里看出，我们采用了XML来描述配置参数的时候，获得了空前的扩展空间，设计过程不再成为一种烦恼。有时候形式对内容的束缚和影响还是很大的。
总结一下：今天我首先提出了在现有体系下规避问题的办法；然后提出了改进体系的方案。
关于“保存成gb2312格式,可是打开一看却是UTF8的”，我这里暂时还没法操作，等过两天回答您。