内容


使用分面导航实现文档搜索

使用元数据优化搜索

Comments

利用分面导航获得更好的搜索

文档搜索是企业内容用户获得他们所需的文档的最重要方法之一。不幸的是,有许多原因使得企业文本搜索系统的工作效率低于公共 Internet 搜索的效率(请参阅 Enterprise Search: Tough Stuff,由 Rajat Mukherjee 和 Jianchang Mao 合著。ACM Queue vol. 2, no. 2,2004 年 4 月)。主要原因是大多数企业内容不是交叉链接的,因此搜索系统无法获得关于某个主题的标识为 “good” 页面的页面排名信息。另一方面,Internet 搜索没有太多地使用元数据(或根本没使用),因为多数 Internet 内容只有非常少的元数据或根本没有元数据 。相反,企业内容通常具有与之相关的元数据。事实上,许多组织对创建标准化元数据非常感兴趣,这些元数据包括 Defense Discovery Metadata Standard (DDMS),由 US Department of Defense 定义,以及 Cross-Enterprise Document Sharing (XDS) 框架,由 IHE 创建,IHE 是一家健康行业协会(请参阅 参考资料,获得关于每个标准化元数据方法的更多信息)。

这样就有了一个使用元数据提高企业内部搜索的机会。元数据非常有用,因为它允许用户指定所有已检索文档必须满足的条件。例如,除了诸如 “diesel pollution” 或 “culvert bomb Anbar Province” 之类的关键字搜索查询之外,用户还可以使用元数据条件指定他们感兴趣的最近三个月由某个特定作者创建的文档。典型的 Internet 搜索系统无法做到这一点。

尽管对于用户而言,每个用户都有几种指定元数据条件的不同方法,但本文即将介绍的这种方法有其特殊优点:分面导航。这里描述的分面导航系统的昵称为 Croton,它是基于 IBM® Omnifind™ Discovery Edition 并利用 DB2 的 XML 功能的技术演示程序。整个 Croton 系统都可以在笔记本电脑中运行。

分面导航的示例

图 1 中显示了 Croton 的分面导航搜索界面。界面顶部是熟悉的搜索框,用户可以将其查询(比如 “cafe”)输入其中。在左边,标题 “Refine by” 的下方,是方面 “Incident Date” 和 “Geography”。每个方面都是不同的值层次结构的最顶部,可以将这些扩展为用户界面中的树。用户先选中了 “Iraq”,然后选中了 “Kirkuk”。最终效果是将结果列表中的文档限制为文本中包含 “cafe” 并且其 Geography 方面包含值 “Geography > Middle East and Persian Gulf > Iraq > Kirkuk” 的那些文档。

此示例说明了分面导航的三个关键特性:

  1. 用户通过单击用应用程序表示的值来选择元数据条件。
  2. 只显示导向文档的元数据。在元数据条件上单击鼠标时,用户永远都不会获得空结果列表。
  3. 元数据是根据称为方面(facets)的几个独立类别进行编组的,每个方面都采用了一些值。可以使用分类法或其他一些方法(比如按日期范围编组,如示例中所示)以分层的方式编组这些值。
图 1. 分面导航应用程序
分面导航应用程序
分面导航应用程序

浏览过 Internet 上的目录的人应该非常熟悉分面导航。目录项事实上就是通过元数据描述的;实际上,如果在这样的应用程序中有一个搜索框,那么它通常只搜索元数据。目前情况下,要搜索的项是通过元数据和内容共同描述的文档,但是基本用户界面与电子商务应用程序相同。

未经培训的搜索者可以很快熟悉并能够轻松使用分面导航,这些特性都提供了巨大的优势。将元数据条件合并到搜索中的其他技术也得到了广泛应用,但这样做也存在一些弊端。常见的一项技术是扩展查询语言,从而允许将元数据条件指定为查询字符串的一部分。这是最早的一代文献搜索引擎(比如 IBM 的 STAIRS)中使用的方法。由于查询语言的复杂性,并且要构成查询还需要了解数据模式,所以需要进行培训才能使用这些应用程序。通常,这类应用程序由库管理员和其他专家使用。

