ODRL Requirement 1.13 - Issues List

"Expressing Permissions/Constraints for each member of a group."

Last modified: 1st December 2004

Editor(s): The ODRL Initiative

Back to Requirements Document.

Specification Draft:

The ODRLv2 allows for expressing permissions for each member of a group.

Issue Summary:

This is the list of issues the ODRL Initiative has considered, when addressing the respective requirement (see above).

Issue Details:

• issue01 - Where to express the One2Many relation?
  

  Solution approaches:

  • Within the permission element the Grantee/Beneficiary element refers to whether the stated permission is granted "(once) per group" or "(once) per member". The group is identified by an id like a single party. If the "Beneficiary" element is chosen within the permission element, the permission is only granted once, i.e. which ever member of the group executes the usage permission first gets access. If the "Beneficiaries" element is chosen, this implies that the resp. beneficiaries id is a group and the permission is granted per member. Code Example:
    The following play permission is exclusively granted once per group.

             <o-ex20:permission assigner="party99">  
               <o-ex20:play/>
               <o-ex20:object>asset01</o-ex20:object>
               <o-ex20:beneficiary id="group01"/>
               <o-ex20:hasConstraint id="c01"/>
             </o-ex20:permission>
    

    The following play permission is exclusively granted once for each member of the group.

             <o-ex20:permission assigner="party99">  
               <o-ex20:play/>
               <o-ex20:object>asset01</o-ex20:object>
               <o-ex20:beneficiaries id="group01"/>
               <o-ex20:hasConstraint id="c01"/>
             </o-ex20:permission>
    

             <o-ex20:constraint id="c01">  
               <o-ex20:count>
                <o-ex20:max>1</o-ex20:max>
               </o-ex20:count>
             </o-ex20:constraint>
    

  • Similar to first solution approach but more flexible. The beneficiary element gets an extra attribute "granularity" that states "perGroup" or "perMember" and allows for granularity that we did not think of. The following permission assignes the right play twice for each member of the group.
    

             <o-ex20:permission assigner="party99">  
               <o-ex20:play/>
               <o-ex20:object>asset01</o-ex20:object>
               <o-ex20:beneficiary granularity="perMember" id="group01"/>
               <o-ex20:hasConstraint id="c01"/>
             </o-ex20:permission>
    

    
    

             <o-ex20:constraint id="c01">  
              <o-ex20:count>
               <o-ex20:max>2</o-ex20:max>
              </o-ex20:count>
             </o-ex20:constraint>