由于我是一个“非专业”的计算机专业毕业生，水平有限，以及对dp2的了解还不够深，有些问题可能很难深入下去，看来要做您的知音，还需要时间啊。
现在我就问题论问题说一下吧，一边倒入一边查重是针对江老师写的“二次开发体验”来试验的，试验结果不令人满意，以这个结果来否定加权算法应该说还不充分，但是用来否定加权法在Marc导入查重方面的应用已经很充分了。
dp2的核心rmsws，如果我猜的没错的话，应该翻译为Resource Management System Web Service，名字就能看出您要做一个很通用的东西，加权法被放入您所说的一次开发，应该是针对于通用数据检索的，作为数据检索应用，用加权法判断数据的“相似”度，应该是一种很好的办法，就像是用google搜出来的很多结果，有相关的，也有不那么相关的，权值高的最相关，权值低的不相关，作为用户来说，找到了能找到的最相关的数据，即便有一些不相关的结果，我不看就是了，对软件的评价不会降低，就像是如果用dp2套录书目数据，搜出多个结果，我只用其中最相关的一条就好了，对软件也不会提出异议。
但是反过来，如果用这种方法排除数据就不那么恰当了。假设，仅仅是假设啊，我自己的数据库，想要排除一批数据，装上google引擎进行搜索，如果产生了很多不相关结果都删除了，那不就造成了数据丢失了吗？！这样我肯定要破口大骂了。一边导入一边查重的应用就类似于很多数据被无辜排除了。
这个地方是不是不要那么高的自动化呢，出现重复数据的时候给用户一个手动决定的机会，就像是搜索引擎会给一个结果list,而不是帮你打开相关页面。基本的工作软件做好了，决定权在用户，这样的机制您觉得怎么样呢？这应该是软件设计方面的问题，而不是核心算法的问题了。
不知不觉间，好像我已经妥协了；但我好像也提出了一个很有意思的话题（这是学您啊，有点喜欢“自吹”，哈哈。），要进行最不相关的检索应该用什么方法呢？当然这个问题也看不到有什么实际应用，说说算了。
顺便说一句，我不工作于图书公司，更不提供低质量的服务，当今社会谁不是眼红脖子粗地竞争，客户不提的东西都想帮人家做好，客户的要求就更不敢怠慢了，我们（肯定不止我们）做事情都是精益求精，千万不要小看了别人的敬业精神。
另外，为客户着想，与客户仔细沟通，发觉客户需求，尽量满足客户的要求才是商道；把自己的精美设计理念强加给客户，“你不懂就是农民，就不配用我们产品”的想法，是只有书呆子才会干的事，就是低“商商”的表现。什么是标准，客户的话就是标准，他说让你上下册分开著录，就得分开著录；你要坚持所谓的标准，不愿意干，那好啊，排队等着的多着呢，我们面对的就是这样的市场，残酷的让人无法坚持真理。...唉，说过了不再说闲话的，晕。
另外，这两天我在看您的rmsws，很感兴趣，我猜的没错的话他既包含web service接口，也包含数据库逻辑层，安装后也只有1M多，会有多么强大的功能呢？我很想详细地了解一下，可惜您只提供了API，却未提供相关说明，能否提供相关文档，不知道您是否欢迎基于rmsws的二次开发，也不知道我的要求是否过分。您既然做的是“数字平台”，那肯定欢迎人在上面跳舞吧？