存档笔记

Ajax技术与图书馆2.0

(前几日donews无法登录,无心写博,但本文写成已久,不得不发于备份站点http://xmulib.net/keven,现搬回来。在这里做一告示,本人有一永久地址:http://www.kevenlw.name/,目前指向上述备份网站,欢迎访问。)

很高兴暨大小钟愿意承担“图书馆2.0”著作中有关Ajax的部分,大家可以分享暨大在实现OPAC2.0时采用Ajax的经验了。不知道其它图书馆或图书馆软件厂商是怎样利用Ajax的。眼下新技术新名词泛滥,泥沙俱下,有些公司才咬了第一口苹果,就宣称尝遍天下奇异水果。这需要我们有一副火眼金睛。

当然这本书中Ajax应该写到什么程度也是一个问题,Ajax可能更适合写技术应用白皮书。

Ajax是Web2.0的一项重要技术,由于它“技术性”较强,在谈论图书馆2.0的时候鲜有提及,但是如果能很好地利用Ajax技术,许多图书馆的应用能够更加“2.0”,使图书馆服务的可用性更强,更加“无缝”。

Ajax 是 Asynchronous Javascript and XML的简称,是一个技术的大杂烩。实际上目前有许多公司 推出的Ajax技术产品(平台或实现方案),分别有不同的名称,例如Adobe(购买Macromedia公司时带过来的)叫做Flex,微软叫做 Atlas(最近在SilverLight中是否改名?),还有Applet,他们具有许多与Ajax共同的特点,但在功能和能力上又有很大的不同。他们 可以统称为富媒体应用(RIA:Rich Internet Applications)。

Ajax给我们的最大能力,是我们可以像客户端软件一样用浏览器,这是非常激动人心的。在我们的大量应用向b/s结构过渡的时候,最大的制肘就是不 能基于状态的(实时)交互。当然,Ajax尽管提供了可能,但这项技术涉及大量技巧和约定,还不是非常成熟,还很复杂,代码的共享性也不是很好,应用起来 十分不易。

著名的Ajax应用举例:

Google maps
Google Mails
Google Suggest

Ajax技术图书馆可以用在什么地方呢?

1、OPAC2.0(如暨大所做);
2、数字图书馆搜索界面;
3、联邦检索;
4、同步显示关键词索引及分类、主题词等;
5、复杂的ILL表单交互;
6、类目及主题标目浏览

想举一些图书馆应用Ajax的例子,但曾经收集的一些例子已经都不可访问,估计当初的试验都已经“转正”。实际上现在越来越多的应用都采用了 Ajax技术,Ajax成了开发Web应用的一种必需,成为开发工具的一部分,图书馆仍旧是指需要提出具体的应用需求就可以了。这样就对了,这说明 Ajax正在走向成熟。
这里有个例子:http://elibrary.med.yale.edu:16080/ajax/。

总结:
应用Ajax的好处:

• 完全基于开放标准:X/HTML, XML, CSS, JavaScript;
• W3C的Web API工作组已着手制定xmlhttprequest响应标准
• 减轻服务器负载;
• 减少带宽负担;
• 减少交互页面;
• 快速响应,界面流程化(streamlined interfaces)

Ajax应用的不足:

• 客户端设置的不可预知性:如果浏览器js被禁止,就无法使用;
• 不是所有浏览器都可用,而且依赖于较高版本的、支持xmlhttprequest的浏览器
• 浏览器对某些功能丧失控制(如后退键);
• 页面的状态不是总能获得,从而降低了可用性;

何时可用Ajax:

• 可预计和可控制的用户环境
• 需要搜索功能;
• 需要多次/多步交互;
• 处理大规模分布式数据;
• 需要复杂验证(表单等)

评论(4)

阻碍成长的九大错误

励志的东东从来非我所爱,然而总是发现许多有为青年落入九大圈套,于心不忍,特别提出,请对号入座。

  • 固步自封/Thinking you already know everything;
  • 乱花迷眼/Being confused by the marketing hype
  • 光说不练/Not taking action
  • 轻易放弃/Giving up
  • 左右摇摆,轻信谣言/Worrying about/listening to what others think
  • 浅尝辄止/Dabbling with it
  • 期望过高/Having unreasonable expectations
  • 缺乏自知/Failing to/not wanting to (at least start to) understand yourself
  • 自暴自弃/Not taking responsibility for yourself

评论(7)

读我所读

感谢许多朋友关注我的网摘。目前我的工作就是“研究”,领导甚至要求我所在的部门为单位的内部网站开设专业学习频道,因此我非常乐意把我的关注和每日所读到的东西与大家分享。只是目前国内的一些2.0服务实在太遭,才有了我昨天埋葬365key的帖子。我曾经因为从当当网上买了盗版书和二手书(里面甚至夹有信件)而去信大骂当当网,诅咒这个网会死得很惨,当然这个愿望还没有实现。

我这里贴出我常用的网络服务和工具,与大家分享我的阅读和思考。

  1. furl网摘。网摘可以看成个人的知识库。这个地址也就是我目前取代365key的地方(实际上365key完全是模仿它的,这么久了一点长进也没有,实在让人纳闷),存放我日常网络阅读的网页,我将逐步把365key上的网摘移到此处。可按主题、日期订阅或查询。这是我的furl网摘的RSS可以订阅。同时推荐一个编目精灵的furl网摘RSS,比我的更专注,更专业。
  2. delicious美味书签。网络书签实际上与网摘服务没有本质的区别,对于我来说一般用美味书签来收藏“网站”,或者英文的资料,常常是具有较大参考价值、众多网页组成的资源集合。这种区分有时也不是很严格,特别是当365key宕机的时候,不得已就乱用了。这里是我del.icio.us美味书签的RSS种子
  3. Google Reader是我每天花时间最多的信息工具,之所以用它取代bloglines主要是它的使用效率,我可以用它方便高效地看更多的帖子。它的局限也就是只能聚合RSS,传统的网站网页它无能为力。但是缺陷在信息过剩的时代似乎无所谓了。共享Google Reader的帖子非常方便,只要做一个钩选,就到了共享目录中。我的Google Reader共享链接在这里,这里是可供订阅的RSS。我觉得比较重要,但同时比较小众的东西(通常是技术性较强的东西,或者我自己一时没有时间看,而需要仔细阅读的东西)我集中在这里,或可订阅RSS。实际上Google Reader为每一个分类或者标签都可以生成一个网页和RSS,这里是我的Lib2.07标签主页RSS种子。Google的服务就是好啊就是好!
  4. 我的豆瓣上有我偶尔买的书,可以参考。豆瓣还不是一个可以作私人藏书目录的地方,提供像librarything那样的服务。国内图书馆2.0在这方面应该还有空间。
  5. 这里是偶的部分DVD收藏,实际上私人藏书目录做到这样也就够用了。
  6. 还有一些不常用、无法分享(例如Zotero)或者不便分享的服务,我就不贴在这里了。我会在博客的边栏上随时提供一些最新的动态。http://www.kevenlw.name/将是我自2004年11月以来所有网志文章的永久存放地址,多谢关注,也感谢厦大提供博客空间。

由于承受不了一些长辈、朋友过多的厚爱,有一点我需要强调一下:我在我的个人博客、网摘或使用各类网络服务中的言论和行为,有时是很率性和夸张的,仅仅代表我自己,或者以我个人的兴趣出发。我无意代表别人或者为别人指路。我愿意为我喜欢的事情奉献我的时间和精力,但我不愿承担我无法承担的责任。我想每一个有责任心的人都应该首先是一个独立的人、知道自己能力和责任边界的人。

评论(2)

如何主持一个开放的小组讨论

几个人在台前就某些主题发起讨论,听众在台下互动的“小组讨论”(Panel Discussion)是一种非常好的学术会议形式,能够在短时间内就某一主题展开深入讨论,使参与方彼此熟悉,并交换大量信息,同时还能让人感到生动、活泼、有趣、获得知识。

然而这样的小组讨论对主持人的要求比较高。国内这样开会还不太多,本人在Lib2.07上就做过一次不成功的尝试,被人BS为“艺术人生”的翻版。正好看到一个有十年经验的主持人Derek Powazek新近写了一篇博文 ,谈到他的经验,很多都是偶所犯的错误,贴出来与大家分享(骨头是DP的,内容都是我自己的,呵呵)。

  1. 做足功课。主人人自己对于所主持讨论的话题(所涉及的专业领域)必须具有足够的知识,同时对于参会者要做足功课,尽可能去了解他们(通过网络搜寻他们的简历、背景和文章,阅读他们的著作等等),必要时应该事先联系,讨论一下相关事宜。
  2. 放低身段。小组讨论不是主持人的表演舞台,而是嘉宾的交锋场所。主持人不能演错角色。即便你对某个问题很有想法,也不要越俎代庖,让嘉宾充分发表看法,甚至说出你想说的话。同时要记住你代表所有听众,或者说你是听众与嘉宾之间的桥梁,如何互动起来完全取决于你的主持。
  3. 隔绝嘉宾。这是Derek Powazek所悟出的诀窍之一。在会前不能让嘉宾就小组讨论的主题展开“会前会”,只能由你分别与嘉宾进行沟通和讨论,保证你是他们之间就某次会议论题的唯一纽带。否则正式的小组讨论很可能搞砸。
  4. 限制话题。要让听众了解选择这些嘉宾的原因,但要特别注意限制某些嘉宾无休止地介绍自己、自己的公司、项目或者观点。嘉宾通常有这种倾向,他们可以无休止地说几个小时。主持人的最大责任就是满足听众和讨论主题的需要,把时间分配给合适的人和合适的话题,并保持话题的生动有趣。当然也需要注意不要忽略或怠慢某些嘉宾,注意机会均等,不均等时要有自然的理由。
  5. 鼓励交锋。小组讨论不能变成分别的个人秀,而主要应该对话,最好是嘉宾在台上就展开交锋,主持人的作用此时就体现出来了,可以成为他们之间的缓冲剂,或者挑衅者,让相关的人充分发表意见。做足功课对这一点非常重要。有时你会发现,专家的观点有时会多么缺乏沟通而彼此误解。所以开放的小组讨论是把这些不同观点拿出来“晒一晒”的最好机会。相信不仅是听众,场上的嘉宾专家们也会获益匪浅。
  6. 变成傻子。对主持人来说,这可能比放低身段更难。好的主持人不仅要使嘉宾感到愉快、刺激或者有收获,还不能忘了代表广大听众,他们往往是更加“弱势”的一方。所以要在必要的时候打断嘉宾的谈话,提出尖锐的问题,鼓励听众参与,转述听众的“傻”问题使之更适合大多数人等。总之主持是个体力活,也是脑力活,不是为自己干的,是为别人干的,时时刻刻记住这一点就可以了。
  7. 会场设置。这一点也很重要。会场布局和设置的方式有时对会议有着致命的影响。比如小组讨论不可高高在上,最好融入到听众中间。并且不能人人一台电脑造成一堵高墙,整个会场只用一台电脑投影,牢牢掌握在主持人手里,调动整个会场的气氛,始终围绕着主持人的话题进行切换、展示。

希望国内多一些这种会议形式,不要总是千篇一律的作报告。

评论(1)

Lib2.07:厦门道无远

会议的结果在持续地发酵,我也来谈点想法。
此次参加厦门年会对本人来说可谓流年不利,诸事不顺。

先是为自己要向大家汇报什么而发愁,准备了数个选题,直到大狗最后通牒,不得不把雨僧想到的题目匆匆奉上。
临行前一天,弄到凌晨,还没有准备好。
于是出门时换错了老伴准备的裤子。
到了机场,竟然发现没带钱包和身份证。
只好让家人送到机场。最后一刻受上天眷顾,还算有惊无险。
喜洋洋地参加游园20日晚的招待酒会,却错过了大狗召集的会前会。
直接导致后来一系列的不当安排:如博客PK阶段的主持人竟然不是金话筒超平先生,而阴差阳错,摊上了我。
晚上ppt准备大半,突然死机,抢回了部分,不得不重做。
第二天蓬头垢面,睡眼惺忪,形神恍惚地读完ppt。让自己和大家都不知所云。
随后一天都沉浸在新朋故友见面的兴奋中,直到晚上。
发现不对,第二天的日程安排,有的人根本没到会,有的人根本没准备,有的人还打招呼要开溜!
人员和议题准备上的不足,使第二天的日程无法按计划进行。
于是第二天的主持,完全是脚踩西瓜皮。

这里只好向大家说抱歉了!

会上有人说除了Lib2.0,说得最多的词就是Keven。
偶已经听不出是恭维还是讽刺。
好在经过多年的磨练,脸皮是足够用的。
曾经想过,我们开一个2.0的unconference 或者camping。
即:

适客参会(Whoever comes is the right people),
适事发生(Whatever happens is the only thing that could have),
适时而启(Whenever it starts is the right time)
适机而止(When it’s over, it’s over)。
(左之兄翻译)

大狗似乎也是这样准备的。
不过我们图林人士开惯了传统的会议。
还不习惯conference2.0。

好好想一想:这是“你”的会。
你所希望的,就是你所给予的。
只想着别人奉献,自己索取。
甚至为没有得到而抱怨,
符合2.0精神吗?

photo by 图有其表

评论(1)

Lib2.07:厦门夜未央

厦大是一颗火种,可能点燃国内图书馆2.0的燎原之火,也可能在鼓浪涛声之中,“哧”地一声,一阵雾气,湮灭了,涛声依旧。 厦大在许多前往朝拜的图林人心中,更像一朵娇嫩的花朵,看着她在一个恶劣的业态中,不真实地盛开,小心地呵护着,生怕某一天早上醒来,看到她已经凋谢。

在这背后,萧馆当然是灵魂和护花使者。在一个等级、资历森严的行业有意无意地实践扁平化管理,在铁罐般大环境中经营着小小的苗圃花房,也算是异数了。可能 萧馆并没有表现出劳累或疲惫,可能是率真的天性使然。然而苗圃中的滋养雨露毕竟有限,小草也总有长大的一天。为什么不能有一片开阔的天空,让花朵恣意地盛 开?

图书馆曾经与衙门无异,即便是广厦摩天琼楼玉宇,也束缚着许多年轻的心灵。知识终究是自由的种子,总能飘到适宜的土壤,或穿破脚下的顽石,怎可能一直受到压抑!?

蛙鸣虫啾的夜晚,我们几乎是彻夜地探究,怎样做一堆薪柴,保住这点点篝火。2.0进行到底,巴别塔并非虚无。

photo by 图有其表

评论(8)

Lib2.07:厦门胡不归

已经开完了,不知道该写些什么。宣布与会议要保持距离的老槐在那边一发而不可收,接连7篇报道,实在没有更多的可写了。

从参与前期的“协办”,到开会的两天,更多的担心并不是如何开好这个会,以厦大的实力以及大家的参与热情,开好这次会议,确保正确的思想路线、政治路线和 组织路线,绝对是没有问题的。我想得更多的,是业界沉默的大多数,他们在想些什么?做些什么?如何评价?为什么不参与、为什么不能参与?正像老槐、超平以 及曾蕾所思所虑的,这是草根的会议,这个会议什么时候忘记草根,成了一个小圈子,这个会议也就走到尽头了。李国新教授提议年会期间举办一个 Web/Lib2.0分会场,我也曾想在年会期间举办相关主题的Tutorial,曾蕾老师也觉得宣传推广普及工作很重要,然而经业内资深人士提醒,年会 实际上是一个大party呀,与这种气氛是不兼容的。

这届会议的成功,可能给下届的主办方浙大信管系带来很大压力,我看到超平师忧心忡忡。但是我也看到叶帅自信的眼神,听到他爽朗的笑声,我看到老槐的宽胸厚 背,看到大家热情的笑脸,我想,我们并不在乎会议的豪华,设施的先进,技术的炫目,我们在乎参与,在乎是否有进展,在乎来自基层的声音,在乎大家是否开心,以及是否能把这种开心转达给读者,从而使我们的行业慢慢地2.0起来。

(于厦门白鹭洲 Reading Coffee)

评论(4)

博客蓝不错

最近工作需要,调查情报新进展,而且准备Lib2.07参会,整理一些2.0的东东,乱七八糟,没空更新博客。

突然发现博客蓝有个功能,解决我大半年来一直想解决的问题,很高兴。许多“狡兔三窟”的博主们肯定有与我同样的需求,在此共享给大家。

博客蓝的“博客搬家”功能比博客大巴要好多了。当初想学编目精灵,把bokee上的东西搬到blogbus上,照他们说的做了,输出了xml文档,却怎么也导不进去。写信给大巴,反应迟缓,最后说我不是付费用户,不给帮忙。NND,气得半死。

把搬家功能在博客蓝中设好,不仅搬bokee,还搬donews.net,(还想搬wordpress.com,无奈被屏蔽,无法访问,设了donews.com,却不知为什么到现在还不成功), 第二天早上打开,哇!已经都在那里了,日期什么都不变,就像你是它的老顾客一样。(博客蓝也够损的,不知道算不算不正当竞争。)

不过俺就管不了那么多了,搬到博客蓝反正也不想长久居住,虽然它没有很方便的输出功能(除了RSS输出),偶仍然可以用Zoundry把它全部备份出来,然后灌入到我的博客大本营中。

于是,实现了我的夙愿:可以带着所有的文章,到处流浪了。

最近donews.com很不稳定,访问速度也越来越慢。正在考虑,把xmulib.net/keven/作为我的主站。给厦大添麻烦了,在这里说声谢谢!

Powered by ScribeFire.

评论(4)

基于WEB2.0社会性软件的图书馆信息服务

更新:把西北图客的初次留言和第二次回复都放在这里。

keven老师:您好
经常阅读您的文章,深受启发,大开视野。
在此表示感谢。
我想请教您一个问题,“基于WEB2.0社会性软件的图书馆信息服务”如果要写,您觉从哪些方面写可能会有的创新。
谢谢

西北图客,您好!

看来你也是个“技术酒徒”,为什么要基于“软件”的信息服务呢?为什么不是基于信息服务的软件呢?你的留言很简短,不知道你对这两个概念的定义,而作为“论文”,概念界定是很重要的,感谢你的信任,在这里也不想打官腔、说废话,我就按照我的理解随便谈谈吧。

社会性软件是Web2.0的一个特征,或者一类基本应用。2.0在本质上是去中心化、消灭中介的,谁要想做信息中介,它就要消灭谁,同时又有无数个中介不 断冒出来,互相掐,谁掐死了别人,谁的商务模式就得到了认可,就成了大腕。所以图书馆信息服务在其中首先要定位准确,它只不过是其中的一类中介而已,在很 多方面不具有优势,在很多方面又具有很多优势,但千万不要以为什么都能做,一下子就拯救了图书馆,或者带来全新的东西。我对“图书馆学”论文爱赶时髦是很 反感的,但创新有时也是一种赶时髦,创新与赶时髦的区别在于有没有批判精神和科学态度。

图书馆信息服务用社会性软件,最大的好处是改变图书馆的大众认知,把图书馆与硬邦邦的“图书”的捆绑,扩大到与“服务”捆绑,与“图书馆员”捆绑,与“信 息”、“知识”捆绑,与人性化的界面捆绑,与“人与人”建立联系捆绑。使图书馆成为虚拟空间中的一种交往方式,成为千禧一代的生活必需。当然图书馆应不应 该这么做?业界(特别是国内的业界)似乎有很多争论,不一定所有的馆长都同意这么做,不一定所有的图书馆都能够这么做。

图书馆信息服务如何应用社会性软件?现成的案例还太少,不足以写论文总结,只能进行思想试验,写些理念层面的东西,但太多理念恐怕已经没有杂志愿意刊登 了。我们在审阅《图书馆杂志》的投稿中,非常青睐那些经过实践,甚至仅仅是进行过一些试验的东西,文字粗糙一些、思想拙朴一些都不要紧,而非常讨厌那些仅 仅是看了一点国外资料就匆匆成文,甚至只是翻译的东西。

如果你认为所有的社会性软件都可以应用到图书馆网站,我也没有话说,但如果要写论文,恐怕还是写一点能够紧密结合图书馆业务的软件,Social OPAC(包括WPOPAC)可以算一个。这确实是一类很好的应用,应用中可以反映出很多问题,可以进行很好的总结。豆瓣之类的应用如果能在图书馆实现, 应该也是差不多的东西。但这些软件在图书馆的具体应用或实验还凤毛麟角,如果没有应用,能写些什么呢?

技术倒是唯一可以写写的东西,目前情况介绍,如何应用,怎样应用,等等,还是有价值的。但前提是要具体用过,进行一些比较,与传统图书馆管理系统结合起来。技术是个日新月异的东西,抓住一些本质,上升到一定的高度来谈,论文才更有价值。太微观也容易被枪毙。

仅仅是一些个人想法,仅供参考。

希望尽快成文,并欢迎向《图书馆杂志》投稿。

以下是“西北图客”的回复,看问题有相当深度,看来写这个题目并非仅仅为发文。

Keven老师,您好!

先也是衷心感谢您在百忙中的回复。

对于社会性软件与web2.0进行界定的确有点困难,原因或在于这两个事物过于复杂,且内涵与形式在不断地丰富与发展。以社会性软件的英文称谓而 言,就有Social software、 social network 、software social networking software and service等诸多称谓,当然国内外应用更多是Social software,这其中也指称三个不同的层次对象:工具层次、媒介层次和生态学层次。对于图书馆的信息服务而言,究竟以哪个层次为主,或者说哪几个层次 及其有机组合却是个未知数。我个人认为,可能应更多的考虑生态学层次,将读者、工作人员、图书馆内部的业务活动与外部的信息服务活动、志趣、各种目标有机 整合成无缝高度耦合的人机系统。进一步而言,也有社会性软件工具与社会性软件系统区别的探讨。同时,Social software这种称谓容易让人感到困惑,是不是以social networking software的表达更准确一些,当然中文的翻译仍然可以“社会性软件”来担当。同样的问题也存在于web2.0,从不同角度考量的话则有不同的理解, 如技术、信息系统、经济学等层面。但无论如何,对于图书馆的信息服务而言,则应运用web2.0核心技术“共享、重组、再造”新的图书馆信息服务系统,如 您所说的豆瓣、Social OPAC,当然也可以包括Ning这样的东东。

会性软件在国内图书馆信息服务中的应用确是不容乐观。最近我做了个网络调查,目前国内仅有14家之多的图书馆在其网站上提供了有限的也是最基本的如图书 馆动态信息、新书通报、商业数据库的RSS链接等的频道订阅功能,而基于关键词的学术网络信息、与web2.0网站的合作、与出版机构新华书店等相关部门 的合用等却凤毛麟角,几乎空白。当然的确也存在一些困难对于图书馆而言,如理念、技术、人才等。社会性软件不是十全十美的,有优势也有缺陷,并不是图书馆 的“救世主”,但社会性软件对图书馆的功用有点类似于数字图书馆对于传统的图书馆,关键在于如何有机的整合,合理的运用。

会性软件对于图书馆来说,可能运用于图书馆网站仅是表面上的文章,正如您所说,如果能够将社会性的软件与图书馆的业务有机结合,则是社会性软件在图书馆 应用的延伸,而这种应用恐怕对传统的业务流程要重新洗牌。当然这是“技术酒徒”辈所期望的,但未必是图书馆界所希望的。

技术的日新月异给我们带来了多元化的选择与便利,但如果不能有效的抓住其本质,则会使我们陷入技术的泥潭而不能自拔,更不用说“技术酒徒”了,因为当我们自己的理论还未成熟时,我们所崇拜的技术已经凋谢了。

后再次感谢Keven老师,不当之处敬请指正。同时我会尽快成文,以不负您的厚望。

西北图客
4/8/2007

评论(6)

也谈如何让MARC安乐死

耄耋少年陈老师在博客中谈及”如何使MARC安乐死“,图情散记在前些日子也论述了”后MARC时代图书馆信息服务的设想“,都提出了一些很好的想法,我这里也想提一点自己的看法,求教于大家。

1、想以一种新的MARC取代旧的MARC是不现实和不足取的,也是不可能的*;
2、在分布式异构环境(说白了即因特网环境)下,多种元数据方式并存是必然的和必需的;
3、元数据方案的标准化并非必需,除非需要与外界进行数据交换或共享(即互操作);
4、MARC只有在所有系统都支持,但又不依赖时才能死的安乐,死得其所;
5、使多种元数据方式在同一系统中并存的解决方案有很多,建立描述对象的属性关系模型是最基本和最可靠的,这个模型实际上是作为一种本体提供服务;
6、元数据方案的标准化不仅仅是属性元素集的标准化,也包括语法和结构的标准化,但更重要的是描述模型的标准化;
7、标准化并非是刚性的、绝对的,可以有不同级别和层次;
8、DC元数据早已不是仅仅包含一套描述元素(更不是15个)的方案,而是一套规范体系,其“应用纲要(Application)”和“抽象模型”的意义远大于元数据核心集合;
9、未来的MARC将是一套元数据描述从语义到语法结构到模型及著录规范和算法的完整体系,这套体系是固化在网络应用的人机界面中,无需用户和任何非专业人士掌握和直接面对的。

*当然,作为一种“图书馆书目”领域应用而言,目前可以作为MARC的替代有很多, 例如MARCXML,MODS等,这些标准可以作为很好的过渡,难以创造MARC昔日的辉煌。将来的ILS系统采用哪一种标准作为替代,目前还看不出来,可能要等RDA来下结论吧,也可能永远没有结论,维持一段战国纷争的时代。眼下最关键的问题,还是解决多标准互融的框架结构和模型的一致性和规范化问题。这个问题有共识了,领域标准让大家自己制定,在应用中形成,多几个都无所谓。

Powered by ScribeFire.

评论(1)

Mashup和Meshup

照我看来,RSS从1.0到2.0,是一个不可饶恕的、极大的倒退。当然这两个东西不是一个东西,完全是不同团体(是不是利益团体不知道)开发的用于同一目的的不同标准。采用混淆视听的手法,满足于一时的简单,而贻患无穷。

Kingsley Idehen在最近的一个帖子里解释了Mashup与Meshup的不同:

Mashups - 粗暴地联结不同来源的数据(Brute force joining of disparate Web Data。我的理解:不考虑被联结方的Meaning。因为没有任何属性描述,也无从查考)
Meshups - 自然地联结不同来源的数据(Natural joining of disparate Web Data )

也就是说,前者是革命婚姻,后者是自由恋爱;前者也可能碰到好人,而后者才是和谐社会的基础。

根源就在于RSS2.0的数据只比HTML多了一个数型结构的描述,链接关系的描述并不是基于语义的(不支持RDF),数据类型不具有自说明性,因而不同应用的数据进行集成(互操作)就存在很大的不确定性,没有人工的参与很难判别数据是否一致,从原理上使得数据集成的自动化成为不可能。

目前有不少2.0开放应用已经事实上支持Meshup了。即:一部分采用了RDF进行数据描述的应用,在进行Mashup时,实际上是在进行Meshup(Meshup子集于Mashup)。例如Googlebase以及Yahoo的一些应用,它们也输出RSS2.0,但却是规范的、支持RDF的RSS2.0,因为他们内部数据是支持RDF的。

Kinsley说:

I can achieve this in minutes without writing a single line of code. I
can do it because of the Data Model prowess of RDF (self-describing
instance-data), the data interchange and transformation power of XML
and XSLT respectively, the inherent power of XML based Web Services
(REST or SOAP), and of course, having a Hybrid Server product like Virtuoso at my disposal that delivers a cross platform solution for exploiting all of these standards coherently.

他还举了两个例子:

  1. Googlebase Query URL as an RDF Data Source
  2. Perform a simple Data Mesh by adding (via link copy and paste) this Upcoming.org Query Services URL for Ajax Events to the RDF Browsers list of Data Sources (paste into the Data Source URI input field).

介绍这些对我们数字图书馆建设有什么意义呢?实际上意义特别重大。与这些襁褓中的语义技术相比,目前的资源整合技术,包括跨库检索、开放链接、门户整合、单点登录等等所采用的具体做法,从总体上而言都是权宜之计,说句不好听的:都是要被淘汰的。对于RDF数据的支持将最终使互联网发生天翻地覆的变化。

语义Web现在非正式地给自己贴了个标签叫Web3.0,也就是Data Web (作为语义Web的第一层:数据层,往上还有描述层、推理层等),虽然有些滑稽与无奈,至少说明语义Web运动走出书斋和实验室,开始注重参与具体应用了。这也是2.0带来的混乱之后的醒悟吧。现在仍有许多人不相信语义Web的理想能够实现,但是我始终认为语义Web,也就是Data Web,与数字图书馆的理想是一致的,但愿Web2.0的发展能够顺利,并且尽快地过渡到3.0。

Powered by ScribeFire.

评论(1)

Cnlib20@Ning的一些情况

除了汉化碰到一些困难,“中文’图书馆2.0′论坛”网站的建设工作基本告一段落。目前已经把去年Info20会议的视频、雨僧访沪的部分视频以及近200张包含许多图林博客照片已经上载。更多的内容陆续增添中……

我们建立这个论坛的目的主要有两个:

1、配合4月21-22日在厦门大学召开的Lib2.07会议
2、作为一个中文“图书馆2.0”交流的基地,聚集一些资源。

感谢大家的积极参与。自3月2日网站设立以来,已经有31名成员接受了邀请或主动加入,已经有七千余次的访问量(有意思的是:基本都是由成员自己带来的访问量),在Ning的社会性网站中也算不错了。我一直很纳闷像 Myspace,Facebook之类的社会性网站(SN: Social Network)为什么会那么受欢迎,建了这个网站才知道,这的确是一个把大家联系起来的好方法!相比而言,SN比Wiki功能更多一些,特别是能够支持功能或数据融合(mashup)是其很好的特点(但据说Myspace已经开始block mashup了),而Ning作为Meta SN(元社会性网络)比其它花哨的SN平台多许多个性化设置功能,因此可以做得更个性化和更实用些,特别能够符合一些学术交流社区的需要。

下一步我希望利用这个平台为大家提供更多的资源,特别是同样在Ning上的一个更大的Library2.0社区,有很多英文资源。另外我希望利用Yahoo!Pipes网络图林有关图书馆2.0的帖子都聚合过来,这样就不需要许多朋友博文发两次了。目前如何组织这些资源也是一个很大的挑战。如果这种SN平台能够与DSpace/Fedora等CM平台结合,就更好了。

Cnlib20是一个参与的平台,图书馆2.0需要您的参与!

cnlib20atning

keven上传于Yupoo.

留言

雨师,新年好!

时钟刚过12点,外面的爆竹声震耳欲聋,已经是大年初一了。我知道再过几小时,雨师将离开南京,取道香港,返回南半球,那个数年前他自主选择的自由之地。

我不知道这个中国的新年对于雨僧这样的新移民来说,是意义更大了,还是越来越淡漠了。这几天,我们将延续一场又一场过年的饕餮盛宴,然而就是在这一场场简单的杯觥交错中,雨师也注定是要永久地缺席了。

他甘心缺席吗?看来不。否则怎么会在这短短的、匆匆的返国旅途中,在春运的高潮中,夹杂在南来北往的白领与民工之间,与满车厢的物欲和乡情是那么地格格不入,匆匆地奔赴上海,莫名其妙地见几个不伦不类的“博客”?

我知道他这次突然回国是为了探望他再次病重的母亲,他和他的家人都很担心,谁都不希望,这可能是最后一次。

我不想占用他更多的时间,但是我知道促成这次雨师来访的,完全是他想看一看这个“网络图林”,而并不是我的邀请。老槐说我是技术救图的数图理想主义者,河边是理念救图的现实批判主义者,而依我看雨师才是个原教旨的理想主义者。真正的理想主义者常常是充满悲情的战士,他不是白求恩,不是雷锋,他们都能够以实践自己的理想作为满足,而雨师关注的事情,是成、是败,是好、是坏,都跟他自己无关。

我突然很想对雨师说一句“新年好”,尽管这个新年他可能越来越淡漠了。而且他看到的时候可能也早已不是新年了。

外一篇:雨师,再见!

人流中雨师匆匆绕过栏杆。我赶忙递过小包,来不及叮嘱几句,就见黄牛紧紧跟上,将车票塞给他。我远远地站在栏杆的入口,看到雨师经过检票口,以及黄牛在接到百元大钞之后露出的笑容。然后雨师的形象就定格在软席候车室玻璃门折射与反射混合的模糊影像中了。

花生壳一直在为没有给雨师买上车票而念叨着,编目精灵也在博客中惦念,而在录制播客的整个上午雨师一点不担心,中午河边盛情招待的午宴中也一点不着急,只是在下午我陪同游览新天地时略显行色匆匆,因为晚上还要参加同学特地为他而准备的聚会。他说同学们几乎每年都要聚会,而他已经有几年没有参加了。

车票是肯定买不到的,而雨师肯定他一定能走成。

到处都是黑压压的滞留人群。雨师让我看着行李,他去售票处看看。只见每个窗口前人潮涌动,让人确信,想买到票已经不能单靠有钱了,还要有奇迹。我对奇迹从来不做幻想,正愧疚中,见雨师带着一个人过来,说:“走!”让我简直以为这个黄牛就是专门安排来跟雨师接头的。

于是出现了前述的一幕。

于是结束了雨师的上海之行。

不知道是性格成就事业还是环境造就性格,雨师已完全是西方的作派了。说来就来了,连个电话、车次都不曾告知,来了之后才知道前一天晚上就到了。雨师坚持所有的费用一概自己支付,坚持得近乎固执。本想第二天早点结束,带雨师在上海引以为荣的景点参观一下,然而等我们吃过午饭,已近下午两点,只有在去火车站“路过”新天地时下来拍了几张照片。留下很多遗憾。

不知道下一次雨师回来,会在何时?

评论(6)

不羁的种子

“你的博客每天大约有多少人访问?”王书记一次突然问我。
“我们现有几个RSS有多少人订阅?”缪馆长在一次会上问技术部门的负责人。

对这些问题,我们只能回答个大概。伴随草根主宰世界时代的到来,内容提供者似乎越来越难以控制自己信息的流向,播下的种子(Feed)会像蒲公英一样飘向四方,并繁衍子孙。RSS被 Feedburner、Bloglines、Greader、Feedsky、Gougou、蚂蚁、抓虾……等等数十个服务网站串烧、聚合,被各类搜索引擎的爬虫骚扰,提供丰富多彩的订阅方法和阅读体验。你的网站每天可能只有200多次点击,但feedburner有300多次访问, bloglines上有100多个固定订阅……难怪Pageview正走向死亡。
RSS是个不受约束的孩子,一出世就由不得爹娘,所以才有这么多的表叔,这么多的寄养的家。后生的孩子如微软的SSE(Simple Sharing Extension)等,增加了回馈机制,就只能做个乖乖女了。

如果你想知道你的读者,只有当他通过bloglines、抓虾、gougou等聚合器订阅,且他愿意让你知道的时候才有可能。并且你只能通过枚举归纳,把所有可能的RSS和RSS服务都加起来,才能算个大概。图谋已经为网络图林进行了好几次的普查了,但都很不完整。

因此这是一个信息的流动完全不同于传统的时代,信息流程中的各类游戏者都需要确立新的角色。

librsskeven上传于Yupoo.)