合并元数据条件的另一个方法是使用查询表单,其字段对应于元数据模式的元素。经验显示,如果有可用的更简单的界面,这种表单很少使用。这与对未经训练用户使用的搜索(比如 Web 搜索)的研究一致,研究显示,不到 10% 的查询使用高级特性(请参阅由 A Spink、D Wolfram、M. Jansen 和 T. Saracevic 合著的 “Searching the Web: The public and their queries”。“美国社会信息科学和技术” 期刊,52 卷 2001 期,226-234 页)。

这些方法都带来了更深层的弊端:容易产生不返回任何结果的查询。这让那些不知道放宽查询条件来获得一些结果的用户感到迷惑。

分面导航克服了这些不利因素。该查询语言非常简单,并且能够与 Internet 搜索引擎兼容。元数据模式的结构是明确的,就像在表单中那样,但用户无法看见他不感兴趣的任何分面的细节。最后,不可能选择不返回任何结果的元数据条件,因为没有将它们显示给用户。此外,如果选中该条件,用户可以查看留在结果列表中的文档数量(请参见 图 1)。

分面导航还有一个更大的优点。根据对用户行为的研究, 我们知道人们喜欢使用一种可以描述为持续改进 的搜索方法(请参阅由 A Spink、T.D. Wilson、N. Ford、A Foster 和 D. Ellis 合著的 “Information seeking and mediated searching study: Part 3. Successive searching”。“美国社会信息科学和技术” 期刊,52 卷 2002 期,716-727 页)。也就是说,他们提供了一个初始主查询,该查询可以保证搜索系统至少能够访问他们感兴趣的区域中的一些文档。然后他们添加了更精确的条件,直到获得他们要寻找的东西。分面导航非常支持这种风格的查询,这也是分面导航在电子商务站点上的目录搜索中得到广泛应用的另一个原因。

本文其余部分描述了使用 IBM Omnifind Discovery Edition 搜索文档及其元数据集合的分面导航系统的概念验证演示。演示中使用的内容是 XML 中获得的恐怖事件报告的集合,我们将它存储为 DB2 V9 中的本机 XML。通过构建此系统,举例说明分面导航中的主要概念,并创建可在笔记本电脑中运行的用于评估和示范目的的演示。

WITS 文档集

我们使用了 WITS 文档集合作为包含大量相关元数据的文档示例。WITS 代表 “Worldwide Incident Tracking System”,它是美国国家反恐怖主义中心维护的恐怖事件数据库(请参阅 参考资料,获得关于 WITS 的更多信息)。 NCTC 使包含 28,752 个事件报告的 XML 文件可用于下载。清单 1 中显示了来自某个事件报告的摘录:

清单 1. 来自 WITS XML 文档的摘录
<IncidentList>
 <Incident>
    <ICN>200458431</ICN>
    <Subject>
      10 civilians killed, at least 45 wounded by suspected GAM in
      Peureulak, Indonesia
    </Subject>
    <Summary>
      On 1 January 2004, in Peureulak, Aceh Province, Indonesia, a
      bomb exploded at a concert, killing ten civilians, wounding 45
      others, and causing major damage to the stage area. Many of the
      victims were Indonesian teenagers. Police blamed the Free Aceh
      Movement (GAM), although the GAM denied responsibility. No 
      other group claimed responsibility.
    </Summary>
    <IncidentDate>01/01/2004</IncidentDate>
    <Location>
      <Region>East Asia-Pacific</Region>
      <Country>Indonesia</Country>
      <CityStateProvinceList>
        <CityStateProvince>
          <City>Peureulak</City>
        </CityStateProvince>
      </CityStateProvinceList>
    </Location>
 ...
 </Incident>
...
</IncidentList>

