:::

以PHP與PostgreSQL實作簡易中文全文檢索功能—概念說明篇

布丁布丁吃布丁

以PHP與PostgreSQL實作簡易中文全文檢索功能—概念說明篇

image

自從PostreSQL 8.3內建了全文檢索的功能之後,我就一直對這功能躍躍欲試。經過這兩天的研讀、嘗試之後,總算也弄出了一點成果。我在Google上並沒有搜尋到很多PHP+PostgreSQL的中文全文檢索功能解決方案,頂多看到中國大陸的文章,或是使用了nlpbampoo這個限定在Linux底下使用的套件,我覺得都不是說很理想。於是我把我所學到的資訊整理一下,在此跟大家分享。

這篇文章預設是給使用PHP發展系統,而也大概知道PostgreSQL的讀者使用,並從全文檢索的概念開始說明起,並提供我寫的簡易範例與安裝教學。由於文章有點長度,我打算分成三篇撰寫。

  1. 概念說明篇 (←現在在此)
  2. 展示安裝篇
  3. 展示說明篇

因為似乎不是一天可以寫得完,所以我就慢慢的一篇一篇地寫囉。


為什麼要需要全文檢索?

全文檢索是一個資訊檢索領域中非常重要的一個議題,知名的Google搜尋引擎就是將全文檢索技術發揮得淋漓盡致的知名成果。在正式介紹全文檢索之前,我想列出幾個您可能會遇到的問題,而這也是您可能會需要全文檢索的原因:

資訊系統就是要有「全文檢索」功能才叫做有SENSE。

這個說得像笑話又好像不是笑話,總之我的確看過有系統介紹廣告強打他們擁有「全文檢索」功能,也看過老師一看到系統就質問「這個有全文檢索嗎?」說不定這功能已經有如品牌標籤一樣,能為您的系統帶來神奇的廣告效果。

LIKE太慢了

基本的搜尋檢索功能是使用SQL的「LIKE」語法來實作。如果您寫過檢索功能,那您應該對以下SQL語法不會太陌生:

SELECT * FROM article WHERE text LIKE '%關鍵字%';

LIKE能使用萬用字元,讓您的搜尋條件變得有彈性。他的作法是採用字串比對,拿起您指定的「關鍵字」,把資料庫中的「TEXT」從頭比對到尾。如果萬用字元一多,那他還要比較個好幾次,才能確認這篇「TEXT」有沒有您指定的「關鍵字」。

當「TEXT」文章內容很短時,您並不太會覺得LIKE有何不妥。但是當您文章的長度達到上萬字,或是您的資料庫中有好幾萬筆文章時,您就會明顯地感受到LIKE的緩慢。

搜尋結果需要依照相關度排序

相關度,這是一個抽象的概念。簡單來說就是搜尋到的結果與您輸入的查詢語句之間的相關程度。相關度越高,表示該文件越符合您輸入的查詢語句;反之,相關度越低,表示該文件可能有涵蓋您指訂的查詢語句,但是並不太重要。

究竟這個「相關度」是依照什麼基準來計算呢?儘管資工領域已經有了TF-IDF之類的技術來計算相關度,但我相信應該大部分的人對於實作這些技術興趣缺缺。

我們需要一個更簡單的方式來計算搜尋結果的相關度,而這件事情PostgreSQl已經幫您作好了。

您需要更有彈性的查詢語句

如果您用過大型系統的搜尋,那麼可能會對於某些搜尋功能中可以加入「&」(表示AND,「且」)、「|」(表示OR,「或」)以及括弧「()」區分條件的查詢感到興趣。儘管這並不是一個很主要的難題,您還是可以用PHP的字串處理來實作LIKE語法,然後取得一個非常複雜、難懂的LIKE條件。

現在PostgreSQL直接支援「&」、「|」以及括弧「()」組成的查詢語法,例如:「(館藏 & 發展) | (社區 | 評估)」。您或許可以考慮那複雜的LIKE,來試著體驗看看這功能的強大。


