《实用语义网》学习笔记（第6章）
作者: （美） 亨德勒 / （美） 阿利芒ISBN: 9787115193841 页数: 330定 价: 59出版社: 人民邮电出版社装 帧: 平装出版年: 2009-2-1
本章开始是我真正感兴趣的所在了：本 体建模和本体编码。渐入佳境。
（一）
- 数据表达（也是一种知识表达）可以基于多种模型，每 种模型可以有多种方法来表达，每种方法也可能有多种编码模式（Schema，如XML模式，数据库模式等）。模式告诉我们所有数据需要传递和表达的信息 （包括结构和语义）。就RDF来说，也有多种等效的方法，但虽然等效，处理方式可能大相径庭，不同的处理方法可能带来不同的“计算”能力（对于语义Web 来说，也是一种推理能力），以及对应于不同的数学运算方式。
- 例如RDF三元组表达，其本质上是图像（节点-连线图），但RDFS更适合 于用集合来表达。点线图的计算和集合的运算是非常不同的，这两种方法可以看成是模型表达的不同。相对说来，集合运算在数学上是非常成熟的。
- RDFS 可以看成是领域模型表达成RDF的形式化语言，就是说领域模型中的各类实体关系，都用RDF三元组来表达，写成RDF模式的序列化形式。当然数据实例，也 都是RDF三元组。这一方面降低了RDFS的应用难度（RDF标准在设计时吸取了XMLS的经验），同时却常常使初学者感到迷惑。好在这个迷惑的过程不会 很长。
- 所谓推理，在这里实际上只是比“检索”前进了一步，即不仅能检索出已经明确表达的知识，而且能够根据规则，判断出没有“显式”表 达出来的知识。应 用到RDF模式，就是不仅能对Asserted Triples进行查询，也能够对Inferenced Triples进行查询。这本来就是RDFS设计的初衷，当然没有问题。当然，如果RDFS本身的表达有问题，有矛盾，通过工具应该是能够检验出来 的，XML模式也可以进行Validation的检查，RDFS当然也行。
- 传统的描述数据的“模式”都不是存在于模式中，或者以模式的 编码方式存 在。例如关系数据库的“模式”，通常是附注文本，或单独的文件，面向对象的对象模型的“模式”也不是以对象的方式进行描述，早期XML文本描述的DTD定 义，也不是合法的XML文件。目前很多数据格式的定义模式一般都采用与数据格式相同的方式，例如通用Lisp的元对象以及Java对象模型的API自定义 表达都是采用自身相同的语言定义模式，XML Stylesheet，以及XML模式，也采用XML方式进行定义。
- 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:小说 - 当然，要使计算机理解 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等等）两方面进行扩展。任何元数据方案以及本体模式，都是组成语义网标准规范体系中的成员，都是对语义网的贡献。
Popularity: 54% [?]
Tags: OWL, RDFS, 实用语义网, 笔记, 语义Web, 语义技术Related posts
《实用语义网》学习笔记（1-5章）
下面是看书时随手记下的内容，为了加强印象，特别是看原版书，不记一些东西很快就扔到爪哇国去了。笔记不一定正确，贴在这里供大家批判。
作者: （美） 亨德勒 / （美） 阿利芒ISBN: 9787115193841 页数: 330定 价: 59出版社: 人民邮电出版社装 帧: 平装出版年: 2009-2-1
第 一章 什么是语义万维网
- 这的确是一个很难向普通人解释的问题，我们来看看两位大师是怎么做的。
- 首先他们介绍了 本书的主题：关于语义万维网 和本体建模。语义万维网顾名思义，肯定是关于万维网的，而且要表达语义。语义按照一般的解释，就是自然语言所表达的含义。本体建模为什么有必要谈呢，主要 是因为W3C固然搞了一大套东西，但不同的工匠做出的活儿肯定是不同的，本书是要教导你做出漂亮的活，而不是粗糙的、仅仅符合W3C那些定义的活。
- 然 后解释了Web的伟大意义，即任何人可以在上面就任何话题说任何话，即AAA口号(Anybody can say Anything about Any topic)。这正是Web的魅力和价值所在。万维网的价值与它参与者的数量和资源数 量成正比，万维网的魅力就在于它是一个不断增长的有机体。那么语义Web又能做什么东东呢？作者举了两个Web应用例子（涉及到四个网站），一个是会议旅 馆信息不同步，一个是冥王星被驱逐出太阳系九大行星行列之后，一些网站的信息同步问题。作者在后文中还会用到这两个例子。
- 通过这两个例 子，说明目前的Web是有很大缺陷的，同时说明，语义Web就是要解决这些个问题。作者称之为“聪明的Web和傻Web”的问题。
- 接 着作者探讨了如何使Web变得聪明，在现有的Web架构中，你不可能提供一个集中式的管理方法，或者架构，使其“聪明”起来，任何这种企图在开放的、分布 式环境下都是不可能的，不仅是经济上不可能，操作上也不可能。所以作者对“聪明”的Web有一个定义，就是需要把数据在适当的时候，以适当的方式呈现出 来。语义Web的架构只要实现这个，就够了。
- 然后作者又对“聪明的程度”作了探讨，聪明并不意味着绝对正确，不可能存在绝对真理，语义 网“容错”是一个关键问题，如何容错，如何继续允许AAA，同时建立自己的过滤和“权威”审定机制，也是这个架构设计中的重要方面。目前主要采用唯一的 URI命名来共存，以及采用RDFS标注来说明概念间的关系。
第二章 语义建模
- 首先介绍了模型的概念：对事物的抽象，隐藏细节、反映概貌，以及模型的作用：沟通、解释预测以及协调不同意见。
- 模 型描述用自然语言在人和人之间交流，比通过计算机交流，要容易得多。人类的交流通常隐含了很多前提条件（语境），例如知识、文化、科技、宗教背景。当然， 也会因此而造成理解程度的差异。
- 整个一章基本上是围绕模型的三个功 能：communication，explanation/prediction，mediating来写，最后着重说明了如何表达异见、以及表达能力有 高有低等问题。
第三章 RDF－语义Web的基础
- 首先提出，语义Web所涉及的语义，不同于符号语义学很复杂的东西，而仅仅是为所涉及的“资 源”给出了一个链 接，作为资源名（即URI）。实际上给出了语义Web一个基本假设：链接即语义。有了这样一个URI，任何指代的东西就有了根据，通过这样一个基本的三元 组的建立，使得认知三角形得以成立（实际上是这样一个认知模型），从而提供了逻辑的结构基础（砖块）：三元组构成的判断式，从而所有的推理运算可以在此基 础上展开（例如一元谓词逻辑的所有计算，最简单的等同计算，以及通过RDF建立关系链接能够表达的所有关系计算——超类，子类，以及通过OWL描述逻辑能 够进行的更复杂的计算，如“非”等等）。
- 本章通过一个莎士比亚戏剧作品的年 表，展示了如何从关系数据库的表单结构表达的隐含语义，转化为分布式Web网络环境上可被获得的三元组链接。这也印证了人们对语义Web的一个通常的说 法：语义Web就是分布式环境下的关系数据库。介绍了表达三元组的技术细节（如说明了采用qname的URI由怎样的两部分组成）。本章的最后提了本书的 第一项“挑战”（Challenge，类似于作业或操练，不过紧跟着就提供了答案和讨论，非常有启发）：把一个关系表转化为RDF表达。这是很有特色的一 种写法。最后还讨论了高阶（逻辑）关系和三元组（RDF）的其它表达（序列化）形式：N-Triples, Notation 3(N3), RDF/XML, 空节点（Blank Nodes）
第四章 语义Web应用架构
- 首先解释了在这样一本以“建模”为题的著作里，为什么要介绍“架构”（Architecture）， 因为这本书同时也 是for working ontologist，要具有实用性。为了解释如何使用，必须要介绍语义Web的高层架构、组成、内容（输入inputs）及来自何处、以及如何用到 RDF的优点、与其他架构的不同之处，等等。
- 支持语义网应用的软件主要有以下几类：
- RDF解析器 （Parser）/序列化工具（Serializer）；
- RDF 库（Store，又称三元组库：Triple Store）；
- RDF 查询引擎（Query Engine）；
- 各种专门应用（Application），如后面介绍的转换器、刮擦器等等。
- 目 前实现所有语义Web应用的底层技术还是以关系型数据库为基础的Web三层应用模式，只是其中增加了语义处理的内容，如查询部分需传递SPARQL语句， 处理和存储部分都需要支持RDF三元组数据，等等。
- 本 章后面其实没讲什么“架构”，都讲各类语义应用/软件了，例如：转换器converter/刮擦器scraper（指从HTML网页或传统应用中获取语义 信息——通常是RDF数据——的工具，当然可以通过各类微格式或其他准标准文档格式进行“刮擦”，通常需要编写GRDDL来实现）；RDF库的互操作解决 方案；查询和提问标准及其与SQL的比较；基于RDF的门户等，最后对于跨库的数据合成（特别是动态合成，类似于Mashup）。
- 上来就引述第一章讲到“傻瓜数据”时所举的例子：“傻瓜 数据如何基于更多的互联关系而使Web上的应用更聪明”（how a more connected Web infrastructure can result in behavior that lets smart applications perform to their potential）。其实当时也没怎么看懂，姑且继续往下看去。
- 基 于RDF的数据整合最大的好处，是保证分布式环境中数据的一致性（consistency）。数据的整合视图可以通过整合数据和整合提问两种方式得到，整 合提问通常需要架构的支持，并且需要适当的提问构建工具/环境以方便构建整合视图。
- 前文中“衣物和衬衫”的例子可以用规范词表的形式来 解决，如规定衣物是衬衫的上位概念，这样在查询衣物时，它的所有下位概念都会出来。这也是一种推理。
- 著名的语义Web堆栈图已经充分说 明了提供推理支持的语义网架构，这个架构是基于RDF，以及以RDF为基础的描述模式的。
- 推理引擎能够判断并未描述出来 的逻辑，不同的引擎判断的能力不同，RDFS和OWL的引擎就有所不同。
- 对于RDF库来说，有两种方式支持推理：Asserted triples和Inferenced triples，其区别类似于实时索引和物理索引的区别，极端的情况是，要么把所有能够推理出的三元组全部都罗列出来，放入库中，要么能不放都不放，所有 的三元组查询都通过规则实时导出。前者利用空间节省时间和计算能力，后者利用计算能力而节省了空间却牺牲了时间。对这两种做法进行动态更新时会碰到不同的 问题，在实际应用中，很难说那种更好，一般都采取折中的做法。
Popularity: 57% [?]
Tags: OWL, RDFS, 实用语义网, 笔记, 语义Web, 语义技术Related posts
语义表达是不是一定要用RDF？
昨天参加了一场博士论文答辩，内容有关语义Web应用，论文架构很庞大，从基本概念、标准规范到元数据和本体的构建，到特定领域应用的实现和查询效果的比较等，感觉该童鞋很不容易。
答辩期间问了两个问题：
1、对于“语义”是如何理解的？机器如何理解语义？是不是Web加了元数据之后就是语义Web了？
2、如何对语义进行编码和查询？为什么没有试验用SAPRQLSPARQL进行查询？
第一个问题是因为论文中罗列了很多语义Web的定义而没有对语义进行定义，更没有说明语义是如何能被机器“理解”，保证机器理解的机制到底是什么？整篇文章给人的感觉好像是对于Web进行了元数据（语义）标注之后就是语义网了。
第二个问题是针对论文认为语义标注必须首先用XML进行结构化，RDF以及KOS转换的本体（OWL)起什么作用都没有明确说明，有点知其然不知其所以然的味道，后面更是没有提到语义Web查询语言SPARQL的独特作用，而是用SQL实现对语义数据的查询。
该 童鞋对于这两个问题的回答还是基本到位的，第一个问题她说到了语义就是所表达内容的含义，需要通过形式化编码才能被机器理解；第二个问题说需要用基于 XML的语义描述语言进行编码，因为在实验系统实现的过程中没有直接支持RDF的数据库系统，所以无法用SPARQL进行语义查询，等等。
这里想补充一些我的认识，有些认识可能比较绝对，对与不对大家可以批评指正。
1、 对于语义Web而言，RDF是基本的编码方式，是不是用了RDF可以作为具不具有明确外在的语义编码的判定标准。就是说，用了RDF，才能说是有语义的， 就像用了ASCII等字符编码标准才能进行文本编码一样。元数据可以不用RDF来表示，但是RDF是专门为了表达元数据而发明的语言（或者说框架或结 构），因为元数据就是“关于数据（主体）的数据（客体）”，主客体通过某种方式（谓词）相联系。这个问题在计算机界一直有争论，但是我这里对RDF的定义 是三元组方式，不一定是XML表达的三元组，也可以是其它方式（如N3等)表达的三元组，或者通过数据库方式能够输出三元组。本体OWL和SKOS都是基 于RDF的，因此它们肯定是表达语义的，而用XML自定义的任何表达方式，可以认为是系统内部局部的语义表达方式，到Web上就不具有可交换性了。因此它 虽然是结构化的，但不是表达全局语义的。
2、RDF是表达机器语义的必要条件，但并不充分。在语义Web中，必须结合URI机制，才能赋予任何一 个表达（资源）的全局语义，当然这个全局也仅仅是对于开放的Web来说的，这也就是URI能够解析的范围。任何一个局域网，无论其规模再大，都可能屏蔽这 种机器语义，而具有其独特的、更丰富的语义。因此，元数据和本体可以适用于比语义Web更广泛的领域，但到了Web上，这些内部语义如果要进行分享、重 用、交换，都有互操作问题。现有的技术架构、模型方案等，都是为了规范和减少这些互操作问题而提出。
3、采用了语义技术，语义Web就可能借助于SKOS或OWL等编码表达的概念体系，进行基于概念的检索，并可能进行知识挖掘和简单推理。SPARQL提供了强大的知识查询能力。
从理解XML到理解RDF，似乎在“思考范式”上要有一个转型。许多搞计算机的人都无法理解，对语义Web认识一直有一个障碍，就是“管它语义不语义，机器懂什么语义？系统只要能满足用户的需求，什么技术不能表达语义？”希望上述解释能够回答这个问题。
Popularity: 27% [?]
Tags: OWL, RDF, 元数据, 语义技术Related posts
就建立“主题描述模型”与雨师的对话
Popularity: 65% [?]
Tags: OWL, SKOS, 主题描述, 知识组织, 语义技术Related posts
关于OWL-S的服务描述- -
服务发现是否假设请求者和提供者使用同一本体？肯定不是。否则 OWL-S 的使用会大大受限，甚至失去意义了，因为其目的本来就是为了寻找合适的本体，其前提假设就有问题。（但是是否假设使用同一本体编码语言呢？也不应该是，但是不一定）
会对本体中介进行一些规范吗？就像 WSMO 对面向对象的中间件一样？虽然可以这样做，但是至今还没有这方面的研究计划和进展。 OWL-S 是采用 OWL 语言的一种服务描述语言，并不规定是否一定有中间件或者服务实现某些功能。
是否仅包含输入描述和输出描述？答案也是否定的。 OWL-S 纲要是用于”广告”语义 Web 服务的，描述的内容包括服务描述、产品描述、输入、输出、前提条件、效果、存取条件、服务质量、安全参数等等，凡是与服务有关的参数均可以用 OWL-S 进行描述。
来自于Katia Sycara” < katia+@cs.cmu.edu >的一帖关于owl-s服务描述问题的澄清，感到有必要存档一下。
There were a number of issues raised in this discussion:
1. Does OWL-S discovery assumes that requesters and provides use a unique ontology?
The answer is NO. OWL-S does not assume the use of a single onrology. It is difficult, however, to see what you mean by “one single ontology”. If you mean “one single OWL file”, then of course trivially OWL-S does not assume a single ontology since you can import as many OWL files as you desire in an OWL-S description, and use any of the concepts defined in those files to describe the OWL-S profile or any other OWL-S component. During the discovery process the Profile of the requested service may refer to a concept, say a:A (the concept A defined in “file” a), and an advertisement may refer to concept b:B that belong to a different ontology (different owl files), and yet b:B may be defined as a subclass of a:A. In this case, matching engines would still be able to match exploiting the logical relation between A and B. At CMU, we have shown different kinds of matches (e.g. exact, plug-in etc) in our matching algorithm (see e.g. [3]).
Another way in which the use of different ontologies can be handled in OWL-S is through mapping rules that could be expressed in SWRL. In this way, to the extent that the similarity between A and B can be made explicit, then the mapping can be exploited. Of course there are issues of where these mappings live, how it is discovered where they live, since of course in the process of service discovery one does not know a priori what the ontological needs of one request would be vis a vis the current advertisement knowledge base. Even if one assumes a unique knowledge base containing such mappings, another set of issues is of course, how this knowledge base gets searched efficiently. 我的论文的一部分就是要解决这个问题：采用登记服务自动完成映射工作，但是基于怎样的请求？机制仍然成问题。
The issue of ontological mapping is an old and well known one that has predated Semantic Web Services. Work on how to express mappings to achieve semantic interoperability efficiently (even assuming the mapping rules are known) has been going on since the late 80's (perhaps even earlier).
The general problem of arbitrary ontology mapping is an open research problem. The real scientific work is in trying to attack the technical issues that I outlined (and others that are there but I did not refer to). After we solve these scientific problems (ie. How to derive the mappings, and how to use them), we can worry about what to call the algorithms.
Since ONTOLOGY MEDIATION is an open research issue, OWL-S is agnostic about the actual ontology mediation process used.( 这方面应该有研究论文，也可以参考一下，属于论文中创新性的内容 ) To the extent that the mediation process is a service, rather than a set of rules, it can be represented in OWL-S and discovered.
2. Should OWL-S do something about ontological mediation like WSMO is doing with the OO mediators?
Up to now, there is no clear operational definition of what a WSMO mediator is, neither is there a clear specification of an ontology or language for describing mediators, or an algorithm for ontological mediation.
To the extent that WSMO mediators are services, rather than sets of rules, they can be represented in OWL-S by specifying what is their profile, process model and grounding (for a detailed discussion on this point see [2]). Furthermore, the discovery mechanism may then become similar to a composition procedure where you combine discovery of the appropriate mediator with the discovery of the appropriate service.
Note that if you take this viewpoint, the sentence “OWL-S has no mediators” is non-sensical: it is analogous to sentences like “Java has no Operating System” or other such sentences. OWL-S is a language (it uses OWL semantics) that allows you to describe Web services, it does not tell you what infrastructure Web services need, nor does it stipulate the existence of mediators or of a discovery registry or any other component. If you think you need a mediator, the role of OWL-S is to provide you the tools to describe a mediator if you decide to implement it as a Web service. If you look at [2] there is a discussion on how to do that.
Popularity: 27% [?]
Tags: OWL, web服务, 语义技术Related posts
关于OWL-S应用的一些问题- -
关于 OWL-S 应用的一些问题（摘自 W3C 语义万维网讨论组 public-sws-ig@w3.org Evan K. Wallace 的一个贴子）：
Eric Miller 在最近的一次会议上提到，许多软件公司对 OWL-S 的应用似乎比当初 RDF-S 和 OWL 来得迟缓，究其原因，大概是因为 OWL-S 目前还是一个 W3C submission 而不是推荐标准，正在讨论之中，变动还会比较大。另一方面好的工具比较少，参考文档和参考案例不多，也影响了应用。
实际上与 OWL-S 处于同一水平层次上的同类技术规范很多，例如 XPDL, BPML, BPE4WS, ebBPSS, BPRI, WMF, 以及 UML2 Action Semantics 等等。 其它更为形式化的如 PSL 和 SWSL 。 OWL-S 似乎并没有像 OWL 一样在同类语言中鹤立鸡群（特别作为概念建模语言方面）。 OWL-S 似乎没有吸收足够的同类语言的成果。
Popularity: 27% [?]
Tags: ontology, OWL, 语义技术