From Susanne.Guth at gmx.net Fri May 5 16:28:44 2006 From: Susanne.Guth at gmx.net (Susanne Guth) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] NEW ODRLv2 Model Semantics - Working Draft Message-ID: <26356.1146810524@www097.gmx.net> Dear Working Group Members, we proudly present the new working draft of the ODRL v2 Model Semantics - the core piece of ODRL Version 2. http://odrl.net/2.0/WD-ODRL-Model.html Thank you for all the supportive work that has been done by the working group during the last year. Please find a list of changes withing the document. Every new comments will be highly appreciated. Best regards -- Susanne Guth susanne@odrl.net ODRL Initiative http://odrl.net/ "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail From Susanne.Guth at gmx.net Wed May 10 18:32:09 2006 From: Susanne.Guth at gmx.net (Susanne Guth) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] NEW ODRLv2 Model Semantics - Working Draft References: <2038.84.251.24.233.1147211726.squirrel@webmail.axxion.fi> Message-ID: <2102.1147249929@www017.gmx.net> Eetu, good to hear from you again. Yes, I agree. The level of datail of the elements is not balanced yet. I would love to refer to a set of metadata for contracts, but I don't now one. Do you? In case there is none, we would like to suggest the vocabulary that is currently in the legal object. The vocabulary here actually needs to be moved to the Document "ODRL V2.0: Core Dictionary" which has to come up later. So long and thanks for your comments. Keep it up! Susanne > > > Guten Abend Dr. Guth, > > Short comment based on the assignment of the rights expression type. This > seems to me as a path towards describing copyright contracts and alike, in > addition to being a control mechanism in DRM solutions. If so, then would > it make sense to have optional references to contract document or document > metadata similar way as with the asset entity? Using uid and reference to > metadata would probably be the straightforward way. > > BR, > > -Eetu > > Eetu Luoma > Managing Director > > Dr.Elma Ltd. > Ylist?nm?entie 26 > FI-40500 Jyv?skyl? > Finland > GSM +358 40 7393075 > email eetu.luoma@drelma.com > > > > > Dear Working Group Members, > > > > > > we proudly present the new working draft of the ODRL v2 Model Semantics > - > > the core piece of ODRL Version 2. > > > > http://odrl.net/2.0/WD-ODRL-Model.html > > > > Thank you for all the supportive work that has been done by the working > > group during the last year. Please find a list of changes withing the > > document. > > > > Every new comments will be highly appreciated. > > > > Best regards > > > > -- > > Susanne Guth > > susanne@odrl.net > > ODRL Initiative > > http://odrl.net/ > > > > "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... > > Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail > > _______________________________________________ > > ODRL-Version2 mailing list > > ODRL-Version2@odrl.net > > http://lists.odrl.net/mailman/listinfo/odrl-version2 > > > > -- Susanne Guth susanne@odrl.net ODRL Initiative http://odrl.net/ Echte DSL-Flatrate dauerhaft f?r 0,- Euro*! "Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl From Steven_Rowat at sunshine.net Fri May 12 03:36:49 2006 From: Steven_Rowat at sunshine.net (Steven Rowat) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] NEW ODRLv2 Model Semantics - Working Draft Message-ID: Hi Suzanne & list, Congratuations on the model publication; it looks very good. And you have been overly kind in including my name in your thank you; really I have been more of an interested spectator, and you have already been highly indulgent of my untutored questions. But, if I may, I'm going to continue that tradition: I've been trying to figure out what exactly is required for ODRL to function in the wider world. To do this I've looked at the Wikipedia representation of the OSI Reference Model (http://en.wikipedia.org/wiki/OSI_model). It seems to me that ODRL resides, in this model, within layer 7, Application (the top layer). Is this a fair conclusion? And if so, what sorts of interfaces within Layer 7 (such as ability to perform as a plug-in to a browser) or to Layers 6 and possibly 5 (Presentation and Session) are either already being worked on or are planned? To slightly reword the last question - is it up to the writers of ODRL to make such interfaces, or are they already existing and it's merely a matter of defining some appropriate code within ODRL to harmonize with them? Best regards, Steven Rowat > >we proudly present the new working draft of the ODRL v2 Model Semantics - >the core piece of ODRL Version 2. > >http://odrl.net/2.0/WD-ODRL-Model.html > >Thank you for all the supportive work that has been done by the working >group during the last year. Please find a list of changes withing the >document. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - web site: mailto:sc@rowatworks.com From renato at odrl.net Fri May 12 11:45:57 2006 From: renato at odrl.net (Renato Iannella) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] NEW ODRLv2 Model Semantics - Working Draft In-Reply-To: References: Message-ID: On 12 May 2006, at 03:36, Steven Rowat wrote: > To slightly reword the last question - is it up to the writers of > ODRL to make such interfaces, or are they already existing and it's > merely a matter of defining some appropriate code within ODRL to > harmonize with them? Steven, it would not make sense for ODRLers to define the interfaces as this is best done by the specific community that implements a DRM system with ODRL. The best example is with the OMA in which they had to define the (secure) layer interfaces from the device right up to the application on the phone. Cheers... Renato Iannella National ICT Australia (NICTA) From vickyw at cs.cornell.edu Wed May 17 10:11:20 2006 From: vickyw at cs.cornell.edu (Vicky Weissman) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] Response to Susanne Guth's mail "New ODRLv2 Model Semantics`` In-Reply-To: Message-ID: <2EE48095D8C21643B0B70EC95F9BFBAF0196587F@EXCHVS1.cs.cornell.edu> 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. From Steven_Rowat at sunshine.net Sat May 20 14:02:21 2006 From: Steven_Rowat at sunshine.net (Steven Rowat) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] NEW ODRLv2 Model Semantics - Working Draft Message-ID: Hi, I've gone through the v2 Model more carefully, and would like to add some comments (in some cases I'm echoing Vicky's concerns; others are different). First, overall, let me say I believe it's more likely ODRL will succeed if this v2 Model document reaches out to people who, like me, are not experts in the model but who have a strong interest in knowing how ODRL works. And at almost all points in the document I was able to follow, and I believe most people could. And for that, congratulations. Because I know it's not easy writing so I can understand it. :-) 1. Overview Vicky: >I recommend expanding the 5 bullets in the Overview to explain each >document.... Agreed. 2.1 Rights Vicky: >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.... Agreed. I also thought the word "Set" might be considered instead of "fragments". But I think either would be better than "Statement" for the purpose. "REQUEST": I believe this sentence is confusing: "The request supports rights expressions that are soliciting the terms and conditions of usage over content from a consuming party". It could possibly mean "soliciting...from a consuming party"; which is not correct (I think!) "The consuming party" is doing the soliciting, not being solicited, for the terms of usage. So you would better say: **The request supports rights expressions that are solicitations from a consuming party of the terms and conditions of usage over content.** I also find the last sentence of the Requests section confusing; not easy to tell who is the former and latter; and in fact it's not sentence; perhaps it could be rewritten as: **The request may also contain the Party entity with Assigner role if this is known; the Assignee(s) Party being responsible for requesting a set of terms and conditions for use over content owned by the Assigner Party.** 2.2 Asset "In the case where the Parent Asset rights contains stateful expressions, then the inheritance relationship can indicate if the state values are also inherited or not." What is a "stateful expression"? Could you perhaps give a very brief example of one at this point - even just a mention (in parentheses)? 2.4.1 Action Vicky: >I didn't understand the discussion on Transfer Rights or the Exclusive flag for actions.> I had my problems with these also. First, I didn't understand point of the whole paragraph on Transfer Rights, maybe because I got off to a bad start with the first sentence, which I think might be missing a crucial "that"; or need to be amended. The first sentence is: "The Transfer Rights entity is a type of Action that indicates rights that can be further allocated as part of the containing Permission must not exceed those identified in the rights expression statement." The way I've tried to make sense of this is to add a [that] as follows: **The Transfer Rights entity is a type of Action that indicates [that] rights that can be further allocated as part of the containing Permission must not exceed those identified in the rights expression statement.** However, even with this emendation, I don't understand the two sentences that follow it. As well, the last sentence ends with "...other parties (i.e. the consumers of consumers)". This seems nonsensical, or at least cannibalistic (). Perhaps *...(ie. the secondary consumers)* would be better? 2.4.2 Constraint Vicky: Agreed. 2.4.3 Duty Vicky: Agreed. --Note also a typo, "who is responsible for fulfill the Duty" should be "for fulfilling the Duty" (the same construction as the sentence following it, which is correct). 2.7 Communication This section appears to define a Communication entity and a Negotiation entity, but I'm unclear about their relationship. Specifically, what aspects are there in the Communication entity? All the listed ones are in the Negotiation entity. Yet the definition of the Communication entity says it adds 'negotation aspects' to a Rights entity. Are they in a hierarchical arrangement? 2.8 Container I have not fully grasped how containers are meant to function in ODRL. Perhaps you could add a text example, or a figure? Example: Offer and Transfer Rights (figure 7) Maybe it's just me, but I found myself staring at the "Offer and Transfer Rights" figure (7) for half an hour, and I was still confused. It's sort of like a map of the London Tube System - one can start anywhere, go anywhere; but how to decide where to start? And which way to go in the next step? And the next? The number of choices is bewildering. I feel that some guiding principle needs to be more obvious, a sorting by time flow, or by a level or hierarchy (sorted visually), or by people; or something. The color scheme and layout, as it is, doesn't do this for me; somehow it all seems mixed together. Perhaps there could be a placing of some of the boxes, or data from boxes, inside others to group them meaningfully? - For example, the "Rights Offer" box could be taken as a starting point, and be larger, at the left side or top, and 004 Duty, 002 Object, and Object5 Action seem to me to be so much a part of this Offer that their boxes could be inside it; in fact so could P05 Party who makes the offer. This would remove 4 boxes from the visual stream, and group some of the Offer's key parts inside it. If the same grouping is done with the rest of the boxes, perhaps they could be reduced to three or four main ones (with the ones inside being either boxes or sublists). I suggest this not because I'm attempting to make it "look nice". But because I frankly don't understand what's going on in this diagram and I think these changes might help it. Best regards, steven rowat >Dear Working Group Members, > > >we proudly present the new working draft of the ODRL v2 Model Semantics - >the core piece of ODRL Version 2. > >http://odrl.net/2.0/WD-ODRL-Model.html > >Thank you for all the supportive work that has been done by the working >group during the last year. Please find a list of changes withing the >document. > >Every new comments will be highly appreciated. > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - web site: mailto:sc@rowatworks.com From aarnab at cs.uct.ac.za Mon May 22 06:35:41 2006 From: aarnab at cs.uct.ac.za (Alapan Arnab) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] Response to Susanne Guth's mail "New ODRLv2 Model Semantics`` In-Reply-To: <2EE48095D8C21643B0B70EC95F9BFBAF0196587F@EXCHVS1.cs.cornell.edu> References: <2EE48095D8C21643B0B70EC95F9BFBAF0196587F@EXCHVS1.cs.cornell.edu> Message-ID: <1148243741.6956.18.camel@iduna> 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 From renato at odrl.net Tue May 23 16:56:44 2006 From: renato at odrl.net (Renato Iannella) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] Response to Susanne Guth's mail "New ODRLv2 Model Semantics`` In-Reply-To: <2EE48095D8C21643B0B70EC95F9BFBAF0196587F@EXCHVS1.cs.cornell.edu> References: <2EE48095D8C21643B0B70EC95F9BFBAF0196587F@EXCHVS1.cs.cornell.edu> Message-ID: Vicky/Steven, thanks for your comments - we will endeavor to include them in next version and add more explanation/examples where you have highlighted some concern. Some quick points 1 - An asset can have many owners 2 - the "mathematical terms" used for constraints(eg duties) should address your scenarios (if not, we will check) Cheers Renato From Susanne.Guth at gmx.net Tue May 30 07:46:22 2006 From: Susanne.Guth at gmx.net (Susanne Guth) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] Response to Susanne Guth's mail New ODRLv2 Model Semantics`` In-Reply-To: <2EE48095D8C21643B0B70EC95F9BFBAF0196587F@EXCHVS1.cs.cornell.edu> References: <2EE48095D8C21643B0B70EC95F9BFBAF0196587F@EXCHVS1.cs.cornell.edu> Message-ID: <20060529214622.168390@gmx.net> 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 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 >? > 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@odrl.net > http://lists.odrl.net/mailman/listinfo/odrl-version2 -- Susanne Guth susanne@odrl.net ODRL Initiative http://odrl.net Bis zu 70% Ihrer Onlinekosten sparen: GMX SmartSurfer! Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer From Susanne.Guth at gmx.net Tue May 30 07:46:22 2006 From: Susanne.Guth at gmx.net (Susanne Guth) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] Response to Susanne Guth's mail New ODRLv2 Model Semantics`` In-Reply-To: <2EE48095D8C21643B0B70EC95F9BFBAF0196587F@EXCHVS1.cs.cornell.edu> References: <2EE48095D8C21643B0B70EC95F9BFBAF0196587F@EXCHVS1.cs.cornell.edu> Message-ID: <20060529214622.168390@gmx.net> 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 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 >? > 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@odrl.net > http://lists.odrl.net/mailman/listinfo/odrl-version2 -- Susanne Guth susanne@odrl.net ODRL Initiative http://odrl.net Bis zu 70% Ihrer Onlinekosten sparen: GMX SmartSurfer! Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer