第五章 專家訪談與系統設計
本研究訪談對象本以檔案管理局（簡稱檔案局）高層決策者及徵 集組、典藏組及資訊組三組人員為主，但因本研究進行訪談調查期 間，檔案局內除了資訊組外，其他組並未接觸長久保存議題，所以訪 談對象改以高層決策者及資訊組人員為主，且在研究進行中，仍持續 與資訊組聯繫，取得他們看法及經驗，並不斷修正本研究設計。
透過訪談調查，了解檔案局目前的典藏現況，本章將分析檔案局 的整體現況及對電子檔案長久保存的看法與檔案局未來目標，並試以 OAIS 參考模式規畫檔案局所需的長久保存系統功能及詮釋資料格 式。
第一節 檔案局簡介
檔案管理局於民國 90 年 11 月成立，為檔案中央主管機關，負有 保存管理國家檔案之責，其下組織與檔案保存管理相關業務主要有徵 集組、典藏組及資訊組。徵集組負責檔案管理政策之研訂與推動、審 核機關檔案銷毀計畫、銷毀目錄、國家檔案移轉目錄及檔案保存年 限、國家檔案之鑑定、徵集、辦理私人或團體所有文件或資料之受贈、
託管或收購等事項；典藏組負責檔案典藏政策之研訂與推動、檔案維 護與修復技術之研發推廣、檔案微縮與數位化等複製儲存作業之規劃 與推動、研訂、推廣檔案典藏環境及設備配置標準、國家檔案典藏庫 房之規劃設置與管理、國家檔案館建築設備與設施之規劃興設與營運 等事項。資訊組負責全國檔案資訊系統之建置與推動、機關檔案管理 資訊化政策之研訂與推動、電子檔案儲存與安全認證管理及推動、檔 案資訊技術研發與交流、提昇檔案應用效率等事項。(檔案局網頁，
http://www.archives.gov.tw/internet/c_about_stat.aspx)
接著即就訪談調查結果進行分析，根據訪談結果，在此針對檔案 局環境，分成幾個議題說明如下：
一、 檔案管理局的電子檔案
國家檔案乃指具有永久保存價值之檔案，於 25 年保存年限屆滿 後，由機關移轉給檔案局者，為國家檔案。所以從公文產生到歸檔檔 案，再經鑑定具永久保存而移轉至檔案局，至少需要 25 年的時間。
隨著電子化政府的推動，從民國 80 幾年開始，希望能提供安全可信 賴的網路環境，並全面實施電子公文交換。雖然政府全面推廣電子公 文，但多數機關仍使用紙本公文，而即使使用了電子公文，在電子公 文簽核時，只有少部份公文線上簽核方式辦理，最後歸檔保存時，也 會印出紙本。從訪談調查得知，檔案局目前並無電子公文所轉成的電 子檔案，其原因有下列幾點：
1. 檔案局成立太短，僅短短兩年的時間，由機關所移轉過來的 檔案並不多。
2. 從民國 87 年才開始推動電子化政府，即使有電子公文，也需 滿 25 年之後才會進到檔案局。
目前檔案局有的電子檔案，皆由典藏組將較為重要的國家檔案進 行數位化，其數位化的目的為了使用方便而非保存，畢竟電子檔案能 透過資訊系統，進行搜尋、檢索且能提供網路服務，所以目前檔案局 的電子檔案不是原生的電子檔案，而數位化的電子檔案，主要目的是 為了流通；在保存方面，檔案局以保存原件為原則。因此現階段典藏 組的業務主要是將檔案描掃數位化，並未考慮未來電子檔案長久典藏 的問題。
二、全國檔案資訊系統
透過受訪者之建議，本研究對全國檔案資訊系統進行了解，目前 他們並未針對電子檔案長久保存的需求去設計系統，只是希望未來能 與目前的檔案資訊系統結合以降低成本。
全國檔案資訊系統所要推動的策略包括：（全國檔案資訊系統計 畫網頁，http://www.archives.gov.tw/internet/c_about_plant_d3.aspx）
1. 建立及推動民眾查詢檔案單一窗口；
2. 建立、推動及輔導機關檔案管理作業資訊化；
3. 建立國家檔案管理資訊作業體系；
4. 建立電子化公文檔案作業體系；
5. 建立國家檔案數位化典藏；
6. 建立檔案知識管理系統。
上述第三點和國家檔案管理資訊作業體系與長久典藏業務相 關，處理國家檔案作業（在此稱為作業體系，其實獨立而言是指一個 系統），高層決策者希望未來長久典藏系統能評估目前的國家檔案管 理系統，降低未來成本。此外，本研究與資訊組人員討論國家檔案管 理作業系統時，受訪者認為未來的典藏系統設計有兩個選擇，第一是 將長久典藏的系統功能直接建置於國家檔案管理資訊系統內，不過要 在原有的系統內新增功能並非易事，需考慮到原建置系統公司、法規 等各方面的問題。另一方案則為重新建置長久典藏系統，從機關彙送 進來之後，即進入系統作業，如此在規畫上較為簡便，但需重新規畫 整個系統的運作。
三、電子檔案的詮釋資料與描述
檔案局的檔案以公文歸檔的資料為主，檔案局內其他類型資料較 少，所以目前的處理是數位化，然後建檔。電子檔案的詮釋資料是在 民 92 年，委託陳昭珍教授所進行的研究案，設計電子檔案所需的詮 釋資料格式，使用 EAD 描述格式，將國家檔案分成四個層級：全宗、
系列、案卷、件。目前已將此 EAD 格式修改，並設計於國家檔案資 訊系統，預計於今年五、六月開放，經徵集組試用之後，依實務需求 進行一些修改，受訪者提供修改後的詮釋資料格式（附錄一）做為本 研究之參考。
由於 EAD 欄位多且複雜，所以在系統的設計上，除了部分欄位 是從公文彙送目錄繼承而來之外，一些相關的欄位能夠用電腦自動去 抓取，此外，還有一些欄位是需要人工註記與描述，如全宗的部分有 內容摘要欄位簡述關於此機關的資訊。
雖然國家檔案需描述到四個層級，機關檔案只需描述到案卷層 級，變成國家檔案之後，再由檔案局描述到系列、全宗層級。由於過 去政府機關對檔案的描述只到件層級，對於這個問題，受訪者表示未 來機關彙送目錄，需描述到案卷層級。現階段檔案局對機關推廣，預 計至民國 97 年開始，檔案局規定機關必須描述至卷，不過對於目前 只做到件的描述，檔案局仍會收錄進來，但對於是否要進行描述徵
補，多位受訪者認為屆時還得視情況，如成本、人力，才考慮是否要 做描述徵補。
第二節 檔案局對電子檔案長久保存的觀念
透過訪談調查，了解檔案局對電子檔案長久保存議題的看法，及 檔案局內對此議題的相關討論，分析檔案局對電子檔案長久保存的策 略及未來方向，做為本研究參考。
一、有關電子檔案長久保存議題的看法
電子檔案長久保存的議題，對大部份檔案局人員來說仍相當陌 生，原因之一是檔案局成立時間很短；原因之二，目前並沒有電子公 文直接進到檔案局；原因之三，檔案局人力有限，為檔案中央主管機 關，須要處理的重要業務繁多，如推動全國檔案資訊化系統，因此無 法著力於電子檔案長久保存作業。但高層決策者提到在近幾年的計畫 中，希望能把國家檔案資訊系統、機關檔案資訊系統、全國目錄系統 及將來的知識管理系統，建立完成。將這些較急迫的計畫進行完畢之 後，下一個重點，就是以電子檔案長久保存為主軸。
目前檔案局內只有典藏組處理數位化檔案，對於未來面臨保存的 問題，有受訪者提到初步作業，應採用的轉移方式。受訪者紛紛表示 檔案局內並沒有對電子檔案長久保存做深入的討論，所幸最近三月，
在資訊組組長的帶領下，進行一個委託案，就是討論電子檔案永久典 藏的議題，所以檔案局內除了高層決策者與資訊組人員對電子檔案長 久保存尚有概念外，其他組組員並未開始接觸。在這之前，典藏組於 民國 91 年歐陽崇榮老師進行一個委託案，探討電子媒體檔案管理制 度及保存技術，除此之外，也有一些電子檔案及其保存的相關研究報 告出來，但檔案局並沒有立即實作，除了經費問題，檔案局也認為應 再研究、觀望，因此檔案局未將電子檔案長久保存的相關研究一併做 出，受訪者表示，目前只能逐步將研究做齊，然後再進行完整的規畫。
此外，檔案局高層決策者談到，雖然目前許多國家已進行電子檔 案長久保存的研究及計畫，美國保證能夠保存電子檔案 400 年以上，
但他們認為誰能保證電子檔案這麼久之後還能用，而且只保存電子檔
案並不可靠，一旦處理不好，電子檔案不見就不見了。有個受訪者更 舉出國外除了電子檔案保存外，另外做一份微縮片保存，主因還是擔 心電子檔案保存的可靠性。所以受訪者認為將來檔案局面對徵集而來 的電子檔案，不可避免地有保存電子檔案的需求，但將參考國外另外 保留一份微縮的做法。
而有關電子檔案的角色定位問題，有受訪者認為電子檔案本身是 不是如此重視，因為媒體本身變更速度很快，即使號稱高科技發達的 美國，他們真正要長久保存的並不是電子檔案，所以未來即使檔案局 只有原生的電子檔案，可能考慮把電子檔案印出來保存。有位受訪者 認為檔案局所考慮的長久的保存，長久不是永遠的意思，而是希望拉 長保存的時間而已，假使軟硬體淘汰，每三年換一代，基於成本的考 量，如果可以的話，會希望未來 5、10 年換一代，可以不要花太多的 時間及精力，畢竟資料量大時，進行轉移或其他長久保存策略，都必 須花費相當大的成本。此外，有多位受訪者認為未來是不是真的會有 這麼多電子檔案需要長久保存也是令人存疑的，因為檔案鑑定之後，
具有永久保存價值的檔案應該有限，以美國為例，NARA 已表示只保 留重要事證，供民眾使用。高層決策者也談到目前檔案局內資料量還 沒有很多，但未來機關檔案移轉進來，資料量必定驚人，有賴完善的 檔案鑑定原則，去蕪存菁。如果未來電子檔案的資料量沒有那麼大，
那麼長久保存就不會那麼困難，在人力、時間的考量下，配合長久保 存策略，對檔案局而言，是游刃有餘的。
電子檔案保存不只讓檔案能夠保存下來而已，更重要的核心課題 是電子檔案的安全性及完整性等問題，安全性是指電子檔案保存系統 必須有足夠的防護措施，如病毒防護、防火牆、入侵者偵測等，而完 整性則是保證檔案的正確性及一致性，檔案做為歷史存證是不能修改 的，但電子檔案因為數位形式容易遭到竄改，而無法還原真相，所以 在電子檔案的保存上，只有在安全性及完整性無虞的前提之下，才可 進行電子檔案保存作業。
由上述分析得知，檔案局面對電子檔案長久保存的議題，做一簡 單整理，有下列幾點看法：
1. 未來電子檔案的保存仍保留一份紙本或微縮，畢竟如果電子 檔案處理不當，可能會造成永久的遺憾。
2. 所謂電子檔案長久保存並非正的「永久」保存，因科技汰換 速度太快，只是將保存的時間拉長，以節省成本。
3. 檔案鑑定的要求必須嚴謹，只保留重要事證。
4. 重視電子檔案的安全性及完整性的問題。
二、電子檔案長久保存計畫
就長久保存計畫來看，澳洲在過去幾年一直在大步前進，並在國 際上出盡風頭，最為人所知的計畫是由維多利亞州政府（PROV）所 進行的 VERS 計晝，這個計畫主要是採用封裝的方式，將檔案的內容、
描述及數位簽章一層層包在一起保存。
有位受訪者表示以往一直在密切注意澳洲的動向，但在這幾年澳 洲的進展似乎緩了下來，認為澳洲應是遇到瓶頸，雖然澳洲一直領先 在前，其方法是邊做邊學，而相較於美國，則是不斷地研究，待研究 成熟之後，才在最近著手進行。澳洲未依國際標準來做長久保存規 畫，只是就他們認為可行的方式，不斷地嘗試錯誤及修正問題，雖然 在 VERS 計畫的文獻上提及其長久保存計畫相當成功，不過受訪者發 現澳洲雖然在電子檔案長久保以跳躍式前進，但就澳洲國家檔案館方 面，卻未提及相關研究，對整個澳洲而言，VERS 倒是像是個試驗計 畫。
最近檔案局資訊組有派組員去澳洲參訪 PROV，了解他們的 VERS 計畫進行的情況，回來的報告卻表示不如文獻上說得那麼成 功，而且他們的電子檔案並沒有做得很多，也沒有很精準。更令人驚 訝的是，他們並沒有思考電子檔案真實性的問題，雖然在計畫中提到 數位簽章的應用，但實際上，他們並沒有將數位簽章封裝保存，他們 認為一旦檔案回歸到國家檔案館時就不可以更改。
此外，受訪者提到除了澳洲，他們也參考了美國，澳洲的問題前 面已提過了，檔案局選擇以美國 ERA 計畫做為主要參考對象，受訪 者認為 ERA 計畫相當完整，而美國目前正在進行招標案，讓廠商競 標來進行 ERA 的建置。
檔案局選擇 ERA 計畫做為參考，有幾個因素：
1. 目前澳洲並不合適，且參訪 PROV 的人員表示失望。
2. NARA 在網站上提供 ERA 的東西非常完整，可以直接取得。
3. NARA 的長久保存架構是以知識為基礎，符合局長要求的知 識管理之理念。
4. ERA 由六個核心計畫組成，這六個核心計畫的結合是透過國 際標準，也就是每個計畫在規畫時，皆依循國際標準，所以 檔案局認為這樣的標準是必要的。
5. 美國宣揚他們的電子檔案能保存 400 年，姑且不論是不是真 的，但至少可以看出他們對於長久保存的把握，讓參考 ERA 的機關更加有信心。
由於這些因素，檔案局資訊組就在最近委託研究案，委託中研院 及政大的教授，準備著手規畫電子檔案長久保存系統，希望參考 ERA、以 OAIS 參考模式為基礎，進行設計。
三、電子檔案長久保存系統及詮釋資料
目前檔案局並沒有特別針對電子檔案長久保存的需求，發展系統 及策略，但最近一個研究案，即將以長久保存為主，以 OAIS 參考模 式為基礎，規畫電子檔案長久保存的系統及策略，資訊組預計今年將 這個研究案做出來，往後則準備用四年中程計畫去實踐。在本研究進 行訪談調查時，了解檔案局內部在上述研究案之前，沒有討論過電子 檔案長久保存的問題，當然在之前的系統設計也沒有對長久保存做特 別的規畫，因為研究案即將啟動，所以在本研究訪談調查期間，資訊 組人員進行了第一次的電子檔案長久保存討論，也讓本研究了解資訊 組對未來電子檔案長久保存系統及策略的初步看法。
高層決策者提到長久保存系統，表示他們已經針對這個議開過幾 次會，主要以擷取、保存、使用三大功能為主軸，考慮從機關移轉、
檔案局典藏、然後到提供使用，這三大功能必須從長久保存的角度，
依作業流程而有一致的規畫，機關要如何轉移進來、檔案局內部要如 何典藏、要如何提供給民眾使用，這一連串的流程除了三大功能外，
還會有一些細部的功能。在詮釋資料方面也是一樣，從機關彙送目錄 進來，需要有什麼欄位，因為檔案主要的來源為機關；在檔案局典藏 時要有哪些欄位，能從機關取得的，便設計進去，由機關彙送目錄時 直接帶入；最後使用時，要提供什麼欄位都必須一併考量。許多可繼 承的資料可一一對照出來，所以資訊組也必須將三大功能及詮釋資料
做統整的工作。而高層決策者對長久保存系統，最擔心的還是成本問 題，在這幾年的全國檔案資料系統已經花費了不少經費。
此外，資訊組認為長久保存系統規畫應該從使用的觀念來看，認 為保存就是為了未來的使用，以美國為例，保存重大事證必須確保未 來能夠被使用。所以受訪者建議系統從擷取、保存到使用，應該從使 用端倒過來推，最後推到擷取端應如何做。詮釋資料的設計也是一 樣，從使用端需要哪些欄位往回推，倒過來了解擷取端要什麼，受訪 者覺得資訊單位要考慮的是使用面，而美國也是從使用面去設計的，
所以希望未來的系統設計是朝美國的方向前進。
除了系統的規畫，高層決策者仍再三強調成本的問題，全國檔案 資訊系統已經投入了一兩億的經費，所以希望能夠在這次委託的案研 究中，評估現在的系統結構及未來的移轉問題，以便將來可以在合理 的成本、人力考量下做轉移。
而詮釋資料部份，雖然也沒有對長久保存需求設計詮釋資料，不 過在 92 年陳昭珍教授的委託案中有設計國家檔案的詮釋資料格式，
以 EAD 為檔案局所設計的，其中提及未來會轉移至永久典藏系統，
可望利用目前已規畫的詮譯資料格式應用在未來的長久典藏系統 中，依作業流程而調整不同使用目的所需的詮釋資料格式，其關係如 圖 5-1 國家檔案描述格式之交換架構圖：
四、電子檔案長久保存策略
檔案局目前並未訂出電子檔案長久保存策略，也沒有開始使用任 何的長久保存方式，因為檔案局成立至今的時間還不夠長到需要更換 設備或轉移。在本次訪談調查中，試以標準、封裝、轉移、模擬等主 要幾種做法，了解檔案局人員如何看待這些方法，未來可能採行的方 式。整理調查結果，依長久保存方式說明受訪者的看法：
1. 轉移，對技術的人來說，轉移是最簡單的，不需要跟非技術 的人討論，只要把檔案放在機房，反正只要能呈現原來的資 料，讓使用者能夠使用即可。
2. 模擬，較轉移複雜，牽涉到後端的作業，應用程式可能需要 重寫，影響層面較大。
3. 封裝，須考慮電子檔案的基本處理單元，處理的單元是根據 封裝的結果定義的，但目前底層的資料不是以封裝的觀念來 儲存，所以封裝與目前既存的作業流程不同，短時間可能沒 有辦法做到。但如果是新開發的系統，產出的結果透過流程
國家檔案 (XML format) 機關檔案目
錄
國家檔案描述
格式 (不只一
種)
XSLT
整合檢 索
如 OAI-MHP
目前主要的格式為DC
資料交換
DC EAD MARC
永久典 藏系統 轉移
圖 5-1 國家檔案描述格式之交換架構圖 資料來源：陳昭珍主持（民 92）。圖 8-1
管理，層層流程處理完後，再一層一層加上封裝的資料，這 樣的作法就可以顯現出封裝的層次，但對目前的檔案局來說 並不適合，新開發系統還需要較長的時間重新設計。另外有 受訪者則認為封包並不適用於機關，檔案局在長久保存的考 量下，可能會用封包的方式，將內容、詮釋資料一層層包上 去，還有將數位簽章包進來，不過高層決策者表示最後如何 做，則要等幾個相關的研究案出來，才能再做評估。
4. 標準化，標準化的制定是透過法規規範，法規則需有一連串 流程處理才可能訂定出來，所以時程上較久。
此外，有受訪者提到檔案局在民國 92 年通過的機關電子檔案管 理作業要點，已對機關檔案訂定檔案保存的策略，總則第十三條：「各 機關應配合電子檔案之保存年限，評估保存維護成本，依據機關檔案 管理資訊化作業要點附表二規定，選擇適當儲存媒體，適時辦理電子 檔案之轉置、更新、模擬及封裝，並優先採取轉置之措施。進行電子 檔案之轉置（轉移）、更新、模擬及封裝時，應先製作二套以上備份，
分置於不同地點保管之。」；第十四條：「各機關保存電子檔案時，應 進行電子媒體之檢測與維護，確保電子媒體之安全；並應指派專人負 責電子檔案軟硬體設施之維護、轉置（轉移）、更新、模擬及封裝」； 第十五條：「各機關得視實際需要，考量電子檔案之性質、價值及安 全，將電子檔案輸出列印成紙本、轉製成微縮片或以其他型式保存 之。」。（機關電子檔案管理作業要點，http://www.archives.gov.tw/
internet/c_law2_rule21.aspx）
可見在機關保存電子檔案 25 年並非易事，所以在機關電子檔案 管理作業要點中，已經提供了轉移、更新、模擬、封裝等方法做為機 關電子檔案保存的參考。此外，就檔案的性質、價值、安全考量，可 將電子檔案印成紙本、轉成微縮片或其他可靠的型式。
受訪者表示他們有朝一定的方向在進行，只是還沒有針對長久保 存來訂定比較明確的法規，目前只針對電子檔案儲存的部分訂定法 規，是以檔案的格式，決定未來的轉移方式。而未來要如何採用這些 長久保存的方法，高層決策者認為這次資訊組的研究案出來之後，應 該會有具體的建議。資訊組則肯定地說，將來電子檔案保存原則上是
用封裝、模擬，並搭配標準，以 NARA 知識為基礎的架構下去做。
五、OAIS 參考模式是否適合長久典藏
資訊組將規畫長久保存的資訊系統，以 ERA 計畫做為參考，而 ERA 便是以 OAIS 參考模式為基礎，所以未來的規畫是以 OAIS 參考 模式為基礎進行設計，本研究問及 OAIS 參考模式是否適合應用於電 子檔案長久保存，多位受訪者抱持不同的態度。
有受訪者表示非常適合，因為將內容分層儲存的架構很好，只是 未來使用面的設計尚需深入的研究，而資料模式的處理上，將內容、
描述資訊分開，再利用封包的概念，以利未來的使用，這也是 OAIS 參考模式考量使用目的。
另外有受訪者表示目前無法回答 OAIS 參考模式是不是適合，因 為此受訪者還未深入了解 OAIS 參考模式，不過他提出了與澳洲和英 國的比較，OAIS 的方向是從底層的標準開始訂定，然後往上；而澳 洲和英國則是先從封裝的物件開始設計，反而在底層的標準訂定上，
並未敘述得很清楚，其最大的差別是美國是由下往上規畫，澳洲、英 國則是由上而下規畫。這位受訪者覺得物件包起的方式是合適的，用 物件來思考比較符合現代軟體開發的觀念。傳統在系統的分析上，以 資料做為處理的角度，首先考慮是什麼欄位，然後整合起來，決定最 後要怎麼做，所以在分析的時候，會從資料流的部份去分析、設計，
做成一個系統。可是人的思考邏輯並非如此，檔案是一個目標，一個 欄位對使用者的意義不大，使用者所要的是整個檔案，是由許多欄位 的描述組成的。因此，如果開發的目的是從整個文件、處理的單元做 為物件的描述的話，比較接近實務上的概念，而實際上要怎麼做，是 程式設計師要去解決的問題，受訪者認為這樣比較接近一般人的思考 邏輯，接近心中所想的。不過如此一來，可能直接影響到作業的效率，
但現在設備的效率會比以前好，受訪者認為可以用設備來彌補軟體設 計上的不足，只要讓使用者感覺不要太慢，能取得所要的資料即可，
這就是物件的優點，所以如果就使用目的來說，受訪者認為這種的物 件模式有其優點。
因為本研究的訪談調查時間是在檔案局最近的研究案後沒多 久，所以對 OAIS 了解的人並不多，深入了解的更是少之又少，所以 只能取得他們的概略的想法。不過有多位受訪者表示，在本研究進行
期間仍能隨時與他們保持聯繫。
第三節 檔案局的未來
檔案局雖然才成立兩年，但隨著電子化政府，資訊科技的進展，
檔案局發展全國檔案資訊系統、規畫電子檔案詮釋資料格式、訂定電 子檔案相關規範等，逐步實現資訊化，高層決策者認為資訊化應該要 考慮整個架構的問題，所以希望做整體性規畫，因為資訊化一投入成 本很高，要考慮互通、整合的問題。
面對檔案局的未來，高層決策者認為未來會有國家檔案館，其方 向第一個就是專業化的管理，要有現代化的管理理念及現代化的專業 知識跟能力；第二個就是要有知識化的管理，因為知識化是未來競爭 優勢的主要動力，發展檔案知識管理系統，是必然要走的途徑；第三 個就是業際化管理，檔案開發之後，要怎樣把推銷出去，把各行業資 訊整理，做為以後推廣的管道；還有科際化的管理，要有新的技術、
新的設備；最後就是要走上國際化的管理，國際間的互相交流及研究 化。所以，現在檔案就應該要走上標準化，未來的作業才會比較便利。
第四節 系統規劃
分析檔案局長久保存系統的功能，首先說明分析的重點，以重新 規畫檔案局資訊系統為主，不考慮目前正在進行中的國家檔案資訊系 統，在與受訪者訪談時，了解國家檔案資訊系統並未針對長久典藏做 規畫，若直接考慮從國家檔案資訊系統建立長久典藏機制，將會面臨 幾個問題：第一，國家檔案資訊系統已依先前規畫進行，而 OAIS 功 能模型需配合多項規格及標準，並不適合目前的資訊系統；第二，現 在要加入長久典藏功能，必須對國家檔案資訊系統相當了解，而且此 系統建置廠商也必須找相同一家，以免有不相容的情形出現。基於上 述問題，本研究以重新規畫較為單純，是故本研究以檔案局為個案，
應用 OAIS 功能模型，規劃長久典藏系統。
一、系統功能分析
除了擷取、保存、使用之外，OAIS 功能模型還包括了資料管理、
行政及保存計畫三個功能，這三個功能也都是長久保存所需具備的系 統功能，此外，檔案局的電子檔案主要來源為機關，目前透過目錄彙 送及使用 EAD 詮釋資料設計的國家檔案描述格式，送到檔案局時為 XML 文件，並接收從機關而來的電子檔案，此情境為 OAIS 中的生產 者，從訪談中得知機關目前沒有採用長久典藏所需的格式及標準，而 NEDLIB 的做法，是在擷取功能之前加了一個接收功能，將接受的資 料轉成長久典藏要求的格式，產生 SIP 資訊封包，對檔案局而言如果 能直接從機關取得 SIP，那麼在典藏系統中的作業，將能更省事且方 便，是故建議機關在傳送給檔案局時，直接將 SIP 製作完成。綜合上 述，本研究將檔案局長久典藏系統之功能參考 OAIS 功能模型分成六 個，其功能運作及分析如下：
1. 擷取功能
在擷取功能中，有幾個細部功能：
(1)接收 SIP：接收從機關傳送的 SIP，在傳輸 SIP 的過程中，最 重要的問題便是安全性的考量，最困難則是檔案太大的傳輸問 題。首先針對安全性的問題，當 SIP 從機關傳送到檔案局，在
這一個傳輸的過程中，檔案可能會被從中攔截，可能發生傳送 錯誤，也可能遭到竄改，所以從擷取功能一接收到電子檔案開 始，首要工作便是檢查 SIP 是否正確，是否安全被傳送進來，
Feenstra(2000)列出在安全上考量的層次包括有取用控制、加 密、真實性、整體查核、完全向前保密、隱藏位址、傳輸監控，
而目前使用於電腦網路安全的協定及系統有下列幾種：
（Feenstra,2000）
IP 控管(IP Filtering)；
網路地址轉換（Network Address Translation,簡稱 NAT）；
網際網路通訊協定安全性（IP Security Architecture,簡稱 IPSec）；
SOCKS 通訊協定；
SSL 通訊協定；
Application proxies；
防火牆（Firewalls）；
AAA servies。
運用上述安全協定所能逹到的安全層次不盡相同，檔案局為保存 具永久保存價值檔案，當然也必須在傳送檔案時有所防護，並在取得 檔案後查核資料的正確性及完整性，所以在擷取功能，應盡可能採用 上述通訊協定及標準。當檔案太大時，則必須分割檔案傳輸，由 TCP/IP 的傳輸層做定義，至擷取功能後再結合成一個檔案，但需進行整體性 查核。
(2)SIP 查核：確定從機關送來的 SIP 內容沒有錯誤及具有真實 性，可使用的方法包括使用 MD5（Message-Digest lgorithm 5）
碼、CRC 等方式進行，確保檔案內容沒有錯誤或被改變。
(3)產生 AIP 及描述資訊：將 SIP 轉換成 AIP。將一個或多個 SIP 轉換成一個或多個 AIP，一個 SIP 可能會產生不同版本的 AIP，
或當 SIP 重覆傳送時，須決定轉換其中一個 SIP 為 AIP。同時 需定義各種類型的儲存格式，如文字檔存 doc 檔，影像存 tiff 檔等，或依不同需求定義不同的格式。AIP 產生後，依據 AIP
產生描述資訊的詮釋資料，用於未來檢索 AIP 之用。
(4)傳送 AIP 及描述資訊：由擷取功能將 AIP 送到檔案保存功能；
描述資訊則送到資料管理功能。
擷取功能透過上述幾個細部的功能，完成在這個階段須進行的工 作。
2. 檔案保存功能
檔案保存功能主要是保存 AIP，在此所應考慮的問題包括有 AIP 的完整性、備份及保存的安全性等問題。其細部功能如下：
(1)接收 AIP 並進行查核：首先將接收到的 AIP，進行內容查核，
是否無誤及是否具真實性，可使用方式如 SIP 的查核。
(2)儲存 AIP：將 AIP 儲存於資料庫中，Feenstra（2000）提出應 決定大量儲存所需使用的儲存媒體。
(3)AIP 更新、轉移：進行 AIP 媒體的更新或轉移，定義多久需進 行更新轉移動作，可視儲存媒體或檔案類型、格式而定。
(4)備份：資料的備份有多種方式，有完整備份、每次有新增時備 份、或每隔一段時間備份，並採用異地備份。異地備份是很重 要的，此外，也應訂定備份策略，每週或隔幾天需做一次完整 備。
(5)提供 AIP：依檢索需求，先將需要的 AIP 複製到適當的媒體或 傳送至暫存區，再傳送 AIP 給取用功能，所以在此應採用中介 軟體以應用於檢索。
檔案保存功能主要針對 AIP 作業，AIP 為長久保存目的，其內容 設計更為複雜，在本章分析的內容也包括 AIP 的設計，在稍後說明。
3. 資料管理功能
提供資料庫，管理從擷取功能的 AIP 描述資料及檔案局行政資 料，能做新增、修改、刪除各功能對資料庫查詢，產生各種報表給檔 案局。其細部功能如下：
(1)管理資料庫，OAIS 定義資料庫的內容有三種：第一種是 AIP 的描述資訊，用來識別館藏的資訊；第二種是系統資訊，用以 支援典藏系統運作；第三種為保存資訊，為在保存過程中所需 要的資訊，檔案局同樣也須在資料庫內管理上述三種資訊。
(2)需求回應：接收使用者查詢，並產生回應，資料庫會提供 SQL 查詢，配合中介軟體用於檢索。
(3)資料庫更新：對現存的資料新增修改。
資料管理功能以資料庫使用為主，負責管理資料，保持完整性，
資料庫內的資料主要來源為擷取功能。
4. 取用功能
取用功能就是提供介面給使用者查詢，依查詢結果從系統內取得 使用者所需要的資料，並為了讓使用者使用，而將長久保存的格式轉 換成目前使用者能夠使用的格式，其細部功能如下：
(1)檢索功能：透過檢索協定，向資料管理功能檢索 AIP 封包的描 述資訊，其介面應使用 http 協定透過瀏覽器呈現，查詢結果呈 現給使用者，使用者可以產生訂單，系統再從檔案保存功能及 資料管理功能取得 AIP 及完整的描述資訊。
(2)產生 DIP：從檔案保存功能取得 AIP 的應用版本之後，即依據 使用者需求產生需求的格式，其格式必須是目前使用者能夠使 用的，可搭配使用數位版權管理（Digital Right Management,簡 稱 DRM），如產生的 DIP 影像檔加入浮水印、文字檔則使用數 位簽章。
(3)傳送給使用者：將結果傳送給使用者，可以使用 http、ftp 或 mail 的方式。
典藏的最終目的是為了能使用，所以提供一個查詢介面並轉換格 式給使用者是必要的，取用功能主要便是執行這些工作。
5. 行政功能
行政功能是管理整個系統運作的功能，建立標準和策略，管理有 關整個系統運作所產生的資訊。
(1)訂定 SIP 規格：檔案局需定期與機關進行溝通及訓練，決定從 機關傳送的 SIP 及詮釋資料的內容。
(2)系統維護：維護系統軟硬體的配置、監視與改善。
(3)審查 SIP：SIP 需先傳送至行政功能，審查 SIP 是否有符合訂 定的標準及詮釋資料內容是否有符合，再送出報表給擷取功 能。
(4)使用者服務：管理使用者資訊，並決定付費方式及交易安全機 制，知識有價，未來檔案局部份檔案取用，也須要付費。
這個功能是對系統的所有功能，為能順利運作而產生的作業需 求。
6. 保存計畫功能
負責研究和發展接序性的保存政策，包括標準、封包設計等，其 細部功能如下：
(1)監控使用者：定期或不定期與機關及使用者互動，進行調查研 究，了解他們的需求，取得回饋。
(2)發展標準及政策：發展及維護長久保存的標準及政策，同樣
地，這也必須透過檔案局內部不定期會議的協調及溝通。
(3)監控技術：隨時掌握目前科技進展，配合機關及使用者需求，
不斷研究和發展。
(4)封包設計及轉移策略：依長久保存需求及技術進展，發展新的 封包設計及轉移計畫。
保存計畫功能如同檔案局內部的研發部門，應視情勢之變化，而 進行更深入的研究。
將檔案局所需的系統規畫功能如圖 5-2。
檔案局長久典藏系統
擷取
SIP查核 接收
SIP產生
AIP及描述資訊 傳送
AIP及描述資訊
檔案保存 備份功能
AIP更 新 、 轉移 儲存
AIP接收
AIP並進 行 查核
提供
AIP資 料 管 理 管 理 資 料 庫
需求回應
資 料 庫 更 新
取用
傳送給使用者 產生
DIP檢 索 功能
行 政
使用者服務 審查
SIP系統維護 訂定
SIP規格
保存計畫
封包設計及轉移策 略 監控技術 發展標準及 政策 監控使用者
圖 5-2 典藏系統功能
二、資料流程
從上述功能分析，對檔案局定義了六個主要系統功能，而其資料 流程指在整個系統中，資料傳送及接收的過程，從機關移轉屆滿 25 年具永久保存價值之電子檔案及目錄，機關必須依檔案局規定的 SIP 封包標準，將電子檔案及詮釋資料包在一起傳送，而且詮釋資料的部 份，不只是依原來的國家檔案描述格式描述而已，而必須加以描述有 關長久保存所需的欄位，凡是由機關移轉至檔案局的電子檔案，便已 表示此電子檔案需永久保存，而在檔案本身的描述外，須增加的欄位 主要為表徵資訊的描述，以便未來取得電子檔案時，能同時取得解 開、呈現電子檔案的相關資訊，進而採用轉移或模擬等方式讀取電子 檔案。
機關必須自行產生 SIP，並將 SIP 傳送到擷取功能，擷取功能取 得 SIP 後，依 AIP 所需的規格產生 AIP，並對 AIP 產生封包描述資訊，
再將 AIP 傳送給檔案保存功能進行下一步的保存作業，另外將封包描 述資訊傳送給資料管理功能。檔案保存功能取得要長久保存的 AIP 後，一方面將 AIP 複製，以其他媒體取代，一方面依保存策略進行長 久保存，例如幾年須更新媒體，最後能提供給取用功能所要求的 AIP。
另一方面，資料管理功能取得描述資訊後，即進行資料庫管理作業，
並提供取用功能查詢。最後取用功能，讓使用者能查詢取得 AIP 後，
轉而產生 DIP，提供給使用者。以圖 5-3 資料流程圖示之。
第五節 封包及詮釋資料設計
OAIS 除了對系統的規畫，也提供了在長久典藏系統中，資訊的 種類及保存的方式，在本節分析封包設計，並依 OAIS 資訊模型架構，
設計長久保存的詮釋資料。OAIS 所提出的封包，將資料與描述一起 保存，以便將來取得資料時能同時取得詮釋資料，而這個詮釋資料的 內容即是保存描述資訊及呈現內容的表徵資訊。OAIS 將封包依不同 需求分成了傳送封包(SIP)、典藏封包(AIP)、使用封包(DIP)，分成三 個封包主要能便於使用，分成三種層次，每個層次依所使用的需求，
規畫所需的內容即可，如此可以讓封包的設計單純化，從機關送 SIP
SIP
封包描述
資料庫更新 AIP
AIP 機關
使用者 取用功能 擷取功能
檔案保存 資料管理
DIP 結果集 訂單需求
查詢 封包描述
結果集 查詢
圖 5-3 資料流程圖 資料來源：本研究整理
到檔案局，機關只需管好如何包成 SIP，他能做哪些描述，當 SIP 被 接收至檔案局時，再依照典藏的需求轉換成需要的 AIP，使用者需要 AIP，只需提供使用者需求的內容及描述即可，所以轉換 DIP 提供使 用，每個階段只需考量自行的需求，如果在三個階段只設計一個封 包，那麼必須在一開始的 SIP 就需考量典藏的需求，又需在意未來使 用的需求，如此一來，雖然設計上較為簡便，但無法達分工分層處理 的概念，所以本研究也將分別設計三個封包。
封包的實體概念如圖 5-4，一個封包內除了自我解壓縮的執行檔 外，主要的內容便是詮釋資料及資料本身，分別說明如下：
一、資料
封包的主要內容便是數位物件本身，從圖 5-4 可見，一個封包可 以由很多個檔案組合而成，如此封裝可能由於檔案太大而有傳輸及資 料存取時間的問題。這個問題在本研究前面資料流程已經分析過了，
必須採用資料分割傳送的方式，目前許多 FTP 及傳輸介面也有支援資 料續傳功能。此外，也可以再運用簡單且低遺失率的壓縮技術。
三個封包的檔案格式依媒體類型而封裝不同的檔案格式，SIP 的 檔案依檔案局要求格式傳送到長久典藏系統，AIP 因典藏及提供給使 用者，而保留三種版本，美國國會圖書館（2001）即建議每一個 AIP 可以將各種類型的檔案依需求而產生不同的版本，分成三種，一種是 用於典藏的版本，通常最高品質；一種是用於傳送、交換及使用的版 本；最後一種則是用於預覽的版本，其資料類型及應用版本參考下表
圖 5-4 LC 實體封包概念圖
資料來源：Library of Congress([LC], 2001) Exhibit 1-1
EOF
封包
Header
自我解壓
主要的 Schema
詮釋資料
增加的 Schema 1
增加的 Schema
資料 檔案 1
資料 檔案 n
資料 封包
Traile r
5-1。最後提供給使用者的 DIP 則以 AIP 中使用及預覽版本。
表 5-1AIP 資料類型及應用版本
媒體類型 版本 檔案格式 典藏 SGML
使用 XML Text
預覽 GIF 典藏 TIFF 使用 JPEG Image
預覽 GIF 典藏 WAV 使用 MP3 Audio
預覽 MP3 典藏 ITU-R601 使用 MPEG-2 Video
預覽 GIF
資料來源：美國國會圖書館(2001) Exhibit 2-14
二、詮釋資料
參考 OAIS 資訊模型，對封包的元素以圖 5-5 表現出來，保存描 述資訊是針對內容本身的描述，如圖所示，保存描述資訊有四種資 訊：參考、起源、情境及固定資訊。
圖 5-5 封包元素 資料來源：本研究整理
封包
內容資訊
結構資訊 語意資訊
表徵資訊
保存描述資
訊（PDI）
參考 資訊
情境 資訊 起源
資訊
固定 資訊
比較檔案局目前使用的國家檔案描述格式，因檔案局國家檔案描 述格式已採用 EAD 精神設計，且 EAD 內已包含了部份的參考、起源 及情境資訊，因此本研究將在原有的國家檔案描述格式加入不足的起 源、情境及固定資訊，參考圖 5-4 LC 實體封包概念圖中詮釋資料部 份，分成主要的 schema 及增加的 schema，本研究將修改的國家檔案 描述格式視為主要的 schema，而主要的 schema 元素依封包作用不同 而有差略；增加的 schema 則用以表示表徵資訊，將主要的 schema 及 增加的 schema 分述如下：
(一)主要的 schema
參考 OCLC/RLG、Cedars、NEDLIB 等詮釋資料，本研究將保存 描述資訊所需的詮釋資料建議如下：
1. 參考資訊：參考資訊對 AIP、SIP、DIP 而言都是必要的，用來 識別檔案本身。除了原有的描述資訊外，在 SIP 轉換成 AIP 時，
系統將利用程式自動產生一個 AIP 的唯一識別，從 SIP 轉換 時，保留其唯一識別，程式則產生另一識別對照，用於 AIP。
2. 起源資訊：國家檔案描述格式已對起源資訊做一部份的描述，
數位版權管理資訊方面，已有檢索控制做管理。對 SIP 而言，
起源資訊讓機關做描述是最方便的，而 AIP 當然必須保存這些 資訊，DIP 則只要提供給使用者需要的起源資訊即可，其中版 權管理資訊則可結合數位版權管理加以應用。
3. 情境資訊：增加關聯的描述，表示此物件與其他內容資料物件 之間的關係，因檔案的性質特殊，必須透過情境資訊以窺全貌，
所以在 EAD 的設計已非常強調其情境資訊，但為保存，本研 究認為應加入 OCLC/RLG 的「建立理由」欄位，說明內容資料 物件被建立的理由及目的，此欄位應使用於 SIP 及 AIP。
4. 固定資訊：固定資訊主要是用來做查核，確認資料無誤及資料 的真確性，檔案為保持原始性，固定資訊的應用對檔案局而言 是絕對必要的。參考各個長久保存的詮釋資料，本研究認為檔
案局應採用的固定資訊欄位如下表 5-2：
表 5-2 固定資訊欄位
欄位 分欄 說明
ObjectAuthentication 物件查核
可重覆，可能有多種查 核方式。提供足夠的資 訊以符合典藏機構對 內容資料物件和內容 的查核需求，以確定內 容資料物件沒有被改 變，如數位簽章、浮水 印、查核等。
AuthenticationType 查核方法
查核內容資料物件的 技術，說明和描述這個 查核的方法。
AuthenticationProcedu re
查核程序
鑑別的步驟和內容，在 使用此查核方式時，提 供足夠的資訊。
AuthenticationDate 查核日期
最近查核的日期，以建 立標準檢查程式的時 間。
AuthenticationResult 查核結果
最近查核的結果。
保存描述資訊因封包不同而欄位元素不同，是故將三個封包的主 要 schema 分別設計。
(二)增加的 schema
除了上述保存描述資訊外，OAIS 資訊模型為了未來能順利將數 位資訊進行轉移、摸擬等長久保存策略，詮釋資料格式需包含表徵資 訊的描述，如圖 5-5 所呈現的表徵資訊，依 OCLC/RLG 的定義，主要 為內容資料物件及軟硬體的環境描述，內容資料物件是指檔案的格
式、編碼等內容，軟硬體的環境描述則為使檔案能夠運作的軟硬體描 述，在此參考 OAIS 的 AIC 設計，AIC 是類別、是 AIP 的群組，將部 份相同性質的 AIP 歸類到 AIC 的類別中，可以是結構，可以是內容，
也可以分成幾個層次，本研究採用美國國會圖書館對 AIP 研究所定義 的 AIC，分成兩種 AIC，一個是表徵類別（AIC Representation）、另 一個是環境類別（AIC Environment），表徵類別很明顯地是將 AIP 內 檔案的語意及結構資訊描述出來，AIP 表徵資訊相同的則歸在同一個 群組中；而環境類別，則是將 AIP 內檔案所要呈現運作的電腦環境做 描述，環境描述相同的就歸到相同的群組。（LC, 2001）
如此處理的優點是未來需要模擬或轉移時較為方便，所以本研究 將 AIP 分成兩種 AIC，表徵類別及環境類別，參考 OCLC/RLG、
NEDLIB 及美國國會圖書館的詮釋資料，表徵類別欄位定義於表 5-3；
環境類別欄位定義於表 5-4。
表 5-3 表徵類別欄位
欄位 說明
StructureType 結構類型
內容資料物件呈現數位物件的類型，可以知道這個 結構的類別，以選擇適當的保存策略，如圖檔、聲 音檔、文字檔、資料庫、網路文件、程式等。
FileDescription 檔案描述
描述組成內容資料物件檔案的技術規格，為保存管 理，而描述的欄位，如 GIF 影像檔：像素、解析度、
色彩、壓縮技術等方面。
Encoder 編碼方式
此檔案所使用的編碼方式
Decoder 解碼方式
此檔案所使用的解碼方式
Encryption 加密方式
此檔案的加密方式
Player 播放程式 Conversion 轉換程式
表 5-4 環境類別欄位
欄位 分欄 說明
Hardware 硬體
Microprocessor 微處理器
描述能運作其軟體環境所需要 的微處理器要求，確保使用者能 有足夠的資源讓軟體能運作。
MultimediaDevice 多媒體配備
描述特定的多媒體配備。
PeripheralDevice 週邊配備
描述特定的週邊配備。
OperateSystem 作業系統
Name 名稱
使用的作業系統名稱。
Version 版本
作業系統版本。
Compiler 編譯器
Name 名稱
編譯器名稱
Version 版本
編譯器版本
Application 應用程式
Name 名稱
應用程式名稱
Version 版本
應用程式版本
將上述表徵資訊做為圖 5-4 中增加的 schema，其欄位重新整理如 表 5-5，其 XML DTD 及 XML Schema 設計如後：
表 5-5 增加的 schema 欄位
欄位 分欄 分欄 分欄
類別 class
表徵類別 representation
結構類型 StructureType 檔案描述 FileDescription 編碼方式 Encoder 解碼方式 Decoder 加密方式 Encryption 播放程式 Player 轉換方式 Conversion 環境類別
environment
硬體 Hardware
微處理器 Microprocessor 多媒體配備 MultimediaDevice 週邊配備
PeripheralDevice 作業系統
OperateSystem
名稱 OSName 版本 OSVersion 編譯器
Compiler
名稱
CompilerName 版本
CompilerVersion 應用程式
Application
名稱
ApplicationName 版本
ApplicationVersion
1. 表徵資訊的 XML DTD
<?xml version="1.0" encoding="big5"?>
<!-- edited with XMLSPY v2004 rel. 3 U (http://www.xmlspy.com) by amy (chan) -->
<!--0 ELEMENT 類別 (表徵類別?, 環境類別?)-->
<!ELEMENT class (representaion?, environment?)>
<!ATTLIST class
class CDATA #REQUIRED
>
<!--1 ELEMENT 表徵類別 (結構類型?, 檔案描述?, 編碼方式?, 解碼方式?, 加密方式*, 播放 程式*, 轉換程式*)-->
<!ELEMENT representation (StructureType?, FileDescription?, Encoder?, Decoder?, Encryption*, Player*, Conversion*)>
<!--2 ELEMENT 結構類型 (#PCDATA)-->
<!ELEMENT StructureType (#PCDATA)>
<!--2 ELEMENT 檔案描述 (#PCDATA)-->
<!ELEMENT FileDescription (#PCDATA)>
<!--2 ELEMENT 編碼方式 (#PCDATA)-->
<!ELEMENT Encoder (#PCDATA)>
<!--2 ELEMENT 解碼方式 (#PCDATA)-->
<!ELEMENT Decoder (#PCDATA)>
<!--2 ELEMENT 加密方式 (#PCDATA)-->
<!ELEMENT Encryption (#PCDATA)>
<!--2 ELEMENT 播放程式 (#PCDATA)-->
<!ELEMENT Player (#PCDATA)>
<!--2 ELEMENT 轉換程式 (#PCDATA)-->
<!ELEMENT Conversion (#PCDATA)>
<!--1 ELEMENT 環境類別(硬體?, 作業系統, 編譯器*, 應用程式*)-->
<!ELEMENT environment (Hardware?, OperateSystem*, Compiler*, Application*)>
<!--2 ELEMENT 硬體 (微處理器?, 多媒體配備*, 週邊配備*)-->
<!ELEMENT Hardware (Microprocessor?, MultimediaDevice*, PeripheralDevice*)>
<!--3 ELEMENT 微處理器 (#PCDATA)-->
<!ELEMENT Microprocessor (#PCDATA)>
<!--3 ELEMENT 多媒體配備 (#PCDATA)-->
<!ELEMENT MultimediaDevice (#PCDATA)>
<!--3 ELEMENT 週邊配備 (#PCDATA)-->
<!ELEMENT PeripheralDevice (#PCDATA)>
<!--2 ELEMENT 作業系統 (作業系統名稱?, 作業系統版本?)-->
<!ELEMENT OperateSystem (OSName?, OSVersion?)>
<!--3 ELEMENT 作業系統名稱 (#PCDATA)-->
<!ELEMENT OSName (#PCDATA)>
<!--3 ELEMENT 作業系統版本 (#PCDATA)-->
<!ELEMENT OSVersion (#PCDATA)>
<!--2 ELEMENT 編譯器 (編譯器名稱?, 編譯器版本?)-->
<!ELEMENT Compiler (CompilerName?, CompilerVersion?)>
<!--3 ELEMENT 編譯器名稱 (#PCDATA)-->
<!ELEMENT CompilerName (#PCDATA)>
<!--3 ELEMENT 編譯器版本 (#PCDATA)-->
<!ELEMENT CompilerVersion (#PCDATA)>
<!--2 ELEMENT 應用程式 (應用程式名稱?, 應用程式版本?)-->
<!ELEMENT Application (ApplicationName?, ApplicationVersion?)>
<!--3 ELEMENT 應用程式名稱 (#PCDATA)-->
<!ELEMENT ApplicationName (#PCDATA)>
<!--3 ELEMENT 應用程式版本 (#PCDATA)-->
<!ELEMENT ApplicationVersion (#PCDATA)>
2. 表徵資訊的 XML schema
<?xml version="1.0" encoding="big5"?>
<!-- edited with XMLSPY v2004 rel. 3 U (http://www.xmlspy.com) by amy (chan) -->
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:element name="class">
<xs:annotation>
<xs:documentation>類別</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="representaion" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element name="StructureType" type="xs:string" minOccurs="0"/>
<xs:element name="FileDesceiption" type="xs:string" minOccurs="0"/>
<xs:element name="Encoder" type="xs:string" minOccurs="0"/>
<xs:element name="Decode" type="xs:string" minOccurs="0"/>
<xs:element name="Encryption" type="xs:string" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="Player" type="xs:string" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="Conversion" type="xs:string" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="environment" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element name="Harderware" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element name="Microprocessor" type="xs:string"
minOccurs="0"/>
<xs:element name="MultimediaDevice" type="xs:string"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="PeripheralDevice" type="xs:string"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="OperateSystem" minOccurs="0"
maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="OSNmae" type="xs:string"
minOccurs="0"/>
<xs:element name="OSVersion" type="xs:string"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="Compiler" minOccurs="0"
maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="CompilerName" type="xs:string"
minOccurs="0"/>
<xs:element name="CompilerVersion" type="xs:string"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="Application" minOccurs="0"
maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="ApplicationName" type="xs:string"
minOccurs="0"/>
<xs:element name="ApplicationVersion" type="xs:string"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
本研究將表徵資訊視為圖 5-4 中增加的 schema，對三個封包而 言，只有 AIP 因長久保存需求要有表徵資訊，此外，由檔案的產生者 對表徵資訊描述是最恰當的，因此，本研究設計此增加的 schema 應 用於 SIP 及 AIP。
三、封包詮釋資料設計
本研究設計三個封包的詮釋資料格式，由於 AIP 是為了長久典 藏，所需的描述最為複雜，欄位也最多，所以本研究先從 AIP 的詮釋 資料設計，再分別說明 SIP 及 DIP 的內容。
(一) AIP 典藏封包
AIP 的內容著重保存，因此 AIP 的保存描述欄位較多，參考國家 檔案描述格式，AIP 除了必須保留所有欄位之外，還須加入 OAIS 訊
模型中保存描述資訊所不足的描述欄位，本研究加入在原有的「資典 藏歷史」欄位之下，加入六個子欄位，說明每次發生的典藏歷史事件，
使得檔案的起源資訊更加清楚，並加入「建立的理由」欄位，說明使 用此數位物件的理由及目的，最後加入「物件查核」及其四個子欄位，
表示出現行國家檔案描述格式所欠缺的固定資訊。由於國家檔案描述 格式依 EAD 建立，EAD 欄位重視檔案的來源及情境，是故本研究認 為在 AIP 的保存描述資訊增加上述幾個欄位及子欄位即可。
而 AIP 除了主要的 schema 保存描述資訊外，為長久保存，尚需 增加的 schema 表徵資訊，所以 AIP 封包中的詮釋資料，由主要的 schema 及增加的 schema 組，將 AIP 保存描述欄位以表 5-6 呈現：（加 底線為原國家檔案描述格式外增加的欄位）
表 5-6 AIP 保存描述資訊欄位
分欄與屬性 分欄與屬性 分欄與屬性 分欄與屬性 分欄與屬
性
分欄與 屬性
資訊類型
EAD 標目
<eadheader>
參考資訊
EAD 識別
<eaddid>
參考資訊
國碼
<countrycode>
參考資訊
背景描述
<profiledesc>
參考資訊
編目者
<creation>
參考資訊
label= 參考資訊
日期
<date>
參考資訊
Label= 參考資訊
編目語言
<langusage>
參考資訊
