From vickyw at cs.cornell.edu Wed Feb 1 10:42:21 2006 From: vickyw at cs.cornell.edu (Vicky Weissman) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] Handling Prohibitions Message-ID: <2EE48095D8C21643B0B70EC95F9BFBAFD85F79@EXCHVS1.cs.cornell.edu> Hi All, I've looked over the email discussions are prohibitions and, based on them, I suggest we do the following: (1) Extend agreements to include prohibitions, where a prohibition says that an action is forbidden if certain conditions hold. (2) Extend agreements to include a default, which is either permit or forbid. (3) Say that a set of agreements imply that a request (e.g., may Alice download Season 1 of Lost) should be granted if (a) the agreements together imply the request should be granted or (2) the agreements together do not imply the request should be granted, do not imply the request should be denied, and the default for all agreements is permit. Are there any objections? -Vicky From aarnab at cs.uct.ac.za Wed Feb 1 02:24:38 2006 From: aarnab at cs.uct.ac.za (Alapan Arnab) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] resumption of containers & model update In-Reply-To: <5860.1138581121@www082.gmx.net> References: <5860.1138581121@www082.gmx.net> Message-ID: <1138721079.8951.53.camel@iduna> Hi, > 1.) Containers I like your approach and I think it makes a lot of sense. There is a need to define interpretation of containers in this case though as the license in your example could be interpreted as: The user is allowed permission A with constraints (X) and (Y) and (X or Y) which is not necessarily what you mean. > 4.) > > What do you guys think of removing the rights-expression-type level and > instead using an attribute "TYPE" in rights to specify the semantics of the > actual rights expression? > > I have a problem with different hierarchies of RE elements, like in alapans > approach - simply for negotiation. If somebody wants to use ODRL without the > negotiation part, then the hierarchies do not make sense at all. An aim > should really be to keep the negotiation part independent of the remaining > model. I think this problem arose because I tried to retain as much of the old model as possible. But your model is very close to my last model so I think we are close to agreement on most of the issues in this regard. > If a RE grants next rights, for example, then these nextrights have to be > defined in a new rights expressed. RE ids would have to link the various > rights expressions. This would have the advantage that a "nextRight" could > more easily become part of a new agreement (I think). > In your model I think it will work. I do have some reservations with regards to validity checking in XML implementations though. Regards Alapan -- 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 aarnab at cs.uct.ac.za Wed Feb 1 02:43:36 2006 From: aarnab at cs.uct.ac.za (Alapan Arnab) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] New ODRL v2.0 Model In-Reply-To: <18665.1138577348@www082.gmx.net> References: <1137412528.7270.34.camel@iduna> <18665.1138577348@www082.gmx.net> Message-ID: <1138722216.8951.59.camel@iduna> Hi Susanne, Thanks a lot for the clarification - I understand the subtle difference now and it makes a lot more sense. But from purely an implementation point of view - if payment is an action, wouldn't both the following code fragments be correct? 1 1 The second one does not make much sense, but I think all validity checkers will pass it. From an implementation point of view, this could raise some problems. Regards Alapan On Mon, 2006-01-30 at 00:29 +0100, Susanne Guth wrote: > Hi Alapan, > > one comment to our discussion: > > Maybe there is still a misunderstanding, what the action element is. > It simply "names" the action that always comes with a permission or duty or > prohibition. > > For example a duty to pay some amount would look like that: > > o-ex20:duty id="d01" relaxed="true"> > > 0,50 > > > > > where "payment" is the action element. There is no duty without an action or > "if there's no action defined then there is not duty". > > And after all: when expressing a prohibtion the duty element is optional > (and implicitly the action element too). > Does that make sense to you or is still something unclear? > > Susanne > ++++++++++++++++++++++++++++ > Mail history: > > 4.5.4 Parties & Duties > > I need some more information on this issue because I don't understand > the conflict that you have. Is it because the Duty always refers to an > Action? > > Yes - a duty requires an action. However, you might want a prohibition > license that allows everything - hence there will be no action to link > with the duty. > > -- 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 aarnab at cs.uct.ac.za Wed Feb 1 20:50:11 2006 From: aarnab at cs.uct.ac.za (Alapan Arnab) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] New ODRL v2.0 Model In-Reply-To: <5249.1138455483@www061.gmx.net> References: <1136968801.7279.11.camel@iduna> <5249.1138455483@www061.gmx.net> Message-ID: <1138787411.7247.2.camel@iduna> Hi Susanne, Thanks a lot for your comments - they are very much appreciated. > 1.) > How do you like a different title that expresses what you actually want to > address - negotiation! Something like: > > "Enabling ODRL for Negotiation" or something similar. I think the overall > approach should be, that negotiation in ODRL can be used as a plug-in. Maybe > as a subschema? What do you think about that? > While I agree that much of the paper was about negotiation, there were significant parts also to do with other aspects of ODRL - aspects that we have now discussed in detail in the past few weeks. As for negotiation - ODRL does not have to specifically cater for it. In my opinion, no language can have all the vocabulary needed to express ideas that have yet to be formed. Expressing negotiations is a matter of vocabulary. What I am interested in is more in the structure of the language, the grammar - so that, if new vocabulary is introduced, it does not require a radical overhaul of the language. In this sense, I would like ODRL to cater structurally for negotiations. Thus, negotiations will in effect be still a plug-in as much of the necessary vocabulary need not be in the main data dictionary - but I think there is a need to stop developing a new REL in order to express negotiations. On this point, I think your proposed model (my comments on that are on a separate email) does fulfil the requirements. > 2.) > On page 2 you write "there is some mandatory information". Can you be more > concrete on this. What exactly is really mandatory? Do we have a contract > expert among us? I know that in Germany, for example, contracts are > formless. What is your source for the information 2.1, 2.2, 2.3, etc. can > you refer to some business standards document? > As I wrote in a footnote earlier, the basis for my discussion in on South African law, which in turn is based on common law and Roman-Dutch law. I did rely on a law text book (ref 11) which is used to teach first year contract law for the basics, but I do intend going over section 2 with a law professor from my university once I get back next week. >From what I understood from the text book, there is some information that is required to be present in a contract to be valid which include things like the date when the contract is being entered into (or comes into effect) etc. but I do plan on getting the information correctly verified etc. soon. > 3.) > In Section 3 you define 3.Bargaining, in Section 3.3 you describe > "Bartering". Which one is the right term? > My mistake - I should stick to one term - and I prefer bartering. > 4.) > You refer to Su et al and name the 4 components for electronic negotiations. > > I guess for the entire ODRL community it would be important to define where > the "language to define rules" ends and where "the language to express > negotiation proposals" --> ODRL starts. I there a concrete example in your > references that show the difference between the two languages? > Unfortunately not. But personally I like to think of it in the following way: The language to express negotiation protocols is the language used between two or more parties to express their needs and offers. Thus in a bazaar for example it could take the form of: Cust: "How much is this?" Sell: "I will give it you for 50" Cust: "That's too much, I can only offer 20" Sell: "At that price, my kids will go hungry to bed. The best I can do is 40" Cust: "I can offer 30 and not more" Sell: "35" Cust: "Ok, but with delivery to my hotel" Sell: "Done" In my mind, that is what ODRL needs to do - express the negotiations and get the final set of terms and conditions. The "language to define rules" refers to how the seller and the customer make up their mind on the value propositions. This could take a lot of different factors into account - for example, previous transaction history, the method of payment, the trustworthiness of the relevant parties. Thus, in the above example, the seller could be calculating his offers based on the cost price and thus maximising his profit, while the buyer is calculating his offers based on how much money he has in his pocket. In my opinion, standard ODRL should not be involved in this - as there are too many permutations involved. > 5.) > What language would be suitable as "language to define rules"? RuleML? > Not sure - I do plan to tackle this issue sometime this year though ;) It could be based on ODRL - but since this has to do with specific installations and AI agents, I don't see a need to cater for it in ODRL specifically. > That's it. If time allows I will respond to the other already ongoing > discussions. We have really important issues here... > So long and thanks for your effort. > :)) > Thanks a lot for your efforts too! Regards Alapan > Susanne > > "The customer is always right" > > > > > > Hi, > > New year's greetings to everyone. > > > > As discussed with Renato and Susanne last month, I have been working on > > a few new ideas on the ODRL v2.0 model, which I have just completed. In > > the attached PDF, you will find a paper detailing the new model, and the > > motivations for the changes (most of which are based on negotiations > > support). The paper also contains 7 examples (in XML), the full schema > > (XSD) and a sample data dictionary. > > > > I can forward the original source documents for the model, xml examples > > and schema file. > > > > I would like your comments and feedback esp. with regards to the duty > > and action elements (see sections 4.5.4 and 4.5.5). > > > > Regards > > Alapan Arnab > > -- > > 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 > > > -- 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 Sun Feb 5 23:34:49 2006 From: renato at odrl.net (Renato Iannella) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] New ODRL v2.0 Model In-Reply-To: <1138722216.8951.59.camel@iduna> References: <1137412528.7270.34.camel@iduna> <18665.1138577348@www082.gmx.net> <1138722216.8951.59.camel@iduna> Message-ID: On 1 Feb 2006, at 01:43, Alapan Arnab wrote: > > But from purely an implementation point of view - if payment is an > action, wouldn't both the following code fragments be correct? > > > > 1 > > > > > > 1 > > True... We need a way to constrain some Actions to Permissions and some to Duties only... Cheers Renato Iannella ODRL Initiative http://odrl.net From Susanne.Guth at gmx.net Mon Feb 6 01:37:52 2006 From: Susanne.Guth at gmx.net (Susanne Guth) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] New ODRL v2.0 Model References: Message-ID: <14050.1139150272@www088.gmx.net> Hi, I don't have a problem with the two rights expressions below. Why do we want to relate certain actions to duties only? For example, if there's one special accountant in a company that is allowed to do payments that are over 5000 ? he requires an according permission. I think, that if we constrain a certain vocabulary to permissions/ or duties we reduce the flexibility of our language. I think, the software/system that uses ODRL v2 rights expressions would have to decide what actions make sense as permissions and duties. I don't think its our work to do. Discussion opened :) So long Susanne > > > On 1 Feb 2006, at 01:43, Alapan Arnab wrote: > > > > > But from purely an implementation point of view - if payment is an > > action, wouldn't both the following code fragments be correct? > > > > > > > > 1 > > > > > > > > > > > > 1 > > > > > > True... > > We need a way to constrain some Actions to Permissions and some to > Duties only... > > Cheers > > Renato Iannella > ODRL Initiative > http://odrl.net > > > _______________________________________________ > 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/ Telefonieren Sie schon oder sparen Sie noch? NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie From Susanne.Guth at gmx.net Tue Feb 7 02:11:24 2006 From: Susanne.Guth at gmx.net (Susanne Guth) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] New ODRL v2.0 Model References: <1138787411.7247.2.camel@iduna> Message-ID: <20364.1139238684@www007.gmx.net> Hi Alapan, all! > > On this point, I think your proposed model (my comments on that are on a > separate email) does fulfil the requirements. Great, so I assume there are no major objectitons to the new model layout. I will then describe a new draft of the ODRL v2 model and put it on the ODRL web site. A new round of "request for comments" will start from there. >2.) >>On page 2 you write "there is some mandatory information". Can you be >>more concrete on this. What exactly is really mandatory? Do we have a >>contract expert among us? I know that in Germany, for example, contracts >>are formless. What is your source for the information 2.1, 2.2, 2.3., .. >>can you refer to some business standards document? > As I wrote in a footnote earlier, the basis for my discussion in on > South African law, which in turn is based on common law and Roman-Dutch > law. I did rely on a law text book (ref 11) which is used to teach first > year contract law for the basics, but I do intend going over section 2 > with a law professor from my university once I get back next week. > Alapan, this is an important issue and comes up again and again. I myself tried to gather mandatory legal and business relevant attributes of contracts, without much success. lawyers kept on telling me, that there are no mandatory attributes or standard sets of attributes for contracts. Furthermore there are different attributes in different contract types (agreement for sale, marriage agreement, etc.) But maybe you have more luck than I do. Please share your new knowledge with us and maybe we can make a statement on the ODRL website on it. So long Susanne -- Susanne Guth susanne@odrl.net ODRL Initiative http://odrl.net/ Telefonieren Sie schon oder sparen Sie noch? NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie From vickyw at cs.cornell.edu Tue Feb 7 03:03:52 2006 From: vickyw at cs.cornell.edu (Vicky Weissman) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] RE: ODRL-Version2 Digest, Vol 13, Issue 3 Message-ID: <2EE48095D8C21643B0B70EC95F9BFBAFD85F8A@EXCHVS1.cs.cornell.edu> Hi All, For what it's worth, I agree with Susanne. I don't think the ODRL language should have two categories of actions, one for duties and one for permissions. As Susanne says, it limits the flexibility of our language. I agree with her that it doesn't seem to be the sort of thing we should be doing (are we going to restrict the language to prevent any statement that seems odd?). It also complicates the language. Finally, from a practical standpoint, I think finding an appropriate split would be very hard (maybe impossible). To see why, consider Alapan's motivating example: On 1 Feb 2006, at 01:43, Alapan Arnab wrote: > > But from purely an implementation point of view - if payment is an > action, wouldn't both the following code fragments be correct? > > > > 1 > > > > > > 1 > > Is it really true that it would *never* make sense to have the second statement? Suppose that a school is collecting donations for a charity; the school gives a prize to the student who collects the most money; and to prevent the prize from going to the kid with the richest parents, there's a rule that each donator is permitted to pay $1 (no more and, to minimize administration costs, no less). As another example, suppose a parent wants to give her child money and the child doesn't want it (maybe the child feels it makes him/her dependent, somehow less), so they work out an agreement that the parent can pay the child $100 dollars per month. I suspect that we can play these sorts of games for almost any action split anyone can think of. Best, Vicky From renato at odrl.net Tue Feb 7 16:36:16 2006 From: renato at odrl.net (Renato Iannella) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] RE: ODRL-Version2 Digest, Vol 13, Issue 3 In-Reply-To: <2EE48095D8C21643B0B70EC95F9BFBAFD85F8A@EXCHVS1.cs.cornell.edu> References: <2EE48095D8C21643B0B70EC95F9BFBAFD85F8A@EXCHVS1.cs.cornell.edu> Message-ID: <1348F8A5-3C00-4760-984D-4A1AEC377AA1@odrl.net> On 7 Feb 2006, at 02:03, Vicky Weissman wrote: >> >> >> 1 >> >> >> >> >> >> 1 >> >> > > Is it really true that it would *never* make sense to have the second > statement? If we looked at a use case that involves assigning rights to digital content ;-), then it does not make sense. Especially given the definition of Permissions: "The Permission entity indicates the actions that the Assignee/s is permitted to perform on the Target asset" I would have thought that by allowing more constraint use, then the semantics would be clearer ?? Cheers Renato Iannella ODRL Initiative http://odrl.net From vickyw at cs.cornell.edu Wed Feb 8 12:56:02 2006 From: vickyw at cs.cornell.edu (Vicky Weissman) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] RE: ODRL-Version2 Digest, Vol 13, Issue 5 Message-ID: <2EE48095D8C21643B0B70EC95F9BFBAFD85F96@EXCHVS1.cs.cornell.edu> On 7 Feb 2006, at 02:03, Vicky Weissman wrote: >> >> >> 1 >> >> >> >> >> >> 1 >> >> > > Is it really true that it would *never* make sense to have the second > statement? On 7 Feb 2006, Renato Iannella replied: >If we looked at a use case that involves assigning rights to digital content ;-), then it does not make sense. > >Especially given the definition of Permissions: >"The Permission entity indicates the actions that the Assignee/s is permitted to perform on the Target asset" I'm tempted to talk about targets that are online bank accounts (paying 1 EUR = depositing 1 EUR) or online customer accounts (paying = paying off debt). Actually, I'm more tempted to talk about targets that are avatars in massively multiplayer games. But, as long as we agree that splitting actions into 2 categories is probably not the way to go, then I guess I should rein in the creativity :-) On 7 Feb 2006, Renato Iannella Said: > I would have thought that by allowing more constraint use, then the semantics would be clearer ?? I don't understand this statement. Could you clarify? Thanks, Vicky From renato at odrl.net Wed Feb 8 17:29:43 2006 From: renato at odrl.net (Renato Iannella) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] RE: ODRL-Version2 Digest, Vol 13, Issue 5 In-Reply-To: <2EE48095D8C21643B0B70EC95F9BFBAFD85F96@EXCHVS1.cs.cornell.edu> References: <2EE48095D8C21643B0B70EC95F9BFBAFD85F96@EXCHVS1.cs.cornell.edu> Message-ID: <34856CA8-F389-4493-A614-C2DBCE7C95A1@odrl.net> On 8 Feb 2006, at 11:56, Vicky Weissman wrote: >> I would have thought that by allowing more constraint use, then the >> semantics would be clearer ?? > I don't understand this statement. Could you clarify? The question is: are all Permissions valid Duties (and vice-versa) ?? Cheers... Renato From aarnab at cs.uct.ac.za Wed Feb 8 19:11:50 2006 From: aarnab at cs.uct.ac.za (Alapan Arnab) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] RE: ODRL-Version2 Digest, Vol 13, Issue 3 In-Reply-To: <2EE48095D8C21643B0B70EC95F9BFBAFD85F8A@EXCHVS1.cs.cornell.edu> References: <2EE48095D8C21643B0B70EC95F9BFBAFD85F8A@EXCHVS1.cs.cornell.edu> Message-ID: <1139386310.7278.26.camel@iduna> Hi, I see and accept Vicky and Susanne's points on the matter of the action element. It makes sense - at least it was clarified ;) Alapan -- 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 aarnab at cs.uct.ac.za Fri Feb 10 01:59:24 2006 From: aarnab at cs.uct.ac.za (Alapan Arnab) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] Handling Prohibitions In-Reply-To: <2EE48095D8C21643B0B70EC95F9BFBAFD85F79@EXCHVS1.cs.cornell.edu> References: <2EE48095D8C21643B0B70EC95F9BFBAFD85F79@EXCHVS1.cs.cornell.edu> Message-ID: <1139497164.7275.22.camel@iduna> Hi, After rethinking on the issues discussed recently, I am wondering if there there is a need for prohibitions in the first place? The permissions in a license come from a finite set defined in a data dictionary. Ideally, the DRM controller should only enforce the permissions defined by their respective permission sets. Thus take a random permission, p, and a permission set PS. There can be four possibilities. p is an element of PS, and appears in the license: In this case, the permission is granted to the assignee p is an element of PS, and does not appear in the license: In this case, the permission is not granted to the assignee p is not an element of PS, and does not appear in the license: In this case, the DRM controller has no say on whether the permission is allowed or not. p is not an element of PS, and appears in the license: This creates an invalid license as the license is using terms that do not exist. If we look at the permissions in a license in this way, I do not see why a prohibition is necessary. Even a "all rights but" statement, is purely a contraction, and as Vicky suggested a tool to convert from a "all rights but" to a proper rights statement is a better approach. The one issue that remains is off course a change in permission sets - specifically if the permission set changes without a change in the namespace of the permission set. Changing namespaces once published should be discouraged, but I do not see a technical solution to this problem. Regards, Alapan On Tue, 2006-01-31 at 18:42 -0500, Vicky Weissman wrote: > Hi All, > > I've looked over the email discussions are prohibitions and, based on them, I > suggest we do the following: > > (1) Extend agreements to include prohibitions, where a prohibition says that > an action is forbidden if certain conditions hold. > > (2) Extend agreements to include a default, which is either permit or forbid. > > (3) Say that a set of agreements imply that a request (e.g., may Alice > download Season 1 of Lost) should be granted if (a) the agreements together > imply the request should be granted or (2) the agreements together do not > imply the request should be granted, do not imply the request should be > denied, and the default for all agreements is permit. > > Are there any objections? > > -Vicky > _______________________________________________ > ODRL-Version2 mailing list > ODRL-Version2@odrl.net > http://lists.odrl.net/mailman/listinfo/odrl-version2 -- 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 vickyw at cs.cornell.edu Fri Feb 10 04:51:17 2006 From: vickyw at cs.cornell.edu (Vicky Weissman) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] RE: ODRL-Version2 Digest, Vol 13, Issue 6 Message-ID: <2EE48095D8C21643B0B70EC95F9BFBAFD85FA9@EXCHVS1.cs.cornell.edu> The question is: are all Permissions valid Duties (and vice-versa) ?? According to the May 16 2005 draft of the model semantics, a Permission is a tuple (act, target, cons, dut), where act is an action, target is an asset, cons is a possibly empty set of constraints, and dut is a possibly empty set of duties. A Duty is either a tuple (act, obj, cons, rel) or a tuple (act, obj, cons), where act is an action, obj is either an asset or a list of names, cons is a possibly empty set of constraints, and rel is a Boolean flag indicating that the duty can be fulfilled at any time (and hence is no duty at all?). Given the definitions, I'm not sure any permission is a valid duty (or vice-versa). If we assume that a permission/duty can omit elements if they are the emptyset, then there's overlap (e.g., permissions of the form (act, target) are also duties). Nevertheless, every permission that includes a non-empty set of duties is not a duty. Every duty that includes the optional rel flag is not a permission. I'm pretty sure that I've misunderstood your question. .... Are you asking if there is an action that can appear as the first element of a permission and not as the first element of a duty (or vice-versa)? If so, then I guess the answer is that they're your definitions, so you can do whatever you want. But I don't see any reason why we would want to build such restrictions into ODRL. Moreover, having an action that can appear only in a duty seems a bit odd since it suggests an individual can be obligated to perform an action act on an object and cannot get (explicit) permission to do act. I get the feeling I'm missing the big picture. Would welcome a clue. Best, Vicky From vickyw at cs.cornell.edu Sat Feb 11 04:34:04 2006 From: vickyw at cs.cornell.edu (Vicky Weissman) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] Prohibitions - the saga continues... Message-ID: <2EE48095D8C21643B0B70EC95F9BFBAFD85FB0@EXCHVS1.cs.cornell.edu> After rethinking on the issues discussed recently, I am wondering if there there is a need for prohibitions in the first place? Most of the contracts (e.g., user agreements, leases) that I've read give permissions, prohibitions, and obligations. I figure that the people who drew up these documents were saying what they felt needed to be said. So I think it would be wise for ODRL to include such statements. >From a technical standpoint, if ODRL does not include prohibitions, then an ODRL agreement cannot distinguish between what is forbidden and what is unregulated. Whether this distinction is important depends on the intended uses for ODRL. For example, suppose that ODRL is designed solely for applications in which a user gets access by presenting an appropriate agreement, namely one that grants the permission. Then I'm not sure that the distinction is important. But, if we stray just a bit from this model, then I think we'll want prohibitions. To see why, consider the following example. Suppose that a database of clinical information is jointly owned by hospital H and research institute R. To get access, an individual needs to present agreements from both H and R that together imply the permission. Notice that we've stepped out of the model I gave in the last paragraph because it's not enough to present an agreement; you have to give agreements from both H and R. Now I think we want prohibitions because we want to detect conflicts between H and R (e.g., H permits an access that R forbids). In fact, I think my earlier suggestion is well-suited to this scenario. Recall the suggestion from my Jan 31 mail: > I suggest we do the following: > > (1) Extend agreements to include prohibitions, where a prohibition > says that an action is forbidden if certain conditions hold. > > (2) Extend agreements to include a default, which is either permit or forbid. > > (3) Say that a set of agreements imply that a request (e.g., may Alice > download Season 1 of Lost) should be granted if (a) the agreements > together imply the request should be granted or (2) the agreements > together do not imply the request should be granted, do not imply the > request should be denied, and the default for all agreements is permit. This approach allows H and R to write agreements that (a) give the conditions under which access should be permitted and (b) give the conditions under which access should be denied. So we can detect if H and R disagree on certain cases, thereby giving them a chance to resolve the dispute. In addition (3) allows H/R to give the default "forbid" so that, if neither explicitly permits the action, then it's forbidden. What's missing from my suggestion is support for statements such as "if H doesn't explicit give permission, then H forbids". We could extend agreements to include such statements, but I think it would be better to make changes at a higher level; that is, instead of requiring that H and R's agreements together imply permission, the application could require that H's agreement(s) implies permission and R's agreement(s) implies permission. Having the change at this level keeps agreements fairly simple and allows for more flexibility when combining agreements. For example, the application could support voting (e.g., if most of the interested parties grant permission, then permission is granted). In general, I think my suggestion is a good way to handle permissions based on multiple agreements. It also works just fine for the simpler case in which any agreement will suffice (in which case the user presents only the agreement that is most favorable to her, or the application considers the set of presented agreements one-by-one). -Vicky From aarnab at cs.uct.ac.za Mon Feb 13 19:21:07 2006 From: aarnab at cs.uct.ac.za (Alapan Arnab) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] Prohibitions - the saga continues... In-Reply-To: <2EE48095D8C21643B0B70EC95F9BFBAFD85FB0@EXCHVS1.cs.cornell.edu> References: <2EE48095D8C21643B0B70EC95F9BFBAFD85FB0@EXCHVS1.cs.cornell.edu> Message-ID: <1139818867.7274.0.camel@iduna> Hi, I don't think prohibitions are necessary at all to handle the scenario you posted. I will try to give a logical proof why (I have ignored invalid licenses): Notation: E -> element of H -> license agreement from Hospital R -> license agreement from Research Institute HPS-> hospital license permission set RPS-> research institute permission set x -> the permission in question pH -> permission granted by DRM controller (Hospital) pR -> permission granted by DRM controller (RI) pJ -> permission granted by DRM controller (joint data) & -> and ! -> not Rules: 1. x E HPS & x E H -> pH 2. x !E HPS & x !E H -> pH 3. x E HPS & x E H -> !pH 4. x E RPS & x E R -> pR 5. x !E RPS & x !E R -> pR 6. x E RPS & x E R -> !pR 7. pR & pH -> pJ >From the above, it is clear, that [7] is satisfied iff ([1] | [2]) & ([4] | [5]). The situation you describe is correctly handled. I agree that explicit forbid is not handled, but that can be easily handled by how x !E RPS is handled (i.e. forbid everything except what is explicitly permitted). But in my opinion, this is a wrong approach, and if the license holders need to control a right, that right should be in the permission set. Alapan On Fri, 2006-02-10 at 12:34 -0500, Vicky Weissman wrote: > > After rethinking on the issues discussed recently, I am wondering if there > there is a need for prohibitions in the first place? > > > Most of the contracts (e.g., user agreements, leases) that I've read give > permissions, prohibitions, and obligations. I figure that the people who > drew up these documents were saying what they felt needed to be said. So I > think it would be wise for ODRL to include such statements. > > >From a technical standpoint, if ODRL does not include prohibitions, then an > ODRL agreement cannot distinguish between what is forbidden and what is > unregulated. Whether this distinction is important depends on the intended > uses for ODRL. For example, suppose that ODRL is designed solely for > applications in which a user gets access by presenting an appropriate > agreement, namely one that grants the permission. Then I'm not sure that the > distinction is important. But, if we stray just a bit from this model, then > I think we'll want prohibitions. To see why, consider the following example. > > > Suppose that a database of clinical information is jointly owned by hospital > H and research institute R. To get access, an individual needs to present > agreements from both H and R that together imply the permission. Notice that > we've stepped out of the model I gave in the last paragraph because it's not > enough to present an agreement; you have to give agreements from both H and > R. Now I think we want prohibitions because we want to detect conflicts > between H and R (e.g., H permits an access that R forbids). In fact, I think > my earlier suggestion is well-suited to this scenario. Recall the suggestion > from my Jan 31 mail: > > > I suggest we do the following: > > > > (1) Extend agreements to include prohibitions, where a prohibition > > says that an action is forbidden if certain conditions hold. > > > > (2) Extend agreements to include a default, which is either permit or > forbid. > > > > (3) Say that a set of agreements imply that a request (e.g., may Alice > > download Season 1 of Lost) should be granted if (a) the agreements > > together imply the request should be granted or (2) the agreements > > together do not imply the request should be granted, do not imply the > > request should be denied, and the default for all agreements is permit. > > This approach allows H and R to write agreements that (a) give the conditions > under which access should be permitted and (b) give the conditions under > which access should be denied. So we can detect if H and R disagree on > certain cases, thereby giving them a chance to resolve the dispute. In > addition (3) allows H/R to give the default "forbid" so that, if neither > explicitly permits the action, then it's forbidden. > > What's missing from my suggestion is support for statements such as "if H > doesn't explicit give permission, then H forbids". We could extend > agreements to include such statements, but I think it would be better to make > changes at a higher level; that is, instead of requiring that H and R's > agreements together imply permission, the application could require that H's > agreement(s) implies permission and R's agreement(s) implies permission. > Having the change at this level keeps agreements fairly simple and allows for > more flexibility when combining agreements. For example, the application > could support voting (e.g., if most of the interested parties grant > permission, then permission is granted). > > In general, I think my suggestion is a good way to handle permissions based > on multiple agreements. It also works just fine for the simpler case in > which any agreement will suffice (in which case the user presents only the > agreement that is most favorable to her, or the application considers the set > of presented agreements one-by-one). > > -Vicky > > > > > > _______________________________________________ > ODRL-Version2 mailing list > ODRL-Version2@odrl.net > http://lists.odrl.net/mailman/listinfo/odrl-version2 -- 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 vickyw at cs.cornell.edu Tue Feb 14 14:12:47 2006 From: vickyw at cs.cornell.edu (Vicky Weissman) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] Prohibitions - the saga continues...Reply to Alapan Message-ID: <2EE48095D8C21643B0B70EC95F9BFBAFD85FB2@EXCHVS1.cs.cornell.edu> Hi , On Feb 10, Vicky Weissman said: ------------------------------- ... Suppose that a database of clinical information is jointly owned by hospital H and research institute R. To get access, an individual needs to present agreements from both H and R that together imply the permission... Now I think we want prohibitions because we want to detect conflicts between H and R (e.g., H permits an access that R forbids). On Feb 13, Alapan Arnab replied: -------------------------------- I don't think prohibitions are necessary at all to handle the scenario you posted. I will try to give a logical proof why (I have ignored invalid licenses): Notation: E -> element of H -> license agreement from Hospital R -> license agreement from Research Institute HPS-> hospital license permission set RPS-> research institute permission set x -> the permission in question pH -> permission granted by DRM controller (Hospital) pR -> permission granted by DRM controller (RI) pJ -> permission granted by DRM controller (joint data) & -> and ! -> not Rules: 1. x E HPS & x E H -> pH 2. x !E HPS & x !E H -> pH 3. x E HPS & x E H -> !pH 4. x E RPS & x E R -> pR 5. x !E RPS & x !E R -> pR 6. x E RPS & x E R -> !pR 7. pR & pH -> pJ >From the above, it is clear, that [7] is satisfied iff ([1] | [2]) & ([4] | [5]). Vicky Weissman, replying: --------------------------- I don't understand your notation. In particular, I don't see why rule 1 doesn't contradict rule 3 (and, similarly, why rule 4 doesn't contradict rule 6). My best guess is that, for each DRM controller, you're maintaining two sets of information. A permission is granted if it is in the controller's permission set and in the agreement; a permission is denied if it is in the controller's permission set and not in the agreement; and it is unregulated if it is not in the permission set nor in the agreement. If this is the case, then you're essentially capturing prohibitions explicitly (as the difference between 2 sets), and you might as well do it in the standard way; that is, with permissions and prohibitions, instead of with permissions and a superset of regulated actions. Regardless of your specific work-around, I do think that, for the example I gave, we want to distinguish forbidden actions from unregulated ones. (Having both permissions and prohibitions is, I believe, the most common way to do this.) To clarify my thinking, suppose that Alice wants to access the clinical database directly and, to get access, she presents an agreement agr_H from the hospital that says "Alice may query the database" and she presents an agreement agr_R from the research institute that says "Alice may access the database directly". Should Alice be given access? If ODRL includes prohibitions, then agr_H does not object to Alice accessing the database and, as a result, I think the request should be granted. If ODRL does not include prohibitions, then we can't tell whether the hospital does not object, in which case access should be granted, or the hospital forbids the action, in which case H and R contradict one another and some "default" action should be done (e.g., contact H and R so they can work out the disagreement, or give Alice access to a perturbed version of the database). -Vicky From renato at odrl.net Tue Feb 14 18:14:15 2006 From: renato at odrl.net (Renato Iannella) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] Prohibitions - the saga continues... In-Reply-To: <2EE48095D8C21643B0B70EC95F9BFBAFD85FB0@EXCHVS1.cs.cornell.edu> References: <2EE48095D8C21643B0B70EC95F9BFBAFD85FB0@EXCHVS1.cs.cornell.edu> Message-ID: <852592CE-E5E1-4101-AFB3-08E597B7CFBF@odrl.net> On 11 Feb 2006, at 03:34, Vicky Weissman wrote: > Most of the contracts (e.g., user agreements, leases) that I've > read give > permissions, prohibitions, and obligations. I figure that the > people who > drew up these documents were saying what they felt needed to be > said. So I > think it would be wise for ODRL to include such statements. Correct - these are the real user-requirements for the enhancements for V2.0 We need to explicit support Prohibitions in the model... Cheers Renato Iannella ODRL Initiative http://odrl.net From renato at odrl.net Tue Feb 14 18:21:20 2006 From: renato at odrl.net (Renato Iannella) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] RE: ODRL-Version2 Digest, Vol 13, Issue 6 In-Reply-To: <2EE48095D8C21643B0B70EC95F9BFBAFD85FA9@EXCHVS1.cs.cornell.edu> References: <2EE48095D8C21643B0B70EC95F9BFBAFD85FA9@EXCHVS1.cs.cornell.edu> Message-ID: On 10 Feb 2006, at 03:51, Vicky Weissman wrote: > I'm pretty sure that I've misunderstood your question. .... Are > you asking > if there is an action that can appear as the first element of a > permission > and not as the first element of a duty (or vice-versa)? If so, > then I guess > the answer is that they're your definitions, so you can do whatever > you want. > But I don't see any reason why we would want to build such > restrictions into > ODRL. Nope...I'm just trying to see if there is a logical need to enable communities (ie, those that build ODRL Profiles) to support stating that Actions A,B,C are permissions and Actions C,D,E are Duties. Cheers Renato Iannella ODRL Initiative http://odrl.net From aarnab at cs.uct.ac.za Tue Feb 14 19:46:37 2006 From: aarnab at cs.uct.ac.za (Alapan Arnab) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] Prohibitions - the saga continues...Reply to Alapan In-Reply-To: <2EE48095D8C21643B0B70EC95F9BFBAFD85FB2@EXCHVS1.cs.cornell.edu> References: <2EE48095D8C21643B0B70EC95F9BFBAFD85FB2@EXCHVS1.cs.cornell.edu> Message-ID: <1139906797.7476.15.camel@iduna> Hi, Sorry - I should have reread my email carefully .... copy and paste always goes wrong. [3] should have read x E HPS & x !E H -> !pH Anyway, the idea I am trying to get to: The actions that need to be controlled (in any way) must be controlled through a pre-defined set of permissions (permission set) (in ODRL 1.1, the standard data dictionary was the standard permission set). For example, for a music store, the permission set could be : [open, play, remix, read]. Thus, the music store _chooses_ to control only those permissions. Thus a license using that permission set can only control those permissions. In such a license, the permission to "watch" has no meaning and can be seen to be unregulated. The DRM controller in such a case should allow that action (although it has no real meaning). Now suppose you have two different licenses using different permission sets that cover a common data file. The DRM controller can be setup to only allow an action if both licenses allow that action. Thus, the only times an action would be allowed is: 1) the action is unregulated by both licenses 2) the action is regulated and allowed by both licenses My question is - given that the permission set is always finite, can there be a scenario where a prohibition is explicitly required? Regards Alapan On Mon, 2006-02-13 at 22:12 -0500, Vicky Weissman wrote: > Hi , > > On Feb 10, Vicky Weissman said: > ------------------------------- > ... Suppose that a database of clinical information is jointly owned by > hospital H and research institute R. To get access, an individual needs to > present agreements from both H and R that together imply the permission... > Now I think we want prohibitions because we want to detect conflicts between > H and R (e.g., H permits an access that R forbids). > > On Feb 13, Alapan Arnab replied: > -------------------------------- > I don't think prohibitions are necessary at all to handle the scenario you > posted. I will try to give a logical proof why (I have ignored invalid > licenses): > > Notation: > E -> element of > H -> license agreement from Hospital > R -> license agreement from Research Institute > HPS-> hospital license permission set > RPS-> research institute permission set > x -> the permission in question > pH -> permission granted by DRM controller (Hospital) pR -> permission > granted by DRM controller (RI) pJ -> permission granted by DRM controller > (joint data) > > & -> and > ! -> not > > Rules: > 1. x E HPS & x E H -> pH > 2. x !E HPS & x !E H -> pH > 3. x E HPS & x E H -> !pH > > 4. x E RPS & x E R -> pR > 5. x !E RPS & x !E R -> pR > 6. x E RPS & x E R -> !pR > > 7. pR & pH -> pJ > > >From the above, it is clear, that [7] is satisfied iff ([1] | [2]) & ([4] | > [5]). > > Vicky Weissman, replying: > --------------------------- > I don't understand your notation. In particular, I don't see why rule 1 > doesn't contradict rule 3 (and, similarly, why rule 4 doesn't contradict rule > 6). My best guess is that, for each DRM controller, you're maintaining two > sets of information. A permission is granted if it is in the controller's > permission set and in the agreement; a permission is denied if it is in the > controller's permission set and not in the agreement; and it is unregulated > if it is not in the permission set nor in the agreement. If this is the > case, then you're essentially capturing prohibitions explicitly (as the > difference between 2 sets), and you might as well do it in the standard way; > that is, with permissions and prohibitions, instead of with permissions and a > superset of regulated actions. > > Regardless of your specific work-around, I do think that, for the example I > gave, we want to distinguish forbidden actions from unregulated ones. > (Having both permissions and prohibitions is, I believe, the most common way > to do this.) To clarify my thinking, suppose that Alice wants to access the > clinical database directly and, to get access, she presents an agreement > agr_H from the hospital that says "Alice may query the database" and she > presents an agreement agr_R from the research institute that says "Alice may > access the database directly". Should Alice be given access? If ODRL > includes prohibitions, then agr_H does not object to Alice accessing the > database and, as a result, I think the request should be granted. If ODRL > does not include prohibitions, then we can't tell whether the hospital does > not object, in which case access should be granted, or the hospital forbids > the action, in which case H and R contradict one another and some "default" > action should be done (e.g., contact H and R so they can work out the > disagreement, or give Alice access to a perturbed version of the database). > > -Vicky > > > > > > > > _______________________________________________ > ODRL-Version2 mailing list > ODRL-Version2@odrl.net > http://lists.odrl.net/mailman/listinfo/odrl-version2 -- 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 aarnab at cs.uct.ac.za Thu Feb 23 00:47:46 2006 From: aarnab at cs.uct.ac.za (Alapan Arnab) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] resumption of containers & model update In-Reply-To: <5860.1138581121@www082.gmx.net> References: <5860.1138581121@www082.gmx.net> Message-ID: <1140616066.13777.2.camel@iduna> Hi Susanne, everyone else I am still working on the contracts issue - semester just started, so academic staff are a little hard to get hold of. A question on the model posted - I see the absence of the "statement"/"ticket" etc. Is this feature removed? Or is this incorporated in the type attribute? If its the later, I have a slight problem (not only with the implications for negotiations) - but for standard usage also, as it will limit the comparability of different licenses. For example, it would not be possible to offer a ticket and a contract on the same digital object as their offers would look the same (i think ...) If it's the former .. I have no problem with it ;) Regards Alapan On Mon, 2006-01-30 at 01:32 +0100, Susanne Guth wrote: > Hi everybody, > > as you can see from my various emails this was an ODRL weekend for me :) > > >From reading through the discussions I found the following: > > 1.) we need containers > 2.) we need prohibitions > 3.) we need contractual details and negotition elements > 4.) the model has simplification potential > > I worked a little bit on the model that you can see attached. This is - of > course - only a draft and no new v2 model. > > 1.) Containers > > I added a container element which is not properly related to the other > elements. Container have the attributes > > BIND containing e.g. OR, AND > TYPE containing e.g. "Container of Constraints" > RELATEDTO containing the element that includes the container. > > I think that we would have to carefully describe in our semantics what each > container type means, so that we provide a chance to implement the language. > > Container Example > > > 20 > > > > > > 31-12-2004 > > > > > > > > > > 2.) > > I kept prohibitions as they were. However, this issue need further > discussion. The important question is if we can formalise the model with > prohibitions in it... vicky I count on you here :) > > 3.) > > I added the negotiation and communication elements. Details (attributes must > be discussed. > > 4.) > > What do you guys think of removing the rights-expression-type level and > instead using an attribute "TYPE" in rights to specify the semantics of the > actual rights expression? > > I have a problem with different hierarchies of RE elements, like in alapans > approach - simply for negotiation. If somebody wants to use ODRL without the > negotiation part, then the hierarchies do not make sense at all. An aim > should really be to keep the negotiation part independent of the remaining > model. > > If a RE grants next rights, for example, then these nextrights have to be > defined in a new rights expressed. RE ids would have to link the various > rights expressions. This would have the advantage that a "nextRight" could > more easily become part of a new agreement (I think). > > Comments? > > -- > Susanne Guth > susanne@odrl.net > ODRL Initiative > http://odrl.net/ > > DSL-Aktion wegen groer Nachfrage bis 28.2.2006 verlngert: > GMX DSL-Flatrate 1 Jahr kostenlos* http://www.gmx.net/de/go/dsl > _______________________________________________ ODRL-Version2 mailing list ODRL-Version2@odrl.net http://lists.odrl.net/mailman/listinfo/odrl-version2 -- 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 Susanne.Guth at gmx.net Thu Feb 23 08:00:11 2006 From: Susanne.Guth at gmx.net (Susanne Guth) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] resumption of containers & model update References: <1140616066.13777.2.camel@iduna> Message-ID: <18339.1140642011@www032.gmx.net> Hi Alapan, its the latter, but I don't understand the concerns you have. Please reformulate what you think the problem is. Thanks Susanne > > Hi Susanne, everyone else > I am still working on the contracts issue - semester just started, so > academic staff are a little hard to get hold of. > > A question on the model posted - I see the absence of the > "statement"/"ticket" etc. Is this feature removed? Or is this > incorporated in the type attribute? > > If its the later, I have a slight problem (not only with the > implications for negotiations) - but for standard usage also, as it will > limit the comparability of different licenses. For example, it would not > be possible to offer a ticket and a contract on the same digital object > as their offers would look the same (i think ...) > > If it's the former .. I have no problem with it ;) > > Regards > Alapan > On Mon, 2006-01-30 at 01:32 +0100, Susanne Guth wrote: > > Hi everybody, > > > > as you can see from my various emails this was an ODRL weekend for me :) > > > > >From reading through the discussions I found the following: > > > > 1.) we need containers > > 2.) we need prohibitions > > 3.) we need contractual details and negotition elements > > 4.) the model has simplification potential > > > > I worked a little bit on the model that you can see attached. This is - > of > > course - only a draft and no new v2 model. > > > > 1.) Containers > > > > I added a container element which is not properly related to the other > > elements. Container have the attributes > > > > BIND containing e.g. OR, AND > > TYPE containing e.g. "Container of Constraints" > > RELATEDTO containing the element that includes the container. > > > > I think that we would have to carefully describe in our semantics what > each > > container type means, so that we provide a chance to implement the > language. > > > > Container Example > > > > > > 20 > > > > > > > > > > > > 31-12-2004 > > > > > > > > > > > > > > > > > > > > 2.) > > > > I kept prohibitions as they were. However, this issue need further > > discussion. The important question is if we can formalise the model with > > prohibitions in it... vicky I count on you here :) > > > > 3.) > > > > I added the negotiation and communication elements. Details (attributes > must > > be discussed. > > > > 4.) > > > > What do you guys think of removing the rights-expression-type level and > > instead using an attribute "TYPE" in rights to specify the semantics of > the > > actual rights expression? > > > > I have a problem with different hierarchies of RE elements, like in > alapans > > approach - simply for negotiation. If somebody wants to use ODRL without > the > > negotiation part, then the hierarchies do not make sense at all. An aim > > should really be to keep the negotiation part independent of the > remaining > > model. > > > > If a RE grants next rights, for example, then these nextrights have to > be > > defined in a new rights expressed. RE ids would have to link the various > > rights expressions. This would have the advantage that a "nextRight" > could > > more easily become part of a new agreement (I think). > > > > Comments? > > > > -- > > Susanne Guth > > susanne@odrl.net > > ODRL Initiative > > http://odrl.net/ > > > > DSL-Aktion wegen groer Nachfrage bis 28.2.2006 verlngert: > > GMX DSL-Flatrate 1 Jahr kostenlos* http://www.gmx.net/de/go/dsl > > _______________________________________________ ODRL-Version2 mailing > list ODRL-Version2@odrl.net > http://lists.odrl.net/mailman/listinfo/odrl-version2 > -- > 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 > > _______________________________________________ > 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/ Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner From aarnab at cs.uct.ac.za Sat Feb 25 01:28:26 2006 From: aarnab at cs.uct.ac.za (Alapan Arnab) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] resumption of containers & model update In-Reply-To: <18339.1140642011@www032.gmx.net> References: <1140616066.13777.2.camel@iduna> <18339.1140642011@www032.gmx.net> Message-ID: <1140791306.7299.25.camel@iduna> Hi Susanne, On the legal issues - I will have an answer for you hopefully on Monday, latest Tuesday. On the type issue: Lets say you have a music file "Hello World" and as the rights holder you would like to offer two types of licences: 1) A short-time limited license (one day) that does not restrict usage to any particular person, which costs 20 Euro cents 2) A person limited license, which restricts who can use the music file, but does not impose any time limit, which costs 1 Euro. In ODRLL v2.0, (1) is catered for by a Ticket and (2) is catered for by a contract. Now, when the user goes to acquire this license, the license server will first present the two offers, (1) and (2) and the user can then select which one (s)he likes, and proceed. In this case, it would be nice to reflect, in the offers themselves, that (1) is a ticket, and (2) is a contract. There in no real need to create an additional element, it could be all handled as an extra attribute. On another note - I was looking at the DMP negotiations call - and I am considering submitting the ODRL negotiations approach. One of the requirements is "setting a parameter as non-negotiable", which would require the creation of an additional attribute for every negotiable element. Alapan On Wed, 2006-02-22 at 22:00 +0100, Susanne Guth wrote: > Hi Alapan, > > its the latter, but I don't understand the concerns you have. Please > reformulate what you think the problem is. Thanks > > Susanne > > > > > Hi Susanne, everyone else > > I am still working on the contracts issue - semester just started, so > > academic staff are a little hard to get hold of. > > > > A question on the model posted - I see the absence of the > > "statement"/"ticket" etc. Is this feature removed? Or is this > > incorporated in the type attribute? > > > > If its the later, I have a slight problem (not only with the > > implications for negotiations) - but for standard usage also, as it will > > limit the comparability of different licenses. For example, it would not > > be possible to offer a ticket and a contract on the same digital object > > as their offers would look the same (i think ...) > > > > If it's the former .. I have no problem with it ;) > > > > Regards > > Alapan > > On Mon, 2006-01-30 at 01:32 +0100, Susanne Guth wrote: > > > Hi everybody, > > > > > > as you can see from my various emails this was an ODRL weekend for me :) > > > > > > >From reading through the discussions I found the following: > > > > > > 1.) we need containers > > > 2.) we need prohibitions > > > 3.) we need contractual details and negotition elements > > > 4.) the model has simplification potential > > > > > > I worked a little bit on the model that you can see attached. This is - > > of > > > course - only a draft and no new v2 model. > > > > > > 1.) Containers > > > > > > I added a container element which is not properly related to the other > > > elements. Container have the attributes > > > > > > BIND containing e.g. OR, AND > > > TYPE containing e.g. "Container of Constraints" > > > RELATEDTO containing the element that includes the container. > > > > > > I think that we would have to carefully describe in our semantics what > > each > > > container type means, so that we provide a chance to implement the > > language. > > > > > > Container Example > > > > > > > > > 20 > > > > > > > > > > > > > > > > > > 31-12-2004 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2.) > > > > > > I kept prohibitions as they were. However, this issue need further > > > discussion. The important question is if we can formalise the model with > > > prohibitions in it... vicky I count on you here :) > > > > > > 3.) > > > > > > I added the negotiation and communication elements. Details (attributes > > must > > > be discussed. > > > > > > 4.) > > > > > > What do you guys think of removing the rights-expression-type level and > > > instead using an attribute "TYPE" in rights to specify the semantics of > > the > > > actual rights expression? > > > > > > I have a problem with different hierarchies of RE elements, like in > > alapans > > > approach - simply for negotiation. If somebody wants to use ODRL without > > the > > > negotiation part, then the hierarchies do not make sense at all. An aim > > > should really be to keep the negotiation part independent of the > > remaining > > > model. > > > > > > If a RE grants next rights, for example, then these nextrights have to > > be > > > defined in a new rights expressed. RE ids would have to link the various > > > rights expressions. This would have the advantage that a "nextRight" > > could > > > more easily become part of a new agreement (I think). > > > > > > Comments? > > > > > > -- > > > Susanne Guth > > > susanne@odrl.net > > > ODRL Initiative > > > http://odrl.net/ > > > > > > DSL-Aktion wegen groer Nachfrage bis 28.2.2006 verlngert: > > > GMX DSL-Flatrate 1 Jahr kostenlos* http://www.gmx.net/de/go/dsl > > > _______________________________________________ ODRL-Version2 mailing > > list ODRL-Version2@odrl.net > > http://lists.odrl.net/mailman/listinfo/odrl-version2 > > -- > > 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 > > > > _______________________________________________ > > ODRL-Version2 mailing list > > ODRL-Version2@odrl.net > > http://lists.odrl.net/mailman/listinfo/odrl-version2 > > > -- 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 Susanne.Guth at gmx.net Sat Feb 25 03:53:16 2006 From: Susanne.Guth at gmx.net (Susanne Guth) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] resumption of containers & model update References: <1140791306.7299.25.camel@iduna> Message-ID: <7433.1140799996@www056.gmx.net> Hi Alapan, I think there is a logic tongh twister in your example. You can not negotiate if you would like agree to a "ticket" or a "contract". A ticket results from a contract. And an offer can only result by the confirmation of an agreement. The field "rights expression type" only describes what the rights expression represents. OK? Are all your concerns cleared? > On another note - I was looking at the DMP negotiations call - and I am > considering submitting the ODRL negotiations approach. One of the > requirements is "setting a parameter as non-negotiable", which would > require the creation of an additional attribute for every negotiable > element. I think it's a good idea to indicate negotional elements. So what are the candidates for this element: Permissions, Duties, Prohibitions and Contstraints. Or shall we go down to the Action- Element Level= Actions & constraints? Discussion opened.. susanne > > Hi Susanne, > On the legal issues - I will have an answer for you hopefully on Monday, > latest Tuesday. > > On the type issue: > Lets say you have a music file "Hello World" and as the rights holder > you would like to offer two types of licences: > 1) A short-time limited license (one day) that does not restrict usage > to any particular person, which costs 20 Euro cents > 2) A person limited license, which restricts who can use the music file, > but does not impose any time limit, which costs 1 Euro. > > In ODRLL v2.0, (1) is catered for by a Ticket and (2) is catered for by > a contract. > > Now, when the user goes to acquire this license, the license server will > first present the two offers, (1) and (2) and the user can then select > which one (s)he likes, and proceed. > > In this case, it would be nice to reflect, in the offers themselves, > that (1) is a ticket, and (2) is a contract. > > There in no real need to create an additional element, it could be all > handled as an extra attribute. > > On another note - I was looking at the DMP negotiations call - and I am > considering submitting the ODRL negotiations approach. One of the > requirements is "setting a parameter as non-negotiable", which would > require the creation of an additional attribute for every negotiable > element. > > Alapan > On Wed, 2006-02-22 at 22:00 +0100, Susanne Guth wrote: > > Hi Alapan, > > > > its the latter, but I don't understand the concerns you have. Please > > reformulate what you think the problem is. Thanks > > > > Susanne > > > > > > > > Hi Susanne, everyone else > > > I am still working on the contracts issue - semester just started, so > > > academic staff are a little hard to get hold of. > > > > > > A question on the model posted - I see the absence of the > > > "statement"/"ticket" etc. Is this feature removed? Or is this > > > incorporated in the type attribute? > > > > > > If its the later, I have a slight problem (not only with the > > > implications for negotiations) - but for standard usage also, as it > will > > > limit the comparability of different licenses. For example, it would > not > > > be possible to offer a ticket and a contract on the same digital > object > > > as their offers would look the same (i think ...) > > > > > > If it's the former .. I have no problem with it ;) > > > > > > Regards > > > Alapan > > > On Mon, 2006-01-30 at 01:32 +0100, Susanne Guth wrote: > > > > Hi everybody, > > > > > > > > as you can see from my various emails this was an ODRL weekend for > me :) > > > > > > > > >From reading through the discussions I found the following: > > > > > > > > 1.) we need containers > > > > 2.) we need prohibitions > > > > 3.) we need contractual details and negotition elements > > > > 4.) the model has simplification potential > > > > > > > > I worked a little bit on the model that you can see attached. This > is - > > > of > > > > course - only a draft and no new v2 model. > > > > > > > > 1.) Containers > > > > > > > > I added a container element which is not properly related to the > other > > > > elements. Container have the attributes > > > > > > > > BIND containing e.g. OR, AND > > > > TYPE containing e.g. "Container of Constraints" > > > > RELATEDTO containing the element that includes the container. > > > > > > > > I think that we would have to carefully describe in our semantics > what > > > each > > > > container type means, so that we provide a chance to implement the > > > language. > > > > > > > > Container Example > > > > > > > > > > > > 20 > > > > > > > > > > > > > > > > > > > > > > > > 31-12-2004 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2.) > > > > > > > > I kept prohibitions as they were. However, this issue need further > > > > discussion. The important question is if we can formalise the model > with > > > > prohibitions in it... vicky I count on you here :) > > > > > > > > 3.) > > > > > > > > I added the negotiation and communication elements. Details > (attributes > > > must > > > > be discussed. > > > > > > > > 4.) > > > > > > > > What do you guys think of removing the rights-expression-type level > and > > > > instead using an attribute "TYPE" in rights to specify the semantics > of > > > the > > > > actual rights expression? > > > > > > > > I have a problem with different hierarchies of RE elements, like in > > > alapans > > > > approach - simply for negotiation. If somebody wants to use ODRL > without > > > the > > > > negotiation part, then the hierarchies do not make sense at all. An > aim > > > > should really be to keep the negotiation part independent of the > > > remaining > > > > model. > > > > > > > > If a RE grants next rights, for example, then these nextrights have > to > > > be > > > > defined in a new rights expressed. RE ids would have to link the > various > > > > rights expressions. This would have the advantage that a "nextRight" > > > could > > > > more easily become part of a new agreement (I think). > > > > > > > > Comments? > > > > > > > > -- > > > > Susanne Guth > > > > susanne@odrl.net > > > > ODRL Initiative > > > > http://odrl.net/ > > > > > > > > DSL-Aktion wegen groer Nachfrage bis 28.2.2006 verlngert: > > > > GMX DSL-Flatrate 1 Jahr kostenlos* http://www.gmx.net/de/go/dsl > > > > _______________________________________________ ODRL-Version2 > mailing > > > list ODRL-Version2@odrl.net > > > http://lists.odrl.net/mailman/listinfo/odrl-version2 > > > -- > > > 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 > > > > > > _______________________________________________ > > > ODRL-Version2 mailing list > > > ODRL-Version2@odrl.net > > > http://lists.odrl.net/mailman/listinfo/odrl-version2 > > > > > > -- > 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 > -- Susanne Guth susanne@odrl.net ODRL Initiative http://odrl.net/ Telefonieren Sie schon oder sparen Sie noch? NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie From renato at odrl.net Mon Feb 27 10:57:45 2006 From: renato at odrl.net (Renato Iannella) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] DMP Submission In-Reply-To: <1140791306.7299.25.camel@iduna> References: <1140616066.13777.2.camel@iduna> <18339.1140642011@www032.gmx.net> <1140791306.7299.25.camel@iduna> Message-ID: <79630458-1097-4DCF-91AF-6723CAF6F72B@odrl.net> On 25 Feb 2006, at 00:28, Alapan Arnab wrote: > On another note - I was looking at the DMP negotiations call - and > I am > considering submitting the ODRL negotiations approach. Speaking of the DMP, they have a call for proposals at the moment (due 27 march) Are they any volunteers to help propose ODRL as one of the technologies? Cheers Renato Iannella From aarnab at cs.uct.ac.za Mon Feb 27 19:11:16 2006 From: aarnab at cs.uct.ac.za (Alapan Arnab) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] DMP Submission In-Reply-To: <79630458-1097-4DCF-91AF-6723CAF6F72B@odrl.net> References: <1140616066.13777.2.camel@iduna> <18339.1140642011@www032.gmx.net> <1140791306.7299.25.camel@iduna> <79630458-1097-4DCF-91AF-6723CAF6F72B@odrl.net> Message-ID: <1141027877.860.0.camel@iduna> Hi Renato, Maybe I can help out on both - as the negotiations use ODRL ... but I am not too sure of the format etc. maybe you can start it off ... Alapan On Mon, 2006-02-27 at 09:57 +1000, Renato Iannella wrote: > On 25 Feb 2006, at 00:28, Alapan Arnab wrote: > > > On another note - I was looking at the DMP negotiations call - and > > I am > > considering submitting the ODRL negotiations approach. > > Speaking of the DMP, they have a call for proposals at the moment > (due 27 march) > > > > Are they any volunteers to help propose ODRL as one of the technologies? > > Cheers > > Renato Iannella > _______________________________________________ > ODRL-Version2 mailing list > ODRL-Version2@odrl.net > http://lists.odrl.net/mailman/listinfo/odrl-version2 -- 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 aarnab at cs.uct.ac.za Mon Feb 27 20:18:19 2006 From: aarnab at cs.uct.ac.za (Alapan Arnab) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] resumption of containers & model update In-Reply-To: <7433.1140799996@www056.gmx.net> References: <1140791306.7299.25.camel@iduna> <7433.1140799996@www056.gmx.net> Message-ID: <1141031899.859.14.camel@iduna> On Fri, 2006-02-24 at 17:53 +0100, Susanne Guth wrote: > Hi Alapan, > > I think there is a logic tongh twister in your example. You can not > negotiate if you would like agree to a "ticket" or a "contract". A ticket > results from a contract. And an offer can only result by the confirmation of > an agreement. The field "rights expression type" only describes what the > rights expression represents. OK? Are all your concerns cleared? > This is truly a twister ;) Well the point is - when presenting an offer, shouldn't there be an indication of what type of contracts are on offer? > > On another note - I was looking at the DMP negotiations call - and I am > > considering submitting the ODRL negotiations approach. One of the > > requirements is "setting a parameter as non-negotiable", which would > > require the creation of an additional attribute for every negotiable > > element. > > I think it's a good idea to indicate negotional elements. So what are the > candidates for this element: Permissions, Duties, Prohibitions and > Contstraints. Or shall we go down to the Action- Element Level= Actions & > constraints? > Down to the lower levels - as I think the constraints themselves are the most useful element of negotiations (e.g. 5 pages instead of 1 page limit on printing). > Discussion opened.. > > susanne > > > > > Hi Susanne, > > On the legal issues - I will have an answer for you hopefully on Monday, > > latest Tuesday. > > > > On the type issue: > > Lets say you have a music file "Hello World" and as the rights holder > > you would like to offer two types of licences: > > 1) A short-time limited license (one day) that does not restrict usage > > to any particular person, which costs 20 Euro cents > > 2) A person limited license, which restricts who can use the music file, > > but does not impose any time limit, which costs 1 Euro. > > > > In ODRLL v2.0, (1) is catered for by a Ticket and (2) is catered for by > > a contract. > > > > Now, when the user goes to acquire this license, the license server will > > first present the two offers, (1) and (2) and the user can then select > > which one (s)he likes, and proceed. > > > > In this case, it would be nice to reflect, in the offers themselves, > > that (1) is a ticket, and (2) is a contract. > > > > There in no real need to create an additional element, it could be all > > handled as an extra attribute. > > > > On another note - I was looking at the DMP negotiations call - and I am > > considering submitting the ODRL negotiations approach. One of the > > requirements is "setting a parameter as non-negotiable", which would > > require the creation of an additional attribute for every negotiable > > element. > > > > Alapan > > On Wed, 2006-02-22 at 22:00 +0100, Susanne Guth wrote: > > > Hi Alapan, > > > > > > its the latter, but I don't understand the concerns you have. Please > > > reformulate what you think the problem is. Thanks > > > > > > Susanne > > > > > > > > > > > Hi Susanne, everyone else > > > > I am still working on the contracts issue - semester just started, so > > > > academic staff are a little hard to get hold of. > > > > > > > > A question on the model posted - I see the absence of the > > > > "statement"/"ticket" etc. Is this feature removed? Or is this > > > > incorporated in the type attribute? > > > > > > > > If its the later, I have a slight problem (not only with the > > > > implications for negotiations) - but for standard usage also, as it > > will > > > > limit the comparability of different licenses. For example, it would > > not > > > > be possible to offer a ticket and a contract on the same digital > > object > > > > as their offers would look the same (i think ...) > > > > > > > > If it's the former .. I have no problem with it ;) > > > > > > > > Regards > > > > Alapan > > > > On Mon, 2006-01-30 at 01:32 +0100, Susanne Guth wrote: > > > > > Hi everybody, > > > > > > > > > > as you can see from my various emails this was an ODRL weekend for > > me :) > > > > > > > > > > >From reading through the discussions I found the following: > > > > > > > > > > 1.) we need containers > > > > > 2.) we need prohibitions > > > > > 3.) we need contractual details and negotition elements > > > > > 4.) the model has simplification potential > > > > > > > > > > I worked a little bit on the model that you can see attached. This > > is - > > > > of > > > > > course - only a draft and no new v2 model. > > > > > > > > > > 1.) Containers > > > > > > > > > > I added a container element which is not properly related to the > > other > > > > > elements. Container have the attributes > > > > > > > > > > BIND containing e.g. OR, AND > > > > > TYPE containing e.g. "Container of Constraints" > > > > > RELATEDTO containing the element that includes the container. > > > > > > > > > > I think that we would have to carefully describe in our semantics > > what > > > > each > > > > > container type means, so that we provide a chance to implement the > > > > language. > > > > > > > > > > Container Example > > > > > > > > > > > > > > > 20 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 31-12-2004 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2.) > > > > > > > > > > I kept prohibitions as they were. However, this issue need further > > > > > discussion. The important question is if we can formalise the model > > with > > > > > prohibitions in it... vicky I count on you here :) > > > > > > > > > > 3.) > > > > > > > > > > I added the negotiation and communication elements. Details > > (attributes > > > > must > > > > > be discussed. > > > > > > > > > > 4.) > > > > > > > > > > What do you guys think of removing the rights-expression-type level > > and > > > > > instead using an attribute "TYPE" in rights to specify the semantics > > of > > > > the > > > > > actual rights expression? > > > > > > > > > > I have a problem with different hierarchies of RE elements, like in > > > > alapans > > > > > approach - simply for negotiation. If somebody wants to use ODRL > > without > > > > the > > > > > negotiation part, then the hierarchies do not make sense at all. An > > aim > > > > > should really be to keep the negotiation part independent of the > > > > remaining > > > > > model. > > > > > > > > > > If a RE grants next rights, for example, then these nextrights have > > to > > > > be > > > > > defined in a new rights expressed. RE ids would have to link the > > various > > > > > rights expressions. This would have the advantage that a "nextRight" > > > > could > > > > > more easily become part of a new agreement (I think). > > > > > > > > > > Comments? > > > > > > > > > > -- > > > > > Susanne Guth > > > > > susanne@odrl.net > > > > > ODRL Initiative > > > > > http://odrl.net/ > > > > > > > > > > DSL-Aktion wegen groer Nachfrage bis 28.2.2006 verlngert: > > > > > GMX DSL-Flatrate 1 Jahr kostenlos* http://www.gmx.net/de/go/dsl > > > > > _______________________________________________ ODRL-Version2 > > mailing > > > > list ODRL-Version2@odrl.net > > > > http://lists.odrl.net/mailman/listinfo/odrl-version2 > > > > -- > > > > 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 > > > > > > > > _______________________________________________ > > > > ODRL-Version2 mailing list > > > > ODRL-Version2@odrl.net > > > > http://lists.odrl.net/mailman/listinfo/odrl-version2 > > > > > > > > > -- > > 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 > > > -- 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 Susanne.Guth at gmx.net Tue Feb 28 04:01:39 2006 From: Susanne.Guth at gmx.net (Susanne Guth) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] resumption of containers & model update References: <1141031899.859.14.camel@iduna> Message-ID: <20064.1141059699@www046.gmx.net> Hi Alapan, with regard to contract, do you mean sales contracts, marriage contracts, etc. ? Negotiating: Yes I guess constraints make sense in any case. But what about if you negotiate permissions that do not have constraints. For example, you either get the copy permission or the print permission. Therefore, I guess we need all perm, proh, duties, constraints, no? Susanne > > On Fri, 2006-02-24 at 17:53 +0100, Susanne Guth wrote: > > Hi Alapan, > > > > I think there is a logic tongh twister in your example. You can not > > negotiate if you would like agree to a "ticket" or a "contract". A > ticket > > results from a contract. And an offer can only result by the > confirmation of > > an agreement. The field "rights expression type" only describes what the > > rights expression represents. OK? Are all your concerns cleared? > > > This is truly a twister ;) Well the point is - when presenting an offer, > shouldn't there be an indication of what type of contracts are on offer? > > > On another note - I was looking at the DMP negotiations call - and I > am > > > considering submitting the ODRL negotiations approach. One of the > > > requirements is "setting a parameter as non-negotiable", which would > > > require the creation of an additional attribute for every negotiable > > > element. > > > > I think it's a good idea to indicate negotional elements. So what are > the > > candidates for this element: Permissions, Duties, Prohibitions and > > Contstraints. Or shall we go down to the Action- Element Level= Actions > & > > constraints? > > > Down to the lower levels - as I think the constraints themselves are the > most useful element of negotiations (e.g. 5 pages instead of 1 page > limit on printing). > > Discussion opened.. > > > > susanne > > > > > > > > Hi Susanne, > > > On the legal issues - I will have an answer for you hopefully on > Monday, > > > latest Tuesday. > > > > > > On the type issue: > > > Lets say you have a music file "Hello World" and as the rights holder > > > you would like to offer two types of licences: > > > 1) A short-time limited license (one day) that does not restrict usage > > > to any particular person, which costs 20 Euro cents > > > 2) A person limited license, which restricts who can use the music > file, > > > but does not impose any time limit, which costs 1 Euro. > > > > > > In ODRLL v2.0, (1) is catered for by a Ticket and (2) is catered for > by > > > a contract. > > > > > > Now, when the user goes to acquire this license, the license server > will > > > first present the two offers, (1) and (2) and the user can then select > > > which one (s)he likes, and proceed. > > > > > > In this case, it would be nice to reflect, in the offers themselves, > > > that (1) is a ticket, and (2) is a contract. > > > > > > There in no real need to create an additional element, it could be all > > > handled as an extra attribute. > > > > > > On another note - I was looking at the DMP negotiations call - and I > am > > > considering submitting the ODRL negotiations approach. One of the > > > requirements is "setting a parameter as non-negotiable", which would > > > require the creation of an additional attribute for every negotiable > > > element. > > > > > > Alapan > > > On Wed, 2006-02-22 at 22:00 +0100, Susanne Guth wrote: > > > > Hi Alapan, > > > > > > > > its the latter, but I don't understand the concerns you have. Please > > > > reformulate what you think the problem is. Thanks > > > > > > > > Susanne > > > > > > > > > > > > > > Hi Susanne, everyone else > > > > > I am still working on the contracts issue - semester just started, > so > > > > > academic staff are a little hard to get hold of. > > > > > > > > > > A question on the model posted - I see the absence of the > > > > > "statement"/"ticket" etc. Is this feature removed? Or is this > > > > > incorporated in the type attribute? > > > > > > > > > > If its the later, I have a slight problem (not only with the > > > > > implications for negotiations) - but for standard usage also, as > it > > > will > > > > > limit the comparability of different licenses. For example, it > would > > > not > > > > > be possible to offer a ticket and a contract on the same digital > > > object > > > > > as their offers would look the same (i think ...) > > > > > > > > > > If it's the former .. I have no problem with it ;) > > > > > > > > > > Regards > > > > > Alapan > > > > > On Mon, 2006-01-30 at 01:32 +0100, Susanne Guth wrote: > > > > > > Hi everybody, > > > > > > > > > > > > as you can see from my various emails this was an ODRL weekend > for > > > me :) > > > > > > > > > > > > >From reading through the discussions I found the following: > > > > > > > > > > > > 1.) we need containers > > > > > > 2.) we need prohibitions > > > > > > 3.) we need contractual details and negotition elements > > > > > > 4.) the model has simplification potential > > > > > > > > > > > > I worked a little bit on the model that you can see attached. > This > > > is - > > > > > of > > > > > > course - only a draft and no new v2 model. > > > > > > > > > > > > 1.) Containers > > > > > > > > > > > > I added a container element which is not properly related to the > > > other > > > > > > elements. Container have the attributes > > > > > > > > > > > > BIND containing e.g. OR, AND > > > > > > TYPE containing e.g. "Container of Constraints" > > > > > > RELATEDTO containing the element that includes the container. > > > > > > > > > > > > I think that we would have to carefully describe in our > semantics > > > what > > > > > each > > > > > > container type means, so that we provide a chance to implement > the > > > > > language. > > > > > > > > > > > > Container Example > > > > > > > > > > > > > > > > > > 20 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 31-12-2004 > > > > > > > > > > > > > > > > > > > > > > > > container"> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2.) > > > > > > > > > > > > I kept prohibitions as they were. However, this issue need > further > > > > > > discussion. The important question is if we can formalise the > model > > > with > > > > > > prohibitions in it... vicky I count on you here :) > > > > > > > > > > > > 3.) > > > > > > > > > > > > I added the negotiation and communication elements. Details > > > (attributes > > > > > must > > > > > > be discussed. > > > > > > > > > > > > 4.) > > > > > > > > > > > > What do you guys think of removing the rights-expression-type > level > > > and > > > > > > instead using an attribute "TYPE" in rights to specify the > semantics > > > of > > > > > the > > > > > > actual rights expression? > > > > > > > > > > > > I have a problem with different hierarchies of RE elements, like > in > > > > > alapans > > > > > > approach - simply for negotiation. If somebody wants to use ODRL > > > without > > > > > the > > > > > > negotiation part, then the hierarchies do not make sense at all. > An > > > aim > > > > > > should really be to keep the negotiation part independent of the > > > > > remaining > > > > > > model. > > > > > > > > > > > > If a RE grants next rights, for example, then these nextrights > have > > > to > > > > > be > > > > > > defined in a new rights expressed. RE ids would have to link the > > > various > > > > > > rights expressions. This would have the advantage that a > "nextRight" > > > > > could > > > > > > more easily become part of a new agreement (I think). > > > > > > > > > > > > Comments? > > > > > > > > > > > > -- > > > > > > Susanne Guth > > > > > > susanne@odrl.net > > > > > > ODRL Initiative > > > > > > http://odrl.net/ > > > > > > > > > > > > DSL-Aktion wegen groer Nachfrage bis 28.2.2006 verlngert: > > > > > > GMX DSL-Flatrate 1 Jahr kostenlos* http://www.gmx.net/de/go/dsl > > > > > > _______________________________________________ ODRL-Version2 > > > mailing > > > > > list ODRL-Version2@odrl.net > > > > > http://lists.odrl.net/mailman/listinfo/odrl-version2 > > > > > -- > > > > > 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 > > > > > > > > > > _______________________________________________ > > > > > ODRL-Version2 mailing list > > > > > ODRL-Version2@odrl.net > > > > > http://lists.odrl.net/mailman/listinfo/odrl-version2 > > > > > > > > > > > > -- > > > 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 > > > > > > -- > 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 > > _______________________________________________ > 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/ Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner From fengwenjie at huawei.com Tue Feb 28 17:16:54 2006 From: fengwenjie at huawei.com (fengwenjie) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] The difference between offer and ticket Message-ID: <001801c63c2e$9240a4b0$420aa40a@china.huawei.com> Hello, all I am a little confused about the definition of rights type 'offer' and 'ticket'. In the V2 Model, it says: "Offer. The Offer entity supports rights expressions that are proposing content under various terms and conditions to any consuming party from the owner party. The Offer entity must contain an Asset entity, one or both Permission and Prohibition entities, and a Party entity with Assigner (rights holder) role. The Offer entity must not contain a Party entity with Assignee or Assignees (consumer/s) roles." "Ticket. The Ticket entity supports rights expressions that are contracts stipulating the content, terms and conditions of usage, and the owning parties involved. The consuming party is not known at the time the ticket is issued and is redeemable by anyone who currently holds the ticket in their possession. The Ticket entity must contain an Asset entity, one or both Permission and Prohibition entities, and at least one Party entity with Assigner role. The Ticket entity must not contain a Party entity with Assignee or Assignees roles. " from above, the only textual difference is that: ticket allows at least one party with Assigner role, while offer only allows exactly one! Then, what's the original intention to have these 2 kinds of rights types? or to say, what's the semantic difference between them? Thanks in advance, Jessica ***************************************************************************************************************************************** This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ****************************************************************************************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.odrl.net/pipermail/odrl-version2/attachments/20060228/9fbfd413/attachment.html From aarnab at cs.uct.ac.za Tue Feb 28 23:45:10 2006 From: aarnab at cs.uct.ac.za (Alapan Arnab) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] Followup on Legal stuff about contracts Message-ID: <1141130710.20376.37.camel@iduna> Hi Susanne and others, I had a discussion with a law professor (Prof Julien Hofman) in my university with regards to ODRL v2.0, and you were right with regards to contracts and form. Currently ODRL is a language to express licensing agreements, and in most countries (all the countries he is aware of), licensing agreements are formless, and sometimes would not even require signatures. However, in most legal systems it is often recommended that licensing agreements have some elements to remove legal ambiguities should disputes arise. So,, there is obviously a need to refine my section 2; but here is a short summary of the recommended elements: 1. Jurisdiction and Dispute Resolution These elements go together and are very useful in resolving contract disputes speedily. In dispute resolution, the parties resolve to go to a mutually agreed party to arbitrate their dispute and is often a cheaper avenue to pursue. Should this fail, or if a party does not wish to take this route, they can choose to sue the other party. Jurisdiction determines where a party can be sued. 2. Choice of law Because of the international nature, it should be possible to choose which law governs the licensing agreement. This is potentially very important in DRM. For example, in EU copyright directive, the rights holder does not have to provide for fair use clauses while copyright law in most countries do not have such restrictions. Thus, it would be advantageous for music labels to base their licensing agreements under EU law rather than, say South African law. 3. Time of Contract For licensing agreements, time of contract is often necessary although not mandatory. 4. Place of contract Licensing agreements should not have a place of contract. A court needs to decide the place of contract when deciding whether it has jurisdiction. 5. Signatures As I mentioned previously, signatures are not mandatory but recommended. In any case digital signatures are a security mechanism. 6. Liabilities This is probably the most important part for most contracts. It could be interesting to provide different pricing models according to the liability risk carried by the supplier. For example, if the ODRL license covers software, the rights holder could provide the software at a very low price but with no guarantees on performance while at a much higher price with guarantees on performance or number of bugs. 7. Lifetime In an electronic medium, the lifetime of a contract (or offers etc) is important as there are very few precedents (if any) that can be used in case of disputes. 8. Offer, Counter-Offer and Requests Although the text in my section is correct, there are some problems encountered in a scenario where a client makes a counter offer. Specifically, electronic transaction law in some countries insist on certain regulation regarding consumer protection from the party that makes the offer. Thus, when a client makes a counter offer, (s)he would be required to abide by such regulation removing the potential for anonymous negotiations (from the client). Thus, it is suggested that we only use the terms Offer (from the rights holder) and Request (from the client). 9. Country of residence (for client) Depending on the country of residence for the client, the rights holder has to abide by certain consumer protection legislation etc. For example, in the case of a EU citizen, a rights holder outside the EU cannot store personal information unless they have signed a safe harbour agreement. 10. Tax I am not sure if the payment model takes care of tax issues, but this could be an element under legal section. 11. Fair Use policy In my ACM-DRM paper last year (which is an evolution from my ODRL workshop paper) I detailed using negotiations as a mechanism to enable fair use. The professor suggested that we have an element in the license that details the rights holders position on fair use and how to approach for fair use. Thus, if the license agreement is based in Europe, (s)he can state that fair use is not offered etc. -------------------------------- Ok, I hope that all made sense and I didn't make any typos etc. Alapan -- 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