基于整體模式匹配的深度網(wǎng)集成系統(tǒng)的研究

邵秀麗， 孫 杰， 侯樂(lè)彩

(南開(kāi)大學(xué)信息技術(shù)科學(xué)學(xué)院，天津300071)

0 引 言

Deep Web研究目的是為用戶(hù)提供一個(gè)統(tǒng)一的訪問(wèn)途徑以自動(dòng)獲取和利用分布在Web上的一些Deep Web的信息。盡管DeepWeb中幾乎包含了所有我們需要的信息，但是要想以人工方式利用這些信息實(shí)際上是一件非常困難的事情，而Deep Web數(shù)據(jù)集成正是為了以盡可能自動(dòng)的方式來(lái)達(dá)到對(duì)Web數(shù)據(jù)庫(kù)中信息有效利用的目的[1-2]。因此，具有很好的研究和應(yīng)用價(jià)值。

本文研究并設(shè)計(jì)實(shí)現(xiàn)了DeepWeb集成系統(tǒng)，以通過(guò)一個(gè)統(tǒng)一的接口訪問(wèn)所有分布的Web數(shù)據(jù)源，獲得質(zhì)量?jī)?yōu)結(jié)構(gòu)好的信息[3]。其中，DeepWeb查詢(xún)接口模式抽取部分本文采用了人工介入配置形成所需信息，從而保證基礎(chǔ)研究的模式信息的準(zhǔn)確性。模式匹配部分是DeepWeb信息集成的基本問(wèn)題，本文提出了新相關(guān)度度量標(biāo)準(zhǔn) S-measure進(jìn)行數(shù)據(jù)挖掘的整體性模式匹配方法[4-6]，利用整體性方法進(jìn)行的模式匹配有別于傳統(tǒng)1:1的匹配，不僅可以發(fā)現(xiàn)簡(jiǎn)單的1:1匹配，還可以發(fā)現(xiàn)m:n的復(fù)雜匹配，匹配精確度和效率均很高。它可以在兩個(gè)模式之外挖掘上下文信息，比如，跨多源的相似屬性，屬性間的共存模式等。在完成了模式匹配給出輸入模式集的屬性間的同義匹配結(jié)果的基礎(chǔ)上，本文設(shè)計(jì)實(shí)現(xiàn)了面向Deep Web對(duì)象的查詢(xún)接口集成系統(tǒng)。根據(jù)源查詢(xún)接口的屬性出現(xiàn)頻率和屬性模式匹配結(jié)果，選擇全局查詢(xún)接口的屬性，然后生成屬性對(duì)應(yīng)的表單元素，主要是基于屬性在模式中出現(xiàn)的頻數(shù)和屬性間的同義信息，最終提交集成的全局模式給用戶(hù)，從而生成全局的查詢(xún)接口，方便用戶(hù)實(shí)現(xiàn)查詢(xún)。

1 集成系統(tǒng)的架構(gòu)設(shè)計(jì)

本文將特定領(lǐng)域(如圖書(shū)領(lǐng)域)的多個(gè)Web查詢(xún)接口頁(yè)面作為輸入，從查詢(xún)接口中抽取模式信息；然后通過(guò)數(shù)據(jù)挖掘的方式進(jìn)行模式間的復(fù)雜匹配，這部分處理功能主要包含：數(shù)據(jù)預(yù)處理、匹配發(fā)現(xiàn)和匹配構(gòu)建；基于匹配結(jié)果生成全局的查詢(xún)接口，從而完成查詢(xún)接口集成。系統(tǒng)的架構(gòu)如圖1所示，其中：

(1)查詢(xún)接口模式抽取：主要完成從Html格式的Web查詢(xún)接口中抽取模式信息的功能。由于作為系統(tǒng)輸入的Web查詢(xún)接口頁(yè)面是Html格式的，而且包含許多接口外的無(wú)用信息，所以在進(jìn)行模式匹配之前，需要設(shè)計(jì)一個(gè)接口抽取器，用于實(shí)現(xiàn)從各個(gè)參與Deep Web的接口中抽取模式信息。本文在設(shè)計(jì)的DeepWeb搜索原型系統(tǒng)中，采用了人工獲取這些接口信息，以避免因模式數(shù)據(jù)的錯(cuò)誤而引起的匹配錯(cuò)誤。并配置各種所需要抽取的模式信息，包括屬性信息、元素信息、元素值域、查詢(xún)接口網(wǎng)址。

