注： 这篇文章涉及到语义网的不同的部分以及它们是如何组合在一起的。如果要从高层次的角度来看这个问题，请看Sandro Hawke的《语义网（简明）》。另一方面，如果你是一个对建立语义网站或者语义web服务感兴趣的网络开发人员，请参见《语义网（网络开发人员用 书）》。现在回到你正常的阅读进度上来。
标识符：统一资源标识符（URI）
如果我要讨论某事物，首先我必须标识它。否则， 你怎么知道我指的是什么？也许我用一种间接的方式来表达“北极星”，“食品杂货店里的一个陌生人”，“那些Bob总是在吃的非常酸的糖果”。也许我也会用 一种更加直接的方式“Jonathan Roberts”，“Mega Warheads”。
我们也用标识符来标识网上的项目。因为我们使用一种 标识符的统一的系统，并且因为每一个被标识出来的项目被认为是一种“资源”，所以我们称这些标识符为“统一资源标识符”或者简称为URIs。我们能够给任 何事物一个URI，并且任何有一个URI的事物可以被认为“在网上”：你，你上周买的书，在你耳边嗡嗡作响的飞虫和任何你能想到的其他事物——它们都能有 一个URI。
URI是网络的基础。几乎网络的其他每一个部分都可以被取代，URI不行：它将网络的其他部分结合在一起。
也许你已经熟悉了URI的一种形式：URL或者统一资源定位符。URL是一个让你访问一个网页的地址，例如：http://www.w3.org/Addressing/。 如果你将它分解开来看，你可以看到一个URL告诉你的电脑到哪里去找一个特别的资源（在这个例子中，W3C的网址）。与其他多数形式的URIs不一样， URL既标识又定位。与一种叫做“mid:”的URI相反，一个“mid:”URI标识一个Email消息，但是它不能为你定位这个消息的一个副本。
因为网络太大，没有任何一个组织能够控制它，所以URIs是分散的。没有一个人或者一个组织来控制谁建立它们或者它们如何使用。一些URI scheme（如http:）依赖于集中的系统（如DNS），其他的格式（比如说freenet:）则完全是分散的。
这 就意味着创建一个URI你不需要得到任何一个人的允许。你甚至能够给一件不属于的你的东西创建一个URIs。这些灵活性使得URIs非常强大的同时也给它 带来了一些问题。因为任何一个人都能创建一个URI，我们不可避免的遇到多个URIs代表同一个事物的问题。更严重的是，没有办法来指出两个URIs是否 确切的指代同一个资源。结果，我们永远不能够确切的说出一个给定的URI代表着什么。但是如果我们要创建像语义网这样巨大的事物，这些是必须做出的折中。
创 建URIs通常的实践是从一个网页开始。网页描述了需要被标识的对象并解释说这个网页的URL就是这个对象的URI。例如，我要为我的那本Tim Berners-Lee所著的《编织万维网》创建一个URI。首先，我建立一个网页来描述我的这本书。然后在那个网页上注明网页的网址就是我的那本书的 URI。这样做，我已经将URI（http://logicerror.com/myWeavingTheWeb)）与我的那本《编织万维网》联系在了一起。创建一个URI能够就像这么简单。
也许你已经注意到在这个实例中URI（http://logicerror.com/myWeavingTheWeb）有两个功能：它同时代表那本物质实体的书和描述书的网页。这是一些讨论所关注的领域——它被称为“语义网识别问题”，它也是语义网工作人员反复讨论的焦点。
下 面是一个需要理解的重要事实。一个URI并不是告诉你的电脑如何在网上获得特定文件的方法的集合（尽管也许它能够做到这一点）。它是一个“资源”（一件事 物）的名称。这个资源也许能也许不能在网上获得，URI也许会也许不会向你的电脑提供获得资源的更多信息的途径。诚然，URL是一种确实能够提供一种方法 获得关于某资源的信息，或者它自己去检索资源，但是其它的用于提供关于URIs的信息和它们所标识的资源的方法仍然在研究过程中。说明URIs所指示的事 物的能力也是语义网非常重要的一个部分的说法也是正确的，但是你不能认定一个URI除了唯一给资源提供标识符外还能做其他任何事。
文档：可扩展标记语言（XML）
人 们设计XML是希望通过一种简单的方式通过网络发送文档。它允许任何人设计自己的文档格式然后按照那种格式书写一个文档。这些文档格式能够包括标记来突出 文档内容的含义。这些标记是“机器可读的”，也就是说，程序能够读取并理解它。通过在我们的文档里包括机器可读的含义，我们使得它们更加强大。
考 虑这样一个简单的例子：如果一个文档包含被标记为“强调”的词，这些词呈现出来的方式能够与上下文相符合。一个web浏览器也许只是简单的用斜体字来显 示，而一个声音浏览器（大声读出网页的工具）也许通过改变语调或者音量来表明这些强调。相反的，如果我简单的将这些词标记为“斜体字”，计算机没有办法知 道为什么这些词是斜体。它是用来强调还是单单为了视觉效果？声音浏览器如何表达这个效果？
下面是一个用纯文本书写的文档的例子：
我刚刚得到了一只新的宠物狗。
就你的电脑而言，这只是一个文本。对于电脑，它没有任何特别的意思。但是现在来考虑这个用基于XML的标记语言标记出来的相同的段落（我们为了这个例子自己创建了标记）
<sentence>
<person href="http://aaronsw.com/">我</person> 刚刚得到了一只新的宠物 <animal>狗</animal>. </sentence>
注 意这段话和上面的有相同的内容，但是内容的一部分被标记了。每一个标记由两个“标签”组成：一个开标签 （如：<sentence>）和一个闭标签（如：</sentence>）。标签的名字（“sentence”）是两标签之间内 容的标记。我们称这些标签和其内容为一个“元素”。这样，上面的文档中sentence这个元素包含句子，“我刚刚得到一只新的宠物狗。”这告诉电脑“我 刚刚得到一只新的宠物狗。”是一个“句子”，但重要的是，它没有告诉电脑“句子”是什么。尽管如此，电脑现在获得了关于文档的一些信息，我们能够使用这些 信息。
相似的，电脑现在知道“我”是一个“人”（不管“人”是什么），“狗”是一只“动物”。有时，除了单单提供元素名以外提供关于元素的内容的 更多的信息是非常有用的。例如，电脑知道上面句子中的“我”代表一个人，但是它不知道是哪个人。通过给我们的元素增加一个“属性”，我们能够提供这种信 息。“属性”既有名字又有值。例如，我们能够这样重写我们的例子：
<sentence>
<person href="http://aaronsw.com">我</person> 刚刚得到了一只新的宠物 <animal type="dog" href="http://aaronsw.com/myDog">狗</animal>.
</sentence>

