orangebench's blog--语义Web step-up

8/27/2004

知识,本体的概念

• 本体

1) 数据, 知识 , 知识库
http://computing-dictionary.thefreedictionary.com/KnowLedge

knowledge - The objects, concepts and relationships that are assumed to exist in some area of interest. A collection of knowledge, represented using some knowledge representation language is known as a knowledge base and a program for extending and/or querying a knowledge base is a knowledge-based system.

Knowledge differs from data or information in that new knowledge may be created from existing knowledge using logical inference. If information is data plus meaning then knowledge is information plus processing.

A common form of knowledge, e.g. in a Prolog program, is a collection of facts and rules about some subject.

For example, a knowledge base about a family might contain the facts that John is David’s son and Tom is John’s son and the rule that the son of someone’s son is their grandson. From this knowledge it could infer the new fact that Tom is David’s grandson.

知识是可以推理的数据,也就是说有形式化的语义的数据. 知识库就是用知识表示语言表示的一个知识的集合。

2）本体，本体库，领域本体
本体：共享概念模型的明确的形式化规范说明
领域本体：特定领域的本体，区别与通用(即领域无关的)本体，如CYC, WordNet
本体库： 一个本体集合？

所以，知识是可以用本体表示，但并不是所有知识都适合用本体表示，如不共享的知识，即Context, 或者“我的小秘密“， 不是表达概念模型的知识，如领域的具体应用相关的知识，即一些facts。

但是在OWL中，本体和知识库这两个概念的区别很模糊。因为OWL本体可以包含一些facts的声明，因为一个OWL本体实际对应于一个描述逻辑的知识库。但通常来说，应用相关的facts不包含在本体中的。

OWL Full真的没用吗？

• OWL
• 语义Web应用

关于OWL Full，我以前有个看法：认为它没多大用，因为推理是不可判定的。现在在反思，不可判定的形式化系统，真的在实际中（特别是在语义Web的应用中）就没有多大价值吗？

在传统的知识库中，由于追求知识的绝对真值，还有可靠性，完全性啊，等等，不可判定好像是对人打击挺大的，好像是没多大用。但在语义Web的场景下，这些约束也许都可以放松，Tim Berners Lee在他的design note里就宣称要一种表达能力很强的语言，甚至是高价逻辑，对推理的要求倒不高，因为语义Web和并不追求知识的绝对正确性。 这些关于语义Web对传统AI研究的理论问题的影响我也说不清，只是觉得会有些本质的不同，只是我不懂。希望听听大家的看法。

让我感觉OWL Full是有用的一个实例是: FOAF, 它的本体就是基于OWL Full的，因为把datatype-valued property声明为inverseFunctional 了。说OWL Full不可判定，并不是每个问题都不可判定的，而我们常碰到的问题是可判定就好了。另外一个例子是，Jena对OWL推理的实现，它是用规则引擎RETE作为基础的，把OWL的公理表示为一些规则，但可靠和完全的描述逻辑推理都是基于表演算的，也就是说 ，Jena中OWL的推理是不完全的。也许语义Web中的推理对完全性的要求都可以放弃，何况可判定性。

我以前说过OWL Full没用，我现在想收回这句话，并表示道歉。OWL Full是值得好好研究的，它的应用也许会出乎我们的想象。

OWL 语义中的comprehension principles

• OWL

为什么在OWL Full语义中要comprehension principles呢？先举个例子：John 是概念Intersection（A B C）的实例，能否推出John 是概念Intersection（A B）的实例呢？如果OWL FULL照搬RDF的语义，它是推不出来的。因为在RDF中，类也是实例，我们无法保证在所有在John是概念(A,B,C)的交 为真的解释中，存在一个对象 Intersection（A B）（注意：Intersection（A B）必须是论域中的一个元素）。
问题在于：一些OWL的类表达式必须同时也是一个实例，所以，OWL FULL语义中利用comprehension principles为每个类表达式添加一个对应的实例。但循环定义不能有comprehension principles，因为会导致语义悖论。
参考：
【1】Jeff Z. Pan and I. Horrocks. RDFS(FA) and RDF MT: Two Semantics for RDFS. In Proceedings of the 2nd International Semantic Web Conference (ISWC2003).
【2 】From SHIQ and RDF to OWL– The Making of a Web Ontology Language

能否找到一个OWL Full的RDFS兼容的，可判定的子集？

• RDF
• OWL

我们知道，用OWL 描述本体有个很烦的跷跷板现象：
1） 如果用OWL DL或Lite 描述本体，则当用RDF表达关于这个本体的事实部分的时候，大部分RDF的功能都不能用了，如类可以当实例看，属性的属性，关于声明的声明（reification）,而这些功能正是RDF的鲜明特性，如果这些都不能用，还能叫RDF吗？
2） 如果用OWL Full 描述本体，一切Okay, 完全兼容RDF(S),RDF的全部功能都能用，但是描述逻辑学家告诉我们：OWL Full是不可判定的，目前没有推理机完全实现了对OWL Full的推理（或许二价逻辑的推理机可以），这等于在说，OWL Full实际上是没用的，提出来，就是为了安慰RDF(S)： 哦，OWL没有完全背叛RDF，有个大佬和RDF兼容了。

