<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>图林中文译站 &#187; 图情技术</title>
	<atom:link href="http://www.libspace.org/category/libtech/feed" rel="self" type="application/rss+xml" />
	<link>http://www.libspace.org</link>
	<description>架信息之桥 谋图林之善</description>
	<lastBuildDate>Mon, 28 Jun 2010 07:35:09 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
		<item>
		<title>Thinking about Open Source</title>
		<link>http://www.libspace.org/archives/thinking-about-open-source.html</link>
		<comments>http://www.libspace.org/archives/thinking-about-open-source.html#comments</comments>
		<pubDate>Mon, 28 Jun 2010 07:35:09 +0000</pubDate>
		<dc:creator>tsingove</dc:creator>
				<category><![CDATA[图情技术]]></category>
		<category><![CDATA[Open Source]]></category>
		<category><![CDATA[开源软件]]></category>

		<guid isPermaLink="false">http://www.libspace.org/?p=404</guid>
		<description><![CDATA[Thinking about Open Source
作者：K.G. Schneider
这周一中午的1:30-3:30，我会在WCC-146B参加了另一次终极辩论：“开源软件——免费的啤酒还是免费的小狗？” Marshall Breeding和Stephen Abram会参加辩论， Roy Tennant会担任主持。它有一个标签#ultdebate，甚至于JohnBerry也会来参加。
(Sidebar: Berry, how is it that four years is “enough” for our debate when you’ve been writing that column for hmmmm… how long? But no matter…)
这个辩论可能会极端无聊，也可能会特别有趣。当主办方邀请我参加这个活动的时候，我刚刚在我新的工作（大学图书馆员）上干了一年多，之前我在一家开源软件的开发和维护公司工作。那时候，Stephen Abram也正要离开他在Sirsi-Dynix风光无限的工作，接手Gale的一个新职位。
I suspect some people expect me to renounce open source (get thee away, open code!), and others expect me to doggedly embrace it no matter what, like those annoying Apple cultics who would devour arsenic if it arrived in a rounded white plastic container with that familiar fruit emblazoned on its bottlecap.
我怀疑有些人期待我谴责开源（开放代码，滚吧！），其他人则期待我固执的拥护它，不管发生什么，就像那些讨厌的苹果拥护者一样——他们也会吃掉砒霜，只要砒霜装在一个白色塑料的圆盒里送到他们这，盒子盖上画着他们熟悉的那个水果标志。
At MPOW, I’ve been ...]]></description>
		<wfw:commentRss>http://www.libspace.org/archives/thinking-about-open-source.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>开放云计算宣言</title>
		<link>http://www.libspace.org/archives/opencloudmanifesto.html</link>
		<comments>http://www.libspace.org/archives/opencloudmanifesto.html#comments</comments>
		<pubDate>Mon, 08 Jun 2009 10:19:04 +0000</pubDate>
		<dc:creator>tsingove</dc:creator>
				<category><![CDATA[图情技术]]></category>
		<category><![CDATA[云计算]]></category>

		<guid isPermaLink="false">http://www.libspace.org/?p=249</guid>
		<description><![CDATA[（译者按：曾几何时，图林多慷慨激昂之士，为生民立命，为天地立心。余浸淫日久，染其恶疾，一见宣言就呆立不动。粗略翻译如下）
原文参见此处

导言
关于“云计算”的喧嚣已日臻白热。有人认为这种趋势将摧枯拉朽，代表了互联网进化的新阶段；也有人则认为这是典型的炒作，它只不过使用了由来已久的计算技术，换汤不换药。正如IT世界的任何新生事物一样，我们必须彻底权衡利弊得失，才能三思而后行。
有一点是清楚的：整个业界必须展开客观、直接的对话，方能明确这个新的计算范式将如何影响组织机构的运行，如何与现有技术整合，以及存在怎样的潜在陷阱，导致技术锁定或选择局限。
本宣言旨在启动一项对话，汇集正在兴起的云计算社区（包括云用户和云供应商），制定一套核心原则。我们认为，该核心原则根植于一个信念，即云计算应该与其它所有IT技术一样开放。
本宣言无意于定义一套终极的云计算分类体系，或者制定什么标准规范，也不打算详述云计算的架构和设计。而是旨在为所有打算利用云计算的首席信息官、政府、 IT用户和商界领袖等提供指南，并为云提供商建立一套核心原则。云计算目前仍处于襁褓之中，依旧稚嫩好学、勤于实践。因此目前正逢其时，日渐成型的云计算社区的成员们应当秉承开放云的理念，共襄盛举。

什么是云计算，它为什么重要？
为了理解开放云计算的核心原则，我们必须首先对一些有关云计算的基本概念取得一致意见。首先，什么是”云” ？“云”这个术语其实正好恰如其分地表达了云计算的架构和内涵（即“云里雾里”。——译者注）。云计算是许多技术，如网格计算、公用计算、SOA和Web 2.0等等，发展到高级阶段的大杂烩，要给“云”下一个精确的定义往往引起激烈的辩论。
虽然对云进行定义、分类和架构是很有意义的事情，但理解云计算的价值则显得更为重要。我们要知道云技术的供应商为什么会走到一起，共同来实现“云”对我们的承诺。
云的最大特点是其扩展能力，以及动态高效地提供计算能力，并使消费者（最终用户，组织或IT人员）无需掌握复杂的底层管理技术而充分享用这种计算能力。云结构本身可以是私人的（在一个组织机构的防火墙内）或者公共的（托管在互联网上） 。这些特点具有以下核心价值：
按需扩展
所有组织都需要处理环境的变化。云计算解决方案能够方便地扩展和收缩规模是其最大的优点。如果一个组织在一段时间内，其计算资源的需求远远高于或低于正常值，云技术（包括公共的或者私人的）都能够处理这些变化。该组织根据资源的实际使用情况支付费用，没有必要根据人为的最高峰值请求资源从而造成浪费。
精简数据中心
任何规模的组织对数据中心都有相当的投资。这包括购买维护硬件软件、提供安装硬件的设施、以及聘用人员维持数据中心的运行等。一个组织可以通过采用云技术而简化其数据中心，或干脆利用公共的云存储服务。
改善业务流程
云提供的基础设施能够改善业务流程。一个组织和它的供应商和合作伙伴可以共享云中的数据和应用程序，让每个人都专注于业务，而不是承载业务的基础设施。
初始成本最小化
对于刚刚起步的公司、新兴行业的机构组织，或者大机构中的”臭鼬工厂“，云计算能够大大降低启动费用。新的组织建立伊始，其所需的基础设施就已经到位，不论是私有云或公共云，云提供商都花费了相当的时间和资源用于建设一个数据中心所必须的基础工作上。
应用的挑战和障碍
虽然云提供了巨大的机会和价值，一些通常的IT需求（安全性，整合等等）仍然不可或缺。此外，由于云计算的多用户租用（多个用户的信息存在于同一台物理设备中）、数据和应用的合并、以及数据可能存在于物理的数据中心之外，还会导致一些新的问题。这里主要讨论云计算必须解决的五项挑战，否则将影响其实现承诺。
安全
许多机构组织都对其无法控制的数据存储和应用系统非常不放心。将自己的工作内容置于一个共享的架构中增加了潜在的未经授权访问和泄露的可能性。验证的一致性、身份管理、兼容性以及存取技术将变得越来越重要。为了赢得客户，云供应商必须在工作规程中提供高度透明性。
数据和应用的互操作
数据和应用程序提供标准的访问接口是很重要的。机构组织常常希望能够灵活的创建新的数据和应用，并能够互操作，而不论基础设施是谁提供（不论是公共云、企业防火墙内的私有云、传统的IT环境、还是前述几种情况的组合） 。云供应商需要支持的互操作标准，使组织可以将任何云提供商的能力纳入其解决方案。
数据和应用可移植性
如果没有标准，收回自己的系统或者更换云服务提供商就会受限。一旦一个组织采用某个云服务商的方案建立或安置自己的系统，收回系统将是十分困难和昂贵的。
治理和管理
IT部门以传统的理念看待云计算方法，就会产生问题。云供应商必须共同努力来解决这些新的治理和管理问题，诸如共享云设施的生命周期管理、授权、支付等标准化机制等。
计量和监测
商业机构的领导倾向于将其IT系统分包给多个云供应商，并监控比较这些供应商提供的服务的性能指标。供应商必须提供一致的格式，以监测云应用和服务性能，并使其与现有的监测系统兼容。
很显然，谁能够在组织内有效地使用云计算，谁的机会就是巨大的。然而，这些机会不是没有风险和障碍。我们认为，云计算的价值能够充分发挥的唯一条件，是云提供商确保他们的云是开放的。
开放云的目标
客户希望他们使用的云服务与其它的IT方案一样开放。要使一个开放的云成为现实，企业领导人必须牢记以下几点：
选择
作为一个组织，选择一个供应商，或一个架构，或一种应用模式，开放的云将他们更容易在商业环境变化时选择不同的供应商或架构。如果该组织由于新的合作伙伴、并购、客户的要求或政府规章，而需要改变其供应商，这将使他们很容易这样做。如果该组织部署的是私人云，当他们扩展规模或扩充功能时，他们还可以选择其它供应商。这样，用于迁移的资源可以转而用于组织的创新。
灵活性
无论组织采用的是哪一个云供应商或哪一种架构，开放的云将他们更容易与其他群体协作，即使这些群体选择不同的供应商和架构。一个开放的云会更容易在不同的供应商之间进行互操作。
速度和敏捷性
云计算的一个重要价值是软硬件需求的按需扩展能力。使用开放的接口允许组织机构建立新的解决方案，整合公共云、私有云和现有的IT系统。当组织机构的条件发生改变时，一个开放的云能够让组织机构得到迅速和灵活地适应。
技能
开放云的副作用是缺乏技术熟练的专业人员。如果有很多特殊的编程模型，IT专业人士是不太乐意去钻研他们的。而开放的云，所需学习的新技术一般较少（特别是现有的技术已经在使用的情况下） ，这样就大大增加了找到具有必要技能专业人员的机会。
开放云的原则
          当然，许多不同的云将会继续存在的，提供其与众不同的价值。我们无意为每一个云计算的功能制定单独的标准，成就一个一统天下的云环境。随着云计算的成熟，有几个关键的原则必须得到遵循，以确保云是开放的，并满足可选择性、灵活性和敏捷性的需求（以下6点的翻译采用网络统发稿）：
        1.云计算供应商必须通力合作，确保能通过公开合作和适当采用标准来解决采用云计算所面临的挑战（安全性、集成、可移植性、互操作性、治理/管理、度量/监控）。
        2.云计算供应商不得利用其市场地位把用户锁定在自己特定的平台内、限制用户选择云计算供应商。
        3.云计算供应商必须尽可能采用已有标准。IT业已经在现有标准和标准组织上进行了大量投资；没必要重复或重新制定已有标准。
        4.需要制定新标准时（或需要修改现有标准时），我们必须审慎、务实，以免制定过多的标准。我们必须要确保标准能促进创新，而不是抑制创新。
        5.社区围绕云计算所做出的任何努力都应该由用户的需求驱动，而不仅仅是云计算供应商的技术需求，而且这些结果都应该用真实的用户需求加以测试或验证。
        6.云计算标准组织、倡导者团体和社区都应该互相合作、互相协调，确保各项成果不会冲突或重叠。
结论
          本宣言旨在开展对话，并非界定。许多细节（例如分类表，定义和应用情境）可以随着云计算社区的壮大而不断完善。
我们概述了组织机构利用云计算技术所面临的挑战。这些问题导致了IT业就建立一个开放的云，呼吁采取一致的行动。作为业界同仁，我们必须共同努力，以确保云仍然是与其它所有的IT技术一样开放。有人可能会认为，现在讨论诸如标准、互操作性、集成性和可移植性还为时过早。虽然这是一个云计算社区充满创新的时代，这些创新应该遵循本宣言所倡导的开放原则。我们认为，目前创建开放的云，正逢其时。
目前已有超过200家公司签署了该宣言，但是可惜的是不包括云计算行业的四大金刚：亚马逊、谷歌、微软和Salesforce.com。
参考：http://www.infoq.com/cn/news/2009/04/The-Open-Cloud-Manifesto
翻译：Kevenlw
]]></description>
		<wfw:commentRss>http://www.libspace.org/archives/opencloudmanifesto.html/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>关联数据问答（Linked Data FAQ）</title>
		<link>http://www.libspace.org/archives/linked-data-faq.html</link>
		<comments>http://www.libspace.org/archives/linked-data-faq.html#comments</comments>
		<pubDate>Mon, 25 May 2009 01:02:03 +0000</pubDate>
		<dc:creator>tsingove</dc:creator>
				<category><![CDATA[Featured]]></category>
		<category><![CDATA[图情技术]]></category>
		<category><![CDATA[资料解析]]></category>
		<category><![CDATA[关联数据，RDF]]></category>

		<guid isPermaLink="false">http://www.libspace.org/?p=245</guid>
		<description><![CDATA[原文出处：http://structureddynamics.com/linked_data.html
翻译：李佳佳 审校：张春景 刘炜
    关联数据是语义万维网第一种可行的表达形式，实用且可操作，适用于各种形式的数据。
    蒂姆•伯纳斯-李(Tim Berners-Lee)在《关联数据的设计问题》中所提到的关联数据四原则，以及维基百科上有关关联数据的介绍，都给出了关联数据大致能够被接受的、正式的或官方的定义。以这些定义为基础，为了更为精确地说明关联数据，本站（Structured Dynamic）采用如下定义：
关联数据是一组最佳实践的集合，它采用RDF数据模型，利用URI（统一资源标识符）命名数据实体，来发布和部署实例数据和类数据，从而可以通过HTTP协议揭示并获取这些数据，同时强调数据的相互关联、相互联系以及有益于人机理解的语境信息。
    以下内容涉及的“关联数据”，都符合上述定义。
常见问题及解答
1.	关联数据是否一定要用RDF？
2.	发布RDF足以创建关联数据吗？
3.	如何发布或部署关联数据？
4.	关联数据只是语义万维网的另一种表述，或者是语义万维网的另一个商标吗？
5.	关联数据只能应用于实例数据吗？
6.	本体在关联数据中扮演什么角色？
7.	关联数据采用的是集中式的方法，还是联邦式(federated)式的方法？
8.	在联合(federating)关联数据的时如何维护语境？
9.	开放数据是关联数据的前提吗？
10.	遗留数据可以表示为关联数据吗？
11.	企业数据，公开数据和公共数据可以混合成关联数据吗？
12.	如何查询或获取关联数据？
13.	如何对关联数据进行访问控制或安全维护？
14.	企业能够从关联数据中获得哪些益处？（或者企业为什么要使用关联数据？）
15.	早期的关联数据应用或使用于哪些方面？
1. 关联数据是否一定要用RDF？
    是的，一定要用。尽管其他方法也可以建立基于主体-谓词-客体（subject-predicate-object）结构的一阶谓词逻辑模型，该结构是资源描述框架（RDF）数据模型的核心，但RDF是基于W3C一系列开放标准。RDF和一阶逻辑之所以强大，在于它的简单性，并有能力表达复杂的模式和关系，适合为现有的各种非结构化、半结构化和结构化数据框架建立模型。

2.发布RDF足以创建关联数据吗？
    并非这样。关联数据只是一套应用了RDF模型的技术，这个模型要求以URIs命名所有的对象，并能够通过HTTP协议访问获取（也有一些其他考虑，参见上文定义以及下文的进一步讨论）。
    一些厂商和数据提供者声称支持关联数据，但是如果他们的数据不能通过HTTP获取，并使用URI作为数据对象的标识，这些数据就不是关联数据。幸运的是，这些数据可以比较直接地将非标准的RDF数据（non-compliant RDF）转化为关联数据。
3.如何发布或者部署关联数据？
    关于如何发布关联数据有许多不错的参考资料，例如《如何在网络上发布关联数据》（How to publish linked data on the web）教程和白皮书《部署关联数据》（Deploying linked data），该白皮书采用了OpenLinks Virtuoso软件作为例子。除此之外，还有一些使用URI的推荐方法，比如W3C的工作草案《语义万维网的“酷”URIs》（Cool URIs for the Semantic Web）。
    但是，目前还没有指南性的文档，能够符合上述定义，同时强调数据类和语境的匹配。很多公司和专业顾问目前能够提供这方面的帮助。
    关键之处在于积极地使数据单元之间的联系具有一定的语义（属性或关系，即三元组中连接主客体的“谓词”），它利用URI进行对象标识，并通过HTTP协议进行揭示（expose）和访问。
4. 关联数据只是语义万维网的另一种表述，或者是语义万维网的另一个商标吗？ 
    绝对不是，虽然这个问题目前是产生许多困惑的源头。
    语义万维网可能最好被理解为一种愿景或者目标，希望机器代理可以使用经过富语义标注的数据来创建链接，找到信息或者自动地在背后替人做事。虽然那我们正在朝着这个目标努力，但是按此解释，语义万维网更多的是一种过程而不是状态。如果认识到语义万维网是一种愿景或者目标，我们就能理解类似“Web 3.0”之类的标签未免过于简单而且片面。
    关联数据是一类实践活动，如果把从最初的文件网络（Web of Documents）到如今的语义万维网愿景看成一个频谱的话，关联数据处于其中部靠前的某个位置。
    关联数据已经呈现在诸位眼前，可行而且实用。可以用它来建立有意义的语义连接，并实现很多其它好处（如下文所述），但后台的自动推理以及自主行为目前还不能实现。
    严格地讲，在语境信息的Web访问和语义万维网的长期愿景尚无着落的前提下，关联数据提供了一种可行的最佳方案。
5. 关联数据只能应用于实例数据吗？
    绝对不是，尽管早期的一些实践都是这样应用的。
   ...]]></description>
		<wfw:commentRss>http://www.libspace.org/archives/linked-data-faq.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>到达彼岸[中英文对照版]</title>
		<link>http://www.libspace.org/archives/daodabianzhongyingwenduizhaoban.html</link>
		<comments>http://www.libspace.org/archives/daodabianzhongyingwenduizhaoban.html#comments</comments>
		<pubDate>Sun, 18 Jan 2009 01:38:59 +0000</pubDate>
		<dc:creator>tsingove</dc:creator>
				<category><![CDATA[Featured]]></category>
		<category><![CDATA[图情技术]]></category>
		<category><![CDATA[MARC]]></category>
		<category><![CDATA[OCLC]]></category>
		<category><![CDATA[RDA]]></category>

		<guid isPermaLink="false">http://www.libspace.org/?p=220</guid>
		<description><![CDATA[原文链接：Getting There
by Diane I. Hillmann, November 2008, Published in Technicalities, Jan./Feb. 2009
I do a lot of traveling around, talking about where cataloging is going and what catalogers need to do to prepare for present and future change, and listening to cataloger’s concerns. Wherever I go, I still get a lot of questions about RDA’s future.  Is RDA really going to happen? Didn’t the LC Bib Control Working Group recommend that it be suspended?  The answer to both those questions is “yes,” although naturally there’s more than that simple ...]]></description>
		<wfw:commentRss>http://www.libspace.org/archives/daodabianzhongyingwenduizhaoban.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>联邦搜索一百问</title>
		<link>http://www.libspace.org/archives/lianbangsousuoyibaiwen.html</link>
		<comments>http://www.libspace.org/archives/lianbangsousuoyibaiwen.html#comments</comments>
		<pubDate>Sat, 11 Oct 2008 00:40:03 +0000</pubDate>
		<dc:creator>tsingove</dc:creator>
				<category><![CDATA[图情技术]]></category>
		<category><![CDATA[SaaS]]></category>
		<category><![CDATA[一站式检索]]></category>
		<category><![CDATA[可用性]]></category>
		<category><![CDATA[联邦搜索]]></category>
		<category><![CDATA[跨库检索]]></category>

		<guid isPermaLink="false">http://www.libspace.org/?p=166</guid>
		<description><![CDATA[原文：100 Federated Search Requirements Questions To Ask Vendors 
翻译原文：编目精灵：联邦搜索一百问（上）  联邦搜索一百问（下）

    联邦搜索、跨库检索、一站式检索，图书馆在选择软件或应用时，要考虑的因素很多。Deep Web Technologies提出了一个清单，包括联邦搜索的潜在客户考虑及要问厂商的100多个问题（目前为117个），分成十四个大类：
    √ 可用性 Usability
    √ 架构 Architecture
    √ 整合 Integration
    √ 搜索功能 Search Features
    √ 结果特性 Results Features
    √ 软件即服务 SaaS (Software as a Service)
    √ 本地主机解决方案 On-site hosting of solution
    √ 系统管理 System Administration
    √ 连接器 Connectors
    √ 提醒 Alerts
    √ 支持 Support
    √ 强化与升级 Enhancements and Upgrades
    √ 计划与部署 Planning and Deployment
    √ 厂商信息 Vendor Information
    据编制说明，这并不是一个完整的清单，也没有一个厂商可以对所有问题都给予肯定的回答，清单的目的只在于帮助图书馆确定对自己重要的方面。
    对图书馆来说，如果向相关厂商抛出这样一份清单，让对方回答所有问题，然后对各家的回复加以汇总分析，确定自己更看重哪些方面的性能，真是可以省很多事。
    清单以图书馆方面或者说其技术主管的角度向厂商提问，对厂商以“你们”相称（译文中多省略），对图书馆方面以“我”或“我们”称呼，而“用户”则指读者或最终用户。或许考虑到问题会不断增加，原文并无编号，为方便标识，以下编号为本人所加。
100 Federated Search Requirements Questions To Ask Vendors (DOC文件)
一、可用性 Usability
1、用户界面是否友好及易于使用（即无需用户培训）？
2、基本搜索是否易于执行？
3、是否提供聚类或其他可视化的检索结果？如果是，我是否可以选取自己需要的聚类字段（如作者、日期范围、出版项）
4、是否支持分面（导览）搜索？
5、是否支持分类法及/或本体？
6、高级搜索是否直观？
7、检索结果页是否内容丰富且易于浏览？
8、是否提供基于Web的帮助页面？
9、支持什么浏览器及其版本？
10、搜索支持的最小屏幕分辨率？

二、架构 Architecture
11、用户一次可搜索的最大来源数量？
12、产品可支持多少并发用户/提问？
13、是否所有组件均私有？是否有部分开源？
14、通过一个搜索表单，软件可在什么程度上并行搜索非结构化数据（如论文、白皮书、报告）、基于Web的OPAC目录、公共网站、自建数据库以及订购服务？
15、在不同用户获取不同搜索页与来源时，是否支持不同的访问级别？（这将由Web应用或HTTP服务器支持）
16、能否通过多协议访问文件来源（如XML网关、HTTP、SR/U、SR/W、Z39.50）？
17、是否支持抓屏作为信息提取的最后手段？
18、是否支持用户从不同地点搜索？如果是，支持何种机制（如基于浏览器的代理、代理服务器）？
19、相关排序算法能否以特定日期范围或者某一特定来源，对结果加权？
20、对于搜索与结果中不同形式的日期，处理得如何？
21、对于搜索与结果中不同形式的作者名称，处理得如何（如爱因斯坦的不同形式Einstein, A.对Einstein, Albert对Albert Einstein）？
22、应用的内部工作可定制性如何（如排序、过滤、排序算法）？
23、能否管理个别用户登录到某一来源？
24、能否按每一来源实施并发搜索数限制？
三、整合 Integration
25、是否有API，我可用于将你们的功能嵌入其他软件（如搜索门户）？如果有，说明文件做得如何？
26、是否有你们系统功能的基于标准的Web服务接口？
27、我能否方便地在自己的主页、其他网页及其他应用中方便地嵌入你们应用的搜索框？
28、能否与URL解析器整合？
29、是否与ILS目录整合以浏览期刊或数据库？
30、具有哪些与社会网络和/或协作工具整合的功能？
31、能否与课程管理系统整合（如Moodle或Sakai）？
四、搜索功能 Search Features
32、我们能否选择特定来源搜索，或者选择多组来源搜索？
33、是否实时并行检索多个来源（即是否事实上做联邦搜索）？
34、是否既搜索文摘也搜索全文？
35、是否对不同用户集支持不同搜索页（外观）？
36、具有哪些高级（字段）搜索能力？用户可搜索哪些字段？
37、能否按不同属性执行搜索（如日期或相关性）？
38、是否支持布尔算子、通配符和/或词组搜索？
39、是否支持邻近搜索？
40、用户能否保存搜索供以后执行？
41、用户能否看搜索历史？
42、用户能否定制其搜索体验？
43、是否提供拼写检查，以更正潜在的拼写错误并提供拼写提示？
44、是否提供期刊与数据库的浏览与题名搜索？
45、我能否按日期范围、只搜索同行评议文献、只搜索全文文献作限定搜索？
46、是否以合理方式处理词干与停用词？
47、是否向用户提供数据库描述？
五、结果特性 Results Features
48、是否提供相关性排序？如果是，如何做的？
49、是否对结果排重？如果是，针对什么字段做排重？
50、是否合并不同来源的多个结果，以产生包含所有来源结果的单一结果页？
51、对单个来源，软件能检索到多少结果？
52、是否提供增量（部分）结果，让用户可以立刻看到部分结果，无须等待所有来源返回所有结果？
53、系统能否对检索结果显示哪些字段提供灵活的处理？
54、能以什么方式排序结果？
55、是否支持结果过滤（缩检）？
56、能否标记搜索结果以下载、保存或打印？
57、结果一览表能否通过电子邮件发送？如果能，能否以HTML或文本方式发送？
58、搜索结果能否输出为RSS种子？
59、能否输出为引文？如果能，以什么格式？
60、用户能否按内容类型组织结果（如视频、演示、培训课程、新闻）？
六、软件即服务 SaaS (Software as a Service)
61、费用结构？按用户数、连接器数或是其他方式收费？
62、我必须签多长时间的合同？
63、是否实施负载平衡(load balancing)？
64、服务是否具有高可用性（如容错）？
65、你们为你们的搜索引擎与连接器配备什么样的实地监测？
七、本地主机解决方案 On-site hosting of solution
66、硬件要求（CPU、内存、存储）？
67、软件运行于什么平台？
68、安装软件的技术要求？
69、维护软件需要什么级别的技术资源（时间与能力）？
70、维护软件需要什么级别的管理支持（时间与能力）？
71、费用结构（如许可条款）？
72、软件维护和错误修复的模式？
八、系统管理 System Administration
73、有什么性能和/或其他指标可用（如用户提问数、特定来源返回文献数、来源性能、搜索词）？
74、提供哪些工具监测本地主机系统的组件（如CPU、内存、进程使用）
75、提供什么创建与管理用户的管理工具
76、能否让来源离线与连线？（如在来源临时宕机的情况下，能够让连接失效是很有用的）
九、连接器 Connectors
77、是否有远程监测连接器的机制？如何处理远程确认的连接器问题？
78、是否有可让我使用的监测连接器的工具，可在某个连接器不再工作时得到通知？
79、能否向我提供可用连接器的清单？
80、在搜索信息源时，是否处理进程(sessions)与cookies？
81、我能否创建自己的连接器？如果能，创建是否很困难？你们为此提供什么工具、培训、文件及支持？
82、能否搜索具有索引文件的应用？
83、是否为链接解析器整合ILS目录？
84、软件能否对某一来源自动检索更多的结果（即得到下一页结果）？
85、你们如何对我的内部来源[自建数据库]维护连接器？
86、你们是否对我的“必须拥有”清单有（或者承诺建立）连接器？
87、你们处理新连接器的过程是什么？需要多长时间建立？
88、能否搜索本地ILS目录？
89、我能否使用你们的应用搜索自己的企业级应用（如Documentum, Lotus Domino, ...]]></description>
		<wfw:commentRss>http://www.libspace.org/archives/lianbangsousuoyibaiwen.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