(2)查詢(xún)接口模式匹配：對(duì)于人工抽取出的原始模式數(shù)據(jù)(其中的接口模式包含屬性信息為商品名、著譯者等)進(jìn)行模式匹配。方法是：先對(duì)這些模式數(shù)據(jù)(主要屬性名)進(jìn)行預(yù)處理，使它們適于數(shù)據(jù)挖掘。而后是對(duì)這些人工采集的模式進(jìn)行匹配發(fā)現(xiàn)，該部分工作是模式匹配的核心部分。為發(fā)現(xiàn)可能的匹配，本文提出了一種相關(guān)性挖掘算法——整體模式匹配算法，算法實(shí)現(xiàn)的思想是：首先使用正相關(guān)挖掘挖掘出可能的成組屬性；然后使用負(fù)相關(guān)挖掘出可能的匹配(即同義屬性)；最后進(jìn)行匹配構(gòu)建工作，首先按照匹配的相關(guān)度排列發(fā)現(xiàn)的匹配，然后采用一致性約束策略篩選出最可信、最一致的匹配。

(3)查詢(xún)接口集成：本文基于模式匹配的結(jié)果和源Web查詢(xún)接口的屬性信息共同選擇全局查詢(xún)接口的屬性。具體做法是選擇在源查詢(xún)接口中出現(xiàn)次數(shù)較多的屬性，每組同義屬性(即每個(gè)匹配)中選擇一個(gè)代表性的屬性，且盡量選擇包含屬性多的成組屬性。然后再生成屬性對(duì)應(yīng)的表單元素及其對(duì)應(yīng)的元素值域。

圖1 系統(tǒng)工作流程

2 人工接口模式抽取

在模式匹配之前，需要得到一個(gè)帶有屬性信息的模式集。這就需要對(duì)同一領(lǐng)域(如圖書(shū))的查詢(xún)接口進(jìn)行模式抽取，可以進(jìn)行人工抽取[7]，也可使用成熟的數(shù)據(jù)抽取工具自動(dòng)抽取[8-9]。本文采用人工抽取的方法，對(duì)查詢(xún)接口的屬性信息進(jìn)行配置。

為更好地開(kāi)展模式抽取工作，首先要清楚需要抽取哪些信息。分為3塊工作：首先，為了進(jìn)行模式匹配，必須抽取屬性信息及屬性與接口模式的對(duì)應(yīng)信息；其次，為了生成統(tǒng)一的查詢(xún)接口，進(jìn)而將用戶(hù)查詢(xún)轉(zhuǎn)換為到各個(gè)數(shù)據(jù)源的查詢(xún)，必須抽取屬性對(duì)應(yīng)的表單元素信息，包括元素類(lèi)型、元素名稱(chēng)、元素值域等；最后，為了提交查詢(xún)從而得到結(jié)果數(shù)據(jù)，必須抽取接口的網(wǎng)址信息和提交方法信息。

2.1 配置接口信息

由于一個(gè)查詢(xún)接口包含多個(gè)屬性，一個(gè)屬性可能包含多個(gè)元素，一個(gè)元素包含一個(gè)表單控件和相關(guān)的描述信息，一個(gè)元素可能對(duì)應(yīng)多個(gè)候選值，所以采用查詢(xún)接口、屬性、元素、元素值4級(jí)表結(jié)構(gòu)來(lái)存儲(chǔ)接口信息。

首先配置查詢(xún)接口基本信息，包括站點(diǎn)名稱(chēng)、網(wǎng)址、提交action、提交方法、所屬領(lǐng)域等，如圖2所示。存儲(chǔ)網(wǎng)址、方法信息是為了完成統(tǒng)一查詢(xún)接口到Web查詢(xún)接口的映射，向Web查詢(xún)接口提交查詢(xún)請(qǐng)求，并得到返回的結(jié)果。

圖2 配置接口信息

