任何独立存在的事物都需要有一个标识来表明它的存在，不论这个标识是有意义的还是无意义的，抽象的还是具体的，文字的还是符号或图示的，或者是编码的。

最常用的标识是由语言文字来表达的名字。名字的作用是为了标识，并且有区分的功能，名字的重复和指代对象的不明确对于人脑来说并不构成很大的问题，人通常可 以通过上下文语境或者概念之间的关联，准确判断所指代的对象，但是对于计算机而言就必须明确区分，ID必须具有唯一性，不同的ID一定是不同的东西，即便 可以给它们建立相等的关系，它们也不是一个东西。

当然，这个唯一性是有一定范围的，不是无限的。例如开放的因特网世界，有命名域规则保证名称的惟一性，而封闭的内联网世界，其名称只需要在其内部具有惟一性即可。

远洋师让我介绍一些网络ID，我就介绍一些，不知道符不符合要求，请远洋师和各位同仁批评指正。

其实用两幅图就可以完整介绍因特网上能用到的几乎所有ID。

图一：说明了URI主要分URL和URN两种，其中URL虽然是一种标识，但同时作为可以直接定位的地址，而URN需要局域解析规则进行定位。

如下图二就说明了URI的基本语法（下图来自网络）

有了上面两张图示，就可以明白关联数据所推荐采用的标识是HTTP URI的子集，即CoolURI。HTTP URI其实就等于URL。CoolURI在上一个帖子中介绍过了。另外，OpenURL等地址规范也都符合URI规范。

关联数据的概念想法其实很简单，但同时又很难让人理解，这是个很有意思的现象。是不是可以拿刘谦的魔术来类比，不知道的看不懂，知道了其实都是业内常见的trick。

前面的博文写了关联数据的n种定义，还没有完成远洋师的要求，远洋师希望解释两个问题：

1. 关联数据是Web of Data（数据的Web）的一种实现，而不再是Web of Documents（文档的Web）；
2.实现关联数据的两种方式：采用HTTP303转向和采用hash（即井号#），各有什么优缺点。

要解释清楚这两个问题，一方面我还要加紧学习，另外对于书社会的广大社员来说也需要学习，因为要听懂对这个问题的解释，听众至少要达到前述定义中的第四级用户——Web应用开发人员——的水平，而且还要假设这类开发人员对于HTTP协议有一定的了解，而不是只利用现成的工具进行开发。我相信这样的用户太少了。为了使1-3级用户也能有所收获，就让我多打比方，慢慢道来吧。

上过网的朋友都知道，通过在浏览器的网址栏键入网址（即URL），就能传回网页。如键入这个URL：“http://www.kevenlw.name/about/index.php”，服务器接收到这个URL，以HTTP（超文本传输）协议来响应这个请求（之前还有DNS域名解析的过程，把域名转化为ip地址，略过不表），将about目录下的index.php文件传输给浏览器，并显示出来。

这个过程，涉及到Web技术的三个主要内容：HTTP、URL和HTML。

• HTTP是服务器操作的指令，规定了遇到各种请求（如GET/PUT/POST/DELETE)服务器如何响应，怎么处理；
• HTML是存储在服务器端的网页文件，将根据请求传送给浏览器，HTML的标准规定了文件的结构，允许包含丰富的超文本链接，并能嵌套各类其它文件格式，如果浏览器一端有相应的资源或程序就能够调用或运行。正是由于HTML，使整个万维网上布满了相互链接的文件，成为一个巨大的、不断膨胀的文件宇宙，这就是Web of Documents的来历。
• URL本来是作为在这个文件宇宙中定位具体的文件而用的，后来演变成兼具名称作用，从而被URI连同URN一起收入麾下，让URI一统江湖了。

