元數據范文
時間：2023-03-18 13:12:07
導語：如何才能寫好一篇元數據，這就需要搜集整理更多的資料和文獻，歡迎閱讀由公務員之家整理的十篇范文，供你借鑒。
篇1
關鍵詞：DC 元數據 EAD 電子檔案 映射
中國分類號：G250.76 文獻標識碼：A 文章編號：1674-098X（2013）01（a）-0-03
隨著計算機和互聯網的普及，來自檔案館、圖書館、博物館及其他機構的各種數字檔案資源如檔案、手稿、照片、古籍、個人論文日益增多，大量的電子檔案給傳統的文件管理方式和理念帶來了不小的沖擊，如何利用信息技術實現電子檔案的科學管理也成為檔案界的研究熱點。隨著元數據技術的發展和應用，利用元數據實現對電子檔案的有序管理已逐漸為檔案界所接受[1]。
來自于不同軟件系統的電子檔案常常具有不同的著錄格式，它們互不兼容，從而導致不同數據庫之間根本無法互相訪問和檢索，對普通的檔案館來說難以實現無障礙的利用與共享。目前，大多數的研究項目對于分布、異構的數字檔案資源只是提供基于互聯網的網絡鏈接與檢索共享，尚未實現元數據級的互操作，因此無法提供專業化的深度增值服務[2]。解決這一問題的途徑之一就是實現元數據的互操作和格式轉換。該文將探討EAD與DC這兩種目前應用最為普遍的元數據之間的映射，具備較大的實用意義。
1 DC元數據與EAD
1.1 DC元數據及特點
DC（Dublin Core）即都柏林核心元數據，是目前網絡信息資源組織最為通用的元數據格式。DC最早由美國OCLC發起研究，是“用該元素集描述任何網絡信息資源，并足夠簡單以至任何作者無需專門培訓即可創建自己文件”的元數據。它由15個基本元素組成，分為三個廣為認可的大類，內容描述類包括題名、主題或關鍵詞、資源描述、來源、語種、相關資源和時空范圍。知識產權類包括責任者、出版者、其他責任者及權限。外形描述類是指對資源外形特征信息的描述，包括日期、資源類型、資源形式和資源標識。
DC的特點包括以下幾方面。
簡易性：只有15個元素，而且通俗
易懂；
通用性：不針對某個特定的學科或領域，支持對任何內容的資源進行描述。增加了跨學科的語義互操作性的可能；
可重復性：其所有元素都是可重復的，解決了多著者與多出版者等重復元素的著錄問題；
可擴展性：它允許資料以地區性規范出現，并保持元數據的一些特性，以便日后有擴充的余地；
可修飾性：對于需要詳細著錄的資料，引進了DC修飾詞。它遵循向上兼容原則，在范圍上對未修飾詞的語義進行限定，在深度上對未修飾詞的語義進行延伸。
1.2 EAD及其特點
EAD的全稱是Electronic Archival Description，即電子檔案著錄，主要用于著錄檔案和手稿資源，包括文該文檔、電子文檔、可視材料和聲音記錄。它開發于1993年加州伯克利大學的一個研究項目。它是以通用標準語言（SGML）和擴展標記語言（XML）文件類型定義（DTD）的形式存在的[3]。EAD元素集定義有3個層次：EAD頭標，著錄檔案的產生、修訂、出版、發行等信息；前事項，著錄檔案題名頁內容；檔案著錄，是對檔案內容及其相關信息的具體描述，包括文件內容、上下關系及增補信息等。
經過多年的研究和發展，EAD受到了檔案界和圖書館界的普遍擁護，是美國檔案協會的成員們以及一些歐洲國家的檔案館主要使用的元數據，也已成為在世界范圍內獲得廣泛應用的電子檔案著錄標準。這是由于EAD具有以下特點。
使用了標準通用置標語言（SGML），SGML是電子文獻處理與交換的國際標準，用EAD著錄的電子檔案可以提供網上的信息共享和檢索。
不依賴于任何的硬件和軟件平臺，不需經過任何的轉化，在Unix操作系統、Microsoft Windows和Macintosh等環境下都可以很好地被識別。
具有伸縮性，同一部文獻既可選用一些簡單的標識符著錄，也可以選用復雜的等級化的標識符著錄。
使用EAD既可以形成新檢索工具，也可將已有的檢索工具轉化為EAD的編碼的機讀格式。轉化時可能要稍作改動或重排，但不需要大量的編輯。
檢索功能強。EAD以查詢語言（QL）為基礎，除了具有一般的檢索功能，如布爾檢索、截詞檢索、近似檢索以外，還可以在目錄中查找單個款目和離散的數
據項。
應用范圍廣，EAD既可用于手稿，也可用于技術革新、藝術與雕塑、醫學、工業等領域的科學資料。
1.3 DC與EAD的比較分析
不難看出，DC和EAD的結構都簡單靈活，具有很強的可兼容性、可擴展性和可互操作性，這些特性都使得這兩種元數據得到越來越多國家的重視并被廣泛應用。對在著錄和信息揭示深度上看，DC對資源主題的揭示過于簡單，對著錄對象的描述深度不夠，不能進行專指度較高的檢索；EAD則著錄詳盡，適用范圍廣泛，檢索途徑多樣[4]。
綜觀DC與EAD的結構特點和應用性能不難發現，DC的最大特征就是簡化的語法系統和有限的元素數量，因此它更具有簡易性和親和力，適用于廣泛的資源描述和利用群體；EAD則更為專業化，適合檔案專業背景，提供了詳盡的資源描述和更多的檢索入口，更適用于資源的深度描述和特定學科領域內的深入交流[5]。
2 DC元數據與EAD的映射
2.1 DC與EAD映射表
該文給出DC與EAD的映射表如表1。
2.2 建立映射規則
建立了以上映射表并不能直接完成DC與EAD的映射與轉換，仍需針對兩種元數據的多種差異建立映射規則，從而使轉換完成得更為完整準確。
2.2.1 解決結構上的差異
在映射表中多個元素均為一一對應，但由于兩種元數據的結構差異，就產生了源元數據和目標元數據元素間的一對多、多對一或無對應關系的情況出現，如DC的責任者和其他責任者兩元素與EAD來源元素的對應為多對一關系，DC的來源、相關資源和版權管理等元素在EAD中則找不到與其相對應的元素。針對這些情況，映射規則必須規定在什么情況下將進行相應轉換、如何轉換，對無對應關系的元素如何進行轉換處理，等等。
2.2.2 解決應用上的差異
由于DC和EAD的結構均靈活多變，存在多種必備和可選元素、可重復與不可重復元素、有無子元素等多種情況。此時映射規則須針對具體情況，做出恰當的規定，如明確規定源元數據必備元素的范圍、確定源元數據多個重復元素的可選擇性、對一方元數據中子元素缺少對應元素時如何處理，等等。
2.2.3 解決語義上的差異
針對二者語義、數據類型和形式、取值范圍不一致等情況做出明確規定，盡量消除差異，確保轉換的規范統一。
3 存在問題及解決辦法
通過理論研究和多個國家的轉換實驗，我們發現對DC和EAD進行轉換的主要困難還是在于EAD的復雜結構與DC元數據過于簡單的矛盾，表現為將EAD轉化為DC之后，難以在同一個全宗的檔案資料之間重新建立鏈接，或者難以對由不同數據庫收藏的、由同一個人或機構產生的資料之間重建鏈接；有時會丟失原EAD記錄中的上下文信息，或者轉換后的著錄不夠清晰，甚至出現錯誤指示等[6]。
以上問題的解決措施有以下幾方面。
3.1 制訂基于DC的電子檔案元數據規范
元數據規范（也稱元數據標準）是描述某類資源的具體對象時所有規則的集合。一般包括完整描述一個具體對象時所需要的數據項集合、各數據項的語義定義、著錄規則和計算機應用時的語法規定。
通過制訂針對電子檔案的元數據規范，我們可以解決DC諸如對著錄對象的描述深度不夠、不能進行專指度較高的檢索、與原EAD文件結構的對應不夠準確等方面的不足。制訂能夠描述或標識電子檔案內容、屬性、外觀特征及層次結構的描述元數據規范和管理元數據規范，從元素、語法、句法等方面對檢索屬性集做出規定，在保證數據質量和檢索效果的基礎上做好檢索點設置，提高轉換后文件對原文件相互聯系的反映準確程度，有效表示轉換后文件的可選項等等，確保轉換后的元數據質量。
3.2 善用DC修飾詞
由于簡單DC的15個元素只限于描述信息的單一層次，而EAD是具有等級結構，特別是在EAD內容描述部分的從屬部分（dsc）中，可從c01到c12多次重復，并且這些從屬部分之間存在密切關聯，要靠簡單的DC元素來充分表達檔案描述之間復雜的層級關系確有一定難度，但是，通過引入適當DC修飾詞的復雜DC將能彌補這一缺憾。
目前DCMI（Dublin Core Metadata Initiative，都柏林核心元數據計劃）確立了兩類修飾詞，即元素修飾詞和編碼體系修飾詞[7]。隨著各類團體遵從dumb-down（向上兼容）原則提出更多的修飾詞，在經過DCMI應用委員會審核批準后推薦給大家使用，由此逐漸形成一個修飾詞的大家族。相信不久的將來，通過檔案工作者的不懈努力，針對檔案專業領域的修飾詞也會應運而生，通過多個修飾詞的分級復用會較好地解決以上
問題。
3.3 確定DC為我國數字檔案館界的元數據標準
目前EAD在我國的應用僅限臺灣，大陸還只處于理論研究階段[8]；而中文DC的研究與開發則已經從早年的實驗階段步入實用階段，已設計并制訂了期刊論文、電子圖書、古籍、家譜和地方志等多種元數據規范，而且使用范圍日趨廣泛，逐漸為越來越多的圖書館所采用。
數字圖書館的成功范例為數字檔案館做出了榜樣。希望我國檔案界盡早確立DC為行業元數據標準，加強數字檔案館建設中元數據利用的一致性，少走彎路，盡早實現中文檔案信息資源的共建和共享，提高我國檔案界的自動化和標準化水平。
參考文獻
[1] 張正強.論中國電子檔案著錄標準化的發展方向[J].圖書情報知識，2004（5）：35-38.
[2] 何小菁.數字檔案館元數據編制研究[J].圖書情報工作，2004（5）：93-95.
[3] 宋雪雁.檔案元數據（EAD）著錄原則探析[J].檔案學通訊，2009（6）：
57-59.
[4] 王萍，宋雪雁.EAD、DC、TEI著錄實例及其比較分析[J].圖書情報工作，2006（12）：79-82.
[5] 王小麗，王芳.國內外數字檔案館元數據標準體系比較研究[J].情報科學，2007（3）：382-389.
[6] 王芳，王小麗.基于OAI協議的數字檔案館元數據互操作問題研究[J].現代圖書情報技術，2007（3）：18-24.
篇2
關鍵詞：信息資源；特色數據庫；元數據；基本原則
引言
隨著時代的發展和進步，當前已經進入知識經濟時代。網絡信息技術的飛速進步，大大加快了信息資源的傳播速度；加上層出不窮的社會科研成果，有用的知識信息量急劇增長，使得人們如何通過Internet快速準確的獲取所需信息已逐漸成為大家關注的問題。作為重要的知識信息集散地，圖書館長期以來扮演著信息服務的前沿陣地的角色。但是事實是，圖書館根本不可能將所有的出版物收集起來供用戶查閱，而且不同用戶對信息資源的需求也不限于單一資源，而是希望對國內外各學科科學新動向、新成果、新發展有較為全面的了解，希望能了解一些市場競爭、市場供求的實時動態信息等。因此，圖書館就必須立足自身實際、充分發揮資源優勢，完成數字化圖書館的建設，實現資源的整合。而信息資源的有效整合的基礎就是元數據的建立。
1 元數據的基本概念
元數據（metadata）又稱為數據的數據（data about data）或對其他信息進行描述的信息 （information that describes other information），其作用類似于圖書館中數目卡片。隨著現代網絡技術的發展，信息資源的快速膨脹給我們帶來了諸多難題，而元數據則是解決這類難題的關鍵所在。元數據能幫助解決的問題主要有以下三個方面：1）有效組織和存儲不勝枚數的信息資源，以解決目前URL方式無法滿足需求的問題；2）作為一種信息檢索方式，幫助人們在浩瀚的信息海洋中快速準確的完成有效信息的檢索。目前主流的信息檢索方法是搜索引擎，但其帶來了龐大的無效信息量，給人們的信息檢索造成困擾；3）有效管理巨量的信息資源。為適應如今信息量劇增、瞬息萬變的世界，應該及時補充和更新已知的信息，所以要加強專家系統、智能與數據挖掘等新支持系統的研發。因此，元數據主要的功用就是對現有信息資源的有效描述、檢索、并對原有信息進行維護、更新和補充，實現信息資源的有效管理和共享。
然而到現為止，元數據仍不存在統一的格式和標準屬性，反而具有非常靈活的形式。不同領域的元數據標準也往往不同，如地理空間領域所用的是DGM，音樂資料領域所用的是sMDL，而檔案領域應用的卻是EAD等等。此外，不同的組織所制定的元數據標準的偏重點也往往有所差異，如MFC、CDF、RDF及Dublin Core（都柏林核心元數據）等，其中影響力最大的當屬Dublin Core，其已經逐漸發展成一種通用的元數據標準。且近些年來，我國相關部門已經根據Dublin Core制定出了相應的中文元數據標準，如會議論文、期刊論文（期刊單篇）、電子圖書、拓片及音頻等元數據的標準。常見的國內元數據標準有CALIS元數據標準和國際科技部元數據標準兩種。
2 特色數據庫的元數據特點
在高度信息化的現代社會，元數據的使用范圍越來越廣，特別是特色數據庫更加具有針對性，我們必須對其特點做深入的了解，才能更好地對它加以利用。經過仔細研究，能夠歸納出以下特點：
1）由于元數據的本質功能是對對象數據進行描述，特色元數據同理，它的本質特點就是描述性，主要利用一些約定俗成的為大眾接受的規則對數據進行描述；
2）特色數據庫的元數據具有復雜性，因為特色數據庫不同于維普、CNKI等這樣的商業數據庫，它包含的資源多種多樣，包括期刊單篇、圖書、會議論文甚至是音頻、視頻等內容，另外，特色數據庫里面的數據除了以一次文獻，可能還有綜述、摘要、關鍵詞等內容，要對特色數據庫建立元數據，就必須考慮特色數據庫的各方面的內容，元數據的檢索也要涵蓋各方面的內容，相對來說較為復雜；
3）特色數據庫中對某些字段的定義難免不夠標準。因為特色數據庫中的資源類型繁多 ，部分不在相同資源類型中的相似內容很有可能在相同的字段中定義，比如時間，圖書的出版時間可能會和會議舉辦的時間共同歸納在數據庫的“時間”的字段當中，再如，不同文獻類型中的頁碼都可能歸納在數據庫的“頁碼”字段；
4）部分滿足現有標準的必備元素在特色數據庫中沒有被準確定位，在特色數據庫建立初期，相比于數據的完整性與可交換性以及字段定義方面來說，著錄者對數據庫的應用和功能更為重視，這樣厚此薄彼的做法直接導致了部分重要字段的丟失，比如審校時間、審校員等管理類型的元數據以及統一資源標識符（簡稱URI）、資源類型等描述型的元數據；
5）特色數據庫元數據中的某些字段內容未達到標準要求，雖然元數據已經有了很長的發展歷程，但在近幾年才被引入到國內，大部分高校在建設特色數據庫的時候它還未被引進，因而過去對其概念的提出并不標準，這就導致各個特色數據庫中的字段定義各行其是，沒有統一的標準，這些在早期被定義的字段內容取法與現有標準的元數據相契合，例如某一期刊中的年卷期被歸納在一個字段中。
3 特色數據庫元數據建立時應注意的問題
3.1元數據的描述深度
所謂元數據的描述深度，就是元數據解釋對象的程度的高低，通俗一點來說，就是元數據在定義時的使用數量。在描述對象時，一定要掌握好度，若描述的程度太高，就會增加輸入難度；反之，則會導致描述對象數據不完整、對象數據反應不精確等問題。相對于商業數據庫而言，特色數據庫對元數據的描述程度更高，它的元數據，還包括一些對象數據的輸入都要求當地職工完成，所以，如果將元數據定義太廣的話，就會成倍增加工作人員的工作量。
對于元數據的要求，讀者和著錄方的要求有明顯的差距。元數據建立的初衷只是使數據更加標準化，方面對數據的檢索、管理等，如果僅僅滿足于這一要求，那么只需要將主要責任者、正題名、主題等一些重要的元數據進行定義便可。但是，使用數據的主要對象是讀者，為了使閱讀更加方便，能從更全面的途徑檢索、獲取信息，受眾群對元數據的著錄提出了更高的要求，他們希望著錄的元數據更多更全。面對數據加工和信息服務之間的矛盾，在建立元數據之前應當盡可能地尋求兩者之間的平衡點，以求達到最好的效果。
3.2建立非一次文獻元數據的標準
現有元數據標準的適用范圍十分有限，主要是如期刊單篇、圖書、會議論文等的基礎文獻資料，特色數據庫解決了這一問題，它不僅囊括了基礎文獻資源，還包括一些非一次文獻，如文摘等。因此，為了避免建立數據庫時做無用功，我們在對文摘等非一次文獻數據庫著錄元數據之前，應當仔細考慮以下問題：是建立基礎文獻的元數據庫，還是建立文摘的數據庫？由于兩者之間存在很大的差異，所以在工作之前應當搞定這一問題。比如作者，若以文摘為依據，元數據應為文摘員，反之，則為作者；再比如著作時間，以文摘為依據，元數據應為文摘創作時間，反之，則為原文創作時間。就個人而言，在為文摘數據庫建立元數據的時候應當以基礎文獻為依據，原因有二：1）在文摘數據庫中有很多像“文摘員”這樣的特殊字段完全能夠從元數據標準中擴展定義；2）文摘始終來源于文獻，它只是對基礎文獻數據的描述。如果在建立數據庫時將文摘作為主要依據，就難以對基礎文獻進行有效描述，如創作時間、作者等重要信息，這將對作者正確理解文獻信息造成障礙。
3.3資源整合模式的運用
資源整合的模式對于元數據的建立十分重要，它能夠指明元數據的建立方向。現有的資源整合模式主要有兩種：網絡模式和獨立模式。雖然這兩種模式能實現一部分相同的功能，比如跨數據、平臺的一站式檢索功能，但兩者之間還存在著較大的差別。運用網絡模式進行資源整合，不會過多考慮文獻所屬的數據庫，而主要考慮數據資源的類型，根據資源屬性建立各自的數據庫；如果運用獨立模式的資源整合模式，就不用考慮資源類型，而按具體標準建立相應地元數據庫。相比之下，網絡模式的資源整合方式更加適用于元數據的建立，主要原因有三：1）獨立模式下的數據庫均有它們的元數據庫，當數據庫達到一定數量時，元數據也會變得十分龐大，這樣不僅不利于數據庫的管理，還會增加檢索的時間，而采用網絡模式進行資源整合，就會有基本固定的元數據庫數量；2）由于不同數據庫之間也存在著相同的資源類型，如期刊單篇同時存在于特色庫和CNKI 中，獨立模式的資源整合方式會增加各個數據庫的元數據，這樣不僅使元數據的定義太過隨意，還增加了職員的工作量；3）由于元數據的標準需要依據相關的資源類型來建立，所以采用網絡模式的資源整合方式更加合理。
4 特色數據庫元數據建立的基本原則
作為描述數據的特殊數據，元數據建立的目的就是便于特色資源的檢索和存取。通過對特色資源的運行方式、功能特點和系統的總體運行性能進行統一的描述和規定，元數據的建立將特色資源進行標引以方便廣大用戶的檢索與使用。但是，目前首先要進行考慮的特色資源的共享問題，因此，特色數據庫元數據的建立應遵循以下原則：
4.1準確性原則
按照元數據的定義，其目的是為了完成對數據內容的描述。因此，準確無誤的元數據標引是實現準確描述數據的前提。具體而言，就是要求元數據建立不僅能準確的描述信息資源，還能保證使用的相關術語、元素定義等概念清晰，不存在模棱兩可的情況，且不使用那些易于發生歧義的元數據。換句話說，元數據建立時不但要將著錄標準、傳輸語言等進行統一規定，還要對元素的設置、標記語言及著錄的原則進行嚴格的規定。只有實現這樣的元數據標引，所建特色數據庫的檢索質量和檢索效率才能達到最好的效果。
4.2標準化原則
在特色數據庫的建設時，標準化是實現有效進行信息標引和資源共建共享的主要因素。但目前而言，元數據建立的標準尚存在很多問題。雖然像都柏林核心元素集等流的元數據建立已經有了統一的通用的標準，但是全國各地仍然難以在資源的共建共享上取得統一的認識，在實際操作中仍各行其是，同時在元數據的標引上也難以達成一致。即使是對相同元素進行元數據的著錄時，差異往往也會很大。例如，最初像都柏林核心元素集只規定有15種核心集元素，以達到規范、簡化元數據的標引過程。但是具體到各地圖書館后，很多圖書館在此基礎上盲目擴充，使得該數據集日益復雜化，越來越難以實現標準化了。元數據的標準化內涵廣泛，既包括元素著錄時內容的標準化、進行相同類型的數字化信息資源的著錄時所用元數據的統一性，還包括元數據建立時采用的編碼語言的統一化等方面。
4.3互操作性原則
當不同的組織和管理且相關技術規范不完全相同，應該給用戶提供統一的檢索界面，實現對用戶的一致，這就是元數據的互操作性原則。由于組織信息進行特色數據庫的建立時，各地圖書館所采用的元數據標準難免會有出入，且學科和內容也有較大差別，數據庫建成后又要求實現資源的共享，故應該遵循元數據建立的互操作性原則，以滿足客戶需求，實現特色數據庫的建立。
4.4編碼語言的統一性原則
實現對元數據的元素與結構的描述和定義的語法規則和具體語義就是元數據的編碼語言。就目前而言，元數據建立時使用的編碼語言有很多種，具體包括超文本標記語言（Hypertext Markup Language，HTML）、標準通用標記語言（Standard General Markup Language，SGML）及可擴展標記語言（Extensible Markup Language，XML）這三種。有的元數據對使用何種編碼語言有著明確的規定，如美國聯邦聯邦地理數據委員會、TE1和EAD都只使用SGML語言。有的元數據在這方面又沒有相關的規定，如DC數據，既有使用XML的，也有使用HTML的。考慮到資源的共享和數據交換，元數據作為傳遞計算機系統所能理解的存儲數據和信息，其元素結構和組織方式必須要能被計算機理解。但是由于元數據有著不甚規范的編碼語言，造成了元數據的格式記錄和編碼規則不統一，這樣的元數據建立的特色數據庫就難以實現資源的共享和數據的管理。因此，采用規范、統一的元數據編碼語言是實現信息資源的準確描述和資源共享的必然選擇。
4.5專用性和通用性原則
元數據建立的專用性指的是某種元數據的建立只能完成一種特定信息資源的描述。而元數據的通用性原則指的是某種元數據可以實現多種信息資源的描述。元數據的專用性適用于對某特定信息資源實現很好的描述，但難以對其他信息資源進行適當的描述；而元數據的通用性原則能實現對多種信息資源的有效描述，卻對特定信息資源缺乏足夠的描述力度。盡管特色數據庫本身是一種專指的數據庫，但是作為優秀的特色資源庫，其專指的應該是學科，但是該學科所覆蓋的內容是可以很廣泛的。因此，為實現眾多信息資源的有效整合和優秀的特色數據庫建設，在進行元數據建立時應兼顧元數據建立的專用性和通用性，在兩者間找到平衡，達到更好的效果。
5 結束語
元數據的建立是建設圖書館特色數據庫、有效整合和管理信息資源的基礎，本文對元數據的基本概念和特點作了較為詳細的闡述，其次針對元數據的建立過程中應注意的諸多問題進行了簡要分析，最后提出了元數據建立的基本原則。
參考文獻
[1]李凌杰.特色數據庫建設中的元數據質量控制研究[J].圖書情報工作，2010（05）43-46.
[2]袁小一，蘇智星.淺談特色數據庫元數據的建立[J].晉圖學刊，2005（05）28-30+35.
[3]陰小建.基于XML的特色數據庫平臺研究[D].山東師范大學，2010.
篇3
由于缺乏統一的組織和管理，相關網絡信息的類目設置十分混亂，如類目劃分沒有遵循合理的標準，劃分同一層次時采用2個或2個以上的劃分標準，沒有應用統一的標準；資源劃分時，重復或遺漏現象較多；很多不符合基本邏輯規則的情況，如整體不能包含局部等在網絡信息的類目展開中大量存在。基于這些原因，當用戶檢索時，搜索到的信息就可能與實際需求之間存在很大的偏差。③為了更好的反映動態變化，大多數網站都會設置最新動態和熱點專題等類目。盡管這些類目的設置可以更好地幫助用戶了解當前最新的信息，但是也會間接的降低信息組織的規律性、邏輯性和層次性，增加網絡信息的易逝性，給用戶的檢索活動帶來諸多不便。從當前網絡信息資源組織的現狀來看，網絡信息資源組織者必須通過改進與完善原有的信息資源組織方法，來構建一個更加適合網絡環境下信息資源的組織方法。基于這種需求背景，元數據的網絡信息資源組織方式產生了。
元數據及元數據方案分析
元數據元數據（Metadata）就是Internet中用于描述數據與資源，促進信息資源組織與發現的數據。關于元數據有以下幾點值得注意：（1）元數據不一定是數字形式，它還可能是其他形式，即元數據的形式是多樣的。（2）元數據不僅可以用于對信息對象進行描述，同時還可用于對被描述對象的其他情況進行說明。（3）元數據可來自各種不同的資源，除了由人類提供或是計算機自動生成外，通過推斷一項資源與另一項資源的關系也可以得到。（4）在信息對象中可以自由增減元數據。元數據方案（1）MARC（機讀目錄格式）。機讀目錄格式（Ma－chine-ReadableCatalogingFormat，MARC）是各國信息資源的主要表示形式之一。它提供了一整套完整而詳盡的流式數據表示規范，在圖書館書目記錄數據應用時，可作為描述、存儲、交換、處理和檢索信息的基礎。經過多年的發展后，MARC已經不僅僅用于描述書目信息，還可用于描述和存取電子信息資源。（2）DC（都柏林核心）。都柏林核心（DC）全稱都柏林核心元素集（DublinCoreElementSet），由O－CLC（聯機計算機圖書館中心）和NSCA（美國超級計算應用中心）在第一屆元數據研討會上討論制定的一種元數據格式。DC作為一種元素集，包含了15個基本的數據元素和44個限定詞。早期制定DC主要是為了對出版物的信息進行描述，而在隨后召開的6次元數據研討會上，經過不斷地補充和修訂，DC的結構與功能已逐漸趨于完善。同時，由于它所具有的簡單、靈活，易于理解，可擴展性、兼容性強等特點，使得它成為了一個很好的適用于網絡信息資源的標識。（3）XML（可擴展標記語言）。可擴展標記語言（ExtensibleMarkupLanguage，XML）從SGML發展而來，是SGML的一個精簡子集，既保留了SGML的可擴展性與適用性，同時也支持了靈活多變的Web應用。更為重要的是，它提供了一種對文檔進行結構化描述的機制，便于將各種結構的文檔作為統一的Web文檔的一部分進行傳輸。由于采用的是結構化的描述方式，因此利用XML便可以在元數據集中定義層次、嵌套結構比較復雜的元素。此外，XML所具有的自己的文件類型（DTD）為在通用的元數據外定義自己的元數據集合提供了便利。（4）RDF（資源描述框架）。資源描述框架（Re－sourceDescriptionFramework，RDF）使用XML語法來表示的資源模型，是一個用于表示Web資源特性及資源與資源之間關系的框架。RDF的提出對解決不同元數據的互操作性與兼容性具有非常大的幫助，同時也為元數據在Web上的應用提供了一種基礎結構，使得各應用程序之間可以在Web上進行交換元數據，為促進網絡資源的自動化處理提供便利。為了實現元數據標準的統一，國際標準化組織（In－ternationalOrganizationforStandardization，ISO）最近專門成立了一個元數據工作組，用于對元數據全球性標準的研究和建立。這一國際性標準化研究工作組的建立，推動元數據的標準化進程具有十分重要的意義，將使其不斷向標準化、結構化方向邁進。隨著因特網的不斷發展，建立標準的元數據系統已成為人們的共同追求的目標。在這其中，元數據方案的標準化工作已經受到了人們的普遍關注，可以說，元數據的重用與元數據的互換已成為當前和今后元數據發展的必然趨勢。
元數據在網絡信息資源組織中的作用及應用
元數據在網絡信息資源組織中的作用（1）描述。元數據所提供的描述功能就是從元數據的定義出發，對信息對象的內容與位置進行描述，實現對信息對象的存取和利用。（2）定位。一般而言，元數據中都會包含與網絡信息資源位置方面相關的信息，利用這些信息就可以準確確定資源的位置，有效地促進信息對象的發現與檢索。除此之外，在確定了信息對象的元數據后，對其在數據庫及其他集合體中的位置基本上也就可以確定了。（3）搜尋。在著錄過程中，可以對信息對象中的重要信息進行組織，賦予其語意，同時建立起聯系，保證檢索結果更加準確，符合用戶需求，為用戶提供有價值的識別資源，發現真正需要的資源。（4）評估。元數據所具有的能夠提供有關信息對象的名稱、內容、時間、格式、作者等信息的功能，使得用戶在不對信息對象進行瀏覽的情況下，就可以對信息對象有一個初步的認識和了解，然后再參照相關的標準，就可以對網絡信息資源價值的大小進行評估，并以此來作為存取與利用資源的標準。（5）選擇。利用元數據提供的相關信息資源的描述信息，并在參考相應評估標準的情況下，用戶就可以非常便利的選擇符合自己需求的信息資源加以利用。元數據在網絡信息資源組織中的應用元數據及其在XML/RDF結合應用下，可以更好地描述與管理網絡信息資源。而在其上的應用技術———推技術（PUSH），則為用戶在實際的應用中提供了巨大的便利。推技術是在元數據的基礎上產生的，其核心主要是：可以自動搜尋網上信息資源，然后在用戶需求的基礎上對組織進行加工和管理。目前，在眾多針對元數據的研究性工作中，如DC、RDF等的研究，對于推技術而言都是用于實現主動信息服務的基礎性研究工作。推技術可直接、全面的表達出用戶的信息需求，從而實現了真正意義上的面向用戶；信息查詢是面向用戶、主題的，全部可由用戶來進行。將拉技術與推技術有機結合，可以產生多種方式，如先推后拉、先拉后推、推中有拉、拉中有推等，這樣不但可以有效減輕帶給網絡的負擔，還可以擴大用戶范圍，為用戶提供更為有效的服務。可以說，它將成為信息系統實現用戶主動信息服務發展的一個方向。
篇4
關鍵詞：元數據 電子文件 檔案著錄
元數據，英文名為 “metadata”，最早出現于計算機信息技術領域，目前已經在多個專業領域，如圖書情報、博物館及檔案等領域中得到廣泛應用，電子文件管理元數據研究已經成了檔案數字化研究中的基礎項目。發展中國的數字檔案館不能不對元數據進行研究。
一、檔案界關于元數據研究的階段劃分
檔案界關于元數據定義的研究起始于20世紀80年代末、90年代初。關于元數據定義的研究目前已經經歷了三個發展階段，第一階段研究認為在電子文件管理中應有元數據的參與，形成了對元數據引進檔案領域后的初始定義；第二階段是在實踐基礎上展開了元數據項目研究之后，形成了對元數據的深化認識；第三個階段則是目前根據元數據在檔案界實際應用而形成的對元數據定義的最新成果。
1.第一階段――元數據的初始定義
元數據是美國著名的電子文件專家戴維?比爾曼首先引進電子文件研究領域的。對其最初的定義是：元數據是關于數據的數據。在這一層面上，元數據的含義與計算機信息技術領域中的元數據的含義是一致的。
然而，這一含義過于抽象、泛指。因為其適用的范圍，既可以是檔案領域，也可以是其他領域，而且元數據對檔案界來說又是一個新出現的術語，在這之前檔案工作者還從未遇到過這一術語，所以，元數據這一概念不是很容易被檔案工作人員所理解。由于這一原因，在國際檔案界，各國電子文件專家、學者又在實踐基礎上對元數據定義進行了新的探索。
2.第二階段――著錄元數據
由于元數據的含義比較抽象，不直觀，不容易被檔案工作人員所理解，所以，為了使元數據在檔案領域有其更為專指的性質和含義，研究者又提出了著錄元數據的概念，即元數據是關于單一電子文件和文件組合的背景及其相互關系的結構化著錄數據。其中具有代表性的就是英國公共檔案館《電子文件管理指南(1999)》中所提出的定義：元數據指的是關于某份文件和文件賴以存在的集合體的信息(如它們的背景聯系及關系)，泛指結構化的描述和著錄數據。①
著錄元數據主要指的是著錄信息。著錄信息是檔案界人員所能理解的，而且是早已熟悉的，所以，“元數據是著錄信息”的提法比“元數據是關于數據的數據”的提法大大前進了一步。因為，這樣就把元數據這一新的術語與傳統的檔案工作的實踐很好地結合起來，并且也有助于實踐中對元數據的操作與運用。
在這方面，美國的電子文件專家戴維?沃爾思(David Wallance)于1993年在加拿大《檔案》雜志上就撰文指出： 元數據管理就是一個作為目前著錄的替代策略而提出來的。原則上，這種方法對檔案工作人員不是什么新方法，因為檔案工作者早已能獲取和利用元數據了。但是，他們以前并沒有聽說過“元數據”這個詞。②
對于這個觀點，澳大利亞《工業、研究與教育戰略合作元數據項目》的主要負責人蘇?麥克密斯（Sue McKemmish）教授在1998年發表的文章中也指出：如果我們以其廣義和靈活的方式來考慮元數據，那么檔案工作者是元數據的專家，元數據實際就是久以存在于我們周圍的一個簡單的新詞，只不過隨著計算機的出現，被賦予了新名稱而稍顯得不同而已。傳統的檢索工具、目錄卡片、案卷目錄、案卷、紙張文件的文頭與文尾都包括了元數據。③
但是，如果把元數據定義為著錄元數據，容易把元數據等同于傳統的著錄數據，如《國際標準――檔案著錄規則(總則)》、《檔案機讀目錄格式》等。但是從當初元數據引進檔案界的最直接的動機來看，主要是為解決數字化環境中的電子文件管理問題。所以，如何使元數據與電子文件管理更直接結合起來，就成為檔案界所致力探索的領域。
3.第三階段――電子文件管理元數據
在著錄元數據的基礎上，國際檔案界又提出了電子文件(檔案)管理元數據，其真正的含義被定義為：“在對電子文件及其與文件創建和管理有關的人、過程和系統進行確認以及為其提供憑證和背景信息的過程中，有關文件的管理、利用和文件可理解性的元數據。”④“電子文件管理元數據是專門設計用于滿足電子文件管理需求，有關保證文件的真實性、可靠性、穩定性、安全性、完整性、可理解性與可利用性的數據。”⑤
由于元數據在電子文件管理中所起的作用和目的性不同于其他用途的元數據，所以，也就把電子文件管理元數據與其他更為泛指的元數據區別開來了，而且也與其他領域中所應用的元數據區別開來了。所以，現在檔案界所提出的元數據，已與圖書館界、博物館界的元數據在內涵與外延上都不盡相同了。
二、檔案界關于元數據外延的研究
前面我們討論與界定了元數據的內涵，那么，元數據所指的外延是什么呢?或者元數據所指的對象有哪些呢?對元數據外延的理解一般可分為三層：
1.單體元數據。即元數據是一個個單獨的實體，如表達電子文件的題名、責任者、日期等的元數據。
2.元數據組。即多個具有共同性質的元數據實體的組合。如具有表示電子文件結構這一共同性質的多個元數據實體：MARC、TEI、JPEG、MPEG 等組合在一起，就構成一個元數據組合。由于元數據性質的多樣性，所以，同一個元數據同時可以歸入多個不同的元數據組合中。
3.元數據系統。即由單體元數據和元數據組所構成的一個有序化的系統。如《電子系統中文件永久性憑證問題的國際研究項目(InterPARES)》的《分析用模板》、美國匹茲堡大學項目的《元數據參考模型》和澳大利亞南威爾士州檔案館制定的《文件管理元數據標準》等均是元數據系統。
三、元數據與著錄信息的區別與聯系
1.元數據與著錄信息的區別
元數據與傳統意義上的著錄信息是不相同的：
(1)兩者的實現目的不同。傳統的著錄信息的目的主要是用于檢索，主要是為實現檔案的情報價值而設置的；而元數據主要目的是用于憑證，主要是為實現檔案的憑證價值而設置的。
(2)兩者的實現方式不同。傳統的著錄信息的實現方式是“后端控制”，即文件歸檔而移交至檔案館后才進行著錄；而元數據實現方式是“前端控制”，即在文件創建時，就同時對文件進行獲取登錄。
(3)兩者的實現環境不同。傳統的著錄信息主要實現環境是手工環境，即在手工環境下，對文件進行著錄；而元數據實現的環境主要是數字化的系統環境，即在數字化的系統環境中對文件進行控制。
(4)兩者實現的過程不同。傳統的著錄側重于檔案工作過程中某一環節上對著錄單位的控制；而元數據的獲取登錄，則是對電子文件從其產生至結束的整個生命周期的控制。
(5)兩者實現手段不同。傳統的著錄實現手段主要是采用手工著錄，即使在制作機讀目錄的情況下，其著錄的過程也是主要靠手工著錄完成的；而元數據的獲取登錄則將元數據系統預設于計算機系統之中，從而使大部分元數據可由計算機系統自動生成。
2.元數據與著錄信息的聯系
元數據與傳統著錄信息的聯系體現在其個體的共同性上，如反映文件內容的題名、反映責任對象的責任者、反映文件生成時間的日期等，這些個體在元數據中有，在傳統的著錄信息中也有。這是因為，盡管元數據與著錄信息在以上這些方面有區別，但是以上這些方面并沒有窮盡它們的所有性質，在除以上這些性質之外，在某些性質上兩者又具共同性。所以，研究元數據，我們又不能不注意到傳統檔案著錄信息，尋求它們之間的共性，以實現對傳統檔案與電子文件在計算機系統中的集成管理。
注釋：
① Public Record Office. Management Appraisal and Preservation of Electronic Records
② David Wallance. Metadata and Archival Management of Electronic Records. Archivaria. 1993. 36
③ Sue McKemmish Glenda Acland etc. Describing Records in Context in the Continuum The Australian recordkeeping Metadata Schema. Archivaria. 2000. 48
④ ICA. Guide for Managing Electronic Records from an Archival Perspective. 1997. p20.
篇5
關鍵詞：元數據；異構數據源；XML；信息系統集成
中圖分類號：TP311文獻標識碼：A文章編號：1009-3044(2007)03-10618-02
1 引言
在信息化建設中，許多單位都先后獨立開發了信息管理系統。由于這些系統在開發平臺、開發工具，開發時間的不同，它們難免會存在邏輯結構、物理結構的不同，即異構性。在實際工作中，往往又需要各個系統的信息之間進行交換、整合、同步等操作來滿足業務需求，但是由于系統的異構性，它們之間不能進行簡單的信息交換，給實際工作帶來諸多不便。因此信息系統集成已經成為當前信息化建設的迫切需求。
本文針對上述問題，把XML作為數據交換的中間文件，提出了一種基于元數據的系統集成的實現方法。
XML（eXtensible Markup Language）可擴展標識語言是W3C組織的XML工作組在1996的SGML（Standard Generalized Markup Language）工作組的基礎上創立的，于1998年2月正式推出了XML1.0版本。XML是SGML的一個嚴格篩選的子集，它既保留了SGML的絕大部分實用的功能，又大大簡化了SGML過于復雜的地方，使XML變得功能強大而又易于使用，特別是它的平臺無關性，非常適合應用于異構系統集成中的數據交換。
Metadata元數據，通常稱為data about data或是data describes otherData。目前，元數據是網絡資源組織發展的熱點，它與XML的發展密不可分。基于XML的元數據格式將走向標準化，為各種異構系統的集成提供必要的手段。
集成系統采用基于元數據的集成方式。其過程是：系統集成模塊接收到查詢請求后，對命令進行解析，對照元數據進行語義檢查和XML封裝，然后將XML格式的查詢發送到Wrapper，由之轉化分解為相應的SQL查詢命令，通過JDBC接口對數據庫操作，將返回的數據源查詢結果提交回系統集成模塊，最后由系統集成模塊綜合轉化后用于用戶界面層顯示，這樣就把已有的多個數據源集成為一個全局管理、采用統一視圖、面向用戶的集成系統。異構系統對用戶而言完全是透明的。
2 集成系統設計
2.1 系統層次結構
基于元數據的異構數據源集成系統如圖1所示。最上層是用戶層，面向普通用戶提供服務，用戶輸入查詢條件，得到查詢結果；中間層是系統層，提取用戶層的查詢條件，返回相應的查詢結果，具有查詢命令解析、元數據管理和數據綜合等功能；最底層的是數據層，包括各種結構化和半結構化的數據，是實際的數據存儲地。
圖1 異構數據源集成系統層次結構圖
2.2 用戶界面
用戶界面采用JSP動態網頁設計，將用戶錄入的查詢條件提交系統集成模塊，并將最終的查詢結果顯示出來。
2.3 系統集成模塊
系統集成模塊分為命令解析、命令分派、元數據管理、數據綜合，數據轉換等功能組成，如圖2所示。查詢命令通過命令解析器的解析后交給命令分派器，命令分派器從元數據庫中查閱相關數據源的信息，將查詢命令封裝為XML發送給指定數據源的Wrapper進行處理。查詢的結果或錯誤信息經Wrapper傳回數據綜合器。數據綜合器從元數據庫中讀取業務數據之間的關聯規則信息，對查詢結果進行綜合。經過數據轉換器格式轉換，生成最終的查詢結果，以一定的格式呈現給用戶界面顯示。
元數據是系統集成能否實現的關鍵。元數據庫中主要存放兩類元數據：數據源描述和業務數據關聯規則。元數據庫將這兩類元數據集中存放，從而實現集中統一管理。
3 元數據的設計、元數據庫的實現途徑
3.1 元數據的設計
3.1.1 數據源描述規則部分元數據設計
該部分元數據包括如下部分：
(1)數據源所在機器的IP或機器名；(2)數據庫類型及名稱；(3)表名、列名及類型；(4)連接條件與篩選條件說明。
其中的表名、列名是Wrapper從數據庫中提取的，插入到XML文件的相應部分。文件片段如下：
在一次關于人員和車輛分配的查詢中，首先通過查詢元數據庫中的關聯規則人員與車輛的關系，然后查詢元數據庫中人員庫和車輛庫的信息，分派查詢命令，最后綜合就可以給出人員和車輛的分配方案。
以上是部分元數據的設計方法，在集成系統中，對業務數據關聯規則采用管理員界面定制，方便動態維護和管理。
3.2 元數據庫的實現途徑
集成系統中元數據庫采用native XML Database數據庫Taminoo。Taminoo除了可以存儲和訪問XML外，還具備多項功能，包括Open Database Connectivity、符合Unicode要求、HTTP通信及處理非XML數據的能力。Taminoo擁有直接XML檢索和特殊檢索的能力，其查詢語言強大而簡短，可進入任意深度。
4 集成系統實現
系統采用J2EE技術實現，分別針對管理員界面層、系統集成模塊、接口規范定義。其中幾個關鍵技術實現如下。
4.1 元數據管理
元數據管理模塊通過發送查詢命令給Wrapper，由Wrapper將數據源的元數據信息提供給元數據庫，由元數據庫進行統一全局管理，從而使多個數據源構成一個統一視圖。通過對業務數據關聯規則的定制，為查詢的結果進行數據綜合提供依據。
4.2 模塊間接口規范的定義
各個模塊間的數據交換用XML的文件格式。進行數據交換時，查詢元數據庫中相應的信息，按照規則進行數據封裝、轉換、傳輸和接收。增加了靈活性和動態適應性。
4.3 Wrapper
Wrapper包括查詢語句轉換和結果轉換功能。查詢語句被轉換為相應的SQL語句，通過JDBC驅動接口訪問具體的數據源。結果轉換部分依據查詢時建立的XML Schema創造XML元素節點樹等，然后將查詢結果插入到XML結果文檔中，從而實現相應的轉換。
5 結束語
本文提出了一種基于元數據的異構數據源的系統集成設計方案，并給出了系統設計和框架結構，對系統實現的關鍵技術進行了討論。本系統將為異構的信息系統的集成提供一種解決方案。在本單位的值班系統的信息化改造中，通過對該方案的實施，使單位內各個獨立異構的系統有效的集成，提供給用戶一個統一的視圖，提高了查詢效率，達到了預期的目的。
參考文獻：
[1]Roth M T, Peter M. Schwarz. Don't Scrap It, Wrap It! A wrapper architecture for legacy data sources[A]. VLDB[C],1997:266-275.
[2]Ullman J D. Principles of database and knowledge-base systems[M]. Vol. II: the New Technologies. Computer Science Press, New York, NY, 1989.
[3]孫君明, 郭紅. 基于XML的異構信息交換研究[J]. 計算機應用研究,2003(1):69-73.
[4]沈兆陽. Java與XML數據庫整合應用[M]. 北京: 清華大學出版社,2002.
[5]陳傳波, 胡書能. 基于J2EE體系的企業數據交換模型研究[J]. 計算機工程,2002,28(4):281-282.
[6]李安渝, 等. Web Services技術與實現[M]. 北京: 國防工業出版社,2003.
[7]李雙慶, 游蓮, 古平, 等. 一個基于XML的數據交換中間件技術[J]. 計算機科學,2003,30(5):180-181.
篇6
當人類具備了獲取海量數據和處理規模化數據的能力時，以大數據應用為特征的信息技術就會走進我們的日常生活與工作之中。自然的、真實的數據能反映出客觀規律，是大數據之源；虛假的、杜撰的數據是污染源，必須從各個層面根除。安全生產領域尚沒有普遍的、規范的數據源獲取體系，因此，必須從數據源建設入手，獲取真實的數據。
規范安全監管信息工作體系
安全生產監管監察涉及行業領域多、地域面積廣、風險種類復雜、監管體系不完善等，于是長期陷入被動的“治療急診”和疲憊的“預防流行”困惑之中。任期壓力、任期風險主宰了決策思維，“預防為主、綜合治理”便缺乏理性共識，固本強基、長遠謀劃、共治久安則成為“奢望”。
政策短期化、碎片化導致全系統的基礎能力弱化，難以構建系統、完整、明晰的行政監管邏輯關系，安全監管信息化則無源可溯。信息化改變的是服務社會的方式，其價值充分體現在數據的真實性、實時性和集成性，精、準、廣是互為制約的三要素。
實現安全監管工作的現代化，既要重視信息化工作平臺建設，又要重視新技術集成創新的普及，并且要遵循“由下而上建設，由上而下指導”。邊建、邊用、邊完善，在“用”字上下功夫，力求“好用、管用、實用”。
從安全監管重中之重破題
有效遏制重特大事故是我們必須完成的答卷，解決“查、防、治、救”科學化、信息化、法制化就是重中之重。科學地解決“查什么、怎么查、查哪里？測什么、怎么測、測哪里？治什么、怎么治、治哪里？”，是精準的基礎；借助信息技術實現指揮“一盤棋”、決策“一張圖”、行動“一張表”，互動“一張網”，是重要的支撐；完善“依法治安”，實現全方位的黨紀、法規威懾是重要的保障。
“查、防、治、救”的核心環節是科學建立查的目標、指標、周期、處置等工作體系，至簡致用，保障數據源的價值。與時俱進地集成創新測、查等手段，不斷提高效能和質量是科研工作的重點。面對多行業、多領域的重大風險源測控需求，四川省安全科學技術研究院于2012年設立了“重大風險源測控四川省重點實驗室”，從礦山露天頭頂風險源入手，集成高分衛星、三維激光、地下物探三項技術優勢，構建了“天空、地表、地下”（三界）多元數據診斷體系，創立了“診斷―分析―設計―治理”（DADT）循環管控模式（見圖1），實現了危險源定量化的預測、預警、預防之科學管控目標，全面提升了安全監管監察能力和信息化管控的水平。
全壽命周期的數字化管控
礦山、危化及交通運輸等領域普遍存在危險源分布廣、點位多、誘發因素復雜及人力難以遍及等共同特點，三界測控技術的處理能力為我們提供了湫碌募際跏侄巍T諢袢〖喙芏韻蠹負緯〖骯丶狀態參數的基礎上，有針對性地分析并研判風險演化規律，及時制定合理的化解、防范和治理措施。
概括而言，就是通過太空高分衛星周期性獲取區域總體數據（m級分辨率）篩查風險，掌握域內風險演變；運用地表三維激光掃描技術，針對已發現并確定的風險實施精準測控（精度mm級），掌握風險具體部位、規模、趨勢和系統關聯；需要時再運用地下地球物理探測技術（m級分辨率），透過現象看本質，由表及里研判風險誘因（見圖2）。
據此，建立由太空、地表、地下“三界”空間測控方法相融合的重大風險源“健康檔案”，持續開展穩態數據與實時（或周期性）監測數據智能比對，實現全過程精細化管控，并進行精準預報、預警，針對性地開展防災減災設計與綜合治理，構建DADT循環管控工作體系，為科學決策和應急處置提供全面的、可靠的數據支持。
篇7
>> 用戶數據素養教育視角下的圖書館科學數據管理研究 高校圖書館科研數據管理研究 大數據時代的高校圖書館數據管理研究 元數據在數字圖書館中的應用 國外高校圖書館科學數據的元數據服務研究 元數據在高校圖書館特色數據庫建設中的應用與實踐 淺談圖書館元數據的應用 美國高校圖書館的研究數據管理服務體系構建及策略研究 加州數字圖書館數據管理計劃工具研究及思考 試論高校圖書館數據管理體系的構建 基于元數據倉儲的圖書館信息資源管理研究 元數據及其在數字圖書館中的應用 醫院圖書館中文圖書數據庫管理系統的應用與實踐 數據挖掘在圖書館管理上的應用 圖書館信息管理中元數據的應用 大數據在圖書館的應用研究 我國大數據技術應用于圖書館的實踐研究 數據挖掘技術在圖書館中的應用 基于數據生命周期的圖書館科學數據服務研究 元數據管理系統的研究與實現 常見問題解答 當前所在位置：.
[12]Data Management Planning[EB/OL].[2014-07-20]..
[13]Khan H， Caruso B， Corson-Rikert J， et al. DataStaR： Using the semantic web approach for data curation[J]. International Journal of Digital Curation，2011，6（2）： 209-221.
[14]Steinhart G. DataStaR： an institutional approach to research data curation[J]. IASSIST Quarterly， 2007， 31（3-4）：34-39.
[15]Bermudez L， Piasecki M. Metadata community profiles for the semantic web[J]. Geoinformatica，2006，10（2）： 159-176.
[16]Lowe B. Datastar： Bridging XML and OWL in science metadata management[M]. // Metadata and Semantic Research. Springer Berlin Heidelberg，2009：141-150.
[17]張曉林. 機構知識庫的發展趨勢與挑戰[J]. 現代圖書情報技術， 2014， 30（2）： 1-7.
[18]Dearborn C C， Barton A J， Harmeyer N A. The Purdue University Research Repository： HUBzero customization for dataset publication and digital preservation[J]. OCLC Systems & Services， 2014， 30（1）： 15-27.
[19]殷沈琴，張計龍，張瑩，等. 社會科學數據管理服務平臺系統選型研究――以復旦大學社會科學數據平臺為例[J].圖書情報工作，2013，57（19）：92-96.
[20]DataONE[EB/OL].[2014-07-19]..
[29]Keralis S D C. Data curation education： A snapshot[J]. L. Jahnke， A. Asher， & SDC Keralis. The problem of data， 2012： 32-43.
篇8
關鍵詞：網刊系統；元數據；中國知網；VB；自動提取
中圖分類號：TP391 文獻標識碼：A 文章編號：1009-3044（2016）09-0090-03
在國內，絕大部分讀者是從期刊網站獲取期刊全文，進而進行引用的。因此，期刊建立自己的官方網站，為讀者提供論文檢索、數據核對、實現在線出版，對擴大期刊的影響力和傳播力至關重要[1]。網刊系統為期刊建立一個實現現刊和過刊的瀏覽、查詢等功能的網刊數據提供了技術平臺[2-3]。以此為基礎，建設期刊自己的網站時，需要對期刊數據進行網刊，對于一般編輯部來說，歷史期刊，有的只是紙質的，需要對歷史期刊電子化，轉化為電子版的期刊還需要進一步進行元數據的提取工作[4-8]。
一般來說，各個編輯部在網刊工作中都是采用手工粘貼拷貝的方式。這種方式不僅工作量很大，而且數據質量很低。另外，由于手工制作的工作量[9]，導致了網站建設要么耗時很長、要么需要大量人力或物力。因此本文基于對象的VB語言編程軟件，編寫了能夠批量提取元數據的程序，采用模式識別智能算法[10-11]，從大型數據庫[12]提供的信息中準確提取本期所有文章的元數據，并形成可直接到網刊系統上的Excel文件，大幅度提高工作效率。
5 結束語
在期刊數字化的工作中，對于很多新建網站的雜志社來說，有兩部分工作：最新1期的元數據提取；歷史期刊的元數據提取。對于很多期刊來說歷史期刊的數據都已經不全了，因此通過大型數據庫來完善網站的過刊數據成為比較可行的途徑之一。通過本文實現的程序可以對1年的過刊數據甚至幾十年的過刊數據一次性進行提取操作，工作效率大幅提升。
但是中國知網上的數據更新比雜志社期刊出版要延時約2個月，而且網刊系統中要求有的元數據有32項，而中國知網提供的僅有12項，所以本文方法并不適合使用在最新一期的元數據提取工作上。下一步工作重點研究對最新一期的排版數據進行元數據的提取上。
參考文獻：
[1] 閆蓓，嚴謹，肖宏.搭建科學與大眾的橋梁：談科技期刊與大眾媒體的新聞報道合作實踐[J].編輯學報， 2009，21（4）： 325-327
[2] 吉玉珠，胡兵.我國學術期刊數字化建設的分析與思考[J].圖書與情報，2003（3）：33-35.
[3] 張科，王景發.期刊網絡采編系統研發及系統功能分析[J].自動化數字化網絡化，2008（4）：72-76.
[4] 洪鷗，姜春明，陳海清.上海市高校科技期刊數字出版現狀及分析[J].學報編輯論叢，2011：172-176.
[5] 丁巖，吳惠勤，龍秀芬等.科技期刊數字化出版轉型初探[J]. 編輯學報， 2011， 23 （sup1）：3-6.
[6] 林有興.關于促進科技期刊高效傳播科技信息的思考[J].編輯學報， 2005，17（3）： 165-166.
[7] 鄭筱梅， 楊小玲. 期刊網絡化趨勢及科技期刊應對策略[J]. 編輯學報， 2009，21（1）： 64-66.
[8] 孫遠，朱曉紅，喻偉.網絡環境下科技期刊數字化建設初探[J]. 人民長江，2009，40（4）：102-103.
[9] 洪鷗，姜春明，王寧.高校學報自然科學版網絡出版現狀[J].調查與思考，2014，25（7）：895-901.
[10] 劉曉華.非計算機專業VB程序設計教學探討[J]. 創新教育，2011（38）：135-137.
篇9
1.1國際范圍內元數據標準頒布情況
作為描述文件（records）背景、內容、結構及其管理過程的數據，元數據（metadata）對于文件（包括檔案）管理的重要性已經獲得了廣泛的認同。上個世紀末以來，澳大利亞［1］、英國［2］、加拿大［3］等國家紛紛推出了不同適用范圍、使用目的的文件管理元數據標準；而相關國際標準的頒布，與各國、地方的標準形成良性的互動，［4］推動元數據標準不斷走向成熟。ISO14721:2003《空間數據與信息移交系統———開放檔案信息系統（OAIS）參考模型》的，引發了數字保存（digitalpreservation）領域基于OAIS的信息模型開發元數據方案的熱潮。在文件管理元數據（recordkeepingmetadata，recordsman－agementmetadata）標準缺失的情況下，也有一些檔案部門據此模型開展了元數據標準的探索和實踐。［5］ISO23081-1:2006《信息與文獻———文件管理流程———文件元數據———原則》和ISO/TR23081-2:2007《信息與文獻———文件管理流程———文件元數據———概念與實施》［6］則開辟了面向文件形成機構文件管理元數據標準的疆土，其提出的多實體、多屬性的元數據框架結構，則被此后很多國家、地區、單位制定的文件管理元數據標準、方案所采納。文件管理元數據和長期保存元數據的區別和聯系也日益為大家所重視。［7］ISO/TR23081-3：2011《信息與文獻———文件管理流程———文件元數據———自我評價方法》則進一步明確了評價現有文件管理元數據的方法。國際上對于文件管理元數據的探索焦點從原則、概念逐步走向實施、應用。
1.2我國電子文件元數據標準的建設
2002年底，青島市檔案局頒布的規范性文件《青島市電子文件歸檔與管理規范（試行）》以“附錄A電子文件著錄項目”的方式規定了電子文件的元數據項目；2005年底，天津市檔案局制定了《天津市電子公文元數據表》；2008年3月，我國核行業標準《核電電子文件元數據》（EJ/T1224-2008）頒布；同年7月，廣州市地方技術規范《電子文件檔案資源管理規范第4部分：元數據》（DBJ440100/T10.4—2008）出臺；2009年底，檔案行業標準《文書類電子文件元數據方案》（DA/T46-2009）問世；2011年1月，ISO23081-1《信息與文獻———文件管理流程———文件元數據———原則》被正式采納為國家標準，標準號為GB/T26163.1-2010；國家檔案局承擔的國家標準《通用電子文件元數據規范》研究項目正在推進過程中，建設、石油等行業的電子文件元數據標準正在醞釀出臺。這些行動標志著我國電子文件的元數據管理從自由探索步入了標準引導、從地方規范和行業規范走向國家規范的發展階段，且標準的內容和形式也不斷與國際標準接軌。［8］
1.3元數據標準的實施問題
隨著諸多標準規范的出臺，文件形成單位和保存單位如何貫徹實施有關標準，在相關系統中產生、管理和利用元數據，日益成為關系到系統建設質量乃至最終文件管理狀況的關鍵。本文所指元數據方案（metadataschema），是文件形成單位或保存單位對電子文件元數據元素語義、語法、賦值及其相互關系（結構）的系統性規定。本文根據電子文件元數據形成和積累的規律，結合杭州市電子文件中心建設的實例，圍繞著一類單位———文件形成單位在建設一類系統———電子文件管理系統（ElectronicRecordsManagementSystem，ERMS）過程中的元數據方案設計問題展開探討。
2電子文件元數據形成、積累的規律
電子文件的元數據隨著文件形成和管理過程而不斷產生、累積，而這樣的產生、累積是要通過系統實現的。探究元數據形成、積累的規律，首先要辨析電子文件生命周期中的系統類型。
2.1電子文件生命周期中的系統類型
從系統的功能來看，電子文件整個生命周期中的系統通常包括三類：［9］支持文件形成單位日常業務工作的開展，在此過程中形成合格、完整的電子文件的“業務系統”（BusinessSystem，BS）；［10］從業務系統中將信息以文件的方式加以捕獲、維護、利用和處置的ERMS，捕獲和處置分別是該系統文件管理功能的起點和終點，我們也可以將ERMS理解為立檔單位檔案輔助管理系統在數字世界中的功能拓展；長期保管各類電子文件，保證其真實、準確、可理解的“文件保存系統”（RecordsPreservationSystem），國際上也將此類系統歸入“可信任數字倉儲”（TrustedDigitalRepository，TDR）。
2.2元數據在各類系統中形成、積累的過程
電子文件不同生命階段的元數據依次在BS，ERMS，TDR中形成，前一階段形成的關鍵元數據將隨著文件一起進入下一個系統。但是，不同系統管理文件的目的不同，管理成本亦有限，不可能也不需要將所有的元數據都保留下來。也就是說，電子文件的元數據是動態增加的，但并非所有的元數據都會和文件同步積累、轉移，某些元數據只存在于產生它的系統中，不會進入下一個系統。當一份文件從BS進入ERMS，或者ERMS進入TDR的時候，部分元數據會與之同行，部分則會與之分離，這樣的過程如圖1所示。
2.3電子文件元數據的運動規律
通過圖1可以看出，電子文件元數據的行程好比一條不斷匯聚的河流，沿途會消耗掉一部分水分，同時也不斷有新的河水注入其中。總體來說，這是一個細水長流、日積月累的過程。就在這個平緩向前的過程中，尤其是在ERMS和TDR的運轉過程中，可能因為文件管理的某種需要臨時性地增加元數據。這樣的需要至少包含兩種情況：第一，移交的需要，為便于TDR長期保存文件，ERMS在向TDR移交文件的時候可能需要臨時增加元數據。比如全宗名、全宗號原本只是全宗級的元數據，文件級元數據可不包含此項，在移交時為了讓每份文件具有自我說明的能力，需要給每份文件重復記錄同樣的全宗名、全宗號。再如為TDR制定并實施合理的文件保存規劃，可能需要大量補充電子文件的技術環境元數據，除了文件格式外，還注明軟件產品、版本號、壓縮類型，字符編碼方案、軟件商信息等。第二，利用的需要，為更好地實現信息服務、知識挖掘等，可以通過元數據自動抽取工具臨時挖掘文件的主題信息，并加以標注。應需臨時增加的部分，通常借助特定的插件、工具完成。正如ISO23081-2:2009所言：“優質的元數據體系是動態的，能夠在必要時隨時增加文件管理元數據”。［11］因此，我們認為電子文件元數據具備持續形成、選擇積累、應需增加的特點。
3ERMS元數據方案設計的準備
為設計出適用的元數據方案，除了人員、資金等方面的準備之外，還需要明確ERMS的系統功能定位，了解相關標準及其實施路徑，掌握ERMS元數據方案設計的內容和方法，以便最終逐一確定元數據元素及其規則。
3.1系統功能定位的確定
上述BS，ERMS，TDR只是概念劃分的結果，各單位需要購置的系統既可能與之對應，也可能具備其中一類系統的部分功能，或者其中兩類系統的全部或部分功能，需要根據系統實際的功能定位來制定元數據方案。比如西方國家所稱的ElectronicDocuments&RecordsManagementSystem（EDRMS）即為一類從電子郵件系統、桌面辦公軟件、工作流系統、掃描系統等辦公類系統中捕獲非結構化文檔，并實施集中存儲、統一利用和文件管理（檔案化管理）的系統，有些EDRMS本身也提供工作流、掃描等功能。提供工作流并支持文件形成業務的EDRMS元數據方案，通常要單純的ERMS包含更多的業務類元數據。類似地，如果我國有單位要實現OA系統和檔案管理系統相集成的電子公文一體化管理系統，或者工程項目文檔協作系統和檔案管理系統相集成的項目文件管理系統，也要設計更為豐富的業務類元數據。此外，一些大型企業面臨建設ERMS和TDR的雙重任務，在系統選型的時候，也傾向于將兩者集成在一起，對此類系統的元數據方案，則要在文件管理元數據之余，更多地考慮長期保存元數據。本文以獨立的ERMS實施為假設前提展開討論。
3.2標準環境
任何單位在設計ERMS元數據方案的時候，都要尋求標準的支持。雖然我國已經出臺不少相關元數據標準，不過，標準實施還是面臨兩個方面的困難：
3.2.1標準適用性不夠
早期出臺的電子公文元數據規范在適用范圍上規定得很明確，區分了文件形成單位和文件保存單位的需要，比如《青島市電子文件歸檔與管理規范（試行）》明確指出面向青島市市直機關、團體和其他社會組織等文件形成單位，《天津市電子公文元數據表》分別對電子政務系統歸檔電子文件和檔案室向檔案館移交的電子文件的元數據加以規定，后者比前者多出5個元數據元素，同時還有各自配套的數據結構規范。但是這些標準大多為經驗性總結，缺乏元數據頂層框架的支持，在與文件形成系統的互操作性方面的支持力稍弱。2008年之后出臺的《電子文件檔案資源管理規范第4部分：元數據》（DBJ440100/T10.4—2008）和《文書類電子文件元數據方案》（DA/T46-2009）則分別依據OAIS和ISO23081的概念模型，元數據元素的設計相對嚴謹，但是其內容較全面，同時包含文件管理元數據和長期保存元數據，適用范圍較廣，同時面向文件形成單位和文件保存單位，導致這兩種具有不同文件管理職責的單位，面臨實施同一個標準的境況，這就需要其根據各自的功能目標加以選擇、拓展、改造、具體化的實際問題。
3.2.2標準實施支持力度不夠
從國際范圍的實踐經驗來看，ERMS元數據標準實施路徑有兩種：第一，將系統功能要求標準和元數據標準銜接，通過系統測試的方式強化合規性要求，使得元數據標準由書面的規定變成市場通用軟件內嵌的事實標準。這樣的系統功能要求標準包括：1997年開始頒布、并且每隔5年更新一次美國國防部標準DoD5015.2-STD《文件管理軟件設計標準》，其中具體規定了文件、文件夾的元數據；［12］2002年英國公共文件局推出的《電子文件管理系統功能要求》系列標準，元數據標準是其中第2部分；歐盟《文件系統通用要求》（MoReq）的2008年版本MoReq2，元數據方案是其重要的一個附錄［13］；在MoReq2基礎上推出的改進版本MoReq2010，則將元數據方案和功能要求條款密切融合，即在功能要求條款中明確具體的元數據要求。［14］第二，制定元數據標準的實施指南，指導各單位具體應用。比如加拿大國家圖書與檔案館（LAC）在頒布《加拿大政府文件元數據標準》的同時，頒布了《加拿大政府文件元數據應用方案》，闡明了元數據元素的應用規則和方法。［15］據筆者了解，已經完成起草任務的我國《電子文件管理系統通用功能要求規范》和《通用電子文件元數據規范》以及《文書類電子文件元數據方案》（DA/T46-2009）相對獨立；亦未見有關文件元數據標準的實施指南。作為文件形成單位，應該牢牢立足于文件形成單位ERMS的基本定位及其元數據的構成特點參考既有標準。鑒于ISO23081提出的元數據模型以及實施建議已經成為國際最佳實踐經驗，本文將此標準為基礎展開探討。
3.3ERMS元數據方案設計的技術路線設計
ERMS元數據方案，就是選擇元數據元素并建立其相互關系。根據ISO23081-2:2009的規定，元數據元素的選擇路徑是有基本規律可循的，那就是基于文件、責任主體、業務、法規、關系等五類實體的文件管理元數據模型，依次定義和標識實體及其級次；按照標識、描述、使用、事件計劃、事件歷史、關系等六類屬性的模塊化設計思路，描述實體及其級次所必須的元數據，建立相關實體/級次元數據之間的關系；［16］根據ERMS需要管理的文件的特點，以及系統實施單位業務和文件管理的情況，建立元數據賦值規則（如賦值范圍、賦值格式、賦值方式等），建立元數據管理規則（如存取權限、導出格式）等。一個元數據方案，只有具體定義到每個元數據何時由誰如何產生、修改、利用、刪除的程度，方可實施。本文主要聚焦于實體、實體級次及其相互關系的確定上，這是元數據方案設計的根基。
4實體的確定
4.1基本實體模型
ISO23081：2009確定的元數據模型，包含文件、責任主體、業務、法規、關系等五大實體，如圖2所示，這是ERMS實體實施的頂層框架。［17］其中的業務實體分為形成文件的業務和文件管理業務兩部分，這進一步印證了本文圖1所揭示的元數據形成和積累的過程。區分實體的意義在于準確定位元數據描述的對象，理解構成文件管理整體環境的各要素及其相互關系。通過分實體的元數據描述，有助于實現系統功能的模塊化設計，以及跨系統的互操作。
4.2實體的實施方式
ISO23081標準申明并不要求直接實施五大實體，而是可以采取非常靈活的策略，既可以選取其中的一種或多種實體，也可以在上述五大實體之外，擴展新的實體。實體的實施方式取決于不同實體描述保持持續鏈接的能力，也和系統功能的實現方式有關。具體說來，主要包括以下幾種實施方式：
4.2.1單實體實施
采用以“文件為中心”的實施方式“簡化”實體模型，即在文件實體中包含了其它實體的信息。早期時候出臺的元數據標準多采用這種模式，如1999年1.0版的澳大利亞聯邦政府機關文件保管元數據標準。早期的檔案輔助管理系統也多采用這種實施方式。
4.2.2多實體直接實施
在文件、責任主體、業務、法規、關系實體中選擇2-5種實體實施。比如我國《文書類電子文件元數據方案》（DA/T46-2009）采用了文件、責任主體、業務和關系4類實體；MoReq2將文件保管期限與處置表理解為特定的法規標準，采用了文件、文件保管期限與處置表（法規標準）、責任主體三類實體，而業務、關系實體則作為其他實體的屬性。［18］
4.2.3多實體擴展實施
即除了文件、責任主體、業務、法規、關系這五大實體之外，還拓展應用其他實體類型。文件、責任主體、業務、法規這四個實體都是多層級的，每個層級都可能包括標識、描述、使用、事件計劃、事件歷史、關系等六個方面的屬性元數據，而且實體的元數據本身還要靠元數據來描述，如此形成多實體、多層次、多屬性的循環、關聯，由此可以將實體層級、屬性、元數據定義等也作為實體來實施。MoReq2010是多實體擴展實施的典范，其規定已經細致到可以在系統中直接應用的程度。MoReq2010共定義了文件聚合（aggregation）、類（class）、組件（component）、背景元數據元素定義（ContextualMetadataElementDefinition）、處置保留（DisposalHold）、保管期限與處置表（DisposalSchedule）、實體類型（EntityType）、事件（Event）、功能定義（FunctionDefinition）、組（Group）、元數據元素定義（MetadataElementDefinition）、文件（Record）、角色（Role）、服務（Service）、模板（Tem－plate）、用戶（User）共16個實體類型。［19］這16個實體類型大致可以分為六類，如表1所示。其中聚合、類別、文件、組件屬于文件實體的不同層級，處置保留、保管期限與處置表屬于法規標準實體的三個具體類型，組、角色、用戶屬于責任主體實體的不同層級；其余8個實體類型分別從屬性、元數據定義（元數據的元數據）、系統這三個角度作的拓展：事件乃屬性元數據實體，背景元數據元素定義、元數據元素定義、模板、實體類型屬于元數據定義實體，而功能定義、服務這兩個實體類型屬于ERMS系統本身的元數據。
4.3杭州市電子文件中心
ERMS的元數據實體杭州市電子文件中心項目是由杭州市檔案局承擔的系統建設項目，其主要任務是為杭州市黨政機關統一建設ERMS，即在全市范圍統一采購、部署和維護ERMS，杭州市檔案局為各ERMS使用單位提供基礎設施、系統平臺和應用軟件的服務，但不代替其完成本單位內部的文件管理業務。這也是我國地方政府電子文件中心建設的一種新定位，不同于永久保管文件、文件中轉站、現行文件查詢服務、文件備份等其他各地電子文件中心的功能定位。［20］該項目計劃分四期開展，一期已經于2010年完成，實現了杭州市政府機關統一使用的辦公自動化系統（OA）的元數據改造，使其產生合乎文件管理要求的元數據；二期于2011年10月完成，完成了ERMS的選型、研發和試點，可以接收管理OA中的電子文件；三、四期的建設將逐步擴大ERMS的使用范圍，逐步和其他系統銜接，以捕獲更多類型的電子文件。本文簡單介紹二期項目設計完成的元數據方案。杭州市電子文件中心ERMS的元數據方案采用多實體實施模式，包含文件、責任主體、文件形成業務、保管與處置、權限管理五大實體。其中保管與處置、權限管理屬于法規標準類的實體。文件實體處于核心地位，與其他實體相互鏈接。關系實體作為文件實體的屬性加以實施。本項目并未采用完整的業務實體，僅將文件形成業務作為一個實體，這跟整個系統的實施方式有關。描述文件形成業務，即收發文處理過程的業務元數據，并非在ERMS中產生，而是在OA中產生、被ERMS接收管理。這些元數據在OA中被固化為一個XML文檔，作為文件的有機組成（可以視為文件的一個特殊的組件———筆者注）隨同文件內容一起進入ERMS。這個XML文檔相對獨立，目前暫不進入文件元數據庫中，日后若普遍存在查詢文件形成業務數據的需要，可比較方便地將其中元數據導入文件元數據庫中。至于文件進入ERMS之后產生的文件管理業務元數據，則作為文件實體的一個屬性存在，其中大多被包括在“事件歷史元數據”中。本項目借鑒了MoReq2和MoReq2010，將保管與處置作為獨立實體加以實施，系統將將該實體中包含的保管期限、ERMS保存期限、觸發條件、處置行為等元數據作為一組相互關聯的元素加以實施，定義好的保管與處置規則可直接應用在類、案卷或文件上。權限管理實體實施的思路與此類似。
5實體級次的確定
5.1實體的級次
ISO23081的概念模型中，文件、責任主體、法規標準、業務等4個實體都具有多個層次，其中文件實體涉及全宗、系列、案卷、文件等層級，責任主體實體包括機構、部門、工作組、個人等層級，業務實體包括聯合職能、職能、活動、事務等層級，法規標準實體包括法律、政策、業務規則等層級。區分層級的意義在于精確地定義各層次的元數據，同一實體不同層級的元數據，既有相同的部分，也有不同的部分。而對于每個層級都有的元數據，下位層次則可以通過鏈接繼承上位層級實體的元數據，而不一定要全部重復描述，這可以在一定程度上精簡元數據方案及其實施成本。
5.2文件實體級次模型及其實施
文件實體是各種實體實施方式中必備的實體類型，因此在各種層次體系中，文件實體的層級最為關鍵。筆者綜合考察了MoReq2，MoReq2010，I－CAREQ以及我國標準《電子文件管理系統通用功能要求》研究成果中所規定的信息模型，構建了如圖3所示的文件實體級次模型，該模型包括聚合（aggregation）、文件（record）、組件（component）三個層次。聚合是由文件組成的，文件是由組件組成的。這三個級次是任何一個ERMS元數據方案都要描述的對象，缺一不可。
5.2.1聚合
聚合即按照機構職能、業務或者文件的性質形成的文件集合體。在ERMS中，聚合通常表現為文件夾（folder）的形式，也可以表現為文件類型（recordstype）的形式。按照檔案管理的傳統，聚合又可以細分為三個層次：全宗、類目和案卷。其中，全宗（fond）是最高的文件聚合層次，在ERMS中，它表現為根文件夾（rootfolder）。類目（class）一般指全宗下具有有機聯系的文件集合體，在傳統意義上的檔案分類體系中，類目的設定一般比較穩定。類目可以有多級，在ERMS中，可以建立多個父文件夾（parentfolder）和子文件夾（childfolder）；也可以根據多個維度建立不同的類目結構。案卷（file）是最低的文件聚合層次，可以在類目下根據需要靈活地增加案卷。在ERMS元數據方案中，既可以將全宗、類目和案卷設定為聚合（文件夾）這一個級次，也可以區分為全宗（根文件夾）、聚合（子文件夾）這兩個層次，或者保留全宗（根文件夾）、類目（中間層次文件夾）、案卷（最低層次文件夾）這三個級次。一個實體級次的好處是系統設計更為簡單、統一；三個實體級次的好處在于更便于區別化對待不同的聚合層次，比如不同級次聚合的編號規則不同，且與檔案管理傳統有效銜接；兩個實體級次則綜合了一個實體級次和三個實體級次的好處。值得一提的是，在MoReq2010的實體模型中，對等使用了聚合、類兩個實體級次，前者指文件系統中的文件夾，通常是為了文件形成者對文件歸類而設置；后者則是指產生于同一業務活動因而具有相同保管期限的文件集合，通常是為了文件管理員（可以理解為文件形成單位的檔案管理員）鑒定處置文件而設置。在實際單位，聚合和類可能一致，也可能不一致。這樣的設置照顧到了有些單位分類方案和保管期限表不銜接的情況。
5.2.2文件
文件是能夠獨立記錄業務活動過程和結果的信息對象。文件是文件管理業務意義上而非技術意義上的最小單元。在數字環境中，文件本身可以被理解為一個容器，其中可能包含一個或多個組件（component）。包含單個組件的文件為單文件（singlerecord），包含多個組件的情況則又兩種：第一，組成文件的組件之間具有技術上的緊密關聯，如網頁文件中的HTML、CSS、JPEG圖片，或一份嵌入外部音頻、視頻的年度報告等，它們共同構成一份復合文件（compoundrecord）。第二，組成文件的組件之間具有管理意義上的緊密關聯，如請示和批復是兩個相對獨立的文檔，但二者需要組合在一起才能表示一個完整的管理活動，這樣的文件被稱為組合文件（combinedrecord）。只有理解了復合文件和組合文件的存在，我們才能夠充分認識到ERMS管理到組件級次的必要性。
5.2.3組件
組件是計算機系統中一組數字信息流，是技術意義上的最小管理單元，如一個圖片，一個word文檔，數據庫的一個視圖等。識別哪個（些）組件構成一份文件，主要看這個（些）組件能否獨立地反映業務活動。組件可能有兩種表現形式：單組件和復合組件，后者本身是有多個技術上緊密關聯的組件組成。比如就一個問題產生的一問一答兩封電子郵件共同構成一個組合文件，其中一封電子郵件帶著附件，這封郵件及其附件共同構成復合組件。對于以非結構化形式存在的組件，IT領域也稱之為文檔（document）。
5.3杭州市電子文件中心
ERMS的元數據實體級次杭州市電子文件中心ERMS的元數據方案中，文件實體包含全宗、類、案卷、文件、組件五個級次；責任主體實體包含單位、部門、角色、人員四個級次，其中角色是一定數量操作權限的集合，部門可以按需改變，人員也可以流動，而角色是相對穩定的；文件形成業務實體目前只有一個級次，隨著三期、四期ERMS管理對象由OA公文向行政審批系統中業務文件的擴大，該實體的級次可能增加；保管與處置包括保管與處置規范、保管與處置規則兩個級次，前者描述國家檔案局及相關主管部門頒布的有關電子文件保管期限和處置要求的法規規范，后者描述具體的處置規則；權限管理實體只有一個級次。
6元數據的確定
6.1元數據的模塊化設計
確定了實體及其級次之后，需要確定每個實體級次的元數據元素。ISO23081—2：2009推薦采用模塊化設計思路，即每個實體，尤其是文件實體，包含標識、描述、使用、事件計劃、事件歷史、關系等六類元數據，這樣的元數據，被張正強教授稱為“屬性元數據”。［21］可以看出，這樣的設計思路吸收借鑒了戴維?比爾曼提出的“可為業務活動接受的通信的元數據參照模式”的成果，該模式將文件管理元數據分為登記、期限和條件、結構、背景、內容、利用史六個層次。［22］
6.2屬性元數據的實施
具體的ERMS項目，可根據六類屬性元數據模型靈活變通，設計出可在系統中實施的元數據。比如MoReq2010將實體的屬性信息區分為元數據、事件歷史、權限控制列表三類，如圖4所示。其實這三類信息都是元數據，只不過因為事件歷史、權限控制列表（使用類屬元數據）這兩類元數據非常重要，MoReq將之凸顯出來。因為實體是有級次的，故需要根據實體及其級次的特點，選擇實施上述六類元數據的部分或全部。對于文件實體而言，這六類屬性元數據都是必須的，但是實施的方式有別，不同級次同類屬性元數據包含的具體元素亦有別。下面分別闡述文件實體中標識、描述、使用、事件計劃、事件歷史、關系元數據的一般實施要求：
6.2.1標識類元數據
此類元數據用于標識文件實體，是每個文件實體級次都必備的屬性元數據，如全宗號、類號、案卷號、文件號、組件號等。
6.2.2描述類元數據
此類元數據用來描述文件的內容，以方便檢索，是每個文件實體級次都必備的屬性元數據。如全宗名、類名、案卷標題、文件題名、摘要、主題詞等。
6.2.3使用類元數據
此類元數據用來描述和文件利用、權限有關的信息，至少可以細分為三類：技術環境、秘密程度、訪問權限等。技術環境元數據描述文件的軟件、硬件、格式等方面的信息，如存儲格式信息、計算機文件名、計算機文件大小、完整性等。秘密程度元數據用來標識文件實體內容的保密要求，如密級、開放等級等。訪問權限元數據用來記錄文件利用的詳細信息，一般要定義何文件能夠由誰執行什么操作，通常由一組相互關聯的元數據組成。雖然都屬于使用類元數據，但是技術環境、秘密程度、訪問權限這三類元數據的實施層次及其方式有所區別。技術環境元數據需要在最低文件實體級次———組件上精確定義，只有組件才是ERMS切實管理的內容對象，才具備存儲格式信息、完整性等屬性信息。其他高層次的文件實體級次則并沒有此類屬性信息。秘密程度元數據需要在文件、聚合級別實施，下級實體可繼承上級實體的秘密程度元數據，原則上組件不具備獨立的秘密程度元數據，雖然讓同一文件的不同組件具備不同的秘密程度在信息系統中毫無問題，但是這樣設置會增加管理的復雜度。訪問權限元數據可在各個文件級次上都要實施，下級實體可繼承上級實體的訪問權限元數據，不過在組件級別上定義的情況較為罕見。也可以將訪問權限元數據單獨作為一個實體來實施，與文件實體進行鏈接。
6.2.計劃類元數據
此類元數據用來描述文件進入ERMS后將要發生的管理行為，體現了對于電子文件管理過程的事前計劃和控制，比較典型的事件包括創建、捕獲、處置、調整開放程度、調整密級等。這類元數據通常包括事件時間、類型、描述等一組相互關聯的元數據，可能由ERMS根據其他元數據自動產生，比如某類文件的處置計劃元數據可以根據其應用的“保管期限與處置”規則自動產生。事件計劃類元數據是傳統檔案輔助管理軟件相對缺失的部分。
6.2.5事件歷史類元數據
此類元數據用來描述ERMS已經發生了的管理行為，通常即執行了的事件計劃。通過對電子文件管理過程的同步記錄，可以支持對于ERMS管理過程的事后監督和審計。事件歷史類元數據也由ERMS自動記錄。6.2.6關系類元數據雖然關系也可以作為單獨的實體來實施，不過目前大部分的ERMS規范和項目都是將關系作為文件實體的屬性。
6.3杭州市電子文件中心
ERMS的文件實體元數據除了將使用類元數據中的訪問權限元數據單獨作為一個實體之外，杭州市電子文件中心ERMS的文件實體元數據包括其他所有屬性元數據。此外，在設計文件實體的元數據時，還需要注意處理不同文件類型、組件類型的元數據設置問題。所謂文件類型，是指根據業務活動的需要，對若干具有共性的文件的抽象表示。文件類型可以為一個單位的分類方案所直接體現，也可能無法在分類方案中直接體現。典型的文件類型如發文、合同、工程圖紙、發票、訂單等，不同的文件類型在文件級次往往具備一些不同的元數據，如合同的發文的簽發者，合同的甲方、乙方、合同金額等。對于這種情況，本項目設置了一個通用的文件級次元數據集，未來隨著ERMS管理范圍的拓展，將在此基礎上再逐一明確各文件類型個性化的元數據。除了多文件類型外，ERMS還要管理不同類型的組件（即計算機意義上的文件），一般根據技術屬性劃分組件類型，比如文本、圖片、音頻、視頻等，不同類型的組件的技術環境元數據（可能還包括其他屬性元數據）并不相同，這類元數據也被黃玉明局長稱為“編碼元數據”或“技術元數據”，國內外也有很多標準支持。［23］對于這種情況，仍然可以借鑒對于不同文件類型元數據的處理方法，即先設置一個通用的組件級次元數據集，在此基礎上再逐一明確各媒體類型組件個性化的元數據。
7小結
篇10
關鍵詞：元數據；異構數據庫；醫療共享信息；查詢系統
中圖分類號：TP311 文獻標識碼：A 文章編號：1006-1959（2017）14-0012-02
隨著醫療行業信息化建設推進，各大城市中心醫院逐步建立起較成熟的HIS、LIS、PACS、RIS等信息系統。這些系統多為不同的業務系統，都是由不同廠家開發的獨立系統，使用的數據庫產品不同，具有異構性，而且數據庫設計也不同，具有數據異構性，導致同一行政區域的不同醫院、不同系統之間數據和資源不能有效共享，醫療數據利用低。通過元數據技術將不同業務系統資源有機整合，以滿足對醫療信息共享的需求。
1 元數據概述
元數據是“描述數據的數據”，或者“關于數據的結構化數據”。元數據是用來描述數據本身的內容特征和其它特征的數據[1]。元數據的目標主要有兩個方面：①簡單高效的描述、保存、組織和管理大量信息資源；②使信息資源的檢索、發現、定位和共享更加便利與高效[2]。元數據的基本結構由內容結構、句法結構和語義結構組成。內容結構用于定義元數據的構成元素；句法結構用于定義元數據的格式結構以及如何描述這種結構；語義結構用于定義元素的具體描述方法。
元數據是醫療信息資源組織和處理的基本工具，它為各種形態的醫療數字資源提供了規范、普遍的描述方法，元數據整合中開放描述和互操作性已成為一個基本要求[3]。
2 醫療共享信息查詢系統模型
醫院的信息系統存在大量異構的數據庫，異構性表現在多個方面，如使用不同的數據庫產品、數據庫表的設計不同、存儲的數據類型不同、運行環境不同等。使用元數據技術對異構數據庫進行統一規范描述，實現共享訪問這些異構數據庫的數據。用戶通過統一的元數據查詢語句完成查詢操作，實現數據的透明訪問，同時保持了本地數據庫的自治性。
區域醫療共享信息查詢系統（MQS），采用B/S三層架構，即系統由表現層、業務邏輯層、數據層組成，見圖1。
表F層為該查詢系統的用戶查詢接口，提供統一查詢界面和顯示查詢結果。業務邏輯層完成查詢請求的處理和查詢結果封裝，該層由元數據管理模塊、轉換器、包裝器組成。元數據管理模塊是系統核心部分，本系統的元數據包括全局數據字典、局部數據字典信息組成，描述最小顆粒為各數據表的字段，并創建描述字段統一的詞匯表，以解決數據異構問題。全局數據字典包括查詢關鍵字與局部數據庫基本表的映射關系。局部數據字典包括數據庫產品名稱、訪問地址和帳號等信息，以解決異構分布問題。轉換器將全局數據庫元數據查詢邏輯語句進行分解轉換，轉換為不同異構數據庫的查詢子語句。包裝器將各個數據庫的查詢結果進行集成處理。數據層是由異構數據庫組成，保存大量的醫療數據信息。
數據查詢流程如下：用戶提交查詢請求，轉換器從元數據管理模塊獲取數據庫映射關系和元數據信息，將用戶提交的元數據邏輯查詢語句轉換成各異構數據庫的查詢語句并發送給相應的數據庫執行。查詢的結果通過包裝器進行合并過濾處理并返回給顯示界面。
3 系統實現的相關技術
XML技術。可擴展標記語言（XML）是在1998 年由萬維網聯盟制定的一種源標注語言，主要是為了解決超文本標記語言（HTML） 無法滿足越來越多的網絡數據交換的需求[4]。使用XML技術可以方便地為數據定義或擴展自定義的描述術語以及這些術語間的結構化關系，良好的自描述性和跨平臺特點使其成為元數據非常理想的描述語言。 MQS以查詢數據為中心使用XML對系統的全局字典進行描述，部分代碼如下：
以上XML代碼實現查詢關鍵字“患者姓名”跟數據庫的映射，其中屬性dbname為異構數據庫的名稱，tbname表示表的名稱，colname表示字段名稱，type表示該字段的類型。
DOM文檔對象模型是W3C組織推薦的處理可擴展標志語言的標準編程接口[5]。MQS系統使用DOM技術根據用戶提交的查詢關鍵字讀取解析XML文檔，獲取異構數據庫的元數據信息，再結合局部數據字典元數據生成相應的不同SQL查詢語句并執行得到結果。
JSP+Servlet+JavaBean技術。JSP 技術是新一代的腳本技術，能夠幫助網頁設計和開發人員簡單且高效的進行動態網頁的開發[6]，JSP動態網頁技術實現MQS與用戶的交互界面，用于用戶查詢請求的提交和查詢結果的顯示，Servlet服務器端程序負責查詢請求的任務分發，JavaBean完成業務邏輯處理，包括訪問數據庫和查詢結果的封裝。
4 總結
本文提出了一種基于元數據的醫療共享信息查詢系統（MQS）解決數據源的異構問題，用戶可以通過系統的統一用戶接口進行查詢，并且從技術的角度分析了系統功能實現的可行性。但并未對異構數據庫的元數據提取進行深入探討，有待進一步完善。
參考文獻：
[1]李小濤，胡曉惠，郭曉利.基于元數據的復雜信息共享技術[J].系統工程與電子技術，2015，37（3）：700-706.
[2]趙華，王健.國內外科學數據元數據標準及內容分析[J].情報探索，2015（2）：21-24.
[3]李萍.醫療數據質量的問題探索和解決模式[J].計算機應用與軟件，2013，30（8）：217-219
[4]楊旋，朱辰，周小甲，等.基于XML的醫院信息集成平臺的研究與應用[J].醫院數字化，2016， 31（12）：82-85.