RDF(S)本身是一个非常完美的形式系统，有形式化的语法，语义，而且是可判定的，还有证明论（entailment closure）,并且是可靠和完全的。但RDF Schema表达能力实在是太弱了，没法构造概念，关于属性就一个定义域和值域。 我一直在想，我们能否找到一个OWL Full的子集，扩展了RDF Schema的表达能力，且完全兼容RDF Schema，并且是可判定的，不像OWL DL那样不兼容RDF(S), 不像OWL Full那样不可判定。

大家有什么看法？ 这个可判定的OWL Full子集 又在何方呢？

ER模型，OO模型(UML)，文档模型(XML Schema)，KR模型（OWL 本体）之间的异同

• OWL
• 语义Web应用

ER模型，OO模型(UML)，文档模型(XML Schema)，KR模型（OWL 本体）之间的异同

现在，开发人员对一个系统建模的时候，会面对各种各样的模型，用OO模型设计类结构，用文档模型设计消息格式，用ER模型设计数据库表，如果再利用SW技术，还要用KR模型设计领域本体。这么多的模型，他们之间到底有哪些异同点？在系统开发的时候，我们应该从哪个模型出发？怎样维护模型之间的映射，同步？

未来的系统设计人员的痛苦

• 其他
• 语义Web应用

我觉得将来做系统设计的人好累哦，他要了解n种模型和体系结构：
1）对领域建模：
KR模型：OWL本体，领域中的概念模型
OO模型：UML, 领域的类设计
文档模型： XML Schema, 消息交换用到的文档
ER模型： 最后这些东东怎么存在数据库中
这些模型之间的映射，一致性的保持，需求变更处理，以及，设计流程，如到底是从哪个模型开始呢，这些都是很困难的问题。
2）系统体系结构
MDA: 模型驱动
SOA: 基于服务
这两种体系结构如何SW技术结合起来，也还未知。

总之，如何把SW技术应用于信息系统，并和已有技术的协作融合，都很值得去研究，哪位能介绍一下这方面的经验和进展？谢谢先。

OWL allValuesFrom 的小trick

• OWL

allValuesFrom 推不出someValuesFrom

“allValuesFrom指的是，如果该属性有值，则必须来自指定的类”，如果该属性没值，则恒成立。没学过数理逻辑的人会觉得不符合直观，但这是没办法的。 例如，如果你没有孩子，别人问你，“你的孩子都在哈佛吗”，我们当然会觉得这个问题很傻瓜，但逻辑必须给一个“是“或“否”的答案。大部分逻辑学家觉得答案为“是”更有道理，因为答案为“否”的话，言外之意，我至少有个孩子，但事实上，你没有孩子。

语义Web的应用报告

• 语义Web应用

下面有对SW应用的全面分析，并且选出了两个最有代表性的应用：Semantic blogging和
Semantic Portal, 有详细的需求分析，实现描述，源代码。

Workpackage 12.1: Open demonstrators

12.1.1 Open demonstrators: Semantic web applications - analysis and selection (pdf), (html) Appendix: Application survey (pdf), (html) 
12.1.2 Semantic blogging and bibliographies - requirements specification (pdf), (html) 
12.1.3 Demo 1 Implementation (pdf), (html) 
12.1.4 Semantic Blogging - Lessons Learnt (pdf), (html)  
12.1.5 Semantic Portals - Requirements Specification (pdf), (html) 
12.1.6 Semantic Portals Demonstrator, (html) 

语义Web的价值

• 语义Web理论

关于SW的价值，昨天刚看到一篇文章，是HP实验室的人写的，他分析了3点：
1）数据表示：“The foundation of the semantic web is a common format, RDF,to represent data. ”
2) 语义：The aspiration of the semantic web is to be able to express meaning. The schema and ontology layers of the semantic web begin to do this。
3）Webness: The critical innovation of the semantic web is to put both these values into a web framework.

参考 http://www.w3.org/2001/sw/Europe/reports/demo_1_report/

语义Web的思想

• 语义Web理论
• 语义Web应用

1） 语义Web是让计算机能够理解并自动的处理Web上的内容，并不是通过人工智能方法，如自然语言理解，或机器学习来实现的,而是通过制定统一的标准，包括RDF，OWL来实现。“It only indicates a machine’s ability to solve a well-defined problem by performing well-defined operations on existing well-defined data. Instead of asking machines to understand people’s language, it involves asking people to make the extra effort”―― Tim Bernes-Lee, What the semantic Web isn’t but can represent.

2） SW的一个任务可以理解为Webize KR，即如你所说：” 把人工智能或知识工程方面的这些成果转移到Web环境中”, 很多传统的AI难题的确一样会在SW研究中碰到，如context, action, non-monotonicity, paraconsistence。AI一直没有像早期所声称的那样改变世界的原因之一就是AI以前大多追求集中式的，封闭的知识处理。而SW通过把知识Web化，并且抛弃AI中那些完全知识，绝对正值，可证明性等限制，很有可能真正地使AI改变世界，正如Web把传统的HyperText全球化的效果。但研究SW是否一定要有AI研究的基础呢，我觉得SW为AI带来了很多新的问题，而这些问题用传统的AI方法并不适合，而其他领域的方法更为适合，如数据库技术。