全文檢索的倒置索引檔

全文檢索並非一般的字串比對,他是藉由搜尋「索引檔」讓檢索的效率大幅提昇的技術。

索引檔是來自於文章(text,為了方便,以下皆將之稱為文章)本身,透過斷詞、計算頻率、記錄位置等程序製作而成。舉例來說,現在有一篇文章的內文如下:

a fat  cat sat on a mat - it ate a fat rats

製作而成索引檔就可能會是:

'ate':9 'cat':3 'fat':2,11 'mat':7 'rat':12 'sat':4

這份索引檔按照了「英文字母」來排序每一個文章中的詞彙,並記錄該詞彙位於文章中的「位置」,同時幫我們把英文作清理語幹(「rats」變成了「rat」)、略過停用字(stop word)「a」、「on」、「-」,讓整個索引檔變得很簡潔。

如果我們要搜尋「rat」的話,系統只需要比對4次就能找到。如果是用傳統的字串比對的話,最笨的方法則需要比對39次才能找到。即使是用人的眼睛來搜尋看看,相信您也會覺得找索引檔會比找文章本身還要容易吧?

這種索引檔正式名稱叫作「倒置索引檔」(inverted index),他將文章內容拆解成詞彙、重新組合了詞彙,讓您搜尋時是透過索引而不必去找文章本身。而這個倒置索引檔也就是整個全文檢索的核心了。以下介紹中提到的索引、倒置索引檔,指得都是同樣的東西喔!


PostgreSQL全文檢索的運作元件

PostgreSQL裡面,全文檢索的用詞叫做「Full Text Search」、「Text Search」或是簡稱「ts」。

他主要提供了以下幾種功能讓您完成全文檢索的工作:

索引:tsvector

這是PostgreSQL用來儲存倒置索引檔的資料類型。如同TEXT、INT、BOOLEAN之類,只是特別是用以作全文檢索倒置索引檔的資料類型。您可以在建立欄位時指定使用tsvector資料型態,或是利用他的函式to_tsvector()將字串轉換成索引的資料型態。

分析索引:to_tsvector()

他的基本用法如下:(詳細說明見此)

to_tsvector([ config regconfig, ] document text) returns tsvector

參數有兩個,第一個regconfig選填,用來指定PostgreSQL的分析器(Parsers);第二個則是要拿來存入索引的文章內容。

舉例來說,您可以這樣使用to_tsvector():

SELECT to_tsvector('english', 'a fat  cat sat on a mat - it ate a fat rats');

如此便會獲得以下結果:

                  to_tsvector
-----------------------------------------------------
 'ate':9 'cat':3 'fat':2,11 'mat':7 'rat':12 'sat':4

目前PostgreSQL的分析器僅有「english」,在處理英文、數字、網址、e-mail等資料上,算是十分地好用,詳細說明請見PostgreSQL的文件。但是由於english是採用半形空白「 」來作為判斷索引的依據,如果要處理像中文這種撰寫時不包含空白的資料來說,就需要搭配斷詞器來使用,稍後我會說明這個解決方案。

查詢語句:tsquery

這是PostgreSQL的查詢語句資料型態,與tsvector正好是相對應的角色。查詢語句包含了要查詢的關鍵字之外,還有「&」、「|」、以及括弧「()」。複雜查詢語句的布林邏輯組合都可以交由tsquery去處理,而不需要您自己實作喔!

分析查詢語句:to_tsquery()

就如to_tsvector一樣,to_tsquery也是將查詢字串轉換成查詢語句資料型態的函式。基本用法如下:

to_tsquery([ config regconfig, ] querytext text) returns tsquery

參數一樣有兩個,前者與to_tsvector一樣是分析器,後者則是要查詢的字串。

舉例來說,您可以這樣使用to_tsquery():

SELECT to_tsquery('english', 'The & Fat & Rats');

得到結果如下:

  to_tsquery   
---------------
 'fat' & 'rat'