然后為每一個(gè)查詢(xún)接口配置對(duì)應(yīng)的屬性信息，主要包括屬性名稱(chēng)，如圖3所示。為了更適合于后續(xù)的模式匹配挖掘算法，這里對(duì)屬性標(biāo)簽做一些處理，使屬性名稱(chēng)盡量簡(jiǎn)化：例如：①去除一般意義上的常用詞，如“的”、“了”和英語(yǔ)中的“on”、“of”、“the”等；②去除 Web常用詞，如“搜索”、“頁(yè)面”、“查詢(xún)”等；③去除網(wǎng)站名稱(chēng)詞，如“卓越”、“當(dāng)當(dāng)”等；④去除領(lǐng)域詞，如“圖書(shū)”、“中藥”等。

圖3 屬性配置

接著配置屬性對(duì)應(yīng)的元素信息，包括元素標(biāo)簽、表單名稱(chēng)、表單Id、表單類(lèi)型、表單值數(shù)據(jù)類(lèi)型、默認(rèn)值等，如圖4所示。

圖4 元素配置

最后配置元素對(duì)應(yīng)的值域，如圖5所示。

圖5 元素值域配置

配置元素信息是為了轉(zhuǎn)換生成Web查詢(xún)接口的查詢(xún)串，完成全局查詢(xún)接口元素到Web源查詢(xún)接口元素的匹配，從而在后續(xù)的查詢(xún)轉(zhuǎn)換時(shí)獲得查詢(xún)串的參數(shù)名稱(chēng)，值域?qū)?yīng)查詢(xún)串的參數(shù)值。

2.2 數(shù)據(jù)預(yù)處理

上面在配置屬性信息時(shí)，已做了初步的簡(jiǎn)化工作，下面在此基礎(chǔ)上繼續(xù)對(duì)屬性信息進(jìn)行句法合并處理：通過(guò)衡量屬性名稱(chēng)和屬性值域的句法相似性合并屬性實(shí)體，例如可通過(guò)名稱(chēng)相似性將“title of book”合并到“title”。

通過(guò)考察語(yǔ)言相似度來(lái)合并句法相似的實(shí)體是一種常見(jiàn)的數(shù)據(jù)清洗技術(shù)[10-11]。本文通過(guò)分別衡量屬性名稱(chēng)和屬性值的句法相似性設(shè)計(jì)了基于名稱(chēng)的合并和基于值域的合并。句法合并將會(huì)減少屬性實(shí)體的數(shù)目，增加單個(gè)的屬性實(shí)體在不同模式中出現(xiàn)的頻數(shù)，從而可以增強(qiáng)相關(guān)挖掘的效果。

(1)基于名稱(chēng)的合并

如果兩個(gè)屬性的名稱(chēng)相似，則合并它們。觀察發(fā)現(xiàn)大多數(shù)DeepWeb數(shù)據(jù)源使用簡(jiǎn)潔的核心的屬性名稱(chēng)(如title)，而其它的數(shù)據(jù)源使用這些核心詞匯的變形(如titleofbook)。因此，如果屬性Ap的名稱(chēng)包含屬性Aq的名稱(chēng) (即Ap的名稱(chēng)是Aq的名稱(chēng)的變形)而且Aq比Ap更常出現(xiàn)(即Aq是大多數(shù))，則認(rèn)為Ap是與 Aq名稱(chēng)相似的。這種基于頻率的策略可以避免絕對(duì)合并。例如，在Books領(lǐng)域，lastname就不會(huì)被合并到name中，這是因?yàn)閘astname比name更常出現(xiàn)，這種情況下本文認(rèn)為它們是兩個(gè)不同的屬性實(shí)體。

(2)基于值域的合并

如果兩個(gè)屬性的元素的值域相似，則合并它們。對(duì)查詢(xún)接口來(lái)說(shuō)，本文認(rèn)為屬性的元素值域是其可選擇的值的集合。這些值在Web表單中經(jīng)常以select控件選項(xiàng)或radio button的形式出現(xiàn)。本文只考慮帶有string類(lèi)型值的屬性，因?yàn)閷?duì)于其它數(shù)據(jù)類(lèi)型的值來(lái)說(shuō)，值相似通常并不意味著屬性相似。例如，在機(jī)票領(lǐng)域，passengers的整型數(shù)值與connections的整型數(shù)值非常相似，但事實(shí)上它們表示不同的意思。

