From luomae at cc.jyu.fi Wed Dec 1 09:33:20 2004 From: luomae at cc.jyu.fi (luomae@cc.jyu.fi) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] Questions and comments for ODRL v2 Message-ID: <4867.80.222.240.224.1101854000.squirrel@webmail3.cc.jyu.fi> Greetings from snowy Central Finland, few questions and comments regarding the contents of requirements document for version 2 and development effort in general: - From requirements management point of view, should there be an indication whether certain requirements are mandatory (version 2 SHALL have..) or discretionary (version 2 SHOULD have..)? - Since it seems that ODRL is concentrating in describing the semantics of contracts, I would promote inclusion of additional context elements, which will help in the interpretation of ODRL rights expressions and supported data dictionary: 1) Geopolitical context or as Milosevic and Bond (1995) define it, the Contract Domain, 2) Content Type/Industry context (interpretation of ODRL elements with e.g. different content types). - To Requirement 1.3 concerning status information: I believe the versio 1.1 already implements this requirement. Since the status of an attribute (i.e. attribute value) cannot be stated in the license as Jaime Delgado argumented, it needs to be maintained in the server side where it can be retrieved. Therefore, an external reference needs to be included to an ODRL document. Such mechanism already exists in the ODRL context model. I find the requirement 1.22. to be rather similar. - Requirement 1.5. additional contract parties is interesting an needed. However, my concern is that can you bound a third party to certain obligation by contract made by another party (?). I believe this should not be possible. - I would additionally promote providing semantics for the "abstract" elements in the permission model, namely, ALL usage, reuse, transfer and asset management rights. It would be helpful in streamlining ODRL documents in cases where contract assigns e.g. ALL reuse rights to a party or where contract does not explicitly say which reuse rights are assigned. - Is it currently possible to express in ODRL document whether a party is allowed to publicly present (e.g. in educational context) a piece of content, otherwise than using user or target constraints? I'd find more simplified way of expressing extremely useful. BR, -Eetu Eetu Luoma, project manager Dr.Elma project (www.it.jyu.fi/elma/) luomae@cc.jyu.fi, +358 40 739 3075 From Susanne.Guth at gmx.net Wed Dec 1 12:08:53 2004 From: Susanne.Guth at gmx.net (Susanne Guth) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] Questions and comments for ODRL v2 References: <4867.80.222.240.224.1101854000.squirrel@webmail3.cc.jyu.fi> Message-ID: <19782.1101863333@www25.gmx.net> Hyv? aamu Eetu! Greeting from very hot, sunny Brisbane! > Greetings from snowy Central Finland, Thanks for all your comments. > - From requirements management point of view, should there be an > indication whether certain requirements are mandatory (version 2 SHALL > have..) or discretionary (version 2 SHOULD have..)? I'm afraid, I don't know if I understand this comment. Do you mean to design certain constellation within the ODRL data model. Please give us a short example where/why we would use mandatory requirements. > - Since it seems that ODRL is concentrating in describing the semantics of contracts, I would promote inclusion of additional context elements, which > will help in the interpretation of ODRL rights expressions and supported > data dictionary: 1) Geopolitical context or as Milosevic and Bond (1995) > define it, the Contract Domain, 2) Content Type/Industry context > (interpretation of ODRL elements with e.g. different content types). Very helpful comment. We will definately need that in our contracts. Do you know whether there is a set of commonly used attributes for contracts or even an XML namespace that we could reuse in ODRL. Otherwise we will think about just adding the two attributes that you recommended. > - To Requirement 1.3 concerning status information: I believe the versio > 1.1 already implements this requirement. Since the status of an attribute > (i.e. attribute value) cannot be stated in the license as Jaime Delgado > argumented, it needs to be maintained in the server side where it can be > retrieved. Therefore, an external reference needs to be included to an > ODRL document. Such mechanism already exists in the ODRL context model. I > find the requirement 1.22. to be rather similar. We are trying to get rid of the context element within constraints. Therefore, we will probably add a status attribute within the constraint elements, . Changing the status attribute requires editing of the license, which is a crucial operation. We assume that only trusted parties of the DRM environment may use this attribute. Please follow the discussions on this requirement and comment again. We will soon publish some working documents that enclude issues lists on each requirement. > > - Requirement 1.5. additional contract parties is interesting an needed. > However, my concern is that can you bound a third party to certain > obligation by contract made by another party (?). I believe this should > not > be possible. That is of course an important issue, although my view is that is has to be insured by the protocol and the processing DRM system (not by the expression language), that e.g. a contract like this requires the digital signature of ALL three/affected parties. > - I would additionally promote providing semantics for the "abstract" > elements in the permission model, namely, ALL usage, reuse, transfer and > asset management rights. It would be helpful in streamlining ODRL > documents in cases where contract assigns e.g. ALL reuse rights to a party > or where contract does not explicitly say which reuse rights are assigned. Good idea. Will will add it to the issues list. > - Is it currently possible to express in ODRL document whether a party is > allowed to publicly present (e.g. in educational context) a piece of > content, otherwise than using user or target constraints? I'd find more > simplified way of expressing extremely useful. Good point again. Such a permission is probably needed all the time to express the legal context/copyright issues of certain works. Are there other permissions that might be needed in the legal context? Is there a vocabulary for uses in the copyright context, yet? Thanks again for your effort. Enjoy your advent. Susanne -- Susanne Guth susanne@odrl.net ODRL Initiative http://odrl.net/ NEU +++ DSL Komplett von GMX +++ http://www.gmx.net/de/go/dsl GMX DSL-Netzanschluss + Tarif zum superg?nstigen Komplett-Preis! From renato at odrl.net Thu Dec 2 14:00:07 2004 From: renato at odrl.net (Renato Iannella) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] Questions and comments for ODRL v2 In-Reply-To: <4867.80.222.240.224.1101854000.squirrel@webmail3.cc.jyu.fi> References: <4867.80.222.240.224.1101854000.squirrel@webmail3.cc.jyu.fi> Message-ID: <45E9AC2E-440E-11D9-87C4-00306541C018@odrl.net> On 1 Dec 2004, at 08:33, luomae@cc.jyu.fi wrote: > - From requirements management point of view, should there be an > indication whether certain requirements are mandatory (version 2 SHALL > have..) or discretionary (version 2 SHOULD have..)? We did not add specific "MUST/SHOULD/MAY" like Requirements until we were sure of the implications. That is, if we said that Req X was "MUST" and we could not find a way to implement it, does that mean we failed? I think we can easily say that all the Requirements are "SHOULD" and that means we must supply a good reason for NOT meeting it and also understand the full implications of this. (We MUST add this to the introduction of the Requirements document ;-) Alternatively, we can add the words MUST/SHOULD/MAY to each requirement. (and/or decide on MUST versus SHOULD versus MAY...) What do other think? Of course in the final V2 Spec, we will use this consistent terminology for the actual language. > - Since it seems that ODRL is concentrating in describing the > semantics of > contracts, I would promote inclusion of additional context elements, > which > will help in the interpretation of ODRL rights expressions and > supported > data dictionary: 1) Geopolitical context or as Milosevic and Bond > (1995) > define it, the Contract Domain, 2) Content Type/Industry context > (interpretation of ODRL elements with e.g. different content types). We did add to the Context to enable the "jurisdiction" of the license to be added. If there are specific elements to ensure the Agreements are "contractually valid" then we should make this clear in V2. Cheers Renato Iannella ODRL Initiative http://odrl.net From renato at odrl.net Fri Dec 3 13:46:38 2004 From: renato at odrl.net (Renato Iannella) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] Early Work on Model V2 Message-ID: <8E0614D9-44D5-11D9-A724-00306541C018@odrl.net> Dear all, Susanne and I have been working on an early draft of the ODRL model for Version 2.0. A copy is attached. At this stage is not at all complete and we will start to now document (in words) what all the classes mean and the various associations etc and different types of Rights expressions. (The UML does not clearly show all of the exact semantics/relationships...) At this stage we welcome any *high level* comments/feedback on the current draft - but expect a lot more in-depth discussion when we release the first Working Draft. Cheers Renato Iannella ODRL Initiative http://odrl.net -------------- next part -------------- A non-text attachment was scrubbed... Name: odrl-V2-model-draft3.jpg Type: image/jpeg Size: 56759 bytes Desc: not available Url : http://lists.odrl.net/pipermail/odrl-version2/attachments/20041203/763c2e87/odrl-V2-model-draft3.jpg From Susanne.Guth at gmx.net Fri Dec 3 21:53:13 2004 From: Susanne.Guth at gmx.net (Susanne Guth) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] Issues Lists Message-ID: <11981.1102071193@www55.gmx.net> Dear all! The requirements document contains now links from every requirement to an issues list. No changes have been made to the requirements themselves. http://odrl.net/2.0/v2req.html These lists shall make it easier for the working group to follow arguments and different solution approaches. Please feel free to comment on each of the issues list, add new issues, give solution approaches or arguments. Any comment is appreciated. So long Susanne -- Susanne Guth susanne@odrl.net ODRL Initiative http://odrl.net/ NEU +++ DSL Komplett von GMX +++ http://www.gmx.net/de/go/dsl GMX DSL-Netzanschluss + Tarif zum supergünstigen Komplett-Preis! From stephane at virtuosomedia.nl Wed Dec 8 21:20:14 2004 From: stephane at virtuosomedia.nl (Stephane van Hardeveld) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] Digital Media Project Message-ID: <006501c4dd0f$821f8c10$fea8a8c0@stephane> I came across the following initiative: http://www.digital-media-project.com/ Anyone on the list aware of what they do? Are there contacts with them? Stephane van Hardeveld VirtuosoMedia From stephane at virtuosomedia.nl Wed Dec 8 21:24:37 2004 From: stephane at virtuosomedia.nl (Stephane van Hardeveld) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] More info on DMPF Message-ID: <006b01c4dd10$1eda3a50$fea8a8c0@stephane> This one covers the viewpoint of BEUC, European bureau for consumers on DRM. http://www.dmpf.org/open/dmp0190.pdf Stephane From Steven_Rowat at sunshine.net Thu Dec 9 06:05:05 2004 From: Steven_Rowat at sunshine.net (Steven Rowat) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] DMP, TRU, BEUC, - and ODRL Message-ID: Hi ODRL2 list, Stephane provided the following links: >http://www.digital-media-project.com/ >http://www.dmpf.org/open/dmp0190.pdf Thank you Stephane, I agree they are both interesting groups. For what it's worth, I'll give my own (rather hasty) opinion of each, after a brief reading of some of their material: The first, the Digital Media Project, seems to me to be adding a whole new layer of abstraction - 'Traditional Rights and Usages' (TRU). They wish to ensure that traditional use (non-Internet) of content is respected within the digital DRM models. While laudatory in principle, I think they're too late. The Internet is, to adopt an analogy that has been made elsewhere about the evolution of life, like an airplane in flight over the ocean that needs repairs. We don't have the choice of putting the plane down on the ground. It's going to stay in flight, and we need to make those repairs *while the plane is in the air*. In other words I think the whole thing is going too fast for this group's main thesis to be respected. That said, I believe many of the TRU ideas will be useful to understand and will affect, if we let them, what happens in ODRL or other DRM. (See a table of TRUs at http://www.chiariglione.org/contrib/040102chiariglione01.htm) I personally found the second document, the position paper of the BEUC (the 'European Consumers' Organization'), more compelling, and feel that some interaction between ODRL and the BEUC may have potential good results. In my opinion, this paper gives many well reasoned points about fair use, privacy, and other issues; some expressed very succinctly. While in some places their paper has a doomsday feel to it - warning that the current decisions about hardwiring and other DRM contract issues are very bad ideas - I feel that most of what they look for is in fact provided by ODRL (potentially, or already); and that they might become a strong supported of ODRL, if they knew more about it. In fact, since I saw no mention of ODRL in the document, it's possible that they are not aware of ODRL at all yet. But even without such contact or mutual support, I think ODRL, and the larger community of content creators and users, would benefit from ODRL's being able to satisfy the concerns the BEUC have listed in this paper. Steven Rowat - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - web site: mailto:sc@rowatworks.com From renato at odrl.net Thu Dec 9 12:29:12 2004 From: renato at odrl.net (Renato Iannella) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] DMP, TRU, BEUC, - and ODRL In-Reply-To: References: Message-ID: On 9 Dec 2004, at 05:05, Steven Rowat wrote: > Hi ODRL2 list, > Stephane provided the following links: > >> http://www.digital-media-project.com/ >> http://www.dmpf.org/open/dmp0190.pdf Steven/Stephane - thanks for bringing up these two groups. I am not to sure of the the proposed outcomes of the DMPF group, but they do have a good collection of requirements for interoperable DRM: We should review this along with the requirements from BEUC. Cheers Renato Iannella ODRL Initiative http://odrl.net From Susanne.Guth at gmx.net Thu Dec 9 19:00:18 2004 From: Susanne.Guth at gmx.net (Susanne Guth) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] More info on DMPF References: <006b01c4dd10$1eda3a50$fea8a8c0@stephane> Message-ID: <11969.1102579218@www37.gmx.net> Stephane I can very well remember the headline that ' Leonardo Chiariglione, the founder of MPEG started the Digital Media Project'. At the beginning there has been not much motion on the web site but now it seems, that the project is active. Thanks for reminding us of the initiative, Stephane. For the ODRL initiative "the functions and requirements for interoperability" will be of interest... and maybe the initiative will chose ODRL as their standard rights language. I am looking forward to do a mapping to their requirements .. Susanne > This one covers the viewpoint of BEUC, European bureau for consumers on > DRM. > http://www.dmpf.org/open/dmp0190.pdf > > Stephane > _______________________________________________ > 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/ GMX ProMail mit bestem Virenschutz http://www.gmx.net/de/go/mail +++ Empfehlung der Redaktion +++ Internet Professionell 10/04 +++ From Susanne.Guth at gmx.net Thu Dec 9 19:21:08 2004 From: Susanne.Guth at gmx.net (Susanne Guth) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] DMP, TRU, BEUC, - and ODRL References: Message-ID: <24392.1102580468@www37.gmx.net> Hi Steven! > - I feel that most of what they look for is in fact provided by ODRL > (potentially, or already); and that they might become a strong supported > of > ODRL, if they knew more about it. In fact, since I saw no mention of ODRL > in the document, it's possible that they are not aware of ODRL at all yet. I don't think so. I am sure that Leonardo Chiariglione as a founder of MPEG is aware of both ODRL and MPEG REL. Maybe he did not mention any of the languages, yet to emphasize his unbiasedness in terms of rights languages. Susanne -- Susanne Guth susanne@odrl.net ODRL Initiative http://odrl.net/ GMX ProMail mit bestem Virenschutz http://www.gmx.net/de/go/mail +++ Empfehlung der Redaktion +++ Internet Professionell 10/04 +++ From Steven_Rowat at sunshine.net Fri Dec 10 04:22:57 2004 From: Steven_Rowat at sunshine.net (Steven Rowat) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] DMP, TRU, BEUC, - and ODRL Message-ID: Hi Susanne/ODRL2 I wrote (about the BEUC): >>. In fact, since I saw no mention of ODRL >> in the document, it's possible that they are not aware of ODRL at all yet. Susanne replied (but apparently about the DMP): >I don't think so. I am sure that Leonardo Chiariglione as a founder of MPEG >is aware of both ODRL and MPEG REL. Maybe he did not mention any of the >languages, yet to emphasize his unbiasedness in terms of rights languages. I was referring only to BEUC with my above statement, which I believe is clear from the context if you reread my original post; it occurs in a paragraph about BEUC. However, if Mr. Chiarglione is also a member of the BEUC as well, I'm sure you're right. But I was under the impression that the DMP and the BEUC are completely separate organizations - and with rather different focuses, as well. steven rowat