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

[Alapan Arnab]

Hi,
My 2 cents on the points raised by 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.  
If I understand this correctly, the XML encoding for the semantics is
the XML encoding of the model, which can be used to create ODRL
licenses. I agree with expanding the bullets idea.
> (*) 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 prefer optional assigners, if only because it allows for anonymous interactions. 
This is especially relevant with Request, because the requestor (usually the client)
might want to remain annonymous until (s)he is offered a license that
(s)he is interested in ...
> (*) 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 totally agree 
> (*) 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.
The non negotiable attribute is aimed to show that a particular right or
constraint is non-negotiable. For example, a music store could decide
that the right to play is a non-negotiable element for protected files
(which makes sense and avoids complicating AI agents). The optional
attribute you raise should, in my opinion, be coupled with the protected
object and not the license.

> 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)?  
In my paper to the ACM-DRM workshop last year[1], I proposed the use of
credentials to solve this problem. I am not sure why you think a
credentials like term (valid driving license or not blacklisted) cannot
be accomodated. 
> 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".
I am not sure why you say that the duties you mentioned cannot be accomodated ...

-- 
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/
Blog: http://idiots-mind.blogspot.com
----------
"You must always believe that you can be the best, but you must never
believe you have achieved it".
Juan Manuel Fangio