为 了避免冲突，我必须唯一的“标识”我的标记元素。还有什么比使用统一资源标识符来它们更好的方法吗？因此，我为我的每一个元素和属性指派一个URI。我使 用被称为“XML名称空间”的东西来实现。这样，任何人都能够创建他们自己的标签并和其他人创建的标签混合使用。名称空间只是把网络（空间）的一部分和被 我们剥夺了名称的意义的东西区分开来的一种方式。我通过给它创建一个URI来为我的标记语言建立一个“名称空间”（就如我们前文所说，我也许会建一个网页 来描述我的标记语言，并且使用这个网页的网址作为我的名称空间的URI）
既然每个人的标签有它们自己的URI，我们不必为标签名冲突而担心。当然，XML会让我们工作更简单，并且可以让我们设置默认的URIs，这样，我们不必每次都将它们打出来：
<sentence
xmlns="http://example.org/xml/documents/"
xmlns:c="http://animals.example.net/xmlns/"><c:person c:href="http://aaronsw.com/">我</c:person>刚刚得到了一只新的宠物<c:animal>狗</c:animal>.</sentence>

声明:资源描述框架（RDF）
现 在，我们开始进入语义网的话题。我们能够创建URI并且在我们的网页上讨论它们是一件非常奇妙的事情。然而，如果我们能够用一种电脑能够处理我们所说的话 的方式来谈论它们将会更加奇妙。例如，在一个网络讨论版上说“我非常喜欢《编织万维网》”是一件事。但是这对于电脑意味着什么？
RDF向我们提供 一种机器可以处理的方法来做出声明。现在电脑不能真正“理解”你说什么，当然，但它能够以一种像是“理解”的方式来处理它。例如，我能够在网上搜索所有的 书评并为每一本书创建一个平均的等级。然后，我会把这些信息放回到网上。另一个网站能够使用这个信息（书平均等级的列表），并创建一个“等级最高的十本 书”的网页。
RDF确实非常简单。除了所有的词都是URI外，一条RDF声明非常像一个简单的句子。每一条RDF声明都有三个部分：一个主语，一个谓词和一个宾语。我们来看一个简单的RDF声明:
<http://aaronsw.com/> <http://love.example.org/terms/reallyLikes> <http://www.w3.org/People/Berners-Lee/Weaving/>
你 能够猜出这句话说的是什么吗？第一个URI是主语。在这个例子中，主语是我。第二个URI是谓词。它将主语和宾语联系在一起。在这个例子中，谓词是“非常 喜欢（realyLikes）”，第三个URI是宾语。这里，宾语是Tim Berners-Lee的书《编织万维网》（Weaving the Web）。所以上面的RDF声明说的是“我非常喜欢《编织万维网》”。
你也许注意到RDF声明几乎能够说任何事，并且它并不在乎是谁说了这些。没 有任何一个官方的站点说出关于《编织万维网》的每一件事或者关于我的每一件事。这向我们传达了一条重要的RDF原理，名字叫“任何事物能够说关于任何事物 的任何事物”。信息是通过网络来传播的。两个人甚至能够说处完全相反的事——Bob说Aaron爱《编织万维网》，但是John却说Aaron恨它。这是 网络所提供的自由。
上面的陈述是用三元组写的，三元组是一种允许你写简单RDF声明的语言。然而，正式的RDF规范定义了RDF的XML表示法，这种方法更复杂一点，但是表达相同的事
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:love="http://love.example.org/terms/"
>
<rdf:Description rdf:about="http://aaronsw.com/">
<love:reallyLikes rdf:resource="http://www.w3.org/People/Berners-Lee/Weaving/" </rdf:Description>
</rdf:RDF>
现在，像那样书写RDF并不是世界上最简单的事，似乎不可能每个人都会很快的开始说这种奇怪的新语言。那么，我们期待着从哪里获得这些RDF信息呢？最有可能的来源是数据库。
世 界上有数以千计的数据库，大多数包含着有趣的机器可处理的信息。政府在数据库中储存着逮捕记录；企业在数据库中存储着零件和存货信息；大多数计算机化的地 址本在——你猜什么地方——数据库中存储着人们的名字和电话号码。当信息存储在数据库中的时候，问计算机关于数据的某个问题是非常简单的：“给我显示出过 去六个月中逮捕的每一个人”，“打印出我们正在减少的所有零件的记录”，“给我姓Jones的人的电话号码”。
RDF非常完美的适合将这些数据库 发布到网上。当我们把它们放到网上的时候，我们为数据库里的每个东西赋予一个URI。这样，其他人也能谈论它。现在，智能程序能够将这些数据组合在一起。 通过使用这些可用的信息，电脑能够开始将你地址本里的Bob Jones和上周被逮捕的Bob Jones以及刚订了100,000个零件的Bob Jones联系在一起。现在，我们能一下子向所有这些数据库提问：“给我每个订了超过100,000个零件并且过去六个月被逮捕的人的名单”。
Schema和本体：RDF Schemas, DAML+OIL, 和 WebOnt
关 于数据库的所有工作假定数据是几乎完美的。但是，很少的（如果有的话）数据库系统对于网络的混乱是有所准备的。当新的术语被发明和定义，任何“硬编码”以 理解特定术语的系统都将可能过时，或者至少其应用受到了限制。如果有人开发了一个使用1-10的指标评价书的新系统而不是只是说有人“非常喜欢”它们会怎 么样？基于旧系统的程序将不能处理新的信息。
更严重的是，对于人或者电脑来说没有办法指出一个特定的术语是什么意思，或者它应该怎样使用。如果我 们从来都不描述URIs的含义，它们将是毫无用处的。这就是为什么要引进schema和本体。schema和本体是描述术语的含义及其关系的方法。这些描 述（当然是用RDF表达出来的）帮助电脑系统更容易的使用术语，决定如何在转换这些术语。
人们已经开发了两个密切相关的系统，RDF Schemas 和 带有本体接口层的DARPA智能描述语言（DAML+OIL）来解决这个问题。例如，一个schema这样说：
@prefix dc: <http://purl.org/dc/elements/1.1/> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
# A creator is a type of contributor: dc:creator rdfs:subClassOf dc:contributor .
（这里我们使用允许我们使用起来更缩略的三元组的超集Notation3）
这 是说创建者是有贡献者的一个子集。这有什么用？好，我们来举个例子：你设计了一个程序收集各种文档的创建者和有贡献者。你的程序用这个词汇(dc: creator 和 dc:contributor) 来理解它找到的信息。一天，大量的来自AOL的新手开始创建RDF文档。他们中没有人知道dc:creator，因此，他们建立自己的术语ed: hasAuthor
# The old way:
<http://aaronsw.com/> is dc:creator of <http://logicerror.com/semanticWeb-long>

