运行 Eclipse
将 Eclipse 驱动程序安装（解压缩）到某个目录（例如，c:\eclipse）中之后，通过运行顶级安装目录中的 Eclipse 可执行文件来启动"工作台"。在 Windows 系统上，该可执行文件称为 eclipse.exe，而在 Linux 系统上称为 eclipse。注意：下列讨论描述 Windows 系统上的设置。Linux 上的设置是相似的。

如果您没有另行指定，则平台将缺省工作区目录创建为可执行文件的兄弟目录（例如 c:\eclipse\workspace）。此工作区目录用作项目的缺省内容区，还用于保存任何必需的元数据。要进行共享安装或多工作区安装，应明确指出工作区的位置而不是使用缺省值。有两种控制工作区位置的方法：使用当前工作目录或使用 -data 命令行自变量。

将工作区位置设置为在当前工作目录内
在此方案中，工作区位置将是当前工作目录中称为 workspace 的目录。

实现此目的最容易的方法可能是使用下列步骤来创建快捷方式：

导航到 Windows 资源管理器中的 eclipse.exe 并使用右键拖动来创建 eclipse.exe 的快捷方式。
编辑快捷方式的属性，以使启动位置：字段标识工作区位置的父目录（例如，c:\users\robert）。
关闭属性对话框并双击快捷方式（如果提供的目录为 c:\users\robert，则工作区位置将为 c:\users\robert\workspace）。
当然，您也可以使用命令提示符（通过将目录切换为工作区父目录然后运行 eclipse.exe）来获得同样的效果。

使用 -data 设置工作区的特定位置
要使用 -data 命令行自变量，只要将 -data your_workspace_location（例如，-data c:\users\robert\myworkspace）添加至快捷方式属性中的目标字段或显式地将它包括在命令行上。

使用 -vm 设置 java VM
建议显式指定在运行 Eclipse 时要使用哪个 Java VM。使用 -vm 命令行自变量（例如，-vm c:\jre\bin\javaw.exe）可以实现此目的。如果不使用 -vm，则 Eclipse 将使用在 O/S 路径上找到的一个 Java VM。当安装其它产品时，它们可更改您的路径，导致在下一次启动 Eclipse 时使用另一 Java VM。

运行 Eclipse 中的高级主题
Eclipse 可执行文件及平台本身提供了人们感兴趣的开发或调试 Eclipse 各部件的许多执行选项。运行 Eclipse 可执行文件的一般格式是：

