基于领域本体和关系模型的XML语义集成方法

摘 要:由于缺乏足够的语义信息，不同模式的XML数据之间很难进行互操作。针对油气井工程中的XML数据集成需求，借助领域全局本体，提出一种模式无关的XML语义集成方法。该方法首先在XML Path路径与领域本体之间进行语义映射，屏蔽其模式差异；然后，按照模型映射方法将XML存储为关系数据；最后通过查询重写将SPARQL转换为SQL语句，实现语义查询。该方法对XML模式进行语义标注，利用关系数据库存储与查询XML数据，能有效处理领域XML数据的语义集成。

ス丶词:领域本体；XML模式；语义映射；语义查询；油井工程

ブ型挤掷嗪: TP391 文献标志码:A

Abstract: Due to the lack of sufficient semantic information, it is difficult to interoperate among XML data files with different schemas. Facing the needs to integrate XML data in the field of wellengineering, this paper proposed a modelindependent semantic integration method for XML data using domain global ontology. This method built semantic mapping between domain ontology and paths of XML schema to shield the pattern differences; then, XML data was stored as relational data using modelmapping method; finally, the SPARQL query was rewritten into SQL statements to realize semantic query. By semantic annotating of XML schema and using relational database to store and query XML data, this method solves the semantic integration for domain XML data effectively.

Key words: domain ontology; XML schema; semantic mapping; semantic query; well engineering

0 引言

作为信息表示和数据交换的一个重要标准，XML是科学数据的一种重要来源和表现形式，用户可以利用XML简单、易扩展的优点，自由定制其组织结构。然而，这种灵活性容易引起相同语义的XML 数据具有不同的模式结构或相反的情况，导致XML数据之间、XML与其他数据格式之间很难进行互操作。此外，XML 模式缺乏足够的语义信息，无法支持基于领域术语的语义查询。为此，迫切需要进行语义集成，为用户提供透明、统一和基于语义的数据访问接口。

目前，利用语义Web和本体技术是解决XML语义集成的有效方法，并产生了一些研究成果。Bohring等人提出的XML2OWL［1］集成框架可以自动地从XML 模式或文档中抽取OWL本体模型，也支持将XML数据转换为OWL实例数据。Ferdinand等人［2］提出了将XML提升至RDF和将XML 模式映射为OWL的两种独立方法。Lehti等人［3］将OWL本体作为全局模式，在XML模式与全局本体之间建立映射，但并不对实例数据进行转换,在进行查询时，将针对于OWL本体的查询转换为XQuery后,再对XML进行查询。Cruz和Xiao等人提出的集成方案［4-5］首先对每个XML数据产生一个资源描述框架(Resource Description on Framework,RDF)本体，然后再将局部本体合并生成全局本体，并通过一个映射表记录全局本体和各局部本体之间的映射关系，最后，将基于全局本体的RDF查询转换为针对XML的XQuery查询。文献［6］提出了一种利用模式图模型进行语义映射的算法，该算法通过计算概念间的匹配相似度对XML模式进行语义标注，实现XML语义集成。

作为关系数据的重要补充，油井工程领域中存在若干个XML模型，如石油标记模型PetroXML、测井标记模型WellLogML、地球物理标记模型GeophysicsML和井场信息传输标准语言WITSM［7］等。为了充分利用这些异构XML数据资源，为决策支持提供全面的数据支撑，本文提出了一种基于领域本体的XML语义集成方法。该方法采用XML模式无关的映射方法，将XML的Path路径与领域全局本体进行映射，屏蔽了XML模式差异；然后按照节点模型映射方法将XML转换为关系数据进行存储，一方面可以与现有的关系存储模式相匹配，另一方面也可以利用关系数据库的成熟技术，提高XML的存储和检索效率；最后，通过查询重写算法将SPARQL查询转换为SQL语句，实现对转存后XML数据的语义查询。

1 实现架构

该方法采用3层实现架构：用户层、语义集成层和包装器层，如图1所示。

1)用户层：提交语义查询需求和获取查询结果。其中，查询构造器负责将基于领域术语的查询请求转换为SPARQL语句并提交给语义集成层。