將屬性的元素可選值看作單詞包(即，單詞頻數(shù)的計(jì)數(shù))，稱(chēng)為集合值，屬性A的集合值記作VA。對(duì)于單詞w，其在VA中的頻率記作。屬性Ap和Aq的值域相似性即和的相似性。理論上，任何合理的相似度函數(shù)在此都適用。本文特別選擇作為相似度函數(shù)。

例如：假設(shè)機(jī)票領(lǐng)域的 3 個(gè)模式：S1、S2、S3，S1的包含的屬性實(shí)體為，S2包含的屬性實(shí)體為，S3包含的屬性實(shí)體為。

屬性實(shí)體triptype出現(xiàn)在S1和S2中，所以其集合值為Vtrip type={round:2,trip:2,one:2,way:2,multi:1,city:1}，其中每個(gè)單詞后面標(biāo)著它的頻數(shù)。特別地，Vtriptype(round)=2，因?yàn)閞ound在兩個(gè)模式中都出現(xiàn)了。類(lèi)似的Vtickettype={round:1,trip:1,one:1,way:1}。所以根據(jù)上面的相似度函數(shù)可以得到

由于相似度數(shù)相當(dāng)大，因此兩個(gè)屬性是相似的，可以合并為一個(gè)屬性實(shí)體trip type。

3 查詢(xún)接口模式匹配

本文的模式匹配工作由匹配發(fā)現(xiàn)和匹配構(gòu)建這兩個(gè)前后相連的步驟組成。將模式匹配問(wèn)題分成上述兩個(gè)處理功能模塊，明確定義兩個(gè)模塊之間的接口，這樣就可以建立模塊化的解決方案。在匹配發(fā)現(xiàn)和構(gòu)建匹配之前，需要對(duì)輸入的模式數(shù)據(jù)進(jìn)行數(shù)據(jù)預(yù)處理工作，即將輸入的模式數(shù)據(jù)屬性名盡量簡(jiǎn)化，使其容易被挖掘。

3.1 匹配發(fā)現(xiàn)

匹配發(fā)現(xiàn)工作的目的是在屬性信息的基礎(chǔ)上應(yīng)用本文的整體模式匹配算法來(lái)發(fā)現(xiàn)所有候選匹配，此候選匹配集中即包含簡(jiǎn)單的1:1匹配，也包含復(fù)雜的m:n匹配，而且可能包含n元復(fù)雜匹配。這些候選匹配可能是正確匹配也可能是錯(cuò)誤匹配，這一步是模式匹配工作的重點(diǎn)，目的是從特定領(lǐng)域的多個(gè)接口模式中獲得不同屬性間的所有可能的語(yǔ)義同義信息[12-13]。工作流程是首先在屬性上進(jìn)行正相關(guān)挖掘，以發(fā)現(xiàn)可能的成組屬性，然后將成組屬性加入源模式信息，在此基礎(chǔ)上再進(jìn)行負(fù)相關(guān)挖掘，發(fā)現(xiàn)可能的同義屬性。

本文將查詢(xún)接口看作一個(gè)包含一系列屬性實(shí)體的扁平模式。屬性實(shí)體定義為屬性名稱(chēng)和屬性元素。每個(gè)屬性實(shí)體被賦予一個(gè)唯一的屬性標(biāo)識(shí)(簡(jiǎn)稱(chēng)為屬性)。為方便描述，在屬性實(shí)體上進(jìn)行匹配時(shí)，使用屬性名稱(chēng)作為屬性標(biāo)識(shí)。

匹配發(fā)現(xiàn)步驟的形式化描述為：給定一個(gè)同一領(lǐng)域的模式集I={Q1,Q2,…,QN}作為輸入(其中Qi為一個(gè)屬性集)，發(fā)現(xiàn)所有的候選匹配R={M1,…,MV}，其中Mj為一個(gè)候選的n元的復(fù)雜匹配，其中是一個(gè)屬性組(即語(yǔ)義上等價(jià)于另一個(gè)屬性或另一個(gè)屬性組的一組屬性)，而且。每個(gè)Mj表示屬性組間的語(yǔ)義同義關(guān)系，而每個(gè)表示中屬性間的成組關(guān)系。