如清单 1 所示,WITS 事件报告既包含文本内容(SubjectSummary 元素),也包含结构化元数据,比如惟一事件编号 (ICN)、日期、位置信息和其他没有显示的数据。可以将此结构化元数据用于分面导航。

使用 IBM Omnifind Discovery Edition 搜索 WITS 集合

IBM Omnifind Discovery Edition(请参阅 参考资料)既包含文本搜索引擎,也包含分面导航引擎。 它还提供了可以从数据库、XML 文件和 Web 页面中收集内容的信息收集器 (crawler)。为了演示分面导航,我们使用 Version 8.4 of Discovery Edition 构建了一个概念验证系统,Version 8.4 of Discovery Edition 是随 Apache Tomcat 5.0 Web 服务器一起提供的。这些都安装在一台笔记本电脑中 。

首先让我们来看一下如何配置 Discovery Edition,以便使用默认用户界面搜索和导航 WITS 集合。然后,在后面的小节中,将了解如何使用树控件显示和选择元数据条件,从而改进文档搜索的用户界面。

定义集合

对于任何搜索项目,分面导航演示都要求定义内容源,配置收集这些内容源并为它们建立索引的信息收集器或其他设备。作为此过程的一部分,您必须告诉搜索引擎文档的哪一部分对应于特性,比如文档的标题、正文文本和其他您想让搜索引擎建立索引或显示的东西。此外,因为分面导航处理的是元数据和内容,所以还需要告诉引擎哪些地方可以找到用于每个文档的元数据值,同时必须为元数据指定数据模型。在使用 Omnifind Discovery Edition 时,可以通过定义保存元数据值的特性来实现上述操作,这些元数据值包括 Incident Date 以及发生事件的城市的名称。您还必须为每个特性指定一个数据类型。使用随产品一起提供的 Management Console 工具可以做到这一点。如果特性值实际上是通过分层结构或值的树结构定义的,换句话说,如果特性是一个分类特性,那么您也可以为它指定数据类型。表 1 中显示了我们的演示中使用的特性。可以根据需要定义其他特性,但这个最小的集合已足以演示分面导航,如表 1 中所示:

表 1. Croton 演示中使用的特性
特性名称类型描述
ICN 文本 来自 <ICN> 元素的标识符
主体 文本 事件的简短描述
主体 文本 事件的完整描述,来自 <Summary> 元素
IncidentDate DateTime 发生事件的日期
地区 文本 地理区域
国家 文本 地区中的国家
StateProvince 文本 国家中的州或省
城市 文本 州或省中的城市
地理 分类法 根据 Region>Country>City 创建

在定义集合的特性之后,可以指定包含 WITS 事件数据的 XML 文件作为集合内容源 ,并定义从 XML 文件中提取每个文档的特性的方式。通过为每个特性编写 XPath 表达式可以做到这一点。例如,定义 WITS XML 文件中的 Subject 特性的 XPath 表达式是 IncidentList/Incident/Subject/text()

定义分类特性

如果保留 Region、Country、StateProvince 和 City 作为独立特性,那么每个特性在用户界面中都应该显示为元数据的一个单独方面。但它们并不是独立的,因为地区中包含国家,城市包含在州或省中,依此类推,因此这些特性是紧密关联的。一个更好的办法是将这些地理特性链接成一个分层结构,帮助用户了解它们的关联方式。为此,我们使用 Taxonomy 数据类型定义了 Geography 特性。分类法提供了在用户界面中显示复杂数据模型的一个特殊的、功能强大的方法。必须根据依次从 WITS 数据模型(参见 清单 1)中的 Location 元素中提取的其他几个特性的值,为给出的文档定义 Geography 特性的值。要为每个文档创建 Geography 特性的值,可以利用 Omnifind Discovery Edition 的功能定义元数据规则。Geography 特性的值变成了 ${Region}: ${Country}: ${City},其中的冒号区分分类法的级别(我们省略了分类法的 StateProvince 级别,因为许多事件报告没有指定它)。为演示此元数据规则的效果,事件的 Geography 特性的值(如 图 1 中所示)变成了 “East Asia-Pacific: Indonesia: Peureulak”。

