W IKI 實作主題式資源指引網站改善策略

回顧表 3-3 所提及之以 Wiki 實作主題式資源指引網站的缺點，其中內容未經組織、

權限太過開放、被人惡意破壞、垃圾條目攻擊等問題，可藉由挑選適當的 Wiki 引擎加 以克服，本研究所採用的 ccTiddly 因為會員註冊並不採開放申請的方式，故權限太過開 放及惡意破壞的問題並不存在。以下茲針對其它八點問題加以探討：

1. Spam 問題：Wikispam 是指在 Wiki 引擎上濫發一些無意義的條目，通常此類條目 都是些廣告資訊。目前有許多工具都是針對 Email Spam 所開發，對於 Wiki Spam 的處理工具則較為少見，處理 WikiSpam 的方法主要有下列三種，本研究採用限 定申請註冊後的使用者及加上內容審核制的方式進行管控。

z 常規的管控方式：進行人工檢視，發現不當的內容則手動進行刪除並暫時/

永久封鎖系統內的問題使用帳號。

z 限定申請註冊後的使用者：使用者提供完整的個人資訊且經完成申請程序後 才能使用 Wiki 系統，例如 DoNews。此種方式一定程度上損害了 Wiki 的開 放性。

z 外掛功能：限制來源 IP，如 Mediawiki 軟體所提供 Spam Blacklist 功能 (www.mediawiki.org/wiki/Help:FAQ#Anti-spam)；或者使用特定的標籤，如 (-{<nofollow>}-)，用以禁止搜尋引擎對 Wiki 內容的外部鏈接進行分析，主要 是處理垃圾鏈接(Spam Link)，可降低 Spam 效果。

2. 社群模式(Community Model)挑選：社群模式挑選是採用開放註冊的方式或是採其 它方式獲得解決，此問題對圖書館而言絕不是什麼大問題，因為圖書館本身就擁有 自己的使用社群，也就是圖書館的讀者。不管採用那種 Wiki 引擎，都必須修改原 有的認證模組，將 Wiki 與圖書館自動化系統的認證模組加以串連，圖 3-2 為更改原 有認證方式的流程圖。

3. 品質控制(Quality Control)：透過共筆方式所建置的資料，其品質是否能為館員所接 受？由於 Wiki 的設計理念及運作精神是所有使用者皆可對任意條目執行新增、編 修…等動作，而此種方式如果直接應用在圖書館內，它所產出的文件內容，馬上就

面臨挑戰與質疑。該如何引入一個機制，能為其把關？為此，本研究修改了原有的 能提供更多的檢索點(Metadata issue)。以 ccTiddly 而言，僅能提供全文檢索，當資 料龐大時，則以全文檢索所檢索出的資料會雜亂無章。而要提供更多的檢索方式，

後之資料庫綱要。

圖 3-3 審核流程圖

tiddly wiki entry/ tiddly_wiki_entry_version

欄位 型態 NULL 預設值 用途

id int(11) 否 系統號

title varchar(255) 否 名稱

body text 否 描述內文

modified varchar(128) 否 修改時間 modifier varchar(255) 否 修改者

否 創作時間 使用者

認證

自由編寫

Discard

新資源

學科專家審核

完成

Discard

館員專家審核 Discard

DC 著錄

主題分類 No No

原模式 修正後

Yes

Yes Yes

No

creator varchar(255) 否 創作者

version int(11) 否 0 修改次數

tags varchar(255) 否 標籤

圖 3-4 ccTiddly 資料庫綱要

資料表 用途 註解

Tiddly_wiki_entry ccTiddly 資料表 建立：Sep 25.2006, 10:00AM 最後更新：Oct30,2006,03:59PM Tiddly_wiki_entry_version ccTiddly 資料表，版本控

制用

建立：Sep 25.2006, 10:00AM 最後更新：Oct30,2006,03:40PM Metadata 記錄詮釋資料 Innodb free:4096KB

建立：Sep 25.2006, 10:00AM Ptotect_title 保護頁面功能 Innodb free:4096KB

建立：Sep 25.2006, 10:00AM recom 推薦資料 Innodb free:4096KB

建立：Sep 25.2006, 10:00AM User 紀錄管理者資訊 InnoDB free：4096KB

建立：Sep 25.2006, 10:00AM 圖 3-5 調整後之資料庫綱要

連結、建立表格、建立標題、縮排、插入水平線、樣式、WikiWord 、使用固定字…

等操作，皆是利用 Wiki syntax 完成，但這對於從未接觸過 Wiki 的使用者，是十分 困擾的。故系統的操作介面設計，朝兩方面進行，原 Wiki 功能則讓原本熟悉 Wiki Syntax 專家使用，可提供更為彈性操作，另外設計 WebForm 的介面供管理者與 Wiki Syntax 初次體驗者使用，方便進行管理與資源推薦，藉以減少額外的學習。WebForm 管理介面功能涵蓋修改網站入口標題、副標題、資源的審核…等功能，而資源推薦 設計則是明顯地標記出所需要的欄位，例如資源名稱、資源網址、資源描述等欄位 供使用者填寫，推薦者一目了然不需額外使用 Wiki Syntax。

Subject Gateway Wiki System Work flow

圖 3-6 SGWS 審核工作流程 開始

發掘資源

學科專家 拒絕

館員

系統自動擷取詮釋 資料

分類

完成

人工著錄

(Dublin core metadata) 推薦資源

Yes No

Yes No

Yes

No

7. 頁面保護：內容若經過審核後，或是頁面不希望再經變動時，該如何提供保護這些 頁面呢？以 Wiki 的機制、精神而言，它是開放的，只要是信任社群，就有權限可 以更動頁面資料，但對圖書館而言，要拿 Wiki 來實作主題式資源指引的應用時，

網站內的資料，例如入口處的歡迎詞，或是已通過資源審核後的內容，仍不希望已 通過認證的讀者可以做修改或更動時該怎麼做；對系統管理人員來說，由於 ccTiddly 的外掛功能可透過 Wiki 頁面完成，只要將讓頁面的標籤(tag)定義為 systemConfig，

系統就能立即引入該巨集功能，此功能可說十分方便，但也充滿著危險，此時就需 引入頁面保護的機制，將這些不希望改變頁面做限制。

8. 統計功能：「大學圖書館設立及營運基準」第 35 條明確指出「大學圖書館應定期進 行館藏、讀者服務及技術服務之調查統計，實施績效評估，並據以改進服務品質 [26] 。系統若無具體的數據可供佐證，服務的績效難以量化，後續的評估、改善亦 無法進行，更遑論做出合理、正確的決策。而 Wiki 引擎本身並無考量此一功能，

可供使用，在此引入 AWstats 軟體(http://awstats.sourceforge.net/)，也額外新增了審 核資源統計功能，藉此可分析使用者的使用狀況與系統內實際通過審核的資源總 數。

四、系統設計

3.4 節中提出以 Wiki 實作主題式資源指引網站的改善策略。以此為基礎，本章提出 系統之設計概念與架構，包括系統設計的目標與規劃、系統架構、系統後置處理等。