分析查詢語句時,就跟分析索引一樣,會經過停用字省略、語幹清除等動作,以便用來查詢索引。然而,to_tsquery一樣會有中文斷詞的問題,這點留到稍後在一起討論。

分析純文字查詢語句:plainto_tsquery()

plainto_tsquery()提供了更簡單的分析方法。他的基本用法與例子都跟to_tsquery()差不多,但是分析器會把半形空白「 」作為&的條件。舉例來說,您可以這樣使用plainto_tsquery():

SELECT plainto_tsquery('english', 'The Fat & Rats:C');

這樣會取得以下結果:

   plainto_tsquery   
---------------------
 'fat' & 'rat' & 'c'

您可以注意到,結果除了像to_tsquery一樣地省略停用字、語幹清除之外,還將空白、標點符號轉換成「&」(AND)條件輸入查詢,因此比起to_tsquery來說更為方便使用。

查詢比對

結合tsvector、to_tsvector()、tsquery、plainto_tsquery()之後,基本的全文檢索引擎就成形了。他們之間可以使用「@@」符號來進行比對,作法如下:

SELECT to_tsvector('fat cats ate fat rats') @@ plainto_tsquery('fat rat');

取得結果將會是「t」,表示有找到。

查詢比對的相關度:ts_rank()跟ts_rank_cd()

這兩個函式可以用來計算索引與查詢語句的相關程度。根據PostgreSQL的說明,他們計算查詢語句在索引中出現的次數、查詢字之間的接近程度以及出現位置。

基本用法如下:

ts_rank([ weights float4[], ] vector tsvector, query tsquery [, normalization integer ]) returns float4
ts_rank_cd([ weights float4[], ] vector tsvector, query tsquery [, normalization integer ]) returns float4

兩個函式的參數都差不多。第一個是權重,可以省略,權重是由4個參數組成,但我到現在還不太會用,詳細還是請去翻翻文件吧。第二、三個是索引與查詢語句,也就是主要計算相關度的來源。最後一個是計算方式的控制,依據輸入的整數不同而會有不同的結果,您也可以同時輸入多個整數,例如「2|4」。計算方法有以下幾種:(4)

  • 0:(預設) 忽略文章長度
  • 1:將相關度除與1+log(文章長度)
  • 2:將相關度除與文章長度
  • 8:將相關度除與文章中字詞出現種類的個數。(例如「fat cats ate fat rats」共有4個種類的字出現)
  • 16:將相關度除與1+log(字詞種類)
  • 32:將相關度除與1+(相關度)

其中,ts_rank_cd()是標準的計算方法,他參考了Clarke、Cormack與Thdhops等人1999年發表的論文「Relevance Ranking for One to Three Term Queries」有興趣的人可以看一看這篇的全文喔!

有了相關度,就能利用他來排序查詢結果了。作法舉例如下:

SELECT title, ts_rank_cd(textsearch, query) AS rank
FROM apod, to_tsquery('neutrino|(dark & matter)') query
WHERE query @@ textsearch
ORDER BY rank DESC LIMIT 10;

結果如下:

                     title                     |   rank
-----------------------------------------------+----------
 Neutrinos in the Sun                          |      3.1
 The Sudbury Neutrino Detector                 |      2.4
 A MACHO View of Galactic Dark Matter          |  2.01317
 Hot Gas and Dark Matter                       |  1.91171
 The Virgo Cluster: Hot Plasma and Dark Matter |  1.90953
 Rafting for Solar Neutrinos                   |      1.9
 NGC 4650A: Strange Galaxy and Dark Matter     |  1.85774
 Hot Gas and Dark Matter                       |   1.6123
 Ice Fishing for Cosmic Neutrinos              |      1.6
 Weak Lensing Distorts the Universe            | 0.818218

PostgreSQL運作架構

小結上述的各種元件,PostgreSQL基本的全文檢索運作圖如下:

