Long Way Studio
文章
三年了，终于想起密码了
本体进化的技术发展水平
本体进化的定义
Ontology Evolution is the timely adaptation of an ontology to the arisen changes and the consistent propagation of these changes to dependent artifacts.
本体工程术语
1. 本体管理
本体管理系统是用于创建、修改、版本化、查询和存储本体的框架。
2. 本体修改
不考虑一致性的本体的变化。
3. 本体进化
考虑一致性的本体修改。
4. 本体版本
通过创建和管理不同的本体版本来处理本体的变化。通过管理一致性而不丢失数据。管理本体版本间的兼容性和映射关系。
本体进化过程
1. 变化的捕捉
从明确的需求中或从变化发现方法的结果中捕捉变化。变化发现方法能够从数据中推导出变化。从需求中捕捉变化的方法是自顶向下的，否则是从底向上的。
a) 结构驱动的变化发现：根据本体结构推导。
b) 使用驱动的变化发现：根据使用模式推导。
c) 数据驱动的变化发现：根据数据变化推导。可以使用数据挖掘和形式概念分析等技术。
2. 变化的表示
为给定的本体模型定义变化的表示。根据不同的粒度表示成原子变化和复杂变化。也可以用本体来表示这种变化（被称为本体变化的本体）。
3. 变化的语义
变化对本体的影响，如一致性等。一致性可以表示成约束（也称不变式），也可以用模型理论来定义（如描述逻辑）。
一致性：和对应的本体模型相关。有对OWL DL中一致性约束的非形式化定义，也有使用描述逻辑的形式化定义。
4. 变化的实现
a) 变化通知：将变化的结果通知给本体工程师。
b) 变化应用：应用所有的变化，具有事务处理的特征（原子性、一致性、独立性和持久性）。
c) 变化日志：跟踪变化的执行。
5. 变化的传播
由于依赖性而产生的，本体变化对依赖于它的本体、实例和应用程序的影响。
a) 依赖本体一致性：比较了基于推(Push-based)的技术和基于拉(Pull-based)的技术应用于同步依赖本体时的异同。针对单结点的依赖本体，提出了基于推技术的依赖本体进化算法。
b) 复制本体一致性：针对多结点的依赖本体，提出了基于拉技术的依赖本体进化算法。
c) 模块化和分布式本体的进化：将本体模块用连接查询连接起来，使用知识编译方法实现模块间的无关性。每个映射查询被离线计算并表示成使用该查询的本体的公理。只要被查询本体模块的概念层次不变，则推理的正确性不变。提供了受概念层次影响的启发式变化检测机制。
6. 变化的确认
对变化的判断，以便避免变化产生的负面影响，如：
a) 因本体工程师对变化影响的误解而执行了不该执行的变化。
b) 对本体的实验性的变化。
c) 合作开发时，不同本体工程师对本体所需变化的不同想法。
现存的工具
1. CVS
可以作为本体版本管理系统的指导。
2. 本体编辑器
a) Protégé：知识模型与OKBC兼容。插件式结构。
b) OntoEdit：内部本体模型，语言无关。支持基于F-Logic的推理引擎Ontobroker。支持一些组合变化（如copy）。可以得到引起变化的数量信息。
c) OilED：支持OIL和OWL。可以使用FaCT推理机执行一致性检查和自动分类。有活动日志，但只记录推理机的活动。
3. KAON中的本体进化
a) 进化日志：暂时不能用于分布式本体进化。
b) Undo/Redo
c) 进化策略：保持进化结果的一致性，允许自定义策略。
d) 进化图：允许用户用自定义的变化增强一组变化。
e) 本体包含工具和本体复制工具
f) 变化发现：发现本体的问题，提出解决的建议。
g) 使用日志：便于发现用户的需要。
4. OntoView
a) 读入变化和本体
b) 识别本体
c) 在概念层比较本体
d) 分析变化的影响
e) 导出变化
5. OntoManager
6. TextToOnto
未来的工作
1. 语言无关的本体进化：用声明式的方法建模本体变化的各个方面。
2. 需求说明：用声明式语言描述变化。允许在同一个框架内表示变化和约束，并在它们之间进行推理。可以是本体查询语言的一种扩展。
3. 本体依赖：本体依赖的形式有本体映射、本体合并、本体对齐和本体集成。可以考虑一种元本体，如映射本体：(1)一致性约束需要考虑映射本体的语义(2)应用于映射的变化将更复杂(3)源和目的本体的概念和属性将成为映射本体的实例。
本体进化：和schema进化不同
Natalya F. Noy1 and Michel Klein2
1Stanford Medical Informatics
Stanford University
Stanford, CA, 94305
noy@smi.stanford.edu
2Vrije University Amsterdam
De Boelelaan 1081a
1081 HV Amsterdam, The Netherlands
michel.klein@cs.vu.nl
本体进化和数据库schema进化有相同也有不同。本文分析了这些不同，并指出了一些研究方向。
本体和数据库schema间的不同
1. 本体也是数据
本体可以看作是知识库的schema，因此和schema进化一样，目的是保持数据的完整性。但是，本体也是数据，建立在本体上的查询也可以返回本体，因此，还需要考虑进化对这种查询的影响。
2. 本体中混合了语义
数据库schema中没有显式的语义，因此需要在进化框架中包含解决进化所带来的约束冲突的协议，而本体本身混合了语义，所以进化框架中不需要协议，用推理机可以对变化的本体重新分类。
3. 本体更经常被重用
数据库schema一般不被重用，不在本系统之外使用。而本体则相反。
4. 本体通常是分布的
数据库schema开发是集中式的，本体是分布的合作式开发。
5. 本体的数据模型更丰富
即使和面向对象数据库的schema比，本体也要丰富得多：基数、反属性、传递属性、互斥类、求并、求交、枚举等。因此对本体变化的处理将更困难。
6. 类和实例可以相同
数据库中shcema和实例是明确区分的。本体和实例则很难区分，如元类（其实例是类）的引入。因此不能只考虑变化对实例的影响。
本体版本和本体进化是变化管理
schema进化：改变了schema而没有丢失数据（用新的schema访问所有的（旧的和新的）数据）。
schema版本：用不同版本的接口访问所有数据。
对本体来说，进化和版本是很难区别的。
本体兼容性是多维的
1. 保留实例数据：版本转换没有丢失任何数据。
2. 保留本体：使用新版本得到的查询结果是使用旧版本的相同查询所得到的结果的超集。
3. 保留因果关系：如果本体被作为公理的集合，则能从旧版本中推出的事实仍然能从新版本中推出。
未来的工作
1. 维护所有版本的本体，根据需要保留的内容定义兼容性的维，在不进行跟踪的情况下找到不同版本间的不同。
2. 定义本体变化操作的集合，分析这些操作的影响。
3. 精确地描述数据或本体的转换，实现可转换的变化。
4. 识别变化。
5. 过期的本体处理。
6. 自动查找本体不同版本间不同的算法。
本体进化方法
摘自：OntoWeb. D1.4. A survey on methodologies for developing, maintaining, evaluating and reengineering ontologies IST-2001-29243。是关于本体进化方面比较详细的描述。
本体进化：本体的适时的调整和变化一致性的传播。
本体变化的影响：
(1) 同一个本体的其它部分；
(2) 实例；
(3) 依赖该本体的本体；
(4) 应用程序。
同本体进化类似的数据库模式的进化已经被广泛地研究了，可以作为参考。
本体进化过程：
1、 发现
由于本体中可能有冗余的实体，及多人开发导致的本体的混乱，因此本体可以被精化和重构。——和软件重构有类似吗？
1.1 结构驱动：分析本体结构的启发式方法。如，所有子概念都有相同的属性，则该属性应该放到父概念中。
1.2 数据驱动：分析数据的启发式方法。如，所有概念C的实例都没有用到C定义的属性，而只用了其父概念的属性，则C可能没有存在的意义了。
1.3 使用驱动：分析知识管理中用户的行为的启发方法。如，跟踪通过查询得到概念的过程来发现一些新概念。
2、 表示法
变化表示的粒度。粒度太小易引起不必要的变化及影响，提出了使用组合变化的粗粒度表示方法。
3、 变化的语义
变化会产生语法不一致和语义不一致。本体变化最终要达到一个一致的状态。
3.1 语法不一致：本体和实例中存在无定义的实体或本体模型约束无效。
3.2 语义不一致：本体实体的意义改变了。
4、 实现
在进化之前，将变化的含义提供给用户，作为是否执行变化的参考。提供事务服务器实现多个改变的同时执行。
5、 传播
将变化影响（四个方面的影响）进行传播，可以递归地进行，需要保证语法一致性和语义一致性。
6、 验证
将本体和领域问题及需求说明进行比较验证，使用进化日志提供undo功能。
Web中的本体版本和变化检测
Michel Klein1, Dieter Fensel1, Atanas Kiryakov2, and Damyan Ognyanov2
1 Vrije Universiteit Amsterdam
De Boelelaan 1081a, 1081 HV Amsterdam, the Netherlands
fmichel.klein|dieterg@cs.vu.nl
2 OntoText Lab., Sirma AI Ltd.
38A Hristo Botev blvd., Sofia 1000, Bulgaria
fnaso|damyang@sirma.bg
在分析了本体版本间的关系的特点及如何识别在线本体的问题后，设计了一套基于Web的本体变化管理系统，能够保持本体版本间的转换和概念关系，允许比较本体版本间的不同，并声明概念关系。可以将版本间的区别可视化，支持可适应的基于规则的发现和分类变化的机制。
一、版本关系的特点
1、 版本关系和概念关系是不同的
变化产生了一个新的本体及两个版本间的版本关系。
版本关系：
1) 转换（真实变化）：两个版本间的变化，如属性约束变化、加入类、删除属性等；
2) 概念关系：两个版本间的关系，如等价关系、归约关系、逻辑规则等；
3) 元数据：描述如时间、作者、意图等内容。
4) 范围：描述更新可用的上下文，如可用的时间等。
2、 说明上的变化和概念上的变化可能有区别
本体是概念的说明。但说明的变化不一定引起概念的变化。
概念变化：产生了不同的本体概念或概念间的关系。
说明变化：和概念相关的变化，但没有改变概念本身。
自动判定一个变化是概念变化还是说明变化是不可能的（据说已经被本体工程领域所证明了）。但是可以启发式地得到变化的影响。
3、 变化的包装
1) 包装表达的粒度：单独定义、整个文件或全部本体。
2) 包装表达的方法：转换说明、替换说明或映射。
二、OntoView
1、 读入变化和本体：用户导入本体，说明版本的元数据。未来将提供转换、映射和修改时的变化的生成。
2、 识别：用URI。
3、 分析变化的影响：只能识别直接影响，未来将提供影响传播分析，使用推理机自动验证变化并说明版本间的概念关系。
4、 导出变化：将本体版本间的概念关系单独作为映射本体输出，以便使用新版本时可以回退到旧版本。未来还将提供转换描述的输出。
三、本体的比较
是一种结构比较。
1、 变化类型：非逻辑变化、逻辑定义变化、标识变化、加入定义和删除定义。
2、 变化检测：将本体分解成三元组<subject, predicate, object>形式，将这种形式的三元组集合表示成图，为每种变化都定义一种规则描述，通过规则比较版本间的变化（类似图比较）。由于类型有继承关系，因此计算类型时，需要传递闭包。
3、 描述概念变化：用hasParent1.1 subPropertyOf hasParent1.3形式表示，复杂的情况（如删除，分拆概念，替换等）作为未来考虑的内容。
一个Java变化影响分析原型工具
Xiaoxia Ren1, Fenil Shah2, Frank Tip3, Barbara G. Ryder1, Ophelia Chesley1y, and Julian Dolby3
Division of Computer and Information Sciences1 IBM Software Group2 IBM T.J. Watson Research Center3
Rutgers University 17 Skyline Drive P.O. Box 704
110 Frelinghuysen Road Hawthorne, NY 10532, USA Yorktown Heights, NY 10598, USA
Piscataway, NJ 08854-8019, USA fenils@us.ibm.com fftip,dolbyg@us.ibm.com
fxren,ryder,ochesleyg@cs.rutgers.edu
本文基于Eclipse实现了一个Java变化影响分析原型工具—Chianti，用它对一个实际项目的两个版本进行分析，将变化分解成一系列原子变化，得到的分析结果表明，变化影响分析对程序理解和调试都是非常有好处的。
面向对象语言比面向过程语言的变化影响分析更难处理，原因在于非局部的变化影响，C语言（除函数指针外）都很容易分析。
1、引言
变化影响分析：用于判定源代码修改所产生影响的技术的总称。
用途：(1)便于程序员通过观察变化影响分析的结果选择不同的修改方案；(2)减少单元测试和回归测试的工作；(3)减少调试的工作。
2、原子变化及依赖
原子变化的分类
(1) AC加入一个空类
(2) DC删除一个空类
(3) AM加入一个空方法
(4) DM删除一个空方法
(5) CM改变方法的体
(6) LC改变虚方法的查找
(7) AF加入一个域
(8) DF删除一个域
(9) AI加入一个空的初始化
(10)DI删除一个空的初始化
(11)CI改变一个初始化的定义
(12)CF改变一个域的初始化的定义
需要求出原子变化的部分序的传递闭包，以实现安全的变化序列。
3、实现（略）
4、评估（略）
5、相关工作
(1) 静态影响分析技术
调用图的可达性分析：不严格、不充分。
用对象关系图中类的关系分类变化，用传递闭包判定影响分析。（本文的基础）
对变量相关概念格的查询，没有有效性的评估。
用类型推理，检查语义保持，只能实现某些类型的变化影响分析。
(2) 动态影响分析技术
用前向静态切片和回归分析进行分析，有一些情况没有考虑。
基于调用栈的动态分析，相当于一种精化的静态分析。
用字节搜索方式，将变化分解，不考虑程序的结构。
(3) 有选择的回归测试
模块级的覆盖
语句级的覆盖
基于程序依赖图和程序切片的粒度的覆盖。
基于启发式的回归测试
(4) 其它
配置管理中对模块访问冲突的检测
通过重用契约检测重用时的一致性问题。
模型转换的分类学及其在图转换中的应用
Tom Mens1 and Pieter Van Gorp2
1 Software Engineering Lab, Universit'e de Mons-Hainaut
Av. du champ de Mars 6, 7000 Mons, Belgium
tom.mens@umh.ac.be
2 Formal Techniques in Software Engineering, Universiteit Antwerpen
Middelheimlaan 1, 2020 Antwerpen, Belgium
pieter.vangorp@ua.ac.be
提出了许多和模型转换相关的分类学概念，对模型转换工具的选择和开发具有很大的指导作用。本文还以图转换为例，分析了提出的分类学概念，对三种工具作了比较。
本分类学是基于Dagstuhl seminar on Language Engineering for Model-Driven Software Development中一个工作组的讨论结果。
1. 什么需要被转换成什么？
源和目标模型的数目：多源模型如模型合并，多目标模型如MDA中的PSM的生成。
技术空间：技术空间是受元-元模型决定的，如XML技术空间使用XML Schema作为元-元模型，MDA技术空间使用MOF作为元-元模型。需要导入导出工具在不同技术空间中建立连接。
内生性和外生性转换：内生性转换是指用相同语言描述的模型间的转换。外生性转换则相反。内生性转换有：优化、重构、简化和范化。外生性转换有：综合、反向工程和迁移。内生性转换中源和目标模型是同一种模型的称为in-place，否则称为out-place。外生性转换都是out-place。
水平和垂直转换：水平垂直转换中源和目标模型是相同抽象级别的。垂直转换则不同。水平转换例如重构和合并。垂直转换例如细化。
2. 模型转换的重要特征
自动化的级别：转换的复杂性：不同复杂程序的转换可能应用不同的技术和工具。
保存：如重构保存了行为，但改变了结构。细化则保存了程序的正确性。
3. 转换语言或工具的成功准则
创建、读取、修改和删除转换的能力：转换工具可以不支持新的功能的添加。
决定什么时候应用转换的能力：转换可以应用的上下文的描述。
定制和重用转换的能力：校验和保证转换正确性的能力：语法正确和语义正确，可终止及结果的一致性也属于语义正确。
测试和验证转换的能力：应用系统测试和验证技术。
处理不完全和不一致模型的能力：检测、修改转换甚至模型的不一致性(如系统设计初期模型的不完全、不一致或二义性)。
分组、组合和分解转换的能力：增强转换的可读性、模型化和可维护性。
指定通用和高阶转换的能力：转换也是模型，也可以被转换。
指定双向转换的能力：
支持跟踪和修改传播：在源和目标模型间建立连接，同步源和目标模型的修改。
4. 转换语言或工具的质量需求
可用性和有用性：
冗长和简洁：需要简洁的语言，但可能造成复杂转换定义时的大量工作。需要在简洁和冗长间找到平衡点。
性能和可伸缩性：
可扩展性：提供插件方式。
数学属性：数学基础可以用于证明可终止、可靠、完备、语法和语义正确性等。
用户接受程度：面向对象可能比逻辑式或函数式更容易接受。
标准化：支持XML、MOF、UML、XMI等标准。
5. 用于模型转换的机制？
声明的：
函数式程序设计，符合转换的特点，是first class，但不容易维护状态。
逻辑式程序设计，回溯，约束传播及合一方便了转换。逻辑语言自带查询机制，不需要额外定义。
操作的(命令的)：
过程式程序设计。
面向对象程序设计。
图转换
比较了AGG、Fujaba和VIATRA。其中VIATRA表现较好。
MOF元建模架构中的模型转换语言
Ivan Kurtev, Klaas van den Berg
Software Engineering Group, University of Twente
P.O. Box 217, 7500 AE, Enschede, the Netherlands
{kurtev, vdberg}@cs.utwente.nl
MOF架构下现有的模型转换语言都是用于特定情况下的，没有通用性。本文分析了其中的原因：MOF中没有对实例化和泛化的显式描述，导致转换语言和实例化机制的紧密耦合。本文用一系列函数表示了不同的实例化和泛化机制，从而实现了可以用于任意层模型间转换的通用语言。
可以理解为提供一种方法将实例化和泛化机制作为转换语言的插件，从而保证了语言的通用性。
MOF架构下的四种转换情况
1、在M2层定义转换，在M1层执行转换。
2、在M1层定义转换，在M0层执行转换。
3、在M2层定义转换，在M1层进行schema compilation，在M0层进行unmarshaling。
4、层间转换。
模型元素实例化的通用模型
模型元素实例化的通用模型
提供了独立于MOF任何层之上的模型元素的通用模型，包括ModelElement、Slot和Literal。
1、ModelElement
父类：无
属性：无
关联：
slot: Slot [1..*] 和Slot:_ModelElement相对。
_Slot: Slot[*] 和Slot:value相对。
2、Literal：
父类：ModelElement
属性：value: Any
关联：无
3、Slot
父类：无
属性：name: Any
关联：
value: ModelElement [0..*]
_ModelElement: ModelElement [1] 和ModelElement:slot相对。
该模型独立于MOF架构，可用RDF或集合关系等表示。任意MOF架构的模型的实例化关系可用该模型表示。
基于通用模型的四种操作函数
1、selection: 选择元模型元素。
2、instantiating: 生成子模型元素。
3、reading: 读元素的属性。
4、setting: 写元素的属性。
转换语言
1、转换说明：基于源和目的元模型，源元模型的配置，目的元模型的配置，通过转换引擎来执行。其中配置指某个模型特定的四种操作函数。
2、转换引擎：输入源模型，源和目的元模型，源元模型的配置，目的元模型的配置，输出目的模型。
MOF 2.0 QVT提案(二次修订版，2004)
本提案是由DSTC、IBM和CBOP共同提交到OMG的。是MDA模型转换标准的提案。
三个特点：表达能力强、语义定义良好、完全自动化
OMG的强制需求：
MOF相容库的查询语言是转换语言的子集。基于MOF2.0核心。转换是自动的。转换和视图的唯一不同是目标扩展对源扩展的依赖性不同。转换定义是声明性的，从F-logic中得到灵感。
OMG的可选需求：
部分可以支持双向转换。可以支持可跟踪性，但会引入大量跟踪信息。转换模型可以定义模式、模式的扩展和转换规则的扩展及重写。可以定义转换的转换。支持带附属数据的转换的参数化。不支持一些特定的源和目标。
需要考虑的问题
基于CMW转换模型。和UML活动语义不兼容。非良性定义的输入会导致非良性的输出，而良性定义的输入也可以导致输入无意义。允许在转换规则中加入前置条件。无法保证目标的良性定义，需要MOF2.0相应标准的完善。视图中目标是依赖于源的，因此一个描述源的改变的模型，对源的以改变又会影响目标。
评估准则
支持复杂的转换：图灵完备的，清晰和声明性的。可重用转换：支持模式（也叫查询）、模式的扩展、转换规则的扩展和重写及转换的组合。可扩展的转换定义：转换包的概念，支持导入、扩展、重用和组合等。
三者关系
查询选择已经存在的对象，转换描述了如何从已经存在的对象生成新对象，在转换时，如果选择保持输入和输出间的连接，则为视图。
版本管理
基于转换的更新问题，即MOF 2.0版本管理问题由MOF相应标准来完成。
功能需求
通过类型匹配元素或元素的组。通过关联、属性值和其它上下文过滤匹配的元素集合。将单元素规则叠代地应用于集合元素。建立源和目标模型元素间的关联。排序约束。对无序的多值属性或关联连接也定义稳定的全排序。处理递归定义的问题。匹配和创建不同元级的元素。支持多源和多目标。
可用性需求
无关规则应用次序无关。隐式创建目标对象。多目标元素可由单规则定义。单目标元素可由多规则定义。允许只处理元素集合的转换规则。规则可以被分组。可定义转换模式，以支持模块的转换定义。显式无缝地在转换模型中嵌入条件和表达式。可以容易地处理可选属性。可以用多种风格书写转换。转换是可组合的。规则可以是多向的。
转换的风格
源驱动：适于树型源，不适于图型源。目标驱动：适于逆向工程或性能优化。方面驱动：基于语义概念。(有AOP的思想)。
未来的工作
多向转换。转换的组合。唯一对象选择。规则和跟踪类的紧密示例耦合。
DSTC的本体定义元模型提案(一次修定版2004-08-18)
本文是从DSTC提交到OMG(对象管理组织)的本体定义元模型(ODM)的提案（一次修定版）中摘录的。相对前面的最初版提案有了很大的丰富，将多种本体相关的元模型进行了详细地划分和描述。比较最初的提案，本提案不再将UML简表(Profile)作为解决方案，而是将MOF相关的一系列工具和方法（QVT等）作为一个整体解决方案，从中我们也可以看出本体定义元模型的发展过程和趋势。
OMG对ODM的需求
1)强制需求
不变。
2)可选需求
不变。
3)相关问题
在ODM和OWL间映射名字的策略。UML中不支持OWL的属性。叠代开发和QVT中的往返工程相关。仅使用UML简表(Profile)是不够的，还需要MOF库生成器、XMI生成器、HUTN生成器和QVT工具。CWM中的商务术语可以作为领域本体的一种。
4)评价标准
紧凑和清晰。映射区域的扩展（OWL可映射到ODM，反之则不行）。ODM的表达能力（比OWL强）。
在OWL但不在UML中的特性
1、谓词定义语言：intersectionOf, unionOf, complementOf, hasValue。
2、名字：唯一名字假设，allDifferent, sameAs, differentFrom, equivalentClass, equivalentProperty。
3、Semantic Web Rule Language和OWL services。
在UML但不在OWL中的特性
1、行为特性：operations, responsibilities, static operations, interface classes, abstract classes, qualified associations。
2、复杂对象：composition, aggregation, composite structures, ports, connectors, collaboration, reference object, value objects, template。
3、访问控制：read-only, public, private, protected。
4、关键词：如<<interface>>。
ODM中的映射关系
1、UML <-> DL：UML和描述逻辑间的映射。
2、RDFS + OWL <-> DL：RDFS及OWL和描述逻辑间的映射。
3、SCL <- DL：DL到简单公共逻辑的转换，由于SCL比DL能力强，所以只能单向转换。
4、ER <-> DL：实体关系模型和描述逻辑间的映射。
5、TM <->DL：Topic Maps到描述逻辑间的映射。
ODM中的元模型
1、描述逻辑元模型
2、RDF Schema元模型
3、OWL元模型
4、简单公共逻辑元模型
5、关系实体元模型
6、Topic Maps元模型