最近半年来一直很忙，做了一些东西，都没有来得及在论坛和大家分享交流。
有些东西可能因为需要一段时间公司内部测试，才能正式给用户使用，但经过这段时间以后，似乎就忘记了它是个新功能了。
下面总结一下。后面我争取抽空一个一个写出文章详细介绍。
1) dp2OPAC 的分面导航功能
在这里已经可以看到示范：
http://dp2003.com/dp2opac/searchbiblio.aspx
这是全年年底做的一个功能了。为保守起见，升级安装 dp2OPAC 的时候，如果不进行专门配置，检索命中的画面还是延续以前的没有分面导航的风格。后面我会专门写文字介绍如何配置，感兴趣的单位可以试试应用它。
分面导航功能，是在检索的画面中，提供一种多层次的导航入口，列出这一批命中的记录的书名、作者、出版社、出版时间、主题词等“多面”的信息，方便访问者跳转，探索这一批书目的更多信息。这是 OPAC 系统提升和完备功能的一个方向。
没有分面导航功能的时候，访问者怎么达到上述目的呢？那就必须要一个一个书目记录地观看，如果看到感兴趣的锚点，跳过去。那时候的画面并不提供一个总结各种线索的面板，信息散布在所有页面中，页面中的各处。假如一批记录数目较多，需要翻页，一般访问者很快会失去翻看的兴趣，一般人也不会耐心从头到尾每页都看。这样会和很多有价值的机会和点失之交臂。
分面导航就是把各种访问者可能会感兴趣的点汇总起来，有点分析这批记录的意思。所以这种功能也可以叫“分面分析”。也可以理解为把浏览画面搬到了普通检索画面来了，对命中的一批记录进行分面浏览。
做出来这个功能后，加上在少数单位试用后，我发现一个平时不显眼的问题，突然上升为明显的问题了。因为分面导航中，作者这个“面”很重要，在导航面板上各种作者名称也是很显眼的，这些名称都是采自 UNIMARC 的 7XX 字段(假如是中文数据的话)，这时候很多单位草率的数据中，当初随便从 200$f$g 复制过去没有修改的带有“(美)”“(英)”等部分就都展现出来了，非常扎眼。(一个好的信息展示方式，自然是也能突出数据本来的问题的) 这使得我想到另外一个话题：如何快速发现和修改书目记录中的某种特征？
2) dp2circulation 书目查询窗的 MarcQuery 脚本功能
MarcQuery 是一种方便操作 MARC 数据的 C# 脚本开发方法，也可以理解为一个函数库，因为它非常方便，而且重要，我们给它取了个专门的名字 -- MarcQuery。这个东西的构想和初步试验，其实在早几年前就开始了，后来因为各种耽误，一直到今年年初才发大力做完(这里感谢阿甲的促进)，目前已经投入实用 --- 但大家基本上都不知道是不是？这就是我在这里介绍的用意了。
dp2 系统牛一点的用户，很早就知道 dp2circulation 里面有各种统计窗，甚至后来框架窗口也有了二次开发的“方案”。在 dp2library 的 library.xml 中可以使用脚本函数；在 dp2kernel 的各种库的 keys 配置文件中可以有脚本函数。MarcQuery 并不是颠覆这些的，它只是其中一个脚本函数库，在延续我们系统中脚本的传统和优势。
但它太方便了，在程序设计概念思路方面，有很大的突破，会给使用它的用户带来很大的效率收益。我觉得它也会给我们一个机会重新审视脚本这种设施，发现更多的价值。自从它诞生后，现在我们的一次开发中许多涉及到 MARC 数据操作的场合，也都开始使用 MarcQuery 函数库了。
MarcQuery 的基本作用就是，操作 MARC 数据，操作记录、字段、子字段，关注什么头标区、指示符、子字段符号之类概念。MARC 数据一直就是 dp2 系统的安身立命之本，那在 MarcQuery 出现以前，人们是怎么操作 MARC 数据的呢？当然也有办法，日子也要过。但老式的一套函数库非常繁琐、困难。开发成本很高。MarcQuery 的使命就是改变这个局面。
它通过两个法宝来处理 MARC 这个难题。
第一个法宝：XPATH。很多人听了可能觉得诧异，XPATH 难道不是操纵 XML 数据的一种方法么？是的，没错。但 XPath 的思想可不限于 XML 。MARC 数据本来就有层次结构，所以是很适合用 XPath 来表达搜索定位的需求的。通过这些年人们持续在 XML 方面的学习投入，XPath 已经被很多开发者熟悉，MarcQuery 采用XPath 来作为定位筛选 MARC 结构的基本设施，就是善用了这部分设施。通过这一项努力，MARC 的内部结构可以方便被搜索和列举了。
(注：MarcQuery 不是操作变换为 MARCXML 以后的数据结构。不是的。MarcQuery 操作的直接是 MARC 的一种内存数据结构，这种结构是我们长期发展起来的一套概念。所以，完全符合 W3C XPath 规范的解析器等等，都是技术关键点了)
第二个法宝：面向集合的程序设计理念。XPath 选出来的 MARC 结构对象，最常见的都是集合的形式，就是一批这样的对象被选中了。同时操作多个对象，作为一种基本的理念被贯彻。MarcQuery 的数据变换的函数，重点提供了集合方式的设施，使得修改 MARC 结构对象非常便利。这也使得脚本代码级联书写方式得以存在和应用。
MarcQuery 作为一个函数库，在 dp2 系统中所有可以使用脚本的地方都可以使用它。但既然 MarcQuery 的主要目的是操作 MARC 记录数据，那它目前在 dp2circulation 前端中最能发挥作用的地方就应该是“书目查询窗”了。
为了应用好 MarcQuery，书目查询窗增加了一种专门的轻便的 MarcQuery 脚本类型，在书目查询窗的上下文菜单中就可以创建一个新脚本文件并执行。为了方便操作者观察脚本执行的效果，书目查询窗提供了一种内存存储修改后记录的机制，等操作者观察好以后，发出保存的命令的时候，这些修改后的记录才真正存入服务器的书目库中。这些优化和改进，真正把 MarcQuery 脚本推进到方便实用的程度。为了对比观察修改前后两条记录，又发展出一种颜色突出显示的对照方法，并在日志窗等多处也有应用。
3) 指纹识别
这个功能的缘起是，去年一次在和红泥巴的阿甲和探长闲谈的时候，他们说到现在小学里面很多一年级二年级的小豆包，很容易丢东西，什么图书馆的借书卡，那基本上是别指望能保管好。能不能有什么替代的办法，让小读者不用借阅证就能借书？当时想到了指纹识别这种方法。但因为开发工作较忙，一直没有真正去实现这个功能，到了年底，探长给寄过来一台指纹阅读器，于是这个功能就出来了。
指纹识别分为 1: 1 和 1: n 两种模式。所谓 1:1，就是在已经确定读者身份的情况下，要求扫描他的指纹作为进一步鉴别，好像输入密码一样。这时候计算机只需要采集一个指纹，和一个以前存储的指纹进行比对。而 1: n，就是在不知道读者姓名证号等一切信息的情况下，让读者扫入他的指纹，然后计算机从数据库中比对所有的以前采集好的指纹，定位这个读者的基本信息。可以看出，1: n这种模式，难度完全在于读者的总规模，如果数据库中的读者数量太多，可能比对识别的时间就会很长，以致于到了无法实用的地步。
(目前综合各种信息推断，读者总规模在1000-2000人的单位比较适合用指纹识别，人数更多可能效果就不好了。这个限制因素不是我们的 dp2 系统造成的，而是目前指纹设备厂家的通行技术水平决定的。不过，一个单位其实常常是部分人采用指纹识别的，假如不是每个人都用指纹识别，那么这个技术还是可以用于人数很多的大单位的)
所以，指纹识别的功能出来后，虽然少量的数据下测试效果都很好，我们还是有种心理准备，就是读者数量大到一定规模的时候，可能会出现识别缓慢和误识别的问题，情况怎样还需要评估，而唯一的评估方法就是投入实用检验。春节以后，在望湖小学进行了较大规模的试验，目前已经有汇报说出现了一些误识别的情况，结合厂家所说万分之几的误识别率，评估了一下觉得还是在预计的范围，但能切身体会到这个技术不是一个绝对完美的技术，还需要其他辅助措施，例如在扫入指纹并识别后，需要语音提示读者姓名帮助判断，后续优化工作正在进行中。这里感谢望湖小学提供第一手的实践经验。
指纹阅读器硬件本身很廉价(目前典型的一款设备在淘宝上只要200多元人民币一个)，它主要提供扫入指纹图像的简单功能，而识别的算法什么的都是在计算机软件(驱动程序模块)中完成的，后面这部分主要决定了系统的运作质量。
读者对指纹阅读器这种新设备的适应也是个课题，为此我们专门开发了练习模式，能够提供给读者熟悉指纹阅读器之用。
从隐私和安全的角度，目前读者库中仅保存指纹特征码，这是厂家才知道具体算法的一种编码，里面有一些形态特征信息，但不等于指纹图像。如果指纹特征码泄密，对于不知道厂家的运算规则的人来说，这种特征码信息无异于天书(我们作为dp2系统的开发者也是不知道这种特征的内部结构和算法的)。读者库中不保存任何指纹图像。这部分能解除人们对指纹应用的隐私安全担忧。不过，隐私和安全始终是一个很重要的话题，我们将密切关注，尽可能将产品做到完善。