这幅图是台东大学RSS应用全图,可以看到,小小的RSS并不简单,解决方案也不能只靠一种。务实的台湾同行们已经扎扎实实地做了起来,我们呢?
(前不久台湾淡江大学召开的Web2.0与图书馆 研讨会,还有许多看点,特别是林泰宏先生的两个报告。)

评论(2)

思考:资源按时空呈现

在思考上海年华图片库的呈现方式时曾经考察过一些新技术,希望探索一些开放的(2.0的)解决方案。

大量的信息资源(例如图片库)都需要标注地理信息,关于地理信息的管理一直是数字图书馆技术的热点,随着Google earth、Yahoo map等应用的成熟该技术已经走向开放、标准和实用(例如Flickr已经开始支持地理位置标注,以及图片按照地图呈现)。当然距离最重要的需求:“简单”,似乎尚有距离。
“简单”的含义是,只要标注有一定的地理/空间信息,系统就能自动提供多种呈现方式。另一方面,对于地理信息的标注或者获取,也需要有系统(平台)或工具(如通过相应微格式的havesting)的支持,并且足够简单。

据说MySQL4.1以后有一个Spetial Extension,能够在关系数据库里管理地理信息。了解了一下,大致有以下功能:

1、数据类型扩展。支持GIS数据,例如用POINT表示二维信息(dc:point; dc:box; etc.);
2、特殊操作。例如可以支持封闭图形的面积计算;
3、GIS数据的输入输出;
4、对GIS数据进行索引,以便快速查找、排序等。