image

  1. 將文件轉換成索引。
  2. 將儲存在資料表中。往後文件有更新時,也一併轉換成索引、更新索引檔。
  3. 使用者利用查詢功能輸入關鍵字,系統將之轉換成查詢語句。
  4. 將查詢語句與資料庫中的索引進行比對。
  5. 取得找到的結果。
  6. 計算相關度,並依照相關度排序結果。


中文斷詞

前文中提及PostgreSQL使用的english分析器主要是依據半形空格來切割字句,但是對於中文這種並沒有明顯分割字句的資料,就無能為力了。

沒有中文斷詞的索引

以下是一個失敗的例子:

SELECT to_tsvector('english', '布丁布丁吃布丁的Blog一直都很無聊');

結果如下:

'布丁布丁吃布丁的Blog一直都很無聊':1

對於這種索引檔,就算您查詢語句輸入「布丁」、「Blog」、「無聊」(具體來說就是「SELECT to_tsvector('布丁布丁吃布丁的Blog一直都很無聊') @@ plainto_tsquery('布丁 無聊');」),都將找不到這份文件

有中文斷詞的索引

為了解決這個困擾,您需要先將中文經過斷詞的程序。將「布丁布丁吃布丁的Blog一直都很無聊」切割成「布丁 布丁 吃 布丁 的 Blog 一直 都 很 無聊」的結果,在丟進PostgreSQL的分割器,才能正確地建立起索引檔。

例如:

SELECT to_tsvector('english', '布丁 布丁 吃 布丁 的 Blog 一直 都 很 無聊');

將會取得以下結果:

'吃':3 '很':9 '的':5 '都':8 'blog':6 '一直':7 '布丁':1,2,4 '無聊':10

這樣的索引檔就可以使用SELECT to_tsvector('布丁 布丁 吃 布丁 的 Blog 一直 都 很 無聊') @@ plainto_tsquery('布丁 無聊');查詢,並正確地找出來了。

中文斷詞器

上述過程中,將「布丁布丁吃布丁的Blog一直都很無聊」轉換成「布丁 布丁 吃 布丁 的 Blog 一直 都 很 無聊」的程序,就叫作「中文斷詞」,中國大陸用語則是「中文分詞」。大致上作法是比對「辭典」、常用字、停用字來判斷哪些字是一個詞,因此「辭典」越豐富的斷詞器,其斷詞的成果就會越好。

我國最知名的斷詞器是中研院發展的CKIP。將上述例子丟進線上展示斷詞之後,得到的結果是「布丁(Na) 布丁(Na) 吃(VC) 布丁(Na) 的(DE) Blog(FW) 一直(D) 都(D) 很(Dfa) 無聊(VH)」。後面的括號是詞性,這是CKIP的特色之一。

我們DLLL實驗室也發展了一套斷詞系統ECScanner,他會定期地蒐集網路新聞文章,以擴大他的辭典。斷詞結果是「布丁/布丁/吃/布丁/的/一直/都/很/無聊」,雖然不知為何少掉了「Blog」一詞,總之還是在此廣告一下。

SCWS簡體中文分詞系統

其他還有各種中文斷詞器,用人用C實作、有人用Java實作,也有人利用PHP來實作,那就是SCWS簡體中文分詞系統。由於我論文的系統是採用PHP+PostgreSQL作為架構,所以看到可以以PHP進行的斷詞器,自然是優先考量。作者hightman不僅讓此系統用於簡體中文,也可以讓臺灣主要的正體中文使用。上述例子中斷詞結果是「布丁 布丁 吃 布丁 的 Blog 一直 都 很 無聊」,還算令人滿意的結果。

但是SCWS的省略標點符號的功能我不是很滿意,所以這是我在展示時有稍微處理的部份。

SCWS除了需要安裝PHP的延伸套件以讓PHP能使用斷詞器之外,還需要附帶XDB辭典與設定檔(包含停用字等設定)。稍後在展示安裝篇時,我會再詳細介紹他的安裝方法。

