檢視國家歷史文物數位化典藏計畫資訊技術工作手冊的原始碼

執行成效

計畫產出

本年度依建置歷史文物詮釋資料（metadata）及索引典、建置智慧型歷史文物多媒體資料庫、建置歷史文物資料處理數位化制度三項目標分段完成。本館原數位化博物館發展已朝向網路化、整體性、前瞻性方向邁進，而結合本次計畫，運用科技改善並豐富終身學習環境、提高政府組織工作效率並促進產業發展；同時考量民眾需求，以服務民眾為主，及加強政府組織與民眾雙向互動之管道。

各項執行內容分為：

1. 數位化元件製作

2. 文物詮釋資料分析

3. 數位流程管理系統建置

4. 多媒體資料庫建置

5. 儲存設備建置



== 數位化產出清單 ==
1. 數位化元件處理類別包括：文物圖像資料、參考文獻、影片資料三類（詳如附件一），預定製作1509 件均依計畫執行完成。包括，銅器類：先秦青銅器、戰國銅帶鉤、漢代銅鏡等。（683 件），版畫類：木刻版畫、清末年畫、17至19世紀的浮世繪等。（826 件）

2. 數位流程管理系統（詳如附件三）

A. 位流程管理Unified Modeling Language(UML)核心工作流程圖

B. 究出版數位典藏管理系統

3. 多媒體資料庫（詳如附件四）

A. E-R model

B. Logical Schema V2.5

C. Physical Schema V2.2

4. 儲存設備Total Storage 建置（詳如附件五）



== 設定的規範與標準 ==
產出規格（數位化原件）

關於典藏數位化儲存檔案格式之運用，概述如下：

根據國科會訂定「國家典藏數位化」有關文物掃描技術問題提及：

★ 解析度（高DPI）平面圖像之製作，為達成文物圖像不失真、永久保存及可欣賞之高品質，製作高解析度文物圖像為基本之製作需求。

★ 應不同目的呈現圖像之需求，圖像有必要呈現不同之解析度，同一文物需製作不同解析度之圖像。

圖檔因應不同品質要求可區分下列三種，都是國際標準通用檔案格式

A. TIF 檔案格式（Tagged-Image File Format）

TIFF 是用在應用程式或電腦作業平台之間交換檔案。TIF 是在所有圖檔中最具彈性的點陣影像格式，TIF 可支援所有的高階點陣繪圖、影像編輯、和排版應用程式。同時，所有掃描器都可產生TIF 影像。TIF 可支援CMYK、RGB、含Alpha 色版灰階檔案。簡單講，TIF 是所有圖檔的「母檔」，也是最高品質的檔案，由於TIF 的檔案量最大，因此，幾乎所有衍生低量的圖檔都可由TIF 檔案格式轉換。例如故宮、北美館、中央研究院、立法院等，不論儲存多少種檔案格式，TIF 檔一定含括在內。

B. JPG 檔案格式（Joint Photographic Experts Group）

JPEG 檔案格式是運用在全球網際網路和其他線上服務中，是最常運用在HTML（Hypertext Markup Language）文件中顯示圖像連續色調的檔案格式。JPEG 格式也支援CMYK、RGB 和灰階色彩模式，但不支援Alpha 色版。

JPEG 可由TIFF 轉壓縮檔，以減少儲存空間及方便傳輸，其壓縮方式可分四種程度：（1）Maximum。（2）High。（3）Medium。（4）Low。以TIFF 20MB 檔案轉JPG 為例，Maximum 為6MB，High 為880K，Medium 為388K， Low 為236K。檔案量愈小，傳輸速度愈快，但失真程度也愈高。

C. GIF 檔案格式（Graphics Interchange Format）

GIF 也是用於全球網際網路和其它線上服務中，亦用在HTML 文件中以顯示影像的檔案格式。也不支援Alpha 色版。GIF 是一種LZW 壓縮格式， 主要設計用途是最小化檔案和快速電子傳輸時間。GIF 不同JPEG 的是， GIF 僅能顯示RGB 色彩，不能用於CMYK。GIF 也是從TIFF 檔案轉壓縮， 壓縮後的容量約為TIFF 檔的五分之一。

