From vickyw at cs.cornell.edu Mon Jun 6 22:49:22 2005 From: vickyw at cs.cornell.edu (Vicky Weissman) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] RE: ODRL-Version2 Digest, Vol 6, Issue 7 Message-ID: <772EF7E386FEDF4FA6E11A9DA703A4D25E6DA8@EXCHVS1.cs.cornell.edu> Hi, Sorry for the late reply. Steven has brought up a point that I strongly agree with. I'd like to reiterate and expand on it a bit. I think ODRL would be a much more compelling language if it came with a relatively easy-to-use implementation. In other words, there should be a way for people to read/write agreements easily. Also, there should be a way for people to ask (and answer) questions about agreements, such as whether a particular action is allowed, which actions are allowed, and what can be done (if anything) to get a desired permission. Designing/building such a solution is a daunting task, at least to me, but I suspect a reasonable effort in this direction could give awesome results. Following in the Creative Commons spirit, we could choose a fragment of ODRL that would likely be of interest to many applications and design a "simple" implementation for that fragment. It still wouldn't be easy, but it could be very worthwhile. On another topic... Anyway, in either case, what I envision is that ensuring that ODRL correctly conforms to a category such as Ticket, Next Rights, or Agreement requires that the permissions code inserted by the coding app or person (Assignor) be perfectly understood by the browser, so that it can be used accurately in interacting with the Assignee. Now, how can this happen if it's 'unspecified'? It would appear there would still need to be a canonical list of acceptable terms to plug into that 'unspecified' place, or the browser wouldn't understand and know how to proceed. So that's a first point - there would still need to be categories with accepted terms, even using an 'unspecified' system This may be trivial to you. I think you might be confusing `unspecified' with `forall'. An agreement that mentions `unspecified' is an unfinished agreement. Its interpretation is the same as any other agreement that has yet to be finalized; it does not give or deny rights. It could be used as a template, an advertisement, etc. Note that the term `unspecified' would not necessarily be used in a ticket or a Next Rights. I propose that a ticket is an agreement whose assignee is a constant, say `ticket holder'. The browser would interpret `ticket holder' to be a name for whoever presents the ticket. This is not the same as the ticket giving rights to everyone, so we wouldn't want to replace `ticket holder' with every subject in the system. Next Rights is an agreement that gives a particular subject permission to grant certain rights to others, so `unspecified' would not be necessary here either. Best, Vicky From renato at odrl.net Thu Jun 9 17:03:43 2005 From: renato at odrl.net (Renato Iannella) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] Comments on Feedback Message-ID: Thanks to Vicky and Steven for their feedback and comments recently. We will endeavor to update the Model based on their comments, as well as discuss some of the more challenging questions at the WG Meeting in Lisbon [1]. Here are some answers/clarifications: S: "An overall conceptual concern I have is that you have attempted too many levels of abstraction..." V: "It seems to me that there are two types of Rights entity, an agreement and a request.." We will take this on board and review the top-level classes to see if we can rationalise them. V: "I'm assuming that the Context in a Rights entity can be extended according to the needs of the particular application. Is this right?" Yes V: "If the Context includes a `space' for textual comments and remarks, why do you need another space for the human readable formulation of the rights expression?" The comments was for *any* comments, but the "human readable" is aimed at representing the rights expression in text - so if it then the "human readable" would be "you have the right to play..." (is this useful - we are not sure?) V: "I don't understand the Request entity." S: "Examples of this would be interesting to me also" We will add more text to this section. The key idea is that the end user can enter a dialog with the rights holder and ask: "Hey, what about if I can do X with your asset Y for Z$ on Friday's?" - it will allow two-way communications instead of the current one-way (ie offers). V: "The document says `If a parent Asset with child Parts is referenced as the Target of a rights expression, then all of the Parts are considered also to be the Target of the same rights expression'. I don't understand why you would want to build this into the language." We wanted to make it clear to the owner that the inheritance relationship with Assets may lead to situations with rights over assets that includes all children assets (if they define it that way). V: "Suppose that Alice is allowed to download asset A; asset B inherits from A; and asset C inherits from B. I think it follows that Alice may download asset C. Also, if Alice transfers the right to download A to Bob, then I think Bob can access assets B and C. Is this right?" Yes. V: "Could an Action describe a set of actions, instead of naming them. For example, could an `Action' be every action that has the property of leaving the asset unchanged (this could include actions such as `downloading' and `copying', but not `changing' or `appending')?" Good question. We need to think about how that style of expression would fit. We were thinking that Actions were more definitive (eg Print). V: " In ODRL version 1.1, the set of actions was closed under AND, OR, and Exclusive-OR. Is that no longer true?" We have left that out. We believe that we can express the same in the current model with a more fine-grained approach to defining permissions with single actions in separate offers, and using Prohibitions to "stop" you doing something with something else. (again, we need to explain that more!) V: "Suppose that an agreement includes a permission whose Action is {`copy', `download'} and the exclusive Boolean flag is set. Can another agreement include a permission whose Action is {`copy'}?" S: "I skipped the 'exclusive boolean flag' paragraph the first time around since I didn't understand it" Because you have already assigned the "copy" permission to someone and you said you would not assign it to anyone else (==exlusive flag), then the cannot assign "copy". V: " What if the assigners are different? What if the assets are different? I think I'm missing the intuition behind the flag." If there are different Assigners, then their must be some agreement between them as to how to deal with exclusive rights. Perhaps one does Europe, the other does Asia. If the assets are different then you are assigning different rights - the "exclusiveness" would have to have the same asset, same owner, and same permissions. V: "Can a constraint capture the fact that an assignee has a certain property (e.g., is a student, has no outstanding fines)? ..." Good question. Will have to review this one in Lisbon. V: "In practice, what's the difference between a Duty in which the Relax flag is true and no duty at all? " The difference is that the Assignee has agreed to do the Duty. Even with Relax=False, this does not mean they don't have to do it - they still do. Some external policy may define the consequences of not doing it. V: "Could an agreement include a duty that requires an action to be done at a particular time, but not before the permission is exercised?" Yes. V: "Are you assuming that each asset a has a single owner o and, for any agreement that includes a, the assigner is o?" No - asset can have multiple rights holders - and we don't assume all will be listed in every agreement that has asset A. V: "Suppose that a user wants to do a particular action (e.g., Alice wants to download a file f). Given a set of agreements, how do we determine whether she has permission to do the desired act?" Good question. Are you sort of asking "what is the formal model to prove that the rights expression is correct" ? We need help in this area - how to practically do this is a big challenge. S: "Statements. I'm having trouble understanding how this would be used, and I would like a real-world example of this, other than the "rights template" example shown later. " A statement was introduced to satisfy the need to allow for expressions that had missing information and/or assumed stuff based on the context of the profile. The best example is with Creative Commons - all that is expressed is the permissions - no asset, not parties. S: "I would like examples of the "Object" of Duty in the real-world." The most common objects would be Payments - it is a bit like Requirements from V1.1 (We may need to find a better word than the overloaded Object) [More feedback to come....] Cheers... Renato Iannella Project Leader, NICTA, Brisbane, QLD, AUSTRALIA P: +61 7 3000 0484 F: +61 7 3000 0480 M: +61 4 1313 2206 E: renato@nicta.com.au W: http://nicta.com.au [1] From renato at odrl.net Fri Jun 10 10:34:55 2005 From: renato at odrl.net (Renato Iannella) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] Second International ODRL Workshop - Final Progam Message-ID: ============================================= Second International ODRL Workshop Lisbon, Portugal, 7-8 July 2005 *** Final Program now available *** ============================================= The Second International ODRL Workshop continues from the successful first Workshop by bringing together people from research and industry to share current experiences and discuss the continuing development of the language to ensure its future success and strength. The ODRL language expresses rights information used in the open creative industries and commercial Digital Rights Management sectors. The Workshop Program is now available. Highlights include: - Keynotes from Simon Nicholson (Sun), Jan van der Meer (Open Mobile Alliance) and Prof Miguel Dias (Adetti) - Seven research papers and invited talks - Panel session on DRM and Patents - ODRL Version 2.0 Working Group meeting The complete details, including Registration information, is available from: We look forward to seeing you in Lisbon. Susanne Guth, o2 Germany, Program Co-Chair Carlos Serrao, Adetti, Program Co-Chair Renato Iannella, NICTA, General Chair From renato at odrl.net Fri Jun 10 11:29:07 2005 From: renato at odrl.net (Renato Iannella) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] Comments on Feedback (2) Message-ID: <3ac688c97e3ce6fbe92553fc6cac7a74@odrl.net> V: "This raises an interesting question, namely how do we interpret an agreement (or set of agreements) that contradicts itself. More generally, how do we determine what's allowed/forbidden by a set of agreements? " This is a good question and always asked for ODRL. It really comes down to formalising the model so that you can "prove" that what the XML bits say is actually true (or what you intended). (This also benefits programmers!) I will ask a few more "logicians" to see if there is a practical answer. V: "My best guess is that the exclusive flag is used in agreements as a way to promise the assignee(s) that no one else is getting permission." Correct Cheers... Renato Iannella Project Leader, NICTA, Brisbane, QLD, AUSTRALIA P: +61 7 3000 0484 F: +61 7 3000 0480 M: +61 4 1313 2206 E: renato@nicta.com.au W: http://nicta.com.au From vickyw at cs.cornell.edu Sat Jun 18 01:25:55 2005 From: vickyw at cs.cornell.edu (Vicky Weissman) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] RE: ODRL-Version2 Digest, Vol 7, Issue 2 Message-ID: <772EF7E386FEDF4FA6E11A9DA703A4D25E6E09@EXCHVS1.cs.cornell.edu> Hi Renato, Thanks for the clarifications :-) From them, I've drawn the following conclusions, which may or may not be right. Please let me know if I'm on the wrong track. The first observation is that the flags in ODRL are used to state ``agreements'' (in the English sense) that cannot be written in ODRL. More specifically, agreements written in a natural language between assigners and assignees often give the permissions and obligations of both parties. This could include the statement that the assigner is not permitted to give anyone but the assignee a particular right (e.g., distribution rights). Since ODRL agreements discuss only the permissions and obligations of the assignee(s), we need a flag to capture the common ``agreement'' that binds assigners. Similarly, because each agreement mentions only one asset, we need a flag to capture the portion of an ``agreement'' that says `if an assignee a may do an action c to an asset s, then a may do c to every subpart of s'. (Alternatively, we can fix the language so that this statement is implicit.) I suspect that a better solution would be to extend ODRL so that the flags, which feel like hacks, are unnecessary, even though they might still be included for ease of use. The second observation is that ODRL draws a somewhat jagged line between what is `covered' in the language and what is external to it. For example, negotiations between a perspective assigner and a perspective assignee can be captured in ODRL through offers and requests. But the consequences of violating policies are outside ODRL's scope, as are the agreements between assigners (e.g., agreements about which owner can create agreements governing access in Asia). I don't have a good intuition for why the line should be drawn where it is being drawn. As an aside (and I apologize if I sound like a broken record, but), it seems like offers and requests are just partial agreements. There's one type of Rights entity, namely an agreement, and people can write partial agreements to advertise possible agreements, request an agreement with certain features, serve as a template, etc. "... how do we determine what's allowed/forbidden by a set of agreements? " This is a good question and always asked for ODRL...I will ask a few more "logicians" to see if there is a practical answer. Do you want me to take a stab at this? (I wouldn't be able to do a formal write-up anytime soon, but could give some options with pros/cons.) Best, Vicky From stephane at virtuosomedia.nl Sat Jun 18 02:06:51 2005 From: stephane at virtuosomedia.nl (Stephane van Hardeveld) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] RE: ODRL-Version2 Digest, Vol 7, Issue 2 In-Reply-To: <772EF7E386FEDF4FA6E11A9DA703A4D25E6E09@EXCHVS1.cs.cornell.edu> References: <772EF7E386FEDF4FA6E11A9DA703A4D25E6E09@EXCHVS1.cs.cornell.edu> Message-ID: <42B2F51B.4070806@virtuosomedia.nl> Vicky Weissman wrote: > Hi Renato, > > Thanks for the clarifications :-) From them, I've drawn the following > conclusions, which may or may not be right. Please let me know if I'm on the > wrong track. > > The first observation is that the flags in ODRL are used to state > ``agreements'' (in the English sense) that cannot be written in ODRL. More > specifically, agreements written in a natural language between assigners and > assignees often give the permissions and obligations of both parties. This > could include the statement that the assigner is not permitted to give anyone > but the assignee a particular right (e.g., distribution rights). Since ODRL > agreements discuss only the permissions and obligations of the assignee(s), > we need a flag to capture the common ``agreement'' that binds assigners. > Similarly, because each agreement mentions only one asset, we need a flag to > capture the portion of an ``agreement'' that says `if an assignee a may do an > action c to an asset s, then a may do c to every subpart of s'. > (Alternatively, we can fix the language so that this statement is implicit.) > I suspect that a better solution would be to extend ODRL so that the flags, > which feel like hacks, are unnecessary, even though they might still be > included for ease of use. I am not completely up to steam with this discussion, but it looks to me that we have a problem here. ODRL should be capable to express as broad as possible (all?) possible digital formal agreements on content between parties. It seems unwise to include an (informal?) flag which then may be reinterpreted or even mis-interpreted. Which of the two will take precedence? > The second observation is that ODRL draws a somewhat jagged line between what > is `covered' in the language and what is external to it. For example, > negotiations between a perspective assigner and a perspective assignee can be > captured in ODRL through offers and requests. But the consequences of > violating policies are outside ODRL's scope, as are the agreements between > assigners (e.g., agreements about which owner can create agreements governing > access in Asia). I don't have a good intuition for why the line should be > drawn where it is being drawn. I do not follow you here. Do you mean ODRL does not allow for the unique description of parties? I believe ODRL permits all kind of identifications, building upon the knowledge and understanding of other groups more involved in this matter. As for the consequences of violations, what do you mean? ODRL describes offers and permissions etc. Violations of the terms mean the offer or right should not be granted. > > As an aside (and I apologize if I sound like a broken record, but), it seems > like offers and requests are just partial agreements. There's one type of > Rights entity, namely an agreement, and people can write partial agreements > to advertise possible agreements, request an agreement with certain features, > serve as a template, etc. > > "... how do we determine what's allowed/forbidden by a set of > agreements? " > > This is a good question and always asked for ODRL...I will ask a few more > "logicians" to see if there is a practical answer. > > Do you want me to take a stab at this? (I wouldn't be able to do a formal > write-up anytime soon, but could give some options with pros/cons.) > > Best, > Vicky I agree a formal statement on this would be more than welcome (I did not follow the whole discussion, I will try to do this this weekend.). It seems that ODRL needs a formal semantic description, besides the syntactical one? Stephane van Hardeveld From renato at odrl.net Mon Jun 20 11:21:22 2005 From: renato at odrl.net (Renato Iannella) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] RE: ODRL-Version2 Digest, Vol 7, Issue 2 In-Reply-To: <772EF7E386FEDF4FA6E11A9DA703A4D25E6E09@EXCHVS1.cs.cornell.edu> References: <772EF7E386FEDF4FA6E11A9DA703A4D25E6E09@EXCHVS1.cs.cornell.edu> Message-ID: <01ad53b4e6f187ed5c089f9064f77f3e@odrl.net> On 18 Jun 2005, at 01:25, Vicky Weissman wrote: > The first observation is that the flags in ODRL are used to state > ``agreements'' (in the English sense) that cannot be written in ODRL. > More > specifically, agreements written in a natural language between > assigners and > assignees often give the permissions and obligations of both parties. > This > could include the statement that the assigner is not permitted to give > anyone > but the assignee a particular right (e.g., distribution rights). > Since ODRL > agreements discuss only the permissions and obligations of the > assignee(s), > we need a flag to capture the common ``agreement'' that binds > assigners. Vicky - I assume you are using the "exclusive" flag as an example here. An alternative would be to use the Duty and Prohibition elements to express this (as Duties can apply to ALL parties in an agreement). Hence, we could express "exclusive" as a Duty on the Assigner, Prohibiting the assignment of the same permission to anyone else. > Similarly, because each agreement mentions only one asset, we need a > flag to > capture the portion of an ``agreement'' that says `if an assignee a > may do an > action c to an asset s, then a may do c to every subpart of s'. > (Alternatively, we can fix the language so that this statement is > implicit.) Alternatively, we could repeat all the permissions/actions on Asset S to all of the parts of Asset S - but that would be tedious? The "model" is that if we assign permissions to Asset S, and Asset S is made up of multiple parts, then our permissions are applicable to all these parts. Is there an alternative model? > The second observation is that ODRL draws a somewhat jagged line > between what > is `covered' in the language and what is external to it. For example, > negotiations between a perspective assigner and a perspective assignee > can be > captured in ODRL through offers and requests. But the consequences of > violating policies are outside ODRL's scope, as are the agreements > between > assigners (e.g., agreements about which owner can create agreements > governing > access in Asia). I don't have a good intuition for why the line > should be > drawn where it is being drawn. Vicky - I think you can cover the entire Rights value chain with ODRL. For example, a rights holder can assign distribution rights to A for Asia and B for Europe. Then A and B - as assigners - can then further slice these down to others (C, D, E, F, G). These these parties can assign their rights (assume based on geography) to end users (X, Y, Z) to final consumption rights, The question is, do we mandate that X, Y, Z know about the agreement between A, B and C, D, E, F, G - and also the agreement between the original RH and A, B ? My impression is that we don't. Communities will decide at what level the entire Rights value chain needs to be exposed and to whom. > "... how do we determine what's allowed/forbidden by a set of > agreements? " > > This is a good question and always asked for ODRL...I will ask a few > more > "logicians" to see if there is a practical answer. > > Do you want me to take a stab at this? (I wouldn't be able to do a > formal > write-up anytime soon, but could give some options with pros/cons.) Yes please! Cheers... Renato From Michael.Goulish at contractor.thomson.com Thu Jun 30 00:49:22 2005 From: Michael.Goulish at contractor.thomson.com (Michael.Goulish@contractor.thomson.com) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] Hello, ODRL! Message-ID: <8879951C280FB64993EF76F04BBEB52176DC6A@TLUSMIFHMBX01.ERF.THOMSON.COM> Hello! My name is Michael Goulish. I'm working for Thomson Gale (http://www.galegroup.com/ ) in Farmington Hills, Michigan. Thomson Gale is both a publisher and an aggregator of many types of digital content. I'm a programmer and architect, and one of my current assignments is investigating how we may be able to use ODRL, both externally (between us and our suppliers/customers) and internally (between disparate software systems). I've had some experience with standards groups, having attended meetings of the W3C DOM WG for a year as an alternate representative of my company at that time (Software AG), so I know something about how standards groups work and how they work together. ( I once, for example, suggested to the DOM WG that we walk across campus to the room where the XML Schema WG was holding a simultaneous meeting -- and barricade them in their room until they answered our questions. The suggestion was accepted, and our questions were answered! (Although we were a much smaller group, we had achieved the element of surprise!) ) My perspectives on ODRL will be those of an implementer, and a member of a large data-sales company. ( "Large" meaning -- on the order of a billion documents of various kinds. ) Please allow me to apologize in advance for the questions I am sure to ask that seem particularly ignorant and/or not especially clever. And here's my first request: Is it possible to get an advance copy of the 2.0 spec? I'm using the 1.1 spec, and the 2.0 requirements doc that I found on the website -- but I can't find a "draft" copy of 2.0 anywhere. Do you have one? (Did I not look in the right place?) Would you be comfortable releasing it in advance? And here's my first question: Is work on 2.0 pretty much complete at this point? Or is it still very much in flux? Or somewhere in between? Thanks very much. And I'm pleased to meet you-all! --------------------------------------------------------- Mick .