不知道MySQL的这个扩展是如何实现这些功能的。只是觉得依靠关系数据库恐怕会有点问题,特别是对于目前大多数网络应用都希望以XML方式管理数据的情况下,局限性就不多说了,不必要的输入输出转换会带来效率、兼容性、互操作方面的很多问题。

目前语义Web领域对信息以时间和空间方式的呈现和管理有许多项目在做,例如SIMILESWAD-Europe 等,前者已经开发出一个很好的开放的Timeline表示方法。将来对于空间/时间信息也希望以RDF标注并能采用SPARQL查询。

有趣的是这些语义技术往往在Blog或Wiki获得最先应用:通过PHP插件或扩展的形式。可能因为这个领域最为活跃,有一批TechSavvy吧。当然这些应用可以“试错”也是一个重要原因,永远的beta版,错了也没什么关系,改了就是。

所以我们的博客、Wiki应用如果在创建内容的时候能够支持标准格式,将给搜索引擎或其他应用揭示、共享带来很大的准确性和便利性。例如我们在描述自己的时候利用博客工具提供的表格输入,就能够建立hcard或foaf数据,我们在增加链接时添加了链接者与本人的关系描述,就增加了XFN格式的社会关系描述(wordpress有这个功能)等等。目前许多个人知识管理/共享系统(例如Piggybank)就是通过内容的格式化标注和发现,建立知识库的。