2)语义集成层：是实现架构的核心，主要包括油气井工程领域全局本体(Well Engineering Ontology,WeOnto)、查询解析器、查询处理器、语义映射规则库和XMLRelational转存器等部件。WeOnto描述了领域共享数据的抽象语义模型，是在领域数据专家指导下建立起来的。WeOnto一方面为查询构造器提供语义查询对象标识，另一方面利用语义映射对XML模式进行语义标注，映射过程中产生的映射规则将被保存在语义映射规则库中。查询解析器负责解析SPARQL语句，并将解析后的信息提交给查询处理器，查询处理器利用该信息，通过查询重写算法，将SPARQL查询转换为SQL语句，从转存为关系数据的原XML数据中获取查询结果。

3)包装器层：验证XML数据的有效性，获取XML的模式信息以及相关的元数据(如提交单位和日期等)。

2 XML语义映射

XML语义映射是语义集成的关键，其目的是在WeOnto与XML模式之间建立映射，以支持基于领域术语的语义查询。本文提出的语义映射方法是模式无关的，是将XML中的Path与WeOnto中的类或属性的层次结构进行映射，屏蔽了XML的模式差异，为用户提供统一和透明的全局语义查询视图。图2显示了WeOnto本体的部分结构。

2.1 XML模式表示

在油气井工程领域中，存在多种模式的XML数据，如果针对每一种模式建立一种映射方式，会导致映射关系复杂，无法进行有效管理。为此，采用XML的路径集合表示其数据模式，将XML中每一条Path路径映射为WeOnto中的一个查询路径(类或对象的层次结构)，实现语义映射。

在XML模式中，Path是由一个或多个定位步(Location Step)组成，定位步是由不同的节点构成，包括根节点、元素节点、属性节点和文本节点。Path包括两种类型：绝对路径和相对路径，绝对路径是从文档树的根节点开始定位,而相对路径则是直接从某个定位步(即节点)开始定位。本文的Path指满足末端节点为文本节点或者属性节点的绝对路径，称为映射路径，记为XPath。

参照文献［8］，下面给出基于路径的XML模式定义。

定义1 基于路径的XML模式XPathModel 是一个4元组，记为：XPathModel = 〈E, T, A, P〉。其中:E表示所有元素；T表示所有文本元素，A表示所有属性元素，P表示映射路径XPath。

图3为一个油井压裂措施的XML的模式结构，其XPathModel包含的两个XPath为：CYC#/QK#/@MC和CYC#/QK#/#HJ/CSLX#/@RQ。

2.2 XML语义视图

采用LAV(Local as Views)［9］映射方法对XML模式进行语义映射，将每一条XPath映射为WeOnto中的查询路径，由此，整个XML的XPathModel被映射为一系列语义视图，记为XSV(XML Semantic Views)，XSV包括所有XPath路径的语义映射信息。XSV定义如下：

定义2 XSV (P1，P2，…，Pn) RDF(X，Y)。其中，Pi是XML中的映射路径，即XPath；RDF(X,Y)={ RDFPi(X,Y) | RDFPi= {rdf1,rdf2,…,rdfn}}，RDFPi为rdf三元组集合，RDFPi以一系列的rdf三元组对映射路径Pi进行定义；X={X1,X2,…,Xn}为映射变量，Xi对应与WeOnto中的类；Y为WeOnto中的数据类型属性，对应映射路径Pi中的末端节点。

定义3给出了RDFPi的形式化定义：

定义3 RDFPi是rdf三元组集合:RDFPi(X,Y) = {rdf1: 〈?X1,rdf:type,WeOnto:StartClass〉,rdf2: 〈?X2,rdfs:subClassOf ?X1〉 | 〈?X1,:objAtt ?X2〉，rdf3: 〈?X2,rdf:type,WeOnto:X2Class〉,…,rdfn: 〈?Xn-1,WeOnto:dataTypeAtt,?Y〉}。其中：rdf1: 〈?X rdf:type WeOnto:StartClass〉表示从WeOnto的某个类开始定位；rdfn表示映射路径Pi的末端节点Y映射为类Xn-1的某个数据类型属性，即Y∈Range(dataTypeAttOfXn-1)； rdf2i(i=1,2,…k)，2i

