[Odrl-version2] Comments on Feedback

[Renato Iannella]

Thanks to Vicky and Steven for their feedback and comments recently.
We will endeavor to update the Model based on their comments, as well 
as discuss
some of the more challenging questions at the WG Meeting in Lisbon [1].

Here are some answers/clarifications:

S: "An overall conceptual concern I have is that you have attempted too 
many levels of abstraction..."
V: "It seems to me that there are two types of Rights entity, an 
agreement and a request.."

We will take this on board and review the top-level classes to see if 
we can rationalise them.

V: "I'm assuming that the Context in a Rights entity can be extended 
according
to the needs of the particular application.  Is this right?"

Yes

V: "If the Context includes a `space' for textual comments and remarks, 
why
do you need another space for the human readable formulation of the 
rights expression?"

The comments was for *any* comments, but the "human readable" is aimed 
at representing the
rights expression in text - so if it <permission><play> then the "human 
readable" would
be "you have the right to play..." (is this useful - we are not sure?)

V: "I don't understand the Request entity."
S: "Examples of this would be interesting to me also"

We will add more text to this section. The key idea is that the end 
user can enter
a dialog with the rights holder and ask: "Hey, what about if I can do X 
with your asset Y
for Z$ on Friday's?" - it will allow two-way communications instead of 
the current one-way
(ie offers).

V: "The document says `If a parent Asset with child Parts is referenced 
as
the Target of a rights expression, then all of the Parts are considered 
also
to be the Target of the same rights expression'.  I don't understand 
why you
would want to build this into the language."

We wanted to make it clear to the owner that the inheritance 
relationship with Assets may lead
to situations with rights over assets that includes all children assets 
(if they define it that way).

V: "Suppose that Alice is allowed to download asset A; asset B inherits 
from
A; and asset C inherits from B.  I think it follows that Alice may 
download
asset C.  Also, if Alice transfers the right to download A to Bob, then 
I
think Bob can access assets B and C.  Is this right?"

Yes.

V: "Could an Action describe a set of actions, instead of naming them.  
For
example, could an `Action' be every action that has the property of 
leaving
the asset unchanged (this could include actions such as `downloading' 
and
`copying', but not `changing' or `appending')?"

Good question. We need to think about how that style of expression 
would fit.
We were thinking that Actions were more definitive (eg Print).

V: " In ODRL version 1.1, the set of actions was closed under AND, OR, 
and
Exclusive-OR.  Is that no longer true?"

We have left that out. We believe that we can express the same in the 
current model
with a more fine-grained approach to defining permissions with single 
actions in
separate offers, and using Prohibitions to "stop" you doing something 
with something else.
(again, we need to explain that more!)

V: "Suppose that an agreement includes a permission whose Action is 
{`copy',
`download'} and the exclusive Boolean flag is set.  Can another 
agreement
include a permission whose Action is {`copy'}?"
S: "I skipped the 'exclusive boolean flag' paragraph the first time 
around since I didn't understand it"

Because you have already assigned the "copy" permission to someone and 
you
said you would not assign it to anyone else (==exlusive flag), then the 
cannot assign "copy".

V: " What if the assigners are different?    What if the assets are 
different?  I think I'm missing the
intuition behind the flag."

If there are different Assigners, then their must be some agreement 
between them as to
how to deal with exclusive rights. Perhaps one does Europe, the other 
does Asia.
If the assets are different then you are assigning different rights - 
the "exclusiveness" would
have to have the same asset, same owner, and same permissions.

V: "Can a constraint capture the fact that an assignee has a certain 
property
(e.g., is a student, has no outstanding fines)? ..."

Good question. Will have to review this one in Lisbon.

V: "In practice, what's the difference between a Duty in which the 
Relax flag
is true and no duty at all? "

The difference is that the Assignee has agreed to do the Duty. Even 
with Relax=False,
this does not mean they don't have to do it - they still do. Some 
external policy may
define the consequences of not doing it.

V: "Could an agreement include a duty that requires an action to be 
done at a
particular time, but not before the permission is exercised?"

Yes.

V: "Are you assuming that each asset a has a single owner o and, for any
agreement that includes a, the assigner is o?"

No - asset can have multiple rights holders - and we don't assume all 
will be listed in every
agreement that has asset A.

V: "Suppose that a user wants to do a particular action (e.g., Alice 
wants to
download a file f).  Given a set of agreements, how do we determine 
whether
she has permission to do the desired act?"

Good question. Are you sort of asking "what is the formal model to 
prove that
the rights expression is correct" ? We need help in this area - how to 
practically do this is
a big challenge.

S: "Statements. I'm having trouble understanding how this would be 
used, and I would like a real-world example of this, other than the 
"rights template" example shown later. "

A statement was introduced to satisfy the need to allow for expressions 
that had missing information and/or
assumed stuff based on the context of the profile. The best example is 
with Creative Commons - all that is expressed
is the permissions - no asset, not parties.

S: "I would like examples of the "Object" of Duty in the real-world."

The most common objects would be Payments - it is a bit like 
Requirements from V1.1
(We may need to find a better word than the overloaded Object)


[More feedback to come....]


Cheers...  Renato Iannella
Project Leader, NICTA, Brisbane, QLD, AUSTRALIA
P: +61 7 3000 0484 F: +61 7 3000 0480 M: +61 4 1313 2206
E: renato at nicta.com.au W: http://nicta.com.au

[1] <http://odrl.net/workshop2005/>