元數據

         1：進入元數據

元數據是什麼意思？元數據如何理解？元數據的做用是什麼？大數據時代，何處安放咱們的元數據？本文將圍繞這些問題來探討。

　　元數據概述

　　元數據（Metadata），又稱中介數據、中繼數據，爲描述數據的數據（data about data），主要是描述數據屬性（property）的信息，用來支持如指示存儲位置、歷史數據、資源查找、文件記錄等功能。元數據算是一種電子式目錄，爲了達到編制目錄的目的，必須在描述並收藏數據的內容或特點，進而達成協助數據檢索的目的。都柏林核心集（Dublin Core Metadata Initiative，DCMI）是元數據的一種應用，是1995年2月由國際圖書館電腦中心（OCLC）和美國國家超級計算應用中心（National Center for Supercomputing Applications，NCSA）所聯合贊助的研討會，在邀請52位來自圖書館員、電腦專家，共同制定規格，建立一套描述網絡上電子文件之特徵。

　　元數據定義 

　　元數據被定義爲：描述數據的數據，對數據及信息資源的描述性信息。

　　元數據（Metadata）是描述其它數據的數據（data about other data），或者說是用於提供某種資源的有關信息的結構數據（structured data）。元數據是描述信息資源或數據等對象的數據，其使用目的在於：識別資源；評價資源；追蹤資源在使用過程當中的變化；實現簡單高效地管理大量網絡化數據；實現信息資源的有效發現、查找、一體化組織和對使用資源的有效管理。 元數據的基本特色主要有：

　　a）元數據一經創建，即可共享。元數據的結構和完整性依賴於信息資源的價值和使用環境；元數據的開發與利用環境每每是一個變化的分佈式環境；任何一種格式都不可能徹底知足不一樣團體的不一樣須要；

　　b）元數據首先是一種編碼體系。元數據是用來描述數字化信息資源，特別是網絡信息資源的編碼體系，這致使了元數據和傳統數據編碼體系的根本區別；元數據的最爲重要的特徵和功能是爲數字化信息資源創建一種機器可理解框架。

　　元數據體系構建了電子政務的邏輯框架和基本模型,從而決定了電子政務的功能特徵、運行模式和系統運行的整體性能。電子政務的運做都基於元數據來實現。其主要做用有：描述功能、整合功能、控制功能和代理功能。

　　因爲元數據也是數據，所以能夠用相似數據的方法在數據庫中進行存儲和獲取。若是提供數據元的組織同時提供描述數據元的元數據，將會使數據元的使用變得準確而高效。用戶在使用數據時能夠首先查看其元數據以便可以獲取本身所需的信息。

　　元數據的做用

　　元數據(MetaData)是MDA中很是重要的概念。它經過統一的、平臺無關的、規範的方式對數據的模式特徵進行描述，經過一個模型結構來表達通用的信息，它集設計模型、開發模型與運行模型爲一體。元數據具備以下幾個做用。

　　(1) 元數據是獨立於平臺的，不管使用什麼技術平臺，元數據自己是不受影響的，這保證了先期工做成果的效用最大化。

　　(2) 元數據是生成平臺相關模型的基礎，可使用代碼生成器等工具將元數據轉換成平臺相關代碼。

　　(3) 元數據爲運行時系統提供了統一的可讀的系統模型，系統運行時可使得實體對象經過運行時元數據模型來得知自身的結構、自身的特徵、在系統模型中的位置以及與其餘對象之間的關係等。這樣就能夠從一個新的角度來觀察、設計、開發系統。

　　(4) 元數據模型是系統運行不可或缺的部分，若是直接修改平臺相關代碼而不修改元數據，就會形成系統運行異常，這就強迫保證元數據模型與代碼同步，保證了設計模型和實現代碼的一致性。

　　(5) 元數據自己就是一個設計模型。系統設計人員可使用元數據進行系統建模，在某種程度上元數據能夠取代UML圖等傳統的設計模型。設計人員將設計完成的元數 據模型交給開發人員，開發人員使用代碼生成器將元數據轉換成平臺相關代碼，而後就能夠基於這些平臺相關代碼進行開發了。元數據起到了設計人員和開發人員溝 通橋樑的做用，設計人員的工做當即就能夠轉換爲能夠運行的平臺相關代碼。

