摘要

搜索引擎在識別可以由結構化數據回答的查詢上做出了重大努力，同時在創建和維護高精度數據庫方面進行了大量投入。雖然這些數據庫具有相對較寬的實體覆蓋，但是它們建模屬性的數量（例如，GDP，CAPITAL，ANTHEM）相對較小。擴展搜索引擎已知的屬性數量可以使它更準確地回答非頻繁查詢，從Web中提取更廣泛的事實，以及恢復Web上表的語義。

Biperpedia，一個具有1.6M（類，屬性）對和67K不同屬性名稱的本體。Biperpedia從查詢流中提取屬性，然后使用最佳提取來從文本中提取屬性。對于每個屬性，Biperpedia保存它出現的一組同義詞和文本模式，從而使其能夠在更多上下文中識別屬性。除了對Biperpedia質量的詳細分析，本文還證明其可以增加Web表的數量，相比于Freebase，我們可以恢復超過4個因素。

1.?介紹

在網絡歷史上，結構化數據一開始便是搜索結果的首選。主要搜索引擎在識別何時可以使用結構化數據來回答用戶的查詢上做出了重大努力。與此同時，他們正在投入大量資源來建立一個數據庫以擴展知識庫，如Freebase?[3]。這些數據庫包含如（法國，CAPITAL，巴黎）的三個成分，其模擬了廣泛的感興趣的主題。來自結構化數據的搜索結果顯示在常規搜索結果的頂部或右側。

雖然在搜索結果中結構化數據庫具有相對較寬的實體覆蓋（例如，瑞典，Gerhard?Weikum，Ghostbusters），但是它們建模的屬性（例如CAPITAL，PUBLICATIONS，RELEASE?DATE）的數量相對較小。例如，對于類COUNTRIES，Freebase只有少于200個屬性，而感興趣的屬性的數目是數以千計的。

?

從以下幾方面考慮，擴展搜索引擎屬性的數量是十分必要的。首先，附加屬性將使得搜索引擎能夠更精確地回答非頻繁查詢（如巴西咖啡生產）。其次，附加屬性可以方便使用開放信息提取技術從網絡文本中提取事實[9]。最后，廣泛的屬性庫也可以讓我們可以恢復Web上表的語義[24]，因為它使得列標題和周圍文本中的屬性名稱能夠更容易被識別。

我們將Biperpedia描述為一個二元屬性的本體，包含比Freebase多兩個數量級的屬性。Biperpedia中的屬性（參見圖1）可以是一對實體（如CAPITAL?of?COUNTRY），實體和值（如COFFEE?PRODUCTION）或實體與敘述（如CULTURE）之間的關系。Biperpedia關注模式級別的屬性，而提取這些屬性的實際值是未來要努力的一個方向。Biperpedia是一個盡力而為的本體，它并不是所有的屬性都是有意義的。然而，我們證明了其具有相當高的準確性（如前100個屬性為0.91，前5000個屬性為0.52）。

除了范圍，Biperpedia與普通本體的第二個區別特征是它立足于支持搜索應用。特別地，Biperpedia應該支持諸如解析用戶查詢，恢復Web表的列的語義以及識別文本中的句子是否是指實體的屬性等任務。傳統的本體已經被應用在以前的搜索（如[15,23]）。然而，傳統的本體往往是脆的，因為它們包含對世界建模的單一方式，包括任何類，實體或屬性的單個名稱。然而，傳統的本體往往是脆弱的，因為它們僅能通過唯一方式對世界建模，包括任何類，實體或屬性的單個名稱。因此，用本體支持搜索應用并不容易，因為將查詢或文本片段映射到本體可能會非常困難。

Biperpedia包括一組便于查詢和文本理解的結構。特別地，Biperpedia將屬性的一組常見拼寫錯誤，同義詞（一些可能相近的詞），其他相關屬性（即使特定關系未知）以及提及屬性的常見文本短語（[20]）附加到每個屬性上。

除了從Freebase本身引導外，Biperpedia還從兩個來源提取新屬性：查詢流和Web上的文本。查詢流是頻繁屬性的來源，但是在所有查詢中識別屬性便成了一個挑戰。Web文本的覆蓋范圍甚至比查詢流更廣，但是如以前的開放信息提取工作結果所示[9]，Web文本中存在很多無意義的屬性。本文貢獻如下：

l?我們描述一種新的本體結構，通過解釋Web查詢和文本適配搜索應用；

l?我們開發了一種用于從查詢流和Web文本中提取本體屬性的算法。特別是，我們開發了一種從文本中高精度提取屬性的方法，通過使用遠程監控來學習文本提取，這些提取器是從查詢流和Freebase中提取的種子屬性；

l?我們描述了一種新穎的算法，它使用屬性被提及的動詞來將屬性分類為數字（如GDP），原子（如CAPITAL）和敘述（如HISTORY）等類別。同時將屬性限制在現有模式中，用于進一步過濾Biperpedia中的屬性，以及用于諸如事實提取和問題回答的下游應用。如此分類是非常有價值的；

l?我們描述了一種將屬性附加到給定類層次結構中最合適的類的算法。該算法對于從Biperpedia貢獻屬性到其他本體是十分必要的；

l?我們通過證明Biperpedia可以幫助解釋Web表的語義來顯示其實用性。我們利用Biperpedia描述了一個模式匹配算法，相比于僅使用Freebase，我們可以解釋的表的數量超過4倍；

l?實驗驗證Biperpedia的高精度和對感興趣屬性的召回。特別地，對于前5000個屬性，我們獲得了超過0.5的精度。?在這些屬性中，只有1％存在于Freebase和1％在DBpedia?[2]。

本文的結構如下。?第2節提出問題，第3節描述了Biperpedia的架構。第4節描述如何從查詢流提取屬性，第5節描述如何從文本提取其他屬性。第6節描述了我們如何合并屬性提取和用同義詞增強本體。第7節評估屬性質量。第8節描述了用于在層次結構中放置屬性的算法。第9節描述了我們如何使用Biperpedia來改進我們對Web表的解釋。第10節描述相關工作，第11節總結。

2.?問題定義

Biperpedia的目標是找到可以與實體類相關聯的模式級屬性。例如，我們想要發現CAPITAL，GDP，LANGUAGES?SPOKEN和HISTORY作為COUNTRIES的屬性。Biperpedia不關心屬性的值。也就是說，我們不是試圖找到某個國家的具體GDP。

類層次結構：我們假設一組給定的實體類，例如COUNTRIES或US?PRESIDENTS（注意類名總是以較大的字體字母開頭）。這些類包括Freebase中的類型和標識Freebase類型子集的附加類。為了達到我們的目的，我們假設（1）類是高質量的（即它們與世界中自然實體集相對應），（2）對于每個類，我們都有一組實例（如法國是一個國家）。我們在類集合上還有一個子類層次結構（如美國PRESIDENTS是POLITICIAN的子類），但子類層次結構可能是不完整的。此外，同一層屬性重要性并不都是相同的（例如，在LOCATIONS類下，我們可以有一個重要的子類，如TOURIST?ATTRACTIONS和一個不感興趣的子類，如SPORTS?TEAMS?LOCATIONS）。

