(1)配置规则表达
产品服务的模块配置过程可以看作是在配置规则作用下对所有状态集合的搜索过程[25]。本章的配置过程基于上一章节中顾客需求本体的表达。
配置规则的形式化表达采用通用的关联规则表达方法:
in产品服务族(F):if(X=x),then(Y=y) (4-20)
其中“in产品服务族(F)”表示该规则只在同一产品族内有效,X表达顾客需求本体,Y表达服务包及服务流本体,故配置规则的本体表达:
由于OWL语言无法表达产生式的规则知识,因此采用SWRL语言表达配置规则本体。
(2)配置规则特性
1)规则的传递性。若有规则R1(if(A=a1),then(B=b2)),R2(if(B=b2),then(C=c1)),则规则存在传递性:
2)规则的可逆性。若有规则R1(if(A=a1),then(B≠b2)),则存在逆向规则R2:
R2(if(B≠b2),then(A=a1)) (4-23)
3)规则的组合型。若有规则R1(if(A=a1),then(B=b2))和R2(if(C=c3),then(B=b2)),则规则会对A=a1和C=c3之间会相互产生影响:(www.xing528.com)
in(F1):if(A=a1),then(B≠b2)→if(B=b2),then(A≠a1) (4-24)
4)规则的不矛盾性。同一配置方案内,不能自相矛盾:
同理,在传递过程中,也不能存在自相矛盾。
假设存在配置规则R1(if(A=a1),then(B=b2)),R2(if(B=b2),then(C=c2)),R3(if(C=c2),then(D=d2)),…,Ri(if(X=x2),then(W=w2)),则:
5)规则的互补性。
假设存在配置规则R1(if(A=a1),then(B=b1)),R2(if(A=a1),then(B=b2)),R3(if(A=a1),then(B=b3)),R4(if(A=a1),then(B≠b4))则:
(3)配置规则构造
面向工业产品服务的配置规则随着服务业务的不同而呈现出完全不同的规则内容,原因在于配置规则是一种反映服务业务内部概念关系及映射关系的基本定理,是一种可以推理和演绎的知识规范。这里的配置规则主要包括服务功能模块配置规则和服务流程模块配置规则,两种规则在制定时不予区分,仅在调用时,依据配置对象来选择。配置规则的来源是多样化的,比如通过服务历史数据的挖掘、服务模块间的约束关系、服务业务的商务逻辑以及服务工程师的知识累积等。
配置规则的表达可以采用SWRL(Semantic Web Rule Language)语言。SWRL可以有效地把服务配置规则标准化并以语义的方式表达出来,便于配置过程的推理。同时,借助SWRLTab插件,可以在Protégé中把配置规则转化为SWRL语言的形式。然而,Protégé的推理能力较弱,这里采用了最容易与Protégé结合的JESS(Java Expert System Shell)推理机来完成配置知识的推理。
免责声明:以上内容源自网络,版权归原作者所有,如有侵犯您的原创版权请告知,我们将尽快删除相关内容。