eclipse [platform options] [-vmargs [Java VM arguments]]
Eclipse 启动参数 命令 描述 原因
-arch architecture
定义 Eclipse 平台在其上运行的处理器体系结构。Eclipse 平台通常使用 Java os.arch 属性的常用值来计算最佳设置。如果在此处指定该项，则这是 Eclipse 平台使用的值。此处指定的值可作为 BootLoader.getOSArch() 用于插件。示例值有："x86"、"sparc"、"PA-RISC"和"ppc"。 2.0
-application applicationId
要运行的应用程序。应用程序由向 org.eclipse.core.runtime.applications 扩展点提供扩展的插件来声明。通常不需要此自变量。如果指定了此项，则该值会覆盖配置提供的值。如果不指定此项，则会运行"Eclipse 工作台"。 1.0
-boot bootJarURL
（建议不使用；用 -configuration 代替；支持 1.0 兼容）。Eclipse 平台的引导插件代码（boot.jar）的位置，表示为 URL。如果指定此项，则会用它来为装入 Eclipse 平台引导程序类装入器的类装入器设置类路径。仅当更改 startup.jar 和 boot.jar 的相对位置时才需要它。注意，不允许使用相对 URL。 *1.0
-classloaderproperties [file]
如果指定的话，则使用给定位置处的类装入器属性文件来激活平台类类装入器增强。文件自变量可以是文件路径或 URL。注意，不允许使用相对 URL。单击此处以获得更多详细信息。 2.0.2
-configuration configurationFileURL
Eclipse 平台配置文件的位置，表示为 URL。配置文件确定 Eclipse 平台、可用插件集和主要功能部件的位置。注意，不允许使用相对 URL。当安装或更新 Eclipse 平台时配置文件被写至此位置。 2.0
-consolelog
将 Eclipse 平台的错误日志镜像到用来运行 Eclipse 的控制台。与 -debug 组合时很方便使用。 1.0
-data workspacePath
要运行 Eclipse 平台的工作区的路径。工作区位置也是项目的缺省位置。相对于从中启动 eclipse 的目录来解释相对路径。 1.0
-debug [optionsFile]
将平台置于调试方式，并从给定位置处的文件装入调试选项（如果指定的话）。此文件指示哪些调试点可用于插件以及是否已启用它们。如果未给出文件位置，则平台在启动 eclipse 的目录中查找称为".options"的文件。URL 和文件系统路径都可作为文件位置。 1.0
-dev [classpathEntries]
将平台置于开发方式。将可选类路径条目（用逗号分隔的列表）添加至每个插件的运行时类路径。例如，当工作区包含要开发的插件时，指定 -dev bin 会为每个插件项目的名为 bin 的目录添加类路径条目，允许在其中存储最新生成的类文件。除去了冗余或不存在的类路径条目。 1.0
-endsplash params
用于在 Eclipse 平台启动并运行时关闭闪屏的内部选项。此选项在闪屏处理链中不同的位置有不同的语法和语义。 2.0
-feature featureId
主要功能部件的标识。主要功能部件为 Eclipse 的已启动实例提供了产品个性，并确定使用的产品定制信息。 2.0
-keyring keyringFilePath
磁盘上授权数据库（或"密钥环"文件）的位置。此自变量必须与 -password 选项配合使用。相对于从中启动 eclipse 的目录来解释相对路径。 1.0
-nl locale
定义 Eclipse 平台在其上运行的语言环境的名称。Eclipse 平台通常自动计算最佳设置。如果在此处指定该项，则这是 Eclipse 平台使用的值。此处指定的值可作为 BootLoader.getNL() 用于插件。示例值有："en_US"和"fr_FR_EURO"。 2.0
-nolazyregistrycacheloading
取消激活装入优化的平台插件注册表高速缓存。缺省情况下，仅当需要时才从注册表高速缓存（可用时）中装入扩展的配置元素，以减少内存占用。此选项将在启动时强制完全装入注册表高速缓存。 2.1
-noregistrycache
绕过读写内部插件注册表高速缓存文件。 2.0
-nosplash
运行平台而不显示闪屏。 1.0
-os operatingSystem
定义 Eclipse 平台在其上运行的操作系统。Eclipse 平台通常使用 Java os.name 属性的常用值来计算最佳设置。如果在此处指定该项，则这是 Eclipse 平台使用的值。此处指定的值可作为 BootLoader.getOS() 用于插件，并用于解析插件清单文件中提及的路径中 $os$ 变量的出现。示例值有："win32"、"linux"、"hpux"、"solaris"和"aix"。 1.0
-password password
授权数据库的密码。与 -keyring 选项配合使用。 1.0
-perspective perspectiveId
启动时要在活动工作台窗口中打开的透视图。如果没有指定该参数，则将打开关闭时活动的透视图。 1.0
-plugincustomization   propertiesFile
包含插件首选项缺省设置的属性文件的位置。这些缺省设置覆盖在主要功能部件中指定的缺省设置。相对于从中启动 eclipse 的目录来解释相对路径。 2.0
-plugins pluginsFileURL
（建议不使用；用 -configuration 代替；支持 1.0 兼容）。 指定 Eclipse 平台查找插件的文件的位置，表示为 URL。该文件为属性文件格式，其中键是任意用户定义名称，值是指向 plugin.xml 文件的显式路径或指向包含插件的目录的路径的用逗号分隔的列表。注意，不允许使用相对 URL。如果指定此项，则此选项会导致创建适当的临时配置。 *1.0
-refresh
启动时执行工作区的全局刷新的选项。这将使从上次平台运行以来在文件系统中所做的任何更改一致。 1.0
-showlocation
用于在窗口标题栏中显示工作区的位置的选项。在发行版 2.0 中，此选项仅与 -data 命令行自变量一起使用。 2.0
-showsplash params
用于显示闪屏（由可执行的 Eclipse 平台启动器执行）的内部选项。此选项在闪屏处理链中不同的位置有不同的语法和语义。 2.0
-vm vmPath
要用来运行 Eclipse 平台的"Java 运行时环境"（JRE）的位置。如果不指定此项，则 JRE 位于 jre（它是 Eclipse 可执行文件的兄弟目录）。相对于从中启动 eclipse 的目录来解释相对路径。 1.0
-ws windowSystem
定义 Eclipse 平台在其上运行的 Windows 系统。Eclipse 平台通常使用 Java os.name 属性的常用值来计算最佳设置。如果在此处指定该项，则这是 Eclipse 平台使用的值。此处指定的值可作为 BootLoader.getWS() 用于插件、用于配置 SWT 以及用于解析插件清单文件中提及的路径中 $ws$ 变量的出现。示例值有："win32"、"motif"和"gtk"。 1.0