　　元數據設計的基本原則

　　除了上邊提到的運行時的元數據中必定不能包含平臺相 關特性以外，在元數據的設計中，「適可而止」也是須要銘記在心的核心原則。對元數據描述的範圍要適可而止，不要試圖一應俱全。運行時元數據是可以給運行時 的系統提供元數據的信息的，這在必定程度上簡化了系統的開發，可是切不可把應該寫在代碼中或者寫到配置文件中的信息寫到元數據中。好比在實體對象元數據 中，給字段增長了「allowNull」特性來表示此字段是否容許爲空。

　　系統保存實體對象的時候，能夠讀取此實體對象對應的元數據，進而取得全部字段的是 否爲空的特性，從而對數據進行校驗。這是對運行時元數據很是合理的運用。可是若是試圖把字段爲空時提示什麼樣的信息、字段最大長度是多少、字段是否進行加 密操做等特性加入元數據的話就會使得元數據模型過於龐大，這也違反了「適可而止」這一基本原則。若是元數據直接驅動系統的運行過程，而且有取代程序代碼的 趨勢的話，就說明設計人員對元數據概念理解錯誤了，用元數據驅動系統運行雖然減小了代碼的編寫，可是這些本不該該放在元數據中的特性是不完備的，一旦須要 擴展就會遇到難以逾越的鴻溝。

　　因爲客戶需求的複雜性，模型結構不能表達出全部業務的處理過程，仍然存在須要利用編程語言才能完成的業務功能。元數據模型解決大多數通用的問題，而對於具備差別性的問題仍是要經過編碼來完成的，不該該讓運行時元數據承擔過多的運行時語義。

　　元數據（MetaData）如何理解

　　元數據是用來描述數據的數據（Data that describes other data）。單單這樣說，不太好理解，我來舉個例子。

　　下面是契訶夫的小說《套中人》中的一段，描寫一個叫作瓦蓮卡的女子：

　　（她）年紀已經不輕，三十歲上下，個子高挑，身材勻稱，黑黑的眉毛，紅紅的臉蛋－－一句話，不是姑娘，而是果凍，她那樣活躍，吵吵嚷嚷，不停地哼着小俄羅斯的抒情歌曲，高聲大笑，動不動就發出一連串響亮的笑聲：哈，哈，哈！

　　這段話裏提供了這樣幾個信息：年齡（三十歲上下）、身高（個子高挑）、相貌（身材勻稱，黑黑的眉毛，紅紅的臉蛋）、性格（活躍，吵吵嚷嚷，不停地哼着小俄羅斯的抒情歌曲，高聲大笑）。有了這些信息，咱們就能夠大體想像出瓦蓮卡是個什麼樣的人。推而廣之，只要提供這幾類的信息，咱們也能夠推測出其餘人的樣子。

　　這個例子中的"年齡"、"身高"、"相貌"、"性格"，就是元數據，由於它們是用來描述具體數據/信息的數據/信息。

　　固然，這幾個元數據用來刻畫我的情況還不夠精確。咱們每一個人從小到大，都填過《我的狀況登記表》之類的東西吧，其中包括姓名、性別、民族、政治面貌、一寸照片、學歷、職稱等等......這一套元數據纔算比較完備。

　　在平常生活中，元數據無所不在。有一類事物，就能夠定義一套元數據。

　　喜歡拍攝數碼照片的朋友應該知道，每張數碼照片都包含EXIF信息。它就是一種用來描述數碼圖片的元數據。按照Exif 2.1標準，其中主要包含這樣一些信息：

　　Image Description 圖像描述、來源. 指生成圖像的工具

　　Artist 做者 有些相機能夠輸入使用者的名字

　　Make 生產者 指產品生產廠家

　　Model 型號 指設備型號

　　Orientation方向 有的相機支持，有的不支持

　　XResolution/YResolution X/Y方向分辨率 本欄目已有專門條目解釋此問題。

　　ResolutionUnit分辨率單位 通常爲PPI

　　Software軟件 顯示固件Firmware版本

　　DateTime日期和時間

　　YCbCrPositioning 色相定位

    

　　再舉一個例子。在電影數據庫IMDB上能夠查到每一部電影的信息。IMDB自己也定義了一套元數據，用來描述每一部電影。下面是它的一級元數據，每一級下面又列出了二級元數據，總共加起來，能夠從100多個方面刻畫一部電影：