SCWS原本也有用PHP寫成的PSCWS4,但是我嘗試用於正體中文UTF8碼時,卻每每變成亂碼。推測可能是PHP的中文在UTF8中會被視為3字元的原因。儘管PSCWS4的處理速度比起SCWS慢很多,但是安裝上卻比SCWS更為簡單、跨平台。PSCWS4在2008年底停止開發,著實讓人感到遺憾。


以中文斷詞改善全文搜尋架構

image

這次我們把中文斷詞加進整個架構當中,流程如下:

  1. 將文件經過中文斷詞,轉換成索引
  2. 將索引儲存在資料表中。往後文件有更新時,也一併經過中文斷詞、轉換成索引、更新索引檔。
  3. 使用者利用查詢功能輸入關鍵字,系統將之先經過中文斷詞處理,再轉換成查詢語句。
  4. 將查詢語句與資料庫中的索引進行比對。
  5. 取得找到的結果。
  6. 計算相關度,並依照相關度排序結果。

這就是簡單的中文全文檢索引擎的原理囉!


以下是我用來meeting時報告的投影片,就是上述內容的簡單概要版。(SkyDrive下載)


image

其實光是原理的介紹,距離實作可用還有一點點的距離。所以我寫了一個簡單的系統來展示如何利用PHP與PostgreSQL來實作中文全文檢索引擎。不過……就讓我稍微延後一下,接著我還是先回到UML的作業上吧XD

(more...)

論文進度報告(2010/5/16)

布丁布丁吃布丁

論文進度報告(2010/5/16)

image

一週的時間飛倏地過去了,很快又到了本週報告進度的時間。

一如上週所說的預定事項,本週則是進行類別圖(Class Diagram)的作業。我在畫圖的過程中也逐漸修正自己對於類別圖的認識,並越畫越得心應手。根據擔任系統分析師的強者我朋友所言,我似乎已經進入到了強化分析的階段。詳細的細節請看KALS WIKI囉!

以下是本週報告時的投影片:(SkyDrive下載)


為什麼要用UML?這樣做系統會比較快嗎?

UML是一種統一塑模語言,簡單來說,就是一種描述系統的文件。透過UML,我可以描述整個系統的架構,並從中思考系統要怎麼運作。

老師在Meeting時有問我說,這樣做系統會比較快嗎?老實說,這通常不會比較快,特別是像我對UML不熟的這種半吊子。

系統開發的方法有很多,比較快速的敏捷開發法通常都是以發展雛型、改進雛型的方式進行。以往我習慣直接先開始寫程式,而不去作系統分析,或著是只有腦中作個粗略的分析而已。接著再從程式雛型不斷地去修改,直到完善。但那並不是一種好的開發方式,或著是說,那是開發方式難以讓人成長。

在繪製UML類別圖的時候,可以很明確地看到類別與類別之間的關係,進而讓我發現此時應該使用何種設計模式。而不會像以往埋頭苦幹許久之後,才想到當初應該使用設計模式的慘狀。能在UML時用上MVC、Factory、Collection、Iterator等設計模式,其實還蠻讓我覺得的確有些許成長的。

不過會採用UML的作法還有另一個理由,就是下面所說的。


實驗積極進行中!不過不是我……

本實驗室的學生很微妙地都變成了教育研究,也就是要找學生作實驗才能進行下一步。由於學校大概都是六月底放暑假,而在之前則是期末考,在這段期間中都不太方便進行實驗。換句話說,實驗通常是五月底或六月初之前就要做完,否則就要等到下學期初。

不知道是否是這個原因,近來兩位學弟都在差不多時期開始了他們的實驗。儘管準備過程中似乎困難重重,但還是祝他們能夠順利完成。

反觀我,即使系統完成了,實驗要進行還需要一段時間的前置作業。也因此很明顯地趕不上五月底、六月初這個時程。既然趕不上,那麼就好好作、仔細作,一邊繼續學些新的東西。這就是我用UML慢慢畫的另外一個理由了。