XSV以语义查询的形式定义了一种映射方式，表示要定位到XPath中末端节点需要在WeOnto中构造的查询语句表达式。如FractureInfo.xml中的XPath: CYC#/@MC对应的XSV为：

{?x rdf:type :OilWell. ?x :organization ?y. ?y rdf:type :Organization. ?y:factory ?z.?z rdf:type :Factory. ?z:name ?MC}

基于XSV形式化定义，以下给出XSV的实例化表示结构。

定义4 XSV实例化结构记为XSVL(XSV List)：

XSVL = {Node | Node = (pnode, node, cnode). Node, pnode, node, cnode ∈ C ∪ P}。 C、P表示WeOnto的类和属性。

1)XSVL是一个有序的节点集合，由若干个Node元素构成；Node是一个三元组，表示WeOnto中的类或数据类型属性，pnode、node和cnode的有序关系表示Node在WeOnto的层次，pnode为node的父类，cnode为node的子类或数据类型属性。

2)Node具有两种类型节点：NodeC表示类节点，NodeDTP表示数据类型属性节点(DataType Property，DTP)。

3)Nodei，Nodei+1， Nodei= (pnodei,nodei,cnodei)， Nodei+1 = (pnodei+1,nodei+1,cnodei+1)，满足：cnodei= Nodei+1。

如XPath: CYC#/QK#/@MC的XSVL为：

{NodeCOilWell(#Well, #OilWell, NodeDTPblockName), NodeDTPblockName(NodeCOilWell, :blockName)}

3 XML数据存储与解析

作为一种存储方式，XML具有自描述、可移植等特点，能够以树型或者层次结构描述数据；但是，XML也存在缺点，如模式复杂多样、需要对其进行解析和文本转换，从而导致数据访问速度较慢；此外，针对XML的查询语言要求用户了解XML文档的结构和语法格式，这在一定程度上限制了XML数据的使用效率，因此，需要提供一种有效的XML数据管理方式。针对集成中的XML存储问题，利用基于前缀编码的节点模型映射方法，将XML数据转存为关系模型，采用SQL语言对转存后的XML数据进行查询，借助关系数据库查询优化等技术，提高存储和查询效率。

3.1 XML关系存储模型

基于关系模式存储XML数据是将XML数据分解到若干个关系表中，从而将XML的查询转化为一系列针对关系模型的查询。然而，XML模式与关系模式在语法、结构和约束等方面存在很多差异。因此，将XML数据存储为关系模型需要经过解析和映射过程进行实现。

将XML数据映射为关系模式，有两类映射方法：模型映射(Model Mapping)和结构映射(Structure Mapping)。模型映射将XML树结构映射为关系模式，该方法对于所有XML文档都有固定对应的关系模式，是XML模式无关的；结构映射将XML模式映射为关系模式以表示其逻辑结构，是模式相关的。

Yoshikawa等人利用节点模型映射方法提出了一个XML的关系存储模式，称为XRel［10］。XRel通过区间编码表示XML文档层次结构，该模式由Element、Attribute、Text和Path 4个关系表组成，分别存储元素、属性、文本和路径信息。在XRel方法基础上，提出一种基于前缀编码的模型映射方法，记为PreCodeXRel。本方法采用前缀编码对元素、文本和属性进行编码，其关系模式包括如下4个表：

Element(nodeID, pathID, prefixID, parentID);

Attribute(nodeID, pathID, prefixID, parentID, value);

Text(nodeID, pathID, prefixID, parentID, value);

Path(pathID, pathExp)。

prefixID字段表示元素(文本或属性)在文档树结构中的层次编码，它将一个节点的双亲编码作为该节点的编码前缀。例如，节点node的prefixID为prefix(node),则其孩子节点nodeChild的prefixID编码为prefix(nodeChild) = prefix(node).n，n是nodeChild在node所有孩子节点中具有相同路径的序号。通过prefixID可以快速判定XML数据中任意两个节点间的结构关系。

3.2 XML数据解析

对XML数据按照关系模式进行存储，首先需要对其进行解析。采用先序遍历算法对XML树结构和数据进行解析，并将解析后的信息保存在以上4个关系表中；然后，利用PrefixIDCoding算法对所有元素进行前缀编码。整个解析过程包括以下步骤。

1)读入XML文档，利用先序遍历算法对其进行解析，根据节点类型分别记录节点的先序遍历序号、父节点的先序遍历序号、节点路径、文本节点值和属性节点值等信息。

2)将以上信息分别存储在Element、Attribute、Text和Path表中，这些表存放在语义集成层中的关系数据库中。