参考例子:

geobloggers.com
mapufacture.com
Google Earth

用中文点亮地球


评论(2)

元数据应用平台的开发需求

华为的朋友在我的博客上留言,要开发一个元数据应用系统,关于互联网或者电信网内容(资源)管理:

内容包括文本,图片,音视频,多媒体等网络资源。
期望通过对内容进行结构化的描述,例如元数据,然后发布,实现对内容或者资源进行检索,依据内容之间的相关性进行聚合,以及统一的访问机制等.

目前大致的思路是,先基于RDF/DC元数据等技术,建立一个简单的资源管理与控制平台,把资源(应该是由URI所确定的)按照某些元信息或是简单的标签进行描述,然后注册在某个地方,然后以此为基础研究对资源的聚类,搜索,资源之间的关联,Web服务对资源的调用访问,资源与服务的匹配关系等等。

对这样一个系统,希望大家出出主意。

首先明确需求如下:

1、资源对象:来自网络(提供URI);
2、资源类型:任意(文本、图片、音视频等);
3、资源描述:规范的元数据(如DC),以RDF编码;
4、应用需求:搜索、聚类、关联;
5、访问方式:开放,支持Web服务。

我们参考原型法来考虑问题:满足上述需求的应用,应该有两类现有应用可作参考:

资源导航门户:

