黄智生博士(Dr. Zhisheng Huang, http://wasp.cs.vu.nl/~huang/)现任 阿姆斯特丹自由大学(Vrije University of Amsterdam) 高级研究员，长期从事人工智能知识表示与行动推理等方向的研究，在国际人工智能界享有很高的声誉。目前正在主持SEKT的核心技术“语义网中非协调本体的推理”（Reasoning with inconsistent ontologies for the Semantic Web)的研究。

黄博士的研究兴趣广泛，包括：logical foundation of the Semantic Web, intelligent multimedia technology, formal theories of intelligent agents, and their implementation, applied logics for decision support systems, and reasoning about actions等，除此之外，黄博士还对philosophy of mind感兴趣。

==================================================

请大家在与黄博士的交流过程中注意以下几点：

* 请采用回复本贴的方式发布您的问题(并尽量使用引用回复方式，以保留上下文)，不要新建主题，以免由于多个话题，引起混乱。

* 大家在与黄博士交流的过程中，使用中英文均可，但术语的表达尽量使用英文。

* 为保证讨论的高效性，请大家在与黄博士讨论或请教问题时尽量围绕黄博士的研究方向展开话题，不要问可以在本版找到答案的问题（比如什么是Semantic Web，什么是Description Logic等。）

* 考虑到参加讨论的人可能比较多，提的问题也会很多。尽管时间不允许黄博士一一
作出回答，但黄博士会在其中挑选出一些最具代表性的问题给予回答。

感谢黄博士，也感谢各位的参与！

语义Web的思想可以说是把知识表示搬到Web上来，即webize KR; 但事实上，传统的KR被证明是失败的，即AI bubble failure，这样的话，有什么理由去让我们相信语义Web就一定能成功呢？KR披上Web的外衣就能让工业界接收吗？SW和KR的决定命运的区别到底在哪里？

Tim berners Lee 在他的design note里论述了他的理由[1]：
1.A Semantic Web is not Artificial Intelligence
2.A semantic Web will not require every application to use expressions of arbitrary complexity
3. A semantic Web will not require proof generation to be useful: proof validation will be enough.
4. Knowledge Representation goes Global:
  We remove the centralized concepts of absolute truth, total knowledge, and total provability, and see what we can do with limited knowledge
。。。

但是，一直觉得他的认证并不充分，也一直没花时间去好好想这个问题。
想听听黄博士对这个问题的看法。

[1]Web design issues; What a semantic can represent
http://www.w3.org/DesignIssues/RDFnot.html

尽管，我们都知道SW的知识肯定是不完全的，也很有可能是不协调的（inconsistent），但这两种推理都过为复杂。

这些天我一直在国内旅行,今天才有机会查看我的HOTMAIL. 刚看到版主给我发的
有关信息, 让各位久等了.

我将尽力回答各位的提问.但由于我处于旅行之中,由于时间和资料的关系,我的
回答可能不能详尽和全面,望见谅.

我将于8月20日左右回到大学上班, 届时会有更合适的环境为大家服务.

致礼!

HUANG

我的一些同事同荷兰Elsevier出版社搞了一个医学文献语义检索工具DOPE,
请参见:

http://aduna.biz/dope/

你可以下载有关软件及申请有关帐号, 你自己使用后,自有体会.

对于国内目前的情况,我还不太全面了解.总觉得热情很好,但尚在
起步.

问题有点大而空，一句话，就是希望您尽量多说说，因为我相信您的看法对大家的研究有
非常好的参考价值。 ；－）

人们对AI和KR有许多误解.
实际上KR主要关注于推理,即从规则表达的数据中
获得间接数据,以此对数据检索的功能作必要的扩充.
由于目前数据检索的普遍使用, 人们希望有关系统
能有适当的(不必是像人那样的高度智能的)推理能力也是自然的.

AI在目前的情况下并不是要实现人的全部智能行为,那还是很遥远的事.

>这样的话，有什么理由去让我们相信语义Web就一定能成功呢？KR披上Web的外衣就能>让工业界接收吗？SW和KR的决定命运的区别到底在哪里？

KR并不神秘, 它的核心是推理,只是想获得一些间接数据,
这对许多系统都是需要的, Web也不例外. SW界有一种
说法, 就是我们只能解决1%的问题,由于Web的普遍使用,
也会给社会带来巨大的效益.

以下是引用orangebench在2004-7-30 9:58:17的发言： 在AI中，对不完全知识的处理有非单调推理，对含有矛盾的知识有超协调推理(paraconsistent reasoning)，还有这两者的结合。 我想问的是：这两种复杂的推理能应用到SW上吗？如果能的话，又要以一种什么形式？ 尽管，我们都知道SW的知识肯定是不完全的，也很有可能是不协调的（inconsistent），但这两种推理都过为复杂。

http://www.cs.vu.nl/~frankh/abstracts/ISWC03.html

以下是引用npubird在2004-7-30 13:25:59的发言： 黄博士，你好。 对于Web上的本体，很可能是分布式的，而应用中可能需要对这些分布式的本体进行集成、合并与映射等工作。请问针对 web上的分布式的多本体管理 有什么看法呢？这样的研究意义和价值大吗？ 国外特别是你们学校这方面做的工作能大致描述一下吗？ 谢谢

我是看好SW的前景的. 我估计用RDF乃至OWL来标注数据将会成为时尚.
正像现在用XML来表示数据已成为计算机科学及许多领域的时尚. RDF与
XML相比, 前者已包括了后者, 因而它不会失去什么.

SW正处于百花齐放百家争鸣的时代, 它给年轻人许多机会.

关于比较好（热门）的研究方向的问题, 实在是难以简要回答的.
可以说在这BBS上所提的许多问题都是很好的.

以下是引用orangebench在2004-7-30 13:40:50的发言： 你们系无疑是目前SW研究中最为强大的力量之一，所以，很想听您谈谈对SW的前景的看法，目前比较好（热门）的研究方向，以及您站在SW研究最前沿的一些感受。 问题有点大而空，一句话，就是希望您尽量多说说，因为我相信您的看法对大家的研究有 非常好的参考价值。 ；－）

1）在Semantic Web上RDF层可能会跳过OWL层，直接和上面的层次打交道，如
rule，proof, trust。第一层RDF（S） 较容易被人接收，因为RDF Schema一般都比较简单，而这种统一的元数据格式又非常有用。目前较为成功的SW项目基本都在这一层面上，如FOAF，RSS 1.0(Atom)，Dublin Core。他们的一个共同特点就是简单。

而OWL层呢，首先建个本体很麻烦，其次推理时间复杂度太高，我感觉会很难真正在Web上得到广泛应用，它的应用场景可能在一些基于SW技术的信息系统中，如企业Portal，企业的知识管理，等。
http://bbs.xml.org.cn/dispbbs.asp?boardID=2&ID=759&star=2

2）RDF（S）已经是有个完善的Web知识表示语言，我总觉得，保持语义和语法兼容的方式扩展RDF（S)非常有用，OWL Full就是这样的扩展，但它是不可判定的，我觉得应该有个可判定的OWL Full子集.但并不是像owl dl那样，因为它和RDF 语义不兼容。

[讨论] 我们能否找到一个OWL Full的RDFS兼容的，可判定的子集
http://bbs.xml.org.cn/dispbbs.asp?boardID=2&ID=8674

谢谢！