3)执行PrefixIDCoding算法，在Element、Attribute、Text和Path表之间进行关系运算，对各个节点进行前缀编码。图4显示了对FractureInfo.xml执行PrefixIDCoding算法后的各元素的前缀编码。

4 XML语义查询

4.1 SPARQL语句解析

SPARQL解析的目的是将查询构造器构造的SPARQL语句中的Select、Where和Filter子句分别进行解析，生成符合XSVL定义的集合对象，从而能够与XSV语义视图进行匹配，实现语义查询。生成的集合对象具有两种类型：MapColumn和FilterColumn，分别对应查询的数据项和筛选条件。该解析算法需要以下4个辅助关系表。

1)WhereInfo(CID,Property,Value)：保存Where子句中出现的绑定变量、属性或类型标识符以及对应的值。

2)SelectTable(CID,Type)：保存Select子句中出现的绑定变量及其类型(如类绑定变量和属性绑定变量)。

3)ClassTable(CID,Type)：保存WhereInfo表中的类绑定变量及该变量在WeOnto中对应的类。如果某个绑定变量对应一个类层次关系，则只保存最底层的类。

4)ConditionTable(CID,Property,Compar,Value)：保存Filter子句出现的属性绑定变量、变量对应的类名称、条件设置和数值。

SPARQL解析算法如下所示。

程序前

Input：SPARQL语句Q

Output：Q对应的MapColumn和FilterColumn集合

/*生成MapColumn集合实例*/

1)

对Q进行解析，将解析后的信息保存到上述4个表中

2)

for (int i=0;i

3)

{String binding=SelectTable.getValueAt(i,0);

//获取元组中的绑定变量

4)String mark=SelectTable.getValueAt(i,1);

//获取binding的类型标识

5)if mark.equals("ClassType") {//判断是否是类绑定变量

6)OntClass ontClass=ClassTable.find(binding);

//获取binding对应的类

7)Iterator iter = ontClass.listDTP();

//获取ontClass的属性DTP

8)While (iter.hasNext())

MapColumn mapc=new MapColumn(iter.next());//为每个DTP构造MapColumn实例

9)}

10)if mark.equals("PropertyType"){//判断是否是属性绑定变量

11) OntClass ontClass=ClassTable.find(binding);

//获取该属性对应的类

12) MapColumn mapc=new MapColumn(ontClass,binding);}

/*生成FilterColumn集合实例*/

13)for (int i=0;i

14){String cName = conditionTable.getValueAt(i,0);//获取类名称

15)String dtpName= conditionTable.getValueAt(i,1);//获取属性名称

16)String comName = conditionTable.getValueAt(i,2);//获取比较类型

17)String value= conditionTable.getValueAt(i,3);//获取比较数值常量

18)FilterColumn fc=

new FilterColumn(cName,dtpName,comName,value);}

1)ザQ进行解析，将解析后的信息保存到上述4个表中

2)ど成MapColumn集合实例

2.1)for (int i=0;i

2.2)【2？】){String binding=SelectTable.getValueAt(i,0);

//获取元组中的绑定变量

2.3)String mark=SelectTable.getValueAt(i,1);

//获取binding的类型标识

2.4)if mark.equals(“ClassType”) {

//判断是否是类绑定变量

2.5)OntClass ontClass=ClassTable.find(binding);

//获取binding对应的类

2.6)Iterator iter = ontClass.listDTP();

//获取ontClass的属性DTP

2.7)While (iter.hasNext())MapColumn mapc=new MapColumn(iter.next());

2.8)//为每个DTP构造MapColumn实例}

2.9)if mark.equals(“PropertyType”){

//判断是否是属性绑定变量

2.10)OntClass ontClass=ClassTable.find(binding);

//获取该属性对应的类

