用于数据库语义查询回答的方法及系统 技术领域 本发明一般地涉及关系数据库。更具体地说， 本发明涉及一种利用本体知识丰富 数据库中个体数据的数据库语义查询回答系统及其方法， 能够高效地实现数据库语义查询 回答。
背景技术 随着数据库的大量应用， 如何高效地检索用户所需的数据已经成为当前急需解决 的问题之一。尤其是， 由于电子医疗记录 (Electrical MedicalRecords， EMRs) 的广泛使 用， 按照每个用户的要求高效地检索临床档案已经成为急需。
IHE XDS(Cross Enterprise Document Sharing) 提出了一种在任意卫生保健机构 之间管理临床档案的共享和检索的体系结构。在该 XDS 中， 将临床档案的查询限制到在档 案提交期间所提供的元数据， 例如提交时间和病人 ID。 但是， 许多用户的查询需求的目标是 临床档案的内容， 例如查找具有某些临床症状适于临床试验的病人。
通常将基于关键词的搜索用于搜索基于内容的临床档案。与标准的查询语言相 比， 例如数据库查询中的 SQL 以及逻辑系统中的查询语言， 基于关键词的搜索受到以下两 方面的限制 ： 1) 关键词不能完全反映用户的要求 ； 以及 2) 难以保证完善的合理检索结果。
Health Level 7 Clinical Document Architecture(CDA) 提出了一种广泛采 用的表示电子医疗记录的标准。除了档案的分层结构之外， CDA 还规定了档案的语义含 义， 以避免引起信息交换的歧义。CDA 的一个主要特点是频繁使用本体 ( 术语 ) 引用， SNOMED-CT(Systematized Nomenclature ofMedicine-Clinical Terms， 医药 - 临床术语的 系统命名 ) 是 CDA 常常引用的一种本体。CDA 档案的片段与 SNOMED-CT 中定义的本体概念 相关联， 而 SNOMED-CT 是用描述逻辑语言 EL+ 表述的。例如， 下面的 CDA 档案片段声明了一 个病人手指受伤的病例 ：
codeSystemName ＝″ SNOMED-CT″ displayName ＝″ Finger injury″ >
该档案片段包含对 SNOMED-CT 中如下原始定义的 “Finger injury( 手指受伤 )” 概念的本体引用 ：
Finger injury is-a Disorder
finding-site Finger
其 中，概 念 “Finger injury” 是 “Disorder( 病 症 )” 的 子 概 念，并 且
“Fingerinjury” 的每一个实例均有受伤位置是一个 “Finger( 手指 )” 的实例。此外， 在 SNOMED-CT 中， 对于身体结构 “Finger” 还存在针对角色 partOf 的定义 ： 将 “Finger” 定义为 “Hand( 手 )” 的一部分 ( 即角色 “partOf” )， 并且将 “Hand” 定义为 “Upper Limb( 上肢 )” 的一部分。为了更方便地描述， 将角色 “partOf” 定义为传递属性， 这意味着如果 a 是 b 的一 部分 ( 即 a“partOf” b) 并且 b 是 c 的一部分 ( 即 b“partOf” c)， 则 a 是 c 的一部分 ( 即 a“partOf” c)。
CDA 档案中的本体引用是实现 CDA 档案的语义查询的关键， 因为 CDA 档案可以解 释为关于本体的事实断言。例如， 上面所述的 CDA 档案片段可以解释为具有概念 “Finger injury” 的实例的病例档案。这些断言可以用下面的 RDF 三元组表示 ：
ex ： CDA_doc_1 rdf ： type ex ： CDADocument.
ex ： CDA_doc_1 ex ： hasObservation ex ： obs_1.
ex ： obs_1 rdf ： type sct ： FingerInjury.
下面作为示例给出一个查询 CDA 档案的具体查询实例， 比如查询哪些病例档案中 的病症的查找位置在 “Finger” 。
Q(x) ： -ex ： CDADocument(x)， ex ： hasObservation(x， y)， sct ： Disorder(y)， sct ： findingSite(y， z)， sct ： Finger(z).
由于上面所示病例档案的 RDF 三元组中仅有关于 “FingerInjury” 的断言， 并没有 对受伤位置 (findingSite) 的引用， 因而直接检索无法获得上述 CDA 档案， 因此无法查询哪 些病例档案中病症的受伤位置 (findingSite) 位于 “Finger” 。
有关卫生保健数据的查询回答对于基于信息的医学场景是非常关键的。然而， 卫 生保健数据一般都是通过卫生保健本体来进行注释的， 比如 SNOMED-CT 和 Gene 本体， 其表 + 达方式属于描述性逻辑语言 EL ， 因此有关卫生保健数据的查询回答依赖于本体推理以便 提供完善的合理回答。上面的例子中， 可以根据 SNOMED-CT 本体推理得到关于上述 CDA 档 案的有关受伤位置的断言。 但是， 上述通过 SNOMED-CT 本体推理的方法需要针对每一个 CDA 档案都进行本体推理。由于卫生保健本体和数据通常规模庞大， 上述方法会产生大量的推 理结果。大量的推理结果可能会造成查询回答系统的性能降低， 因而不能快速高效地处理 查询。
同样， 对于本体和数据规模庞大的其他类似行业， 也存在对本体进行合理推理并 高效处理查询回答的问题。
发明内容 鉴于上述情况， 本发明提出一种用于数据库语义查询回答的系统和方法， 能够对 关系数据库进行知识完善而不会使其数据增加过多， 并且能够在保证回答的合理性和完备 性的同时提高查询效率。
在下文中首先给出关于本发明的简要概述， 以便提供关于本发明的某些方面的基 本理解。应当理解， 这个概述并不是关于本发明的穷举性概述。它并不是意图确定本发明 的关键或重要部分， 也不是意图限定本发明的范围。其目的仅仅是以简化的形式给出某些 概念， 以此作为稍后论述的更详细描述的前序。
根据本发明的一个方面， 提供一种用于数据库查询回答的方法， 包括 ： 针对本体中
的存在型约束， 生成关于角色和概念的典型个体 ind’ ； 使用典型个体 ind’ 和本体将原始数 据中的隐式数据转换为显式数据 ； 以及从原始数据和转换的显示数据中检索满足查询中的 所有查询条件的回答。
根据本发明的另一方面， 用于数据库查询回答的方法还包括 ： 根据原始数据和转 换的显示数据生成以实名个体开始以典型个体结束的基本路径 ； 判断查询中是否存在倒 树； 以及如果查询中存在倒树并且倒树的根变量匹配为典型个体， 则通过附加如下查询条 件对查询进行改写 ： 要求存在一条基本路径， 使得倒树上所有的变量匹配都是直接或间接 位于基本路径上的节点。
根据本发明的另一个方面， 提供一种用于数据库查询回答的系统， 包括 ： 典型个体 生成单元， 配置为针对本体中的存在型约束， 生成关于角色和概念的典型个体 ind’ ； 数据 转换引擎， 配置为使用典型个体 ind’ 和本体将原始数据中的隐式数据转换为显式数据 ； 以 及查询单元， 配置为从原始数据和转换的显示数据中检索满足查询中的所有查询条件的回 答。
根据本发明的另一个方面， 用于数据库查询回答的系统还包括 ： 基本路径生成单 元， 配置为根据原始数据和转换的显示数据生成以实名个体开始以典型个体结束的基本路 径； 以及查询改写单元， 配置为判断查询中是否存在倒树， 并且在查询中存在倒树且倒树的 根变量匹配为典型个体的情况下， 通过附加如下查询条件对查询进行改写 ： 要求存在一条 基本路径， 使得倒树上所有的变量匹配都是直接或间接位于基本路径上的节点。 另外， 本发明还提供用于实现上述数据库查询回答方法的计算机程序。
此外， 本发明也提供至少计算机可读介质形式的计算机程序产品， 其上记录有用 于实现上述数据库查询回答方法的计算机程序代码。
附图说明 本发明可以通过参考下文中结合附图所给出的描述而得到更好的理解， 其中在所 有附图中使用了相同或相似的附图标记来表示相同或者相似的部件。 所述附图连同下面的 详细说明一起包含在本说明书中并且形成本说明书的一部分， 而且用来进一步举例说明本 发明的优选实施例和解释本发明的原理和优点。在附图中 ：
图 1 示出根据本发明的一个实施例的基于数据库的语义查询回答系统的示意结 构方框图 ；
图 2 示出根据本发明的一个实施例对本体中的概念公理和角色公理标准化后数 据的存储形式 ；
图 3(a) 示出根据本发明的一个具体示例的倒树查询的示意图 ；
图 3(b) 示出根据本发明的一个具体示例所生成的数据之间的关系示意图 ；
图 4 示出根据本发明的一个实施例的基于数据库的语义查询回答方法的处理过 程的流程图 ； 以及
图 5 示出用于实施根据本发明的基于数据库的语义查询回答方法的信息处理设 备的结构方块图。
本领域技术人员应当理解， 附图中的元件仅仅是为了简单和清楚起见而示出的， 而且不一定是按比例绘制的。 例如， 附图中某些元件的尺寸可能相对于其他元件放大了， 以
便有助于提高对本发明实施例的理解。 具体实施方式
在下文中将结合附图对本发明的示范性实施例进行描述。为了清楚和简明起见， 在说明书中并未描述实际实施方式的所有特征。 然而， 应该了解， 在开发任何这种实际实施 例的过程中必须做出很多特定于该实际实施方式的决定， 以便实现开发人员的具体目标， 例如， 符合与系统及业务相关的那些限制条件， 并且这些限制条件可能会随着实施方式的 不同而有所改变。此外， 还应该了解， 虽然开发工作有可能是非常复杂和费时的， 但对得益 于本公开内容的本领域技术人员来说， 这种开发工作仅仅是例行的任务。
在此， 还需要说明的一点是， 为了避免因不必要的细节而模糊了本发明， 在附图中 仅仅示出了与根据本发明的方案密切相关的装置结构和 / 或处理步骤， 而省略了与本发明 关系不大的其他细节。
为了便于加深对本发明原理的理解， 在下文中将以采用描述逻辑语言 EL+ 描述的 上述 SNOMED-CT 本体知识以及 CDA 卫生保健数据为具体示例， 对如何丰富和完善关系数据 库而不过多增加数据、 以及如何在保证回答的合理性和完备性的同时提高查询效率进行详 细描述和分析。但是本领域技术人员应当明白， 本发明并不仅仅局限于 SNOMED-CT 本体知 识和相应的 CDA 卫生保健数据， 而是可以应用到各种关系数据及其相关的本体知识。 首先将参照图 1 至图 4 描述根据本发明实施例的基于数据库的语义查询回答系统 及其方法的工作原理。
如图 1 所示， 根据本发明的一个实施例的基于数据库的语义查询回答系统包括本 体标准化单元 101、 典型个体生成单元 103、 数据转换引擎 105、 基本路径生成单元 107、 关系 数据库 109、 以及查询改写单元 111。
这里， 关系数据库 109 用于存储原始数据以及在下文中详细描述的由本体标准化 单元 101、 典型个体生成单元 103、 数据转换引擎 105 和基本路径生成单元 107 生成的各种 数据。在根据本发明的该实施例中， 以实例类型形式存储成员三元组的数据并以实例角色 形式存储关系三元组的数据。
本体标准化单元 101 将 EL+ 本体知识中的概念公理和角色公理标准化， 并且根据 标准化的概念公理和角色公理， 将原始数据转换为原概念包含形式的数据、 交概念包含形 式的数据、 存在型约束左包含形式的数据、 存在型约束右包含形式的数据、 角色包含形式的 数据、 以及角色链包含形式的数据。本体标准化单元 101 将转换后的各种数据存储在关系 数据库 109 中。
典型个体生成单元 103 针对 EL+ 本体中的存在型约束， 生成关于角色 R 和概念 B 的典型个体。这里，表示存在概念 B 的角色为 R 的关系。典型个体生成单元103 也将所生成的典型个体及相应的角色和概念存储在关系数据库 109 中。
数据转换引擎 105 使用典型个体生成单元 103 所生成的典型个体和 EL+ 本体将原 始数据中的隐式数据转换为显式数据。在根据本发明的该实施例中， 数据转换引擎 105 基 于本体标准化单元 101 标准化的概念公理和角色公理， 使用原始数据、 本体标准化单元 101 生成的数据、 以及典型个体生成单元 103 生成的典型个体及相应的角色和概念， 生成关于 原始数据和典型个体的三元组数据并存储在关系数据库 109 中。基本路径生成单元 107 使用原始数据、 本体标准化单元 101 生成的数据、 典型个体 生成单元 103 生成的典型个体及相应的角色和概念、 以及数据转换引擎 105 生成的数据， 生 成以实名个体开始以典型个体结束的基本路径， 以便于语义实现数据库查询。在根据本发 明的该实施例中， 基本路径生成单元 107 遍历由关于实名个体和典型个体的实例角色形式 的数据、 以及关于典型个体的实例类型形式的数据构成的关系图， 计算由实名个体开始由 典型个体结束的基本路径， 并且以基本路径、 基本路径之尾、 以及直接或间接位于基本路径 上的节点的三元组形式将所有的基本路径存储在关系数据库 109 中。
在本体标准化单元 101、 典型个体生成单元 103、 数据转换引擎 105、 基本路径生成 单元 107 完善和丰富了关系数据库 109 之后， 为了保证回答的合理性和完备性， 查询改写单 元 111 针对查询中的倒树附加查询条件。在根据本发明的该实施例中， 查询改写单元 111 对查询中的倒树附加如下查询条件 ： 在倒树的根变量匹配为典型个体的情况下， 要求存在 一条基本路径， 使得倒树上所有的变量匹配都是直接或间接位于基本路径上的节点。
根据本发明的该实施例的基于数据库的语义查询回答系统， 不仅能够通过本体标 准化单元 101、 典型个体生成单元 103、 数据转换引擎 105、 基本路径生成单元 107 对关系数 据库进行知识完善而不会使其数据增加过多， 而且能够通过查询改写单元 111 对查询中的 倒树附加查询条件在保证回答的合理性和完备性的同时提高查询效率。
下面将结合具体实例对根据本发明的该实施例的基于数据库的语义查询回答系 统中包括的各个模块本体标准化单元 101、 典型个体生成单元 103、 数据转换引擎 105、 基本 路径生成单元 107、 关系数据库 109、 以及查询改写单元 111 的工作原理进行详细的描述。
首先， 在关系数据库 109 中， 根据本发明的一个具体示例， 对 RDF 三元组形式的各 种原始数据进行存储形式的转换。例如， 对于个体 ind 从属于概念 concept 的 RDF 成员 三元组数据， 转换为以实例类型形式， 即表格 TYPEOF(ind， concept) 存储。对于个体 ind1 与 ind2 之间有角色 role 关系的 RDF 关系三元组数据， 则转换为以实例角色形式， 即表格 RELATIONSHIP(ind1， role， ind2) 存储。
例如， 对于从上文提到的 CDA 档案片段中断言的 RDF 三元组， 在根据本发明的实施 例的关系数据库 109 中将以下面的形式存储 ：
TYPEOF(ex ： CDA_doc_1， ex ： CDADocument)
RELATIONSHIP(ex ： CDA_doc_1， ex ： hasObservation， ex ： obs_1)
TYPEOF(ex ： obs_1， sct ： FingerInjury)
本体标准化单元 101 将本体知识中的概念公理和角色公理标准化为原概念包含公 理 subβsup、 交概念包含公理 sub16sub2βsup、 存在型约束左包含公理 存在型约束右包含公理 角色包含公理 role1βrole2、 以及角色链包含公 理 role1° role2βrole3。
这里， sub 表示子类概念， sup 表示超类概念， 并且 role 表示角色。 原概念包含公理 subβsup 表示子类 sub 包含于超类 sup， 交概念包含公理 sub16sub2βsup 表示子类 sub1 与 子类 sub2 的合取 (conjunction) 包含于超类 sup， 存在型约束左包含公理 表示具有角色 role 的子类 sub 包含于超类 sup， 存在型约束右包含公理 表示子类 sub 包含于具有角色 role 的超类 sup， 以及角色包含公理 role1βrole2 表示角色 role1 包含于角色 role2。另外， 角色链包含公理 role1° role2βrole3 表示如果概念 a 和 b 具有角色 role1 关系并且概念 b 和 c 具有角色 role2 关系， 则概念 a 和 c 之间具有角 色 role3 的关系。
关于本体标准化的处理， 请参见文献 “Baader F， Brandt S， Lutz C.Pushing the EL envelope.In Proc.of the 19th Joint Int.Conf.on ArtificialIntelligence(IJCAI 2005)， 2005” ， 这里略去其详细描述。
在此， 对于本体标准化单元 101 标准化后的上述公理， 根据本发明的一个实施例， 分别以原概念包含形式 ATOMICSUB(SUB， SUP) 表格、 交概念包含形式 GCIINTER(SUB1， SUB2， SUP) 表格、 存在型约束左包含形式 GCIEXISTS(ROLE， SUB， SUP) 表格、 存在型约束右包含形 式 EXISTSSUB(SUB， ROLE， SUP) 表格、 角色包含形式 SUBROLE(ROLE， ROLE’ ) 表格、 以及角色 链包含形式 ROLECHAIN(ROLE1， ROLE2， ROLE3) 表格存储在关系数据库 109 中。图 2 示出了 根据本发明的一个实施例对本体中的概念公理和角色公理标准化后数据的具体存储形式。 在图 2 所示的表格中， 除了上述表格之外， 还包括表格 IDURI(ID， URI)， 用于存储本体中的 所有概念 (URI) 及在关系数据库 109 中为其分配的内部标识 (ID)。
例 如，根 据 本 发 明 的 实 施 例，对 于 上 文 提 到 的 SNOMED-CT 中 的 概 念 “FingerInjury” 将 存 储 为 ATOMICSUB(sct ： FingerInjury， sct ： Disorder) 和 EXISTSSUB(sct ： FingerInjury， sct ： findingSite， sct ： Finger)。 再 比 如，对 于 作 为 “Hand( 手 )” 的一部分的 “Finger” 来说， 根据本发明的实施例将存储为 EXISTSSUB(sct ： Finger， sct ： partOf， sct ： Hand)。 同 样，对 于 作 为 “UpperLimb( 上 肢 )” 一 部 分 的 “Hand”来说， 在关系数据库 109 中将其存储为 EXISTSSUB(sct ： Hand， sct ： partOf， sct ： UpperLimb)。另外， 对于 SNOMED-CT 中的传递角色 “partOf” ， 在关系数据库 109 中将其存储 为 ROLECHAIN(sct ： partOf， sct ： partOf， sct ： partOf)。
典型个体生成单元 103 针对本体中的存在型约束 生成关于角色 R 和概 念 B 的典型个体 ind’ ， 并且将所生成的典型个体 ind’以及相应的角色 R 和概念 B 以 CANONIND(ind’ ， R， B) 形式存储在关系数据库 109 中。
例如， 对于上文中提到的查找位置 (findingSite) 在 “Finger”的存在型约束， 典型个体生成单元 103 可以生成典型个体 ex ： uuu_1 并以表格 CANONIND(ex ： uuu_1， sct ： findingSite， sct ： Finger) 将其存储在关系数据库 109 中。
数据转换引擎 105 使用本体知识和典型个体生成单元 103 所生成的典型个体 ind’ 将原始数据中的隐式数据转换为显式数据。 具体地说， 根据本发明的一个实施例， 针对本体 标准化单元 101 所标准化后的概念公理和角色公理， 分别为其定义 Datalog 规则并进行推 论， 如表 1 所示。
另外， 在根据本发明的一个实施例中， 数据转换引擎 105 还采用公知的自下而上 的策略对所述各个 Datalog 规则进行迭代推论和评估， 直到没有新的三元组数据生成为 止。
表 1 用于标准化的 EL+ 公理的 Datalog 规则
在表 1 所示的推论中， “： -” 后边的数据结构为前提， 而 “： -” 前边的数据结构为结 论。 举例来说， 对于原概念包含公理 subβsup， 数据转换引擎 105 根据原概念包含形式的数 据 ATOMICSUB(sub， sup) 和关于子类的实例类型形式的数据 TYPEOF(ind， sub) 生成关于超 类的实例类型形式的数据 TYPEOF(ind， sup)。这意味着如果一个子类概念 sub 包含于另一 个超类概念 sup 并且个体 ind 是子类概念 sub 的实例类型， 则能够推断出该个体 ind 也是 超类概念 sup 的实例类型。例如， 对于上文中提到的具体示例， 由于存在数据原概念包含形 式的数据 ATOMIC SUB(sct ： FingerInjury， sct ： Disorder) 以及关于子类的实例类型形式 的数据 TYPEOF(ex ： obs_1， sct ： FingerInjury)， 因此能够推断得出关于超类的实例类型形 式的数据 TYPEOF(ex ： obs_1， sct ： Disorder)。
类 似 地， 对 于 交 概 念 包 含 公 理 sub16sub2βsup， 数 据 转 换 引 擎 105 根 据 交 概 念包含形式的数据 GCIINTER(sub1， sub2， sup)、 关于第一子类的实例类型形式的数据 TYPEOF(ind， sub1)、 以及关于第二子类的实例类型形式的数据 TYPEOF(ind， sub2) 生成关 于超类的实例类型形式的数据 TYPEOF(ind， sup)。这意味着如果个体 ind 既是子类概念 sub1 的实例类型也是子类概念 sub2 的实例类型， 并且子类概念 sub1 和子类概念 sub2 的合 取包含于超类概念 sup， 则能够推断出该个体 ind 也是超类概念 sup 的实例类型。
基于同样原理， 对于存在型约束左包含公理数据转换引擎 105根据存在型约束左包含形式的数据 GCIEXISTS(role， sub， sup)、 实例角色形式的数据 RELATIONSHIP(ind1， role， ind2)、 以及关于子类的实例类型形式的数据 TYPEOF(ind2， sub) 生成关于超类的实例类型形式的数据 TYPEOF(ind1， sup)。这意味着如果第一个体 ind1 和 第二个体 ind2 存在角色 role 关系， 第二个体 ind2 是子类概念 sub 的实例类型， 并且具有 角色 role 的子类概念 sub 包含于超类概念 sup， 则能够推断出第一个体 ind1 是超类概念sup 的实例类型。
而 且， 对 于 角 色 包 含 公 理 role1βrole2， 数 据 转 换 引 擎 105 根 据 角 色 包 含 形 式 的 数 据 SUBROLE(role1， role2)、 以及关于第一角色的实例角色形式的 数 据 RELATIONSHIP(ind1， role1， ind2) 生 成 第 二 角 色 的 实 例 角 色 形 式 的 数 据 RELATIONSHIP(ind1， role2， ind2)。这意味着如果角色 role1 包含于角色 role2 并且第一 个体 ind1 和第二个体 ind2 之间具有实例角色 role1 关系， 则能够推断出第一个体 ind1 和 第二个体 ind2 之间也具有实例角色 role2 关系。
另外， 对于角色链包含公理 role1° role2βrole3， 数据转换引擎 105 根据角色链 包含形式的数据 ROLECHAIN(role1， role2， role3)、 关于第一个体、 第一角色和第二个体的 实例角色形式的数据 RELATIONSHIP(ind1， role1， ind2)、 以及关于第二个体、 第二角色和第 三个体的实例角色形式的数据 RELATIONSHIP(ind2， role2， ind3) 生成关于第一个体、 第三 角色和第三个体的实例角色形式的数据 RELATIONSHIP(ind1， role3， ind3)。这意味着如果 第一个体 ind1 和第二个体 ind2 之间具有实例角色 role1 关系， 第二个体 ind2 和第三个体 ind3 之间具有实例角色 role2 关系， 并且实例角色 role1、 实例角色 role2 以及实例角色 role3 之间具有角色链包含关系 role1° role2βrole3， 则能够推断出第一个体 ind1 和第 三个体 ind3 之间具有实例角色 role3 关系。
这里需要指出的是， 对于存在型约束右包含公理数据转换引擎105 则根据存在型约束右包含形式的数据 EXISTSSUB(sub， role， sup)、 实例类型形式的数 据 TYPEOF(ind， sub)、 以及根据本发明的实施例由典型个体生成单元 103 所生成的典型个 体及相应的角色和概念 CANONIND(ind’ ， role， sup) 生成关于实名个体和典型个体的实例 角色形式的数据 RELATIONSHIP(ind， role， ind’ )、 以及关于典型个体的实例类型形式的数 据 TYPEOF(ind’ ， sup)。
也就是说， 如果存在个体 ind 属于存在型约束右包含形式的数据 EXISTSSUB(sub， role， sup) 中的子类概念类型 sub， 并且存在关于角色 role 和超类概念 sup 的典型个体 ind’ ， 则能够推断出 RELATIONSHIP(ind， role， ind’ ) 和 TYPEOF(ind’ ， sup)。
实际上， 存在型约束右包含公理的逻辑语义已经超出了 Datalog规则的范围， 这意味着对于每一个属于子类概念类型 sub 的个体 ind1， 根据现有技术， 必须 为该个体 ind1 生成一个新的个体 ind2 及相应的关系数据， 比如 RELATIONSHIP(ind1， role， ind2) 和 TYPEOF(ind2， sup)。可以想象， 当存在大量的子类概念 sub 的实例时， 必然会导致 巨量的新个体和关系数据产生， 这些个体应用到表 1 所示的 Datalog 规则中进行迭代评估， 所花费的时间也相当可观。
相反， 对于本发明的实施例， 由于针对一类个体 ind 生成了典型个体 ind’ ， 则无需 如现有技术那样， 针对每一个属于此类的具体个体 ind1 生成一个新的个体 ind2， 因此能够 急剧减少新生成的个体的数量。相应地， 进行表 1 所示的 Datalog 规则的迭代推理所花费 的时间也明显下降。
再 回 到 上 文 的 具 体 示 例， 除 了 所 产 生 的 典 型 个 体 CANONIND(ex ： uuu_1， sct ： findingSite， sct ： Finger) 之外， 由于还存在三元组数据 EXISTSSUB(sct ： FingerInjury， sct ： findingSite， sct ： Finger) 和 TYPEOF(ex ； obs_1， sct ： FingerInjury)， 因此能够推断 出新的数据 RELATIONSHIP(ex ： obs_1， sct ： findingSite， ex ： uuu_1) 和 TYPEOF(ex ： uuu_1，sct ： Finger)。
到此为止， 对于上文的具体示例， 除了初始断言的三元组数据之外， 还新推断出了 如下所示的三元组数据用于对语义查询提供回答。
ex ： obs_1 rdf ： type sct ： Disorder.
ex ： obs_1 sct ： findingSite ex ： uuu_1.
ex ： uuu_1 rdf ： type sct ： Finger.
利用新生成的三元组数据和初始断言的三元组数据， 能够非常快捷容易地得出在 背景技术中给出的查询示例的回答。
但是， 由于在典型个体生成单元 103 生成典型个体 ind’ 时对存在型约束右包含公 理 回答。 比 如，以 SNOMED-CT 中 定 义 为 “Hand” 的 一 部 分 的 “Finger” 以 及 定义为 “UpperLimb” 一 部 分 的 “Hand” 为 例，这 里 存 在 两 个 存 在 型 约 束，即
进行了语义近似， 因此导致并不是对所有的查询郭能保证提供正确的和因此典型个体生成单元 103 生成两个典型个体比如 ex ： u1 和 ex ： u2 并且将其在关系数据库 109 中分别存 储 为 CANONIND(ex ： u1， sct ： partOf， sct ： Hand) 和 CANONIND(ex ： u1， sct ： partOf， sct ： UpperLimb)。
此外， 假设在关系数据库 109 中将 “yourFinger( 你的手指 )” 存储为 TYPEOF(ex ： yourFinger， sct ： Finger)。另外， 本体标准化单元 101 从 SNOMED-CT 本体知识中能够得出 EXISTSSUB(sct ： Finger， sct ： partOf， sct ： Hand) 和 EXISTSSUB(sct ： Hand， sct ： partOf， sct ： UpperLimb)。基于上述原始数据和典型个体生成单元 103 生成的数据， 数据转换引 擎 105 对存在型约束右包含公理 进行 Datalog 规则推论， 能够生成新的 数 据 RELATIONSHIP(ex ： yourFinger， sct ： partOf， ex ： u1)、 TYPEOF(ex ： u1， sct ： Hand)、 RELATIONSHIP(ex ： u1， sct ： partOf， ex ： u2)、 TYPEOF(ex ： u2， sct ： UpperLimb)。
接下来， 假设在关系数据库 109 中将 “myFinger( 我的手指 )” 存储为 TYPEOF(ex ： myFinger， sct ： Finger)， 将 “myHand( 我的手 )” 存储为 TYPEOF(ex ： myHand， sct ： Hand)， 并 且同时将二者的实例关系存储为 RELATIONSHIP(ex ： myFinger， sct ： partOf， ex ： myHand)。 同样， 数据转换引擎 105 对存在型约束右包含公理 进行 Datalog 规则推 论， 能够推断出新的数据 RELATIONSHIP(ex ： myHand， sct ： partOf， ex ： u2)。此外， 由于 sct ： partOf 的传递性， 因此能够推断出新的数据 RELATIONSHIP(ex ： yourFinger， sct ： partOf， ex ： u2) 和 RELATIONSHIP(ex ： myFinger， sct ： partOf， ex ： u2)。
以上由本体标准化单元 101、 典型个体生成单元 103、 以及数据转换引擎 105 所 生成的数据之间的关系可以用图 3(b) 所示的树清楚地表示。在图 3(b) 中， “a” 表示 “my finger” ， “b” 表示 “my hand” ， “c” 表示 “your finger” ， “u1” 和 “u2” 分别表示典型个体生 成单元 103 针对 和 生成的典型个体。
现在， 进行 “哪两个个体同是某物的一部分” 的查询， 即进行如图 3(a) 所示的倒树 查询 “Q(x， y) ： -sct ： partOf(x， z)， sct ： partOf(y， z)” 。如果根据上面由数据转换引擎 105所完善的数据进行查询， 将导致 “我的手指和你的手指同是某物的一部分” 的回答， 这显然 是不正确的。
从上面的示例中可以看出， 对于倒树形式的查询， 根据本发明的实施例由典型个 体生成单元 103 和数据转换引擎 105 所完善生成的数据可能会导致以错误的方式匹配查询 倒树。导致查询回答错误的原因是由于存在型约束右包含公理 子类概念 sub 的实例个体都共享了针对存在型约束 中的所有 所生成的关于角色 role 仅仅生和超类概念 sup 的同一个典型个体 ind’ ， 并且针对同一个存在型约束成一个典型个体 ind’ 。
以上面的具体示例为例， 查询 “sct ： partOf(x， z)” 和 “sct ： partOf(y， z)” 构成 了倒树。由于存在型约束右包含公理 使 得典型个体 “u2” 是由 “my hand” 和 “u1” 共享的典型个体。进而， 由于诸如传递规则 sct ： partOf 的表达性规则进行迭代推论和评估， 使得典型个体 “u2”成为由 “my finger”和 “your finger” 共享的典型个体， 因此针对上述查询给出了错误回答。
另一方面， 由典型个体生成单元 103 和数据转换引擎 105 所完善生成的数据中实 际上也存在匹配倒树查询的回答。比如， 对于上面的具体示例， “myfinger” 和 “my hand” 也 共享同一典型个体 ex ： u2， 但是这样的共享不是源于多次使用存在型约束右包含公理， 因 此能够针对上述查询给出正确回答。
为了解决上述问题， 根据本发明的基本路径生成单元 107 通过生成以实名个体开 始以典型个体结束的基本路径来将不正确的回答滤除。
具 体 地 说， 基 本 路 径 生 成 单 元 107 首 先 标 识 针 对 存 在 型 约 束 右 包 含 公 理 进行的推论所生成的关系三元组， 将其记做 BT。 然后， 基本路径生成单元 107 遍历由关系三元组 BT 构成的图， 计算由节点 u0， ...， uk 构成的基本路径 BP(uk)， 其中 u0 为实名个体， u1， ...， uk 为典型个体， 并且对于任 u1， 意的 0 ≤ i ＜ k， 使得＜ ui， ui+1 ＞∈ BT。这里将 u0 称为基本路径之首， 将 uk 称为基本路径 之尾。
最后， 基本路径生成单元 107 以 BPath(path， tail， node) 形式存储所有的基本 路径， 其中 path 为基本路径， tail 为基本路径之尾， node 为直接位于基本路径上的节点 ui(0 ≤ i ＜ k) 或间接位于基本路径上的节点。这里， 间接位于基本路径上的节点为具有实 例角色关系 RELATIONSHIP(v， r， u0) 的实名个体 v。
在上面所示的具体示例中， 按照基本路径生成单元 107 的上述处理可以生成 3 条 基 本 路 径， 即 b ＊ u2、 c ＊ u1、 以 及 c ＊ u1 ＊ u2， 其中 “＊”表 示 节 点 之 间 相 互 链 接。 同 样， 为 了 描 述 方 便 起 见， 这 里 的 a” 、 “b” 、 “c”分 别 表 示 “myfinger” 、 “my hand” 和 “your finger” ， “u1”和 “u2”分 别 表 示 典 型 个 体 生 成 单 元 103 针 对 存 在 型 约 束
和生成的典型个体。下面的表 2 示出了由基本路径生成单元 107 生成的基本路径的存储形式， 其中 “a” 间接位于 基本路径 b ＊ u2 上， 这是由于存在 RELATIONSHIP(ex ： myFinger， sct ： partOf， ex ： myHand)， 而 ex ： myHand 正是基本路径 b ＊ u2 之首 b。
表 2 基本路径存储表14101996208 A CN 101996213
说路径 b ＊ u2 b ＊ u2 c ＊ u1 c ＊ u1 ＊ u2 c ＊ u1 ＊ u2明路径尾 u2 u2 u1 u2 u2书经过节点 b a c c u111/13 页在本体标准化单元 101、 典型个体生成单元 103、 数据转换引擎 105、 基本路径生成 单元 107 完善和丰富了关系数据库 109 之后， 为了保证回答的合理性和完备性， 查询改写单 元 111 针对查询中的倒树附加查询条件。即， 根据数据倒树以单条基本路径匹配查询倒树 的基本路径标准， 在倒树的根变量匹配为典型个体的情况下， 要求存在一条基本路径， 使得 倒树上所有的变量匹配都是直接或间接位于基本路径上的节点。
下面将详细说明根据该实施例的基于数据库的语义查询回答系统中的查询改写 单元 111 的工作原理。
首先， 查询改写单元 111 对查询中的每一个根节点按照倒树遍历原则标识查询中 的每一个倒树 ({s1， ...， sn}， t)， 其中 t 为查询中的根节点， s 1， ...， sn 为以 t 作为根节点 的倒树中所包括的各个节点。
具体地说， 对于给定查询 q， 使用 Rq 来表示查询 q 中的倒树根节点集合， 使得 Rq ： ＝ {t|#{s|R(s， t) ∈ q} ＞ 1}。然后， 对于每一个根节点 t ∈ Rq， 计算倒树的元素集合， 使得 S0 ： ＝ {s|R(s， t) ∈ q} 并且 Si+1 ： ＝ Si ∪ {s’ |R’ (s’ ， t’ ) ∈ q， t’ ∈ Si}。在 Si+1 到达固 定点即 Si+1 ＝ Si 时终止倒树元素集合的计算。此时， 使用 St 来表示倒树 t 中所包含的节点 集合， 即， St ： ＝∪ i ＞＝ 0Si， 并且将查询 q 中的每一个倒树表示为一对 (St， t)， 其中 t ∈ Rq。 这里， 也将 St 表示为 {s1， ...， sn}。
在标识完查询中的所有倒树之后， 查询改写单元 111 对查询中的每一个倒树
({s1， ...， sn}， t) 附加查询条件 CANONIND(t) →BPath(p， t， s1)， ...， BPath(p， t， sn)，其中 CANONIND(t) 表示 t 的变量匹配为一个由典型个体生成单元生成的典型个体， 表示 存在一条由基本路径生成单元生成的基本路径 p， BPath(p， t， s1)， ...， BPath(p， t， sn) 表 示由基本路径存储单元存储着倒树上 s1， ...， sn 的变量匹配。
对于上文中提到的查询 Q(x， y) ： -sct ： partOf(x， z)， sct ： partOf(y， z)， 由于具有 倒树 ({x， y}， z)， 因此查询改写单元 111 将其改写为
Q(x， y) ： -sct ： partOf(x， z)， sct ： partOf(y， z)， (CANONIND(z) → BPath(p， z， x)，
BPath(p， z， y)).
将该查询改写单元 111 改写后的查询提交到由本体标准化单元 101、 典型个体生 成单元 103、 数据转换引擎 105、 基本路径生成单元 107 完善和丰富的关系数据库 109， 能够 得出正确的查询回答， 即返回包括 “my finger” 和 “my hand” 的回答， 而将包括 “my finger”和 “your finger” 的回答排除在外。
这里需要指出的是， 在上面描述的基于数据库的语义查询回答系统中， 可以由本 体标准化单元 101、 典型个体生成单元 103、 数据转换引擎 105、 基本路径生成单元 107、 以及 + 关系数据库 109 构成语义数据库生成系统， 事先根据 EL 本体知识对原始数据进行扩展和 完善， 以便于进行查询。这样， 在实时查询时， 可以仅由查询改写单元 111 对所输出的查询 进行改写， 从而实现快速高效的查询效率。
以上结合附图 1 至附图 3 详细描述了根据本发明的一个实施例的基于数据库的语 义查询回答系统的结构及其详细工作原理。下面将结合图 4 描述根据本发明的一个实施例 的基于数据库的语义查询回答方法的处理过程。
如图 4 所示， 根据该实施例的基于数据库的语义查询回答方法包括本体标准化步 骤 S401、 典型个体生成步骤 S403、 数据转换步骤 S405、 基本路径生成步骤 S407 以及查询改 写步骤 S409。
同样， 在根据本发明的该实施例的基于数据库的语义查询回答方法中， 对于 RDF 三元组形式的各种原始数据， 以实例类型形式， 即 TYPEOF(ind， concept) 表格将 RDF 成员 三元组的数据存储在关系数据库中， 并且以实例角色形式， 即 RELATIONSHIP(ind1， role， ind2) 表格将 RDF 关系三元组的数据存储在关系数据库中。这里， TYPEOF(ind， concept) 表示个体 ind 从属于概念 concept， 而 RELATIONSHIP(ind1， role， ind2) 表示个体 ind1 与 ind2 之间有角色 role 关系。 由于在根据本发明该实施例的基于数据库的语义查询回答方法中的本体标准化 步骤 S401、 典型个体生成步骤 S403、 数据转换步骤 S405、 基本路径生成步骤 S407 以及查询 改写步骤 S409 等各个步骤中的具体处理过程分别与参照图 1 描述的基于数据库的语义查 询回答系统中的本体标准化单元 101、 典型个体生成单元 103、 数据转换引擎 105、 基本路径 生成单元 107、 以及查询改写单元 111 等各个模块中的处理类似， 因此在此略去进一步的详 细描述。
同样， 这里需要指出的是， 在上面结合图 4 所描述的基于数据库的语义查询回答 方法中， 也可以仅仅通过本体标准化步骤 S401、 典型个体生成步骤 S403、 数据转换步骤 S405、 以及基本路径生成步骤 S407 事先根据 EL+ 本体知识对原始数据进行扩展和完善， 以 便于进行查询。这样， 在实时查询时， 由查询改写步骤 S409 对所输出的查询进行改写， 从而 实现快速高效的查询效率。
以上结合具体实施例描述了本发明的基本原理， 但是， 还需要指出的是， 对本领域 的普通技术人员而言， 能够理解本发明的方法和装置的全部或者任何步骤或者部件， 可以 在任何计算装置 ( 包括处理器、 存储介质等 ) 或者计算装置的网络中， 以硬件、 固件、 软件或 者它们的组合加以实现， 这是本领域普通技术人员在阅读了本发明的说明的情况下运用他 们的基本编程技能就能实现的。
因此， 本发明的目的还可以通过在任何计算装置上运行一个程序或者一组程序来 实现。所述计算装置可以是公知的通用装置。因此， 本发明的目的也可以仅仅通过提供包 含实现所述方法或者装置的程序代码的程序产品来实现。也就是说， 这样的程序产品也构 成本发明， 并且存储有这样的程序产品的存储介质也构成本发明。 显然， 所述存储介质可以 是任何公知的存储介质或者将来所开发出来的任何存储介质。
在通过软件和 / 或固件实现本发明的实施例的情况下， 从存储介质或网络向具有 专用硬件结构的计算机， 例如图 5 所示的通用个人计算机 700 安装构成该软件的程序， 该计 算机在安装有各种程序时， 能够执行各种功能等等。
在图 5 中， 中央处理单元 (CPU)701 根据只读存储器 (ROM)702 中存储的程序或从 存储部分 708 加载到随机存取存储器 (RAM)703 的程序执行各种处理。在 RAM 703 中， 也根 据需要存储当 CPU 701 执行各种处理等等时所需的数据。CPU 701、 ROM 702 和 RAM 703 经 由总线 704 彼此连接。输入 / 输出接口 705 也连接到总线 704。
下述部件连接到输入 / 输出接口 705 ： 输入部分 706， 包括键盘、 鼠标等等 ； 输出部 分 707， 包括显示器， 比如阴极射线管 (CRT)、 液晶显示器 (LCD) 等等， 和扬声器等等 ； 存储部 分 708， 包括硬盘等等 ； 和通信部分 709， 包括网络接口卡比如 LAN 卡、 调制解调器等等。通 信部分 709 经由网络比如因特网执行通信处理。
根据需要， 驱动器 710 也连接到输入 / 输出接口 705。可拆卸介质 711 比如磁盘、 光盘、 磁光盘、 半导体存储器等等根据需要被安装在驱动器 710 上， 使得从中读出的计算机 程序根据需要被安装到存储部分 708 中。
在通过软件实现上述系列处理的情况下， 从网络比如因特网或存储介质比如可拆 卸介质 711 安装构成软件的程序。
本领域的技术人员应当理解， 这种存储介质不局限于图 5 所示的其中存储有程 序、 与装置相分离地分发以向用户提供程序的可拆卸介质 711。可拆卸介质 711 的例子 包含磁盘 ( 包含软盘 ( 注册商标 ))、 光盘 ( 包含光盘只读存储器 (CD-ROM) 和数字通用盘 (DVD))、 磁光盘 ( 包含迷你盘 (MD)( 注册商标 )) 和半导体存储器。或者， 存储介质可以是 ROM 702、 存储部分 708 中包含的硬盘等等， 其中存有程序， 并且与包含它们的装置一起被 分发给用户。
还需要指出的是， 在本发明的装置和方法中， 显然， 各部件或各步骤是可以分解和 / 或重新组合的。这些分解和 / 或重新组合应视为本发明的等效方案。并且， 执行上述系列 处理的步骤可以自然地按照说明的顺序按时间顺序执行， 但是并不需要一定按照时间顺序 执行。某些步骤可以并行或彼此独立地执行。
虽然已经详细说明了本发明及其优点， 但是应当理解在不脱离由所附的权利要求 所限定的本发明的精神和范围的情况下可以进行各种改变、 替代和变换。 而且， 本申请的术 语 “包括” 、 “包含” 或者其任何其他变体意在涵盖非排他性的包含， 从而使得包括一系列要 素的过程、 方法、 物品或者装置不仅包括那些要素， 而且还包括没有明确列出的其他要素， 或者是还包括为这种过程、 方法、 物品或者装置所固有的要素。在没有更多限制的情况下， 由语句 “包括一个 ......” 限定的要素， 并不排除在包括所述要素的过程、 方法、 物品或者装 置中还存在另外的相同要素。