名稱，域類和范圍：Biperpedia中屬性的名稱是具有一個或多個字母的字符串，如POPULATION或LIFE?EXPECTANCY?FOR?WOMEN。每個屬性都有一個域類，即定義屬性的實體集合。一個屬性可以對應多個類。如POPULATION是類LOCATIONS和類BIOLOGICAL?BREEDS的屬性。因此，類名和屬性名的組合唯一地定義了一個屬性。屬性的域僅僅指定該屬性適用于該類的實例。但是，屬性通常附加在許多類中。例如，屬性POPULATION適用于超過2500個類（包括LOCATIONS的所有子類）。因此，Biperpedia會嘗試識別要附加屬性的最佳類（第8節）。Biperpedia附加一個范圍與每個屬性。范圍指定屬性值應屬于的類或數據類型。例如，CAPITAL的范圍是CITIES，而LIFE?EXPECTANCY的范圍是實數。我們只在簡單的情形下提出了解決計算范圍的問題。

同義詞和拼寫錯誤：Biperpedia的主要目標是能夠識別用戶生成的內容（例如查詢和文本）中的屬性。用戶顯然沒必要與Biperpedia中的屬性完全一致，他們也已經習慣于能自動修復常見拼寫錯誤的搜索引擎。為了支持盡可能多的召回，Biperpedia為每個屬性附加一組常見的拼寫錯誤和Biperpedia認為涉及相同的屬性（第6節）的一組同義詞。重要的是要注意，拼寫錯誤和同義詞取決于類。?例如，MOTER是PERSON類的MOTHER的拼寫錯誤，同時卻是CARS類中的MOTOR的錯誤拼寫。

相關屬性和提示：Biperpedia可以識別密切相關的屬性也很重要。?例如，Biperpedia應該知道MOTHER是PARENT的子集，FIRSTNAME是FULL?NAME的一部分，RURAL?POPULATION是POPULATION的一個組成部分。這樣的知識可以幫助搜索引擎回答更廣泛的查詢，并且當它們包含更詳細的數據時能夠檢索相關的Web表。例如，一個用戶查詢抽象地指定屬性（如POPULATION），同時存在包含諸如RURAL?POPULATION和URBAN?POPULATION組件屬性的高質量表。Biperpedia當前不識別所有可能的關系，并將所有這些關系折疊到子/超級屬性。

同樣，為了便于在文本和查詢中識別提及的屬性，Biperpedia還將一組提及該屬性值的句子和查詢模式附加到每個屬性上（參見圖1）。在這方面，Biperpedia非常類似于Patty系統[20]。?我們在本文中不討論檢測相關屬性的問題。

出處：由于Biperpedia的屬性是從多個源提取的，因此我們附加了發現屬性的數據源集合（Freebase，QueryStream，Text）和一些源特定的源信息（在第4節和第5節描述）。當合并兩個屬性時認為它們是同義詞，便會保留每個同義詞的來源。

與傳統本體的差異：Biperpedia和手動創建的本體之間的核心區別是Biperpedia嘗試找到在查詢和文本中人們認為與實體相關的屬性。相反，從設計上考慮手動策略會以更復雜的方式對屬性建模。例如，ARCHITECTURAL?STYLE是Biperpedia認為與MUSEUMS類相關的屬性。然而，在Freebase中將相同的屬性作為路徑建模：MUSEUMS具有包含一組建筑物的屬性BUILDINGS?OCCUPIED，同時類BUILDINGS具有屬性ARCHITECTURAL?STYLE。Freebase設計更加模塊化，但在查詢和文本中，人們卻指的是博物館的建筑風格，我們的目標是識別這樣的情況。當然，Biperpedia仍然可以使得MUSEUMS具有BUILDINGS?OCCUPIED屬性，BUILDINGS具有ARCHITECTURAL?STYLE的屬性。為了支持涉及遍歷本體中路徑的更復雜的推理，Biperpedia將需要識別其包含的冗余路徑。?一般來說，將Biperpedia這樣盡最大努力本體的優點和手工創建的本體相結合，為未來研究提供了更具有潛力的方向。

評估：鑒于我們的目標，我們以兩種方式評估Biperpedia的質量。?首先，給定Biperpedia對類C提出的屬性A，A是否是C的實例的合理屬性？第二，評估Biperpedia是否在應用程序中起作用。在本文中，我們證明了Biperpedia是理解Web表語義的不可或缺的工具。

3.?BIPERPEDIA系統

Biperpedia提取途徑如圖2所示。在最上層有兩個階段。第一階段從多個數據源提取屬性候選項，第二階段則合并所提取的屬性，并通過查找同義詞，相關屬性以及屬性的最佳類來增強本體。以FlumeJava管道[6]方式實現。

?

屬性提取：流水線通過從多個源（包括Freebase，查詢流和Web文本）提取屬性候選項開始。

從Freebase中提取的過程如下（注意，在Freebase中classes被稱為types，attributes被稱為properties）。首先遍歷所有類型，并檢索附加屬性作為Biperpedia的屬性。對于每個屬性存儲名稱，范圍類型和英語描述（如果存在）。另外還將Freebase屬性附加到它們的子類型上。例如，POPULATION是Freebase中LOCATIONS的屬性，但我們也將它附加到COUNTRIES和CITIES上。涉及查詢流和Web文本的提取分別會在第4和第5節中加以描述。

我們還嘗試從Web表中提取屬性[4]。然而，我們發現Web表中的絕大多數屬性是上下文敏感的。在第9節中，我們可以使用Biperpedia來更好地解釋Web表中的屬性。

本體增強：一旦提取完成，即合并屬性候選集合，并通過域類對它們進行索引（例如，我們收集COUNTRIES的所有屬性）。?因此，以下步驟在單個域類中完成。

拼寫錯誤：從識別哪些屬性是正確屬性名稱的常見拼寫錯誤開始。我們的實驗表明，拼寫錯誤占了4％的屬性，但有些卻頻繁發生并最終是排名靠前的屬性（如FALG是COUNTRIES查詢的頂級屬性之一）。自然，相比于其他來源，拼寫錯誤在查詢流中出現得更加頻繁。

同義詞：接下來，Biperpedia識別屬性名稱中的同義詞（見第6節）。實驗表明，32％的（拼寫無誤）屬性可以被認為是其他詞的同義詞。注意，原則上，當本體用于解釋查詢時，我們可以嘗試在查詢時檢測拼寫錯誤和同義詞。然而，在Biperpedia中存儲的拼寫錯誤和同義詞為分析許多之前的查詢大有裨益。此外，拼寫錯誤和同義詞不會經常改變，因此實時分析查詢并不能帶來明顯的益處。

子屬性：我們目前使用兩種啟發式方法來識別子屬性：（1）如果我們在Web上（使用諸如[14]的技術）找到足夠的證據證明“A?IS?AB”，其中A和B都是屬性，我們就認為屬性A是B的子屬性（例如，MOTHER?IS?PARENT）。（2）如果我們找到一對屬性，其中一個屬性包含一個修飾符作用在另一個屬性上（如RURAL?POPULATION?and?POPULATION），我們認為第一個是第二個的子屬性。雖然存在噪聲，這些啟發式算法在實踐中產生的結果卻十分有用。

最佳類：Biperpedia輪流處理每個屬性，并嘗試找到層次結構中的最佳類以附加之。

以數字/文本/非原子分類：Biperpedia將每個屬性分為數字（如COFFEE生產），原子-文本（如POLICE-CHIEF），非原子（如HISTORY）或無四類。這些標簽對于諸如手動策劃或僅提取原子屬性的事實，又或者推斷數字屬性的測量單位和范圍是大有裨益的。

4.?查詢流提取