　　Cast and Crew（演職人員）、Company Credits（相關公司）、Basic Data（基本狀況）、Plot & Quotes（情節和引語）、Fun Stuff（趣味信息）、Links to Other Sites（外部連接）、Box Office and Business（票房和商業開發）、Technical Info（技術信息）、Literature（書面內容）、Other Data（其餘信息）。

　　元數據最大的好處是，它使信息的描述和分類能夠實現格式化，從而爲機器處理創造了可能。

 

　　MP3音樂元數據

　　你大概常常聽到元數據（metadata）這一律念。它指的是存在於計算機文件中的一種「隱藏」數據，這些數據會用一些特定的識別信息來給某一文件加上「標籤」。例如，你可能在媒體討論中聽過關於元數據在通話數字錄音中的運用。元數據的格式根據文件類型而不一樣。本文關注的重點是音樂文件元數據。

　　音樂元數據，也被稱做MP3文件的ID3標籤，就是歌曲的識別信息，如

　　做曲人

　　表演者

　　歌曲名稱

　　專輯名

　　發行年份

　　音軌編號

　　流派

　　專輯封面

　　歌詞

　　製做人

　　其餘

　　當你上傳音樂至iTunes時，元數據會顯示相應信息，而非只有可怕的「未知藝術家」及「曲目1」。元數據跟MP3的文件名毫無關係，它須要音樂播放器或特定編輯程序進行識別或更改。其重要性有如下幾點：

　　1. 使你本身的名字出如今主要音樂數據庫中，好比Rovi/Allmusic（譯者注：關於音樂的元數據數據庫）以及CDDB/Gracenote（譯者注：音樂網絡數據庫）。這很重要，由於任何一個音樂專業人士都會使用這些數據庫，檢索做品、覈實創做身份及演職人員。

　　2. 若是你打算將本身的音樂應用於影視做品，那麼對版權進行跟蹤是很是重要的，而元數據的做用也就體現於此。看成品的元數據被正確地收錄在發行商的數據庫內，版權費就能夠付到你手裏。有時你可能會發wav文件給出版商，但要知道，這種時候，mp3格式更經常使用，如MusicXRay和TAXI（譯者注：二者均爲音樂人與行業專業人士進行直接互動的音樂平臺）這樣的音樂網站就更傾向於接受mp3文件。

　　3. 若是你要將本身的做品提交給某位樂評人或當地/國際的廣播電臺，那麼不管你選擇經過公關公司、仍是本身直接聯繫，你的電子資料包中都應該包括有攜帶了正確元數據（包括專輯信息）的mp3格式歌曲。

　　一旦你的mp3文件被正確標記，歌曲就能夠上傳到Allmusic或CDDB等音樂數據庫，並與你的名字直接關聯。

　　音樂元數據與MP3 音樂元數據可與音樂文件相關聯，方式有如下兩種：

　　它能夠直接包含於文件自己（mp3 或WMA文件）；

　　它能夠存在於CD（wav文件）中那些與歌曲相關聯的分離文件裏。

　　MP3文件較小，音頻質量不如wav文件。CD製做主要使用的是wav文件。CD的元數據所在位置取決於製做者。除非你是工程師，否則基本上你不會去建立或編輯CD光盤中wav文件的相應元數據。（若是你用iTunes或其餘軟件把CD拷貝到電腦裏，軟件在將其轉化爲MP3文件的時候會自動複製wav文件元數據至相應位置）

　　但因爲MP3文件較小，常應用於向樂評人、電臺或比賽提交做品，故本文涉及的是如何增長或修改mp3文件的元數據，而非wav文件。

　　專輯封面專輯封面小貼士：專輯封面應爲正方形的圖片，格式爲jpeg，分辨率至少爲300 x 300。還有一些常見的分辨率爲340 x 340、375 x 375，甚至600 x 600。在編輯元數據以前，要確保封面大小已調好。在向樂評人或電臺提交做品前，請確認好他們對封面的尺寸要求。

　　使用Windows Explorer、iTunes或GooglePlay來編輯元數據若是你用的是PC電腦，可使用Windows Explorer來編輯ID3元數據。

　　不少人在PC或Mac電腦裏使用iTunes。