Towards an Interoperability Ontology for Software Development Tools(http://www.stormingmedia.us/89/8994/A899414.htm)

Software ontology(http://encyclopedia.thefreedictionary.com/Software%20ontology)

UML for Ontology Development(http://ubot.lockheedmartin.com/ubot/papers/publication/KER4.doc)

New Trends in Software Methodologies, Tools and Techniques(http://www.lyee-project.soft.iwate-pu.ac.jp/lyee_w03/flyer.pdf)

2) OWL DL在计算复杂性上已是比较高的，再加上一点附加的功能就会变得不可计算。实际上，我估计在RDF(S)上仅加上布尔逻辑运算就将使语言变得不可计算。（当然，我还没有形式证明它，有时间的话，我会试着证明它，或反证它，你也可以自己试试). 当然你可以自己试着找一个可判定的OWL Full子集，且同RDF(S)兼容，并证明它。这是最好的回答。

OWL DL 与RDF(S)不相容的问题之一是， 前者不允许类作为性质的值(Classes as Property Values),这对许多初学者觉得表达上很不方便。W3C网站上有一篇较好的文章，教大家
怎样使用OWL DL来取得类似的表达能力，而不致于使用OWL Full而使之不可计算：

http://www.w3.org/2001/sw/BestPractices/OEP/ClassesAsValues-20040623/

Towards an Interoperability Ontology for Software Development Tools(http://www.stormingmedia.us/89/8994/A899414.htm)

Software ontology(http://encyclopedia.thefreedictionary.com/Software%20ontology)

UML for Ontology Development(http://ubot.lockheedmartin.com/ubot/papers/publication/KER4.doc)

New Trends in Software Methodologies, Tools and Techniques(http://www.lyee-project.soft.iwate-pu.ac.jp/lyee_w03/flyer.pdf)

2) OWL DL在计算复杂性上已是比较高的，再加上一点附加的功能就会变得不可判定。实际上，我估计在RDF(S)上仅加上布尔逻辑运算就将使语言变得不可判定。（当然，我还没有形式证明它，有时间的话，我会试着证明它，或反证它，你也可以自己试试). 当然你可以自己试着找一个可判定的 OWL Full子集，且同RDF(S)兼容，并证明它。这是最好的回答。

OWL DL 与RDF(S)不相容的问题之一是， 前者不允许类作为性质的值(Classes as Property values),这对许多初学者觉得表达上很不方便。W3C网站上有一篇较好的文章，教大家
怎样使用OWL DL来取得类似的表达能力，而不致于使用OWL Full而使之不可判定：

http://www.w3.org/2001/sw/BestPractices/OEP/ClassesAsvalues-20040623/

以下是引用orangebench在2004-7-30 15:27:36的发言： 我觉得你们学校，甚至整个欧洲，对SW的理论问题，如本体，描述逻辑，以及本体的应用研究地比较多，而对RDF这层反而关注不多。我有两个观点，想请您指教一下： 1）在Semantic Web上RDF层可能会跳过OWL层，直接和上面的层次打交道，如 rule，proof, trust。第一层RDF（S） 较容易被人接收，因为RDF Schema一般都比较简单，而这种统一的元数据格式又非常有用。目前较为成功的SW项目基本都在这一层面上，如FOAF，RSS 1.0(Atom)，Dublin Core。他们的一个共同特点就是简单。 而OWL层呢，首先建个本体很麻烦，其次推理时间复杂度太高，我感觉会很难真正在Web上得到广泛应用，它的应用场景可能在一些基于SW技术的信息系统中，如企业Portal，企业的知识管理，等。 http://bbs.xml.org.cn/dispbbs.asp?boardID=2&ID=759&star=2 2）RDF（S）已经是有个完善的Web知识表示语言，我总觉得，保持语义和语法兼容的方式扩展RDF（S)非常有用，OWL Full就是这样的扩展，但它是不可判定的，我觉得应该有个可判定的OWL Full子集.但并不是像owl dl那样，因为它和RDF 语义不兼容。 [讨论] 我们能否找到一个OWL Full的RDFS兼容的，可判定的子集 http://bbs.xml.org.cn/dispbbs.asp?boardID=2&ID=8674 谢谢！ [此贴子已经被作者于2004-7-30 16:11:32编辑过]

XDIG: Extended DIG Description Logic Interface for Prolog

The Extended DIG Description Logic Interface for Prolog (XDIG) is a logic
programming infrastructure for the Semantic Web. XDIG supports both DIG
clients and DIG servers. As a DIG client, the Prolog programs can call any
external DL reasoner which supports the DIG DL interface. As a DIG server,
the Prolog programs can serve as a DL reasoner, which can be used to
support additional DL reasoning processing.

You can download the XDIG package for SWI-Prolog from the website:

http://wasp.cs.vu.nl/sekt/dig/

1。什么是Context ，为什么RDF reification不能表示context?
2。什么是provenance ，RDF reification能表示provenance吗？
3. Named graph vs. Quads， 区别和优劣？

谢谢！

以下是引用Huang在2004-8-27 19:54:07的发言： 希望使用逻辑程序设计语言开发语义网系统的同行，可看看 我们最近开发的软件包： XDIG: Extended DIG Description Logic Interface for Prolog 。。。。。

以下是引用orangebench在2004-8-31 16:40:32的发言： 在Ian Horrocks的ORL（OWL Rules Language）那篇文章中，提到了描述逻辑可能和prolog之间的语义不协调性，具体我也没弄清楚。 在您的DL和prolog集成系统中， 语义的问题怎么解决呢？ 另外，其中的推理也是不可判定的吧？ [quote]以下是引用Huang在2004-8-27 19:54:07的发言： 希望使用逻辑程序设计语言开发语义网系统的同行，可看看   我们最近开发的软件包：      XDIG: Extended DIG Description Logic Interface for Prolog 。。。。。 [/quote]

1. Reification（具体化): 即对有关的语句进行再描述。
2. RDF Reification (RDF具体化描述): 即用RDF的具体化词汇来描述RDF陈述，
这些RDF具体化词汇是： rdf:Statement， rdf:subject， rdf:predicate，和 rdf:object。
3. Context（上下文), 即与有关陈述所直接相关的其他陈述， 它可以被理解成一个陈述集合，所以在RDF上可以理解成一个图（也就是一个三元组集合).
4. Provenance(出处)：即有关陈述的来源，也就是提供者。
5. Named Graph(具名图)：即带有名字的图。
6. Quads (四元组)：很容易看出来，一个具名图总可以用一个四元组来表示，
所以在语义上Named Graph可以被理解成一个Quads。

注意：
1. 一个上下文可能有不同的出处。
2. 同一个出处也可能对应不同的上下文。
3. RDF Reification 可以一定程度地用来表述出处。
4. RDF Reification 增加了储存空间，加重了计算开销.

因此有人建议使用四元组办法来解决问题， 与RDF的三元组的
表示相比，会省许多开销(一个四元组至少对应三个三元组, 1x4 < 3X3)，
在表达上也容易理解一些。

以下是引用orangebench在2004-8-31 16:36:48的发言： 最近看RDF-Interest maillist对rdf reification的讨论非常热烈，不到5天，可能快100个帖子了，我也是看的稀里糊涂。不知道黄博士是否也关注这个讨论。下面的问题，我不太明白： 1。什么是Context ，为什么RDF reification不能表示context? 2。什么是provenance ，RDF reification能表示provenance吗？ 3. Named graph vs. Quads， 区别和优劣？ 谢谢！

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

先让我把有关概念根据我的个人理解解释一遍(希望能听听你们的不同意见)：

1. Reification（具体化): 即对有关的语句进行再描述。
2. RDF Reification (RDF具体化描述): 即用RDF的具体化词汇来描述RDF陈述，
这些RDF具体化词汇是： rdf:Statement， rdf:subject， rdf:predicate，和 rdf:object。
3. Context（上下文), 即与有关陈述所直接相关的其他陈述， 它可以被理解成一个陈述集合，所以在RDF上可以理解成一个图（也就是一个三元组集合).
4. Provenance(出处)：即有关陈述的来源，也就是提供者。
5. Named Graph(具名图)：即带有名字的图。
6. Quads (四元组集合)：很容易看出来，一个具名图总可以用一个四元组集合来表示，
所以在语义上Named Graph可以被理解成一个Quads。