[[圖片:TIFF、JPEG、GIF 三種圖檔之比較.jpg|center]]
本館目前採用規格

*永久保存檔 600 dpi TIFF CMYK 檔
*永久保存檔 300 dpi TIFF CMYK 檔
*用於網路傳輸 150 dpi JPEG 檔
*參考文獻 300 dpi PDF 檔
*動態影像 Intranet MPEG I、Internet WMV 28~100 Kbps



作業規範
A. 數位化元件製作作業規範
[[圖片:數位化元件製作作業規範.jpg|center]]
B. 影像掃描檔案格式說明

TIFF：這是前Aldus 公司（現已合併入Adobe 公司）設計出來的桌上排版圖像格式，也是另一個我們會經常使用的格式之一。TIFF 格式可儲存任何顏色的文件（黑白至24Bit，RGB 及CMYK），亦可存為Mac 或PC 的格式，亦有將文件壓縮的選擇。在這裡的LZW（Lempel-Ziv-Welch）壓縮程式，是不會影響圖像質素的。常用的一些壓縮文件軟體，如Aladdin 的Stufflt，亦是用此程式。

TIFF的優點：
#使用壓縮方法存檔之時文件體積較細小
#可在排版軟體中做高解析度顯示
#在大部分排版軟體中都可以直接控制TIFF 文件的光度、反差或著色等
#可在QuickDraw 列印機上可列印出高解析度的圖像
#可利用ColorSync 等顏色管理方案來校色
#可利用QuickEditx 來編輯

TIFF的缺點：
#單一的文件，在分色時要下載四次
#高解析度顯示之時，在排版軟體操作減慢
#不能去背

 

PDF(Portable Document Format)是Adobe 公司發展的一個跨平台的可攜式個人文件格式，需要使用特別的瀏覽工具(Acrobat Reader)來開啟。

PDF的優點：
#文件可以用相當的質素來保存，但文件體積就可以縮至幾乎四分之一的大小，適合用於線上傳送
#適合圖文整合的儲存格式

PDF的缺點：解讀圖檔的功能不強，也就是色彩模式會不準，因為PDF 主要是用於文件格式，並非圖檔。

C.  數位流程管理系統建置作業規範

運用Unified Modeling Language(UML)統一塑模語言，分析博物館核心工作流程。

博物館營運的初端是從文物典藏管理和流程開始，並認知博物館知識分享的必要性。典藏管理的核心就是管理文物資訊的流動，主要目的乃在於「將最正確、適當的文物現況資訊、知識，在最適當（短）的時間，提供給最需要的人」，因而能快速採取行動。資訊流動的範圍擴及全館，以典藏組、研究組、展覽組為使用重點。

運用UML 進行分析規劃，其主要目的就是要將典藏管理流程視覺化和文件規格所用的符號加以統一。並依文物資訊產生的動態流程、各關係者及使用情境、環境做出整體的規劃分析﹔以切合目前及未來延伸之功能需求。本階段將依序完成下列步驟：

a. 使用案例圖(Use Case Diagram)

以視覺化塑模有效的收集典藏管理流程，以使用案例分析方式來收集典藏管理流程時，會找出系統的行為者（使用者）、使用案例（典藏管理流程）、以及行為者和使用案例間的關係。需求收集、分析、架構設計、以及元件設計，均以UML 的符號來表達。

b. 次序圖(Sequence Diagram)

次序圖主要呈現出在一個時間序列上，典藏程序是透過那些物件彼此間傳遞訊息(message)而完成的。在紀錄完典藏管理流程的情節後，根據這些情節加以分析，找出完成此情節的物件和彼此間傳遞的訊息，再加上時間軸，繪製成次序圖。

c. 類別圖(Class Diagram)

類別圖主要表達出系統靜態結構，在分析完次序圖後，整理出從各個情節中的物件，進一步去發掘物件彼此間是否存在有共通性，然後定義出用來產生這些物件的類別，並根據次序圖的訊息資訊，定義出類別之間的關係，最後繪製出類別圖。在設計階段，若是因為設計的考量有增加新的類別時，則需再檢討新類別是否會對原先的類別圖產生影響，檢討後的類別圖就成為因設計考量而調整的結果，而無需修改分析階段的類別圖。