2.11)MapColumn mapc=new MapColumn(ontClass,binding);}

2.12)

3)ど成FilterColumn集合实例

3.1)for (int i=0;i

3.2){String cName = conditionTable.getValueAt(i,0);

//获取类名称

3.3)String dtpName= conditionTable.getValueAt(i,1);

//获取属性名称

3.4)String comName = conditionTable.getValueAt(i,2);

//获取比较类型

3.5)String value= conditionTable.getValueAt(i,3);

//获取比较数值常量

3.6)FilterColumn fc=new FilterColumn(cName,dtpName,comName,value);}

程序后

4.2 SPARQL语义查询重写

查询重写是利用XSV定义，将全局语义查询重写为转存为关系模式的XML数据的SQL查询。基于XSVL存储结构，SPARQL语义查询重写算法包括如下4个步骤：

1)按照4.1节的解析算法对查询Q进行解析，解析后Q的MapColumn实例集合记为QMapColumn；FilterColumn实例集合记为QFilterColumn。

2)将XML数据的XSVL集合记为CollXSVL，每一个元素记为XSVLi(0≤ i ≤ n，n=|CollXSVL|)，将XSVLi与QMapColumn和QFilterColumn进行包含关系判断：如果QFilterColumn XSVLi并且QMapColumn XSVLi，则将XSVLi放入集合CollSatiable中。

3)依次从CollSatiable集合中选取XSVLi，按照以下步骤完成查询重写：

①XSVLi ∈ CollSatiable，XSVLi中存在某些Node元素与QFilterColumn的实例具有相同的映射路径，从XSVLi中获取这些Node对应的XPath对象，每个XPath记为pathIDi；将QFilterColumn实例中设置的条件值记为valuei。然后，构造集合CollPathID和CollPathValue分别存储pathIDi和valuei元素，即：

CollPathID= {pathID1, pathID2, …, pathIDm}

CollPathValue= {value1, value2, …, valuem}

②分别在Text和Attribute两个关系表中对pathIDi路径定义的条件数值进行关系运算，返回满足条件的xID(xID是XML文档的编号)和符合这些条件的元素对应的前缀编码。首先对Text表进行关系运算，结果记为QText(xID, prefixID)，公式如下：

QText(xID, prefixID)

πText1.docID, Text1.prefixID σexpression1 Text1×Text2

其中：expression1=((Text1.pathID=pathID1 and Text1.value=value1) … or (Text1.pathID=pathIDm and Text1.value=valuem)) and Text1.prefixID like Text2.prefixID) group by Text1.docID, prefixID)；Text1和Text2是Text表的两个别名。

然后，对Attribute表进行同样的关系运算，结果记为QAttribute(xID, prefixID)：

QAttribute(xID, prefixID)

πAttribute1.docID, Attribute1.prefixIDσ expression2 Attribute1×Attribute2

其中：expression2=((Attribute1.pathID=pathID1 and Attribute1.value=value1) …or (Attribute1.pathID=pathIDm and Attribute1.value=valuem)) and Attribute1.prefixID like Attribute2.prefixID) group by Attribute1.docID, prefixID);Attribute1和Attribute2是Attribute表的两个别名。

③分别对QText和QAttribute结果集进行筛选：如果某个xID对应的prefixID的记录数目等于选择条件的数目m，m=|CollPathValue|或者m的倍数，则该xID文档中可以作为候选的查询文档，即文档中可能具有满足查询条件的记录，并且这些记录的前缀编码与prefixID具有包含或者被包含的关系。首先，从QText和QAttribute结果集中删除不满足上述条件的记录，然后，从每个xID对应的每m个具有包含或者被包含关系的前缀编码中选择其中任意一项(如保留前缀编码最长的一项)，记为prefixID′，该编码将用于4)中的关系运算。

4)对Attribute表和Text表分别进行如下关系运算：

QText′πpathID,valueσ(pathID in CollPathID)…(xID = QText.xID)Text×QText

QAttribute′

πpathID,valueσ(pathID in CollPathID)…(xID = QAttribute.xID)Attribute×QAttribute

Q’Text

πpathID,valueσ(pathID in CollPathID), (prefixID like QText.prefixID’), (xID = QText.xID) Text×QText