3） 关于SW的应用，我一直没时间真正去做一个系统，所以也一直很想听听真正做过系统的人的观点。我说说自己的猜想：a）相对与传统的基于数据库的信息系统而言，如果这个系统是完全封闭的，不会和别的系统打交道，如果这个系统的模块没有重用的价值，则用不着SW技术。对这种系统用SW技术的优势在于：把数据用RDF表示，便于重用，以及系统的互操作性，另外RDF表示的数据处于概念层次上，独立于数据表示的格式，如库表的设计。b)相对于基于XML的信息系统，我觉得RDF完全可以作为XML的替代，因为RDF就是有语义的XML数据。

也就是说，SW技术可以应用于大部分的信息系统，只要有元数据的地方，就可以用RDF，因为RDF本身就是一种元数据表示语言。在数据库系统中，元数据是库表的Schema,在XML信息系统中，元数据是XML的标签和XML Schema，而RDF+RDF Schema完全可以做为他们的替代品，而它的优势之一就是它是有语义的，机器可理解的，而且Web化.

sementic web的意义何在

• 语义Web理论
• 语义Web应用

Semantic Web可以分两层理解：
1）RDF是统一的元数据语言，在图书馆能用作者名，书名查询，而在Web上只能用关键词查询，原因在于Web上的数据没有元数据。 即使RDF没有推理能力，这种统一的元数据语言也非常有用。
2）RDF表示的Web上的元数据还可以推理，可以发掘隐含的知识，聚集分散的知识，这就是本体的作用，因为本体提供了领域的概念模型，背景知识等等；

Semantic Web不会很快就能实现，但我一直觉得Semantic Web技术可以很快应用于实际的信息系统。

一些后继的想法：

第一层对应的实际就是RDF/RDF Schema,着重的是元数据格式； 第二层对应的就是OWL本体了，因为着重在强大的推理能力。

从目前来看，第一层RDF（S） 较容易被人接收，因为RDF Schema一般都比较简单，而这种统一的元数据格式又非常有用。目前较为成功的SW项目基本都在这一层面上，如FOAF，RSS 1.0(Atom)，Dublin Core。他们的一个共同特点就是简单，容易被人接受。

而OWL层呢，首先建个本体很麻烦，其次推理时间复杂度太高，我感觉会很难真正在Web上得到广泛应用，它的应用场景可能在一些基于SW技术的信息系统中，如企业Portal，企业的知识管理，等。

结果是：在Semantic Web上RDF层可能会跳过OWL层，直接和上面的层次打交道，如rule，proof, trust。

基于语义Web技术的MIS与基于XML技术，传统MIS的比较

• 语义Web应用

摘要：我们描述一个简单的业务系统的用例，然后介绍不同的实现技术及其比较。

我没有做过实际的基于SW技术的信息系统，因此本文只是一些猜想性的东西，希望抛砖引玉，能得到大家的指教,也欢迎大家补充，谢谢！
注意我们讨论的对象是传统的MIS系统，如图书查询系统，学生管理系统之类的。

用例： 用户在查询界面选择查询条件，如搜索论坛的帖子，有主题，作者，时间限制
实现： 按通过的B/S框架，分为三层：表示层，业务逻辑层，数据层

目前常用的技术方案：
1） 表示层： Web表单。 JSP/servlet
2） 业务逻辑层：得到请求，从数据层获取数据，返回结果给表示层
3） 数据层： 数据存在关系数据库，元数据，如主题，作者是数据的字段名，或说元数据即 数据库schema
基于XML的技术方案:
1） 表示层： Web表单。 XML+XSLT 或XForm
2） 业务逻辑层：得到请求，从数据层获取数据，返回结果给表示层（利用XML查询引擎）
3） 数据层： 数据用XML表示，存在XML数据库，元数据是XML的标签或说元数据用XML Schema/DTD 表示
基于RDF的技术方案:
1） 表示层： Web表单。有两种：a）界面不变，对用户屏蔽RDF Schema,则用户的体验和上两种界面一样 b）让用户可以看到RDF Schema（ontology），可以根据RDF Schema中的关系组装查询条件，如SHOE的界面。
2） 业务逻辑层：得到请求，从数据层获取数据，返回结果给表示层（利用RDF查询引擎）
3） 数据层： 数据用RDF表示，存在RDF数据库，元数据是RDF本身和RDF Schema

比较：
1） 用户体验：也许没有多大变化。把RDF Schema呈现给用户并不是个好的主意。
2） 开发人员体验：
(a) 概念层到数据层次上的转化：给用户查询的界面是基于系统的概念模型，而底下的关系数据库是数据模型，开发人员需要在这两种模型之间做很多转换工作，而用RDF表示数据，因为RDF本身是概念层次上的，屏蔽了很多语法层上的东西，因此，这种转换工作最少。
(b) 语义信息的硬编码：我们的世界是需要语义信息的，而传统MIS和XML系统中是没有这种语义信息的，为了让系统能够解决现实世界的问题，方法就是把语义信息写死在程序中，例如：为了让用户查找水果的信息，开发人员首先要知道苹果，香蕉是水果，然后分别去查香蕉，苹果的信息，而如果用RDF技术的话，因为它有语义，有推理，RDF引擎可以告诉开发人员香蕉和苹果是水果。如果有更复杂的推理的话，人的脑袋是应付不了的，所以很容易出现程序的不完全性，而这种不完全性是程序本身无法检验出来的。这也是一些系统，如飞船，核电站的软件需要形式化方法的原因。