d. 狀態圖(StateChart Diagram)

狀態變遷圖主要呈現狀態轉換的次序，及在物件存在時，接受到事件時所反映出的狀態變遷和行動(Action)，若系統內的物件有狀態變遷(statetransition)的情形，就需要透過狀態圖的繪製，協助分析物件內部的動態行為，即狀態轉換的過程。狀態圖適合描述跨數個使用案例之物件內之行為變換過程。

e. 元件圖(Component Diagram)

元件圖主要表達系統被切割成那些軟體元件以及軟體元件（如：原始碼元件、二元碼元件(Binary Component)、可執行元件(Executable Component)間的關係，分析完成之後加入設計機制的考量和定義類別內屬性和方法的參數及還回值的型態外，並決定系統將被切割成那幾個軟體元件以及軟體元件之間的，然後繪製元件圖。

f. 系統佈建圖(Deployment Diagram)

面對複雜的網路系統，可能有多個Server(Database server/Transaction server/Web server)和多個Client，系統元件也將分佈在不同的server 上執行，在同一個Server 上，不同的程序同時執行不同的元件。因此，需要透過佈建圖好好規劃系統在實際環境執行時，各運作單元(如Regustration, Database node)的分佈安排、彼此間的關係的定義、以及在各運作單元上所執行的軟體程序(Software Process)的安排。

因此，從需求收集、物件導向分析／設計、架構設計（N-Tier, Internet/Intranet, 元件化架構）、甚至到系統上線的佈建圖，均以UML 定義標準塑模符號給發展者於系統視覺化、溝通和產生各式文件時使用。這些推導過程是循環漸增式的(Iterative and Incremental)，彼此間環環相扣，相互確認，一直到整個模型同步穩定為止。



採行標準（metadata 部份）

A. 對照國際標準進行元素英文轉譯工作(CDWA)

B. 配合計畫辦公室內容發展組參與書畫小組、器物小組及金石拓片小組工作進度

C. 本館研究人員及文物管理人員針對本年度metadata欄位結構、元素內涵、定義、著錄規範等進行討論及試用



工作程序

A. 各類元件數位化進行方式：

a. 文物圖像資料：彙整本年度執行範圍銅器及版畫文物，過去歷年已完成數位化之圖片檔案，檢視現有數位檔案格式是否符合計畫訂定之規格標準，過濾出尚未完成之文物清冊後發包進行正片掃描工程。

b. 參考文獻：彙整本館銅器及版畫文物歷年相關出版，包括：館刊、學報、圖錄、史物叢刊等文獻，以文章主題為單位，完成約100 篇數位檔案，提供著錄參考文獻資料。

c. 影片資料：完成銅器及版畫相關錄影帶、光碟及研討會、演講實況影數位檔案，提供著錄參考文獻資料。

B. 數位流程管理系統進行方式：

西諺有云：A picture is worth a thousand words。我們也常說「百聞不如一見。」在軟體技術領域，圖形是表達與傳遞軟體知識所不可或缺的工具。OpenFlow 系統的設計目的是要為網路程式的設計、開發、管理與維護等軟體生命週期的幾個程序找到一個共通的，可以用來表達軟體結構的圖形化表示法。為了達成這個目標，網路軟體的核心：程式碼，就必須被「整型」一下才能同時滿足設計、開發與維護的需要。

網路軟體與使用者互動的主要媒介是Web 與Email，而互動的主要方式是透過一系列的表單傳遞與回應的步驟。這個一系列的步驟也就是使用者與程式之間的互動關係。OpenFlow 系統的主要創新之處，是利用程式與使用者間互動關係的流程圖來表達程式的邏輯結構。

為了要讓程式碼與流程圖整合在一起，OpenFlow 也歸納了這些互動步驟的主要功能，並且將需要完成這些功能的程式檔案與這些步驟整合在一起。結果就是一份既可以當程式設計圖，又可以被檔案管理員(File Manager)使用的程式檔案圖的整合了圖形與文字的程式表達方式。這張圖也剛剛好解決了網路程式檔案眾多、連接關係複雜，所導致的難以管理與維護的問題。