出書進度

本週meeting時,老師也有談到一下出書的進度。(註:由於現在書的工作進度已經交給老師去處理了,所以現在不是「寫書」,而是「出書」。) 老師提到了幾個需要修改的地方,包括數位格式的匯整表格、metadata的繪製方法(其實被我移到第二章數位典藏專案規劃那邊去了XD)、另外加入數位化作業一章之類的。大致上我之前也有考慮過那些問題,只是礙於時間、人力不足,最後捨棄不加。老師指出這些點,也就是老師有仔細檢查的一點證明。老師也辛苦了。現在出書時間似乎延後到暑假中再來進行,就隨意吧。


image

本週專案管理時程沒有什麼改變,所以不更新。

下週預定事項是繼續完成Class Diagram,加油囉!(喔!)

(more...)

論文進度報告(2010/5/9)

布丁布丁吃布丁

論文進度報告(2010/5/9)

繼上次做完專案規劃之後,這週則是開始作UML的系統分析與設計。UML的作法主要是參考游峰碩寫的UML系統分析與設計(學貫行銷出版),個人是覺得寫得還不錯,案例也很實在。照著這本書依樣畫葫蘆,倒也把使用案例圖活動圖畫了幾張出來。至於正不正確、實不實用……做下去就知道了。

大四時我有修過系統分析,不過並沒有很紮實地受過UML的訓練。我雖然寫程式有段時間了,寫寫小工具雖然還算得心應手,但是作大型系統時就必定暴露出沒有全面性思考的缺陷。因此這次就想先從UML著手來構思系統,一邊畫各種模型,一邊強迫自己思考系統該怎麼呈現。

大致上我預計製作以下幾種文件:

  1. 詞彙表:記錄本系統使用的詞彙
  2. 使用案例圖:呈現user(學生)、supervisor(教師)、administrator(系統管理者)三種角色主要執行的幾種動作
  3. 活動圖:將幾種案例以活動步驟來描述。目前繪製完成user端的六種活動圖。
  4. 類別圖:系統使用的概念轉換成較為具體的類別class,並敘述各類別之間的關聯
  5. 循序圖:描述系統中物件互動的情形

畫完循序圖,整個系統也就差不多了,接下來就是開始系統實作。

繪製UML的時候,其實感覺非常不習慣。對我來說,寫程式的樂趣在於馬上可以看到成果。但是UML怎麼畫,卻都還是腦中構想的流程圖,沒有實際上完成什麼東西的成就感,因此畫起來頗讓人感到無聊。這時深深地感受到敏捷系統開發流程強調的測試導向或是雛型架構等方法的重要性——雖然必定會有哪裡搞錯,但能看到成品,比較能夠激勵人心吧。

另一方面,由於不知道自己這樣畫是不是正確,畫起來也無從依據,只能憑感覺來架構。希望這些文件能在之後的階段中派上用場才是。

不過,如果要讓自己成長的話,就不能一直停留在用直覺寫程式的階段。UML文件是必要的,特別是未來要與他人合作開發系統的話,只有自己腦中構想的系統架構,可是無法進行溝通啊!


image

好,接下來則是檢視一下專案管理的時候了。

現在位於「系統分析」階段,由於加入了UML的學習時間,所以原本預定一週完成的系統分析,延長至三週完成。殘酷的是這不影響預定畢業的時間,還是1/25結束(汗)。

專案管理的所有檔案現在改移到KALS協作平台的專案管理中,有興趣的人可以從該頁中下載全部的專案檔案。


簡單報告完畢之後,接下來就要著手畫類別圖了。套句現任系統分析師說的話:「使用案例圖跟活動圖畫不好沒關係,類別圖跟循序圖畫好最重要,因為系統就是照著他們來做的。」所以終於到了接近系統核心的類別圖,這讓我忽然覺得壓力很大啊(抖抖抖)。

不管怎樣,加油吧。

(more...)