将 -vmargs 条目后面的所有自变量（但不包括 -vmargs）作为虚拟机自变量（即，在要运行的类的前面）直接传递到所指示的 Java VM。注意：如果 Eclipse 启动在 Java vm 自变量（-vmargs）之后提供的自变量（例如，-data），则 Eclipse 将不会启动并且您将接收到"JVM 已终止。出口代码为 1"的错误。

在不同的 VM 上运行
在 J9 上运行 Eclipse
当在 J9 版本 1.5 上运行 Eclipse 时，建议使用以下 VM 选项：

eclipse.exe [eclipse arguments] -vm path_to_j9w.exe         -vmargs -ms:32 -mm:2048 -mo:32768 -moi:32768 -mca:32 -mco:128 -mx:2000000
当在 J9 版本 2.0 上运行 Eclipse 时，J9W 选择的缺省自变量应为合适的选项。但是，要覆盖 Eclipse 可执行文件以内部方式自动设置的参数，必须指定 -vmargs 不带任何参数，如下所示：

eclipse.exe [eclipse arguments] -vm path_to_j9w.exe -vmargs
有关进一步信息，参考 J9 VM 文档和帮助。

在 IBM Developer Kit, Java(TM) Technology Edition VM 上运行 Eclipse
IBM Developer Kit, Java(TM) Technology Edition 1.3 Linux 的缺省 VM 设置适合进行初期研究工作，但在进行大型开发时是不够的。对于大型开发，应修改 VM 自变量以使有更多的堆可用。例如，下列设置将允许 Java 堆增大为 256MB。

算法与我

当我在1980年转入计算机科学系时，还没有多少人的专业方向是计算机科学。有许多其他系的人嘲笑我们说：“知道为什么只有你们系要加一个‘科学’，而没有‘物理科学系’或‘化学科学系’吗？因为人家是真的科学，不需要画蛇添足，而你们自己心虚，生怕不‘科学’，才这样欲盖弥彰。”其实，这点他们彻底弄错了。真正学懂计算机的人（不只是“编程匠”）都对数学有相当的造诣，既能用科学家的严谨思维来求证，也能用工程师的务实手段来解决问题——而这种思维和手段的最佳演绎就是“算法”。

记得我读博时写的Othello对弈软件获得了世界冠军。当时，得第二名的人认为我是靠侥幸才打赢他，不服气地问我的程序平均每秒能搜索多少步棋，当他发现我的软件在搜索效率上比他快60多倍时，才彻底服输。为什么在同样的机器上，我可以多做60倍的工作呢？这是因为我用了一个最新的算法，能够把一个指数函数转换成四个近似的表，只要用常数时间就可得到近似的答案。在这个例子中，是否用对算法才是能否赢得世界冠军的关键。

还记得1988年贝尔实验室副总裁亲自来访问我的学校，目的就是为了想了解为什么他们的语音识别系统比我开发的慢几十倍，而且，在扩大至大词汇系统后，速度差异更有几百倍之多。他们虽然买了几台超级计算机，勉强让系统跑了起来，但这么贵的计算资源让他们的产品部门很反感，因为“昂贵”的技术是没有应用前景的。在与他们探讨的过程中，我惊讶地发现一个O(n*m)的动态规划(dynamic programming)居然被他们做成了O(n*n*m)。更惊讶的是，他们还为此发表了不少文章，甚至为自己的算法起了一个很特别的名字，并将算法提名到一个科学会议里，希望能得到大奖。当时，贝尔实验室的研究员当然绝顶聪明，但他们全都是学数学、物理或电机出身，从未学过计算机科学或算法，才犯了这么基本的错误。我想那些人以后再也不会嘲笑学计算机科学的人了吧！

网络时代的算法

有人也许会说：“今天计算机这么快，算法还重要吗？”其实永远不会有太快的计算机，因为我们总会想出新的应用。虽然在摩尔定律的作用下，计算机的计算能力每年都在飞快增长，价格也在不断下降。可我们不要忘记，需要处理的信息量更是呈指数级的增长。现在每人每天都会创造出大量数据（照片，视频，语音，文本等等）。日益先进的纪录和存储手段使我们每个人的信息量都在爆炸式的增长。互联网的信息流量和日志容量也在飞快增长。在科学研究方面，随着研究手段的进步，数据量更是达到了前所未有的程度。无论是三维图形、海量数据处理、机器学习、语音识别，都需要极大的计算量。在网络时代，越来越多的挑战需要靠卓越的算法来解决。