注意：
1. 一个上下文可能有不同的出处。
2. 同一个出处也可能对应不同的上下文。
3. RDF Reification 可以一定程度地用来表述出处。
4. RDF Reification 增加了储存空间，加重了计算开销.

因此有人建议使用四元组办法来解决问题， 与RDF的三元组的
表示相比，会省许多开销(一个四元组至少对应三个三元组, 1x4 < 3X3)，
在表达上也容易理解一些。

看了那个邮件列表的讨论以及一些相关的论文，有以下一些结论：

1）RDF具体化是关于陈述的描述，但对这个陈述本身的真值不作判定，而上下文需要描述一个陈述在不同的上下文中真值的变化，因此，RDF具体化无法表达上下文（context）。
   ----Guha's "contexts for the Semantic Web"

2) RDF数据出处（provenance）都要求一种“quotation”（引用）机制，即对里面的陈述不作解释，这也是避免认知逻辑中的“referential opacity ”问题。而RDF具体化不是引用机制，这在RDF primer文档中有特意地说明，RDF具体化要对里面的陈述作出解释。

3）具名图是一种引用机制，它是quad的一个特例，即第四元是图的URIref。

这样的化，RDF 具体化到底有什么用呢？

“ RDF Reification 可以一定程度地用来表述出处”，这个“一定程度”的意思又是什么呢？
什么情况下，它不能完全表述呢？

恕我愚笨, 谢谢！

以下是引用Huang在2004-8-31 20:07:36的发言： //skip 注意： 1. 一个上下文可能有不同的出处。 2. 同一个出处也可能对应不同的上下文。 3. RDF Reification 可以一定程度地用来表述出处。 4. RDF Reification 增加了储存空间，加重了计算开销. 因此有人建议使用四元组办法来解决问题， 与RDF的三元组的 表示相比，会省许多开销(一个四元组至少对应三个三元组, 1x4 < 3X3)， 在表达上也容易理解一些。

数据出处（Provenace)对应一个信息提供者， 所以可以指向一个名字或Link.
上下文(Context)对应一个陈述集合，通常可用Reification+Bag来描述。
具体例子可参见：
http://www.hpl.hp.com/techreports/2003/HPL-2003-231.pdf

“一定程度”是指对这些描述方法，人们还有许多争论，主要是
对有关概念还没有一个统一的定义，而且这些描述是否能满足人们
对有关概念的相应功能的所有要求还没有深入的研究。

http://www.googlefight.com/cgi-bin/compare.pl?q1=%22semantic+web%22&q2=%22relational+database%22&B1=Make+a+fight%21&compare=1&langue=us

以下是引用orangebench在2004-7-30 9:52:24的发言： 有什么理由去让我们相信语义Web就一定能成功呢？

你好！
我一口气看完了所有的贴，虽然有些还不甚了然，但我知道你在SW方面有很深的造诣，我想请求你一个有关SW的应用的问题。

我现在在做有关觉察上下文计算方面的工作，想通过推理已有的状况推知更深层的知识，如已知某个用户需要“彩色激光A4的打印机”，而计算环境中没有直接满足要求的打印机，而有“彩色喷墨A3的打印机”，需要能通过推理来告诉用户“计算环境中没有所需的打印机，不过有近似满足要求的打印机”。

请问，这种问题基于本体（语义）推理是否能解决？解决的思路大体是什么？

我目前想使用RDF+OWL描述所有的资源，通过推理描述内容来解决问题，不知道行否？

谢谢。

你提了一个很好的问题， 它在理论上和工程上都十分值得深入研究。

从工程的角度上看， 一个直观的解决方法是建立一个“可能替代品“关系
来描述它们， 即把“彩色喷墨A3的打印机”描述成“彩色激光A4的打印机”
的一种可能替代品，这样当没有所需的打印机的时候，就寻找一个可能替代品来回答。

但这种方法并不是很理想的方法，它要求我们要把有关“替代品”关系
事先描述好， 而不是从有关概念的语义上自动得出“相近产品”的关系。
人们总是希望把有关系统实现得更"智能化”一些，也就是能够实现你上述所说的
“通过推理已有的状况推知更深层的知识”，
这同通常所说的逼近推理(approximate reasoning)不相同，同模糊推理也不
完全一样。

这里涉及到SW上的一个很普遍的基础问题，即如何度量两个概念之间的语义距离。
语义距离越近，就表明两个概念越相似。这样在工程实现上就可以用于有关“可能替代品“
的推理。许多人现在使用的是计算语言学上的方法， 特别是用WordNet的办法来度量
两个概念的语义距离。有的使用格论（Lattice Theory)的方法来度量两个概念的距离，
即分析有关概念的属性组成，如”彩色激光A4的打印机“的属性是"彩色，激光， A4，...",
"彩色喷墨A3的打印机”的属性是"彩色，喷墨， A3，...", 它们只在很少的几个属性上
是不同的，所以是非常相近的。

过一段时间，我给你传一些有关文献， 供你参考。

我还有几个问题向你求教：
1、你所提及的“度量两个概念之间的语义距离”的方法能否使用Jena之类的RDF/OWL工具实现？如何实现？

2、你说的方法： “分析有关概念的属性组成，如”彩色激光A4的打印机“的属性是"彩色，激光， A4，...","彩色喷墨A3的打印机”的属性是"彩色，喷墨， A3，...", 它们只在很少的几个属性上是不同的，所以是非常相近的”，这种方法是否能处理“语义大小”问题？如“彩色打印机”能替代“黑白打印机”，“A3幅面打印机”能替代“A4幅面打印机”，这里好像是“彩色>黑白”，“A3>A4”。

谢谢。

Jena之类的RDF/OWL工具只是有关的语言处理工具而已。语义距离的分析
和处理是属于更上层的东西。它需要非标准的逻辑和推理能力。要在这些工具
之上再建立一个处理层。这有许多不同的做法。

比如说，我们现在就是用逻辑程序语言建立一个基于概念相关性的推理层来
进行语义网中非协调本体的推理。目前我们只是用语法相关性（syntactic
relevance)来处理，结果表明它能够较好地处理非协调本体的推理。目前有关
系统仍在实现之中。待它全部完成之后，我可能给你提供源代码供你参考。
如果你对逻辑程序设计的方法感兴趣的话， 可参见我们的有关网站上的材料：
http://wasp.cs.vu.nl/sekt/dig

是的。 这是从属性的序关系推导出一个概念集的偏序关系。所以它构成
一个格(Lattiice). 下面是一些参考文献， 你可以读一读：

1. Concept lattice
A concept lattice is a mathematical structure that may be used to model an ontology。
http://www.fact-index.com/c/co/concept_lattice.htm

2.Algorithms for Concept Lattice Decomposition and their Applications
http://www.infosun.fmi.uni-passau.de/st/papers/tr-95-09/tr-95-09.ps.gz