相關(guān)挖掘的一個(gè)關(guān)鍵問(wèn)題是相關(guān)度的度量方法，即如何計(jì)算多個(gè)屬性的正相關(guān)度和如何計(jì)算多個(gè)屬性、屬性組的負(fù)相關(guān)度。為解決這個(gè)問(wèn)題，本文設(shè)計(jì)了一個(gè)具有Apriori特征的度量方法，由計(jì)算兩個(gè)數(shù)據(jù)項(xiàng)的相關(guān)度開(kāi)始，逐步計(jì)算3項(xiàng)、4項(xiàng)、……數(shù)據(jù)的相關(guān)度。

3.2 匹配構(gòu)建

匹配構(gòu)建的工作重點(diǎn)是從候選匹配集中采用一致性約束策略選擇語(yǔ)義上最可信、最一致的子集作為最終的匹配結(jié)果，這步工作就是對(duì)匹配結(jié)果的優(yōu)化，本文使用基于相關(guān)度分值的匹配排列和基于一致性約束的選擇策略。

匹配構(gòu)建工作的主要目的是在候選匹配集中選擇可信度高的、不互相沖突的匹配。

給定發(fā)現(xiàn)的候選匹配集R={M1,…,MV}，匹配構(gòu)建工作包括：匹配排列和匹配篩選。

在匹配排列階段，按照特定的排列標(biāo)準(zhǔn)C給所有的候選匹配排序，排序后用RC={}表示。以往的模式匹配算法幾乎都是以發(fā)現(xiàn)成對(duì)語(yǔ)義相關(guān)匹配為目的的，在此類(lèi)模式匹配算法中，匹配排列階段都非常簡(jiǎn)單，直接根據(jù)匹配發(fā)現(xiàn)步驟計(jì)算出的分值排列候選匹配。然而，在本文的尋找n元復(fù)雜匹配的方案框架下，這種簡(jiǎn)單的排列策略就不再適用了，所以開(kāi)發(fā)出了一種不同評(píng)分策略Cmax。

匹配篩選階段，選出RC的一個(gè)子集作為最后的匹配進(jìn)程的輸出。大多數(shù)模式匹配方案都基于一致性約束選擇候選匹配，比如兩個(gè)覆蓋同一個(gè)屬性(本文稱(chēng)之為沖突)的匹配不能同時(shí)被選中，本文也采用這樣的一致性策略來(lái)篩選候選匹配。

4 查詢(xún)接口的集成

Deep Web數(shù)據(jù)集成的核心即是形成統(tǒng)一的查詢(xún)接口界面，即查詢(xún)接口的集成。查詢(xún)接口集成的目的是為用戶(hù)提供統(tǒng)一的全局查詢(xún)接口，用戶(hù)在此接口界面上輸入查詢(xún)信息，點(diǎn)擊查詢(xún)后即可獲得多個(gè)Web源的查詢(xún)結(jié)果[14-15]。

本文基于模式匹配的結(jié)果和源Web查詢(xún)接口的屬性信息共同選擇全局查詢(xún)接口的屬性。方法是選擇在源查詢(xún)接口中出現(xiàn)次數(shù)較多的屬性，每組同義屬性(即每個(gè)匹配)中選擇一個(gè)代表性的屬性，且盡量選擇包含屬性多的成組屬性。然后再生成屬性對(duì)應(yīng)的表單元素及其對(duì)應(yīng)的元素值域。最后基于接口模式和模式匹配結(jié)果形成一個(gè)全局的查詢(xún)接口。查詢(xún)接口集成包括屬性選擇，表單元素生成和元素值域生成3部分工作。

4.1 屬性選擇

首先統(tǒng)計(jì)各屬性和屬性組在接口中出現(xiàn)的概率，存入數(shù)據(jù)庫(kù)相應(yīng)字段。研究表明，出現(xiàn)概率在20%以上的屬性占領(lǐng)域內(nèi)所有屬性的80%，據(jù)此選擇出現(xiàn)概率20%以上的屬性和屬性組作為候選屬性(組)。