再举另一个网络时代的例子。在互联网和手机搜索，如果要找附近的咖啡店，那么搜索引擎该怎么处理这个请求呢？最简单的办法就是把整个城市的咖啡馆都找出来，然后计算出它们的所在位置与你之间的距离，再进行排序，然后返回最近的结果。但该如何计算距离呢？图论里有不少算法可以解决这个问题。

这么做也许是最直观的，但绝对不是最迅速的。如果一个城市只有为数不多的咖啡馆，那么这么做应该没什么问题，反正计算量不大。但如果一个城市里有很多咖啡馆，又有很多用户都需要类似的搜索，那么服务器所承受的压力就大多了。在这种情况下，我们该怎样优化算法呢？

首先，我们可以把整个城市的咖啡馆做一次“预处理”。比如，把一个城市分成若干个“格子(grid)”，然后根据用户所在的位置把他放到某一个格子里，只对格子里的咖啡馆进行距离排序。

问题又来了，如果格子大小一样，那么绝大多数结果都可能出现在市中心的一个格子里，而郊区的格子里只有极少的结果。在这种情况下，我们应该把市中心多分出几个格子。更进一步，格子应该是一个“树结构”，最顶层是一个大格——整个城市，然后逐层下降，格子越来越小，这样有利于用户进行精确搜索——如果在最底层的格子里搜索结果不多，用户可以逐级上升，放大搜索范围。

上述算法对咖啡馆的例子很实用，但是它具有通用性吗？答案是否定的。把咖啡馆抽象一下，它是一个“点”，如果要搜索一个“面”该怎么办呢？比如，用户想去一个水库玩，而一个水库有好几个入口，那么哪一个离用户最近呢？这个时候，上述“树结构”就要改成“r-tree”，因为树中间的每一个节点都是一个范围，一个有边界的范围（参考:http://www.cs.umd.edu/~hjs/rtrees/index.html）。

通过这个小例子，我们看到，应用程序的要求千变万化，很多时候需要把一个复杂的问题分解成若干简单的小问题，然后再选用合适的算法和数据结构。

并行算法：Google的核心优势

上面的例子在Google里就要算是小case了！每天Google的网站要处理十亿个以上的搜索，GMail要储存几千万用户的2G邮箱，Google Earth要让数十万用户同时在整个地球上遨游，并将合适的图片经过互联网提交给每个用户。如果没有好的算法，这些应用都无法成为现实。

在这些的应用中，哪怕是最基本的问题都会给传统的计算带来很大的挑战。例如，每天都有十亿以上的用户访问Google的网站，使用Google的服务，也产生很多很多的日志(Log)。因为Log每份每秒都在飞速增加，我们必须有聪明的办法来进行处理。我曾经在面试中问过关于如何对Log进行一些分析处理的问题，有很多面试者的回答虽然在逻辑上正确，但是实际应用中是几乎不可行的。按照它们的算法，即便用上几万台机器，我们的处理速度都根不上数据产生的速度。

那么Google是如何解决这些问题的？

首先，在网络时代，就算有最好的算法，也要能在并行计算的环境下执行。在Google的数据中心，我们使用的是超大的并行计算机。但传统的并行算法运行时，效率会在增加机器数量后迅速降低，也就是说，十台机器如果有五倍的效果，增加到一千台时也许就只有几十倍的效果。这种事半功倍的代价是没有哪家公司可以负担得起的。而且，在许多并行算法中，只要一个结点犯错误，所有计算都会前功尽弃。

那么Google是如何开发出既有效率又能容错的并行计算的呢？

Google最资深的计算机科学家Jeff Dean认识到，Google所需的绝大部分数据处理都可以归结为一个简单的并行算法：Map and Reduce（http://labs.google.com/papers/mapreduce.html）。这个算法能够在很多种计算中达到相当高的效率，而且是可扩展的（也就是说，一千台机器就算不能达到一千倍的效果，至少也可以达到几百倍的效果）。Map and Reduce的另外一大特色是它可以利用大批廉价的机器组成功能强大的server farm。最后，它的容错性能异常出色，就算一个server farm宕掉一半，整个fram依然能够运行。正是因为这个天才的认识，才有了Map and Reduce算法。借助该算法，Google几乎能无限地增加计算量，与日新月异的互联网应用一同成长。