3. B. Ganter and R. Wille. Formal Concept Analysis - Mathematical Foundations. Springer Verlag, 1999.

4.A Formal Concept Analysis Homepage
http://www.upriss.org.uk/fca/fca.htm

5. Peter Burmeister's Introduction to FCA and ConImp
http://www.mathematik.tu-darmstadt.de/~burmeister/ConImpIntro.ps

从上面一些网址开始，可以搜索到更多相关文献。

是的， 上面所说的办法是“格论”的方法，它只是给出一个序关系，
所以说是定性的。它不一定非得定量，因为我们只要能够知道在序关系
上排的最近是哪个概念就可以了。

当然你可以用计算语言学上的办法，它经常可以取得定量结果。
请参见下列一些文献：

1. Budanitsky, Alexander and Hirst, Graeme.
``Evaluating WordNet-based measures of semantic distance.''
ftp://ftp.cs.toronto.edu/pub/gh/Budanitsky+Hirst-2004.pdf

2. Budanitsky, Alexander and Hirst, Graeme.
``Semantic distance in WordNet: An experimental, application-oriented evaluation of five measures.''
ftp://ftp.cs.toronto.edu/pub/gh/Budanitsky+Hirst-2001.pdf

3. Ted Pedersen, Semantic Distance Measures,
http://www.d.umn.edu/~tpederse/Code/Readme.distance-0.11.txt

4. Graeme Hirst and David St-Onge, Lexical chains as representations of context for the detection and correction
of malapropisms, in Fellbaum 1998, 305-332.

5. Jay Jiang and David Conrath, Semantic similarity based on corpus statistics and lexical taxonomy, in: Proceedings
of International Conference on Research in Computational Linguistics, Taiwan, 1997.

6. Philip Resnik, Using information content to evaluate semantic similarity, in Proceedings
of the 14th IJCAI, 448-453, 1995.
http://www.umiacs.umd.edu/~resnik/

请参见上面所列的有关文献 （第41楼和第42楼).

我赞赏你承认自己“糊涂”的勇气。在追求知识的过程中，我们大家都应该本着
老老实实的态度，决不满足于一知半解。只要存在着疑虑，就要认真地去思考和
探索，使得自己对有关问题的理解建立在一个较为坚实的基础上。

你上面提出的问题已经有大量的文献可供参考。如果这么多的文献及其讨论都不能
使你解除困惑的话，我在这里用有限的篇幅和时间恐怕也不能解决问题。为此，我
思考了许多天，有了下列一个想法，想同你探讨探讨，不知是否可行？

我想使用一个“启发式”的方式同你讨论有关问题， 也就是说我不再简单地重复
现有文献和讨论已有的说法或理论，而是从一个你自己所感兴趣的具体工程问题出发，通过
讨论和具体实现， 让你自己一步步地去领悟（或批判）有关的方法， 理论，以及技术。

这就需要你要有足够的时间和耐心去独立思考， 去寻求自己的真正理解。你还得
花许多时间去把你思考的问题和方法通过实现来检验，来加深自己的体会。这并
不亚于学一门新课。这要看你的自己的时间和决心来定，当然我会给你提供适当
的技术支持。  而且对我自己来说，我也只能 在工作之余，到这个论坛同你们探讨
有关问题， 也就是说如果我外出开会出差，或工作繁忙的时候，就不能及时
回复。

如果上述方法可行的话， 我们就开使一个系列对话，题目就暂定为：

〖关于语义网的对话－－－从一个工程实例开始〗

以下是引用Huang在2004-9-28 18:42:11的发言： 我赞赏你承认自己“糊涂”的勇气。在追求知识的过程中，我们大家都应该本着 老老实实的态度，决不满足于一知半解。只要存在着疑虑，就要认真地去思考和 探索，使得自己对有关问题的理解建立在一个较为坚实的基础上。 你上面提出的问题已经有大量的文献可供参考。如果这么多的文献及其讨论都不能 使你解除困惑的话，我在这里用有限的篇幅和时间恐怕也不能解决问题。为此，我 思考了许多天，有了下列一个想法，想同你探讨探讨，不知是否可行？ 我想使用一个“启发式”的方式同你讨论有关问题， 也就是说我不再简单地重复 现有文献和讨论已有的说法或理论，而是从一个你自己所感兴趣的具体工程问题出发，通过 讨论和具体实现， 让你自己一步步地去领悟（或批判）有关的方法， 理论，以及技术。 这就需要你要有足够的时间和耐心去独立思考， 去寻求自己的真正理解。你还得 花许多时间去把你思考的问题和方法通过实现来检验，来加深自己的体会。这并 不亚于学一门新课。这要看你的自己的时间和决心来定，当然我会给你提供适当 的技术支持。  而且对我自己来说，我也只能 在工作之余，到这个论坛同你们探讨 有关问题， 也就是说如果我外出开会出差，或工作繁忙的时候，就不能及时 回复。 如果上述方法可行的话， 我们就开使一个系列对话，题目就暂定为： 〖关于语义网的对话－－－从一个工程实例开始〗

你所说的针对context的similarity 研究目前还非常少， 原因在于它的有效解决通常被认为应
建立在更低层的(也就是基于概念的similarity的)研究的坚实基础上.

但你还是可以参考下列一些文献：

1. Glen Jeh,  Jennifer Widon, SimRank, a meaure of structure-context similarity,
http://www-cs-students.stanford.edu/~glenj/simrank.pdf

2. Yoram Biberman,  A context similarity measure, http://portal.acm.org/citation.cfm?id=188418.

我的硕士论文是有关semantic web的研究，当今世界xml横行天下，就连音乐的乐谱发布都用xml来做了，美其名曰MusicXML。MusicXML主要是做乐谱出版印刷和网络出版用，由于我的IT(在北欧读IT６年了)学习和音乐背景，我提出了是否《用Sementic Web 进行对音乐的人工智能分析》的论文题目，但semantic web本身具体的东西还都不太完善，茫茫兮休远，苍然兮独怆。

KTH 的音乐声学系TMH一直立志于对音乐感情的分析研究，目前世界在这一领域已经取得一些成绩，包括电脑对乐谱的计算机分析，电脑对wave音频文件强弱的逻辑分析，以得出此段物理载体的相对应的人类的感情。相关的成果如果能够转化成为semantic web中的　人工智能分析标准，那么则可实现对网络上音乐的职能话分析。因为MusicXML也可以载入音符强弱，那么semantic web也可以成为音乐演奏者感情分析的工具。

题外给大家：可能有人问了谁吃饱了撑的分析音乐的感情做什么？　多唠叨一句：这个非常重要，在音乐来说，以后都xml了，那么音乐的分类，搜索，就成为一个很大的问题，由于音乐xml不同于语言xml，所以音乐语法和我们的语法是不一样的。在科学上来说，比如说你饲养了一只电子机器猪，如果你想给这只猪加上感情，比如你生气了，那么猪要有音频的人类感情分析。比如你想让电子猪欣赏音乐的话，那么就得有音乐人工智能软件。
在商业上，目前我觉得最可行的是手机铃声，现在手机铃声已经有公司用xml储存分类了，不久所有铃声就都会在线，如果有一兄弟失恋了，想找点失恋音乐的话，只需要打入：我失恋了。那么semantic web 语言部分就把这个信息转化成感情部分，通过某rdf到Semantic Web音乐部分，找出最适合失恋感情的音乐。

wolfqi@mac.com　也可通过邮件联系。

TELL:0047-91121981

