虽然说在服务的IO匹配时，确实是把IO参数名或消息名绑定了本体中的类，但是：在作服务匹配的时候，难道就仅仅之利用了继承关系么？
　如果确实只利用了继承关系，那就是一棵分类树。
　但是在很多现在对服务匹配的文章中可以看到，有基于语义距离的，有基于属性关系或属性相似度的，等等！这些能用在分类树中么?

在没看到这样的paper之前，我认为：基于继承关系的匹配方法是经典的、主流的。理由有二：
  1. ISWC2002 Paolucci那篇文章的引用率极高；
  2. 我所知道的现在仅有的两个有较大影响的语义服务匹配测试数据集都是基于此方法：
    1) DFKI所做的一个实在的OWL-S匹配系统及其测试数据集owl-s tc;
    2)CEC'06 and EEE'06 上的WS-Challenge 的Semantic Service Discovery竞赛所用的数据集，也是一个用XML Schema所表示的type hirerarchy。

比如公司本体，下面有2个子类，服务和产品，他们都有质量（服务质量评估，产品质量评估），那么"质量“应该是subclass呢？还是property?如果是property是否可以被服务和产品共同使用？还是要定义2次

还有比如数据挖掘流程本体，子类有”数据预处理“和”建模“，建模下面有子类”算法“，”算法“比如又含”算法a",而算法a既是建模时候用的，也是数据预处理时候用的，那么应该怎么表示这个关系呢？如果用protege owl应该怎么操作？关系图上是否是一个箭头从“数据预处理”直接斜插到“算法”下面的“算法a"? 这样会否打乱层次关系？从hierarchy变成gragh了?