本体构建实例

9.2.2　本体构建实例

1.客户本体的构建

随着电子商务的发展，客户资源开始成为全球企业争夺的对象。客户不再局限于某个特定的区域如一个城市、省或国家。电子商务的出现和发展源于两方面的原因:一是全球经济一体化和商务活动国际化的需求，二是信息技术的快速发展及其在商务活动中的广泛应用。基于Web的电子商务具有更多的开放、灵活和动态，必将以多种方式帮助改善商务关系:不再是实施一个供应商一个链接，而是供应商可以通过大量潜在客户与市场链接起来;供应商和客户可以在大量商业伙伴中进行选择;供应商和客户可以随着市场的发展而更新其商务关系。基于Web的电子商务可以允许接触大量的潜在客户，而不存在需要实施许多通信渠道的问题。

现代竞争已经从企业间的竞争转向供应链间的竞争。企业倾向于关注其核心能力，并形成更小的实体，这导致了对商业交互的更多需求。在新的竞争环境下，客户是指最终客户，最终客户已成为企业和供应链关注的焦点。通过电子商务，客户可以购买其所需要的任何东西。通常，客户的需求总在保持变化，据预测，基于客户需求的商务活动将获得更大的竞争优势。

如何留住老客户和获得新客户是客户关系管理(Customer Relation Management，缩写为CRM)的主要内容和目标。作为CRM战略实施的基础之一，客户信息共享应该首先得到构建，以便形成一个通信平台。许多技术如COM(Component Object Model)、CORBA(Common Object Request Broker Architecture)和Agent的开发是为了解决信息共享的技术问题。虽然这些技术通过不同系统间的消息交换模式在信息共享方面运行得很好，但它们只是基本的语法共享，不能从语义上描述客户信息，所以不能表达隐含的在信息系统中存在的与客户知识相关的公理、事实、判断和规则。^[7]因此，从知识库或其他信息源中推理的结构化信息是无法获得的。当然，一些新的和有用的有关客户的知识很难产生或推导。更重要的是，不基于语义关系的信息共享常常由于某些原因如在相同或不同的商务环境下相同的概念具有不同的名称而导致混乱。^[8]

从语义方面出发，信息共享还存在许多没有解决的问题。多数基于语法关系的信息共享问题在考虑其功能机制时是不可避免的。

作为信息共享模式的另一种方式，基于语义关系的本体得到了更多的关注。因为这种信息共享模式可以提供一个统一的通信平台，并避免一些语义上的错误，因而大家努力地设计出一种有效的工具以便在企业内外进行有效的信息共享。

一个相同的概念在两个不同的领域可能通过两个不同的标识符加以识别。如果一个程序想要在两个不同的领域比较和链接信息，它必须知道这两个标志符实际上表示了相同的含义。本体可以帮助解决这个问题。^[9]

(1)一个客户本体的架构

在图9-2中，提出了客户本体的架构。^[10]这个架构不可能作为CRM中的一个标准本体，因为客户本体的标准化依赖于许多组织的关注和努力。在CRM中，存在许多需要表达的关系，以便机器能够明白和处理。如何将在自然语言中表示的判断转变为形式化描述逻辑是本体构建中的一个主要任务。在客户本体架构中，考虑了OWL提供的表达能力。

OWL类解释为包含个体的集，它们通过精确地表示类成员需求的形式化(数学)描述而得到描述。属性是两个个体的二元关系，即属性将两个个体链接在一起。实例表示领域中感兴趣的对象。

在图9-2中，椭圆代表类，箱形代表属性。OWL描述是以属性为中心的，每个属性拥有领域(domain)和范围(range)。Customer是一个类，它有6个子类:High_Contribution_Customer，Low_Contribution_Customer，Dedicated_Customer，Non_Dedicated_Customer，Long_Term_Customer，Short-Term_Customer。Non_Dedicated_Customer和Short-Term_Customer的交集形成一个新类，这个新类是Disloyal_Customer的超类。Dedicated_Customer和Long_Term_Customer的交集形成一个新类，这个新类是Loyal_Customer的超类。3个属性hasContact，affiliation，hasIncome的Domain都是类Customer，hasContact的range是类Contact。6个属性hasName，hasEmail，hasCountry，hastate，hasCity，hasZipcode的Domain都是类Contact，属性affiliation的range是类Affiliation。属性hasIncome的range是类Income。类Income与包含个体Less_Then_Ten_Thousand，More_Than_Hundred_ Thousand，More_Than_Ten_Thousand_And_Less_Then_Hundred_Thousand的枚举类相等。