Q’Attribute

πpathID,valueσ(pathID in CollPathID),(prefixID like QAttribute. prefixID’),(xID = QAttribute.xID) Attribute× QAttribute

QText′结果集中的记录形式为{pathIDi, valuei}，表示pathIDi对应的XPath中的末端文本节点是一个查询项，数值为valuei；同样，QAttribute′结果集中的记录形式为{pathIDi, valuei}，表示pathIDi对应的XPath中的末端属性节点是一个查询项，数值为valuei。最后，这些记录组成最终查询结果。

4.3 算法分析与比较

SPARQL解析算法包括两个解析过程：SPARQL语句解析和WeOnto模型解析。前者采用文本解析方法进行处理，即读入整个SPARQL语句，然后根据Select、Where及Filter子句中的符号标识将逐个将类、属性和常量保存到4个关系表中，由于应用中的SPARQL文件大小普遍不超过128@KB，所以该过程具有很高的执行效率。在进行WeOnto解析时，首先利用Jena和Pallet读入整个WeOnto模型，然后再根据关系表中的相关记录确定WeOnto中的类或属性。该过程运行效率主要取决于WeOnto本体的规模，目前的WeOnto 1.0版本中包括63个实体类，157个属性和247个约束匿名类，通过解析函数中加入的计时功能，首次将WeOnto读入内存到解析结束，共耗费0.392@s(实验机器CPU为Intel Core 2 2.10@GHz, 1@GB Memory)，后续的解析耗时0.093~0.130@s。SPARQL语义查询重写算法本质上是数据库SQL查询处理，其执行效率取决于数据规模和关系运算的复杂性(选择、联结和投影)。不同数据库中的两张Text表或者Attribute表进行联结操作时，处理方法是将其中的一张表复制到对方的数据库中去，然后再进行联结操作。这种处理方法生成的查询计划简单，在数据量较小的情况下，性能非常好。但是，当单表数据记录达到10万~100万条时，执行耗时较大，为此，可以通过提高数据库性能及网络带宽，提升系统集成及查询性能。

针对SPARQLSQL解析与查询，Chebotko［11］和Harris ［12］提出了相关的算法，与本文算法相同，它们采用特定的关系模型对解析信息进行存储，然而，它们并不支持SPARQL中的Filter子句解析；文献［13］提出的Sparql2SQL of Jena方法采用Jena APIs访问本体和关系模型，由于Jena效率局限性，系统性能不高。此外，以上三种方法都是对关系数据进行查询处理，并不支持XML数据的集成与查询。本文算法下一步的研究重点是实现Union子句的支持。

4.4实例分析

以FractureInfo.xml文档为例，以下从XML解析、语义映射和语义查询3个过程给出实现过程：

1)解析FractureInfo.xml，将元素、属性、文本和路径分别存储在Element、Attribute、Text和Path关系表中。解析后的信息为：具有18条绝对路径(包括14条XPath路径)、58个节点(包括属性节点和文本节点)、8个属性节点和22个文本节点。然后，在FractureInfo.xml与WeOnto之间建立映射，即构造XSV和XSVL。语义映射如表1所示。

FractureInfo.xml对应的XSV定义为：

XSVFractureInfo(P1,P2,…,P14)

{?x rdf:type :OilWell. ?x :organization ?y. ?y rdf:type :Organization. ?y:factory ?z. ?z rdf:type :Factory. ?z:name ?MC}, {?x rdf:type :OilWell. ?x :blockName ?QK},…, {?x rdf:type :OilWell. ?x :measure ?y. ?y rdf:type :Fracture. ?y :propAgent ?ZCJ}

2)执行SPARQL解析算法，生成MapColumn和FilterColumn实例。如查询Q：“查询在2009年1月份实施了压裂措施，并且该措施采用的是投球工艺，当前月产油量大于40吨的油井井号和该井的流压”。对应的QMapColumn和QFilterColumn实例为：

