:::

論文進度報告(2010/6/3)

布丁布丁吃布丁

論文進度報告(2010/6/3)

image

距離上次的進度報告,已經間隔了半個月。這半個月之間去了兩次法院、提出了附帶民事訴訟、帶朋友在台北繞啊繞、整理備份電腦,所以其實也沒推進多少進度。

這次的進度主要是完成了Model的Class Diagram,以及Webpage Application(簡稱WebApp)中大概50%的View的Class Diagram(關於專有名詞的定義,請參考KALS wiki詞彙表)。在規劃View之前,我也利用Pencil先畫了幾張網頁藍圖,像是這篇開頭的那張圖就是利用Pencil畫得,很像以假亂真的程式吧?XD 目前WebApp的藍圖皆存放在wiki當中,請點此進入觀賞

以上進度的投影片如下:(SkyDrive備份)


畫圖畫到大翻修

image

畫到View的時候,會發現很多需要再修改的地方。舉例來說,上圖Annotation View Window就是後來跑出來的想法。這是為了讓標註可以寫很多,又不限制於一定要在小小的Annotation Box,而能夠顯示在獨立視窗中的折衷方案。這個改變足以讓整個View跟Model都要大翻修,所以目前進度又得延後了。

此外,像是權限設定的規則也多了不少限制,讓流程簡化,但一些功能又得再改過。


專案進度確認

image

也就是說,View的製作過程又要往後延期。事實上他已經延期了一次,這是第二次的延期。整個工作時間擴大到兩個禮拜,也就是大概還要一個禮拜、6/9才能完成。

image

這次專案管理的甘特圖中,我把系統實作的部份又區分得更為詳細。大致上可分為Webpage Application、Administration Application與作業系統實作這三個部份,而當Webpage Application作完之後,就可以開始邀約實驗參與者的動作。這樣排下來,專案還是會在1/25左右畢業。反正就認了吧XD

那麼接下來就是修改網頁藍圖,然後繼續修改View的Class Diagram吧。加油!

(more...)

網站藍圖繪製工具:Pencil

布丁布丁吃布丁

網站藍圖繪製工具:Pencil

image

身為一個網頁設計者,您一定有許多時候需要跟人討論網頁呈現樣貌的情況。也許強者們可以用短短的時間很快寫完一個網站,但您也可以考慮利用像Pencil這種專門用來繪製網站藍圖(Website Wireframe)的工具,讓您輕鬆、快速地「畫」出一個網站的樣貌,以便跟大家進行討論!


Website Wireframe 網站藍圖

1422855_a25749dfc10336b5e8157d910ae5d275

設計網站或各種電腦軟體使用者介面(User Interface)的設計者,應該都對Wireframe不陌生。Wireframe可以簡單地翻譯成「藍圖」,或著說是「介面的草稿」。在繪製網站時,利用Wireframe來作為溝通用的工具更是常見的方法。上圖是利用MockFlow繪製的網站藍圖,單純的線條與配色讓他看起來很像是設計者手中筆記本裡會出現的草圖。

Wikiedia中對此有更詳細的解釋:

Wireframe,或著說「web ware frame」、「web wireframing」,是一種用於介面設計的簡易視覺化指引工具,可對於網站結構與頁面之間的關聯提供具體的參考。網站藍圖是用以呈現使用介面中網頁排版元件的類似圖畫。一般來說,在任何介面設計之前,都會先完成藍圖。

 

儘管您用紙筆、用任意的繪圖工具,都能製作出網頁藍圖。但是一般的繪圖工具要畫個按鈕、畫個捲軸,其實都不太方便。把網頁元件畫得太過抽象,畫出來的網頁藍圖也很難有具體的感覺。所以您需要的應該是更專業、更方便的網頁藍圖繪製工具,也就是本篇介紹的Pencil。


Pencil

logo