　　元數據編碼語言與製做方式

　　1 元數據編碼語言

　　元數據編碼語言（Metadata Encoding Languages）指對元數據元素和結構進行定義和描述的具體語法和語義規則，常稱爲定義描述語言（DDL）。

　　在元數據發展初期人們常使用自定義的記錄語言（例如MARC）或數據庫記錄結構（如ROADS等），但隨着元數據格式的增多和互操做的要求，人們開始採用一些標準化的DDL來描述元數據，例如SGML和XML，其中以XML最有潛力。

　　2 元數據製做方式

　　（1）專門編制模塊（例如對MARC、GILS、FGDC等）

　　（2）數據處理時自動編制（例如對Dublin Core等）

　　（3）數據物理處理時自動編制（例如數字圖像掃描時的某些元數據參數）

　　（4）共享元數據（例如OCLC/CORC、IMESH

　　元數據互操做性

　　1 元數據互操做性問題

　　因爲不一樣的領域（甚至同一領域）每每存在多個元數據格式，當在用不一樣元數據格式描述的資源體系之間進行檢索、資源描述和資源利用時，就存在元數據的互操做性問題（Interoperability）：

　　多個不一樣元數據格式的釋讀、轉換和由多個元數據格式描述的數字化信息資源體系之間的透明檢索。

　　2 元數據格式映射

　　利用特定轉換程序對不一樣元數據元格式進行轉換，稱爲元數據映射（Metadata Mapping/Crosswalking）。

　　已有大量的轉換程序存在，供若干流行元數據格式之間的轉化，例如

　　Dublin Core與USMARC； Dublin Core與EAD

　　Dublin Core與GILS；　GILS與MARC TEI

　　Header與MARC FGDC與MARC

　　也可利用一種中介格式對同一格式框架下的多種元數據格式進行轉換，例如UNIverse項目利用GRS格式進行各類MARC格式和其它記錄格式的轉換。格式映射轉換準確、轉換效率較高。不過，這種方法在面對多種元數據格式並存的開放式環境中的應用效率明顯受到限制。

　　3 標準描述框架

　　解決元數據互操做性的另外一種思路是創建一個標準的資源描述框架，用這個框架來描述全部元數據格式，那麼只要一個系統可以解析這個標準描述框架，就能解讀相應的Metadata格式． 實際上，XML和RDF從不一樣角度起着相似的做用。

　　XML經過其標準的DTD定義方式，容許全部可以解讀XML語句的系統辨識用XML_DTD定義的Metadata格式，從而解決對不一樣格式的釋讀問題。

　　RDF定義了由Resources、Properties和Statements等三種對象組成的基本模型，其中Resources和Properties關係相似於E-R模型，而Statements則對該關係進行具體描述。

　　RDF經過這個抽象的數據模型爲定義和使用元數據創建一個框架，元數據元素可當作其描述的資源的屬性。

　　進一步地，RDF定義了標準Schema，規定了聲明資源類型、聲明相關屬性及其語義的機制，以及定義屬性與其它資源間關係的方法。另外，RDF還規定了利用XML Namespace方法調用已有定義規範的機制。

　　大數據時代 何處安放咱們的元數據？

　　咱們須要收集，歸檔，研究的數據量是很是驚人的，可是若是咱們能巧妙利用元數據，就能快速找到咱們所須要的數據文件。不過，單獨存儲，研究元數據自己就是一個「大數據」問題，其中一個很重要的方面就是咱們要把元數據存儲到哪裏？

　　目前，咱們已經被「瘋狂」的大數據包圍了，整個世界都在適應大數據，咱們要了解如何使用大數據，如何爲大數據設計相應的處理系統，儘管如此，大數據仍然是一片深不可測的海洋。以咱們的生活爲例，在咱們周圍處處都有攝像頭——商店外面，商店裏面，十字路口，直升飛機上，銀行，還有人們的手機上。還有大量的傳感器——在街道上，在汽車裏，在公園裏，在橋上。還有一些特殊行業用的傳感器，好比說電力行業，油氣行業，醫院，網絡服務，網頁，天氣，海洋，軍隊，等等。它們無時無刻不在收集數據。而全部這些數據都有一個共同的地方——它們都須要元數據。

