英语原文共 5 页，剩余内容已隐藏，支付完成后下载完整资料
英文文献翻译
文献：Database Concepts in a Domain Ontology
翻译：
一个领域本体中的数据库概念
Henrihs Gorskis1
, Ludmila Aleksejeva2
, Inese Poļaka3
1–3Riga Technical University, Latvia
摘要：在基于本体的数据访问任务中，有多种从域本体映射到数据库的方法。 为此，外部映射文件是最常用的。 这些文档描述了如何从数据库中获取描述本体个体和其他值所需的数据。 本文调查了特殊数据库概念的使用。 这些概念与领域本体没有分离; 它们与领域概念混合形成一个组合应用本体。 通过创建数据库概念和领域概念之间的自然关系，可以更轻松地实现映射并实现特定目的。 本文还调查了除领域概念之外，如何使用这些数据库概念影响本体构建和数据检索。
关键字 - 数据库，数据映射，本体。
一、导言
本体是描述相对于其他概念的概念及其含义的重要工具。 Tom Gruber在1993年给出了本体的一个定义。根据他的定义，本体是一个“域概念化的共同形式化规范”[1]。 本体用于定义通信术语，数据元建模和其他目的。 除了特定领域内使用的概念层次之外，还定义了关系和含义。 通过分享这个术语和术语背后隐含的含义，本体就是知识共享和交流。 由本体提供的概念模型是基础数据的元模型，它允许通过将概念性知识添加到双方通信中提供的数据来扩展信息。
在基于本体的数据访问任务中，本体描述的这些基本功能用于从数据库提取数据。基于本体的数据访问的目标是能够使用本体作为数据库内容的通信层，以便能够使用本体提供的现有数据提供的功能[2]。通过本体访问数据，可以使用本体中包含的关于数据库数据的知识，从而扩展它，并过滤它以符合本体的概念。但是，在基于本体的数据访问成为可能之前，应该完成将本体概念映射到数据的任务。由于本体描述与数据库模式有很大不同，因此需要一些中间映射。本文提出了一种新颖的数据映射方法，该方法使用本体概念作为基本数据库对象的映射点。通过使用本体本身的元素作为数据库的映射点，还可以观察本体中知识的意识形态一致性。除了简单性，这种映射方法还提供了另外一个好处。
二、现有方法
现有的地图绘制解决方案在很大程度上依赖于外部地图文件（图1）。这些文档包含映射作为附加文件中的规则和描述[3]，[4]。无论使用何种软件工具从数据库获取数据，它都使用这些附加文件来知道如何创建数据查询。这导致了本体概念与数据库连接或不连接的不一致性。本体工程师不能立即告知这些信息，而无需首先查阅单独的映射文档。使用映射文档还有助于在构建OBDA系统时采用本体优先方法。当本体已经存在时，使用映射文档是最舒服的。在这种情况下，映射被创建到现有的概念上。当数据库必须对新构建的本体进行特定任务的影响时，它会感到不太舒服。在这种情况下，本体和映射文件必须同时并行创建。
图1.本体到数据库映射。
使用映射文件的一个例子是名为Ontop的软件解决方案[5]。 Ontop使用映射文件来描述如何从数据库中获取个体。 映射文件使用占位符名称，个人类，带占位符值的个人属性和SQL查询来定义目标个人。 占位符名称和任何值都使用从数据库获取的值进行扩展。 这样，Ontop创建一个虚拟的RDF图并将其与本体结合起来。 IMBD电影本体的映射示例如下[6]。
mappingId Actor
target imdb:name/{person_id} a dbpedia:Actor .
source select person_id from cast_info where
cast_info.role_id = 1
mappingId Person has Birth Name
target imdb:name/{person_id} dbpedia:birthName
{name} .
source select name.id as person_id, name.name as
name from name
mappingId Person has Birth Date
target imdb:name/{person_id} dbpedia:birthDate
{dob}^^xsd:string .
source select person_id, info as dob from
person_info where info_type_id = 21 有时映射信息不是在附加映射文件中提供的，而是使用其他存储和使用解决方案。 一个例子是使用数据库本身[7]来存储映射规则。
数据库映射的另一种方法是将数据库结构重新创建为本体[8]，[9]。 在这种方法中，数据库被视为本体描述的基础（图2）。 创建的本体模仿数据库。 这具有以下优点：数据将很好地适用于本体概念。 这种方法的缺点是创建的本体主要是数据库结构，并且只提供很少的域定义。 这有时并不专门用于基于本体的数据访问任务，而且还用于合并多个数据库[10]，[11]或用于其他数据迁移和数据验证[12]任务。
图2.从数据库结构创建本体。
与本文提出的方法有一些相似之处的一种相关方法是使用概念注释作为如何从数据库获取数据的指标和说明[13]，[14]。在这种方法中，映射是通过声明本体概念上的注释来执行的。注释包含作为纯文本的数据库查询，它们可以由数据检索引擎执行。查询获得的数据是个人和数值。这种方法允许将域和映射信息存储在相同的位置，即本体。本文所述的方法与所有相关方法不同。
三、数据库概念
本文提出将特殊数据库概念与联合应用本体内的自然域概念一起使用。 这些数据库概念本身将被用作数据库对象的映射点。 这可以仅使用作为IRI字符串提供的概念名称来完成。 这些IRI字符串能够包含足够的信息来指向数据库对象。 映射可以通过正确解释这些IRI字符串来实现。
所提出的方法提供了三种类型的映射概念 - 表或视图概念，列概念和表关系。表或视图概念通过使用类进行映射。表或视图类指向数据库表或视图。在这些表中找到的数据库记录可以解释为相应类的个人。任何数据库表记录都可以作为表类的一个个体获得。数据库列使用数据属性进行映射。如果记录本身（记录存在的事实）是个人，那么表中的列是具有特定值的数据属性。个人使用这些特殊的数据库数据属性来表明这些值是从数据库中获得的。表之间的关系通过使用对象属性进行映射。表格到类别概念或表格列表到数据属性的映射不是一个新想法[15]，[16];然而，仅仅使用概念名称本身而没有附加的映射规则是新颖的。
这些特殊的数据库概念用于创建到数据库的链接以获取个人和价值。 为了能够实现这一点，它们必须与其他非数据库链接域概念区分开来。 这是通过使用前缀完成的。 映射本体将具有多个不同的前缀。 所有域概念使用一个或多个域前缀。 此外，为映射中使用的每个单独的数据库创建一个数据库前缀。 例如，让我们说，本体描述了一个域，并且所有域概念都是在本体内创建的。 因此，所有领域概念应“http://example.com/ontology/”前缀开头。 这个本体也映射到并引用一个数据库。 因此，域中的所有数据库概念都应以前缀“http://example.com/database/”开头。 前缀也可以指示概念的类型。 这可以使用以下示例前缀完成：
“http://example.com/OBDA/database1/table/”,
“http://example.com/OBDA/database2/table/”,
“http://example.com/OBDA/database1/view/”,
“http://example.com/OBDA/database1/column/”,
“http://example.com/OBDA/database1/relation/”. 除了指示查询创建系统，数据库对象的类型之外，使用前缀还有另一个优点。 通过使用前缀，可以有多个具有相同名称的概念。本体可能包含领域概念，表格概念和列概念，全部使用相同的名称，但含义不同。例如，当多个数据库映射到本体时，它们可能包含具有相同名称的表。在IRI的前缀中提供数据库名称允许在多个数据源之间进行折旧。另一个例子是数据库表“person”的情况，它可能包含大量与人有关的记录，包括一些测试记录，变更跟踪记录或其他记录，这些记录存储在同一张表中，但没有描述真实的人。在一个或多个表格中也可能有一个人的名字。 这些列可能表示与表格人员的关系。 最后，人的概念也可能存在于域中。 什么是“人”的领域概念描述可能与表人的数据不同。 因此，区分这些概念很重要。 使用不同的前缀使这成为可能。 这使得数据库概念可以在其各自元素层次结构中的任何位置自由插入到本体中，而不会干扰域概念。
四、具有混合概念的本体建筑
提出的数据库概念的可用性也对本体构建过程产生影响。数据库概念可以作为整个领域本体的基础。来自数据库的可用数据可以决定如何构建本体。修改本体构建过程以首先检查和分析可用数据和数据库的结构。接下来，确定重要的表格，视图，列和值。基于这些来自数据库的见解，数据库概念是在本体中创建的。在找到重要的数据库概念并将其添加到本体之后，可以通过在其层次结构中的数据库概念之上和之下添加域概念来扩展本体。由于来自数据库或其他数据源的所有概念都可以与领域概念区分开来，因此本体工程师可以在扩展本体中包含的知识的过程中自由使用任何领域术语。将数据库概念视为与域概念相同的位置有助于创建有意义的概念并与数据建立关系。创建与数据库概念无关的领域概念可能表明这些领域概念可能不是必需的。
理解数据库概念不能像领域概念那样被解释和使用是很重要的。例如，以类的形式添加到本体的表概念表示表中所有已知记录的集合。不多也不少。不管表格被称为什么或它应该实现什么用途。 “人员”表仍然只是数据库提供有关人员信息的一组记录;它不是描述一个人的概念的表述。如果需要一个人的实际概念，则必须将其作为领域概念分开添加到本体中。然而，人的概念在某种程度上与数据库表概念有关。根据本体与数据库的相关程度，数据库概念可能高于或低于域概念。例如，如果表“person”的数据库概念高于“person”的域概念，则与数据库的关系很强。这表明，根据这个本体论，在所有人的数据库表中都没有记录，任何人都不能成为一个人。这也意味着表格中可能有不是真人的记录。如果数据库概念低于域概念，则与数据库的连接很弱。数据库中关于人员的记录应被视为一个人;它继承了一个人的所有品质。但是，可能有人在数据库中没有记录
图3.混合概念本体片段。
图3显示了使用混合概念构建的示例本体的类层次结构的一部分。 蓝色类概念代表与数据库连接的类。 他们可以通过他们的前缀进行识别。 绿色概念是领域概念。 这个例子包含两种不同的域类概念。 数据库概念下的类与数据库严格相关。 该示例本体的构建使得心脏病专家的每个示例（实例）也必须是数据库表“医生”中的记录。 这是由“心脏病专家”级别低于所有“医生”记录类别所暗示的。 域类“Person”更一般。 它结合了来自两个不同数据库表的记录。层次结构还指出，病人和医生都是人。 在这个例子中，类“Person”也存在类“Person”的其他实例存在的可能性，而不是患者或医生。
图4.更严格的混合概念本体
如果需要一个将多个表中的记录组合起来的概念，但它也与数据库密切相关，则可以使用联合来定义它。 例如，如果有必要声明“患者”和“医生”都是人，并且人的实例只能来自这些数据库表，则本体工程师可以定义“患者”和“医生”的联合以及 将“Person”类划分为这个联盟。 这种本体可以在图4中看到。因此，任何联合或其他分组概念只包含与数据库相关的概念，因此与数据库本身密切相关。
列概念非常相似。 它们不是被添加到类层次结构中，而是被添加到数据属性层次结构中。 它们也可能具有描述其上下的数据属性的领域概念。 在构建本体时，这些数据库数据属性可用于定义复杂的域类。
图5.复杂的数据库概念
图5显示了使用数据库列作为条件的复杂类定义的示例。 当复合类在其定义中使用某个表的数据库列时，它也应该是该表的概念的子类。 这是因为只有这个表类（数据库记录）的个人才会有这个特定的列。 在上面的例子中，复杂类为记录的进一步分类提供了充分的标准，即心脏病专家或外科医生。 如果在不同数据库表中有多个列，并且所有这些列具有相同的含义，则可以将这些数据属性作为超级概念引入到这些数据属性中。 在这种情况下，在复杂类的定义中使用这样的超级数据属性将产生相同的结果。
对象属性是唯一需要特殊命名的数据库概念。 由于它们涉及两个表，它们必须包含两个表的名称。 此类对象属性的IRI由一个前缀指示与数据库的比率，后跟两个由双短划线分隔的数据库表名称。 这样的IRI可能看起来像这样“... / database1 / relation / Patient - Doctor”
数据检索引擎可以从概念前缀中确定数据库表关系的大小写。 通过分割对象属性概念名称，使用双短划线作为分隔符，并将两个部分与公共前缀组合在一起，就可以获得涉及该关系的两个表的IRI。 这种关系被认为是定向的。 关系从第一个表到第二个表。 不幸的是，关于这种关系的性质的任何细节都失去了。
数据库概念应该扩展并尽可能多地涉及领域概念。 描述域的任何知识都必须添加到本体中。 数据库概念不应该是任何本体中最重要的部分。 它们可以作为本体论的基础和骨干，不仅可以映
全文共10527字，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[10779]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