通过按范围对连续变量值进行编组,然后将它们进一步细分来创建分层结构,可以将这些变量强制转换为分类特性形式。可以配置 Omnifind Discovery Edition 自动实现上述操作。图 2 中显示了一个日期示例。此图显示了 2006 年全年中的 Incident Date 方面的值。日期被自动编组为 6 个范围,2 个月一个范围,然后这些范围形成了分层结构的下一级别。如果用户想选择这些范围中的一个,那么下一个显示将显示月份和某个月内的日期范围。可以使用此方法为任何连续数据创建分层结构。

图 2. 以分层结构形式描述的 Date 方面,类似于分类特性
以分层结构形式描述的 Date 方面,类似于分类特性

此时,我们已经定义了一个集合及其特性,已经创建了 WITS XML 文件并使用数据填充了每个 Incident 文档的特性,现在可以在 Management Console 中使用默认用户界面了,如 图 3 中所示。尽管还有更多的工作要做,但这已经显示了分面导航的主要特性。在图 3 中,用户正在搜索 “truck”,Omnifind Discovery 返回了 103 个文档。这些文档的元数据值都被显示出来,用户有机会使用它们来提炼搜索。此外还有返回的文档的列表显示。

尽管可以使用 Management Console 调整此界面,但对于此演示系统,我们想做一些重大改变。文档的列表显示不同于文档搜索中的标准。更值得注意的是,因为只显示了大多数可选择的元数据值来保持用户界面上的固定资源,所以在没有实际选择可用值并将它们添加到查询中的情况下,用户无法研究这些值。没有只研究值的分层结构的有效操作。要允许用户执行这些操作,则需要一个新的用户界面。

图 3. 默认用户界面
默认用户界面
默认用户界面

一个改进的用户界面

为了在研究元数据方面时给用户提供更大的灵活性,让用户更好地控制结果列表的细节,我们使用另一个用户界面替换了图 3 中的用户界面 (UI),如 图 4 所示。此 UI 是通过修改 Tabbed Navigation 界面使用 Java Server Pages (JSP) 实现的,Tabbed Navigation 界面是随 Omnifind Discovery Edition 8.4 一起提供的。

对于 Tabbed Navigation 界面,我们将进行两项主要修改。第一个修改是使用树控件替换 “Refine By”(元数据)选项的显示。这使用户能够更容易地研究可用值。第二个修改是扩展搜索结果列表,这样用户就可以单击事件报告的标题并查看整个报告。这会使结果页面类似于实际的文档搜索标准。

图 4. 基于树导航的可供选择的用户界面,该界面是使用 JSP 实现的
基于树导航的可供选择的用户界面,该界面是使用 JSP 实现的
基于树导航的可供选择的用户界面,该界面是使用 JSP 实现的

树控件(如图 4 中所示)是显示不同方面中的可用元数据值的简便(但却是动态的)方式。树的每个分枝都对应于元数据的一个方面。这允许用某种简便方式显示几个方面。此外,通过打开和关闭子树(没有选中它们),可以很容易地研究元数据条件。对于用户不感兴趣的方面,不展开它们即可,这样它们就不会占据屏幕空间。因此,此方法符合我们的直观界面的目标,并且允许很容易地研究包含许多方面的复杂元数据模型。