OpenFlow 的主要貢獻是用一個圖文整合的程式語言，將原本不容易整合的網路軟體生命週期的幾個程序，整合在一起。這個「一魚雙吃」的設計，同時整合了程式設計圖與程式檔案圖，因此能讓網路程式的開發與維護達到「事半功倍」的效果。

舉例來說：在軟體設計的初期，程式設計師與使用者可以互相討論程式與使用者應有的互動邏輯，並且將這個邏輯用流程圖表達出來。有了流程圖之後，程式設計師可以直接的使用流程圖中的步驟圖示(icons)來開啟並撰寫需要完成該步驟的程式碼。在開發過程中，如果需求有改變，程式設計師可以很容易的找到需要修改的流程圖及相關的檔案以完成修改的功能。由於設計圖與程式碼是同樣一份文件，因此使得文件及程式碼的設計、開發、管理與維護都大為簡化。避免了傳統開發方法，文件與程式碼不相同，所容易造成的不一致的問題。也節省了需要產出與維護許多不同設計文件的成本。

「國立歷史博物館數位典藏計畫」的同仁，使用了OpenFlow 系統開發了「月刊書籍出版系統」與「展覽流程規劃系統」。由於上述OpenFlow 系統的好處，使得開發人員能迅速掌握需求，並且能有效的與使用者溝通，因此能大幅的增進開發的速度。不但如此，所有系統的設計架構及程式碼都可以「按圖索驥」的找到他們的蹤跡。這個特性使得開發出來的系統，可以很容易的針對其他單位的類似需求，提供迅速又節省成本的解決方案。

目前OpenFlow 系統的程式語言是Perl。支援PHP、JSP、ASP 等語言的版本正在開發中。預計這些非Perl 語言的版本，可以於明年（2002 年）開發完成。由於程式語言不同的限制，所以這些語言的版本可能不能完整的提供目前Perl 語言版本的所有功能。在未來， OpenFlow 將會朝與CVS (Code Version System) 及軟體測試技術(software testing)結合的方向，設計專屬的開發方法與工具，以支援軟體開發團隊所需要的完整功能的方向邁進。

 

OpenFlow 開發端， 伺服端， 使用端的軟硬體需求

● 開發端：

■ 軟體需求：OpenFlow Visual Designer for Windows 98, Windows 2000, or Windows NT.

■ 硬體需求：X86 型個人電腦

● 伺服端：

■ 軟體需求：

◆ Windows 2000 with IIS, PerlEx, ActivePerl, OpenFlow Application Server Version 1.0 for Windows 2000

◆ Linux or Unix with Apache Web Server and OpenFlow Application Server Version 1.0 for Linux.

■ 硬體需求：可以執行Linux, Unix, Window 2000 的工作站。

● 使用端：任何可以使用視窗介面瀏覽器的電腦軟硬體。

數位流程管理系統經分析結果，分為「文物典藏管理系統」及「出版品管理系統」執行；文物典藏管理系統首重支援後續數位化工作執行，偏重管理性功能，出版品管理系統則偏重蒐集即時產生之數位資料，累積充實參考文獻的豐富性。

a. 文物典藏管理系統工作內容：

（1） 重整本館原有典藏管理系統，因原計畫經費不足，此部份已申請教育部專案補助，便於研究人員進行研究及支援計畫完成。

（2） 完成項目：資料庫轉換完成、開發WebBase 管理系統。

b. 出版品管理系統工作內容：

數位典藏計畫為一持續之工作，經分析依「核心流程改造」概念重新設計工作流程，目的為融入博物館原有知識生產流程，降低重複數位化成本。完成系統包括：

（1） 著者資料管理系統：主要是管理著者的各類資料，如基本資料、專長、榮譽...等資料。

（2） 出版計劃管理系統：主要管理刊物出版計劃，刊物的稿約管理，列印收據，列印出版伸請單。

（3） 繳稿上傳系統：提供稿件上傳的功能。

（4） 校稿上傳系統：校稿檔案回傳子流程。