1、资源对象:各类网站、网页(可通过URL链接);
2、资源类型:网页,可能会有pdf等文件;
3、资源描述:专业人员加工的元数据(很多应用了DC,但不一定以RDF编码);
4、应用需求:提供搜索、浏览功能,以及人工的分类(聚类)、(主题)关联;
5、访问方式:开放访问,但不一定支持Web服务,但有这种趋势,例如可能支持SRU/W的REST访问等。

个人知识管理(网摘)系统(如365key、Zotero、PiggyBank等):

1、资源对象:网页或网上的任何资源(提供URL或能够被一定服务解析的DOI/OpenURL等);
2、资源类型:任意(文本、图片、音视频等);
3、资源描述:任何规范的元数据(如DC、微格式)或不规范的元数据(如Tag),以XML/RDF或自定义形式编码;
4、应用需求:标注annotation、存档(在线或离线)、搜索、获取、聚类(多种算法、相关反馈或纯粹人工)、关联(规范控制);
5、访问方式:本地、圈内(可定义)、开放,支持或不支持开放API,提供或不提供基于标准或非标准的Web服务。

针对您的需求描述需要进一步澄清的问题:

1、您需要上述哪些功能?
2、您需要开发的是应用型系统(上述第一种为主)还是工具型系统(上述第二种),或者在开发应用的同时开发一些工具?
3、您的系统开发工具和运行平台怎样考虑?纯开源还是商业应用?纯网络实现(Ajax)还是可以有C/S参与?
4、您希望支持各类“标准”,支持到什么程度?(例如元数据格式的类型——包括数据存储和交换的考虑、流程的耦合程度——即各模块的封装程度、服务标准的支持——如何注册、搜寻、发布服务等)

