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

[Vicky Weissman]

<R> 
In V1.1, we had an explicit XML container mechanism that allowed you to say
that you have Permission X <or> Y (not both) - by default, all Permissions
were and-ed. This container was a bit messy.

There seems to be 3 alternatives:

1 - Put all the <or> options into separate Offers

2 - Link the alternate Permissions as Prohibitions - that is - You are
Permitted
     to do X and Y, but you are Prohibited to do X if you have done Y (and
vice versa)

3 - Keep the <or> structure in the V2 model

<V>
I've never have a good intuitive understanding of the containers.  If I
remember correctly, the original model allowed <and>, <or>, and <xor>
containers, where <or> is an abbreviation for inclusive-or and <xor> is an
abbreviation for exclusive-or.  Suppose that X = "watch the movie twice at
medium resolution", Y = "watch the movie once at high resolution", and
Microsoft gives the user permission X <and> permission Y.  I think this means
that the user can watch the movie three times, twice at medium resolution and
once at high resolution.  The user can also choose to do some partial
combination of these actions, such as watching the movie once at high and
once at medium.  So far so good.  

Now suppose Microsoft gives the user permission X <or> permission Y.  This is
more troubling.  One interpretation is that the user can choose whether to do
X or to do Y, but cannot do both.  But, if this were the case, then how is
<or> different from <xor>?  Another possibility, is that Microsoft promises
to give the user permission X <or> Y, but won't commit to which.  This might
make sense.  Maybe Microsoft's player has limited bandwidth so, when the user
tries to play the movie, MS will either show it in high res (after which the
user has no more permissions to exercise) or MS will show it in medium res
but let the user watch it a second time at medium if the user so desires.  Of
course, this also seems like an <xor> rather than an <or>, but its hard to
believe a contract would say "we'll let you watch the movie once at high,
twice at medium, or three times (once at high, twice at medium), depending on
our mood".  The bottom line is that I don't understand the intuitive meaning
behind the <or> container, at least with respect to permissions.  

Finally, suppose Microsoft gives me permission X <xor> permission Y.  Now,
the interpretations that I tried to give to <or> make sense here.
Unfortunately, there's more than one interpretation to choose from.  The
alternatives (1) and (2) that Renato gives in his email suggest that the
intended meaning of permission X <xor> permission Y is that the *user* can
choose whether to exercise X or Y.  If you go with alternative (1), the user
makes her choice before committing to the agreement and, if you go with
alternative (2), the choice is made when the user first exercises a relevant
permission.  Obviously, I can't tell you which you want, and I'm not sure you
don't want both.  In fact, I wouldn't be surprised if you want three flavors
of <xor>.  In the first, the user picks an option (in the example, the user
would pick between X and Y) before committing to an agreement.  In the
second, the user picks an option when she wants to execute one of the
relevant permissions.  In the third, the owner/manager of the asset picks an
option at the time of execution, probably based on the current environment
(e.g., system load).  Note: there's no reason to have the owner make a
decision at the time of the offer, since in this scenario, the owner could
simply tailor the offer to her preference (in the example, the owner might
offer x or might offer y, but wouldn't create an offer that had the two
permissions xor-ed).  

In summary, I'd keep the <and> container and see no reason why it shouldn't
be the default.  I'd remove the <or> container, because I don't understand it
(lets not think about what that says about me :).  And, for maximum
flexibility, I'd replace the <xor> container by 3 flavors of <xor>, which
amounts to allowing an offer to be an <xor> of offers, a permission to be an
<xor> of permissions or an <xor-owner's choice> of permissions.  Note that
I'm assuming the <xor> is the user's choice unless otherwise specified.      

<A>
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.

<V>
I like your examples.  I think the first example shows that the <or>
container makes intuitive sense for some entities (in particular,
constraints).  This suggests that, to determine which containers should be in
ODRL, we need to consider each entity individually.  Also, if ODRL includes
<or> for constraints, I think the document should note that the <or> is
essentially an abbreviation.  As you point out, we don't need <or> to make
the statement but, by using <or>, we can capture the idea in a shorter
statement that is arguably easier to read.  

The second example, together with the first, highlights that we need to be
careful with <or> and <xor>.  Notice that in the first example, you talk
about an "or container", meaning inclusive-or.  (I'm assuming a staff member
who is also a student and consults for Rolling Stone can copy a).  In the
second example, you again talk about "or", but here mean an exclusive-or.
(I'm assuming I can't both do unlimited printing and make a backup.)      


> <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?  

<A>
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.

<V2>
I think you're assuming that the value of no_copies is known at the time of
the request.  If this is the case, then the naïve algorithm that I suggested
should work just fine.  More generally, if we assume all possibly relevant
facts are known at the time of evaluation, then I think the algorithm gives
the intuitively correct answer.  But suppose the value of no_copies is not
known.  Then I think a naïve DRM controller will not grant the permission,
thus giving an intuitively incorrect response, because neither (no_copies <
5) nor (no_copies >= 5) individually evaluates to true.   

-Vicky