市面上繪製網頁藍圖的工具非常多,Pencil是其中少數開放原始碼的網頁藍圖專門繪製工具。該工具具有以下特色:

  • 開放原始碼就是可以免費使用!
  • 可內建多種網頁排版元件,例如表單按鈕、捲軸、視窗、圖示。
  • 常見繪圖功能:可微調元件的長寬、位置、對齊、前後、顏色、 旋轉等等。
  • 背景功能:一張頁面可以疊在背景頁面上繪製,讓整個風格統一。
  • 連結功能:可以指定某個元件連結到指定的頁面。
  • 可作為Firefox的Add-on(這Add-on也太過複雜了!),也可以安裝成獨立程式。
  • 可匯出成為HTML、PNG、Openoffice.org文件、Word文件以及PDF。
  • 跨平台:支援Windows、Linux。
  • 可自行安裝Stencils(Pencil的擴充元件)以及輸出樣板。

下載與安裝Pencil

Pencil是一個跨平台的工具,他可以作為Firefox的Add-on安裝(Pencil 1.1支援Firefox3.5以上版本),但是使用時必須開啟Firefox;也可以以獨立程式運作,而不必依賴Firefox。不管哪種,操作的介面都幾乎沒什麼不同。

安裝Stencils

除了Pencil主程式之外,請務必下載各種Stencils,讓您的Pencil擁有更多元件。

4007290837_37742a3bf6

舉例來說,如果您在Pencil中安裝了Dojo UI Widgets,就可以繪製以上的圖案。

image

安裝Stencils的方式也很簡單,開啟Pencil主程式之後,選擇「Tools > Install New Collection…」,並選擇您下載的Stencils的ZIP檔案,即完成安裝。

image

安裝完成之後,左側「Shape Collections」就會出現安裝好的Stencils囉!


Pencil操作介面介紹

image

Pencil的介面不算複雜,我將之拆成10個部份來講解,請對照上圖來參考:

  1. 檔案管理:開新檔案、開啟舊檔、儲存、另存新檔
  2. 檢視比例:放大、恢復1:1、縮小

以下是操控元件的設定:

  1. 對齊
  2. 移至上層、下層
  3. X軸、Y軸的位置,寬(W)與高(H),角度(A)
  4. 字體顏色、框線顏色、背景顏色:各個元件皆有所不同,有時此處的顏色設定並無法生效,要直接到元件的Properties(屬性)中去設定才行。
  5. 文字排版:包括類別(段落、標題)、尺寸、字型、大小等等。

以下是主要編輯區:

  1. 元件區:分成安裝而來的Shape Collections與您自行設定的My Collections。使用時只要把元件區的元件拖曳到10編輯區中即可。
  2. 頁面導覽列與新增頁面(New Page):您可以在一份檔案中建立多個頁面,並在各頁面中進行連結。
  3. 編輯區:主要編輯的區域。

基本上,您可以把他當作是一個預先有很多網頁元件的繪圖軟體即可。可惜他的對齊功能並沒有很強,無法像Office能夠按著Shift就以固定方向移動物件,也沒有按著Ctrl拖曳物件就能複製物件的作法,但因為工具列可以直接指定位置,所以比起慢慢拖曳,還是輸入數值會快得多。

此外,Pencil還有背景功能、匯出跟連結功能,但連結功能可能是輸出成HTML時才會用到,我並沒有實際用過。所以以下只介紹背景功能跟匯出功能囉!


背景功能

Pencil可以為某一個頁面指定背景,這背景則是另一個頁面。

image

舉例來說,上圖我先畫好的背景頁面。

 image image

接著我就可以在畫其他頁面時,將該頁面設為背景。您可以注意到上面兩張圖中的背景工具列是相同的,只是個別多了不同的訊息與表單而已。

設定頁面背景

image

在頁面導覽列的該頁面上方按右鍵,開啟「Properties…」對話視窗。

image

就能夠設定下方的Background了!


匯出成PNG

Pencil基本上可以匯出成多種格式,其中我最常用的就是匯出成PNG圖檔。以下簡單介紹他的匯出作法。

image

編輯完各頁面之後,選擇左上角的「Document > Expoert Document…」或按Ctrl+Shift+E快速鍵。

image

選擇「Rasterized graphics (PNG files)」,再按「Next >」下一步按鈕。

image

選擇「All pages in the document」,再按「Next >」下一步按鈕。

image

指定輸出資料夾之後,按下「Finish」按鈕。

image

等待他慢慢處理。

image