算法并不局限于计算机和网络

举一个计算机领域外的例子：在高能物理研究方面，很多实验每秒钟都能几个TB的数据量。但因为处理能力和存储能力的不足，科学家不得不把绝大部分未经处理的数据丢弃掉。可大家要知道，新元素的信息很有可能就藏在我们来不及处理的数据里面。同样的，在其他任何领域里，算法可以改变人类的生活。例如人类基因的研究，就可能因为算法而发明新的医疗方式。在国家安全领域，有效的算法可能避免下一个911的发生。在气象方面，算法可以更好地预测未来天灾的发生，以拯救生命。

所以，如果你把计算机的发展放到应用和数据飞速增长的大环境下，你一定会发现；算法的重要性不是在日益减小，而是在日益加强。

周竞涛 (zhoujtnet@yahoo.com.cn)
王明微 (wangmv@hotmail.com)
西北工业大学CAD/CAM国家专业实验室
2003年9月

本文介绍了XML结合RDF实现Web数据基于语义的描述。
今天，越来越多的Web应用需要通过交换数据来实现互操作。XML的出现使实现Web应用之间的语法互操作成为可能，而RDF则可以借助XML来实现Web应用之间的语义互操作。那么XML和RDF是如何来完成它们各自职能的呢？
引言——语义

语义到底是指什么？这是一个比较难回答的问题，就像有人问起Ontology到底指什么一样。如果读者已经对Semantic Web有一些了解的话，就会知道语义是一个正在改变我们所熟悉的Internet的一个关键元素，甚至是提高全球经济发展效率不可或缺的重要元素[1]。本文并不是要给出语义的一个精确解释，因为这确实很困难，尤其当这个概念被不同领域所引用的时候，它的含义往往存在着一些差异。讨论语义的目的是希望我们能够更好地理解XML和RDF到底在数据表示和交换中起到什么作用，更清楚地看到XML和RDF之间的区别，各自的优点和不足。我们可以将语义简单地看作是数据（符号）所代表的概念的含义，以及这些含义之间的关系，是对数据的抽象或者更高层次的逻辑表示。对于计算机领域来说，语义一般是指用户对于那些用来描述现实世界的计算机表示的解释，即用户用来联系计算机表示和现实世界的途径。或许这听起来还是不够通俗，让我们通过一个的例子来进一步说明语义的含义：以关系数据库为例，数据库中的数据可以简单的认为是存储在一张张表中，例如我们将学生的基本信息存入到一张"学生"表中。这时，对于表中的每一列数据所构成的集合，其所隐含的意思就是该列数据所要表达的对应的概念，这个概念往往体现为设计人员对该列数据对应的属性所给定的名称，例如"姓名"、"性别"等等。这些属性之间的关系就相当于数据对应的概念之间所存在的关系，它们都是学生这个实体的属性。数据库表中的属性和关系都可以看作数据的语义信息。当然，语义并不是这么简单，它代表的关系可能更为复杂，甚至超过E-R模型等数据库建模语言的表达范围。其实语义并不是引入到IT领域的新概念，数据库长期以来已经在用语义来区分模式和数据，并作为数据库建模、查询和事务管理技术的一部分，语义是保证数据管理系统达到可扩展性、高效性和健壮性要求的一个关键元素。

数据表示中的语法与语义

在了解了什么是语义之后，让我们来进一步讨论语法和语义在数据描述和交换中的作用。事实上，数据交换所要达到的真正目的是得到所交换数据所代表的含义，实现数据在含义上的交换，而不是单纯的数据本身的交换，这同人与人之间的信息交换类似。对于人类来说，我们可以通过相同的语言进行交互，交互双方以他们所共同遵守的语言组织规律（相当于语法）对所要表达的信息含义（相当于语义）进行组织才能使对方理解。人与人之间信息的传达并不需要非常严格的语法，即便是对方在语言表达上存在着一定的错误，我们仍然可能理解对方所要表达的意思。但对于计算机之间的信息交换来说，语法与语义缺一不可。数据正确的语法表达是保证计算机之间能够进行信息交换和处理的前提，而数据语义的描述则是数据可被计算机正确理解和推理的基础。