要对用户界面进行规划,不必从头开始,只需修改基于 JSP 的 UI 之一即可,这些 UI 是随 Omnifind Discovery Edition 8.4 一起提供的。我们将使用 TabbedNav 界面,它是作为 WAR 文件提供的,可以将它安装到开发环境(比如 Rational Application Developer (RAD))中,并且可以修改它来满足我们的目的。图 5 显示了已完成应用程序的不同部分,所有这些都可以运行在一台笔记本电脑中。JSP 托管在 Tomcat Web 服务器上,JSP 依赖于作为 Discovery 产品一部分的 Java 库。而这些库又使用了 Omnifind Discovery 服务器提供的 Web 服务。 恐怖事件报告的 XML 文件是由 Discovery 服务器提供的,如上所述,该文件被加载到 XML 数据库 DB2 9 中,执行文档显示的 JSP 可以从中检索此文件。可以将它们作为 XML 传输给浏览器,该浏览器包含一个 XSL 文件,为了便于显示,该文件将 XML 格式化为 HTML。本文将简单描述所有这些组件。

图 5. 分面导航应用程序的架构
分面导航应用程序的架构
分面导航应用程序的架构

树控件

我们将从用于显示元数据的树控件开始介绍。您可能想在用户打开和关闭子树时获得快速响应。Treeview 控件非常合适,可从网上获得它(请参阅 参考资料), 它是在浏览器中的 JavaScript 中执行的,这意味着它可以作出响应,通过根据 JSP 中的内容编写 JavaScript,可以在服务器端构建 JavaScript。要创建树,请使用新文件 refineByTree.jsp 替换作为 TabbedNav 代码一部分的文件 refineByList.jsp,新文件几乎完全模仿了 refineByList。在新文件中,通过调用 Discovery Edition Java 库构建树分层结构,然后使用 Web 服务与 Discovery 服务器进行通信。对于树中的每个节点,都定义了一个超级链接,如果用户单击该链接,就会向 Discovery 发送应用一个元数据条件的信号。

构建树分层结构

使用 Treeview 控件创建顶级文件夹(比如 “Geography”)的 JavaScript 如下所示:

folder0 = 
   insFld( foldersTree, gFld( "Geography", "javascript:undefined"));

其中,folder0 是提供给顶级文件夹的惟一名称,insFldgFld 是 Treeview 函数,foldersTree 是树的名称,而 “Geography” 是文件夹上的标签。函数 gFld 的最后一个参数是用户单击文件夹时调用的 JavaScript 函数;因为 “Geography” 是顶级文件夹,所以单击不会执行任何操作,并且函数是无参数的。其他代码(没有显示)用于以一致的方式为树中的每个节点分配不同名称。通过声明将此名称作为 Treeview 控件的 “外部 ID”,允许它在重新绘制结果页面时保持相同的树外观,从而维护状态。从用户的角度来看,这将提供更自然的感官。

清单 2 中显示了循环遍历顶级特性的 Java 代码,如下所示。注意方法的调用,比如来自 Omnifind Discovery Java 库的 DrillDown.getTallyFeatures()TallyFeature.getLabel()

清单 2. 使用顶级特性填充树的 Java 代码
DrillDown drillDown = resultSet.getDrillDownPlus();
StringBuffer buf = new StringBuffer(); // Holds HTML

// Loop through top-level features
for (int j = 0; j < drillDown.getTallyFeatures().length; j++){
  TallyFeature toplevelFeature = drillDown.getTallyFeatures()[j];
  String nodeName = "folder" + j;

  String label = toplevelFeature.getLabel(); // e.g. 'Geography'

  // Code to emit Treeview JavaScript goes here 

  // Add the sub-tree for the top level feature.
  addSubTree( buf, pageContext, toplevelFeature, nodeName);

} // end for j

对于每个顶级特性或方面,都有一个可能值组成的子树。refineByTree.jsp 中的 Java 函数 addSubTree 为子树创建了 JavaScript,并将它编写到缓冲器中。这引发的一个并发症状是:Discovery Java API 只允许获得子树中节点组成的列表以及子树的递归级别,因此需要根据此信息重新构造子树。对于列中的给定条目,通过进一步查看后面跟随的条目是否具有更高的递归级别,可以了解它是否具有子代。如果具有子代,那么当前条目必须是一个文件夹,您要将其名称和递归级别推到辅助堆栈上并将它们添加到树中。然后,当发现包含更低递归级别的列表条目时,通过从堆栈中取出文件夹,直到发现递归级别小于列表项的递归级别的文件夹,可以确定该条目属于哪个文件夹。