　　元數據是關於數據的數據。舉個例子，元數據能夠包括傳感器位置信息（GPS座標），特定時間的記錄信息，傳感器感應的方向，傳感器的固件以及傳感器的型號等等。

　　在對數據進行後期處理時，你能夠用新獲得的元數據信息給文件標上「標籤「。好比說照相機，能夠用時間來做爲元數據標籤，記錄有趣的事情（或許會和事件自己一塊兒被記錄下來）。還有一些元數據標籤能夠是其它相關的信息資源，好比說其它的照相機型號或天氣數據。

　　從中咱們能夠看出，元數據的使用依賴於其質量。若是元數據不精確，那使用相關的原始數據時就會出現問題，甚至會形成分析失敗。有一些元數據是人爲製造的，不能自動生成，因此會有必定的錯誤率。

　　認識到什麼樣的元數據對特定數據文件很重要，瞭解如何運用它們分析數據，這是很是重要的問題，並且這不只僅涉及到技術解決方案，還有可能涉及到社會學和心理學的解決方案。

　　可是一個看起來很簡單的問題卻對元數據的使用形成重大影響，那就是——咱們要把元數據存儲在什麼地方？

　　何處安放你的數據？

　　在遇到這個問題時，我曾想過兩個方法。第一個是把元數據放到全部數據的中心位置。第二個方法是把元數據和它自己的數據放在一塊兒。

　　許多研究和歸檔系統都採用第一種方法。它很是簡單，就是收集特定文件的元數據並存儲起來。這種方法普遍用於數據庫中，你能夠按照本身的需求搜索數據庫，尋找含有你感興趣信息的文件（在這裏咱們假設元數據是正確的，不然那就是另一回事了）。

　　搜索的結果每每是找到文件的位置（文件全名以及文件訪問路徑），接着你就能夠把文件複製到某些處於活動狀態的存儲設備中再進行進一步的分析。

　　集中元數據這種方法面臨的問題是元數據和文件之間的映射。舉個例子，當各類文件的元數據升級時，你就須要一種更新機制去升級集中元數據的服務器。理想狀態是，升級速度很是快，不然，搜索數據就會過時。可是你怎麼定義「快」呢？這取決於你的用戶和用戶模式。

　　這種更新機制有一個潛在的問題。若是數據庫和文件不一樣步怎麼辦？比方說，當一個文件被移動，它在數據庫中的全路徑再也不有效時怎麼辦？

　　答案很明顯，數據庫也會失效，至少包含那個文件的數據庫會失效。不過使人感到欣慰的是，更新機制會告訴數據庫文件已經移動，數據庫會採起相應的措施，或者爲新的位置建立元數據，或者升級現有的元數據對應文件新的位置。在一些案例中，升級窗口還會影響升級數據庫。

　　還有一點須要注意，就是數據庫自己的數據完整性。你須要利用備份，複製或其它類似的功能來進行數據保護。不要忘了數據庫主要功能是從中讀取數據，這就意味着你須要注意數據庫的大小，注意讀取錯誤。一些廠商會從消費級SATA硬盤中創建索引，當你讀取100GB的數據時，你就有可能遇到讀取錯誤。若是你藉助RAID控制器創建存儲，你就有可能重建，而在重建過程當中，你還有可能遇到新的問題。

　　第二種方法，把元數據和數據存儲在一塊兒。這種方法很可取，由於這樣你就只需擔憂一個文件系統的數據完整性了。若是文件被移動，元數據也隨之移動。你能夠隨時把元數據加入到文件中，由於它就和文件在一塊兒。

　　理想的狀態是，若是咱們有好的工具來和文件一塊兒複製，移動元數據，那咱們就能夠輕鬆地複製或移動數據文件。好比說，你把文件複製到某些活動狀態存儲中，元數據就要和其一塊兒移動。這還意味着你能夠升級這些文件的元數據，而後把它們複製回去，把升級後的元數據和文件放在一塊兒。

　　咱們能夠藉助擴展屬性（擴展文件屬性）來達到這一目的。許多文件系統都支持擴展屬性，爲用戶提供多種選擇，使用戶能夠經過擴展文件屬性把元數據添加到文件中，固然，它們也提供多種文件讀取方式。一些文件系統會對擴展屬性強加限制，好比說加入數量的限制，但並非全部的文件系統都這樣。無論怎麼說，把元數據和數據存儲在一塊兒是一個值得考慮的方法。

