7.5.3.1本体构建工具Protégé3.4.4
Protégé3.4.4是一个集成的软件工具，可被系统开发者和领域专家用来开发基于知识的系统。用Protégé3.4.4开发的应用可用于特定领域的问题解决和决策。Protégé3.4.4是一个免费的开源平台，作为其核心功能，Protégé3.4.4实施了一套丰富的知识建模结构(knowledge-modeling structures)和动作(actions)，以便支持多种表达形式下的本体的创建、可视化和操纵。Protégé3.4.4可进行个性化设置以友好地支持知识模型的创建和数据输入。更多地，Protégé3.4.4可以通过插件架构和基于Java的应用编程界面(Javabased Application Programming Interface，API)进行扩展以支持基于知识的工具和应用的开发。Protégé-OWL编辑器允许用户构建本体，支持W 3C的Web本体语言OWL。[87]
7.5.3.2本体构建实例——利用OWL构建客户知识管理本体
随着经济全球化和知识经济的到来，企业客户关系管理不断面临新的机遇和挑战。研究和实践证明企业不断满足客户需求的努力是重要的，客户也因此成为企业争夺的重要资源。在全球和数字经济下的客户关系管理(Customer Relationship Management，CRM)迫使企业重新思考它们应该以什么样的方式与越来越广的客户群体构建关系。[88]从某个层面上看，CRM和知识管理(Knowledge Management，KM)实践面向的是相同的目标，即为客户提供持续的产品或服务改善。在知识管理环境下推行客户关系管理被称为是“客户知识管理(Customer Knowledge Management，CKM)”或“知识推动的客户关系管理(know ledge-enabled CRM)”。[89]
客户知识管理旨在管理客户知识从而产生增值的渠道知识以加强关系和协作效率。[90]对于一个企业来说，留住已有的客户并吸引新的客户是CKM的主要内容和目标。每个企业都会拥有不同类型的客户。在CKM中，把握客户行为是重要的。企业应该通过分析客户信息以区分不同类型的客户，识别最有价值的客户，并通过提供个性化的产品和服务来提升客户的忠诚度。[91]
通常，企业通过类似的偏好可以将客户分为多种类型，通过考察每种类型客户群体不同的特征来确定最大利益客户群体。[92]在客户知识管理本体构建中，每类客户可以看成是一个类(class)。客户作为一个整体是一个大类，它有许多子类(subclasses)，如VIP客户(VIP customers)和普通客户(normal customers)。不管是超类(superclass)还是子类，每个类都有自己独特的特征。例如，忠诚的客户可看是客户的子类，特指对本企业产品或服务有特别兴趣并长期使用本企业产品或服务的一类客户。客户下还有更多的子类，如长期的客户(Long-term customers)，高贡献的客户(High contribution customers)，低贡献的客户，低忠诚度的客户，短期的客户，等等，企业应该能够高效地识别不同类型的客户以更好地优化客户关系管理。另外，客户的基本信息如姓名、性别、年龄、单位、联系方式等以及来自客户的反馈等都是CKM中应该特别关注的信息和知识，有效搜集和处理这些有关客户的知识必将推动企业提升竞争优势。然而，如何有效地管理客户知识一直以来都是实施CKM战略面临的一个巨大挑战。在CKM战略实施中，为了使客户知识能够被机器自动地识别和处理，本体越来越多地受到学术界和实践界的关注。与传统的信息和知识共享技术相比，本体能提供更多的语义描述功能，本节将利用OWL构建客户知识管理本体。
(1)客户知识管理本体框架
我们设计了一个客户知识管理本体的框架(图7-3)。我们不期望将此本体作为CKM中的标准本体，因为CKM本体的标准化是一个系统工程，需要依靠来自多个领域的专家的长期协作和努力。在实施CKM战略时，存在很多概念以及这些概念之间的语义关系，这些都需要在构建本体时得到清晰的表达，以便机器能够进行自动的理解和处理。如何将自然语言中的表达转变为形式化描述逻辑中的表达是本体构建中的一个关键任务。[93]在设计CKM本体框架时，我们考虑了OWL所提供的语义表达能力。
OWL类是指包含个体的集合，这些个体用形式化的语言进行描述，以便精确地表达对类成员的需求，OWL的一个关键特征是超类—子类关系可以由推理机进行自动的计算。[94]属性(property)是指个体之间的二元关系，即属性将两个个体链接到一起。在OWL中，属性用来创建限制(restriction)。OWL中的限制分为三个主要类别:量词(Quantifier)限制、基数(Cardinality)限制和值(hasValue)限制。[95]属性可以反向，还可以限制为拥有一个单值，即具有功能性(functional)。个体代表了我们感兴趣领域的对象。[96]
在图7-3中，椭圆表示类，没有标签的箭头表示超类—子类关系。箭头进入的类是超类，箭头离开的类是子类。OWL以属性为中心，每个属性用箭头线上的标签表示。属性将两个类关联起来，对于每个属性，箭头进入的类是属性的值域(range)，箭头离开的类是属性的领域(domain)。根据这个原则，我们画出了本体框架。
图7-3 客户知识管理本体框架示意图
在图7-3中，客户(Customer)被定义为一个类，它有两个子类:VIP_Customer和Normal_Customer，每个子类有三个“someValuesFrom”限制。“someValuesFrom”限制用来描述满足某类限制的匿名(未命名)的类。例如，由“someValuesFrom HighLoyalty”描述的类和由“someValuesFrom HighTerm”描述的类形成了一个交互的类，这个类与由“someValuesFrom HighContribution”描述的类合并形成了一个类，这个新形成的类是类VIP_Customer的超类。同样，我们可以类似地理解图7-3中的类Normal_Customer的含义。
在图7-3中，有8个属性(即hasLoyalty、hasContribution、hasTerm、hasFeedback、hasContact、hasAffiliation、hasIncome、hasName)的领域都是类Customer。同时，这些属性都有自己的值域，例如，属性“hasFeedback”的值域是类“Feedback”。类“Feedback”表达的是来自客户的知识，涉及4类知识:满意度(satisfaction)、报怨(complaint)、期望(expectation)和需求(requirement)。
(2)客户知识管理本体的构建和分析
在Protégé3.4.4环境下，我们构建了基于图7-3的CKM本体。图7-4是在构建CKM本体时的Protégé3.4.4的一个画面的截图，是类VIP_Customer的属性视图。
图7-4 类VIP_Customer的属性视图
OWL本体基于逻辑模型，使得概念得到定义和描述。复杂的概念可以通过简单的概念得以构建，并且逻辑模型允许推理机的使用以便检测是否本体中的所有表达和定义是相互一致的，推理机还能够识别哪个概念符合哪个定义。通过对本体中的所有类运行这类检测，推理机能够计算出本体类的层次，因而能帮助正确地维护层次。[97]
OWL提供丰富的形式化语义词汇，如“disjointWith”、“intersectionOf”、“unionOf”、“complementOf”、“one of”、“minCardinality”、“maxCardinality”、“cardinality”、“someValuesFrom”等，以便表达强大的语义关系和限制。下面，我们将基于几段从CKM本体中抽取的OWL源代码进行语义表达的分析。
①基数限制(Cardinality restrictions)和类的不相交
类可以表示成不相交。在CKM本体中，“Short_Term”是“Term”的子类，这个类在属性“has_Time”上有如下限制:“maxCardinality 5”;“Long_Term”是“Term”的子类，这个类在属性“has_Time”上有如下限制:“minCardinality 5”。类“Short_Term”和“Long_Term”可以表示为不相交。相应的OWL表达如下:
②布尔合并和“hasValue”限制
OWL允许类和属性进行任意的布尔合并。限制“someValuesFrom”是“hasValue”限制类型之一。在CKM本体中，我们对属性“hasLoyalty”、“hasTerm”和“hasContribution”分别定义了“someValuesFrom”限制以便分别创建一个新类。新创建的类通过交互(intersectionOf)和联合(unionOf)进行合并。我们在前面对VIP_Custome类的含义进行了解释，它的OWL表达如下，从中我们可以看到OWL的强大的语义表达能力。
(www.xing528.com)
③枚举类
类可以通过枚举所有的个体来进行描述，类的成员正是枚举出来的个体的集合。在CKM本体中，“Type”是一个枚举类，它的个体是:“Product_Quality”，“Post_Sale_Service”，“Attitude”，“Logistic_Service”。相应的OWL表达如下:
＜owl:Class rdf:ID=＂Type＂＞
＜owl:equivalentClass＞
④定义属性
OWL是一个以属性为中心的本体语言，每个属性都有自己的领域和值域。在CKM本体中，我们定义了一个对象属性“hasType”，“hasType”的领域是由“Complaint”和“Satisfaction”联合运算后得到的类，它的值域是“type”，我们在前面刚刚讨论过这个枚举类。相应的OWL表达如下:
7.5.3.3本体的维护和管理
语义Web本体构建是一项复杂的工程，构建好的本体还需要得到良好的维护和管理。
(1)成本问题
在领域知识中，有些概念比其他的概念更持久，但必须意识到它们不可能永远不变。例如，用来对医学病毒进行分类的词汇在新的过程和知识出现时会发生变化。因此，需要将本体看成是动态的结构。一些本体可能持续的时间长一些，如描述周期表元素的词汇;一些本体可能容易变动，如新兴和边缘学科中出现的词汇。社会和实践总在以一种复杂的微小的方式不断地改变着规范、概念和术语。在本体开发中，不应当感到奇怪或抵触这种变化。在这种环境下创建的本体应当知道什么时候需要进行修改。因此，本体开发和维护的成本是一个不可回避的问题。
在一些领域，成本不管多大都将容易得到补偿。例如，本体在结构良好的领域如科学应用中，不仅功能强大而且是一种基本的工具。在某些商业应用中，通过使用结构良好的和协调的词汇规范所获得的潜在利益和产出将远远超过开发本体的成本和成本维护的边际成本。
事实上，在Web不规则的状态下，当本体的用户群增加时，这些成本可得到降低。如果假设将本体创建成本分摊给用户，则所需要的本体工程师数量以用户数量的对数函数增加，创建时间以工程师数量的平方增加。对一个基本模型来说，这些假设是单纯但可行的。结果是，为大量用户创建本体时包含在每个用户里的努力以非常快的速度变得非常小。[98]
(2)本体的特征分析
并非所有的本体具有同样的特征。通常，人们能够区分出深本体(deep ontologies)和浅本体(shallow ontologies)。深本体是那些在科学和工程中遇到的本体，这需要很大的努力才能开发出概念间的关系。对于蛋白质和医学这样的领域，本体对数据非常敏感，当利用本体对复杂的构成某些对象的属性集进行分类时，这会变得更加明显。浅本体包含相对较少的交换词汇，这些词汇可以组织大量的数据，例如，在银行和金融环境下使用的客户、账号、透支等。浅本体能够提供大量可重用的数据，并只需要简单的词汇和关系。[99]
深本体的复杂性使得一些人避开本体而使用另一种称为标记(tagging)的方法。它们代表一种当个人管理自己的信息需求时有机出现的结构。当大量的人对特定信息感兴趣并被鼓励着描述这个信息——或标记它(他们可以自己进行标记以便组织自己的内容检索，或无私地帮助他人)时，大众中产生了大量的结构。不采用集中形式的分类，用户可以为文档或其他信息源分配关键词。
著名的使用和开发标记的应用有图像发布和共享站点Flickr[100]和共享书签的站点del.icio.us。[101]这些应用从下到上，起源于非中央机构，有时称为Web2.0或社会软件(social software)。
在Web规模上进行标记当然是一个有趣的发展。它提供了一种潜在的元数据源。民间产生了大量的关键词检索，它们是在信息检索努力中的一种新现象，但这些民间的东西不同于本体，它们服务于不同的目的。本体的目的在于仔细地描述数据世界的部分，允许不同格式中的数据间的映射和交互。本体根据URIs进行参照，标记使用单词。本体通过一种仔细的、清晰的、努力消除模糊不清的过程得到描述。标记的定义是一种松散的、不清晰的过程，其中存在一些模糊不清。本体上使用的推理过程是基于逻辑的，利用了诸如join的运算。标记上使用的推理过程是统计，并使用了诸如聚类的技术。[102]
这并不意味着标记将永远替代浅本体。在本体需求存在的地方，轻量级但强有力的本体已经出现并得到广泛的使用。例如，Friend-of-a-Friend[103]，以及合作应用如Flink。[104]这符合语义Web技术和开发Web自组织技术的双重和补充发展的需求。
一些人认为本体是从上而下的强制的创建，与人们的实践、某领域的潜在任务或环境运行不关联，或仅仅一段时间内相关联。这种想法与开发一个单一的一致的涉及所有事物的本体相关，例如Cyc。[105]这种大范围的，包括所有事物的本体或许存在有趣的应用，但是它的应用无法得到实施。事实上，可以开发出不同领域的独立的本体。
本体是为了促进实际数据共享实践的合理化。本体是一种手段，以便在兴趣领域间共享含义，任何人能够使用这些本体来描述自己的数据，能够扩展或重用某个本体的元素。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