在以这种方式进行操作之前,函数 addSubTree 会发出 Treeview JavaScript 来创建一个文件夹节点或子节点,使用的方式与对顶级文件夹使用的方式几乎是相同的。主要不同在于,如果用户单击 JavaScript 函数,那么现在树中的每个节点都可以调用该函数,因此,可以将相应的元数据条件添加到用户的当前查询中。函数 javascript:drillerDownMenus 是由作为 Discovery 库一部分的 JavaScript 库提供的。refineByList.jsp 的代码提供了其用法的示例。这引发的更深层的并发症状是:Treeview API 需要用于 drillerDownMenus 参数的不同分隔符,具体情况取决于该参数是作为 insFld 的参数提供的(这创建了一个文件夹,分割符必须是双引号),还是作为 insDoc 的参数提供的(这创建了一个叶节点,分隔符必须是单引号)。

最后,为树节点添加一些悬停文本并指定呈现它们时使用的 CSS 样式,这将导致产生具有可用的一致外观的树控件,如 图 4 中所示。为了满足使用演示应用程序的 Treeview 控件的条件,还必须在输出中包含带有链接到 Treeview Web 页面的链接的标题,可以在 图 4 中看见该标题。

查看文档

为了完成改进的用户界面,我们想让搜索结果列表中的某个事件报告的标题链接到该报告的副本。如果该报告是一个现有 Web 页面,那么很容易做到这一点,但在这里,它是一个隐藏在 WITS XML 文件中的 XML 片段。我们需要一个可以使用给定 ICN 编号从文件中提取 Incident 元素内容的工具。

使用 DB2 存储和查询 XML 数据

您将要使用的工具是 DB2,我们已经在托管其他演示组件的笔记本电脑上安装了该工具。因为 DB2 版本 9 能够存储 XML 文档并返回它们(或一部分)来响应查询。我们在表 CROTON_DATA 中存储了 WITS XML 文件,该表的模式如图 6 中所示:

图 6. CROTON_DATA 表的模式
CROTON_DATA 表的模式
CROTON_DATA 表的模式

此表只包含一行。整个 WITS XML 文件都存储在 XML 列中。如果要处理一个以上的 XML 文件,例如包含来自不同时期的报告集的文件,那么应该包含更多的行。稍后我们将了解如何从表的 XML 内容中选择个别 Incident 元素。

要填充该表,只需使用 SQL 命令导入文件即可,如 清单 3 中所示(可能需要先增加 DB2 日志文件的大小):

清单 3. 使用 SQL 命令导入文件
IMPORT FROM "[path]\Croton\Datasets\incidents.del" 
OF DEL XML FROM "[path]\Croton\Datasets" 
METHOD P (1, 2) MESSAGES "c:\msg.txt" 
INSERT INTO MARWICK.CROTON_DATA (NAME, "DATA");

其中的文件路径已获得简化。命令引用的文件 incidents.del 的内容如下:

"WITS","<XDS FIL='wits.xml'/>"

当然,wits.xml 是包含所有事件报告的文件的名称,清单 1 中显示了它的一个片段。

在 DB2 9 导入 XML 文件之后,它会解析 XML 并为其建立索引,以便允许针对该文件执行 XML 查询。DB2 9 包含一个 XML 数据库引擎,该引擎可以与 SQL 数据库引擎一起使用,这使 XML 查询非常有效。

要从 CROTON_DATA 表中检索单个事件报告,只需一个 XML 查询即可。清单 4 举例说明了一个示例查询:

清单 4. 检索单个事件报告
xquery
for $Incident in 
db2-fn:xmlcolumn( "CROTON_DATA.DATA")/IncidentList/Incident
where $Incident/ICN="200458437"
return $Incident;