3） 系统互操作性：
为了解决传统系统的互操作性的苦难，XML技术被大为提倡，但XML只解决了语法层的问题，XML本身没有形式化的语义，语义信息仍然需要硬编码，可以预见，你硬编码了，我也硬编码了，如果我们对某个冬冬的理解不一样，我们俩的系统一起运作就会出问题。例如，你的系统对工资的理解是税前，我的系统对工资的理解是税后，如果这写死在程序里了，当然两个系统互操作的就有问题了。
结论：
1） MIS系统都可以用SW技术来做。RDF可以看成是有语义的XML数据，所有XML能用的地方，偶RDF也能用，现在还有什么地方XML不能用吗？
2） 封闭的，独立的MIS 没必要用SW技术reengineering。
3） 语义Web技术可以让开发人员更happy，让系统有良好的互操作性。

再补充一下：

用SW技术写应用程序，开发人员的确可以省很多事情。
1）不用设计数据库，不用写JDBC，不用写复杂的SQL语句。用RDF表示数据的话，RDFStore技术会自动搞定这些问题，当然效率免不了更低，但如果数据访问量不大的话，SW技术方案有很大的优越性。如果数据访问量大的话，只能采取Adaptor模式，即用RDF封装数据。具体怎么封装，又要写一篇长文了。。。。。。
2）RDF查询引擎有推理的功能，开发人员不需要把这些推理写死在代码中。例如，用户要查找懂XML的人，假设我们的数据库有很多关于XML的信息，如上过XML课的学生懂XML, 教XML课的老师懂XML, 写过XML书的人懂XML….., 如果用传统的技术，要么设计库表的时候要考虑到
这么多种人懂XML，要么写程序的时候，开发人员首先要推理出这么多种人都懂XML,然后写一个很大的带Join的SQL语句。如果有SW技术，即有推理的话，这些都可以写在本体中，开发人员只要写个很简单的查懂XML的人的RDF Query 语句，然后推理引擎把这么多种人找出来，开发人员几乎不动脑子！ 夸张点说，对传统的开发模式，开发人员都要写一个应用相关的推理引擎，但他自己却很难感觉到。 ；-）

OWL DL和DL的区别

• OWL
• 描述逻辑

OWL DL的逻辑基础是DL,但由于OWL DL要面向语义Web，而DL是传统的逻辑语言，两者还是有一定的区别的：
1） OWL用URIref来标识概念，属性，实例，等等，而DL用名字（字符串），另外，逻辑中一般采用唯一名假设，即名字不同的两个东东是不同的，而OWL由于Web的开放性，很有可能不同的人对同一个东东给出的URIref不同，因此不能采用唯一名假设。这也是要有owl:AllDifferent的原因。因为在OWL中，我们要显式地说明哪些URIref代表的资源是不同的，如果用owl:differentFrom，要表示很多个URIref两两不同，非常麻烦，因此，就有了owl:AllDifferent。
2） OWL用XML Schema的数据类型，DL一般没用。
3） OWL DL 有一个基于框架的抽象语法，还有一个基于RDF/XML的语法，DL没有。
4） OWL DL 是基于RDF的，因此，允许有匿名节点，DL一般不支持这种存在量化。
5） OWL 能够 Import 其他本体
6） OWL DL有本体和标注属性，如owl:DeprecatedClass, 一些版本信息，这些属性是有一定的语义的。

参考：google it
【1】 From SHIQ and RDF to OWL– The Making of a Web Ontology Language
介绍了OWL的由来，以及设计时的考虑，很值得一读，对理解OWL很有用。
【2】 Reducing OWL Entailment to Description Logic Satisfiability
介绍了怎样把OWL本体蕴涵问题规约到描述逻辑的可满足性问题。

Java 规则引擎 (JSR-94) 相关资料

• Rules

Java 规则引擎 (JSR-94) 相关资料 

——————————————————————————–
http://www.blogcn.com 2004年7月26日14:5 作者:flier_lu 
 
 对软件设计来说，如何在将用户业务相关问题域映射到与实现技术相关的面向对象体系架构，而又同时保证映射的准确性和灵活性，是构建大型系统的关键性因素之一。个人认为通过构建基于工作流和规则驱动的软件体系架构是最终解决之道。工作流负责宏观的任务流程定制和重组；规则驱动则负责微观的任务逻辑与实现分离。
Java在这方面先行一步，由JCP(Java Community Process)定义的JSR94:JavaRuleEngineAPI描述了如何提供规则引擎API，实现客户程序与规则引擎的交互。此接口集包括了规则的载入、执行以及管理等等功能，由BEA、IBM等厂商推动支持，同时也有大量的开源实现。

过于规则引擎的目标和优势，可以参考下面这篇文章的介绍

Business rules management systems

在Java规则引擎领域，做得最好的三家商业公司分别是：

1.PST的OPSJ
2.Sandia国家实验室的Jess
3.ILOG的JRules

在开源阵营，则有众多的选择

Open Source Rule Engines Written In Java

其中比较著名的Drools可以参考TSS上的一篇介绍文章

IntroductionDrools

javarules.org网站上有相对较为全面的资源介绍。