你用生动的语言给大家描述了一个非常吸引人的语义网可能应用项目。人们
通常对语义网的印象总是那些枯燥的术语， 如元数据，本体，和描述逻辑等等。
你所说的音乐语义网和情感分析给人们展现的是语义网更富有生活情趣的一面。
我觉得你的《用Sementic Web 进行对音乐的人工智能分析》的想法是很有价值的。
我非常乐意与你讨论有关的技术问题，帮助你把有关工作做好。
详细内容请看我的下一篇的针对你的具体问题的回复。

至于如何实现一个语义网工程项目， 还没有统一的标准和工具。现在正出于一个百花齐放
百家争鸣的时代。有人这样描述当今的语义网：参加现在的语义网国际会议，就象参加一百
多年以前的飞机制造会议。 谁都相信制造一个具有商业前景的飞机是可能的， 但人们却对如何造飞机却争论不休， 人们所看到的只是形形色色的粗糙的飞机设计模型。准确地说，当今
的语义网研究状态比上述情况要好得多。许多基本问题都已经国际标准化， 如RDF和OWL等（虽然还有一些争论， 如对OWL)，而且在技术上并不需要等待重大突破。许多工作只要投入足够的人力就能实现的，这也就是为什么发达国家会以官方的名义在语义网领域投入这么多的研究经费和人力。

虽然没有统一的标准可以使用， 但人们总是能够参照建立信息系统等其他软件工程项目那样那样，完成以下几个环节： 系统设计(System Design) － 数据表示(Data Represenation)
-数据处理(Data Processing) - 数据展现 (Data Presentation)。

你所要做的第一步， 就是要有一个良好的系统设计。 实际上它要求考虑其他几个
环节的主要问题， 即数据表示(Data Represenation)， 数据处理(Data Processing)，
和 数据展现 (Data Presentation)。待我在下面具体讨论。

如只采用RDF/S， 好处是：简单易学，有许多现成的工具可供使用. 有现成的RDF查询管理系统
提供数据处理和查询能力，如Sesame。缺点是： 知识表达能力有限，如不能表达逻辑否定。这样就无法描述这样一条音乐基本知识： 喜庆音乐不是悲伤音乐。

如采用OWL-DL，好处是知识表达能力较强，使用的是国际标准化的本体描述语言， 有利于向后
兼容。 当前的不足是： 还没有较好的OWL DL推理机可供使用，考虑到OWL仅在今年初才通过国际标准。这个问题可能很快就会解决。

我建议你可以用OWL, 使用Protege作为本体编辑工具，生成OWL的音乐本体描述。

2. 数据处理:  更准确地说就是数据查询与推理。 你可以使用KAON工具来进行OWL的
知识推理， 或采用其他工具把OWL变为DIG格式， 使用DL推理机如Racer来进行。

3. 数据展现: 也就是要考虑 检索后或推理后所获得的数据， 应如何展现给用户。 你可以使用XSLT的有关工具把推理机返回的结果再次转换，生成有关的HTML格式，或多媒体格式提供给用户。

请原谅， 我在这里只是简要地介绍有关环节，许多具体术语和细节还没有详细介绍。你或其他读者有什么具体问题，请进一步提出。我将另行详细回答。

技术飞速发展，已经有基于audio的semantic web软件产品问世，http://www.moodlogic.com 但是是基于对音频的分析和应用，原理是把音频分成若干小段，用meta data标记，然后进行诸如：速度，情绪等感情分析。比如你有一万首mp3,你很累想听点轻松的，只要选relax即可。

而我的项目是想建立世界上第一个基于Music Notation,即 MusicXML(http://www.recordare.com/xml/tutorial.html)的ontology.因为一直在思考如何分析乐谱的问题，所一没太深入探讨xml技术问题。

去描述一条音乐，我是这样的，需要把音乐以小单元（比如一拍子的四个音组成的和弦的感情）描述，从属关系是：

单元-->小节-->乐段，

那么，ontology记载着这些关系和描述。但是如果去分析总的乐段的情绪，我目前的方法是分析每一个单元的情况，然后每一个乐段会有一个总的参数(Sum)，比如：happy: 96, sad:12;  exciting:45,quiet:17;  satisfied:79,disatisfied:12 . 那么这个乐段的总情绪应该是欢快的明朗的舒服的。

现在有一个难关，就是一条音乐的总情绪参数究竟是什么是否是应该由ontology来描述的。因为ontology和musicXML恐怕只带有单元的情绪信息，而sum参数也在ontology里面表述好吗？

我觉得是可以的。因为在这个ontology出来以后，下一步就是做automatic extraction,　以java程序自动的为MusicXML做情绪分析的metadata。在这个分析的时候，也可以自动的把sum情绪向量表示进去。

我也挺感兴趣的。

以下是引用wolfqi在2004-10-10 3:57:12的发言： 黄博士您好，我来自瑞典皇家工学院，www.kth.se,久慕大名，今天没想到在这儿逮到您了。 我的硕士论文是有关semantic web的研究，当今世界xml横行天下，就连音乐的乐谱发布都用xml来做了，美其名曰MusicXML。MusicXML主要是做乐谱出版印刷和网络出版用，由于我的IT(在北欧读IT６年了)学习和音乐背景，我提出了是否《用Sementic Web 进行对音乐的人工智能分析》的论文题目，但semantic web本身具体的东西还都不太完善，茫茫兮休远，苍然兮独怆。 KTH 的音乐声学系TMH一直立志于对音乐感情的分析研究，目前世界在这一领域已经取得一些成绩，包括电脑对乐谱的计算机分析，电脑对wave音频文件强弱的逻辑分析，以得出此段物理载体的相对应的人类的感情。相关的成果如果能够转化成为semantic web中的　人工智能分析标准，那么则可实现对网络上音乐的职能话分析。因为MusicXML也可以载入音符强弱，那么semantic web也可以成为音乐演奏者感情分析的工具。 题外给大家：可能有人问了谁吃饱了撑的分析音乐的感情做什么？　多唠叨一句：这个非常重要，在音乐来说，以后都xml了，那么音乐的分类，搜索，就成为一个很大的问题，由于音乐xml不同于语言xml，所以音乐语法和我们的语法是不一样的。在科学上来说，比如说你饲养了一只电子机器猪，如果你想给这只猪加上感情，比如你生气了，那么猪要有音频的人类感情分析。比如你想让电子猪欣赏音乐的话，那么就得有音乐人工智能软件。 在商业上，目前我觉得最可行的是手机铃声，现在手机铃声已经有公司用xml储存分类了，不久所有铃声就都会在线，如果有一兄弟失恋了，想找点失恋音乐的话，只需要打入：我失恋了。那么semantic web 语言部分就把这个信息转化成感情部分，通过某rdf到Semantic Web音乐部分，找出最适合失恋感情的音乐。 wolfqi@mac.com　也可通过邮件联系。

本体技术与其他人工智能技术一样依赖于相关的知识表示和推理技术，但它与通常的知识库系统
，专家系统， 和主体技术（Agent Technology)系统所显著不同的是： 本体表示更强调数据共享性。也就是说本体所表达的数据要为他人所充分接收， 它所要表达的一般是共享知识，而不是带有个人观点的数据。

这种区分有点类似于“知识"(knowledge) 和”相信“(belief)的区别。一个知识命题是一个
大家所接受的客观描述， 而一个相信命题是一个他人可能不能接受的主观描述。如”每个星期都有个星期五“是一个知识命题，（我们很难想象会有人不同意这个论述),   而”星期五是不吉利的“则是一个相信命题。前者为所有的人所接受， 后者只为个人所接受。除此之外，还有约定知识， 如”星期五是每星期的第五天“是为许多人所接受， 但一些人可能不接受，因为他们会认为星期日是每星期的第一天， 这只是约定的不同。