# The new way:
<http://logicerror.com/semanticWeb-long> ed:hasAuthor <http://aaronsw.com/> .
正常情况下，你的程序将简单的忽略这些新声明，因为它不能理解它们。然而，一种灵魂非常的聪明以至于通过提供如何在它们之间转换的信息在这两个世界建立了桥梁：
# [ X dc:creator Y] is the same as [ Y ed:hasAuthor X] dc:creator daml:inverse ed:hasAuthor .
这 告诉你的程序ed:hasAuthor与dc:creator是相反的，这意味着你的程序所需要做的事就是交换主语和宾语并将ed:hasAuthor变 为dc:creator。既然你的程序理解DAML本体，它现在获取这个信息并使用它处理所有它以前并不理解的hasAuthor声明。
到2001年9月3日，W3C在准备开始一个网络本体（WebOnt）工作组（有些人称之为WOW-G）。这个组织被授权在RDF Schema 和 DAML+OIL的工作的基础上建立网络本体语言。这个组织将开发出什么非常有趣的事，我们拭目以待。
逻辑
从现在开始，我们将讨论语义网尚未开发出来的部分。不像上面讨论的那样，我不是在讨论特定的系统，而是讨论可能成为（正在成为）很多不同系统的基本概念。
有可用来理解那些基本概念（子类，相反等等）系统是非常好的一件事，然而我们能够声明任何的原理并允许电脑使用这些原理来推理是一件更好的事。
这里有个例子：我们说一家公司决定，如果有人售出超过100件我们的产品，那么他将是超级销售人员俱乐部的一员。一个聪明的程序能够遵照这个规则作简单的推理：“John已经卖出了102件商品，因此，John是超级销售人员俱乐部的一员”。
证据
一旦我们建立遵照逻辑的系统，使用它们来证明事情才有意义的。全世界的人都能够书写逻辑声明。你的机器然后就能够按照这些语义“链”建立证据。
例： 企业销售记录显示Jane已经售出55个小部件和66个链轮齿。存货系统说明小部件和链轮都是不同的公司产品，固有的数学规则说明55 + 66 = 121并且121大于100。并且，据我们所知，销售超过100件产品的人是超级销售人员俱乐部的一员。电脑将这些所有的逻辑规则放到一起形成证据，表明 Jane是是超级销售人员俱乐部的一员。
建立这些证据是困难的（这需要遵循数以千计，或者可能是数以百万计的语义网中的“链”），相比之下，检查 它们是很简单的。这样，我们开始建立信息处理者的网络。他们其中的一些仅仅为其他人提供数据以供使用。其他人更聪明一些，使用这些数据建立规则。最聪明的 是按照所有这些规则和声明获得结论，并恰当的将他们的结果放回到网络（包括纯文本的老数据）中作为证据的“启发式引擎”。
信赖：数字签名和信赖网
现在你也许已经想到这整个的计划是伟大的，但是如果任何人能够说任何事它将是毫无用处的。谁能够相信这样的系统？你就不会让我进你的站点？好，我只要说我是世界之王并且我是被授权的。按照“任何事物能够说关于任何事物的任何事物”的规则，谁能够阻止我？
这 就是为什么需要数字签名。基于数学和密码学，数字签名提供证据表明某个人书写了（或者认同）一篇文档或者一段声明。啊哈！因此我用数字化的方法给我的所有 的RDF陈述签名。那样，你能够确定我书写了它们（或者至少说我担保它们的真实性）。现在，你简单的告诉你的程序相信谁的签名不相信谁的签名。每个人都能 设定自己的等级或者信赖（妄想），电脑能够决定多大程度上相信所读到的东西。
现在你足够相信人们并让他们利用网上的大多数东西是非常不可能的。那 就是为什么需要“信赖网”。你将告诉你的电脑，你信赖你的最好的朋友Robert。Robert突然成了网上相当走红的一个人，并且信赖很多人。当然，所 有他信赖的人信赖其他一组人。每个这些人又信赖其他一组人等等。当这些信赖关系从你身边扩散开来，它们形成了“信赖网”。每一个这些关系中的人通过它有一 定程度的信赖（或者不信赖）。
注意不信赖和信赖一样有用。假定你的电脑发现一篇没有人显式的表明信赖也没有人显式的表明不信赖的文档。最有可能的是，相比于对一篇显式的表明不可信赖的文档，你的电脑更信赖这篇文档。
当决定一段信息有多大程度的可信度时，电脑将考虑所有这些因素。它也能够按照你所期望的透明的或者不透明的作出处理。例如，你也很喜欢一个简单的“赞许或者不赞许”的显示。另外有些人坚持用一种复杂的解释，包括所有包含在决定中的描述。
Tim Berners-Lee刚按了“Oh, yeah? ”这个按钮，点击那个按钮时你的电脑被要求尝试提供相信这些数据的原因。但是你是否自己决定或者把它留给你的电脑，所需的用来作出这个决定足够的信息可以通过信赖网获得。
结论：盛大的景象
关 于网络最好的事就是对于这么多不同的人来说，它是这么样的不同。即将出现的语义网将是这种多样性增加数以千倍。对于一些人来说，语义网的这些定义出来的特 点将使你的生活变得很轻松。通过它，你的PDA，你的笔记本电脑，你的台式机，你的服务器和你的汽车将彼此通讯。对于其他人，它将使企业决策自动化避免枯 燥的手工处理。对于另外的人，它将是评定网上文档的可信度的能力，我们将感觉到非常轻松的就能够获取我们的问题的答案——而这目前来说使充满着沮丧。
不管原因是什么，几乎所有的人都能够发现原因来支持这个语义网的盛大的景象。当然，通往那里有很长的路要走——我们也不能保证我们将会实现它——但是我们已经取得了很大的进步。可能是无止境的，即使我们什么也不能实现，这段旅程将会使它自身最大的酬劳。

<完>
参与讨论本主题

关于973计划“语义网格的基础理论、模型与方法研究”和“证候规范与疾病、方剂相关的基础研究”项目立项的通知

