[Odrl-version2] Comments on Feedback
Renato Iannella
renato at odrl.net
Thu Jun 9 17:03:43 EST 2005
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/>
More information about the Odrl-version2
mailing list