书目（OPAC）的价值（二）
星期五, 1月 27th, 2006January 23, 2006
Filed under: Correspondence (同行交流) - keven @ 12:26 am
以实体图书馆为基础的数字图书馆（复合型图书馆），从某种意义上来说就是以书目数据/二次文献为核心的数字图书馆。书目数据的格式和操作的传统单一模式一旦被打破，数字图书馆资源管理中传统资源与数字资源的隔阂就可望被打破，书目数据将真正集成到图书馆集成管理系统中去，支持多种metadataschema的同时处理。真正的数字图书馆集成管理系统就有可能产生。（我们孜孜以求的 支持多模式的元数据管理系统 ，看来大方向是没有错）。
对于OPAC扩展应用的瓶颈在哪里？从技术层面上来看，图书馆员被70年代末产生的MARC（ISO2709/AACR2）格式所累，第三方提供的集成管理软件又不能向图书馆员和读者提供对书目数据的机动灵活的操控和丰富的语义关联，技术已经发展了n代了，那时甚至连这种需求想都不可能想过。
Web2.0时代的图书馆自动化系统就不能再以MARC为核心，而代之以基于本体或参考模型的书目格式（例如FRBR、OAIS等）来管理各类微内容（书目记录、索引、文摘、网页、用户记录、全文、图表、音视频、程序、课件、公式、分子式、X光片……）的CM系统为核心，而这个CM系统从观念上也与现在的应用模式大不相同， 它将不可能是一家公司、一个产品通吃天下，而是以资源内容的语义互操作为核心的，物理层、逻辑层、语义层、显示层分离的，与以用户需求为导向的、提供用户交互环境和工具为目的，松散耦合的、开放的、支持分布式管理的数字图书馆系统。
书目（OPAC）将在全新的图书馆的数字环境中存在，它绝不是不是封闭的、孤立的、将被取代东西，而是信息生态链中的一环，是可以关联、挖掘的东西（不过好像我们从来没有像产业界和金融行业一样，花一点成本去”挖掘”读者的信息需求规律和模式）。书目可以与读者的偏好和利用信息关联，可以采用RSS形式分类/按主题发布，可以采用OpenURL或COinS方式与全文勾连，可以虚拟拼装成联合目录，支持馆际互借和联合编目……等等（NCSU的图书馆已经开始这样做了，他们正是采用了一家数据挖掘公司的软件方案，见下文。更多的例子参考文末”延伸阅读”）。
任何一个搞数字图书馆研究和开发的公司和个人，都会密切关注这一领域的进展。
加州大学图书馆在去年12月发布了一篇研究报告 Rethinking how we provide bibliographic services for the University of California (Full report [pdf] Executive summary [ pdf ])，提出应该对图书馆书目系统的结构进行了彻底的变革。而 北卡州立大学（ NCSU）图书馆 已经将其中的观点付诸实施了。该馆采用了Endeca公司提供的系统，这是一家专门从事企业信息搜索与挖掘软件开发的公司，采用数据挖掘的理念，对图书馆目录的主题关联、作者关联、媒体关联、读者兴趣聚类、推荐等的功能进行了全新的开发。其中一些观点，我们已经在AADL2.0版的图书馆系统中看到了影子。可以说现在除了 AADL 之外，又多了一家L2的典范–NCSU的图书馆系统。
OCLC的资深研究员Lorcan 为这些新的变化激动不已 。
老槐 说呼吁研究《L2时代的OPAC》，已经有人写了， Jackie强力推荐 的Casey Bisson在ALA仲冬会议上的演讲就是一片很好的论文。有朋友留言说为什么我们总是跟在别人屁股后面，拾别人牙慧（大意）？实在是技不如人那！差距越拉越大，能跟得上就算不错了，业界的当权者甚至连这点尚不能自知！
Casey演讲的核心就这么几条：
- OPAC的可用性已经落后于技术的发展和用户的要求了；
- OPAC的”可查找性”从来就不是唯一的和不可替代的，特别是到了搜索引擎主宰互联网的时代；
- OPAC应该放低身段，赋予更多的2.0属性（关联性、固定链接、RSS）；
- 实现OPAC的基础结构（architecture）必须发生变革，必须支持remixing；
Casey最后也认为图书馆和图书馆员在数字时代应该更具有优势的，只是优势的发挥受到了一些固有的限制。
资源和用户是图书馆的财富。书目作为图书馆最重要的资源，虽然其曾具有”太阳般的宇宙中心”作用，但是人们毕竟已经认识到宇宙不存在中心，图书馆所收藏和管理的资源的拼图中它只是最早进入视野的一块，其他二次文献、全文信息、Web资源、数字仓储、链接资源、机构库、OA等等，都还没有建立起适当的关联统一视图。我们期待具有标准的互操作架构将这些资源和服务粘合起来，但是眼下这些标准规范也处在形成和变化过程中。
延伸阅读：
Lorcan Dempsey: Thinking about the catalog 后面有很多留言和讨论，非常值得一读。
以及老罗的其他相关post:
- Making data work - Web 2.0 and catalogs
- A service-able catalog
- Circulating data - intentionally
- Making data work harder
- Metasearch, Google and the rest
E-Matrix - NCSU Library E-resources Management System
介绍了NCSU的电子资源管理系统
6 Comments »
一个OPAC能引发如此大一通议论，Keven先生的脑子里真有挖之不尽的思想啊！
这篇东西不是博文而是论文，我们坚决不同意K先生仅将其放在自己博客中。必须投稿，比如《中图学报》或者《大图学报》，至少也要放到K先生自己打理的那个杂志栏目中。
Comment by 老槐 - January 23, 2006 @ 10:38 am
也是完成老槐的作业啊。国外对这个东东突然热起来了，2.0时代谈图书馆的核心竞争力，OPAC正好水到渠成吧。
现在还只是一些资料堆积，这个话题往外看与图书馆的服务有关，往里看与图书馆的技术进步和数字图书馆建设有关，是一个很好的选题。年后把这些资料好好消化一下再说。也欢迎大家一起讨论，文章是写不完的。
Comment by keven - January 23, 2006 @ 11:06 am
岁末，图林只有K老师还在坚守博客啊。。
Comment by 小农 - January 23, 2006 @ 12:55 pm
等待K先生的大作早日出版，搞搞大，光发期刊不过瘾哦。
Comment by wmdzn - January 23, 2006 @ 2:27 pm
借助”上海年华”谈一下OPAC建议。
1、简单看了”上海年华”现在的β测试版–这个效果，两个字评价：好看。在上级领导视察或作汇报时一定很长(zhang)脸。对我这种缺乏艺术细胞的人来说，只有好看和不好看这种评价词–特别崇拜能把网站弄得好看的技术员。
2、自然而然，”上海年华”一定会增加信息量，这就涉及到OPAC。国内系统由于立足点不太高，多仅考虑解决本地信息发布和查询需求，所以界面和数据常没有考虑到多语种版本–甚至没有照顾到繁体和简体中文的使用习惯，即用繁体检索词不能检索到简体内容数据。但对于”上海年华”这种立意比较高的项目和特色数据库，一定要考虑用UTF-8而不要用GB2312作为字符编码方案喔（现在的”上海年华”网页是用的GB2312）。
3、很多OPAC，由于没有采用UTF-8，为了体现出多种语言界面版本，分设了多个独立的语种网页，建设和管理维护成本增加，更因这种分设的方式，导致不同语种版本的使用者交流的信息不能共享–这不利于WEB2.0提倡的全民参与。事实上，类似OCLC的FirstSearch界面就是一种很好的解决方案，采用UTF-8作为字符的编码，这样可以容纳下全球的文字，网站实际是没有某种固定语种版本的，仅由使用者选择自己的习惯语种，由系统自动填入相应的界面字符而已。（打个广告，我公司也早就有类似应用）
4、界面内容比较固定、量也较少，翻译成本不算太大。但如果一个有价值的数据库也要充分照顾不同语种习惯用户使用，就需要为这些信息添加不同语种的描述。受传统MARC的影响，多数图书馆制作元数据时，只提供了中文数据，没有考虑其它语种的数据（如英文），或者是另建一英文描述数据库来解决需求，这种语种描述数据分离也增加了制作和管理维护成本。
5、利用xml:lang机制实现资源的多语种元数据描述是提升数据库影响力的重要手段。然而，在元数据中提供多语种的描述，这个成本大大超出了界面多语种成本。所以，最好是引入类似Wiki的机制，在基本语种元数据的基础上，由访问者或遍布全球的外聘工作人员，实现数据的对照翻译–这样，不断充实完善，最终就会形成一个多语种界面和内容切换、用户充分交流参与的OPAC了。
Comment by 平台江 - January 24, 2006 @ 12:31 pm
谢谢江先生。特别是批评和建议很有道理，我们定会考虑。目前”上海年华”还是一些相对独立的子项目，希望接下去能开发一些2.0必须的交互功能（如rss,tag等），涉及到业务流程，与其他系统的关联基本上还未考虑，这是个遗憾。但是将来肯定有整合的问题的。
Comment by keven - January 24, 2006 @ 2:20 pm
Trackback: http://tb.donews.net/TrackBack.aspx?PostId=709766
- January 17, 2006 @ 