(2)客户本体的OWL源代码

在Protégé-2000中，构建了基于图9-2的OWL客户本体。OWL本体基于概念可以得到定义和描述的逻辑模型。复杂概念可以通过简单概念得到构建。另外，逻辑模型允许推理机的使用，以便检测本体中所有的判断和定义是否相互一致，识别哪个概念适合哪个定义。推理机能够帮助正确地维持层次结构，这在处理可能拥有多个父类的类时特别有用^[11]。用OWL描述的本体的一个重要特征是它们可以被推理机所处理。由推理机提供的一个主要服务是检测一个类是否另一个类的子类。通过对某个本体中所有类运行这种检测，推理机可以计算出导出的本体类层次。另一个推理机提供的标准服务是一致性检测。基于某个类的描述，推理机能够检测某个类是否可能拥有实例。^[12]

OWL拥有更多的具有形式化语义的词汇，如disjointWith，intersectionOf，unionOf，complementOf，oneOf，minCardinality，maxCardinality，cardinality，以便表达更多的语义关系和限制，如类的不相交、类的相交、类的联合、类的补充、类的枚举、类的基数。下面针对OWL客户本体，结合具体的例子进行分析。

①宣布为不相交的类。类可以宣布为不相交。在图9-2中，类Short_Term_Customer是指属性has_Time＜5的客户，Long_Term_Customer是指属性has_Time≥5的客户。类Short_Term_Customer和Long_ Term_Customer可以宣布为不相交。相关的源代码如下:

＜owl:Class rdf:ID=“Short_Term_Customer”＞

＜rdfs:subClassOf＞

　＜owl:Class rdf:ID=“Customer”/＞

＜/rdfs:subClassOf＞

＜owl:disjointWith＞

　＜owl:Class rdf:ID=“Long_Term_Customer”/＞

＜/owl:disjointWith＞

＜/owl:Class＞

②类的布尔运算。OWL允许类和属性的任意布尔运算。Dedicated_Customer是指Number_of_Purchased_Product≤2的客户，类Long_Term_Customer和Dedicated_Customer的交集形成了新类，类Loyal_Customer是这个新类的子类。相关的源代码如下:

＜owl:Class rdf:about=“#Loyal_Customer”＞

＜rdfs:subClassOf＞

　＜owl:Class＞

　　＜owl:intersectionOf rdf:parseType=“Collection”＞

　　　＜owl:Class rdf:about=“#Long_Term_Customer”/＞

　　　＜owl:Class rdf:about=“#Dedicated_Customer”/＞

　　＜/owl:intersectionOf＞

　＜/owl:Class＞

＜/rdfs:subClassOf＞

③基数的限制。在OWL中，基数值可以是任意的非负整数。Long_Term_Customer是指属性has_Time的最小基数是5的客户。相关的源代码如下:

＜owl:Class rdf:about=“#Long_Term_Customer”＞

＜rdfs:subClassOf＞

　＜owl:Restriction＞

　　＜owl:onProperty＞

　　　＜owl:DatatypeProperty rdf:ID=“has_Time”/＞

　　＜/owl:onProperty＞

　　＜owl:minCardinality rdf:datatype=“http://www.w3.org/2001/XMLSchema#int”

　　＞5＜/owl:minCardinality＞

　＜/owl:Restriction＞

＜/rdfs:subClassOf＞

④枚举类。类可以通过列举所有构成类的个体进行描述。类的成员就是列举的个体的集合。在客户本体中，Income是一个枚举类，它包括的个体有:Less_Than_Ten_Thousand，More_Than_Hundred_ Thousand，More_Than_Ten_Thousand_And_Less_Than_Hundred_ Thousand。相关的源代码如下:

＜owl:Class rdf:ID=“Income”＞

＜owl:equivalentClass＞

　＜owl:Class＞

　　＜owl:oneOf rdf:parseType=“Collection”＞

　　　＜Income rdf:ID=“Less_Than_Ten_Thousand”/＞