有時候不知為何地會出現錯誤,不過可以忽視。作完之後按下「OK」鍵就完成了。

image

一張一張的頁面圖就匯出到您指定的資料夾囉。

image

這一張就是用Pencil畫出來的網頁藍圖喔!


結語

Pencil只是一個基本的工具,但他也比起您用PowerPoint的繪圖工具慢慢地畫個捲軸、畫個按鈕,還來得美觀且快速得多。

image

在使用Pencil之前,我還用過MockFlow這個同樣是繪製藍圖的工具。現在許多繪製工具都是以Flash寫成,可以利用網頁瀏覽器開啟、直接線上編輯。MockFlow除了繪製網頁藍圖之外,還提供了各式各樣的藍圖範本,從Facebook的應用程式介面設計到Android手機的使用介面都可以支援,而且提供的元件又更加豐富、對齊功能又好用。但是這個專業軟體只免費提供4張頁面的繪製,超過就要付錢了。我這貧窮小民買不起,才只好摸摸鼻子來使用免費的Pencil。

總之,正所謂「工欲善其事,必先利其器」,Pencil的確為網頁設計的流程帶來不少方便。我可以用一兩天的時間把想像中的網站畫出來,以方便跟其他人討論、尋求建議,而之後也可以作為實際架設時的參考文件。如果您也常常需要繪製網頁藍圖,那麼Pencil應該是一個不錯的選擇喔!

(more...)

Plurk備份與搜尋策略:PlurkBackup + GoogleDocs

布丁布丁吃布丁

Plurk備份與搜尋策略:PlurkBackup + GoogleDocs

image

身為一個噗浪(或稱Plurk)的使用者,把生活中的大小事情都記在噗浪中,是很理所當然的事情。我早已習慣把各種資訊都丟到噗浪,不僅自己作個備份,也能分享給週遭的朋友們。然而,噗浪的使用者都知道,要搜尋早期的噗浪內文,實在是一件非常痛苦的事情。儘管每天都會寫一些資訊記錄在噗浪中,但是卻找不到自己以前寫的資料,那是多麼地不方便。

我以前使用Google Reader來記錄我噗浪的RSS,但是這種方案並沒辦法記錄到回應的內容(為了避免吵到大家,我習慣把相同的資訊用回應集中在同一串噗文中),而且Google Reader的搜尋功能真是差到一種境界,很難想像他居然是掛著Google名號的工具。

最近找尋可行方案時,發現到了Sean製作的噗浪備份工具PlurkBackup,他可以將指定日期範圍內自己的噗文連帶回應地下載到本機端,並以HTML網頁的形式呈現。

除了備份之外,我還需要全文檢索的功能以找尋我寫過的噗文。於是我利用此工具將噗浪以月份分隔下載之後,上傳到Google Docs中,便可在Google Docs裡搜尋我備份的噗浪內容了。

以下就以圖文並茂的方式,一一來說明我的噗浪備份與搜尋策略吧!


1. 下載PlurkBackup

PlurkBackup是綠色軟體,下載解壓縮後便可直接執行。


2. 備份噗浪

image

PlurkBackup的功能介面非常簡單。請輸入帳號、密碼、日期開始與結束的範圍、選擇是否要分離私噗(私密的噗浪文)、指定輸出的資料夾位置。最後按下「開始下載」按鈕,就可以運作了。

image

上圖就是備份完成的網頁檔案。

使用時有幾點需要注意:

  1. 日期範圍前後可對調:「2010年6月1日 至 2010年6月2日」或「2010年6月2日 至 2010年6月1日」,下載之後都會是這兩天的噗文。
  2. 備份下來的檔案名稱會註明日期,以上述例子來說,檔案名稱將會是20100602-20100601.html
  3. 備份時會由時間越晚越先備份。如上圖備份檔案所顯示的,7月21日會比7月20日還在網頁上方。
  4. 開始下載時,該視窗將無法移動、放大縮小,甚至看起來會像當掉一樣。
  5. 有時候噗浪備份工具真的會當掉!請利用工作管理員把他關掉吧。

