==========
以下是引用 Harry 于 2009-3-1 13:43:40 发表的文字:
由于我是一个“非专业”的计算机专业毕业生，水平有限，以及对dp2的了解还不够深，有些问题可能很难深入下去，看来要做您的知音，还需要时间啊。
现在我就问题论问题说一下吧，一边倒入一边查重是针对江老师写的“二次开发体验”来试验的，试验结果不令人满意，以这个结果来否定加权算法应该说还不充分，但是用来否定加权法在Marc导入查重方面的应用已经很充分了。
dp2的核心rmsws，如果我猜的没错的话，应该翻译为Resource Management System Web Service，名字就能看出您要做一个很通用的东西，加权法被放入您所说的一次开发，应该是针对于通用数据检索的，作为数据检索应用，用加权法判断数据的“相似”度，应该是一种很好的办法，就像是用google搜出来的很多结果，有相关的，也有不那么相关的，权值高的最相关，权值低的不相关，作为用户来说，找到了能找到的最相关的数据，即便有一些不相关的结果，我不看就是了，对软件的评价不会降低，就像是如果用dp2套录书目数据，搜出多个结果，我只用其中最相关的一条就好了，对软件也不会提出异议。
但是反过来，如果用这种方法排除数据就不那么恰当了。假设，仅仅是假设啊，我自己的数据库，想要排除一批数据，装上google引擎进行搜索，如果产生了很多不相关结果都删除了，那不就造成了数据丢失了吗？！这样我肯定要破口大骂了。一边导入一边查重的应用就类似于很多数据被无辜排除了。
这个地方是不是不要那么高的自动化呢，出现重复数据的时候给用户一个手动决定的机会，就像是搜索引擎会给一个结果list,而不是帮你打开相关页面。基本的工作软件做好了，决定权在用户，这样的机制您觉得怎么样呢？这应该是软件设计方面的问题，而不是核心算法的问题了。
不知不觉间，好像我已经妥协了；但我好像也提出了一个很有意思的话题（这是学您啊，有点喜欢“自吹”，哈哈。），要进行最不相关的检索应该用什么方法呢？当然这个问题也看不到有什么实际应用，说说算了。
顺便说一句，我不工作于图书公司，更不提供低质量的服务，当今社会谁不是眼红脖子粗地竞争，客户不提的东西都想帮人家做好，客户的要求就更不敢怠慢了，我们（肯定不止我们）做事情都是精益求精，千万不要小看了别人的敬业精神。
另外，为客户着想，与客户仔细沟通，发觉客户需求，尽量满足客户的要求才是商道；把自己的精美设计理念强加给客户，“你不懂就是农民，就不配用我们产品”的想法，是只有书呆子才会干的事，就是低“商商”的表现。什么是标准，客户的话就是标准，他说让你上下册分开著录，就得分开著录；你要坚持所谓的标准，不愿意干，那好啊，排队等着的多着呢，我们面对的就是这样的市场，残酷的让人无法坚持真理。...唉，说过了不再说闲话的，晕。
另外，这两天我在看您的rmsws，很感兴趣，我猜的没错的话他既包含web service接口，也包含数据库逻辑层，安装后也只有1M多，会有多么强大的功能呢？我很想详细地了解一下，可惜您只提供了API，却未提供相关说明，能否提供相关文档，不知道您是否欢迎基于rmsws的二次开发，也不知道我的要求是否过分。您既然做的是“数字平台”，那肯定欢迎人在上面跳舞吧？
==========
> 现在我就问题论问题说一下吧，一边倒入一边查重是针对江老师写的“二次开发体验”来试验的，试验结果不令人满意，以这个结果来否定加权算法应该说还不充分，但是用来否定加权法在Marc导入查重方面的应用已经很充分了。
一边导入一边查重的dp2batch的方案，我们主要是为了特殊需求的用户准备的。楼上我已经说了，在发现两条数据基本重复的前提下，这个批处理流程没法进行数据的质量判断，没法进行合并，而是简单放弃转入后面的“重”的记录，这样处理有很多问题。虽然有很多问题，但是这种处理办法有用户喜欢，我们没办法拒绝。
而我们主要推荐的利用外部数据源的方式，很简单，就是让用户开辟一个专门的数据库，比如叫做“源书目库”，然后将所有的外部数据装入，根本不要什么批查重。当编目人员需要的时候，他会去检索这个源书目库，检索命中多条也没有关系，他自会作出选择和判断。这个模式早就有了，不是什么新玩意。
而dp2rms里面的查重窗，主要提供给“实时”操作用。也就是说，什么时候编目员觉得想要查重了，在当前记录上触发查重功能，然后查重窗列出一个查重的命中结果列表。列表中也会有阈值方面的参考信息，但是仅仅供编目员参考，而不是强迫说什么一定算重、什么一定不算重。因为这是事件驱动的操作模式，很灵活，并不需要我们开发者规定一个用户的操作顺序。说白了查重窗就是一个带有阈值的普通检索窗而已。
这个查重窗的一个副业，才是被批处理程序中二次开发方案的脚本调用。在批处理的脚本调用的时候，江汇泉给出的这个例子，显然很简单，是看了阈值相关情况就决定“是”还是“否”。但是脚本程序可以编写得很复杂，功能很丰富。也就是说，您在楼上提出的设想，在脚本程序中完全可以实现。这就是我们平台的威力。当然，值得不值得这么去做，或者做一次给您看看让您高兴高兴，那就要看相关条件是否具备了。
否定加权算法的作用和价值和正确性，您说的这些都不够。楼上说了，您有本事去弄个大型的试验，要有试验结果才行。哪有随便找出一点例外，就说这个算法不行？而且您的例外也被我破解了，修改了一点参数，就变得不例外了。我觉得您目前否定不了这个算法的什么。
> dp2的核心rmsws...加权法被放入您所说的一次开发，应该是针对于通用数据检索的，作为数据检索应用...
加权算法不是rmsws这一层的。而是在它上面(外面)一层的东西。在dp2rms里面实现的，明明就是一个“前端”的模块，而不在WebService中。
而图书馆应用服务器也实现了类似的加权检索评估算法，虽然它处在图书馆应用服务器的WebService内，但是相对于内核rmsws来说，却又是典型的Client层。
> ...但是反过来，如果用这种方法排除数据就不那么恰当了...
上面刚刚给您讲过了，一边转入一边查重是一个无关紧要的、用户选用的二次开发方案。用户完全可以不用。您不用夸张。
外来数据的导入主要数据是提供选用。重了也根本不是问题，只要能查出来加以利用就可以。凡是脑筋正常的人，都不会对要参考的外部数据进行查重、过滤。过滤个什么劲呢？
就好比您去图书馆办一个借书证，规定说这个证可以借100万册的范围中的多少本，可以您却非闹着要把可选范围降低为10万册。不可思议。
至于要用一边查重一边导入的方式来创建图书馆“正式数据”，这是相当不严肃的，我们不会推荐用户这么去用。(正确的方法是，用户需要一条一条手动从源数据库中检索、确认、修改合并、保存) 说实在话，这个方案完全是一个鸡肋，找不到什么恰当的场合来用它。我要写文章，都不会写这个话题。江汇泉有点偏爱这个模块，可能是因为他接触的用户多，有些用户比较看重这个而已。
> ...这个地方是不是不要那么高的自动化呢，出现重复数据的时候给用户一个手动决定的机会，就像是搜索引擎会给一个结果list,而不是帮你打开相关页面。基本的工作软件做好了，决定权在用户，这样的机制您觉得怎么样呢？这应该是软件设计方面的问题，而不是核心算法的问题了。
dp2rms里面的详细窗和查重窗结合起来的模式，正是这个意思。您不去用用感受感受，却好像在这里得到了一个“新”想法似的。查重窗设计为一个标准的MDI子窗口，和详细窗平等，可以随时互相切换着操作，正是为了提供事件驱动的灵活操作模式，目的是想要用户通过一切可用的设施来决定和编辑，软件仅仅提供一个操作环境，并不施加什么明显的流程。
我们很早就把这种模式，叫做“实时”操作模式。相对于“批处理”的明显流程循环的模式。
> 顺便说一句，我不工作于图书公司，更不提供低质量的服务，当今社会谁不是眼红脖子粗地竞争，客户不提的东西都想帮人家做好，客户的要求就更不敢怠慢了，我们（肯定不止我们）做事情都是精益求精，千万不要小看了别人的敬业精神。
我的意思是，凡是对一边查重一边转入的所谓“爽”方式感兴趣的人，都是一种类似的思维模式和喜好。您一上来就剖析这个东西，不能不说透露出了您的某些口味。当然，也有可能是资料和选择范围不足，或者某种偶然性造成的。
> ...把自己的精美设计理念强加给客户，“你不懂就是农民，就不配用我们产品”的想法，是只有书呆子才会干的事，就是低“商商”的表现...
说这个话要看场合。如果对一般用户，不说也罢。对您这样的高级人士，我还是觉得说实话最好：我觉得设计就是某种强加，用户是不知道自己要什么的。当然，你的产品出来以后，他们看了，会知道自己喜欢不喜欢，合适不合适。但是他们没法在产品出来前预先知道。这就是制造者和用户的本质区别。
设计产品，当然需要很高的智商。而一般性评价产品，不需要太高的智商，因为这里面口味喜好的成分很大，口味本身无对错。但是，如果在公司里面谋职，要解剖一个产品给出“建设性”的意见，要对智商的要求太高太高了。当然，我声明，这并不是对一般用户的要求。
> ...什么是标准，客户的话就是标准，他说让你上下册分开著录，就得分开著录；你要坚持所谓的标准，不愿意干，那好啊，排队等着的多着呢，我们面对的就是这样的市场，残酷的让人无法坚持真理...
客户的话不是标准，不能随便讨好用户。讨好是要遭报应的，特别是，一群用户和另一群用户的口味并不相同，您要讨好那边呢？
就著录的事情而言，我们现在做到是您随便著录。例如上下册在一起，或者上下册不在一起。都能做到。当然这也是拜MARC的灵活性所赐，软件在这里只要不去干预这种先天的灵活性就可以了，并不需要做什么伟大的创造。
但是，作为一个有作为的公司，必定要有自己的学术观点和形象。哪种方式著录不标准，不好，我们见到了会指出来，会推荐专家咨询，甚至会办培训班。我们绝对不会看到人家著录有问题还夸，那岂不是太不厚道了？
从我们和用户打交道的经验来看，这方面的提醒非常重要。用户一方面通过这些感知到公司这群人的分量，另外也要求软件基本的、缺省的配置，应当是正统的，充满标准和规范的，以便给起步的用户一个正面的引导。
把话说开一些。如果真的出现特别不规矩的用户，强行要把我们的产品往不标准、不通用的方向去引，我们通常会拒绝。丢失点生意不算什么，眼光要长远。退货也不怕，用户觉得不好用，就可以退货。
> ...rmsws，...我猜的没错的话他既包含web service接口，也包含数据库逻辑层...
rmsws的作用是提供一个“逻辑数据库”层。享用rmsws的开发人员，觉得这个逻辑数据库的设施很完备，能够很简单就定义检索点，记录里面可以携带下属的资源记录，有一个XML格式的检索语言，繁琐的事情都给管好了。
实际上如果没有这一层，开发人员势必要到处写很多重复的代码，直接和关系数据库打交道，那样是很痛苦的。也可以简单理解为，rmsws就是要消除令人烦恼的数据库接口代码，给出一个十年二十年稳定不变的开发接口。
因为开发接口统一，所以也形成了rmsws下面挂接的关系数据库底层可以多种，而不影响上层外部调用代码的格局，对产品跨平台、做大做强很有意义。
您现在用的这个bbs系统，就是我们为了检验这个rmsws能力而编写的一个应用。帖子全部都用XML格式存储在rmsws中。帖子里面可以携带图片等资源。每个记录删除的时候，下属的图像资源等就被删除了。记录备份的时候，可以连带下属的图像资源一起备份 -- dp2batch的.dp2back格式，一种可以存储XML和二进制资源的格式。
> ...我很想详细地了解一下，可惜您只提供了API，却未提供相关说明，能否提供相关文档，不知道您是否欢迎基于rmsws的二次开发，也不知道我的要求是否过分...
您说的是WebService的WSDL文件，是的，无论如何声称WebService的都要提供这个接口，主要给机器探索接口用。记得您说您也是因为这个对我们的产品感兴趣的。
我们现在人力很紧张，在图书馆应用服务器dp2libraryws WebService方面，勉强挤时间写了一个API的说明，一直没有精力写rmsws的API的文档。在公司内部用，口传心授，倒也无妨，只是没有文档，外部的人就没法用。
实际上我们有一个用户单位在用应用服务器的WebService接口搞一些开发，这不算二次开发了，可能叫1.5次开发合适一些。不过他们也没有直接用rmsws层的WebService。
如果您感兴趣，我可以花一些功夫来整理这些文档，并且公司里面也可以抽出部分人力来进行配套的服务，例如写一点示范代码，示范样例，解答一些基本的问题。
但是现在比较脆弱的是，您和我们的关系相当脆弱，没有正规的商业合作关系。这倒也不是说钱不钱的问题，而是说在这种状况下，双方的心理都比较脆弱，弄不好一点小事情、小问题就弄得合作不愉快了，互相指责了起来，这就有违我们做事情的初衷了。
我比较喜欢从负面看问题，先了解问题的潜在风险，您知道，这也是大部分程序员的个性，写程序看一个函数的返回值的时候还喜欢先判断if -1怎么样呢，把不正常的情况放在前面判断，而把正常的情况放在后面判断。这种生活方式的好处是，把甜的水果放在后面吃，感觉生活越来越甜，好受一些。
所以，我们不如简单明确一点，互相做一点基本的承诺：您保证对我们的开发环境和资料的版权的尊重，并且保证对我们的劳动抱有一种帮助性的、积极评价的基本姿态，而我们这方保证把事情善始善终，告一个段落，形成一点有用的成果。
我自己的时间弹性很大，有兴趣的事情可以多做，没有兴趣的事情可以少做。当然，这是说客户订单以外的部分。客户的订单永远排第一，要保证饯行对客户的承诺。我觉得这样一种相对松散自由的风格，对中小公司来说是一件好事情。我们不能在没有变成大公司的时候，提前用大公司的呆板来束缚自己，那样很傻。我们的现有的企业文化，其中包含的创造力和竞争力，一种天真执着的精神，都是基于这样一种自发的自然的土气的风格，我们明白这一点。
数字平台这个名字确如您理解的那样，除了在图书馆行业有了一个应用产品，我们内心的最大价值还是要通用的平台产品。这个公司的名字很牛气，为什么这么说，您去工商局注册就知道，数字，平台，两个都是禁止词，可是我们公司的名字就是用两个禁止词构成的，如果不是我们这样的创始人去操办，其他人绝对办不下这么牛气的名字。其中的诀窍就不好意思说了，算提供一个遐想的空间。