　　　＜Income

rdf:ID=“More_Than_Ten_Thousand_And_Less_Than_Hundred_ Thousand”/＞

　　　＜Income rdf:ID=“More_Than_Hundred_Thousand”/＞

　　＜/owl:oneOf＞

　＜/owl:Class＞

＜/owl:equivalentClass＞

　＜/owl:Class＞

目前，语义Web本体语言已得到标准化。XML，XML Schema，RDF，RDF Schema和OWL对本体语言的标准化做出了巨大的贡献。然而，客户本体的标准化需要未来更多的努力。客户OWL本体构建是一项复杂的工程。这里探讨了客户本体的架构，并利用Protégé-2000构建OWL本体。利用OWL，可以表达自然语言中的更多关系以便机器能够明白和处理客户信息并进行推理。客户OWL本体是电子商务中有效的CRM的基础。

2.客户抱怨本体的构建

客户抱怨是一类重要的来自客户的信息，它是客户不满意的主要标准。

优秀实践的企业将抱怨看成是改善的机会，这些企业明白抱怨解决和客户忠诚之间的连接。他们热衷于集成抱怨数据和客户反馈以便进行改善，并努力地在企业中加以变化——不管是改善过程或是创建新的产品。一个计划良好的抱怨管理和问题解决过程允许企业获得客户反馈和数据。客户抱怨信息用来改善过程、增加客户满意度和忠诚度、增加利润。^[13]

客户抱怨管理在留住老客户和获得新客户方面具有重要的作用，它也是CRM的一个重要内容。对于一个企业来说，存在许多不同类型的客户抱怨，例如，有些抱怨是有关物流服务的，有些是有关售后服务的，有些是有关质量的，有些是有关态度的。抱怨的解决可能是经济补偿、改善服务等。如果一个客户抱怨是有关质量而未得到快速解决，企业不仅会失去这个客户而且会丧失其他客户。企业应当学着分辨轻微的抱怨和严重的抱怨并采取不同的策略。另外，抱怨拥有许多属性如hasNumber，hasProblem，hasResolution，madeBy。客户是抱怨的根源，客户拥有许多属性如sex，age，marriage status，number of children，income，affiliation，telephone，E-mail等。如何管理这些属性信息，如何定义抱怨和属性的关系以及不同抱怨之间的关系是CRM战略中必须解决的问题。

客户抱怨信息应当在企业内部的部门之间甚至供应链的企业之间得到共享。优秀企业已意识到在企业间共享信息的重要性，因为其他职员或企业能够从相同的信息中获益。在构建信息共享平台中，使用了许多技术。例如，客户抱怨信息可以存储在数据库或数据仓库中。在数据库中，抱怨的每个属性可以定义成一个字段，根据每个字段，某个抱怨可得到快速检索。通常，数据库能够高效地管理大量的抱怨。在数据仓库中，许多数据挖掘技术如时间序列、回归、主成分、相关分析、快速聚类、层次聚类可用来分析和发现有关抱怨的一些规则和关系。另外，一些技术如COM、CORBA和Agent都是为了解决信息共享的技术问题。^[14]OWL在构建抱怨本体时能够表达更多的语义关系。

(1)一个客户抱怨本体的架构

在图9-3中，提出了一个客户抱怨本体的架构。^[15]这不可能作为抱怨管理中的一个标准本体，因为抱怨本体的标准化依赖于多个组织的合作和努力。在CRM中，存在许多语义关系需要表达以便机器能够明白和处理。如何将自然语言转换成形式化描述逻辑是本体构建的一个重要任务。在图9-3的架构中考虑了OWL提供的表达语义关系的能力。

同样，在图9-3中，类用椭圆表达，属性用箱形表达，OWL以属性为中心，每个属性拥有domain和range。Complaint被定义成为一个类，它有两个子类:Light_Complaint和Strong_Complaint。4个属性hasNumber，hasProblem，hasResolution，madeBy的domain都是类Complaint。属性hasProblem的range是类Problem。属性hasResolution的range是类Resolution。属性madeBy的range是类Customer。类Problem拥有4个子类:Logistic_Service，Post_Sale_Service，Attitude，Quality。类Resolution拥有3个子类:Economic_Compensation，Improving_Service，No_Response。属性hasContact的domain是类Customer，属性hasContact的range是类Contact。5个属性hasName，hasEmail，hasZipcode，hasCity，hasCountry的domain是类Contact。属性hasCountry的range是类Country。类Country与包含个体China，America，France，Germany，England，Australia，Japan和Korea的枚举类相等。

AllValuesFrom是针对某个类来限制属性的，它是指这个属性针对某个特定类具有本地的range限制。因而，如果这个类的某个实例通过这个属性与第二个个体相关联，则第二个个体可以认为是具有本地range限制类的一个实例。SomeValuesFrom是针对某个类来限制属性的，某个特定类可能在某个属性上具有限制，至少那个属性的一个值是某种类型。^[16]在图9-3中，类Light_Complaint具有属性hasProblem，该属性通过someValuesFrom限制到类Logistic_Service和Post_Sale_Service，它的另一个属性通过someValuesFrom限制到类Improving_Service和Economic_Compensation。然后，两个属性相交。类Strong_Complaint具有属性hasProblem，该属性通过someValues-From限制到类Attitude，它的另一个属性通过allValuesFrom限制到类No_Response。然后，两个属性限制相交。另外，类Strong_Complaint具有属性hasProblem，这个属性通过someValuesFrom限制到类Quality，这个限制和上面相交的结果形成unionOf的布尔运算。

(2)客户抱怨本体的OWL源代码

在Protégé-2000环境下，根据图9-3构建了OWL客户抱怨本体。下面针对OWL客户抱怨本体，结合具体的例子进行分析。

①基于unionOf的属性限制。OWL允许类和属性的任意布尔结合。考虑类Light_Complaint，属性hasProblem通过someValuesFrom限制到类Logistic_Service和类Post_Sale_Service，可以利用基于unionOf的属性限制来表达这种语义关系。OWL表示如下:

＜owl:Class＞

　＜owl:unionOf rdf:parseType=“Collection”＞

＜owl:Restriction＞

　＜owl:onProperty＞

　 ＜owl:ObjectProperty rdf:about=“#hasProblem”/＞

　＜/owl:onProperty＞

＜owl:someValuesFrom rdf:resource=“#Logistics_Service”/＞

＜/owl:Restriction＞

＜owl:Restriction＞

＜owl:someValuesFrom rdf:resource=“#Post_Sale_Servie”/＞

　＜owl:onProperty＞

　 ＜owl:ObjectProperty rdf:about=“#hasProblem”/＞

　＜/owl:onProperty＞

＜/owl:Restriction＞

＜/owl:unionOf＞

＜/owl:Class＞

②基于intersectionOf的属性限制。考虑类Strong_Complaint，属性hasProblem通过someValuesFrom限制到类Attitude，属性hasResolution通过allValuesFrom限制到类No_Response。然后，这两个属性限制相交。可以利用基于intersectionOf的属性限制来表达这个语义关系。OWL表示如下:

＜owl:Class＞

＜owl:intersectionOf rdf:parseType=“Collection”＞

　＜owl:Restriction＞

　＜owl:someValuesFrom rdf:resource=“#Attitude”/＞

　　＜owl:onProperty＞

　　 ＜owl:ObjectProperty rdf:about=“#hasProblem”/＞

　　＜/owl:onProperty＞

　＜/owl:Restriction＞

　＜owl:Restriction＞

　　＜owl:allValuesFrom＞

　　 ＜owl:Class rdf:ID=“No_Response”/＞

　　＜/owl:allValuesFrom＞

　　＜owl:onProperty＞

　　 ＜owl:ObjectProperty rdf:ID=“hasResolution”/＞

　　＜/owl:onProperty＞

　＜/owl:Restriction＞

　＜/owl:intersectionOf＞

＜/owl:Class＞

③枚举类。在客户抱怨本体中，类Country与包含个体China，America，France，Germany，England，Australia，Japan和Korea的枚举类相等。OWL表示如下:

＜owl:Class rdf:ID=“Country”＞

　＜owl:equivalentClass＞

＜owl:Class＞

　＜owl:oneOf rdf:parseType=“Collection”＞

　　＜Country rdf:ID=“America”/＞

　　＜Country rdf:ID=“China”/＞

　　＜Country rdf:ID=“England”/＞