此外,由於之後我打算上傳到Google Docs以獲得全文檢索功能,而Google Docs對於文件的大小有所限制(要轉換成Google Docs格式才能檢索到內文喔),單一文件檔案大小必須低於500KB,所以我日期範圍是以1個月(例如:2010年5月1日 至 2010年5月31日)或是半個月(例如:2010年5月1日 至 2010年5月15日)為主,以免單一檔案大小過大。

image

如果您擔心自己噗浪的密碼會外洩,建議您可以先到噗浪上把自己的密碼暫時修改成暫時用的密碼(例如123456789),然後用暫時用密碼來備份噗浪。待備份完成之後,再將密碼改回來即可。


3. 上傳到Google Docs

image

Google Docs提供了免費1G的空間,可讓您上傳各種資料,把他當作一個免費的網路硬碟使用。如果您還沒有Google帳號,何不申請一個來用用看呢?

image

Google Docs在日前的改版中,已經可以建立Folder(資料夾)了。於是我建立了一個名為「Plurk」的資料夾,專門擺放我備份的噗浪資料。

image

點下首頁左上角的「Upload」按鈕之後,就可以進入Upload Files(上傳檔案)的畫面。您可以在此選擇要上傳的檔案打勾「Convert documents…」(將各種文件轉換成Google Docs格式)的選項以讓Google Docs可以搜尋他的內文、並於左下角選擇上傳目的的資料夾「Plurk」。最後按下「Start upload」,很快就可以上傳完成囉!

image

上傳完成,在Google Docs裡面顯示的格式就如上圖!

以後您就可以在Google Docs中隨時調出噗浪的記錄囉!


4. 搜尋噗浪記錄

將噗浪上傳並轉換成Google Docs之後,您就可以利用Google Docs的搜尋功能來找尋備份的噗浪記錄!

image

Google Docs的搜尋框就在上方,您可以單純輸入關鍵字搜尋全部Google Docs的資料,也可以點開「Show search options」以進入進階搜尋。

image

在進階搜尋中,除了指定關鍵字之外,還可以在左下角指定Search folders(資料夾)為「Plurk」,讓搜尋範圍更為明確。

image

搜尋的結果會列出來,表示我在這些期間皆有在噗浪中提及「詐騙」這個字眼。然而在這個搜尋結果中,是沒有辦法像一般Google搜尋一樣,能同時顯示被搜尋文字的上下文。

image

打開文件內文,並利用Ctrl + F開啟搜尋功能,就可以知道這篇備份中要搜尋的關鍵字的位置了。


利用這個噗浪備份策略,我得以方便地回溯之前在噗浪上零星記載的詐騙資料,並整理出昨天寫得三篇詐騙文(檢察官偵訊與法院判決書新竹法院的調解不成立主嫌上訴),也相當符合我使用Plurk作為筆記、Blog作為匯整的想法。因此在此也推薦各個噗浪使用者利用這個策略來備份噗浪!

(more...)

[詐欺案件] 主嫌上訴

布丁布丁吃布丁

[詐欺案件] 主嫌上訴

收到調解傳票後幾天,我又收到另一封來自於臺灣高等法院的傳票,詢問書記官之後,得知這次是詐欺案件主嫌數人提出上訴,因此這次不是地方法院而是高等法院的審理。書記官跟我說,被害人可到可不到、也沒有旅費,能做的事情頂多就是跟法官說說話而已。實際上今早的開庭也的確是如此,許多被害人怒氣沖沖也只能呆作門外,直到審判結束之後才能進去法庭跟法官抱怨抱怨。


這次開庭地點是在臺灣高等法院刑事大廈,他位於台北地方法院的隔壁,外觀內部似乎也跟台北地方法院沒差多少,但是進入時就要經過X光檢查包包是否有危險物品,可以感受到一種慎重的氣氛。

抵達法庭報到時,不意外地看到門外大概超過50多個人待在走廊等待開庭,法警面對大排長龍的受害者,一一確認報到資料。報到完之後就只能附近找個板凳空位坐下,許多青少年受害者身旁有父母陪著,大家聊天的內容不外乎都是受騙過程、金額、以及悔恨的心情。

不久,戴著手銬腳銬的犯人們鋃鐺入庭,他們都剃了個光頭,表情平靜。似乎並沒有把這一群受害者擺在眼裡——所以他們才覺得自己被判得太重了,要求上訴減輕刑罰吧?