对于今天的大部分计算机应用来说，其所产生的信息并没有采用统一的语法描述格式，信息在语法描述上存在着千差万别，这就造成了信息表达上的语法异构；而对于信息所代表含义（即语义）的解释，则是以硬编码的方式写入到了应用中，这种所谓程序式语义（procedural semantics）[2]的信息语义建模方法，分离了信息的语义和信息的语法描述，将对信息的理解固化到了特定的代码逻辑中。因此程序式语义有很大的局限，既不具备扩展性也不具备通用性，难于维护和集成。与程序式语义的信息建模方法相反，声明式的语义建模方法[2]通过将数据的语义描述与特定应用逻辑的分离，将数据的语义描述纳入到数据层，将数据语义的解释留给了通用的形式化系统（例如一阶逻辑，描述逻辑，Datalog等推理系统），而与具体的数据和应用逻辑无关，具有非常好的适应性、可重用性。数据基于语义的描述就是以声明式的语义建模方法对数据的语义进行描述。通过实现数据的语义描述可以大大减轻应用处理数据的压力。

XML——Web数据的语法描述标准

信息在语法描述上的差异，我们往往可以通过必要的数据格式转化来将信息转化为目标应用能够处理的语法格式。当然，更为理想的情况应该是所有的信息都采用同样的语法来描述，XML的出现使得不同类型的数据表示成同一格式成为了可能。XML已经成为了Web上数据表示和交换的事实标准，是应用之间或者机器之间共享数据的一种有效方式。XML及其相关技术的发展极大地促进了信息表达和交换过程中语法描述上的统一，越来越多的应用开始选用XML作为其数据、配置信息、消息以及服务的语法描述模式。迄今为止，XML已经成为了Web上最理想的数据表达方式。XML的可扩展性是XML区别其他标记语言的最基本特征。XML的核心在于以一种标准化的方式来建立数据表示的结构，而将具体标记的定义留给了用户。XML的可扩展性使XML可以满足各种不同领域数据描述的需要，并可以对计算机之间交换的任何数据进行编码。

XML是否已经足够

当我们刚刚接触XML时，我们可能会因为XML的表现能力，可扩展性和光明的前景而激动不已，可是随之而来的问题是：两个用XML表示的消息或数据，如何才能实现交换？是不是我们只要采用了XML格式，二者的交换就万事大吉了?。XML除了给我们提供了一个可以被应用自动化读取的格式外，并不能进一步促进数据交换的自动化程度，我们还需要通过专用的程序来对XML数据进行解释，以获取目标应用能够处理的数据部分。注意，这里的解释并不同于对XML文档的解析。当然，对XML文档解释的前提是首先完成对XML文档的解析。尽管XML已经拥有了各种版本的解析器，但解析器的真正作用是一个XML的读取和处理器，并不是一个解释器。因此我们必须采用特定的应用程序来对XML的内容解释，很显然这些程序之间并不存在互换性和通用性。

尽管XML的灵活性使得用户可以快速、容易的描述任意的内容，但由于XML并不能解释它标记的含义，大多数处理应用要求这些标记集合能够满足某种标准或者双方的约定。XML允许用户通过XML模式来定义这些标记的集合。XML模式（诸如XML DTD和XML Schema等）为XML文档提供了一种约束机制，用来限定XML文档所用到的标记和这些标记之间的结构关系。XML模式为XML文档提供了一定的语义描述能力，然而XML模式的语义仍然是隐含的。XML模式的元素含义要么由用户根据元素的名称（通过自然语言描述）去推断，要么通过另外一个文档来描述，XML模式并不能对其所含有的语义进行任何解释。

为了实现XML文档的解释或者转换，用户必须将这些语义编码到工具中，而将数据的最终解释留给了特定的应用。不仅如此，由于XML模式只能对XML的语法合法性进行验证，而不能区分XML属性和元素在含义上的不同，因此对于同样的信息内容，我们可以将其映射为多种不同的XML结构。例如我们要说明某本书（Book）的作者（Author）是哪个作家（Name），可以得到例1中的多种XML Schema的定义。

例1 对于同一信息的多个XML Schema的定义

XML实例  对应的DTD定义 

<Book id="B_id">
 <Author>  
  <Name id="A_id"/> 
 </Author>
</Book>

 
<xs:element name="Author">
 <xs:complexType>
  <xs:sequence>
   <xs:element ref="Name"/>
  </xs:sequence>
 </xs:complexType>
</xs:element>
<xs:element name="Book">
 <xs:complexType> 
  <xs:sequence> 
   <xs:element ref="Author"/>
  </xs:sequence>
  <xs:attribute name="id" type="xs:string" use="required"/>
 </xs:complexType>
</xs:element>
<xs:element name="Name">
 <xs:complexType>
  <xs:attribute name="id" type="xs:string" use="required"/>
 </xs:complexType>