教育部、中国科学院、国家中医药管理局：

按照国家重点基础研究发展计划（简称973计划）的总体部署，经研究决定，批准“语义网格的基础理论、模型与方法研究”和“证候规范与疾病、方剂相关的基础研究”两个项目立项，现就有关事项通知如下：

一、聘任诸葛海同志为“语义网格的基础理论、模型与方法研究”项目首席科学家，中国科学院为项目依托部门，项目实施期限5年（2004年9月-2009年8月）。

二、聘任王庆国同志为“证候规范与疾病、方剂相关的基础研究”项目首席科学家，教育部、国家中医药管理局为项目依托部门，项目实施期限5年（2004年9月-2009年8月）。

请有关单位按照《国家重点基础研究发展规划项目管理暂行办法》、《国家重点基础研究专项经费财务管理办法》认真做好项目实施工作。

二〇〇四年九月十七日



<完>
参与讨论本主题

版权开放，欢迎转载 copyleft 2003, hax<hax@sjtu.edu.cn>.

========================
术语译名：

RDF model RDF模型
RDF statement RDF语句
literal 文字常量
namespace 命名空间

table 表
field 字段
========================

本页概述了当前在关系数据库里存储RDF的几种方法，
*THIS IS A REQUEST FOR COMMENTS*，请将您的想法投稿
到 (www-rdf-interest@w3.org)！

动机（Motiviation）
-------------------

我们需要永久存储和操作（大量的）RDF数据。一个可选的做法是使
用关系数据库技术。这个方法的主要优点是它提供了一个可升级的
通用方案。

准则（Criteria）
----------------

这个不完全的列表指出了数据库模式设计需要考虑的准则（无先后顺序）：

* 可伸缩性：我们能存储和查询超过十亿(1B+)的triples吗？
* 查询：支持哪一类的查询？它们可以被容易的公式化表述和处理吗？
* 效率：查询的耗费多大？交付查询结果的耗费呢？
* 优化：我们能如何处理refication？
* 组织：怎样在存储数据之上建立关联？我们能对RDF models进行
易分辨的混合并仍能确定triples来自何处吗？

以下的提议方案从不同方面满足上述准则。本页的维护者对可伸缩性
问题尤感兴趣。请将反映你需求的准则提交给我！

出版物（Publications）
----------------------

下面这个论文讨论了以垂直模式存储和查询稀疏的关系表，这与一些
提议方案的精神非常相似：

R. Agrawal, A. Somani, and Y. Xu: Storage and Querying of
E-Commerce Data, Proc. VLDB 2001, Roma, Italy, available as
http://www.vldb.org/conf/2001/P149.pdf

存储RDF的数据库模式
-------------------

（最近的投稿在前）

清晰的模型（Explicit models）
-------------------------------

贡献者：Brian MacBride<bwm@hplb.hpl.hp.com>

日期：2000/5/11

摘要：本表示法清晰的表现模型并使用了视图

数据库模式（Oracle）和作者的描述：

sql = "CREATE TABLE RDFRESOURCE"
+ "("
+ "Id INTEGER not null primary key,"
+ "NS INTEGER not null,"
+ "RoName varchar(255)"
+ ")";

资源表保存所有的资源，Id是内部的标识符字段，NS是个指针，指向
namespace表的条目以给出资源的命名空间。RoName应该叫做‘localname’，
是Qname的局部命名部分。

sql = "CREATE TABLE RDFNameSpace"
+ "("
+ "Id INTEGER not null primary key,"
+ "NsName varchar(255)"
+ ")";

命名空间表。

sql = "CREATE TABLE RDFLiteral"
+ "("
+ "Id INTEGER not null primary key,"
+ "VAL varchar (4000)"
+ ")";

literals [hax注：可译作文字常量] 表。 4000字符的限制对当前目
标来说足够。[hax注：Oralce的可变字符串的上限是4000字节]

sql = "CREATE TABLE RDFStatement"
+ "("
+ "Id INTEGER not null primary key,"
+ "Subject INTEGER not null,"
+ "Predicate INTEGER not null,"
+ "ObjResource INTEGER not null,"
+ "ObjLiteral INTEGER not null,"
+ "Res CHAR(1) not null"
+ ")";

Statement [hax注：可译作语句或陈述] 表。最初是单个对象字段，
可以有一个对象或者文字常量的ID。使用一个复杂的JOIN表达式来列
举陈述，但并不如期望的运行。可能是我对SQL经验不足。而这个工
作和感觉更“正确”。Res是一个标志以说明对象是资源还是文字常
量。

sql = "CREATE TABLE RDFModel"
+ "("
+ "ModelId INTEGER not null,"
+ "Statement INTEGER not null,"
+ "Asserted CHAR(1) not null,"
+ "Reified CHAR(1) not null,"
+ "primary key(ModelId, Statement)"
+ ")";

数据库可以处理多个models [hax注：可译作模型]。这个表保存了每
个模型的语句列表。最初该表由语句表组合，但当执行集合操作时不
能工作。

Asserted标志说明该语句用于给模型作断言。
Reified标志说明该模型用于使模型具体化。
后者是留给未来实现的挂钩（hook）。具体化（Reification）没有
被实现，因此这个方法是未经测试的。

每个模型都是资源，并在资源表里有一个记录。ModelId字段是该资
源的标识符。这样，就可以写关于某个模型的语句。这里有一个模型
的类，这样可以在确认模型有效性时列出需要被加载的模式（schemas）。

sql = "CREATE OR REPLACE VIEW RootModel"
+ " AS SELECT UNIQUE Id, Subject, Predicate,
ObjResource, ObjLiteral, Res, Asserted, Reified"
+ " FROM RDFModel, RDFStatement"
+ " WHERE RDFModel.Statement = RDFStatement.Id";

这创建一个人造的模型视图，包含数据库里所有的语句，无论语句在
哪一个“实际的”模型里。

视图被大量使用。每个模型都是一个视图，即一个在其他模型视图或
者RootModel视图之上的查询。因此每次Stanford API 调用一个创建
模型的操作——如某个查询，数据库里就创建一个新的视图。这必然
会导致一些对数据库的查询引擎来说异乎寻常的查询，而我就依靠数
据库的查询优化器来整理之。这里也存在因陈旧失效的视图被留在数
据库里而可能的应用崩溃问题。

