第三章、 蒐集之資料、文獻分析
第三節、 BIM技術文獻雲端服務之資料檢索技術
壹、 全文檢索技術
根據維基百科的定義[46],所謂的全文檢索是一種”從文本或資料庫中,不 限定資料欄位,自由地萃取出訊息的技術”。而在執行全文檢索任務的程式,
一般稱作搜尋引擎,它可以將使用者隨意輸入的文字,試圖從檢索的索引資料 庫中,找到符合的內容,以提供給使用者發現具有該文字的文件資訊。目前搜 尋引擎在網際網路上的應用,已是相當的普及。而對於一般的文件庫的搜尋,
亦有相對應的發展及應用。常見於網際網路的搜尋引擎如:Google Search、
Yahoo、Bing、…等,都是大部份 Internet 使用者經常使用的工具。這些工具主 要提供 Internet 上的文件搜尋。而在電腦文件搜尋亦有許多商用搜尋引擎、及 免 費 的 開 放 源 始 碼 的 搜 尋 引 擎 可 供 使 用 。 在 商 用 搜 尋 引 擎 上 如 :IBM OmniFind、龍捲風…。而免費的開放源始碼的搜尋引擎則有:Apache Solr、
Lucene 、 BaseX 、 Crawzilla 、 Clusterpoint Server (freeware licence for a single-server)、DataparkSearch、KinoSearch…等。但是這些免費的搜尋引擎大 都有其限制。例如:支援語言、檔案格式、文件數量…等。而其中與本研究最 相關的莫過於支援語言和檔案格式的問題。和中文有關的議題主要牽涉到:中 文斷詞方式及中文語法解析與其它語言的差異和多語言混合的問題。這在多數 的免費搜尋引擎大都沒有提供。雖然開放原始碼的優勢可以提供使用者自行開 發相關套件,但是入門門檻相當高。
大致上搜尋引擎(不管是 Google、 Yahoo、 或 Nutch)都可以區分成幾 個組成要素:
1. Crawler (網路蜘蛛、網路機器人、爬網程式) :負責根據設定的初始入口 網 址 或 檔 案 位 置 , 將 該 網 址 或 檔 案 位 置 內 含 的 連 結 加 入 Link Graph Database ,接著根據 Link Graph Database 繼續深入搜尋。Crawler 爬的資 料,相當的大。如果以 Web-Scale 來說容量會高達 Peta-Bytes 等級。因此
需要 Google File System 或 Hadoop Distributed File System 這一類分散式 檔案系統來當作暫時的檔案存放。
2. Link Graph Database :這部份是目前 Google 與 Microsoft Bing 等著名的搜 尋引擎特別強調想改進的部份。 Google Percolator 搜尋引擎近期之所以可以 達 成 「 即 時 搜 尋 」, 有 一 部 份 也 是 來 自 於 名 為 Pregel 的 Link Graph Database。
3. Index Pool ( 索引庫) :基本上索引庫的基本起源是 Inverse Index,簡單來 說,就是將多個檔案加以分析,進而得到一個(關鍵字,檔案列表)的反向 索引。最早,Lucence 專案做的事情就是幫忙斷字斷詞,以方便進行統計哪 個關鍵字出現次數最高,且這些關鍵字運用在 哪幾個檔案中。從 Crawler 爬取的 HTML 檔案內容,需要經過 HTML Parser 然後再經過斷字斷詞的處 理 , 才 能 透 過 Inverse Index 的處理,得到索引庫。 索引庫的運算在 Google、Yahoo!、及 Nutch 中,即是使用 MapReduce 演算法,以增加分散 運算的彈性。
4. Search Engine Web Interface(搜尋引擎的網頁介面):即搜尋引擎的網頁介面,
會去讀取索引庫,以顯示搜尋關鍵字的結果。
在了解了搜尋引擎的組成之後,針對常見的搜尋引擎進行了解。在經過一 番選擇之後,特別要提出來的是IBM OmniFind Yahoo Edition、Apache Lucene、
及國網中心的Crawlzilla 這三個解決方案。
貳、 IBM OmniFind Yahoo Edition
IBM OmniFind Yahoo Edition[47 Lucene]是由 IBM 與 YAHOO 共同提出的 一個搜尋引擎解決方案。很特別是它是一個免費的軟體,執行於JAVA 的環境,
並且提供了下列幾個特點[45]:
跨平台支援 ( 32 位元的 Linux 與 Windows 都支援 )
安裝容易,只要三個 Click 就可以安裝完成 81
支援索引 200 多種以上的檔案類型
有完整且多國語言(超過 30 國語系)的 Web 管理介面可供全文檢索引擎的設 定與管理
提供超簡易的 API 介面(HTTP GET/POST),將搜尋功能整合進既有系統非 常方便
提供三種建立索引的方式
直接針對檔案系統建立索引
透過 Web Crawler (Spider) 直接對特定網址進行全站檢索
可透過 API 進行文件索引
支援同義字,並可匯入、匯出
提供查詢狀態統計功能
內建客製化搜尋介面的設定,也提供 API 介面客製化搜尋結果
而這些特性對於一般運用而言,已經相當的足夠。更重要的是其安裝方式 非常簡單,只要執行其封裝好的安裝程式,幾乎都可以安裝成功。對於一個想 要建立搜尋引擎服務的企業而言,不失為一個選擇。唯一的缺憾是,這套軟體 已不再提供更新的版本。
參、 Apache Lucene及Crawlzilla
Lucene[46]是由 Apache 軟體基金會支持與提供的一套全文檢索與搜尋的 開放原始碼程式庫。它提供一個簡單卻十分強大的應用程式介面。是這幾年最 受歡迎的免費JAVA 資訊檢索程式庫,特別是結合了 Hadoop 之後,讓它變成 一個完全不輸企業級應用的搜尋引擎。而Apache Solr 即是其企業應用版本 [46]。然而和其它搜尋引擎一樣,其用於中文最大的問題還是中文分詞的問題。
以英文為例單句中的單字會以空白區分,而中文等亞洲文字卻是一字接著一字
的方式,在這種方式下,肯定不能為單字符(si-gram)為單位進行檢索。否則則 分不出”台灣”、”灣台”、”台”、”及”灣”之間的差別。但是這個問題可以由外加 語法分析工具來完成。Crawlzilla 即是一個由國家高速網路與計算中心,使用 Lucene 為程式庫,並基於 Hadoop 之上所開發出來的一套搜尋引擎套件。其結 構如下圖:
圖 3-13 Crawlzilla 的架構圖 (資料來源:Crawlzilla Develop team, 2010 )[45]
其針對中文環境,特別加強了中文分詞的能力,但目前僅支援Linux 平台。
該專案並獲得榮獲2010 開放原始碼創新應用開發大賽職業組冠軍[48]及 2011 年國研院傑出科技貢獻獎佳作[49],是一個十分難得且優秀的作品。而且該專 案所提供的中文文獻相當齊全,並有完整的影音教學,更是難能可貴。
由於該團隊已將整個安裝程序進行了自動化,所以除了是一個完整的搜尋 引擎的解決方案外,也是一個建置Hadoop 這個 MapReduce 運算環境最簡單的 方法。對於本研究後續的雲端運算運用而言,不失為一個一舉兩得的方案。
雖然Crawlzilla 擁有如此多的優點,但是實際運用在本研究的情形如何,
仍有待進一步的驗證。
83
肆、 建立特定領域之知識本體(節錄自臺大土木金育暉(101)碩士論文) 知識本體為一種整理與儲存知識的方式,其定義為將一知識內容用清楚並 標準化的方式「概念化」[3],而其中「概念化」的含意為將知識內容以不失原 意的方式將其內容簡化。因此使用知識本體的方式為當獲得一個知識時,將其 知識內容簡化成一知識概念,接著將該知識概念跟其他原有的知識概念進行連 結。此項連結可能會包含有此知識概念為另一知識概念的實例,或是此知識概 念是另一知識概念的解釋,或更多不同的關聯性。利用這樣的方式,將不同知 識概念進行連結。更重要的是可以藉由這樣的連結關係,去推論出兩個未有直 接 連 結 的 知 識 概 念 之 間 的 關 係 。 而 將 知 識 本 體 以 OWL (Web Ontology Language)[4]的格式儲存後,就可以使電腦理解並儲存知識概念。更進一步的 可以讓電腦利用知識本體的內容來進行知識概念之間的邏輯推論。
由於每個知識領域對於知識本體的運用方式不同,所以知識本體就需要依 照每個知識領域的使用目的進行建置,因此在建置知識本體時的步驟就會有所 不同。如圖3-14 左為 Noy 與 McGuinness 對於他們所設計的知識本體建置軟體 Protege,在進行知識本體建置時建議的操作步驟[5],共分為六個步驟,由決定 知識領域範圍開始,先使用已存在的知識本體作為基礎,接著列舉重要的知識 概念並定義知識概念彼此之間的關係與屬性。而圖 2 右則為 Uschold 與 Gr"uninger 對於在進行知識本體建置時的所建議的步驟[6],共分為四個步驟,
首先為確定知識本體的使用目的與應用範圍,再進行知識本體內容的抓取,接 著將知識本體編碼儲存後,融入現有知識本體。
分析兩者建置知識本體的步驟後,可以發現兩者有相似之處,在圖2 中以 虛線註明並進行對照,因此可以統整出在建置知識本體的過程中重要步驟,共 有三個部分:
確認知識本體所涵蓋的領域範圍
確認想要建置的知識本體的領域,並對該領域有一明確定義並限定該領域 的範圍。
知識概念擷取與知識概念的關聯性建置
將在限定範圍內的知識概念擷取出來並定義不同知識概念之間的關聯 性。
將知識本體的內容轉換為電腦可閱讀之格式
將知識本體中的知識概念與其相互之間的關係,依照電腦可閱讀的格 式進行儲存。
根據以上所統整的知識本體建置流程,第一個與第二個步驟皆需要許多領 域專家參與協助,其中又以第二步驟需要領域專家投入許多時間進行,以確認 何項知識概念是屬於欲建置的知識本體的範圍內。且根據 Noy 與 McGuinness 的建議,建置知識本體為一不斷循環的流程,因此領域專家須不斷對知識本體 的內容進行修訂,以增加該知識本體的內容與完善性。但如此一來在建置知識 本體時將耗費大量的人力與時間,所以如何減少領域專家在建置知識本體時所 參與的工作量,是本研究的主要目標。
85
Determine the
Domain and Scope Identify Purpose and Scope
Resusing Existing Ontologies
Ontology Capture Enumerate Terms
圖 3-14 建置知識本體之流程 (資料來源:轉引自臺大土木金育暉(101)碩士論文)
Define the Classes and the Class
Hierarchy
Define the Properties
Ontology Coding
Integrating Existing Create Instances Ontologies
在知識本體中,需定義不同知識概念之間的關係,所以由上節的文獻回顧 中,本研究選用BIM Handbook 的 Glossary 章節,來做為基本知識本體的主要 知識來源。因該章節的內容除了對於知識概念的說明以外,仍有針對不同知識 概念之間的關係進行說明。
以下條列出本研究所選用的知識概念與其彼此之間的關係:
1.Buildng information modeling (BIM)
基本知識本體的領域範圍為BIM,因此選用該知識概念作為基本如識本體 的最上層結構。
2.BIM system
其內容為整合 BIM 工具並提供平台讓不同工具進行連接,所以此知識概
其內容為整合 BIM 工具並提供平台讓不同工具進行連接,所以此知識概