[Odrl-version2] Response to Susanne Guth's mail "New ODRLv2 Model Semantics``

[Vicky Weissman]

Hi,

I finally got a chance to read the new draft.  I haven't done a careful
analysis and I'm sure issues will crop up here and there (they always do)
but, overall, it looks great.  Specific suggestions and questions are given
below.

Best,
Vicky

(*) I recommend expanding the 5 bullets in the Overview to explain each
document.  (I'm thinking 3 sentences or less per doc.)  In particular, I can
take a guess as to what the XML Encoding of the model is but I'm not
confident that my guess is correct; I suspect the Semantics are the part Ric
and I are doing but wouldn't have guessed that from the document alone; and I
don't know what the XML encoding for the semantics is (maybe implemented
algorithms that check permissions?).  If you don't want to expand the
bullets, then I suggest removing them.  

(*) I think of a statement as a complete idea; fragments are a set of
phrases.  So I wonder if "fragments" wouldn't be a better name for the
"statement" rights expression. 

(*) Are you assuming that every asset has exactly one owner?  If so, that
should be said somewhere (maybe I missed it?).  Otherwise, it's not clear to
me why the Request expression has an optional Assigner.  To illustrate the
issue, suppose that Alice and Bob can each write agreements giving access to
an asset called doc1.  Alice gives Charlie permission to read doc1.  Now
consider 2 different requests.  In the first, Charlie requests to read doc1
and the Assigner role is omitted.  In the second, Charlie requests to read
doc1 and the Assigner role is Bob.  If both requests give the same answer;
that is, Charlie is permitted to read doc1, then I suspect that the Assigner
role is irrelevant and, for simplicity sake, should not be a part of the
expression.  If only the first request gives permission, then it still seems
odd to have an optional Assigner because I don't see why a requester would
ever be inclined to include it in her request.  The only motivation I can
think of for having an Assigner has to do with efficiency (i.e., maybe the
algorithm evaluating the request starts with agreements issued by the
Assigner and, if it finds a permission, can return before considering the
others).  This may be reason enough, but I think some discussion in the draft
would be helpful.

(*) I think having a (single) "action" entity include any number of "action
names" is likely to lead to confusion.  For what it's worth, I would have an
"action" include exactly one name, and allow permissions/prohibitions to
include a set (i.e., an AND-container) of actions.  Either way, I think a
sentence is needed explaining what it means for a consumer to have permission
to {edit, copy} a file f.  Is the statement equivalent to a set of
permissions; one giving permission to edit and one giving permission to copy?
Or does the statement allow only a joint action; that is, the consumer may
"edit and copy" but may not necessarily "edit" and may not necessarily
"copy".  

(*) I like the idea of allowing expressions to be negotiable, but wonder if
it would make more sense to have an optional pointer to a document describing
how negotiations can be initiated (e.g., it might include who to contact, how
contact can be made, and details on precisely what can be negotiated), rather
than a Boolean flag.  Non-negotiable expressions would not have the pointer.


I didn't understand the discussion on Transfer Rights or the Exclusive flag
for actions.  

I am concerned that defining a constraint to be a mathematical term
needlessly limits ODRL's expressive power.  For example, we cannot have
constraints such as "consumer is over 18 years of age", "consumer has a valid
driver's license", and "consumer is not blacklisted".  Why can't a constraint
simply be a name and a non-empty list of entities (possibly negated)?  

I'm also concerned that a duty is needlessly limited and, as a result, we
cannot have duties such as "if a user runs a particular beta program, then
she must return a user evaluation", "if the user plays a movie, then she must
pay 5 dollars at the end of the month", and "if a user signs a non-disclosure
agreement, then she may view the company's internal documents".  In addition,
I wonder if ODRL should include duties that prohibit actions such as "if you
read the internal report, then you are not permitted to work for the
prosecution in a legal case against the company".

Recall that ODRL v1.0 has constraints and requirements, where both entities
describe conditions that must be satisfied for a permission to be granted;
the difference is that a consumer is powerless to satisfy a constraint (e.g.,
less than 5 copies have been made), whereas requirements can be satisfied by
the user (e.g., by paying a fee, giving attribution).  In v2.0, requirements
seem to have been replaced by duties with the Relax flag set to false.  Is
this correct?  If so, then it seems like the new version is less intuitive
(and less expressive) than the old. 

Finally, if a consumer is both allowed and forbidden to print the same asset,
then the enforcement mechanism cannot "honor" both expressions.  In
particular, by forbidding the action, the permission is not "honored".  Did
you mean to say that conflicts are resolved by denying permission? 

That's all for now.