此查询以 XML 片段的形式返回所请求的 Incident 的内容。清单 5 显示了如何使用 JDBC 和现有数据库连接实例从 Java 发出 XML 查询,就像它是一个普通的 SQL 查询那样:

清单 5. 通过使用 JDBC 发出 XML 查询来返回 XML 数据的 Java
String result;
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery( query);
if( rs.next()) {
      result = rs.getString( 1); // return XML fragment
}

将 XML 数据返回给 Croton

数据库访问代码被打包为 Croton 应用程序中的会话 bean XMLData。该 bean 由新的 JSP showIncident 使用,当用户单击搜索结果列表中的事件标题时,将使用以下形式的链接调用此 JSP:

http://localhost:8080/Croton/showIncident.jsp?icn=200458437.

要在构建结果列表页面时构造此 URL,则需要使用 Java 库函数从 Omnifind Discovery Edition 服务器获得每个结果列表项的 ICN 特性的值。当用户单击链接时,将调用 showIncident JSP,该 JSP 将从其查询对象中检索 ICN 特性的值。然后利用前面描述过的 XML 查询,使用 XMLData bean 检索 Java String 中的 XML 事件数据。最后,通过 showIncident 将事件数据 XML 返回给浏览器。

但这里还有最后一个额外的步骤。浏览器无法做好呈现原始 XML 的工作。为了进一步帮助用户,您可以使用样式表将原始 XML 转换为格式良好的 HTML 页面。样式表指定了将 XML 映射到 HTML 的方式。它驱动用户浏览器中的转换引擎。我们使用了一个简单的样式表来做两件事情:(1) 定义 HTML 输出中使用的演示文稿样式,比如字体和颜色;(2) 创建使用这些样式并将它们应用于原始 XML 中的数据的 HTML 输出 。 在下面来自样式表的代码片段中,将对第二个步骤进行说明:

<tr>
     <td class="FacetMajorHeader">Subject</td>
     <td><xsl:value-of select="//Incident/Subject"/></td>
</tr>

在这里,Subject 元素的内容是在表行中呈现的。标题 ("Subject") 是使用为元素类 FacetMajorHeader 指定的样式呈现的。xsl:value-of 元素的 select 属性显示了一个 XPath 表达式,该表达式选择 XML 中的 Subject 元素的内容,然后将它从 XML 映射到样式表定义的 HTML。内容是使用包含的表的样式呈现的,这里没有显示。

现在只剩下将引用插入样式表中,插入 showIncident.jsp 返回的 XML 的开始处。结果产生如 图 7 中所示的格式。

图 7. 使用样式表格式化的 XML 事件报告
使用样式表格式化的 XML 事件报告
使用样式表格式化的 XML 事件报告

对于用户而言,读取原始 XML 可能更容易一些,为了演示目的,页面上包含一个链接到 XML 原始版本的链接。样式表包含用来处理 XML 特性的代码,这些特性包括重复 XML 中的元素、元素值列表等等,显示的示例中并没有包括所有这些特性。

结束语

本文从指出企业搜索(特别是包含可用元数据的搜索)完全不同于 Internet 搜索开始介绍,这是满足用户需求的一种不同方法。本文中描述的 Croton demo 举例说明了分面导航如何支持文本搜索条件,以及如何以自然的方式组合元数据条件,这允许用户从组织的元数据创建投资中获得最大的利益。Croton demo 还举例说明了如何通过 DB2 9 和 IBM Omnifind Discovery Edition 的 XML 功能,使得使用基于标准的方法、基于 XML、XPath 查询语法和 Extensible Stylesheet Language 的方法成为可能。通过使用组合了内容和元数据的原始 XML 模式,可以简化总体解决方案,从而实现数据索引和存储。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Information Management, XML
ArticleID=317845
ArticleTitle=使用分面导航实现文档搜索
publish-date=07022008