以文本方式查看主题 - 中文XML论坛 - 专业的XML技术讨论区 (http://bbs.xml.org.cn/index.asp) -- 『 Semantic Web(语义Web)/描述逻辑/本体 』 (http://bbs.xml.org.cn/list.asp?boardid=2) ---- 采用本体和推理机相对直接用程序语言来实现应用逻辑到底有啥优势? (http://bbs.xml.org.cn/dispbbs.asp?boardid=2&rootid=&id=123658) |
-- 作者:scutpalmer -- 发布时间:2/29/2012 9:52:00 AM -- 采用本体和推理机相对直接用程序语言来实现应用逻辑到底有啥优势? 刚接触本体和推理机的菜鸟,希望做一些在上下文感知领域的应用研究。看了一些例子,觉得从实现应用逻辑的方式来说,应用创建阶段可以理解为是先构建领域本体,然后编写推理规则。应用执行阶段可以理解为获得动态的上下文实例作为输入,由推理机进行推理,判断出条件为真时触发相应的动作。 比较困惑的是,这种方式比直接用编程语言来实现有什么优势呢,或者是潜在的优势?我知道这个回答肯定是有的,否则也没必要研究了。但是想不太清楚。参考一些例子,感觉本体定义在面向对象的程序语言中似乎也能够通过等价的数据结构来表达,例如类和实例,对象和属性的关系。应用逻辑对应的推理规则,直接用程序语句来表达也不见得复杂。有些例子,感觉熟练的程序员可能通过程序来实现会更容易。 再考虑到执行性能,按我的初浅理解,直接的程序实现应该是比推理机要效率高得多。 请各位朋友指点迷津:) 谢谢! |
-- 作者:zouyuanrenren -- 发布时间:2/29/2012 10:42:00 PM -- 可扩展性和可维护性更好。 用程序语言来实现的话,你的应用逻辑是代码的一部分。如果你要增加,减少,改变类,属性,或者规则的话,就要重新编码实现。 用本体和推理机的话,应用逻辑是数据的一部分。改变应用逻辑可以通过改变本体来实现,而不需要,或仅需要极微小的代码上的变动。 另外考虑到执行性能,程序实现不一定比推理机更高效。你可以把推理机理解成专业的高度优化的API。通常比你自己编码的通用性和性能都更好。就好比你编程的时候会倾向用.NET或者JAVA的类库和数据结构一样。当然在特定领域的应用中,是有特定的优化的,不排除这种情况。 |
-- 作者:scutpalmer -- 发布时间:3/1/2012 1:36:00 PM -- 多谢您的回答,我也理解您的意思。 可仔细想想,如果应用逻辑有变化,对于程序,一般都是在现有代码基础上进行修改更新,而对于本体/推理机,则是更新本体和规则。这两种形式的工作量,未必有数量级或者本质上的区别。如果完全是新应用逻辑,程序需要完全重新开发代码,编写全新的数据结构。可本体/推理机也对应需要从无到有构建新的本体和规则。好像同样未必有本质差别。 当然,程序还有一个重新编译部署过程,但是这些应该是可以通过自动工具来完成,并不会带来新的工作量。 |
-- 作者:zouyuanrenren -- 发布时间:3/2/2012 2:05:00 PM -- 本体,规则和查询只是数据的一部分。从开发者的角度来说,代码也是数据,没什么区别。但对用户来说,就完全不一样了。 比如您是一个企业,找SAP帮您定做了一个系统。结果在实际运行中发现要变更一些业务逻辑,您是去找SAP重新编码更快更省时间,还是让您企业里面的业务专家直接改本体更快更省时间?当然修改本体有相应的工具,这个工具的易用性也很重要,对业务专家进行必要的培训也很重要。 打个不太恰当的比方,本体,规则和查询类似于淘宝上的商品数据,图片,视频,音乐和logo等资源。做网站的时候肯定不可能把这些全部写到html里面,而是要外置到不同的库里面去。本体中所包含的应用逻辑也是同理。 使用本体的原因和使用数据库,图片文件,音频视频文件等等的原因是一样的。虽然所有的数据都可以直接放在代码里面,但用单独的方式来管理在开发和维护上会更高效。这里的关键就是,应用逻辑是可以当作数据的一部分的。 此外,其他的好处在于: 2.通用性。推理机是针对某种特定语法的。哪怕有新的规则,只要他们仍包含在特定语法内,推理机都可以支持。如果超出了支持的范围,换一个表达能力更强的推理机就行了。如果现有的推理机都不够用,那么很可能编码也无法实现。因为你的规则和模型可能是逻辑上不可判定的。逻辑语言本身研究的就是怎么用最少的限制来支持最丰富的概念表达,同时在运算上又可行。 3.重用性。把规则和模型写在本体文件里面,系统的各个模块和分系统都可以访问和使用它们。写在代码里面,别的系统怎么调用?难道在所有用到的地方都要复制一遍吗?每次变动的时候把所有相关的模块都重新编译一遍? 4.开发过程中的协调。如果用代码来实现,那么对于同一条规则,同一个对象,同样的数据,在不同的开发人员手中可能是不一样的,那么在系统的不同模块,甚至同一个模块的不同版本上,也可能是不一样的。这样就增加了很多格式转换的接口。最简单的解决方案就是定义一个通用的数据模型,表达方式和命名规则,这样大家分别独立开发的模块可以简单的连接起来,或者开发的时候可以到一个全局公共的库里面去查是不是有人定义过了。而RDF和OWL就是这样一个通用的数据模型和表达方式,有了现成的为什么不用呢? 当然以上的并不绝对,很多软件开发商要考虑到自身的独立性,所以并不希望使用公共的标准,往往会在公司内部用自己的一套标准。但是对于用户来说,他的软件系统和数据格式是否能跟他的上下游企业保持一致往往非常重要,这个时候用一个通用的标准显然更方便。 [此贴子已经被作者于2012-3-4 5:39:48编辑过]
|
-- 作者:admin -- 发布时间:3/4/2012 4:17:00 AM -- 实际上,这个问题,可能是所有进入企业的语义网研究者都要面临回答的一个问题。
|
-- 作者:scutpalmer -- 发布时间:3/5/2012 9:19:00 AM -- 受益匪浅,多谢各位的回答! 看来路还长着:路漫漫其修远兮 吾将上下而求索! |
-- 作者:timearrow -- 发布时间:3/6/2012 9:39:00 AM -- “本体+推理”vs“直接编程”,一是“专业化”,把知识处理从数据处理中独立出来,就像把编译器从编程中独立出来类似,会带来一系列专业化的好处;一是“开放互联”,统一开放的标准和接口让互联网级的知识共享成为可能; 至于“效率”高下,取决于专业化发展程度,从个例来看,直接原生编程应该更高,从大范围协作来看,专业化肯定高,这个跟国际贸易的原理一致; 从本质看,"本体+推理"处理了元模型和实例多个抽象层面的内容,更贴近人的思考方式;"直接编程"把这些抽象层次压扁在信息处理一个层面上,更贴近机器的处理方式; |
-- 作者:miketion -- 发布时间:3/17/2012 2:10:00 AM -- 一个比LZ还菜的鸟飞过,学习一下! |
-- 作者:scutpalmer -- 发布时间:4/10/2012 10:07:00 AM -- 菜鸟继续求赐教! 请各位达人指正本人如下的理解是否有误: 规则引擎也就是基于规则的推理引擎,这里规则等价于程序语言中的if-then语句。我的理解相当于将程序中if-then语句表示的应用逻辑从程序中解耦分离出来,以形式化的规则来定义,然后由规则引擎来执行。这样可以通过改变规则来灵活的改变业务逻辑,而不需要改变程序本身,具有更好的应用可维护性。同时基于规则引擎来执行规则也可以获得更好的效率; 而基于本体的推理引擎即推理机,在执行时需同时加载本体和规则。类比编程,本体相当于以新的方式来定义类和对象这些数据结构,其特点是以少的语句来构建知识库并蕴含较多的信息量,这也是智能性的基础。规则则相当于应用逻辑,因为本体的智能性,和直接写程序对比,形式上相对简单的规则语句描述即可实现比较复杂的逻辑。
|
W 3 C h i n a ( since 2003 ) 旗 下 站 点 苏ICP备05006046号《全国人大常委会关于维护互联网安全的决定》《计算机信息网络国际联网安全保护管理办法》 |
3,945.313ms |