查詢流是反映用戶興趣屬性的絕佳源。挖掘查詢流的主要挑戰是涉及實體屬性的查詢與其他查詢混合在一起，并且難以將它們分開。Biperpedia從一組360億個匿名不重復查詢中提取屬性，步驟如下：

?

查找候選屬性：最初，我們考慮所有形式如“what?is?the?A?of?E?”的查詢來查找候選屬性名A.例如，我們可以在查詢流中找到查詢“what?is?the?population?of?france”。?我們用A表示A的所有值。

接下來，我們考慮形式“A?E”或“E?A”存在的所有查詢，其中A∈A，E已經被實體識別器標記為實體[12]。請注意，由于此簡短形式在查詢中更常見，因此該步驟所匹配的查詢數量將遠多于第一步。特別地，我們會發現屬性A應用于更多的實體，這對于我們管道的其余部分是至關重要的。

結果以（A，E，f）的三元組集合形式輸出，其中A∈A是候選屬性名稱，E是實體字符串，f是查詢“A?E”或“E?A”在查詢流中出現的次數。

協調到Freebase：此步驟的目標是將實例中的屬性提示提升到類，以便我們可以匯總它們。?具體來說，對于每對（C，A），其中C是類，A是候選屬性名稱，我們計算兩個值：

l?InstanceCount（C，A）：在查詢流中提及形式為“A?E”或“E?A”的查詢的C中不同實體E的數量；

l?QueryCount（C，A）：“A?E”或“E?A”形式出現的流中查詢的總數，其中E表示C的實例。

InstanceCount（C，A）指示屬性A在C的實例中出現的頻率，而QueryCount（C，A）指示屬性A在查詢流中出現的頻率。這些值指示特定A是否是屬性?-?具有低計數的候選屬性A通常是噪聲。對于每個三元組，（A，E，f），我們進行如下處理（見圖3）。

l?在Freebase中協調E與實體E。這個步驟本質上是啟發式的：有時我們會將e匹配到錯誤的實體，更有甚者找不到匹配項。識別器返回候選實體的排名列表后，我們會保守地選擇第一個。有些情況下，我們會錯過有效的映射（如對于蘋果，識別器將返回公司和水果，但我們只選擇公司）。然而，我們可以保守，因為即使我們錯過了一些實體，它也不會降低模式級提取。仍有大量公司名不會與水果混淆，因此能夠以較高的可靠性發現公司的財產。

l?通過給定E的值查找Freebase中的所有類C?1...C?n，其中E已知隸屬其中。對于每對（C?I，A），InstanceCount（C，A）的值加1，并將C添加至QueryCount（C，A）。

刪除共同引用：搜索查詢中通常的模式是通過限定符跟蹤實體。例如，許多用戶查詢barack?obama總統（美國的每個總統亦如此），于是我們可以提取PRESIDENT作為美國總統的頂級屬性，而這并不是理想做法。為了過濾這樣的提取，我們在網絡文本中查找表明BARACK?OBAMA是總統的證據。通過運行一個標準的參數解析算法[13]來查找字符串“barack?obama”和“president”在文本語料庫中指向同一個實體的次數是否足夠多。對于共同引用字符串對，我們不增加計數器InstanceCount（C，A）和QueryCount（C，A）。而是維持一個計數器CoReferences（C，A）來跟蹤共同參考事件的數量。

輸出候選屬性：Biperpedia保留InstanceCount（C，A）高于設定閾值的任意對（C，A）。?屬性的來源包括計數器InstanceCount（C，A）和QueryCount（C，A）。

5.?從網頁文本中提取

Web上的文本為Biperpedia提供了更豐富的屬性來源，并在很多方面與從查詢提取的屬性互補。雖然查詢能夠反應人們所希望的屬性，但文本能夠提供更多實體的百科全貌概覽（如維基百科，新聞文章，新聞稿，產品手冊等）。例如，雖然許多人查詢一個城鎮當前的MAYOR（市長），但對其FIRE-CHIEF（消防隊長）的查詢卻相對較少。此外，從文本中提取屬性還可以用來確認該屬性的來源是查詢還是從其他來源提取。在本節中，我們將介紹如何從文本中提取Biperpedia的屬性。所面臨的主要技術挑戰是從文本中提取屬性可能有很多無關信息。在本節中我們的主要技術貢獻是展示通過使用查詢流和Freebase的提取來訓練高質量的文本提取器。

但在描述提取過程之前，我們先回顧并討論兩個廣泛存在的問題：（1）我們是否可以像查詢一樣手動定義一小部分模式來取代提取器？?（2）我們的提取目標是開放域，那么是否簡單地利用現有的開放信息提取系統，而不是設計一個新的提取器？

第一個問題的答案是否定的，我們將在本節稍后提供實證證據證明在實踐中需要大量的提取模式。直觀的原因是，在文本中，屬性可能與實體以各種方式共同表達，而不像簡短的查詢文本，僅允許幾種可能的屬性表達。

第二個問題的答案也是沒有，下面將詳細討論之。

我們可以利用現有的開放域系統嗎？如前所述，Biperpedia的目標是模式級的屬性提取，而大多數現有的開放域提取系統則輸出事實。原則上，可以使用常規開放域提取器的輸出來獲得屬性而不是屬性值。例如，可以提取（PERSON，STARRED?IN，MOVIE）的許多實例，并假定STARRED?IN是適用于PERSON的屬性。然而，該方法存在一些限制，這在各種現有的開放域提取器的上下文中被最好地表現出來。

ReVerb系統[9,10]在實體之間提取類似“加星標”和“被選為”地二進制關系。每個關系被限定為動詞短語或滿足詞性標簽上以動詞為中心的正則表達式。由于許多屬性如CULTURE或POLICE-CHIEF通過動詞短語表示顯得不自然，因此存在局限性。其次，對于刪除重復動詞短語并規范化到一個名詞短語的形式是不平凡的。例如，我們需要能夠將STARRED?IN，IS?THE?STAR?OF和HAS?ACTED?IN歸一化為名詞短語形式LEAD?ACTOR，同時排除附帶表達反向屬性的緊湊短語，如STARRED。

OLLIE系統[18]是對ReVerb的改進，因為它也引入名詞短語模式，所以可以提取諸如POLICE-CHIEF的屬性值。雖然有所改進，但仍然不能正確處理像“巴西的咖啡生產增加5％”的情況。在這句話中，提取的關系將會是“巴西咖啡生產”和“5％”之間的“升”，而不是巴西和咖啡生產之間的理想關系。直接學習連接巴西和咖啡生產的模式顯得更為簡單。

最后，NELL系統[5]有一組限制在≈600的關系（包括反轉），所以不能得到一個巨大的屬性集。

鑒于以上所述問題，我們采取直接學習將實體連接到屬性的模式的方法。實體和屬性都假定為名詞短語，這就避免了刪除屬性的動詞重復形式到規范名詞短語的問題。值得注意的是，即使在名詞短語屬性的情況下也需要刪除重復數據（如LEAD?ACTOR和STAR?ACTOR應該相同），但是在這里我們使用第6節所描述的同義詞檢測系統。

由于我們已經從Freebase和查詢流中提取了高質量的屬性，因此應用遠程監控從文本中提取屬性就顯得很自然了。

5.1.?通過遠程監控提取

Biperpedia通過誘導一組（實體，屬性）的提取模式并將它們應用于文本語料庫來從文本中提取屬性。這些模式利用一組標準自然語言處理（NLP）原語。例如，一旦我們在文本中識別出名詞短語，我們就可以應用詞匯模式“?A?of?E?”，其中A和E與名詞短語匹配，并分別表示屬性和實體。類似地，一旦文本被依賴解析器處理（這里，依賴關系標簽所指的是“possessive（占有）”），解析模式“E?poss>?A”就會將第二名詞短語標識為屬性。我們注意到，誘導模式需要擴展以提取屬性的值。