留言

2007:Keven因你而变

自从毛军建议我写《从Web 2.0到图书馆2.0:服务因用户而变》(现代图书情报技术2006/9),就让我感到,生活将由此不同。

果然,虽然2006总评不及格 ,但却成就了我的2.0元年。许多围绕Web2.0图书馆2.0的演讲、报告,Info2.0会议,以及自己涉猎的诸多领域无不打上了2.0的印记。大狗那边给第二届《Web2.0与信息服务》确定的主题也是“服务:因你而变”。好吧,2007,keven也因你而变。

2.0最大的价值在于一下子拉近了从理论到技术、从技术到应用的距离,在降低技术门槛的同时,加速了各种技术受实践检验的进程。人们呼唤杀手级应用,然而草根应用如雨后春笋,任何东西都在竞争中受到考验,物竞天择再次成为规律。不随需而变,就没有出路。

因此,我也就不做什么新年计划,只有给自己的新年寄语。以下的一些事情,诚邀“你”的参与,一切将因“你”而变。

1、进入“博客时代”的网络图林,仍然需要一支不断壮大的博客队伍。只有普及才体现草根性,只有每个个人主体意识的觉醒才有整个事业和整体学科的繁荣,才能克服陈腐的精英意识。在网络图林我们要倡导老槐竹帛斋(以及雨僧)的那种批判精神,以“网络图学”的学风抵御六大弊端
2、理论创见不是一朝一夕的事情,特别是还不知道有没有这种理论、需不需要某种创见的时候。无论如何,当前的图书情报领域迫切需要国际化眼光、跨学科视角和IT应用素材,传统的理论需要继承,但不能成为包袱,也不应成为阻碍创新的籍口。
3、Lib20′07数图大会是07年我最为关注的两场国内盛会,同时也将有机会参加DC-2007IFLA’07。躬逢盛世,不容虚度。
4、图书馆2.0必 须尽快由空谈转为实践。借助国内外数次2.0会议成果,可以对几个方面的应用进行一些总结。首先希望能够利用本馆的资源,跨部门合作,进行一些探索。某些 项目也不可能以一馆或一己之力而为之,应可以以2.0形式建立虚拟小组(Working Group或Task force),或招募并培训“志愿者”,或进行“泛地区”合作。
5、本人将致力于全面考察并试验开源软件在Lib2.0的应用,以打通元数据(及本体)应用从方案到实施的全过程为重点,选择适当开发环境和工具,提供一定的范例。同时将积极参与厦大图情百科的工作。