sql = "CREATE TABLE RDFKEYS"
+ "("
+ "TableName char(10) not null primary key,"
+ "Key INTEGER not null"
+ ")";
sql = "INSERT INTO RDFKEYS (TableName, Key)
valueS('Resource', 0)";
sql = "INSERT INTO RDFKEYS (TableName, Key)
valueS('NameSpace', 0)";

一个键发生表。可能可以使用序列器（sequencer） [hax注：Oracle
使用序列产生自动递增或循环的数字]，但看起来有点数据库特性相
关，至少不是我一开始想要的，尽管真的只需要一个发生器。

关于模式（schemas）有个问题。当前，模式像模型一样处理，并可以
输入到模式有效性校验器。没有尝试使用模式来定义一个更特殊的数
据库结构。


<完>
参与讨论本主题

@prefix earl: <http://www.w3.org/2001/03/earl/0.95#> .
@prefix p3p: <http://www.w3.org/2000/07/p3pmodel/p3prdfschema#> .
@prefix : <http://myns.org/3/#> .

:G {:Validator a earl:Tool, earl:Assertor;
p3p:uri <http://validator.w3.org/html>;
earl:operator :Sean .
:Sean earl:email <mailto:sean@w3.uk>;
a earl:Person .

}

:G2 {:MyPage earl:testSubject <http://example.org/page> .
:fails earl:validity earl:Fails;
earl:date "2001-03-17" .
:ULTest
earl:test <http://w3.org/html4/testassertion123>;
earl:testMode earl:Auto;
earl:purpose "checking html4 dtd content model";
earl:repairInfo
[ earl:expectedResult <http://w3.org/tr/html4#ul> ] .

}
以上文件在sever端读取到字符串trigExample中后在browser上可以使用 eval(TrigToJson(trigExample))来获得两个object：prefix(namespaces), graphs，从而获得所有的数据。

分 布式和语义，答案似乎已经有了rdf/xml。但是并不能面向用户。rdf/xml很难啃，如何指定将rdf/xml中的数据显示出来，也是难题。对于框 架开发本身也有难度，站点上不同平台对rdf/xml的操作有不同的方式，要想统一的话如使用dom、sax，就很底层了。或许可以将xml的解析放到 browser上，在javascript中使用dom，这还是底层的操作，而且可能提供的js lib文件比较大，带来传输速度问题。mozilla中正开发E4X，提供xml的javascript bingding，未来可能会在各种浏览器中集成，这是一个值得期待的好消息，但是利用binding 操作xml时，js lib可能也不会很小。总之在通用性，开发难度以及灵活性之间难以兼顾。

另一中选择是rdf/n3，其不是w3c的推荐标准，但是比rdf/xml更受欢迎。进一步抽去n3中的rule，formulate等与数据存贮关系不大的部分，我们可以关注它的子集turtle ：http://www.ilrt.bris.ac.uk/discovery/2004/01/turtle/，turtle是对n3的另一个子集n-triple 的扩展。使用turtle会有两个问题：不像xml那样有节点的概念，因此无法取得文档的某个片断；工具太少。

前一个问题可以通过使用Turtle的一个超集Trig：http://www.wiwiss.fu-berlin.de/suhl/bizer/TriG/#turtle 来解决。它用来表示具名图（named graph）。 和quad（四元组）比较相似，增加的元为graphname，以表示一个表述片断（具名图）。具名图是可以嵌套的，他的每一个资源也是图。 graphname和Id间可以建立对应关系，从而实现idrdf。

后一个问题可以通过将Trig转化为json来解决 ，实际上Trig和json的结构很像。转化起来比较简单，除了作为subject 的空节点难以用json表示，但相信也可以解决。而json是很适合于交换数据和处理数据的，这方面几乎超过了xml。对于grider而言他们只需要学 习json就够了，这非常简单。

能否直接用json存贮文件？方便，不需要转化了，但是目前还没有看到这方面的例子，而且rdf工具也不能处理json文件。但是不管用json还是Trig存贮数据，只要能提供json<-->Trig转化api，就不是问题，而这很简单。
目前可以考虑提供这样的api，暂命名为json3G
请关注：http://01235.net/default.asp?cateID=2


<完>
参与讨论本主题

现有互联网的飞速发展使它的缺陷逐渐暴露了出来，如网页功能单调、搜索引擎智能化程度低等，这是因为大部分Web上的内容是设计给人阅读的，而不是让计算 机程序按其意义进行操作的。计算机能熟练地解析网页的版面，知道哪里是标题，哪里有与其他页面的链接。但是，它分辨不出个人主页和天气预报的区别，因为没 有可靠的方法来处理其中的语义，没有办法智能地理解网页内容和进行操作。

语义Web就是想弥补这方面的不足,为网页扩展了计算机可处理的语义信息。语义Web中，各种资源被人为地赋予了各种明确的语义信息，计算机可以分辨和识 别这些语义信息，并对其自动进行解释、交换和处理。但是语义Web与人工智能中的语义网络是两个不同的概念，它的研究对象和所采用的方法与传统自然语言处 理也是不同的，它对现有的Web进行了语义扩展，从而使其能被计算机做一定的理解和处理，从功能上看它将是一个能够“理解”人类信息的智能网络。将语义 Web融入现在Web结构的初步努力已经在进行中了。不久的将来，当机器有更强的能力去处理和“理解”数据时，我们将看到很多重要的新功能。例如，某人想 报名参加一个研讨会，计算机就可自动地为其制定最佳日程和路线以及预定酒店等。

互联网的创始人Tim Berners-Lee在2000年提出了语义Web的概念和体系结构。

在其体系结构中,第一层是Unicode和URI，它是整个语义Web的基础，Unicode（统一编码）处理资源的编码，URI（统一资源定位器）负责 标识资源；第二层是XML＋名空间＋XML模式，用于表示数据的内容和结构；第三层是RDF＋RDF模式，用于描述资源及其类型；第四层是本体词汇，用于 描述各种资源之间的联系；第五层是逻辑，在下面四层的基础上进行逻辑推理操作；第六层是验证，根据逻辑陈述进行验证以得出结论；第七层是信任，在用户间建 立信任关系。

第二、三、四层是语义Web的关键层，用于表示Web信息的语义，也是现在语义Web研究的热点所在。可扩展标记语言XML (eXtensible Markup Language)让每个人都能创建自己的标签，来对网页或页面的部分文字进行注释。 脚本，或者说是程序，可以将这些标签运用到复杂的应用中，不过程序编写者必须知道网页作者是如何使用每一个标签的。简而言之，XML允许用户在文档中加入 任意的结构。资源描述框架RDF （Resource Description Framework ）的基本结构是对象-属性-值三元组，也就相当于句子中的主语、动词和宾语。这些三元组可以用XML语法来表示。用这种结构描述由机器处理的大量数据，是 非常自然的方法。RDF模式是一个描述RDF资源的属性（Property）和类（Class）的词汇表，提供了关于这些属性和类的层次结构的语义。

因为两个系统可能采用不同的标识符表示同一概念，也可能用一个标识符表示不同的含义，程序若要在两个数据库之间进行信息的比较和合并，就必须了解某些标识 符表示的是否是同一事物。对该问题的一个解决方法就是本体论(Ontology)。本体是概念化的显式说明，包括分类和一套推理规则。分类定义对象的类别 及其之间的关系，使我们能够表达实体之间的大量关系，而根据推理规则，程序可以进行自动推理。简单地说，就是在不同的系统间定义一本字典或者度量表，使它 们对实体及其之间的关系达成共识，以便交流和共享。

语义Web需要能够对Web文档中的术语含义进行形式化描述。DAML+OIL（即DARPA代理标记语言+本体推论语言），OWL（Web本体语言）， 它们是W3C规范的重要扩充和改进，都是建立在人工智能知识表示基础之上的本体语言，提供了一种自然方式来描述在Web词间的类与子类之间的关系，以及在 类与类之间（或子类与子类之间）关系上的限制。它们比RDF模式添加了更多的用于描述属性和类的词汇，例如类之间的不相交性 （Disjointness）、等价性、更丰富的属性类型、属性特征等。

当然，要实现语义Web是远远不够的，更主要的技术难题还在于要让电脑可以进行更多的“思考”和“推断”。为使语义Web工作，计算机必须能访问结构化的 信息集合以及一套推理规则，据此进行自动推理。增加逻辑性——使用规则去推理，选择行动的方式以及回答问题的方法——是语义Web组织面临的一个任务。

有了大量富含语义信息的网页，就好像有了一个巨大的全球互联的数据库。有了语义信息的帮助，人们开发出的软件代理Agent程序的智能和自动化将大大提 高，它们从不同的资源中收集网页内容，搜索和处理信息并和其他程序交换信息，真正发挥语义Web的力量。当出现更多的机器可处理的网页内容和服务（包括更 多的代理）时，通过代理之间的信息交换和协同工作，信息处理的效率将呈指数级增长，能更好地满足用户的需求。

网 格

网格是一种新兴的技术，正处在不断发展和变化当中。简单地说，网格是一种信息社会的网络基础设施，是利用互联网把分散在不同地理位置上的多个资源，包括计 算资源、存储资源、通信资源、软件资源、信息资源、知识资源等全面连通和统一分配、管理及协调起来，通过逻辑关系组成一台“虚拟的超级计算机”。这台机器 把每一台参与其中的、包括个人电脑在内的计算机都作为自己的一个“节点”，成千上万个这样的“节点”并联起来，就组成了“一张有超级计算能力的网格”。而 每一位将自己的计算机连接到网格上的用户，也就“拥有了”这架超级计算机，可以随时随地调用其中的计算和信息资源，在获得一体化信息服务的同时，最大程度 地实现资源共享。网格计算模式首先把要计算的数据分割，然后不同节点的计算机可以根据自己的处理能力下载一个或多个数据片断。只要位于某个节点的计算机的 用户不使用计算机时，就会调动闲置的计算能力。网格的优势在于不但数据处理能力超强，而且能充分利用网上的闲置处理能力来节约计算成本，实现资源的共享， 消除资源孤岛。

网格计算技术首先出现在科研领域的大型科学计算和项目研究中，医药、制造、气象、勘探等需要大型计算机功能的行业将首批成为这一技术的受益者，随着连接到 网格系统上的计算资源的增加，网格计算技术也会造福于小企业和消费者，家庭PC用户也将能够用上公、私机构提供的更快、更廉价的服务，到那时任何设备可以 在任何地方接入以享用某种层次的资源，而不必关心这些资源是从那里来的, 就像用现在的电网一样。

美国自然科学基金于1997年启动了高级计算框架计划（PACI），欧盟于2000年和2001年分别启动了EuroGrid和DataGrid。 2001年全球网格论坛（Global Grid Forum）成立, 这是一个规范网格研究，制定网格标准的国际组织。就像TCP/IP协议是Internet的核心一样，构建网格也需要对标准协议和服务进行定义。迄今为 止，网格还没有正式的标准，但在核心技术上，相关机构与企业已达成一致：由美国Argonne国家实验室与南加州大学信息科学学院(ISI)合作开发的 Globus Toolkit已成为网格计算事实上的标准。企业界的网格相关研究开发工作中，最重要的就是Web服务。目前，一些业界巨头已经就几个底层标准协议达成了 共识，包括XML、SOAP、WSDL、UDDI等。

语义网格

结合语义Web、网格和Web服务的优点和弥补各自的不足，研究人员提出了语义网格的概念。附图表明了Web、网格、语义Web和语义网格的关系，网格是 Web在计算能力上的提升，而语义网格是网格在语义能力上的扩展；从另一个角度说，语义Web是在现有Web上增强了语义能力，而语义网格是语义Web对 计算能力的扩展。

在英国的e-Science计划研究中，人们发现，网格的现有努力和e-Science设想之间存在差距，要达到e-Science的易用性和无缝自动化 要求，必须实现尽量多的机器可处理性和尽量少的人类介入，这却和语义Web的目标有一些相似，于是在2001年最先提出了语义网格的构想，并且于2002 年在全球网格论坛GGF成立了语义网格研究组SEM-GRD。他们的语义网格构想的关键之处就是把所有的资源，包括服务，都用一种机器可处理的方式来描 述，其目标是实现语义的互操作性。达到这个目标的一种实现方法是把语义Web的技术应用到网格计算的开发中，下至基础设施上至网格应用。值得注意的是“语 义”是从下到上弥漫在整个网格中而不是仅仅在其上增加了一个语义（知识）层。

中国科学院计算技术研究所知识网格研究组在诸葛海研究员的带领下正在开展语义网格方面的研究，通过采用新的计算模式和新的资源组织和管理的模型，可有效地 辅助用户进行资源获取、共享、管理、协同工作和决策等，为人们提供更深层、更全面、更智能的服务。重点解决三个科学问题：资源的规范组织、语义互联和智能 聚合。

·规范组织。提出资源空间模型和资源的规范化组织和管理的理论、方法、技术和工具，使各种无序资源（信息、知识和服务）规范组织，使用户和服务能够有效、正确地根据语义操作各种资源，以提高资源的使用效率。

·语义互联。通过多层语义互联和单一语义映像，使分布在全球的各种网络资源在语义层上互联，消除资源孤岛，主要通过类型化的语义链网络来使资源的语义能被机器所理解。

·智能聚合。解决如何使资源能够互相理解，根据用户的需求有效、动态、智能地聚合各种资源，这主要通过软设备来实现。

语义Web的概念和体系结构

Web、网格、语义Web和语义网格的关系


<完>
参与讨论本主题

网 格计算代表计算领域向前迈进了一大步。尽管此项技术还处于新兴阶段，但在 developerWorks 的网格计算专题中，我们将不断地推出新的文章、教程、参考资料和工具。许多对网格计算感兴趣的读者都会问一些非常基本的问题：如何使用这些资料？从哪里开 始？如何把这些资料串到一起？然后做些什么？本文的阅读对象正是那些想要学习网格计算但又不知如何开始的读者。本文在适当的上下文环境中介绍了网格计算的 基本概念，并把相关的 developerWorks 文章、教程、技巧、IBM 学习服务教育、研讨会和 IBM 产品串联到一起，供日后深入研究。本文以一种直观的框架介绍网格计算，尝试整合多方资料，同时突出了重点。

如果您感觉这些还不够，那就对了。因为网格领域正在迅速发展，标准、框架、实现和应用程序的改变日新月异。当前的网格计算也许会让您想起从前的 Web，或者 XML 和 Web 服务的出现；一旦稳定的标准和工具产生并相互融合，就会引发相应领域的快速成长。


什么是网格计算?
网 格计算是一种新兴的技术，不同人有不同的定义。网格计算的概念十分简单：有了网格计算技术，您可以将原本毫无关系的服务器、存储系统、和网络联合在一起， 组成一个大的系统，为用户交付非同寻常的高质量服务。对于最终用户或应用程序来说，网格看起来就像是一个巨大的虚拟计算系统。

现在来详 细阐明这一点。借助于网格技术，机构可以使用大量计算机并通过共享计算资源来解决问题，这里所说的问题可能涉及数据处理、网络带宽或者数据存贮。通过网格 联合在一起的系统可能位于同一个房间，也可能分布在世界各地；可能运行在多种硬件平台之上；可能运行在不同的操作系统之上；可能属于不同的机构。在一个地 方授予用户开始某项任务的权限之后；网格就会利用大量的 IT 资源来完成这个任务。对网格的所有用户来说，网格就是一个运行任务的巨大的虚拟计算机。

这种想法听起来不错，但怎样才能变为现实呢？答案是需要标准的、开放的、通用的协议和接口。网格计算的标准不久就会被定义出来，目前已经渐露身影。

什么样的系统不属于网格？群集、网络附加存储设备、科学装置、网络，这些都不是网格。它们可能是网格的重要组件，但就本身而言，都不能称之为网格。

网格有哪些种类？

计算网格，具有部分预留资源的计算机，可以处理关键数据，或是为其他负载较重的计算机分担任务。
拾遗网格（Scavenging grid），从空闲的服务器和桌面计算机中回收 CPU 周期，用于处理资源消耗量大的任务。
数据网格，为同一机构中的所有数据存储库提供统一界面，通过这个界面可以实现对数据的查询、管理和保护。
更多信息：

红皮书 网格计算基础 是很好的入门读物。
文章 网格计算：为开发人员提供基本概念 给出了一系列初级的白皮书、书籍和文章。从中您可以获取更多关于网格计算的知识。
想要了解 IBM 的电子商务随需应变策略，请参考文章电子商务随需应变：开发人员蓝图.
可以从 Grid computing 网站上获取白皮书、分析报告、成功案例，以及很好的入门视频讲座。

回页首


我可以使用网格计算做些什么？
和 Internet 一样，网格计算也起源于研究和学术领域。现在，商业企业也开始使用网格了。网格计算带来了新型的财务和商业模型。以下是一些例子：

在财经服务领域，网格计算被用于加速交易处理、处理海量数据、并为只能容忍极短停机时间的工作平台提供更稳定的 IT 环境。

政府机关使用网格来集中、保护和集成大量数据存储。许多市政和军事机构都特别要求跨代理机构协作、数据集成和安全，以及跨数千个数据存储库快速获取信息。

涉足生命科学（比如基因组研究）的公司使用并行和网格计算对大量数据执行处理、净化、交叉制表和比较操作。更快的处理速度意味着更快地占领市场。在该行业，任何轻微的优势都可能成为决定因素。

为什么网格计算是重要的？

网 格计算将会把许多计算机联合到一起。几乎所有机构都存在大量的闲置计算资源，广泛分布在各个地方。大型主机有 40% 的时间处于闲置状态，UNIX 服务器只有少于10% 的时间在真正“执行”任务，几乎所有的 PC 每天有 95% 的时间什么都不做。请想像一下，如果一家航空公司 95% 的飞机在地面上、一家汽车制造商 40% 的组装工厂被闲置、或者一家连锁旅店 95% 的房间是空置的，那该是多么糟糕的情况。

借助 网格计算，企业可以优化计算和数据资源，把这些资源集中用于大容量的工作负荷，通过网络共享资源，以及促进协作。许多人把网格计算看作是 Internet 革命之后势必会走的下一步，并认为逐渐成熟的标准和带宽成本的下降是目前的主要驱动力。计算环境的虚拟化 —— 网格计算 —— 是 IBM 电子商务随需应变策略的一个关键组件。通过虚拟化计算环境，使其自动化，并集成业务处理和信息，您将获得能够改善业务的、随需应变的运行环境。

更多信息：

请参考 ibm.com上Grid 解决方案 的列表
阅读同样位于 ibm.com 上的 Grid 的优势
阅读同样位于 ibm.com上的随需应变的商务。


回页首


网格计算有哪些主要组件？
安全性，因为必须保证只有授权用户才能访问和使用网格资源。
数据管理，因为数据必须被传输、净化、打包和处理。
资源管理，因为网格必须了解哪些任务可以使用哪些资源。
信息服务，因为用户和应用程序必须可以高效地查询网格。
更多信息：

请参考 网格计算：关键组件是什么？


回页首


网格计算有哪些相关标准？
架构。网 格计算的架构定义在开放网格服务架构（Open Grid Services Architecture，OGSA）的基础之上，这是由 Global Grid Forum (GGF) 开发的一种标准。OGSA 定义了什么是网格服务，并定义了网格环境提供的整体结构和服务。

网格同 时也建立在 Web 服务的标准之上，OGSA 称网格服务不过是符合特定规范的 Web 服务。例如，网格服务的定义采用带有少许扩展的标准 WSDL（Web Services Definition Language，Web 服务定义语言）。这一点为什么十分重要？因为这样的话，我们就可以使用现有的标准，比如 SOAP、XML 和 WS-Security 来访问各种网格服务。当新的网格服务可用时，我们可以通过标准的方式查找、识别和利用它们。除此之外，OGSA 将会为采用不同底层工具构建的网格服务提供彼此之间的互操作性。

规范。开放网格服务基础设施（Open Grid Services Infrastructure，OGSI) 是 OGSA 用于描述概念的正式规范。OGSI 详细给出了一组服务原语，这些服务原语定义了所有网格服务通用的核心行为。

