下载文档原格式
西⽠书课后习题——第⼆章2.1数据集包含500正例和500反例，按照70%的⽐例划分训练集和验证集，则验证集需要有150个正例、150个反例，则共有C1505002种划分⽅式。
2.2数据集包含100个样本，10折交叉验证时，每个训练集应该有45正例、45反例，验证集应该有5正例、5反例，由于训练集中正例、反例⽐例为1:1，则按照题⽬的预测算法，预测时会进⾏随机预测（因为训练样本数⽐例相同），所以错误率的期望为50%留⼀法时，留下来做验证集的样本有两种情况：正例、反例。
当留下来的是正例时，训练集中反例⽐正例多⼀个，按照题⽬的算法会将验证集预测为反例，预测错误；留下来的是反例时同理，会将验证集预测为正例。
所以错误率的期望为100%2.3F1的⼤⼩与BEP的⼤⼩没有明确的关系。
根据公式F1=2∗P∗RP+R，⽽BEP是查准率和查全率相等的点，即BEP=P=R，带⼊前式有F1=2∗P∗RP+R=2∗P∗PP+P=P=BEP，可以认为F1=BEP吗？显然不可以。
可以构造反例进⾏验证，容易构造BEP相同的两个分类器的F1值并不相同，分类器将所有训练样本按⾃⼰认为是正例的概率排序，排在越前⾯分类器更可能将它判断为正例。
按顺序逐个把样本标记为正，当查准率与查全率相等时，BEP=P=R。
当然分类器的真实输出是在这个序列中的选择⼀个位置，前⾯的标记为正，后⾯的标记为负，这时的查准率与查全率⽤来计算F1值。
可以看出有同样的BEP值的两个分类器在不同位置截断可能有不同的F1值，F1的⼤⼩与BEP的⼤⼩没有明确的关系。
2.4查全率：真正的正例被预测为正例的⽐率真正例率：真正的正例被预测为正例的⽐率显然查全率=真正例率查准率：预测的正例中真正的正例所占的⽐率假正例率：真正的反例被预测为正例的⽐率查准率与假正例率没有数值上的关系2.52.6ROC2.7参考图2.5由定义可以知道TPR与FPR都是由0上升到1，那么FNR则是由1下降到0。
多变量时间序列的聚类、相似查询与异常检测的开题报告一、研究背景和意义多变量时间序列数据是指由多个时间序列组成的数据结构，它广泛应用于金融、医疗、环境、交通等众多领域。
在实际应用中，对于多变量时间序列数据的分析，通常需要先将其进行聚类、相似查询和异常检测等处理。
聚类可以将相似的时间序列分组，简化数据分析的复杂度；相似查询可以在数据库中快速搜索与查询目标时间序列相似的时间序列；异常检测可以发现在多变量时间序列数据中的异常点或异常模式，为用户提供有价值的信息。
二、研究内容本研究将聚焦于多变量时间序列数据的聚类、相似查询和异常检测三个方面，包括以下内容：1.多变量时间序列聚类多变量时间序列聚类可以帮助用户对相似的时间序列进行分类，从而简化数据分析的复杂度。
针对多变量时间序列聚类的问题，本研究将研究多个聚类算法，包括基于距离的层次聚类、划分聚类和基于密度的聚类算法等，并比较它们的聚类效果。
2.多变量时间序列相似查询多变量时间序列相似查询是指在数据库中快速查询与目标时间序列相似的时间序列。
本研究将研究多个时间序列相似度度量方法，并针对多变量时间序列数据的特点设计相应的相似度计算方法，同时研究相应的索引结构和查询算法。
3.多变量时间序列异常检测多变量时间序列异常检测是指发现在多变量时间序列数据中的异常点或异常模式。
本研究将针对多变量时间序列数据的特点，设计相应的异常检测算法，比较其效果，并在实际应用中进行验证。
三、研究方法本研究将采用以下研究方法：1.问题分析和需求分析首先对多变量时间序列数据处理中的聚类、相似查询和异常检测问题进行分析，确定其目标和需求。
2.算法设计和实现根据需求，设计聚类算法、相似查询算法和异常检测算法，并进行实现。
3.实验验证和比较在多个数据集上进行实验验证，比较不同算法的效果和性能。
四、预期结果通过本研究，预期可以达到以下结果：1.提出一系列针对多变量时间序列数据处理的聚类、相似查询和异常检测算法，并实现相应的软件工具。
多模态逻辑的研究动因及意义论文多模态逻辑的研究动因及意义论文传统模态逻辑多为单模态逻辑，即在同一系统内只考虑一种模态算子(如时间、知识、程序等)，很少尝试着在同一模态系统内同时考虑多种模态算子。
而随着模态逻辑在人工智能、计算科学等领域的发展，人们开始思考这样的问题:是否可以在同一逻辑系统内处理必然、时间、知识、义务、程序等多种模态算子?基于这样的考虑，逻辑学家开始尝试构造多模态逻辑系统。
多模态逻辑系统是指包含两种或两种以上模态算子的模态逻辑系统，并且模态算子之间不可规约。
本文拟从多模态逻辑的产生背景、研究动因、概念界定出发，阐明研究多模态逻辑的理论和现实意义。
一、多模态逻辑的产生背景模态逻辑，从狭义上讲，是研究“必然”和“可能”的逻辑。
从现代意义上讲，模态逻辑为研究这些概念提供了一个框架。
在形式逻辑的背景下，除了可以明确地使用模态算子对这些概念进行表述以外，还可以研究这些概念的内涵和逻辑关系。
同时，在语义学(如克里普克语义学)背景下，可以研究这些概念的外延。
模态逻辑的这些特性使其成为语言学、哲学、数理逻辑的交汇点。
从语言学的角度而言，不能简单地将模态逻辑看作是亚里士多德所谓的关于“可能”和“必然”的逻辑，而将其看作是关于“模态的逻辑”的研究则更为合理。
从一般意义上讲，模态逻辑是关于模态概念的研究。
自然语言是十分丰富的，各种模态概念的存在也使得模态逻辑的研究对象更为充盈。
其中，比较有代表性的例子有真势模态、时态模态、道义模态、认识论模态等。
鉴于在自然语言中存在着多种模态概念，模态逻辑的研究对象也不再局限于单一种类的模态。
不同种类的模态在不同领域内的作用也使得它们成为模态逻辑必不可少的研究对象。
相对于传统模态逻辑的“标准”定义而言，多模态逻辑扩展了传统模态逻辑的研究范围。
对不同种类模态的研究可以构建不同的模态逻辑系统，为不同种类的模态构建一个通用的研究框架，使得各种类型的模态逻辑在这一框架下既可以保持自身的独立性，又可以具备统一的形式化规则，这才是模态逻辑的研究目标。
1.1什么是数据挖掘？（a）它是一种广告宣传吗？（d）它是一种从数据库、统计学、机器学和模式识别发展而来的技术的简单转换或应用吗？（c）我们提出一种观点，说数据挖掘是数据库进化的结果，你认为数据挖掘也是机器学习研究进化的结果吗？你能结合该学科的发展历史提出这一观点吗？针对统计学和模式知识领域做相同的事（d）当把数据挖掘看做知识点发现过程时，描述数据挖掘所涉及的步骤答：数据挖掘比较简单的定义是：数据挖掘是从大量的、不完全的、有噪声的、模糊的、随机的实际数据中，提取隐含在其中的、人们所不知道的、但又是潜在有用信息和知识的过程。
数据挖掘不是一种广告宣传，而是由于大量数据的可用性以及把这些数据变为有用的信息的迫切需要，使得数据挖掘变得更加有必要。
因此，数据挖掘可以被看作是信息技术的自然演变的结果。
数据挖掘不是一种从数据库、统计学和机器学习发展的技术的简单转换，而是来自多学科，例如数据库技术、统计学，机器学习、高性能计算、模式识别、神经网络、数据可视化、信息检索、图像和信号处理以及空间数据分析技术的集成。
数据库技术开始于数据收集和数据库创建机制的发展，导致了用于数据管理的有效机制，包括数据存储和检索，查询和事务处理的发展。
提供查询和事务处理的大量的数据库系统最终自然地导致了对数据分析和理解的需要。
因此，出于这种必要性，数据挖掘开始了其发展。
当把数据挖掘看作知识发现过程时，涉及步骤如下：数据清理，一个删除或消除噪声和不一致的数据的过程；数据集成，多种数据源可以组合在一起；数据选择，从数据库中提取与分析任务相关的数据；数据变换，数据变换或同意成适合挖掘的形式，如通过汇总或聚集操作；数据挖掘，基本步骤，使用智能方法提取数据模式；模式评估，根据某种兴趣度度量，识别表示知识的真正有趣的模式；知识表示，使用可视化和知识表示技术，向用户提供挖掘的知识1.3定义下列数据挖掘功能：特征化、区分、关联和相关性分析、分类、回归、聚类、离群点分析。
集成梯度特征归属方法-概述说明以及解释1.引言1.1 概述在概述部分，你可以从以下角度来描述集成梯度特征归属方法的背景和重要性：集成梯度特征归属方法是一种用于分析和解释机器学习模型预测结果的技术。
随着机器学习的快速发展和广泛应用，对于模型的解释性需求也越来越高。
传统的机器学习模型通常被认为是“黑盒子”，即无法解释模型做出预测的原因。
这限制了模型在一些关键应用领域的应用，如金融风险评估、医疗诊断和自动驾驶等。
为了解决这个问题，研究人员提出了各种机器学习模型的解释方法，其中集成梯度特征归属方法是一种非常受关注和有效的技术。
集成梯度特征归属方法能够为机器学习模型的预测结果提供可解释的解释，从而揭示模型对于不同特征的关注程度和影响力。
通过分析模型中每个特征的梯度值，可以确定该特征在预测中扮演的角色和贡献度，从而帮助用户理解模型的决策过程。
这对于模型的评估、优化和改进具有重要意义。
集成梯度特征归属方法的应用广泛，不仅适用于传统的机器学习模型，如决策树、支持向量机和逻辑回归等，也可以应用于深度学习模型，如神经网络和卷积神经网络等。
它能够为各种类型的特征，包括数值型特征和类别型特征，提供有益的信息和解释。
本文将对集成梯度特征归属方法的原理、应用优势和未来发展进行详细阐述，旨在为读者提供全面的了解和使用指南。
在接下来的章节中，我们将首先介绍集成梯度特征归属方法的基本原理和算法，然后探讨应用该方法的优势和实际应用场景。
最后，我们将总结该方法的重要性，并展望未来该方法的发展前景。
1.2文章结构文章结构内容应包括以下内容：文章的结构部分主要是对整篇文章的框架进行概述，指导读者在阅读过程中能够清晰地了解文章的组织结构和内容安排。
第一部分是引言，介绍了整篇文章的背景和意义。
其中，1.1小节概述文章所要讨论的主题，简要介绍了集成梯度特征归属方法的基本概念和应用领域。
1.2小节重点在于介绍文章的结构，将列出本文各个部分的标题和内容概要，方便读者快速了解文章的大致内容。
模拟ai英文面试题目及答案模拟AI英文面试题目及答案1. 题目: What is the difference between a neural network anda deep learning model?答案: A neural network is a set of algorithms modeled loosely after the human brain that are designed to recognize patterns. A deep learning model is a neural network with multiple layers, allowing it to learn more complex patterns and features from data.2. 题目: Explain the concept of 'overfitting' in machine learning.答案: Overfitting occurs when a machine learning model learns the training data too well, including its noise and outliers, resulting in poor generalization to new, unseen data.3. 题目: What is the role of a 'bias' in an AI model?答案: Bias in an AI model refers to the systematic errors introduced by the model during the learning process. It can be due to the choice of model, the training data, or the algorithm's assumptions, and it can lead to unfair or inaccurate predictions.4. 题目: Describe the importance of data preprocessing in AI.答案: Data preprocessing is crucial in AI as it involves cleaning, transforming, and reducing the data to a suitableformat for the model to learn effectively. Proper preprocessing can significantly improve the performance of AI models by ensuring that the input data is relevant, accurate, and free from noise.5. 题目: How does reinforcement learning differ from supervised learning?答案: Reinforcement learning is a type of machine learning where an agent learns to make decisions by performing actions in an environment to maximize a reward signal. It differs from supervised learning, where the model learns from labeled data to predict outcomes based on input features.6. 题目: What is the purpose of a 'convolutional neural network' (CNN)?答案: A convolutional neural network (CNN) is a type of deep learning model that is particularly effective for processing data with a grid-like topology, such as images. CNNs use convolutional layers to automatically and adaptively learn spatial hierarchies of features from input images.7. 题目: Explain the concept of 'feature extraction' in AI.答案: Feature extraction in AI is the process of identifying and extracting relevant pieces of information from the raw data. It is a crucial step in many machine learning algorithms, as it helps to reduce the dimensionality of the data and to focus on the most informative aspects that can be used to make predictions or classifications.8. 题目: What is the significance of 'gradient descent' in training AI models?答案: Gradient descent is an optimization algorithm used to minimize a function by iteratively moving in the direction of steepest descent as defined by the negative of the gradient. In the context of AI, it is used to minimize the loss function of a model, thus refining the model's parameters to improve its accuracy.9. 题目: How does 'transfer learning' work in AI?答案: Transfer learning is a technique where a pre-trained model is used as the starting point for learning a new task. It leverages the knowledge gained from one problem to improve performance on a different but related problem, reducing the need for large amounts of labeled data and computational resources.10. 题目: What is the role of 'regularization' in preventing overfitting?答案: Regularization is a technique used to prevent overfitting by adding a penalty term to the loss function, which discourages overly complex models. It helps to control the model's capacity, forcing it to generalize better to new data by not fitting too closely to the training data.。
数据仓库与数据挖掘教程（第2版）课后习题答案第七章第七章作业1.信息论的基本原理是什么？一个传递信息的系统是由发送端(信源)和接收端(信宿)以及连接两者的通道(信道)组成的。
信息论把通信过程看做是在随机干扰的环境中传递信息的过程。
在这个通信模型中，信息源和干扰(噪声)都被理解为某种随机过程或随机序列。
在进行实际的通信之前，收信者(信宿)不可能确切了解信源究竟会发出什么样的具体信息，也不可能判断信源会处于什么样的状态。
这种情形就称为信宿对于信源状态具有不确定性，而且这种不确定性是存在于通信之前的，因而又叫做先验不确定性。
在通信后，信宿收到了信源发来的信息，这种先验不确定性才会被消除或者被减少。
如果干扰很小，不会对传递的信息产生任何可察觉的影响，信源发出的信息能够被信宿全部收到，在这种情况下，信宿的先验不确定性就会被完全消除。
但是，在一般情况下，干扰总会对信源发出的信息造成某种破坏，使信宿收到的信息不完全。
因此，先验不确定性不能全部被消除, 只能部分地消除。
换句话说，通信结束之后，信宿仍具有一定程度的不确定性。
这就是后验不确定性。
2.学习信道模型是什么？学习信道模型是信息模型应用于机器学习和数据挖掘的具体化。
学习信道模型的信源是实体的类别，采用简单“是”、“非”两类，令实体类别U 的值域为{u1，u2}，U 取u1表示取“是”类中任一例子，取u2表示取“非”类中任一例子。
信宿是实体的特征（属性）取值。
实体中某个特征属性V ，他的值域为{v1，v2……vq}。
3.为什么机器学习和数据挖掘的分类问题可以利用信息论原理？信息论原理是数据挖掘的理论基础之一。
一般用于分类问题，即从大量数据中获取分类知识。
具体来说，就是在已知各实例的类别的数据中，找出确定类别的关键的条件属性。
求关键属性的方法，即先计算各条件属性的信息量，再从中选出信息量最大的属性，信息量的计算是利用信息论原理中的公式。
4自信息：单个消息ui 发出前的不确定性（随机性）称为自信息。
数据挖掘算法原理与实现第2版第三章课后答案
1.密度聚类分析：
原理：密度聚类分析是指通过测量数据对象之间的密度（density）
来将其聚成几个聚类的一种聚类分析方法。
它把距离邻近的数据归入同一
类簇，并把不相连的数据分成不同的类簇。
实现：通过划分空间中每一点的邻域来衡量数据点之间的聚类密度。
它将每个数据点周围与它最近的K个数据点用一个空间圆包围起来，以定
义该数据点处的聚类密度。
然后，可以使用距离函数将所有点分配到最邻
近的类中。
2.引擎树：
原理：引擎树（Search Engine Tree，SET）是一种非常有效的数据
挖掘方法，它能够快速挖掘关系数据库中指定的有价值的知识。
实现：SET是一种基于决策树的技术，通过从关系数据库的历史数据
中提取出有价值的信息，来建立一种易于理解的引擎树，以及一些有益的
信息发现知识，以便用户快速找到想要的信息。
SET对原始数据进行一系
列数据挖掘处理后，能够提取出其中模式分析的信息，从而实现快速、高
效的引擎。
3.最大期望聚类：
原理：最大期望聚类（Maximization Expectation Clustering，MEC）是一种有效的数据挖掘算法，它可以自动识别出潜在的类簇结构，提取出
类簇内部的模式，帮助用户快速完成类簇分析任务。
Reasoning with Multi-Version Ontologies:a Temporal Logic ApproachZhisheng Huang and Heiner StuckenschmidtAI Department,Vrije Universiteit Amsterdam,The Netherlands{huang,heiner}@cs.vu.nlAbstract.In this paper we propose a framework for reasoning withmulti-version ontology,in which a temporal logic is developed to serveas its semantic foundation.We show that the temporal logic approachcan provide a solid semantic foundation which can support various re-quirements on multi-version ontology reasoning.We have implementedthe prototype of MORE(Multi-version Ontology REasoner),which isbased on the proposed framework.We have tested MORE with severalrealistic ontologies.In this paper,we also discuss the implementationissues and report the experiments with MORE.1IntroductionWhen an ontology is changed,the ontology developers may want to keep the older versions of the ontology.Although maintaining multi-version ontologies increases the resource cost,it is still very useful because of the following benefits:–Change Recovery.For ontology developers,the latest version of an ontol-ogy is usually less stable than the previous ones,because the new changes have been introduced on it,and those changes and their consequences have not yet been fully recognized and evaluated.Maintaining the previous ver-sions of the ontology would allow the possibilities for the developers to with-draw or adjust the changes to avoid unintended impacts.–Compatibility Ontology users may still want to use an earlier version of the ontology despite the new changes,because they may consider the function-alities of the earlier version of the ontology are sufficient for their needs.Fur-thermore,multi-version ontologies may have different resource requirement.Ontology users may prefer an earlier version with less resource requirement to a newer version with higher resource requirement.The list above is not complete.We are going to discuss more benefits in the next section.Those benefits can justify to some extend that multi-version ontology management and reasoning systems are really useful.The change recovery requires the system should provide a facility to evaluate the consequences 0The work reported in this paper was partially supported by the EU-funded SEKT project(IST-506826).2Zhisheng Huang et al.raising from ontology changes and a tool to compare multi-versions of the ontology.Selecting a compatible version needs the system which can support a query language for reasoning on a selected version of the ontology.This requires a query language which can express the temporal aspects of the ontology changes.Intuitively multiple versions of an ontology can be considered as a temporal sequence of change actions on an ontology.That serves as our departure point in this paper.In this paper we will investigate how temporal logics serve as the semantic foundation of multi-version ontology reasoning.We propose a framework of reasoning with multi-version ontologies which is based on a temporal logic approach.We will show that the temporal logic can provide a solid semantic foundation which serve as an extended query language to detect the ontology changes and their consequences.We have implemented the prototype of MORE(Multi-version Ontology REasoner),which extends existing systems for querying Description Logic Ontologies with temporal operators that support the maintenance of multiple versions of the same ontology.We discuss the implementation of the MORE more prototype and report the preliminary experiences with applying MORE to realistic ontologies.This paper is organized as follows:Section2provides a brief survey on the ontology evolution and versioning.Section3discusses the problem of multi-version ontology reasoning.Section4presents a temporal logic for reasoning with multi-version ontologies.Section5shows how the proposed temporal logic can serve as a query language for reasoning with multi-version ontologies.Section 6discusses the implementation issues of MORE and report the experiments with MORE.Section7discusses related work,further work,and concludes the paper. 2Solved and Open Problems in Ontology EvolutionDatabase schema evolution is an important area related to the problem of on-tology evolution.In the following,we summarize some of the basic requirements for schema evolution and versioning that have been stated in connection with the problem of schema evolution for object oriented databases that are most relevant for the problem of ontology evolution.Evolvability The basic requirement in connection with schema evolution is the availability of a suitable apparatus for evolving the schema in terms of change operations and a structure for representing changes.Integrity An important aspect of schema evolution is to preserve the integrity of the database during change.Syntactic conflicts may occur for example due to multiply defined attribute names in the same class definition.Further,se-mantic conflicts can appear if changes to the schema break up referential integrity or if the modification of an integrity constraints makes it in com-patible with another one.Compatibility The literature mentions two aspects of compatibility:downward compatibility means that systems that were based on the old version of theLecture Notes in Computer Science3 schema can still use the database after the evolution.Upward compatibility means that system that are built on top of the new schema can still access the old data.In principle,the issues discussed above are also relevant for the problem of ontology evolution.In the following,we summarize recent work that addressed the different aspects mentioned above for the special case of ontologies. Evolvability The evolvability of ontologies has been addressed by different re-searchers by defining change operations and change representations for ontol-ogy languages.Change operations have been proposed for specific ontology languages.In particular change operations have been defined for OKBC, OWL(Klein2004)and for the KAON ontology language(Stojanovic et al 2002).All approaches distinguish between atom and complex changes.Dif-ferent ways of representing ontological changes have been proposed:besides the obvious representation as a change log that contains a sequence of op-erations,authors have proposed to represent changes in terms of mappings between two versions of the same ontology(Noy and Musen2003). Integrity The problem of preserving integrity in the case of changes is also present for ontology evolution.On the one hand the problem is harder here as ontologies are often encoded using a logical language where changes can quickly lead to logical inconsistency that cannot directly be determined by looking at the change operation.On the other hand,there are logical reason-ers that can be used to detect inconsistencies both within the ontology and with respect to instance data.As this kind of reasoning is often costly,heuris-tic approaches for determining inconsistencies have been proposed(Klein 2004,Stuckenschmidt and Klein2003).While deciding whether an ontology is consistent or not can easily be done using existing technologies,repair-ing inconsistencies in ontologies is an open problem although there is some preliminary work on diagnosing the reasons for an inconsistency which is prerequisite for a successful repair(Schlobach and Cornet2003). Compatibility The problem of compatibility with applications that use an ontology has received little attention so far.The problem is that the impact of a change in the ontology on the function of the system is hard to predict and strongly depends on the application that uses the ontology.Part of the problem is the fact that ontologies are often not just used as afixed structure but as the basis for deductive reasoning.The functionality of the system often depends on the result of this deduction process and unwanted behavior can occur as a result of changes in the ontology.Some attempts have been made to characterize change and evolution multiple versions on a semantic level (Hefflin and Hendler2000,Hefflin and Pan2004).This work provides the basis for analyzing compatibility which currently is an open problem.We conclude that at the current state of research the problem of defining the basic apparatus for performing ontology evolution in terms of change operations and representation of changes is understood.Open questions with respect to4Zhisheng Huang et al.ontology evolution mainly concern the problem of dealing with integrity problems and with ensuring compatibility of the ontology with existing applications.The basic problem that has to address in the context of both of these topic lies in the logical nature of many ontology specifications.We therefore need methods that work a the semantic level and are aware of logical implications caused by changes.The formal characterization of ontology evolution provided by Heflin is a step in the right direction,but it does not provide any concrete methods for supporting evolution that are necessary to resolve existing problems with respect to dealing with inconsistency or determining compatibility.3Multi-Version Reasoning:An Open ProblemAs mentioned above,versioning is the key to compatibility as it enables each application to use a version of the ontology that bestfits its requirements.Our work therefore focuses on supporting the management of different versions of the same ontology on a semantic level.In particular,we want to pro-vide functionality for answering queries about knowledge derivable from different versions.The corresponding approach has to provide two kinds of functionalities:–Ask questions about statements derivable from certain versions.–Ask for versions that allow to derive certain statementsWhile thefirst kind of functionality can be used to inspect a given version of the ontology in order tofind out whether important statements can or cannot be derived from it,the second kinds of functionality helps tofind a version that is compatible with a given application because important statements can be derived from it.Another issues is the scope of the approach,in particular the space of versions to be considered.There are several possible scenarios.In most relevant cases, we are concerned with a history of different versions of the same ontology where each version replaces the previous one.We call this the retrospective approach as a result,we have a sequence of versions.Typical questions in this setting are: Invariant Facts:Are the facts from the old version still derivable?Obsolete Facts:What facts are not derivable any more?New Facts:Are the facts are newly derivable from the new version?Version Retrieval:What is the last version that can be used to derive certain facts?There are also scenarios,in which different versions of the ontology co-evolve. This is mostly the case in scenarios where the development of the ontology is not controlled by an authority.In the following,we ignore this scenario which is less relevant for professional ontology development.The other question is whether future versions are considered to be part of the space of versions.Such future versions can be characterized in terms of changes to an existing version.Lecture Notes in Computer Science5 As mentioned above,different proposals for change representations exist that could be used for this purpose.We call this the prospective approach.Typical questions here are:–Will this change make it possible to derive a certain fact?–Will this change disable the derivation of a certain fact that was derivable before?We believe that including future versions in the scope of the management approach has many benefits as it allows us to answer’what if’questions that help the ontology engineer to better plan new versions.In this paper,however, we limit our attention to the retrospective approach.The development of our method is based on the assumption that different versions of an ontology are managed on a central server.In a commercial set-ting,ontologies are normally created and maintained on a development server. Stable versions of the ontology are moved to a production server publishes the corresponding models and therefore plays the role of the central server.Further Compatangelo et al(2004)propose a blackboard architecture that also allows the centralized management of different ontology versions in distributed environ-ments that makes our approach applicable also in the distributed setting.Based on this general assumption,there are a number of quite relevant application scenarios for the version management technology sketched above.4A Temporal Logic for Multi-version Ontology ReasoningTemporal logics can be classified as two main classes with respect to two different time models:linear time model and branching time model.The linear time logics which express properties over a single sequence of states.This view is suitable for the retrospective approach to multi-ontology reasoning where we assume a sequence of versions.Branching time logics are express properties across different sequences of states.This feature would be needed for the prospective approach where we consider different possible sequences of changes in the future.The linear temporal logic LTL is a typical temporal logic for modeling linear time,whereas the computation tree logic CTL is a typical one for modeling branching time(Rescher1971,van Benthem1995,Clarke et al. 1999).Temporal logics are often future-oriented,because their operators are de-signed to be ones which involve the future states.Typical operators are:the op-erator Futureφwhich states that’φholds sometimes in the future with respect to the current state’,and the operator Alwaysfφwhich states that’φalways holds in the future with respect to the current state’,and the operatorφUntilψwhich states that’φalways holds in the future untilψholds’.For a discrete time6Zhisheng Huang et al.model,the operator Nextφis introduced to state thatφholds at the next state with respect to the current state.For the retrospective reasoning,we only need a temporal logic that only talks about the ly,it is one which can be used to compare the current state with some previous states in the past.It is natural to design the following past-oriented operators,which correspond with the counterparts of the future oriented temporal operators respectively:–the previous operator states that a factφholds just one state before the current state the current state.–the the sometimes-in-the past operator states that a factφholds sometimes in the past with respect to the current state.–the always-in-the-past operator states thatφholds always in the past with respect to the current state.In this paper,we use a linear temporal logic,denoted as LTLm,which actu-ally is a restricted linear temporal logic LTL to past-oriented temporal operators.4.1Version Spaces and Temporal ModelsIn the following,we will define the formal semantics for the temporal oper-ators by introducing an entailment relation between a semantic model(i.e., multi-version ontologies)and a temporal formula.We consider a version of an ontology to be a state in the semantic model.We do not restrict ontology specifications to a particular language(although OWL and its description logics are the languages we have in mind).In general,an ontology language can be considered to be a set of formulas that is generated by a set of syntactic rules in a logical language L.We consider multi-versions of an ontology as a sequence of ontologies which are connected each other via change operations.Each of these ontologies has a unique name.This is different from the work in[10],in which an ontology is considered as one which contains the set of other ontologies which are backwards compatible with.We have the following definition.Definition1(Version Space).An version space S over an ontology set Os is a set of ontology pairs,namely,S⊆Os×Os.We use version spaces as a semantic model for our temporal logic,restricting our investigation to version spaces that present a linear sequence of ontologies: Definition2(Linear Version Space).A linear version space S on an ontol-ogy set Os is a version space which is afinite sequence of ontologiesS={ o1,o2 , o2,o3 ,···, o n−1,o n }Alternatively we write the sequence S as follows:S=(o1,o2,···,o n)Lecture Notes in Computer Science7 We use S(i)to refer the i th ontology o i in the space.For a version space S=(o1,o2,···,o n),We call thefirst ontology S(1)in the space the initial version of the version space,and the last ontology S(n)the latest version of the version space respectively.We introduce an ordering≺S with respect to a version space S as follows: Definition3(Ordering on Version Space).o≺S o iffo occurs prior to o in the sequence S,i.e.,S=(···,o,···,o ,···).Proposition1(Prior version and Linear Ordering).the prior version relation≺S is a linear ordering,namely,≺S is(i)irreflexive,i.e.,(o≺S o),(ii)transitive,i.e.,o≺S o and o ≺S o ⇒o≺S o ,(iii)asymmetry,i.e.,o≺S o ⇒o ≺S o,(iv)comparable,i.e.,either o≺S o or o ≺S o,for any ontology o,o ,o .4.2Syntax and Semantics of LTLmThe Language L+for the temporal logic LTLm can be defined as an extension to the ontology language L with Boolean operators and the temporal operators as follows1:q∈L⇒q∈L+φ∈L+⇒¬φ∈L+φ,ψ∈L+⇒φ∧ψ∈L+φ∈L+⇒PreviousVersionφ∈L+φ∈L+⇒AllPriorVersionsφ∈L+Where the negation¬and the conjunction∧must be new symbols that do not appear in the language L to avoid the ambiguities.Define the disjunction ∨,the implication→,and the bi-conditional↔in terms of the conjunction and the negation as usual.Define⊥as a contradictoryφ∧¬φand as a tautology φ∨¬φrespectively.Using these basic operators,we can define some addition operators useful for reasoning about multiple versions.We define the SomePriorVersion operator in terms of the AllPriorVersions operator asSomePriorVersionφ=d f¬AllPriorVersions¬φThe always-in-the-past AllPriorVersions operator is one which does not con-sider the current state.We can define a strong always-in-the-past AllVersions 1Note that the logic also contains a Since operator which makes it a complete tempo-ral logic.As there is not direct use of this operator for managing multiple versions, we omit it from the discussion8Zhisheng Huang et al.operator asAllVersionsφ=d fφ∧AllPriorVersionsφ,which states that’φalways holds in the past including the current state’.Let S be a version space on an ontology set Os,and o be an ontology in the set Os,we extend the entailment relation for the extended language L+as follows:S,o|=q iffo|=q,for q∈L.S,o|=¬φiffS,o|=φ.S,o|=φ∧ψiffS,o|=φ,ψ.S,o|=PreviousVersionφiff o ,o ∈S such that S,o |=φ.S,o|=AllPriorVersionsφifffor any o such that o ≺S o,S,o |=φ.For a linear version space S,we are in particular interested in the entailment relation with respect to its latest version of the ontology S(n)in the version space S.We use S|=φto denote that S,S(n)|=φ.Model checking has been proved to be an efficient approach for the evaluation of temporal logic formulas(Clarke et al.1999).In the implementation of MORE,we are going to use the standard model checking algorithm for evaluation a query in the temporal logic LTLm. Therefore,we do not need a complete axiomatization for the logic LTLm in this paper.5LTLm as a Query LanguageThere are two types of queries:reasoning queries and retrieval queries.The former concerns with an answer either’yes’or’no’,and the latter concerns an answer with a particular value,like a set of individuals which satisfy the query ly,the evaluation of a a reasoning query is a decision problem, whereas the evaluation of a retrieval query is a search problem.In this section, we are going to discuss how we can use the proposed temporal logic to support both reasoning queries and retrieval queries.5.1Reasoning queriesUsing the LTLm logic we can formulate reasoning queries over a sequence of ontologies that correspond to the typical questions mentioned in Section3.Are all facts still derivable?This question can be answered for individ-ual facts using reasoning queries.In particular,we can use the queryφ∧PreviousVersionφto determine for factsφderivable from the previous version whether they still hold in the current version.the same can be done for older versions by chaining the PreviousVersion operator or by using the operator AllVersions to ask whether formulas was always true in past versions and is still true in the current one(AllVersionsφ).Lecture Notes in Computer Science9 What facts are not derivable any more?In a similar way,we can ask whether certain facts are not true in the new version any more.This is of particularuse for making sure that unwanted consequences have been excluded in thenew version.The corresponding query is¬φ∧PreviousVersionφ.Using the AllPriorVersions operator,we can also ask whether a fact that was alwaystrue in previous versions is not true anymore.Are the facts are newly derivable from the new version?Reasoning queriescan also be used to determine whether a fact is new in the current version.As this is true if it is not true in the previous version,we can use the fol-lowing query for checking thisφ∧¬PreviousVersionφ.We can also check whether a new fact never holded in previous versions using the following queryφ∧¬SomePriorVersionφ.What is the last version that can be used to derive certain facts?Using reasoning queries we can check whether a fact holds in a particular version.As versionsare arranged in a linear order,we can move to a particular version using the PreviousVersion operator.the query PreviousVersion PreviousVersionφfor instance checks whetherφwas true in the version before the previous one.A drawback of reasoning queries lies in the fact,that they can only check a property for a certain specific fact.When managing a different versions of a large ontology,the user will often not be interested in a particular fact,but ask about changes in general.This specific functionality is provided by retrieval queries.5.2Retrieval QueriesMany Description Logic Reasoners support so-called retrieval queries that returna set of concept names that satisfy a certain condition.For example,a children concept c of a concept c,written child(c,c ),is defined as one which is subsumedby the concept c,and there exists no other concepts between ly,child(c,c )=d f c c∧∃c (c c ∧c c∧c =c∧c =c ).Thus,the set of new/obsolete/invariant children concepts of a concept on an ontology o in the version space S is defined as followsnewChildren(S,o,c)=d f{c |S,o|=child(c,c )∧¬PreviousVersion child(c,c )}.obsoleteChildren(S,o,c)=d f{c |S,o|=¬child(c,c )∧PreviousVersion child(c,c )}. invariantChildren(S,o,c)=d f{c |S,o|=child(c,c )∧PreviousVersion child(c,c )}.The same definitions can be extended into the cases like parent concepts, ancestor concepts,descendant concept and equivalent concepts.Those query supports are sufficient to evaluate the consequences of the ontology changes andthe differences among multi-version ontologies.We will discuss more details inthe section about the tests on MORE.10Zhisheng Huang et al.5.3Making version-numbers explicitlyTemporal logics allow us to talk about the temporal aspects without reference toa particular time point.For reasoning with multi-version ontologies,we can alsotalk about the temporal aspects without mentioning a particular version name.We know that each state in the temporal logic actually corresponds with a versionof the ontology.It is not difficult to translate the temporal statements into a statement which refers to an explicit version number.Here are two approachesfor it:relative version numbering and absolute version numbering.Relative version numbering The proposed temporal logic is designed to beone for past-oriented.Therefore,it is quite natural to design a version numberingwhich is relative to the current ontology in the version space.We use the formulaVersion0φto denote that the property holds in the current ly,werefer to the current version as the version0in the version space,and otherstates are used to refer to a version relative to the current version,written asVersion−i as follows:Version0φ=d fφ.Version(−i)φ=d f PreviousVersion(Version(1−i)φ).The formula Version−iφcan be read as’the propertyφholds in the previousi-th version’.Absolute version numbering Given a version space S with n ontologies onit,i.e.,|S|=n+1.For the latest version o=S(n),it is well reasonable tocall the i-th ontology S(i)in the version space the version i of S,denoted asVersion i,ly,we can use the formula Version i,Sφto denote that thepropertyφholds in the version i in the version space S.Thus,we can define theabsolute version statement in terms of a relative version statement as follows:Version(i,S)φ=d f Version(n−i)φ.Explicit version numbering provides the basis for more concrete retrieval queries.In particular,we now have the opportunity to compare the childrenof a concept c in two specific ontologies i and j in the version space S.The corresponding definitions are the following:newChildren(S,c)i,j=d f{c |S|=Version(i,S)child(c,c )∧¬Version(j,S)child(c,c )}. obsoleteChildren(S,c)i,j=d f{c |S|=¬Version(i,S)child(c,c )∧Version(j,S)child(c,c )}. invariantChildren(S,c)i,j=d f{c |S|=Version(i,S)child(c,c )∧Version(j,S)child(c,c )}.Again,the same can be done for other predicates like parent-,ancestor or descendant concepts.Lecture Notes in Computer Science11Fig.1.Architecture of MORE.6Implementation of MOREWe implemented a prototypical reasoner for multi-version ontologies called MORE based on the approach described above.The system is implemented as an intelligent interface between an application and state-of-the art description logic reasoners(comparefigure1)and provides server-side functionality in terms of an XML-based interface for uploading different versions of an ontology and posing queries to these versions.Requests to the server are analyzed by the main control component that also transforms queries into the underlying temporal logic queries if necessary.The main control element also interacts with the ontology repository and ensures that the reasoning components are provided with the necessary information and coordinates the informationflow between the reasoning components.The actual reasoning is done by model checking components for testing temporal logic formulas that uses the results of an external description logic reasoner for answering queries about derivable facts in a certain version.The MORE prototype in implemented in Prolog and uses the XDIG inter-face(Huang and Visser2004),an extended DIG description logic interface for Prolog2.MORE is designed to be a simple API for a general reasoner with multi-version ontologies.It supports extended DIG requests from other ontology applications or other ontology and metadata management systems and supports multiple ontology languages,including OWL and DIG(Bechhofer et al.2003)3. This means that MORE can be used as an interface to any description logic reasoner as it supports the functionality of the underlying reasoner by just pass-ing requests on and provides reasoning functionalities across versions if needed. Therefore,the implementation of MORE will be independent of those particular 2http://wasp.cs.vu.nl/sekt/dig3/dig/12Zhisheng Huang et al.applications or systems.A prototype of MORE is available for download at the website:http://wasp.cs.vu.nl/sekt/more.6.1Experiments with MOREWe have tested the current implementation of the MORE system on different versions of real life ontologies from different domains.In the following,we briefly report experiments we performed on detecting changes in the concept hierarchy of the following two ontologies.The OJKL Ontology The OJKL Ontology(Ontology of the Juridical Legal Knowledge)is a legal Ontology that has been developed in the SEKT project4 to support the content-based retrieval of legal documents(Casanovas et al.2005). We usedfive different versions of the ontology from different stages of the de-velopment process.Each of these version contains about80concepts and60 relations.The BiosSAIL Ontology The BioSAIL Ontology which was developed within the BioSTORM project5.It has been used in earlier experiments on change management reported in(Klein2004).the complete data set consists of almost 20different versions of the ontology.We take three versions of the BioSAIL ontology for the tests reported below.Each version of BioSAIL ontology has about180classes and around70properties.Those two ontologies have been tested with different temporal reasoning queries.We concentrated on retrieval queries about the structure of the concept hierarchy.In particular,we used retrieval queries with explicit version numbering as introduced in section 5.3.Below we show the results for the queries about the new and obsolete child,parent,ancestor,and descendant relations in the concept hierarchy.It has to be noted that the result are not the result of a syntactic analysis of the concept hierarchy,but rely on description logic reasoning.This means that we also detect cases where changes in the definition of a concept lead to new concept relations that are only implicit in the Ontology.The results of these queries can be found at http://wasp.cs.vu.nl/sekt/more/test/.Further,arbitrary temporal queries using the operators introduced in this paper can be formulated and executed.the only limitation is the interface to the underlying DL reasoner, that currently is only implemented for queries about the concept hierarchy.This can easily be extended to any functionality provided by the RACER system (Haarslev and M¨o ller2001).A list of the template queries for temporal reasoning queries are available at the MORE testbed,which can be download from the MORE website.The average time cost for each temporal reasoning query is 4/5/projects/biostorm/。