而这些产品的算法，基本上都是来源于Dr.CharlesForgy在1979年提出的[URL=http://encyclopedia.thefreedictionary.com/Rete%20algorithm]RETE算法[/URL]。其核心思想是将分离的匹配项根据内容动态构造匹配树，以达到显著降低计算量的效果。下面几篇文章简要介绍了此算法：

 CIS587:The RETE Algorithm
The Rete Algorithm
RETE演算法
《专家系统原理与编程》中第11章 

看了OWL Rule Language(ORL)的感受

• Rules

看了WWW2004的文章 A proposal of OWL Rule Language(ORL)，有一些总结或说感想，想说一说。

RDF和OWL都已经成为标准了，语义Web体系结构的上一层应该是logic了，因此在OWL上加Rule现在很热门。由于Rule可以表达OWL无法表示的属性合成，属性值的转移，的确很有必要。目前的提案主要有两个：SWRL0.6[1]和ORL[2]，SWRL主要比ORL多了些预定义的关于数据类型的谓词，其他差别好像没有。 ORL的特点是直接在OWL上加Horn Rule，并且对Rule的解释是和OWL DL兼容的，为了这个兼容性，rule里面常用的失败即否定（Negation as Failure, NAF），还有原子公式的否定和析取都抛弃了。但即使这样，ORL还是不可判定的，目前也没有有效的推理机能实现ORL（一价逻辑的推理机肯定可以，但效率很低，实用价值不大），也无法用商业上的规则引擎实现，因为ORL中的谓词是OWL的类以后，就可以目前规则不能表示的存在，任意量化。 所以，ORL有一些限制版：

1） strictly-Horn：让rule中的谓词只能是OWL中的类名，而不能是类表达式。但是，这个和ORL目前允许rule中的谓词是类表达式的表达能力其实是一样的， 因为完全可以为rule中出现的类表达式在OWL中定义一个类和它等价[3]。
2） DLP[4]： LP和OWL的一个公共子集，即取OWL的能用规则模拟的那一小部分,我称它为OWL Mini，这样，OWL Mini 就是规则的一部分了，当然可以用目前的规则引擎实现，还可以进一步扩展规则中常用的NAF, 优先，过程附件(procedure attachment).但是，OWL Mini的表达能力有点太弱了。

总之，OWL Rule 还是没有完美的解决方案。另外一个思路就是混合推理(hybrid reasoning),但我也刚开始摸索。

[1] SWRL: A Semantic Web Rule Language Combining OWL and RuleML Version 0.6 of 30 April 2004 http://www.daml.org/2004/04/swrl/
[2] ORL: www2004.org/proceedings/docs/1p723.pdf
[3] Usage Suggestions： http://www.daml.org/listarchive/joint-committee/1491.html
[4] Description Logic Programs: Combining Logic Programs with Description Logic.
http://www2003.org/cdrom/papers/refereed/p117/p117-grosof.html

关于本体重用: 一些度量,单位在本体中的表示

• OWL

关于本体重用:一些度量,单位 在本体中的表示

[From Uschold, Michael F in public-swbp-wg@w3.org]

Below is a good source for a quick summary of the Gruber ontology on physical quantities, units and dimensions. Note that As encoded in Ontolingua, Gruber’s ‘ontology’ is not a single ontology, but rather a collection of modules, each technically single ontologies.

Mike
===
Ontology Reuse and Application
Reference: Mike Uschold, Mike Healy, Keith Williamson, Peter Clark, Steven Woods.
Ontology Reuse and Application. In Proceedings of the International Conference on Formal Ontology and Information Systems - FOIS’98 (Frontiers in AI and Applications v46), pages 179-192, Ed: N. Guarino, Amsterdam:IOS Press, 1998.

Abstract: In this paper, we describe an investigation into the reuse and application of an existing ontology for the purpose of specifying and formally developing software for aircraft design. Our goals were to clearly identify the processes involved in the task, and assess the cost-effectiveness of reuse. Our conclusions are that (re)using an ontology is far from an automated process, and instead requires significant effort from the knowledge engineer. We describe and illustrate some intrinsic properties of the ontology translation problem and argue that fully automatic translators are unlikely to be forthcoming in the foreseeable future. Despite the effort involved, our subjective conclusions are that in this case knowledge reuse was cost-effective, and that it would have taken significantly longer to design the knowledge content of this ontology from scratch in our application. Our preliminary results are promising for achieving larger-scale knowledge reuse in the future.

PDF: http://www.cs.utexas.edu/users/pclark/papers/fois98.pdf
Compressed postscript: http://www.cs.utexas.edu/users/pclark/papers/fois98.ps.Z

OWL DL 本体构建指南

• OWL

OWL DL 本体构建指南
摘自 OWL Pizzas: Common errors & common patterns from practical experience of teaching OWL-DL

1. Always paraphrase a description or definition before encoding it in OWL,
and record the paraphrase in the comment area of the interface.
在用本体表示以前，用自然语言描述清楚你想表达的意思
2. Make all primitives disjoint - which requires that primitives form trees
使得没有完全定义的类互为不交
3. Use somevaluesFrom as the default qualifier in restrictions
allvaluesFrom 并不蕴涵somevaluesFrom, 缺省情况下使用somevaluesFrom
如果用allvaluesFrom ,或maxCarndinality定义类, 由于DL采用开放世界假设，使得无法判定
一个实例属于这个类。
4. Be careful to make defined classes defined – the default is primitive. The
classifier will place nothing under a primitive class (except in the presence
of axioms /domain/range constraints)
谨慎给出类的完全定义。
5. Remember the open world assumption. Insert closure restrictions if that is
what you mean.
注意描述逻辑中的开放世界假设，这与数据库不同，如果需要的化加入封闭世界公理。
6. Be careful with domain and range constraints. Check them carefully if classification
does not work as expected.
谨慎给出类的定义域和值域约束，他们是全局约束，可能会导致不期望的结果
7. Be careful about the use of “and” and “or”(intersectionOf, unionOf )
注意逻辑意义上的“and”和“or”和自然语言中的区别
8. To spot trivially satisfiable restrictions early, always have an existential
(somevaluesFrom) restriction corresponding to every universal (allvaluesFrom)
restriction, either in the class or one of its superclasses (unless you specifi-
cally intend the class to be trivially satisfiable).
如果想表达某个类的属性值必须都是属于一个类的，别忘了加上somevaluesFrom限制.
参考：http://bbs.xml.org.cn/dispbbs.asp?boardID=2&ID=8036
9. Run the classifier frequently; spot errors early
频繁运行分类器，早点发现错误。

OWL本体设计模式(1): N-元关系的表示

• OWL

我们都知道，RDF只表示二元关系，但在实际应用中，多元关系非常常见，如：小红借给小明语文书，是个三元关系： borrow(小红，语文书，小明); 再如，小明的身高是170cm.也是个三元关系 length(小明，170, cm). 推广来说，n元关系如何在RDF和OWL中表示呢？

我们假设三元组为(a,b,c). a,b.c 都是资源或Literal

1． 方法一
如果三元组中a是老大，即有个资源的地位是支配性的，如:小明的身高是170cm.
表示方法为 把老大提出来，再把三元关系分解为3个二元关系：
R1(a, a’) ， R2（a’,b）, R3（a’,c） // R1(a, a’) 用RDF三元组表示为 （a , R1 , a’）
例如：小明的例子可以表示为
length(小明，length_obj_1); //小明是老大, length_obj_1 是一个身高对象
value(length_obj_1，170); //值
unit(length_obj_1，cm); //单位
2． 方法二
如果三元组中没有明显的老大，如: 小红借给小明语文书.
表示方法为提出一个对象，每个元素都和这个对象有关系：
R1(g, a) ， R2（g,b）, R3（g, c）
例如：小红借书的例子可以表示为
rdf:type (borrow_obj_1, BorrowRelation); // BorrowRelation 是一个表示借书关系的类
borrow_owner((borrow_obj_1,小红)；
borrow_agent((borrow_obj_1,小明)； //借书的人
borrow_book((borrow_obj_1, 语文书)；

3． 结论
1) n-元关系有2exp(n-2) 种表示方法： 二元关系一种表示法，三元关系有如上二种表示法，由数学归纳法得证。
2) 如果用RDF对复杂系统建模，有必要引入一个中间的抽象层，用以表示N元关系，还有named graph, context 等。如引入rdfe:relation(a,b,c,d,….)表示n元关系
3) n-关系的表示对RDF数据的查询和存储优化很有价值，因为n-关系往往对应了数据库中的表。

注：大部分摘译自：
http://www.w3.org/2001/sw/BestPractices/OEP/n-aryRelations-20040623/

更为详细的信息也参考它。

语义Web设计模式(3): 枚举类的使用

• OWL

在OWL DL中提供了枚举类(oneOf)的功能，遗憾的是，就是因为这个oneOf,目前尚没有有效的算法完全支持OWL DL 本体的蕴涵推理，常用的描述逻辑的推理机Fact, Racer都不支持枚举类。因此，在目前的实际应用中，我们应避免使用它。但碰到直观上需要枚举类的情况，例如，描述一个人的健康状况：健康(good health)，一般(medium health),不健康(poor health), 怎么办呢？用枚举类的话，很直观：即健康状态这个类是由三个实例枚举组成的类。如下表示：

Class (Health_value equivalentClass
oneOf (medium_health good_health poor_health))

现在，我们提出一个oneOf 的替代方法：即把实例全升级为类。
我们可以把 健康，一般,不健康 都作为一个健康状态的子类，他们是两两分离的(disjoint),且健康状态类是这三个类的并集。如下表示：

Class(Health_value equivalentClass
unionOf (Poor_health_value Medium_health_value Good_health_value))

Class(Good_health_value paritial Health_value) // Good_health_value 是Health_value 的子类
Class(Medium _health_value paritial Health_value)
Class(Poor _health_value paritial Health_value)

disjointClasses(Good_health_value ,Poor_health_value , Medium_health_value))

