Archive for the ‘语义Web’ Category

URI简要说明

星期日, 十二月 5th, 2010

作为对前一篇博文的补充,感到有必要把URI的概念再炒炒冷饭。

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

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

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

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

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

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

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

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

文档的Web和“东西”的Web

星期日, 十二月 5th, 2010

两年来一直想做一些关联数据的普及工作,总有一种无从下手的感觉。这个话题越来越热,有远洋师和雨师等的号召和书社会众社员的积极响应,感觉似乎时机成熟了,于是先放出风去,给自己一点不得不做的压力。

关联数据的概念想法其实很简单,但同时又很难让人理解,这是个很有意思的现象。是不是可以拿刘谦的魔术来类比,不知道的看不懂,知道了其实都是业内常见的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“#”两种实现方案各自的特点)。

Tags: URI, 关联数据, 文档的Web, 语义Web, 语义技术

Related posts

《实用语义网》学习笔记(第6章)

星期一, 三月 15th, 2010
《实用语义网》封面

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

第六章 RDF模式(Schema)

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

(一)

  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等等)两方面进行扩展。任何元数据方案以及本体模式,都是组成语义网标准规范体系中的成员,都是对语义网的贡献。

Tags: OWL, RDFS, 实用语义网, 笔记, 语义Web, 语义技术

Related posts

《实用语义网》学习笔记(1-5章)

星期一, 三月 15th, 2010

下面是看书时随手记下的内容,为了加强印象,特别是看原版书,不记一些东西很快就扔到爪哇国去了。笔记不一定正确,贴在这里供大家批判。

《实用语义网》封面

作者: (美) 亨德勒 / (美) 阿利芒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)。
第五章 RDF与推理
  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,其区别类似于实时索引和物理索引的区别,极端的情况是,要么把所有能够推理出的三元组全部都罗列出来,放入库中,要么能不放都不放,所有 的三元组查询都通过规则实时导出。前者利用空间节省时间和计算能力,后者利用计算能力而节省了空间却牺牲了时间。对这两种做法进行动态更新时会碰到不同的 问题,在实际应用中,很难说那种更好,一般都采取折中的做法。
Tags: OWL, RDFS, 实用语义网, 笔记, 语义Web, 语义技术

Related posts

几个概念:开放数据,关联数据,语义Web和Web3.0

星期三, 一月 20th, 2010

针对童鞋们经常提问,以及本人根据网络资源和自己的理解整理如下:

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

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

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

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

Tags: linked data, Open Data, Web3.0, 关联数据, 语义Web, 语义技术

Related posts

语义万维网服务的自动发现

星期五, 八月 21st, 2009

20090822-update:本文为加入Research Blogging而修订(在文后添加了他们所要求的引文代码,以便集成到RB的平台上),日期也应要求改成今天(原来是2005年2月24日)。需要说明的是,W3C的语义网服务发现的技术框架目前已经有了很大进展,目前轻量级的、更加松散耦合的approach逐渐占了上风,估计这种繁复和缺乏灵活性的方案不会得到普及。目前“关联数据(Linked 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 : ,

Tags: web服务, 研客, 语义Web, 语义技术

Related posts