From aarnab at cs.uct.ac.za Wed Jan 11 19:40:01 2006 From: aarnab at cs.uct.ac.za (Alapan Arnab) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] New ODRL v2.0 Model Message-ID: <1136968801.7279.11.camel@iduna> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: new_odrl_20060111.pdf Type: application/pdf Size: 302550 bytes Desc: not available Url : http://lists.odrl.net/pipermail/odrl-version2/attachments/20060111/10db1c8f/new_odrl_20060111.pdf From Susanne.Guth at gmx.net Wed Jan 11 21:08:11 2006 From: Susanne.Guth at gmx.net (Susanne Guth) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] New ODRL v2.0 Model References: <1136968801.7279.11.camel@iduna> Message-ID: <31043.1136974091@www89.gmx.net> Hi Alapan, happy new year and thanks a bunch for your effort. Can't wait to read about your ideas.. susanne > > 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 > -- 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 Susanne.Guth at gmx.net Mon Jan 16 03:47:49 2006 From: Susanne.Guth at gmx.net (Susanne Guth) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] New ODRL v2.0 Model References: <1136968801.7279.11.camel@iduna> Message-ID: <5758.1137343669@www23.gmx.net> Hi Alapan, happy new year everybody, thanks for your proposal with regard to ODRL 2.0. Let's get things moving! Here are my first comments, yet not complete (there have been a bunch of issues in your paper :) ) With regard to "other issues": 4.5.1 Containers We kicked out the containers because it is extremely complex to define the semantics and implement containers. (That showed the implementation experiences). On the other hand we did not come up with a better solution for expressing XOR/OR/AND relations. In ODRL v1.1 containers are allowed for a bunch of things; maybe in v2.0 Containers should only be allowed for permissions, prohibitions and duties. What do you guy think? 4.5.2 "NOT" By allowing to express "Prohibitions" we have our means to express "NOT". Originally the NOT was requested to express things like: "Everything is allowed, except 'thisandthat'. The odrl-v2.0-"prohibition" offers such a means. 4.5.3 Next Rights I kind of like the idea to eliminate one level in the ODRLv2.0 and instead use a variable to express different types of rights expressions. We might want to think about adding your "Type" attribute of License to the "Rights" element. By that however we reduce our flexibility to but e.g. an offer an "next rights" into one "rights" node tree? In your current proposal a ticket could be part of a license which could have the Type="Offer". That would not really make sense to me. We should keep ticket, offer, request, agreement, etc. on one level respectively with the same type of element. In your proposal, offer is an attribute and ticket is an element. 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? That's it for now. More comments to come. Any other thought of the ODRL v2.0 people? So long Susanne > > 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 > -- Susanne Guth susanne@odrl.net ODRL Initiative http://odrl.net/ DSL-Aktion wegen großer Nachfrage bis 28.2.2006 verlängert: GMX DSL-Flatrate 1 Jahr kostenlos* http://www.gmx.net/de/go/dsl From Susanne.Guth at gmx.net Mon Jan 16 03:47:49 2006 From: Susanne.Guth at gmx.net (Susanne Guth) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] New ODRL v2.0 Model References: <1136968801.7279.11.camel@iduna> Message-ID: <5758.1137343669@www23.gmx.net> Hi Alapan, happy new year everybody, thanks for your proposal with regard to ODRL 2.0. Let's get things moving! Here are my first comments, yet not complete (there have been a bunch of issues in your paper :) ) With regard to "other issues": 4.5.1 Containers We kicked out the containers because it is extremely complex to define the semantics and implement containers. (That showed the implementation experiences). On the other hand we did not come up with a better solution for expressing XOR/OR/AND relations. In ODRL v1.1 containers are allowed for a bunch of things; maybe in v2.0 Containers should only be allowed for permissions, prohibitions and duties. What do you guy think? 4.5.2 "NOT" By allowing to express "Prohibitions" we have our means to express "NOT". Originally the NOT was requested to express things like: "Everything is allowed, except 'thisandthat'. The odrl-v2.0-"prohibition" offers such a means. 4.5.3 Next Rights I kind of like the idea to eliminate one level in the ODRLv2.0 and instead use a variable to express different types of rights expressions. We might want to think about adding your "Type" attribute of License to the "Rights" element. By that however we reduce our flexibility to but e.g. an offer an "next rights" into one "rights" node tree? In your current proposal a ticket could be part of a license which could have the Type="Offer". That would not really make sense to me. We should keep ticket, offer, request, agreement, etc. on one level respectively with the same type of element. In your proposal, offer is an attribute and ticket is an element. 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? That's it for now. More comments to come. Any other thought of the ODRL v2.0 people? So long Susanne > > 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 > -- Susanne Guth susanne@odrl.net ODRL Initiative http://odrl.net/ DSL-Aktion wegen großer Nachfrage bis 28.2.2006 verlängert: GMX DSL-Flatrate 1 Jahr kostenlos* http://www.gmx.net/de/go/dsl From Steven_Rowat at sunshine.net Mon Jan 16 10:46:13 2006 From: Steven_Rowat at sunshine.net (Steven Rowat) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] New ODRL v2.0 Model Message-ID: Hi Alapan, Thanks for the opportunity to see your work. Comments below. Specifics first, then general. 4.1 Rights, Signature and Legal Elements. All changes [#1-3] agreed. 4.2 Communication and License Elements Changes 4-6, uncertain if necessary, but no objection 4.3 Contract Change 7, agreed Overall Comments: 1. Bidding would probably be a large-scale addition and if so might slow down dissemination of ODRL at a critical time. 2. What is a "ticket" in your revamped model (or, for that matter, in the original version 2. I admit I've forgotten)? How is it different from "contract"? 3. The use of the word 'contract' will be appropriate for negotiations between corporations and bureacracies, but might put off the average consumer wishing to download music or a few pages of text, say. In this situation, in my opinion, "Agreement" is much more user-friendly. Admittedly, the average user will not need to be looking under the hood, so "Agreement" could be used in pull-down menus etc., and 'contract' in the actual code. But still, it would be more clean to have the same word used at both levels, unless there is a legal reason why the word 'contract' has to be used; I suspect that there is not. ("A rose by any other name would smell as sweet"). 4. Section 4.5, "Other Issues": Unfortunately in all of these I seem to understand too little about the situation to see a problem. I think I'll take the 'glass-is-half-full' approach and treat this as evidence that ODRL 2 is almost ready for release. :-) steven rowat >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 > >Attachment converted: Macintosh HD:new_odrl_20060111.pdf (PDF /CARO) (000A9288) >_______________________________________________ >ODRL-Version2 mailing list >ODRL-Version2@odrl.net >http://lists.odrl.net/mailman/listinfo/odrl-version2 From renato at odrl.net Mon Jan 16 13:49:05 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: <1136968801.7279.11.camel@iduna> References: <1136968801.7279.11.camel@iduna> Message-ID: Hi Alapan - thanks for the comprehensive contribution. I am "warming" to the idea of supporting contract negotiation in V2 as it is an important (and costly) part of rights management. What do others think of this, as this would be a major change to V2 so far...?? Some of my other comments include: 4.5.1 - if we can think of an elegant way to support containers in the model, then that would be good, but we need to make it simple and not complicate implementations. 4.5.2 - have a NOT on parties would be interesting! 4.5.3 - is there is nice way to support next rights? 4.5.4 - the idea was that we can define a single Duty (eg a payment) and link it to multiple permissions. Alternatively, with some form of container, we could collect them together and assign a single Duty to them... 4.5.5 - "actions" are the lower level "data dictionary" terms like, print, display etc. The Permission/Prohibition, is the parent of these. Cheers... Renato Iannella National ICT Australia (NICTA) From aarnab at cs.uct.ac.za Mon Jan 16 22:56:26 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: <5758.1137343669@www23.gmx.net> References: <1136968801.7279.11.camel@iduna> <5758.1137343669@www23.gmx.net> Message-ID: <1137412586.7272.36.camel@iduna> Hi Susanne, Thanks for your comments. I will try to reply to each email - should make tracking a bit easier. > 4.5.1 Containers > > We kicked out the containers because it is extremely complex to define the > semantics and implement containers. (That showed the implementation > experiences). On the other hand we did not come up with a better solution > for expressing XOR/OR/AND relations. In ODRL v1.1 containers are allowed for > a bunch of things; maybe in v2.0 Containers should only be allowed for > permissions, prohibitions and duties. What do you guy think? > I have the exact same problem - containers are very useful but dificult to define and implement. I have an idea - maybe not a generic container, but something that might do the job - I will use constraint as an example: Define a container type for each type that we wish to be in a container eg. ConstraintContainer. This can be defined as: ConstraintContainer = * ConstraintContainer = * where container is one of "and","or","xor" and "not" This allows for a nested list of constraints, and then instead of linking to a constraint, it links to a constraint or a container. > 4.5.2 "NOT" > > By allowing to express "Prohibitions" we have our means to express "NOT". > Originally the NOT was requested to express things like: "Everything is > allowed, except 'thisandthat'. The odrl-v2.0-"prohibition" offers such a > means. > The way I have defined prohibition does make that work - but not could be useful for parties (something not catered for). > 4.5.3 Next Rights > > I kind of like the idea to eliminate one level in the ODRLv2.0 and instead > use a variable to express different types of rights expressions. We might > want to think about adding your "Type" attribute of License to the "Rights" > element. By that however we reduce our flexibility to but e.g. an offer an > "next rights" into one "rights" node tree? > > In your current proposal a ticket could be part of a license which could > have the Type="Offer". That would not really make sense to me. We should > keep ticket, offer, request, agreement, etc. on one level respectively with > the same type of element. In your proposal, offer is an attribute and ticket > is an element. > Yeah, I am not totally happy with how I have done the current implementation. The improvement in my view is to have three elements at that level: communication, license and nextRights. License and nextRights can then be either tickets, statements or contracts. > 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. 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 Mon Jan 16 23:04:29 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: References: Message-ID: <1137413069.7272.43.camel@iduna> Hi, Comments for Steven's email: > > 1. Bidding would probably be a large-scale addition and if so might slow down dissemination of ODRL at a critical time. Not really - bidding is just an extension to the type elements and thus has no real effect on the overall license structure. > > 2. What is a "ticket" in your revamped model (or, for that matter, in the original version 2. I admit I've forgotten)? How is it different from "contract"? A ticket in both models is essentially the same as a ticket for a concert, the bus etc - it gives the bearer a set of rights from the rights holder; and the bearer is not a defined party (so I could give you my ticket and you will have access). > 3. The use of the word 'contract' will be appropriate for negotiations between corporations and bureacracies, but might put off the average consumer wishing to download music or a few pages of text, say. In this situation, in my opinion, "Agreement" is much more user-friendly. Admittedly, the average user will not need to be looking under the hood, so "Agreement" could be used in pull-down menus etc., and 'contract' in the actual code. But still, it would be more clean to have the same word used at both levels, unless there is a legal reason why the word 'contract' has to be used; I suspect that there is not. ("A rose by any other name would smell as sweet"). > Agreed - but I think it is also a problem with current DRM systems - DRM systems are enforcement of license contracts not copyright - I think it is better for consumers to know and accept the fact instead of the current scenario where no-one knows what the exact situation is? > 4. Section 4.5, "Other Issues": Unfortunately in all of these I seem to understand too little about the situation to see a problem. I think I'll take the 'glass-is-half-full' approach and treat this as evidence that ODRL 2 is almost ready for release. :-) > Well I do have a full blown XML schema ... but I am not sure using it would be a good idea ;) > steven rowat > > > >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 > > > >Attachment converted: Macintosh HD:new_odrl_20060111.pdf (PDF /CARO) (000A9288) > >_______________________________________________ > >ODRL-Version2 mailing list > >ODRL-Version2@odrl.net > >http://lists.odrl.net/mailman/listinfo/odrl-version2 > > > _______________________________________________ > 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 Jan 16 23:42:30 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: References: <1136968801.7279.11.camel@iduna> Message-ID: <1137415350.7272.50.camel@iduna> Hi, Responses to Renato's email > Some of my other comments include: > > 4.5.1 - if we can think of an elegant way to support containers in > the model, then that would be good, but we need to make it simple and > not complicate implementations. > See my response to Susanne's email. > 4.5.5 - "actions" are the lower level "data dictionary" terms like, > print, display etc. > The Permission/Prohibition, is the parent of these. > So if "print" is an action, how do I put a constraint to it? In ODRL 1.1, "print" was a permission, thus: 1 would have given a permission to print maximum of 1 time. However, in the ODRL v2.0 it becomes: 1 which is not correct as an additional permission (e.g. display) could also be linked under permissions and then what does the count refer to? It's for this reason, none of the examples I provide have any constraints. Alapan > > Cheers... Renato Iannella > National ICT Australia (NICTA) > > > _______________________________________________ > 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 Jan 17 03:26:14 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 12, Issue 3 Message-ID: <2EE48095D8C21643B0B70EC95F9BFBAFD85EF2@EXCHVS1.cs.cornell.edu> Hi all, Like Susanne and Steven, I also enjoyed reading Alapan and Andrew's paper. Comments below: (1) Your discussion on denial of service attacks raises the question of what could be done if the attack is distributed (i.e., attacker infiltrates many machines and has each one begin bartering at the same time). This problem is certainly not unique to ODRL and, perhaps, the entire topic of defense should be given a full treatment in another paper. (2) I'm not sure why a use license cannot both grant some permissions and forbid others. (3) I'm concerned that your interpretation of permitting/prohibiting agreements is problematic. To see why, suppose that Alice is a faculty member of Univ. of Cape Town and a citizen of South Africa. The university writes two agreements, the first allows faculty members to "checkout" a library resource for 6 months and the second allows any citizen of South Africa to put in a request for a library resource (which is then reviewed and acting on accordingly). The two agreements are in conflict, because the first forbids Alice to request a resource, since she is faculty and not explicitly permitted in the first agreement, and the second permits Alice to make the request, since she is a citizen of Cape Town. In general, I suspect that conflicts are likely to arise unless, for each principal p, there is at most one agreement that permits (or denies) rights to p. An obvious solution is to remove implicit assumptions from agreements; that is, a permitting/prohibiting agreement permits/forbids the actions specified (under the conditions given) and does not make any statements beyond that. (4!) You say that the your recommended changes to the permission/prohibition elements "removes all the ambiguities presented in the current approach". Since you have not given formal semantics for your suggestion, this is simply not true. Because your suggestion is written in English, there are a variety of ways in which I could interpret it. For example, suppose an agreement says only that Alice may print 5 copies of the report. Your suggestion could be equivalent to "if Alice has not made 5 copies, then she may print the report and is forbidden to do anything else; otherwise, she is forbidden to do any action". Alternatively, you could mean "if Alice has not made 5 copies, then she may print the report and she is forbidden to do anything else to the report; otherwise, there is no action that she can do legitimately that involves the report". (Given the discussion in the second paragraph of Section 4.5.4, you seem to favor the first interpretation, whereas I think the second is more intuitive.) Riccardo Pucella and I have given formal semantics to a representative fragment of ODRL v.1; I suspect a similar approach could be used here (almost finished with journal version, which I can send you if interested). (5) I can see why a general-purpose NOT container might be useful, but I'm not sure it makes sense to have both an XOR and a NOT container. To see why, notice that XOR(true, blah) = NOT blah, and XOR(blah_1,..., blah_n) = OR[e_1,..., e_n], where e_i = AND[blah_i, NOT blah_1, ..., NOT blah_{i-1}, blah_{i+1}, ..., blah_n]. (6) The ambiguity that you allude to in Section 4.5.5 was, I believe, discussed in the conference version of "A Formal Foundation for ODRL", WITS-04 (Workshop on Issues in the Theory of Security). If interested, I can send you a copy or you can download it from my homepage (http://www.cs.cornell.edu/People/vickyw). It is also discussed in the full version, which is on the verge of being submitted and, I think, is a substantial improvement on the conference paper. (7) Maybe I shouldn't say this, because it's not a "technical comment", but I found your paper especially easy to read. I appreciate you taking the time to communicate so clearly. Best, Vicky -----Original Message----- Today's Topics: 1. Re: New ODRL v2.0 Model (Susanne Guth) 2. Re: New ODRL v2.0 Model (Steven Rowat) Hi Alapan, happy new year everybody, thanks for your proposal with regard to ODRL 2.0. Let's get things moving! Here are my first comments, yet not complete (there have been a bunch of issues in your paper :) ) With regard to "other issues": 4.5.1 Containers We kicked out the containers because it is extremely complex to define the semantics and implement containers. (That showed the implementation experiences). On the other hand we did not come up with a better solution for expressing XOR/OR/AND relations. In ODRL v1.1 containers are allowed for a bunch of things; maybe in v2.0 Containers should only be allowed for permissions, prohibitions and duties. What do you guy think? 4.5.2 "NOT" By allowing to express "Prohibitions" we have our means to express "NOT". Originally the NOT was requested to express things like: "Everything is allowed, except 'thisandthat'. The odrl-v2.0-"prohibition" offers such a means. 4.5.3 Next Rights I kind of like the idea to eliminate one level in the ODRLv2.0 and instead use a variable to express different types of rights expressions. We might want to think about adding your "Type" attribute of License to the "Rights" element. By that however we reduce our flexibility to but e.g. an offer an "next rights" into one "rights" node tree? In your current proposal a ticket could be part of a license which could have the Type="Offer". That would not really make sense to me. We should keep ticket, offer, request, agreement, etc. on one level respectively with the same type of element. In your proposal, offer is an attribute and ticket is an element. 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? That's it for now. More comments to come. Any other thought of the ODRL v2.0 people? So long Susanne ---------------------------------------------------------------------- Message: 2 Date: Sun, 15 Jan 2006 15:46:13 -0800 From: Steven_Rowat@sunshine.net (Steven Rowat) Subject: Re: [Odrl-version2] New ODRL v2.0 Model To: "ODRL Version 2.0" Message-ID: Content-Type: text/plain; charset="us-ascii" Hi Alapan, Thanks for the opportunity to see your work. Comments below. Specifics first, then general. 4.1 Rights, Signature and Legal Elements. All changes [#1-3] agreed. 4.2 Communication and License Elements Changes 4-6, uncertain if necessary, but no objection 4.3 Contract Change 7, agreed Overall Comments: 1. Bidding would probably be a large-scale addition and if so might slow down dissemination of ODRL at a critical time. 2. What is a "ticket" in your revamped model (or, for that matter, in the original version 2. I admit I've forgotten)? How is it different from "contract"? 3. The use of the word 'contract' will be appropriate for negotiations between corporations and bureacracies, but might put off the average consumer wishing to download music or a few pages of text, say. In this situation, in my opinion, "Agreement" is much more user-friendly. Admittedly, the average user will not need to be looking under the hood, so "Agreement" could be used in pull-down menus etc., and 'contract' in the actual code. But still, it would be more clean to have the same word used at both levels, unless there is a legal reason why the word 'contract' has to be used; I suspect that there is not. ("A rose by any other name would smell as sweet"). 4. Section 4.5, "Other Issues": Unfortunately in all of these I seem to understand too little about the situation to see a problem. I think I'll take the 'glass-is-half-full' approach and treat this as evidence that ODRL 2 is almost ready for release. :-) steven rowat From aarnab at cs.uct.ac.za Tue Jan 17 04:00:04 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 12, Issue 3 In-Reply-To: <2EE48095D8C21643B0B70EC95F9BFBAFD85EF2@EXCHVS1.cs.cornell.edu> References: <2EE48095D8C21643B0B70EC95F9BFBAFD85EF2@EXCHVS1.cs.cornell.edu> Message-ID: <1137430804.31915.22.camel@iduna> Hi Vicky, Thanks a lot for your kind comments - glad the paper was informative. > > (1) Your discussion on denial of service attacks raises the question of what > could be done if the attack is distributed (i.e., attacker infiltrates many > machines and has each one begin bartering at the same time). This problem is > certainly not unique to ODRL and, perhaps, the entire topic of defense should > be given a full treatment in another paper. Yes - the problem affects anonymous negotiations in general. On the whole, this is not a problem for ODRL as ODRL is focussed on the language - but does need to be addressed at some level. > (2) I'm not sure why a use license cannot both grant some permissions and > forbid others. > My problems with the existing model was the fact that it was possible to have a license that granted and forbid the same set of permissions. This problem is clearly overcome with my approach. The current motto in RELs is - grant only the rights that are mentioned. Thus in a prohibition model - it should simply be assign all the rights except the ones mentioned. For this reason, there is no need to ever express a set of rights that are forbidden. > (3) I'm concerned that your interpretation of permitting/prohibiting > agreements is problematic. To see why, suppose that Alice is a faculty > member of Univ. of Cape Town and a citizen of South Africa. The university > writes two agreements, the first allows faculty members to "checkout" a > library resource for 6 months and the second allows any citizen of South > Africa to put in a request for a library resource (which is then reviewed and > acting on accordingly). The two agreements are in conflict, because the > first forbids Alice to request a resource, since she is faculty and not > explicitly permitted in the first agreement, and the second permits Alice to > make the request, since she is a citizen of Cape Town. In general, I suspect > that conflicts are likely to arise unless, for each principal p, there is at > most one agreement that permits (or denies) rights to p. An obvious solution > is to remove implicit assumptions from agreements; that is, a > permitting/prohibiting agreement permits/forbids the actions specified (under > the conditions given) and does not make any statements beyond that. > > (4!) You say that the your recommended changes to the permission/prohibition > elements "removes all the ambiguities presented in the current approach". > Since you have not given formal semantics for your suggestion, this is simply > not true. Because your suggestion is written in English, there are a variety > of ways in which I could interpret it. For example, suppose an agreement > says only that Alice may print 5 copies of the report. Your suggestion could > be equivalent to "if Alice has not made 5 copies, then she may print the > report and is forbidden to do anything else; otherwise, she is forbidden to > do any action". Alternatively, you could mean "if Alice has not made 5 > copies, then she may print the report and she is forbidden to do anything > else to the report; otherwise, there is no action that she can do > legitimately that involves the report". (Given the discussion in the second > paragraph of Section 4.5.4, you seem to favor the first interpretation, > whereas I think the second is more intuitive.) Riccardo Pucella and I have > given formal semantics to a representative fragment of ODRL v.1; I suspect a > similar approach could be used here (almost finished with journal version, > which I can send you if interested). > I would like to read your journal paper. On the examples you mention (with Alice printing) - I am not sure what the difference is. However, I do agree that a more formal semantic is required when it comes to the issue of containers and the prohibition model. > (5) I can see why a general-purpose NOT container might be useful, but I'm > not sure it makes sense to have both an XOR and a NOT container. To see why, > notice that XOR(true, blah) = NOT blah, and XOR(blah_1,..., blah_n) = > OR[e_1,..., e_n], where e_i = AND[blah_i, NOT blah_1, ..., NOT blah_{i-1}, > blah_{i+1}, ..., blah_n]. As I mentioned, one useful function of NOT would be to explicitly restrict a party (which is not covered by the prohibition model). > > (6) The ambiguity that you allude to in Section 4.5.5 was, I believe, > discussed in the conference version of "A Formal Foundation for ODRL", > WITS-04 (Workshop on Issues in the Theory of Security). If interested, I can > send you a copy or you can download it from my homepage > (http://www.cs.cornell.edu/People/vickyw). It is also discussed in the full > version, which is on the verge of being submitted and, I think, is a > substantial improvement on the conference paper. > I will have a look at the paper. > (7) Maybe I shouldn't say this, because it's not a "technical comment", but I > found your paper especially easy to read. I appreciate you taking the time > to communicate so clearly. > Thanks a lot! 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 vickyw at cs.cornell.edu Tue Jan 17 05:16:04 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 12, Issue 4 Message-ID: <2EE48095D8C21643B0B70EC95F9BFBAFD85EF5@EXCHVS1.cs.cornell.edu> A ticket in both models is essentially the same as a ticket for a concert, the bus etc - it gives the bearer a set of rights from the rights holder; and the bearer is not a defined party (so I could give you my ticket and you will have access). If that's the case, then a ticket is a contract in which the relevant party is "agreement holder", so I still don't see why ODRL has both agreements/contracts and tickets, rather than a principal "agreement holder" (which I think would be simpler). ----------------- I'm not sure why a use license cannot both grant some permissions and forbid others. My problems with the existing model was the fact that it was possible to have a license that granted and forbid the same set of permissions. This problem is clearly overcome with my approach. Whether your approach overcomes the problem depends on how we reason about a set of licenses. If we consider each license independently of the others, then I agree that your approach solves the problem. If we consider the licenses as a set, then the problem essentially still exists, since one license can permit an action that another forbids. ------------------ The current motto in RELs is - grant only the rights that are mentioned. Thus in a prohibition model - it should simply be assign all the rights except the ones mentioned. For this reason, there is no need to ever express a set of rights that are forbidden. If we assume every action that is not explicitly permitted is forbidden, then we lose the distinction between what is forbidden and what is unregulated (i.e., we force every agreement to regulate every action). As a result, agreements will often contradict one another, even when the intentions of the agreements' writers are not in conflict. To illustrate the idea, suppose that Alice's mother says she may have a cookie (i.e., issues an agreement giving Alice this right) and Alice's father says she may play outside (i.e., issues an agreement giving Alice this right). If I've understood your suggestion correctly, then you would say that Alice's mother permits Alice to have a cookie and forbids Alice from doing anything else, including playing outside and even breathing; similarly, Alice's father permits Alice to play outside and forbids Alice to do anything else, including eating a cookie and breathing. So, while the parents agree that Alice is not allowed to breath, they disagree over whether she may eat a cookie and whether she may play outside. That is, the agreement issued by Alice's mother contradicts the agreement issued by Alice's father (and the overall interpretation is just plain silly). It is not clear how we could "fix" the agreements. Certainly, the agreements could be rewritten so that Alice's mother and father both permit eating a cookie, playing outside, and breathing (along with all other unobjectionable activities). But what if Alice's mother doesn't care about whether Alice may play outside? Then we're forcing the mother to regulate an action that she doesn't care about and, if she permits when the father forbids (or vice-versa), we get a conflict. ------------------ suppose an agreement says only that Alice may print 5 copies of the report. Your suggestion could be equivalent to "if Alice has not made 5 copies, then she may print the report and is forbidden to do anything else; otherwise, she is forbidden to do any action". Alternatively, you could mean "if Alice has not made 5 copies, then she may print the report and she is forbidden to do anything else to the report; otherwise, there is no action that she can do legitimately that involves the report". On the examples you mention (with Alice printing) - I am not sure what the difference is. The first interpretation implies that Alice is forbidden to breath; the second implies only that she is forbidden to breath on the report (or do anything else *to the report*, other than possibly printing). ------------- I would like to read your journal paper. The current version can be downloaded from http://www.cs.cornell.edu/People/vickyw/tmp/PucellaWeissman.pdf (.ps). Comments very welcome (though, for reasons of personal sanity, I probably won't put in changes until the paper has come back from review). Best, Vicky From aarnab at cs.uct.ac.za Tue Jan 17 07:12:18 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 12, Issue 4 In-Reply-To: <2EE48095D8C21643B0B70EC95F9BFBAFD85EF5@EXCHVS1.cs.cornell.edu> References: <2EE48095D8C21643B0B70EC95F9BFBAFD85EF5@EXCHVS1.cs.cornell.edu> Message-ID: <1137442338.32399.29.camel@iduna> On Mon, 2006-01-16 at 13:16 -0500, Vicky Weissman wrote: > > A ticket in both models is essentially the same as a ticket for a concert, > the bus etc - it gives the bearer a set of rights from the rights holder; and > the bearer is not a defined party (so I could give you my ticket and you will > have access). > > > If that's the case, then a ticket is a contract in which the relevant party > is "agreement holder", so I still don't see why ODRL has both > agreements/contracts and tickets, rather than a principal "agreement holder" > (which I think would be simpler). > Can't really counter that - because I totally agree. Although, to be fair, the current approach does make implementation easier. > ----------------- > > I'm not sure why a use license cannot both grant some permissions and forbid > others. > > > My problems with the existing model was the fact that it was possible to have > a license that granted and forbid the same set of permissions. This problem > is clearly overcome with my approach. > > > Whether your approach overcomes the problem depends on how we reason about a > set of licenses. If we consider each license independently of the others, > then I agree that your approach solves the problem. If we consider the > licenses as a set, then the problem essentially still exists, since one > license can permit an action that another forbids. > Ah - I see what you mean. The next question then should be - how does license sets work. Assume that Alice has License A, B, and C for the Object O. In my view, Alice should be able to perform any action permitted by A, B or C unless a license is explicitly invalidated - i.e. if C states that B is invalidated, then any rights allowed by B is ignored. Which leads to a new requirement - there should be a mechanism to invalidate other licenses - like a revocation list. I do not see why licenses for a particular object should be evaluated as a set - because there could be specific reasons for having multiple licenses (different validity dates for example). > ------------------ > > The current motto in RELs is - grant only the rights that are mentioned. > Thus in a prohibition model - it should simply be assign all the rights > except the ones mentioned. For this reason, there is no need to ever express > a set of rights that are forbidden. > > > If we assume every action that is not explicitly permitted is forbidden, then > we lose the distinction between what is forbidden and what is unregulated > (i.e., we force every agreement to regulate every action). As a result, > agreements will often contradict one another, even when the intentions of the > agreements' writers are not in conflict. > > To illustrate the idea, suppose that Alice's mother says she may have a > cookie (i.e., issues an agreement giving Alice this right) and Alice's father > says she may play outside (i.e., issues an agreement giving Alice this > right). If I've understood your suggestion correctly, then you would say > that Alice's mother permits Alice to have a cookie and forbids Alice from > doing anything else, including playing outside and even breathing; similarly, > Alice's father permits Alice to play outside and forbids Alice to do anything > else, including eating a cookie and breathing. So, while the parents agree > that Alice is not allowed to breath, they disagree over whether she may eat a > cookie and whether she may play outside. That is, the agreement issued by > Alice's mother contradicts the agreement issued by Alice's father (and the > overall interpretation is just plain silly). > > It is not clear how we could "fix" the agreements. Certainly, the agreements > could be rewritten so that Alice's mother and father both permit eating a > cookie, playing outside, and breathing (along with all other unobjectionable > activities). But what if Alice's mother doesn't care about whether Alice may > play outside? Then we're forcing the mother to regulate an action that she > doesn't care about and, if she permits when the father forbids (or > vice-versa), we get a conflict. Ok - I see your objections. I have been working on a similar problem for a while and have sort of invented a new concept for rights which I have been calling "Level 1 vs Level 2 rights". This work has been raised from a smaller sub project on a OS kernel level DRM. Basically, level 1 rights are core rights that can be enforced on any system, regardless of OS, hardware etc. I haven't identified all of these rights, but they are basically quite a few common access rights like - read, modify, and execute (i.e. very similar to the file permission security). Level 2 rights are rights that have specific meaning to the data and application in question. For example, the concept of a printable page has meaning in a word processor but has no meaning for wireframe models for games. So far what we are working on, is that, level 1 rights are mandatory - they are either allowed or disallowed. Level 2 rights will be dependent on the application and the data involved, and should be taken as "rights holder doesn't really care". Thus - for humans, breathing would be a level 1 right, while playing outside and eating cookies would be level 2 rights. Maybe this type of approach will solve this issue - as regardless of which prohibition model we use, the issues you mention will remain. > ------------------ > > suppose an agreement says only that Alice may print 5 copies of the report. > Your suggestion could be equivalent to "if Alice has not made 5 copies, then > she may print the report and is forbidden to do anything else; otherwise, she > is forbidden to do any action". Alternatively, you could mean "if Alice has > not made 5 copies, then she may print the report and she is forbidden to do > anything else to the report; otherwise, there is no action that she can do > legitimately that involves the report". > > > On the examples you mention (with Alice printing) - I am not sure what the > difference is. > > > The first interpretation implies that Alice is forbidden to breath; the > second implies only that she is forbidden to breath on the report (or do > anything else *to the report*, other than possibly printing). > Understood - and although in context I was only thinking of the object in the digital sense; which is incorrect as ODRL should be usable as a normal object. > ------------- > > I would like to read your journal paper. > > > The current version can be downloaded from > http://www.cs.cornell.edu/People/vickyw/tmp/PucellaWeissman.pdf (.ps). > Comments very welcome (though, for reasons of personal sanity, I probably > won't put in changes until the paper has come back from review). > Will have a look - not sure I have time in the near future to comment on it 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 vickyw at cs.cornell.edu Wed Jan 18 05:59:41 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 12, Issue 5 Message-ID: <2EE48095D8C21643B0B70EC95F9BFBAFD85F06@EXCHVS1.cs.cornell.edu> I do not see why licenses for a particular object should be evaluated as a set - because there could be specific reasons for having multiple licenses (different validity dates for example). In ODRL v. 1.1, an agreement can grant a right based on whether a permission does (or does not) hold. If ODRL v 2.0 keeps this feature, then some interactions between agreements seem unavoidable. I think the v2.0 specification should formally define when a permission (e.g., Alice may download the file) or prohibition follows from a set of agreements. Riccardo and I took a stab at this for v1.0 in the journal paper I sent out yesterday, but whether our design decisions best meet the needs of the community... I just don't know. Best, Vicky From renato at odrl.net Wed Jan 18 15:46:14 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: <1137415350.7272.50.camel@iduna> References: <1136968801.7279.11.camel@iduna> <1137415350.7272.50.camel@iduna> Message-ID: <1C01CDAF-1EE1-4EDA-93EB-0199D2388F16@odrl.net> On 16 Jan 2006, at 22:42, Alapan Arnab wrote: > So if "print" is an action, how do I put a constraint to it? Have a look at a example here: (We are not saying this is the final way, but is a proposal...) Cheers... Renato Iannella National ICT Australia (NICTA) From aarnab at cs.uct.ac.za Thu Jan 19 03:07:20 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: <1C01CDAF-1EE1-4EDA-93EB-0199D2388F16@odrl.net> References: <1136968801.7279.11.camel@iduna> <1137415350.7272.50.camel@iduna> <1C01CDAF-1EE1-4EDA-93EB-0199D2388F16@odrl.net> Message-ID: <1137600440.8775.1.camel@iduna> Hi Hi, > > So if "print" is an action, how do I put a constraint to it? > > Have a look at a example here: > > > > (We are not saying this is the final way, but is a proposal...) Thanks - I think I understand. However, I still think that the action element does not really serve a purpose. In the issues-list, the example is: asset01 However, I think the permission model from ODRL 1.0 is much more elegant, and the above example would look: asset01 I do understand that the current approach was due to the prohibition model - but _if_ the prohibition model is changed, then the action model is not really necessary. 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 Thu Jan 19 17:24:11 2006 From: aarnab at cs.uct.ac.za (aarnab@cs.uct.ac.za) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] Updated Model Message-ID: <26732.212.51.126.129.1137651851.squirrel@webmail.cs.uct.ac.za> Hi, I have updated the model with regards to NextRights as shown in the attached image. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: ODRL_new.png Type: image/png Size: 83091 bytes Desc: not available Url : http://lists.odrl.net/pipermail/odrl-version2/attachments/20060119/89ceeca9/ODRL_new.png From renato at odrl.net Mon Jan 23 17:50:57 2006 From: renato at odrl.net (Renato Iannella) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] Updated Model In-Reply-To: <26732.212.51.126.129.1137651851.squirrel@webmail.cs.uct.ac.za> References: <26732.212.51.126.129.1137651851.squirrel@webmail.cs.uct.ac.za> Message-ID: On 19 Jan 2006, at 16:24, wrote: > I have updated the model with regards to NextRights as shown in the > attached image. Thanks Alapan - perhaps we can simplify further... Since we have TransferRights as a specialised Action, then TransferRights will always point to a set of rights, hence we could point it direct to License? Cheers... Renato Iannella National ICT Australia (NICTA) From aarnab at cs.uct.ac.za Mon Jan 23 18:20:38 2006 From: aarnab at cs.uct.ac.za (aarnab@cs.uct.ac.za) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] Another model update Message-ID: <10898.212.51.126.129.1138000838.squirrel@webmail.cs.uct.ac.za> Hi, After considering some of the comments from Vicky with regards to prohibition and some comments from Renato, I have updated my proposed model (attached). Maybe this approach makes more sense. Regards Alapan PS. I will be out of a regular net connection for about 2 weeks - so apologies in advance if I don't reply to emails. -------------- next part -------------- A non-text attachment was scrubbed... Name: ODRL_new.png Type: image/png Size: 82767 bytes Desc: not available Url : http://lists.odrl.net/pipermail/odrl-version2/attachments/20060123/92d69c4b/ODRL_new.png From aarnab at cs.uct.ac.za Mon Jan 23 18:24:31 2006 From: aarnab at cs.uct.ac.za (aarnab@cs.uct.ac.za) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] Updated Model In-Reply-To: References: <26732.212.51.126.129.1137651851.squirrel@webmail.cs.uct.ac.za> Message-ID: <10930.212.51.126.129.1138001071.squirrel@webmail.cs.uct.ac.za> Hi, If you look at the previous model, you will see that is exactly what I had before. However, as it was correctly pointed out - that approach is misleading as it leads to the possibility of having different, unusable license types as one of the attributes. Thus the separation is a better approach - but what could be done is to remove TransferRights and have NextRights as a special action (thus removing one level of the tree). Alapan > > On 19 Jan 2006, at 16:24, > wrote: > >> I have updated the model with regards to NextRights as shown in the >> attached image. > > Thanks Alapan - perhaps we can simplify further... > > Since we have TransferRights as a specialised Action, > then TransferRights will always point to a set of rights, hence > we could point it direct to License? > > Cheers... Renato Iannella > National ICT Australia (NICTA) > > > _______________________________________________ > ODRL-Version2 mailing list > ODRL-Version2@odrl.net > http://lists.odrl.net/mailman/listinfo/odrl-version2 From Susanne.Guth at gmx.net Sun Jan 29 00:38:03 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: <1136968801.7279.11.camel@iduna> Message-ID: <5249.1138455483@www061.gmx.net> Hi Alapan, first of all I have some more comments on your paper. I would like to have them separately from the discussions we already have... here we go: 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? 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? 3.) In Section 3 you define 3.Bargaining, in Section 3.3 you describe "Bartering". Which one is the right term? 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? 5.) What language would be suitable as "language to define rules"? RuleML? 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. :)) 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 > -- 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 Susanne.Guth at gmx.net Sun Jan 29 01:46:48 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: <1137413069.7272.43.camel@iduna> Message-ID: <25143.1138459608@www061.gmx.net> Stefan, Alapan, everybody! Please have a short look at an early paper from myself. I defined the various term, ticket, right, contract, etc. Maybe we can adapt some term officially for the ODRL community, so that we can be clear in future? What do you think? see Chapter 5 Susanne > > Hi, > Comments for Steven's email: > > > > 1. Bidding would probably be a large-scale addition and if so might slow > down dissemination of ODRL at a critical time. > Not really - bidding is just an extension to the type elements and thus > has no real effect on the overall license structure. > > > > 2. What is a "ticket" in your revamped model (or, for that matter, in > the original version 2. I admit I've forgotten)? How is it different from > "contract"? > A ticket in both models is essentially the same as a ticket for a > concert, the bus etc - it gives the bearer a set of rights from the > rights holder; and the bearer is not a defined party (so I could give > you my ticket and you will have access). > > 3. The use of the word 'contract' will be appropriate for negotiations > between corporations and bureacracies, but might put off the average > consumer wishing to download music or a few pages of text, say. In this situation, > in my opinion, "Agreement" is much more user-friendly. Admittedly, the > average user will not need to be looking under the hood, so "Agreement" could > be used in pull-down menus etc., and 'contract' in the actual code. But > still, it would be more clean to have the same word used at both levels, > unless there is a legal reason why the word 'contract' has to be used; I suspect > that there is not. ("A rose by any other name would smell as sweet"). > > > Agreed - but I think it is also a problem with current DRM systems - DRM > systems are enforcement of license contracts not copyright - I think it > is better for consumers to know and accept the fact instead of the > current scenario where no-one knows what the exact situation is? > > 4. Section 4.5, "Other Issues": Unfortunately in all of these I seem to > understand too little about the situation to see a problem. I think I'll > take the 'glass-is-half-full' approach and treat this as evidence that ODRL 2 > is almost ready for release. :-) > > > Well I do have a full blown XML schema ... but I am not sure using it > would be a good idea ;) > > steven rowat > > > > > > >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 > > > > > >Attachment converted: Macintosh HD:new_odrl_20060111.pdf (PDF /CARO) > (000A9288) > > >_______________________________________________ > > >ODRL-Version2 mailing list > > >ODRL-Version2@odrl.net > > >http://lists.odrl.net/mailman/listinfo/odrl-version2 > > > > > > _______________________________________________ > > 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/ Telefonieren Sie schon oder sparen Sie noch? NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie From Susanne.Guth at gmx.net Sun Jan 29 01:46:48 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: <1137413069.7272.43.camel@iduna> Message-ID: <25143.1138459608@www061.gmx.net> Stefan, Alapan, everybody! Please have a short look at an early paper from myself. I defined the various term, ticket, right, contract, etc. Maybe we can adapt some term officially for the ODRL community, so that we can be clear in future? What do you think? see Chapter 5 Susanne > > Hi, > Comments for Steven's email: > > > > 1. Bidding would probably be a large-scale addition and if so might slow > down dissemination of ODRL at a critical time. > Not really - bidding is just an extension to the type elements and thus > has no real effect on the overall license structure. > > > > 2. What is a "ticket" in your revamped model (or, for that matter, in > the original version 2. I admit I've forgotten)? How is it different from > "contract"? > A ticket in both models is essentially the same as a ticket for a > concert, the bus etc - it gives the bearer a set of rights from the > rights holder; and the bearer is not a defined party (so I could give > you my ticket and you will have access). > > 3. The use of the word 'contract' will be appropriate for negotiations > between corporations and bureacracies, but might put off the average > consumer wishing to download music or a few pages of text, say. In this situation, > in my opinion, "Agreement" is much more user-friendly. Admittedly, the > average user will not need to be looking under the hood, so "Agreement" could > be used in pull-down menus etc., and 'contract' in the actual code. But > still, it would be more clean to have the same word used at both levels, > unless there is a legal reason why the word 'contract' has to be used; I suspect > that there is not. ("A rose by any other name would smell as sweet"). > > > Agreed - but I think it is also a problem with current DRM systems - DRM > systems are enforcement of license contracts not copyright - I think it > is better for consumers to know and accept the fact instead of the > current scenario where no-one knows what the exact situation is? > > 4. Section 4.5, "Other Issues": Unfortunately in all of these I seem to > understand too little about the situation to see a problem. I think I'll > take the 'glass-is-half-full' approach and treat this as evidence that ODRL 2 > is almost ready for release. :-) > > > Well I do have a full blown XML schema ... but I am not sure using it > would be a good idea ;) > > steven rowat > > > > > > >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 > > > > > >Attachment converted: Macintosh HD:new_odrl_20060111.pdf (PDF /CARO) > (000A9288) > > >_______________________________________________ > > >ODRL-Version2 mailing list > > >ODRL-Version2@odrl.net > > >http://lists.odrl.net/mailman/listinfo/odrl-version2 > > > > > > _______________________________________________ > > 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/ Telefonieren Sie schon oder sparen Sie noch? NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie From Susanne.Guth at gmx.net Sun Jan 29 02:08:27 2006 From: Susanne.Guth at gmx.net (Susanne Guth) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] odrl v2.0 example References: <1137415350.7272.50.camel@iduna> Message-ID: <28761.1138460907@www061.gmx.net> Alapan and all, please have a look at the paper that provides the basis of ODRL Version 2.0 data model: It also includes a schema and some xml examples. Following the odrl v2.0 model today a permission with constraint would look as follows print ebook123 play notGraterThan 1 We decided not to put any examples on the web site yet because the model was not final, but maybe to avoid confusions in the future we should publish some non-binding examples. What do you guys think? Susanne > > Hi, > Responses to Renato's email > > Some of my other comments include: > > > > 4.5.1 - if we can think of an elegant way to support containers in > > the model, then that would be good, but we need to make it simple and > > not complicate implementations. > > > See my response to Susanne's email. > > > 4.5.5 - "actions" are the lower level "data dictionary" terms like, > > print, display etc. > > The Permission/Prohibition, is the parent of these. > > > So if "print" is an action, how do I put a constraint to it? In ODRL > 1.1, "print" was a permission, thus: > > 1 > > > would have given a permission to print maximum of 1 time. However, in > the ODRL v2.0 it becomes: > > > > 1 > > which is not correct as an additional permission (e.g. display) could > also be linked under permissions and then what does the count refer to? > It's for this reason, none of the examples I provide have any > constraints. > > Alapan > > > > Cheers... Renato Iannella > > National ICT Australia (NICTA) > > > > > > _______________________________________________ > > 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 Steven_Rowat at sunshine.net Sun Jan 29 16:13:55 2006 From: Steven_Rowat at sunshine.net (Steven Rowat) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] New ODRL v2.0 Model Message-ID: Hi Suzanne, > >see Chapter 5 Thanks, this was very helpful and very clear about how you would like "Ticket" to operate. I have no trouble with it. And I see also that "contract" is going to be an unavoidable word. I only suggest, as before, that for front-line consumer applications, "agreement" might be better to have on the pull-down menus. But this would be a call made by whoever writes the software to run on the browser, so it's not really an issue in writing ODRL. steven > >Susanne > >> >> Hi, >> Comments for Steven's email: >> > >> > 1. Bidding would probably be a large-scale addition and if so might slow >> down dissemination of ODRL at a critical time. >> Not really - bidding is just an extension to the type elements and thus >> has no real effect on the overall license structure. >> > >> > 2. What is a "ticket" in your revamped model (or, for that matter, in >> the original version 2. I admit I've forgotten)? How is it different from >> "contract"? >> A ticket in both models is essentially the same as a ticket for a >> concert, the bus etc - it gives the bearer a set of rights from the >> rights holder; and the bearer is not a defined party (so I could give >> you my ticket and you will have access). >> > 3. The use of the word 'contract' will be appropriate for negotiations >> between corporations and bureacracies, but might put off the average >> consumer wishing to download music or a few pages of text, say. In this >situation, >> in my opinion, "Agreement" is much more user-friendly. Admittedly, the >> average user will not need to be looking under the hood, so "Agreement" >could >> be used in pull-down menus etc., and 'contract' in the actual code. But >> still, it would be more clean to have the same word used at both levels, >> unless there is a legal reason why the word 'contract' has to be used; I >suspect >> that there is not. ("A rose by any other name would smell as sweet"). >> > >> Agreed - but I think it is also a problem with current DRM systems - DRM >> systems are enforcement of license contracts not copyright - I think it >> is better for consumers to know and accept the fact instead of the >> current scenario where no-one knows what the exact situation is? >> > 4. Section 4.5, "Other Issues": Unfortunately in all of these I seem to >> understand too little about the situation to see a problem. I think I'll >> take the 'glass-is-half-full' approach and treat this as evidence that >ODRL 2 >> is almost ready for release. :-) >> > >> Well I do have a full blown XML schema ... but I am not sure using it >> would be a good idea ;) >> > steven rowat >> > >> > >> > >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 >> > > >> > >Attachment converted: Macintosh HD:new_odrl_20060111.pdf (PDF /CARO) >> (000A9288) >> > >_______________________________________________ >> > >ODRL-Version2 mailing list >> > >ODRL-Version2@odrl.net >> > >http://lists.odrl.net/mailman/listinfo/odrl-version2 >> > >> > >> > _______________________________________________ >> > 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/ > >Telefonieren Sie schon oder sparen Sie noch? >NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie >_______________________________________________ >ODRL-Version2 mailing list >ODRL-Version2@odrl.net >http://lists.odrl.net/mailman/listinfo/odrl-version2 From Susanne.Guth at gmx.net Mon Jan 30 09:54:12 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: <12841.1138575252@www082.gmx.net> Hi Steven, thanks for your comments. I agree and read your earlier mail. Agreement is nicer. :) so long Susanne > > Hi Suzanne, > > > > >see Chapter 5 > > Thanks, this was very helpful and very clear about how you would like > "Ticket" to operate. I have no trouble with it. > > And I see also that "contract" is going to be an unavoidable word. I only > suggest, as before, that for front-line consumer applications, "agreement" > might be better to have on the pull-down menus. But this would be a call > made by whoever writes the software to run on the browser, so it's not really > an issue in writing ODRL. > > steven > > > > >Susanne > > > >> > >> Hi, > >> Comments for Steven's email: > >> > > >> > 1. Bidding would probably be a large-scale addition and if so might > slow > >> down dissemination of ODRL at a critical time. > >> Not really - bidding is just an extension to the type elements and thus > >> has no real effect on the overall license structure. > >> > > >> > 2. What is a "ticket" in your revamped model (or, for that matter, in > >> the original version 2. I admit I've forgotten)? How is it different > from > >> "contract"? > >> A ticket in both models is essentially the same as a ticket for a > >> concert, the bus etc - it gives the bearer a set of rights from the > >> rights holder; and the bearer is not a defined party (so I could give > >> you my ticket and you will have access). > >> > 3. The use of the word 'contract' will be appropriate for > negotiations > >> between corporations and bureacracies, but might put off the average > >> consumer wishing to download music or a few pages of text, say. In this > >situation, > >> in my opinion, "Agreement" is much more user-friendly. Admittedly, the > >> average user will not need to be looking under the hood, so "Agreement" > >could > >> be used in pull-down menus etc., and 'contract' in the actual code. But > >> still, it would be more clean to have the same word used at both > levels, > >> unless there is a legal reason why the word 'contract' has to be used; > I > >suspect > >> that there is not. ("A rose by any other name would smell as sweet"). > >> > > >> Agreed - but I think it is also a problem with current DRM systems - > DRM > >> systems are enforcement of license contracts not copyright - I think it > >> is better for consumers to know and accept the fact instead of the > >> current scenario where no-one knows what the exact situation is? > >> > 4. Section 4.5, "Other Issues": Unfortunately in all of these I seem > to > >> understand too little about the situation to see a problem. I think > I'll > >> take the 'glass-is-half-full' approach and treat this as evidence that > >ODRL 2 > >> is almost ready for release. :-) > >> > > >> Well I do have a full blown XML schema ... but I am not sure using it > >> would be a good idea ;) > >> > steven rowat > >> > > >> > > >> > >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 > >> > > > >> > >Attachment converted: Macintosh HD:new_odrl_20060111.pdf (PDF /CARO) > >> (000A9288) > >> > >_______________________________________________ > >> > >ODRL-Version2 mailing list > >> > >ODRL-Version2@odrl.net > >> > >http://lists.odrl.net/mailman/listinfo/odrl-version2 > >> > > >> > > >> > _______________________________________________ > >> > 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/ > > > >Telefonieren Sie schon oder sparen Sie noch? > >NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie > >_______________________________________________ > >ODRL-Version2 mailing list > >ODRL-Version2@odrl.net > >http://lists.odrl.net/mailman/listinfo/odrl-version2 > > > _______________________________________________ > 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 Mon Jan 30 09:54:12 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: <12841.1138575252@www082.gmx.net> Hi Steven, thanks for your comments. I agree and read your earlier mail. Agreement is nicer. :) so long Susanne > > Hi Suzanne, > > > > >see Chapter 5 > > Thanks, this was very helpful and very clear about how you would like > "Ticket" to operate. I have no trouble with it. > > And I see also that "contract" is going to be an unavoidable word. I only > suggest, as before, that for front-line consumer applications, "agreement" > might be better to have on the pull-down menus. But this would be a call > made by whoever writes the software to run on the browser, so it's not really > an issue in writing ODRL. > > steven > > > > >Susanne > > > >> > >> Hi, > >> Comments for Steven's email: > >> > > >> > 1. Bidding would probably be a large-scale addition and if so might > slow > >> down dissemination of ODRL at a critical time. > >> Not really - bidding is just an extension to the type elements and thus > >> has no real effect on the overall license structure. > >> > > >> > 2. What is a "ticket" in your revamped model (or, for that matter, in > >> the original version 2. I admit I've forgotten)? How is it different > from > >> "contract"? > >> A ticket in both models is essentially the same as a ticket for a > >> concert, the bus etc - it gives the bearer a set of rights from the > >> rights holder; and the bearer is not a defined party (so I could give > >> you my ticket and you will have access). > >> > 3. The use of the word 'contract' will be appropriate for > negotiations > >> between corporations and bureacracies, but might put off the average > >> consumer wishing to download music or a few pages of text, say. In this > >situation, > >> in my opinion, "Agreement" is much more user-friendly. Admittedly, the > >> average user will not need to be looking under the hood, so "Agreement" > >could > >> be used in pull-down menus etc., and 'contract' in the actual code. But > >> still, it would be more clean to have the same word used at both > levels, > >> unless there is a legal reason why the word 'contract' has to be used; > I > >suspect > >> that there is not. ("A rose by any other name would smell as sweet"). > >> > > >> Agreed - but I think it is also a problem with current DRM systems - > DRM > >> systems are enforcement of license contracts not copyright - I think it > >> is better for consumers to know and accept the fact instead of the > >> current scenario where no-one knows what the exact situation is? > >> > 4. Section 4.5, "Other Issues": Unfortunately in all of these I seem > to > >> understand too little about the situation to see a problem. I think > I'll > >> take the 'glass-is-half-full' approach and treat this as evidence that > >ODRL 2 > >> is almost ready for release. :-) > >> > > >> Well I do have a full blown XML schema ... but I am not sure using it > >> would be a good idea ;) > >> > steven rowat > >> > > >> > > >> > >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 > >> > > > >> > >Attachment converted: Macintosh HD:new_odrl_20060111.pdf (PDF /CARO) > >> (000A9288) > >> > >_______________________________________________ > >> > >ODRL-Version2 mailing list > >> > >ODRL-Version2@odrl.net > >> > >http://lists.odrl.net/mailman/listinfo/odrl-version2 > >> > > >> > > >> > _______________________________________________ > >> > 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/ > > > >Telefonieren Sie schon oder sparen Sie noch? > >NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie > >_______________________________________________ > >ODRL-Version2 mailing list > >ODRL-Version2@odrl.net > >http://lists.odrl.net/mailman/listinfo/odrl-version2 > > > _______________________________________________ > 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 Mon Jan 30 10:11:17 2006 From: Susanne.Guth at gmx.net (Susanne Guth) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] RE: ODRL-Version2 Digest, Vol 12, Issue 3 References: <2EE48095D8C21643B0B70EC95F9BFBAFD85EF2@EXCHVS1.cs.cornell.edu> Message-ID: <1233.1138576277@www082.gmx.net> Vicky, thanks for your comprehensive comments. I would like to raise only one issue: I also think, that solely prohibitions may cause problems. Not so much because they conflict with permissions (some intelligent rule based DRM software would have to handle it) but with the simple reason, that prohibitions are hard to implement these days. All access control software I know does not on the basis of prohibitions but permissions. You can easily implement: the person p may read and edit the file f. But it is not easy to unambigously implement: person p may do everything but edit. If the only two possible rights are "read" and "edit" than the software could conclude that p may read. But what if the access rights are extended to "read", "edit", and "delete" ? However, I think we need to offer prohibitions, because ODRL is working on a higher level and we have concrete applications like the CC profile. So long Susanne P.S. Next, I will try to read your paper.. but I really have a hard time reading your stuff.. it doesn't have sw architectures, XML or Java code in it ;) > > (3) I'm concerned that your interpretation of permitting/prohibiting > agreements is problematic. To see why, suppose that Alice is a faculty > member of Univ. of Cape Town and a citizen of South Africa. The > university > writes two agreements, the first allows faculty members to "checkout" a > library resource for 6 months and the second allows any citizen of South > Africa to put in a request for a library resource (which is then reviewed > and > acting on accordingly). The two agreements are in conflict, because the > first forbids Alice to request a resource, since she is faculty and not > explicitly permitted in the first agreement, and the second permits Alice > to > make the request, since she is a citizen of Cape Town. In general, I > suspect > that conflicts are likely to arise unless, for each principal p, there is > at > most one agreement that permits (or denies) rights to p. An obvious > solution > is to remove implicit assumptions from agreements; that is, a > permitting/prohibiting agreement permits/forbids the actions specified > (under > the conditions given) and does not make any statements beyond that. > -- Susanne Guth susanne@odrl.net ODRL Initiative http://odrl.net/ DSL-Aktion wegen großer Nachfrage bis 28.2.2006 verlängert: GMX DSL-Flatrate 1 Jahr kostenlos* http://www.gmx.net/de/go/dsl From Susanne.Guth at gmx.net Mon Jan 30 10:11:17 2006 From: Susanne.Guth at gmx.net (Susanne Guth) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] RE: ODRL-Version2 Digest, Vol 12, Issue 3 References: <2EE48095D8C21643B0B70EC95F9BFBAFD85EF2@EXCHVS1.cs.cornell.edu> Message-ID: <1233.1138576277@www082.gmx.net> Vicky, thanks for your comprehensive comments. I would like to raise only one issue: I also think, that solely prohibitions may cause problems. Not so much because they conflict with permissions (some intelligent rule based DRM software would have to handle it) but with the simple reason, that prohibitions are hard to implement these days. All access control software I know does not on the basis of prohibitions but permissions. You can easily implement: the person p may read and edit the file f. But it is not easy to unambigously implement: person p may do everything but edit. If the only two possible rights are "read" and "edit" than the software could conclude that p may read. But what if the access rights are extended to "read", "edit", and "delete" ? However, I think we need to offer prohibitions, because ODRL is working on a higher level and we have concrete applications like the CC profile. So long Susanne P.S. Next, I will try to read your paper.. but I really have a hard time reading your stuff.. it doesn't have sw architectures, XML or Java code in it ;) > > (3) I'm concerned that your interpretation of permitting/prohibiting > agreements is problematic. To see why, suppose that Alice is a faculty > member of Univ. of Cape Town and a citizen of South Africa. The > university > writes two agreements, the first allows faculty members to "checkout" a > library resource for 6 months and the second allows any citizen of South > Africa to put in a request for a library resource (which is then reviewed > and > acting on accordingly). The two agreements are in conflict, because the > first forbids Alice to request a resource, since she is faculty and not > explicitly permitted in the first agreement, and the second permits Alice > to > make the request, since she is a citizen of Cape Town. In general, I > suspect > that conflicts are likely to arise unless, for each principal p, there is > at > most one agreement that permits (or denies) rights to p. An obvious > solution > is to remove implicit assumptions from agreements; that is, a > permitting/prohibiting agreement permits/forbids the actions specified > (under > the conditions given) and does not make any statements beyond that. > -- Susanne Guth susanne@odrl.net ODRL Initiative http://odrl.net/ DSL-Aktion wegen großer Nachfrage bis 28.2.2006 verlängert: GMX DSL-Flatrate 1 Jahr kostenlos* http://www.gmx.net/de/go/dsl From Susanne.Guth at gmx.net Mon Jan 30 10:29:08 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: <1137412528.7270.34.camel@iduna> Message-ID: <18665.1138577348@www082.gmx.net> 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. -- 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 Mon Jan 30 11:32:01 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 Message-ID: <5860.1138581121@www082.gmx.net> 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 großer Nachfrage bis 28.2.2006 verlängert: GMX DSL-Flatrate 1 Jahr kostenlos* http://www.gmx.net/de/go/dsl -------------- next part -------------- A non-text attachment was scrubbed... Name: ODRLv2DataModel0106.jpg Type: image/pjpeg Size: 64117 bytes Desc: not available Url : http://lists.odrl.net/pipermail/odrl-version2/attachments/20060130/9026c0f1/ODRLv2DataModel0106.bin From renato at odrl.net Mon Jan 30 15:00:07 2006 From: renato at odrl.net (Renato Iannella) 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: Thanks Susi - I like the update! > 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 :) We also need to be able to express the semantics of Permissions/ Prohibitions in the (less formal) Model. In particular, the conflict that arises when both are used in a single expression (or expressions that are merged/inherited...) In the current V2 Model, we only say that Permissions are what you are allowed to perform on the Target, and Prohibitions what you are not. Remember in V1.1 we said that Permissions are what you are allowed to perform on the target **and nothing else** - that last bit is the important difference. a) Consider the following: Permission = Display Prohibition = Print The person can display the target but not print it. What about editing? It certainly does not say I can't do it. But it does not say that I can either. How can we define the semantics of Permissions/Prohibitions so that when they both appear, it is clear what they both mean? Perhaps we need a way to indicate if they represent a "closed set" of actions? Cheers... Renato From aarnab at cs.uct.ac.za Mon Jan 30 19:53:31 2006 From: aarnab at cs.uct.ac.za (Alapan Arnab) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] Formalising ODRL Message-ID: <1138611211.8543.0.camel@iduna> Hi, I think there is a need to formalise ODRL v2.0, both using UML modelling and using logic constructs like Vicky's paper on ODRL 1.1, before it can be "stabilised". Unfortunately, I am not very experienced with logic structures and thus I am not too confident on the correctness of my work; but I hope it is correct. So, I will kick off first, and I have based the initial work on how Vicky and Ricardo Pucella's paper. I have revised (again) the ODRL v2 model (attached), so first a few notes: PROHIBITION MODEL and INTERPRETATION --------------------------------------- The latest prohibition model brings a question of interpretation, and I think there is a need to introduce the idea of strict and relaxed interpretation. In a relaxed interpretation, permissions are either granted or denied. If there is an unlisted permission, the interpretation is that the rights holder does not care whether it is granted or not. A strict interpretation could have two sub cases - strict permission or strict prohibition. In strict permission, only the rights listed are granted. In such a case, prohibition is meaningless. In strict prohibition, only rights that are listed are denied ("All rights but"). In this case, a permission is meaningless. STATEMENT, TICKET AND CONTRACTS ------------------------------- Like Vicky, I do not think there is a need for these distinctions. This model is further complicated as there it will be very difficult to enforce the restrictions in XML schemas alone, and will need separate XSLT stylesheets. It would be best that ODRL offers a few templates that can be used to demonstrate these different license types - eg offer a ticket template. CONTAINERS ---------- I am still unsure of how to express containers in UML. I think the loop idea as expressed in the Asset element, is a good way. In the formalised semantic below, a container is expressed with the keyword CONTAINER and can be one of "and, or, xor" FORMAL Step 1 ------------- This is the first step, and I have taken direction from Figure 1 in the previously mentioned paper. This would probably be a good place to start. License := involving P (Parties) regarding A* (Assets) with PS (Permission Sets) P := Assigner*.Assignee* Assigner* (Ticket case) Assigner := ar !ar Assigner.Duty* CONTAINER(Assigner) Assignee := ae !ae Assignee.Duty* CONTAINER(Assignee) Duty := d d.Constraint* CONTAINER(Duty) A element of Assets PS := Permission Permission* CONTAINER(PS) Permission := p !p p.Constraint* Constraint := c CONTAINER(Constraint) --------------------------------------------------- Hope this all makes sense ;) Kind regards Alapan PS. I am still without a regular Internet connection, so apologies in advance if I do not reply quickly. I should have a regular Internet connection from 7 Feb. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: ODRL_2_revised.png Type: image/png Size: 77838 bytes Desc: Url : http://lists.odrl.net/pipermail/odrl-version2/attachments/20060130/f332cbd3/ODRL_2_revised.png From aarnab at cs.uct.ac.za Mon Jan 30 20:03:10 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: <1138611790.8543.7.camel@iduna> Hi, Sorry didn't read this email, so my model is a bit outdated! I will have a look at the entire thread and respond soon (I hope). 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 Mon Jan 30 20:17:14 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: Message-ID: <15724.1138612634@www030.gmx.net> Hi Renato, I agree, we have to make this clear: What about distinguishing the following cases: Case 1.) Either permissions OR (exclusive) prohibitions are allowed: In this world we can follow our former spec, saying "Permissions are what you are allowed to perform on the target **and nothing else**" "Prohibitions are what you are NOT allowed to perform on the target **but everything else** is allowed." Case 2.) Permissions AND Prohibitions are allowed: In this world we could state: "Permissions are what you are allowed to perform on the target **and nothing else**" "Prohibitions are what you are explicitly NOT allowed to perform on the target **and anything else is still not allowed." With this second case, we could cover the CC licenses, I think. Don't we? +++++++++++++++ With this, we treat Prohibitions under certain conditions differently. Is that problematic? Vicky? If we run into troubles, then I would suggest to only go with solution/case 2. So long Susanne > > Thanks Susi - I like the update! > > > 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 :) > > We also need to be able to express the semantics of Permissions/ > Prohibitions in the > (less formal) Model. In particular, the conflict that arises when > both are used in > a single expression (or expressions that are merged/inherited...) > > In the current V2 Model, we only say that Permissions are what you > are allowed to > perform on the Target, and Prohibitions what you are not. > > Remember in V1.1 we said that Permissions are what you are allowed to > perform on > the target **and nothing else** - that last bit is the important > difference. > > a) Consider the following: > Permission = Display > Prohibition = Print > > The person can display the target but not print it. > > What about editing? It certainly does not say I can't do it. > But it does not say that I can either. > > > How can we define the semantics of Permissions/Prohibitions so that > when they > both appear, it is clear what they both mean? > > Perhaps we need a way to indicate if they represent a "closed set" of > actions? > > Cheers... Renato > > > _______________________________________________ > 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/ 10 GB Mailbox, 100 FreeSMS/Monat http://www.gmx.net/de/go/topmail +++ GMX - die erste Adresse für Mail, Message, More +++ From aarnab at cs.uct.ac.za Mon Jan 30 20:24:53 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: <15724.1138612634@www030.gmx.net> References: <15724.1138612634@www030.gmx.net> Message-ID: <1138613093.8543.17.camel@iduna> Hi, Please see my note on interpretation on this issue on my previous email. Alapan On Mon, 2006-01-30 at 10:17 +0100, Susanne Guth wrote: > Hi Renato, > > I agree, we have to make this clear: > > What about distinguishing the following cases: > > Case 1.) Either permissions OR (exclusive) prohibitions are allowed: In this > world we can follow our former spec, saying > > "Permissions are what you are allowed to perform on the target **and > nothing else**" > > "Prohibitions are what you are NOT allowed to perform on the target **but > everything else** is allowed." > > Case 2.) Permissions AND Prohibitions are allowed: In this world we could > state: > > "Permissions are what you are allowed to perform on the target **and > nothing else**" > > "Prohibitions are what you are explicitly NOT allowed to perform on the > target **and anything else is still not allowed." > > With this second case, we could cover the CC licenses, I think. Don't we? > > +++++++++++++++ > > With this, we treat Prohibitions under certain conditions differently. Is > that problematic? Vicky? If we run into troubles, then I would suggest to > only go with solution/case 2. > > So long > Susanne > > > > > > Thanks Susi - I like the update! > > > > > 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 :) > > > > We also need to be able to express the semantics of Permissions/ > > Prohibitions in the > > (less formal) Model. In particular, the conflict that arises when > > both are used in > > a single expression (or expressions that are merged/inherited...) > > > > In the current V2 Model, we only say that Permissions are what you > > are allowed to > > perform on the Target, and Prohibitions what you are not. > > > > Remember in V1.1 we said that Permissions are what you are allowed to > > perform on > > the target **and nothing else** - that last bit is the important > > difference. > > > > a) Consider the following: > > Permission = Display > > Prohibition = Print > > > > The person can display the target but not print it. > > > > What about editing? It certainly does not say I can't do it. > > But it does not say that I can either. > > > > > > How can we define the semantics of Permissions/Prohibitions so that > > when they > > both appear, it is clear what they both mean? > > > > Perhaps we need a way to indicate if they represent a "closed set" of > > actions? > > > > Cheers... Renato > > > > > > _______________________________________________ > > 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 Steven_Rowat at sunshine.net Tue Jan 31 05:12:16 2006 From: Steven_Rowat at sunshine.net (Steven Rowat) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] resumption of containers & model update Message-ID: Hi Suzanne, My reaction is that it will be much better if a 'case 1' and 'case 2' can be avoided, and there can be a consistent way to set up Permissions and Prohibitions default/overrides that will handle all situations. (At this point, I feel the same way about Alapan's most recent solution; that having two major types of dealing with Per/Pro is courting trouble). But if we go with Case 2, Suzanne, as you suggest, as the only one, the wording as you've set it out still isn't clear to me as follows: What happens in the conflict situation (where the Rightsholder sets both Permissions and Prohibitions, perhaps accidentally at different times, and they conflict)? Perhaps this could be solved by making one by default always the override - it could be either the Permission or the Prohibition, it doesn't matter, as long as it's consistent and the Rightsholder learns that this will happen. So this might be solved with the following additions [in square brackets]: >Case 2.) Permissions AND Prohibitions are allowed: In this world we could >state: > > "Permissions are what you are allowed to perform on the target **and nothing else**" > > "Prohibitions are what you are explicitly NOT allowed to perform on the >target **[UNLESS it is set as a permission, in which case it is allowed] and anything else is still not allowed, [UNLESS it is set as a permission, in which case it is allowed] " Or, it could be the other way around, with the UNLESS'es in the Permission, and the Prohibition as the overrider. steven From vickyw at cs.cornell.edu Tue Jan 31 09:29:00 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 12, Issue 12 Message-ID: <2EE48095D8C21643B0B70EC95F9BFBAFD85F69@EXCHVS1.cs.cornell.edu> Hi Susanne (and everyone else on the list :), We seem to be talking about adding two types of statements to ODRL. The first, which I call prohibitions, says that an action is forbidden if certain conditions hold. For example, a prohibition might say "printing is forbidden if the asset being printed is eArticle #712, the subject doing the printing is Alice, and Alice has not paid 25 cents". My guess is that adding prohibitions to ODRL shouldn't be too hard. (Note: this is a guess because I haven't tried to do it.) There is another type of statement that you seem interested in, call it an "all-but" statement. An all-but statement says that every action but those in some list A are permitted. Before we consider how we could add all-but statements to ODRL, lets think about why/if we really want them. Possibility 1: the agreement writer wants to use an all-but statement as an abbreviation for a longer statement. For example, she might write "permit all actions but actions a_1,.., a_n" as an abbreviation for "permit actions a_1',..., a_m' and forbid actions a_1,..., a_n". Alternatively, "permit all actions but actions a_1,.., a_n" might be an abbreviation for "permit actions a_1', ..., a_m'", where m is presumably much larger than n. Either way, if all-but statements are simply abbreviations, then I don't think we should add them to ODRL (since this will make the language longer -> harder to learn). Instead there should be a program that converts such statements to proper (no all-but) ODRL. Possibility 2: when the agreement writer says "permit all actions but actions a_1,.., a_n", she really means "forbid actions a_1,..., a_n; I do not object to any other action being performed". Suppose this is the case and the agreement writer later says "forbid action a", where a is not in {a_1, ..., a_n}. If the two statements together are not a contradiction, then the all-but statement is really just a prohibition. Otherwise, it's another beast entirely. Possibility 3: when the agreement writer says "permit all actions but a_1,.., a_n", she really means forbid a_1, ..., a_n, and permit every action that is not in {a_1,..., a_n} - even if that action was not part of the vocabulary when the agreement was made. I suspect that the "all-but" statements are either abbreviations, in which case we shouldn't add them to ODRL, or are prohibitions in disguise, in which case we can just add prohibitions and be done. Am I right? -Vicky From vickyw at cs.cornell.edu Tue Jan 31 09:41:49 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 12, Issue 13 Message-ID: <2EE48095D8C21643B0B70EC95F9BFBAFD85F6B@EXCHVS1.cs.cornell.edu> 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...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. Can BIND contain NOT? At the risk of sounding silly, if not, why not? Best, Vicky