这样，如果要表示一个健康的人，可以说健康状况属性至少有个值是属于”健康”这个类的。

// has_health_status: 健康状况，函数型对象属性，值域：Health_value, 定义域：Person
Class(Healthy_person equivalentClass
intersectionOf(Person and
restriction(has_health_status somevaluesFrom Good_health_value)))

要表示某个人是健康的，只要它的has_health_status 值是类Good_health_value的一个实例 即可。

Individual (John type Person
has_health_status John_health）

Individual(John_health type Good_health_value )
或者直接说

Individual(John type Person
type restriction(has_health_status somevaluesFrom Good_health_value))

总结：
通过把实例升级为类，可以避免使用枚举类，但是很不直观。但这样做还有一个好处：我们可以进一步细分健康状态，如健康可以再分为非常健康，非常非常健康。但用枚举类是不可以的，因为实例只有相同和不同，不可能有重叠。

备注：
Racer虽然不支持对实例的枚举，但支持对数据值的枚举。

参考：
Alan Rector，Representing Specified values in OWL: “value partitions” and “value sets” W3C Working Draft 12 June 2004。

http://www.w3.org/2001/sw/BestPractices/OEP/Lists-of-values-20040625/

语义Web设计模式(2): 受限基数约束的表示

• 其他
• OWL

熟悉DAML+OIL的人可能还记得有属性：minCardinalityQ，maxCardinalityQ，它们是
Qualified cardinality restrictions（QCR，我翻译为受限基数约束,不知妥当否），但OWL规范认为它们过于复杂去掉了。但他们在实际建模中很有用，特别是对part-whole关系,而part-whole关系在空间，解剖学，产品本体中很常见。例如，我们要表示：一个手有5个手指且其中有一个是拇指，用描述逻辑可以表示为：＝5 hasFinger ; ＝1 hasFinger.Thumb. 再举个例子，如学校可以申请答辩的博士至少要发表一篇SCI收录的文章， >=1 hasPaper. SCIPaper (>= 表示至少，即大于等于)。 受限基数约束在OWL中如何表示呢？

方法一：用owl:somevaluesFrom

owl:somevaluesFrom 实际上是受限基数约束的一种特殊形式，它表示： 这个属性至少有一个属于某类型的值. 上面SCI文章的例子可以表示为:

Class(可申请答辩的博士,
subClassOf(Restriction(hasPaper, somevaluesFrom(SCIPaper)))

方法二: 用subPropertyOf

第一种方法只适用与基数至少1的情况，更一般的情况，可以引一个新的子属性. 这个属性的值域就是那个类型，例如，SCI文章那个例子可以这样表示：

Property(hasPaper) //属性hasPaper 的值域是Paper
Property(hasSCIPaper
subPropertyOf(hasPaper)) //属性hasSCIPaper 的值域是SCIPaper,它是Paper的子类
Class(可申请答辩的博士
subClassOf(Restriction(hasSCIPaper minCardinality(1))))

对5个手指的例子可以表示为：
Property(hasFinger)
Property(hasThumb
subPropertyOf(hasFinger))
Class(NormalHand
subClassOf(Restriction(hasFinger cardinality(5)))
subClassOf(Restriction(hasThumbe cardinality(1))))

方法二引入了一个新的属性，如果part-whole关系很复杂，如零部件很多，像飞机，轮船，则这种表示方法会显得非常邋遢。最好的方法是直接支持QCR,值得一提的是描述逻辑的推理机RACER支持QCR. 所以，有的系统可能会对扩展OWL语言，从而支持QCR.

注：大部分摘译自：Guus Schreiber,http://www.cs.vu.nl/~guus/public/qcr.html , first draft , 25 May 2004

开放世界语义对本体构建的影响

• OWL

看了些关于用OWL构建本体的讲义和教程，其中都会提到OWL的逻辑基础描述逻辑中的推理是基于开放世界假设(Open World Assumption)的，从而在构建本体时要特别注意这点。因此，我小小的总结一下，但并没有深入去研究开放世界语义，故不能保证正确性，欢迎大家讨论。

当我们对现实世界的问题做形式化描述时，不可避免地掌握的信息是不完全的，例如，我们不知道Peter是否是个Student，但这个信息的确又是很有用的。一种常用的做法是采用封闭世界假设(Closed World Assumption, CWA), 即如果我们在知识库中推不出来P或P的否定，就把P的否定加入知识库。有两种情况, CWA很有用. 一是可以当假设知识库中的知识是完全的时候. 例如, 在数据库中, 如果学生表中没有Peter, 则认为Peter不是学生. 二是当知道知识库的知识是不完全的, 如不足于回答一些问题, 但我们必须在不完全知识的情况下做出决定, 这时候CWA就有用了. 其实, 我们人思考问题也常常是这样的, 例如, [@todo]

对不完全知识的处理的另外一种方法就是采用开放世界假设(Open World Assumption, OWA), 它和CWA相反, 对推不出来的命题就很诚实地当作不知道这个命题的正确与否, 这样的后果就是知识库中能推导出来的结论大大减少.

但在语义Web环境下, 因为Web的开放性, 相关的知识很可能分布在Web上不同的场所, 因此在语义Web上推理, 用CWA是很不恰当的. 例如, 如果在一个知识库中只说了hasFriend(Peter, Tom), 如果采用CWA, 就会得到结论: Peter只有一个朋友. 这当然是不合理的, 因为很可能在别的地方说了Peter还有其他的朋友. 所以, 如果要在语义Web中聚集不同来源的知识, 应该采用OWA. (有一种中庸之道: 局部封闭世界(Local Closed World), 这里不多说). 描述逻辑中的推理刚好是采用OWA的, 所以它的确适合作为语义Web的逻辑基础.

OWA对本体构造有很大的影响, 因为OWA 认为, 没有显式说明的信息就是未知, 因此,我们在构建本体的时候, 要记住一个原则: “把你知道的全说出来”!

现在，我们看看怎样在OWL本体中说出那些你实际上知道, 但容易忘了说的东西.

1） 唯一名假设(Unique Name Assumption, UNA)： owl:AllDifferent
逻辑中一般采用唯一名假设，即名字不同的两个实例是不同的，而OWL由于Web的开放性，很有可能不同的人对同一个实例给出的URIref不同，因此不能采用唯一名假设。这也是要有owl:AllDifferent的原因。因为在OWL中，我们要显式地说明哪些URIref代表的资源是不同的，如果用owl:differentFrom，要表示很多个URIref两两不同，非常麻烦，因此，就有了owl:AllDifferent。

注意: RACER 支持唯一名假设. 这点使得它不是很适合做SW上的推理. 当然, 新版本也许会改进.
2） 分离和覆盖： owl:disjointWith

在定义类的时候, 可能定义B和C都是A的子类, 这时候可能会忘了说明B和C是Disjoint的, 这个信息对公理中用了否定比较有用, 因为这可以推出, B的实例肯定不属于C, 另外, 还一个容易忘的是覆盖公理(covering axiom).，即说明B和C的合取 覆盖了A(即A是B和C的并的子集), 因为这可以进一步推出: 如果x是A的实例, 且不是B的实例, 则x是C的实例.
最牛的覆盖定理当然是说B是C的否定, 即B和C的合取覆盖了整个论域, 这样, 一个实例x不属于B则属于C.

3） 实例识别：owl:maxCardinality , owl:allvaluesFrom

OWA还有一个很坏的影响是对有些类, 你永远没法判定这个实例是否属于这个类. 例如, 我们定义类D是具有最多2个孩子的人, 现在有个实例y, 知识库中说了y有两个孩子, 但我们能推出y是属于类D的实例吗? 不能! 因为采用OWA, 推理引擎会认为也许其他地方还会说y有第3个孩子, 所以推不出y至多只有2个孩子. 类似的是OWL的属性限制allvaluesFrom, 因为你也无法保证 这个”all”能成立.

结论是: 如果你的应用中需要判定实例属于某个类, 谨慎使用owl:maxCardinality和owl:allvaluesFrom.

4） 封闭公理
OWA会导致一些麻烦, 原因是我们没有把”我们知道的全说出来”. 解决方法就是采用封闭公理(closure axioms), 把路子堵死. 下面有两种常用的封闭公理.

a).用allvaluesFrom 封闭 somevaluesFrom

先举个例子, 假如类A定义为所有孩子都是学生的人, 即 A= restriction(allvaluesFrom hasChild Student); 现在已知类B定义为有孩子是高中生, 有孩子是大学生, 即:

Class(B partial
Restriction(somevaluesFrom hasChild HighSchool ) )
Class(B partial
Restriction(somevaluesFrom hasChild College ) )

这时,我们能推出B是A的子类吗?

按照OWA, 答案是不能, 因为你没说 B的孩子都是学生, 你只说他的孩子有高中生,有大学生. 所以, 为了让B是A的子类, 你要把事情说死, 即加一个封闭公理:

Class(B partial
Restriction(allvaluesFrom hasChild unionOf(College HighSchool) ) )

即说明 B 的孩子都是高中生或大学生, 再加上高中生和大学生都是学生的子类, 我们才可以推出 B 是 A 的子类.

总结:
“A closure axiom on a property consists of a universal restriction that acts along the property to say that it can only be filled by the specified fillers. The restriction has a filler that is the union of the fillers that occur in the existential restrictions for the property”.

b)用cardinality =n 封闭 allvaluesFrom