開庭之時,法警傳喚了幾個人的名字,但大部分沒被叫到的人仍然作在外面。有些受害者擠在門外,從法庭開啟的大門間觀看,可以看到法官、被告等人,但是完全聽不清楚他們談論的內容,也就無法得知審判的過程,更不用會有在審判中講幾句話的機會。

一個小時左右,審判結束,犯人又是鋃鐺離庭,法警開始一一發回身份證、受理附帶民事訴訟,並指示有任何意見的受害者,此時可以跟法官提出。

儘管我事前問過書記官,早就知道這場差不多也是這種感覺。但是許多受害者對於自己無法觀看審查經過、也無法介入審查過程、又拿不到旅費等感到不滿,甚至有人激動地快要跟法警吵了起來的感覺。

一些受害者排隊等著進入法庭跟法官訴苦,法庭內傳來震震的怒斥聲,被害者無以宣洩的怒氣,此時只有法官等人聆聽,還是無法傳達到那些詐欺犯身上。


回來之後我查了一下司法院的開庭進度查詢,得知此案月底還有另一場審判程序。如果我們被害人仍然只是在外面坐板凳的話,那下次可能就不去了吧。

(more...)

[詐欺案件] 新竹法院的調解不成立

布丁布丁吃布丁

[詐欺案件] 新竹法院的調解不成立

20100526 新竹地方法院傳喚調解_頁面_2

五月初,我收到了來自新竹地方法院的傳票,才知道原來詐欺案件還沒有結束。

傳票上面註明我是去參加調解,但是我並不知道到底要調解些什麼。那時也沒有先打電話去問書記官(傳票上面都會註明電話喔)。就傻傻地在報到日期坐車去了新竹法院,本來以為可以經由調解從被告拿回三萬元,但是調解經過讓人一肚子火,最後憤而回來寫了附帶民事訴訟寄了出去。這調解簡直浪費時間,直接告了比較快。


被告遲到,調解過程沒誠意

我在報告時間前十幾分鐘抵達了新竹法院,並完成報到手續。雖然被告還沒來,但那位看起來像是調解委員的人信誓旦旦地向我保證一定會拿回這三萬塊,讓我安心了不少。

一邊與傻殿聊天、一邊等待被告,可是被告卻遲遲不來。我們等了半個多小時之後,最後也無奈地準備離開。沒想到還好在報到處時與姍姍來遲的被告碰頭,於是又回到了調解室,開始了遲到半個多小時的調解。

到那時我才大概知道為什麼我要來調解、調解的內容是什麼。

被告是我當初被詐騙時匯入的帳戶擁有者,而被告被檢察官認為是詐欺主嫌的同夥,也就是提供帳戶的共犯,所以認定被告有罪,處有期徒刑快三個月。但由於被告的帳戶中受騙金額都是小額,法院認為他可先調解以減輕刑罰。打聽之後,發現除了我之外,還有另一位也是被騙三萬多,只是當天調解時另一位並沒有出現。

調解室裡面只有調解委員、受害者也就是我、被告三人,我跟調解委員皆認為三萬塊錢是小錢,被告應該可以輕易地拿出來。沒想到被告堅持自己無罪,也不願意花錢消災,絲毫沒有付錢讓調解成立的意願。

事實上,這種調解的確對被告不利。要嘛就是給被害者錢、減輕刑罰;要嘛就是不給錢,三個月照罰;要嘛就是三個月照罰,再加上我提出附帶民事訴訟,由法院強制被告掏錢。不管從哪種方向來看,被告都是虧。儘管這點很也很多人在抱怨,但不管他是共犯或是帳本被偷走,都是他自己理虧在先,實在是很難說無罪又沒有責任。

但問題來啦,被告就是堅持自己無罪,又不想扛任何責任。一個消息是我被詐騙的錢並沒有被領走,而是存在被告的帳戶中。由於該帳戶被結凍,被告也無法領取。因此被告提出的條件是:「法院解凍我的帳戶,把錢還我,然後我再把錢給你。」但是這種條件基本上是不可能成立的,被告在調解的過程中也很清楚這個事實。換句話說,被告真正的目的是想要靠調解來減輕罪行,又不想賠我錢。