我們使用遠程監控[19]和從Freebase提取的高質量屬性以及查詢流來從文本中誘導提取模式。遠程監控已經成功地用于各種大規模提取任務，如[19,27]。在遠程監控中，不提供監控語料庫（獲取代價高），而是提供包含了我們希望提取的類型樣本事實的知識庫（KB）。在我們的例子中，KB是從已經由Biperpedia提取的頂部屬性創建的。之后，我們假設如果在一個句子中看到該KB中的一對相關實體，則該事實表示對應關系。例如，考慮圖4的左半部分。假設我們知道COFFEE?PRODUCTION是巴西的一個屬性。如果我們看到文本“巴西的咖啡生產增長了5％”，我們可以斷定詞匯模式“The?A?of?E”和解析模式“A?prep>?of?pobj>?E'是連接屬性和實體的候選模式。

我們已經獲得按頻率排序的候選模式的聚集列表，以及它們覆蓋的已知屬性的數量。表1展示了由此誘導的一些頂部詞法和解析模式。我們選擇由至少10個不重復的（實體，屬性）對得出的所有模式，并且在文本語料庫的子集中至少訪問10次。

?

使用誘導模式的屬性提取：我們對所有文本應用以下自然語言預處理器：詞性標記器，依賴性解析器，名詞短語分割器，命名實體識別器，參數解析器和實體解析器。這些步驟是必要的，因此我們可以定義如前所述的特定提取模式。參數解析器將代詞和名詞解析為實體，從而增加覆蓋。例如在文本“約翰·史密斯住在倫敦。?[他的]（妻子）...“，參數解析器會告訴我們”他的“和”約翰·史密斯“是同一個實體，所以”妻子“實際上是”約翰·史密斯“的一個屬性。?實體解析器將所提到的實體映射到Freebase，使我們可以像對查詢流一樣實現從單個提取到類的推廣。

?

誘導模式隨后通過使用詞法和解析模式匹配器在大量NLP處理的網絡爬蟲語料庫（圖4的右半部分）上加以應用。非名詞性（即名詞）匹配的屬性將被丟棄。該步驟輸出形如（A，E，E-ID，f）的一組提取元組。除了E-ID是E的Freebase?id外，這些元組與來自查詢流的提取具有相同的形式。這些元組以與查詢流完全相同的方式進行處理。

圖5展示了頂部誘導提取模式的產量。雖然我們誘導了超過2500個模式，但前200個模式占比卻達到提取的99％以上。同時有超過6％的提取沒有模式覆蓋，這意味著我們確實需要一個模式感應管道來學習大量的模式，而不能簡單地使用一小組手寫模式。

?

5.2.?屬性分類

我們已經可以從Web文本中提取的大量屬性仍然需要一個方法對添加到Biperpedia的屬性加以選擇。鑒于Biperpedia的預期用途（例如，添加到Freebase，問題回答和表解釋），Biperpedia將關注于具有清晰定義的值的原子屬性。特別地，我們的目標是區分原子數值（如COFFEE?PRODUCTION）以及來自非原子屬性（諸如CULTURE和HISTORY）的原子文本屬性（如POLICE-CHIEF）。將屬性分類為原子與非原子還為未來檢測元數據（如范圍和單位）以及最終提取屬性值提供了可能。

技術挑戰是對屬性在不提取值的情況下進行分類（這是一個更難的問題）。下面描述的算法演示了自然語言處理的另一個好處。具體來說，因為我們的文本語料庫已經做過預處理，所以語料庫中每個句子的依賴性語法分析信息都已經掌握了。由于每個屬性是一個名詞短語，我們知道句子中的動詞是一個語法主題（由nsubj依賴性標簽指定）。我們發現，一個屬性的最頻繁的動詞列表可為分類任務提供很多信息。例如，通過查看文本“巴西的咖啡產量增加5％”，我們可以推斷咖啡生產是一個數字屬性，因為動詞'增加'與數字屬性正相關。同樣，通過查看“紐約警察局長今天辭職...”這一文字，我們可以推斷出POLICE-CHIEF不是一個數字屬性，因為動詞'辭職'與數字屬性負相關。

注意我們的分類并不詳盡，因為存在其他種類的屬性在我們的三個類別（如電話號碼，日期，拼寫錯誤，離散值屬性等）中未完全覆蓋。他們將被分到第四類其他，這是一個相對非結構化的“背景”類別。接下來將描述如何為這三個更結構化的興趣類別學習三個獨立的二元分類器。

特征。原始特征列表只是top-k動詞的集合，是文本語料庫中屬性的nsubj父節點，其中k是通過交叉驗證設置的。其與屬性一同從文本中提取而來（參見圖4）?？梢酝ㄟ^添加額外的語言提示（如形容詞，修飾符和附加到屬性的特殊子句）來豐富此特性空間，這是我們未來工作中需要探索的方向。

表2展示了一些樣本屬性的前幾個動詞。如前所述，像COFFEE?PRODUCTION和ENROLLMENT這樣的數字屬性與諸如增加，下降等動詞詞義具有很強的相關性。經常出現的動詞如have,?say,?become等存在于每個類別中，最終在訓練期間將給予低權值。

?

然而因為我們只有有限的訓練語料庫，使用原始詞匯作為特征會因為巨大的詞匯量以及測試時未知的特征導致過度擬合。因此，我們采用相對標準的特征散列技巧將動詞向量減少到具有預設維度d的標準空間內。更具體地，每個動詞v?i都被Hash到維度h（v?i）mod?d的標準空間中，其中h是散列函數。散列具有額外的優點，即不需要繞過特征詞典，僅需存儲散列函數h和d。

分類器。使用邏輯回歸模型組合獲得的最終散列特征，其權重由小型手動標記屬性語料庫學習得到。使用L1和L2來對模型進行正則化，即優化以下訓練目標：

?

其中W是待訓練的權重向量，F（xi，yi）是用于訓練屬性xi的哈希特征向量，標記為yi∈{-1,1}，λ1，λ2是使用交叉驗證的L1?/L2超參數集合。該目標使用現成的標準二階解算器進行優化。我們著重為三個感興趣的類別學習單獨的模型（即W向量），并且通過網格搜索和交叉驗證為每個分類器分別調整超參數λ1，λ2，d，k。

實驗。我們使用5層折疊的交叉驗證手動標記的1212個屬性的語料庫訓練和評估三個分類器。這些屬性屬于16個不同的類，以避免在訓練期間的任何偏差。我們將我們的分類器與一個簡單的基準進行比較，給每個屬性賦予多數標簽（正或負）。我們的目標是發現動詞簽名在該基線上有多少有助于對屬性的分類。

表3列出了三個任務的分類結果，使用超參數的最佳設置。感興趣的兩個指標是：僅通過正標簽確定精確度/召回/?F1（即在三個任務中分別將屬性標記為數字，原子文本或非原子），以及在正和負標簽上兩者的總體精度。我們發現我們的分類器可以識別具有相當高的正F1分數和總體準確性的原子屬性（數字和文本）。數字屬性特別容易識別動詞簽名，總體精度為93.9％。而非原子屬性則顯得相對較難，即使有動詞簽名幫助我們在基線上提高了近10個絕對點，其仍具有較低的F1分數。