</xs:element>
</xs:schema>

<Book id="B_id">
 <Author>
  <Name>
   <id>A_id</id>
  </Name>
 </Author>
</Book>

 
<xs:element name="Author">
 <xs:complexType>
  <xs:sequence> 
   <xs:element ref="Name"/>
  </xs:sequence>
 </xs:complexType>
</xs:element>
<xs:element name="Book">
 <xs:complexType> 
  <xs:sequence> 
   <xs:element ref="Author"/> 
  </xs:sequence>   
  <xs:attribute name="id" type="xs:string" use="required"/>
 </xs:complexType> 
</xs:element> 
<xs:element name="Name">
 <xs:complexType> 
  <xs:sequence> 
   <xs:element ref="id"/> 
  </xs:sequence> 
 </xs:complexType> 
</xs:element>
<xs:element name="id" type="xs:string"/>

<Book>
 <id>B_id</id>
 <Author>
  <Name>
   <id>A_id</id>
  </Name>
 </Author>
</Book>

 
<xs:element name="Book">
 <xs:complexType> 
  <xs:sequence> 
   <xs:element ref="id"/> 
   <xs:element name="Author">
    <xs:complexType>
     <xs:sequence> 
      <xs:element name="Name"> 
       <xs:complexType>
        <xs:sequence>
         <xs:element name="id"/>
        </xs:sequence>
       </xs:complexType>
      </xs:element>
     </xs:sequence> 
    </xs:complexType>
   </xs:element>
  </xs:sequence> 
 </xs:complexType>
</xs:element>

这种数据表达上的不唯一性意味着，相同的XML文档可以存在多种不同的解释，而相同的应用也可能对不同的XML作出同样的解释。这种解释上的多对多关系，使得我们在交换XML文档之前，必须对其所使用到的标记的名称、组织格式和含义进行约定，任何对该XML文档的单方面扩展都可能会给数据交换过程带来更多的麻烦，甚至导致失败。然而，这种通过约定来实现信息共享的方式只适用于两两之间的信息交换，却不能满足Web上多个用户或团体大范围的信息共享。假设我们要集成n个应用所产生的XML信息，即便是要集成部分的含义完全一致，但由于它们来自不同的应用，各自的XML模式描述很可能存在着不同（既包括标记命名的不同也包括结构组织上的不一致），所以我们仍然不得不做大量的模式之间的转换，而目的只是为了保证它们在语法的描述结果上保持一致。当然我们可以通过采用一个统一的全局的XML模式来描述所有相关的XML信息，但这显然是不现实的，即便是在一个企业内部，我们也很难建立一个稳定的标准化的企业数据表示模式。

RDF(Resource Description Framework)——Web数据的语义描述模型

XML所存在的问题是因为XML不具备语义描述能力。为此，W3C推荐以RDF(resource Description Framework)标准来解决XML的语义局限。RDF提出了一个简单的模型用来表示任意类型的数据。这个数据类型由节点和节点之间带有标记的连接弧所组成。节点用来表示Web上的资源，弧用来表示这些资源的属性。因此，这个数据模型可以方便的描述对象（或者资源）以及它们之间关系。RDF的数据模型实质上是一种二元关系的表达，由于任何复杂的关系都可以分解为多个简单的二元关系，因此RDF的数据模型可以作为其他任何复杂关系模型的基础模型。

RDF和XML是互为补充的。首先，RDF希望以一种标准化，互操作的方式来规范XML的语义。XML文档可以通过简单的方式实现对RDF的引用。如例2所示。

例2 XML对RDF的引用示例

<?xml version="1.0"?>
 <Description  
  xmlns="http://www.w3.org/TR/WD-rdf-syntax#"              
   about="http://www.w3.org/test/page"      
    s:Author ="http://www.w3.org/staff/Ora"/>

借助RDF，表达同一事实的XML描述就可以被转化为统一的RDF陈述。对于例1，它们可以表示为下面的RDF模型：

通过在XML中引用RDF，可以将XML的解析过程与解释过程相结合。也就是说，RDF可以帮助解析器在阅读XML的同时，获得XML所要表达的主题和对象，并可以根据它们的关系进行推理，从而做出基于语义的判断。XML的使用可以提高Web数据基于关键词检索的精度，而RDF与XML的结合则可以将Web数据基于关键词的检索更容易地推进到基于对象的检索。