更多的规范正在逐渐出现。Global Grid Forum 上有 10 多个工作组正忙于在各个领域定义一系列网格标准，这些领域包括：应用程序和程序设计模型、架构、数据管理、安全性、性能、调度和资源管理。

我 需要对正在发展的网格标准了解多少呢？这取决于您自己的需要。IBM 和其他业内领先厂商，以及许多网格软件供应商的研究人员和代表，都加入到 GGF 的工作中来，目的是为了定义网格标准。您是公司的软件开发人员吗？如果是，当基于新标准的网格工具和产品发布时，您就可以使用它们。您可能希望了解标准， 并大致知道标准进行到什么程度。那么请关注 developerWorks 的网格计算专区，我们将会尽最大努力及时通知您标准的进展情况。

更多信息：

网格专区发布的 网格计算 —迈向标准化平台 。
从 Grid Watch column 的 Grid Watch column 中获取开发人员的最新观点。
通过 developerWorks 上的文章 Visual Tour of OGSA 了解 OGSA 是如何规划网格的（2003 年 8 月）。
了解 Global Grid Forum 的工作 http://www.ggf.org.
学习更多关于 Web 服务的知识 developerWorks Web 服务专区。 .
在 GridForge 上有 OGSI 规范 和一个非常详细的 OGSI 入门 。