?

我們觀察到三個任務需要不同長度的動詞簽名（即k）。只有50個動詞足以識別數字屬性，其他屬性需要更多的動詞憑證來做出決定。圖6繪制了不同k值，三個分類器的正標簽F1以及總體精確度。我們發現，對于所有的分類器，性能提高到一個點后（特定k）就開始逐漸減少/平坦化。這是可預料的，因為系統最初受益于逐漸增多的信息動詞，隨著動詞數量的增多辨別力便會下降，性能也便隨之下降。總體而言，我們觀察到50-200個動詞足以以相當好的精度對屬性進行分類。

?

6.?同義詞檢測

一般人們會在查詢和網絡文本中以不同的方式引用相同的屬性。例如，TOURIST?ATTRACTIONS和TOURIST?SPOTS是同義詞。此外，查詢流包含許多拼寫錯誤，而用戶會認為搜索引擎將自動修復它們。Biperpedia的質量在很大程度上取決于其識別同義詞和拼寫錯誤的能力。我們注意到，拼寫錯誤和同義詞都取決于屬性附加的類。

檢測同義詞和拼寫錯誤是值得自己詳細的處理，并不是本文的主要貢獻。?為了完整性，我們會描述Biperpedia如何解決這些問題。在這兩種情況下，我們使用內部的技術處理查詢擴展[7]和拼寫校正。

我們依靠搜索引擎實現拼寫校正。給定類C的屬性A，搜索引擎將為查詢“C?A”提出的拼寫校正。如果一個校正是C的屬性A'，則我們認為A是A'的拼寫錯誤。例如，給定類BOOKS的屬性WRITTER，搜索引擎將建議books?writer是books?writter的拼寫校正。

為了檢測同義詞，我們訓練SVM分類器，該分類器在一對屬性A?1和A?2上使用以下特征：（1）Jaro-Winkler文本屬性之間的相似性，（2）一個屬性是否是另一個的子屬性，（3）這兩個屬性是否已知為WordNet中的反義詞[11]，以及（4）查詢擴展的相似度。具體來說，我們比較“C?A?1”和“C?A?2”的查詢擴展結果。擴展集合高度重疊說明A?1和A?2可能是同義詞。基于我們在本文中沒有報告的實驗，我們估計基于SVM的同義詞精度高達0.87。

7.?屬性質量

在本節中，我們評估Biperpedia屬性的質量，并將其與DBpedia?[2]進行比較，DBpedia是一個自動從維基百科的InfoBoxes中提取的本體。

7.1.?實驗設置

Biperpedia的當前版本使用略微超過10,000個類的層次結構構建。提取之后，合并同義詞并僅將屬性附加到最好的類上，最終得到了1.6M類-屬性對，其中有67,000個不同屬性名。（我們注意到，將屬性附加到最佳類的步驟將類-屬性對的數量減少了近50％。）如表4所示，Biperpedia大約是DBpedia的30倍。我們從Freebase中提取所有屬性，但每個類僅從查詢流中提取8000個屬性，剩余從查詢流中未提取的文本中添加4000個屬性。我們注意到，從Freebase中提取的屬性數量少于屬性總數的6％。

?

我們實驗了10個代表性類別（表5），所選擇的一些寬泛，另一些狹隘。依舊顯示相應的DBpedia類中的屬性數量（如果存在）。

?

7.2.?總體質量

為了測量精度，我們設定一些k值，從top-k中手動標記100個隨機選擇的屬性（當k≤100時標記為所有）。然后從3份評估中使用投票方式來確定屬性對于該類是好還是壞。在表6中，我們使用兩個不同的屬性排名來測量精度：按查詢排序?-?通過查詢流中出現屬性的類的實例數對類的屬性排序，按文本排序?-?在文本中進行同樣操作。?“精度”列指示標記為“好”的屬性的分數。隨著k的增加精度會下降，直到5000仍然超過0.5。注意到之前的工作[16,21]在k?=?50時精度略低于本文k?=?1000的情況。結果還表明除了此5000個以外還有許多的屬性可以添加到Biperpedia，但是我們需要更集中的技術來識別它們。Freebase列顯示良好屬性也出現在Freebase中，其下降迅速。值得注意的是當k?=?5000時99％的屬性是Freebase的新屬性，這顯示了Biperpedia模式擴充的重要性。類似地，DBpedia列顯示良好屬性也存在DBpedia中（使用表5中存在于DBpedia的5個類別），其也隨著k的增加而下降。

?

當按文本排序時，屬性的精度比由查詢流排序時屬性的精度稍低?？梢越忉尀?#xff1a;從查詢流中提取可以比一般文本更精確。然而，在較低的等級下精度是類似的。雖然我們未在表中列出，但有趣的當k值較小時，查詢流和文本中出現的屬性的精度是相似的，但當k?=?5000時精度差卻高達8％。這是因為當一個屬性在一個源中非常頻繁地出現時，它不需要任何佐證，但是隨著頻率降低，佐證成為一個因素。

表7顯示了屬性的等級（k）與其同義詞數量之間的有趣關系。?隨著k增加，每個屬性的同義詞減少。例如，UNIVERSITIES類每top-10屬性有2.8個同義詞，但每top-1000屬性只有0.75個同義詞。因此排名較高的屬性傾向于以多種形式表示。

?

7.3.?討論

Biperpedia的分析揭示了幾個重要的發現。首先，精度損失的最重要原因是由于映射字符串到Freebase中的實體的錯誤。例如，對于諸如COUNTRIES或US?PRESIDENTS之類的實體鏈接相對比較容易，當k=5000時精度高達20-30％，而如FILMS和HOTELS等存在更高頻率將字符串錯誤地鏈接到實體的，精度就會低于該數量。幸運的是，改進實體鏈接正在持續進行中。同樣，Biperpedia不會提取其實例不足以在Freebase中存在的對象類的屬性，如SPOONS。為了提取這些類的屬性，Biperpedia仍然可以使用相同的提取模式，但不應該嘗試將模式中的實體映射到Freebase，而是假定每一項是適當類的匿名實體。

其次，我們注意到許多高頻查詢的屬性并不具體（如CULTURE，HISTORY）。這可以通過用戶開始對這樣的查詢主題的探索來解釋。我們還注意到，存在可以與其他屬性相關聯的更多屬性的類。例如，地理位置往往具有許多屬性，因為數量通常是相對于地理測量的。

最后，我們意識到Biperpedia的優勢之一是提取多標記屬性。這些屬性往往更豐富，并且經常在Web表中出現。為了提取額外的這樣的屬性，我們以示例解釋下面所實現的規則。如果POPULATION或RURAL?POPULATION是來自查詢流的高度排名的屬性，那么我們推斷諸如URBAN?POPULATION一類的共享相同句法根（即“population”）的其他屬性也是良好的，即使他們支持度并不高。對于表5中的每個類，我們從Web文本的前5000屬性之外的屬性中抽樣了100個多標記屬性，對其隨機子集進行評估，得到平均精度為0.67。這比Web文本的前500個屬性的精度（0.64）要好（表6）。使用這種方法，我們能夠在維持平均精度的前提下使Biperpedia的大小翻倍。我們認為Biperpedia表明前5000以外屬性中有很多良好屬性待挖掘，但我們需要更集中的技術來獲取。

8.?發現最佳類

如前所述，Biperpedia會將一個屬性附加到它相關層次結構中的每個類。當我們想要驗證一個屬性是否與一個特定類相關時該做法是行之有效的，但是如果我們希望創建一個更模塊化的本體或找到可以適配Freebase的屬性，就需要找到最佳類供屬性附加。

