From renato at odrl.net Tue May 10 09:26:46 2005 From: renato at odrl.net (Renato Iannella) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] Second International ODRL Workshop Message-ID: Dear ODRL WGs and Interest group: ============================================= Second International ODRL Workshop Lisbon, Portugal, 7-8 July 2005 ============================================= 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 (DRM) sector. The Workshop will be held in Lisbon, Portugal from Thursday 7 July to Friday 8 July 2005. The Workshop Program is now available and includes Keynotes from Sun, Adetti, and numerous invited speakers and paper presentations. The complete details, including Registration information, is available from: We look forward to seeing you in Lisbon in 2005. Susanne Guth, O2, Program Co-Chair Carlos Serrao, Adetti, Program Co-Chair Renato Iannella, NICTA, General Chair From Susanne.Guth at gmx.net Mon May 16 21:17:50 2005 From: Susanne.Guth at gmx.net (Susanne Guth) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] NEW: ODRLv2 Model Semantics - Working Draft Message-ID: <28257.1116242270@www25.gmx.net> Dear ODRL Community! We are happy to announce the ODRL Version 2 Model Semantics Working Draft. It contains the new basic data model of ODRLv2 and gives some examples. The model semantics are detached of the syntax. However, ODRL syntax and core dictionary will follow. http://odrl.net/2.0/WD-ODRL-Model.html Please have a look at the datamodel and give the working group some feedback. Any comment is - as always - appreciated! Susanne Guth Renato Iannella -- Susanne Guth susanne@odrl.net ODRL Initiative http://odrl.net/ 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail +++ GMX - die erste Adresse für Mail, Message, More +++ From Steven_Rowat at sunshine.net Sun May 22 02:31:00 2005 From: Steven_Rowat at sunshine.net (Steven Rowat) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] re: ODRL V2.0 - Model Semantics Message-ID: Greetings, Here are some comments on "ODRL 2 Model Semantics" Overall, very impressive. A substantial increase in scope. After reading it, I have only two main concerns; (and only the second of these is substantive on the content): [2.0]. I have serious trouble following the visual lines in the main model diagram. For instance, under "Offer" you state: "The Offer entity must contain an Asset entity, one or both Permission and Prohibition entities, and a Party entity with Assigner (rights holder) role." However, when I try to follow this on the diagram, I at first see only one line, with no arrowhead, going straight down from Offer into Permission, and one line, with arrowhead, going from Permission into Asset. I see nothing to indicate that Prohibition and Party are indicated. Then, on second look, later, I've realized that it might be interpreted that there is also a line going across from Offer to Prohibition, but there's no way to know since there are so many lines superimposed there. I strongly suggest that the superimposed lines be separated so they run parallel instead, so that they can be followed. Especially on that first set under the Rights types, there are too many possibilities. [2.1]. An overall conceptual concern I have is that you have attempted too many levels of abstraction at once in attempting to include Transfer Rghts, Next Rights, and Tickets. This concern is in part a selfish one, because I am in this working group as a representative of those who will wish to sell their own works directly to the public (and which, as I've argued in several essays, I believe an important new possibility for the Internet and for society as a whole). Yet several of the levels of abstraction you have laid out in this model are targeted at corporations who will broker the works of others. I agree that these are welcome additions to anyone who would use ODRL if they work well. However, my concern is that ODRL runs the risk of becoming too complex and of attempting to be too many things to too many people. Of course, that is exactly what ODRL is attempting to do - be a very high level language for the management of rights. I just hope it does not, like many other things in our world at present, fail *because* of its success at doing what corporations want. [2.4] Note typo error: "...indicates the *grated* operation on the Target Asset." should be 'granted' (Or, possibly, 'gated')? Again, much thanks for this work. steven rowat p.s. I hope to see a browser that can read ODRL in...what, a week or two? ;-) From vickyw at cs.cornell.edu Mon May 23 13:40:19 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 3 Message-ID: <772EF7E386FEDF4FA6E11A9DA703A4D25E6D76@EXCHVS1.cs.cornell.edu> Hi all, I categorized my feedback using the section headings in the draft. The comments fall roughly into 3 categories: a number without a `*' indicates a question, a place where I'm double-checking my understanding, or a minor comment; a number with a single `*' is a fairly minor remark; and a number with `**' is more interesting. Best, Vicky 2.1 Rights Class Model ---------------------- 1) I'm assuming that the Context in a Rights entity can be extended according to the needs of the particular application. Is this right? 2*) 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? 3**) It seems to me that there are two types of Rights entity, an agreement and a request. A statement is a partial agreement, an offer is a type of statement where only the assignee(s) is missing; a ticket is an agreement where the assignee(s) is the ticket holder; and a Next Rights is an agreement where the assignee(s) is given permission to assign rights to others. If this is correct, then wouldn't it be simpler and clearer to remove all but the agreement and request entities and to say that partial agreements can be created to suit an application's needs (e.g. an agreement without an assignee could be used as an offer for a perspective customer). I think this approach would also address Steve Rowat's second point in his email from May 21. 4) I don't understand the Request entity. Could you send me a few examples? I'm particularly curious about Request entities in which the asset in the request is different from the asset in the permission/prohibitions, the permission/prohibition has constraints, there is more than one Assignee, and the Assigner is known. 2.2 Asset Model --------------- 1) The document calls an asset the `Target' of a permission/prohibition. In XaCML, the word means something else. So you might want to use a different word to avoid confusion (though I don't think this is a big deal). 2*) 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. In particular, suppose that an agreement gives Alice the right to copy a speech that has 5 parts. Why should it necessarily follow that Alice may copy only one of the parts, possibly taking it out of context? 3) 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? 2.4.1 Action Model ------------------ 1) It seems odd that an `Action' (singular) contains a set of Action Names (plural). 2*) 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')? 3) In ODRL version 1.1, the set of actions was closed under AND, OR, and Exclusive-OR. Is that no longer true? 4) 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'}? What if the assigners are different? What if the assets are different? I think I'm missing the intuition behind the flag. 2.4.2 Constraint Model ---------------------- 1) Can a constraint capture the fact that an assignee has a certain property (e.g., is a student, has no outstanding fines)? Can a constraint capture that an assignee does not have a certain property (e.g., is not a felon or is not on the do-not-sell-to list)? Can a constraint capture math terms with negation (e.g., number of copies is not greater than one)? 2.4 Duty Model -------------- 1) In practice, what's the difference between a Duty in which the Relax flag is true and no duty at all? 2) Could an agreement include a duty that requires an action to be done at a particular time, but not before the permission is exercised? For example, could an agreement allow me to watch as many movies as I want, provided that I pay a bill at the end of the month? If so, should duties come with consequences for noncompliance? Misc ---- 1) Are you assuming that each asset a has a single owner o and, for any agreement that includes a, the assigner is o? 2) 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? From Steven_Rowat at sunshine.net Thu May 26 03:43:25 2005 From: Steven_Rowat at sunshine.net (Steven Rowat) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] NEW: ODRLv2 Model Semantics - Working Draft Message-ID: Hi, A housekeeping issue, - I don't know if it's just my system, but I've had some strange troubles reading/accessing this link with each of four different browsers/readers: >http://odrl.net/2.0/WD-ODRL-Model.html It appears possible there are some sort of junk characters in it. My evidence: --Mozilla 1.2 reads OK online, but won't read a web archive made from it - displays it as text (code and all). --iCab 3 froze my system online (twice) when I tried to access that link, although it will read Mozilla's web archive. --IE 5 displays online as code only. It also displays a couple of junk characters before the Doctype declaration. --Golive 5 opens the page from the Moz archive, but complains that there are invalid characters. To be more specific, here's what the page looks like in IE5. This is NOT source code I'm showing you, this is the UI of the page as read and displayed: ++++ ?? ODRL V2.0 Model Semantics- Working Draft