輔仁大學2010圖書館與資訊社會研討會第一天感想

布丁布丁吃布丁

輔仁大學2010圖書館與資訊社會研討會第一天感想

  • 主辦單位:輔仁大學圖書資訊學系暨輔仁大學圖書館
  • 會議日期:99年5月6日(四)〜99年5月7日(五)
  • 會議地點:輔仁大學濟時樓九樓會議廳
  • 會議主旨:研討會的目的在於藉由多元化知識的角度探討圖書資訊相關之理論、研究、開發與實務,讓與會人士能夠在傳統與現代、理論與實務、管理與服務、不同科技在圖書資訊經營、服務與開發設計相關議題上,進行知識的交流與學術的對話。
  • 議程網址

輔大圖資自從林麗娟老師開始創立了這個活動開始,我也就當作每年回娘家一樣,回去看看大家,順便從研討會中吸收點知識。今年由陳舜德老師接任所長之後,研討會仍如節慶般地在五月初舉行,各校的學生、老師們也都來響應這場參雜各種主題的「大拜拜」。

我參加的是5/6(四)的行程。以下也就對印象較深的場次,簡單地記錄感想。一部分感想也寫在Plurk,而這篇則是一個較完整的匯整。


數位典藏如何著手?「從簡單的做起」

早上聽王梅玲老師描述(抱怨?)去年校長交待她的「藍海計畫」——研究如何從智慧財產管理中進行獲益,也就是國家型數位典藏計畫現在一直在想的,要怎麼從數位典藏中賺錢。 半個多小時介紹下來,問題看到的比解決方法還要多,王老師還頻頻關切著台灣百年圖書館史 (遮臉)。

由於政大是公共機關,賺錢的方法雖沒有,但把數位典藏用於教學的這條方法則是被一再強調。具體來說,也就是不把數位典藏的成品當作商業資料庫販售、或是作什麼商品化的加值應用,而應該是把成果用於教學活動上,包括數位課程的教材豐富化。反過來說,這也就是建置數位典藏的一項指標:支援教學目的。

從上述的過程中推論,要擺脫智慧財產的束縛,最基本的方法還是「低調自己用」,就如教學單位政大之於課堂教學一樣。但話說回來,許多資料庫好像本來就是為了「要用」而建,只是想知道能不能更進一步地「賣錢」。這種結論不就是請建置者不要癡心妄想,建完自己用就好的意思嗎?

除此之外,數位典藏建置的優先順序中,「擺脫智慧財產權是否棘手」也變成了考量因素之一。柯學姐認為故宮擁有的資產大多都沒有智慧財產權的問題,因此他的數位典藏商業化經驗從根本就讓一般機構無從借鏡。這也是大家的無奈吧。

對了,DSpace不具備商業授權機制,數位典藏要賣錢請找其他系統,謝謝。


圖書資訊哲學課題的震撼教育

接著我跑到了第一場場地A,去聽聽靜宜助教畢業論文「圖書資訊學研究所學生就讀動機之研究」。有鑑於報考圖資研究所的人數逐年下降,靜宜助教的研究對於各個相關系所都很有幫助。分析結果主要指出學生的求學目的在於「就業」,而學校名氣比課程發展更為重要(這好像是一般人普遍的想法啊)。此外,也對學生、學會提出了一些建議。

image 

(表引用自靜宜助教的論文!寫個Blog就沒很打算很認真地寫參考來源了orz)

有趣的是,問卷分析結論中指出,全職學生與較已畢業學生容易有逃避生活中的某項事務情形發生。是的,全職學生&非已畢業學生就是我,而寫這個Blog就是逃避論文的一段小插曲。(意義不明)

接著是師大博士班吳寂絹學姐的論文「圖書資訊學的哲學課題」。她介紹了何謂資訊(形上學)、社會認識論(認識學)、資訊倫理(倫理學)這三塊議題,並建議圖資系所的課程發展可以納入哲學。雖然圖資的研究方向主要是實證科學或是應用為主,較少人在探討抽象的、概念的哲學問題。但其實我還蠻羨慕那種以理論來解析事物原理的技術,如果自己也懂得這麼多道理的話,寫起論文應該就不會只有系統技術這麼無聊了XD