考慮到后續(xù)的查詢(xún)轉(zhuǎn)換步驟，知道從屬性組到單個(gè)屬性的轉(zhuǎn)換要比從單個(gè)屬性到屬性組轉(zhuǎn)換更容易，前者只需要簡(jiǎn)單的將各個(gè)屬性對(duì)應(yīng)的元素值組合起來(lái)，而后者需要對(duì)屬性的元素值進(jìn)行拆分。所以在進(jìn)行屬性選擇時(shí)優(yōu)先選擇屬性組，而且優(yōu)先選擇包含屬性較多的屬性組。綜合以上分析，屬性選擇規(guī)則如下：

第一步，對(duì)于在同義屬性Mj：Gj1=Gj2=…=Gjw中出現(xiàn)的候選屬性(組)，按以下規(guī)則選擇一個(gè)Gjk代表此同義概念出現(xiàn)在最終的查詢(xún)接口中：

(1)若Mj包含成組屬性，且成組屬性出現(xiàn)概率在20%以上，優(yōu)先選擇成組屬性；若無(wú)成組屬性，再選單個(gè)屬性；

(2)選擇成組屬性時(shí)，優(yōu)先選擇包含屬性多、出現(xiàn)次數(shù)多的組，相同時(shí)，任選其一；

(3)選擇單個(gè)屬性時(shí)，優(yōu)先選擇出現(xiàn)次數(shù)多的屬性，次數(shù)一樣多時(shí)，任選其一。

第二步，對(duì)于不在同義屬性中出現(xiàn)的候選屬性Ai，此屬性需出現(xiàn)在最終的查詢(xún)接口中。

將選出的屬性和成組屬性存入新的數(shù)據(jù)庫(kù)表 generalAttribute和 GeneralGroup。

4.2 表單元素生成

統(tǒng)一查詢(xún)接口的屬性確定之后，就需要為各個(gè)屬性生成表單控件[10]。通過(guò)4.1知道，查詢(xún)接口中的表單控件類(lèi)型一般有text、radio、checkbox、select、textarea這5種，其中radio和select都是單選，其效果是相同的；text和textarea都是文本輸入框，也認(rèn)為其作用是相似的。因此，出現(xiàn)在最終的統(tǒng)一查詢(xún)接口中的表單控件類(lèi)型可以簡(jiǎn)化為text、select、checkbox這3種。

考慮到后續(xù)的查詢(xún)轉(zhuǎn)換步驟，很明顯將select的值轉(zhuǎn)換為text的值要比從后者到前者的轉(zhuǎn)換容易得多，因?yàn)閠ext的值是用戶(hù)輸入的，很難保證其在select中有對(duì)等的值。因此，系統(tǒng)更傾向于使用select控件。類(lèi)似的，當(dāng)select和checkbox比較時(shí)，傾向于使用select控件，這是因?yàn)閱芜x到多選的轉(zhuǎn)換比多選到單選的轉(zhuǎn)換相對(duì)容易得多。當(dāng)checkbox和text比較時(shí)，傾向于使用checkbox控件。綜合以上分析，為屬性生成表單控件時(shí)，具體做法如下：

對(duì)于上文選出的屬性，考察它即其同義屬性在原始查詢(xún)接口中包含的表單元素的元素類(lèi)型、元素?cái)?shù)目及其出現(xiàn)的次數(shù)。

式中：C(n)select——對(duì)應(yīng)n個(gè)select元素的屬性出現(xiàn)的次數(shù)，其它類(lèi)似。

GmaxSelect=max(G(n1)select,G(n2)select,…,G(nm)select)，GnumberSelect為取到最大值的G(n)select對(duì)應(yīng)的nj。

GmaxCheck、GnumberCheck與 GmaxText、GnumberText也作類(lèi)似定義。

比較 GmaxSelect、GmaxCheck、GmaxText的大小，可得：

(1)若 GmaxSelect>=GmaxCheck且 GmaxSelect>=GmaxText，則屬性對(duì)應(yīng)的表單控件是GnumberSelect個(gè)select列表，元素名稱(chēng)為select1、select2、…；

(2)若 GmaxCheck>GmaxSelect且 GmaxCheck>=GmaxText，則屬性對(duì)應(yīng)的表單控件是GnumberCheck個(gè)checkbox，元素名稱(chēng)為check1、check2、…；