　　＜Country rdf:ID=“Japan”/＞

　　＜Country rdf:ID=”Korea”/＞

　　＜Country rdf:ID=“Australia”/＞

　　＜Country rdf:ID=“France”/＞

　　＜Country rdf:ID=“Germany”/＞

　＜/owl:oneOf＞

＜/owl:Class＞

　＜/owl:equivalentClass＞

＜/owl:Class＞

④类宣布为不相交。在图9-3中，No_Response不同于Economic_ Compensation和Improving_Service，可以利用disjointWith来表达这种语义关系。OWL表示如下:

＜owl:Class rdf:about=“#No_Response”＞

＜owl:disjointWith rdf:resource=“#Economic_Compensation”/＞

＜rdfs:subClassOf rdf:resource=“#Resolution”/＞

＜owl:disjointWith rdf:resource=“#Impoving_Service”/＞

＜/owl:Class＞

3.合同本体的构建

合同管理的目标是保证:货物或服务在合同下根据合同中描述的时间、成本、数量、质量标准得到提供。有效的合同管理要求提供者解释合同的每个细节，为了从合同中获得最多，合同管理者和提供者需要改善关系以便支持双方的利益。^[17]

在合同管理的过程知识和战略知识描述中存在很多概念和语义关系，如参与者、合同范围内所履行的责任、执行合同的目标、委托、期望的实现目标的商业行为。例如，货物销售合同具有典型的角色:buyer，seller和banker。参与者可能是执行合同的商业实体或个人。考虑的事情通常是一些产品或对买者来说具有经济价值的东西，为了得到这些东西，买者准备付款或其他补偿，而这对卖者来说是有价值的。买者具有对所订购的货物付款的基本义务，卖者具有生产和提供合同中规定的货物的基本义务。还存在其他嵌套的两层义务，如卖者有义务包装好货物以适合运输和交货。^[18]

合同管理在电子商务中扮演着重要角色。对一个企业来说，存在多种类型的合同。通常，具有长时间或高价值的合同是重要的合同，具有短时间或低价值的合同是一般的合同。在合同管理中也会存在一些问题，有些发生在合同前，有些发生在合同中，有些发生在合同后。合同前的问题可能会是:谈判的用词、不正确的营销实践。合同中的问题可能是:物流服务、合同终止、合同条款、交货和安装、账目或付款。合同后的问题可能是产品质量。企业应当识别不同的合同问题并采取相应的措施。另外，合同拥有许多属性如hasPayment，hasEfficientDate，hasTimePeriod，hasValue，hasDelivery，hasBuyer，hasSeller，hasThirdParty。如何管理这些属性信息，如何定义合同和属性以及不同合同之间的关系是实现有效的合同管理必须解决的问题。

同样，本体成为在共享合同信息中表达语义的技术。OWL在构建合同本体时具有表达语义关系的能力。

(1)一个合同本体的架构

在图9-4中，提出了一个合同本体的架构。^[19]这个本体不可能作为合同管理的标准本体，因为合同本体的标准化依赖于许多组织的合作和努力。在合同管理中，存在许多语义关系需要表达以便机器能够明白和处理。在图9-4的架构中，考虑了OWL的表示功能。

在图9-4中，类用椭圆表达，属性用箱形表达。Contract被定义成一个类，它具有两个子类:Normal_Contract和Important_Contract。9个属性hasPayment，hasEfficientDate，hasTimePeriod，hasValue，hasDelivery，hasBuyer，hasSeller，hasThirdParty，hasProblem的domain都是类Contract。属性hasProblem的range是类Problem，属性hasDelivery的range是类Delivery。4个属性hasAddress，hasDate，hasGoods，hasService的domain是类Delivery。属性hasBuyer的range是类Buyer，属性hasSeller的range是类Seller，属性hasThird Party的range是类ThirdParty。2个属性hasObligation，hasRight的domains是类Buyer，Seller和ThirdParty。类Problem有3个子类: Pre_Contract_Problem，Contract_Phase_Problem，Post_Contract_Problem;类Pre_Contract_Problem有2个子类:Negotiation_of_Terms，Incorrect_Marketing_Practice;类Contract_Phase_Problem有5个子类:Logistic_ Service，Contract_Termination，Contract_Terms，Delivery_and_Installation，Billing_or_Payment;类Post_Contract_Problem有1个子类: Product_Quality。类Value与包含个体Less_Then_One_Hundred_Thousand，More_Than_One_Million，More_Than_One_Hundred_Thousand_ And_Less_Then_One_Million的枚举类相等。

