[Odrl-version2] RE: ODRL-Version2 Digest, Vol 9, Issue 7

Alapan Arnab aarnab at cs.uct.ac.za
Tue Aug 30 02:48:02 EST 2005


> <S>
> We thought about this "and" "or" expressiveness in our model in Lissabon but
> did not really find a nice solution. Any proposals?
> <V>
> Can you give some examples of what you'd want to do with the "and" and "or"
> constraint containers?  Do you remember which solutions were proposed and
> what people didn't like about them? 
> 
IIRC, I was one of the proponents for and & or containers. The example I
gave used credentials as an example, but should be possible to craft
other examples. Credentials could be part of the data dictionary as a
constraint.

Take a piece of music - the rights holders may allow for unlimited
reproductions of the music if the user is:
a) A student at University of Cape Town (UCT)
b) An academic staff member at UCT
c) A journalist from Rolling Stones Magazine

using the notation you used earlier, this can be stated as:
\forall x (
	MemberOf(x, pu) AND
	Credential ((rolling_stone_magazine & journalist) ||
		 	(UCT & (student || staff)))
	=> Perm(x, copy, a))

Yes, this can be simplified to a statement using just one container, but
using both an and and an or container would be more useful.

Containers could also be used to define choices in rights - you can
either have unlimited printing of an e-book or make a backup of the
e-book once.
> <S>
> We have to assume our members are known. Which would also be the case in a
> real implementation.
> <V>
> Suppose that the Cornell library signs an agreement with the ACM.  The
> agreement is that any member of the Cornell community (student, faculty, or
> staff) can print any ACM article up to 5 times.  Could such an agreement be
> written in ODRL?  If the answer is yes, what happens to next year's incoming
> class?  At the time the agreement was made, they were not members of the
> Cornell community nor were their identities known, but intuitively they
> should be able to make copies once they join Cornell.  With this example in
> mind, I think membership should be determined at the time a request is made
> (e.g., when Alice asks to copy an ACM article) and not assumed to be known
> when the agreement is signed.  What do you think?   
> 
This is a scenario dependent on the ID manager rather than the DRM
system itself. This scenario could easily be dealt with credentials for
example - the license can be used by anyone who presents a valid
credential from Cornell. However, for this to work, the DRM controller
itself needs to be able to handle credentials.
> <V1> (paraphrasing and polishing a bit)
> Consider the statements "if Alice has made less than 5 copies of h, she is
> permitted to copy f" and "if Alice has made at least 5 copies of h, she is
> permitted to copy f".  Should we conclude that Alice may copy f, even if we
> do not know how many times she copied h?  The intuitive answer (at least to
> me) is that Alice may copy f because either she has made fewer than 5 copies
> of h, in which case the first statement implies the permission, or she has
> made at least 5 copies, in which case the second statement implies
> permission.  An alternative is to say that a permission is granted iff it
> follows from a single statement, in which case Alice may not necessarily copy
> f because neither statement alone gives her permission.  Two slight
> modifications to the alternative approach are (1) assume that all relevant
> environment facts are known, in which case we know how many times Alice
> copied h and we can conclude either from the first or second statement alone
> that she may copy f and (2) allow the application (i.e., the parties in the
> agreement) to define when a permission follows from a set of statements based
> on whether it follows from each statement individually.  
> <S>
> That seems to be a good approach [alternative approach + 2]:  Do I understand
> that correctly: In our case above, in case the rule is "permissions are
> granted if it follows from a single statement" then the permission is
> granted.  Then a second iteration may start with the rule "permissions are
> granted if it follows from 3 statements." then the permission would be
> denied.  After, the second iteration we have an indicator for statements
> whose constraints cancel out. The interpretation process of each individual
> party might decide how to deal in these cases...no?
> <V2>
> I didn't understand your response, so I suspect we're not together.
> Hopefully, my rewrite above helped.  Let me reiterate the key points here.
> Suppose we say that a set S of statements imply a permission p iff there is
> an s in S such that s implies p.  Then, according to the definition, the
> statements "if Alice has made less than 5 copies of h, she is permitted to
> copy f" and "if Alice has made at least 5 copies of h, she is permitted to
> copy f" do not imply that Alice my copy f.  The permission doesn't follow
> from the first statement, because Alice might have made more than 4 copies,
> and the permission doesn't follow from the second statement, because Alice
> might have made less than 5 copies.  In general, I don't see how we could
> efficiently detect statements whose constraints "cancel out" based on whether
> the statements individually imply a permission.  
> 
Surely, the state of no_copies must be checked at the implementation
level - i.e. at the DRM controller, the license is translated to:
if ((no_copies < 5) || (no_copies >= 5)) then copy f;
A smart compiler could condense this down to always true; but I would
not expect such features from a DRM controller. From a DRM controller,
it should check the state of no_copies and then allow copy f.

Hope these comments have some use.

Regards
Alapan
-- 
Alapan Arnab
Data Networks Architecture (DNA) Laboratory
Department of Computer Science
University of Cape Town
Rondebosch, 7700
South Africa

Tel: +27 21 650 3127
Web: http://people.cs.uct.ac.za/~aarnab/
----------
"You must always believe that you can be the best, but you must never
believe you have achieved it".
Juan Manuel Fangio



More information about the Odrl-version2 mailing list