From renato at odrl.net Wed Mar 1 13:03:30 2006 From: renato at odrl.net (Renato Iannella) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] The difference between offer and ticket In-Reply-To: <001801c63c2e$9240a4b0$420aa40a@china.huawei.com> References: <001801c63c2e$9240a4b0$420aa40a@china.huawei.com> Message-ID: On 28 Feb 2006, at 16:16, fengwenjie wrote: > from above, the only textual difference is that: ticket allows at > least one party with Assigner role, while offer only allows exactly > one! Then, what's the original intention to have these 2 kinds of > rights types? or to say, what's the semantic difference between them? Hi Jessica - the primary difference between Offer and Ticket is that the Offer is only *proposing* as set of permissions (and constraints etc), whereas a Ticket *allows* a set of permissions (and constraints etc). The latter being for the actual holder of the ticket. Is that clear? Perhaps we need to update the model... Cheers Renato Iannella ODRL Initiative http://odrl.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.odrl.net/pipermail/odrl-version2/attachments/20060301/f8c3e02e/attachment.html From fengwenjie at huawei.com Thu Mar 2 13:09:45 2006 From: fengwenjie at huawei.com (fengwenjie) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] Re: The difference between offer and ticket References: <0IVH00GQW7A60W@szxga01-in.huawei.com> Message-ID: <002c01c63d9e$609432d0$420aa40a@china.huawei.com> Hi Renato, That is to say, Offer only represent the holder's ability, while Ticket means the holder has issued the rights. Then I have still another question: why the two has different contraint on the number of Party with Assigner role? Actually, in one negotiation, shouldn't the Assigner of Offer and Ticket be the same? BR, Jessica ----- Original Message ----- > > from above, the only textual difference is that: ticket allows at > > least one party with Assigner role, while offer only allows exactly > > one! Then, what's the original intention to have these 2 kinds of > > rights types? or to say, what's the semantic difference between them? > > Hi Jessica - the primary difference between Offer and Ticket is that > the Offer is only *proposing* as set of > permissions (and constraints etc), whereas a Ticket *allows* a set of > permissions (and constraints etc). The latter being for the actual > holder of the ticket. > > Is that clear? Perhaps we need to update the model... > > Cheers > > Renato Iannella > ODRL Initiative > http://odrl.net > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://lists.odrl.net/pipermail/odrl-version2/attachments/20060301/f8c3e02e/attachment-0001.htm > > ------------------------------ > > _______________________________________________ > ODRL-Version2 mailing list > ODRL-Version2@odrl.net > http://lists.odrl.net/mailman/listinfo/odrl-version2 > > > End of ODRL-Version2 Digest, Vol 14, Issue 2 > ******************************************** From renato at odrl.net Thu Mar 2 14:50:25 2006 From: renato at odrl.net (Renato Iannella) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] Re: The difference between offer and ticket References: <8070894A-89B1-4850-8A83-C2619C6EAF56@hku.hk> Message-ID: On 2 Mar 2006, at 12:09, fengwenjie wrote: > Then I have still another question: why the two has different > contraint on > the number of Party with Assigner role? Yes, you are correct - we need to update the Offer to allow "at least one Party entity with Assigner role" > Actually, in one negotiation, shouldn't the Assigner of Offer and > Ticket be the same? Yes. Cheers... Renato Iannella National ICT Australia (NICTA) From aarnab at cs.uct.ac.za Thu Mar 2 18:43:15 2006 From: aarnab at cs.uct.ac.za (Alapan Arnab) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] Re: The difference between offer and ticket In-Reply-To: <002c01c63d9e$609432d0$420aa40a@china.huawei.com> References: <0IVH00GQW7A60W@szxga01-in.huawei.com> <002c01c63d9e$609432d0$420aa40a@china.huawei.com> Message-ID: <1141285396.7022.3.camel@iduna> Hi, I think this is a good example on why there is a need to have another attribute to indicate the type of offer - which should remove the ambiguities. Alapan On Thu, 2006-03-02 at 10:09 +0800, fengwenjie wrote: > Hi Renato, > > That is to say, Offer only represent the holder's ability, while Ticket means > the holder has issued the rights. > Then I have still another question: why the two has different contraint on > the number of Party with Assigner role? Actually, in one negotiation, shouldn't > the Assigner of Offer and Ticket be the same? > > BR, > Jessica > > ----- Original Message ----- > > > > from above, the only textual difference is that: ticket allows at > > > least one party with Assigner role, while offer only allows exactly > > > one! Then, what's the original intention to have these 2 kinds of > > > rights types? or to say, what's the semantic difference between them? > > > > Hi Jessica - the primary difference between Offer and Ticket is that > > the Offer is only *proposing* as set of > > permissions (and constraints etc), whereas a Ticket *allows* a set of > > permissions (and constraints etc). The latter being for the actual > > holder of the ticket. > > > > Is that clear? Perhaps we need to update the model... > > > > Cheers > > > > Renato Iannella > > ODRL Initiative > > http://odrl.net > > > > > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: http://lists.odrl.net/pipermail/odrl-version2/attachments/20060301/f8c3e02e/attachment-0001.htm > > > > ------------------------------ > > > > _______________________________________________ > > ODRL-Version2 mailing list > > ODRL-Version2@odrl.net > > http://lists.odrl.net/mailman/listinfo/odrl-version2 > > > > > > End of ODRL-Version2 Digest, Vol 14, Issue 2 > > ******************************************** > _______________________________________________ > 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 Mar 7 07:51:57 2006 From: Susanne.Guth at gmx.net (Susanne Guth) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] Re: The difference between offer and ticket References: Message-ID: <24335.1141678317@www041.gmx.net> Hi all, I added a relation from the Party Entity to the Rights Entity called "assigner". I am currently working on the new model page. When published please have a look at the cardinalities and if you agree to them. Susanne > > On 2 Mar 2006, at 12:09, fengwenjie wrote: > > > Then I have still another question: why the two has different > > contraint on > > the number of Party with Assigner role? > > Yes, you are correct - we need to update the Offer to allow "at least > one Party entity with Assigner role" > > > Actually, in one negotiation, shouldn't the Assigner of Offer and > > Ticket be the same? > > Yes. > > Cheers... Renato Iannella > National ICT Australia (NICTA) > > > > _______________________________________________ > 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/ Echte DSL-Flatrate dauerhaft für 0,- Euro*! "Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl From Susanne.Guth at gmx.net Tue Mar 7 07:51:57 2006 From: Susanne.Guth at gmx.net (Susanne Guth) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] Re: The difference between offer and ticket References: Message-ID: <24335.1141678317@www041.gmx.net> Hi all, I added a relation from the Party Entity to the Rights Entity called "assigner". I am currently working on the new model page. When published please have a look at the cardinalities and if you agree to them. Susanne > > On 2 Mar 2006, at 12:09, fengwenjie wrote: > > > Then I have still another question: why the two has different > > contraint on > > the number of Party with Assigner role? > > Yes, you are correct - we need to update the Offer to allow "at least > one Party entity with Assigner role" > > > Actually, in one negotiation, shouldn't the Assigner of Offer and > > Ticket be the same? > > Yes. > > Cheers... Renato Iannella > National ICT Australia (NICTA) > > > > _______________________________________________ > 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/ Echte DSL-Flatrate dauerhaft für 0,- Euro*! "Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl From Susanne.Guth at gmx.net Tue Mar 7 10:03:26 2006 From: Susanne.Guth at gmx.net (Susanne Guth) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] Followup on Legal stuff about contracts References: <1141130710.20376.37.camel@iduna> Message-ID: <26948.1141686206@www041.gmx.net> Renato, Alapan, I updated the model an adopted the text and scenarios. Alapan please have a look at the Legal entity. Could you please provide a text for liabilities, or don't we need this attribute? Could you please also provide the semantics for the negotiation entity... THANKS. Please read through the document and let me know if I oversaw sections that have to be updated. I added a relation from Party to Rights, btw. After you two proof read the document, we can publish it as a new model draft (containers are still missing though...one after the other ;) ). Here's the draft: http://odrl.net/2.0/WD-ODRL-Model-20060306.html So long Susanne -- Susanne Guth susanne@odrl.net ODRL Initiative http://odrl.net/ Bis zu 70% Ihrer Onlinekosten sparen: GMX SmartSurfer! Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer From renato at odrl.net Wed Mar 8 15:41:21 2006 From: renato at odrl.net (Renato Iannella) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] Followup on Legal stuff about contracts In-Reply-To: <26948.1141686206@www041.gmx.net> References: <1141130710.20376.37.camel@iduna> <26948.1141686206@www041.gmx.net> Message-ID: <7DF2F65B-EDD4-43C3-A3D9-89EA6A5FB2A4@odrl.net> Susanne - thanks for the update - great work. I have some minor editing but will leave that to the end. Here are some more substantive questions: 1 - Should we have a "Change History" as the table of contents says? (or too many changes!) 2 - On the Model, Permission, Prohibition, and Duty all have a "tradeable" attribute. What is this for? 3 - On the Model, the "inherit" association on the Asset entity probably is best as an attribute now. 4 - In the Rights Class Model, where we say "the Request/Ticket (etc) must contain an Asset" should we say "...must contain at least one Asset" ? 5 - In the Permission Model, we should say that since the Permission must contain ONE Action, that multiple Permissions are also allowed. Also, we say that the Permission must also contain ONE Asset - can it be multiple?? 6 - The Duty Model scenario examples have Action/Measure/Value shown, but we only talk about Action and "Object" in the normative text? 7 - Legal model - Alapan, need some text definitions here (thanks!) 8 - I think we need to add wording to clarify the situation when there are both Permissions and Prohibitions in the expression (and where there is a direct conflict). I can work on that... 9 - The Ticket Scenario - need to remove the Assignee party as this is not part of a ticket 10 - We need to add an Acknowledgments section at the end and list all people (including from this WG) how have contributed to the document. Looking good! Cheers... Renato Iannella National ICT Australia (NICTA) From Steven_Rowat at sunshine.net Fri Mar 10 06:40:56 2006 From: Steven_Rowat at sunshine.net (Steven Rowat) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] New ODRL v2.0 Model Message-ID: Hi all, Great to have the 2.0 model at a public stage. Good to see the UML inclusion and the new Legal entity. My first question agrees with Renato's, >1 - Should we have a "Change History" as the table of contents says? >(or too many changes!) and I propose a short way of doing this: How about, under Change History, put something like: "Sections D, B, F [or whatever] are added." "Sections Q, M, F have major changes." "Sections A, Y, Z are substantially unchanged." I think would aid others (and still might aid me!) in approaching the document. Other question / comments (some minor, some major): 1. What are the numbers "1" and "0", with periods and asterisks sometimes, indicating on the main model graphic? 2. Why are the reType not listed in the Rights model box? It seems like they are key players in the model - shouldn't they be visible? 3. Is it really necessary/useful to repeat the word "Model" after each section heading, ie., Rights Class Model, Asset Model, etc. For example, with "Asset" you immediately begin using the word "entity" to refer to the Asset; I feel there's less conflict in the flow if it just went: "2.2 Asset "The Asset entity is aimed at identifying..." 4. Under section 2.1, I found this sentence confusing: "Statement. The statement supports rights expressions that consists of any number of (or none of) entities from the complete model. This is aimed at scenarios..." Two issues with this: a) "...consists of any number of (or none of) entities...." reads strangely. How about: "...consists of any number of (or no) entities...." b) Either way, the first sentence by itself definitely needs the later sentences to explain it, but the antecdent of "This" is not clear. It could be taken to men "Statement" entity itself, but I think this is not what you meant. In other words, if you mean "this" and the following to be explaining the "none" of case only, I suggest using "...the latter (no entities from the model)..." instead, as in: "Statement. The statement supports rights expressions that consists of any number of (or no) entities from the complete model. The latter (no entities from the model) is aimed at scenarios..." If, on the other hand, you do mean the entire Statement entity exists to have this function, then I'm still confused about what Statement's function is when it *does* have rights entities from the complete model. 5. In the 2.1 "Next Rights" paragraph, I believe you've left out the quotation marks around several words in the following sentence: Shouldn't this read: . It seems to make a circle. I don't understand what is inherited from what - it sounds to me from this that the Asset is inheriting rights from the Asset. Either that or rights from somewhere else that are assigned to the Asset are being re-assigned to the Asset by inheritance - but if they're already assigned, why re-assign them to the same place? 7. Section 2.3 This sentence: "In this case, the Party entity must identify a group of people." I believe would be more correct to say: "In this case, the Party entity must identify a group of people and/or legal entities", since you have been careful to define Party in this way. 8. Section 2.4.3 Typo "who is responsible for fulfill the Duty" should read either: >who is responsible for fulfilling the Duty" or "who is responsible to fulfill the Duty" . It occurs again later in the same paragraph. 9. Section 2.6, Legal a) I feel "jurisdiction" and "dispute resolution" need to be listed separately; they are distinct entities. b) I'm not sure how "dispute resolution" can be carefully and well-specified in a near-future timeframe. It seems it's a big concept that might be something to be worked on for ODRL 3.0 c) I don't think "Human readable notes" belongs in Legal. I think it's nice to have the notes in ODRL 2 though. Could it be put somewhere else? 10. Section 2.7, Negotiation. I feel the same as about "dispute resolution". I'll go personal here with a final comment. I've been hoping for ODRL-mediated transactions on the web 10 years; since long before I even knew about ODRL. And it would be nice to have it do everything including open cans and take the dog for a walk. And maybe it will eventually. :-) But I think it's doing great right now, even without Dispute Resolution and Negotiations (but definitely including Legal), and I'm for putting version 2 out without those two. Perhaps they can be added in an update - a version 2.5, say. I haven't read the examples yet, but this is too long anyway, so I'll send. Great work Suzanne and all! steven rowat From Steven_Rowat at sunshine.net Fri Mar 10 14:45:27 2006 From: Steven_Rowat at sunshine.net (Steven Rowat) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] New ODRL v2.0 Model Message-ID: Greetings, Further comments on the v. 2 model after reading the examples: 1. Statement. My apologies. Now I understand: it could be used as a template. 2. Offer/Agreement. Overall concern about flow in the scenario diagrams: could it be possible to set them up so they flow left-right, or top-bottom, in the same way that the code will flow? Or in some otherwise relatively straightforward order? I find in looking at the two diagrams Offer and Agreement that I don't know where to start, and where to go, in order to figure out what is going on. For example, in the Offer, my inclination would be to start with Fred, and put him top or left, since the music file wouldn't exist without him. And he's offering something. It's a music file. It has constraints and duties. So sequence might be something like: Fred -> offers -> a music file -> which can be copied -> (but only once) -> for $.50 or using the ODRL terms, but in the same order: Party (Fred) -> Rights (offer) ->Asset (music file) -> Permission (copy) -> Constraint (once) -> Duty ($.50) For me, this seems to work in this case. Maybe it will break down in larger ones; not sure. Otherwise, it all seems good. Unleash it on the world! :-) Steven Rowat From Susanne.Guth at gmx.net Sat Mar 11 11:41:43 2006 From: Susanne.Guth at gmx.net (Susanne Guth) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] Followup on Legal stuff about contracts References: <7DF2F65B-EDD4-43C3-A3D9-89EA6A5FB2A4@odrl.net> Message-ID: <22556.1142037703@www002.gmx.net> Hi Renato, thanks for the review. Please read my comments in line. New draft is available @ http://odrl.net/2.0/WD-ODRL-Model-20060310.html > > > Susanne - thanks for the update - great work. > I have some minor editing but will leave that to the end. > > Here are some more substantive questions: > > 1 - Should we have a "Change History" as the table of contents says? > (or too many changes!) Is absolutely required and has been added to the draft. > 2 - On the Model, Permission, Prohibition, and Duty all have a > "tradeable" attribute. What is this for? > Has to do with the negotiation and was discussed with Alapan in several emails. It indicates if this entity is subject to negotiation or not. Draft has been updated. > 3 - On the Model, the "inherit" association on the Asset entity > probably is best as an attribute now. I don't understand this comment please clarify. > 4 - In the Rights Class Model, where we say "the Request/Ticket (etc) > must contain an Asset" should we say "...must contain at least one > Asset" ? Agreed. Done. > > 5 - In the Permission Model, we should say that since the Permission > must contain ONE Action, that multiple Permissions are also allowed. > Also, we say that the Permission must also contain ONE Asset - can it > be multiple?? No, there must not be multiple assets in one permission unless you can identify several assets with one ID. Also there must not be multiple Actions in one permission. That's a little bit of a draw back of the presentation because it may make larger expressions very long. However, there is no ambiguouty possible what a Permission refers to anymore. > 6 - The Duty Model scenario examples have Action/Measure/Value shown, > but we only talk about Action and "Object" in the normative text? Oh, thanks. That a mistake of course. I changed the duty elements, so now they contain actions and objects. Have a look! > 7 - Legal model - Alapan, need some text definitions here (thanks!) > > 8 - I think we need to add wording to clarify the situation when > there are both Permissions and Prohibitions in the expression (and > where there is a direct conflict). I can work on that... That would be great. Thanks. > 9 - The Ticket Scenario - need to remove the Assignee party as this > is not part of a ticket I changed the describtion here. I think it should be possible to identifier an assignee. For example, if the ticket can only be executed by a specific person. > 10 - We need to add an Acknowledgments section at the end and list > all people (including from > this WG) how have contributed to the document. Done! I quickly did put the containers in. They need more semantic thought. Any comments for containers? So long Susanne -- Susanne Guth susanne@odrl.net ODRL Initiative http://odrl.net/ "Feel free" mit GMX FreeMail! Monat für Monat 10 FreeSMS inklusive! http://www.gmx.net From aarnab at cs.uct.ac.za Mon Mar 13 05:35:44 2006 From: aarnab at cs.uct.ac.za (Alapan Arnab) Date: Sat Jun 2 13:28:05 2007 Subject: [Odrl-version2] Followup on Legal stuff about contracts In-Reply-To: <26948.1141686206@www041.gmx.net> References: <1141130710.20376.37.camel@iduna> <26948.1141686206@www041.gmx.net> Message-ID: <1142188544.7159.47.camel@iduna> Hi, Sorry for the late response! Luckily, I got Susanne's last email in time ... I will respond according to the latest version (ODRL-Model-20060310). General Comments: ----------------- Africa is spelt with a C and not a K ;) My surname is spelt wrong Can we have a date for the changelog? Model Notes: ------------ In my opinion, the relationship constraints for Signature, Legal, Negotiation, Party and Encryption are incorrect. 1) Signature: The model currently reads "A rights expression will have 1 signature while a signature can belong to one or more rights expressions". Since, signatures here do refer to digital signatures, and a license should be able to have multiple (or even no) signatures I think it should rather read "A rights expression will have 0 or more signatures, while a signature is unique to the rights expression" 2) Legal: The model currently reads "A rights element will have 1 legal element while a legal element can belong to one or more rights elements". While I am a proposer for legal elements in a REL, I am not sure if it should be compulsory. It would probably be better to make it an optional element. 3) Negotiation: The model currently reads "A rights element will have 1 or more negotiation elements while the negotiation element is unique to the rights element". I think that there should be only one negotiation element and it should be optional (to cater for the systems that do not support negotiations). I have further comments on this element later. 4) Party: The model currently reads "A rights element will have 0 or 1 party while a party is unique to a rights element". Conceptually, surely a party can belong to 1 or more rights elements? Also, a rights element will often have more than 1 party and never have no parties. I think it should read "A rights element will have 1 or more parties while a party can belong to one or more rights elements" 5) Encryption: The model currently reads "An asset will have 1 encryption key, while the encryption key can belong to 0 or more assets". The later part does not make any sense - surely a key for an asset must belong to an asset. Also, this does not take unencrypted assets into account or assets with multiple keys. I think it should rather read "An asset can have 0 or more encryption keys, while the encryption key can belong to one or more assets" Element Comments ----------------- 1) Rights: - Surely the attributes should be required and not optional (will as opposed to may)? - Is there a need for NextRights as an attribute. I think it should be possible to cater for downstream rights without resorting to an extra attribute because the downstream portion of the rights will be catered for by TransferRights action. - Description should also include the new elements added 2) Legal: - jurisdiction and dispute resolution should be separate elements. It should be possible to provide both sets of information in a license. Text: jurisdiction details the courts that will have the jurisdiction in connection with all legal proceedings arising from the agreement. Dispute resolution details the arbitration process in the case of a contract dispute arising after the conclusion of the contract. - liabilities: The licensor details the extent of the liabilities incurred by the licensor in case the product does not meet the licensee's expectations or causes damages etc. (or something like that) - expiration/date issued: date should read date & time 3) Negotiation Personally I think it should read communication instead of negotiation. After all, negotiation is effectively carried on with the the Rights element (request/offer/agreement etc) Other than acceptance and rejection, it should also have a general info element. This would not only allow for simple messages that would not normally fit in, but also metadata that needs to be communicated before an agreement is signed (for example in a Music store, it could be used to detail the bit rate, the encoding format etc of the digital asset before the license is bought). Thanks for the great work Susanne! Alapan -- 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