Ieee trial use recommended practice for digital rights expression languages (drels) suitable for ele

IEEE Computer Society

1484.4

TM

IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

Sponsored by the Learning Technology Standards Committee

IEEE 3 Park Avenue New York, NY 10016-5997, USA

IEEE Std 1484.4â„¢-2007

14 September 2007

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4TM-2007

IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

Sponsor Learning Technology Standards Committee of the IEEE Computer Society

Approved 22 March 2007

IEEE-SA Standards Board

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

Grateful acknowledgement is made to Susanne Guth, Manual Ham, John Mason, and Thomas Provert for permission to use their papers in the informative annexes of this document.

Abstract: This recommended practice facilitates the creation, management and delivery of digital content for eLearning by technology that implements Digital Rights Expression Languages (DRELs). This recommended practice determines what, if any, extensions are needed so that these DRELs can meet the identified requirements.

Keywords: Digital Rights Expression Language, DREL, MPEG-21, Open Digital Rights Access, Open eBook Forum, ODRL, Rights Expression Language, REL

________________________ The Institute of Electrical and Electronics Engineers, Inc. 3 Park Avenue, New York, NY 10016-5997, USA Copyright Š 2007 by the Institute of Electrical and Electronics Engineers, Inc. All rights reserved. Published 14 September 2007. Printed in the United States of America.

IEEE is a registered trademark in the U.S. Patent and Trademark Office, owned by the Institute of Electrical and Electronics Engineers, Incorporated.

Adobe and Photoshop are registered trademarks of Adobe Systems Incorporated in the United States and/or other countries.

Print: PDF:

ISBN 0-7381-5601-9 ISBN 0-7381-5602-7

SH95686 SS95686

No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission of the publisher.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating Committees of the IEEE Standards Association (IEEE-SA) Standards Board. The IEEE develops its standards through a consensus development process, approved by the American National Standards Institute, which brings together volunteers representing varied viewpoints and interests to achieve the final product. Volunteers are not necessarily members of the Institute and serve without compensation. While the IEEE administers the process and establishes rules to promote fairness in the consensus development process, the IEEE does not independently evaluate, test, or verify the accuracy of any of the information contained in its standards.

Use of an IEEE Standard is wholly voluntary. The IEEE disclaims liability for any personal injury, property or other damage, of any nature whatsoever, whether special, indirect, consequential, or compensatory, directly or indirectly resulting from the publication, use of, or reliance upon this, or any other IEEE Standard document.

The IEEE does not warrant or represent the accuracy or content of the material contained herein, and expressly disclaims any express or implied warranty, including any implied warranty of merchantability or fitness for a specific purpose, or that the use of the material contained herein is free from patent infringement. IEEE Standards documents are supplied “AS IS.�

The existence of an IEEE Standard does not imply that there are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to the scope of the IEEE Standard. Furthermore, the viewpoint expressed at the time a standard is approved and issued is subject to change brought about through developments in the state of the art and comments received from users of the standard. Every IEEE Standard is subjected to review at least every five years for revision or reaffirmation. When a document is more than five years old and has not been reaffirmed, it is reasonable to conclude that its contents, although still of some value, do not wholly reflect the present state of the art. Users are cautioned to check to determine that they have the latest edition of any IEEE Standard.

In publishing and making this document available, the IEEE is not suggesting or rendering professional or other services for, or on behalf of, any person or entity. Nor is the IEEE undertaking to perform any duty owed by any other person or entity to another. Any person utilizing this, and any other IEEE Standards document, should rely upon the advice of a competent professional in determining the exercise of reasonable care in any given circumstances.

Interpretations: Occasionally questions may arise regarding the meaning of portions of standards as they relate to specific applications. When the need for interpretations is brought to the attention of IEEE, the Institute will initiate action to prepare appropriate responses. Since IEEE Standards represent a consensus of concerned interests, it is important to ensure that any interpretation has also received the concurrence of a balance of interests. For this reason, IEEE and the members of its societies and Standards Coordinating Committees are not able to provide an instant response to interpretation requests except in those cases where the matter has previously received formal consideration.

At lectures, symposia, seminars, or educational courses, an individual presenting information on IEEE standards shall make it clear that his or her views should be considered the personal views of that individual rather than the formal position, explanation, or interpretation of the IEEE. Comments for revision of IEEE Standards are welcome from any interested party, regardless of membership affiliation with IEEE. Suggestions for changes in documents should be in the form of a proposed change of text, together with appropriate supporting comments. Comments on standards and requests for interpretations should be addressed to: Secretary, IEEE-SA Standards Board 445 Hoes Lane Piscataway, NJ 08854 USA Authorization to photocopy portions of any individual standard for internal or personal use is granted by the Institute of Electrical and Electronics Engineers, Inc., provided that the appropriate fee is paid to Copyright Clearance Center. To arrange for payment of licensing fee, please contact Copyright Clearance Center, Customer Service, 222 Rosewood Drive, Danvers, MA 01923 USA; +1 978 750 8400. Permission to photocopy portions of any individual standard for educational classroom use can also be obtained through the Copyright Clearance Center.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

Introduction This introduction is not part of IEEE Std 1484.4-2007, IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies.

The Digital Rights Expression Languages Working Group (DRELs WG) of the IEEE LTSC was formally established in March 2003 at the Paris quarterly meeting of the LTSC and was initially co-chaired by Juliette Adams. This followed a series of study group meetings held throughout 2002 that investigated both DRELs and Digital Rights Management (DRM) in relation to the needs of learning, education, and training. With a view to constraining the problem space and minimizing stakeholder confusion, the WG developed a project proposal that focused only on DRELs. The resulting Project Authorization Request (PAR) was accepted on 14 April 2003.

During the agreed work program, it became clear that the need for DRELs within education and training communities worldwide is still at an embryonic stage. However, while the sector has voiced its strong need for DRELs, it has not, as yet, identified unique requirements that current DRELs cannot satisfy. This reflects the state-of-play within the eLearning industry where learning technologies associated with pedagogy, process, and learning activities are still largely in the research and development phase. This does not mean that such requirements may not exist, but they have not been explicitly identified in this trial use recommended practice.

The working group gathered a series of use cases that were submitted following the initial call for contributions issued on 2 June 2003. These use cases are detailed in Annex A. Most use cases were provided by stakeholders who have not yet implemented DRM systems but who are keen to make use of them. From these use cases, the WG then extracted a number of requirements, which are included in the normative section of this document (see Clause 2).

In order to align these requirements with existing rights expression languages, the WG received three language mappings, including MPEG REL, formally known as ISO/IEC 21000-5:2004; the open eBook Forum (OeBF) profile of MPEG REL; and, Open Digital Rights Language (ODRL) (see Annex A, Annex B, and Annex C). Based on these mappings and reviews thereof, the working group produced a table summarizing which requirements are met by each language mapping.

This trial-use recommended practice aims to provide a basis from which stakeholders within learning, education, and training can make informed decisions about their DREL needs.

Notice to users Errata Errata, if any, for this and all other standards can be accessed at the following URL: http:// standards.ieee.org/reading/ieee/updates/errata/index.html. Users are encouraged to check this URL for errata periodically.

Interpretations Current interpretations can be accessed at the following URL: http://standards.ieee.org/reading/ieee/interp/ index.html.

iv Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

Patents Attention is called to the possibility that implementation of this recommended practice may require use of subject matter covered by patent rights. By publication of this recommended practice, no position is taken with respect to the existence or validity of any patent rights in connection therewith. The IEEE shall not be responsible for identifying patents or patent applications for which a license may be required to implement an IEEE standard or for conducting inquiries into the legal validity or scope of those patents that are brought to its attention.

Publication of this trial-use recommended practice for comment and criticism has been approved by the Institute of Electrical and Electronics Engineers. Trial-use standards are effective for 24 months from the date of publication. Comments for revision will be accepted for 18 months after publication. Suggestions for revision should be directed to the Secretary, IEEE-SA Standards Board, 445 Hoes Lane, P.O. Box 1331, Piscataway, NJ 08855-1331, and should be received no later than 22 February 2009. It is expected that following the 24-month period, this trial-use standard, revised as necessary, shall be submitted to the IEEE-SA Standards Board for approval as a full-use standard.

Participants At the time this standard was completed, the working group had the following membership: Magda Mourad, Chair Jon Mason, Technical Editor Juliette Adams (Initial co-Chair) Leah Berkhoff Stephen Downes Rachel Ellaway Kameshwar V. Eranki Mike Fore Brad Gandee Serge Goldstein

Susanne Guth Manuel Ham Tim Hand Chad Kainz Wilbert Kraan Sam Meredith Kiyoshi Nakabayashi

Martha Nalebuff Florian Pestoni Harry Piccariello Thomas Probert Daniel R. Rehak Robby Robson Steve Sarapata Bernd Simon

The following members of the individual balloting committee voted on this standard. Balloters may have voted for approval, disapproval, or abstention.

Satish K. Aggarwal Kerry E. Blinco Juan C. Carreon Keith Chow Tommy P. Cooper Geoffrey Darnton Thomas J. Dineen Kameshwar V. Eranki Yaacov Fenster Geoffrey A. Frank Ron K. Greenthaler Randall C. Groves

Shui H. Heung Rutger A. Heunks Nancy Hoebelheinrich Werner Hoelzl Dennis Horwitz Arshad Hussain Peeya Iwagoshi Robert B. Kelsey Susan K. Land Solomon Lee Yeou Song Lee William Lumpkins

G. L. Luri David A. Massart Richard A. McBride Michael S. Newman Claude Ostyn Vikram Punj Daniel R. Rehak Randall M. Safier Scott A. Valcourt Derek T. Woo Paul R. Work Oren Yuen

v Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

When the IEEE-SA Standards Board approved this recommended practice on 22 March 2007, it had the following membership: Steve M. Mills, Chair Robert M. Grow, Vice Chair Don Wright, Past Chair Judith Gorman, Secretary Richard DeBlasio Alex Gelman William R. Goldbach Arnold M. Greenspan Joanna N. Guenin Julian Forster* Kenneth S. Hanus William B. Hopf

Richard H. Hulett Hermann Koch Joseph L. Koepfinger* John Kulick David J. Law Glenn Parsons Ronald C. Petersen Tom A. Prevost

Narayanan Ramachandran Greg Ratta Robby Robson Anne-Marie Sahazizian Virginia C. Sulzberger Malcolm V. Thaden Richard L. Townsend Howard L. Wolfman

*Member Emeritus

Also included are the following nonvoting IEEE-SA Standards Board liaisons: Satish K. Aggarwal, NRC Representative Alan H. Cookson, NIST Representative

Jennie M. Steinhagen IEEE Standards Program Manager, Document Development

Michael D. Kipness IEEE Standards Program Manager, Technical Program Development

vi Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

Contents

1. Overview .....................................................................................................................................................1 1.1 Scope ....................................................................................................................................................1 1.2 Purpose .................................................................................................................................................1 1.3 Special terms ........................................................................................................................................1 1.4 Acronyms and abbreviations ................................................................................................................2 2. Functional requirements for eLearning technologies ..................................................................................2 2.1

Attributes of the Digital Rights Expression Language ....................................................................3

2.2

Aggregation and disaggregation of learning objects .......................................................................3

2.3

Attribution .......................................................................................................................................4

2.4

Conditional use................................................................................................................................4

2.5

Tracking...........................................................................................................................................5

2.6

Offers...............................................................................................................................................5

3. Issues ..........................................................................................................................................................5 3.1 Requirements analysis ...........................................................................................................................5 3.2 Practitioner feedback .............................................................................................................................6 Annex A (informative) Use case requirements ...............................................................................................7 Annex B (informative) Historical background..............................................................................................20 Annex C (informative) Mapping requirements to ODRL .............................................................................27 Annex D (informative) Mapping requirements to MPEG REL ....................................................................57 Annex E (informative) Mapping requirements to OeBF...............................................................................93

vii Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies 1. Overview 1.1 Scope This recommended practice identifies digital rights (DR) requirements for eLearning technologies. These requirements should be aligned with the most widely known standards-based specifications for Digital Rights Expression Language (DREL) that are being adopted or developed by international, regional, national, and private organizations and consortia.

1.2 Purpose This recommended practice facilitates the creation, management, and delivery of digital content for eLearning by technology that implements DRELs. This recommended practice should determine what, if any, extensions are needed so that these DRELs can meet the identified requirements.

1.3 Special terms For the purposes of this recommended practice, the following special terms apply: 1.3.1

content: Any resource that can be regarded as “containing” information and is independent of its structure and presentation.

1.3.2

Digital Rights Expression Language (DREL): A language in which expressions of permissions and conditions are specified to control the distribution or use of learning objects. The use of a DREL is one tool that is used in DRM systems. The functional requirements of a DREL are the main focus of this document.

1.3.3

Digital Rights Management (DRM): A broad term used to describe a process or a system for managing digital rights associated with digital content. DRM covers a wide range of activities including (but not limited to) the following: — — —

Use of a digital rights expression language Authentication of rights expressions, devices, users, and resources Association of rights expressions to digital content

1 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

—

Protection of digital content from being used without rights

NOTE—It is important to note that the requirements for a DRM system are out of scope for this document. 1

1.3.4

learning content: Any material useful for creating, managing, or facilitating a learning experience regardless of medium, structure, or commercial status.

1.3.5

learning object: A term that has been defined very broadly by the IEEE LTSC in IEEE Std 1484.12.1 2 for the purposes of creating metadata. Operationally, however, it is a term that has been widely adopted and used to distinguish digital assets that have some kind of learning objective and/or assessment associated with them. It is used in this latter sense in Clause 2.

1.3.6

rights: Expressions that describe such things as permissions and conditions that are typically associated with the use of content.

1.4 Acronyms and abbreviations DREL DRM ICT LET LO LOX LTSC MPEG ODRL OeBF PAR REL RTO SCORM WG

Digital Rights Expression Language Digital Rights Management Information and Communications Technology learning, education, and training learning object Learning Object Exchange Learning Technology Standards Committee Motion Pictures Experts Group Open Digital Rights Language Open eBook Forum project authorization request Rights Expression Language Registered Training Organization Sharable Content Object Reference Model working group

2. Functional requirements for eLearning technologies The functional requirements derived from the use cases specified (see Annex A) are classified into the following six groups: — — — — — —

Attributes of the DREL Aggregation and disaggregation of learning objects Attribution Conditional use Tracking Offers

While traditional learning, education, and training (LET) environments can often be characterized by large cohorts and heterogeneous communities sharing and reviewing materials at various levels of resource granularity such activities have not been in the interests of traditional content producers. Thus, rights expressions for LET stakeholders can be seen as largely associated with the lifecycle of content (such as learning objects).

1

Notes in text, tables, and figures are given for information only and do not contain requirements needed to implement the standard.

IEEE Std 1484.12.1™-2002, IEEE Standard for Learning Object Metadata, is available from the Institute of Electrical and Electronics Engineers, 445 Hoes Lane, Piscataway, NJ 08855-1331, USA.

2

2 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

In general terms, the requirements gathered for this trial-use recommended practice have all been largely framed in terms of expressing rights associated with content.

NOTE—It is recognized that as rights-enabled infrastructure becomes widely deployed over time, new requirements may emerge. An important consideration is that eLearning Technologies involve engagement of learners (and related stakeholders) with processes and applications as well as content. Rights expression may apply to any form of content not just learning objects e.g., raw assets and metadata instances.

2.1

Attributes of the Digital Rights Expression Language

The following are the attributes of the DREL: 2.1.1

The DREL should be based on a formal grammar.

2.1.2

The DREL should allow the specification of constraints that persist when a learning object is updated or new version is released.

2.1.3

The DREL should support the articulation of roles undertaken by users. For example, a user may be associated with the role of “instructor” for an identified learning object.

2.1.4

The DREL should support the use of unique identifiers when they exist for learning objects.

2.1.5

The DREL should support a single rights expression to apply to a class of learning objects. The DREL should therefore support class definitions and affiliations.

2.1.6

The DREL should be extensible and allow alternative schemas wherever sensible to meet the future needs of the learning, education, and training community.

2.1.7

The DREL should define a minimal core set of primitive constructs from which all other expressions can be constructed or derived. For example, instead of defining pay-per-view, rent-toown, and other such models, the core should provide the fundamental building blocks to link constraints (e.g., payment) to actions to allow constraints to repeat according to various criteria, provide metering syntax, etc.

2.1.8

The DREL should support the specification of constraints that can be used as defaults.

2.2 Aggregation and disaggregation of learning objects Learning objects may be created through aggregation into more complex learning objects. Constraints may be associated with the learning objects employed in such aggregations allowing the learning objects to be reused. Therefore 2.2.1

The DREL should allow the specification of constraints for the aggregation of content within learning objects.

2.2.2

The DREL should allow the specification of constraints for the disaggregation of content within learning objects.

2.2.3

The DREL should allow the specification of constraints that must be preserved and propagated under aggregation.

2.2.4

The DREL should allow the specification of constraints for the use of the aggregated learning objects.

3 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

2.2.5

The DREL should allow specification of constraints associated with different levels of granularity in an aggregated learning object.

2.2.6

The DREL should allow specification of different schemes to uniquely identify different portions of an aggregated learning object to which constraints apply.

2.2.7

The DREL should allow the specification of constraints requiring the retention of specific metadata as an integral component of a learning object regardless of source.

2.3 Attribution Learning objects may be created from other learning objects and may require attribution. Therefore 2.3.1

The DREL should allow the specification of attribution constraints associated with the use associated with specific uses of learning objects.

2.4 Conditional use The use of learning objects and other content is sometimes subject to the following conditions of use: 2.4.1

The DREL should allow for the specification of a set of conditions that must be fulfilled before a right (or set of rights) can be exercised.

2.4.2

The DREL should allow the specification of different kinds of constraints for access to learning objects for different individual users, categories of users, and circumstances as applicable.

2.4.3

The DREL should allow specification of constraints limiting the number of times learning objects can be used, accessed, distributed, and/or replicated.

2.4.4

The DREL should allow the specification of connectivity-based constraints, e.g., online or offline use of learning objects.

2.4.5

The DREL should allow specification of device-based constraints to restrict the use of content to a single computer or a group of computers.

2.4.6

The DREL should allow the specification of anonymous access to learning objects.

2.4.7

The DREL should allow the specification of usage rights to learning objects for educational, research, and scholarly purposes such as Fair Use. This may include declarations applying Fair Use policies.

2.4.8

The DREL should allow the specification of constraints associated with policies that may apply to individuals or groups. Policies may be context specific.

2.4.9

The DREL should allow the specification of constraints associated with multi-tiered distribution, e.g., instances where learning objects are distributed by one entity that redistributes to other entities, of learning objects.

2.4.10

The DREL should support the unambiguous specification of time-based constraints such as specific times, fixed intervals, sliding intervals, and metered intervals that can span across different time zones.

2.4.11

The DREL should support the specifications of fees according to standard terms and conditions.

4 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

2.4.12

The DREL should support limiting rights to portions of learning objects.

2.4.13

The DREL should support distribution and management of free learning objects.

2.4.14

The DREL should support specifying a price, including a price of “free,” for unlimited usage of a learning object.

2.4.15

The DREL should support the specification of payment of a fee for each use of a learning object that may be constrained by connectivity-based conditions, e.g., connection to an online service, web portal, and web service.

2.4.16

The DREL should support subscription-based pricing and access to learning objects.

2.4.17

The DREL should support time-based pricing rules for learning objects.

2.4.18

The DREL should support the specification of learning object usage under a site-license.

2.4.19

The DREL should support the specification of constraints related to the manner in which the use of a learning object is supervised, e.g., a teacher supervises taking a test.

2.5 Tracking In some cases, usage of learning objects may need to be tracked.

2.5.1

The DREL should allow the specification of requirements for tracking access, usage, distribution, and purchase of content.

2.6 Offers The ability to offer learning objects to individuals or groups of people is important within the learning, education, and training community. The offers themselves can be subject to a variety of conditions such as fees, time, membership, etc. Furthermore, offers can specify additional constraints on the use of the learning object being offered.

2.6.1 The DREL should allow the specification of offers. Both the offers and the use of the learning objects may be subject to constraints.

3. Issues 3.1 Requirements analysis In the course of completing the tasks associated with the PAR an issue arose that was not resolved by the WG: “How are digital objects that extend beyond content supported by the DRELs?” This question arises because in the learning, education, and training community there are ‘digital objects’ such as software applications that may be subject to usage control. For example, Adobe® Photoshop® has hundreds of functions such as auto-color, auto-brightness, image-size, crop, etc. 3 Are these application functions to be controlled through the use of a DREL? Or are they out of scope? In fact, the scope statement within the PAR (“Digital Rights requirements for eLearning technologies”) could be read more broadly than the statement of purpose (“to facilitate the creation, management, and delivery of digital content for eLearning 3

The following information is given for the convenience of users of this standard and does not constitute an endorsement by the IEEE of these products. Equivalent products may be used if they can be shown to lead to the same results.

5 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

by technology that implements digital rights expression languages”). The WG made the programmatic decision to focus the scope of this document on DREL for digital content.

3.2 Practitioner feedback The WG also received some comments and feedback after initial deadlines indicating that further rights expressions could be made that would be of benefit in library contexts. In particular, a distinction was drawn between the use of “view” and “lend,” where “view” can be seen to depend on an “obtain” action that is largely invisible when accessing digital materials via the Web. This is particularly important in situations where libraries may lend ebooks. Two further rights expressions were suggested. They are as follows: — “The DREL should support the transfer of some rights to a user without increasing the number of usable copies of the resource. [one copy, one user] — The DREL should support time-based rights that revert to the original rights holder at expiration. [lending]”

6 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

Annex A (informative) Use case requirements Table A.1 represents a compilation of requirements, articulated as use cases, that were gathered from stakeholders following a Data Call on 2 June 2003. These use cases have been matched with (an) appropriate DREL statement(s).

Table A.1–Use case requirements General description use case Students and instructors engaged in eLearning activities access and process content from multiple sources. Sometimes this may mean aggregating components of a learning object with components of another learning object.

Researchers want to make the output of their scholarship freely available while also wanting to do so under certain conditions, primarily associated with attribution.

#

Requirement name

Education/Training requirement

DREL requirement

1

Multiple Sources of Aggregated Content

Documents (and environments) in education and training are often aggregated from multiple sources. Rights need to be aggregated in a sensible fashion.

1. The DREL shall allow content owners specify permissions to allow their content to be embedded/aggregated within other learning objects.

2. The DREL shall allow content owners to specify the permissions and conditions that must be preserved when content is aggregated.

3. The DREL shall support the aggregated permissions and conditions for the aggregated learning objects.

1.1

Heterogeneous copyright constraints

Same as requirement for #1.

Rights expressions must be able to carry information from multiple sources.

1.2

Rights roll-up rules

Aggregation of content is done under license and in cases where it is not otherwise specified the aggregation has the constraints of the aggregated element with the most restrictive rights. In other words, the restriction propagates upward into the aggregation.

Rights expressions should be able to express “rights roll-up rules.”

2

Attribution and other Creative Commons notions

In education and training, it is desirable to express Creative Commons licenses, including those addressing attribution, non-commercial use, etc.

1. Expressions of specific types of conditions and permissions are resolved through a data dictionary. A standardized extension of the dictionaries that “come with” MPEG REL and ODRL are required.

2. The DREL shall allow content owners to specify permissions to allow anyone to view scholarly output for free.

3. The DREL shall allow content owners to specify permissions to allow anyone to extract portions of their scholarly output as long as the stated attribution is made in the resulting learning object.

7 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

Table A.1–Requirements use cases (continued)

General description use case

#

Requirement name

Education/Training requirement

DREL requirement

IP rights are applicable to any form of digital resource— from data to single files to learning objects and clusters of objects, etc.

3

Granularity of Content

Rights associated with modular content are handled at various levels of aggregation—raw assets (such as text files, graphics, images, etc), newsfeeds, learning objects, clusters of learning objects, courses, and metadata

1. The DREL shall allow content owners to specify rights expressions that support different levels of content granularity. (NOTE—This may need to be supported by a taxonomy of content types.)

2. The DREL shall support rights expressions for aggregated objects.

3. The DREL should allow the specification of constraints that must be preserved and propagated under aggregation.

Rights associated with learning objects persist through subsequent updates, where some of these updates are not performed by the original rights holder.

3.1

Versioning of learning objects

Same as requirement as listed in #3.

Covered in #1 and #1.1

A student or teacher downloads a learning object that is protected by a single download-per-user policy to use offline on their home computer. This LO cannot be disaggregated or forwarded.

4

Single use and offline use

Offline and home use.

1. The DREL shall support rights expressions intended for an individual user or for groups of users.

2. The DREL shall support countbased conditions to restrict the number of times content can be used.

3. The DREL shall support devicebased conditions to restrict the use of content to a single computer or a group of computers.

4. The DREL shall support connectivity-based conditions to ensure that content is used online or offline.

Systems designers will want a means of separating the declaration of rights from the enforcement of rights. They may wish this because they do not wish to pay for, or encumber, a system with enforcement mechanisms.

Thus, “do not copy” in one context may be distinct from “do not copy” in another context, such that in the former an enforcement mechanism, such as specialized non-copy software is required, while in the latter, no such software is required.

5

Separating Declaration from Enforcement

The context of a usage cannot always be predicted.

However, where it can, and enforcement of rights is a desired outcome context of usage is important. In other contexts, it may be more appropriate just to view a declaration of rights.

1. The separation appears to happen naturally since DRELs do not actually perform the enforcement.

2. Rights expression in DREL shall support consistent interpretation across applications.

3. The DREL shall be based on a formal grammar and standardized nomenclature.

8 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

Table A.1–Requirements use cases (continued)

General description use case

#

Requirement name

Education/Training requirement

DREL requirement

When purchasing content purchasers will want to be able to express choice of provider. This is expressed in the following ways: (1) they may wish to opt for one, rather than another, distributor of a given bit of content; (2) they may wish to opt for one, rather than another, payment processing agency; (3) they may wish to opt for one, rather than another, personal profile or authentication agency.

6

Choice of Providers in supply chains

When purchasing content, purchasers will want to be able to express choice of provider. This is expressed in several ways: they may wish to opt for one, rather than another, (1) distributor of a given bit of content; (2) payment processing agency; or (3) personal profile or authentication agency.

Possible need for rights policies that apply to categories of content or groups of people (see use case #6.1).

Rights policies can grant a specific set of permissions and conditions to a group of people or to a category of resources. For example, a server repository can have this policy: “university students” can view “university-owned ebooks.”

When a student named Alice requests access to an ebook called Solstice, the student gets the resulting license derived from the rights policy: “Alice can view Solstice.”

6.1

Support rights policies that apply to categories of content or to groups of people

Same as requirement for #6

The DREL shall support the specification of context specific rights applying to policies. e.g., Fair Use policies may be context specific

Anonymous access to content should be the default, rather than the exception (much in the way that one normally buys a book anonymously).

7

Anonymous access

In much the same way that one normally buys books, anonymously accessing digital content should not be unnecessarily encumbered by having to submit personal information.

The DREL shall support rights expressions to specify that “anyone” can use the specified content REL should be able to allow anyone to anonymously access content.

Potential purchasers will want to be able to access and read reviews and other evaluations of learning material before making a purchase decision; this information needs to be made available at the point of sale.

8

Read reviews and evaluations

Reading reviews and other evaluations of learning material before making a purchase decision is a typical requirement of learners, educators, and trainers.

Trial usage (preview with certain conditions); relatedness to other objects (reviews, evaluations, other LOs, etc.). The ability for a rights holder to offer a free preview of the content must be supported by the DREL and this is covered in use case #4.

9 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

Table A.1–Requirements use cases (continued)

General description use case

#

Requirement name

Education/Training requirement

DREL requirement

Purchasers will want to be able to compare, side-by-side and in the same environment, content that is offered for free with content that is offered for sale; it follows therefore that the mechanisms used to market, distribute and license commercial content cannot impose an encumbrance on free materials offered through the same system (for it would then no longer be possible to offer free materials in this system, and thus, would grant a monopoly of the system to materials offered for sale).

8.1

Evaluating procurement options

Evaluating learning material prior to its procurement is a typical requirement of learners, educators, and trainers. Ideally, determining outcomes should not be “predetermined” by constraints of whether this material is “for free” or “for purchase.”

The DREL shall allow rights holders to specify that portions or entire content be previewed by specific users also covered in use case #4.

A small producer of content would like to offer content for sale without investing in user authentication and similar mechanisms. This producer hopes and expects to have “right of access” to markets. In other words, the provisions for DRM should not explicitly or implicitly contain the means to lock out competing producers.

9

Basic content offer

Learners, educators, and trainers all produce content and sometimes may wish to offer it for sale without wanting to deal with complex mechanisms of tracking its use.

1. The DREL shall allow content owners to offer for free the permission to view a learning object.

2. The DREL shall allow content owners to offer for a fee the permissions to view and print (without additional restrictions) a learning object.

3. The DREL shall allow content owners the ability to specify tracking conditions when content is used.

A researcher offers his/her content very cheap (or for free) to the role “student,” but a little bit more expensive for the role “teacher.”

10

Matching offers with roles

Matching offers with roles already takes place in many ways - with journal subscriptions or conference registrations, for example.

1. The DREL shall allow rights holders to specify offers for free or with condition to permit the use of learning objects to groups of people with specific roles such as student, teacher, club member, journal subscriber, etc.

2. The DREL shall support the specification of rights expressions associated with activities or roles defined in a formal taxonomy.

A researcher offers his/her content to teachers that are members of a certain group (for example teachers of the same university) much cheaper, than to teachers that are not members of the group. The requirement here would be to define an attribute e.g., group, and think about reasonable values for this attribute.

10.1

Matching offers with roles

Matching offers with groups of persons/roles.

Same as requirement for use case #10.

10 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

Table A.1–Requirements use cases (continued)

General description use case

#

When granting rights to other people, it is of interest for the authors, on what “level in the educational hierarchy” the other people are—e.g., professors are above assistant professors and teaching assistants. Assistant professors are above PhD students and so on. Authors tend to grant more permissions to people that are on the same hierarchical level and we can draw some relations to knowledge management here.

10.2

Expressing rights associated with a wide variety of content.

Requirement name

Education/Training requirement

DREL requirement

Matching offers with roles (3).

Matching offers with groups of persons/roles requires identification for the role of the consumer, and a vocabulary expressing such roles.

Same as requirement for use case #10.

11

Accommodating diverse content types

In education and training settings, there is wide (and increasing) diversity in content types (texts, simulations, animations, video, etc.).

Not specified.

Situations such as the “booking” of content use operate most efficiently when an alert mechanism for this is triggered.

12

Alerting

There are many situations where it is desirable to provide an alert mechanism for the access to or use of content.

Not specified.

Software developers of open source educational technology need to be able to incorporate DREL techniques and code that is compatible with major open source licenses, such as the GPL, the LGPL, MIT, BSD, and Apache.

13

Open source licenses

An increasing amount of educational software is developed under a range of open source licenses.

License restrictions on the DREL that are not compatible with the major open source software licenses will mean that the uptake of a DREL will be severely limited, and possibly fragmented.

An increasing amount of educational software is developed under a range of open source licenses. License restrictions on the DREL that are not compatible with the major open source software licenses will mean that the uptake of a DREL will be severely limited, and possibly fragmented.

Australian K-12 authorities wish to facilitate a streamlined approach to eLearning where constraints associated with the use of content do not interrupt its usage during each session.

14

Sector-wideand sitelicensing.

Schooling authorities wish to facilitate the acquisition of eLearning competencies and do not want to be constrained by having to clear the rights associated with content for each usage.

Rights expressions must accommodate usage at various levels of multiple use—individual, class, cohort, site, region, sector, etc.

Australian K-12 authorities do not wish to be placed in a situation where they have “to acquire and install specific software products in every management and usage environment, in order to use a learning object.”

15

Self-contained content and its usage.

Out of scope.

Out of scope.

11 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

Table A.1–Requirements use cases (continued)

General description use case

#

Requirement name

Education/Training requirement

DREL requirement

A law student expects his right of Fair Use to be respected, thereby allowing him to, for example, copy a selection from an article for use in an essay, even in cases where such use is forbidden by the vendor.

16

Fair use

Copying a selection of content (text and/or graphics) from an article for use in an essay or other educational purpose is a typical requirement of the education and training sector.

Legislation exists in various jurisdictions that allows this despite individual copyright notices on materials forbidding it.

The DREL must be able to specify whether Fair Use needs explicit declaration. This will be subject to “Context.” See 6.1 for the multiple variables (of which Fair Use must be one).

Universities create a range of reports on eLearning content usage that meet with their legal requirements such as copyright. Reports may include details of usage, technical controls to limit usage, and relevant compliance information accompanying resources.

Reports can also be used as feedback on effective and popular usage of content for developers and management.

17

Reports that meet legal requirements

Universities require a means for generating reports that can match their specific legal requirements with usage of eLearning content and copyright.

The DREL shall support the specification of a tracking mechanism when content is used.

University X has outsourced the development of digital material associated with output from its R&D: University X maintains copyright over the content while the developers maintain copyright on specific technological solutions they used to add interactivity to the content.

18

Separating content from technology

Universities and their staff will need mechanisms for tracking their IP on content that is subsequently utilized in novel technical ways. This presents a challenge because electronic boundaries are sometimes diffuse.

N/A.

Following on from #18, University X makes their content available to other universities free of charge as long as their logo is displayed when their content is accessed.

18.1

Persistent identification of IP

Attribution.

(Also refer to use case #9.)

This is an implementation/process issue and not a DREL requirement.

Same as use case #2.

12 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

Table A.1–Requirements use cases (continued)

General description use case

#

Requirement name

Education/Training requirement

DREL requirement

A lecturer uses a national e-content exchange to locate two Japanese learning objects (LOs). The lecturer finds that both are suitable but would prefer to take Lesson 1,2,4,6 from LO#1 and Lessons 3,5,7,8 from LO#2. On viewing the digital rights, the lecturer sees that this is possible and instructs the university LO repository administrator (or automated system) to do this and create a personalized LO for use by the students. The merged digital rights are still honored.

19

Merging digital rights from disparate LOs into a new LO

Lecturers will typically want to mix and match content and portions of content that might have rights attached.

Disaggregating and reassembling content is a typical activity for a lecturer.

Same as use case #1.

Extending the scenario in #19, the lecturer develops supplementary material to assist the students with the Japanese LO. These are so successful that the lecturer re-submits the whole LO back into the e-content exchange as a new LO. The digital rights on the original Japanese LOs allow this (reuse right was granted).

The university decides to charge on each sale of the new LO. When all three digital rights are “merged,” the final fee for the new LO is calculated. Each time it is purchased, the three rights holders are credited.

20

Merging digital rights from disparate LOs into a new LO

Aggregation of content.

Same as use case #1.

A lecturer wants to provide a seamless link from the course management system to access a specific library e-reserve article, and then add another link to a broad-ranging search across various repositories for students to search for other similar articles, with direct links to full text versions of relevant articles once discovered by student searches.

21

Integrating library permissions

Within a university, lecturers will want (and require) students to access specific (and sometimes scarce) resources that have local permissions assigned by the library. Integrating these permissions with other content usage ideally needs to be seamless.

N/A The web links to content are out of scope—these are implementation issues dealing with the management of content.

13 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

Table A.1–Requirements use cases (continued)

General description use case

#

A librarian wants to ensure that digital rights, copyright, and Fair Use are properly managed within a collection of resources aggregated by a lecturer for use in the course management system, and then later to preserve any lecturer-created resources within the aggregation, as well as pointers to any external copyright materials, for the future.

22

A student wishes to gain easy access to various learning and information resources across the university, with contextual advice on searching techniques together with online help from a virtual reference desk. The virtual reference desk is able to see previous failed search attempts by the student if the student decides to share these failed searches.

23

Requirement name Tracking lecturer usage

Privacy assumed but permissions to share log of personal activity

Education/Training requirement

DREL requirement

Libraries will sometimes need to perform an audit on usage by lecturers of copyrighted materials for which they are the custodians.

The DREL shall support the specification of a tracking mechanism when content is used.

The open environment of universities is conducive to sharing of digital information of many kinds.

Personal search logs or other online activities that are tracked can be shared if appropriate permissions are in place to do so.

Not specified:

(See use case #9)

—Authentication and authorization issues. The DREL can only provide elements to support the authentication of users and what authorization these users have to content.

—Failed attempts to access content get logged by systems to track hackers.

—May need mechanism to declare that session information can be used by a third party.

A researcher wishes to automatically gain access to data and computational services within a grid repository at another institution, where access to this repository should be anonymous, but the other institution needs to know that the researcher is authenticated at their home institution, and the anonymous access request has relevant attributes for accessing the repository according to the policies for this grid repository.

24

An IT Director wants to provide a single login point to all staff and students for seamless access to all university systems, but only to the systems they are entitled to use according to the security and policy requirements of each system and the institution itself.

25

Maintaining anonymity while being authenticated

Maintaining anonymity while undertaking or participating in research is a common university requirement.

Out of scope.

Allowing access to a search system and distributed authentication is out of scope. The DREL does not care if authentication is distributed or centralized. DRELs carry information about “who” has “permissions” to “content” provided that some “conditions” are met.

See related use cases #7 and #10.

Authentication and access control

Single sign-on is currently pursued by universities as a service goal. However, different systems will need to apply different policies to users.

Out of scope. This is a system requirement, not a DREL requirement.

NOTE—The above statement may represent a content-centric view on what the capabilities of a DREL should be. Therefore, single sign-on is out of scope, but not all access management issues are out of scope.

14 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

Table A.1–Requirements use cases (continued)

General description use case

#

Requirement name

Education/Training requirement

DREL requirement

A university wants an extension of the copyright extensions associated with face-to-face teaching to also cover web-based teaching.

The U.S. TEACH legislation only does that in a very circumscribed fashion, because it requires that the presentation of material to the web-connected students be done essentially simultaneously with the presentation to the classroom students i.e., it allows you to stream a class in real time to a distant location. This ignores the reality that more and more education is delivered “just-in-time,” which is not generally class time, but any time convenient to the student.

26

Web-based teaching copyright provisions.

“Just-in-time” delivery copyright extensions.

The DREL shall support the specification of rights expressions to deal with web-based presentations.

Determining whether the downstream use of content will have a commercial aspect to it or not will also determine conditions of use.

27

Determining commercial usage.

Content is often shared freely in university settings.

However, where it is used for commercial reasons, certain IP rights must be recognized.

The DREL shall allow a rights holder to specify multi-tiered distribution rights.

An instructional designer (ID) searches a learning object Exchange (LOX) and requests a preview or evaluation copy of an object that requires a nominal payment for any use.

However, the object does not currently have such rights expressed in its conditions for use, so the ID submits an offer for trialing purposes to the administrator of the LOX who then contacts the rights holder. An agreement is reached. As a further consequence, the administrator develops an “offer template” for trialing purposes for all objects held within the LOX.

28

There are numerous intermediaries involved in education and training (tutors, instructional designers, teacher aides, teachers, etc.). In appraising the value or otherwise of content, such persons require the ability to evaluate content prior to recommending the purchase of this content.

Out of scope.

Trial usage permission.

[For example, a rights holder H allows distributor D (tier 1) to issue commercial and non-commercial licenses to allow students (tier 2) to use content under some constraints.]

The ability to assign a variety of rights to content is already covered in other requirements specified. However, the ability to modify existing rights over content is a management issue, so is out of scope.

15 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

Table A.1–Requirements use cases (continued)

General description use case

#

A teacher logs onto an institute intranet to search for learning objects for a specific training session. There are four different types available: (1) unrestricted but requiring attribution (2) restrictions on changing or revising (3) commercially sourced and paid for, and (4) commercially available but for which payment is required (and institute protocols require a chain of approvals before this can take place).

29

An instructional designer (ID) searches a Learning Object Exchange (LOX) for some specific LOs. Finding none that are suitable, the ID develops some and then loads them to the LOX, assigning the necessary metadata and rights information.

30

An instructional designer (ID) sources an LO from a national pool (repository) and wishes to re-purpose it for a context other than the one it was created for. Fortunately the LO is available for unrestricted use. The LO is downloaded, and the development team integrate it into another context. It is reloaded into the repository with the additional metadata and rights are assigned.

31

Similar to #31, except that original LO is constrained by a range of usage conditions.

31.1

Requirement name

Education/Training requirement

Determining and responding to rights restrictions.

Educators and trainers will be typically faced by a range, if not a myriad, of choices concerning conditions of use of learning objects. In wanting to benefit from the modularity of such content, they will require systems that make it easy to assemble this content in a manner that does not impede workflow.

Tools for assigning rights.

Educators and trainers require systems that enable them to assign rights in simple ways. That is, they (and sometimes their students) act as publishers of content.

DREL requirement

Out of scope.

This is a content procurement and management issue, which is a system issue.

The ability to assign a variety of rights to content is already covered in other requirements specified.

Tools are out of scope.

Re-purposing learning objects

Educators and trainers are trained to apply content to novel contexts. They are often wishing to modify existing content and modify it for use in a new context.

See use case #1 (roll-up rights).

Re-purposing learning objects (2)

Same requirement as #31.

Already covered by other requirements specified.

Also, if the content already has a rights expression granting unrestricted use (play, edit, print, copy, etc.), then the consumer of the content can do whatever he/she is legally authorized to do with the content.

16 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

Table A.1–Requirements use cases (continued)

General description use case

#

Requirement name

Education/Training requirement

DREL requirement

A teaching video is made of a surgical procedure but cannot identify the patient. There are a number of individuals involved, some of whom have rights issues, some consent—the patient; the patient’s next of kin; the lead consultant surgeon; other members of the theatre staff; the specific hospital department in which the procedure took place; the hospital trust (or other global body) in which the procedure took place; and the university or faculty for whose students the video was made.

For any one or more than one of these entities to establish rights would seem to place the others in positions requiring varying degrees of consent. For instance, for the hospital and university to coown the rights to the video, consent would be required from most if not all of the individuals concerned. Some of these consents may be covered within a contract of employment. Non-contracted people, and in particular the patient, will almost certainly have no rights over the video but will have degrees of deciding control via consent of how and where the video is used (and indeed if it is made at all). Is consent therefore a prior condition in a multifactorial situation, required to allow rights to be assigned?

32

Consent

Particularly in the medical training field, restrictions to digital assets are associated with consent. Patients and their families can restrict who has access to digital assets that identify the patients. A DREL needs to have the semantics to express consent based restrictions.

Not specified.

TAFE NSW (an Australian VOCED provider) has developed a model for assessment validation with an associated website that shows the model working in practice. It is available for other registered training organizations (RTOs) for a fee. This fee is higher for public RTOs. Adaptation and contextualization are allowed to suit user needs.

33

Maximum use of a document model with an associated Web site.

Rights propagation.

Not uniquely specified.

17 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

Table A.1–Requirements use cases (continued)

General description use case

#

Requirement name

Education/Training requirement

DREL requirement

A private registered training organization (RTO) has developed interactive material for Cert II level competency Work Effectively with Others for business studies area. The material contains reusable material for developing teamwork and can be used across a variety of discipline areas. For this to happen, the materials need to be evaluated and vetted where appropriate.

34

Wide application of resources developed by private RTO but vetting of adaptations required.

Trial usage and possible repurposing; similar to #33.

Not uniquely specified.

A developer has produced an animation on how to use a compass. He/She wants to make this widely available for educational use to assist, for example, recreational bushwalkers.

35

Maximizing educational use including ability to adapt and republish.

Rights propagation.

Not uniquely specified.

A college is developing and providing learning materials or learning objects to students in a variety of methods and situations from a variety of sources and in a variety of media and locations. It resells materials to students in some form (this could be done through a sale at the campus bookstore or perhaps by including the cost of materials in the student fees) on a costrecovery basis only. For example, reading packages and/or course content packages may contain such things as articles from the internet or A/V resources such as videos and would be provided to the students in paper formats, on CD, or via a password protected internet site.

36

Noncommercial cost recovery

Non-commercial cost recovery of learning materials development. As technology changes and learner needs change, institutions have no choice but to adapt to the changes and to deliver these materials in a manner that is not only economically viable for both the institution and the learner, but in a manner that meets the needs of both the learner and the copyright owner.

Distribution and sales issue; medium of delivery is a condition.

18 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

Table A.1–Requirements use cases (continued) General description use case

#

Requirement name

Education/Training requirement

DREL requirement

Content license includes the limitation on usage duration and number of users.

37

Usage duration and number of users.

Management of usage duration and number of users.

Not uniquely specified.

In requirement #37, duration may be either absolute (fixed by contract), or relative (measured from learner’s actual learning start date).

38

Absolute/ relative duration.

Management of usage duration and number of users—including detail concerning absolute or relative duration.

Not uniquely specified.

In requirement #38, number of users may be counted as either simultaneous users or cumulative users.

39

Simultaneous/ cumulative number of users.

Management of usage by number of users.

Not uniquely defined.

The license described in #38 and #39 may be applied single content as well as a course consisting of multiple contents.

40

Compound course.

Management of usage in context of compound course.

Not uniquely defined.

In requirements #38–#40, the multiple contents may be provided by multiple content providers, and intermediate agent (aggregator) combines and sells them to the end user.

41

The above case (#41) can be applied to multiple LOs in a single content.

42

For the SCORM content, some providers wants to protect whole content, but some wants to protect SCOs only, and some course structure. It depends on the provider’s core-competence.

43

Content may be licensed with other educational service such as mentoring.

44

Usage condition violation by the end user should be notified to all the providers and intermediate agents.

45

Usage condition violation by the intermediate agents also should be prevented and notified to the provider.

46

NOTE—Ability to express an initiating event.

NOTE—Roll-up or composite rights; see use case #1 Content aggregator.

Management of usage by content aggregator.

Not uniquely specified.

NOTE—Roll-up or composite rights; see use case #1

Content consisting of multiple source LOs

Management of usage of multiple source LOs.

SCORM content protection.

Protection of SCORM content.

Educational service license

Licensing via third party service

Tracking

Notification of usage violation

Not uniquely specified.

NOTE—Roll-up or composite rights; see use case #1 Not uniquely specified.

NOTE—Differential roll-up

Not specified.

See use cases #36 and #37.

N/A. Implementation of Rights Management is out of scope NOTE—Notification an implementation issue

Tracking

Prevention of usage violation

N/A. Implementation of Rights Management is out of scope NOTE—Prevention an implementation issue.

19 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

Annex B (informative) Historical background Annex B is included from the following document editors to provide a historical reference. _____________________________________________________________________________________ January 30, 2004 Version 1.0 IEEE LTSC Document Editors: Manuel Ham, ContentGuard Jon Mason, education.au limited Thomas Probert, Lydia, Inc

B.1. Introduction B.1.1 Purpose The purpose of this document is to provide a distillation of the requirements articulated by stakeholders from learning, education, and training (LET) communities concerning the functionality of Digital Rights Expression Languages (DRELs).

B.1.2 Background In developing a work plan to accomplish its aims, the LTSC DREL WG established a Requirements Analysis Subcommittee tasked with evaluating the DREL use cases and producing the functional requirements for DRELs relevant to practitioners of eLearning technology.

The Requirements Analysis Subcommittee reviewed “use cases and requirements” captured in two Calls for Data dated 2-Jun-2003 and 3-Jun-2003 contained in the attachments as the “IEEE LTSC Requirements Spreadsheet” (the Spreadsheet).

The requirements proposed by the Open eBook Forum and the MPEG REL provide a useful perspective and validation of the basic capabilities for a DREL. Only the requirements from OeBF and MPEG REL that were specific to learning, education, and training are included in this document.

The functional requirements that are documented in the paragraphs that follow are broadly representative of the current needs of learning, education, and training. However, it is recognized that as rights-enabled infrastructure becomes widely deployed over time, new requirements may emerge. An important consideration is that eLearning technologies involve engagement of learners (and related stakeholders) with processes and applications as well as content. However, most requirements have hitherto been framed in terms of expressing rights associated with content.

Initially, five “use cases” were selected from the Spreadsheet as representative of the educational community. These were analyzed to establish an analysis process for the subcommittees’ interpretation of the intent of the remaining Use cases.

The DREL functional requirements analysis process focused on the need to specify permissions and conditions over digital content and reduced emphasis on enforcement or implementation mechanisms.

20 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

Associated with each requirement are references that comprise a concordance between the Spreadsheet and the listed requirement. This concordance is used to provide a crosswalk (see Table B.1) between the requirements identified by the subcommittee and the data represented in the use cases.

Table B.1–Crosswalk

Spreadsheet use case numbers Req.#

1

2

3

3.1

4

2.1.1

5

6.1

7

9

10

12

13

14

16

17

22

26

27

38

x

2.1.2

x

2.1.3

x

2.1.4

x

x

x

2.1.5

x

2.1.6 2.1.7 2.1.8 2.2.1

x

x

2.2.2

x

x

2.2.3

x

x

2.2.4

x

2.2.5

x

2.2.6

x

2.2.7

x

2.3.1

x

2.4.1 2.4.2

x

2.4.3

x

2.4.4

x

2.4.5

x

2.4.6

x

x

x

x x

21 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

Table B.1–Crosswalk (continued) Spreadsheet use case numbers Req. #

1

2

3

3.1

4

5

6.1

7

9

10

12

13

14

2.4.7

x

2.4.8

x

16

17

22

26

27

38

x

2.4.9

x

2.4.10

x

2.4.11

x

2.4.12 2.4.13

x x

2.4.14

x

2.4.15

x

x

2.4.16 2.4.17

x x

x

2.4.18

x

x

2.4.19 2.5.1

x

2.6.1

x

x

x

x

B.1.3 Definition of terms Normative terminology is, of course, a key component of any language. However, this document is not a normative reference. The following terms are “defined” only with a view to help in overall readability of this annex. content: Any resource that can be regarded as “containing” information and is independent of its structure and presentation.

Digital Rights Management: A broad term used to describe a process or a system for managing digital rights associated with digital content. DRM covers a wide range of activities including (but not limited to) the following:  The use of a digital rights expression language  The authentication of rights expressions, devices, users, and resources  The association of rights expressions to digital content  The protection of digital content from being used without rights NOTE—It is important to note that the requirements for a DRM system are out of scope for this document.

22 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

Digital Rights Expression Language: A language in which expressions of permissions and conditions are specified to control the distribution or use of learning objects. The use of a DREL is one tool that is used in DRM systems. The functional requirements of a DREL are the main focus of this document. learning content: Any material useful for creating, managing, or facilitating a learning experience regardless of medium, structure, or commercial status. learning object: A term has been defined very broadly by the IEEE LTSC in the LOM standard for the purposes of creating metadata. Operationally, however, it is a term that has been widely adopted and used to distinguish digital assets that have some kind of learning objective and/or assessment associated with them. It is used in this latter sense below. rights: Expressions that describe such things as permissions and conditions that are typically associated with the use of content.

B.1.4 References IEEE Std 1484.12.1-2002, IEEE Standard for Learning Object Metadata — http://shop.ieee.org/ieeestore/Product.aspx?product_no=SH95001 OeBF Rights and Rules Coordinated Requirements — http://www.idpf.org/specifications/rrwgcoordinated.htm MPEG REL Requirements — http://www.chiariglione.org/mpeg/working_documents/mpeg21/requirements/RDD&REL_requirements.zip IEEE LTSC DREL Analysis of Use Cases and Development of Functional Requirements — http://ltsc.ieee.org/wg4/materials.html IEEE LTSC DREL Requirements Spreadsheet — http://ltsc.ieee.org/wg4/materials.html

B.2. Learning, education, and training requirements This subclause contains the DREL functional requirements for the learning, education, and training community.

B.2.1 Attributes of the Digital Rights Expression Language B.2.1.1 The DREL shall be based on a formal grammar.

B.2.1.2 The DREL shall allow the specification of version or update invariant constraints. The default shall be that constraints are persistent.

B.2.1.3 The DREL shall support the articulation of roles undertaken by users. Example: User may be associated with the role of “instructor” for an identified learning object.

B.2.1.4 The DREL shall support unique identifiers for learning objects.

B.2.1.5 The DREL shall support a single rights expression to apply to a class of learning objects.

The DREL shall therefore support class definitions and affiliations.

23 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

B.2.1.6

The DREL shall be extensible and allow alternative schemas wherever sensible to meet the future needs of the learning, education, and training community.

B.2.1.7

The DREL shall define a minimal core set of primitive constructs from which all other expressions can be constructed or derived. For example, instead of defining pay-per-view, rent-to-own, and other such models, the core shall provide the fundamental building blocks to link constraints (e.g., payment) to actions, to allow constraints to repeat according to various criteria, provide metering syntax, etc.

B.2.1.8 The DREL shall support the specification of constraints that can be used as defaults.

B.2.2 Aggregation and disaggregation of learning objects Learning objects may be created through aggregation into more complex learning objects. Constraints may be associated with the learning objects employed in such aggregations allowing them to be reused.

Therefore B.2.2.1

The DREL shall allow the specification of constraints for the aggregation or embedding of content within learning objects.

B.2.2.2

The DREL shall allow the specification of constraints for the disaggregation of content within learning objects.

B.2.2.3

The DREL shall allow the specification of constraints that must be preserved and propagated under aggregation or embedding.

B.2.2.4

The DREL shall allow the specification of constraints for the use of the aggregated learning objects.

B.2.2.5

The DREL shall allow specification of constraints associated with different levels of granularity in an aggregated learning object.

B.2.2.6

The DREL shall allow specification of different identification schemes to uniquely identify different portions of an aggregated learning object.

B.2.2.7

The DREL shall allow the specification of constraints requiring the retention of specific metadata as an integral component of a learning object.

B.2.3 Attribution Learning objects may be created from other learning objects and may require attribution. Therefore B.2.3.1

The DREL shall allow the specification of attribution constraints associated with the use (aggregation, disaggregation, reference, etc) of learning objects.

B.2.4 Conditional use B.2.4.1 The DREL shall allow for the specification of a set of conditions that must be fulfilled before a right (or set of rights) can be exercised.

B.2.4.2 The DREL shall allow the specification of heterogeneous constraints for access to learning objects by different individuals, groups as applicable.

B.2.4.3 The DREL shall allow specification of constraints limiting the number of times learning objects can be used, accessed, distributed, and/or replicated.

24 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

B.2.4.4 The DREL shall allow the specification of connectivity-based constraints, e.g., connection to an online service, web portal, web service, etc. associated with the use of learning objects.

B.2.4.5 The DREL shall allow specification of device-based constraints, e.g., associated with the capabilities of specific reading systems or other applications, associated with the use of learning objects.

B.2.4.6 The DREL shall allow the specification of anonymous access to learning objects.

B.2.4.7 The DREL shall allow the specification of usage rights to learning objects for educational, research, and scholarly purposes.

B.2.4.8 The DREL shall allow the specification of constraints associated with policies that may apply to individuals or groups.

B.2.4.9 The DREL shall allow the specification of constraints associated with multi-tiered distribution, i.e., instances where learning objects are distributed by one entity that redistributes to other entities, of learning objects.

B.2.4.10 The DREL shall support the unambiguous specification of time-based constraints such as specific times, fixed intervals, sliding intervals and metered intervals that can span across different time zones.

B.2.4.11 The DREL shall support the specification of fees in industry standard terms.

B.2.4.12 The DREL shall support the specification of information about portions of learning objects, including both identified portions and generic portions (such as “any five pages”) in order to support limiting rights to these certain portions.

B.2.4.13 The DREL shall support distribution and management of free learning objects.

B.2.4.14 The DREL shall support specifying a price, including a price of free, for unlimited usage of a learning object.

B.2.4.15 The DREL shall support the specification of payment of a fee for each use of a learning object that may be constrained by connectivity-based conditions, e.g., connection to an online service, web portal, and web service.

B.2.4.16 The DREL shall support subscription-based pricing and access to learning objects.

B.2.4.17 The DREL shall support time-based pricing rules for learning objects.

B.2.4.18 The DREL shall support the specification of learning object usage under a site-license.

B.2.4.19 The DREL shall support the specification of constraints related to the manner in which the use of a learning object is supervised, e.g., a teacher supervises taking a test.

B.2.5 Tracking B.2.5.1 The DREL shall allow the specification of requirements for tracking access, usage, distribution, and purchase of content.

25 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

B.2.6 Offers The ability to offer learning objects to individuals or groups of people is important within learning, education, and training community. The offers themselves can be subject to a variety of conditions such as fees, time, membership, etc. Furthermore, offers can specify additional constraints on the use of learning object being offered.

B.2.6.1 The DREL shall allow the specification of offers. Both the offers and the use of the learning objects may be subject to constraints.

B.3. Issues Table B.2 is a list of issues that came up during the development of the functional requirements.

Table B.2—Issues #

Issue

Description

1

How are digital objects that extend beyond content supported by the DRELs?

In the LET community, there are digital objects such as software applications whose use might need to be controlled. For example, Adobe Photoshop has hundreds of functions like autocolor, auto-brightness, image-size, crop, etc. Are these application functions to be controlled through the use of a DREL? Or are they out of scope?

Resolution

26 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

Annex C (informative) Mapping requirements to ODRL _____________________________________________________________________________________ Editor: Susanne Guth Email: susanne.guth@wu-wien.ac.at Date: 25 June 2004 Version 1.0

C.1. Introduction This document outlines the response from the Open Digital Rights Language (ODRL) Initiative to the Digital Rights Expression Language (DREL) Requirements Version 1.0 (dated 30 January 2004) of the Learning Technology Standards Committee (LTSC). The submission is based on extensive research, development, and implementation experience with digital rights management systems by the supporters of the ODRL Initiative. The ODRL Initiative is confident the resultant submission meets and exceeds the expectations of the LTSC DREL working group and is committed to working with the LTSC in future development of the DREL specification.

This response refers to the following documents: LTSC DREL Requirements Version 1.0 http://ltsc.ieee.org/wg4/index.html LTSC DREL Use Case/Requirements Spreadsheet - Draft 4, 4 Dec 03 http://ltsc.ieee.org/wg4/files/DREL_Requirements_draft41.pdf Open Digital Rights Language (ODRL) Version 1.1 http://odrl.net/1.1/ODRL-11.pdf ODRL Rights Expression Language (REL) XML Schema http://odrl.net/1.1/ODRL-EX-11.xsd ODRL Rights Data Dictionary (RDD) XML Schema http://odrl.net/1.1/ODRL-DD-11.xsd

C.2. Requirement mapping to ODRL This annex contains the DREL functional requirements for the learning, education, and training community. Each requirement is mapped to the REL ODRL with a use case and ODRL code examples showing the ODRL implementation of the requirement. Please note that the XML code examples sometime omit the XML namespace prefixes due to clarity reasons.

C.2.1 Attributes of the Digital Rights Expression Language This subclause contains the DREL functional requirements for the learning, education, and training community. Each requirement is mapped to the REL ODRL with a use case and ODRL code examples

27 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

showing the ODRL implementation of the requirement. Please note that the XML code examples sometime omit the XML namespace prefixes due to clarity reasons.

C.2.1.1 “The DREL shall be based on a formal grammar.”

The current ODRL specification version 1.1 formally specifies the ODRL language basics (grammar) and the ODRL core vocabulary or data dictionary (please also refer to 2.1.7).

Furthermore, the ODRL initiative is engaged in defining a “formal semantics” for ODRL which is different from a formal grammar. A formal semantics would represent rights expressions independent from a certain syntax, i.e., right expression language. A formal semantics is the basis for the formulation of state machines for ODRL rights expressions. State machines allow for an unambiguous interpretation of ODRL instances. Some work on this subject has already been published: Riccardo Pucella and Vicky Weissman, A Formal Foundation for ODRL, Workshop on Issues in the Theory of Security (WITS'04), Barcelona, 2004.

Another publication with this subject was presented at the ODRL Workshop in Vienna: M. Holzer, S. Katzenbeisser, C. Schallhart, Towards a formal semantics for ODRL, ODRL Workshop, Vienna, April 2004.

The specification of a formal semantics is planned to be part of ODRL version 2.

C.2.1.2 “The DREL shall allow the specification of version or update invariant constraints.

The default shall be that constraints are persistent.”

The context element in ODRL allows for the specification of versions. The context element can be assigned to each ODRL element, such as assets, parties, permissions, constraints, etc.

The following ODRL example shows an offer for the asset “ODRL Specification,” more exactly for version 1.1 of the ODRL specification. The offer states that this version of the specification may be printed until the end of 2004. However, for special purposes, also versions for permission and/or constraint elements can be expressed. In the offer below, the permission and the constraint are related to the version number 0.7, which could represent special semantics of the permission “play” and the constraint “datetime.”

<?xml version="1.0" encoding="UTF-8"?> <o-ex:rights xmlns:o-ex="http://odrl.net/1.1/ODRL-EX" xmlns:o-dd="http://odrl.net/1.1/ODRL-DD"> <o-ex:offer> <o-ex:asset> <o-ex:context> <o-dd:name>ODRL Specification</o-dd:name> <o-dd:version>1.1</o-dd:version> </o-ex:context> </o-ex:asset type=”work”> <o-ex:permission> <o-ex:context> <o-dd:version>urn:univ:v0.7</o-dd:version> </o-ex:context> <o-dd:print/> <o-ex:constraint> <o-ex:context> 28 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

<o-dd:version>urn:univ:v0.7</o-dd:version> </o-ex:context> <o-dd:datetime> <o-dd:end>2004-12-31T00:00:00</o-dd:end> </o-dd:datetime> </o-ex:constraint> </o-ex:permission> </o-ex:offer> </o-ex:rights> Also via the type attribute of the ODRL element “asset” it can be further specified whether the asset is of the type “work,” "expression,” ”manifestation" or “item. For details on the type attribute please refer to the ODRL specification version 1.1.

C.2.1.3 “The DREL shall support the articulation of roles undertaken by users. Example: User may be associated with the role of “instructor” for an identified learning object.”

The context element in ODRL allows for the specification of roles. The context element can be assigned to each ODRL element, such as assets, parties, permissions, constraints, etc.

The following ODRL example shows a license that allows all students to display the asset “ODRL Specification.” <?xml version="1.0" encoding="UTF-8"?> <o-ex:rights xmlns:o-ex="http://odrl.net/1.1/ODRL-EX" xmlns:o-dd="http://odrl.net/1.1/ODRL-DD"> <o-ex:agreement> <o-ex:asset> <o-ex:context> <o-dd:name>ODRL Specification</o-dd:name> </o-ex:context> </o-ex:asset> <o-ex:permission> <o-dd:display/> </o-ex:permission> <o-ex:party> <o-ex:context> <o-dd:role>Student</o-dd:role> </o-ex:context> </o-ex:party> </o-ex:agreement> </o-ex:rights> C.2.1.4 “The DREL shall support unique identifiers for learning objects.”

The context element in ODRL allows for the specification of unique identifiers. The URI format is used for all identifiers. The context element can be assigned to each ODRL element, such as assets, parties, permissions, constraints, etc.

The following ODRL instance shows an offer for the Video on Project Management with the unique identifier urn:univ:lr-wuw-video-1.The video may be played without any constraints. <?xml version="1.0" encoding="UTF-8"?> <o-ex:rights xmlns:o-ex="http://odrl.net/1.1/ODRL-EX" xmlns:o-dd="http://odrl.net/1.1/ODRL-DD"> <o-ex:offer> <o-ex:asset> <o-ex:context> 29 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

<o-dd:name> Video on Project Management</o-dd:name> <o-dd:uid> urn:univ:lr-wuw-video-1</o-dd:uid> </o-ex:context> </o-ex:asset> <o-ex:permission> <o-dd:play/> </o-ex:permission> </o-ex:offer> </o-ex:rights> C.2.1.5 “The DREL shall support a single rights expression to apply to a class of learning objects. The DREL shall therefore support class definitions and affiliations.”

Depending on the actual use case and implementation, this requirement can be supported differently.

1.

Defining one asset type via the attribute “role” where permissions can be assigned. The following ODRL example shows a license that allows the student urn:univ:sguth to display all assets of the type “PowerPoint Presentations.” <?xml version="1.0" encoding="UTF-8"?> <o-ex:rights xmlns:o-ex="http://odrl.net/1.1/ODRL-EX" xmlns:o-dd="http://odrl.net/1.1/ODRL-DD"> <o-ex:agreement> <o-ex:asset> <o-ex:context> <o-dd:role>Powerpoint Presentations</o-dd:role> </o-ex:context> </o-ex:asset> <o-ex:permission> <o-dd:display/> </o-ex:permission> <o-ex:party> <o-ex:context> <o-dd:uid>urn:univ:sguth</o-dd:uid> <o-dd:name>Susanne Guth</o-dd:name> <o-dd:role>Student</o-dd:role> </o-ex:context> </o-ex:party> </o-ex:agreement> </o-ex:rights>

2.

Defining multiple assets with an ID. In the following ODRL agreement, the permission “play” refers to all listed asset and is assigned to the party urn:univ:sguth. If no further references are given, the permissions refer to all listed assets, i.e., to urn:univ:lr-wuw-video-1 and urn:univ:lr-wuw-software-1. (Please also refer to the code example in 2.2.5.) <?xml version="1.0" encoding="UTF-8"?> <rights> <agreement> <asset id="Asset-01"> <context> <uid>urn:univ:lr-wuw-video-1</uid> </context> </asset> <asset id="Asset-02"> <context> <uid>urn:univ:lr-wuw-software-1</uid> </context> </asset> 30 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

<permission> <play> </permission> <party> <context> <uid>urn:univ:sguth</uid> </context> </party> </agreement> </rights> 3.

If various permissions shall not be formulated, another alternative is to bundle the learning objects within assets. In the following ODRL agreement, the permission play refers to the videos 1 to 5 and is assigned to the party urn:univ:sguth. <?xml version="1.0" encoding="UTF-8"?> <rights> <agreement> <asset> <context> <uid>urn:univ:lr-wuw-video-1</uid> <uid>urn:univ:lr-wuw-video-2</uid> <uid>urn:univ:lr-wuw-video-3</uid> <uid>urn:univ:lr-wuw-video-4</uid> <uid>urn:univ:lr-wuw-video-5</uid> </context> </asset> <permission> <play> </permission> <party> <context> <uid>urn:univ:sguth</uid> </context> </party> </agreement> </rights>

4. Depending on the DRM system, a bundle of learning objects should have unique ID as well. In that case, the bundle is referenced in a rights expression as a single asset. In the following ODRL agreement, the permission display refers to the bundle urn:univ:group-of-assets2222B and is assigned to the party urn:univ:sguth. <?xml version="1.0" encoding="UTF-8"?> <o-ex:rights xmlns:o-ex="http://odrl.net/1.1/ODRL-EX" xmlns:o-dd="http://odrl.net/1.1/ODRL-DD"> <o-ex:agreement> <o-ex:asset > <o-ex:context> <o-dd:uid>urn:univ:group-of-assets-2222B</o-dd:uid> </o-ex:context> </o-ex:asset> <o-ex:permission> <o-dd:display/> </o-ex:permission> <o-ex:party> <o-ex:context> <o-dd:uid>urn:univ:sguth</o-dd:uid> 31 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

</o-ex:context> </o-ex:party> </o-ex:agreement> </o-ex:rights> They key point made in ODRL is that it tries not to be an identification language (as well as a REL). So ODRL just uses the “power” of the UDI (e.g., with an URI) to identify (a single object or group of objects). For referencing packaged learning objects, the SCORM specification (http://www.adlnet.org/) could be (re-) used in ODRL rights expressions.

C.2.1.6 “The DREL shall be extensible and allow alternative schemas wherever sensible to meet the future needs of the learning, education, and training community.”

As ODRL is defined in XML schemas ODRL is extensible by definition. To extend the language semantics and vocabulary sub-schemas of ODRL have to be defined, respectively other XML namespaces can be imported into ODRL instances. ODRL itself already reuses the XML Signature specification of the W3C to specify digital signature information within ODRL instances, i.e., electronic contract or tickets. Alternative schemas that could be used to e.g., further specify the assets and the learning objects are the Dublin Core or LTSC LOM standard, respectively the vCard standard.

C.2.1.7 “The DREL shall define a minimal core set of primitive constructs from which all other expressions can be constructed or derived. For example, instead of defining payper-view, rent-to-own, and other such models, the core shall provide the fundamental building blocks to link constraints (e.g., payment) to actions, to allow constraints to repeat according to various criteria, provide metering syntax, etc.”

ODRL is designed just like that. The ODRL language is defined in two XML schemas. 

One is called ODRL Expression Language XML Schema, which defines the building blocks or “grammar”4 of ODRL, containing assets, parties, permissions, constraints, etc. and their relations.



The second one is called ODRL Data Dictionary XML Schema, which defines the ODRL data dictionary5, including terms, such as print, sell, display etc for the language element “permission.”

This data dictionary can be easily extended by writing a subschema.

C.2.1.8 “The DREL shall support the specification of constraints that can be used as defaults.”

ODRL does not differentiate “who” is writing constraints at what time into the ODRL rights expression.

Whether constraints have been entered by default, or by the authors they have the same syntax and place in the rights expression. Having a default constraint seem to depend on whether the software is entering a constraint by default if the authors/rightsholders did not do so. Default constraints could be implemented via rights expression templates that are offered to the customers.

To understand this requirement completely there has been a discussion with the LTSC working group. The author of the document understands the requirement as follows: “A collection of learning resources shall receive certain rights, which can be overridden, extended or restricted by additional rights expressions that are assigned to individual resources within the collection.” For this purpose, ODRL offers the concept of “inheriting” rights. Please note that this is not an official clarification of the LTSC requirement 2.1.8.

4 5

Linguists would call the building blocks the “syntax” of the language.

Linguists would call the data dictionary the “lexis” or vocabulary of the language.

32 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

An example is given below in which the first rights expression specifies the “play” permission for the identified asset urn:example:asset:007. The second rights expression is assigned to an asset with the unique ID urn:example:asset:007-Part1, which is related to the first asset. It specifies that the rights for the first asset should be inherited by the second asset.

The expression also indicates not to override the inherited rights (the default), hence, the complete rights for the second asset include the “play” and “give” permissions for the asset urn:example:asset:007. If the second expression did indicate to override the inherited rights, then the only permissions for the second asset would be “give.” For details about the attributes “default” and “override,” please refer to the ODRL Specification version 1.1. <rights> <offer> <asset> <context> <uid>urn:example:asset:007</uid> </context> </asset> <permission> <play/> </permission> </offer> </rights> <rights> <offer> <asset> <context> <uid>urn:example:asset:007-Part1</uid> </context> <inherit override="false" default="false"> <context> <uid>urn:example:asset:007</uid> </context> </inherit> </asset> <permission> <give/> </permission> </offer> </rights>

C.2.2. Aggregation and disaggregation of learning objects Learning objects may be created through aggregation into more complex learning objects. Constraints may be associated with the learning objects employed in such aggregations allowing them to be reused.

Therefore C.2.2.1 “The DREL shall allow the specification of constraints for the aggregation or embedding of content within learning objects.”

The ODRL data dictionary comprises the definition of the right “aggregation” that can be assigned to parties. The right aggregate is defined as follows: “The act of using an asset (or parts of it) as part of a composite work or collection.”

33 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

This right can then be constrained like any other right—for example, by time. In the following ODRL example, the party urn:univ:sguth may aggregate the asset urn:univ:lr-wuw-video-1 until the end of year 2004. <?xml version="1.0" encoding="UTF-8"?> <o-ex:rights xmlns:o-ex="http://odrl.net/1.1/ODRL-EX" xmlns:o-dd="http://odrl.net/1.1/ODRL-DD"> <o-ex:agreement> <o-ex:asset> <o-ex:context> <o-dd:uid> urn:univ:lr-wuw-video-1</o-dd:uid> </o-ex:context> </o-ex:asset> <o-ex:permission> <o-dd:aggregate> <o-ex:constraint> <o-dd:datetime> <o-dd:end>2004-12-31T00:00:00</o-dd:end> </o-dd:datetime> </o-ex:constraint> <o-dd:aggregate> </o-ex:permission> <o-ex:party> <o-ex:context> <o-dd:uid>urn:univ:sguth</o-dd:uid> </o-ex:context> </o-ex:party> </o-ex:agreement> </o-ex:rights> C.2.2.2. “The DREL shall allow the specification of constraints for the disaggregation of content within learning objects.”

The ODRL data dictionary does not comprise the definition of a right that refers to “disaggregation.” An extension of the ODRL data dictionary would be necessary in this case. Still the language concept then allows to assign constraint to the “new” right.

The following ODRL code example shows how the ODRL data dictionary can be extended. The ODRL instance imports a fictitious XML namespace (prefix “ext”) that defines the XML element “disaggregate,” which can from then on be used in the ODRL instance. The ODRL license below states that the party urn:univ:sguth may disaggregate the asset urn:univ:lr-wuw-package-1 with a constraint.

The constraint says that it is required to make an attribution to the disaggregated asset that holds the original package ID.

<?xml version="1.0" encoding="UTF-8"?> <o-ex:rights xmlns:o-ex="http://odrl.net/1.1/ODRL-EX" xmlns:o-dd="http://odrl.net/1.1/ODRL-DD"> xmlns:ext="http://someInitiative.net/Vocabulary"> <o-ex:agreement> <o-ex:asset> <o-ex:context> <o-dd:uid> urn:univ:lr-wuw-package-1</o-dd:uid> </o-ex:context> </o-ex:asset> <o-ex:permission> <ext:disaggregate> <o-ex:requirement> 34 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

<o-dd:attribution> <o-ex:context> <o-dd:remark> If the package is disaggregated a reference to the original package ID has to be made in the resulting asset. </o-dd:remark> </o-ex:context> </o-dd:attribution> </o-ex:requirement> </ext:disaggregate> </o-ex:permission> <o-ex:party> <o-ex:context> <o-dd:uid>urn:univ:sguth</o-dd:uid> </o-ex:context> </o-ex:party> </o-ex:agreement>

</o-ex:rights> C.2.2.3. “The DREL shall allow the specification of constraints that must be preserved and propagated under aggregation or embedding.”

The ODRL data dictionary comprises the definition of the right “aggregation” that can be assigned to parties. (See also 2.21.) This right can then be constrained like any other right. For the current requirement a constraint is needed that expresses that a right has to be preserved under aggregation. There is no constraint that is called “preserve” in the default vocabulary of ODRL 1.1. Therefore, to show a possible solution for such a use case a fictitious namespace (prefix “ext”) was added to the ODRL instance.

In the following ODRL example, the asset urn:univ:lr-wuw-video-1 can be aggregated by urn:univ:sguth until the end of year 2004 and under aggregation the current rights have to be preserved. <?xml version="1.0" encoding="UTF-8"?> <o-ex:rights xmlns:o-ex="http://odrl.net/1.1/ODRL-EX" xmlns:o-dd="http://odrl.net/1.1/ODRL-DD"> xmlns:ext="http://someInitiative.net/Vocabulary"> <o-ex:agreement> <o-ex:asset> <o-ex:context> <o-dd:uid> urn:univ:lr-wuw-video-1</o-dd:uid> </o-ex:context> </o-ex:asset> <o-ex:permission> <o-dd:aggregate> <o-ex:constraint> <o-dd:datetime> <o-dd:end>2004-12-31T00:00:00</o-dd:end> </o-dd:datetime> <ext:preserverights/> </o-ex:constraint> <o-dd:aggregate> </o-ex:permission> <o-ex:party> <o-ex:context> <o-dd:uid>urn:univ:sguth</o-dd:uid> </o-ex:context> </o-ex:party> 35 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

</o-ex:agreement> </o-ex:rights> C.2.2.4. “The DREL shall allow the specification of constraints for the use of the aggregated learning objects.”

In this case, we suggest issuing a permission that allows aggregation and a certain usage right (here play).

Both rights can be constrained. (Or each right can be constrained separately, as shown in req. 2.2.1). In the following ODRL example, the asset urn:univ:lr-wuw-video-1 can be aggregated and/or played by urn:univ:sguth until the end of year 2004.

<?xml version="1.0" encoding="UTF-8"?> <o-ex:rights xmlns:o-ex="http://odrl.net/1.1/ODRL-EX" xmlns:o-dd="http://odrl.net/1.1/ODRL-DD"> <o-ex:agreement> <o-ex:asset> <o-ex:context> <o-dd:uid> urn:univ:lr-wuw-video-1</o-dd:uid> </o-ex:context> </o-ex:asset> <o-ex:permission> <o-dd:play/> <o-dd:aggregate/> <o-ex:constraint> <o-dd:datetime> <o-dd:end>2004-12-31T00:00:00</o-dd:end> </o-dd:datetime> </o-ex:constraint> </o-ex:permission> <o-ex:party> <o-ex:context> <o-dd:uid>urn:univ:sguth</o-dd:uid> </o-ex:context> </o-ex:party> </o-ex:agreement> </o-ex:rights> C.2.2.5. “The DREL shall allow the specification of constraints associated with different levels of granularity in an aggregated learning object.”

For the requirement found in 2.1.5, we already introduced how to describe a complex asset. Here again the aggregated learning object consists of the two assets: the video urn:univ:lr-wuw-video-1 and the software urn:univ:lr-wuw-software-1. The license additionally shows three permissions and the party Department of IS (urn:univ:department-IS). The first permission “forAsset01” states that the video may be played without constraints. The second permission “forAsset02” states that the software may be executed on the machine with the CPU urn:univ:mac-11ab33, and finally the third permission “forPackage” states that the whole package may be duplicated until the end of 2004. <?xml version=”1.0” encoding=”UTF-8”?> <rights> <agreement> <asset id=”Asset-01”> <context> <uid>urn:univ:lr-wuw-video-1</uid> </context> </asset> 36 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

<asset id=”Asset-02”> <context> <uid>urn:univ:lr-wuw-software-1</uid> </context> </asset> <permission id= »forAsset01 »> <asset idref= »Asset-01 »/> <play> </permission> <permission id= »forAsset02 »> <asset idref=”Asset-02”/> <execute> <constraint> <cpu> <context> <uid> urn:univ:mac-11ab33</uid> </context> </cpu> </constraint> </execute> </permission> <permission id=”forPackage”> <asset idref=”Asset-01”/> <asset idref=”Asset-02”/> <duplicate> <constraint> <datetime> <end>2004-12-31T00:00:00</end> </datetime> </constraint> </duplicate> </permission> <party> <context> <uid>urn:univ:department-IS</uid> </context> </party> </agreement> </rights> C.2.2.6. “The DREL shall allow specification of different identification schemes to uniquely identify different portions of an aggregated learning object.”

This requirement has indirectly already been addressed in an earlier use case; please refer to the code example given in 2.2.5. The code example shows an aggregated learning object that consists of the two assets: the video urn:univ:lr-wuw-video-1 and the software urn:univ:lr-wuwsoftware-1. Both portions of the learning object have a unique local id “Asset-01” and “Asset-02” and a unique global id “urn:univ:lr-wuw-video-1” and “urn:univ:lr-wuw-software1.” Thus, different identification schemes are provided that allow a unique global identification and furthermore a local identification, e.g., for relating different permissions to different portions of the aggregated learning object (as shown in 2.2.5).

37 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

C.2.2.7. “The DREL shall allow the specification of constraints requiring the retention of specific metadata as an integral component of a learning object.”

In ODRL it is easy to express constraints to any kind of resource. In this case, the metadata is the resource and simply requires an ID. Thus, any constraint can be assigned to the metadata. See the example below, for example, that satisfies the OAI community, as their need is to specify rights over metadata. The given metadata has the ID urn:uniA:lo-B-metadata987 and the permission states that the metadata may be harvested only if the metadata is kept with the learning object.

<?xml version="1.0" encoding="UTF-8"?> <o-ex:rights xmlns:o-ex="http://odrl.net/1.1/ODRL-EX" xmlns:o-dd="http://odrl.net/1.1/ODRL-DD"> xmlns:oai="http://oaiInitiative.net/Vocabulary"> <o-ex:rights> <o-ex:offer> <o-ex:asset> <o-ex:context> <o-dd:uid> urn:uniA:lo-B-metadata987 </o-dd:uid> </o-ex:context> </o-ex:asset> <o-ex:permission> <oai:harvest> <o-ex:constraint> <oai:must-keep-metadata-with-lo/> </o-ex:constraint> </oai:harvest> </o-ex:permission> </o-ex:offer> </o-ex:rights>

C.2.3. Attribution Learning objects may be created from other learning objects and may require attribution. Therefore C.2.3.1 “The DREL shall allow the specification of attribution constraints associated with the use (aggregation, disaggregation, reference, etc) of learning objects” The ODRL data dictionary comprises the definition of the requirement “attribution” that can be assigned to rights. The requirement attribution is defined as follows: “The use of the asset must always include attribution of the asset owners.”

The following ODRL code example states that the asset (learning object) ODRLMapping to LTSC Requirements may be modified by urn:univ:mstrembe with the constraint that an attribution has to be made to the new asset. <?xml version="1.0" encoding="UTF-8"?> <o-ex:rights xmlns:o-ex="http://odrl.net/1.1/ODRL-EX" xmlns:o-dd="http://odrl.net/1.1/ODRL-DD"> <o-ex:agreement> <o-ex:asset> <o-ex:context> <o-dd:uid>urn.ieee.ltsc.odrlmapping.v1</o-dd:uid> <o-dd:name>ODRLMapping to LTSC Requirements</o-dd:name> </o-ex:asset> 38 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

<o-ex:permission> <o-dd:modify> <o-ex:requirement> <o-dd:attribution> <o-ex:context> <o-dd:remark> The LTSC Requirement mapping to ODRL has been originally created by S.Guth. </o-dd:remark> </o-ex:context> </o-dd:attribution> </o-ex:requirement> </o-dd:modify> </o-ex:permission> <o-ex:party> <o-ex:context> <o-dd:uid>urn:univ:mstrembe</o-dd:uid> </o-ex:context> </o-ex:party> </o-ex:agreement> </o-ex:rights>

C.2.4. Conditional use C.2.4.1. “The DREL shall allow for the specification of a set of conditions that must be fulfilled before a right (or set of rights) can be exercised.”

The ODRL language concept defines the “requirements” for this purpose. In the following example the right play may be performed to the resource urn:univ:lr-wuw-video-1 by the party urn:univ:sguth after the payment of € 100 has been made. <?xml version="1.0" encoding="UTF-8"?> <o-ex:rights xmlns:o-ex="http://odrl.net/1.1/ODRL-EX" xmlns:o-dd="http://odrl.net/1.1/ODRL-DD"> <o-ex:agreement> <o-ex:asset> <o-ex:context> <o-dd:uid> urn:univ:lr-wuw-video-1</o-dd:uid> </o-ex:context> </o-ex:asset> <o-ex:permission> <o-dd:play> <o-ex:requirement> <o-dd:prepay> <o-dd:payment> <o-dd:amount currency="EUR">100.00</o-dd:amount> </o-dd:payment> </o-dd:prepay> </o-ex:requirement> </o-dd:play> </o-ex:permission> <o-ex:party> <o-ex:context> <o-dd:uid>urn:univ:sguth</o-dd:uid> </o-ex:context> </o-ex:party> </o-ex:agreement> </o-ex:rights> 39 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

C.2.4.2. “The DREL shall allow the specification of heterogeneous constraints for access to learning objects by different individuals, groups as applicable.”

For the mapping of this requirement, please refer to 2.4.8, as this requirement can be expressed analogously.

C.2.4.3. “The DREL shall allow specification of constraints limiting the number of times learning objects can be used, accessed, distributed, and/or replicated.”

The ODRL data dictionary defines the constraint “count” for this purpose. In the following example the user urn:univ:sguth may perform the right play to the asset urn:univ:lr-wuw-video-1 only five times. The count constraint can be used to analogously narrow replication, usage, access, distribution permissions. <?xml version="1.0" encoding="UTF-8"?> <o-ex:rights xmlns:o-ex="http://odrl.net/1.1/ODRL-EX" xmlns:o-dd="http://odrl.net/1.1/ODRL-DD"> <o-ex:agreement> <o-ex:asset> <o-ex:context> <o-dd:uid> urn:univ:lr-wuw-video-1</o-dd:uid> </o-ex:context> </o-ex:asset> <o-ex:permission> <o-dd:play> <o-ex:constraint> <o-dd:count>5</o-dd:count> </o-ex:constraint> </o-dd:play> </o-ex:permission> <o-ex:party> <o-ex:context> <o-dd:uid>urn:univ:sguth</o-dd:uid> </o-ex:context> </o-ex:party> </o-ex:agreement> </o-ex:rights> C.2.4.4. “The DREL shall allow the specification of connectivity-based constraints, e.g., connection to an online service, web portal, web service, etc. associated with the use of learning objects.”

The ODRL data dictionary comprises the definition of the constraint “software” that can be assigned to permissions. The constraint “software” is defined as follows: “An identifiable software application that must be present. Use context to identify the device.

In the following ODRL code example, the party urn:univ:sguth may play the video urn:univ:lr-wuw-video-1 only with the web service that is running on port 8085 of http://ws.universal.org. <?xml version="1.0" encoding="UTF-8"?> <o-ex:rights xmlns:o-ex="http://odrl.net/1.1/ODRL-EX" xmlns:o-dd="http://odrl.net/1.1/ODRL-DD"> <o-ex:agreement> <o-ex:asset> <o-ex:context> 40 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

<o-dd:uid> urn:univ:lr-wuw-video-1</o-dd:uid> </o-ex:context> </o-ex:asset> <o-ex:permission> <o-dd:play> <o-ex:constraint> <o-dd:software> <o-ex:context> <o-dd:service>ws.universal.org:8085</o-dd:service> </o-ex:context> </o-dd:software> </o-ex:constraint> </o-dd:play> </o-ex:permission> <o-ex:party> <o-ex:context> <o-dd:uid>urn:univ:sguth</o-dd:uid> </o-ex:context> </o-ex:party> </o-ex:agreement> </o-ex:rights> C.2.4.5. “The DREL shall allow specification of device-based constraints, e.g., associated with the capabilities of specific reading systems or other applications, associated with the use of learning objects.”

The ODRL data dictionary defines several device based constraints, such as CPU, network, screen, memory, printer, etc. For example, the definition of the constraint “CPU” that can be assigned to permissions is defined as follows: “An identifiable computing system with a central processing unit (CPU). Use context to identify the device.”

In the following ODRL code example, the party urn:univ:sguth may play the video urn:univ:lr-wuw-video-1 only on the machine with the CPU urn:univ:mac-11ab33. <?xml version="1.0" encoding="UTF-8"?> <o-ex:rights xmlns:o-ex="http://odrl.net/1.1/ODRL-EX" xmlns:o-dd="http://odrl.net/1.1/ODRL-DD"> <o-ex:agreement> <o-ex:asset> <o-ex:context> <o-dd:uid> urn:univ:lr-wuw-video-1</o-dd:uid> </o-ex:context> </o-ex:asset> <o-ex:permission> <o-dd:play> <o-ex:constraint> <o-dd:cpu> <o-ex:context> <o-dd:uid> urn:univ:mac-11ab33</o-dd:uid> </o-ex:context> </o-dd:cpu> </o-ex:constraint> </o-dd:play> </o-ex:permission> <o-ex:party> 41 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

<o-ex:context> <o-dd:uid>urn:univ:sguth</o-dd:uid> </o-ex:context> </o-ex:party> </o-ex:agreement> </o-ex:rights>

C.2.4.6 “The DREL shall allow the specification of anonymous access to learning objects.”

This requirement can be coded in ODRL by assigning rights to a mission or role-specific party. In the following example, the resource urn:univ:lr-wuw-video-1 may be played by all parties that have the role “guest.” <?xml version="1.0" encoding="UTF-8"?> <o-ex:rights xmlns:o-ex="http://odrl.net/1.1/ODRL-EX" xmlns:o-dd="http://odrl.net/1.1/ODRL-DD"> <o-ex:agreement> <o-ex:asset> <o-ex:context> <o-dd:uid> urn:univ:lr-wuw-video-1</o-dd:uid> </o-ex:context> </o-ex:asset> <o-ex:permission> <o-dd:play/> </o-ex:permission> <o-ex:party> <o-ex:context> <o-dd:role>guest</o-dd:role> </o-ex:context> </o-ex:party> </o-ex:agreement> </o-ex:rights> C.2.4.7. “The DREL shall allow the specification of usage rights to learning objects for educational, research, and scholarly purposes.”

The ODRL data dictionary comprises the definition of the constraint “purpose” that can be assigned to permissions. The constraint “purpose” is defined as follows: “Specification of a specific purpose to which the usage is constrained.”

In the following ODRL code example, the party urn:univ:sguth may play the video urn:univ:lr-wuw-video-1 only for the purpose urn:anta.gov.au:vocab:public-edu, that is educational purposes. <?xml version="1.0" encoding="UTF-8"?> <o-ex:rights xmlns:o-ex="http://odrl.net/1.1/ODRL-EX" xmlns:o-dd="http://odrl.net/1.1/ODRL-DD"> <o-ex:agreement> <o-ex:asset> <o-ex:context> <o-dd:uid> urn:univ:lr-wuw-video-1</o-dd:uid> </o-ex:context> </o-ex:asset> <o-ex:permission> <o-dd:play> <o-ex:constraint> 42 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

<o-dd:purpose> <o-ex:context> <o-dd:uid>urn:anta.gov.au:vocab:public-edu</o-dd:uid> </o-ex:context> </o-dd:purpose> </o-ex:constraint> </o-dd:play> </o-ex:permission> <o-ex:party> <o-ex:context> <o-dd:uid>urn:univ:sguth</o-dd:uid> </o-ex:context> </o-ex:party> </o-ex:agreement> </o-ex:rights> C.2.4.8. “The DREL shall allow the specification of constraints associated with policies that may apply to individuals or groups.”

After discussing this requirement with the LTSC WG on DREL, it was understood that the following is meant by the requirement: “A DREL shall be able to express sets of constraints that apply to individuals, and it shall be able to express sets of constraints that apply to groups.”

The following ODRL example shows different requirements, respectively constraints for different users or user groups. In ODRL this requirement can be implemented by using containers. In containers that are of the “ex-or” type, the application must choose one of the alternatives in the container, i.e., the DRM system has to decide what constraint has to be taken. The first set of constraints (or requirements) should apply to company members and the second set of constraints should apply to the individual urn:univ:sguth. The code example states that company members may print the training note urn:univ:lr-wuw-trainignnotes-1 for € 0.50 and the individual urn:univ:sguth may print for € 1.00.

<?xml version="1.0" encoding="UTF-8"?> <rights> <offer> <asset> <context> <uid> urn:univ:lr-wuw-trainignnotes-1</uid> </context> </asset> <permission> <print> <container type=’ex-or’> <container type=’and’> <constraint> <group> <context> <role>CompanyMember</role> </context> </group> </constraint> <requirement> <prepay> 43 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

<payment> <amount currency=”EUR”>0.50</amount> </payment> </prepay> </requirement> </container> <container type=’and’> <constraint> <individual> <context> <uid> urn:univ:sguth </uid> </context> </individual> </constraint> <requirement> <prepay> <payment> <amount currency=”EUR”>1.00</amount> </payment> </prepay> </requirement> </container> </container> </print> </permission> </offer> </rights> C.2.4.9. “The DREL shall allow the specification of constraints associated with multi-tiered distribution, i.e., instances where learning objects are distributed by one entity that redistributes to other entities, of learning objects.”

The ODRL data dictionary includes the definition of various transfer rights. A transfer indicates a set of procedures in which the rights over the asset can be transferred. The ODRL data dictionary support the transfer rights sell, lend, give, lease. These rights can be constrained as any other usage right. In the example below, the further distribution of the asset urn:univ:lr-wuw-video-1 is constrained from the beginning of 1 January 2005. <?xml version="1.0" encoding="UTF-8"?> <o-ex:rights xmlns:o-ex="http://odrl.net/1.1/ODRL-EX" xmlns:o-dd="http://odrl.net/1.1/ODRL-DD"> <o-ex:agreement> <o-ex:asset> <o-ex:context> <o-dd:uid> urn:univ:lr-wuw-video-1</o-dd:uid> </o-ex:context> </o-ex:asset> <o-ex:permission> <o-dd:play> <o-dd:give> <o-ex:constraint> <o-dd:datetime> <o-dd:start>2005-01-01T00:00:00</o-dd:start> </o-dd:datetime> </o-ex:constraint> </o-dd:give> </o-ex:permission> 44 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

<o-ex:party> <o-ex:context> <o-dd:uid>urn:univ:sguth</o-dd:uid> </o-ex:context> </o-ex:party> </o-ex:agreement> </o-ex:rights> C.2.4.10. “The DREL shall support the unambiguous specification of time-based constraints such as specific times, fixed intervals, sliding intervals and metered intervals that can span across different time zones.”

The ODRL data dictionary comprises three different temporal constraints that can be assigned to rights.

The temporal constraints are time limits within which any entity can function and are defined as follows: 1. datetime: A date and/or time-based range. Date and Time value of “datetime” must conform to ISO 8601. This contains the following subentities: start—the beginning of the range (inclusive) end—the end of the range (inclusive) fixed—an exact point in date/time If there is no “start” and/or “end” value, then the range is open-ended.

NOTE—The subentity “start” must always be less than or equal to “end” and one must always be present if there is no “fixed” value. The subentity “fixed” can only appear by itself.

The listing below shows the use of an asset with a “datetime” constraint. The right play may be performed to the asset urn:univ:lr-wuw-video-1 by the party urn:univ:sguth from 31 December 2004 until 31 December 2005 Central European Time (+1:00). <?xml version="1.0" encoding="UTF-8"?> <o-ex:rights xmlns:o-ex="http://odrl.net/1.1/ODRL-EX" xmlns:o-dd="http://odrl.net/1.1/ODRL-DD"> <o-ex:agreement> <o-ex:asset> <o-ex:context> <o-dd:uid> urn:univ:lr-wuw-video-1</o-dd:uid> </o-ex:context> </o-ex:asset> <o-ex:permission> <o-dd:play> <o-ex:constraint> <o-dd:datetime> <o-dd:start>2004-12-31T00:00:00+01:00</o-dd:start> <o-dd:end>2005-12-31T00:00:00+01:00</o-dd:end> </o-dd:datetime> </o-ex:constraint> </o-dd:play> </o-ex:permission> <o-ex:party> <o-ex:context> <o-dd:uid>urn:univ:sguth</o-dd:uid> </o-ex:context> </o-ex:party> </o-ex:agreement> </o-ex:rights>

45 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

2. accumulated: A date and/or time-based range. The maximum period of metered usage time. Period value must conform to ISO 8601. For example, “P30H” indicates a 30 h period.

The listing below shows the use of an asset with the “accumulated” constraint. The right play may be performed to the asset urn:univ:lr-wuw-video-1 by the party urn:univ:sguth for an accumulated 30 h period. <?xml version="1.0" encoding="UTF-8"?> <o-ex:rights xmlns:o-ex="http://odrl.net/1.1/ODRL-EX" xmlns:o-dd="http://odrl.net/1.1/ODRL-DD"> <o-ex:agreement> <o-ex:asset> <o-ex:context> <o-dd:uid> urn:univ:lr-wuw-video-1</o-dd:uid> </o-ex:context> </o-ex:asset> <o-ex:permission> <o-dd:play> <o-ex:constraint> <o-dd:accumulated>P30H</o-dd:accumulated> </o-ex:constraint> </o-dd:play> </o-ex:permission> <o-ex:party> <o-ex:context> <o-dd:uid>urn:univ:sguth</o-dd:uid> </o-ex:context> </o-ex:party> </o-ex:agreement> </o-ex:rights> 3. interval: Recurring period of time in which the rights can be exercised. Date and Time value must conform to ISO 8601. For example, “P7D” indicates a 7 day period.

The listing below shows the use of an asset with the “interval” constraint. The right “play” may be performed to the asset urn:univ:lr-wuw-video-1 by the party urn:univ:sguth for a 7 day period. <?xml version="1.0" encoding="UTF-8"?> <o-ex:rights xmlns:o-ex="http://odrl.net/1.1/ODRL-EX" xmlns:o-dd="http://odrl.net/1.1/ODRL-DD"> <o-ex:agreement> <o-ex:asset> <o-ex:context> <o-dd:uid> urn:univ:lr-wuw-video-1</o-dd:uid> </o-ex:context> </o-ex:asset> <o-ex:permission> <o-dd:play> <o-ex:constraint> <o-dd:interval>P7D</o-dd:interval> </o-ex:constraint> </o-dd:play> </o-ex:permission> <o-ex:party> <o-ex:context> <o-dd:uid>urn:univ:sguth</o-dd:uid> </o-ex:context> 46 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

</o-ex:party> </o-ex:agreement> </o-ex:rights> C.2.4.11 The DREL shall support the specification of fees in industry standard terms.

The ODRL data dictionary comprises three different payment requirements that can be assigned to rights: 1.

prepay—The amount due prior to the granting/use of the rights. Use payment entity to specify the payment. Temporal constraints may also be used.

2.

postpay—The amount due after the use of the rights. Use payment entity to specify the payment. Temporal constraints may also be used.

3.

peruse—The amount due for each use of the granted rights. Use payment entity to specify the payment.

The payment element may further specify the prepay, postpay, and peruse requirement with amount, currency, tax percent and tax code. The listing below states that the video urn:univ:lr-wuw-video1 may be played by the party urn:univ:sguth after the payment of € 20.00 has been made. <?xml version="1.0" encoding="UTF-8"?> <o-ex:rights xmlns:o-ex="http://odrl.net/1.1/ODRL-EX" xmlns:o-dd="http://odrl.net/1.1/ODRL-DD"> <o-ex:agreement> <o-ex:asset> <o-ex:context> <o-dd:uid> urn:univ:lr-wuw-video-1</o-dd:uid> </o-ex:context> </o-ex:asset> <o-ex:permission> <o-dd:play> <o-ex:requirement> <o-dd:prepay> <o-dd:payment> <o-dd:amount currency="EUR">20.00</o-dd:amount> </o-dd:payment> </o-dd:prepay> </o-ex:requirement> </o-dd:play> </o-ex:permission> <o-ex:party> <o-ex:context> <o-dd:uid>urn:univ:sguth</o-dd:uid> </o-ex:context> </o-ex:party> </o-ex:agreement> </o-ex:rights> C.2.4.12. “The DREL shall support the specification of information about portions of learning objects, including both identified portions and generic portions (such as ‘any 5 pages’) in order to support limiting rights to these certain portions.”

The ODRL data dictionary includes the definition of the aspect constraint “unit” that can be assigned to rights. The constraint “unit” is defined as follows: Specification of constraints on the whole asset or sub-parts of the asset. “Unit” contains the following attribute: 47 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

— type: The classification of the sub-unit part type. The values for the type attribute must be from a well known vocabulary and represented as a URI. If constraint elements have further child elements, the child element applies to the parent constraint. In the following example, the user urn:univ:sguth may display not the entire book, but “any 5 pages” of the book urn:univ:lr-wuw-book-1. The vocabulary for the unit type NumberOfPages has been taken from an ONIX vocabulary. <?xml version="1.0" encoding="UTF-8"?><o-ex:rights xmlns:oex="http://odrl.net/1.1/ODRL-EX" xmlns:o-dd="http://odrl.net/1.1/ODRL-DD"> <o-ex:agreement> <o-ex:asset> <o-ex:context> <o-dd:uid> urn:univ:lr-wuw-book-1</o-dd:uid> </o-ex:context> </o-ex:asset> <o-ex:permission> <o-dd:display> <o-ex:constraint> <o-dd:unit o-ex:type="onix:NumberOfPages"> <o-ex:constraint> <o-dd:range> <o-dd:min>1</o-dd:min> <o-dd:max>5</o-dd:max> </o-dd:range> </o-ex:constraint> </o-dd:unit> </o-ex:constraint> </o-dd:display> </o-ex:permission> <o-ex:party> <o-ex:context> <o-dd:uid>urn:univ:sguth</o-dd:uid> </o-ex:context> </o-ex:party> </o-ex:agreement> </o-ex:rights> C.2.4.13. “The DREL shall support distribution and management of free learning objects.”

To express the free usage of a learning object, simply the payment requirement element is left out (first ODRL code example). To make the free use more explicit the amount of the payment requirement can be set to zero (second ODRL code example).

The listing below states that the video urn:univ:lr-wuw-video-1 may be played by the party urn:univ:sguth without constraints or payment requirements.

<?xml version="1.0" encoding="UTF-8"?> <o-ex:rights xmlns:o-ex="http://odrl.net/1.1/ODRL-EX" xmlns:o-dd="http://odrl.net/1.1/ODRL-DD"> <o-ex:agreement> <o-ex:asset> <o-ex:context> <o-dd:uid> urn:univ:lr-wuw-video-1</o-dd:uid> </o-ex:context> </o-ex:asset> <o-ex:permission> 48 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

<o-dd:play/> </o-ex:permission> <o-ex:party> <o-ex:context> <o-dd:uid>urn:univ:sguth</o-dd:uid> </o-ex:context> </o-ex:party> </o-ex:agreement> </o-ex:rights> The listing below states that the video urn:univ:lr-wuw-video-1 may be played by the party urn:univ:sguth without constraints or payment requirements. The payment requirements have explicitly been set to zero.

<?xml version="1.0" encoding="UTF-8"?> <o-ex:rights xmlns:o-ex="http://odrl.net/1.1/ODRL-EX" xmlns:o-dd="http://odrl.net/1.1/ODRL-DD"> <o-ex:agreement> <o-ex:asset> <o-ex:context> <o-dd:uid> urn:univ:lr-wuw-video-1</o-dd:uid> </o-ex:context> </o-ex:asset> <o-ex:permission> <o-dd:play> <o-ex:requirement> <o-dd:prepay> <o-dd:payment> <o-dd:amount currency="EUR">0.00</o-dd:amount> </o-dd:payment> </o-dd:prepay> </o-ex:requirement> </o-dd:play> </o-ex:permission> <o-ex:party> <o-ex:context> <o-dd:uid>urn:univ:sguth</o-dd:uid> </o-ex:context> </o-ex:party> </o-ex:agreement> </o-ex:rights> C.2.4.14. “The DREL shall support specifying a price, including a price of 'free,' for unlimited usage of a learning object.”

Unlimited usage is expressed via leaving out the constraints. In the example below, the video urn:univ:lr-wuw-video-1 may be played by the party urn:univ:sguth without constraints (unlimited) or requirements (“for free”). For a price of “free,” please refer to the second example of 2.4 13. <?xml version="1.0" encoding="UTF-8"?> <o-ex:rights xmlns:o-ex="http://odrl.net/1.1/ODRL-EX" xmlns:o-dd="http://odrl.net/1.1/ODRL-DD"> <o-ex:agreement> <o-ex:asset> <o-ex:context> <o-dd:uid> urn:univ:lr-wuw-video-1</o-dd:uid> </o-ex:context> </o-ex:asset> 49 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

<o-ex:permission> <o-dd:play/> </o-ex:permission> <o-ex:party> <o-ex:context> <o-dd:uid>urn:univ:sguth</o-dd:uid> </o-ex:context> </o-ex:party> </o-ex:agreement> </o-ex:rights> C.2.4.15. “The DREL shall support the specification of payment of a fee for each use of a learning object that may be constrained by connectivity-based conditions, e.g., connection to an online service, web portal, web service, etc.”

For an overview of expressing payments, please refer to 2.4.11. Constraints and requirements can be either assigned to one particular right (see example below) or to all granted rights in one permission. In the following example, the rights “play” and “duplicate” both are constrained to the software service http://www.universal.org/ but each right has different payment requirements. The party urn:univ:sguth has to pay € 1.00 for playing the video urn:univ:lr-wuw-video-1 once and has to pay € 10.00 each time the video is duplicated. <?xml version="1.0" encoding="UTF-8"?> <o-ex:rights xmlns:o-ex="http://odrl.net/1.1/ODRL-EX" xmlns:o-dd="http://odrl.net/1.1/ODRL-DD"> <o-ex:agreement> <o-ex:asset> <o-ex:context> <o-dd:uid> urn:univ:lr-wuw-video-1</o-dd:uid> </o-ex:context> </o-ex:asset> <o-ex:permission> <o-dd:play> <o-ex:requirement> <o-dd:peruse> <o-dd:payment> <o-dd:amount currency="EUR">1.00</o-dd:amount> </o-dd:payment> </o-dd:peruse> </o-ex:requirement> </o-dd:play> <o-dd:duplicate> <o-ex:requirement> <o-dd:peruse> <o-dd:payment> <o-dd:amount currency="EUR">10.00</o-dd:amount> </o-dd:payment> </o-dd:peruse> </o-ex:requirement> </o-dd:duplicate> <o-ex:constraint> <o-dd:software> <o-ex:context> <o-dd:service>http://www.universal.org/</o-dd:service> </o-ex:context> 50 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

</o-dd:software> </o-ex:constraint> </o-ex:permission> <o-ex:party> <o-ex:context> <o-dd:uid>urn:univ:sguth</o-dd:uid> </o-ex:context> </o-ex:party> </o-ex:agreement> </o-ex:rights> C.2.4.16 “The DREL shall support subscription-based pricing and access to learning objects.”

This requirement is supported by ODRL via assigning rights to a specific role, e.g., students, subscribers, teachers, etc. The ODRL expression below grants the right to “play” the video urn:univ:lr-wuwvideo-1 within the fixed subscription interval of e.g., 31 December 2004 and 31 December 2005 to the role “subscriber.” <?xml version="1.0" encoding="UTF-8"?> <o-ex:rights xmlns:o-ex="http://odrl.net/1.1/ODRL-EX" xmlns:o-dd="http://odrl.net/1.1/ODRL-DD"> <o-ex:agreement> <o-ex:asset> <o-ex:context> <o-dd:uid> urn:univ:lr-wuw-video-1</o-dd:uid> </o-ex:context> </o-ex:asset> <o-ex:permission> <o-dd:play> <o-ex:constraint> <o-dd:datetime> <o-dd:start>2004-12-31T00:00:00+01:00</o-dd:start> <o-dd:end>2005-12-31T00:00:00+01:00</o-dd:end> </o-dd:datetime> </o-ex:constraint> </o-dd:play> </o-ex:permission> <o-ex:party> <o-ex:context> <o-dd:role>subscriber</o-dd:role> </o-ex:context> </o-ex:party> </o-ex:agreement> </o-ex:rights> C.2.4.17. “The DREL shall support time-based pricing rules for learning objects.”

This requirement is provided by joining temporal constraints and payment requirements within containers.

To express a payment requirement, for example, that is dependent from the current local time the following ODRL expression would be used. Here, to play the video urn:univ:lr-wuw-video-1 costs a student € 0.50 in the morning (from 0.00 hours to 12:00 hours) and € 0.90 in the afternoon (from 12:00 hours to 24:00 hours).

<rights> <agreement> 51 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

<asset> <context> <uid>urn:univ:lr-wuw-video-1</uid> </context> </asset> <permission> <play> <requirement> <container type="ex-or"> <container type="and"> <peruse> <payment> <amount currency="EUR">0.50</amount> </payment> </peruse> <datetime> <start>00:00:00<start> <end>12:00:00</end> </datetime> </container> <container type="and"> <peruse> <payment> <amount currency="EUR">0.90</amount> </payment> </peruse> <datetime> <start>12:00:00<start> <end>24:00:00</end> </datetime> </container> </container> </requirement> </play> </permission> <party> <context> <role>student</role> </context> </agreement> </rights> C.2.4.18. “The DREL shall support the specification of learning object usage under a sitelicense.”

Implementing such a requirement in ODRL depends on how a “site” is identified in the system that processes the ODRL expression. A site could be identified by a certain subnetwork, which can be identified via a range of IP addresses. Another way to identify a “site” is to identify a certain group of people. The ODRL code below shows the implementation of both cases. The first example shows an ODRL instance that restricts the right play to the group of people with the ID urn:wu-wien:is which could be the “site” of the department of information systems at Vienna University. In the second example the right play is restricted via the network constraint to a site. The “site” is identified by all computers that have an IP address beginning with 137.208.224.

Identifying a site via the group constraint: <rights> <agreement> <asset> 52 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

<context> <uid>urn:univ:lr-wuw-video-1</uid> </context> </asset> <permission> <play> <constraint> <group> <context> <uid>urn:wu-wien.ac.at:is</uid> </context> </group> </constraint> </play> </permission> </agreement> </rights> Identifying a site via the network constraint: <rights> <agreement> <asset> <context> <uid>urn:univ:lr-wuw-video-1</uid> </context> </asset> <permission> <play> <constraint> <network> <context> <uid>137.208.224.XXX</uid> </context> </network> </constraint> </play> </permission> </agreement> </rights> C.2.4.19. “The DREL shall support the specification of constraints related to the manner in which the use of a learning object is supervised, e.g., a teacher supervises taking a test.”

To implement this requirement, we recommend reusing a vocabulary that clearly states what “supervises” means, respectively defines different forms of supervision, e.g., the LOM vocabulary. The respective right can then be constrained by the “purpose constraint.” See the corresponding ODRL offer code example below, where the right play to the resource urn:univ:lr-wuw-video-1 is restricted to the purpose “examination.” <rights> <offer> <asset> <context> <uid>urn:univ:lr-wuw-video-1</uid> </context> </asset> <permission> <play> 53 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

<constraint>

<purpose> <context> <uid>uri:lom.org/vocab/supervision/examination</uid> </context> </purpose> </constraint> </play> </permission> </offer> </rights> C.2.5. Tracking C.2.5.1 “The DREL shall allow the specification of requirements for tracking access, usage, distribution and purchase of content.”

The ODRL data dictionary comprises the definition of the requirement “tracked” that can be assigned to permissions. The requirement “tracked” is defined as follows: “The user will be tracked for their use of the asset. The user must be aware of privacy policy of the service provider.”

In the example below, the video urn:univ:lr-wuw-video-1 may be played by the party urn:univ:sguth whereby the usage right play is tracked. Please note that additional tracking details could be specified (e.g., where or how often the asset is tracked). <?xml version="1.0" encoding="UTF-8"?> <o-ex:rights xmlns:o-ex="http://odrl.net/1.1/ODRL-EX" xmlns:o-dd="http://odrl.net/1.1/ODRL-DD"> <o-ex:agreement> <o-ex:asset> <o-ex:context> <o-dd:uid> urn:univ:lr-wuw-video-1</o-dd:uid> </o-ex:context> </o-ex:asset> <o-dd:play> <o-ex:requirement> <o-dd:tracked> <o-ex:context> <o-dd:remark> The frequency of usages is tracked by the service provider. </o-dd:remark> </o-ex:context> </o-dd:tracked> </o-ex:requirement> </o-dd:play> <o-ex:party> <o-ex:context> <o-dd:uid>urn:univ:sguth</o-dd:uid> </o-ex:context> </o-ex:party> </o-ex:agreement> </o-ex:rights>

54 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

C.2.6. Offers The ability to offer learning objects to individuals or groups of people is important within learning, education, and training community. The offers themselves can be subject to a variety of conditions such as fees, time, membership, etc. Furthermore, offers can specify additional constraints on the use of learning object being offered.

C.2.6.1 “The DREL shall allow the specification of offers. Both the offers and the use of the learning objects may be subject to constraints.”

The ODRL language concept allows for the formulation of offers and agreements. The document mostly includes agreements and, for example, subclause 2.1.2 shows a fully qualified offer. Both, agreement and offer may be specified by e.g., asset, permission, parties, etc. Permission may be constrained in general, thus the use of learning objects can be constraint in offers. If the offer itself shall be constraint, ODRL allows to specify a date in the context element of the offer. In the example below, the offer with the id urn:uni:offer:1111 expires 31 December, 2005 and the play permission to the asset urn:univ:lr-wuw-video-1 expires 31 December 2006. Note that with ODRL several parties can be identified. The offer below specifies the rightsholder urn:univ:gneumann (distinguished from the consumer by the rightsholder element) of the asset urn:univ:lr-wuw-video-1. <?xml version="1.0" encoding="UTF-8"?> <o-ex:rights xmlns:o-ex="http://odrl.net/1.1/ODRL-EX" xmlns:o-dd="http://odrl.net/1.1/ODRL-DD"> <o-ex:offer> <o-ex:context> <o-dd:uid> urn:uni:offer:1111 </o-dd:uid> <o-dd:date> <o-dd:end>2005-12-31T00:00:00+01:00</o-dd:end> </o-dd:date> </o-ex:context> <o-ex:asset> <o-ex:context> <o-dd:uid> urn:univ:lr-wuw-video-1</o-dd:uid> </o-ex:context> </o-ex:asset> <o-ex:permission> <o-dd:play/> <o-ex:constraint> <o-dd:datetime> <o-dd:end>2006-12-31T00:00:00+01:00</o-dd:end> </o-dd:datetime> </o-ex:constraint> </o-ex:permission> <o-ex:party> <o-ex:rightsholder/> <o-ex:context> <o-dd:uid> urn:univ:gneumann </o-dd:uid> </o-ex:context> </o-ex:party> </o-ex:offer> </o-ex:rights> Alternatively, an offer can be treated as a “thing” having a unique ID to which ODRL rights expressions can be expressed. Assuming, additional constraints shall be expressed for the offer above with the UID

55 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

<urn:uni:offer:1111>, then the following expression can be formulated, that restricts the offer to the country Austria: <?xml version="1.0" encoding="UTF-8"?> <o-ex:offer> <o-ex:asset> <o-ex:context> <o-dd:uid> urn:uni:offer:1111 </o-dd:uid> </o-ex:context> </o-ex:asset> <o-ex:constraint> <o-dd:spatial> <o-ex:context> <o-dd:uid> urn:countries:austria </o-dd:uid> </o-ex:context> </o-dd:spatial> </o-ex:constraint> </o-ex:offer> </o-ex:rights>

56 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

Annex D (informative) Mapping requirements to MPEG REL Manuel Ham, ContentGuard June 24, 2004 Version 1.1

D.1. Introduction The goal of this document is to provide a set of MPEG REL examples relevant to the eLearning community. The term “MPEG REL” is used to refer to the international standard on Rights Expression Language, ISO/IEC 21000-5. ISO/IEC 21000-5 provides more detail on the syntax and the semantics of the rights expression language.

D.2 Example #1—University offer This is an example of a particular university issuing an offer to any of its students to view (play) any ebook in the university’s library.

If a student decides to accept the offer, then the university’s licensing service needs to verify that the consumer is a student. The student presents a student-certificate to the licensing service. Upon verification, the licensing service generates a consumer license.

In this example, the consumer’s license specifies that the stated student, Alice, has the right to play the stated e-book, “ABC Book.”

University Issues This Offer License Offer-grant

Alice Receives This License

Any-student Obtain

License

Usage-grant

Usage-grant Alice

Any-student Matching grants

Play

Play ABC Book

Any-ebook

Figure D.1—University offer

57 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

This example satisfies the following IEEE 1484.4 LTSC DREL requirements: Table D.1—University offer Requirement

Validation description

2.1.1 (Formal grammar)

This example is based on the ISO/IEC 21000-5 specification, which formally defines the syntax and semantics of a rights expression language. ISO/IEC 21000-5 is an international standard.

2.1.3 (Articulation of roles)

This example shows how the role of “student” is defined by a particular university. The university issues offers to “students” who must present a student-certificate to prove they are in fact students.

2.1.4 (Unique identifiers for learning objects)

This example shows the use of unique identifiers to refer to the e-book “ABCBook.”

2.1.5 (Single rights expression to apply to a class of learning objects)

This example shows a university’s offer using a single rights expression to refer to all the e-books in the university’s library.

2.1.7 (Core set of primitive constructs)

This example uses core primitives from the rights expression language.

2.4.7 (Specification of usage rights to learning objects for educational, research, and scholarly purposes)

This example allows any university student to view any of the e-books in the university’s library.

2.4.13 (Distribution and management of free learning objects)

This example offers for free to any university student the permission to view any e-book in the university’s library.

2.6.1 (Specification of offers)

This example shows a basic offer issued by a particular university.

This is the MPEG REL coding for the university’s offer:

<?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <grant licensePartId="offerGrant"> <forAll varName="anyStudent"> <propertyPossessor> <sx:propertyUri definition="urn:myu:student"/> </propertyPossessor> </forAll> <forAll varName="anyBook"> <anXmlExpression>digitalResource/nonSecureIndirect[startswith(@URI,'http://www.myu.edu/library')]</anXmlExpression> </forAll> <principal varRef="anyStudent"/> <obtain/> <grant licensePartId="usageGrant"> <principal varRef="anyStudent"/> <mx:play/> <digitalResource varRef="anyBook"/> </grant> <!-- Optional fee condition (see “Comments” below) may be added here--> </grant> <issuer/> </license> 58 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

This is the MPEG REL coding for Alice’s student-certificate: <?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <grant licensePartId="Alice-student-certificate"> <keyHolder licensePartId="Alice-key"> <info> <dsig:KeyValue> <dsig:RSAKeyValue> <dsig:Modulus>acmM4ccyzA==</dsig:Modulus> <dsig:Exponent>AQABAA==</dsig:Exponent> </dsig:RSAKeyValue> </dsig:KeyValue> </info> </keyHolder> <possessProperty/> <sx:propertyUri definition="urn:myu:student"/> </grant> <issuer/> </license> This is the MPEG REL coding for the resulting consumer license: <?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <grant licensePartId="usageGrant"> <keyHolder licensePartId="Alice"> <info> <dsig:KeyValue> <dsig:RSAKeyValue> <dsig:Modulus>acmM4ccyzA==</dsig:Modulus> <dsig:Exponent>AQABAA==</dsig:Exponent> </dsig:RSAKeyValue> </dsig:KeyValue> </info> </keyHolder> <mx:play/> <digitalResource> <nonSecureIndirect URI="http://www.myu.edu/library/ABCBook.spd"/> </digitalResource> </grant> <issuer/> </license>

59 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

D.2.1 Comments In this example, the absence of a fee condition on the offer means that there is no charge for this offer.

However, the example can be further enhanced to require a fee condition on the offer itself. The MPEG REL allows for the specification of conditions to the offer-grant as well as to the usage-grant. The fee condition might look as follows:

<sx:feePerUse> <sx:rate> <sx:amount>1.00</sx:amount> <sx:currency xmlns:iso="urn:mpeg:mpeg21:2003:01-REL-SXNS:currency">iso:USD</sx:currency> </sx:rate> <sx:to> <sx:aba> <sx:institution>99991212</sx:institution> <sx:account>1234567890</sx:account> </sx:aba> </sx:to> </sx:feePerUse>

D.3 Example #2—Tracking example This is an example of a consumer’s license that specifies a tracking condition when content is used. In order to satisfy legal requirements, an educational institution might establish a tracking service to record usage information in order to produce usage reports on learning objects. Moreover, this example allows anonymous access to the stated resource.

Consumer license with tracking condition License Usage-grant Anyone Play ABC Book Tracking condition

Figure D.2—Tracking example

60 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

This example satisfies the following IEEE 1484.4 LTSC DREL requirements: Table D.2—Tracking Requirement

Validation description

2.1.1 (Formal grammar)

This example is based on the ISO/IEC 21000-5 specification, which formally defines the syntax and semantics of a rights expression language. ISO/IEC 21000-5 is an international standard.

2.1.4 (Unique identifiers for learning objects)

This example shows the use of unique identifiers to refer to the e-book “ABC Book.”

2.1.7 (Core set of primitive constructs)

This example uses core primitives from the rights expression language.

2.4.1 (Support conditions that shall be fulfilled before a right is exercised)

This example has a tracking condition that must be fulfilled prior to granting permission to view the specified e-book.

2.4.6 (Anonymous access)

This example lets anyone view the specified e-book. There is no principal specified in the license.

2.4.13 (Distribution and management of free learning objects)

This example allows anyone to view the stated e-book for free as long as the use is tracked.

2.4.14 (Unlimited use for a fee or free)

This example allows anyone to play unlimited times the specified content.

Since there’s no fee condition, the unlimited use is for free.

2.5.1 (Tracking conditions)

This example has a tracking condition.

This is the MPEG REL coding for this consumer license:

<?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <grant licensePartId="usageGrant"> <mx:play/> <digitalResource licensePartId="eBook"> <nonSecureIndirect URI="http://www.myu.edu/library/ABCBook.spd"/> </digitalResource> <sx:trackReport licensePartId="trackUsage"> <serviceReference> <sx:uddi> <sx:serviceKey> <sx:uuid>1F8903B0-FC03-4c5b-A445-AAFCCEC01111</sx:uuid> </sx:serviceKey> </sx:uddi> <serviceParameters> <datum> <mx:play/> </datum> <datum> <digitalResource licensePartIdRef="eBook"/> 61 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

</datum> </serviceParameters> </serviceReference> </sx:trackReport> </grant> <issuer/> </license> D.3.1 Comments In this example, the absence of a fee condition implies that there are no fees associated with this license.

D.4 Example #3—Multi-tier distribution This use case illustrates how to use the MPEG REL in a multi-tier distribution business model, which focuses on specifying rights and conditions for all participants in the distribution chain. In this example, a music publisher, PDQ Records, allows other parties to sell consumers rights to play music from its library.

Consumers pay a flat fee of $16.50 for each recording they buy—$1.50 goes to PDQ records and $15.00 goes to the educational distributor. Figure D.3 illustrates this use case:

Figure D.3—Multi-tier distribution To represent this use case: — PDQ Records must provide licenses to its distributor stipulating the terms of the distribution agreement.

— Distributors may provide licenses to consumers stipulating the agreed-upon fee structure.

62 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

This example satisfies the following IEEE 1484.4 LTSC DREL requirements: Table D.3—Multi-tier distribution Requirement

Validation description

2.1.1 (Formal grammar)

This example is based on the ISO/IEC 21000-5 specification, which formally defines the syntax and semantics of a rights expression language. ISO/IEC 21000-5 is an international standard.

2.1.3 (Articulation of roles)

This example shows how the role of a “distributor” is defined by PDQ Records through the issuance of certificates.

2.1.4 (Unique identifiers for learning objects)

This example shows the use of unique identifiers to refer to a particular song.

2.1.5 (Class of LOs)

An Xml-expression is used to identify songs in the PDQ Records library.

2.1.7 (Core set of primitive constructs)

This example uses core primitives from the rights expression language.

2.4.1 (Support conditions that shall be fulfilled before a right is exercised)

This example specifies conditions that must be satisfied in order to exercise the stated right.

2.4.2 (Heterogeneous constraints to use content by individuals or groups)

This example shows that any “distributor” can issue licenses to consumers who purchase the specified content.

2.4.9 (Multi-tiered distribution)

This example shows the rights and conditions issued by the rights holder, PDQ Records, to its distributors (as identified by the appropriate certificate). These rights and conditions also provide the rights and conditions that may be issued to consumers.

Thus, the example shows a mechanism to express rights to multiple participants in the value chain.

2.4.11 (Fee-based usage)

In this example, the consumer is charged a flat fee to play the specified content.

2.4.14 (Unlimited use for a fee or free)

After the consumer pays a flat fee, the consumer is entitled to unlimited use of the specified content. This example shows how to specify a service to verify payment.

The following subclauses describe how to specify this information in the MPEG REL. D.4.1. Constructing licenses for distributors In this example, PDQ Records provides the following two licenses to each of its distributors: — A license that identifies that principal as a PDQ Records distributor.

— A license that grants the distributor the right to issue licenses to consumers.

To identify a principal as a PDQ Records distributor, the first license has a grant containing the possessProperty right. The possessProperty right grants the identified principal the right to claim ownership of the characteristics listed as resources in the grant. A license granting the possessProperty right is sometimes called a “certificate.” Figure D.4 illustrates the structure of a certificate:

63 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

PDQ Distributor Certificate License Identity-grant Educational Distributor Possess Property Distributor

Figure D.4â&#x20AC;&#x201D;Licenses for Distributors In the following example license, Educational Distributor is identified as the holder of a specific key and is granted possession of the property of being a PDQ Records distributor.

In this example and all later examples, the prefix sx: identifies elements from the standard extension, mx: identifies elements from the MPEG REL multimedia extension, and dsig: refers to the namespace that defines XML signatures. All other elements are defined in the MPEG REL Core. For information on how schema namespaces are declared in the license file, see the page that describes licenses.

Educational Distributor possesses the property of being a distributor: <?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <!--Educational Distributor possesses the property of being a PDQ Records distributor--> <grant> <keyHolder licensePartId="educationalDistributor"> <info> <dsig:KeyValue> <dsig:RSAKeyValue> <dsig:Modulus>A1KZGazht24NIu/y2mZrve++61KoLM==</dsig:Modulus> <dsig:Exponent>AQAQAA==</dsig:Exponent> </dsig:RSAKeyValue> </dsig:KeyValue> </info> </keyHolder> <possessProperty/> <sx:propertyUri definition="urn:pdq:distributor"/> </grant> <issuer/> </license> In addition to this certificate, PDQ Records must issue a license to its distributors representing the publisher/distributor relationship. Figure D.5 illustrates the basic structure of this license:

64 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

Figure D.5—License for distributors inclusive of publisher relationship This license represents the publisher/distributor relationship as follows: — The principal to whom the grant is issued is identified as possessing the property of being a PDQ Records distributor. This example uses a variable defined using the forAll element to identify PDQ Records distributors using pattern matching. The forAll element contains a propertyPosessor pattern that stipulates that matching principals must possess the property of being a distributor.

— The distributor is granted the issue right, which allows the distributor to issue the consumer grant that is listed as a resource within this grant.

— The consumer grant stipulates the type of grant that the distributor may issue to consumers. The consumer grant specifies that the distributor can grant any one principal the right to play any one recording that PDQ Records owns provided that the consumer pays two flat fees—$1.50 to PDQ records and $15.00 to the distributor. The two feeFlat conditions are enclosed in an allConditions element, which specifies that both feeFlat conditions must be satisfied before the consumer may exercise the play right. For each fee, a service reference is checked to determine whether the consumer has already paid.

The consumer grant uses the following variables, which are defined using forAll elements.

65 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

Table D.4â&#x20AC;&#x201D;Consumer grant variables Variable

Definition

anyone

This forAll element does not contain a pattern, which means that the variable is unqualified and matches anything used as a principal. This enables the distributor to issue this grant to any one principal.

songByPDQ

This forAll element is qualified with an XML expression that identifies songs in the PDQ Records library.

paymentVerificationService

This forAll element does not contain a pattern, which means that the variable is unqualified and matches anything used as a payment verification service. This enables the distributor specify the service used to verify whether the consumer has already paid the $15.00 fee.

paymentService

This forAll element does not contain a pattern, which means that the variable is unqualified and matches anything used as a payment service. This enables the distributor specify the service that will collect the $15.00 fee from the consumer.

PDQ Records grants distributors the right to issue licenses to consumers:

<?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <!-- Any PDQ records distributor may issue the contained grant --> <grant> <!--This variable matches principals that are PDQ records distributors --> <forAll varName="distributor"> <propertyPossessor> <sx:propertyUri definition="urn:pdq:distributor"/> <trustedRootIssuers/> </propertyPossessor> </forAll> <!-- This variable matches any principal--> <forAll varName="anyone"/> <!-- This variable matches any song owned by PDQ records --> <forAll varName="songByPDQ"> <anXmlExpression>digitalResource/nonSecureIndirect[startswith(@URI,'http://www.pdqrecords.com/')]</anXmlExpression> </forAll> <!-- This variable matches any payment verification service the distributor wants to use --> <forAll varName="paymentVerificationService"/> <!-- This variable matches any payment collection service the distributor wants to use --> <forAll varName="paymentService"/> <principal varRef="distributor"/> <issue/> <!-- The grant that a distributor may issue --> <grant> <principal varRef="anyone"/> <mx:play/> <digitalResource varRef="songByPDQ"/> 66 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

<allConditions> <sx:feeFlat> <serviceReference> <sx:uddi> <sx:serviceKey> <sx:uuid>D04951E4-332C-4693-B7DBD3D1D1C20844</sx:uuid> </sx:serviceKey> </sx:uddi> <serviceParameters> <datum> <principal varRef="anyone"/> </datum> <datum> <digitalResource varRef="songByPDQ"/> </datum> </serviceParameters> </serviceReference> <sx:rate> <sx:amount>1.50</sx:amount> <sx:currency xmlns:iso="urn:mpeg:mpeg21:2003:01-REL-SXNS:currency">iso:USD</sx:currency> </sx:rate> <sx:to> <sx:aba> <sx:institution>139371581</sx:institution> <sx:account>111111</sx:account> </sx:aba> </sx:to> </sx:feeFlat> <sx:feeFlat> <serviceReference varRef="paymentVerificationService"/> <sx:rate> <sx:amount>15.00</sx:amount> <sx:currency xmlns:iso="urn:mpeg:mpeg21:2003:01-REL-SXNS:currency">iso:USD</sx:currency> </sx:rate> <sx:to> <sx:paymentService> <serviceReference varRef="paymentService"/> </sx:paymentService> </sx:to> </sx:feeFlat> </allConditions> </grant> </grant> <issuer/> </license> D.4.2 Constructing licenses for consumers When a consumer purchases a song from one of the PDQ Records distributors, the distributor exercises the issue right to issue the consumer's license. At that time, the distributor replaces the variables in the consumer grant in the distribution license with specific information.

Figure D.6 illustrates the structure of the license that Educational Distributor issues to a consumer, Alice.

67 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

Figure D.6—Licenses for consumers The structure of the grant in Alice’s license matches the grant that the distributor is authorized to issue, as specified in the distributor's license. However, in issuing the license, Educational Distributor has replaced the variables as follows: — Alice has replaced the anyone variable. In the license, Alice is represented as the holder of a particular key.

— Take Five has replaced the songByPDQ variable. In this license, this song is identified as a digitalResource identified using a uniform resource identifier (URI).

— A specific service reference has replaced the paymentVerificationService variable. This service reference identifies the service that Educational Distributor uses to keep track of whether the payment has already been made.

— A specific service reference has replaced the paymentService variable. This service reference identifies the service that Educational Distributor uses to collect payments.

NOTE—The elements representing Alice and Take Five are defined in the inventory and referenced elsewhere in the license. This is because service references in the feeFlat elements reference Alice and Take Five, so that Alice’s purchase of this music can be identified separately from other transactions handled by these services. This detail is omitted from the figure above for clarity sake.

Educational Distributor issues a license to Alice: <?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" 68 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <inventory> <!-- Alice is identified as the holder of a particular key --> <keyHolder licensePartId="Alice"> <info> <dsig:KeyValue> <dsig:RSAKeyValue> <dsig:Modulus>Efgao6NYf==</dsig:Modulus> <dsig:Exponent>AQAQAA==</dsig:Exponent> </dsig:RSAKeyValue> </dsig:KeyValue> </info> </keyHolder> <!-- The recording is identified as an MPEG DIDL --> <digitalResource licensePartId="TakeFive"> <nonSecureIndirect URI="http://www.pdqrecords.com/TakeFive.mpg"/> </digitalResource> </inventory> <grant> <keyHolder licensePartIdRef="Alice"/> <mx:play/> <digitalResource licensePartIdRef="TakeFive"/> <!-- The fees that Alice must pay to play the recording --> <allConditions> <sx:feeFlat> <serviceReference> <sx:uddi> <sx:serviceKey> <sx:uuid>D04951E4-332C-4693-B7DBD3D1D1C20844</sx:uuid> </sx:serviceKey> </sx:uddi> <serviceParameters> <datum> <keyHolder licensePartIdRef="Alice"/> </datum> <datum> <digitalResource licensePartIdRef="TakeFive"/> </datum> </serviceParameters> </serviceReference> <sx:rate> <sx:amount>1.50</sx:amount> <sx:currency xmlns:iso="urn:mpeg:mpeg21:2003:01-REL-SXNS:currency">iso:USD</sx:currency> </sx:rate> <sx:to> <sx:aba> <sx:institution>139371581</sx:institution> <sx:account>111111</sx:account> </sx:aba> </sx:to> </sx:feeFlat> <sx:feeFlat> <serviceReference> <sx:uddi> <sx:serviceKey>

69 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

<sx:uuid>E12061E4-332C-4693-B7DBD3D1D1C20844</sx:uuid> </sx:serviceKey> </sx:uddi> <serviceParameters> <datum> <keyHolder licensePartIdRef="Alice"/> </datum> <datum> <digitalResource licensePartIdRef="TakeFive"/> </datum> </serviceParameters> </serviceReference> <sx:rate> <sx:amount>15.00</sx:amount> <sx:currency xmlns:iso="urn:mpeg:mpeg21:2003:01-REL-SXNS:currency">iso:USD</sx:currency> </sx:rate> <sx:to> <sx:paymentService> <serviceReference> <sx:uddi> <sx:serviceKey> <sx:uuid>F98231E4-332C-4693-B7DBD3D1D1C20844</sx:uuid> </sx:serviceKey> </sx:uddi> <serviceParameters> <datum> <keyHolder licensePartIdRef="Alice"/> </datum> <datum> <digitalResource licensePartIdRef="TakeFive"/> </datum> </serviceParameters> </serviceReference> </sx:paymentService> </sx:to> </sx:feeFlat> </allConditions> </grant> <issuer/> </license>

D.5 Example #4â&#x20AC;&#x201D;Site license with count conditions This is an example of a particular site, Training Facility A1, allowing any of its current members to preview any of the learning objects in the library. The members can only play each learning object once for free.

This example satisfies the following IEEE 1484.4 LTSC DREL requirements:

70 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

Table D.5—Requirement validations Requirement

Validation description

2.1.1 (Formal grammar)

This example is based on the ISO/IEC 21000-5 specification, which formally defines the syntax and semantics of a rights expression language.

ISO/IEC 21000-5 is an international standard.

2.1.3 (Articulation of roles)

This example shows how the role of “member” is defined by a particular training facility.

2.1.5 (Single rights expression to apply to a class of learning objects)

This example uses an expression to refer to all the learning objects in the library.

2.1.7 (Core set of primitive constructs)

This example uses core primitives from the rights expression language.

2.4.1 (Support conditions that shall be fulfilled before a right is exercised)

This example specifies conditions that must be satisfied in order to exercise the stated right.

2.4.3 (Limit the number of uses)

This example allows any member of the training facility to play any learning object at most once for free.

2.4.18 (Site-license)

This example shows a site-license to control access to a collection of learning objects.

This is the MPEG REL coding for a certificate that identifies Alice as a member of the training facility:

<?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <grant licensePartId="memberCertificate"> <keyHolder licensePartId="Alice-key"> <info> <dsig:KeyValue> <dsig:RSAKeyValue> <dsig:Modulus>acmM4ccyzA==</dsig:Modulus> <dsig:Exponent>AQABAA==</dsig:Exponent> </dsig:RSAKeyValue> </dsig:KeyValue> </info> </keyHolder> <possessProperty/> <sx:propertyUri definition="urn:trainingFacilityA1:member"/> </grant> <issuer/> </license> This is the MPEG REL coding for the site-license that allows any member of the training facility to play any learning object from the library:

<?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" 71 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <grant licensePartId="siteLicense"> <forAll varName="anyMember"> <propertyPossessor> <sx:propertyUri definition="urn:trainingFacilityA1:member"/> </propertyPossessor> </forAll> <forAll varName="anyBook"> <anXmlExpression>digitalResource/nonSecureIndirect[startswith(@URI,'http://www.trainingfacilitya1.com/library')]</anXmlExpression > </forAll> <principal varRef="anyMember"/> <mx:play/> <digitalResource varRef="anyBook"/> <sx:exerciseLimit> <!--The service that keeps state information--> <serviceReference> <sx:uddi> <sx:serviceKey> <sx:uuid>1F8903B0-FC03-4c5b-A445-AAFCCEC01111</sx:uuid> </sx:serviceKey> </sx:uddi> <serviceParameters> <datum> <mx:play/> </datum> <datum> <digitalResource varRef="anyBook"/> </datum> <datum> <principal varRef="anyMember"/> </datum> </serviceParameters> </serviceReference> <sx:count>1</sx:count> </sx:exerciseLimit> </grant> <issuer/> </license>

D.6 Example #5â&#x20AC;&#x201D;Default constraints This is an example of a license that can be used by a system to specify default constraints to control access to a collection of digital content. Only the specified group of people can access the stated digital content within the specified time conditions and if and only if the tracking service says there are no specific licenses for the specific learning object.

72 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

This example satisfies the following IEEE 1484.4 LTSC DREL requirements: Table D.6—Default constraints Requirement

Validation description

2.1.1 (Formal grammar)

This example is based on the ISO/IEC 21000-5 specification, which formally defines the syntax and semantics of a rights expression language. ISO/IEC 21000-5 is an international standard.

2.1.3 (Articulation of roles)

This example shows how the role of “trainer” is defined.

2.1.5 (Single rights expression to apply to a class of learning objects)

This example uses an expression to refer to all the learning objects in the library.

2.1.7 (Core set of primitive constructs)

This example uses core primitives from the rights expression language.

2.1.8 (Constraints used as defaults)

This example shows a license that applies to a group of people and to a category of content. This is a general license that can be used by a system as a default policy.

2.4.1 (Support conditions that shall be fulfilled before a right is exercised)

This example specifies conditions that must be satisfied in order to exercise the stated right.

2.4.8 (Policies that apply to individuals or groups)

This example shows a policy that applies to all trainers.

2.4.10 (Time-based usage)

This example shows how to specify a validity interval as a condition on usage.

This is the MPEG REL coding for a certificate that identifies the keyHolder as a “trainer”:

<?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <grant licensePartId="trainerCertificate"> <keyHolder licensePartId="Alice"> <info> <dsig:KeyValue> <dsig:RSAKeyValue> <dsig:Modulus>acmM4ccyzA==</dsig:Modulus> <dsig:Exponent>AQABAA==</dsig:Exponent> </dsig:RSAKeyValue> </dsig:KeyValue> </info> </keyHolder> <possessProperty/> <sx:propertyUri definition="urn:trainingFacility:trainer"/> </grant> <issuer/> </license> This is the MPEG REL coding for the license that allows any trainer to play any learning object from its library:

73 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

<?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <grant> <forAll varName="anyTrainer"> <propertyPossessor> <sx:propertyUri definition="urn:trainingFacility:trainer"/> </propertyPossessor> </forAll> <forAll varName="anyBook"> <anXmlExpression>digitalResource/nonSecureIndirect[startswith(@URI,'http://www.institution.com/library')]</anXmlExpression> </forAll> <principal varRef="anyTrainer"/> <mx:play/> <digitalResource varRef="anyBook"/> <allConditions> <!--check to see if there are any specific licenses that apply to this resource--> <sx:trackQuery> <serviceReference> <sx:uddi> <sx:serviceKey> <sx:uuid>D04951E4-332C-4693-B7DBD3D1D1C20844</sx:uuid> </sx:serviceKey> </sx:uddi> <serviceParameters> <datum> <digitalResource varRef="anyBook"/> </datum> </serviceParameters> </serviceReference> <sx:notMoreThan>1</sx:notMoreThan> </sx:trackQuery> <validityInterval> <notBefore>2005-01-01T15:30:00</notBefore> <notAfter>2005-12-31T15:30:00</notAfter> </validityInterval> </allConditions> </grant> <issuer/> </license>

D.7 Example #6â&#x20AC;&#x201D;Trusted device or online connectivity conditions This is an example of a rights expression specifying that an individual play the stated learning object on a trusted device or be connected to an online service.

74 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

This example satisfies the following IEEE 1484.4 LTSC DREL requirements: Table D.7â&#x20AC;&#x201D;Trusted device conditions Requirement

Validation description

2.1.1 (Formal grammar)

This example is based on the ISO/IEC 21000-5 specification, which formally defines the syntax and semantics of a rights expression language. ISO/IEC 21000-5 is an international standard.

2.1.4 (Unique identifiers for learning objects)

This example shows the use of unique identifiers to refer to a particular song.

2.1.7 (Core set of primitive constructs)

This example uses core primitives from the rights expression language.

2.4.1 (Support conditions that shall be fulfilled before a right is exercised)

This example specifies conditions that must be satisfied in order to exercise the stated right.

2.4.4 (Connectivity-based usage)

This example shows how to specify a connectivity-based condition (connection to an online service).

2.4.5 (Device-based usage)

This example shows how to specify a device-based condition (must play on a trusted device).

2.4.15 (Fees associated with connectivity based usage)

This example shows a fee-condition associated with the connectivity-based usage.

This is the MPEG REL coding for the license that allows an individual, Alice, to play the specified learning object, Top Jazz Hits, either on a trusted device or while connected to an online service.

<?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <grantGroup> <forAll varName="anyMyuTrustedDevice"> <propertyPossessor> <sx:propertyUri definition="urn:myu:trustedDevice"/> </propertyPossessor> </forAll> <keyHolder licensePartId="Alice"> <info> <dsig:KeyValue> <dsig:RSAKeyValue> <dsig:Modulus>SRagFBUrIzSfaS0xR9lZdUEF0ThO4w==</dsig:Modulus> <dsig:Exponent>AQABAA==</dsig:Exponent> </dsig:RSAKeyValue> </dsig:KeyValue> </info> </keyHolder> <grant> <mx:play/> <mx:diReference licensePartId="JazzTopHits">

75 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

<mx:identifier>urn:myu:library:music:catalog:jazz:TopHits</mx:identif ier> </mx:diReference> <mx:renderer> <principal varRef="anyMyuTrustedDevice"/> </mx:renderer> </grant> <grant> <mx:play/> <mx:diReference licensePartId="JazzTopHits"> <mx:identifier>urn:myu:library:music:catalog:jazz:TopHits</mx:identif ier> </mx:diReference> <allConditions> <sx:seekApproval> <serviceReference> <sx:uddi> <sx:serviceKey> <sx:uuid>D04951E4-332C-4693-B7DBD3D1D1C20844</sx:uuid> </sx:serviceKey> </sx:uddi> <serviceParameters> <datum> <principal licensePartIdRef="Alice"/> </datum> <datum> <mx:diReference licensePartIdRef="JazzTopHits"/> </datum> </serviceParameters> </serviceReference> </sx:seekApproval> <sx:feePerUse> <sx:rate> <sx:amount>1.00</sx:amount> <sx:currency xmlns:iso="urn:mpeg:mpeg21:2003:01-REL-SXNS:currency">iso:USD</sx:currency> </sx:rate> <sx:to> <sx:aba> <sx:institution>99991212</sx:institution> <sx:account>1234567890</sx:account> </sx:aba> </sx:to> </sx:feePerUse> </allConditions> </grant> </grantGroup> <issuer/> </license>

D.8 Example #7â&#x20AC;&#x201D;Aggregation with attribution This is an example of a rights expression specifying that an instructor can embed the stated learning object onto another object as long as the stated attribution condition is satisfied.

76 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

This example satisfies the following IEEE 1484.4 LTSC DREL requirements: Table D.8â&#x20AC;&#x201D;Aggregation with attribution Requirement

Validation description

2.1.1 (Formal grammar)

This example is based on the ISO/IEC 21000-5 specification, which formally defines the syntax and semantics of a rights expression language. ISO/IEC 21000-5 is an international standard.

2.1.4 (Unique identifiers for learning objects)

This example shows the use of unique identifiers to refer to a particular learning object.

2.1.6 (Extensibility)

The language defines several XML abstract types that can be extended including the principal, resource, right, and condition abstract types. In this example, the mx:mark condition is used to specify an attribution. An alternative is to extend the condition abstract type to add an attribution condition specific to the eLearning community.

2.1.7 (Core set of primitive constructs)

This example uses core primitives from the rights expression language.

2.2.1 (Constraints for embedding learning objects)

This example shows how to specify the embed right to allow a learning object to be aggregated onto another learning object.

2.3.1 (Attribution condition)

This example shows how to specify an attribution condition using the mx:mark condition. Uses the AcmeWatermark example from the ISO/IEC 21000-5 specification.

2.4.1 (Support conditions that shall be fulfilled before a right is exercised)

This example specifies conditions that must be satisfied in order to exercise the stated right.

This is the MPEG REL coding for the license that allows an instructor to embed onto another learning object the specified learning object as long as the stated attribution is made.

<?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <grant> <forAll varName="anyMyuInstructor"> <propertyPossessor> <sx:propertyUri definition="urn:myu:instructor"/> </propertyPossessor> </forAll> <principal varRef="anyMyuInstructor"/> <mx:embed/> <mx:diReference licensePartId="myuLO123"> <mx:identifier>urn:myu:library:catalog:lecture:LO123</mx:identifier> </mx:diReference> <!--Using the mx:mark condition to specify attribution--> <mx:mark> <mx:diReference licensePartIdRef="myuLO123"/> <acme:acmeWatermark value="Textual attribution: A project funded by the City Historical Society"/> </mx:mark> </grant> 77 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

<issuer/> </license>

D.9 Example #8—Disaggregation with attribution This is an example of a rights expression specifying that an instructor can disaggregate the stated learning object as long as the stated attribution condition is satisfied.

This example satisfies the following IEEE 1484.4 LTSC DREL requirements: Table D.9—Disaggregation with attribution

Requirement

Validation description

2.1.1 (Formal grammar)

This example is based on the ISO/IEC 21000-5 specification, which formally defines the syntax and semantics of a rights expression language. ISO/IEC 21000-5 is an international standard.

2.1.4 (Unique identifiers for learning objects)

This example shows the use of unique identifiers to refer to a particular resource.

2.1.6 (Extensibility)

The language defines several XML abstract types that can be extended including the principal, resource, right, and condition abstract types. In this example, the mx:mark condition is used to specify an attribution. An alternative is to extend the condition abstract type to add an attribution condition specific to the eLearning community.

2.1.7 (Core set of primitive constructs)

This example uses core primitives from the rights expression language.

2.2.2 (Constraints for dismantling learning objects)

This example shows how to specify the embed right to allow a learning object to be disaggregated onto another learning object.

2.3.1 (Attribution condition)

This example shows how to specify an attribution condition using the mx:mark condition. Uses the AcmeWatermark example from the ISO/IEC 21000-5 specification.

2.4.1 (Support conditions that shall be fulfilled before a right is exercised)

This example specifies conditions that must be satisfied in order to exercise the stated right.

This is the MPEG REL coding for the license that allows an instructor, Alice, to diminish the specified learning object as long as the specified attribution is made.

<?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <grant> <forAll varName="anyMyuInstructor"> <propertyPossessor> <sx:propertyUri definition="urn:myu:instructor"/> </propertyPossessor> </forAll> <principal varRef="anyMyuInstructor"/> <mx:diminish/> 78 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

<mx:diReference licensePartId="myuLO123"> <mx:identifier>urn:myu:library:catalog:lecture:LO123</mx:identifier> </mx:diReference> <!--Using the mx:mark condition to specify attribution--> <mx:mark> <mx:diReference licensePartIdRef="myuLO123"/> <acme:acmeWatermark value="Textual attribution: A project funded by the MyUniversity"/> </mx:mark> </grant> <issuer/> </license>

D.10 Example #9—Conditions on an aggregated composite object In this example, an aggregated learning object (or composite object) consists of different parts: Part1, Part2, Part3, and Part4. Each part was embedded onto the resulting aggregated learning object (or composite object).

This example shows how a rights expression is constructed to control the use of the parts as well as the use of the aggregated object itself.

This example satisfies the following IEEE 1484.4 LTSC DREL requirements: Table D.10—Conditions on an aggregated composite object Requirement

Validation description

2.1.1 (Formal grammar)

This example is based on the ISO/IEC 21000-5 specification, which formally defines the syntax and semantics of a rights expression language. ISO/IEC 21000-5 is an international standard.

2.1.2 (Invariant constraints)

This example shows the specification of multiple constraints that the system retained when the composite object was aggregated.

2.1.4 (Unique identifiers for learning objects)

This example shows the use of unique identifiers to refer to specific resources.

2.1.7 (Core set of primitive constructs)

This example uses core primitives from the rights expression language.

2.2.4 (Constraints for the use of aggregated LOs)

This example shows a rights expression for the composite object.

2.2.5 (Constraints for the different levels of granularity)

The example also has rights expressions for the different parts that make up the composite object.

2.2.6 (Identification of different portions of aggregated LOs)

The example also has rights expressions for the different parts that make up the composite object.

2.4.1 (Support conditions that shall be fulfilled before a right is exercised)

This example specifies conditions that must be satisfied in order to exercise the stated right.

2.4.12 (Portion-based usage)

This example shows how to specify rights and conditions on portions of a composite learning object.

This is the MPEG REL coding for the license that allows an instructor, Alice, to play the aggregated learning object, CompositeObject1, for free but with a time constraint.

79 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

Alice can also print any of the parts of the composite learning object as long as she satisfies the partâ&#x20AC;&#x2122;s specified fee condition.

<?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <inventory> <keyHolder licensePartId="Alice"> <info> <dsig:KeyValue> <dsig:RSAKeyValue> <dsig:Modulus>acmM4ccyzA==</dsig:Modulus> <dsig:Exponent>AQABAA==</dsig:Exponent> </dsig:RSAKeyValue> </dsig:KeyValue> </info> </keyHolder> </inventory> <grantGroup> <principal licensePartIdRef="Alice"/> <grant> <mx:play/> <mx:diReference licensePartId="CompositeObject1"> <mx:identifier>urn:myu:library:compositeLO:123456</mx:identifier> </mx:diReference> <validityInterval> <notBefore>2005-01-01T15:30:00</notBefore> <notAfter>2005-12-31T15:30:00</notAfter> </validityInterval> </grant> <!--Rights and conditions for each part of the composite object--> <grant> <mx:print/> <mx:diReference licensePartId="Part1"> <mx:identifier>urn:myu:library:primitiveLO:123</mx:identifier> </mx:diReference> <sx:feePerUse> <sx:rate> <sx:amount>1.00</sx:amount> <sx:currency xmlns:iso="urn:mpeg:mpeg21:2003:01-REL-SXNS:currency">iso:USD</sx:currency> </sx:rate> </sx:feePerUse> </grant> <grant> <mx:print/> <mx:diReference licensePartId="Part2"> <mx:identifier>urn:myu:library:primitiveLO:234</mx:identifier> </mx:diReference> <sx:feePerUse> <sx:rate> <sx:amount>2.00</sx:amount>

80 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

<sx:currency xmlns:iso="urn:mpeg:mpeg21:2003:01-REL-SXNS:currency">iso:USD</sx:currency> </sx:rate> </sx:feePerUse> </grant> <grant> <mx:print/> <mx:diReference licensePartId="Part3"> <mx:identifier>urn:myu:library:primitiveLO:345</mx:identifier> </mx:diReference> <sx:feePerUse> <sx:rate> <sx:amount>3.00</sx:amount> <sx:currency xmlns:iso="urn:mpeg:mpeg21:2003:01-REL-SXNS:currency">iso:USD</sx:currency> </sx:rate> </sx:feePerUse> </grant> <grant> <mx:print/> <mx:diReference licensePartId="Part4"> <mx:identifier>urn:myu:library:primitiveLO:456</mx:identifier> </mx:diReference> <sx:feePerUse> <sx:rate> <sx:amount>4.00</sx:amount> <sx:currency xmlns:iso="urn:mpeg:mpeg21:2003:01-REL-SXNS:currency">iso:USD</sx:currency> </sx:rate> </sx:feePerUse> </grant> </grantGroup> <issuer/> </license>

D.11 Example #10â&#x20AC;&#x201D;Retention of metadata in learning object There may be circumstances where metadata associated with learning objects cannot be harvested or redistributed but must remain with the learning object.

MPEG REL allows the specification of a prohibited-attribute-changes condition. This condition can be used to ensure that the identified metadata is retained when a right is exercised.

This example satisfies the following IEEE 1484.4 LTSC DREL requirements:

81 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

Table D.11—Retention of metadata in learning object Requirement

Validation description

2.1.1 (Formal grammar)

This example is based on the ISO/IEC 21000-5 specification, which formally defines the syntax and semantics of a rights expression language. ISO/IEC 21000-5 is an international standard.

2.1.4 (Unique identifiers for learning objects)

This example shows the use of unique identifiers to refer to a particular book.

2.1.7 (Core set of primitive constructs)

This example uses core primitives from the rights expression language.

2.2.7 (Constraints requiring the retention of specific metadata)

This example uses the prohibited-attribute-changes condition to prevent changes to the specified metadata.

2.4.1 (Support conditions that shall be fulfilled before a right is exercised)

This example specifies conditions that must be satisfied in order to exercise the stated right.

This is the MPEG REL coding for the license that prohibits changes to the metadata in a learning object.

<?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <grant licensePartId="usageGrant"> <keyHolder licensePartId="Alice"> <info> <dsig:KeyValue> <dsig:RSAKeyValue> <dsig:Modulus>acmM4ccyzA==</dsig:Modulus> <dsig:Exponent>AQABAA==</dsig:Exponent> </dsig:RSAKeyValue> </dsig:KeyValue> </info> </keyHolder> <mx:embed/> <digitalResource licensePartIdRef="myBook"> <nonSecureIndirect URI="http://www.myu.edu/library/ABCBook.spd"/> </digitalResource> <mx:prohibitedAttributeChanges> <mx:set definition="http://www.myu.edu/library/ABCBook.spd#authorshipMetadata"/> </mx:prohibitedAttributeChanges> </grant> </license>

D.12 Example #11—Supervision-based usage The MPEG REL allows for the specification of a seek-approval condition as a requirement to exercise a stated right over a digital object. The seek-approval condition provides a mechanism to ask an online service to see if a supervising teacher has registered his/her presence at the test site. A response is transmitted.

82 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

This example satisfies the following IEEE 1484.4 LTSC DREL requirements: Table D.12â&#x20AC;&#x201D;Supervision-based usage Requirement

Validation description

2.1.1 (Formal grammar)

This example is based on the ISO/IEC 21000-5 specification, which formally defines the syntax and semantics of a rights expression language.

ISO/IEC 21000-5 is an international standard.

2.1.4 (Unique identifiers for learning objects)

This example shows the use of unique identifiers to refer to a particular book.

2.1.7 (Core set of primitive constructs)

This example uses core primitives from the rights expression language.

2.4.1 (Support conditions that shall be fulfilled before a right is exercised)

This example specifies conditions that must be satisfied in order to exercise the stated right.

2.4.19 (Constraints related to the manner in which the use of a learning object is supervised)

This example uses the seek-approval condition to specify that a supervisor be present when students take the quiz.

This is the MPEG REL coding for the license that specifies a seek-approval condition to require the presence of a supervisor in order to exercise the stated right.

<?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <grant> <keyHolder licensePartId="Alice"> <info> <dsig:KeyValue> <dsig:RSAKeyValue> <dsig:Modulus>SRagFBUrS0h27GJrA15SS7TYZzSfaS0xR9lZdUEF0ThO4w==</dsig: Modulus> <dsig:Exponent>AQABAA==</dsig:Exponent> </dsig:RSAKeyValue> </dsig:KeyValue> </info> </keyHolder> <mx:play/> <mx:diReference licensePartId="Quiz101"> <mx:identifier>urn:myu:courses:cs555:Quiz101.quz</mx:identifier> </mx:diReference> <!--Asking the supervising service if Alice can take the quiz--> <sx:seekApproval> <serviceReference> <sx:uddi> <sx:serviceKey> <sx:uuid>D04951E4-332C-4693-B7DB-D3D1D1C20844</sx:uuid> </sx:serviceKey> </sx:uddi> <serviceParameters> <datum> <principal licensePartIdRef="Alice"/> 83 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

</datum> <datum> <mx:play/> </datum> <datum> <mx:diReference licensePartIdRef="Quiz101"/> </datum> </serviceParameters> </serviceReference> </sx:seekApproval> </grant> <issuer/> </license>

D.13 Example #12—Subscription-based pricing This example satisfies the following IEEE 1484.4 LTSC DREL requirements: Table D.13—Subscription-based pricing Requirement

Validation description

2.1.1 (Formal grammar)

This example is based on the ISO/IEC 21000-5 specification, which formally defines the syntax and semantics of a rights expression language. ISO/IEC 21000-5 is an international standard.

2.1.3 (Articulation of roles)

This example shows the how any “consumer” is specified.

2.1.7 (Core set of primitive constructs)

This example uses core primitives from the rights expression language.

2.4.1 (Support conditions that shall be fulfilled before a right is exercised)

This example specifies conditions that must be satisfied in order to exercise the stated right.

2.4.2 (Heterogeneous constraints to use content by individuals or groups)

This example specifies conditions that must be satisfied in order for the group of consumers to exercise the stated right.

2.4.10 (Timed-based usage)

This example specifies validity intervals.

2.4.11 (Fee-based usage)

This example specifies fee-conditions to exercise the stated right.

2.4.16 (Subscription-based pricing)

This example specifies different prices for subscribers based in different territories.

2.4.17 (Time-based pricing)

This example specifies a one-year subscription.

2.6.1 (Offers)

This example specifies offers for consumers to obtain.

D.13.1 Granting rights by subscription In the following examples, the online education magazine publisher offers its consumers the following subscription options: — A basic yearly subscription to the magazine.

— Different subscription rates based on geographic location — Discounted subscription rates for schools and libraries.

These examples represent a different magazine publishing business model. Rather than purchasing rights to a specific issue (similar to buying an issue on the news stand), consumers may purchase a subscription for a flat fee and receive a one year subscription.

84 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

D.13.2 Granting a yearly subscription In this example, the online education magazine publisher offers consumers a yearly subscription to the magazine for a fee of $15.00.

Figure D.7 illustrates the structure of a license that represents the offer that the publisher makes to consumers. This example illustrates the following interesting features of the MPEG REL: — This example uses the possessProperty right to identify magazine subscribers. The possessProperty right grants the identified principal the right to claim ownership of the characteristics listed as resources in the grant (in this case, being a subscriber).

— This grant that consumers may obtain defines a variable using the forAll element. The forAll element contains a validityIntervalDurationPattern to stipulate that matching validity intervals must have a duration of one year. This variable is then used in the grant’s validityInterval condition to specify that the subscription may cover any one-year interval.

Figure D.7—Granting a yearly subscription The following example license shows how to represent this information in the MPEG REL: D.13.3 The online education magazine publisher offers consumers a yearly magazine subscription <?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <!--The publisher offers consumers a one-year magazine subscription -> <!--Since this is an offer, any consumer is granted the right to obtain the grant group listed as a resource --> 85 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

<grant> <!-- This forAll element contains a pattern that matches any oneyear time interval --> <forAll varName="oneYear"> <sx:validityIntervalDurationPattern> <sx:duration>P1Y</sx:duration> </sx:validityIntervalDurationPattern> </forAll> <!-- This forAll element does not contain a pattern, so it matches any consumer --> <forAll varName="Consumer"/> <keyHolder varRef="Consumer"/> <obtain/> <!-- The grant that the consumer may obtain. It grants the consumer the right to claim ownership of the property of being a subscriber for one year --> <grant> <keyHolder varRef="Consumer"/> <possessProperty/> <sx:propertyUri definition="urn:onlineEdMag:subscriber"/> <validityInterval varRef="oneYear"/> </grant> <!--If a consumer exercises the obtain right to obtain a license, this fee is paid to the publisher --> <sx:feePerUse> <sx:rate> <sx:amount>15.00</sx:amount> <sx:currency xmlns:iso="urn:mpeg:mpeg21:2003:01-REL-SXNS:currency">iso:USD</sx:currency> </sx:rate> </sx:feePerUse> </grant> <issuer/> </license> Figure D.8 illustrates the structure of the license that the online education magazine publisher issues to Alice if she accepts this offer and pays the $15.00 fee. This license grants Alice the right to claim ownership of the characteristic subscriber for one year.

Figure D.8â&#x20AC;&#x201D;Online Publisher offers consumer subscription The example in D.13.4 license shows how to represent this information in the MPEG REL.

86 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

D.13.4 The online education magazine publisher grants a yearly subscription <?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <!--The publisher grants Alice a one-year magazine subscription --> <!--Alice has the right to claim ownership of the property of being a subscriber for one year--> <grant> <!--Alice's identity--> <keyHolder licensePartId="Alice"> <info> <dsig:KeyValue> <dsig:RSAKeyValue> <dsig:Modulus>Fa7wo6NYfasdfd==</dsig:Modulus> <dsig:Exponent>AQAQAA==</dsig:Exponent> </dsig:RSAKeyValue> </dsig:KeyValue> </info> </keyHolder> <possessProperty/> <sx:propertyUri definition="urn:onlineEdMag:subscriber"/> <!--The particular one-year time interval during which this subscription is valid--> <validityInterval> <notBefore>2002-02-03T17:26:00</notBefore> <notAfter>2003-02-03T17:25:00</notAfter> </validityInterval> </grant> <issuer/> </license> D.13.5 Basing subscription rates on location In this example, the online education magazine publisher offers consumers a yearly subscription to the magazine for a fee of 15 U.S. dollars or 17 Canadian dollars.

The following figure illustrates the structure of a license that represents the offer that the publisher makes to consumers. This license differs from the offer described in “Granting a Yearly Subscription” in the following ways: — This offer contains two grants that consumers may obtain—one for consumers in the U.S. and one for consumers in Canada.

— The each of these grants contains two conditions: territory feePerUse

Identifies a geographic location.

Specifies the appropriate fee for that location.

These conditions must be simultaneously met, so they are enclosed within an allConditions element.

Figure D.9 illustrates these changes.

87 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

Figure D.9—Basing subscription rates on location The following example license shows how to represent this information in the MPEG REL: 88 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

D.13.6 The online education magazine publisher offers subscription rates based on location <?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <!-- The publisher offers consumers different subscription rates depending on location--> <grant> <forAll varName="oneYear"> <sx:validityIntervalDurationPattern> <sx:duration>P1Y</sx:duration> </sx:validityIntervalDurationPattern> </forAll> <forAll varName="Consumer"/> <keyHolder varRef="Consumer"/> <obtain/> <grant> <keyHolder varRef="Consumer"/> <possessProperty/> <sx:propertyUri definition="urn:onlineEdMag:subscriber"/> <validityInterval varRef="oneYear"/> </grant> <!--Since there are now two conditions, they are enclosed within an allConditions element--> <allConditions> <!--The territory in which this grant may be used--> <sx:territory> <sx:location> <sx:country xmlns:iso="urn:mpeg:mpeg21:2003:01-REL-SXNS:country">iso:US</sx:country> </sx:location> </sx:territory> <!--The fee appropriate for this territory--> <sx:feePerUse> <sx:rate> <sx:amount>15.00</sx:amount> <sx:currency xmlns:iso="urn:mpeg:mpeg21:2003:01-REL-SXNS:currency">iso:USD</sx:currency> </sx:rate> </sx:feePerUse> </allConditions> </grant> <grant> <forAll varName="oneYear"> <sx:validityIntervalDurationPattern> <sx:duration>P1Y</sx:duration> </sx:validityIntervalDurationPattern> </forAll> <keyHolder varRef="Consumer"/> <obtain/> <grant> <keyHolder varRef="Consumer"/> <possessProperty/> 89 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

<sx:propertyUri definition="urn:onlineEdMag:subscriber"/> <validityInterval varRef="oneYear"/> </grant> <!--Since there are two conditions, they are enclosed within an allConditions element--> <allConditions> <!--The territory in which this grant may be used--> <sx:territory> <sx:location> <sx:country xmlns:iso="urn:mpeg:mpeg21:2003:01-REL-SXNS:country">iso:CA</sx:country> </sx:location> </sx:territory> <!--The fee appropriate for this territory--> <sx:feePerUse> <sx:rate> <sx:amount>17.00</sx:amount> <sx:currency xmlns:iso="urn:mpeg:mpeg21:2003:01-REL-SXNS:currency">iso:CAD</sx:currency> </sx:rate> </sx:feePerUse> </allConditions> </grant> <issuer/> </license> If Alice accepts this offer and pays the appropriate fee, the online education magazine publisher issues her the license shown in “Granting a Yearly Subscription,” which grants her the right to claim ownership of the characteristic subscriber for one year.

D.14 Example #13—Preserved constraints on an aggregated object Embedding individual learning objects, e.g., Part1, Part2, Part3, and Part4, that contain their own rights and conditions onto an aggregated learning object, .e.g., CompositeObject1, requires that the resulting rights and conditions be aggregated as well.

If the parts of the aggregated learning object, CompositeObject1, can be individually distinguishable, then the task of aggregating all the rights and conditions is considerably less complicated. The reason is that the rights and conditions for each distinguishable part can be specified as shown in Example 9 -- Conditions of an Aggregated learning object.

However, if the parts of the aggregated learning object CompositeObject1 cannot be individually distinguishable (e.g., embedding several photos onto a bitmap image results in an aggregated learning object where the parts cannot be individually distinguished), then the application or system must aggregate the rights and conditions (see the coded example in this section).

90 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

This example satisfies the following IEEE 1484.4 LTSC DREL requirements: Table D.14—Preserved constraints on an aggregated object Requirement

Validation description

2.1.1 (Formal grammar)

This example is based on the ISO/IEC 21000-5 specification, which formally defines the syntax and semantics of a rights expression language. ISO/IEC 21000-5 is an international standard.

2.1.4 (Unique identifiers for learning objects)

This example shows the use of unique identifiers to refer to specific resources.

2.1.7 (Core set of primitive constructs)

This example uses core primitives from the rights expression language.

2.2.3 (Preservation and propagation of constraints under aggregation or embedding)

This example shows how the rights and conditions of individual learning objects (Example 9) were aggregated when multiple learning objects were embedded. The assumption is that all of the original rights and conditions associated with each part must be preserved and propagated.

An alternative to this approach is to extend the ‘condition’ abstract type to introduce a new condition called “preserveGrants,” identifies a list of grants that explicitly identify the rights and conditions to be preserved and propagated.

2.2.4 (Constraints for the use of aggregated LOs)

This example shows a rights expression for the aggregated learning object, CompositeObject1.

2.4.1 (Support conditions that shall be fulfilled before a right is exercised)

This example specifies conditions that must be satisfied in order to exercise the stated right.

This example contains aggregated conditions from each of the parts that make up the composite learning object.

<?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <inventory> <keyHolder licensePartId="Alice"> <info> <dsig:KeyValue> <dsig:RSAKeyValue> <dsig:Modulus>acmM4ccyzA==</dsig:Modulus> <dsig:Exponent>AQABAA==</dsig:Exponent> </dsig:RSAKeyValue> </dsig:KeyValue> </info> </keyHolder> </inventory> <grantGroup> <principal licensePartIdRef="Alice"/> <grant> <mx:play/> <mx:diReference licensePartId="CompositeObject1"> <mx:identifier>urn:myu:library:compositeLO:123456</mx:identifier> 91 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

</mx:diReference> <validityInterval> <notBefore>2005-01-01T15:30:00</notBefore> <notAfter>2005-12-31T15:30:00</notAfter> </validityInterval> </grant> <!-- Aggregated rights and conditions from the parts --> <grant> <mx:print/> <mx:diReference licensePartIdRef="CompositeObject1"/> <sx:feePerUse> <sx:rate> <sx:amount>10.00</sx:amount> <sx:currency xmlns:iso="urn:mpeg:mpeg21:2003:01-REL-SXNS:currency">iso:USD</sx:currency> </sx:rate> </sx:feePerUse> </grant> </grantGroup> <issuer/> </license>

92 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

Annex E (informative) Mapping requirements to OeBF Manuel Ham, ContentGuard June 25, 2004 Version 1.1

E.1. Introduction The goal of this document is to validate the IEEE LTSC DREL Requirements by providing examples of valid OeBF REL licenses.

The OeBF REL is defined as a rights expression language based on MPEG REL (ISO/IEC 21000-5). The OeBF REL specifies syntax and semantics of a number of new types and elements that are specifically interesting to applications for electronic publications.

The main difference between this document and the MPEG REL Validation document is the use of the OeBF-REL elements dealing with portion-based usage. This difference is highlighted in Example #9.

E.2 Example #1—University offer This is an example of a particular university issuing an offer to any of its students to view (play) any ebook in the university’s library.

If a student decides to accept the offer, then the university’s licensing service needs to verify that the consumer is a student. The student presents a student-certificate to the licensing service. Upon verification, the licensing service generates a consumer license.

In this example, the consumer’s license specifies that the stated student, Alice, has the right to play the stated e-book, “ABC Book.”

93 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

University Issues This Offer License Offer-grant

Alice Receives This License

Any-student Obtain

License

Usage-grant

Usage-grant Alice

Any-student Matching grants

Play

Play ABC Book

Any-ebook

Figure E.1—University offer (OeBF) This example satisfies the following IEEE 1484.4 LTSC DREL requirements:

Table E.1—University offer Requirement

Validation description

2.1.1 (Formal grammar)

This example is based on the ISO/IEC 21000-5 specification, formally defines the syntax and semantics of a rights expression language.

ISO/IEC 21000-5 is an international standard.

2.1.3 (Articulation of roles)

This example shows how the role of “student” is defined by a particular university. The university issues offers to “students” who must present a student-certificate to prove they are in fact students.

2.1.4 (Unique identifiers for learning objects)

This example shows the use of unique identifiers to refer to the e-book “ABCBook.”

2.1.5 (Single rights expression to apply to a class of learning objects)

This example shows a university’s offer using a single rights expression to refer to all the e-books in the university’s library.

2.1.7 (Core set of primitive constructs)

This example uses core primitives from the rights expression language.

2.4.7 (Specification of usage rights to learning objects for educational, research, and scholarly purposes)

This example allows any university student to view any of the e-books in the university’s library.

2.4.13 (Distribution and management of free learning objects)

This example offers for free to any university student the permission to view any e-book in the university’s library.

2.6.1 (Specification of offers)

This example shows a basic offer issued by a particular university.

This is the OEBF-REL coding for the university’s offer:

<?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS"

94 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <grant licensePartId="offerGrant"> <forAll varName="anyStudent"> <propertyPossessor> <sx:propertyUri definition="urn:myu:student"/> </propertyPossessor> </forAll> <forAll varName="anyBook"> <anXmlExpression>digitalResource/nonSecureIndirect[startswith(@URI,'http://www.myu.edu/library')]</anXmlExpression> </forAll> <principal varRef="anyStudent"/> <obtain/> <grant licensePartId="usageGrant"> <principal varRef="anyStudent"/> <mx:play/> <digitalResource varRef="anyBook"/> </grant> <!-- Optional fee condition (see “Comments” below) may be added here--> </grant> <issuer/> </license> This is the OEBF-REL coding for Alice’s student-certificate:

<?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <grant licensePartId="Alice-student-certificate"> <keyHolder licensePartId="Alice-key"> <info> <dsig:KeyValue> <dsig:RSAKeyValue> <dsig:Modulus>acmM4ccyzA==</dsig:Modulus> <dsig:Exponent>AQABAA==</dsig:Exponent> </dsig:RSAKeyValue> </dsig:KeyValue> </info> </keyHolder> <possessProperty/> <sx:propertyUri definition="urn:myu:student"/> </grant> <issuer/> </license> This is the OEBF-REL coding for the resulting consumer license: <?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" 95 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <grant licensePartId="usageGrant"> <keyHolder licensePartId="Alice"> <info> <dsig:KeyValue> <dsig:RSAKeyValue> <dsig:Modulus>acmM4ccyzA==</dsig:Modulus> <dsig:Exponent>AQABAA==</dsig:Exponent> </dsig:RSAKeyValue> </dsig:KeyValue> </info> </keyHolder> <mx:play/> <digitalResource> <nonSecureIndirect URI="http://www.myu.edu/library/ABCBook.spd"/> </digitalResource> </grant> <issuer/> </license> E.2.1 Comments In this example, the absence of a fee condition on the offer means that there is no charge for this offer.

However, the example can be further enhanced to require a fee condition on the offer itself. The OEBFREL allows for the specification of conditions to the offer-grant as well as to the usage-grant. The fee condition might look like as follows:

<sx:feePerUse> <sx:rate> <sx:amount>1.00</sx:amount> <sx:currency xmlns:iso="urn:mpeg:mpeg21:2003:01-REL-SXNS:currency">iso:USD</sx:currency> </sx:rate> <sx:to> <sx:aba> <sx:institution>99991212</sx:institution> <sx:account>1234567890</sx:account> </sx:aba> </sx:to> </sx:feePerUse>

E.3 Example #2—Tracking example This is an example of a consumer’s license that specifies a tracking condition when content is used. In order to satisfy legal requirements, an educational institution might establish a tracking service to record usage information in order to produce usage reports on learning objects. Moreover, this example allows anonymous access to the stated resource.

96 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

Consumer license with tracking condition License Usage-grant Anyone Play ABC Book Tracking condition

Figure E.2—Tracking example (OeBF) This example satisfies the following IEEE 1484.4 LTSC DREL requirements: Table E.2—Tracking Requirement

Validation description

2.1.1 (Formal grammar)

This example is based on the ISO/IEC 21000-5 specification, which formally defines the syntax and semantics of a rights expression language.

ISO/IEC 21000-5 is an international standard.

2.1.4 (Unique identifiers for learning objects)

This example shows the use of unique identifiers to refer to the e-book “ABC Book.”

2.1.7 (Core set of primitive constructs)

This example uses core primitives from the rights expression language.

2.4.1 (Support conditions that shall be fulfilled before a right is exercised)

This example has a tracking condition that must be fulfilled prior to granting permission to view the specified e-book.

2.4.6 (Anonymous access)

This example lets anyone view the specified e-book. There is no principal specified in the license.

2.4.13 (Distribution and management of free learning objects)

This example allows anyone to view the stated e-book for free as long as the use is tracked.

2.4.14 (Unlimited use for a fee or free)

This example allows anyone to play unlimited times the specified content.

Since there’s no fee condition, the unlimited use is for free.

2.5.1 (Tracking conditions)

This example has a tracking condition.

This is the OEBF-REL coding for this consumer license: <?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <grant licensePartId="usageGrant"> <mx:play/> <digitalResource licensePartId="eBook"> <nonSecureIndirect URI="http://www.myu.edu/library/ABCBook.spd"/> 97 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

</digitalResource> <sx:trackReport licensePartId="trackUsage"> <serviceReference> <sx:uddi> <sx:serviceKey> <sx:uuid>1F8903B0-FC03-4c5b-A445-AAFCCEC01111</sx:uuid> </sx:serviceKey> </sx:uddi> <serviceParameters> <datum> <mx:play/> </datum> <datum> <digitalResource licensePartIdRef="eBook"/> </datum> </serviceParameters> </serviceReference> </sx:trackReport> </grant> <issuer/> </license> E.3.1 Comments In this example, the absence of a fee condition implies that there are no fees associated with this license.

E.4 Example #3—Multi-tier distribution This use case illustrates how to use the OEBF-REL in a multi-tier distribution business model, which focuses on specifying rights and conditions for all participants in the distribution chain. In this example, a music publisher, PDQ Records, allows other parties to sell consumers rights to play music from its library.

Consumers pay a flat fee of $16.50 for each recording they buy—$1.50 goes to PDQ records and $15.00 goes to the educational distributor. The following figure illustrates this use case:

Figure E.3—Multi-tier distribution (OeBF)

98 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

To represent this use case: — PDQ Records must provide licenses to its distributor stipulating the terms of the distribution agreement.

— Distributors may provide licenses to consumers stipulating the agreed-upon fee structure.

This example satisfies the following IEEE 1484.4 LTSC DREL requirements: Table E.3—Multi-tier distribution Requirement

Validation description

2.1.1 (Formal grammar)

This example is based on the ISO/IEC 21000-5 specification, which formally defines the syntax and semantics of a rights expression language. ISO/IEC 21000-5 is an international standard.

2.1.3 (Articulation of roles)

This example shows how the role of a “distributor” is defined by PDQ Records through the issuance of certificates.

2.1.4 (Unique identifiers for learning objects)

This example shows the use of unique identifiers to refer to a particular song.

2.1.5 (Class of LOs)

An Xml-expression is used to identify songs in the PDQ Records library.

2.1.7 (Core set of primitive constructs)

This example uses core primitives from the rights expression language.

2.4.1 (Support conditions that shall be fulfilled before a right is exercised)

This example specifies conditions that must be satisfied in order to exercise the stated right.

2.4.2 (Heterogeneous constraints to use content by individuals or groups)

This example shows that any “distributor” can issue licenses to consumers who purchase the specified content.

2.4.9 (Multi-tiered distribution)

This example shows the rights and conditions issued by the rights holder, PDQ Records, to its distributors (as identified by the appropriate certificate). These rights and conditions also provide the rights and conditions that may be issued to consumers.

Thus, the example shows a mechanism to express rights to multiple participants in the value chain.

2.4.11 (Fee-based usage)

In this example, the consumer is charged a flat fee to play the specified content.

2.4.14 (Unlimited use for a fee or free)

After the consumer pays a flat fee, the consumer is entitled to unlimited use of the specified content. This example shows how to specify a service to verify payment.

The following subclauses describe how to specify this information in the MPEG REL. E.4.1 Constructing Licenses for Distributors In this example, PDQ Records provides the following two licenses to each of its distributors: — A license that identifies that principal as a PDQ Records distributor.

— A license that grants the distributor the right to issue licenses to consumers.

To identify a principal as a PDQ Records distributor, the first license has a grant containing the possessProperty right. The possessProperty right grants the identified principal the right to claim ownership of the characteristics listed as resources in the grant. A license granting the possessProperty right is sometimes called a “certificate.” Figure E.4 illustrates the structure of a certificate:

99 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

PDQ Distributor Certificate License Identity-grant Educational Distributor Possess Property Distributor

Figure E.4â&#x20AC;&#x201D;Licenses for distributors (OeBF) In the following example license, Educational Distributor is identified as the holder of a specific key and is granted possession of the property of being a PDQ Records distributor.

In this example and all later examples, the prefix sx: identifies elements from the standard extension, mx: identifies elements from the MPEG REL multimedia extension, and dsig: refers to the namespace that defines XML signatures. All other elements are defined in the MPEG REL Core. For information on how schema namespaces are declared in the license file, see the page that describes licenses.

Educational Distributor possesses the property of being a distributor: <?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <!--Educational Distributor possesses the property of being a PDQ Records distributor--> <grant> <keyHolder licensePartId="educationalDistributor"> <info> <dsig:KeyValue> <dsig:RSAKeyValue> <dsig:Modulus>A1KZGazht24NIu/y2mZrve++61KoLM==</dsig:Modulus> <dsig:Exponent>AQAQAA==</dsig:Exponent> </dsig:RSAKeyValue> </dsig:KeyValue> </info> </keyHolder> <possessProperty/> <sx:propertyUri definition="urn:pdq:distributor"/> </grant> <issuer/> </license> In addition to this certificate, PDQ Records must issue a license to its distributors representing the publisher/distributor relationship. Figure E.5 illustrates the basic structure of this license:

100 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

Figure E.5—Licenses for distributors inclusive of publisher relationship (OeBF) This license represents the publisher/distributor relationship as follows: — The principal to whom the grant is issued is identified as possessing the property of being a PDQ Records distributor. This example uses a variable defined using the forAll element to identify PDQ Records distributors using pattern matching. The forAll element contains a propertyPosessor pattern that stipulates that matching principals must possess the property of being a distributor.

— The distributor is granted the issue right, which allows the distributor to issue the consumer grant that is listed as a resource within this grant.

— The consumer grant stipulates the type of grant that the distributor may issue to consumers. The consumer grant specifies that the distributor can grant any one principal the right to play any one recording that PDQ Records owns provided that the consumer pays two flat fees—$1.50 to PDQ records and $15.00 to the distributor. The two feeFlat conditions are enclosed in an allConditions element, which specifies that both feeFlat conditions must be satisfied before the consumer may exercise the play right. For each fee, a service reference is checked to determine whether the consumer has already paid.

101 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

The consumer grant uses the following variables, which are defined using forAll elements.

Table E.4â&#x20AC;&#x201D;Consumer grant variables Variable

Definition

anyone

This forAll element does not contain a pattern, which means that the variable is unqualified and matches anything used as a principal. This enables the distributor to issue this grant to any one principal.

songByPDQ

This forAll element is qualified with an XML expression that identifies songs in the PDQ Records library.

paymentVerificationService

This forAll element does not contain a pattern, which means that the variable is unqualified and matches anything used as a payment verification service. This enables the distributor specify the service used to verify whether the consumer has already paid the $15.00 fee.

paymentService

This forAll element does not contain a pattern, which means that the variable is unqualified and matches anything used as a payment service. This enables the distributor specify the service that will collect the $15.00 fee from the consumer.

PDQ Records grants distributors the right to issue licenses to consumers:

<?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <!-- Any PDQ records distributor may issue the contained grant --> <grant> <!--This variable matches principals that are PDQ records distributors --> <forAll varName="distributor"> <propertyPossessor> <sx:propertyUri definition="urn:pdq:distributor"/> <trustedRootIssuers/> </propertyPossessor> </forAll> <!-- This variable matches any principal--> <forAll varName="anyone"/> <!-- This variable matches any song owned by PDQ records --> <forAll varName="songByPDQ"> <anXmlExpression>digitalResource/nonSecureIndirect[startswith(@URI,'http://www.pdqrecords.com/')]</anXmlExpression> </forAll> <!-- This variable matches any payment verification service the distributor wants to use --> <forAll varName="paymentVerificationService"/> <!-- This variable matches any payment collection service the distributor wants to use --> <forAll varName="paymentService"/> <principal varRef="distributor"/> 102 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

<issue/> <!-- The grant that a distributor may issue --> <grant> <principal varRef="anyone"/> <mx:play/> <digitalResource varRef="songByPDQ"/> <allConditions> <sx:feeFlat> <serviceReference> <sx:uddi> <sx:serviceKey> <sx:uuid>D04951E4-332C-4693-B7DBD3D1D1C20844</sx:uuid> </sx:serviceKey> </sx:uddi> <serviceParameters> <datum> <principal varRef="anyone"/> </datum> <datum> <digitalResource varRef="songByPDQ"/> </datum> </serviceParameters> </serviceReference> <sx:rate> <sx:amount>1.50</sx:amount> <sx:currency xmlns:iso="urn:mpeg:mpeg21:2003:01-REL-SXNS:currency">iso:USD</sx:currency> </sx:rate> <sx:to> <sx:aba> <sx:institution>139371581</sx:institution> <sx:account>111111</sx:account> </sx:aba> </sx:to> </sx:feeFlat> <sx:feeFlat> <serviceReference varRef="paymentVerificationService"/> <sx:rate> <sx:amount>15.00</sx:amount> <sx:currency xmlns:iso="urn:mpeg:mpeg21:2003:01-REL-SXNS:currency">iso:USD</sx:currency> </sx:rate> <sx:to> <sx:paymentService> <serviceReference varRef="paymentService"/> </sx:paymentService> </sx:to> </sx:feeFlat> </allConditions> </grant> </grant> <issuer/> </license>

103 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

E.4.2 Constructing licenses for consumers When a consumer purchases a song from one of the PDQ Records distributors, the distributor exercises the issue right to issue the consumer's license. At that time, the distributor replaces the variables in the consumer grant in the distribution license with specific information.

Figure E.6 illustrates the structure of the license that Educational Distributor issues to a consumer, Alice:

Figure E.6—Licenses for consumers (OeBF) The structure of the grant in Alice’s license matches the grant that the distributor is authorized to issue, as specified in the distributor’s license. However, in issuing the license, Educational Distributor has replaced the variables as follows: — Alice has replaced the anyone variable. In the license, Alice is represented as the holder of a particular key.

— Take Five has replaced the songByPDQ variable. In this license, this song is identified as a digitalResource identified using a uniform resource identifier (URI).

— A specific service reference has replaced the paymentVerificationService variable. This service reference identifies the service that Educational Distributor uses to keep track of whether the payment has already been made.

— A specific service reference has replaced the paymentService variable. This service reference identifies the service that Educational Distributor uses to collect payments.

NOTE—The elements representing Alice and Take Five are defined in the inventory and referenced elsewhere in the license. This is because service references in the feeFlat elements reference Alice and Take Five, so that Alice’s purchase of this music can be identified separately from other transactions handled by these services. This detail is omitted from the figure above for clarity sake.

104 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

Educational Distributor issues a license to Alice: <?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <inventory> <!-- Alice is identified as the holder of a particular key --> <keyHolder licensePartId="Alice"> <info> <dsig:KeyValue> <dsig:RSAKeyValue> <dsig:Modulus>Efgao6NYf==</dsig:Modulus> <dsig:Exponent>AQAQAA==</dsig:Exponent> </dsig:RSAKeyValue> </dsig:KeyValue> </info> </keyHolder> <!-- The recording is identified as an MPEG DIDL --> <digitalResource licensePartId="TakeFive"> <nonSecureIndirect URI="http://www.pdqrecords.com/TakeFive.mpg"/> </digitalResource> </inventory> <grant> <keyHolder licensePartIdRef="Alice"/> <mx:play/> <digitalResource licensePartIdRef="TakeFive"/> <!-- The fees that Alice must pay to play the recording --> <allConditions> <sx:feeFlat> <serviceReference> <sx:uddi> <sx:serviceKey> <sx:uuid>D04951E4-332C-4693-B7DBD3D1D1C20844</sx:uuid> </sx:serviceKey> </sx:uddi> <serviceParameters> <datum> <keyHolder licensePartIdRef="Alice"/> </datum> <datum> <digitalResource licensePartIdRef="TakeFive"/> </datum> </serviceParameters> </serviceReference> <sx:rate> <sx:amount>1.50</sx:amount> <sx:currency xmlns:iso="urn:mpeg:mpeg21:2003:01-REL-SXNS:currency">iso:USD</sx:currency> </sx:rate> <sx:to> <sx:aba> <sx:institution>139371581</sx:institution> <sx:account>111111</sx:account> 105 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

</sx:aba> </sx:to> </sx:feeFlat> <sx:feeFlat> <serviceReference> <sx:uddi> <sx:serviceKey> <sx:uuid>E12061E4-332C-4693-B7DBD3D1D1C20844</sx:uuid> </sx:serviceKey> </sx:uddi> <serviceParameters> <datum> <keyHolder licensePartIdRef="Alice"/> </datum> <datum> <digitalResource licensePartIdRef="TakeFive"/> </datum> </serviceParameters> </serviceReference> <sx:rate> <sx:amount>15.00</sx:amount> <sx:currency xmlns:iso="urn:mpeg:mpeg21:2003:01-REL-SXNS:currency">iso:USD</sx:currency> </sx:rate> <sx:to> <sx:paymentService> <serviceReference> <sx:uddi> <sx:serviceKey> <sx:uuid>F98231E4-332C-4693-B7DBD3D1D1C20844</sx:uuid> </sx:serviceKey> </sx:uddi> <serviceParameters> <datum> <keyHolder licensePartIdRef="Alice"/> </datum> <datum> <digitalResource licensePartIdRef="TakeFive"/> </datum> </serviceParameters> </serviceReference> </sx:paymentService> </sx:to> </sx:feeFlat> </allConditions> </grant> <issuer/> </license>

E.5 Example #4â&#x20AC;&#x201D;Site license with count conditions This is an example of a particular site, Training Facility A1, allowing any of its current members to preview any of the learning objects in the library. The members can only play each learning object once for free.

106 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

This example satisfies the following IEEE 1484.4 LTSC DREL requirements: Table E.5—Site license with count conditions Requirement

Validation description

2.1.1 (Formal grammar)

This example is based on the ISO/IEC 21000-5 specification, which formally defines the syntax and semantics of a rights expression language. ISO/IEC 21000-5 is an international standard.

2.1.3 (Articulation of roles)

This example shows how the role of “member” is defined by a particular training facility.

2.1.5 (Single rights expression to apply to a class of learning objects)

This example uses an expression to refer to all the learning objects in the library.

2.1.7 (Core set of primitive constructs)

This example uses core primitives from the rights expression language.

2.4.1 (Support conditions that shall be fulfilled before a right is exercised)

This example specifies conditions that must be satisfied in order to exercise the stated right.

2.4.3 (Limit the number of uses)

This example allows any member of the training facility to play any learning object at most once for free.

2.4.18 (Site-license)

This example shows a site-license to control access to a collection of learning objects.

This is the OEBF-REL coding for a certificate that identifies Alice as a member of the training facility:

<?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <grant licensePartId="memberCertificate"> <keyHolder licensePartId="Alice-key"> <info> <dsig:KeyValue> <dsig:RSAKeyValue> <dsig:Modulus>acmM4ccyzA==</dsig:Modulus> <dsig:Exponent>AQABAA==</dsig:Exponent> </dsig:RSAKeyValue> </dsig:KeyValue> </info> </keyHolder> <possessProperty/> <sx:propertyUri definition="urn:trainingFacilityA1:member"/> </grant> <issuer/> </license>

This is the OEBF-REL coding for the site-license that allows any member of the training facility to play any learning object from the library:

107 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

<?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <grant licensePartId="siteLicense"> <forAll varName="anyMember"> <propertyPossessor> <sx:propertyUri definition="urn:trainingFacilityA1:member"/> </propertyPossessor> </forAll> <forAll varName="anyBook"> <anXmlExpression>digitalResource/nonSecureIndirect[startswith(@URI,'http://www.trainingfacilitya1.com/library')]</anXmlExpression > </forAll> <principal varRef="anyMember"/> <mx:play/> <digitalResource varRef="anyBook"/> <sx:exerciseLimit> <!--The service that keeps state information--> <serviceReference> <sx:uddi> <sx:serviceKey> <sx:uuid>1F8903B0-FC03-4c5b-A445-AAFCCEC01111</sx:uuid> </sx:serviceKey> </sx:uddi> <serviceParameters> <datum> <mx:play/> </datum> <datum> <digitalResource varRef="anyBook"/> </datum> <datum> <principal varRef="anyMember"/> </datum> </serviceParameters> </serviceReference> <sx:count>1</sx:count> </sx:exerciseLimit> </grant> <issuer/> </license>

E.6 Example #5â&#x20AC;&#x201D;Default constraints This is an example of a license that can be used by a system to specify default constraints to control access to a collection of digital content. Only the specified group of people can access the stated digital content within the specified time conditions and if and only if the tracking service says there are no specific licenses for the specific learning object.

108 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

This example satisfies the following IEEE 1484.4 LTSC DREL requirements: Table E.6—Default constraints Requirement

Validation description

2.1.1 (Formal grammar)

This example is based on the ISO/IEC 21000-5 specification, which formally defines the syntax and semantics of a rights expression language. ISO/IEC 21000-5 is an international standard.

2.1.3 (Articulation of roles)

This example shows how the role of “trainer” is defined.

2.1.5 (Single rights expression to apply to a class of learning objects)

This example uses an expression to refer to all the learning objects in the library.

2.1.7 (Core set of primitive constructs)

This example uses core primitives from the rights expression language.

2.1.8 (Constraints used as defaults)

This example shows a license that applies to a group of people and to a category of content. This is a general license that can be used by a system as a default policy.

2.4.1 (Support conditions that shall be fulfilled before a right is exercised)

This example specifies conditions that must be satisfied in order to exercise the stated right.

2.4.8 (Policies that apply to individuals or groups)

This example shows a policy that applies to all trainers.

2.4.10 (Time-based usage)

This example shows how to specify a validity interval as a condition on usage.

This is the OEBF-REL coding for a certificate that identifies the keyHolder as a “trainer”:

<?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <grant licensePartId="trainerCertificate"> <keyHolder licensePartId="Alice"> <info> <dsig:KeyValue> <dsig:RSAKeyValue> <dsig:Modulus>acmM4ccyzA==</dsig:Modulus> <dsig:Exponent>AQABAA==</dsig:Exponent> </dsig:RSAKeyValue> </dsig:KeyValue> </info> </keyHolder> <possessProperty/> <sx:propertyUri definition="urn:trainingFacility:trainer"/> </grant> <issuer/> </license>

109 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

The following is the OEBF-REL coding for the license that allows any trainer to play any learning object from its library: <?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <grant> <forAll varName="anyTrainer"> <propertyPossessor> <sx:propertyUri definition="urn:trainingFacility:trainer"/> </propertyPossessor> </forAll> <forAll varName="anyBook"> <anXmlExpression>digitalResource/nonSecureIndirect[startswith(@URI,'http://www.institution.com/library')]</anXmlExpression> </forAll> <principal varRef="anyTrainer"/> <mx:play/> <digitalResource varRef="anyBook"/> <allConditions> <!--check to see if there are any specific licenses that apply to this resource--> <sx:trackQuery> <serviceReference> <sx:uddi> <sx:serviceKey> <sx:uuid>D04951E4-332C-4693-B7DBD3D1D1C20844</sx:uuid> </sx:serviceKey> </sx:uddi> <serviceParameters> <datum> <digitalResource varRef="anyBook"/> </datum> </serviceParameters> </serviceReference> <sx:notMoreThan>1</sx:notMoreThan> </sx:trackQuery> <validityInterval> <notBefore>2005-01-01T15:30:00</notBefore> <notAfter>2005-12-31T15:30:00</notAfter> </validityInterval> </allConditions> </grant> <issuer/> </license>

E.7 Example #6â&#x20AC;&#x201D;Trusted device or online connectivity conditions This is an example of a rights expression specifying that an individual play the stated learning object on a trusted device or be connected to an online service.

110 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

This example satisfies the following IEEE 1484.4 LTSC DREL requirements: Table E.7â&#x20AC;&#x201D;Trusted device Requirement

Validation description

2.1.1 (Formal grammar)

This example is based on the ISO/IEC 21000-5 specification, which formally defines the syntax and semantics of a rights expression language. ISO/IEC 21000-5 is an international standard.

2.1.4 (Unique identifiers for learning objects)

This example shows the use of unique identifiers to refer to a particular song.

2.1.7 (Core set of primitive constructs)

This example uses core primitives from the rights expression language.

2.4.1 (Support conditions that shall be fulfilled before a right is exercised)

This example specifies conditions that must be satisfied in order to exercise the stated right.

2.4.4 (Connectivity-based usage)

This example shows how to specify a connectivity-based condition (connection to an online service).

2.4.5 (Device-based usage)

This example shows how to specify a device-based condition (must play on a trusted device).

2.4.15 (Fees associated with connectivity based usage)

This example shows a fee-condition associated with the connectivity-based usage.

This is the OEBF-REL coding for the license that allows an individual, Alice, to play the specified learning object, Top Jazz Hits, either on a trusted device or while connected to an online service.

<?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <grantGroup> <forAll varName="anyMyuTrustedDevice"> <propertyPossessor> <sx:propertyUri definition="urn:myu:trustedDevice"/> </propertyPossessor> </forAll> <keyHolder licensePartId="Alice"> <info> <dsig:KeyValue> <dsig:RSAKeyValue> <dsig:Modulus>SRagFBUrIzSfaS0xR9lZdUEF0ThO4w==</dsig:Modulus> <dsig:Exponent>AQABAA==</dsig:Exponent> </dsig:RSAKeyValue> </dsig:KeyValue> </info> </keyHolder> <grant> <mx:play/> 111 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

<mx:diReference licensePartId="JazzTopHits"> <mx:identifier>urn:myu:library:music:catalog:jazz:TopHits</mx:identif ier> </mx:diReference> <mx:renderer> <principal varRef="anyMyuTrustedDevice"/> </mx:renderer> </grant> <grant> <mx:play/> <mx:diReference licensePartId="JazzTopHits"> <mx:identifier>urn:myu:library:music:catalog:jazz:TopHits</mx:identif ier> </mx:diReference> <allConditions> <sx:seekApproval> <serviceReference> <sx:uddi> <sx:serviceKey> <sx:uuid>D04951E4-332C-4693-B7DBD3D1D1C20844</sx:uuid> </sx:serviceKey> </sx:uddi> <serviceParameters> <datum> <principal licensePartIdRef="Alice"/> </datum> <datum> <mx:diReference licensePartIdRef="JazzTopHits"/> </datum> </serviceParameters> </serviceReference> </sx:seekApproval> <sx:feePerUse> <sx:rate> <sx:amount>1.00</sx:amount> <sx:currency xmlns:iso="urn:mpeg:mpeg21:2003:01-REL-SXNS:currency">iso:USD</sx:currency> </sx:rate> <sx:to> <sx:aba> <sx:institution>99991212</sx:institution> <sx:account>1234567890</sx:account> </sx:aba> </sx:to> </sx:feePerUse> </allConditions> </grant> </grantGroup> <issuer/> </license>

E.8 Example #7â&#x20AC;&#x201D;Aggregation with attribution This is an example of a rights expression specifying that an instructor can embed the stated learning object onto another object as long as the stated attribution condition is satisfied.

112 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

This example satisfies the following IEEE 1484.4 LTSC DREL requirements: Table E.8â&#x20AC;&#x201D;Aggregation with attribution Requirement

Validation description

2.1.1 (Formal grammar)

This example is based on the ISO/IEC 21000-5 specification, which formally defines the syntax and semantics of a rights expression language. ISO/IEC 21000-5 is an international standard.

2.1.4 (Unique identifiers for learning objects)

This example shows the use of unique identifiers to refer to a particular learning object.

2.1.6 (Extensibility)

The language defines several XML abstract types that can be extended including the principal, resource, right, and condition abstract types. In this example, the mx:mark condition is used to specify an attribution. An alternative is to extend the condition abstract type to add an attribution condition specific to the eLearning community.

2.1.7 (Core set of primitive constructs)

This example uses core primitives from the rights expression language.

2.2.1 (Constraints for embedding learning objects)

This example shows how to specify the embed right to allow a learning object to be aggregated onto another learning object.

2.3.1 (Attribution condition)

This example shows how to specify an attribution condition using the mx:mark condition. Uses the AcmeWatermark example from the ISO/IEC 21000-5 specification.

2.4.1 (Support conditions that shall be fulfilled before a right is exercised)

This example specifies conditions that must be satisfied in order to exercise the stated right.

This is the OEBF-REL coding for the license that allows an instructor to embed onto another learning object the specified learning object as long as the stated attribution is made.

<?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <grant> <forAll varName="anyMyuInstructor"> <propertyPossessor> <sx:propertyUri definition="urn:myu:instructor"/> </propertyPossessor> </forAll> <principal varRef="anyMyuInstructor"/> <mx:embed/> <mx:diReference licensePartId="myuLO123"> <mx:identifier>urn:myu:library:catalog:lecture:LO123</mx:identifier> </mx:diReference> <!--Using the mx:mark condition to specify attribution--> <mx:mark> <mx:diReference licensePartIdRef="myuLO123"/> <acme:acmeWatermark value="Textual attribution: A project funded by the City Historical Society"/> </mx:mark> </grant> 113 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

<issuer/> </license>

E.9 Example #8—Disaggregation with attribution This is an example of a rights expression specifying that an instructor can disaggregate the stated learning object as long as the stated attribution condition is satisfied.

This example satisfies the following IEEE 1484.4 LTSC DREL requirements: Table E.9—Disaggregation with attribution Requirement

Validation description

2.1.1 (Formal grammar)

This example is based on the ISO/IEC 21000-5 specification, which formally defines the syntax and semantics of a rights expression language. ISO/IEC 21000-5 is an international standard.

2.1.4 (Unique identifiers for learning objects)

This example shows the use of unique identifiers to refer to a particular resource.

2.1.6 (Extensibility)

The language defines several XML abstract types that can be extended including the principal, resource, right, and condition abstract types. In this example, the mx:mark condition is used to specify an attribution. An alternative is to extend the condition abstract type to add an attribution condition specific to the eLearning community.

2.1.7 (Core set of primitive constructs)

This example uses core primitives from the rights expression language.

2.2.2 (Constraints for dismantling learning objects)

This example shows how to specify the embed right to allow a learning object to be aggregated onto another learning object.

2.3.1 (Attribution condition)

This example shows how to specify an attribution condition using the mx:mark condition. Uses the AcmeWatermark example from the ISO/IEC 21000-5 specification.

2.4.1 (Support conditions that shall be fulfilled before a right is exercised)

This example specifies conditions that must be satisfied in order to exercise the stated right.

This is the OEBF-REL coding for the license that allows an instructor, Alice, to diminish the specified learning object as long as the specified attribution is made.

<?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <grant> <forAll varName="anyMyuInstructor"> <propertyPossessor> <sx:propertyUri definition="urn:myu:instructor"/> </propertyPossessor> </forAll> <principal varRef="anyMyuInstructor"/> <mx:diminish/> <mx:diReference licensePartId="myuLO123"> 114 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

<mx:identifier>urn:myu:library:catalog:lecture:LO123</mx:identifier> </mx:diReference> <!--Using the mx:mark condition to specify attribution--> <mx:mark> <mx:diReference licensePartIdRef="myuLO123"/> <acme:acmeWatermark value="Textual attribution: A project funded by the MyUniversity"/> </mx:mark> </grant> <issuer/> </license>

E.10 Example #9—Conditions on an aggregated composite object In this example an aggregated learning object (or composite object) consists of different parts: Part1, Part2, Part3, and Part4. Each part was embedded onto the resulting aggregated learning object (or composite object).

This example shows how a rights expression is constructed to control the use of the parts as well as the use of the aggregated object itself.

This example satisfies the following IEEE 1484.4 LTSC DREL requirements: Table E.10—Conditions on an aggregated composite object Requirement

Validation description

2.1.1 (Formal grammar)

This example is based on the ISO/IEC 21000-5 specification, which formally defines the syntax and semantics of a rights expression language. ISO/IEC 21000-5 is an international standard.

2.1.2 (Invariant constraints)

This example shows the specification of multiple constraints that the system retained when the composite object was aggregated.

2.1.4 (Unique identifiers for learning objects)

This example shows the use of unique identifiers to refer to specific resources.

2.1.7 (Core set of primitive constructs)

This example uses core primitives from the rights expression language.

2.2.4 (Constraints for the use of aggregated LOs)

This example shows a rights expression for the composite object.

2.2.5 (Constraints for the different levels of granularity)

The example also has rights expressions for the different parts that make up the composite object.

2.2.6 (Identification of different portions of aggregated LOs)

The example also has rights expressions for the different parts that make up the composite object.

2.4.1 (Support conditions that shall be fulfilled before a right is exercised)

This example specifies conditions that must be satisfied in order to exercise the stated right.

2.4.12 (Portion-based usage)

This example shows how to specify rights and conditions on portions of a composite learning object.

This is the OEBF-REL coding for the license that allows an instructor, Alice, to play the aggregated learning object, CompositeObject1, for free but with a page limit—only the first 100 pages of the composite object can be displayed.

115 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

Alice can also print any of the separate parts of the composite learning object as long as she pays the specified fee.

<?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:oebx="urn:oebf:rr:2004:01-REL-OEBX-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <inventory> <keyHolder licensePartId="Alice"> <info> <dsig:KeyValue> <dsig:RSAKeyValue> <dsig:Modulus>acmM4ccyzA==</dsig:Modulus> <dsig:Exponent>AQABAA==</dsig:Exponent> </dsig:RSAKeyValue> </dsig:KeyValue> </info> </keyHolder> </inventory> <grantGroup> <principal licensePartIdRef="Alice"/> <grant> <mx:play/> <mx:diReference licensePartId="CompositeObject1"> <mx:identifier>urn:myu:library:compositeLO:123456</mx:identifier> </mx:diReference> <oebx:portion> <oebx:unit xmlns:acme="urn:acme:identifiers">acme:page</oebx:unit> <oebx:range> <oebx:from>1</oebx:from> <oebx:to>100</oebx:to> </oebx:range> </oebx:portion> </grant> <!--Rights and conditions for each part of the composite object--> <grant> <mx:print/> <mx:diReference licensePartId="Part1"> <mx:identifier>urn:myu:library:primitiveLO:123</mx:identifier> </mx:diReference> <sx:feePerUse> <sx:rate> <sx:amount>1.00</sx:amount> <sx:currency xmlns:iso="urn:mpeg:mpeg21:2003:01-REL-SXNS:currency">iso:USD</sx:currency> </sx:rate> </sx:feePerUse> </grant> <grant> <mx:print/> 116 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

<mx:diReference licensePartId="Part2"> <mx:identifier>urn:myu:library:primitiveLO:234</mx:identifier> </mx:diReference> <sx:feePerUse> <sx:rate> <sx:amount>2.00</sx:amount> <sx:currency xmlns:iso="urn:mpeg:mpeg21:2003:01-REL-SXNS:currency">iso:USD</sx:currency> </sx:rate> </sx:feePerUse> </grant> <grant> <mx:print/> <mx:diReference licensePartId="Part3"> <mx:identifier>urn:myu:library:primitiveLO:345</mx:identifier> </mx:diReference> <sx:feePerUse> <sx:rate> <sx:amount>3.00</sx:amount> <sx:currency xmlns:iso="urn:mpeg:mpeg21:2003:01-REL-SXNS:currency">iso:USD</sx:currency> </sx:rate> </sx:feePerUse> </grant> <grant> <mx:print/> <mx:diReference licensePartId="Part4"> <mx:identifier>urn:myu:library:primitiveLO:456</mx:identifier> </mx:diReference> <sx:feePerUse> <sx:rate> <sx:amount>4.00</sx:amount> <sx:currency xmlns:iso="urn:mpeg:mpeg21:2003:01-REL-SXNS:currency">iso:USD</sx:currency> </sx:rate> </sx:feePerUse> </grant> </grantGroup> <issuer/> </license>

E.11 Example #10â&#x20AC;&#x201D;Retention of metadata in learning object There may be circumstances where metadata associated with learning objects cannot be harvested or redistributed but must remain with the learning object.

OEBF-REL allows the specification of a prohibited-attribute-changes condition. This condition can be used to ensure that the identified metadata is retained when a right is exercised.

This example satisfies the following IEEE 1484.4 LTSC DREL requirements:

117 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

Table E.11—Retention of metadata in learning object Requirement

Validation description

2.1.1 (Formal grammar)

This example is based on the ISO/IEC 21000-5 specification, which formally defines the syntax and semantics of a rights expression language. ISO/IEC 21000-5 is an international standard.

2.1.4 (Unique identifiers for learning objects)

This example shows the use of unique identifiers to refer to a particular book.

2.1.7 (Core set of primitive constructs)

This example uses core primitives from the rights expression language.

2.2.7 (Constraints requiring the retention of specific metadata)

This example uses the prohibited-attribute-changes condition to prevent changes to the specified metadata.

2.4.1 (Support conditions that shall be fulfilled before a right is exercised)

This example specifies conditions that must be satisfied in order to exercise the stated right.

This is the OEBF-REL coding for the license that prohibits changes to the metadata in a learning object.

<?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <grant licensePartId="usageGrant"> <keyHolder licensePartId="Alice"> <info> <dsig:KeyValue> <dsig:RSAKeyValue> <dsig:Modulus>acmM4ccyzA==</dsig:Modulus> <dsig:Exponent>AQABAA==</dsig:Exponent> </dsig:RSAKeyValue> </dsig:KeyValue> </info> </keyHolder> <mx:embed/> <digitalResource licensePartIdRef="myBook"> <nonSecureIndirect URI="http://www.myu.edu/library/ABCBook.spd"/> </digitalResource> <mx:prohibitedAttributeChanges> <mx:set definition="http://www.myu.edu/library/ABCBook.spd#authorshipMetadata"/> </mx:prohibitedAttributeChanges> </grant> </license>

E.12 Example #11—Supervision-based usage The OEBF-REL allows for the specification of a seek-approval condition as a requirement to exercise a stated right over a digital object. The seek-approval condition provides a mechanism to ask an online service to see if a supervising teacher has registered his/her presence at the test site. A response is transmitted.

118 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

This example satisfies the following IEEE 1484.4 LTSC DREL requirements: Table E.12â&#x20AC;&#x201D;Supervision-based usage Requirement

Validation description

2.1.1 (Formal grammar)

This example is based on the ISO/IEC 21000-5 specification, which formally defines the syntax and semantics of a rights expression language.

ISO/IEC 21000-5 is an international standard.

2.1.4 (Unique identifiers for learning objects)

This example shows the use of unique identifiers to refer to a particular book.

2.1.7 (Core set of primitive constructs)

This example uses core primitives from the rights expression language.

2.4.1 (Support conditions that shall be fulfilled before a right is exercised)

This example specifies conditions that must be satisfied in order to exercise the stated right.

2.4.19 (Constraints related to the manner in which the use of a learning object is supervised)

This example uses the seek-approval condition to specify that a supervisor be present when students take the quiz.

This is the OEBF-REL coding for the license that specifies a seek-approval condition to require the presence of a supervisor in order to exercise the stated right.

<?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <grant> <keyHolder licensePartId="Alice"> <info> <dsig:KeyValue> <dsig:RSAKeyValue> <dsig:Modulus>SRagFBUrS0h27GJrA15SS7TYZzSfaS0xR9lZdUEF0ThO4w==</dsig: Modulus> <dsig:Exponent>AQABAA==</dsig:Exponent> </dsig:RSAKeyValue> </dsig:KeyValue> </info> </keyHolder> <mx:play/> <mx:diReference licensePartId="Quiz101"> <mx:identifier>urn:myu:courses:cs555:Quiz101.quz</mx:identifier> </mx:diReference> <!--Asking the supervising service if Alice can take the quiz--> <sx:seekApproval> <serviceReference> <sx:uddi> <sx:serviceKey> <sx:uuid>D04951E4-332C-4693-B7DB-D3D1D1C20844</sx:uuid> </sx:serviceKey> </sx:uddi> <serviceParameters> <datum> <principal licensePartIdRef="Alice"/> 119 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

</datum> <datum> <mx:play/> </datum> <datum> <mx:diReference licensePartIdRef="Quiz101"/> </datum> </serviceParameters> </serviceReference> </sx:seekApproval> </grant> <issuer/> </license>

E.13 Example #12—Subscription-based pricing This example satisfies the following IEEE 1484.4 LTSC DREL requirements: Table E.12—Subscription-based pricing Requirement

Validation description

2.1.1 (Formal grammar)

This example is based on the ISO/IEC 21000-5 specification, which formally defines the syntax and semantics of a rights expression language. ISO/IEC 21000-5 is an international standard.

2.1.3 (Articulation of roles)

This example shows the how any “consumer” is specified.

2.1.7 (Core set of primitive constructs)

This example uses core primitives from the rights expression language.

2.4.1 (Support conditions that shall be fulfilled before a right is exercised)

This example specifies conditions that must be satisfied in order to exercise the stated right.

2.4.2 (Heterogeneous constraints to use content by individuals or groups)

This example specifies conditions that must be satisfied in order for the group of consumers to exercise the stated right.

2.4.10 (Timed-based usage)

This example specifies validity intervals.

2.4.11 (Fee-based usage)

This example specifies fee-conditions to exercise the stated right.

2.4.16 (Subscription-based pricing)

This example specifies different prices for subscribers based in different territories.

2.4.17 (Time-based pricing)

This example specifies a one-year subscription.

2.6.1 (Offers)

This example specifies offers for consumers to obtain.

E.13.1 Granting rights by subscription In the following examples, the online education magazine publisher offers its consumers the following subscription options: — A basic yearly subscription to the magazine.

— Different subscription rates based on geographic location — Discounted subscription rates for schools and libraries.

These examples represent a different magazine publishing business model. Rather than purchasing rights to a specific issue (similar to buying an issue on the news stand), consumers may purchase a subscription for a flat fee and receive a one year subscription.

120 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

E.13.2 Granting a yearly subscription In this example, the online education magazine publisher offers consumers a yearly subscription to the magazine for a fee of $15.00.

Figure E.7 illustrates the structure of a license that represents the offer that the publisher makes to consumers. This example illustrates the following interesting features of the MPEG REL: — This example uses the possessProperty right to identify magazine subscribers. The possessProperty right grants the identified principal the right to claim ownership of the characteristics listed as resources in the grant (in this case, being a subscriber).

— This grant that consumers may obtain defines a variable using the forAll element. The forAll element contains a validityIntervalDurationPattern to stipulate that matching validity intervals must have a duration of one year. This variable is then used in the grant’s validityInterval condition to specify that the subscription may cover any one-year interval.

Figure E.7—Granting yearly subscription (OeBF) The following example license shows how to represent this information in the MPEG REL: E.13.3 The online education magazine publisher offers consumers a yearly magazine subscription <?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <!--The publisher offers consumers a one-year magazine subscription -> <!--Since this is an offer, any consumer is granted the right to obtain the grant group listed as a resource --> 121 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

<grant> <!-- This forAll element contains a pattern that matches any oneyear time interval --> <forAll varName="oneYear"> <sx:validityIntervalDurationPattern> <sx:duration>P1Y</sx:duration> </sx:validityIntervalDurationPattern> </forAll> <!-- This forAll element does not contain a pattern, so it matches any consumer --> <forAll varName="Consumer"/> <keyHolder varRef="Consumer"/> <obtain/> <!-- The grant that the consumer may obtain. It grants the consumer the right to claim ownership of the property of being a subscriber for one year --> <grant> <keyHolder varRef="Consumer"/> <possessProperty/> <sx:propertyUri definition="urn:onlineEdMag:subscriber"/> <validityInterval varRef="oneYear"/> </grant> <!--If a consumer exercises the obtain right to obtain a license, this fee is paid to the publisher --> <sx:feePerUse> <sx:rate> <sx:amount>15.00</sx:amount> <sx:currency xmlns:iso="urn:mpeg:mpeg21:2003:01-REL-SXNS:currency">iso:USD</sx:currency> </sx:rate> </sx:feePerUse> </grant> <issuer/> </license> The following figure illustrates the structure of the license that the online education magazine publisher issues to Alice if she accepts this offer and pays the $15.00 fee. This license grants Alice the right to claim ownership of the characteristic subscriber for one year.

Figure E.8â&#x20AC;&#x201D;Online publisher offers consumer subscription (OeBF) The following example license shows how to represent this information in the MPEG REL:

122 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

E.13.4 The online education magazine publisher grants a yearly subscription <?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <!--The publisher grants Alice a one-year magazine subscription --> <!--Alice has the right to claim ownership of the property of being a subscriber for one year--> <grant> <!--Alice's identity--> <keyHolder licensePartId="Alice"> <info> <dsig:KeyValue> <dsig:RSAKeyValue> <dsig:Modulus>Fa7wo6NYfasdfd==</dsig:Modulus> <dsig:Exponent>AQAQAA==</dsig:Exponent> </dsig:RSAKeyValue> </dsig:KeyValue> </info> </keyHolder> <possessProperty/> <sx:propertyUri definition="urn:onlineEdMag:subscriber"/> <!--The particular one-year time interval during which this subscription is valid--> <validityInterval> <notBefore>2002-02-03T17:26:00</notBefore> <notAfter>2003-02-03T17:25:00</notAfter> </validityInterval> </grant> <issuer/> </license> E.13.5 Basing subscription rates on location In this example, the online education magazine publisher offers consumers a yearly subscription to the magazine for a fee of 15 U.S. dollars or 17 Canadian dollars.

The following figure illustrates the structure of a license that represents the offer that the publisher makes to consumers. This license differs from the offer described in “Granting a Yearly Subscription” in the following ways: — This offer contains two grants that consumers may obtain, one for consumers in the U.S. and one for consumers in Canada.

— The each of these grants contains two conditions: territory

Identifies a geographic location.

feePerUse Specifies the appropriate fee for that location.

These conditions must be simultaneously met, so they are enclosed within an allConditions element.

123 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

Figure E.9 illustrates these changes.

Figure E.9—Basing subscription rates on location (OeBF)

124 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

The following example license shows how to represent this information in the MPEG REL: E.13.6 The online education magazine publisher offers subscription rates based on location <?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <!-- The publisher offers consumers different subscription rates depending on location--> <grant> <forAll varName="oneYear"> <sx:validityIntervalDurationPattern> <sx:duration>P1Y</sx:duration> </sx:validityIntervalDurationPattern> </forAll> <forAll varName="Consumer"/> <keyHolder varRef="Consumer"/> <obtain/> <grant> <keyHolder varRef="Consumer"/> <possessProperty/> <sx:propertyUri definition="urn:onlineEdMag:subscriber"/> <validityInterval varRef="oneYear"/> </grant> <!--Since there are now two conditions, they are enclosed within an allConditions element--> <allConditions> <!--The territory in which this grant may be used--> <sx:territory> <sx:location> <sx:country xmlns:iso="urn:mpeg:mpeg21:2003:01-REL-SXNS:country">iso:US</sx:country> </sx:location> </sx:territory> <!--The fee appropriate for this territory--> <sx:feePerUse> <sx:rate> <sx:amount>15.00</sx:amount> <sx:currency xmlns:iso="urn:mpeg:mpeg21:2003:01-REL-SXNS:currency">iso:USD</sx:currency> </sx:rate> </sx:feePerUse> </allConditions> </grant> <grant> <forAll varName="oneYear"> <sx:validityIntervalDurationPattern> <sx:duration>P1Y</sx:duration> </sx:validityIntervalDurationPattern> </forAll> <keyHolder varRef="Consumer"/> <obtain/> <grant> <keyHolder varRef="Consumer"/> <possessProperty/> 125 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

<sx:propertyUri definition="urn:onlineEdMag:subscriber"/> <validityInterval varRef="oneYear"/> </grant> <!--Since there are two conditions, they are enclosed within an allConditions element--> <allConditions> <!--The territory in which this grant may be used--> <sx:territory> <sx:location> <sx:country xmlns:iso="urn:mpeg:mpeg21:2003:01-REL-SXNS:country">iso:CA</sx:country> </sx:location> </sx:territory> <!--The fee appropriate for this territory--> <sx:feePerUse> <sx:rate> <sx:amount>17.00</sx:amount> <sx:currency xmlns:iso="urn:mpeg:mpeg21:2003:01-REL-SXNS:currency">iso:CAD</sx:currency> </sx:rate> </sx:feePerUse> </allConditions> </grant> <issuer/> </license> If Alice accepts this offer and pays the appropriate fee, the online education magazine publisher issues her the license shown in “Granting a Yearly Subscription,” which grants her the right to claim ownership of the characteristic subscriber for one year.

E.14 Example #13—Preserved constraints on an aggregated object Embedding individual learning objects, e.g., Part1, Part2, Part3, and Part4, that contain their own rights and conditions onto an aggregated learning object, e.g., CompositeObject1, requires that the resulting rights and conditions be aggregated as well.

If the parts of the aggregated learning object, CompositeObject1, can be individually distinguishable, then the task of aggregating all the rights and conditions is considerably less complicated. The reason is that the rights and conditions for each distinguishable part can be specified as shown in Example #9—Conditions of an Aggregated learning object.

However, if the parts of the aggregated learning object CompositeObject1 cannot be individually distinguishable (e.g., embedding several photos onto a bitmap image results in an aggregated learning object where the parts cannot be individually distinguished), then the application or system must aggregate the rights and conditions (see the coded example in this section).

This example satisfies the following IEEE 1484.4 LTSC DREL requirements:

126 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

Table E.14—Preserved constraints on an aggregated object Requirement

Validation description

2.1.1 (Formal grammar)

This example is based on the ISO/IEC 21000-5 specification, which formally defines the syntax and semantics of a rights expression language. ISO/IEC 21000-5 is an international standard.

2.1.4 (Unique identifiers for learning objects)

This example shows the use of unique identifiers to refer to specific resources.

2.1.7 (Core set of primitive constructs)

This example uses core primitives from the rights expression language.

2.2.3 (Preservation and propagation of constraints under aggregation or embedding)

This example shows how the rights and conditions of individual learning objects (Example 9) were aggregated when multiple learning objects were embedded. The assumption is that all of the original rights and conditions associated with each part must be preserved and propagated.

An alternative to this approach is to extend the ‘condition’ abstract type to introduce a new condition called “preserveGrants” which identifies a list of grants that explicitly identify the rights and conditions to be preserved and propagated.

2.2.4 (Constraints for the use of aggregated LOs)

This example shows a rights expression for the aggregated learning object, CompositeObject1.

2.4.1 (Support conditions that shall be fulfilled before a right is exercised)

This example specifies conditions that must be satisfied in order to exercise the stated right.

This example contains aggregated conditions from each of the parts that make up the composite learning object.

<?xml version="1.0" encoding="UTF-8"?> <license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS ./rel-mx.xsd"> <inventory> <keyHolder licensePartId="Alice"> <info> <dsig:KeyValue> <dsig:RSAKeyValue> <dsig:Modulus>acmM4ccyzA==</dsig:Modulus> <dsig:Exponent>AQABAA==</dsig:Exponent> </dsig:RSAKeyValue> </dsig:KeyValue> </info> </keyHolder> </inventory> <grantGroup> <principal licensePartIdRef="Alice"/> <grant> <mx:play/> <mx:diReference licensePartId="CompositeObject1"> <mx:identifier>urn:myu:library:compositeLO:123456</mx:identifier> </mx:diReference> <validityInterval> 127 Copyright © 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 1484.4-2007 IEEE Trial-Use Recommended Practice for Digital Rights Expression Languages (DRELs) Suitable for eLearning Technologies

<notBefore>2005-01-01T15:30:00</notBefore> <notAfter>2005-12-31T15:30:00</notAfter> </validityInterval> </grant> <!-- Aggregated rights and conditions from the parts --> <grant> <mx:print/> <mx:diReference licensePartIdRef="CompositeObject1"/> <sx:feePerUse> <sx:rate> <sx:amount>10.00</sx:amount> <sx:currency xmlns:iso="urn:mpeg:mpeg21:2003:01-REL-SXNS:currency">iso:USD</sx:currency> </sx:rate> </sx:feePerUse> </grant> </grantGroup> <issuer/> </license>

128 Copyright Š 2007 IEEE. All rights reserved.

Authorized licensed use limited to: Khwaja Fareed University of Eng & IT. Downloaded on July 09,2020 at 06:27:54 UTC from IEEE Xplore. Restrictions apply.