其次，由于RDF是以一种建模的方式来描述数据语义的，这使得RDF可以不受具体语法表示的限制。但是RDF仍然需要一种合适的语法格式来实现RDF在Web上的应用。虽然RDF（模型）既可以用Notation3[3]来表示，也可以用XML来表示。但是，由于XML已经成为被广泛支持的Web数据表示标准，便于应用的读取，因此将RDF序列化为XML表示可以使RDF获得更好的应用可处理特性，并使得RDF数据可以像XML数据一样的容易使用、传输和存储。

因此，RDF是定制XML的良伴，而不只是对某个特定类型数据的规范表示[4]，XML和RDF的结合，不仅可以实现数据基于语义的描述，也充分发挥了XML与RDF的各自优点，便于Web数据的检索和相关知识的发现。

RDF是否已经足够

与XML中的标记（tags）类似，RDF中的属性（properties）集也是没有任何限制的。也就是说我们既可以<rdf:Description about=http://www.w3.org/test><s:Creator>张三</s:Creator></rdf:Description>也可以用<rdf:Description about=http://www.w3.org/test1><s:Author>张三</s: Author ></rdf:Description> 来表示某个作品的创作者。这就是我们通常所说的同义词现象，即同一个概念可以以不同的词汇来描述。在实际应用中这个词汇并不一定要和词典中的词汇有一定的对应关系，例如英文语法中常见的缩写就属于此种情况。与同义词现象相对应的另一个问题就是一词多意，即同一个词汇在不同的应用背景下可以表示不同的意思。RDF的模型不具备解决这两个问题的能力，而RDF Schema虽然可以为RDF资源的的属性和类型提供词汇表，但是基于RDF的数据语义描述仍然可能存在语义冲突。为了消解语义冲突，我们在描述数据语义的时候可以通过引用Ontology的相关技术，对语义描述结果作进一步的约束。幸运的是，RDF(Schema)在提供了简单的机器可理解语义模型的同时，为领域化的Ontology语言（OIL（Ontology Interchange Language），OWL（Web Ontology Language））提供了建模基础，并使得基于RDF的应用可以方便地与这些Ontology语言所生成的Ontology进行合并。RDF的这一特性使得基于RDF的语义描述结果具备了可以和更多的领域知识进行交互的能力，也使基于XML和RDF的Web数据描述具备了良好的生命力。

参考资料

Amit Sheth, Robert Meersman. Amicalola Report: Database and Information Systems Research Challenges and Opportunities in Semantic Web and Enterprises. SIGMOD Record Special Issue on Semantic Web, Database Management and Information Systems, December 2002.充分讨论了Semantic Web的发展给多个领域所带来的机遇和挑战。
Stefan Decker, Sergey Melnik, Frank Van Harmelen, Dieter Fensel, Michel Klein, Jeen Broekstra, Michael Erdmann, and Ian Horrocks. The semantic web: The roles of xml and rdf. IEEE Expert, 15(3), October 2000. 该文论述了XML和RDF在Semantic Web中的不同角色和各自的作用。
SEAN B P. The Semantic Web: An Introduction [EB/OL]. http://infomesh.net/2001/swintro, 2001-09.对Semanitc Web的介绍。
Uche Ogbuji.Generate RDF using XSLT.http://www-106.ibm.com/developerworks/library/x-think4/ , July 1, 2001. 讨论如何从已有的XML 格式数据转化为RDF模型的描述，突出了RDF 可用作定制 XML 的搭挡，而不仅仅用作某些数据类型的规范表示的观点。
[tttt]Tim Berners-Lee. Why RDF model is different from the XML model. http://www.w3.org/DesignIssues/RDF-XML.html September 1998 主要从查询的角度来比较XML于RDF。
Graham Klyne. Information Modelling using RDF - Constructs for Modular Description of Complex Systems. citeseer.nj.nec.com/422203.html. 该文介绍了以RDF对复杂系统建模的一些实验性工作。
Uche Ogbuji. Thinking XML # 1: XML和语义：实际情况： 介绍了语义透明性的思想，讨论了XML 相关开发的重要性。

关于作者

周竞涛，西北工业大学CAD/CAM国家专业实验室博士研究生，致力于将哲学、数学结合到技术研究中，主要研究方向：中间件、XML技术、EII、Semantic Web Service。 曾多次在国内外发表与XML和语义相关的学术论文。部分论文被SCI和ISTP索引。可以通过zhoujtnet@yahoo.com.cn与他联系。

王明微，陕西西安，西北工业大学CAD/CAM国家专业实验室硕士研究生，研究方向：逆向工程、模式识别。可以通过wangmv@hotmail.com与他联系。