(3)若GmaxText>GmaxSelect且GmaxText>GmaxCheck，則屬性對(duì)應(yīng)的表單元素是 GnumberText個(gè) text，元素名稱(chēng)為 text1、text2、…。

4.3 值域生成

設(shè)置select控件、checkbox控件的值域。

select控件：若GnumberSelect=1，對(duì)于可選值較少且比較固定的值域，如折扣，在人工抽取階段統(tǒng)一處理，如30折以下錄入時(shí)改為3折以下。對(duì)可選值較多且不同接口的相應(yīng)元素間差別較大的值域，如圖書(shū)類(lèi)型，選擇對(duì)應(yīng)元素的值域的并集作為統(tǒng)一接口中對(duì)應(yīng)元素的值域；若GnumberSelect>1，選擇一個(gè)元素類(lèi)型為select、元素?cái)?shù)目為GnumberSelect的對(duì)應(yīng)屬性的元素值域，直接一一對(duì)應(yīng)賦值給各個(gè)select元素。Post值與顯示值相同。

checkbox控件：若GnumberCheck=1，選擇對(duì)應(yīng)元素的值域的并集作為統(tǒng)一接口中對(duì)應(yīng)元素的值域；若GnumberCheck>1，選擇一個(gè)元素類(lèi)型為checkbox、元素?cái)?shù)目為GnumberCheck的對(duì)應(yīng)屬性的元素值域，直接一一對(duì)應(yīng)賦值給各個(gè)checkbox元素。

4.4 集成接口

選擇出屬性、生成屬性對(duì)應(yīng)的表單元素及其值域之后，就可以生成全局的查詢(xún)接口[11]。將選擇出來(lái)的屬性和生成的表單元素布局到同一個(gè)頁(yè)面，為了界面的友好性和易用性，采用如下規(guī)則：

(1)每個(gè)屬性的屬性名及其對(duì)應(yīng)的元素布局到同一行；不同的屬性布局在不同行。

(2)根據(jù)元素類(lèi)型動(dòng)態(tài)生成對(duì)應(yīng)類(lèi)型的元素，對(duì)于text類(lèi)型的元素，直接布局與對(duì)應(yīng)屬性的后面；對(duì)于和checkbox類(lèi)型的元素和select類(lèi)型的元素，通過(guò)查詢(xún)值域表得到選項(xiàng)值。

(3)最后加入搜索按鈕，形成全局查詢(xún)接口。

5 Deep Web圖書(shū)搜索系統(tǒng)實(shí)際應(yīng)用情況

DeepWeb圖書(shū)搜索系統(tǒng)試圖建立一個(gè)全局的圖書(shū)搜索界面，用戶(hù)只需要在這個(gè)界面中輸入一次查詢(xún)信息，即可在互聯(lián)網(wǎng)上眾多的網(wǎng)上書(shū)店站點(diǎn)中查詢(xún)相應(yīng)的圖書(shū)信息，減輕用戶(hù)的搜索負(fù)擔(dān)和輸入負(fù)擔(dān)。

該系統(tǒng)主要功能模塊包括抽取多個(gè)網(wǎng)上書(shū)店的查詢(xún)接口信息，在抽取的模式信息上進(jìn)行模式匹配，利用源模式屬性信息和模式匹配的結(jié)果3部分。抽取出的模式信息存入關(guān)系數(shù)據(jù)庫(kù)中，顯示、配置效果如圖6所示。

圖6 Deep Web圖書(shū)搜索系統(tǒng)接口配置界面

抽取的模式信息中，共有32個(gè)屬性實(shí)體，屬性實(shí)體及其出現(xiàn)頻數(shù)，例如出現(xiàn)概率在20%以上的屬性有：出版社(頻數(shù)14)，ISBN(頻數(shù) 12)，作者(頻數(shù) 11)，書(shū)名(頻數(shù) 10)，售價(jià)(頻數(shù) 9)等。在這些接口信息上進(jìn)行模式匹配，發(fā)現(xiàn)接口間屬性信息的同義匹配關(guān)系有{出版日期}={出版時(shí)間}(排列分值為0.765625)、{分類(lèi)}={類(lèi)別}(排列分值為 0.70000)、{名稱(chēng)}={書(shū)名}(排列分值為0.757575)、{著譯者}={作者 (排列分值為0.733333)}。結(jié)果表明模式匹配的結(jié)果是具有很高的準(zhǔn)確率和有效性。最后綜合源模式的屬性信息和模式匹配結(jié)果自動(dòng)生成統(tǒng)一的全局網(wǎng)上圖書(shū)查詢(xún)界面如圖7所示，該界面包括了網(wǎng)上書(shū)店查詢(xún)接口的絕大部分意義相當(dāng)?shù)牟樵?xún)條件，取得了良好的準(zhǔn)確性、友好性、易用性。

