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

[Susanne Guth]

Hi Vicky,

thanks for your comments. I try them today:

1.) I added explanations to the document types. Thanks for the good hint. I think that your contribution is required for the Model and the Core Profile. However, I think it might make sense to open up new documents for your contribution. What do you think?

2.) I think of a fragment as something incomplete. However, a statement can still be a complete rights expression with parties, permissions, constraints, etc. and then fragment would not really fit. Maybe we find some other term?

3.) Well the rights holder kind of disappeared. In our previous draft, we had the relationship of the rightsholder. Renato, Alapan why was that removed again? How do we express, I own my music file?

Vicky, a Request usually provokes an offer. The offer then should include an assigner. Therefore, I might make sense to already include the assigner in the request. It might happen, that a rights expression without an assigner are not valid. For example, if the application needs to validate the assigners certificate before rendering.

You write: "If both requests give the same answer;..." a request does not give an answer, because it is a request. Only tickets, agreements, nextrights, and statements can "give an answer" or grant rights. 

Bottom line: I think we should stick with "one owner per asset". 

4.) Hi Vicky, I very much like the comment about you "# of Actions". I noticed this mistake earlier and already changed the cardinalities to 1 - 1, but I am happy that somebody is looking into this in detail, too! :) Keep it up!

5.) I agree, that the negotiation process maybe requires more detail. Alapan, how does the process look like, and how can we indicate negotiable attributes? Did you already state that in one of your documents? 

6.) Vicky I don't see that we can not express "consumer is over 18 years of age" or "consumer must have a valid driver's license." We would simply chose the constraint name accordingly. E.g. ( age_consumer >= 18 ) or ( valid_driverslicense == TRUE)

7.) I also don't see your concerns with the duties. We only have duties now, so that we CAN express your examples. "if the user plays a movie, then she must pay 5 dollars at the end of the month" --> permission= play, asset = a movie, duty = pay, object (of duty) = 5 dollars, constraint (of duty) = by the end of the month. I the duty is not fulfilled then the permission is not granted. Does that make sense? 

Please have a look at this issue
<http://www.odrl.net/2.0/issues/issueslist-1_10.html>
and let me know if you have further questions on duties, requirements. I am sure the new model is not more restrictive...

So long
Susanne

> &#xA> 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.  
>     
> _______________________________________________
> ODRL-Version2 mailing list
> ODRL-Version2 at odrl.net
> http://lists.odrl.net/mailman/listinfo/odrl-version2

-- 
Susanne Guth
susanne at odrl.net
ODRL Initiative
http://odrl.net

Bis zu 70% Ihrer Onlinekosten sparen: GMX SmartSurfer!
      Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer