From stephane at virtuosomedia.nl Fri Oct 15 19:39:58 2004 From: stephane at virtuosomedia.nl (Stephane van Hardeveld) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] First requirements working draft Message-ID: <065001c4b292$8e66d610$fea8a8c0@stephane> Two small remarks on typos: - The copyright statement points to http://odrl,net, should probably be http://odrl.net - in Goals: 'keep ODLR simple' should be 'keep ODRL simple' Furthermore, I believe we also discussed the different approach between contracts/agreements and a kind of ticketing system, where a contract is negotiated (maybe with a paying party?) and the rights are consumed by others (the beneficiaries) in the form of tickets. Or where a subscription is necotiated in the form of a contract, which contains the right to open 15 e-books in a year, and the actual choosing of one book to read is constructed as a ticket. Does point 1.5 cover this? Stephane van Hardeveld VirtuosoMedia From Susanne.Guth at gmx.net Fri Oct 15 17:53:46 2004 From: Susanne.Guth at gmx.net (Susanne Guth) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] First requirements working draft issued, please review! Message-ID: <8611.1097823226@www3.gmx.net> To the ODRL version 2 working group and the ODRL interest list. A first working draft of the document Open Digital Rights Language (ODRL) Version 2 Requirements has been published today at the ODRL Version 2 WG Web Page: http://odrl.net/2.0/ The document results from the work in standardization groups (e.g. LTSC REL), the ODRL Workshop 2004, and several publications that are discussing ODRL. Please send your comments, additional requirements, and critics to susanne@odrl.net by the end of October. Any remarks will be appreaciated. So long -- 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 Mon Oct 18 15:23:49 2004 From: Susanne.Guth at gmx.net (Susanne Guth) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] contracts/tickets and downstream rights References: <065001c4b292$8e66d610$fea8a8c0@stephane> Message-ID: <22008.1098073429@www14.gmx.net> Stephane! Thanks for your useful remarks. You are addressing crucial points. After discussing this with Renato your issue probably falls into two requirement categories 1.5 and 1.1: Amongst other cases, with 1.5 ("Provide additional contract parties or third parties") we want to address the case where one contract is including e.g. seller, buyer, and a beneficiary party that is acting on behalf of the buyer. For example, if a university buys access right to a commercial library for their students. Here, students of the Vienna University may access the library until end of year 2004. A corresponding future ODRL instance could look like this: http://www.somelibrary.com/ Some Library LTD Vienna University of Econ. & BA Student at Vienna University of Econ. & BA 2004-12-31T23:59:59 So, if a person can identify himself as a student of the Vienna University he will get access to the library on the basis of the above contract. No, additional tickets have to be issued. Maybe, here it is important to note that we have to distinguish between different stages in a contract life cycle (please refer to "Toward a Conceptual Framework for Digital Contract Composition and Fulfillment" http://wi.wu-wien.ac.at/people/Guth/toward_contract_frmwrk.pdf). The contract itself can be stated in an ODRL instance (Lifecycle phase: contract conclusion) and tickets which are issued for consumption of rights (Lifecycle phase: execution of rights) can also be issued as ODRL instances. This probably does not require a new version of ODRL. Keeping track of how many tickets have already been issued and executed would need the logic and database of a DRM system. The following ODRL examples show a contract and two tickets that are related to each other. urn.someserviceprovider#service00999 Some ServiceProvider Stephane v. H. 2 20.00 Two tickets are issued. One ticket per one-time use of the resp. service. Most likely digitally signed, with expiration date, etc. by the service provider. Note that payment or rightsholder information is of no value anymore. Both tickets would look like the following. Each time the a customer wants to use the service he would have to provide one of his (valid, not expired, not already used) tickets. urn:ssp/TICKET-ID#5234985jga?fkjaoq5o urn.someserviceprovider.com#service00999 urn.ssp.webservices#000999 urn.ssp.user#shardeveld Amongst other cases, with Requirement 1.1 (Provide improved next rights (downstream rights)), we want to give the ODRL community a clear way of dealing with rights that are passed along the value chain. Is your question addressing this topic(, too)? (In your example, do you see the beneficiaries as customers of the paying party, where the paying party is the consumer of the content creator?) So long Susanne P.S. I did not run the examples in a validator, please excuse typ-os. > Furthermore, I believe we also discussed the different approach between > contracts/agreements and > a kind of ticketing system, where a contract is negotiated (maybe with a > paying party?) and the > rights are consumed by others (the beneficiaries) in the form of tickets. > Or where a subscription is necotiated in the form of a contract, which > contains the right to open > 15 e-books in a year, and the actual choosing of one book to read is > constructed as a ticket. > Does point 1.5 cover this? > > Stephane van Hardeveld > VirtuosoMedia > -- Susanne Guth susanne@odrl.net ODRL Initiative http://odrl.net/S +++ GMX DSL Premiumtarife 3 Monate gratis* + WLAN-Router 0,- EUR* +++ Clevere DSL-Nutzer wechseln jetzt zu GMX: http://www.gmx.net/de/go/dsl From Steven_Rowat at sunshine.net Tue Oct 19 04:24:24 2004 From: Steven_Rowat at sunshine.net (Steven Rowat) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] re: First requirements working draft issued, please review! Message-ID: Hello, As requested by Ms. Guth, I am posting these responses to the V2 requirements (below, after the '++++++') to this ODRL working group. In general my comments are a support for the existing V2 requirements; I have merely gone into detail as to why I feel certain of them are particularly important for the situation of an independent 'content creator' who wishes to sell their own works digitally on the Internet. The only requirement for this situation that concerned me as possibly missing is the ability to easily use a (probably free) 'preview' of a portion of the work as part of the sale situation; however Ms. Guth has explained that this is possible as well; which is good, because I think this would be an important capability of the system. +++++++ Goals: "Keep ODLR simple" is a typo error. Should be 'ODRL'! Requirements: 1.1 Provide improved next rights (downstream rights). Agreed. I strongly support 1.1 downstream rights for control over usage by *content creators in particular*. To me, the idea that content creators can have full control throughout the distribution is the exciting and revolutionary part of the whole ODRL scheme, since it means that: a) there will be less censorship by 'middlemen' (or women) - who are usually corporate players with little interest in the content itself. b) there will be less (unnecessary) profit removal by non-creators before the content reaches the user; thereby allowing for fair return to the creator. In many creative endeavours at present, this does not happen - only the distributors get paid, not the creators. (This is not only unfair, in the larger picture it distorts our social evolution mechanisms.) 1.4. Support contract negotiation. This is extremely important, since content use may come in the form of yearly subscriptions, use without copying, use with copying, fair use, use with ability to modify the content, collaborative use, etc. etc. There should be an easy way to set up a mechanism where the content creator can: a) know clearly his or her options in these semantics; b) set them easily; and where the user can have the resulting choices easily displayed and easy to respond to. [UML may be useful here. See my comments about UML after point 6]. 1.7. Provide a "NOT" expression. This seems like an efficient mechanism in some cases. However, it may a) run afoul of laws in certain jurisdictions; or b) allow the user to make use of the content in ways that the creator or other enabler of this expression never intended. If these problems are addressed in its wording and semantics, though, I see no reason why this shouldn't be rolled into the basic contract negotiations described in section 1.4. 1.9. Provide an aligned constraint data model. This seems like a good idea, especially if it will streamline integration with other access systems during implementation. 2. Keep ODRL simple. Strongly agreed. (Aside: point 1.9 is a good example of following this rule). An example would be using plain language terms wherever possible. The remarkable world-wide spread of HTML is due in no small part, in my opinion, to the fact that it uses common language terms throughout. Contrast with, say, Javascript, where cryptic symbols must be mastered. Keep ODRL in the HTML tradition, as far as allowing anyone who uses a given lanaguage as a whole (ie., English) to be able to understand and even develop in the ODRL in their language. Thus content creators themselves will be able to understand the language of ODRL; which makes sense if it is to be the main vehicle for the sale of their works. 6. UML UML was new to me, so I went quickly through Borland's excellent tutorial (). Using UML seems like a very good idea. In fact, I find myself hoping for - expecting - that someone will produce a UML software tool that will allow content creators to set their permissions. The world is full of content creators who are not computer literate, and the quickest way to integrate them into an internet distribution system for their work will be to give them a *diagram*-based tool for setting the copyright use and price permissions for their work. If ODRL is already using UML, then it would be a short hop to having software companies produce transparent software tools for creator use - much like Dreamweaver or Adobe GoLive, say, are greatly accelerating the ability of internet users to make HTML pages without actually writing code; they merely drag and drop, etc.. In the same way, UML could function in ODRL permission-setting, I envision. Thanks again for your work, and hope this helps a little, Best wishes, steven rowat - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - web site: mailto:sc@rowatworks.com From renato at odrl.net Thu Oct 21 15:07:19 2004 From: renato at odrl.net (Renato Iannella) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] More Requirements Message-ID: Here are some more requirements we need to consider: 1 - Offer/Agreement Model Only The current model of only supporting Offers and Agreements needs to be reviewed. There maybe cases where this is not relevant and just a generic set of rights is only required to be expressed. There is also the possibility of supporting a "Request" which is from a Consumer to a Rights Holders. 2 - Exclusive Permission At the moment a Permission can be stated to be ?Exclusive? with the use of an attribute. This could be expressed using a constraint or other means. 3 - ForEachMember Constraint The forEachMember constraint allows members of entities to be assigned individual constraints (using URI and id/idref). This could be expressed via other mechanisms as well as supporting other options (eg: any Member, one Member, all members, etc). 4 - Condition Model The current Condition model is under-utilised. It needs to be reviewed with the new V2 data model. 5 - Revoke Model The current Revoke model is under-utilised. It needs to be reviewed with the new V2 data model to determine if it is still required. Revoking licenses may only make sense in specific implementations of trust models. 6 - Security Model The current Security Model is very explicit. It needs to be reviewed to determine if it is best to be more open with the details being provided in community Profiles (eg OMA Mobile DRM). 7 - Containers Model The current Containers model needs to be reviewed to see if it is adequate and/or can be improved. 8 - Sequence Model The current Sequence model needs to be reviewed to see if it is adequate and/or can be improved. 9 - Linking Model The current Linking model needs to be reviewed to see if it is adequate and/or can be improved. 10 - Inheritance Model The inheritance model is used in the OMA DRM specification. It would be useful to review its use to ascertain if any improvements/refinements are necessary. 11 - The WEMI Model ODRL supports the Work/Expression/Manifestation/Item model to describe layers of content (from the Library community). It would be useful to review this to ascertain if any improvements/refinements are necessary. It maybe better, for example, to incorporate this with Inheritance and/or Linking between assets. Cheers Renato Iannella ODRL Initiative http://odrl.net From stephane at virtuosomedia.nl Thu Oct 21 22:13:58 2004 From: stephane at virtuosomedia.nl (Stephane van Hardeveld) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] contracts/tickets and downstream rights References: <065001c4b292$8e66d610$fea8a8c0@stephane> <22008.1098073429@www14.gmx.net> Message-ID: <007601c4b75f$0ffde490$2e00000a@vaiostephane> > Stephane! > > Thanks for your useful remarks. You are addressing crucial points. > > After discussing this with Renato your issue probably falls into two > requirement categories 1.5 and 1.1: Thank you! > Maybe, here it is important to note that we have to distinguish between > different stages in a contract life cycle (please refer to "Toward a > Conceptual Framework for Digital Contract Composition and Fulfillment" > http://wi.wu-wien.ac.at/people/Guth/toward_contract_frmwrk.pdf). The > contract itself can be stated in an ODRL instance (Lifecycle phase: contract > conclusion) and tickets which are issued for consumption of rights > (Lifecycle phase: execution of rights) can also be issued as ODRL instances. > This probably does not require a new version of ODRL. Keeping track of how > many tickets have already been issued and executed would need the logic and > database of a DRM system. This is exactly what I meant. It seems appropriate to include some formal notion of the lifecycle to ODRL. Maybe even with an (optional) tag which reflects the state this agreement is meant for (e.g. contract proposal, contract conclusion, fulfillment, consumption, downstream transfer), maybe as part of a Usage Scenario specialization. This could of course be left to the DRM system without a reflection in the ODRL, since it has to keep track of the life-cycle anyway. > > > urn.ssp.user#shardeveld > > I suppose the uid of the consumer may relate this party to the consumer Stephane van H. of your example? Could this also be a beneficiary party, which has a seperate agreement with the consumer party in the original contract? > > Amongst other cases, with Requirement 1.1 (Provide improved next rights > (downstream rights)), we want to give the ODRL community a clear way of > dealing with rights that are passed along the value chain. Is your question > addressing this topic(, too)? (In your example, do you see the beneficiaries > as customers of the paying party, where the paying party is the consumer of > the content creator?) Might be. It should be possible, for example, to offer a contract where one buys an (anonymous?) ticket for an un-identified piece of music from a large supplier of music, and pass this on to another party (the beneficiary). This latter party may then exchange this ticket for a piece of music, providing the value of this ticket covers the value of this piece of music. (An electronic coupon, so to speak). > So long > Susanne > > P.S. I did not run the examples in a validator, please excuse typ-os. > Regards, Stephane > > Furthermore, I believe we also discussed the different approach between > > contracts/agreements and > > a kind of ticketing system, where a contract is negotiated (maybe with a > > paying party?) and the > > rights are consumed by others (the beneficiaries) in the form of tickets. > > Or where a subscription is necotiated in the form of a contract, which > > contains the right to open > > 15 e-books in a year, and the actual choosing of one book to read is > > constructed as a ticket. > > Does point 1.5 cover this? > > > > Stephane van Hardeveld > > VirtuosoMedia > > > > -- > Susanne Guth > susanne@odrl.net > ODRL Initiative > http://odrl.net/S > > +++ GMX DSL Premiumtarife 3 Monate gratis* + WLAN-Router 0,- EUR* +++ > Clevere DSL-Nutzer wechseln jetzt zu GMX: http://www.gmx.net/de/go/dsl > > _______________________________________________ > ODRL-Version2 mailing list > ODRL-Version2@odrl.net > http://lists.odrl.net/mailman/listinfo/odrl-version2 > From stephane at virtuosomedia.nl Thu Oct 21 22:35:22 2004 From: stephane at virtuosomedia.nl (Stephane van Hardeveld) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] More Requirements Message-ID: <002601c4b762$0d09f190$2e00000a@vaiostephane> Hi, > Here are some more requirements we need to consider: > > 1 - Offer/Agreement Model Only > The current model of only supporting Offers and Agreements > needs to be reviewed. There maybe cases where this is not > relevant and just a generic set of rights is only required > to be expressed. There is also the possibility of supporting > a "Request" which is from a Consumer to a Rights Holders. > Agreed! > > 2 - Exclusive Permission > At the moment a Permission can be stated to be ?Exclusive? > with the use of an attribute. This could be expressed using > a constraint or other means. Yes, I tend to like solutions without attributes :-). Besides, exclusivity is in itself a constraint, so why not express it that way? > 3 - ForEachMember Constraint > The forEachMember constraint allows members of entities to > be assigned individual constraints (using URI and id/idref). > This could be expressed via other mechanisms as well as > supporting other options (eg: any Member, one Member, all > members, etc). This would be very useful > 5 - Revoke Model > The current Revoke model is under-utilised. It needs to be > reviewed with the new V2 data model to determine if it is still > required. Revoking licenses may only make sense in specific > implementations of trust models. If it is necessary, it could be implemented via a ticketing system. One agrees to a contract during contract negotiation, and the consumption takes place via tickets. If a revocation system is needed, this can be accomplished by checking with a DRM Management system before sending out a new ticket. Maybe it should be included in the usage scenarios? > 6 - Security Model > The current Security Model is very explicit. It needs to be > reviewed to determine if it is best to be more open with the > details being provided in community Profiles (eg OMA Mobile DRM). And ISMACrypt? > 10 - Inheritance Model > The inheritance model is used in the OMA DRM specification. > It would be useful to review its use to ascertain if any > improvements/refinements are necessary. Maybe some specific inheritance models/specs may arise in the usage scenario discussions > 11 - The WEMI Model > ODRL supports the Work/Expression/Manifestation/Item model > to describe layers of content (from the Library community). > It would be useful to review this to ascertain if any > improvements/refinements are necessary. It maybe better, for > example, to incorporate this with Inheritance and/or Linking > between assets. > > > Cheers > > Renato Iannella > ODRL Initiative > http://odrl.net Regards, Stephane van Hardeveld From renato at odrl.net Fri Oct 22 16:44:24 2004 From: renato at odrl.net (Renato Iannella) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] More Requirements In-Reply-To: <002601c4b762$0d09f190$2e00000a@vaiostephane> References: <002601c4b762$0d09f190$2e00000a@vaiostephane> Message-ID: <6E53A36E-23ED-11D9-9F80-00306541C018@odrl.net> On 21 Oct 2004, at 21:35, Stephane van Hardeveld wrote: > Yes, I tend to like solutions without attributes :-). Besides, > exclusivity > is in itself a constraint, so why not express it that way? Yes, we can model as an Constraint, but we need to also indicate that the party is the *only* party with those rights. >> 6 - Security Model >> The current Security Model is very explicit. It needs to be >> reviewed to determine if it is best to be more open with the >> details being provided in community Profiles (eg OMA Mobile DRM). > > And ISMACrypt? Does ISMACrypt use W3C XML Digital Signature and Encryption standards? Cheers Renato Iannella ODRL Initiative http://odrl.net From Susanne.Guth at gmx.net Fri Oct 22 17:24:11 2004 From: Susanne.Guth at gmx.net (Susanne Guth) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] your reqs. OK? References: <6E53A36E-23ED-11D9-9F80-00306541C018@odrl.net> Message-ID: <3377.1098426251@www20.gmx.net> Did I add your requirements OK? http://odrl.net/2.0/WD-v2req-20041022.html This document is not yet linked. Susanne -- Susanne Guth susanne@odrl.net ODRL Initiative http://odrl.net/ +++ GMX DSL Premiumtarife 3 Monate gratis* + WLAN-Router 0,- EUR* +++ Clevere DSL-Nutzer wechseln jetzt zu GMX: http://www.gmx.net/de/go/dsl From Susanne.Guth at gmx.net Fri Oct 22 17:25:37 2004 From: Susanne.Guth at gmx.net (Susanne Guth) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] More Requirements References: <002601c4b762$0d09f190$2e00000a@vaiostephane> Message-ID: <7824.1098426337@www20.gmx.net> Stephane! Thanks for you valuable comments. Could you give me some references to ISMACrypt? Susanne > > 6 - Security Model > > The current Security Model is very explicit. It needs to be > > reviewed to determine if it is best to be more open with the > > details being provided in community Profiles (eg OMA Mobile DRM). > > And ISMACrypt? > -- Susanne Guth susanne@odrl.net ODRL Initiative http://odrl.net/ +++ GMX DSL Premiumtarife 3 Monate gratis* + WLAN-Router 0,- EUR* +++ Clevere DSL-Nutzer wechseln jetzt zu GMX: http://www.gmx.net/de/go/dsl From stephane at virtuosomedia.nl Fri Oct 22 19:08:25 2004 From: stephane at virtuosomedia.nl (Stephane van Hardeveld) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] your reqs. OK? References: <6E53A36E-23ED-11D9-9F80-00306541C018@odrl.net> <3377.1098426251@www20.gmx.net> Message-ID: <007501c4b80e$4e6f33a0$fea8a8c0@stephane> Yep. Stephane ----- Original Message ----- From: "Susanne Guth" To: "ODRL Version 2.0" Sent: Friday, October 22, 2004 8:24 AM Subject: [Odrl-version2] your reqs. OK? > Did I add your requirements OK? > > http://odrl.net/2.0/WD-v2req-20041022.html > > This document is not yet linked. > Susanne > > -- > Susanne Guth > susanne@odrl.net > ODRL Initiative > http://odrl.net/ > > +++ GMX DSL Premiumtarife 3 Monate gratis* + WLAN-Router 0,- EUR* +++ > Clevere DSL-Nutzer wechseln jetzt zu GMX: http://www.gmx.net/de/go/dsl > > _______________________________________________ > ODRL-Version2 mailing list > ODRL-Version2@odrl.net > http://lists.odrl.net/mailman/listinfo/odrl-version2 > From stephane at virtuosomedia.nl Fri Oct 22 19:38:46 2004 From: stephane at virtuosomedia.nl (Stephane van Hardeveld) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] More Requirements References: <002601c4b762$0d09f190$2e00000a@vaiostephane> <7824.1098426337@www20.gmx.net> Message-ID: <064401c4b812$8c0f94d0$fea8a8c0@stephane> http://www.isma.tv/resources/isma2 http://www.isma.tv/resources/techspecs/ Unfortunately, you will need to become a member. It is not as open as one would like... As I am looking into it again (been a while) it is probably too focussed on stream encryption. It does say something about DRM, but is working together with MPEG4-IPMP. >From their website: "In developing these specifications, ISMA relies on open, established standards and often proposes amendments to relevant standards bodies' efforts that are still in development. The primary goal of ISMA is to publish and promote systemic, end-to-end specifications that enable cross-platform and multi-vendor implementations. The first ISMA specification defines an implementation agreement for streaming MPEG-4 video and audio over IP networks. The alliance has also recently published its very first integration specification for digital rights management (DRM). Ongoing work consists of interactive content, next generation audio/video streaming specifications, and initiatives for home networking and enterprise applications. " Please, check it out, maybe it is not appropriate as example security model at all. Stephane ----- Original Message ----- From: "Susanne Guth" To: "ODRL Version 2.0" Sent: Friday, October 22, 2004 8:25 AM Subject: Re: [Odrl-version2] More Requirements > Stephane! > > Thanks for you valuable comments. Could you give me some references to > ISMACrypt? > > Susanne > > > > 6 - Security Model > > > The current Security Model is very explicit. It needs to be > > > reviewed to determine if it is best to be more open with the > > > details being provided in community Profiles (eg OMA Mobile DRM). > > > > And ISMACrypt? > > > > -- > Susanne Guth > susanne@odrl.net > ODRL Initiative > http://odrl.net/ > > +++ GMX DSL Premiumtarife 3 Monate gratis* + WLAN-Router 0,- EUR* +++ > Clevere DSL-Nutzer wechseln jetzt zu GMX: http://www.gmx.net/de/go/dsl > > _______________________________________________ > ODRL-Version2 mailing list > ODRL-Version2@odrl.net > http://lists.odrl.net/mailman/listinfo/odrl-version2 > From Steven_Rowat at sunshine.net Sat Oct 23 04:10:28 2004 From: Steven_Rowat at sunshine.net (Steven Rowat) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] More Requirements Message-ID: Greetings, Renato wrote: >1 - Offer/Agreement Model Only > The current model of only supporting Offers and Agreements > needs to be reviewed. There maybe cases where this is not > relevant and just a generic set of rights is only required > to be expressed. There is also the possibility of supporting > a "Request" which is from a Consumer to a Rights Holders. Agreed that both are important changes - I think; but to clarify: in the "generic set of rights" expression situation, do you mean that, for instance, there may be cases where the rights holder wishes to publish the fact that anyone may use the work in certain ways, without needing to interact (ie. invoke an Agreement)? For example, suppose I hold the publishing rights to recordings by a musician who has died. I may, for various reasons, decide to donate some forms of the rights play these recordings into the public domain. Under the v 1.1 model, someone would need to be in 'Agreement' with this - but this is not relevant in this case, since I only need to publish the specific 'gifts' and the permission structure for their use. Hence the model needs to be changed to support this. Is this an example of what you mean? If so, I agree that it's necessary for ODRL to support this in V.2. >possibility of supporting > a "Request" This seems very important, since a major advantage of the Internet over traditional media is that it has two-way capability. Certainly we ought to enshrine some form of this capability at a core level of ODRL; and there may even be more than one core form of 'Request'. For example, it may be important to have the user be able to request things from either the rights holder *or* the 'work' itself. That is, one type of Request is part of the Agreement about using a work, and one is part of the work - in the sense that the 'Request' may be part of an *interaction* with a work which is itself a piece of software. That last idea leads to other possibilities that may be outside the scope of this particular section - I'm not sure - yet still it seems important to recognize, somewhere in ODRL, that 'Requests' or some term analogous to it could, with increasing use of video and audio chat software, become a very interesting part of how information-flow interactions are carried on. For example: suppose you and I are chatting over the internet using video-conference software, and you're a Professor of Linguistics and I'm a 'language student'. It would be wonderful, and possibly revolutionary in the higher-education field, if ODRL could handle the situation where the student 'requests' (by asking a question), and your answer - spoken in realtime or chosen by you from a list of pre-packaged 'answers' - is not only viewed by the student, but downloaded automatically onto the student's CPU, where they can peruse it at their leisure - but only in certain ways (set by the permissions/constraints of the interaction). And of course as part of the ODRL interaction, there would be a small payment by the student before the Request would be answered. :-) Or, as another example, someone who is offering counselling in a particular area - say, divorce counselling - could be having an on-line discussion with someone who is asking them questions; the questions could be Requests which would only be answered as long as the appropriate duty (payment) is fulfilled during the request process. Are these possibilities covered by any part of ODRL 1.1 at present, or in the projections for V 2? If not, perhaps they could be considered; I feel that enabling these types of interactions for royalty or piece-pay (or barter) interactions on the Internet could have useful and possibly wide-ranging applications. steven rowat - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - web site: mailto:sc@rowatworks.com From renato at odrl.net Mon Oct 25 12:33:55 2004 From: renato at odrl.net (Renato Iannella) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] More Requirements In-Reply-To: <064401c4b812$8c0f94d0$fea8a8c0@stephane> References: <002601c4b762$0d09f190$2e00000a@vaiostephane> <7824.1098426337@www20.gmx.net> <064401c4b812$8c0f94d0$fea8a8c0@stephane> Message-ID: On 22 Oct 2004, at 18:38, Stephane van Hardeveld wrote: > Unfortunately, you will need to become a member. It is not as open as > one > would like... You can download version 1.0 (just need to supply your email address). V1 does not mention any of the W3C signature/encryption standards. V2 is planned for release later this year. At this stage, we should keep any ODRL security model based on open standards... Cheers Renato Iannella ODRL Initiative http://odrl.net From Susanne.Guth at gmx.net Mon Oct 25 13:12:36 2004 From: Susanne.Guth at gmx.net (Susanne Guth) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] contracts/tickets and downstream rights References: <007601c4b75f$0ffde490$2e00000a@vaiostephane> Message-ID: <24835.1098670356@www33.gmx.net> > > > > > > > urn.ssp.user#shardeveld > > > > > > I suppose the uid of the consumer may relate this party to the consumer > Stephane van H. > of your example? Could this also be a beneficiary party, which has a > seperate agreement with the > consumer party in the original contract? Yes, exactly! And this makes already clear that the semantics of seller, buyer, rightsholder, beneficiary must be clearly stated. Maybe, in my second example (with contracts and tickets) it would have been more sensible if I had chosen "beneficiary" for the party "urn.ssp.user#shardeveld". ... > Might be. It should be possible, for example, to offer a contract where > one > buys an (anonymous?) ticket for an un-identified piece of music from a > large > supplier of music, and pass this on to another party (the beneficiary). > This > latter party may then exchange this ticket for a piece of music, providing > the > value of this ticket covers the value of this piece of music. (An > electronic > coupon, so to speak). Yes, that is our plan. I will try to make this more clear in the requirement 1.5. So long Susanne -- Susanne Guth susanne@odrl.net ODRL Initiative http://odrl.net/ Geschenkt: 3 Monate GMX ProMail + 3 Ausgaben der TV Movie mit DVD ++++ Jetzt anmelden und testen http://www.gmx.net/de/go/mail ++++ From renato at odrl.net Wed Oct 27 13:35:28 2004 From: renato at odrl.net (Renato Iannella) Date: Sat Jun 2 13:28:04 2007 Subject: [Odrl-version2] More Requirements In-Reply-To: References: Message-ID: On 23 Oct 2004, at 03:10, Steven Rowat wrote: > Agreed that both are important changes - I think; but to clarify: in > the > "generic set of rights" expression situation, do you mean that, for > instance, there may be cases where the rights holder wishes to publish > the > fact that anyone may use the work in certain ways, without needing to > interact (ie. invoke an Agreement)? Yes, for cases outside the stricter Offer/Agreement model. > That last idea leads to other possibilities that may be outside the > scope > of this particular section - I'm not sure - yet still it seems > important to > recognize, somewhere in ODRL, that 'Requests' or some term analogous > to it > could, with increasing use of video and audio chat software, become a > very > interesting part of how information-flow interactions are carried on. There is *potential* for this (at this stage) and with a more flexible model a community may develop a profile for this. Cheers Renato Iannella ODRL Initiative http://odrl.net