当然有人可能并不接受上述区分， 他们会认为一切可用于推理和行动的信息都可以称为知识，如果是这样的话， 我们可以把前者称为所有人的共享知识， 后者为个人知识，而约定知识是部分人的共享知识。

本体要描述的是共享知识，而不是个人知识。因此当我们决定要把那些数据在本体中来描述时，就要先判断一下是否为他人所接受。我们要把那些共同所接受的命题在本体中描述，而把那些个人知识留在本体推理的上一层来实现。前者是本体之内的推理， 后者是本体之上的推理。这是本体技术中的两个不同推理层次。前者的推理是由相关逻辑的推理机自动完成的，而后者要由我们在本体描述的基础上再加一个推理层来实现。

这样做的好处是我们能够最大程度地实现数据共享和可重用。由于本体数据是大多数人所接受的，别人可以自由使用你所提供的数据，而把带有个人观点的数据留在本体描述之外，我们还可以根据不同的需要，提供不同的推理需求。这也就是为什么语义网分多个层次， 前者
对应的是本体描述层， 而后者对应的是上面的逻辑和证明层。

最重要的第一步是要作适当的文献调查。我想在音乐学术界或心理学界应该有一些现成的理论或方法来研究如何从乐曲单元到乐段特征的分类。如果有大家所公认的理论或方法，那么就可以直接把它在本体描述层次上进行。如果这些文献也只是一些一家之言，也可以把它作为约定知识，在本体描述层来实现。如果这一切都没有有关文献支持，有关分类方法只是你所要自己提出的个人想法，那么我们就得谨慎地思考， 我们所作出的分类结论是否会被他人所接受。

那么我们就要这样做： 把那些公认的音乐基础知识及其分类在本体描述中实现， 如
有关调式的知识，和声学的知识等， 而把那些个人观点留在本体描述的上一层的推理来
实现。

如果你有时间作一番有关的文献调查，给大家报告报告，我想我们大家都会非常高兴地听听
你所提供的音乐科研报告。如果你的结论是：有关问题在学术界还是一片空白， 那我们下一步要做的就是要详细讨论你所提出的基本思路。 有关问题我将会在后续讨论中详细展开。

谢谢！

决定是否把有关数据储存在一起，还是分开储存，主要取决于数据的内在关联程度。现有的许多
实用系统已能够处理相当规模的数据， 如Sesame系统能够处理40万条RDF的Wordnet陈述. 实际上，能够处理数百万条数据这已是对实用系统的一个基本要求。一般都能达到这个要求。

当然， 根据内在关联程度把有关数据分别储存，有利于数据管理，修改和变动。如OWL语言中， 可以用import语句来把多个储存在不同地方的本体连接在一起使用。

本体的模块化技术是SW中的当前研究热点之一。