在图9-4中，类Important_Contract具有属性hasValue，该属性通过someValuesFrom限制到个体More_Than_One_Million。类Important_Contract的另一个属性hasTimePeriod通过someValuesFrom限制到“owl:minCardinality=5”。然后，这两个属性限制形成unionOf的布尔运算。

(2)合同本体的OWL源代码

在Protégé-2000环境下，根据图9-4构建了OWL合同本体。下面针对OWL合同本体，结合具体的例子进行分析。

①基于unionOf的属性限制。OWL允许类和属性的任意布尔运算。考虑类Important_Contract，属性hasValue通过someValues-From限制到个体More_Than_One_Million，属性hasTimePeriod通过someValuesFrom限制到“owl:minCardinality=5”，然后，这两个属性限制形成unionOf的布尔运算。可以利用基于unionOf的属性限制来表达这个语义关系，OWL代码如下:

＜owl:Class rdf:about=“#Important_Contract”＞

＜rdfs:subClassOf＞

＜owl:Class＞

　＜owl:unionOf rdf:parseType=“Collection”＞

　　＜owl:Restriction＞

　　　＜owl:onProperty＞

　　　　＜owl:DatatypeProperty rdf:ID=“hasTimePeriod”/＞

　　　＜/owl:onProperty＞

　　　＜owl:minCardinality rdf:datatype=“http://www.w3.org/2001/XMLSchema#int”

　　　＞5＜/owl:minCardinality＞

　　＜/owl:Restriction＞

　　＜owl:Class＞

　　　＜owl:oneOf rdf:parseType=“Collection”＞

　　　　＜Value rdf:ID=“More_Than_One_Million”/＞

　　　＜/owl:oneOf＞

　　＜/owl:Class＞

　＜/owl:unionOf＞

＜/owl:Class＞

＜/rdfs:subClassOf＞

＜owl:disjointWith rdf:resource=“#Normal_Contract”/＞

＜rdfs:subClassOf rdf:resource=“#Contract”/＞

＜/owl:Class＞

②基数限制。在OWL中，基数值可以是任意的非负整数。Important_Contract是指属性hasTimePeriod通过someValuesFrom限制到“owl:minCardinality=5”的合同，代码如下:

＜owl:Restriction＞

　＜owl:onProperty＞

＜owl:DatatypeProperty rdf:ID=“hasTimePeriod”/＞

　＜/owl:onProperty＞

　＜owl:minCardinality rdf:datatype=“http://www.w3.org/2001/ XMLSchema#int”

　＞5＜/owl:minCardinality＞

＜/owl:Restriction＞

③枚举类。在合同本体中，类Value与包含个体Less_Then_One_ Hundred_Thousand，More_Than_One_Million，More_Than_One_ Hundred_Thousand_And_Less_Then_One_Million的枚举类相等，OWL表示如下:

＜owl:Class rdf:ID=“Value”＞

　＜owl:equivalentClass＞

＜owl:Class＞

　＜owl:oneOf rdf:parseType=“Collection”＞

　　＜Value rdf:ID=“Less_Then_One_Hundred_Thousand”/＞

　　＜Value

rdf:ID=“More_Than_One_Hundred_Thousand_and_Less_Than_One_ Million”/＞

　　＜Value rdf:about=“#More_Than_One_Million”/＞

　＜/owl:oneOf＞

＜/owl:Class＞

　＜/owl:equivalentClass＞

＜/owl:Class＞

④类宣布为不相交。在合同本体中，Normal_Contract与Important_Contract不同，可以利用disjointWith来表达这种语义关系，OWL代码如下:

＜owl:Class rdf:ID=“Normal_Contract”＞

　＜owl:disjointWith＞

＜owl:Class rdf:ID=“Important_Contract”/＞

　＜/owl:disjointWith＞

　＜rdfs:subClassOf＞

＜owl:Class rdf:ID=“Contract”/＞

　＜/rdfs:subClassOf＞

＜/owl:Class＞