今年3月间CASHL免费服务周,文献传递需求数猛增,情报咨询部忙不过来。应馆里安排,曾做了几天检索电子期刊、下载原文,发现OPAC中电子期刊链接常常出错。事后经了解,才知道近几年,电子期刊书目记录已经不再维护了。
听到这个消息自然很吃惊,因为本馆OPAC为西文电子期刊做单独的书目记录,已有很长历史了,还有同事去香港学过如何用程序处理维护书目记录。近几年竟然听之任之,不再更新?联想中文电子期刊,以前期刊采购曾在印刷本记录下注明有电子刊的信息,现在期刊部烟消云散,大概也没人维护了。这种信息不全、链接出错的状况,对使用OPAC的读者肯定是一种误导。
中文电子期刊几乎一统江湖,不做进OPAC读者也知道去查期刊网、维普、万方之类电子资源。但西文电子期刊从整体上讲购入的并不多,在没有一个统一检索入口的情况下,利用率肯定大打折扣。毕竟是花大价钱买来的东西,而且很有可能一夜飞失(如果下年没订购的话),如不及时行乐,岂不太冤?
自己属于OPAC粉丝,但据说现在图书馆OPAC都不收录订购的电子期刊,而是另做“电子期刊导航系统”之类,也就是中文或/和外文电子期刊一览表或检索系统。本馆也有一个这样的导航系统。但图书馆只订印刷版或只订电子版的情况也不少见,如果读者要查期刊,必须分别到两处去查,不是太不“用户友好”了吗?
我以为,宁可没有所谓的“电子期刊导航系统”,也必须把订购的电子资源做进OPAC,并且维护好。如果两者兼而有之,给读者多一个入口,当然也很好。
抽空查了几家大馆,电子资源确实都没有做进OPAC,做得好的也不过为数据库本身做一条书目记录(如:中国期刊网全文数据库[电子资源])。
但我不相信图书馆OPAC现在都已不收电子期刊,或者已不再维护之说──虽然电子资源大部分只是使用权,但毕竟是花费巨资购得的,难道都不愿意再花些相对而言极小的功夫,增加或方便其利用?这是不可思议的事。
便去香港的八家公立大学图书馆OPAC查,发现他们不但为每个库做一条书目记录,而且也为库中的每一种资源做书目记录,无一例外。在香港大学的OPAC中看到2005年9月的维护信息,应当算是仍在维护的证明了。
从OPAC看,香港八个大学馆的做法各异,没有完全相同的。下面是通过查“中国期刊网”得出的一个简表,或许有助于找到既简化、又不失有效的方法:
图书馆 | 馆藏记录 | “馆有”附注 | 印刷本/电子版书目记录 | 电子期刊链接 |
香港大学 | 收录年限 独立索书号 |
无 | 电子版反映原刊信息 与印刷本做不同记录 |
到特定期刊 |
香港中文大学 | 说明收录年限 | 无 | 与印刷本做1条记录 | 到特定期刊 |
香港城市大学 | 无 | 无 | 电子版简单反映原刊信息 与印刷本做不同记录 |
到特定期刊 |
香港教育学院 | 无 | 注明收录年限 | 电子版不反映原刊信息 与印刷本做不同记录 |
到特定期刊 |
香港浸会大学 | 无 | 未说明收录年限 | 电子版反映原刊信息 与印刷本做不同记录 |
到特定期刊 |
香港科技大学 | 无 | 无 | 电子版反映原刊信息 与印刷本做不同记录 |
到特定期刊 |
香港理工大学 | 无 | 无 | 与印刷本做1条记录 | 到特定期刊 |
香港岭南大学 | 无 | 注明收录年限 | 电子版不反映原刊信息 与印刷本做不同记录 |
到数据库 |
蓝字:精制做法 &
nbsp; 红字:简化做法
从方便维护角度,总体上倾向于科技大学的做法。
如果书目信息不易获得,从方便生成角度,书目记录也可采用城市大学的做法。
如果链接到特定期刊有困难,就只能无奈地像岭南大学那样链接到数据库了──有总比没有好。
总结下来OPAC收录电子期刊的简易做法如下:
·电子版做独立的书目记录(如果被多个数据库收录,则做多条书目记录)
·链接到特定的期刊,而不是数据库(通过程序处理链接地址,而不用固定链接)
·不做馆藏记录
·不做收录年限附注
如此,只要有简单的书目信息(无需比导航系统中的信息更多),就可用现有软件转换成MARC格式,而后转入图书馆集成系统。通过程序处理链接地址,维护工作也尽可能降到最低限度。
看本馆OPAC中的电子期刊,除了链接部分,基本上就是按上述要求做的。
那么维护的关键到底在哪儿呢?因为未经手做这件事,所以不清楚处理起来的困难之处。本馆之所以做过而后又放弃,肯定是有说得过去的理由的。但只要确定应当做,总能找到行之有效的方法的,事在人为。
只是不了解国内的OPAC里电子期刊的整体维护情况如何。
维护好象难在:对电子期刊的增删除问题,许多电子期刊都有了永久性地址,如JSTOR等许多都是如此。
精灵老师:你博客的一边全黑,遮住部分字,看起来很不方便哦.另外很喜欢您的博客,学了许多东西.
呵呵,谢谢光临。
正好趁此机会建议您改用Firefox浏览器。
哈,谢谢你了,不小心又学了一招,现在浏览起来方便多了
我们馆一直在OPAC做电子刊、电子书。数据库也做了一些。这是在还没有导航库、Portal之类的时候就开始做了。现在的federated检索不敢恭维,但一站式全在OPAC也成问题(全要MARC)。OPAC能不能集成各种元数据?
856维护我们开发了一个扫描程序,但只知道断链,修复还靠人工。
我觉得全要MARC倒并不是难事,反正MARC转换也不难,比较麻烦的是856的维护。
现在OPAC正在改进中,今后外挂式的OPAC集成更多非MARC元数据应该是没有问题的。但链接更新仍是问题的焦点。