评论(10)

2006年总评:不及格

2006是我的2.0元年,这一年绝大多数与”学术”或”研究”相关的事情,基本上都是关于2.0,这在我的”新年愿望“中是始料未及的。

花生壳早早总结了”新年愿望”的执行情况 ,大致给自己打了60分。我可能连勉强及格都算不上。但对于去年的五项愿望,也得硬着头皮交待一下:

1、煽动图林博客起来。虽然与偶的努力没多大关系,但见网络图林之火已成燎原之势,熊熊燃烧,也很欣慰。这其中竹帛斋主功不可没,景仰一个!
2、数图”统一场”论取得阶段性进展。没有完成。2.0技术和应用的蓬勃发展缩短了从理论到应用的时间,也对单一的理想化的框架提出了挑战,框架是否可行有赖于符合趋势的切实应用。本想在06年内将基于博士论文的两篇论文修改完善之后投给两个学报,以弥补本人投稿的空白,然而完善还有很多工作要做。计划近期完成一稿投了再说,供大家批评指正。
3、“上海年华”项目 。尽力了,但自己不满意。跨部门项目管理一直是大型机构难以解决的问题,年内”上海年华”项目在管理体制上有了重大改变,”落地”到具体的业务部门,对于”总体组”的职能要求有所降低,本人将继续做好咨询和参谋工作。
4、信息资源组织方面的专著。与2相同的理由,没有完成。目前从本学科角度看待信息资源组织已经有多本教材和专著了,而跳出图情领域,将信息技术所带来的诸多变化上升到哲学层面,反过来审视”泛”资源(把参与活动的”人”也作为一种资源)的组织,同时对于”泛”资源组织所涉及的各类技术进行考察,明辨方向。循着这个思路还需要做大量的工作,不是一年两年所能完成的。所以去年的这项”愿望”未免太过于雄心勃勃,当时也是为了激励自己吧。
5、减肥计划。勉强及格吧。添置了一台跑步机,也偶尔跑上半个小时,感觉体力比以前好,但由于LD(领导)并没有规定具体减肥指标,自己也就瞒天过海,找点借口得过且过啦。