c. 多媒體資料庫建置進行方式：

傳統的資料庫設計與發展方法，一般均依循需求蒐集、概念設計、邏輯設計、實體設計、系統測試與實作的順序，逐步進行。依據Boehm 的生命週期成本差異理論，系統改變的成本，會隨著其發生時點的向後推移而遞增，因此，若改變發生於生命週期的初期，其成本較低，若改變發生於生命週期的後期，則其成本將大幅增加。為避免這些因改變而增加的成本，傳統的方法一般均強調在需求蒐集的階段，應該盡力蒐集完整的需求，所有或絕大部分的改變，其發生的時點應該侷限於需求蒐集的階段，一旦需求蒐集階段完成後，應儘量避免改變，甚至將需求凍結，以去除因改變而增加的成本。

傳統方法所抱持的這種觀點，很明顯的是由系統發展者的角度出發，但是，資料庫系統成敗的關鍵因素，在於是否能滿足使用者的需要，如果使用者的需求，在需求蒐集階段完成後，已經有了重大的改變，但是系統發展者卻拘泥於傳統方法的限制，不願或不能改變其系統以回應使用者需求的變化，那麼，雖然系統發展者或許能以較低的成本發展出一套僵化的系統，但是這樣的系統卻不禁令人懷疑，其適用性究竟如何？

數位博物館的metadata 資料庫管理系統，是傳統方法不適用的一個明顯例子。Metadata 規格的標準，不是單一的個人、單一的單位、甚或單一的國家所能夠片面決定的。Metadata 規格的標準，一方面應該整合許多現存的metadata 規格，另一方面也應該能夠持續地納入新的研究成果，在這種情況下，強制要求在某一特定的時點後，即不准對metadata 的規格，做任何的更動，是相當不切實際的。

因此，對於數位博物館的metadata 資料庫管理系統而言，真正應該強調的，不是禁止改變的發生，而是如何以較佳的方式來回應這些不可避免的改變。以下將簡述靈敏的數位博物館metadata 資料庫管理系統所應具備的一些特質。

（一）靈敏的數位博物館metadata 資料庫管理系統應該是一個良好的測試基台。這包含以下數點：

#數位博物館metadata 的領域專家們應該能夠透過友善的介面，很方便地訂定metadata 的規格，這些metadata 的規格，應該不須要資訊專業人員的介入，即可自動地轉換成資料庫的資料表，並且自動地產生適當的輸入介面，以方便實際metadata的輸入。
#領域專家們應該能夠很方便地修改metadata 的規格，這些對於metadata 規格的修改，應該不須要資訊專業人員的介入，即可自動地反映於資料庫的資料表與輸入的介面，並且資料庫內現存的資料，在合理的範圍內，應該能自動地轉換成新的規格。
#每當領域專家們建立新的metadata 的規格，或改變原有的規格時，應該不須要資訊專業人員的介入，即可自動地產生適當的查詢介面，以方便領域專家與其他的領域專家或一般使用者合作，以共同評估該metadata 規格的適用性。綜合上述，靈敏的metadata 系統之測試基台功能，主要在提供領域專家一個可以即時測試的工作環境，使得領域專家在訂定metadata 規格

（二）

靈敏的數位博物館metadata 資料庫管理系統應該能由測試基台快速地轉換成正式的系統。靈敏的metadata 系統應該不是用過即棄的雛形，在經過適當的調校後，它應該能支援極大量資料的存取，在特定的負載下，能提供可接受的回應時間，並支援系統的延展性(scalability)。

在一個理想的metadata 規格發展環境中，可能包括三套靈敏的數位博物館metadata 資料庫管理系統，其中第一、二套系統是擔任研究與測試的 用途，並且輪流承擔備份與實驗metadata 規格的責任，而第三套系統則是在metadata 規格成熟穩定至某一程度後，作為對外發佈的正式系統，如此，metadata 規格不但可以持續不斷地發展，而一般使用者也可以在最短的時間內，享受領域專家們最新的研究成果。

== 參考資料 ==
參與研發單位：國立歷史博物館

提供單位：國立歷史博物館

使用單位：國立歷史博物館

[[Category: 技術彙編]]