如果把OWL的XML树状结构转成三元组的关系结构用关系数据库系统来支持，则在推理上会增加许多开销，如寻找子树效率就会低很多。一般来说，它要用列表方式
来储存效率会高一些。大多是用表处理语言系统来处理。如Racer就是用LISP语言。我们最近在用Prolog开发一个OWL DL推理机，前台是我们开发的XDIG(一个
Prolog的DIG服务器〕， 后台是外挂的Racer DL推理机。目前还在调试之中.
如果你对其感兴趣的话， 我们将提供进一步的细节。

注意的是Racer已能处理相当规模的数据。我们用Racer处理过DICE本体（一个医学本体库）,其涉及到数万个概念描述，效率尚可。你所说的“海量”是个什么概念？目前我们所看到的大型本体库，如wordnet，现有系统一般都能处理。

Sesame目前支持OWL Tiny(支持属性的特征描述，以及(In)Equality)，还不知道它准备用什么方法支持OWL Lite的推理。

我看到用deductive database，如XSB可以支持部分OWL Lite的推理，因为一个OWL Lite的子集可以用Datalog或prolog完全刻画（如：description logic program）, 但不知道deductive database的效率如何，不明白这项在90年代初就比较成熟的技术为什么没有被工业界采纳。

我最关心的是对海量ABox数据的处理，最少是百万级的，如果没有数据库支持，而是在内存中运算，如prolog，racer，Jena2的OWL推理（Rete规则引擎），我估计都难以处理。 最近Ian Horrock他们做了个Instance store，但只能处理role-free的ABox。

不明白，你们怎么用prolog开发一个OWL DL推理机，而且还要挂一个Racer。能否告知更详细的资料，或项目文档的URL？ 谢谢！

以下是引用Huang在2004-11-12 21:26:44的发言： 现在大多数RDF系统都能支持数据库数据储存，如Sesame就支持mySQL数据库系统。由于RDF的推理相对简单，所以用数据库处理比较方便。 Sesame也将支持 OWL lite. 当然，当我们说OWL，一般都是指OWL DL.它的推理比较复杂，要求有DL推理机的支持。 如果把OWL的XML树状结构转成三元组的关系结构用关系数据库系统来支持，则在推理上会增加许多开销，如寻找子树效率就会低很多。一般来说，它要用列表方式 来储存效率会高一些。大多是用表处理语言系统来处理。如Racer就是用LISP语言。我们最近在用Prolog开发一个OWL DL推理机，前台是我们开发的XDIG(一个Prolog的DIG服务器〕， 后台是外挂的Racer DL推理机。目前还在调试之中. 如果你对其感兴趣的话， 我们将提供进一步的细节。 注意的是Racer已能处理相当规模的数据。我们用Racer处理过DICE本体（一个医学本体库）,其涉及到数万个概念描述，效率尚可。你所说的“海量”是个什么概念？目前我们所看到的大型本体库，如wordnet，现有系统一般都能处理。

我最关心的是对海量ABox数据的处理，最少是百万级的，如果没有数据库支持，而是在内存中运算，如prolog，racer，Jena2的OWL推理（Rete规则引擎），我估计都难以处理。 最近Ian Horrock他们做了个Instance store，但只能处理role-free的ABox。

[quote][b]

你所说的“海量”数据处理问题， 我想也就是SW业界所说的“Scalability”问题。
我的同事在作这方面的研究，这是欧盟的一个三年研究课题。今年才第一年。有
许多方法， 如逼近推理法， 分布处理法， 模块处理法等等， 详情请看有关
的技术报告：
http://www.cs.vu.nl/~holger/KnowledgeWeb/Deliverables/D2.1.1/D2.1.1-StateOfTheArt.pdf

我看到用deductive database，如XSB可以支持部分OWL Lite的推理，因为一个OWL Lite的子集可以用Datalog或prolog完全刻画（如：description logic program）, 但不知道deductive database的效率如何，不明白这项在90年代初就比较成熟的技术为什么没有被工业界采纳。

[quote]

有关的datalog技术一直还在用， 请参见我的同事的有关报告：

http://www.cs.vu.nl/~holger/KnowledgeWeb/Deliverables/D2.1.2/D2.1.2-Approximation.pdf

其第三章第二节讨论的是如何把OWL DL转成Datalog。

有关Sesame支持OWL Lite的消息来自于 Naso的下列报告：

The next version of the ontology (i.e. the first one of GO) will be in OWL Lite.
Actually, it already is and it works fine with Sesame and Jena. We did an
extension of the in-memory SAIL of Sesame for this purpose (to
partially support OWL Lite) which will become public soon. Again very soon,
there will be a new version of KIM which works with GO,
which also means OWL Lite.

Latter, if necessary, we can provide a version of GO in RDFS, for the sake
of compatibility with tools which does not support OWL. Even this is not
badly needed, because OWL Lite (at a syntactical level) is an extension
of RDFS. So, to read an OWL file in RDFS tool, one needs to load the
owl.rdfs first and next the owl file. Then, the classes, properties,
as well as any other resources and literals will be visible as if they were in RDFs.

我请Sesame的开发者Jeen  Broekstra 回答你的问题， 他的答复如下：

As Naso mentions, OntoText has been working on a version of the Sesame
in-memory store that supports (part of) OWL Lite. I haven't actually
seen it myself yet (nor tested it), but we will hopefully include that
in the next release of Sesame.

The current version of Sesame supports partial OWL Lite by use of its
custom inferencer, on top of an RDBMS. This is not very scalable but
works well enough for relatively simple OWL models. There is an XML rule
file for this custom inferencer, which is especially for OWL
inferencing, included in the source download of Sesame.

Regards,

Jeen

2）“reasoner does not directly answer queries relating to dynamically introduced class expressions.” －Jena 2 Inference support

3）“Scalability”问题，即难以对海量实例做推理。

我对Sesame还不太了解，如果sesame的方法也是基于Rule的，不知道如何克服这些问题。

为什么描述逻辑没有类似“公理系统”的proof theory呢？

由于描述逻辑推理的复杂性，其 tableaux方法从工程的角度比公理系统方法更实用。
因为我们通常都是从一个询问推理开始， 关注的是一个命题p是否是有关前提S的一个结论。
Tableaux总是从命题p开始， 看看p的否定式not(p)是否与前提S中的某些命题相冲突。 如果有冲突，则表明not(p)是不可满足的，我们就可以立即得出p是前提S的一个结论。

“公理证明系统”不是从我们所关注的命题开始的， 而是漫无边际地推出许多结论，
但我们所要的结论却可能迟迟不到。除非你能改进其推导过程，使用点“启发性”方法，使之更快地寻找出我们所关心的结论，但这已是有点象Tableaux方法了。

以下是引用Huang在2004-11-19 20:08:11的发言： 由于描述逻辑推理的复杂性，其 tableaux方法从工程的角度比公理系统方法更实用。 因为我们通常都是从一个询问推理开始， 关注的是一个命题p是否是有关前提S的一个结论。 Tableaux总是从命题p开始， 看看p的否定式not(p)是否与前提S中的某些命题相冲突。 如果有冲突，则表明not(p)是不可满足的，我们就可以立即得出p是前提S的一个结论。 “公理证明系统”不是从我们所关注的命题开始的， 而是漫无边际地推出许多结论， 但我们所要的结论却可能迟迟不到。除非你能改进其推导过程，使用点“启发性”方法，使之更快地寻找出我们所关心的结论，但这已是有点象Tableaux方法了。

你们现在有没有从事这项研究的？谢谢答复！

DL推理机的实现比较复杂。Racer提供了一个很好的DL推理机，而且还提供标准的DIG interface支持。但目前的DIG interface只支持标准的DL推理服务，尚未支持OWL推理。
而且OWL不是一个推理查询语言，也就是说我们最多能用OWL描述本体，但不能用OWL
来询问本体。这就需要对OWL和DIG作适当的结合。
OWL DL推理需要DL推理机， 有了Racer, 我们完全不必重复劳动. 我们就用它作为外挂。
我们要加上从OWL到DIG转换模块。我们是用Prolog系统来做的。

有关系统还在调试之中。你能否给我一个你的个人电子邮件地址。我将在适当的时候，给
你发去有关软件包。如果你能作些数据测试，发现一些Bugs, 那就更好。

我想你所说的本体集成，可能指的是本体融合， 即把多个本体汇集在一起使用，即SW业界所说的ontology reconciliation. 这是一个很大的题目，因为它涉及到许多不同的情况：

本体合并（ontology merging): 把几个本体并在一起，消除重叠的和不协调的部分
本体串联 (ontology aligning)：把几个本体串在一起，即建立相互之间的映射，但各自仍然独立而且没有被改变。
本体集成 (ontology integrating): 把几个本体有机地结合在一起，产生新的一个本体。

有许多文献研究这些问题。下列文献提供了一个较好的综述文章：
A. Hameed, et al, Ontology Reconciliation, in: S. Staab and R. Studer (eds.),
Handbook on ontologies in Information Systems, Springer verlag, 231-250, 2003.

有关本体集成较好的文章有：
Diego Calvanese, et al.,  a framework for ontology integration, www.semanticweb.org/SWWS/program/full/paper21.pdf.

我们的一些同事作的有关C-OWL的文章也可供参考：
1. H. Stuckenschmidt, et al,  Using C-OWL for the Alignment and Merging of Medical Ontologies, Proceedings of the First International Workshop on
Formal Biomedical Knowledge Representation (KRMed'04), 2004.
http://www.cs.vu.nl/~frankh/postscript/KRMed04.pdf

2. Paolo Bouquet, Fausto Giunchiglia, Frank van Harmelen, Luciano Serafini, Heiner Stuckenschmidt, C-OWL: Contextualizing Ontologies (ISWC'03) ,
http://www.cs.vu.nl/~frankh/postscript/ISWC03.pdf

我现在的研究方向也与本体有关(本体在专家系统中的应用）。现在专家系统的几个主要

问题是：1）缺乏常识，2）知识难于共享，3）推理问题。我觉得本体是可以用来解

决前两个问题的。我的看法是：将属于常识的易于共享的本体知识与属于专业的难

于共享的专家个人知识分离，本体知识部分的形式化做到与具体应用系统无关。现

在的问题就是：本体部分的知识如何与领域知识的融合问题(我想本体与领域知识都

采取相同的形式化方法可能不现实）、特别是联合推理问题（如果他们采用不同的形式化方

法）。不知道您有什么建议。谢谢。

以下是引用Huang在2004-12-3 21:03:24的发言：   DL推理机的实现比较复杂。Racer提供了一个很好的DL推理机，而且还提供标准的DIG interface支持。但目前的DIG interface只支持标准的DL推理服务，尚未支持OWL推理。 而且OWL不是一个推理查询语言，也就是说我们最多能用OWL描述本体，但不能用OWL 来询问本体。这就需要对OWL和DIG作适当的结合。 OWL DL推理需要DL推理机， 有了Racer, 我们完全不必重复劳动. 我们就用它作为外挂。 我们要加上从OWL到DIG转换模块。我们是用Prolog系统来做的。 有关系统还在调试之中。你能否给我一个你的个人电子邮件地址。我将在适当的时候，给 你发去有关软件包。如果你能作些数据测试，发现一些Bugs, 那就更好。

还有几位从本论坛得知我的情况，而同我进行私下学术联系的国内同行，我也曾答应他们帮他们看论文，也由于一时抽不得空来，也还没及时回复。借这个机会我一并向他们表示深深的歉意。
（但还是争取尽早给他们有一个答复。)

谢谢你！ 有关的报告在线录象片段可以从以下得到：
http://wasp.cs.vu.nl/sekt/gallery/ustc-visit04/256k.ram
你从中也许还能找到你自己的影子。

如果由于网络问题， 在线录象不能正常观看的话， 也可以先把它下载下来：
http://wasp.cs.vu.nl/sekt/gallery/ustc-visit04/256k.rm

我们开发的一个XDIG系统就是开发DL推理机之上的应用的逻辑程序设计软件包，它能使系统在需要的时候调用DL推理机进行本体推理，其余则有自己根据用户的需要作相应的处理。

由于工作繁忙，百事缠身，常常不能及时到这个论坛来同大家交流， 深感力不从心， 因此我打算结束在本论坛的应答服务。望大家理解。

这些天来有幸通过本论坛结识了许多国内学术同行，我非常高兴，特别对你们的科学探索精神留有深刻的印象。尤其要感谢admin和orangebenchden簦把这个论坛办得如此丰富多彩,成为了汇集了中华大地语义网研究人才的胜地。

在这新的一年即将来临之际以及本人即将离开本论坛之际， 我谨向来到论坛的每一位同行朋友，表示新年的祝福。 下面我用本论坛的术语， 给论坛和论坛的各位参与者送一对节日对联：

新年寄语 义网中华本体精英
科学赶超 文本网络万维功夫

预祝本论坛在新的一年里，越办越好，通过语义网的研究讨论，联络更多中华大地的本体研究精英，作出超一流的（超文本)科学成果，出更多更好的网络和万维网的科学研究论文。

致以最美好的祝福！

Huang

非常欢迎等您有空闲的时候，再来论坛指导。

祝您新年快了，工作顺利！

以下是引用Huang在2004-12-17 21:34:44的发言： 各位好！ 由于工作繁忙，百事缠身，常常不能及时到这个论坛来同大家交流， 深感力不从心， 因此我打算结束在本论坛的应答服务。望大家理解。 这些天来有幸通过本论坛结识了许多国内学术同行，我非常高兴，特别对你们的科学探索精神留有深刻的印象。尤其要感谢admin和orangebenchden簦把这个论坛办得如此丰富多彩,成为了汇集了中华大地语义网研究人才的胜地。 在这新的一年即将来临之际以及本人即将离开本论坛之际， 我谨向来到论坛的每一位同行朋友，表示新年的祝福。 下面我用本论坛的术语， 给论坛和论坛的各位参与者送一对节日对联： 新年寄语 义网中华本体精英 科学赶超 文本网络万维功夫 预祝本论坛在新的一年里，越办越好，通过语义网的研究讨论，联络更多中华大地的本体研究精英，作出超一流的（超文本)科学成果，出更多更好的网络和万维网的科学研究论文。 致以最美好的祝福！ Huang

通过与您的对话，我们的眼界开阔了许多，对一些问题有了新的认识，令我们大家受益匪浅！

在此，代表全体版友向您致以谢意！

另外非常感谢您给我们的节日对联！

祝您在新的一年里工作顺利，硕果累累！

以下是引用Huang在2004-12-17 21:34:44的发言： 各位好！ 由于工作繁忙，百事缠身，常常不能及时到这个论坛来同大家交流， 深感力不从心， 因此我打算结束在本论坛的应答服务。望大家理解。 这些天来有幸通过本论坛结识了许多国内学术同行，我非常高兴，特别对你们的科学探索精神留有深刻的印象。尤其要感谢admin和orangebenchden簦把这个论坛办得如此丰富多彩,成为了汇集了中华大地语义网研究人才的胜地。 在这新的一年即将来临之际以及本人即将离开本论坛之际， 我谨向来到论坛的每一位同行朋友，表示新年的祝福。 下面我用本论坛的术语， 给论坛和论坛的各位参与者送一对节日对联： 新年寄语 义网中华本体精英 科学赶超 文本网络万维功夫 预祝本论坛在新的一年里，越办越好，通过语义网的研究讨论，联络更多中华大地的本体研究精英，作出超一流的（超文本)科学成果，出更多更好的网络和万维网的科学研究论文。 致以最美好的祝福！ Huang

我的论文分三个部分，我做了标注偶

前提：什么是音乐乐谱语义，什么是音乐乐谱语义的数据表现形式？
what is Music Notation's Semantic? What is the data presentaion of Music Notation's Semantic?

定义一：音乐自然音符所表现出来的人类的感情（如：喜怒哀乐）的定义就是音乐乐谱语义。
定义二：一段音乐乐谱语义的总定义是这段音乐“单元音乐乐谱语义”的综合

音乐乐谱语义的数据表现形式，我设计为音乐语义参数，即：每一个和声所表现出来的情绪是不单纯的，有很多意思，比如一个和声可能有７０％的洪亮和３０％愤怒，能因为都是属于“阳”性性质。

１。Music Notation's Semantic (音符的语义，这方面人类在和弦上有知识能，命题共性可寻。)
因为音乐的复杂性，所以在第一步，我会做非常非常简单的东西出来（无变调）。即：和声语义与感情语义

　－　和声语义　－　和声的物理自然频率的结合对人是有刺激的，人的感情反映有喜怒哀乐。
　－　感情语义　－　音乐中有感情的描述，比如：欢快的，痛苦的，和音乐表情：fff = 强；ppp＝弱　等等，这些原有的音乐表情影响音乐本身的语义。

２。如何classify音乐乐谱语义
　－　音乐乐谱语义参数标准
　－　树：包括人类情感分类，音乐和声分类
　－　音乐乐谱语义参数　来表示　人类感情与音乐和声的关系
　－　集成的单元语义（形成段的语义结论）
　
目前马上就进入system design过程中，决定使用owl，然后我马上研究一下音频他们是怎么做的，可能会有启发。

下面是［喜］［怒］［哀］［乐］的四个参数，与拍子分成８个部分，每个部分有自己的参数，比如第２部分就有变化，因为旋律２与和声１３５有２度的关系，所以会有不一样的感觉。（这个例子里参数是臆想的）。那最后会有一个总的参数百分比计算出来。音符是我们看到听到的东西，是现象，而语义（人类感情）是赋予电脑乐谱背后的东西，而乐谱与乐谱，甚至以后乐谱与文章（感情语义），乐谱与图像（感情语义），乐谱与动物叫声（感情语义）在语义上相关联就有了考证和通用的标准。

目前我所面临的问题就是如何把这个ontology描述出来了。在我描述之前，希望大家多提意见，谢谢！

此主题相关图片如下：

我们这里在做中医药的医学本体库，因为是全国十几个中医药科研机构同时分块做，现有的本体膨胀的很快，具体多少个概念和实例没有统计过，但Protege的文件已经有10多个G，且开发还在进行。我们起先用Protege处理，后来一个10几M的 文件就要打开好久，后来用Protege的服务器版本，把本体分布化了，稍微好了一些。这个本体还只用到RDF去描述，主要用于做简单查询，后面还想提升到OWL能支持DL推理，但感觉难度非常大。

不知道黄博士有何建议，目前性能更好一些的SW存储、推理工具？

我觉得高性能的分布是本体存储与处理是未来SW应用的必定需求，现在已有的SW应用数据量都还小，所以需求还不突出，就如传统的DB一样，性能永远是一个瓶颈问题。

“如何度量两个概念之间的语义距离。语义距离越近，就表明两个概念越相似。这样在工程实现上就可以用于有关“可能替代品“的推理。许多人现在使用的是计算语言学上的方法， 特别是用WordNet的办法来度量两个概念的语义距离。有的使用格论（Lattice Theory)的方法来度量两个概念的距离”

不知道黄博士指的格论是不是概念格？ 关于概念格在语义网络中的应用，您有什么见解？能否给我一些相关的资料（joyeezhao@hotmail.com）？谢谢！