MapColumnWellID={NodeCOilWell(#Well, #OilWell, NodeDTPwellID), NodeDTPwellID(NodeCOilWell, :wellID)}

MapColumnFlowPress={NodeCOilWell(#Well, #OilWell, NodeCOutPut), NodeCOutPut (NodeCOilWell, #OutPut, NodeDTPFlowPress), NodeDTPFlowPress (NodeCOutPut, :flowPress)}

FilterColumnFinishDate={NodeCOilWell(#Well, #OilWell, NodeCFracture),NodeCFracture (NodeCOilWell,#Fracture,NodeDTPfinishDate),NodeDTPfinishDate (NodeCFracture,:finishDate,=′200901′)}

FilterColumnMeaName={NodeCOilWell(#Well,#OilWell,NodeCFracture),NodeCFracture(NodeCOilWell,#Fracture,NodeDTPmeaName),NodeDTPmeaName(NodeCFracture,:meaName,=′压裂′)}

FilterColumnFractType={NodeCOilWell(#Well, #OilWell, NodeCFracture), NodeCFracture (NodeCOilWell, #Fracture, NodeDTPfractType), NodeDTPfractType (NodeCFracture, :fractType,=′投球′)}

FilterColumnOilOutPut={NodeCOilWell(#Well, #OilWell, NodeCOutPut), NodeCOutPut (NodeCOilWell, #OutPut, NodeDTPOilOutPut), NodeDTPOilOutPut (NodeCOutPut, :oilOutPut >40)}

3)将所有XSVLi与QMapColumn和QFilterColumn匹配，获取满足匹配条件的所有XSVLi。FractureInfo.xml有4条XPath的XSVL与QFilterColumn实例相同，这4条路径为P10、P13、P14和P16；此外，FractureInfo.xml文档中的P6和P11对应的XSVL与QMapColumn实例相同。因此，在第4)步对Q进行查询重写。

4)构造CollPathID和CollPathValue集合，存储与QFilterColumn实例匹配的P10、P13、P14和P16映射路径标识以及对应的选择条件，即：

CollPathID= {10, 13, 14, 16}

CollPathValue={>=40, =′压裂′, =′200901′, =′投球′}

利用该信息，对Text表和Attribute表分别进行以下SQL运算，根据返回的XML文档编号xID和前缀编码prefixID判断哪些XML文档中存在满足条件的数据。SQL语句如下：

程序前

Select t1.xID, t1.prefixID

From Text t1, Text t2

Where t1.pathID=t2.pathID And ((t1.pathID = 10 And Cast(t1.value as float) > 40) Or (t1.pathID = 13 And t1.value = ′Fracture′) Or (t1.pathID = 14 And t1.value = ′200901′) Or (t1.pathID = 16 And t1.value= ′TouQiu′)) And t1.prefixID like t2.prefixID Order by t1.prefixID,t1.pathID

Select a1.xID, a1.prefixID

From Attribute a1, Attribute a2

Where a1.pathID = a2.pathID And ((a1.pathID = 10 And Cast(a1.value as float) > 40) Or (a1.pathID = 13 And a1.value = ′Fracture′) Or (a1.pathID = 14 And a1.value =′200901′) Or (a1.pathID = 16 And a1.value= ′TouQiu′)) And a1.prefixID like a2.prefixID Order by a1.prefixID,a1.pathID

程序后

返回的结果记录如表2所示。

表2表明，只有xID为“2009011201”、prefixID为1.1.1.1或1.1.1.1.1对应pathID列的数值组成的集合等于CollPathID，即在“2009年1月12日”提交的编号为“01”的FractureInfo.xml文档中具有满足条件的记录，这些记录的前缀编码与1.1.1.1和1.1.1.1.1具有“Like”关系，将‘prefixID’赋值为“1.1.1.1”。

5)将QMapColumn实例与XSVL进行匹配，返回的XPath编号为6和11；基于第4)步的结果，分别对Text表和Attribute表构造如下SQL语句，获取最终查询结果：

程序前

Select pathID, value

From Text

Where (pathID = 6 Or pathID = 11)

And (prefixID like ′1.1.1.1%′ Or prefixID like ′1.1.1.1.1%′)

Select pathID, value

From Attribute

Where (pathID = 6 Or pathID = 11)

And (prefixID like ′1.1.1.1%′ Or prefixID like ′1.1.1.1.1%′)

程序后

两个SQL语句各返回一条查询结果，分别为{6, 扣251}和{11，10.3}，即满足查询条件的井号是“扣251”，其2009年1月的流压为“10.3@Mpa”。

5 系统实现及应用

本方法系统架构基于Java技术实现。采用JavaApplet构造基于Web的用户查询界面，借助Jena API解析WeOnto本体并实现XML语义映射；利用Dom4j对XML进行解析并将解析后的数据存储在SQL Server 2000数据库中。

该系统已经在中石油大港油田进行了实际应用。通过对该油井日常生产、工艺措施和井下设备3种类型的XML数据进行语义集成，提供基于领域术语的语义查询功能，取得了良好的应用效果。

6 结语

针对油气井工程领域中的XML数据资源，从XML语义映射、XML数据存储和语义查询3个方面进行了重点研究，提出了一种基于领域本体的XML语义集成方法。该方法在领域全局本体与XML的Path路径之间建立语义映射，提供统一、透明和基于语义的数据访问视图。为了对不同模式的XML数据进行有效存储，采用基于节点模型的映射方法，将XML数据转换为关系模型进行存储，并在此基础上提出了一种SPARQLSQL语义查询重写算法。比较目前的集成方案，该方法结合关系数据库的存储、查询技术和本体提供的语义描述能力，为用户提供更加有效的异构XML集成与应用服务。下一步，将对语义视图定义的自动化和查询的语义保持方面进行研究。

げ慰嘉南:

[1] BOHRING H, AUER S. Mapping XML to OWL ontologies［C］// Proceedings of the 13 Leipziger InformatikTage (LIT 2005)，LNI72. Heidelberg: Springer, 2005:147-156.

[2] FERDINAND M, ZIRPINS C, TRASTOUR D. Lifting XML schema to OWL［C］// Proceedings of the International Conference on Web Engineering, LNCS 3140. Heidelberg: Springer, 2004:776-777.

[3] LEHTI P, FANKHAUSER P. XML data integration with OWL: experiences and challenges［C］// Proceedings of the 2004 International Symposium on Applications and the Internet. Washington, DC: IEEE Computer Society, 2004:160-167.

[4] CRUZ I F, XIAO H, HSU F. An ontologybased framework for XML semantic integration［C］// IDEAS04: Proceedings of the International Database Engineering and Applications Symposium. Washington, DC: IEEE Computer Society, 2004:217-226.

[5] XIAO H. Query processing for heterogeneous data integration using ontologies［D］. Chicago: University of Illinois, 2006.

[6] 王渊，陈玉. 一种XML Schema 和Ontology间的语义映射算法［J］. 小型微型计算机系统, 2005, 26(11)：1988-1990.

[7] KIRKMAN M A, SYMMONDS M E, HARBINSON S W, et al. Wellsite information transfer standard markup language［EB/OL］.［2011-02-20］. /wiki/Wellsite_information_transfer_standard_markup_language.

[8] AN Y, BORGIDA A, MYLOPOULOS J. Constructing complex semantic mappings between XML data and ontologies ［EB/OL］.［2011-02-20］.disi.unitn.it/~p2p/RelatedWork/Matching/iswc05.constructing.pdf.

[9] DUSCHKA O M, GENESERETH M R. Answering recursive queries using views［C］// Proceedings of the ACM SIGACTSIGMODSIGART Symposium on Principles of Database Systems. New York: ACM, 1997:109-116.

[10] YOSHIKAWA M, AMAGASA T, SHIMURA T, et al. XRel: a pathbased approach to storage and retrieval of XML documents using relational databases ［J］. ACM Transactions on Internet Technology, 2001, 1(1):110-141.

[11] CHEBOTKO A, LU S, JAMIL H M, et al. Semantics preserving SPARQLtoSQL query translation for optional graph patterns.TRDB052006CLJF［R］. Detroit: Wayne State University, Department of Computer Science, 2006.

[12] HARRIS S. SPARQL query processing with conventional relational database systems［C］// Proceedings of Web Information Systems Engineering 2005. Berlin: SpringerVerlag, 2005:235-244.

[13] Sparql2sql: A query engine for SPARQL over Jena triple stores［EB/OL］.［2011-02-14］./