舉例說明找到最佳類的技術挑戰。假設我們要將屬性BATTERY?LIFE分配給圖7所示的層次結構中的類。最頂層的CONSUMER_PRODUCTS太寬泛，因為并不是所有的消費產品（例如SHOES）都有電池。?相對的葉節點SLR_DIGITAL_CAMERAS和COMPACT_DIGITAL_CAMERAS太具體，因為任何數碼相機都有電池。因此，DIGTIAL?CAMERAS可以被認為是BATTERY?LIFE的最佳類。使用類似的參數，COMPUTER_PERIPHERALS（DIGITAL_CAMERAS的兄弟類）也可以被視為BATTERY?LIFE的最佳類?；蛘?#xff0c;如果BATTERY_LIFE適用于消費產品的絕大多數子類，我們就可以將其附加到CONSUMER_PRODUCTS。因此，尋找最佳類的挑戰就是找到不太一般又不太具體的類，且能簡化本體。

?

下面描述的算法的關鍵思想是為一個類中每個屬性計算支持。然后將屬性在該類中的支持度與其在父類和同級類中的支持進行比較，以確定屬性的最佳位置。重要的是，支持度的概念使我們能夠考慮多種方式做出安置決策。

我們的算法使每個屬性的放置決定獨立于其他屬性。一個有趣的未來研究方向是使用先前的屬性放置決定來驅動后續的放置。

8.1.?放置算法

算法1計算屬性A的最佳類OA。非正式地，對于每個屬性A，算法以自底向上的方式遍歷A被標記為相關的類的每棵樹（即包含（C，A）的類C的每棵樹）。對于每對類和屬性（C，A），我們計算C中A的支持度S（C，A），支持度從來源計算。例如，對于從查詢流中提取的屬性，支持度是包含A的C的實例數和C中屬性的實例數最大值之間的比

?

文本提取的支持度也以同樣的方式計算，且來自Freebase的屬性的支持是1。我們將S（C，A）定義為從任何源獲得的最大支持度。

算法需要做的關鍵決定如下。當有幾個兄弟節點有足夠的支持度時，他們都應該在OA中，或者我們應該繼續類層次結構。?為了解決這個問題，算法計算兄弟節點的多樣性測量。?如果兄弟節點之間幾乎沒有多樣性，我們繼續遍歷樹。如果有顯著的多樣性，即只有少數兄弟節點有足夠的支持度，即輸出這些兄弟節點。多樣性定義如下。

?

其中C?1?...C?n是兄弟類。當多樣性高于閾值θ（算法1中的第9行）時，我們將所有兄弟節點中支持度最高的節點添加到OA中。在我們的例子中，對于屬性BATTERY?LIFE，CONSUMER_PRODUCTS下的同級類的多樣性將很高，因為一些消費產品具有電池，而另外一些沒有。因此擁有高支持的兄弟類將被添加到OBATTERY?LIFE。我們在實驗中單獨調整θ值。

8.2.?評估

我們對Biperpedia的屬性應用算法1，評估分配50個屬性到1100個類的結果。對于每個分配評估其是否滿足（1）正確，（2）應該是直接父節點，（3）其中一個直接子節點，（4）?除同一層次的直接父子節點的類，或（5）完全錯誤。?如果屬性被分配給其最佳類之一就被稱為精確的，若被分配給最佳類的直接父節點或子節點則稱為近似的。我們的結果考慮了幾個精度度量：

?

l?M?exact：精確分配占所有分配的比率。

l?M?approx：近似分配占所有分配的比率。注意，近似賦值仍然是有價值的，因為人們只需要考慮類的小鄰域以找到完全匹配。

與等同，但僅在第七節應用良好。

為了演示多樣性指數的好處，我們還與一個strawman算法進行比較，當考慮具有足夠支持度的節點n時，使用以下規則自下而上遍歷樹。當n的父節點的支持度等于n，或者有5個（調整以在實驗中最好表現）及更多具有與n支持度相同的孩子節點時，算法沿著樹繼續遍歷。否則，該屬性將分配給n及其任何有足夠支持度的兄弟節點。

表8所示的評估結果表明當θ為0.9（我們只選擇實驗中的幾個值列在表中）時結果最佳，不管是未過濾還是過濾的屬性算法都比strawman優越超過50％。即使是未過濾的屬性，我們的算法也以72％的精度近似匹配，這為導入Biperpedia屬性到另一個本體提供了一個良好的起點。與在θ?=?1.0不被計算，因為在這種極端情況下，屬性A將僅被分配給每個無直接父節點的相關根節點。實驗中，α的值設置為0.1，但是我們注意到α（算法1中的第10行）主要影響返回類的數量，而不是結果的精度。

?

分析算法的錯誤是未來工作的一個有趣的挑戰。我們的多樣性措施高度依賴于人們對特定實體的興趣。例如，用戶經常查詢總統的兄弟，但不是查詢其他政府職稱的人。結果，類GOVERNMENT_TITLES的多樣性變得很大，并且算法會將屬性BROTHER分配給類PRESIDENTS而不是GOVERNMENT_TITLES。但是，GOVERNMENT_TITLES是PRESIDENTS的父類，顯然對BROTHER更加適合（但不是最終賦值）。一種可行的解決方案是在多樣性指數的計算考慮出現的頻率。

9.?解釋WEB表

最后，如果Biperpedia可以改善搜索應用，其將是有用的。在本節中，我們展示了Biperpedia極大地提高了我們恢復Web表語義的能力。

在網絡上有數以百萬計的高質量HTML表格，內容非常多樣化。除了回答在搜索引擎上許多用戶的查詢，通過有趣的方式對這些表進行組合可以產生新的數據集和發現。最近的幾項研究主要集中在利用這些表[1,4,17,25,26]。Web表的一個主要挑戰是了解表中表示的屬性。例如，圖8中的表格顯示了SHIPS的GROSS?TONNAGE和LOAD?CAPACITY。在本節中，我們將介紹如何使用Biperpedia解釋Web表。解釋Web表是指使用Biperpedia屬性附加的過程。我們可以將一個Biperpedia屬性附加到一個特定的列（我們稱為列映射），或者如果不能定位精確的列或屬性名稱不是由單列，就將屬性附加到整個表（表映射）。如果我們可以將Biperpedia屬性附加到表上，則當關鍵字查詢包含這些屬性時，搜索引擎可以給包含該表的頁面賦予更高的權重，因為該屬性在頁面上比在其他地方的隨意出現具有更重要的作用。因此，可以更準確地檢索關鍵字查詢的表。

?

翻譯網頁表也是Biperpedia召回的標志。特別是，使用Biperpedia解釋的表的數量是Freebase的4倍。

9.1.?映射算法

我們描述了我們計算列和表映射的算法，原則上，它是一個關于模式匹配問題的變體，其中有大量的文獻[8]。區別就是我們不給定一對模式及其對應表。相反，表的最佳描述屬性可能在周圍文本或頁面的標題中。周圍文本對于解釋沒有模式的Web表特別重要。?因此，我們算法的任務是將Biperpedia屬性匹配到周圍文本和頁面標題中的列標題或標記n-gram。主要分兩步。

（1）預處理：給定具有表頭H?1...H?n的表，其中H∈H1...H?n，我們創建一組匹配的字符串集合SH。該集合包括H以及：