回页首


我可以马上构建网格吗？
当然。您可以使用开放源代码工具或者供应商提供的专利工具和产品马上开始构建网格。随着时间推移，网格标准将会稳定下来，那时供应商将会提供符合新标准的工具，使您可以更加方便地把各个组件结合到一起。

Globus Toolkit。从下载开放源代码的 Globus Toolkit 3.0 (GT3) 开始是一个不错的选择。GT3 是 OGSI 标准的第一个完整实现，该工具由 Globus Project 开发，这是一个致力于把网格概念应用于科学和工程计算的研究和开发项目。这个工具由一组支持网格和网格应用程序的服务和软件库组成，GT3 中包含了针对安全性、信息基础设施、资源管理、数据管理、通信、故障检测、移植性等各个方面的软件。另外一个可用的工具是 Commodity Grid Kits (CoG)，它提供了在特定框架中访问网格服务的能力，包括 Java、Python 和 Perl 。

工具的种类。网格工具可以被分为以下几类：

基础设施。基础设施包括文件系统、调度程序和资源管理器、消息传送系统、安全应用程序、证书颁发机构，以及像 GridFTP 这样的文件传输机制。
目录服务。网格上的系统必须能够发现可用的服务。简言之，网格系统必须能够定义（和监视）网格的拓扑，这样才能达到共享和协作的目的。许多网格目录服务实现建立在以往成功的模型之上，比如 LDAP、DNS、网络管理协议和索引服务。
调度程序和负载均衡器。网格的主要优势之一在于效率最大化，调度程序和负载均衡器提供了这种功能以及其他功能。调度程序确保任务按照一定的顺序（例如，优先级、最后期限、紧急）来完成，负载均衡器在整个系统内分配任务和数据管理，减少瓶颈产生的机会。
开发人员工具。每个计算领域都需要工具来帮助开发人员。针对网格开发人员的工具定位各有不同（文件传输、通信、环境控制），其范围覆盖了从各种工具程序到所有 API。
安全性。网格环境的安全性是指验证和授权 —— 换句话说，也就是控制谁/什么可以访问网格的资源 —— 但不局限于此。例如，消息完整性和消息保密性在财务和医疗领域中是十分重要的。
更多信息：