上面提到如果用allvaluesFrom定义一个类, 则永远无法判定一个实例是否属于这个类, 封闭的方法就是加上一个基数限制. 如, 定义类A是有3个孩子且所有孩子都是博士的人,这样如果实例a有三个孩子b,c,d 且b,c,d 都不是相同的人(AllDifferent), 且b,c,d都是博士, 这样就可以推出a是属于类A了.

参考
[1] Ian Horrocks的关于构建本体的课程讲义
[2] DL handbook chapter 2: P26 2.2.4.4 Closed- vs. open-world semantics
[3] protégé owl tutorial http://www.co-ode.org/resources/tutorials/ProtegeOWLTutorial.pdf

• Blogroll
  • 阿飞外传(MDA)
  • GaryChan's Weblog
  • Planet RDF(推荐)
• 语义Web
  • Data Semantics Community
  • 语义Web论坛
  • 语义Web开源项目
  • RBAC
  • 希腊语义Web门户
  • 开放翻译计划
  • 本体库(SchemaWeb)
• 业余爱好
  • 燃情音乐剧
  • 爱音客
  • flash screensaver maker
  • HoopChina篮球论坛
  • 北京大学
• Categories:
  • 其他
  • 语义Web理论
    • RDF
    • OWL
    • Rules
  • 语义Web应用
    • FOAF
    • Semantic Blogging
    • Semantic Portal
    • 电子政务
  • 本体
  • 描述逻辑
  • XML
  • MDA
  • 语义Web工程
  • 语义Web服务
  • 相关软件和工具
• Search:
  
  
• Archives:
  • November 2004
  • October 2004
  • September 2004
  • August 2004
• August 2004 S M T W T F S     Sep » 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31  
• Other:
  • Login
  • Register
• Meta:
  • RSS 2.0
  • Comments RSS 2.0
  • Valid XHTML
  • WP

Powered by WordPress