l?如果H超過3個標記，則我們將所有2-grams和3-grams添加到SH中。

l?如果H包含標記or或and，我們將該標記之前和之后的文本添加到SH中。

l?如果H列中的值都是C類的成員，則我們將C的名稱添加到SH中。

我們還將以下字符串添加到SH中，但是只有當以上匹配項都找不到時，才會考慮以下情況：

l?如果H有多個標記，則通過連接單詞首字母來添加縮略詞。

l?我們添加屬性的句法解析的根（例如POPULATION是RURAL?POPULATION的根）。

我們還從頁面標題的文本或緊鄰表格的文本中所有的2-grams和3-grams中創建一個表級別的字符串集合T.

（2）匹配：我們假設每個表與描述其主題列中實體層次結構中的類C相關聯。?如果我們沒有主題列，或者類的預測是低置信度的，便忽略該表。

考慮Biperpedia對于C類的所有屬性，嘗試將它們的名稱與T和SH1...SHn中的元素相匹配。我們使用Jaro-Winkler字符串相似性來查找近似匹配。若在SH中找到一項匹配，就將它們輸出為列匹配，若在T中找到匹配，則將它們輸出為表匹配。

示例：在圖8中，主題列的類為SHIPS。列“Beam”直接映射到屬性BEAM，列“GT”作為首字母縮略詞映射到GROSS?TONNAGE。在預處理期間，第四列將標記為COUNTRY，并將映射到屬性COUNTRY。LOAD?CAPACITY屬性將作為表映射輸出。事實上，列“Beam”，“Max?TEU“和”GT“確實描述了船舶的負載能力。圖9所示為Biperpedia為沒有模式的表找到有用映射的示例。

?

9.2.?評估

我們評估了映射算法對從Web提取的大約200個表的精度。我們選擇了質量相對較高的表格，而不是呈現非表格內容的HTML表格。同事使用了WebTables的主題列注釋器以及與其相關的類[24]。除了所有表集合，我們還做了如下實驗：（1）一組具有更高質量和更多列的維基百科表，（2）沒有模式的表的集合（即傳統的模式匹配算法不會返回任何內容）。

為了評估列匹配，我們測量了精度（正確匹配的百分比）和召回率（正確映射列的占比）。?然而，并非所有列都具有相同的重要性，并且表映射具有很多優勢。為了測量這一點，我們假設每個表都具有一個或多個代表性屬性。直觀地，這些屬性應該能使表從查詢中檢索，因為它們保存了表的本質。例如，屬性LOAD_CAPACITY可以被認為是代表圖8中的表，而LIFE?SPAN代表了圖9中的表。代表性屬性不需要對應于表中的單個列。我們請求我們的評估者判斷映射是否捕獲他們認為的表的代表屬性。

9.2.1.?解析質量

表9展示了基于3個評估器的質量評價結果。Representative列顯示至少找到一個正確的代表屬性的表的數量。Overall?(P/R)列為所有映射的平均精度/召回率。Avg.?P/R?per?table計算每個表的精度/召回率，然后計算所有表的平均值。對于完整數據集，有46％是正確的（每個表51％），所有列的75％由一個屬性（每個表78％）覆蓋。我們能夠在82％的時間內使用代表屬性來捕獲表的本質。

?

僅考慮維基百科表，精度和召回率略低的兩個原因有：首先，維基百科表往往有更復雜的周圍文本，會導致一些錯誤的映射。這一點可以通過使用IR技術，通過基于周圍文本的重要性計算單詞的權重來解決這個缺陷。第二，維基百科表往往有更多的列，因此更難正確地映射。

最后，我們考慮了一組沒有模式行或WebTables不能識別模式行的表。對于這些表，沒有常規模式匹配技術可以提供任何解釋。在某種意義上，這些是在語料庫中最難解釋的表。?然而，通過生成表映射，我們仍然能夠找到78％的表的代表性屬性，并獲得重要的精度和召回率值，雖然略低于維基百科表。這個實驗證明，通過使用一個大的屬性本體，即使他們沒有模式，我們依舊能夠找到描述Web表的方法。

9.2.2.?與Freebase的比較

下一個問題是這些映射中有多少是由于Biperpedia與已經存在于Freebase中的屬性。?表10中的結果表明絕大多數是由于Biperpedia的額外屬性。第一組列顯示了到Biperpedia屬性的映射數量，映射到Freebase屬性的數量以及它們之間的比率。例如，當映射完整數據集時，807正確映射中的142個是Freebase屬性，因此?Biperpedia與Freebase相比，覆蓋率提高了5.7倍。?第二組列顯示了用于映射到代表性屬性的各個量。對于代表性屬性，改進因子甚至更高，因為代表性屬性更復雜，因此不太可能在Freebase中找到。對于沒有模式的表，相對覆蓋率甚至更高。

?

9.2.3.?錯誤分析

表11的頂部顯示了我們的算法的兩個最常見的錯誤，原因是周圍文本和頁面標題中的噪聲標記n-gram被映射到與HTML表無關的屬性。我們可以通過使用更好的IR?/?NLP技術來優化與表格更“相關”的n-gram來減少此錯誤。?最后一個原因是使用查詢擴展對列標題的各種不正確的字符串匹配。這里，更明智地使用查詢擴展可以減少錯誤。

?

表11的下半部分考慮檢測代表性屬性中的錯誤。?最大的錯誤原因是當表描述涉及另一個常數時（例如，不同年份的Ballon?D'Or獎的獲獎者）?？梢韵胂?#xff0c;我們的類層次結構應該包含類BALLON?D'O?R?W?INNERS，但無論多么詳細，類層次結構總是有空隙。第二個原因是當列標題或上下文中沒有足夠的信息與屬性進行比較時。這里，到頁面的外部鏈接可以提供額外的證據。第三個原因是三個評估器同時否決任何代表性屬性，但一些屬性確實是代表性的。第四個原因是Biperpedia的覆蓋不足，僅適用于9％的情形。最后的原因是當屬性名稱不是2-gram或3-gram，并且需要更復雜的名詞短語識別。

10.?相關工作

我們已經在整篇文章中談到了幾個相關的作品。?我們在這里關注其他屬性提取的工作。?Pasca等人[21，22]是第一個探索使用查詢流數據生成實體的屬性，他們的主要成果是查詢流比文本的屬性提取準確率高出45%。雖然我們的結果與觀察結果一致，然而我們更進一步顯示查詢流可以用于從文本中提取種子。此外，我們解決了從查詢流和其他來源提取出現的拼寫錯誤和同義詞的問題。Biperpedia的規模比以前的工作大得多。特別是，他們報告的前50個（這是他們考慮的最大排名）的精度略低于我們在排名1000的精度。最后，我們證明了廣泛的屬性集合有利于解釋HTML表。

Lee?et?al[16]解決了確定類C如何被賦予屬性A或者屬性A被賦予類C的典型相關問題。相反，我們集中于通過識別同義詞，拼寫錯誤，以及屬性對之間的關系構建具有屬性的本體。它們還具有從查詢和Web文本中提取屬性的管道，但是存在幾個關鍵的區別。首先，他們以兩種模式從文本中提取屬性，而我們已經表明，要獲得一個相當大和高質量的本體，需要使用數百個模式。第二，它們獨立于源提取屬性，而我們使用來自查詢流的高質量提取來對我們的文本提取種子。它們還執行概念水平提取，我們沒有進行，例如使用諸如葡萄酒酸度的模式來提取WINES類的屬性。他們在50級報告的精度與我們在1000級報告的水平相同。Lee?et?al.提及將Web表作為其工作的動機，但未提及將其屬性應用于此任務。

