From Susanne.Guth at gmx.net Sun Jan 14 04:26:39 2007 From: Susanne.Guth at gmx.net (Susanne Guth) Date: Sat Jun 2 13:28:06 2007 Subject: [Odrl-version2] NEW ODRLv2 Model Semantics - Working Draft Message-ID: <20070113172639.148480@gmx.net> Dear ODRL community, we proudly present, the new Working Draft of the ODRL Version 2.0 Model Semantics. The new working draft shows major revisions of the ODRL Version 2.0 Model Semantics including the Communication Entity, the Container Model, and various attributs. Please find a comprehensive list of changes within the document. Thank you for all the supportive work that has been done by the working group during the last year. All additional comments on this working draft are highly appreciated. Please make your comments by End of February, to make sure they are incorporated in the Draft Specification. Thanks and kind regards Susanne -- Susanne Guth ODRL Initiative susanne@odrl.net Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer From renato at odrl.net Tue Jan 16 16:31:21 2007 From: renato at odrl.net (Renato Iannella) Date: Sat Jun 2 13:28:06 2007 Subject: [Odrl-version2] Make it Simpler? In-Reply-To: <1167319496.6928.17.camel@iduna> References: <1167319496.6928.17.camel@iduna> Message-ID: Alapan's email and a recent paper [1] have made me re-think the ODRL V2.0 path. We have a choice of making ODRL V2.0 more complex OR we can make the CORE language simple and support extensions for related DRM implementations. That is, ODRL has a core REL aspect that does not include all the associated functions like Digital Signatures, negotiations, legal stuff etc. All that can be added with specific profiles. The idea is we keep the core language "clean" from these additional features. This is just an idea - and I welcome comments from the WG. (and happy new year to all!) Cheers Renato Iannella ODRL Initiative http://odrl.net [1] From aarnab at cs.uct.ac.za Tue Jan 16 21:04:54 2007 From: aarnab at cs.uct.ac.za (Alapan Arnab) Date: Sat Jun 2 13:28:06 2007 Subject: [Odrl-version2] Make it Simpler? In-Reply-To: References: <1167319496.6928.17.camel@iduna> Message-ID: <1168941894.6936.9.camel@iduna> I had a long chat with Helieman and Jamkhedkar (two of the authors of the paper[1] I think you were meaning to reference ...) with regards to this point. One critical point is that, while there needs to be a small core, the core also needs to have stubs that can accommodate the more complex scenarios. One of the things I was trying with my previous email was to narrow down the core requirements and identify the possible stubs. I have made some changes to the paper (mostly grammatical), but I think basing ODRL on a formalised model would be a good step. Using profiles to set up the different stubs would be the next logical step then? Alapan [1]: http://doi.acm.org/10.1145/1179509.1179522 On Tue, 2007-01-16 at 15:31 +1000, Renato Iannella wrote: > Alapan's email and a recent paper [1] have made me re-think the ODRL > V2.0 path. > > We have a choice of making ODRL V2.0 more complex OR we can make the > CORE language simple > and support extensions for related DRM implementations. > > That is, ODRL has a core REL aspect that does not include all the > associated functions like > Digital Signatures, negotiations, legal stuff etc. All that can be > added with specific profiles. > The idea is we keep the core language "clean" from these additional > features. > > This is just an idea - and I welcome comments from the WG. > > (and happy new year to all!) > > Cheers > > Renato Iannella > ODRL Initiative > http://odrl.net > > [1] id=1179522&jmp=references&coll=GUIDE&dl=GUIDE&CFID=15151515&CFTOKEN=6184 > 618> > _______________________________________________ > 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 Tue Jan 16 21:50:52 2007 From: Susanne.Guth at gmx.net (Susanne Guth) Date: Sat Jun 2 13:28:06 2007 Subject: [Odrl-version2] Make it Simpler? In-Reply-To: <1168941894.6936.9.camel@iduna> References: <1167319496.6928.17.camel@iduna> <1168941894.6936.9.camel@iduna> Message-ID: <20070116105052.42100@gmx.net> Hi Alapan, what do you exactly mean with "basing ODRL on a formalised model"? So long Susanne -------- Original-Nachricht -------- Datum: Tue, 16 Jan 2007 12:04:54 +0200 Von: Alapan Arnab An: "ODRL Version 2.0" Betreff: Re: [Odrl-version2] Make it Simpler? > I had a long chat with Helieman and Jamkhedkar (two of the authors of > the paper[1] I think you were meaning to reference ...) with regards to > this point. One critical point is that, while there needs to be a small > core, the core also needs to have stubs that can accommodate the more > complex scenarios. One of the things I was trying with my previous email > was to narrow down the core requirements and identify the possible > stubs. > > I have made some changes to the paper (mostly grammatical), but I think > basing ODRL on a formalised model would be a good step. Using profiles > to set up the different stubs would be the next logical step then? > > Alapan > [1]: http://doi.acm.org/10.1145/1179509.1179522 > On Tue, 2007-01-16 at 15:31 +1000, Renato Iannella wrote: > > Alapan's email and a recent paper [1] have made me re-think the ODRL > > V2.0 path. > > > > We have a choice of making ODRL V2.0 more complex OR we can make the > > CORE language simple > > and support extensions for related DRM implementations. > > > > That is, ODRL has a core REL aspect that does not include all the > > associated functions like > > Digital Signatures, negotiations, legal stuff etc. All that can be > > added with specific profiles. > > The idea is we keep the core language "clean" from these additional > > features. > > > > This is just an idea - and I welcome comments from the WG. > > > > (and happy new year to all!) > > > > Cheers > > > > Renato Iannella > > ODRL Initiative > > http://odrl.net > > > > [1] > id=1179522&jmp=references&coll=GUIDE&dl=GUIDE&CFID=15151515&CFTOKEN=6184 > > 618> > > _______________________________________________ > > 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 cantoergosum@guth.it http://cantoergosum.guth.it/ Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer From Susanne.Guth at gmx.net Tue Jan 16 21:50:52 2007 From: Susanne.Guth at gmx.net (Susanne Guth) Date: Sat Jun 2 13:28:06 2007 Subject: [Odrl-version2] Make it Simpler? In-Reply-To: <1168941894.6936.9.camel@iduna> References: <1167319496.6928.17.camel@iduna> <1168941894.6936.9.camel@iduna> Message-ID: <20070116105052.42100@gmx.net> Hi Alapan, what do you exactly mean with "basing ODRL on a formalised model"? So long Susanne -------- Original-Nachricht -------- Datum: Tue, 16 Jan 2007 12:04:54 +0200 Von: Alapan Arnab An: "ODRL Version 2.0" Betreff: Re: [Odrl-version2] Make it Simpler? > I had a long chat with Helieman and Jamkhedkar (two of the authors of > the paper[1] I think you were meaning to reference ...) with regards to > this point. One critical point is that, while there needs to be a small > core, the core also needs to have stubs that can accommodate the more > complex scenarios. One of the things I was trying with my previous email > was to narrow down the core requirements and identify the possible > stubs. > > I have made some changes to the paper (mostly grammatical), but I think > basing ODRL on a formalised model would be a good step. Using profiles > to set up the different stubs would be the next logical step then? > > Alapan > [1]: http://doi.acm.org/10.1145/1179509.1179522 > On Tue, 2007-01-16 at 15:31 +1000, Renato Iannella wrote: > > Alapan's email and a recent paper [1] have made me re-think the ODRL > > V2.0 path. > > > > We have a choice of making ODRL V2.0 more complex OR we can make the > > CORE language simple > > and support extensions for related DRM implementations. > > > > That is, ODRL has a core REL aspect that does not include all the > > associated functions like > > Digital Signatures, negotiations, legal stuff etc. All that can be > > added with specific profiles. > > The idea is we keep the core language "clean" from these additional > > features. > > > > This is just an idea - and I welcome comments from the WG. > > > > (and happy new year to all!) > > > > Cheers > > > > Renato Iannella > > ODRL Initiative > > http://odrl.net > > > > [1] > id=1179522&jmp=references&coll=GUIDE&dl=GUIDE&CFID=15151515&CFTOKEN=6184 > > 618> > > _______________________________________________ > > 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 cantoergosum@guth.it http://cantoergosum.guth.it/ Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer From eetu.luoma at drelma.com Tue Jan 16 21:58:07 2007 From: eetu.luoma at drelma.com (Eetu Luoma) Date: Sat Jun 2 13:28:06 2007 Subject: [Odrl-version2] Make it Simpler? In-Reply-To: References: <1167319496.6928.17.camel@iduna> Message-ID: <60665.88.114.32.146.1168945087.squirrel@webmail.axxion.fi> Agree. I believe major part of the extra functions relate to attempt to formalize copyright contract contents and associated processes. I'd suggest that an "ODRL Copyright Contract Profile" will be created and, once finished, we'll be able to see whether some functions belong to the core or the profile. Such WG for creating profile has now one volunteer :) -Eetu > > Alapan's email and a recent paper [1] have made me re-think the ODRL > V2.0 path. > > We have a choice of making ODRL V2.0 more complex OR we can make the > CORE language simple > and support extensions for related DRM implementations. > > That is, ODRL has a core REL aspect that does not include all the > associated functions like > Digital Signatures, negotiations, legal stuff etc. All that can be > added with specific profiles. > The idea is we keep the core language "clean" from these additional > features. > > This is just an idea - and I welcome comments from the WG. > > (and happy new year to all!) > > Cheers > > Renato Iannella > ODRL Initiative > http://odrl.net > > [1] id=1179522&jmp=references&coll=GUIDE&dl=GUIDE&CFID=15151515&CFTOKEN=6184 > 618> > _______________________________________________ > ODRL-Version2 mailing list > ODRL-Version2@odrl.net > http://lists.odrl.net/mailman/listinfo/odrl-version2 > From Steven_Rowat at sunshine.net Wed Jan 17 08:27:48 2007 From: Steven_Rowat at sunshine.net (Steven Rowat) Date: Sat Jun 2 13:28:06 2007 Subject: [Odrl-version2] Make it Simpler? In-Reply-To: <60665.88.114.32.146.1168945087.squirrel@webmail.axxion.fi> References: <1167319496.6928.17.camel@iduna> <60665.88.114.32.146.1168945087.squirrel@webmail.axxion.fi> Message-ID: Hi, I also agree. I find the Jamkhedkar et al. paper has several convincing arguments. I'm glad it's being discussed! I would like to add the following two thoughts: 1. Such simplification will help to solve the problem of individual versus corporate/bureaucratic control of the DRM system. That is, the current large-scale monolithic DRMs will likely be weighted in favour of large organizations that can control who gets entry into the system (a danger I outlined in more detail in my web discussions of this issue). I believe that individuals creating work that gets used by individuals, without large group control, is a potentially enormous benefit of the Internet and DRM working together. It seems clear to me that a simplified REL with smaller extensions that can be developed and modified by third parties (including by non-profit groups) will allow these two poles of that continuum (individual versus group control) more likelihood of co-existing. For instance, the total needs of the following scenario: music file created by A -> downloaded for a fee by B -> can be played anywhere but not changed or resold. are far simpler than the needs of: music file created by A -> can be resold by corporation X as long as it is only changed via parameters Q -> can be resold by corporation Z as long as A gets N% of the royalties that Z pays X - can be played once on hardware B or M, but not transferred to hardware L, or.... Anyway, you get the picture. The second scenario can go on forever. What the Jamkhedkar paper is telling us is that there is a core idea about 'muisic file created by A' that is all the REL needs to specify; and that most of what is in both the above scenarios is not part of this. I believe that making a core simplified REL will make it far more likely that the first scenario above can become a reality, since the extra parts required to be built by 'middleware' are also simple. If we wait for a REL that can satisfy the second scenario, then it seems likely that either it won't happen at all, or that the costs of delivering the functions will be so high that most them will be exlcuded for individuals - possibly even all of them. 2. Since both Xrml and ODRL are developed and developing, such a refocusing will allow them to specialize and cease to be antagonists. I suggest it makes the most sense for ODRL to become the core REL, and for XrML to fragment and specialize in middleware implementations. Consider these three quotes from the paper: "...this simplification will require manufacturers of rendering devices to support only the core of the language, allowing heavy-duty rights management functionalities to be implemented on the server side, where they belong." and: "Because rights are much less transient than technology, their expression should not be tied to any language. " and: "Thus, the core REL should not specify how rights should be created, authenticated, communicated, audited,..." These ideas suggest to me that the core DRM REL should be concerned with long-term human rights; essentially with ethical standards being met; standards that have evolved over millennia. The middleware interacts in real-time with the current social structure to implement this, in both hardware and software. I suggest that, like morality, any general human language is free. Any implementation of a language for the purpose of buying and selling, or distributing, in real-time, does not need to be free and usually isn't. Therefore the ODRL, which is free and defined as remaining as such, is more appropriate for the core, and XrML, which charges a fee and is defined as remaining as such, is more appropriate to develop the middleware extensions to the ODRL core. Steven Rowat > > This is just an idea - and I welcome comments from the WG. >> >> (and happy new year to all!) >> >> Cheers >> >> Renato Iannella >> ODRL Initiative >> http://odrl.net >> >> [1] > id=1179522&jmp=references&coll=GUIDE&dl=GUIDE&CFID=15151515&CFTOKEN=6184 > > 618> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.odrl.net/pipermail/odrl-version2/attachments/20070116/c2ecb314/attachment.html From Steven_Rowat at sunshine.net Thu Jan 18 09:20:35 2007 From: Steven_Rowat at sunshine.net (Steven Rowat) Date: Sat Jun 2 13:28:06 2007 Subject: [Odrl-version2] Make it Simpler? Message-ID: Hi, I have some added thoughts, also derived from reading the Jamkhedkar et al. paper. Primarily, I would like to suggest that Jamkhedkar's analogy with the simple tuples at the core of an SQL database may be the place to start. If the REL core can be made *very* simple, then a huge amount of 'plug-ins' for middleware can be offloaded, and ODRL might be much more quickly/widely adopted. What I thought about last night, in attempting to simplify this as much as possible, was how the creation of a 'new idea' or 'work of art' comes about: it is almost always the product of a analysis/synthesis thought in the brain of a single person. That person then makes an embodiment, a representation of it, in physical object form, in order to communicate the idea to others. (Person) Creating --> created idea (object) This is the key tuple, the relation between the Person (who may occasionally be a group; so we can use the term 'Party' to cover both), and the embodiment of their idea. This embodiment is in some medium, and when identified with a tag becomes a recognizable object or 'Work'. So we have: Party - > Work That's as simple as it gets, I think, and if ODRL did nothing more than allow XML expression of worldwide databases that listed each tuple of Party and Work (Einstein, Paper on Special Relativity), including contact address for Einstein, then middleware could conceivably furnish everything else. However, I don't think we need to go that simple (almost, but not quite). The next step, which makes it a 3-tuple, would be: Party -> Work -> User The relation between Work and User is where the huge complexity lies, and the point of the Jamkhedkar et al. paper, as I see it, is that ODRL and Xrml have gone too far into trying to manage that relation. As others have indicated, stubs can be embedded on left-hand side of the 'Work -> User' relation to help in this management. However there is an unlimited number of such stubs that can be embedded. And these stubs are much more liable to change with technology and with jurisdiction (and with evolution of the Party's decisions) than are the original 'Party -> Work' 2-tuple. The original Party -> Work relation will generally last for a lifetime or lifetimes; whereas anything in the 'Work -> User' relation is liable to change; more change as we go further to the right. So the trick is how far into that second relation we need to go. It occurs to me that, as part of the Core REL, we might provide one key 'special stub': the Party can in advance specify certain basic decisions about use of their Work (free; sale; no copies; etc.), and this will facilitate quick formulation of middleware that will finish the relation - without having to resort to contacting the Party and negotiating, in many cases. However, in a sense, even that stub is secondary and on a different level than the original 2-tuple. Everything in the relation between the 'Work' and 'User' is subject to context limitation, and will be only valid locally in time or place. The 'Party -> Work' is universally valid, can be accessed by any users of the second relation. So, in sum, I suggest we start with specifying the 'Party' and 'Work' simple connection in a way that all conceivable parties can access and use, and when that is stable add a first stub into the 'Work -> Users' relation that expresses the simplest possible decisions that 'Party' can make about how 'Work' can be used. Then gradually add more complex stubs for specific situations, doing the most general ones first. And if the language used to access the Core is formulated to permit it, perhaps most or all of these additional stubs can be written by middleware providers. In other words, the proper field of the Core REL, which will be free and open source, will be information about the creator of a work (perons, group) and how to identify the work (object tag), and, to a limited degree, how the creator wishes the work to be used. Any actual implementation of a mechanism to distribute the work to other people will be developed separately from this, and can be either free or not free, depending on the decisions of the people doing the work to create the required mechanisms. There! All solved. ;-) Anyway, if you got this far, thanks for reading it. :-) Steven Rowat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.odrl.net/pipermail/odrl-version2/attachments/20070117/b2fab72f/attachment.html From renato at odrl.net Thu Jan 18 17:24:29 2007 From: renato at odrl.net (Renato Iannella) Date: Sat Jun 2 13:28:06 2007 Subject: [Odrl-version2] Make it Simpler? In-Reply-To: References: Message-ID: Steven - your comments reflects the original and high-level ODRL model: Parties<-->Assets<-->Rights Rights became the more complex of the three. We certainly need to support expressions of "offers" (your creation idea) and typical "agreements" (min of 2 parties, 1 Asset, 1 Right) The hard part is to work out the level of complexity of Rights that will be in Core. Cheers Renato Iannella ODRL Initiative http://odrl.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.odrl.net/pipermail/odrl-version2/attachments/20070118/7b00fc99/attachment.html