圖7 Deep Web圖書(shū)搜索查詢(xún)接口

6 結(jié)束語(yǔ)

本文對(duì)Deep Web查詢(xún)接口模式抽取、Deep Web查詢(xún)接口模式匹配及查詢(xún)接口的集成進(jìn)行了研究，并在這些研究基礎(chǔ)上建立了一個(gè)面向Deep Web對(duì)象的查詢(xún)接口集成系統(tǒng)，達(dá)到了對(duì)Deep Web關(guān)鍵技術(shù)的探討和實(shí)踐的目的。但仍然處于探索性的工作，要實(shí)現(xiàn)一個(gè)真正可用的自動(dòng)集成系統(tǒng)仍然有許多的問(wèn)題，例如：接口模式的自動(dòng)獲取等有待更深入的研究。

[1]Kabra G,Zhang Z.Dewex an exploration facility for enabling the deep web integaration[C].Proceedings of 23rd International Conference on Data Engineering,2007:1511-1512.

[2]Liu W,Meng X F,Meng W Y.A survey of deep web data integration[J].Chinese Journal of Computers,2007,30(9):1475-1489.

[3]劉偉,孟小峰,孟衛(wèi)一.Deep Web數(shù)據(jù)集成研究綜述[J].計(jì)算機(jī)學(xué)報(bào),2007,30(9):1475-1489.

[4]Avigdor Gal.Interpreting similarity measures:bridging the gap between schema matching and data integration[C].International Conference on Data Engineering,2008:278-285.

[5]Chuang S L,Chang K C.Integrating web query results:holistic schema matching[C].Proceeding of the 17th ACM Conference on Information and Knowledge Management.New York,USA:ACM Press,2008:33-42.

[6]Zhontian He,Jun Hong,David Bill.Schema matching across query interfaces on the deep web[C].Proceedings of the 25th British National Conference on Databases,2008:51-62.

[7]Chang K C C,He Bin,Li Cengkai,et al.The UIUC web integration repository[EB/OL].http://metaquerier.cs.uiuc.edu/repository/datasets/tel-8/browsable.html.2007-10-21.

[8]Zhang Z,He B,Chang K C C.Understanding web query interfaces:Best-effort parsing with hidden syntax[C].Proc of the ACM SIGMOD Conference.New York,USA:ACM Press,2004:107-118.

[9]Qian L H,Zhou GD,Zhu QM,et al.Exploiting constituentdependencies for tree kernel-based semantic relation extraction[C].Proceedings of the 22nd International Conference on Computational Linguistics,2008:696-704.

[10]劉玉,陳金雄.數(shù)據(jù)倉(cāng)庫(kù)中的數(shù)據(jù)清洗[J].醫(yī)學(xué)信息,2008(11):55-71.

[11]王詠梅,嵇曉,汪恒杰,等.面向多數(shù)據(jù)源的數(shù)據(jù)清洗關(guān)鍵技術(shù)的研究[J].科技資訊,2009(1):35-43.

[12]He B,Chang K C.Making holistic schema matching robust:An ensemble approach[C].Proceedings of the 11th ACM SIGKDD International Conference on Knowledge Discovery in Data Mining.Chicago,USA:ACM Press,2005:429-438.

[13]Evermann J.Theries of meaning in schema matching:an exploratory study[J].Information Systems,2009,34(1):28-44.

[14]Liu Wei,Li Xian,Ling Yanyan,et al.A deep web data integration system for job search[J].Wuhan University Journal of Natural Sciences,2006,11(5):34-40.

[15]Jiang Fangjiao,Jia Linlin,Meng Xiaofeng.Query translation on the fly in deep web integration[J].Wuhan University Journal of Natural Sciences,2007,12(5):29-34.