11.?結論

我們描述了Biperpedia，一個二元屬性的本體，它擴展了Freebase，并從查詢流和Web文本中提取屬性。我們提取的關鍵思想是使用來自Freebase的高質量屬性和查詢流來從文本中進行種子提取。我們演示了Biperpedia的實用程序，它可以解釋超過Freebase4倍的Web表。我們目前正在將高質量的屬性從Biperpedia添加到Freebase中。

除了改進和擴展我們的類層次結構和用于將字符串解析為立即對Biperpedia有益的實體的算法之外，我們還在追求兩個主要方向。首先，我們正在開發用于分類對和屬性之間的不同關系并從Web文本中發現它們的方法。第二，我們有意挖掘復雜屬性名的語法。例如，我們希望能夠識別，INCREASE?IN?TOTAL?ASIAN?POPULATION描述了屬性ASIAN?POPULATION的改變。這種解釋對于理解大量高質量Web數據至關重要。

最后，從搜索應用程序的角度來看，我們的算法可以應用于可能具有不同結果的任何查詢流。例如，將我們的方法應用于來自移動設備的查詢流將不同于一般查詢流的屬性，并且需要適配于流量需求搜索的本體。

12.?引用

[1]?M.?D.?Adelfio?and?H.?Samet.?Schema?extraction?for?tabular?data?on?the?web.?PVLDB,?2013.

[2]?S.?Auer,?C.?Bizer,?G.?Kobilarov,?J.?Lehmann,?R.?Cyganiak,?and?Z.?G.?Ives.?Dbpedia:?A?nucleus?for?a?web?of?open?data.In?ISWC/ASWC,?pages?722–735,?2007.

[3]?K.?D.?Bollacker,?C.?Evans,?P.?Paritosh,?T.?Sturge,?and?J.?Taylor.?Freebase:?a?collaboratively?created?graph?database?for?structuring?human?knowledge.?In?SIGMOD?Conference,pages?1247–1250,?2008.

[4]?M.?J.?Cafarella,?A.?Y.?Halevy,?D.?Z.?Wang,?E.?Wu,?and?Y.?Zhang.?Webtables:?exploring?the?power?of?tables?on?the?web.?PVLDB,?1(1):538–549,?2008.

[5]?A.?Carlson,?J.?Betteridge,?B.?Kisiel,?B.?Settles,?E.?R.Hruschka,?and?T.?M.?Mitchell.?Toward?an?architecture?for?never-ending?language?learning.?In?AAAI,?2010.

[6]?C.?Chambers,?A.?Raniwala,?F.?Perry,?S.?Adams,?R.?R.?Henry,?R.?Bradshaw,?and?N.?Weizenbaum.?Flumejava:?easy,?efficient?data-parallel?pipelines.?In?PLDI,?pages?363–375,?2010.

[7]?H.?Cui,?J.-R.?Wen,?J.-Y.?Nie,?and?W.-Y.?Ma.?Probabilistic?query?expansion?using?query?logs.?In?WWW,?pages?325–332,?2002.

[8]?A.?Doan,?A.?Y.?Halevy,?and?Z.?G.?Ives.?Principles?of?Data?Integration.?Morgan?Kaufmann,?2012.

[9]?O.?Etzioni,?A.?Fader,?J.?Christensen,?S.?Soderland,?and?Mausam.?Open?information?extraction:?The?second?generation.?In?IJCAI,?pages?3–10,?2011.

[10]?A.?Fader,?S.?Soderland,?and?O.?Etzioni.?Identifying?relations?for?open?information?extraction.?In?EMNLP,?pages?1535–1545,?2011.

[11]?C.?Fellbaum.?WordNet:?An?Electronic?Lexical?Database.?Bradford?Books,?1998.

[12]?J.?R.?Finkel,?T.?Grenager,?and?C.?D.?Manning.?Incorporating?non-local?information?into?information?extraction?systems?by?gibbs?sampling.?In?ACL,?2005.

[13]?A.?Haghighi?and?D.?Klein.?Simple?coreference?resolution?with?rich?syntactic?and?semantic?features.?In?EMNLP,?pages?1152–1161,?2009.

[14]?M.?A.?Hearst.?Automatic?acquisition?of?hyponyms?from?large?text?corpora.?In?COLING,?pages?539–545,?1992.

[15]?J.?Lee,?J.-K.?Min,?and?C.-W.?Chung.?An?effective?semantic?search?technique?using?ontology.?In?WWW,?pages?1057–1058,?2009.

[16]?T.?Lee,?Z.?Wang,?H.?Wang,?and?S.-W.?Hwang.?Attribute?extraction?and?scoring:?A?probabilistic?approach.?In?ICDE,?pages?194–205,?2013.

[17]?G.?Limaye,?S.?Sarawagi,?and?S.?Chakrabarti.?Annotating?andsearching?web?tables?using?entities,?types?and?relationships.?PVLDB,?3(1):1338–1347,?2010.

[18]?Mausam,?M.?Schmitz,?S.?Soderland,?R.?Bart,?and?O.?Etzioni.?Open?language?learning?for?information?extraction.?In?EMNLP-CoNLL,?pages?523–534,?2012.

[19]?M.?Mintz,?S.?Bills,?R.?Snow,?and?D.?Jurafsky.?Distant?supervision?for?relation?extraction?without?labeled?data.?In?ACL,?pages?1003–1011,?2009.

[20]?N.?Nakashole,?G.?Weikum,?and?F.?M.?Suchanek.?Patty:?A?taxonomy?of?relational?patterns?with?semantic?types.?In?EMNLP-CoNLL,?pages?1135–1145,?2012.

[21]?M.?Pasca?and?B.?V.?Durme.?What?you?seek?is?what?you?get:?Extraction?of?class?attributes?from?query?logs.?In?IJCAI,?pages?2832–2837,?2007.

[22]?M.?Pasca,?B.?V.?Durme,?and?N.?Garera.?The?role?of?documents?vs.?queries?in?extracting?class?attributes?from?text.?In?CIKM,?pages?485–494,?2007.

[23]?T.?Tran,?P.?Cimiano,?S.?Rudolph,?and?R.?Studer.?Ontology-based?interpretation?of?keywords?for?semantic?search.?In?ISWC/ASWC,?pages?523–536,?2007.

[24]?P.?Venetis,?A.?Y.?Halevy,?J.?Madhavan,?M.?Pasca,?W.?Shen,?F.?Wu,?G.?Miao,?and?C.?Wu.?Recovering?semantics?of?tables?on?the?web.?PVLDB,?4(9):528–538,?2011.

[25]?J.?Wang,?H.?Wang,?Z.?Wang,?and?K.?Q.?Zhu.?Understanding?tables?on?the?web.?In?ER,?pages?141–155,?2012.

[26]?M.?Yakout,?K.?Ganjam,?K.?Chakrabarti,?and?S.?Chaudhuri.?Infogather:?entity?augmentation?and?attribute?discovery?by?holistic?matching?with?web?tables.?In?SIGMOD?Conference,?pages?97–108,?2012.

[27]?L.?Yao,?S.?Riedel,?and?A.?McCallum.?Collective?cross-document?relation?extraction?without?labelled?data.?In?EMNLP,?pages?1013–1023,?2010.

總結

以上是生活随笔為你收集整理的Biperpedia: An Ontology for Search Applications/ 应用于搜索应用的本体!的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。