簡介
資源（Resource）：所有在Web上被命名、具有URI(Unified Resource Identifier 統一資源描述符)的東西。如網頁、XML文檔中的元素等；
描述（Decription）：對資源屬性（Property）的一個陳述（Statement），以表明資源的特性或者資源之間的聯繫；
框架（Frameword）：與被描述資源無關的通用模型，以包容和管理資源的多樣性、不一致性和重複性。
綜合起來，RDF就是定義了一種通用的框架，即資源—屬性—值的三元組，一不變應萬變，來描述Web上的各種資源。
一個簡單的RDF的例子：
(指明被描述資源的URI)
Tim Bray （被描述資源有一個叫Author即作者的屬性，其值是Tim Bray）
（被描述資源有一叫Home-Page即主頁的屬性，其值指向另一資源）
（結束標誌）
兩大關鍵技術
RDF有兩大關鍵技術——URI和XML。URI是Web資源的唯一標識，它是更常用的統一資源定位符URL的超集，除了網頁以外，它還可以標識頁面上的元素、書籍、電視等資源，甚至可以標識某一個人。在RDF中，資源無所不在，資源的屬性是資源，屬性的值可以是資源，甚至於一個陳述也可以是資源，也就是說，所有這些都可以用URI標識，可以再用RDF來描述。那RDF怎樣放在網路上讓人使用呢？XML作為一種通用的檔案格式承擔了這個責任，它定義了RDF的表示語法，這樣就可以方便的用XML來交換RDF的數據。
contents.rdf檔案
我們先拋開那些形式上的目錄結構，了解一下最重要的東西。
content，locale，skin 這三個目錄都被稱為包（package），那么什麼是包呢？在 Mozilla 下，包（package）就是一組檔案集合，它的內容和功能就像上面對 content，locale，skin 等目錄描述的那樣。包可以被註冊到 Mozilla 系統下，並且一旦被註冊，它其中的檔案就可以通過一種被稱為 chrome 的地址協定進行訪問。包可以包含任意類型的檔案，這些檔案可以被分別放置於不同的子目錄下。包的表現形式既可以是目錄也可以是 JAR 檔案，但常以 JAR 做為表現形式，同時 contents.rdf 檔案是必須的。那么，contents.rdf 的確切功能又是什麼呢？ contents.rdf 檔案就是用來分別描述這些包的，它描述了每種包的結構和負責完成的功能。確切的說，它其中的信息是為包的註冊服務的。擴展在安裝時，負責安裝擴展的程式會分析它的內容，並將包註冊到 Mozilla 系統中。只有在包被註冊到 Mozilla 系統之後，它才可以進行正常的工作，才可以被通過 chrome 地址協定進行訪問。本章的後面將對 chrome 地址協定和擴展的安裝原理做更一步的解釋，現在只說明 contents.rdf 檔案的結構。 再有，由於基於 Gecko 1.8 核心的 Mozilla 程式採用一種新的方式來進行包的註冊，所以 contents.rdf 其實已經被廢棄掉了。新方式通過一個位於擴展頂級目錄的 chrome.manifest 檔案來完成同樣的功能，它是一個格式十分簡單的純文本檔案。但為了保證擴展能夠兼容 Gecko 1.8 以前的版本，我們還要在擴展中使用 contents.rdf 檔案格式，直到它真正的被廢棄掉。 我們已經了解到，contents.rdf 的檔案格式是 RDF/XML 格式的，它是一種通過 XML 描述的 RDF 格式。RDF（Resource Description Framework，譯為“資源描述框架”）主要用來描述資源之間的關係，並且可以用許多格式來表示，但常用 XML 格式進行表示。Mozilla 也只是套用了這樣一種格式來描述它的包資源。前面提到的 3 個包屬於 3 種不同類型的資源，所以在進行描述時也會有所區別。並且這些包的描述格式是相對固定的，你完全可以通過修改下面的模板檔案來生成你的 contents.rdf 檔案。
適用於 content 包的 contents.rdf 檔案
示例格式如下：
chrome://sampleext/content/overlay.xul
下面對以上的一些格式做解釋說明，先看一下它的檔案頭部。
上面這一段格式相對固定，它主要是用來引入 RDF 和 chrome 命名空間。
接下來
這裡的 package 和 sampleext 都需要注意。首先，package 用來說明它描述的是一個 content 類型的包。對於 locale 和 skin 類型的包，應把它替換成 locale 和 skin，雖然這看上去與包目錄的命名有些不一致。sampleext 是用來唯一標識擴展的名稱，Mozilla 系統靠它來識別是哪個擴展的註冊信息。後面還有好幾處出現了同樣的內容，你都需要注意。對於 locale 和 skin 則不能寫能 locale:sampleext 或 skin:sampleext 這種“類推”出來的格式，它們的格式後面做說明。
檔案的中間部分
標識中的內容已經說明，它是適用於 Mozilla Suite 和老版本 Firefox/Thunderbird 的附加信息，所以對於核心較老的 Mozilla 必須被寫成：
chrome:extension="true" chrome:displayName="Sample Extension" chrome:author="Your Name Here" chrome:authorURL="http://sampleextension.mozdev.org/" chrome:description="A sample extension with advanced features" chrome:settingsURL="chrome://sampleext/content/settings.xul">
對於新版本的 Mozilla， 中的內容可以忽略。這段內容主要用來描述擴展的一些附加信息，如作者和擴展的顯示名稱等。其實在 install.rdf 檔案中，存在同樣的一段描述信息。因而，這裡再做描述顯得有些羅嗦，作者也不建議你在 contents.rdf 中加入那些附加的信息。
檔案的結尾部分
chrome://sampleext/content/overlay.xul
這是 content 類型的 contents.rdf 檔案所描述的關鍵部分。Mozilla 下的擴展之所以能夠和瀏覽器整合在一起，像一個程式一樣工作，是因為它採用了一種被稱為“復蓋（Overlays）”的技術。你的擴展可以在 Mozilla 的某個已有界面上，再組合上另外的 XUL 界面元素，而不會與之產生任何的衝突和不協調。這種技術與其說是“復蓋”，不如說是“合併”更合適。因為，原有的界面元素會根據加上去的界面元素自動調整自己的位置，以適應變化。同時,“復蓋”技術還為擴展程式的運行提供了“入口點”，這也正是我們編寫的擴展能夠運行的原因。 在上面的內容中，第一個 RDF:Seq 標記指明要對 Mozilla 的界面進行復蓋；而要對哪些界面進行復蓋，則通過它的子標記 RDF:li 標記進行描述，如： 它意思是要復蓋負責描述瀏覽器界面的 browser.xul 檔案，這個檔案就是通過 chrome 地址協定進行指定的，後面你還將看到在許多情況下，我們都需要通過 chrome 地址協定來訪問註冊到 Mozilla 系統下的包資源。如果你還想復蓋其它的界面檔案，你只需像上面一樣指定多個 RDF:li 標識。 第二個 RDF:Seq 對那些被復蓋的檔案做更進一步的描述，它描述了指定的目標檔案會被當前包下的哪幾個檔案所復蓋。如：
chrome://sampleext/content/overlay.xul
意思是用 overlay.xul 復蓋 browser.xul 檔案，並且 overlay.xul 也是以 chrome 方式進行定位的，或者說是以已經註冊後的地址進行定位的。如果還有更多的界面檔案要復蓋到 browser.xul 上，照上面格式書寫即可。
適用於 locale 包的 contents.rdf
檔案 示例格式如下：
我們可以看到，locale 包的 contents.rdf 檔案的與 content 包的 contents.rdf 檔案沒有什麼太大的區別，只有檔案前面的 RDF:li，其 resource 中寫的是 locale:en-US，注意區別前面 content 中的 package:sampleext。後面的 RDF:Description 格式相對固定，只是你要注意將 RDF:li 中的 sampleext 替換成與上面一致的擴展名稱。另外，由於這一類型的 contents.rdf 是用來描述語言包的，所以，你必須要處理好相應的語言描述信息。
適用於 skin 包的 contents.rdf 檔案
示例格式如下：
我們可以看到，它與 locale 包的 contents.rdf 檔案差不多，格式也很相近，只是 RDF:Description 標記中的屬性少了一些。因為，這兩種資源的描述幾乎是採用一致的格式進行註冊的，你只要注意 skin:classic/1.0 即可。 以上只是給出一些標準的格式，隨著你對擴展開發的深入，你會發現一些特殊的格式及套用。另外，由於這個檔案是 XML 的，所以作者提醒你保存成不帶檔案頭標記（BOM）的 UTF-8 格式，並且建議你在創建完此檔案之後，用瀏覽器再驗證一下檔案的格式和編碼問題。