調解過程非常糟糕,被告態度強硬、沒有協調的空間、甚至想強行曲解我的意見。我提出分期付款的調解條件,但被告顯然不接受。最後乾脆今天調解先延後,我希望被告回去想一想能不能接受分期付款的條件,但被告表示他要去找找讓法官判他無罪並賠他錢的方法。

到最後他的態度仍然令我嘆氣,因此從新竹回來之後,乾脆憤而提起附帶民事訴訟比較快。

附帶一提,調解並沒有旅費,只有證人身份才有旅費,這也讓我碰了一鼻子灰。


附帶民事訴訟

與錢相關的問題,都是民事的範圍。附帶民事訴訟是跟著被告的刑事訴訟一起跑,可以節省訴訟費,許多事情湊在一起解決,對法院來說也比較方便。

回來之後我與家人討論討論,仔細想想,如果被告堅持要法院提出錢,那我就給法院一個提出錢的理由——附帶民事訴訟。對被告來說最好的情況是法院從他被凍結的帳戶中提錢來還我,不好的情況就是被告要自己想辦法。

我從司法院的網站上下載了附帶民事訴訟的起訴狀範本,並打電話詢問書記官以獲得需要填寫的資料內容,最後事實及理由的部份則是請法扶會的律師免費諮詢來確認,然後寄到新竹法院以完成提告的動作。詳細的過程請看此串

提出附帶民事訴訟同時,我也取消了調解,也就是以調解不成立收場。未來可能此案還會在民事訴訟時傳喚我,到時候就走著瞧吧。


浪費時間的調解

收到傳票時,一定要先去詢問書記官,看看自己被叫去幹麼?可不可以不去?不去的話會損失什麼權益?去的話能不能申請旅費?

這次調解案,如果早知道被告的態度如此之差、調解條件又這麼沒誠意,我就不會花了三百多交通費千里迢迢地跑到新竹去開庭,然後一肚子大便地無功而返。如果知道被告打算這樣,那我就直接調解請假,提出附帶民事訴訟就好。又快又省事,連書記官都認為我直接提告、不用再繼續調解拖下去比較實在。

收到傳票時請跟書記官聯絡一下,問清楚了再去法院。希望這個教訓能跟大家共勉之。

(more...)

[詐欺案件] 檢察官偵訊與法院判決書

布丁布丁吃布丁

[詐欺案件] 檢察官偵訊與法院判決書

繼去年年底我被詐騙的案件之後,最近又發生了許多相關的事件,這整件事情還沒結束。由於事情有點多,所以我想一篇一篇地慢慢來整理一下。

距離詐騙發生、報警,經過一個多月之後,我收到了來自法院的傳票,叫我去偵訊。偵訊只是檢察官在法庭上詢問各個受害人的受害狀況,以作為提出詐欺罪的證據,因此偵訊並不會看到詐騙集團,也沒有法官。

我與一堆受害者以證人的身份被傳喚,大家在偵訊室中一一地說出受騙的經過與金額,其中也有被騙走帳戶的受害者。特別的是,有個受害者驚覺自己帳戶被騙而凍結,他就利用另一本帳戶引用詐騙集團上鉤來進行交易,再夥同警察將他們逮捕。根據後來判決書所寫的內容。似乎這是其中一條破案的關鍵。勇敢的被害人大哥,謝了!

偵訊的內容即作為法庭上判決的證據,所以後來我也沒有收到任何需要出庭的傳票。


偵訊結束後又隔了四個多月,家裡收到一本厚厚的法院判決書。判決內容大概有10幾頁,而後面其他都是受害者名單與經過。根據受害經過的記錄,有人被騙了快要百萬,實在是相當的可憐。

判決書中,被告有11人,由於受害人相當多,每個人都有四百多、五百多條罪名,處有期徒刑一年十個月、二年八個月,主嫌甚至處刑四年八個月並強制工作三年。

判決書的結果主要摘錄如下:

(四)爰審酌被告等不思循合法正當途徑獲得財富,竟利用如附表一、二所示之被害人對於人性之信任、深處經濟困境時急於借貸之心情,及貪小便宜、難以克制美色誘惑等人性弱點,詐使如附表一、二所示之被害人陷於錯誤後,分別匯出如附表一、二所示之款項,被告乙z○、n○○更於以如附表三所示之方式詐取如附表三所示之金融帳戶後,用以詐取如附表四所示被害人之款項,顯見渠等之守法意識均相當薄弱,應予非難;另考量被告甲午○、乙丁○、乙z○、戊F○四人除自身加入詐騙集團外,復招攬、吸收下線加入,及其等於集團內實際負責之工作,堪認其等在集團中實居於主要地位;被告辛○○雖並未招攬下線,然其負責之工作包含刊登詐騙廣告,及向因陷於錯誤而撥打電話與其聯絡之如附表二所示之被害人為實際詐騙行為,堪認其參與程度亦較深;至被告n○○、丁E○、乙h○主係擔任收取人頭帳戶之工作,被告甲R○、丁辛○、戊○○則係擔任車手工作,在詐騙集團中非屬核心角色等情,暨如附表一、二、三、四所示之被害人受詐騙之財物損失,及被告等於本院審理時均坦承犯行,然實際上均未賠償各被害人任何損失,及各被告之犯罪動機、手段、生活狀況、品行、智識程度等一切情狀,分別量處如主文所示之刑,及就被告n○○、丁E○、乙h○、甲R○、丁辛○、戊○○部分,各諭知易科罰金之折算標準,再各定其應執行之刑,及就被告n○○、丁E○、乙h○、甲R○、丁辛○、戊○○之應執行刑併諭知易科罰金之折算標準。
(五)再按,有犯罪之習慣或因遊蕩或懶惰成習而犯罪者,於刑之執行前,令入勞動場所,強制工作。前項之處分期間為三年。但執行滿一年六月後,認無繼續執行之必要者,法院得免其處分之執行。執行期間屆滿前,認為有延長之必要者,法院得許可延長之,其延長之期間不得逾一年六月,並以一次為限,刑法第九十條定有明文。……經查,被告甲午○、乙丁○前已曾因加入以賴銘楷為首之詐騙集團而犯常業詐欺取財案件,此有臺中高分院九十七年度上訴字第三一六二號及最高法院九十八年度臺上字第五八二○號刑事判決在卷可稽,於該案遭查獲後,仍不思悔改,竟貪圖詐騙可輕易獲取之暴利,再另起爐灶,而為本案事實二所載之四百九十一筆詐欺犯行,顯見其二人之品行頑劣、惡性重大,係有犯罪之習慣及以犯罪為常業之人。因之,若僅單純予以論罪科刑施予刑事處罰,顯難收矯劣治惡之效,有予令入勞動場所強制工作,藉以摒除不勞而獲之心,訓練一技之長之必要,爰均依刑法第九十條之規定,諭知於刑之執行前,令入勞動場所強制工作三年;至被告乙z○部分,公訴人雖亦認其係恃詐欺為生,有宣告強制工作之必要等語,然查,被告乙z○於為本案犯行前,並無詐欺之前科,此有臺灣高等法院被告前案紀錄表一份在卷可佐,則其是否確有犯罪之習慣,已非無遺,又矯正被告乙z○犯行之有效方法,在於提供其適當之更生保護、就業機會及社會扶助,並非僅有執行強制工作之保安處分一途,且強制工作之保安處分係對被告人身自由之長期且嚴格之限制,本應從嚴認定,況本院既已於量刑時,將被告乙z○之涉案情節、參與程度、犯案次數等一切情狀均納入考量,而諭知如主文所示之刑,對被告乙z○已足收警惕矯治之效,爰不另為強制工作之諭知,附此敘明。


收到判決書之後,我就想說是否可以提出附帶民事訴訟或是其他民事訴訟的,想辦法把受騙的三萬元拿回來。但是打電話詢問是否可以尋求法律扶持基金會協助時,卻收到「10萬元小額訴訟無法提供扶助」的回絕。

那時想說,完了,三萬塊就真的像是丟進水溝一樣,一去不回了。沒想到,事情還沒結束。

(more...)

以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...)