最後是吳泓慕學弟的「電腦科學文獻分佈與主題於不同傳播管道之比較:以P2P 為例」。套句黃元鶴老師的掩護:「這只是期末報告修改過來的。」大家就請手下留情,不要猛轟學弟了吧orz


資料探勘研究,資料才是最重要的

下午第二場我跑去場地A,主要是想聽聽郭俊桔老師跟曾元顯老師的研究。

image

郭老師作的「自動建構中文MeSH標題同義詞及其檢索效益之研究」,也就是把英文的MeSH翻譯成中文之後,再以文字探勘的方式從CEPS資料庫中的繁體醫學文獻取出同義關鍵字。中間涉及多資訊技術的處理,總之就是從摘要中取出了關鍵字就是。最後出來的結果似乎不盡理想,郭老師推估可能是由於CEPS資料庫中PDF文獻的品質不佳。我記得CEPS的PDF要嘛是只有影像,要嘛是用OCR文字辨識影像(辨識率可想而知),較少是真的原生數位文件的典藏。結果不良的資料來源,自然也探不出理想的成果,不禁令人感嘆。

image

曾元顯老師的論文是「數位時代之自動化主題分析與資訊組織─內容探勘技術在教育評鑑研究發展趨勢分析之應用」。名字有點長,但其實是介紹曾老師如何使用他開發的文字探勘系統,用於分析主題概念上。那是一種文字探勘工具,可以對文字進行斷詞、詞幹去除,接著以「共現詞」作為關聯,將各文件進行分群。最後則用這些詞作為該群的代表詞彙。在此論文中,曾老師尚利用WoS提供大量參考書目資訊的特色,以「書目對」作為另一種關聯的方法來分群。透過用這兩種分群方式的結果,並探討這種分群方法是否符合專家認為的看法,而真的有效。

事實上,由於文件量不多、我的專業知識也不足,分析的結果說來也頗差強人意。但曾老師這種文字探勘的方法卻是擁有非常多種應用,可以幫助研究者在茫茫的文字之海中,大略地辨識出文件的脈絡。作為一個起點,或是與其他方法的比較,都是非常令人感興趣的一種技術。


Koha居然有公司開始提供服務了

2010-05-06-710

想起前幾年我好像也在搞Koha,沒想到這次居然看到碩陽數位科技有限公司居然開始提供Koha服務了!

Koha是一種圖書館自動化系統(簡單來說,就是超級複雜的巨大系統就對了!),特色是開放原始碼的軟體,可讓人以低成本的方式安裝。事實上,輔大圖資系的圖書館服務隊也多次採用Koha,來協助偏遠地區圖書館建立自動化系統。

雖然Koha是免費的,但他也相當地難上手。安裝時技術門檻高,儘管龍山學長撰寫的自動化安裝已經行之有年,但不及現今系統硬體架構更換的速度。2008年我嘗試安裝Koha時,也是弄得灰頭土臉,到最後只得求助VirtualBox的幫忙。

看到現在有廠商可以支援Koha的服務,這就是當年毛慶禎老師認為的開放原始碼獲利的理想方法之一。Coffe Break時我與毛老師聊起這件事情,老師笑著說:「一開始有點手忙腳亂,沒想到後來做得還不錯。」應該也是美事一樁。

我也非常期待開放原始碼的Koha能夠不讓其他高昂費用的圖書館自動化系統專美於前,大家加油吧!


除了研討會之外,其他事情包括靜宜助教也畢業了、小童助教也大肚子了、學弟們還是非常有精神,跟林麗娟老師報告了一下我的研究題目云云。也看到阿凎與會,休息時一堆人打PSP什麼的。就是一些生活雜事了XD

(more...)