一个由方案（scheme，或译为主题）、域名和路径组成的URI标识，从仅仅标识文档，到用来标识“任何东西”，看似简单的变化，其背后却是思考范式的变化，是哲学认识论层面的变化。(一个最重要的trick就在这里）。这个变化使得我们可以把大千世界的任何东西，都“投影”到万维网上，每个东西都有URI，都有对这件东西的描述（元数据）以及用数据表达的这件东西，这样，万维网就变成了一个数据的世界，其实构成了一个波普尔所称的第三世界（在我看来，这个概念和URI体系可以应用到物联网）。

可以看到，URI同时解决了命名问题和定位问题，然而在具体实现URI命名和定位时，该名称还有永久性和易实现的要求，路径作为某个“东西”的名称的一部分，就不能允许轻易发生改变，并且不同的软硬件平台和技术环境下都能够正确编码，这就是CoolURI的由来。

同时对于同一个对象，必须允许有不同的描述与表达方式，例如对于上面kevenlw的描述，既要有html文件（php可以认为是动态生成的html文件），通过浏览器显示给人看，又要有rdf文件描述kevenlw的各种性状属性以便机器获取相关元数据信息，如foaf文件：http://www.kevenlw.name/kevenfoaf.rdf。这两个文件其实描述的是同一个“东西”，因此不应该有不同的ID标识（注意：在这里是两个不同的URI，这是不规范的），必须在一个URI中区分这两类数据，同时让服务器有一种机制，能够自动地根据请求方的不同，传送不同格式的数据。

（下一篇再讲采用303转向和hash“#”两种实现方案各自的特点）。

作者: （美） 亨德勒 / （美） 阿利芒ISBN: 9787115193841 页数: 330定 价: 59出版社: 人民邮电出版社装 帧: 平装出版年: 2009-2-1

本章开始是我真正感兴趣的所在了：本 体建模和本体编码。渐入佳境。

（一）

1. 数据表达（也是一种知识表达）可以基于多种模型，每 种模型可以有多种方法来表达，每种方法也可能有多种编码模式（Schema，如XML模式，数据库模式等）。模式告诉我们所有数据需要传递和表达的信息 （包括结构和语义）。就RDF来说，也有多种等效的方法，但虽然等效，处理方式可能大相径庭，不同的处理方法可能带来不同的“计算”能力（对于语义Web 来说，也是一种推理能力），以及对应于不同的数学运算方式。
2. 例如RDF三元组表达，其本质上是图像（节点-连线图），但RDFS更适合 于用集合来表达。点线图的计算和集合的运算是非常不同的，这两种方法可以看成是模型表达的不同。相对说来，集合运算在数学上是非常成熟的。
3. RDFS 可以看成是领域模型表达成RDF的形式化语言，就是说领域模型中的各类实体关系，都用RDF三元组来表达，写成RDF模式的序列化形式。当然数据实例，也 都是RDF三元组。这一方面降低了RDFS的应用难度（RDF标准在设计时吸取了XMLS的经验），同时却常常使初学者感到迷惑。好在这个迷惑的过程不会 很长。
4. 所谓推理，在这里实际上只是比“检索”前进了一步，即不仅能检索出已经明确表达的知识，而且能够根据规则，判断出没有“显式”表 达出来的知识。应 用到RDF模式，就是不仅能对Asserted Triples进行查询，也能够对Inferenced Triples进行查询。这本来就是RDFS设计的初衷，当然没有问题。当然，如果RDFS本身的表达有问题，有矛盾，通过工具应该是能够检验出来 的，XML模式也可以进行Validation的检查，RDFS当然也行。
5. 传统的描述数据的“模式”都不是存在于模式中，或者以模式的 编码方式存 在。例如关系数据库的“模式”，通常是附注文本，或单独的文件，面向对象的对象模型的“模式”也不是以对象的方式进行描述，早期XML文本描述的DTD定 义，也不是合法的XML文件。目前很多数据格式的定义模式一般都采用与数据格式相同的方式，例如通用Lisp的元对象以及Java对象模型的API自定义 表达都是采用自身相同的语言定义模式，XML Stylesheet，以及XML模式，也采用XML方式进行定义。
6. RDFS引入更多的 “资源”来定义资源和资源之间的关系，定义的这些资源其实只是一个“约定”，本来任何人都可以这样定义，只是W3C作为一个约定，写入了“标准”中去了而 已。
   例如rdf:type只能定义实例的类型，例如《红楼梦》是一本小说：
   [1] ex:红楼梦 rdf:type ex:小说
   其中ex表示定义“红楼梦”和“小说”的命名域。
   如果要定义“小说”（类名）是一种“文学作品”（类名）， 就没有相应的rdf资源元素，W3C扩展了一个rdfs:subClassOf，以及rdfs:superClassOf，可以这样定义：
   [2] ex:小说 rdfs:subClassOf ex:文学作品
   或者：
   [3] ex:文学作品 rdfs:superClassOf ex:小说
7. 当然，要使计算机理解 rdfs:subClassOf和rdfs:superClassOf之间的关系，还需要进一步用到本体定义语言OWL扩展的一个元 素：owl:inverseOf。实际上OWL也是一套对RDF进行扩展的词表，丰富了RDF的语义表达能力。
   继续上面的例子。由[1]和 [2]，就可以推出：
   [4] ex:红楼梦 rdf:type ex:文学作品
   其中 rdf:type，rdfs:subClassOf两个资源之间的语义关系是RDF标准中定义（预设）好的（包括与rdf:superClassOf，以 及这两个资源元素与owl:inverseOf之间的关系），因此机器才能自动做出上述推论。
   这样的推理，类似于编程语言中IF/THEN表达的 语句。
   这其实才是RDF推理。

（二）

除了rdfs:subClassOf之外，RDFS还扩展了许多元素，rdfs:subPropertyOf是其中最重要的一个。
类有子类，也有 属性。属性有子属性。
[5]
ex:著 rdfs:subPropretyOf ex:创作
由：
[6] ex:曹雪芹 ex:著 ex:红楼梦
可以得到：
[7] ex:曹雪芹 ex:创作 ex:红楼梦

建模举例：
某图书馆的工作 人员中有职业的图书馆员，外聘的信息技术人员、外包公司的技术人员以及自由职业者，如果要建立他们与图书馆之间的各类用工关系，该如何做？
首先析 出需要描述的关系：合同关系contractsTo，自由职业freeLancesTo，外包公司indirectlyContractsTo，直接聘用 isEmplyedBy，以及笼统的用工关系worksFor。
所有职员与公司之间的这些关系，其实都是“属性”关系，应该用 rdfs.subPrepertyOf建立起联系。
上述五种属性之间的关系，用工关系包括合同用工和直接聘用，合同用工又包括自由职业者合同和外 包公司合同（用词在这里不一定符合中国法律，但语义就是这个意思）。可以作如下表达：
[8]
ex:isEmplyedBy rdfs:subPropertyOf ex:worksFor
ex:contractsTo rdfs:subPropertyOf ex:worksFor
ex:freeLancesTo rdfs:subPropertyOf ex:contractsTo
ex:indirectlyContractsTo rdfs:subPropertyOf ex:contractsTo

这样，如果：
Keven isEmplyedBy TheLibrary
机器可以得到以下推理：
Keven worksFor TheLibrary

如果：
Marcia freeLancesTo TheLibrary
Raizen indirectlyContractsTo TheLibrary
机 器就可以自动做出下面的推理：
Marcia contractsTo TheLibrary
Raizen contractsTo TheLibrary

属性之间的这种关系定义，在面向对象的编程中是没有对应规定的，这一点需要注意。

（三）

RDFS另外有两个重要扩展：rdfs:domain 和rdfs:range，它们也跟“属性（Property）”元素有关：rdfs:domain关乎属性的主语的取值，rdfs:range关乎属性的 宾语（对象）的取值，都是一种约束（限定），或者说提供了对三元组当属性词（谓语）确定之后，用来描述主语和宾语的限定的扩展元素。

举例说明如下：

[9]
如果属性P的值域（domain）为D，x的P属性是y，那么x的类 型一定是D。可以写为：
IF
P rdfs:domain D
and
x P y
THEN
x rdf:type D

[10]
如果属性P的范围（range）为R，x的P属性是y，那么y的类型一定是R。可以写为：
IF
P rdfs:range R
and
x P y
THEN
y rdf:type R

有 了这两个元素，就能够对于取值范围进行约束，从而可以采用规范词表之类的方法进行取值的规范控制。但是RDFS不能描述某一个实例不属于某个类（这在 OWL中得到了扩展），当定义了P的domain和range之后，如果有“x’ P y’”，不论x’或y’取何值，系统都必然地把它们归入预定的domain和range，加入预设的domain和range（例如规范词表或分类法）中 没有x’或y’的实例，就会发生矛盾，需要另外解决。

进一步，结合rdfs:subClassOf，可以有一些更有意思的推理：
如 果某个属性P有值域D，而值域D是D’的子类，则D’也是P的值域。表示如下：
[11]
IF
P rdfs:domain D
and
D rdfs:subClassOf D’
THEN
P rdfs:domain D’
具体举例：网页（D）是网络资源（D’）的子 类，具有URL的HTML页面（P）是网页（属于值域D），那么也一定是网络资源（属于值域D’）。
这里与面向对象的分析和设计似乎相反，类的属 性不是被子类继承，反而被超类获得。这是Web的特性决定的：属性自身就是资源，不专属于特定的类。

属性交集的例子：
[12]
如 果：
属性P ⊆ R ⋂ S
x P y （x的P属性值为y）
则：
x R y （x的R属性值为y）；
x S y （x的S属性值为y）。

（四）

例子：
甲图书馆用 Lib1:borrows表示外借图书，乙图书馆用Lib2:checkedOut来表示，一个Web应用要将他们的外借数据合并，可以采用以下方法等同 这两个属性：
Lib1:borrows rdfs:subPropertyOf Lib2:checkedOut
Lib2:checkedOut rdfs:subPropertyOf Lib1:borrows
然后，让这两个属性共同作为一个属性的子属性：
Lib1:borrows rdfs:subPropertyOf ex:hasPossession
Lib2:checkedOut rdfs:subPropertyOf ex:hasPossession
这样，使用ex:hasPossession就可以获取所有两个图书馆 外借图书的数据了。

这种方法可以用来整合多个不同的元数据方案。例如，用DC元数据元素作为“核心集”时，MARC等不同元数据方案中的 诸如ex:author，ex:editor之类的元素，都可以 subPreportyOf dc:creator，就可以支持DC标准作为统一查询的元数据标准了。

不用作推理的RDFS元素还有如下一 些：rdfs:label（给定一个显示 名），rdfs:seeAlso（交叉参考），rdfs:isDefinedBy（定义主体），rdfs:comment（注释）等等。

总结一下：

RDFS是用来描述RDF的模式语言，主要提供了定义类（class）、类与类之间的关系（subClass）、属性 （property）、属性之间关系（subProperty）的方法，并规定了简单的、基于集合理论的类继承规则，以及属性继承规则。可以看出RDFS 对RDF的上述扩展，也是完全基于RDF的（全都是三元组），这也保证了RDFS可以像RDF一样，具有同样的开放性，任何人都可以用来定义任何RDF模 式。

虽然RDFS引入了值域和范围，用来限定资源类的属性取值，增加了RDFS的复杂性，但RDFS仍然是非常简单的，没有多少内容。也因 为此，它的适用面和能力是非常强大的。当然如果要表达更为丰富的语义和推理关系，还需要从规则表达（如OWL和SKOS）和词表（如SKOS、FOAF、 DC等等）两方面进行扩展。任何元数据方案以及本体模式，都是组成语义网标准规范体系中的成员，都是对语义网的贡献。

作者: （美） 亨德勒 / （美） 阿利芒ISBN: 9787115193841 页数: 330定 价: 59出版社: 人民邮电出版社装 帧: 平装出版年: 2009-2-1

第 一章 什么是语义万维网

1. 这的确是一个很难向普通人解释的问题，我们来看看两位大师是怎么做的。
2. 首先他们介绍了 本书的主题：关于语义万维网 和本体建模。语义万维网顾名思义，肯定是关于万维网的，而且要表达语义。语义按照一般的解释，就是自然语言所表达的含义。本体建模为什么有必要谈呢，主要 是因为W3C固然搞了一大套东西，但不同的工匠做出的活儿肯定是不同的，本书是要教导你做出漂亮的活，而不是粗糙的、仅仅符合W3C那些定义的活。
3. 然 后解释了Web的伟大意义，即任何人可以在上面就任何话题说任何话，即AAA口号(Anybody can say Anything about Any topic)。这正是Web的魅力和价值所在。万维网的价值与它参与者的数量和资源数 量成正比，万维网的魅力就在于它是一个不断增长的有机体。那么语义Web又能做什么东东呢？作者举了两个Web应用例子（涉及到四个网站），一个是会议旅 馆信息不同步，一个是冥王星被驱逐出太阳系九大行星行列之后，一些网站的信息同步问题。作者在后文中还会用到这两个例子。
4. 通过这两个例 子，说明目前的Web是有很大缺陷的，同时说明，语义Web就是要解决这些个问题。作者称之为“聪明的Web和傻Web”的问题。
5. 接 着作者探讨了如何使Web变得聪明，在现有的Web架构中，你不可能提供一个集中式的管理方法，或者架构，使其“聪明”起来，任何这种企图在开放的、分布 式环境下都是不可能的，不仅是经济上不可能，操作上也不可能。所以作者对“聪明”的Web有一个定义，就是需要把数据在适当的时候，以适当的方式呈现出 来。语义Web的架构只要实现这个，就够了。
6. 然后作者又对“聪明的程度”作了探讨，聪明并不意味着绝对正确，不可能存在绝对真理，语义 网“容错”是一个关键问题，如何容错，如何继续允许AAA，同时建立自己的过滤和“权威”审定机制，也是这个架构设计中的重要方面。目前主要采用唯一的 URI命名来共存，以及采用RDFS标注来说明概念间的关系。

第二章 语义建模

1. 首先介绍了模型的概念：对事物的抽象，隐藏细节、反映概貌，以及模型的作用：沟通、解释预测以及协调不同意见。
2. 模 型描述用自然语言在人和人之间交流，比通过计算机交流，要容易得多。人类的交流通常隐含了很多前提条件（语境），例如知识、文化、科技、宗教背景。当然， 也会因此而造成理解程度的差异。
3. 整个一章基本上是围绕模型的三个功 能：communication，explanation/prediction，mediating来写，最后着重说明了如何表达异见、以及表达能力有 高有低等问题。

第三章 RDF－语义Web的基础

1. 首先提出，语义Web所涉及的语义，不同于符号语义学很复杂的东西，而仅仅是为所涉及的“资 源”给出了一个链 接，作为资源名（即URI）。实际上给出了语义Web一个基本假设：链接即语义。有了这样一个URI，任何指代的东西就有了根据，通过这样一个基本的三元 组的建立，使得认知三角形得以成立（实际上是这样一个认知模型），从而提供了逻辑的结构基础（砖块）：三元组构成的判断式，从而所有的推理运算可以在此基 础上展开（例如一元谓词逻辑的所有计算，最简单的等同计算，以及通过RDF建立关系链接能够表达的所有关系计算——超类，子类，以及通过OWL描述逻辑能 够进行的更复杂的计算，如“非”等等）。
2. 本章通过一个莎士比亚戏剧作品的年 表，展示了如何从关系数据库的表单结构表达的隐含语义，转化为分布式Web网络环境上可被获得的三元组链接。这也印证了人们对语义Web的一个通常的说 法：语义Web就是分布式环境下的关系数据库。介绍了表达三元组的技术细节（如说明了采用qname的URI由怎样的两部分组成）。本章的最后提了本书的 第一项“挑战”（Challenge，类似于作业或操练，不过紧跟着就提供了答案和讨论，非常有启发）：把一个关系表转化为RDF表达。这是很有特色的一 种写法。最后还讨论了高阶（逻辑）关系和三元组（RDF）的其它表达（序列化）形式：N-Triples, Notation 3(N3), RDF/XML, 空节点（Blank Nodes）

第四章 语义Web应用架构

1. 首先解释了在这样一本以“建模”为题的著作里，为什么要介绍“架构”（Architecture）， 因为这本书同时也 是for working ontologist，要具有实用性。为了解释如何使用，必须要介绍语义Web的高层架构、组成、内容（输入inputs）及来自何处、以及如何用到 RDF的优点、与其他架构的不同之处，等等。
2. 支持语义网应用的软件主要有以下几类：
   • RDF解析器 （Parser）/序列化工具（Serializer）；
   • RDF 库（Store，又称三元组库：Triple Store）；
   • RDF 查询引擎（Query Engine）；
   • 各种专门应用（Application），如后面介绍的转换器、刮擦器等等。
3. 目 前实现所有语义Web应用的底层技术还是以关系型数据库为基础的Web三层应用模式，只是其中增加了语义处理的内容，如查询部分需传递SPARQL语句， 处理和存储部分都需要支持RDF三元组数据，等等。
4. 本 章后面其实没讲什么“架构”，都讲各类语义应用/软件了，例如：转换器converter/刮擦器scraper（指从HTML网页或传统应用中获取语义 信息——通常是RDF数据——的工具，当然可以通过各类微格式或其他准标准文档格式进行“刮擦”，通常需要编写GRDDL来实现）；RDF库的互操作解决 方案；查询和提问标准及其与SQL的比较；基于RDF的门户等，最后对于跨库的数据合成（特别是动态合成，类似于Mashup）。

1. 上来就引述第一章讲到“傻瓜数据”时所举的例子：“傻瓜 数据如何基于更多的互联关系而使Web上的应用更聪明”（how a more connected Web infrastructure can result in behavior that lets smart applications perform to their potential）。其实当时也没怎么看懂，姑且继续往下看去。
2. 基 于RDF的数据整合最大的好处，是保证分布式环境中数据的一致性（consistency）。数据的整合视图可以通过整合数据和整合提问两种方式得到，整 合提问通常需要架构的支持，并且需要适当的提问构建工具/环境以方便构建整合视图。
3. 前文中“衣物和衬衫”的例子可以用规范词表的形式来 解决，如规定衣物是衬衫的上位概念，这样在查询衣物时，它的所有下位概念都会出来。这也是一种推理。
4. 著名的语义Web堆栈图已经充分说 明了提供推理支持的语义网架构，这个架构是基于RDF，以及以RDF为基础的描述模式的。
5. 推理引擎能够判断并未描述出来 的逻辑，不同的引擎判断的能力不同，RDFS和OWL的引擎就有所不同。
6. 对于RDF库来说，有两种方式支持推理：Asserted triples和Inferenced triples，其区别类似于实时索引和物理索引的区别，极端的情况是，要么把所有能够推理出的三元组全部都罗列出来，放入库中，要么能不放都不放，所有 的三元组查询都通过规则实时导出。前者利用空间节省时间和计算能力，后者利用计算能力而节省了空间却牺牲了时间。对这两种做法进行动态更新时会碰到不同的 问题，在实际应用中，很难说那种更好，一般都采取折中的做法。

开放数据（Open Data）：
在网络上可以公开得到的数据，没有任何控制访问的措施（无需登录，否则只能是免费数据或其它名称）。
为了促进开放数据应用，模仿“创作共用”协议，好事者也提出了“开放数据共用协议”。
开放元数据是其中的一类。
项目举例：

• data.gov（美国）
• Open Data Network（德国）
• making public data public（英国）

关联数据（Linked Data）：
一种数据访问（整合）技术，基本上都是以RDF方式表达，对于Http协议进行少量扩展（规定）而成。低成本，高可用性，整合简单。
开放链接数据（Linked Open Data）是关联数据的一项运动。

• 美国纽约时报项目，目前已经上载了5000个人物的主题表目，可以按照cc by协议开放使用。
• Linked Data Research Center
• GoodRelations：关于产品、价格和企业数据的规范词表
• oeGOV：应用于政府信息管理的本体词表

Web3.0：
Web2.0的热衷者或者搅局者提出的一个概念，作为下一代Web的一种趋势探讨，有人说就是语义Web，有人在语义Web基础上添加了P2P、各类无线应用甚至云计算等内容。

语义Web：
现有Web之上的、以数据资源为基本组成单位的Web，这些资源（数据）都标注有元数据描述，从而能够进行语义查询，以及数据整合，提供了互联网上实现语义互操作的技术平台。关联数据可以理解为语义Web的一种实现。
Web of Data是其另一别称。

我感兴趣的问题实际上就是Ontology based metadata services for information retrieval. 实际上是开发一个或一组智能代理，利用Semantic Web services架构解决异构系统的情报检索互操作问题。前提条件是一定的Semantic Web services架构。首先必须对这个概念解释清楚。这是个很热门的话题了实际上，一篇经典的文章见（2001年的文章，稍早一些，还没有DAML-S）：http://www.daml.org/services/ieee01-KSL.pdf，一个作者是越南人，第三作者是个中国留学生，都很年轻啊！

以下主要来自（Katia Sycara, Massimo Paolucci, Anupriya Ankolekar, Naveen Srinivasan, “Automated discovery, interaction and composition of Semantic Web services”）*

Web services 利用自主的代理在分布的环境中实现自动的”按需”服务，Semantic Web提供服务描述和服务接口的语义支持，目前这方面的标准正在逐步建立起来，然而多个Web service之间的协调和语义一致性是一个关键问题，目前BPEL4WS 和WSCI在这方面作了一些探索，然而最可能的途径是通过DAML-S提供解决框架。

组合多个Web services可以分为三方面的问题：

1. “计划”Web服务之间的交互以及其提供的功能如何整合；
2. “发现”Web服务实现的的任务；
3. 对Web服务之间的”交互”进行有效的管理。

这三个方面是交织在一起的，计划决定了如何去发现Web服务的类型，却依赖于Web服务的实现。同样，Web服务的交互过程依赖于计划的实施，计划本身又依赖于对交互的需求。

揭示一个Web服务，系统必须提供对于Web服务所能实现功能和能力的描述机制，并且能够识别和比较不同Web服务的功能和能力的异同。另一个挑战是系统还必须支持对不同Web服务的交互的支持。

也就是说需要从语义和语法两个方面提供互操作性，而不是仅仅是目前考虑的重点–从语法上制定协议标准（例如SOAP和WSDL，利用XSD展现消息数据的结构）。语法的互操作性仅仅提供了消息交换的结构，没有提供消息内容的解释。UDDI仅仅是关于Web服务的信息库，并不包含Web服务能力的揭示。WSCI和BPEL4WS描述了多个Web服务可以组合在一起成为一个更复杂的Web服务，但是其重点放在语法的规定上，因此并不支持自动的Web服务的组合。

语义互操作因此成为Web服务协同组合的关键问题。它必须：

1. 表达和支持Web服务的任务实现（例如网上卖书或者信用卡认证等），以便通过对于Web服务功能清楚的描述和广告而实现自动发现；
2. 表达和支持业务关系和规则（Business relations and rules）；
3. 表达和支持消息排序（message ordering）；
4. 理解消息的语义；
5. 表达和支持使用特定Web服务的前提条件以及激活服务的效果；
6. 允许Web服务组合成为更为复杂的服务。

Web服务可以直接在语义Web基础上直接建立，后者为Web提供了内容语义，能够被代理或者其他服务获取，代理能够通过严格定义的语义内容和规则进行推理，由本体提供的概念模型能够很好地解释Web网页的内容。从这一点来看，语义Web为Web服务提供了其所需得的语义互操作的基础，提供了形式化的语言和本体，用以支持服务描述、消息内容的理解、业务规则，并提供了不同本体之间的联系。语义Web和Web服务互相促进：前者使Web成为一个庞大的机读数据库，后者提供机器自动使用这些数据的工具。

由此可以认为，”语义Web服务”是语义元数据、本体、形式化工具和Web服务架构的集成，是基于良好定义的语言进行语义描述的Web服务(A Semantic Web service is a Web Service whose description is in a language that has well-defined semantics)。

因此，网络计算的不确定性得到了最大程度的消除，Web服务的发现、选择、组合、沟通、激活、监测、管理、恢复和补偿都得到了最大程度的自动化和实现。特别低，语义Web服务依赖语义Web描述：

1. 消息交换的内容；
2. 消息交换的顺序；
3. 消息交换的状态变化。

结果为不同服务的无缝互操作提供了基础。

利用语义Web描述Web服务有很多具体内容，包括描述Web服务的许多附加属性，例如服务质量、安全性约束等，可能最重要的是在Web服务的运行过程中的状态描述，包括其输入和前提条件，以及输出和结果等，这些是对于其功能和能力描述所必需的。

文章的第二部分讨论了DAML-S对于发现和激活语义Web服务的作用，并进一步讨论了Web服务发现的不同方法和DAML-S处理模型的形式语义。第三部分集中讨论DAML-S怎样用于Web服务能力的发现，怎样在UDDI注册系统的基础上更进一步。在第四部分介绍了DAML-S虚拟机，主要用于第二部分介绍的”DAML-S处理模型”形式语义的处理。第五部分提供了DAML-S虚拟机运行效果的评价，我们可以看到其运行并不频繁。第六部分描述了一个具体的利用DAML-S组合服务的应用。第七部分是结论。

（语义Web服务图示及说明）。

服务描述一般包括三方面内容：服务能力描述；非功能性静态参数（元数据）；对该项服务负责的服务实体的描述。

服务能力描述：对于符合一定前提条件的Web服务输入产生一定的输出（返回消息），以及其间的副产品。例如一个付费新闻服务需要一个日期和信用卡帐号的输入，然后判断是否符合日期和信用卡的有效性以及信用卡没有被过度使用（超出信用额度的透支）的前提条件，所产生的输出是提交用户一个满足其日期请求的新闻网址，以及从信用卡中扣除相应的服务费用，其中可能会有非功能性静态参数（元数据）参与整个过程，例如对于新闻质量、收费标准以及新闻类别的选者和控制等。

处理过程和服务概要提供了描述Web服务的两个方面：服务概要描述服务内容和能力，而处理过程描述如何实现服务。例如Amazon的Web服务的概要描述了该网站的售书功能，而服务过程则必须详细描述为了实现卖书的过程，请求者必须首先查到他所需要的书，提供支付信息，并提供发货地址等。

*Sycara, K. (2003). Automated discovery, interaction and composition of Semantic Web services Web Semantics: Science, Services and Agents on the World Wide Web, 1 (1), 27-46 DOI: 10.1016/j.websem.2003.07.002

Technorati : DAML-S, Semantic Web

语义网命中多桀。一说是自1994年在李爵士的脑中闪现（见证据），然FOAF之父DanBri却用了一个图证明与Web是同时出现的（顺便一说，DanBri的头像实在是很酷哦），这是一张SW史前的草图，可惜是电子版，没有画在餐巾纸上，无法证明什么。为尊者讳，在互联网领域说一个东西很老是不礼貌的，虽然语义网大旗一直扛得很艰难，几乎被Web2.0抢了风头，但是现在可以改一个名头，称之为Web3.0，凤凰涅磐，浴火重生。

闲话少说，言归正传。Alex开篇就说，语义网是一个百变精怪，对于不同的人可能是不同的东西。让我想起emiller对于数字图书馆瞎子摸象的比喻：对于某些人来说语义网是Web中以RDF或OWL表示的数据（OWL实际就是一种RDF，RDF又都是XML）；对另一些人来说RDF干脆就是微格式；还有人认为语义网只是基于语义的Web服务，另一些人则认为是网络上的人工智能……

Alex的这篇“语义网范式(Semantic Web Pattern)”，主要把混沌一片的语义网应用和各种对语义网的认识进行了梳理，可以认为是当前的“语义网类型学”。

1、自底向上和自顶向下：从方法学上认识语义网。

2、主流标注技术：RDF, 微格式和Meta Headers(HTML文件头)。

3、用户分类：面向最终用户还是面向企业。

4、开放语义API。

5、语义搜索。

6、情境（上下文）技术。

7、语义数据库。

原文对上述每个类型都进行了简要的评述并列举了一些例子。文章发表后引来了很多讨论和争议。我们暂且不去评说这些分类和评述是否一定正确，从帮助我们学习和认识语义网的角度来说，还是十分有益的。

Ian和Carl认为这个观点有其局限性，“通常计算、数据和知识是彼此不可分割的，特别是知识不仅驻留在网格应用中，而且也渗透到网格应用和基础框架的全部有效范围内。”（作者认为一种更准确的体系结构应该是基于组件的，其中的各种宏组件协同工作）。

我 的想法也是基于这样一种分层模型进行，我认为如果把看成对象的信息、数据、知识（Semantic on the grid）与系统架构和实现所需要的“信息、数据和知识”(semantic for/in the grid)分开来讨论，这种分层架构完全是能够成立的。但是这个观点还没有进行证明，我目前还没有很好的形式化的方法能够对这一点加以证明，也还没有看到 那些采用分层观点的系统事先进行过证明。

语义网格(Semantic Grid)是目前最大的、以知识（信息的语义）为操纵/管理对象和目的的研究计划，最接近我们图书馆学研究的核心领域。前面我们探讨过，网格与Web服 务已经全面合流，前者称为后者的一种实现形式（或一种应用），可以看成以后者为环境的一组中间件构成的分布式计算平台，提供网络、硬件、软件资源共享的网 格能力。而语义网格则是语义万维网与网格发展的一个杂交，提供的是资源内容（信息）共享的能力，即信息系统的语义互操作的能力，这超越了计算机仅仅作为工 具的资源共享，而直取计算机作为其存在目的的共享――信息的语义。参见著名的图示：

解决信息语义的异构，正是数字图书馆梦寐以求的目标。网格架构的环境与数字图书馆的信息环境是完全一致的，都是分布式的广域网环境，只是数字图书馆在承认环境无序的前提下寻找一种跨语义的解决方案，而语义网格所开的药方是在Web环 境中再构建一个中间的环境，使得符合这个环境的信息体都具有语义互操作功能。两者的目的是一致的，途经不一样，数字图书馆很有借鉴语义网格、向后者寻求方 法论支持的必要。从解决问题的方案本质来看，形式化地描述信息，使其负载的语义能够为机器所解析和认识，从而利用人工智能数十年的研究成果操纵广域网信 息，是语义网格和数字图书馆的共同目标。语义网格甚至可以看成是数字图书馆语义互操作方案的一种特例。

关于语义网格立项时的“可行性报告”可参见：http://www.semanticgrid.org/v1.9/semgrid.pdf，详细介绍了语义网格的相关技术、分层模型、问题领域和技术构想，以下是“中国万维网联盟”的bbs上一位叫Whale的网友贴的一个帖子，内容的组织和翻译得都不错，就直接节选拷贝粘贴在这里了：

网格论坛组织GGF，也开了专门的板块来支持语义网格项目研究。目前已经有关于semanticgrid的国际会议和期刊目前语义网格的概念同知识网格应该相同，GCC2004上英国e_Science的首席科学家TonyHey作主题演讲时证实了这个结论。

语义网格的研究重点是用语义和知识工程的方法来解决目前网格平台建设和应用中存在的各种问题.其研究内容可以概括为以下几个方面.

1. 智能实验室(Smart Laboratories)

智能化的实验室是e-Science成功不可豁缺的,同时配置智能实验室可以充分挖掘Grid的能力.

2. 面向服务的结构（Service-Oriented Architectures）

研究语义网格设施的预备和实现,研究基于语义的服务描述语言.

3. 基于代理的方法（Agent Based Approaches）

研究Agent Based架构使用,研究交互语言以便开发\制定\维护e-Science marketplaces

4. 信任和证实(Trust and Provenance)

研究网格系统中计算信任建立的过程\方法\技术,决定内容种源和品质,这些涉及到数字权管理问题.

5. 元数据和注释（Metadata and Annotation）

元数据设施已经以RDF的形式存在,进一步工作研究支持ontology设计和运用的方法和工具,研究Annotation工具和方法.

6. 知识工具(Knowledge Technologies)

知识捕获工具和方法\动态内容连接(dynamic content linking)\基于注解搜索 (annotation basedsearch)\annotated reuse repositories\自然语言处理方法 (natural language processing methods )(for content tagging,mark-up, generation and summarisation) \数据挖掘(data mining)\机器学习(machine learning) \Internet 推理服务 ( internet reasoning services).

7. 集成媒体(Integrated Media)

把一系列的媒体合成到e-science基础设施中,包括视频\音频\各种图像方法\;研究 metadata和annotation同这些多样媒体格式的关联

8. 内容表达(Content Presentation)

研究内容的可视化技术和方法

9. 电子科研工作流和协作(e-Science Workflow and Collaboration)

理解现在和未来e-Science合作的工作流，拥护应该能够形成，维护和解散基于一定成员限制规则和操作规则的合作环境。

10. 普适电子科研(Pervasive e-Science)

不仅关注计算能力,更包括所有对所有资源的访问

面向语义的网格承诺带来语义可互操作性，智能自动化，行动指南以及灵活重用的优势，它日益被认为是网格计算演变中的一个重要阶段。我们将语义网格广泛的应用场景概括为以下几个方面的网格应用。

服务发现.

英国e-Science的领头项目myGrid寻求提供开放源代码的高层网格中间件, 用于形式化表达,管理以及共享生物信息实验中的密集数 据. MyGrid所用资源是开放网格体系结构的服务,这些服务能够静态或动态的与上下文结合.这里的上下文包括用户信息,执行代码,执行速度,可靠性和 对用户有用的适当的认证机制.能否找到正确的服务依赖于服务的知识.服务的语义描述对服务的自动发现,查找,选择,精确匹配,组合,交互操作,调用以及执行的监控都是必要的.在开放网格体系结构中, 服务规范提供了描述接口的语法, 但服务除了按照一定的参数和返回值要求执行操作,还应该按照一定的用户需 求来响应.

生物信息学家常常掌握着一些特殊的数据,他们需要找到服务来操作这些数据以便产生期望的结果,或者他们希望在这些数据之上应用一些任务. 他们必须表达他 们的需求,以便同可用的服务来匹配, 并考虑服务的功能,接收和产生的数据以及用于完成其目标的资源, 从而匹配用户的需求. 而且, 他们必须从能够完成任务的后选者中选出在请求约束下获取结果情况最佳的一个. 这种选择依赖于功能,代价,服务质量,地理位置和发布者相关的元数据.

基于提供的功能进行的这种服务分类正在被不同的组织采用,作为一种有效的查找.索引合适服务的方法.不同组织目前在服务注册的分类模式上是一致的. 比如生物信息学应用和仓库EMBOSS套件对本身所包含工具有一个粗略的分类,并且被当前众多的生物信息学集成平台使用.

MyGrid的一个假设是:第三方服务注册为可用的生物信息服务编目分类.服务描述的附加(个性化的)元数据使用RDF陈述来进行声明. 服务提供者发布 他们的服务,服务使用者通过多种机制,如名字,词语,特征,类型或本题描述来查找,匹配服务.myGrid生物信息服务本体基于DAML-S服务模型.服务描述分为两类:服务种类设计的领域名, 可调用服务实例的操作元数据(如数据质量,服务质量和代价等). DAML+OIL提供了服务描述的词汇。匹配首先对域进行匹配，然后是操作的属性。 副本服务（生物学里大量存在）之间有着同样的描述，但操作意义上的服务配置不同。在执行工作流之前，对服务类和他们的实例进行发现，匹配和选择。在执行期间，实例也可以动态的选择。

知识注释,通知和指南

Geodise试图用网格技术，设计优化技术，知识管理技术，Web服务和本体技术来构建一个具有目前最高水平的知识密集性设计工具，该工具要与OGSA 基础设施保持一致。Geodise正使用知识工程方法学来对设计知识进行建模，封装，以便航空引擎不见等新设计能够一更低的成本更快的开发出来。

Geodise首次使用的知识模式之一就是通过注释使工程设计流具有丰富的语义。Geodise希 望能够回答的一个关键问题是：以前的实际开发出什么以及怎么重用它们。一个典型的工程设计通常包括问题定义信息（几何方面）；工具用于划分网格或者将集合 设计拆分成能够进行分析的单元；然后，将优化方法产生的一组行为应用上去，以不同的参数进行实验，并得一组可能的设计方案。所有这些信息――如何四用软件 包的每一步活动――都记录在日志中。为了最有效的重用日志文件中包含的知识，Geodise项目中通过使用域本体术语从语义上丰富这些日志文件。经过语义扩充的结果日志形成一个知识库，该知识库可以被查询，索引和重用。这样一个知识库使的我们能够基于以前的经验，为当前的设计问题找到合适的解决办法。

工作流合成

工作流通过系统性计划将服务连接在一起，进行协调的组合。知识可以用于约束和知道工作流组合，并验证配置是否正确。

myGrid系统用于对用户数据选择适当的操作，并用于规定哪个操作接着哪个操作是合理的。在myGrid中，任务本体对工作流过程进行模拟，并用于注释 服务的输入和输出语义（当前用Web服务工作流语言来表示）。数据的语义类型必须匹配，比如，因为酶是一种蛋白质，而BLASTp以蛋白质作为输入，因此 酶的集合可以作为BLASTp的输入。语义兼容不同于语法兼容。两种服务可以在语义上相同，但有着不同的特征，对应的数据格式不同。反过来，两种服务可有相同的句法标签和操作名，但语义上完全不同。Geodise也实现了一个基于知识，辅助本体的工作流构建助手KOWCA.关于设计搜索和优化的通用知识要 转化成基于规则的知识库。底层知识库系统检查工作流的一致性，并对在工作流创建中下一步应该作些什么提出建议。

数据集成

工作流是服务集成的一种形式。另一种形式是数据和元数据的集成。通过描述公共模型中的元数据，实验的所有部分都能够相互关联，因此能够在其上进行推理。

对于语义集成，本体扮演两种角色：（1）由于数据模型是一种简单的本体，在相同的类型的数据库管理系统中的所有数据库要么使用相同的本体，要么 提供到标准本体的映射。（2）许多智能信息集成系统用本体代表一种映射原数据库的标准模型。用户根据目标本体提交请求，然后他们自动透明的转换成依据源本体的要求，也就是数据仓库模式。

协作服务

协 同会议涉及会议内容的实况交流，以及支持会议的基础设施操作信息。在最简单的情况下，信息可以是幻灯片或者远程投影仪控制。新形式的信息也可以互相交换， 如发言者队列，分布式选举，会议最新消息或者对以有文档的注释。另外，也可以进行小组讨论。这些都丰富了知识内容。共享，存储这些信息能够极大的丰富科学 活动的协作过程。

支持协作处理的一种方法是访问网格Access Grid. Access Grid主要集中于大规模分布式会议和培训的应用中。Access Grid 资源包括多媒体呈现和交互，特别是基于空间的可视化会议（组到组），以及网格中间件和虚拟环境的接口。Access Grid结点是专用设施，这些设施包括必要的高质量音频和视频技术，以及提供一种有效的用户体验。CoAKTing项目就是集中于集成智能会议空间，注释在线会议的媒体流。

语义Web技术和实时信息流两者的结合与网格计算高度相关。元数据流可以由人，设备或者服务产生，例如注释，设备配置以及实时处理的数据。会议空间不仅可以是会议室，它也可以是实验室甚至是小实验室。如在Comb-e-Chem项目中所研究的一样，会议空间配备有大量设备阵列和多媒体技术设施。当携 带一台设备到小空间时，需要发现并组合可用的服务，因为这与形成使用网格服务的虚拟组织紧密相关。

因为p2p网络目前作为一种广义的网格系统，现在技术也日益成熟，但是其中很多问题尚没有解决。目前关于semantic p2p的研究也是一项比较好的领域。

虽然现在有semantic web service研究搞得很火，但更多的关注于服务角度问题，网格架构从OGSA到WSRF也迎合这种趋势，但是网格同Web Service还是区别很大的，虽然都是面向服务的架构(SOA)，但是网格更多关注资源、计算层面的问题，p2p也是如此。

我对这种具体的项目感兴趣的原因并不是纯技术层面的，而是对其中”知识整序”模式和方法的兴趣，以及其背后的技术发展历史背景和社会心理原因，对知识认知的复杂性的简化、工具化和计算机化。这似乎又上升到哲学层次。

目前这个项目正在开发一个RDF可视化的本体：Fresnel并用之于本体表达，以及提高Longwell的性能（在普通服务器上处理GB级的RDF三元组和MB级的属性”面”），将Longwell与RDF收割集成，

看起来看似简单的RDF应用起来可真麻烦啊。这几乎能决定RDF的生死。想到RSS曾经名为RDF Site Summary并且至今1.0（支持RDF）和2.0版(不支持RDF)分属不同阵营，又搞出Atom等等，好在服务器都支持，对用户并无大碍，却苦了开发人员，也使得推广应用不如预期。

说起哲学，最近一直有个想法挥之不去，就是图书馆学的学科建设问题，从知识交流角度认识图书馆学，可以为图书馆学带来许多理论上的革新观念，然而却更使图书馆成为一种”前”科学–使其看起来还未从哲学中脱胎出来，哪位哲人说过，任何具体科学都始于哲学而终于美学。现在看来图书馆学除了操作性的、工具的、经验的内容之外，还应该有更多的哲学和科学认知（认识论）的内容，虽然看上去使其非常不成熟，但是至少能够使其更有理性，能够在信息技术主宰的世界中找到中流砥柱。甚至包括制度图书馆学，制度一定是人为”安排”的吗？在极端自由主义思潮下的西方，和受到多种社会政治文化因素纷扰的中国，任何社会事业作为一种明确的、以国家为主体的”制度安排”，都是不可能没有其深刻的、表现为莫名其妙的”经济文化环境”和”社会历史背景”的。这种”安排”是否可能是来自于一种”社会无意识”呢？如何达到（怎样的环境能够达到这种）社会无意识？在这里可能要对蒋老师说声抱歉了，没有机会仔细拜读蒋老师的制度图书馆学，在这里纯粹胡说。
关于Jena

Jena是一个由HP实验室开发的处理元数据（主要是基于RDF的管理、查询等）的Java应用程序。目前是Jena2版本，Jena1做到了支持RDF的数据表达、解析、查询（采用RDQL）和简单的推理，Jena2的目标在支持本体（包括DAML、RDFS和OWL的应用程序接口API）。

- 评论人：kevenlw

Tue May 24 08:56:52 CST 2005　

simile项目的piggy-bank工具推出了2.0版，功能大大增加，学习中…

- 评论人：keven

Tue May 10 13:06:01 CST 2005　

感谢孙馆长提供意见。我的看法好像正好相反，利益分配是制度的结果，而且制度背后更加有深刻的 社会历史原因。我们正处在转型期，治国缺乏哲学（和谐社会？以德治国？）将使所有的”制度”没有根基。

- 评论人：孙继林

Tue May 10 12:29:00 CST 2005　

关于制度我的理解是利益分配结果，比如公共财政，来自社会税收，办公共事业反馈于社会，促进社会文明和进步，推动生产力发展，增加税收，这是良性循环。
为了避免公共财政被个人侵占，或者浪费，就要制定相关的制度，财政拨款的程序，审计制度，公共事业管理人的选拔制度，公共事业的评估制度，具体到一个图书馆的馆藏建设制度、目录体系、借阅制度，都是为了保证公众的税收能够有效地使用，公平地使用，保证每个公民的利益。
如果制度缺陷，公共财政被个人侵占或者浪费了，就无益于社会文明和进步，乃至引起公众的不满，社会就要追加成本去纠正错误，就是恶性循环。我以为，图书馆的制度讨论要放到公共事业管理的框架里去讨论，就像大家讨论各地旅游景观门票涨价，不单纯讨论涨价后多收了几个钱，如何分配这些钱，而是要考虑自然和文化遗产保护，旅游大环境的发展，要从更多人利益角度考虑。

Technorati : Jena, RDF, 本体

语义万维网技术

万维网协会主席 Tim Berners-Lee 认为万维网的未来是”语义万维网”–万维网向机读信息和自动服务的延伸而远远超出目前的能力。在数据、程序、网页以及其他万维网资源之上的语义呈现，将使万维网成为基于知识的万维网，使目前的服务提升到一个新的水平。通过”理解”万维网上的内容，达到更精确的过滤、分类以及检索信息资源，自动服务将在更大的范围上帮助人类实现目标。这个过程将最终实现极端丰富的知识系统以及在此基础上的特别的推理服务。这些服务将有助于我们日常生活的方方面面，像今天人们对于电力一样普遍而不可或缺。

目前的万维网只是信息的堆积而不提供信息的处理，也就是说并没有把计算机当作一种计算设备。最近围绕 UDDI, WSDL, 和 SOAP 等发展起来的新技术正在把 Web 变成一种新的水平层次上的服务。应用软件课题通过万维网而获得和执行，这个技术叫做 Web 服务。 Web 服务通过提供一种程序自动交流、发现服务的机制，从而可以大大提高万维网体系结构的潜能。因而得到众多软件开发公司的关注。 Web 服务使电脑设备连接在一起，以一种新的方式使用因特网交换和联合数据。 Web 服务技术的关键在于使用松散耦合的”随时”组合可重用软件组件的方式提供服务。这从技术和业务两方面都产生深远的影响。

Semantic Web Service 似乎又多了一个兄弟： Semantic Web enabled Web Services ，欧洲 IST 的一个项目。

相关的项目、组织或网站：

http://swws.semanticweb.org/

http://swsi.semanticweb.org/

Software can be delivered and paid for as fluid streams of services as opposed to packaged products. It is possible to achieve automatic, ad hoc interoperability between systems to accomplish organizational tasks. Examples include business application, such as automated procurement and supply chain management, but also non-commercial applications as well as military applications. Web services can be completely decentralized and distributed over the Internet and accessed by a wide variety of communications devices. Organizations can be released from the burden of complex, slow and expensive software integration and focus instead on the value of their offerings and mission critical tasks. The dynamic enterprise and dynamic value chains would become achievable and may be even mandatory for competitive advantage.

Technorati : Semantic Web, SemanticWeb, 知识组织