中文XML论坛--基于语义Web技术的MIS与基于XML技术，传统MIS的比较[原创]

姓名：(无权查看)
城市：(无权查看)
院校：(无权查看)

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

我没有做过实际的基于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，让系统有良好的互操作性。

[此贴子已经被作者于2004-6-21 14:36:58编辑过]

姓名：(无权查看)
城市：(无权查看)
院校：(无权查看)

很好的分析和比较工作。

非常感谢Orangebench的辛苦劳动。

姓名：(无权查看)
城市：(无权查看)
院校：(无权查看)

想法蛮好的，是不是就是语义搜索给了一个比较具体的应用？

姓名：(无权查看)
城市：(无权查看)
院校：(无权查看)

谢谢micky的捧场；-）

我没做过实际的系统，所以只能举举语义检索这个老掉牙的例子。

姓名：(无权查看)
城市：(无权查看)
院校：(无权查看)

-------------------
语义信息的硬编码：我们的世界是需要语义信息的，而传统MIS和XML系统中是没有这种语义信息的，为了让系统能够解决现实世界的问题，方法就是把语义信息写死在程序中，例如：为了让用户查找水果的信息，开发人员首先要知道苹果，香蕉是水果，然后分别去查香蕉，苹果的信息，而如果用RDF技术的话，因为它有语义，有推理，RDF引擎可以告诉开发人员香蕉和苹果是水果。如果有更复杂的推理的话，人的脑袋是应付不了的，所以很容易出现程序的不完全性，而这种不完全性是程序本身无法检验出来的。这也是一些系统，如飞船，核电站的软件需要形式化方法的原因。
-------------------------------------

想法非常好，只是有一点疑问。传统将语义硬编码的方式可以保证应用的效率。如果过于强调语义封装的灵活性，可能会影响应用效率。这一点可能还需要一些突破。。。

考虑那些语义需要硬编码，哪些语义可以用RDF来封装?如何在效率和灵活性之间做一个权衡呢？

仅供参考。。。呵呵

姓名：(无权查看)
城市：(无权查看)
院校：(无权查看)

效率肯定是受影响的，有点龌龊的安慰之词就是：高级语言肯定比汇编语言慢。

具有哪些语义信息需要硬编码，哪些需要用本体，RDF来表示，这是一个应用
相关的问题，另外，本体不能表达的肯定需要程序硬编码的。

以下是引用trevol在2004-6-21 15:22:52的发言：
想法非常好，只是有一点疑问。传统将语义硬编码的方式可以保证应用的效率。如果过于强调语义封装的灵活性，可能会影响应用效率。这一点可能还需要一些突破。。。
考虑那些语义需要硬编码，哪些语义可以用RDF来封装?如何在效率和灵活性之间做一个权衡呢？
仅供参考。。。呵呵

姓名：(无权查看)
城市：(无权查看)
院校：(无权查看)

再补充一下：

用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 语句，然后推理引擎把这么多种人找出来，开发人员几乎不动脑子！夸张点说，对传统的开发模式，开发人员都要写一个应用相关的推理引擎，但他自己却很难感觉到。；-）

我就总结出这么两点好处，欢迎大家补充！

姓名：(无权查看)
城市：(无权查看)
院校：(无权查看)

SW在信息检索的应用，可能会面临一个问题：如何来用领域知识本体描述其它形式的资源（HTML/XML/文本、WEB SERVICE）?其中尤其以文本为甚。如果用来描述这一类资源的话，如何来控制描述的粒度。目前可能有两种极端：一个是粗粒度，类似于目前的期刊文献的分类法；一种是细粒度，类似于W3C的一些原型系统，对文本中的多个核心概念进行语义标记。两种方法各有利弊，如何取舍，不知道有没有比较好的思路。。。呵呵

姓名：(无权查看)
城市：(无权查看)
院校：(无权查看)

标注的粒度取决于本体的粒度，本体的粒度取决于应用需求。好像没有一般性的方法。

以下是引用trevol在2004-6-26 9:53:41的发言：
SW在信息检索的应用，可能会面临一个问题：如何来用领域知识本体描述其它形式的资源（HTML/XML/文本、WEB SERVICE）?其中尤其以文本为甚。如果用来描述这一类资源的话，如何来控制描述的粒度。目前可能有两种极端：一个是粗粒度，类似于目前的期刊文献的分类法；一种是细粒度，类似于W3C的一些原型系统，对文本中的多个核心概念进行语义标记。两种方法各有利弊，如何取舍，不知道有没有比较好的思路。。。呵呵


	W 3 C h i n a ( since 2003 ) 旗下站点苏ICP备05006046号《全国人大常委会关于维护互联网安全的决定》《计算机信息网络国际联网安全保护管理办法》	7,955.078ms