第三章 ODRL、XrML、MPEG-21 REL 的描述與解釋
數位權利的關鍵性特徵為實質增加網路上數位材料的可再用 性，同樣的也增加實體素材的效能。普及的網路改變了傳布數位 媒體的天性，使單向的流動（從出版者到終端使用者） ，轉變成一 個互動的循環，讓作品可以再次結合或者是擴展，達到重複利用 的目的。在所有的階段裡，權利必須被管理，並且在信賴的環境 裡加以兌現。數位版權管理描述語言，造就了權利管理的可能性。
在此章節裡，研究者將會對三種描述語言分別作描述，從語言的 發展歷程，到語言本身的架構，並穿插解釋其設計上的用意。
第一節 ODRL(Open Digital Rights Language)的描述與解釋 一、 發展緣起
1997 年，以自動化版權保護為專題的 John S. Erickson 從 Dartmouth 大學畢業後，在 HP 實驗室繼續對這塊領域進行研究。
Erickson 的研究激勵了在澳洲 IPR 實驗室的 Renato Ianella，於是 Ianella 在 2000 年提出了 ODRL 這個開放性的標準版權語言。ODRL 目前被許多在澳洲以及歐洲的學院、數位圖書館使用，另外也有 商業性的應用，如 Open Mobile Alliance 用其發展無線訊息協定。
ODRL 參考了 Erickson 的研究所得，並以英國的 indecs、Editeur 作為它的基礎參考文件。上述提到的兩個工業計畫，在企圖讓數 位材料的商業化得以定型這一塊上，都是相當具備代表性的。雖 然說 ODRL 原本是 IPR 實驗室所發展的工作之一，但是它現在由 十多個團體共同合作研發。包括有：
♦ The <indecs> Project [INDECS]
♦ Electronic Book Exchange Working Group [EBX]
♦ International Federation of Library Associations [IFLA]
♦ DOI Foundation [DOI]
♦ ONIX International [ONIX]
♦ Moving Pictures Expert Group [MPEG]
♦ IMS Global Learning Consortium [IMS]
♦ Dublin Core Metadata Initiative [DCMI]
♦ Propagate Project [PROPSGSTE]
♦ OpenEBook Forum [OEBF]
♦ Association of American Publishers [AAP]
♦ Digital Imaging [DIG35]
ODRL 企圖成為數位版權管理系統中機器可運作的一部份。為 了保持它的開放性，ODRL 以免費提供的方式，讓每一位希望合 併其全部或者部分到自己所擁有的系統的人，都能夠自由地從 ODRL 的網站上取得說明文件。這份文件包括了 XML 圖式的語義 概觀，對於本來就熟悉 XML 的人來說，這份文件將會顯得相當容 易理解且清楚(Coyle,2004)。目前 ODRL 為 World Wide Web (W3C) 所支持。
二、 設計理念
ODRL 有下述各項設計理念：
1. 不僅是數位化的版權管理
在 ODRL 的設計者眼中，數位版權管理應同時為有形的和 無形的資產作管理，包括：權利描述、分層、分析、評估、交 易和監視等動作。數位版權管理是數位化的權利管理，實際上 作用在實體作品（例：一本書） ，也能夠作用在數位作品（例：
一本電子書）上。
2. 增進版權管理的效率
目前管理交易和保護資產的方法通常效率不彰，方法本身 亦有專利權、壟斷的問題，或者經常要求訊息用物理形式包裹 起來或嵌入，顯然不利於數位版權管理的發展。
因應前述問題，ODRL 最初的構想是以外掛程式的方式搭 載在一個公開的系統架構上，提供具有互通性的點對點數位版 權管理服務。這樣一來，ODRL 不僅可以獨立地於系統外，表 達權利陳述，也可以結合系統一起發揮作用。
3. 公開且具有擴展性
DRM 系統必須以公開的功能架構為基礎，並以此加以設
計、考量，以期擁有健全(robust)且具擴展性的資訊模式。目
前的數位版權管理技術包含了描述期限與限制的語言，在能夠
控制的環境下追蹤資產使用或者將資產清單編碼，為整個版權
管理架構起完整的架構。而 ODRL 是為在安全典藏機制不可
知的狀況下，試圖為數位版權描述提供提供語義學，以便創造 一個公開且信任的環境。
ODRL 的存在，可以說是補充了現有、類似範疇之版權管理標 準，藉著提供數位等值物(equivalents)，和支援擴展性，提供在網 路環境下，擁有數位天性的資產，種種新的服務。在物理性的環 境裡，ODRL 同樣可以使用為原本非數位形式的資產，創造數位 形式的版權管理。
三、 語言概述
1. ODRL 的組成
ODRL 是一套標準化的版權描述語言，採 XML 為語法，
ODRL 本身由「表達語言」與「資料辭典」兩部分共同組合而 成。除了表達語言與資料辭典各自擁有的 XML schema 之外，
再加上 ODRL 本身提供的敘述，與數位簽章所有的安全編碼 圖式，讓 ODRL 得以表達版權。資料辭典主要是匯集表達語 言中所有出現的詞彙，並附有摘要性的定義，幫助理解。
2. ODRL 表示版權的方法
ODRL 中的核心語意，即是為了能夠表達資產與條件而 生，以提供版權擁有者設計資產清單及表達，選用合適的版權 描述。版權描述有兩種彈性表達方式，一種是指定給特定的資 產，例如，PDF 格式存在的電子書，加入會員的使用者有可 以享有預覽前五頁的權利。另一種則是以資產清單中的某個範 圍作為版權描述的對象，
3. ODRL 可發揮的作用
ODRL 強調版權表達語言的語意和資料辭典中所定義的元
素。ODRL 可以被使用在信賴或不被信賴的系統中，以及數位
或非數位的資產。進一步地說，在使用 ODRL 時，它既不指
定版權管理系統所應具備的性能，也沒有任何對系統在信賴服
務上的要求（比如說，內容的保護、數位/物理性的傳播、付
款協商）。顯而易見地，ODRL 所能發揮的最大功用，是使數
位資產在獲取與管理將會像可視的物理性資產的版權交易一
樣。然而在現實的世界裡，ODRL 還是需要搭載於版權管理系
4. ODRL 的擴展性
ODRL 定義一系列的核心語意。額外新增的語意可以放在 ODRL 最頂層，以便讓第三方根據這些新增的資料辭典作加值 服務。ODRL 並不為 DRM 執行或者命令任何政策，但是他提 供一個表達這種政策的機制。任何社群或者組織，都可以根據 自身行業的特殊性與需求，採用 ODRL 來表達這種政策。
5. ODRL 的唯一性要求
ODRL 在使用上必須注意到「資產」與「使用者」的識別 都必須是唯一的。普遍而言， 「識別」是一個非常困難的問題，
處理過程中需要經過許多認證機制的核可與認同，而這也是為 什麼識別機制和政策通常位於 ODRL 的外部。某些以 ODRL 加以發展的特殊版本可能會滿足這種表明資產或主體資訊的 需求。
6. ODRL 為符合一般需求為主
ODRL 模式是奠基在分析和研究版權描述模型與語意此 類特定需求，目標在可為廣大的社群所應用。ODRL 希望能夠 成為「一般性」的版權管理描述語言，以迎合大多數部門的一 般需求(common requirements)，因此也連帶的被目前其他組織 團體所進行的工作與標準、模式影響。ODRL 期望藉著定義一 個獨立但有擴展性的語意，與其發展團體相容。ODRL 並不特 定針對任何媒體類型來作發展，企圖達到跨部門的互通性。
四、 語言架構
ODRL 語言的模型跟字彙辭典提供版權表達的架構與核心語 意。ODRL 用「基礎模型」(Foundation Model)提供一個整體性的 架構，來表現出元素應如何應用。
之後所出現的圖，左上方有 EX 記號的，即代表「實體」
(entities)；左上方有 DD 記號的，則為元素(elements)；左上方為
DS 的，代表 XML 的數位簽章類型(XML Digital Signatures)。
（一） ODRL 基礎模型
圖 3- 1 ODRL 的基礎模型
資料來源：Iannella, R. (2002,8,8). Open Digital Rights Language (ODRL).
Available at: http://odrl.net/1.1/ODRL-11.pdf
如 圖 3- 1 所示，主要的核心實體為「資產(asset)」、「權利
(right)」 、「主體(party)」三者。除了上述的三個核心實體，基礎模 型中還有「提供（Offers）實體」和「同意（Agreements）實體」。
提供實體與同意實體的呈現對 ODRL 的核心部分是相當重要的。
這使得版權表達的目的，能夠更清楚地呈現。另外，內文(context) 實體也扮演了關鍵性的角色，以下在 ODRL 中所提供的十個實體 的介紹：
1. 資產（Asset）實體
資產包含物理及數位的內容。資產必須要被獨一無二的加 以識別。而且資產還可作切割，細分為次一級的部分，許多次 級部分又可組合回一個資產。因為具備這種可分解性，資產會 以許多不同的形式來呈現。資產可能是不可視的一件作品，或 者是以一份清單來加以描述。另外，資產可能會經過加密，使 得在傳送內容的過程中確保安全性。
DS
EX
資產 數位簽章
EX
撤銷
EX
權利
EX
內文
EX
提供
EX
限制
EX
許可
EX
同意
EX EX 主體
版權擁 有者
EX
要求
EX
條件
EX
加密
摘要/金鑰
資產實體（有時是參照到一本書、內容、創作、智慧資產） ， 被視為一個完整的實體。假使權利實體對應的是資產實體的次 級部分，那麼該次級部分也同樣必須有唯一識別。相同地，
ODRL 可以指定資產的次級部分的限制。同時，資產實體可以 依照他們在 IFLA 模式裡，對智慧資產所定義的層，包含了作 品、呈現方式、媒體表現方式、單件這四種層次來進行個別的 權利表達描述。這種分層特徵使得版權可以在不可知的資產，
以及個別的狀況中被表達。
2. 權利（Rights）實體
權利實體最直接關聯到的是許可（Permissions）實體，許 可實體之下又有三個實體--限制（Constraints）實體、要求
（Requirements）實體、條件（Conditions）實體。許可實體主 要是用來說明，資產被核可的實際使用行為或活動（像是播放 視訊資產） 。限制實體是針對上述許可實體所作出的限制（像 是僅可以播放該視訊最多五次）。要求實體說明行使許可時必 須盡的義務，或付出的代價（像是每次播放都必需支付五元美 金）。條件實體用來指定例外狀況，假使條件成立的話，就終 止許可，且必須重新商議交易的內容（例如，信用卡使用期限 到期，所有的許可將會撤銷以致於無法播放影片，直到下次再 次取得許可為止）。
3. 主體(Party)實體
包含終端使用者(end users)與版權擁有者(Rights
Holder)。主體可以是人、組織或其他有加以定義、能夠識別 的角色。終端使用者通常指的是資產的消費者(consumers)；版 權擁有者通常會有幾種不同的角色，像是資產的創作者、製造 者、傳布者，他們可以宣稱自己擁有資產中某些形式的所有 權，或擁有資產中的某些許可（Permissions）的擁有權（可以 作轉讓或再次轉讓者）。版權擁有者可能同時也得以享有收取 版稅收入的權利。
4. 提供(offers)實體
提供(offer)實體是讓版權擁有者可以對他們所擁有的特定 資產，下特定的版權建議，以便協商或者是提供特定的許可。
提供(offers)實體可以被連結，創造出不同的層次，以便在不同
的商業模式中提供消費者多樣的選擇性。版權擁有者可以利用 提供實體，來說明自己提供何種資產的何種權利許可，可以想 像成招商廣告的形式。
5. 同意(agreements)實體
同意(agreements)實體將提供(offers)實體轉換進入一份版 權許可(license)，於是版權許可中就會有資產擁有者同意授與 某項資產的某些權利，這是由資產擁有者對一份特定資產所下 的版權使用狀，有了同意實體，被授權者就可以依據其中資產 擁有者給定的權利去加以運用。但是，這並不表示提供實體有 優先於同意實體的前提在。在交易雙方產生互動之後，同意實 體即被創造以表達接受的詞彙與條件。這種模型也可以用來表 達取消任何的提供或同意。
6. 許可(permissions)實體
許可實體通常會被許可實體與同意實體所用。許可實體是 用來表達對特定的資產可以作什麼樣的動作。在許可實體裡，
可以指定授與的權利，比如說資產有哪些被許可的用法 (usage)、再利用法(reuse)、轉換法(transfer))、管理法
(management)。許可有時也會伴隨限制實體或要求實體的出 現。
7. 限制(constraints)實體
限制實體是用來限制權利的，也就是針對許可實體所載被 認可的權利去作限制。限制有許多不同的面向，例如限制使用 者、裝置、範圍、時間等。
8. 要求(requirements)實體
要求實體是用來進行協議的，裡面會記載版權擁有者希望 被授權者接受的一些要求，假使授權者接受並且滿足了要求實 體中的要求，被授權者才能夠取得授權許可。要求實體會有一 些對費用、互動、用法上面的要求。
9. 條件(conditions)實體
條件實體記載的是一些例外的條件，一旦這些例外條件發
止。它利用了許可實體與限制實體，當達到實體裡所載，權利 將會被取消。
10. 內文(context)實體
在基礎模型裡面的實體，幾乎都可以使用內文（Context）
實體。內文實體會關聯到其他實體，其主要用途是幫助其他實 體描述更多的資訊，這些資訊不僅能夠包括實體本身的資訊，
還有實體跟實體之間的關係。舉例來說，一份與同意實體產生 關聯的內文實體，可能指定有某個交易的日期；一份與主體實 體關聯的內文實體也可能指定了主體是哪些人、團體。雖然並 沒有一定要使用內文實體的規定，但由於使用內文實體能夠讓 版權描述更加清楚，所以一般會強烈建議使用。
內文(context)實體在實體的識別上扮演了一個非常重要的 角色，因為它採用標準化的唯一編碼來達成實體的識別。這種 唯一編碼能夠用來參照到任何實體，可用在提供實體間的連 結。舉例來說，同意實體藉著編碼關聯到提供實體的內文實 體，然後由內文實體中所記載的唯一識別碼，連結到原生的提 供實體。
對 ODRL 而言，主體(party)跟資產(asset)的描述皆位於 ODRL 的外部。位於內部的實體必須使用 URI（Uniform Resource Identifier）來加以參照。URI 是一種獨一無二的識別 系統，同時包含了對實質實體的解析機制。主體實體與資產實 體的唯一識別機制，表達在他們所關聯的內文實體內。
上述實體的使用，使得廣泛且具彈性的 ODRL 描述變得更加
可行。另外，版權的描述亦可以被加上數位簽署。 例 3- 1 是以 XML
所寫的 ODRL 基礎模型，可以從中了解每個實體在一份版權描述
中的位置。
例 3- 1
ODRL 基礎模型
<rights>
<context>.
<uid> ... </uid>
</context>
<offer>
<asset> ... </asset>
<permission>
<permission-type>
<requirement> ... </requirement>
<constraint> ... </constraint>
</permission-type>
<condition> ... </condition>
</permission>
<party>
<context> ... </context>
<rightsholder> ... </rightsholder>
</party>
</offer>
<agreement>
<context> ... </context>
<party> ... </party>
<permission> ... </permission>
<asset> ... </asset>
</agreement>
</rights>
基礎模型提供的是完整的版權描述，如果想更深入去了解每 一個實體，可以繼續參考以下的介紹，參考每個實體自己的模型。
由模型，可以讓我們更清楚它們是如何組成與被使用。
表達「誰」同意給 予何種「資產」的 哪些「許可」
主體 許可 (包含要求、
限制、條件) 資產
表達「誰」提供什麼「資 源」的哪些權利「許可」
（二） ODRL 的許可模型
ODRL 可以在提供實體與同意實體中利用許可實體來表 達許可。許可實體所描述的，主要是能夠在資產上進行的特 別動作或對資產作特別的處理的允許。ODRL 的許可模型如 圖 3- 2 ：
圖 3- 2 ODRL 許可模型
來源：Iannella, R. (2002,8,8). Open Digital Rights Language (ODRL). Available at:
http://odrl.net/1.1/ODRL-11.pdf
許可實體由四種抽象實體聚集組成。這些抽象實體（如 圖 3- 2
中的雲狀結構）原本是單獨的，我們可以運用其中一到多個共同 組成一個群組許可，這些用來組成許可的抽象實體有：
1. 使用(Usage)：指出資產可以用何種方式來消費（比如說，
展示、列印、播放、執行）。
2. 重複利用(Reuse)：資產可以用何種操作而重新恢復效用 （比 如說，修改、摘錄、註解、聚集） 。
3. 轉換(Transfer)：一系列的程序，關於資產的版權是如何轉 換的（可理解為：賣出、出借、給予、租賃）。
4. 資產管理(Asset Management)：數位資產的管理操作（可理
使用
EX
許可
EX
內文
EX專賣品
重複利用
轉換
資產管理EX
展示
EX
列印
EX
播放
EX
執行
EX
修改
EX
摘錄
EX
註解
EX
聚集
EX
賣出
EX
租借
EX
給予
EX
租賃
EX
移動
EX
複製
EX
刪除
EX
更新
EX
備份
EX
儲存
EX
回復
EX
安裝
EX
移除
解為：移動、複製、刪除、更新、備份、儲存、回復、安 裝、移除） 。
另外，許可實體支援：
1. 專賣品（Exclusivity）屬性，如果說認證許可被限制給某一 經過委託的主體時，那麼發行該許可的認證便成為該主體 所專有的（每一個給一個同意實體）。
2. 以內文實體對特定的集合或許可群體給定一個獨一無二的 識別。
許可實體必須要透過提供實體或同意實體，以與一個或多個 資產實體建立關聯。這種關聯可以是直接載明的（像是：「許可」
是「提供」或「同意」的子元素）也可以是間接寫就的（透過一 個「提供」或「同意」的參照而來） 。許可實體可以跟零到多個限 制實體、條件實體或要求實體產生關聯。
要特別注意的是，任何在 ODRL 中未清楚規範與未被指定的 部分，都是未經過認證的，不可以自行假設。 例 3- 2 為許可模型的 XML 語法範例。
<permission>
<display/>
<print>
<constraint> ... </constraint>
</print>
<annotate/>
</permission>
例 3- 2 許可模型的 XML 語法範例
給予展示與列印的許 可，其中又對列印做 出某些限制
（三） ODRL 的限制模型
ODRL 支援版權限制的描述。這是用來識別資產裡面的許 可實體之下有何種限制。ODRL 的限制模型如 圖 3- 3 ：
圖 3- 3 ODRL 限制模型
來源：Iannella, R. (2002,8,8). Open Digital Rights Language (ODRL). Available at:
http://odrl.net/1.1/ODRL-11.pdf
限制實體是由好幾個抽象實體所聚集而成的。這些抽象實體
（如 圖 3- 3 中的雲狀結構）本身代表一種個別的限制，然後可以用
來聚合成相似的限制，抽象實體可用來限制以下各種不同的面向：
♦ 使用者（User）：限制經過識別的使用者才可以進行使用，可 以是個別使用者，或者是團體使用者。
♦ 裝置（Device）：限制只能在指定的實體裝置或者是系統中使
使用者
EX 限制 EX
內文
裝置 範圍 版權 方面 目標
時間
DD 個人
DD 團體
DD CPU
DD 網路
DD 螢幕
DD 儲存裝置
DD 記憶體
DD 印表機
DD 軟體
DD 硬體
DD 計次
DD 範圍
DD 空間
DD 特定時間
DD 累積時間
DD 一段間隔
DD 轉讓許可
DD 品質
DD 格式
DD 單位
DD 浮水印
DD 目的
DD 企業
DD
修訂內文用（理解：CPU、網路、螢幕、儲存裝置、記憶體、印表機、
軟體、硬體）。
♦ 範圍（Bounds）：以固定的次數，或者是某種限度或範圍之內 的使用（理解：計次、範圍、空間）。
♦ 時間（Temporal）：限制在某時間界限內得以使用（理解：特 定日期時間、累積時間、一段間隔）。
♦ 方面（Aspect） ：對資產的明顯特徵或描述加以使用的限制（理 解：品質、格式、單位、浮水印） 。
♦ 目標（Target）：指出該資產在何地以及如使用有所限制（理 解：目的、企業、修訂的內文）。
♦ 版權（Right） ：只用在資產有轉讓的許可且讓說明書（和限制）
擁有向下傳布的許可（理解：轉讓許可）
通常一個限制實體會關聯到一個許可實體。假使說一個限制 跟很多個許可出現在同一個層級，代表該限制將會作用在所有的 許可上面。
限制可以從零到多個。在這個裡，子限制適用到母限制。舉 例來說，如果我們在<count>跟<range>之下使用<unit>時，會有以 下幾種不同的狀況：
♦ 當<count>在<unit>的限制之外，表示權利可以被行使的次數
（例如：在列印的元素裡面計算五次，表示可以列印五次） 。
♦ 當<count>在<unit>的限制之內，是表示 unit 的次數（例如：
在列印頁數的單位元素裡面下達計算五次，是表示列印五頁 的意思）。
♦ 當<range>在<unit>的限制之內，表示最大或最小單位元的位 置順序（例如：在列印元素裡面的頁數類型單位元素之中的 範圍值，從最小 1，到最大 100，也就表示列印頁數 1 到 100） 。
♦ 當<range>在<unit>的限制之外，要依照內含的元素來判斷有 何種限制。
另外，所有的限制元素可能都有一個內文(context)元素，以支
援 uid 的使用，和一個「類型」的屬性，以參照附加資訊。
假使說執行系統無法表現所有被表達出來的限制，那麼一開 始該限制就不應該被授與。也就是說，如果一個系統不瞭解如何 保證指定的限制如何加以兌現，那麼他就不應該讓該限制得到授 予。
如果說許可有多重限制的話，所有的限制都應該在不衝突的 狀況下獲得兌現。假使說有衝突的情況發生，亦將會有錯誤產生。
限制的 XML 實例
ODRL 的限制模型可以用 XML 來表示。 例 3- 3 就是一個例 子，用來表現許可被限制只能在特定的 CPU 中展示。列印的許 可限制在五次。播放的許可限制在七天的週期，而且本身最多 播放十次。
<display>
<constraint>
<cpu/>
</constraint>
</display>
<print>
<constraint>
<count>5</count>
</constraint>
</print>
<play>
</constraint>
<interval>P7D</interval>
<constraint>
<count>10 </count>
</constraint>
</constraint>
</play>
例 3- 3 限制的 XML 實例
限制舉例：轉讓許可
轉讓是商業行為中常見的一種模式，在轉讓許可上設限，使資 產的所有權能夠順利地向下傳布。轉讓許可僅僅可被確定擁有版 權的主體所使用，於是能夠轉讓版權給其他的使用者，在被使用 的範圍上是比較小的。
對轉讓許可的限制，可以用清單的方式來列出，這個清單上 列出當資產作轉讓的時候，一定會隨之轉讓的許可，或者是可能
限制只能在指定 的 CPU 中展示
限制只能 列印五次
限制在七天內 最多播放十次
會隨之轉讓的許可。假使某一個許可並沒有被列出，那也就是說 該許可可能沒有隨著資產的轉讓而轉讓。換句話說，預設值是當 資產在轉讓的同時，許可並非是伴隨著轉讓過去的，必須確實有 列在轉讓清單上才會一同轉讓。
當一個許可被轉讓的同時，轉讓資產的主體可能會，也可能 不會允許接收轉讓的主體動手改變這個許可（通常來講先前擁有 資產的主體，會縮小許可本身的範圍，至少不超過原先擁有資產 主體的權限）。轉讓許可的實體支援下列三種屬性值：
1) 相等（equal）
2) 小於（less）
3) 不大於（less than or equal to）
假使往下傳輸的屬性設置是相等，當資產在轉讓時，預設的情 況是，許可必須要在不改變的情況下一併傳送。假使往下傳輸的 屬性是小於，當資產在轉讓時，較少的許可次集合體將會跟著傳 送。假使往下傳輸的屬性是不大於，當資產在轉讓時，許可將會 較之前為狹窄或相等，而且絕對不會擴大。
例 3- 4 顯示轉讓許可的限制（應用在銷售轉讓許可時）包含了
兩個選擇。第一個選擇包含「列印」與「播放」兩個許可，往下
傳輸屬性設在相等。這是表示當資產被賣出給其他的使用者，出
售者在同意實體下授權，必須提供這兩個許可。第二個選擇同樣
包含「聚集」與「註解」兩個許可，並且往下傳輸屬性設在不大
於。這表示當資產售出給其他的使用者，出售者可能會提供這兩
個許可，或者是其中一個，又或者兩個都不提供。
<permission>
<sell>
<constraint>
<transferPerm downstream="equal">
<print/>
<display/>
</transferPerm>
<transferPerm downstream="notgreater">
<aggregate/>
<annotate/>
</transferPerm>
</constraint>
</sell>
</permission>
例 3- 4 限制模型：轉換許可的 XML 語法
限制舉例：應用到每一個成員的限制
有些限制是針對含有一些分支實體的實體上（例如：團體中的 成員） 。舉例來說，一個對團體的限制，按照慣例，可能會指向一 群個體的集合。在一般的狀況下，當對團體的列印許可下了「1」
的限制，便是說該資產僅只能夠「被列印一次」 。但是，我們可能 會希望這個 1 的限制是對群體中的每一個成員而作的，而不是僅 針對整個團體所下的限制，也就是說並不是讓整個團體只能列印 一次，而是讓在團體中的每一個個人都可以列印該資產一次。
在上述案例當中，限制必須應用在「每一個成員」的階層，
我們可以用「forEachMember」這個機制來完成希望達到的功效。
這種機制使得我們可以用「成員」為單位來作限制，而不是成員 所組成的「團體」作為限制單位，並且將參照的限制應用在每一 個團體裡面的成員。
ODRL 定義了一個 URI 來表現這種語意：
「http://odrl.net/1.1/#forEachMember」，
這個 URI 的值被用在「限制」元素裡面的「類型」屬性。限 制元素可參照到其他每一個使用 id/idref 的實體。
思考下面的 例 3- 5 ，當資產已經取得能夠在課堂上教授的版權
（例如：可用在教授 JAVA101 這一班） 。教師已經購買了關於該資 產的版權，並且在第一個限制中（識別碼為 student01） ，讓這個班
第一種轉讓許可選擇，
包含列印與播放
第二種轉讓許可選擇，
包含聚集及註解
級裡面的學生都能夠作播放的動作。列印的許可同時有「1」的限 制，但是這個限制參照到第一個限制（使用 idref），並有
「forEachMember」類型的屬性。這代表班級裡面的每一個成員都 可以列印該資產一次，而不是說資產總共只能被列印一次。
<display>
<constraint id="student01">
<group>
<context>
<uid>ldap://dir.uni.au/class=JAVA101;o=A-UNI;c=AU</uid>
</context>
</group>
</constraint>
</display>
<print>
<constraint idref="student01"
type="http://odrl.net/1.1/#forEachMember">
<count>1</count>
</constraint>
</print>
例 3- 5 限制模型；應用到每一位成員的限制-XML 語法
（四） ODRL 要求模型
ODRL 支援版權要求的表達。在獲取許可之前，必須要先滿 足某些先決條件，要求模型裡面所載的，便是版權擁有者預先指 定的一些條件，假使消費者同意滿足這些版權擁有者所提出來的 要求，才有可能去取得許可。ODRL 要求模型如 圖 3- 4 。
費用 互動 用法
DD 郵資費用
EX
要求
EX內文
DD 預付費用 DD 支付
DD 每次使用 費用
DD 認可條件
DD 註冊
DD 屬性
DD 追蹤
展示上的限制
列印上的限制
圖 3- 4 ODRL 的要求模型
來源：Iannella, R. (2002,8,8). Open Digital Rights Language (ODRL). Available at:
http://odrl.net/1.1/ODRL-11.pdf
要求實體包含三個抽象實體。這些抽象實體（ 圖 3- 4 中的雲狀 結構）個別代表一些不同的要求類別，可以群組使用，以指定要 求。三個抽象實體分別是：
1) 費用（Fee）-指出該為使用付多少費用（可以理解成：預付費 用、郵資費用、每次使用費用）。
2) 互動（Interactions）-指出授權方要求使用者應進行的互動（可 以理解成：認可接受某些條件、註冊個人資料） 。
3) 用法（Usage）-指出對該資產在使用上的要求（可以理解成：
屬性、追蹤）。
要求實體可能會關聯到一個或多個許可實體。假使一個要求 實體與一個以上的許可實體出現在同一個層次，要求實體就會一 次應用到所有的許可實體之中。當許可實體對應到多重的要求實 體時，所有的要求實體都應該確保會被承兌，並且不能發生任何 的衝突。當衝突發生，錯誤就會產生。另外，所有要求實體的元 素都可能會有一個內文元素。
ODRL 資料辭典同樣也定義一般可重複使用的支付(Payment) 實體。支付實體可能由固定數量的付款額、貨幣數量、應付稅款
（百分比） 、徵稅代碼所組成。
有一點必須特別注意的是，如果說系統無法表現版權擁有者 所提出的要求實體，那就絕對不能認證。也就是說，假使一個系 統不瞭解指定的要求實體如何被達到，那它就不能同意任何的許 可。系統的使用者將被知會可能會有這種狀況的發生。
要求的 XML 實例
ODRL 的要求模型可以用 XML 來表達。 例 3- 6 的例子是對播
放許可的要求，使用者在每次播放時皆必須支付二十元澳幣（加
上百分之十的稅金） 。
<play>
<requirement>
<peruse>
<payment>
<amount currency="AUD">20.00</amount>
<taxpercent code="GST">10.0</taxpercent>
</payment>
</peruse>
</requirement>
</play>
例 3- 6 要求模型的 XML 語法
取得播放許可時，
必須先滿足的要求
（五） ODRL 的條件模型
ODRL 支援版權條件的描述。如果說有某些在條件實體中 指定的條件成立，或者發生，會使得許可不再具備合法性與 效力，系統必須要終止許可。ODRL 的條件模型如 圖 3- 5 所示。
圖 3- 5 ODRL 的條件模型
來源：Iannella, R. (2002,8,8). Open Digital Rights Language (ODRL). Available at:
http://odrl.net/1.1/ODRL-11.pdf
條件的實體重複利用了兩個既存的實體，有：
♦ 許可（Permission）-指出會觸發事件的許可。
♦ 限制（Constraint）-指出會觸發限制的限制。
假使條件為真（指定的事件發生） ，那麼系統必須停止先前授 與使用者的許可。系統將會告知使用者關於這種情況的發生，並 且提供關於重新協商同意的資訊。
條件實體可能會關聯到一個或多個許可實體。假使一個條件 實體跟很多個許可實體出現在同一個階層底下，那麼條件會一次 對應到所有的許可。許可如果有多重條件的話，每一個條件都必 須能夠實現，而且不能夠有衝突發生。假使說衝突發生的話，錯 誤也將產生。另外，所有的條件元素可能有一個內文元素。
必須注意的是，任何被表達出來但不能夠保證被達成或被系 統所理解的條件，都不應該授予相關的許可。
EX
內文
EX條件
EX
限制
EX
許可
同樣相當重要的一點，條件和限制/許可雖然在表現上非常類 似，但卻有相反的影響結果。當版權可以以許可（被授權人被允 許作什麼）以及限制（限制被授權人所擁有的許可）的方式表達，
結果將會是取得版權。條件實體可以作達同樣的語意，但引發的 結果剛好相反，也就是，假使條件所指定的內容發生了或達到了，
那版權許可會失去效用，變成不再具備合法效用。
條件的 XML 範例
ODRL 條件模型可以用 XML 來表達。 例 3- 7 中可以看到兩 個許可：賣出跟播放。播放許可在特定軟體類型上做出限制，
意指當軟體被使用來播放視訊時，播放許可必須終止。另外，
有些限制是用在所有的許可上面（同時用在播放跟銷售）。這 種限制是用在空間性的地區（澳洲），也就是說當許可被攜離 澳洲時，許可必須被終止。
<permission>
<sell/>
<play>
<condition>
<constraint>
<software> ... </software>
<constraint/>
</condition>
</play>
</permission>
<condition>
<constraint>
<spatial>
<context>
<uid>iso3166:AU</uid>
</context>
</spatial>
<constraint/>
</condition>
例 3- 7 條件模型的 XML 語法
（六） ODRL 版權擁有者(Rights Holder)模型
ODRL 支援版權擁有者的識別。版權擁有者是一個經過認證 的主體，在使用資產時，必須先滿足版權擁有者對欲取得版權者 所提出的要求。ODRL 版權擁有者模型如 圖 3- 6 所示：
針對播放所 作的限制
針對整份許可 所作的限制
圖 3- 6 ODRL 版權擁有者模型
來源：Iannella, R. (2002,8,8). Open Digital Rights Language (ODRL). Available at:
http://odrl.net/1.1/ODRL-11.pdf
版權擁有者實體是由一個抽象實體所組成的，這個抽象實體
如 圖 3- 6 中的雲狀體，代表了版稅的一些類型，可群組類似的版稅
權利，以表達版權擁有者的應得權利。能夠用來組成版稅描述的 有：
♦ 百分比（Percentage）-指出一個在每一次交易時，使用了某一 個主體所擁有的的資產，而必須支付的付款額，這個付款額 以百分比的方式顯示。
♦ 固定總額（Fixed Amount）-指出一個在每一次交易時，使用 了某一個主體所擁有的的資產，而必須支付的付款額，這個付 款額以一個固定的總金額來顯示。
另外，要特別注意的是，版權擁有者並非只能是一個主體，
它可容納一個或多個主體，並且與一個或多個資產產生關聯。
版權擁有者的 XML 範例
ODRL 版權擁有者模型可以用 XML 來表達。 例 3- 8 顯示有兩 個經過認證的主體，在每一次資產經過網路傳送時，一個會得到 百分之十的版稅，另一個則得到百分之九十。
EX 內文
EX 主體 EX 版權擁有者 版稅
DD 百分比 DD 固定總額
DD 支付款項
<party>
<context> ... </context>
<rightsholder>
<percentage>90</percentage>
</rightsholder>
</party>
<party>
<context> ... </context>
<rightsholder>
<percentage>10</percentage>
</rightsholder>
</party>
例 3- 8 版權擁有者模型的 XML 語法
得到 90%版稅 的版權擁有者
得到 10%版稅 的版權擁有者
（七） ODRL 的內文模型
ODRL 的內文模型，是用來支援關於實體，與實體間關係的附 加資訊的描寫。ODRL 內文模型如 圖 3- 7 ：
圖 3- 7 ODRL 的內文模型
來源：Iannella, R. (2002,8,8). Open Digital Rights Language (ODRL). Available at:
http://odrl.net/1.1/ODRL-11.pdf
內文實體是十個其他實體的聚集體，包括：
1) UID：一個獨一無二的實體識別碼。
2) 名稱(Name)：用來描述實體的名字。
3) 角色(Role)：實體所扮演的角色。
4) 註解(Remark)：與實體相關的註解。
5) 版本(Version)：指出該實體的版本。
6) 日期(Date)：指出實體產生的日期或者是有效日期。
7) 事件(Event)：指出事件的類型。
8) 物理位置(Physical Location：指出事件或實體的物理性位置。
9) 數位位置(Digital Location)：指出事件或實體的數位性位置。
10) 外部參照(External Reference)：連結到關於該實體的外部參照 資訊。
11) 交易(Transaction)：關於該實體的買賣傳送資訊。
12) 服務(Service)：連結到提供給該實體的服務。
DD 角色
註解
EX 內文
DD UID
DD 名稱
DD
DD 日期
DD
物理位置
DD 事件
DD
數位位置
DD
外部參照
DD 服務
DD 交易
DD 版本
內文可用在許多不同的目的，亦可以與任何實體產生關聯。
當宣告資產的時候，它可以為主體指向該資產所屬的獨一無二的 識別碼。當宣告主體時，他可以用來指向主體的識別碼，以瞭解 主體所扮演的角色、名稱。整個版權描述（像是提供實體）在被 創造之初，也都可以有一個內文，指向其版權描述獨一無二的識 別碼。同意（Agreement）實體也可以有一個內文實體，以提供關 於交易的資訊。
以文字為基礎(text-based)的內容實體（像是名字或者是評 論） ，可以使用 xml 的 lang 屬性，指向以文字為值的人類語言。在 涉及識別（在 uid 元素裡）以及字彙值（在角色元素）時，必須要 授予 URIs。對識別來說，這要求圖式(schema)以合適的命名空間 註冊。這種機制是為了提供最大的彈性給附加的 URIs，以及字彙 圖式給 ODRL 利用。無論如何，為了達到一致性，<uid>元素可能 也含有字串資料類型。
多重的 uid 元素可能會用在內文裡面。舉例來說，一個資產可 能含有很多不同的部分，而每一個部分都必須透過 uid 元素來參 照，使得整個作品可以被視為一個整體的資產。
內文的 XML 範例
ODRL 內文模型可以用 XML 來加以表示。 例 3- 9 是一個描述 主體的 XML 內文範例。
<party>
<context>
<uid>x500:c=EX;o=FederalLibrary;ou=Registry;cn=MariaKBrown</uid
>
<name>Maria Brown</name>
<role>onix:AO1</role>
<reference>http://www.maria-k-brown.com/vcard.xml</reference>
</context>
</party>
例 3- 9 內文模型的 XML 語法
（八） ODRL 提供模型
ODRL 的提供模型，是讓「版權擁有者」描述其所擁有的資 產，以及附屬於該資產的權利，來進行交易的協商，以便讓他人
關於主體資訊的內文
付出相對的代價。提供實體所載的內容，類似於廣告或者告示中 提供的資訊。ODRL 的提供模型如 圖 3- 8 。
圖 3- 8 ODRL 的提供模型
來源：Iannella, R. (2002,8,8). Open Digital Rights Language (ODRL). Available at:
http://odrl.net/1.1/ODRL-11.pdf
提供實體是四個其他實體的聚集體，包括有：
♦ 資產（Asset）：關於資產的資訊。
♦ 版權擁有者（Rights Holder）：要求欲取得版權者作出某些回饋 或付出某些代價的主體。
♦ 許可（Permission）：被提供的使用許可的資訊
♦ 內文（Context）：關於提供實體的細節描述，像是日期、時間、
地點、識別碼等等
提供實體讓擁有該資產的主體可以就該資產進行協商或對部 分特定的許可作細節性的描述。雖然非強迫，使用內文實體給提 供實體分派唯一識別碼是被強烈建議的。一個提供模型最少必須 包含一個「資產」與一個「許可」 。假使版權擁有者沒有特別說明 的話，系統將會從其他來源獲取這項資訊。
提供的 XML 範例
ODRL 的提供模型可以用 XML 來表達。 例 3- 10 是用來描寫某 兩位資產擁有者所願意提供的資產、許可，並使用了內文實體來 幫助描寫。
EX
許可
EX
內文
EX
提供
EX
資產
EX
主體
EX
版權擁有者
<offer>
<context>
<uid>http://www.example.com/offer/3893823823472384888373</uid>
<date><fixed>2001-10-10T09:00:00</fixed></date>
<service>http://www.example.com/e-book-store</service>
</context>
<asset> ... </asset>
<permission> ... </permission>
<party>
<rightsholder> ... </rightsholder>
</party>
</offer>
例 3- 10 提供模型的 XML 語法
（九） ODRL 的同意模型
ODRL 讓主體對資產的特定版權表達同意描述。ODRL 的同 意模型如 圖 3- 9 所示。
圖 3- 9 ODRL 的同意模型
資料來源：Iannella, R. (2002,8,8). Open Digital Rights Language (ODRL).
Available at: http://odrl.net/1.1/ODRL-11.pdf
同意實體是四個實體的聚集體，包括有：
♦ 資產（Asset）-關於資產的資訊。
♦ 主體（Party）-有關該同意主體的資訊。
♦ 許可（Permission）-獲得同意的使用方法許可的資訊或連結。
♦ 內文（Context）-關於該同意的細節，像是日期、時間、地點、
識別碼等等。
EX
許可
EX
內文
EX
同意
EX
資產
EX
主體
同意實體允許特定的主體對其擁有的資產作協商與同意的細 節描述。雖非強制，但是強烈建議使用內文實體來給定同意實體 一個唯一的識別碼。一個同意實體必須要包括至少一個「資產」
與「許可」實體在內。假使主體沒有特別指定的話，系統必須從 其他的來源裡面獲取這項資訊。
同意的 XML 範例
ODRL 同意模型可以用 XML 來表達。 例 3- 11 中顯示了一個同 意，它有內文，是主體間對資產的同意描述。
<agreement>
<context>
<uid>doi:10.999/license/20010701/8736282828AAS</uid>
<date><fixed>2001-07-01T10:31:30</fixed></date>
<pLocation>Sydney, Australia</pLocation>
<remark>Transacted by Example.Com</remark>
</context>
<party>
<context> ... </context>
</party>
<asset> ... </asset>
<permission>
...
</permission>
</agreement>
例 3- 11 同意模型的 XML 語法
描述同意的 一段內文
（十） ODRL 的取消模型
ODRL 支援提供實體、同意實體和其他版權描述的取消。
ODRL 取消模型如 圖 3- 10 。
圖 3- 10 ODRL 的取消模型
來源：Iannella, R. (2002,8,8). Open Digital Rights Language (ODRL). Available at:
http://odrl.net/1.1/ODRL-11.pdf
取消實體是由內文實體所聚集成的：
♦ 內文（Context）-該描述的識別碼
取消實體可以讓版權描述裡面的說明書取消，透過在內文裡 面的唯一識別碼（uid） 。識別碼（和識別圖式）必須要能夠被系統 所辨識。
在內文實體中的唯一識別碼（uid）可以被應用在下面任何一 項：
♦ 整個版權表達
♦ 提供（Offers）
♦ 同意（Agreements）
♦ 許可（Permissions）
於是上面所列的任何一個實體，或者是所有實體都可以使用 取消實體來達到取消的功用。如果先前使用了多重表達的方式，
也可以用多重的取消描述，在同一時間內取消。
取消的 XML 範例
ODRL 取消模型可以用 XML 來表達。 例 3- 12 是之前曾經在 例
3- 11 中出現的「同意」描述，我們藉由 uid 中所載的同意實體識別
碼，將先前 例 3- 11 中的同意取消。
<rights>
<revoke>
<context>
EX 取消 EX
內文
<date><fixed>2001-10-30T12:30:30</fixed></date>
<remark>Error in Original Agreement</remark>
</context>
</revoke>
</rights>
例 3- 12 取消的 XML 範例
（十一） ODRL 的加密模型
ODRL 加密模型如 圖 3- 11 所示，它是由額外的 ODRL 實體（有 EX 記號的實體）和有數位簽章的實體（有 DS 記號的實體） 、加 密實體（有 EC 記號的實體）所組成。
圖 3- 11 加密模型
資料來源：Iannella, R. (2002,8,8). Open Digital Rights Language (ODRL).
Available at: http://odrl.net/1.1/ODRL-11.pdf
為了支援描述關於資產加密的資訊，ODRL 定義一個叫做 Digest 的新實體，它是資產實體的子實體。
Digest 實體是設計來保護相關內容與下面子實體的綑綁完整性：
♦ DigestMethod-指出使用來計算 digest 值的演算法。”SHA-1”演算 法必須要被支援。
♦ DigestValue-計算而得的 Digest 的值。
包含一個單一的”Key Info”實體的資產實體可能也會包括：
EC 加密資料
EX 資產 EX 摘要
DS 摘要方法
DS 摘要值
DS 金鑰資訊
DS 金鑰值
DS 金鑰名稱
EC 加密金鑰
DS 金鑰資訊
EC 加密方法
DS 金鑰名稱
DS
X509 資料
DS
SPKI 資料
EC 加密值
DS
X509 憑證
DS
X509 SKI
DS
X509 CRL
DS
SPKI S-Exp
利用 uid 的使用，取 消先前的同意實體
♦ “Key Value”和”Key Name”，或
♦ 多重的”Encrypted Key”子實體。
加密的 Key 實體包含下列子實體：
♦ 加密方法（EncryptionMethod）-指出使用的加密演算法。”RSA”
演算法是一定要支援的。
♦ 密碼文件資料（Cipher Data）-在 CipherValue 子實體中包含未加 工的加密資料。
♦ Key Info-可參照 圖 3- 12 中對數位簽章的介紹來瞭解關於這個實 體的細節。
XML 加密輪廓側寫(XML Encrypted Profile) ODRL 加密輪廓側寫有下列要求限制：
♦ 承認的加密方法為 RSA：
http://www.w3.org/2001/04/xmlenc#rsa-1_5
♦ 承認的鑰匙資訊為 X509Data：
http://www.w3.org/2000/09/xmldsig#509Data
（十二） 數位簽章
ODRL 數位簽章模型如 圖 3- 12 所示，它包含從數位簽章
（有 DS 記號的實體）與加密說明書（有 EC 為記號的實體）
中取出的實體。
圖 3- 12 ODRL 數位簽章模型
來源：Iannella, R. (2002,8,8). Open Digital Rights Language (ODRL). Available at:
http://odrl.net/1.1/ODRL-11.pdf
ODRL 利用 XML 數位簽章說明書裡面的實體，來支援版權描 述的數位簽章。ODRL 表達與簽章都被裝在版權（right）實體內。
簽章實體透過「id」屬性來參照到版權描述。
簽證實體包含了 SignedInfo 實體，而它又有下面三個實體：
1. 標準的方法（CanonicalizationMethod） ：指定標準的演算法可 以應用在 SignedInfo 元素，優先表達簽章的計算結果。
2. 簽章方式（SignatureMethod） ：指出使用來產生簽章的方法。
RSA 是一定要支援的方法。
3. 參照（Reference） ：透過參照連結到版權描述的連結。參照實 體同樣也包含一個轉換（Transform）實體，來指出任何轉換 的要求（封包簽證與 C14N 是被要求一定要按照順序支援 的）。參照實體同樣也包含 DigestMethod 跟 DigestValue 實體
（就像之前在「加密」中所描述的一樣）。
簽章實體除了上述的 SignedInfo 以外，還包括：
♦ 簽章值（SignatureValue）：以 64 位元為基礎編碼的簽章值。
♦ 金鑰資訊（KeyInfo）：這個實體包含了另外三個子實體，分別
EX
權利
DS
簽章
DS
簽章資訊
DS
金鑰資訊
DS
簽章值
DS
參照
DS 標準的方法
DS
簽章方法
DS
轉換
DS
轉換 S
DS
摘要方法
DS
摘要值
DS
SPKI 資料
DS
X509 資料
DS
金鑰名稱
DS X509 證明書
DS
X509 SKI
DS
X509 CRL
DS SPKI S-Exp
是 X509Data、SPKData、KeyName。
KeyName 實體包含一個字串值，是讓簽署者用來傳達關於容 器的解密鑰匙識別碼。
SPKI Data 實體裡面的資訊，包含關聯到 Simple Public Key Infrastructure(SPKI)公共鑰配對、證明書或其他 SPKI 資訊，它含 有 SPKI-Exp 實體，而這是在 SPKI 中標準以 64 位元為基礎編碼的 S-expression。
X509 Data 實體包含下列：
♦ X509 憑證-包含 64 位元為編碼基礎的二進位著名編碼規則
（DER，Distinguished Encoding Rules）X509 V.3 憑證。
♦ X509 SKI-包含 64 位元為編碼基礎的清楚（非 DER 編碼）X509 V.3 SKI 延伸值。
♦ X509 CRL-包含 64 位元為編碼基礎的憑證作廢列表（CRL）。
XML 數位簽章側寫
ODRL 數位簽章側寫是一個具合法性的簽證 （就像[XML-SIG]
中定義的一樣） ，受下列限制：
♦ 承認標準的 XML
♦ 承認 RSA 簽證：
<http://www.w3.org/TR/2000/09/xmldsig#rsa-sha1>
♦ 承認 SHA-1 摘要方法
<http://www.w3.org/TR/2000/09/xmldsig#sha1>
♦ 承認封包簽證與標準的 XML 轉換：
<http://www.w3.org/TR/2001/REC-xml-c14n-20010315>
<http://www.w3.org/TR/2000/09/xmldsig#enveloped-signature>
♦ 承認 X509Data 跟 SPKIData 金鑰資訊
<http://www.w3.org/TR/2000/09/xmldsig#X509Data>
<http://www.w3.org/TR/2000/09/xmldsig#SPKIData>
安全性模型的 XML 範例
ODRL 安全性模型可以用 XML 來表示。 例 3- 13 顯示資產元 素目前擁有適合摘要的加密元素與內容加密金鑰值。 例 3- 14 則顯 示一個已經經過數位簽署的版權描述。這個版權描述的元素都被 置放在 MyRightsData 中的 id。（注意：這裡的 id 屬性跟使用在 context 元素中的 uid 元素並不一樣，雖然他們的值可能相同） 。Id 是被參照元素使用在簽證裡面。轉換元素也同樣指出處理簽證的 XML 描述所要求的演算法。
例 3- 13 跟 例 3- 14 都需要去包含一個最大的 XML 命名空間（以
支援 ODRL、XML 簽證、XML 加密） ，這些都必須清楚地在命名
空間字首先指出。
例 3- 13 安全模型的 XML 語法--加密
加密資訊 說明需要支 援的類型
例 3- 14 加密模型-數位簽章
（十三） 加密的 ODRL 元素
在某些環境裡面，可能僅需要對部分的 ODRL 描述作加 密的動作，而非全份 ODRL。舉例來說，僅讓版權擁有者的版 稅資訊成為機密，不讓他人得知。之前所提到的安全模型便可 以滿足這樣的要求。
對特定的 ODRL 元素作加密可能就像 XML-ENC 的第四 章處理規則。在第二章的[XML-ENC]也提供了一個很好的概 要。ODRL 元素中所記載的清楚文字要受到保護時，將會以產 生加密的 XML 結構來代替。然而分享用來保護這些元素的金 鑰已經超出 ODRL 的範疇，必須讓相關的主體自行控制。
數位簽章
加密資訊
（十四） 描述的容器
ODRL 描述語言同樣也支援一些用容器以群組實體的機 制。在容器內的群組必須要有清楚的語意，且必須能夠被支援。
這裡有三種經過定義的群組機制：
1. And：所有的實體都必須要被支援或認可
2. Exclusive Or：只有其中一個實體必須被支援/認可 3. Inclusive Or：其中一個或多個實體必須被支援/認可
「容器(container)」這種新結構被用來聚集其他的實體，達到 上述三種群組機制其中的一種功用。容器裡有一個屬性叫做「類 型(type)」（有固定值：and、ex-or、in-or），以指定容器的類型。
預設的容器類型是 and。另外，當沒有容器結構被使用的時候，預 設值 and 將會是隱藏的。
容器的語意只應用在直接的容器分支。傳統上，容器結構用 來集合許可、限制、條件與要求，但他也可以被用在裝載其他的 實體。
容器的 XML 範例
ODRL 容器結構可以用 XML 來表達。在例 14 中所顯示的例
子，是一個播放的許可，但是限制了 CPU 或儲存裝置，並提供兩
種付費選擇--預付澳幣兩百元或者是每次使用的時候都支付一點
五澳幣。
例 3- 15 容器的 XML 範例
（十五） 表達連結
ODRL 表達語言同樣也支援明確的連結表達區塊的能 力。在表達區塊之間的連結不僅應包含明確的語意，而且必須 獲得支援。連結讓 ODRL 表達可以重複利用已經存在的表達 句來建構新的表達，並允許區塊間有明確的連結。每一個 ODRL 區塊都可以使用 id 這個屬性作為唯一識別，且可參照 到 idref 屬性。
在一般的案例中，出現在 ODRL 版權描述裡面的實體都 被假定是相關的。也就是說，許可實體與一個資產實體是被假 定相關的（例如：在表達中，許可與資產的關係將是，該許可 是相關於該資產的許可） 。當一個明確的連結被使用，那麼這 個連結將具備優先權。在下一個段落中將顯示出這些案例是如 何被表達的。
連結的 XML 範例
ODRL 連結架構可以用 XML 來表示。 例 3- 16 中的例子顯 示出一個對應到 ASSET-01 的銷售許可跟同時對應到
ASSET-01 跟 ASSET-02 的借出許可。
付款的兩種選擇，分 別以兩個容器裝載
例 3- 16 連結的 XML 範例
（十六） 表達繼承
ODRL 表達語言支援將資產間的繼承能力描述列入到說 明書中。也就是允許母/子間的關係被定義。
子資產元素可以將繼承(inherit)元素給包含進來，以便指 出從哪一個母資產中繼承得到該權利。所有的母資產權利都將 會與子資產權利作合併。在合併的過程中，必須要小心不得讓 版權表達產生衝突。
繼承的元素有「無效(override)」屬性給子資產，無效屬性 為真時，就放棄繼承母資產的權利，而會另外定義自己的權 利。但預設值為偽。所以當子資產中無效屬性不成立時，子資 產將會繼承母資產的權利。
預設元素同樣也有個「不履行(default)」屬性給母資產，
假使為真的話將不允許子資產撤銷來自母資產的權利。但預設 值為偽。要注意的是， 「無效」與「不履行」不能同時為成立。
繼承的 XML 範例
ODRL 繼承結構可以用 XML 來表達。 例 3- 17 中，第一個 權利表達，指定對識別的資產有播放的許可。第二個權利描
提供的兩個資產中，資產一 是擁有銷售許可及借出許可 的，資產二則擁有借出許可
別的資產處獲得繼承。
這段表達同時也指出不去忽視繼承的權利（預設值） ，因 此，第二個資產的完整權利包含了播放與許可給予。假使第二 個表達確實忽略了繼承的權利，那麼僅僅只有第二個資產的給 予許可而已。
例 3- 17 繼承的 XML 範例
由上面的描述裡，可以觀察到的是每一個實體都擁有自己發 揮作用的模型，為了讓描述可以更方便，繼承與連結也都被考慮 進去，實體的重複使用性相當高。另外不難得知的是，在 ODRL 裡面，相當強調的一點是實體必須能夠被系統識別才能夠授予，
權利也很謹慎小心地不作擴充解釋。
繼承上一段描述所 給予的播放權利