下载Globus Toolkit.
IBM 红皮书 Globus Toolkit 3 Quick Start 介绍了 GT3 工具的高级概念和整体架构，并讲述了如何安装、配置和测试 GT3。
查看Globus CoG kits.
查看不断更新的文章库


回页首


IBM 提供哪些网格计算工具？
IBM 网格计算策略将会网格化 IBM 的所有产品。公司目前正在使自己的存储、服务器、基础设施、数据库管理、系统管理、消息传送和文件系统内容符合 OGSA。同时，IBM 正在开发的新技术和产品也把 OGSA 作为共同的基础。

IBM Grid Toolbox是一组可安装的软件包，其中包含了带有附加文档的 Globus Toolkit，以及为运行 AIX 和 Linux 的 IBM eServer 硬件所编写的自定义安装脚本。
IBM DB2 Information Integrator为随需应变的电子商务提供基础，使得公司可以统一、实时地访问各种分布式信息。
IBM Emerging Technologies Toolkit 来自 alphaWorks 的一个软件开发工具包，用于设计、开发和执行日益自动化的网格相关技术和 Web 服务。
Grid application framework for Java 是来自 alphaWorks 的一个轻量级框架，它从应用逻辑中抽象出所有网格语义，并提供能够与通用 Java 程序设计模型协同工作的简单程序设计模型。
IBM 首次引入 grid computing capabilities in WebSphere Application Server ，用于平衡服务器负载。


回页首


怎样才能在我的应用程序中启用网格？
这需要一定的规划。首先需要考虑网格的基本结构和它所提供的服务。您必须知道如何把基础设施的各个部分组合到一起，其中包括安全性、资源管理、信息服务和数据管理，这些将会影响应用程序架构、设计和部署。

更多信息：

How grid infrastructure affects application design是一篇高级文章。
请从Design an application for grid中了解应该关注的要点。
关于在应用程序中启用网格的更多更详细的讨论，请参阅 IBM 红皮书 Enabling Applications for Grid Computing with Globus.




<完>
参与讨论本主题