2006年评语:各方面工作取得一定进展,同时,各方面工作有待进一步提高。总之:不及格。

评论(8)

年度汉字:断

Bloglines总算好了,好的还算比较彻底。游园应该可以恢复工作了。
MSN朋友们都能上去,而我却还不行。不过我还有gtalk。可惜中国电信似乎只有一家,Keso在那里提醒大家:对于只有一个电信的中国,世界依然是不可能平的。
4.11让我们警醒,算人祸,12.26谁都没有责任,只是天灾而已吗?
断网并不要命,断头就是大事了,其中折射出的思考,恐怕在历史上都可以记一笔。
所以,我的年度汉字:断。

powered by performancing firefox

评论(5)

“数字图书馆”专业应该学什么?

思考:如果有“数字图书馆”专业,应该学些什么?

  • 数字图书馆概论/原理?(教材:《数字图书馆概论》或其它,参考课件:数字图书馆)
  • 知识组织(参考资料:Sowa的知识表示)与元数据和本体(参考课件:知识组织与元数据
  • 内容管理(结合OSS?)
  • OSS:Greenstone/Dspace/Fedora/Eprint etc.
  • 数字图书馆评价、用户研究
  • 信息构建?(包括信息检索信息组织、信息系统可用性、可视化等相关内容)
  • 传统的ILS与Web2.0相关技术(Open API、Mashup tech).等
  • 信息资源的长期保存
  • 知识产权与文化环境(数字阅读etc.)
  • 其它数字图书馆相关技术以及一般的数据库技术、软件工程、人工智能等等
    • Web技术
    • OOA/OOD
    • SemanticWeb(RDF/OWL)
    • 网格/语义网格(参考资料:网格计算
    • WebServices/SOA
    • HCI
    • Jena
    • RoR
    • LAMP(XAMPP))

        欢迎添加。

    评论(12)

    « Previous entries