ODRL V2.0 - Model Semantics

Working Draft: 16th May 2005

This version:
http://odrl.net/2.0/WD-ODRL-Model-20050516.html
Latest version:
Hi, Some further remarks about the ODRL 2 model, prompted largely by Vicky's interesting comments. Since the markup is getting complex, I'll separate each of my separate points with: ++++++++ +++++++++++ >2.1 Rights Class Model >The ODRL Model consist of a number of predetermined classes of rights expressions...> A small grammatical error I believe; 'consists', not 'consist' would be correct here, since the subject of the sentence ("Model") is singular. +++++++++ >The Rights entity may contain a Context that supports the following information: .../...Where do we define these terms formally? > I'm confused by the final sentence. Are you asking if there is a place in ODRL where this information can be entered? Or, are you saying that they are somehow contained in the following section, the "Rights Entities", and we should be suggesting which of them need which values of the context? +++++++++ Vicky wrote: >2*) 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? I'd like this clarified also. My untutored assmption is that it means that 'textual comments and remarks' will be machine readable - at least to the degree that they are identified in XML as being comments and remarks on this particular entity - whereas the second is a description of the entire entity that would include an abstraction of all the other information in the context. There will be some overlap between the two fields, but the 'human readable formulation' could just be containing an abstracted/summary version of all the information, including of the text/comments, whereas the latter could be more extensive in its dedicated form. +++++++++ >Statement. The Statement entity supports rights expressions that consists of any number of (or none of) entities from the complete model. This is aimed at scenarios where there is no fixed criteria for the content....> 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. If a rights template is the only real-world use, then I suggest that having a separate entity for this purpose is unnecessary. (One could just as easily make up an offer, leave out the names, and save it as a personal template.) +++++++++ Vicky wrote: >3**) It seems to me that there are two types of Rights entity, an agreement and a request......If this is correct, then wouldn't it be simpler and clearer to remove all but the agreement and request entities and to say that partial agreements can be created to suit an application's needs....>> Perhaps, but if ODRL is going to standardize the DRM process so that all user agents can understand it, then this would require a fairly subtle (and likely complex) layer of constraints on how the agreemtents could be rewritten, would it not? My guess is that this would be even more complicated and subject to pitfalls than spelling out six types of Rights Entities. However, I do believe it would be a good idea to compromise between the two positions: maybe reducing down to three or four types of Rights entities, and making two or three of them as context- or value-dependent versions of the others. +++++++++ Vicky wrote: >4) I don't understand the Request entity. Could you send me a few examples? Examples of this would be interesting to me also; I'm guessing it would be something like this: A web site has a standing Rights Entity Offer that you can download 10 songs for $10, but only play them on one machine. A person coming to the web site could send a Request that they download 5 songs for 5 dollars (and specify, probably, which songs). Or they might Request that they download the 10 songs for $15, but be able to play them on any machine. Or that they be able to download the 10 songs for $1,000, and be able to resell them to anyone. ;-) Etc. In essence, it would be a form of bartering. Especially since the Assignor could come back with a return offer. It could even work as haggling, in a formal way, in order to buy and sell large objects, like books or artworks, that might have offers and counter-offers....could it not? +++++++++ >2.2 Asset Model Vicky wrote: >In particular, suppose that an >agreement gives Alice the right to copy a speech that has 5 parts. Why >should it necessarily follow that Alice may copy only one of the parts, >possibly taking it out of context? Would this not already be convered by Constraint/Prohibition in the Agreement? In other words, the Agreement will be specifically set up by the Assignor so that this can't happen. +++++++++ Vicky wrote: >4) Suppose that an agreement includes a permission whose Action is {`copy', >`download'} and the exclusive Boolean flag is set. ......I think I'm missing the >intuition behind the flag. You're not the only one. :-). I skipped the 'exclusive boolean flag' paragraph the first time around since I didn't understand it, but this time, since you're (admirably) not going to let it go by, I searched on Google for "Exclusive boolean flag" to see if I could find something about it. Result: 8,058,044,651 pages searched. ONE RESULT. It was Vicky's statement, above! :-) LOL. After that I widened the search and did find out what it meant, which I think is "one or the other but not both", which doesn't seem so hard..... But still, in the Model 2 explanation, I'd be happier if we could avoid sentences like the last one in section 2.4.1: This made my head spin the first time around. Perhaps adding a gloss sentence would help, like: "In other words, by default ODRL 2 Actions do not use the exclusive 'or'". Still, in the larger context, is it absolutely necessary to use the exlusive 'or'? It makes the document hard to understand for people who are not academic specialists in logic. And what we are attempting here, or at least what I'm attempting , is something that will be accessible to non-specialists and specialists alike, to the degree that is feasible in the context of the job that needs to be done. +++++++++ >2.4.2 Constraint Model Vicky wrote: >1) Can a constraint capture the fact that an assignee has a certain property >(e.g., is a student, has no outstanding fines)? Can a constraint capture >that an assignee does not have a certain property (e.g., is not a felon or is >not on the do-not-sell-to list)? Very interesting suggestions. I agree it would be good to have these types of information available. +++++++++ >2.4 Duty Model Small grammatical error in first paragraph: >...the Assignee of the linked Permission is responsible for fulfill the Duty...> Should be 'for fulfilling' the Duty, I believe. +++++++++ >The Duty entity contains the following: .../..../ Object (required). The Object of a Duty may also be an Asset entity. The Object entity contains an unlimited set of Object Names which are formally defined as Profiles. > I would like examples of the "Object" of Duty in the real-world. I don't yet understand how this would function. What sorts of "Objects" are contemplated here? I'll note that the word "Object" is misused, overused, and confusingly used in many other applications. Perhaps it could be avoided here entirely, and some other word that has a hint of the desired function (which I don't understand yet) could be substituted. _______ Again, thanks to all who work on this. I'm hopeful that someday ODRL will be an important step in world information flow. steven rowat From renato at odrl.net Thu May 26 10:24:14 2005 From: renato at odrl.net (Renato Iannella) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] NEW: ODRLv2 Model Semantics - Working Draft In-Reply-To: References: Message-ID: <6b986bc5f2741437f5c979738320acc7@odrl.net> On 26 May 2005, at 03:43, Steven Rowat wrote: >> http://odrl.net/2.0/WD-ODRL-Model.html > > It appears possible there are some sort of junk characters in it. My > evidence: Hi Steven, yes there were a few junk chars at the beginning of the file. This is now fixed (and it now also conforms to HTML 4.0 Strict) Cheers Renato Iannella ODRL Initiative http://odrl.net From vickyw at cs.cornell.edu Fri May 27 00:40: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 6, Issue 5 Message-ID: <772EF7E386FEDF4FA6E11A9DA703A4D25E6D93@EXCHVS1.cs.cornell.edu> Hi, I can't answer most of Steve's questions/comments, but I have a few responses. +++++++++ Vicky wrote: 3**) It seems to me that there are two types of Rights entity, an agreement and a request......If this is correct, then wouldn't it be simpler and clearer to remove all but the agreement and request entities and to say that partial agreements can be created to suit an application's needs....>> Steven replied: Perhaps, but if ODRL is going to standardize the DRM process so that all user agents can understand it, then this would require a fairly subtle (and likely complex) layer of constraints on how the agreemtents could be rewritten, would it not? ... Vicky's reply: Maybe I'm being na?ve, but I think all we need is a constant `unspecified', which can appear anywhere in an agreement. The assigner of the agreement is allowed to replace any occurrence of `unspecified' with anything else and the assignment is complete (i.e., can be used to imply a permission) if and only if none of the fields in the assignment are `unspecified'. Why would things need to be more complicated than that? +++++++++ >2.2 Asset Model Vicky wrote: In particular, suppose that an agreement gives Alice the right to copy a speech that has 5 parts. Why should it necessarily follow that Alice may copy only one of the parts, possibly taking it out of context? Steven replied: Would this not already be convered by Constraint/Prohibition in the Agreement? In other words, the Agreement will be specifically set up by the Assignor so that this can't happen. Vicky replies: I think you're suggesting that an agreement include a permission and a prohibition, where the permission says that the speech may be copied, which implies that each part may be copied, and the prohibition says that none of the parts individually may be copied. 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? I asked this in my last email and suspect that the answer will tell us if the assumption can be worked around in the way that you suggest. I'm not sure how we can use constraints to work around the assumption. (I'm not saying we can't, I'm just saying I don't see how we can.) +++++++++ Vicky wrote: 4) Suppose that an agreement includes a permission whose Action is {`copy', `download'} and the exclusive Boolean flag is set. ......I think I'm missing the intuition behind the flag. Steve replied: ...I think [the meaning of the exclusive Boolean flag] is "one or the other but not both", which doesn't seem so hard... Vicky replies: 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. For example, consider an agreement in which Pixar gives Disney the right to distribute its latest movie. If the `exclusive' flag is set in the agreement, then Pixar is not only giving Disney the distribution right, Pixar is also promising Disney that it won't give the right to anyone else. Of course, that's just a guess. It might be the case, as Steven suggests, that the flag is an xor. But then it's not clear why the xor is linked to actions. In fact, it's not clear why you'd want xor at all. Suppose that, if a customer can't play a movie, then she can either request a refund or asked for another copy of the film (but not both). This seems like a reasonable statement for a movie vendor to make and it does involve an xor. But I think we could capture the statement without xor as a set of statements including `if a customer can't play a movie and she hasn't requested another copy, then she may ask for a refund'; `if a customer can't play a movie and hasn't requested a refund, then she may ask for another copy'; and `if a customer can't play a movie then she is forbidden to do the action of requesting another copy while simultaneously asking for a refund'. More generally, I suspect we can capture the statements that use xor in practice with ones that don't. BTW: could we capture the example in ODRL? Off the top of my head, I don't see how because each agreement mentions only one asset. Best, Vicky From Steven_Rowat at sunshine.net Sat May 28 03:14:12 2005 From: Steven_Rowat at sunshine.net (Steven Rowat) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] Model 2 Semantics - 'unspecified' Rights, canonical list, and GUI Message-ID: Hi, Vicky wrote: >Maybe I'm being na?ve, but I think all we need is a constant `unspecified', >which can appear anywhere in an agreement. The assigner of the agreement is >allowed to replace any occurrence of `unspecified' with anything else and the >assignment is complete (i.e., can be used to imply a permission) if and only >if none of the fields in the assignment are `unspecified'. Why would things >need to be more complicated than that? To answer this interesting question, for myself I'd like to know more about what the expected linkage chain is between ODRL and the enduser. Perhaps others can chime in to give an overview of where exactly ODRL is being planned to fit in, especially in the major context of the Internet and browsers. However, for now, here's an example situation I've imagined: for general Internet use, I'm assuming that ODRL is going to be used primarily by two entities that interact using it: one will be the web browser and one will be an application written around ODRL that allows content publishers to set permissions on their web pages. Of course, this latter permission-setting in ODRL could be done also by hand, by savvy coders, in the same way that an HTML/CSS page can be coded by hand. However hundreds of thousands, perhaps millions, more people will quickly be able to use ODRL if there is a coding application that relieves them of the need to learn a new language; in the same way that the explosion of web pages is due to the GUI html-coding applications. 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. However, second, and I believe important for the successful acceptance of the ODRL system, is the following: if the permissions-setter is not coding savvy (as many individual content-owners or even publishers will not be), they may appreciate the help that a coding app will give them; especially if almost all the forseeable situations can be covered by several variations that are already laid out. In other words, the canonical list may need to have 10 or even 20 terms to cover all situations of types of Rights Agreement that it will encounter in 'unspecified', but the average, say, poetry publisher, will only want to have to learn about the three or four categories of Rights Agreement that they will actually use; so an GUI application for them will only present them with those alternatives. So, I find the position I'm coming to with this reasoning is that the two positions could be combined. Your 'unspecified', with a cononical list of possibles, could be the default position, to guarantee maximum flexibilty for both developers and for coders who want to use a full range of the possible forms for the agreement; and a UI wrapper application would merely choose which ones it wants to present to its target audience of permissions-setters. And the browser would understand all of them in either case. ? steven rowat From renato at odrl.net Mon May 30 10:00:51 2005 From: renato at odrl.net (Renato Iannella) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] WG Meeting in Lisbon Message-ID: <12d64f489119094f06421b622f0a1dac@odrl.net> Dear all - we plan to have a WG meeting at the ODRL Workshop on the Friday afternoon [1] to focus on the Model and future planning. Hope to see you all there ;-) Cheers Renato Iannella ODRL Initiative http://odrl.net 2nd International ODRL Workshop 7-8 July 2005 [1]