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

非常感谢Orangebench的辛苦劳动。

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

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

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

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