　　可是凡事有利就有弊，把元數據和數據存儲在一塊兒也有許多缺點。首先就是用戶如何有效率地搜索元數據？

　　搜索的主要方式是掃描文件系統的樹形結構，找到每一個文件的元數據而後返回信息。可是這種方式要受到文件數量及文件樹形結構的影響，搜索可能會花大量的時間，也許會浪費大量的時間作無用功。

　　若是你想尋找文件，那你就須要搜索全部文件的元數據。不幸的是，目前幾乎沒有使人滿意的工具或技術把文件（包括元數據）複製到其它存儲（或活動狀態的存儲設備）中。舉個例子，NFS不支持擴展文件屬性的傳輸，用戶就不能經過它複製文件或從歸檔轉移到活動位置。有複製文件和元數據的方式，可是你須要花大量的精力確保能達到你預期的效果。

　　更好的方法

　　我我的認爲第二種方法會好一些，由於元數據老是和數據在一塊兒，這樣用戶就能夠隨時訪問元數據。在第一種把元數據集中起來的方法中，除了要保護數據以外，你不得不使用額外的資源來保護數據庫，保證其精確性。考慮到那難以置信的數據量，再加上須要保護的新的歸檔，我如今以爲這兩種方法都不夠完美。

　　既然這樣，那何不把這兩種方法結合起來！

　　我仍然以爲元數據應該和數據存儲在一塊兒，最主要的緣由就是元數據相對於數據而言，自己就是相同的東西，把它們分開沒有多大的意義。

　　不過，掃描含有上億個文件的樹形結構也是不現實的。因此，咱們須要專爲搜索設計的框架，在其中創建一個集中元數據索引，不過全部元數據的功能仍在於文件自己。

　　若是咱們建立了一個歸檔並把全部的數據都放入其中，那咱們就能夠抓取元數據並創建一個集中索引。當文件移動到歸檔中時，咱們能夠把元數據集中在一個文件中。

　　使人欣慰的是，歸檔自己的機制能夠發現歸檔中文件的改變，獲取元數據並升級集中索引。可是，如果歸檔有REST接口，那就沒有好的方式去「升級」文件。若是你從一個歸檔中提取了一個文件並作了更改，大多數狀況下，你都須要把整個文件再放回到歸檔中，由於對於歸檔來講，這是一個「新」文件。有一些歸檔容許用戶升級文件，可是這種機制用起來並不容易，相比之下，提取文件，作更改，再放回去則是很是簡單。在這種狀況下，提取操做要獲取元數據，這使得這一步驟變得簡單。

　　對於全部元數據來講，發揮做用的是文件，元數據只是附加其上（我我的認爲使用的是擴展文件屬性）。若是集中索引由於某些緣由失效了，你要花一些時間掃描文件系統來「從新收集」元數據，可是你並無從根本上失去你的索引。

　　總結

　　人們曾經認爲把元數據存儲在什麼地方這個問題很是簡單，根本用不着進行長時間的討論。直到有一天人們忽然發現，現在的世界已經天翻地覆，大數據呈爆炸式增加，文件數量上億，這時候考慮元數據放到哪裏就變得很是重要，處理好這個問題，對於數據的實際使用有重大意義。

　　把全部元數據放到集中索引是不切實際的，由於這樣你就必須進行大量的數據保護，不只要保護數據，還要保護集中索引。僅僅移動文件位置而不升級索引會對搜索帶來極大的影響。

　　一樣的，藉助擴展文件屬性把元數據和數據放在一塊兒也不可取，由於每次數據搜索都意味着元數據要經過樹形結構被蒐集起來再搜索。雖然把元數據和數據放在一塊兒很是天然，可是這種存儲方式每每會浪費大量的搜索時間。

　　我認爲最好的解決方案是把這兩種方式結合在一塊兒。把元數據放在數據中，當數據被移動到歸檔中時，你就能夠把元數據提取出來，同時創建一個集中索引，用這個索引來進行數據搜索。

　　藉助一個簡單的REST接口，就能夠很輕鬆地升級索引。可是，若是索引丟失或崩潰了，那就須要再次掃描歸檔的樹形結構來從新收集元數據了。