From vickyw at cs.cornell.edu Wed Feb 1 10:42:21 2006
From: vickyw at cs.cornell.edu (Vicky Weissman)
Date: Sat Jun 2 13:28:05 2007
Subject: [Odrl-version2] Handling Prohibitions
Message-ID: <2EE48095D8C21643B0B70EC95F9BFBAFD85F79@EXCHVS1.cs.cornell.edu>
Hi All,
I've looked over the email discussions are prohibitions and, based on them, I
suggest we do the following:
(1) Extend agreements to include prohibitions, where a prohibition says that
an action is forbidden if certain conditions hold.
(2) Extend agreements to include a default, which is either permit or forbid.
(3) Say that a set of agreements imply that a request (e.g., may Alice
download Season 1 of Lost) should be granted if (a) the agreements together
imply the request should be granted or (2) the agreements together do not
imply the request should be granted, do not imply the request should be
denied, and the default for all agreements is permit.
Are there any objections?
-Vicky
From aarnab at cs.uct.ac.za Wed Feb 1 02:24:38 2006
From: aarnab at cs.uct.ac.za (Alapan Arnab)
Date: Sat Jun 2 13:28:05 2007
Subject: [Odrl-version2] resumption of containers & model update
In-Reply-To: <5860.1138581121@www082.gmx.net>
References: <5860.1138581121@www082.gmx.net>
Message-ID: <1138721079.8951.53.camel@iduna>
Hi,
> 1.) Containers
I like your approach and I think it makes a lot of sense. There is a
need to define interpretation of containers in this case though as the
license in your example could be interpreted as:
The user is allowed permission A with constraints (X) and (Y) and (X or
Y)
which is not necessarily what you mean.
> 4.)
>
> What do you guys think of removing the rights-expression-type level and
> instead using an attribute "TYPE" in rights to specify the semantics of the
> actual rights expression?
>
> I have a problem with different hierarchies of RE elements, like in alapans
> approach - simply for negotiation. If somebody wants to use ODRL without the
> negotiation part, then the hierarchies do not make sense at all. An aim
> should really be to keep the negotiation part independent of the remaining
> model.
I think this problem arose because I tried to retain as much of the old
model as possible. But your model is very close to my last model so I
think we are close to agreement on most of the issues in this regard.
> If a RE grants next rights, for example, then these nextrights have to be
> defined in a new rights expressed. RE ids would have to link the various
> rights expressions. This would have the advantage that a "nextRight" could
> more easily become part of a new agreement (I think).
>
In your model I think it will work. I do have some reservations with
regards to validity checking in XML implementations though.
Regards
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
From aarnab at cs.uct.ac.za Wed Feb 1 02:43:36 2006
From: aarnab at cs.uct.ac.za (Alapan Arnab)
Date: Sat Jun 2 13:28:05 2007
Subject: [Odrl-version2] New ODRL v2.0 Model
In-Reply-To: <18665.1138577348@www082.gmx.net>
References: <1137412528.7270.34.camel@iduna>
<18665.1138577348@www082.gmx.net>
Message-ID: <1138722216.8951.59.camel@iduna>
Hi Susanne,
Thanks a lot for the clarification - I understand the subtle difference
now and it makes a lot more sense.
But from purely an implementation point of view - if payment is an
action, wouldn't both the following code fragments be correct?
1
1
The second one does not make much sense, but I think all validity checkers
will pass it. From an implementation point of view, this could raise some
problems.
Regards
Alapan
On Mon, 2006-01-30 at 00:29 +0100, Susanne Guth wrote:
> Hi Alapan,
>
> one comment to our discussion:
>
> Maybe there is still a misunderstanding, what the action element is.
> It simply "names" the action that always comes with a permission or duty or
> prohibition.
>
> For example a duty to pay some amount would look like that:
>
> o-ex20:duty id="d01" relaxed="true">
>
> 0,50
>
>
>
>
> where "payment" is the action element. There is no duty without an action or
> "if there's no action defined then there is not duty".
>
> And after all: when expressing a prohibtion the duty element is optional
> (and implicitly the action element too).
> Does that make sense to you or is still something unclear?
>
> Susanne
> ++++++++++++++++++++++++++++
> Mail history:
>
> 4.5.4 Parties & Duties
>
> I need some more information on this issue because I don't understand
> the conflict that you have. Is it because the Duty always refers to an
> Action?
>
> Yes - a duty requires an action. However, you might want a prohibition
> license that allows everything - hence there will be no action to link
> with the duty.
>
>
--
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 aarnab at cs.uct.ac.za Wed Feb 1 20:50:11 2006
From: aarnab at cs.uct.ac.za (Alapan Arnab)
Date: Sat Jun 2 13:28:05 2007
Subject: [Odrl-version2] New ODRL v2.0 Model
In-Reply-To: <5249.1138455483@www061.gmx.net>
References: <1136968801.7279.11.camel@iduna>
<5249.1138455483@www061.gmx.net>
Message-ID: <1138787411.7247.2.camel@iduna>
Hi Susanne,
Thanks a lot for your comments - they are very much appreciated.
> 1.)
> How do you like a different title that expresses what you actually want to
> address - negotiation! Something like:
>
> "Enabling ODRL for Negotiation" or something similar. I think the overall
> approach should be, that negotiation in ODRL can be used as a plug-in. Maybe
> as a subschema? What do you think about that?
>
While I agree that much of the paper was about negotiation, there were
significant parts also to do with other aspects of ODRL - aspects that
we have now discussed in detail in the past few weeks.
As for negotiation - ODRL does not have to specifically cater for it. In
my opinion, no language can have all the vocabulary needed to express
ideas that have yet to be formed. Expressing negotiations is a matter of
vocabulary. What I am interested in is more in the structure of the
language, the grammar - so that, if new vocabulary is introduced, it
does not require a radical overhaul of the language.
In this sense, I would like ODRL to cater structurally for negotiations.
Thus, negotiations will in effect be still a plug-in as much of the
necessary vocabulary need not be in the main data dictionary - but I
think there is a need to stop developing a new REL in order to express
negotiations.
On this point, I think your proposed model (my comments on that are on a
separate email) does fulfil the requirements.
> 2.)
> On page 2 you write "there is some mandatory information". Can you be more
> concrete on this. What exactly is really mandatory? Do we have a contract
> expert among us? I know that in Germany, for example, contracts are
> formless. What is your source for the information 2.1, 2.2, 2.3, etc. can
> you refer to some business standards document?
>
As I wrote in a footnote earlier, the basis for my discussion in on
South African law, which in turn is based on common law and Roman-Dutch
law. I did rely on a law text book (ref 11) which is used to teach first
year contract law for the basics, but I do intend going over section 2
with a law professor from my university once I get back next week.
>From what I understood from the text book, there is some information
that is required to be present in a contract to be valid which include
things like the date when the contract is being entered into (or comes
into effect) etc. but I do plan on getting the information correctly
verified etc. soon.
> 3.)
> In Section 3 you define 3.Bargaining, in Section 3.3 you describe
> "Bartering". Which one is the right term?
>
My mistake - I should stick to one term - and I prefer bartering.
> 4.)
> You refer to Su et al and name the 4 components for electronic negotiations.
>
> I guess for the entire ODRL community it would be important to define where
> the "language to define rules" ends and where "the language to express
> negotiation proposals" --> ODRL starts. I there a concrete example in your
> references that show the difference between the two languages?
>
Unfortunately not. But personally I like to think of it in the following
way:
The language to express negotiation protocols is the language used
between two or more parties to express their needs and offers. Thus in a
bazaar for example it could take the form of:
Cust: "How much is this?"
Sell: "I will give it you for 50"
Cust: "That's too much, I can only offer 20"
Sell: "At that price, my kids will go hungry to bed. The best I can do
is 40"
Cust: "I can offer 30 and not more"
Sell: "35"
Cust: "Ok, but with delivery to my hotel"
Sell: "Done"
In my mind, that is what ODRL needs to do - express the negotiations and
get the final set of terms and conditions.
The "language to define rules" refers to how the seller and the customer
make up their mind on the value propositions. This could take a lot of
different factors into account - for example, previous transaction
history, the method of payment, the trustworthiness of the relevant
parties. Thus, in the above example, the seller could be calculating
his offers based on the cost price and thus maximising his profit,
while the buyer is calculating his offers based on how much money
he has in his pocket. In my opinion, standard ODRL should not be
involved in this - as there are too many permutations involved.
> 5.)
> What language would be suitable as "language to define rules"? RuleML?
>
Not sure - I do plan to tackle this issue sometime this year though ;)
It could be based on ODRL - but since this has to do with specific
installations and AI agents, I don't see a need to cater for it in ODRL
specifically.
> That's it. If time allows I will respond to the other already ongoing
> discussions. We have really important issues here...
> So long and thanks for your effort.
> :))
>
Thanks a lot for your efforts too!
Regards
Alapan
> Susanne
>
> "The customer is always right"
>
>
> >
> > Hi,
> > New year's greetings to everyone.
> >
> > As discussed with Renato and Susanne last month, I have been working on
> > a few new ideas on the ODRL v2.0 model, which I have just completed. In
> > the attached PDF, you will find a paper detailing the new model, and the
> > motivations for the changes (most of which are based on negotiations
> > support). The paper also contains 7 examples (in XML), the full schema
> > (XSD) and a sample data dictionary.
> >
> > I can forward the original source documents for the model, xml examples
> > and schema file.
> >
> > I would like your comments and feedback esp. with regards to the duty
> > and action elements (see sections 4.5.4 and 4.5.5).
> >
> > Regards
> > Alapan Arnab
> > --
> > 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
> >
>
--
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 renato at odrl.net Sun Feb 5 23:34:49 2006
From: renato at odrl.net (Renato Iannella)
Date: Sat Jun 2 13:28:05 2007
Subject: [Odrl-version2] New ODRL v2.0 Model
In-Reply-To: <1138722216.8951.59.camel@iduna>
References: <1137412528.7270.34.camel@iduna> <18665.1138577348@www082.gmx.net>
<1138722216.8951.59.camel@iduna>
Message-ID:
On 1 Feb 2006, at 01:43, Alapan Arnab wrote:
>
> But from purely an implementation point of view - if payment is an
> action, wouldn't both the following code fragments be correct?
>
>
>
> 1
>
>
>
>
>
> 1
>
>
True...
We need a way to constrain some Actions to Permissions and some to
Duties only...
Cheers
Renato Iannella
ODRL Initiative
http://odrl.net
From Susanne.Guth at gmx.net Mon Feb 6 01:37:52 2006
From: Susanne.Guth at gmx.net (Susanne Guth)
Date: Sat Jun 2 13:28:05 2007
Subject: [Odrl-version2] New ODRL v2.0 Model
References:
Message-ID: <14050.1139150272@www088.gmx.net>
Hi,
I don't have a problem with the two rights expressions below. Why do we want
to relate certain actions to duties only?
For example, if there's one special accountant in a company that is allowed
to do payments that are over 5000 ? he requires an according permission.
I think, that if we constrain a certain vocabulary to permissions/ or duties
we reduce the flexibility of our language.
I think, the software/system that uses ODRL v2 rights expressions would have
to decide what actions make sense as permissions and duties. I don't think
its our work to do. Discussion opened :)
So long
Susanne
>
>
> On 1 Feb 2006, at 01:43, Alapan Arnab wrote:
>
> >
> > But from purely an implementation point of view - if payment is an
> > action, wouldn't both the following code fragments be correct?
> >
> >
> >
> > 1
> >
> >
> >
> >
> >
> > 1
> >
> >
>
> True...
>
> We need a way to constrain some Actions to Permissions and some to
> Duties only...
>
> Cheers
>
> Renato Iannella
> ODRL Initiative
> http://odrl.net
>
>
> _______________________________________________
> 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/
Telefonieren Sie schon oder sparen Sie noch?
NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie
From Susanne.Guth at gmx.net Tue Feb 7 02:11:24 2006
From: Susanne.Guth at gmx.net (Susanne Guth)
Date: Sat Jun 2 13:28:05 2007
Subject: [Odrl-version2] New ODRL v2.0 Model
References: <1138787411.7247.2.camel@iduna>
Message-ID: <20364.1139238684@www007.gmx.net>
Hi Alapan, all!
>
> On this point, I think your proposed model (my comments on that are on a
> separate email) does fulfil the requirements.
Great, so I assume there are no major objectitons to the new model layout.
I will then describe a new draft of the ODRL v2 model and put it on the ODRL
web site. A new round of "request for comments" will start from there.
>2.)
>>On page 2 you write "there is some mandatory information". Can you be
>>more concrete on this. What exactly is really mandatory? Do we have a
>>contract expert among us? I know that in Germany, for example, contracts
>>are formless. What is your source for the information 2.1, 2.2, 2.3., ..
>>can you refer to some business standards document?
> As I wrote in a footnote earlier, the basis for my discussion in on
> South African law, which in turn is based on common law and Roman-Dutch
> law. I did rely on a law text book (ref 11) which is used to teach first
> year contract law for the basics, but I do intend going over section 2
> with a law professor from my university once I get back next week.
>
Alapan, this is an important issue and comes up again and again. I myself
tried to gather mandatory legal and business relevant attributes of
contracts, without much success. lawyers kept on telling me, that there are
no mandatory attributes or standard sets of attributes for contracts.
Furthermore there are different attributes in different contract types
(agreement for sale, marriage agreement, etc.)
But maybe you have more luck than I do. Please share your new knowledge with
us and maybe we can make a statement on the ODRL website on it.
So long
Susanne
--
Susanne Guth
susanne@odrl.net
ODRL Initiative
http://odrl.net/
Telefonieren Sie schon oder sparen Sie noch?
NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie
From vickyw at cs.cornell.edu Tue Feb 7 03:03:52 2006
From: vickyw at cs.cornell.edu (Vicky Weissman)
Date: Sat Jun 2 13:28:05 2007
Subject: [Odrl-version2] RE: ODRL-Version2 Digest, Vol 13, Issue 3
Message-ID: <2EE48095D8C21643B0B70EC95F9BFBAFD85F8A@EXCHVS1.cs.cornell.edu>
Hi All,
For what it's worth, I agree with Susanne. I don't think the ODRL language
should have two categories of actions, one for duties and one for
permissions. As Susanne says, it limits the flexibility of our language. I
agree with her that it doesn't seem to be the sort of thing we should be
doing (are we going to restrict the language to prevent any statement that
seems odd?). It also complicates the language. Finally, from a practical
standpoint, I think finding an appropriate split would be very hard (maybe
impossible). To see why, consider Alapan's motivating example:
On 1 Feb 2006, at 01:43, Alapan Arnab wrote:
>
> But from purely an implementation point of view - if payment is an
> action, wouldn't both the following code fragments be correct?
>
>
>
> 1
>
>
>
>
>
> 1
>
>
Is it really true that it would *never* make sense to have the second
statement? Suppose that a school is collecting donations for a charity; the
school gives a prize to the student who collects the most money; and to
prevent the prize from going to the kid with the richest parents, there's a
rule that each donator is permitted to pay $1 (no more and, to minimize
administration costs, no less). As another example, suppose a parent wants
to give her child money and the child doesn't want it (maybe the child feels
it makes him/her dependent, somehow less), so they work out an agreement that
the parent can pay the child $100 dollars per month. I suspect that we can
play these sorts of games for almost any action split anyone can think of.
Best,
Vicky
From renato at odrl.net Tue Feb 7 16:36:16 2006
From: renato at odrl.net (Renato Iannella)
Date: Sat Jun 2 13:28:05 2007
Subject: [Odrl-version2] RE: ODRL-Version2 Digest, Vol 13, Issue 3
In-Reply-To: <2EE48095D8C21643B0B70EC95F9BFBAFD85F8A@EXCHVS1.cs.cornell.edu>
References: <2EE48095D8C21643B0B70EC95F9BFBAFD85F8A@EXCHVS1.cs.cornell.edu>
Message-ID: <1348F8A5-3C00-4760-984D-4A1AEC377AA1@odrl.net>
On 7 Feb 2006, at 02:03, Vicky Weissman wrote:
>>
>>
>> 1
>>
>>
>>
>>
>>
>> 1
>>
>>
>
> Is it really true that it would *never* make sense to have the second
> statement?
If we looked at a use case that involves assigning rights
to digital content ;-), then it does not make sense.
Especially given the definition of Permissions:
"The Permission entity indicates the actions that the Assignee/s is
permitted to perform on the Target asset"
I would have thought that by allowing more constraint use, then the
semantics
would be clearer ??
Cheers
Renato Iannella
ODRL Initiative
http://odrl.net
From vickyw at cs.cornell.edu Wed Feb 8 12:56:02 2006
From: vickyw at cs.cornell.edu (Vicky Weissman)
Date: Sat Jun 2 13:28:05 2007
Subject: [Odrl-version2] RE: ODRL-Version2 Digest, Vol 13, Issue 5
Message-ID: <2EE48095D8C21643B0B70EC95F9BFBAFD85F96@EXCHVS1.cs.cornell.edu>
On 7 Feb 2006, at 02:03, Vicky Weissman wrote:
>>
>>
>> 1
>>
>>
>>
>>
>>
>> 1
>>
>>
>
> Is it really true that it would *never* make sense to have the second
> statement?
On 7 Feb 2006, Renato Iannella replied:
>If we looked at a use case that involves assigning rights to digital content
;-), then it does not make sense.
>
>Especially given the definition of Permissions:
>"The Permission entity indicates the actions that the Assignee/s is
permitted to perform on the Target asset"
I'm tempted to talk about targets that are online bank accounts (paying 1 EUR
= depositing 1 EUR) or online customer accounts (paying = paying off debt).
Actually, I'm more tempted to talk about targets that are avatars in
massively multiplayer games. But, as long as we agree that splitting actions
into 2 categories is probably not the way to go, then I guess I should rein
in the creativity :-)
On 7 Feb 2006, Renato Iannella Said:
> I would have thought that by allowing more constraint use, then the
semantics would be clearer ??
I don't understand this statement. Could you clarify?
Thanks,
Vicky
From renato at odrl.net Wed Feb 8 17:29:43 2006
From: renato at odrl.net (Renato Iannella)
Date: Sat Jun 2 13:28:05 2007
Subject: [Odrl-version2] RE: ODRL-Version2 Digest, Vol 13, Issue 5
In-Reply-To: <2EE48095D8C21643B0B70EC95F9BFBAFD85F96@EXCHVS1.cs.cornell.edu>
References: <2EE48095D8C21643B0B70EC95F9BFBAFD85F96@EXCHVS1.cs.cornell.edu>
Message-ID: <34856CA8-F389-4493-A614-C2DBCE7C95A1@odrl.net>
On 8 Feb 2006, at 11:56, Vicky Weissman wrote:
>> I would have thought that by allowing more constraint use, then the
>> semantics would be clearer ??
> I don't understand this statement. Could you clarify?
The question is: are all Permissions valid Duties (and vice-versa) ??
Cheers...
Renato
From aarnab at cs.uct.ac.za Wed Feb 8 19:11:50 2006
From: aarnab at cs.uct.ac.za (Alapan Arnab)
Date: Sat Jun 2 13:28:05 2007
Subject: [Odrl-version2] RE: ODRL-Version2 Digest, Vol 13, Issue 3
In-Reply-To: <2EE48095D8C21643B0B70EC95F9BFBAFD85F8A@EXCHVS1.cs.cornell.edu>
References: <2EE48095D8C21643B0B70EC95F9BFBAFD85F8A@EXCHVS1.cs.cornell.edu>
Message-ID: <1139386310.7278.26.camel@iduna>
Hi,
I see and accept Vicky and Susanne's points on the matter of the action
element. It makes sense - at least it was clarified ;)
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
From aarnab at cs.uct.ac.za Fri Feb 10 01:59:24 2006
From: aarnab at cs.uct.ac.za (Alapan Arnab)
Date: Sat Jun 2 13:28:05 2007
Subject: [Odrl-version2] Handling Prohibitions
In-Reply-To: <2EE48095D8C21643B0B70EC95F9BFBAFD85F79@EXCHVS1.cs.cornell.edu>
References: <2EE48095D8C21643B0B70EC95F9BFBAFD85F79@EXCHVS1.cs.cornell.edu>
Message-ID: <1139497164.7275.22.camel@iduna>
Hi,
After rethinking on the issues discussed recently, I am wondering if
there there is a need for prohibitions in the first place?
The permissions in a license come from a finite set defined in a data
dictionary. Ideally, the DRM controller should only enforce the
permissions defined by their respective permission sets. Thus take a
random permission, p, and a permission set PS. There can be four
possibilities.
p is an element of PS, and appears in the license: In this case, the
permission is granted to the assignee
p is an element of PS, and does not appear in the license: In this case,
the permission is not granted to the assignee
p is not an element of PS, and does not appear in the license: In this
case, the DRM controller has no say on whether the permission is allowed
or not.
p is not an element of PS, and appears in the license: This creates an
invalid license as the license is using terms that do not exist.
If we look at the permissions in a license in this way, I do not see why
a prohibition is necessary. Even a "all rights but" statement, is purely
a contraction, and as Vicky suggested a tool to convert from a "all
rights but" to a proper rights statement is a better approach.
The one issue that remains is off course a change in permission sets -
specifically if the permission set changes without a change in the
namespace of the permission set. Changing namespaces once published
should be discouraged, but I do not see a technical solution to this
problem.
Regards,
Alapan
On Tue, 2006-01-31 at 18:42 -0500, Vicky Weissman wrote:
> Hi All,
>
> I've looked over the email discussions are prohibitions and, based on them, I
> suggest we do the following:
>
> (1) Extend agreements to include prohibitions, where a prohibition says that
> an action is forbidden if certain conditions hold.
>
> (2) Extend agreements to include a default, which is either permit or forbid.
>
> (3) Say that a set of agreements imply that a request (e.g., may Alice
> download Season 1 of Lost) should be granted if (a) the agreements together
> imply the request should be granted or (2) the agreements together do not
> imply the request should be granted, do not imply the request should be
> denied, and the default for all agreements is permit.
>
> Are there any objections?
>
> -Vicky
> _______________________________________________
> 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 vickyw at cs.cornell.edu Fri Feb 10 04:51:17 2006
From: vickyw at cs.cornell.edu (Vicky Weissman)
Date: Sat Jun 2 13:28:05 2007
Subject: [Odrl-version2] RE: ODRL-Version2 Digest, Vol 13, Issue 6
Message-ID: <2EE48095D8C21643B0B70EC95F9BFBAFD85FA9@EXCHVS1.cs.cornell.edu>
The question is: are all Permissions valid Duties (and vice-versa) ??
According to the May 16 2005 draft of the model semantics, a Permission is a
tuple (act, target, cons, dut), where act is an action, target is an asset,
cons is a possibly empty set of constraints, and dut is a possibly empty set
of duties. A Duty is either a tuple (act, obj, cons, rel) or a tuple (act,
obj, cons), where act is an action, obj is either an asset or a list of
names, cons is a possibly empty set of constraints, and rel is a Boolean flag
indicating that the duty can be fulfilled at any time (and hence is no duty
at all?).
Given the definitions, I'm not sure any permission is a valid duty (or
vice-versa). If we assume that a permission/duty can omit elements if they
are the emptyset, then there's overlap (e.g., permissions of the form (act,
target) are also duties). Nevertheless, every permission that includes a
non-empty set of duties is not a duty. Every duty that includes the optional
rel flag is not a permission.
I'm pretty sure that I've misunderstood your question. .... Are you asking
if there is an action that can appear as the first element of a permission
and not as the first element of a duty (or vice-versa)? If so, then I guess
the answer is that they're your definitions, so you can do whatever you want.
But I don't see any reason why we would want to build such restrictions into
ODRL. Moreover, having an action that can appear only in a duty seems a bit
odd since it suggests an individual can be obligated to perform an action act
on an object and cannot get (explicit) permission to do act.
I get the feeling I'm missing the big picture. Would welcome a clue.
Best,
Vicky
From vickyw at cs.cornell.edu Sat Feb 11 04:34:04 2006
From: vickyw at cs.cornell.edu (Vicky Weissman)
Date: Sat Jun 2 13:28:05 2007
Subject: [Odrl-version2] Prohibitions - the saga continues...
Message-ID: <2EE48095D8C21643B0B70EC95F9BFBAFD85FB0@EXCHVS1.cs.cornell.edu>
After rethinking on the issues discussed recently, I am wondering if there
there is a need for prohibitions in the first place?
Most of the contracts (e.g., user agreements, leases) that I've read give
permissions, prohibitions, and obligations. I figure that the people who
drew up these documents were saying what they felt needed to be said. So I
think it would be wise for ODRL to include such statements.
>From a technical standpoint, if ODRL does not include prohibitions, then an
ODRL agreement cannot distinguish between what is forbidden and what is
unregulated. Whether this distinction is important depends on the intended
uses for ODRL. For example, suppose that ODRL is designed solely for
applications in which a user gets access by presenting an appropriate
agreement, namely one that grants the permission. Then I'm not sure that the
distinction is important. But, if we stray just a bit from this model, then
I think we'll want prohibitions. To see why, consider the following example.
Suppose that a database of clinical information is jointly owned by hospital
H and research institute R. To get access, an individual needs to present
agreements from both H and R that together imply the permission. Notice that
we've stepped out of the model I gave in the last paragraph because it's not
enough to present an agreement; you have to give agreements from both H and
R. Now I think we want prohibitions because we want to detect conflicts
between H and R (e.g., H permits an access that R forbids). In fact, I think
my earlier suggestion is well-suited to this scenario. Recall the suggestion
from my Jan 31 mail:
> I suggest we do the following:
>
> (1) Extend agreements to include prohibitions, where a prohibition
> says that an action is forbidden if certain conditions hold.
>
> (2) Extend agreements to include a default, which is either permit or
forbid.
>
> (3) Say that a set of agreements imply that a request (e.g., may Alice
> download Season 1 of Lost) should be granted if (a) the agreements
> together imply the request should be granted or (2) the agreements
> together do not imply the request should be granted, do not imply the
> request should be denied, and the default for all agreements is permit.
This approach allows H and R to write agreements that (a) give the conditions
under which access should be permitted and (b) give the conditions under
which access should be denied. So we can detect if H and R disagree on
certain cases, thereby giving them a chance to resolve the dispute. In
addition (3) allows H/R to give the default "forbid" so that, if neither
explicitly permits the action, then it's forbidden.
What's missing from my suggestion is support for statements such as "if H
doesn't explicit give permission, then H forbids". We could extend
agreements to include such statements, but I think it would be better to make
changes at a higher level; that is, instead of requiring that H and R's
agreements together imply permission, the application could require that H's
agreement(s) implies permission and R's agreement(s) implies permission.
Having the change at this level keeps agreements fairly simple and allows for
more flexibility when combining agreements. For example, the application
could support voting (e.g., if most of the interested parties grant
permission, then permission is granted).
In general, I think my suggestion is a good way to handle permissions based
on multiple agreements. It also works just fine for the simpler case in
which any agreement will suffice (in which case the user presents only the
agreement that is most favorable to her, or the application considers the set
of presented agreements one-by-one).
-Vicky
From aarnab at cs.uct.ac.za Mon Feb 13 19:21:07 2006
From: aarnab at cs.uct.ac.za (Alapan Arnab)
Date: Sat Jun 2 13:28:05 2007
Subject: [Odrl-version2] Prohibitions - the saga continues...
In-Reply-To: <2EE48095D8C21643B0B70EC95F9BFBAFD85FB0@EXCHVS1.cs.cornell.edu>
References: <2EE48095D8C21643B0B70EC95F9BFBAFD85FB0@EXCHVS1.cs.cornell.edu>
Message-ID: <1139818867.7274.0.camel@iduna>
Hi,
I don't think prohibitions are necessary at all to handle the scenario
you posted. I will try to give a logical proof why (I have ignored
invalid licenses):
Notation:
E -> element of
H -> license agreement from Hospital
R -> license agreement from Research Institute
HPS-> hospital license permission set
RPS-> research institute permission set
x -> the permission in question
pH -> permission granted by DRM controller (Hospital)
pR -> permission granted by DRM controller (RI)
pJ -> permission granted by DRM controller (joint data)
& -> and
! -> not
Rules:
1. x E HPS & x E H -> pH
2. x !E HPS & x !E H -> pH
3. x E HPS & x E H -> !pH
4. x E RPS & x E R -> pR
5. x !E RPS & x !E R -> pR
6. x E RPS & x E R -> !pR
7. pR & pH -> pJ
>From the above, it is clear, that [7] is satisfied iff ([1] | [2]) &
([4] | [5]).
The situation you describe is correctly handled.
I agree that explicit forbid is not handled, but that can be easily
handled by how x !E RPS is handled (i.e. forbid everything except what
is explicitly permitted). But in my opinion, this is a wrong approach,
and if the license holders need to control a right, that right should be
in the permission set.
Alapan
On Fri, 2006-02-10 at 12:34 -0500, Vicky Weissman wrote:
>
> After rethinking on the issues discussed recently, I am wondering if there
> there is a need for prohibitions in the first place?
>
>
> Most of the contracts (e.g., user agreements, leases) that I've read give
> permissions, prohibitions, and obligations. I figure that the people who
> drew up these documents were saying what they felt needed to be said. So I
> think it would be wise for ODRL to include such statements.
>
> >From a technical standpoint, if ODRL does not include prohibitions, then an
> ODRL agreement cannot distinguish between what is forbidden and what is
> unregulated. Whether this distinction is important depends on the intended
> uses for ODRL. For example, suppose that ODRL is designed solely for
> applications in which a user gets access by presenting an appropriate
> agreement, namely one that grants the permission. Then I'm not sure that the
> distinction is important. But, if we stray just a bit from this model, then
> I think we'll want prohibitions. To see why, consider the following example.
>
>
> Suppose that a database of clinical information is jointly owned by hospital
> H and research institute R. To get access, an individual needs to present
> agreements from both H and R that together imply the permission. Notice that
> we've stepped out of the model I gave in the last paragraph because it's not
> enough to present an agreement; you have to give agreements from both H and
> R. Now I think we want prohibitions because we want to detect conflicts
> between H and R (e.g., H permits an access that R forbids). In fact, I think
> my earlier suggestion is well-suited to this scenario. Recall the suggestion
> from my Jan 31 mail:
>
> > I suggest we do the following:
> >
> > (1) Extend agreements to include prohibitions, where a prohibition
> > says that an action is forbidden if certain conditions hold.
> >
> > (2) Extend agreements to include a default, which is either permit or
> forbid.
> >
> > (3) Say that a set of agreements imply that a request (e.g., may Alice
> > download Season 1 of Lost) should be granted if (a) the agreements
> > together imply the request should be granted or (2) the agreements
> > together do not imply the request should be granted, do not imply the
> > request should be denied, and the default for all agreements is permit.
>
> This approach allows H and R to write agreements that (a) give the conditions
> under which access should be permitted and (b) give the conditions under
> which access should be denied. So we can detect if H and R disagree on
> certain cases, thereby giving them a chance to resolve the dispute. In
> addition (3) allows H/R to give the default "forbid" so that, if neither
> explicitly permits the action, then it's forbidden.
>
> What's missing from my suggestion is support for statements such as "if H
> doesn't explicit give permission, then H forbids". We could extend
> agreements to include such statements, but I think it would be better to make
> changes at a higher level; that is, instead of requiring that H and R's
> agreements together imply permission, the application could require that H's
> agreement(s) implies permission and R's agreement(s) implies permission.
> Having the change at this level keeps agreements fairly simple and allows for
> more flexibility when combining agreements. For example, the application
> could support voting (e.g., if most of the interested parties grant
> permission, then permission is granted).
>
> In general, I think my suggestion is a good way to handle permissions based
> on multiple agreements. It also works just fine for the simpler case in
> which any agreement will suffice (in which case the user presents only the
> agreement that is most favorable to her, or the application considers the set
> of presented agreements one-by-one).
>
> -Vicky
>
>
>
>
>
> _______________________________________________
> 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 vickyw at cs.cornell.edu Tue Feb 14 14:12:47 2006
From: vickyw at cs.cornell.edu (Vicky Weissman)
Date: Sat Jun 2 13:28:05 2007
Subject: [Odrl-version2] Prohibitions - the saga continues...Reply to Alapan
Message-ID: <2EE48095D8C21643B0B70EC95F9BFBAFD85FB2@EXCHVS1.cs.cornell.edu>
Hi ,
On Feb 10, Vicky Weissman said:
-------------------------------
... Suppose that a database of clinical information is jointly owned by
hospital H and research institute R. To get access, an individual needs to
present agreements from both H and R that together imply the permission...
Now I think we want prohibitions because we want to detect conflicts between
H and R (e.g., H permits an access that R forbids).
On Feb 13, Alapan Arnab replied:
--------------------------------
I don't think prohibitions are necessary at all to handle the scenario you
posted. I will try to give a logical proof why (I have ignored invalid
licenses):
Notation:
E -> element of
H -> license agreement from Hospital
R -> license agreement from Research Institute
HPS-> hospital license permission set
RPS-> research institute permission set
x -> the permission in question
pH -> permission granted by DRM controller (Hospital) pR -> permission
granted by DRM controller (RI) pJ -> permission granted by DRM controller
(joint data)
& -> and
! -> not
Rules:
1. x E HPS & x E H -> pH
2. x !E HPS & x !E H -> pH
3. x E HPS & x E H -> !pH
4. x E RPS & x E R -> pR
5. x !E RPS & x !E R -> pR
6. x E RPS & x E R -> !pR
7. pR & pH -> pJ
>From the above, it is clear, that [7] is satisfied iff ([1] | [2]) & ([4] |
[5]).
Vicky Weissman, replying:
---------------------------
I don't understand your notation. In particular, I don't see why rule 1
doesn't contradict rule 3 (and, similarly, why rule 4 doesn't contradict rule
6). My best guess is that, for each DRM controller, you're maintaining two
sets of information. A permission is granted if it is in the controller's
permission set and in the agreement; a permission is denied if it is in the
controller's permission set and not in the agreement; and it is unregulated
if it is not in the permission set nor in the agreement. If this is the
case, then you're essentially capturing prohibitions explicitly (as the
difference between 2 sets), and you might as well do it in the standard way;
that is, with permissions and prohibitions, instead of with permissions and a
superset of regulated actions.
Regardless of your specific work-around, I do think that, for the example I
gave, we want to distinguish forbidden actions from unregulated ones.
(Having both permissions and prohibitions is, I believe, the most common way
to do this.) To clarify my thinking, suppose that Alice wants to access the
clinical database directly and, to get access, she presents an agreement
agr_H from the hospital that says "Alice may query the database" and she
presents an agreement agr_R from the research institute that says "Alice may
access the database directly". Should Alice be given access? If ODRL
includes prohibitions, then agr_H does not object to Alice accessing the
database and, as a result, I think the request should be granted. If ODRL
does not include prohibitions, then we can't tell whether the hospital does
not object, in which case access should be granted, or the hospital forbids
the action, in which case H and R contradict one another and some "default"
action should be done (e.g., contact H and R so they can work out the
disagreement, or give Alice access to a perturbed version of the database).
-Vicky
From renato at odrl.net Tue Feb 14 18:14:15 2006
From: renato at odrl.net (Renato Iannella)
Date: Sat Jun 2 13:28:05 2007
Subject: [Odrl-version2] Prohibitions - the saga continues...
In-Reply-To: <2EE48095D8C21643B0B70EC95F9BFBAFD85FB0@EXCHVS1.cs.cornell.edu>
References: <2EE48095D8C21643B0B70EC95F9BFBAFD85FB0@EXCHVS1.cs.cornell.edu>
Message-ID: <852592CE-E5E1-4101-AFB3-08E597B7CFBF@odrl.net>
On 11 Feb 2006, at 03:34, Vicky Weissman wrote:
> Most of the contracts (e.g., user agreements, leases) that I've
> read give
> permissions, prohibitions, and obligations. I figure that the
> people who
> drew up these documents were saying what they felt needed to be
> said. So I
> think it would be wise for ODRL to include such statements.
Correct - these are the real user-requirements for the enhancements
for V2.0
We need to explicit support Prohibitions in the model...
Cheers
Renato Iannella
ODRL Initiative
http://odrl.net
From renato at odrl.net Tue Feb 14 18:21:20 2006
From: renato at odrl.net (Renato Iannella)
Date: Sat Jun 2 13:28:05 2007
Subject: [Odrl-version2] RE: ODRL-Version2 Digest, Vol 13, Issue 6
In-Reply-To: <2EE48095D8C21643B0B70EC95F9BFBAFD85FA9@EXCHVS1.cs.cornell.edu>
References: <2EE48095D8C21643B0B70EC95F9BFBAFD85FA9@EXCHVS1.cs.cornell.edu>
Message-ID:
On 10 Feb 2006, at 03:51, Vicky Weissman wrote:
> I'm pretty sure that I've misunderstood your question. .... Are
> you asking
> if there is an action that can appear as the first element of a
> permission
> and not as the first element of a duty (or vice-versa)? If so,
> then I guess
> the answer is that they're your definitions, so you can do whatever
> you want.
> But I don't see any reason why we would want to build such
> restrictions into
> ODRL.
Nope...I'm just trying to see if there is a logical need to
enable communities (ie, those that build ODRL Profiles)
to support stating that Actions A,B,C are permissions and
Actions C,D,E are Duties.
Cheers
Renato Iannella
ODRL Initiative
http://odrl.net
From aarnab at cs.uct.ac.za Tue Feb 14 19:46:37 2006
From: aarnab at cs.uct.ac.za (Alapan Arnab)
Date: Sat Jun 2 13:28:05 2007
Subject: [Odrl-version2] Prohibitions - the saga continues...Reply to
Alapan
In-Reply-To: <2EE48095D8C21643B0B70EC95F9BFBAFD85FB2@EXCHVS1.cs.cornell.edu>
References: <2EE48095D8C21643B0B70EC95F9BFBAFD85FB2@EXCHVS1.cs.cornell.edu>
Message-ID: <1139906797.7476.15.camel@iduna>
Hi,
Sorry - I should have reread my email carefully .... copy and paste
always goes wrong. [3] should have read x E HPS & x !E H -> !pH
Anyway, the idea I am trying to get to:
The actions that need to be controlled (in any way) must be controlled
through a pre-defined set of permissions (permission set) (in ODRL 1.1,
the standard data dictionary was the standard permission set). For
example, for a music store, the permission set could be : [open, play,
remix, read]. Thus, the music store _chooses_ to control only those
permissions. Thus a license using that permission set can only control
those permissions. In such a license, the permission to "watch" has no
meaning and can be seen to be unregulated. The DRM controller in such a
case should allow that action (although it has no real meaning).
Now suppose you have two different licenses using different permission
sets that cover a common data file. The DRM controller can be setup to
only allow an action if both licenses allow that action. Thus, the only
times an action would be allowed is:
1) the action is unregulated by both licenses
2) the action is regulated and allowed by both licenses
My question is - given that the permission set is always finite, can
there be a scenario where a prohibition is explicitly required?
Regards
Alapan
On Mon, 2006-02-13 at 22:12 -0500, Vicky Weissman wrote:
> Hi ,
>
> On Feb 10, Vicky Weissman said:
> -------------------------------
> ... Suppose that a database of clinical information is jointly owned by
> hospital H and research institute R. To get access, an individual needs to
> present agreements from both H and R that together imply the permission...
> Now I think we want prohibitions because we want to detect conflicts between
> H and R (e.g., H permits an access that R forbids).
>
> On Feb 13, Alapan Arnab replied:
> --------------------------------
> I don't think prohibitions are necessary at all to handle the scenario you
> posted. I will try to give a logical proof why (I have ignored invalid
> licenses):
>
> Notation:
> E -> element of
> H -> license agreement from Hospital
> R -> license agreement from Research Institute
> HPS-> hospital license permission set
> RPS-> research institute permission set
> x -> the permission in question
> pH -> permission granted by DRM controller (Hospital) pR -> permission
> granted by DRM controller (RI) pJ -> permission granted by DRM controller
> (joint data)
>
> & -> and
> ! -> not
>
> Rules:
> 1. x E HPS & x E H -> pH
> 2. x !E HPS & x !E H -> pH
> 3. x E HPS & x E H -> !pH
>
> 4. x E RPS & x E R -> pR
> 5. x !E RPS & x !E R -> pR
> 6. x E RPS & x E R -> !pR
>
> 7. pR & pH -> pJ
>
> >From the above, it is clear, that [7] is satisfied iff ([1] | [2]) & ([4] |
> [5]).
>
> Vicky Weissman, replying:
> ---------------------------
> I don't understand your notation. In particular, I don't see why rule 1
> doesn't contradict rule 3 (and, similarly, why rule 4 doesn't contradict rule
> 6). My best guess is that, for each DRM controller, you're maintaining two
> sets of information. A permission is granted if it is in the controller's
> permission set and in the agreement; a permission is denied if it is in the
> controller's permission set and not in the agreement; and it is unregulated
> if it is not in the permission set nor in the agreement. If this is the
> case, then you're essentially capturing prohibitions explicitly (as the
> difference between 2 sets), and you might as well do it in the standard way;
> that is, with permissions and prohibitions, instead of with permissions and a
> superset of regulated actions.
>
> Regardless of your specific work-around, I do think that, for the example I
> gave, we want to distinguish forbidden actions from unregulated ones.
> (Having both permissions and prohibitions is, I believe, the most common way
> to do this.) To clarify my thinking, suppose that Alice wants to access the
> clinical database directly and, to get access, she presents an agreement
> agr_H from the hospital that says "Alice may query the database" and she
> presents an agreement agr_R from the research institute that says "Alice may
> access the database directly". Should Alice be given access? If ODRL
> includes prohibitions, then agr_H does not object to Alice accessing the
> database and, as a result, I think the request should be granted. If ODRL
> does not include prohibitions, then we can't tell whether the hospital does
> not object, in which case access should be granted, or the hospital forbids
> the action, in which case H and R contradict one another and some "default"
> action should be done (e.g., contact H and R so they can work out the
> disagreement, or give Alice access to a perturbed version of the database).
>
> -Vicky
>
>
>
>
>
>
>
> _______________________________________________
> 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 aarnab at cs.uct.ac.za Thu Feb 23 00:47:46 2006
From: aarnab at cs.uct.ac.za (Alapan Arnab)
Date: Sat Jun 2 13:28:05 2007
Subject: [Odrl-version2] resumption of containers & model update
In-Reply-To: <5860.1138581121@www082.gmx.net>
References: <5860.1138581121@www082.gmx.net>
Message-ID: <1140616066.13777.2.camel@iduna>
Hi Susanne, everyone else
I am still working on the contracts issue - semester just started, so
academic staff are a little hard to get hold of.
A question on the model posted - I see the absence of the
"statement"/"ticket" etc. Is this feature removed? Or is this
incorporated in the type attribute?
If its the later, I have a slight problem (not only with the
implications for negotiations) - but for standard usage also, as it will
limit the comparability of different licenses. For example, it would not
be possible to offer a ticket and a contract on the same digital object
as their offers would look the same (i think ...)
If it's the former .. I have no problem with it ;)
Regards
Alapan
On Mon, 2006-01-30 at 01:32 +0100, Susanne Guth wrote:
> Hi everybody,
>
> as you can see from my various emails this was an ODRL weekend for me :)
>
> >From reading through the discussions I found the following:
>
> 1.) we need containers
> 2.) we need prohibitions
> 3.) we need contractual details and negotition elements
> 4.) the model has simplification potential
>
> I worked a little bit on the model that you can see attached. This is - of
> course - only a draft and no new v2 model.
>
> 1.) Containers
>
> I added a container element which is not properly related to the other
> elements. Container have the attributes
>
> BIND containing e.g. OR, AND
> TYPE containing e.g. "Container of Constraints"
> RELATEDTO containing the element that includes the container.
>
> I think that we would have to carefully describe in our semantics what each
> container type means, so that we provide a chance to implement the language.
>
> Container Example
>
>
> 20
>
>
>
>
>
> 31-12-2004
>
>
>
>
>
>
>
>
>
> 2.)
>
> I kept prohibitions as they were. However, this issue need further
> discussion. The important question is if we can formalise the model with
> prohibitions in it... vicky I count on you here :)
>
> 3.)
>
> I added the negotiation and communication elements. Details (attributes must
> be discussed.
>
> 4.)
>
> What do you guys think of removing the rights-expression-type level and
> instead using an attribute "TYPE" in rights to specify the semantics of the
> actual rights expression?
>
> I have a problem with different hierarchies of RE elements, like in alapans
> approach - simply for negotiation. If somebody wants to use ODRL without the
> negotiation part, then the hierarchies do not make sense at all. An aim
> should really be to keep the negotiation part independent of the remaining
> model.
>
> If a RE grants next rights, for example, then these nextrights have to be
> defined in a new rights expressed. RE ids would have to link the various
> rights expressions. This would have the advantage that a "nextRight" could
> more easily become part of a new agreement (I think).
>
> Comments?
>
> --
> Susanne Guth
> susanne@odrl.net
> ODRL Initiative
> http://odrl.net/
>
> DSL-Aktion wegen groer Nachfrage bis 28.2.2006 verlngert:
> GMX DSL-Flatrate 1 Jahr kostenlos* http://www.gmx.net/de/go/dsl
> _______________________________________________ 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 Thu Feb 23 08:00:11 2006
From: Susanne.Guth at gmx.net (Susanne Guth)
Date: Sat Jun 2 13:28:05 2007
Subject: [Odrl-version2] resumption of containers & model update
References: <1140616066.13777.2.camel@iduna>
Message-ID: <18339.1140642011@www032.gmx.net>
Hi Alapan,
its the latter, but I don't understand the concerns you have. Please
reformulate what you think the problem is. Thanks
Susanne
>
> Hi Susanne, everyone else
> I am still working on the contracts issue - semester just started, so
> academic staff are a little hard to get hold of.
>
> A question on the model posted - I see the absence of the
> "statement"/"ticket" etc. Is this feature removed? Or is this
> incorporated in the type attribute?
>
> If its the later, I have a slight problem (not only with the
> implications for negotiations) - but for standard usage also, as it will
> limit the comparability of different licenses. For example, it would not
> be possible to offer a ticket and a contract on the same digital object
> as their offers would look the same (i think ...)
>
> If it's the former .. I have no problem with it ;)
>
> Regards
> Alapan
> On Mon, 2006-01-30 at 01:32 +0100, Susanne Guth wrote:
> > Hi everybody,
> >
> > as you can see from my various emails this was an ODRL weekend for me :)
> >
> > >From reading through the discussions I found the following:
> >
> > 1.) we need containers
> > 2.) we need prohibitions
> > 3.) we need contractual details and negotition elements
> > 4.) the model has simplification potential
> >
> > I worked a little bit on the model that you can see attached. This is -
> of
> > course - only a draft and no new v2 model.
> >
> > 1.) Containers
> >
> > I added a container element which is not properly related to the other
> > elements. Container have the attributes
> >
> > BIND containing e.g. OR, AND
> > TYPE containing e.g. "Container of Constraints"
> > RELATEDTO containing the element that includes the container.
> >
> > I think that we would have to carefully describe in our semantics what
> each
> > container type means, so that we provide a chance to implement the
> language.
> >
> > Container Example
> >
> >
> > 20
> >
> >
> >
> >
> >
> > 31-12-2004
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 2.)
> >
> > I kept prohibitions as they were. However, this issue need further
> > discussion. The important question is if we can formalise the model with
> > prohibitions in it... vicky I count on you here :)
> >
> > 3.)
> >
> > I added the negotiation and communication elements. Details (attributes
> must
> > be discussed.
> >
> > 4.)
> >
> > What do you guys think of removing the rights-expression-type level and
> > instead using an attribute "TYPE" in rights to specify the semantics of
> the
> > actual rights expression?
> >
> > I have a problem with different hierarchies of RE elements, like in
> alapans
> > approach - simply for negotiation. If somebody wants to use ODRL without
> the
> > negotiation part, then the hierarchies do not make sense at all. An aim
> > should really be to keep the negotiation part independent of the
> remaining
> > model.
> >
> > If a RE grants next rights, for example, then these nextrights have to
> be
> > defined in a new rights expressed. RE ids would have to link the various
> > rights expressions. This would have the advantage that a "nextRight"
> could
> > more easily become part of a new agreement (I think).
> >
> > Comments?
> >
> > --
> > Susanne Guth
> > susanne@odrl.net
> > ODRL Initiative
> > http://odrl.net/
> >
> > DSL-Aktion wegen groer Nachfrage bis 28.2.2006 verlngert:
> > GMX DSL-Flatrate 1 Jahr kostenlos* http://www.gmx.net/de/go/dsl
> > _______________________________________________ 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
susanne@odrl.net
ODRL Initiative
http://odrl.net/
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner
From aarnab at cs.uct.ac.za Sat Feb 25 01:28:26 2006
From: aarnab at cs.uct.ac.za (Alapan Arnab)
Date: Sat Jun 2 13:28:05 2007
Subject: [Odrl-version2] resumption of containers & model update
In-Reply-To: <18339.1140642011@www032.gmx.net>
References: <1140616066.13777.2.camel@iduna>
<18339.1140642011@www032.gmx.net>
Message-ID: <1140791306.7299.25.camel@iduna>
Hi Susanne,
On the legal issues - I will have an answer for you hopefully on Monday,
latest Tuesday.
On the type issue:
Lets say you have a music file "Hello World" and as the rights holder
you would like to offer two types of licences:
1) A short-time limited license (one day) that does not restrict usage
to any particular person, which costs 20 Euro cents
2) A person limited license, which restricts who can use the music file,
but does not impose any time limit, which costs 1 Euro.
In ODRLL v2.0, (1) is catered for by a Ticket and (2) is catered for by
a contract.
Now, when the user goes to acquire this license, the license server will
first present the two offers, (1) and (2) and the user can then select
which one (s)he likes, and proceed.
In this case, it would be nice to reflect, in the offers themselves,
that (1) is a ticket, and (2) is a contract.
There in no real need to create an additional element, it could be all
handled as an extra attribute.
On another note - I was looking at the DMP negotiations call - and I am
considering submitting the ODRL negotiations approach. One of the
requirements is "setting a parameter as non-negotiable", which would
require the creation of an additional attribute for every negotiable
element.
Alapan
On Wed, 2006-02-22 at 22:00 +0100, Susanne Guth wrote:
> Hi Alapan,
>
> its the latter, but I don't understand the concerns you have. Please
> reformulate what you think the problem is. Thanks
>
> Susanne
>
> >
> > Hi Susanne, everyone else
> > I am still working on the contracts issue - semester just started, so
> > academic staff are a little hard to get hold of.
> >
> > A question on the model posted - I see the absence of the
> > "statement"/"ticket" etc. Is this feature removed? Or is this
> > incorporated in the type attribute?
> >
> > If its the later, I have a slight problem (not only with the
> > implications for negotiations) - but for standard usage also, as it will
> > limit the comparability of different licenses. For example, it would not
> > be possible to offer a ticket and a contract on the same digital object
> > as their offers would look the same (i think ...)
> >
> > If it's the former .. I have no problem with it ;)
> >
> > Regards
> > Alapan
> > On Mon, 2006-01-30 at 01:32 +0100, Susanne Guth wrote:
> > > Hi everybody,
> > >
> > > as you can see from my various emails this was an ODRL weekend for me :)
> > >
> > > >From reading through the discussions I found the following:
> > >
> > > 1.) we need containers
> > > 2.) we need prohibitions
> > > 3.) we need contractual details and negotition elements
> > > 4.) the model has simplification potential
> > >
> > > I worked a little bit on the model that you can see attached. This is -
> > of
> > > course - only a draft and no new v2 model.
> > >
> > > 1.) Containers
> > >
> > > I added a container element which is not properly related to the other
> > > elements. Container have the attributes
> > >
> > > BIND containing e.g. OR, AND
> > > TYPE containing e.g. "Container of Constraints"
> > > RELATEDTO containing the element that includes the container.
> > >
> > > I think that we would have to carefully describe in our semantics what
> > each
> > > container type means, so that we provide a chance to implement the
> > language.
> > >
> > > Container Example
> > >
> > >
> > > 20
> > >
> > >
> > >
> > >
> > >
> > > 31-12-2004
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > 2.)
> > >
> > > I kept prohibitions as they were. However, this issue need further
> > > discussion. The important question is if we can formalise the model with
> > > prohibitions in it... vicky I count on you here :)
> > >
> > > 3.)
> > >
> > > I added the negotiation and communication elements. Details (attributes
> > must
> > > be discussed.
> > >
> > > 4.)
> > >
> > > What do you guys think of removing the rights-expression-type level and
> > > instead using an attribute "TYPE" in rights to specify the semantics of
> > the
> > > actual rights expression?
> > >
> > > I have a problem with different hierarchies of RE elements, like in
> > alapans
> > > approach - simply for negotiation. If somebody wants to use ODRL without
> > the
> > > negotiation part, then the hierarchies do not make sense at all. An aim
> > > should really be to keep the negotiation part independent of the
> > remaining
> > > model.
> > >
> > > If a RE grants next rights, for example, then these nextrights have to
> > be
> > > defined in a new rights expressed. RE ids would have to link the various
> > > rights expressions. This would have the advantage that a "nextRight"
> > could
> > > more easily become part of a new agreement (I think).
> > >
> > > Comments?
> > >
> > > --
> > > Susanne Guth
> > > susanne@odrl.net
> > > ODRL Initiative
> > > http://odrl.net/
> > >
> > > DSL-Aktion wegen groer Nachfrage bis 28.2.2006 verlngert:
> > > GMX DSL-Flatrate 1 Jahr kostenlos* http://www.gmx.net/de/go/dsl
> > > _______________________________________________ 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
> >
>
--
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 Sat Feb 25 03:53:16 2006
From: Susanne.Guth at gmx.net (Susanne Guth)
Date: Sat Jun 2 13:28:05 2007
Subject: [Odrl-version2] resumption of containers & model update
References: <1140791306.7299.25.camel@iduna>
Message-ID: <7433.1140799996@www056.gmx.net>
Hi Alapan,
I think there is a logic tongh twister in your example. You can not
negotiate if you would like agree to a "ticket" or a "contract". A ticket
results from a contract. And an offer can only result by the confirmation of
an agreement. The field "rights expression type" only describes what the
rights expression represents. OK? Are all your concerns cleared?
> On another note - I was looking at the DMP negotiations call - and I am
> considering submitting the ODRL negotiations approach. One of the
> requirements is "setting a parameter as non-negotiable", which would
> require the creation of an additional attribute for every negotiable
> element.
I think it's a good idea to indicate negotional elements. So what are the
candidates for this element: Permissions, Duties, Prohibitions and
Contstraints. Or shall we go down to the Action- Element Level= Actions &
constraints?
Discussion opened..
susanne
>
> Hi Susanne,
> On the legal issues - I will have an answer for you hopefully on Monday,
> latest Tuesday.
>
> On the type issue:
> Lets say you have a music file "Hello World" and as the rights holder
> you would like to offer two types of licences:
> 1) A short-time limited license (one day) that does not restrict usage
> to any particular person, which costs 20 Euro cents
> 2) A person limited license, which restricts who can use the music file,
> but does not impose any time limit, which costs 1 Euro.
>
> In ODRLL v2.0, (1) is catered for by a Ticket and (2) is catered for by
> a contract.
>
> Now, when the user goes to acquire this license, the license server will
> first present the two offers, (1) and (2) and the user can then select
> which one (s)he likes, and proceed.
>
> In this case, it would be nice to reflect, in the offers themselves,
> that (1) is a ticket, and (2) is a contract.
>
> There in no real need to create an additional element, it could be all
> handled as an extra attribute.
>
> On another note - I was looking at the DMP negotiations call - and I am
> considering submitting the ODRL negotiations approach. One of the
> requirements is "setting a parameter as non-negotiable", which would
> require the creation of an additional attribute for every negotiable
> element.
>
> Alapan
> On Wed, 2006-02-22 at 22:00 +0100, Susanne Guth wrote:
> > Hi Alapan,
> >
> > its the latter, but I don't understand the concerns you have. Please
> > reformulate what you think the problem is. Thanks
> >
> > Susanne
> >
> > >
> > > Hi Susanne, everyone else
> > > I am still working on the contracts issue - semester just started, so
> > > academic staff are a little hard to get hold of.
> > >
> > > A question on the model posted - I see the absence of the
> > > "statement"/"ticket" etc. Is this feature removed? Or is this
> > > incorporated in the type attribute?
> > >
> > > If its the later, I have a slight problem (not only with the
> > > implications for negotiations) - but for standard usage also, as it
> will
> > > limit the comparability of different licenses. For example, it would
> not
> > > be possible to offer a ticket and a contract on the same digital
> object
> > > as their offers would look the same (i think ...)
> > >
> > > If it's the former .. I have no problem with it ;)
> > >
> > > Regards
> > > Alapan
> > > On Mon, 2006-01-30 at 01:32 +0100, Susanne Guth wrote:
> > > > Hi everybody,
> > > >
> > > > as you can see from my various emails this was an ODRL weekend for
> me :)
> > > >
> > > > >From reading through the discussions I found the following:
> > > >
> > > > 1.) we need containers
> > > > 2.) we need prohibitions
> > > > 3.) we need contractual details and negotition elements
> > > > 4.) the model has simplification potential
> > > >
> > > > I worked a little bit on the model that you can see attached. This
> is -
> > > of
> > > > course - only a draft and no new v2 model.
> > > >
> > > > 1.) Containers
> > > >
> > > > I added a container element which is not properly related to the
> other
> > > > elements. Container have the attributes
> > > >
> > > > BIND containing e.g. OR, AND
> > > > TYPE containing e.g. "Container of Constraints"
> > > > RELATEDTO containing the element that includes the container.
> > > >
> > > > I think that we would have to carefully describe in our semantics
> what
> > > each
> > > > container type means, so that we provide a chance to implement the
> > > language.
> > > >
> > > > Container Example
> > > >
> > > >
> > > > 20
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > 31-12-2004
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > 2.)
> > > >
> > > > I kept prohibitions as they were. However, this issue need further
> > > > discussion. The important question is if we can formalise the model
> with
> > > > prohibitions in it... vicky I count on you here :)
> > > >
> > > > 3.)
> > > >
> > > > I added the negotiation and communication elements. Details
> (attributes
> > > must
> > > > be discussed.
> > > >
> > > > 4.)
> > > >
> > > > What do you guys think of removing the rights-expression-type level
> and
> > > > instead using an attribute "TYPE" in rights to specify the semantics
> of
> > > the
> > > > actual rights expression?
> > > >
> > > > I have a problem with different hierarchies of RE elements, like in
> > > alapans
> > > > approach - simply for negotiation. If somebody wants to use ODRL
> without
> > > the
> > > > negotiation part, then the hierarchies do not make sense at all. An
> aim
> > > > should really be to keep the negotiation part independent of the
> > > remaining
> > > > model.
> > > >
> > > > If a RE grants next rights, for example, then these nextrights have
> to
> > > be
> > > > defined in a new rights expressed. RE ids would have to link the
> various
> > > > rights expressions. This would have the advantage that a "nextRight"
> > > could
> > > > more easily become part of a new agreement (I think).
> > > >
> > > > Comments?
> > > >
> > > > --
> > > > Susanne Guth
> > > > susanne@odrl.net
> > > > ODRL Initiative
> > > > http://odrl.net/
> > > >
> > > > DSL-Aktion wegen groer Nachfrage bis 28.2.2006 verlngert:
> > > > GMX DSL-Flatrate 1 Jahr kostenlos* http://www.gmx.net/de/go/dsl
> > > > _______________________________________________ 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
> > >
> >
> --
> 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
>
--
Susanne Guth
susanne@odrl.net
ODRL Initiative
http://odrl.net/
Telefonieren Sie schon oder sparen Sie noch?
NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie
From renato at odrl.net Mon Feb 27 10:57:45 2006
From: renato at odrl.net (Renato Iannella)
Date: Sat Jun 2 13:28:05 2007
Subject: [Odrl-version2] DMP Submission
In-Reply-To: <1140791306.7299.25.camel@iduna>
References: <1140616066.13777.2.camel@iduna> <18339.1140642011@www032.gmx.net>
<1140791306.7299.25.camel@iduna>
Message-ID: <79630458-1097-4DCF-91AF-6723CAF6F72B@odrl.net>
On 25 Feb 2006, at 00:28, Alapan Arnab wrote:
> On another note - I was looking at the DMP negotiations call - and
> I am
> considering submitting the ODRL negotiations approach.
Speaking of the DMP, they have a call for proposals at the moment
(due 27 march)
Are they any volunteers to help propose ODRL as one of the technologies?
Cheers
Renato Iannella
From aarnab at cs.uct.ac.za Mon Feb 27 19:11:16 2006
From: aarnab at cs.uct.ac.za (Alapan Arnab)
Date: Sat Jun 2 13:28:05 2007
Subject: [Odrl-version2] DMP Submission
In-Reply-To: <79630458-1097-4DCF-91AF-6723CAF6F72B@odrl.net>
References: <1140616066.13777.2.camel@iduna>
<18339.1140642011@www032.gmx.net> <1140791306.7299.25.camel@iduna>
<79630458-1097-4DCF-91AF-6723CAF6F72B@odrl.net>
Message-ID: <1141027877.860.0.camel@iduna>
Hi Renato,
Maybe I can help out on both - as the negotiations use ODRL ... but I am
not too sure of the format etc. maybe you can start it off ...
Alapan
On Mon, 2006-02-27 at 09:57 +1000, Renato Iannella wrote:
> On 25 Feb 2006, at 00:28, Alapan Arnab wrote:
>
> > On another note - I was looking at the DMP negotiations call - and
> > I am
> > considering submitting the ODRL negotiations approach.
>
> Speaking of the DMP, they have a call for proposals at the moment
> (due 27 march)
>
>
>
> Are they any volunteers to help propose ODRL as one of the technologies?
>
> Cheers
>
> Renato Iannella
> _______________________________________________
> 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 aarnab at cs.uct.ac.za Mon Feb 27 20:18:19 2006
From: aarnab at cs.uct.ac.za (Alapan Arnab)
Date: Sat Jun 2 13:28:05 2007
Subject: [Odrl-version2] resumption of containers & model update
In-Reply-To: <7433.1140799996@www056.gmx.net>
References: <1140791306.7299.25.camel@iduna>
<7433.1140799996@www056.gmx.net>
Message-ID: <1141031899.859.14.camel@iduna>
On Fri, 2006-02-24 at 17:53 +0100, Susanne Guth wrote:
> Hi Alapan,
>
> I think there is a logic tongh twister in your example. You can not
> negotiate if you would like agree to a "ticket" or a "contract". A ticket
> results from a contract. And an offer can only result by the confirmation of
> an agreement. The field "rights expression type" only describes what the
> rights expression represents. OK? Are all your concerns cleared?
>
This is truly a twister ;) Well the point is - when presenting an offer,
shouldn't there be an indication of what type of contracts are on offer?
> > On another note - I was looking at the DMP negotiations call - and I am
> > considering submitting the ODRL negotiations approach. One of the
> > requirements is "setting a parameter as non-negotiable", which would
> > require the creation of an additional attribute for every negotiable
> > element.
>
> I think it's a good idea to indicate negotional elements. So what are the
> candidates for this element: Permissions, Duties, Prohibitions and
> Contstraints. Or shall we go down to the Action- Element Level= Actions &
> constraints?
>
Down to the lower levels - as I think the constraints themselves are the
most useful element of negotiations (e.g. 5 pages instead of 1 page
limit on printing).
> Discussion opened..
>
> susanne
>
> >
> > Hi Susanne,
> > On the legal issues - I will have an answer for you hopefully on Monday,
> > latest Tuesday.
> >
> > On the type issue:
> > Lets say you have a music file "Hello World" and as the rights holder
> > you would like to offer two types of licences:
> > 1) A short-time limited license (one day) that does not restrict usage
> > to any particular person, which costs 20 Euro cents
> > 2) A person limited license, which restricts who can use the music file,
> > but does not impose any time limit, which costs 1 Euro.
> >
> > In ODRLL v2.0, (1) is catered for by a Ticket and (2) is catered for by
> > a contract.
> >
> > Now, when the user goes to acquire this license, the license server will
> > first present the two offers, (1) and (2) and the user can then select
> > which one (s)he likes, and proceed.
> >
> > In this case, it would be nice to reflect, in the offers themselves,
> > that (1) is a ticket, and (2) is a contract.
> >
> > There in no real need to create an additional element, it could be all
> > handled as an extra attribute.
> >
> > On another note - I was looking at the DMP negotiations call - and I am
> > considering submitting the ODRL negotiations approach. One of the
> > requirements is "setting a parameter as non-negotiable", which would
> > require the creation of an additional attribute for every negotiable
> > element.
> >
> > Alapan
> > On Wed, 2006-02-22 at 22:00 +0100, Susanne Guth wrote:
> > > Hi Alapan,
> > >
> > > its the latter, but I don't understand the concerns you have. Please
> > > reformulate what you think the problem is. Thanks
> > >
> > > Susanne
> > >
> > > >
> > > > Hi Susanne, everyone else
> > > > I am still working on the contracts issue - semester just started, so
> > > > academic staff are a little hard to get hold of.
> > > >
> > > > A question on the model posted - I see the absence of the
> > > > "statement"/"ticket" etc. Is this feature removed? Or is this
> > > > incorporated in the type attribute?
> > > >
> > > > If its the later, I have a slight problem (not only with the
> > > > implications for negotiations) - but for standard usage also, as it
> > will
> > > > limit the comparability of different licenses. For example, it would
> > not
> > > > be possible to offer a ticket and a contract on the same digital
> > object
> > > > as their offers would look the same (i think ...)
> > > >
> > > > If it's the former .. I have no problem with it ;)
> > > >
> > > > Regards
> > > > Alapan
> > > > On Mon, 2006-01-30 at 01:32 +0100, Susanne Guth wrote:
> > > > > Hi everybody,
> > > > >
> > > > > as you can see from my various emails this was an ODRL weekend for
> > me :)
> > > > >
> > > > > >From reading through the discussions I found the following:
> > > > >
> > > > > 1.) we need containers
> > > > > 2.) we need prohibitions
> > > > > 3.) we need contractual details and negotition elements
> > > > > 4.) the model has simplification potential
> > > > >
> > > > > I worked a little bit on the model that you can see attached. This
> > is -
> > > > of
> > > > > course - only a draft and no new v2 model.
> > > > >
> > > > > 1.) Containers
> > > > >
> > > > > I added a container element which is not properly related to the
> > other
> > > > > elements. Container have the attributes
> > > > >
> > > > > BIND containing e.g. OR, AND
> > > > > TYPE containing e.g. "Container of Constraints"
> > > > > RELATEDTO containing the element that includes the container.
> > > > >
> > > > > I think that we would have to carefully describe in our semantics
> > what
> > > > each
> > > > > container type means, so that we provide a chance to implement the
> > > > language.
> > > > >
> > > > > Container Example
> > > > >
> > > > >
> > > > > 20
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > 31-12-2004
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > 2.)
> > > > >
> > > > > I kept prohibitions as they were. However, this issue need further
> > > > > discussion. The important question is if we can formalise the model
> > with
> > > > > prohibitions in it... vicky I count on you here :)
> > > > >
> > > > > 3.)
> > > > >
> > > > > I added the negotiation and communication elements. Details
> > (attributes
> > > > must
> > > > > be discussed.
> > > > >
> > > > > 4.)
> > > > >
> > > > > What do you guys think of removing the rights-expression-type level
> > and
> > > > > instead using an attribute "TYPE" in rights to specify the semantics
> > of
> > > > the
> > > > > actual rights expression?
> > > > >
> > > > > I have a problem with different hierarchies of RE elements, like in
> > > > alapans
> > > > > approach - simply for negotiation. If somebody wants to use ODRL
> > without
> > > > the
> > > > > negotiation part, then the hierarchies do not make sense at all. An
> > aim
> > > > > should really be to keep the negotiation part independent of the
> > > > remaining
> > > > > model.
> > > > >
> > > > > If a RE grants next rights, for example, then these nextrights have
> > to
> > > > be
> > > > > defined in a new rights expressed. RE ids would have to link the
> > various
> > > > > rights expressions. This would have the advantage that a "nextRight"
> > > > could
> > > > > more easily become part of a new agreement (I think).
> > > > >
> > > > > Comments?
> > > > >
> > > > > --
> > > > > Susanne Guth
> > > > > susanne@odrl.net
> > > > > ODRL Initiative
> > > > > http://odrl.net/
> > > > >
> > > > > DSL-Aktion wegen groer Nachfrage bis 28.2.2006 verlngert:
> > > > > GMX DSL-Flatrate 1 Jahr kostenlos* http://www.gmx.net/de/go/dsl
> > > > > _______________________________________________ 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
> > > >
> > >
> > --
> > 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
> >
>
--
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 Feb 28 04:01:39 2006
From: Susanne.Guth at gmx.net (Susanne Guth)
Date: Sat Jun 2 13:28:05 2007
Subject: [Odrl-version2] resumption of containers & model update
References: <1141031899.859.14.camel@iduna>
Message-ID: <20064.1141059699@www046.gmx.net>
Hi Alapan,
with regard to contract, do you mean sales contracts, marriage contracts,
etc. ?
Negotiating:
Yes I guess constraints make sense in any case. But what about if you
negotiate permissions that do not have constraints. For example,
you either get the copy permission or the print permission.
Therefore, I guess we need all perm, proh, duties, constraints, no?
Susanne
>
> On Fri, 2006-02-24 at 17:53 +0100, Susanne Guth wrote:
> > Hi Alapan,
> >
> > I think there is a logic tongh twister in your example. You can not
> > negotiate if you would like agree to a "ticket" or a "contract". A
> ticket
> > results from a contract. And an offer can only result by the
> confirmation of
> > an agreement. The field "rights expression type" only describes what the
> > rights expression represents. OK? Are all your concerns cleared?
> >
> This is truly a twister ;) Well the point is - when presenting an offer,
> shouldn't there be an indication of what type of contracts are on offer?
> > > On another note - I was looking at the DMP negotiations call - and I
> am
> > > considering submitting the ODRL negotiations approach. One of the
> > > requirements is "setting a parameter as non-negotiable", which would
> > > require the creation of an additional attribute for every negotiable
> > > element.
> >
> > I think it's a good idea to indicate negotional elements. So what are
> the
> > candidates for this element: Permissions, Duties, Prohibitions and
> > Contstraints. Or shall we go down to the Action- Element Level= Actions
> &
> > constraints?
> >
> Down to the lower levels - as I think the constraints themselves are the
> most useful element of negotiations (e.g. 5 pages instead of 1 page
> limit on printing).
> > Discussion opened..
> >
> > susanne
> >
> > >
> > > Hi Susanne,
> > > On the legal issues - I will have an answer for you hopefully on
> Monday,
> > > latest Tuesday.
> > >
> > > On the type issue:
> > > Lets say you have a music file "Hello World" and as the rights holder
> > > you would like to offer two types of licences:
> > > 1) A short-time limited license (one day) that does not restrict usage
> > > to any particular person, which costs 20 Euro cents
> > > 2) A person limited license, which restricts who can use the music
> file,
> > > but does not impose any time limit, which costs 1 Euro.
> > >
> > > In ODRLL v2.0, (1) is catered for by a Ticket and (2) is catered for
> by
> > > a contract.
> > >
> > > Now, when the user goes to acquire this license, the license server
> will
> > > first present the two offers, (1) and (2) and the user can then select
> > > which one (s)he likes, and proceed.
> > >
> > > In this case, it would be nice to reflect, in the offers themselves,
> > > that (1) is a ticket, and (2) is a contract.
> > >
> > > There in no real need to create an additional element, it could be all
> > > handled as an extra attribute.
> > >
> > > On another note - I was looking at the DMP negotiations call - and I
> am
> > > considering submitting the ODRL negotiations approach. One of the
> > > requirements is "setting a parameter as non-negotiable", which would
> > > require the creation of an additional attribute for every negotiable
> > > element.
> > >
> > > Alapan
> > > On Wed, 2006-02-22 at 22:00 +0100, Susanne Guth wrote:
> > > > Hi Alapan,
> > > >
> > > > its the latter, but I don't understand the concerns you have. Please
> > > > reformulate what you think the problem is. Thanks
> > > >
> > > > Susanne
> > > >
> > > > >
> > > > > Hi Susanne, everyone else
> > > > > I am still working on the contracts issue - semester just started,
> so
> > > > > academic staff are a little hard to get hold of.
> > > > >
> > > > > A question on the model posted - I see the absence of the
> > > > > "statement"/"ticket" etc. Is this feature removed? Or is this
> > > > > incorporated in the type attribute?
> > > > >
> > > > > If its the later, I have a slight problem (not only with the
> > > > > implications for negotiations) - but for standard usage also, as
> it
> > > will
> > > > > limit the comparability of different licenses. For example, it
> would
> > > not
> > > > > be possible to offer a ticket and a contract on the same digital
> > > object
> > > > > as their offers would look the same (i think ...)
> > > > >
> > > > > If it's the former .. I have no problem with it ;)
> > > > >
> > > > > Regards
> > > > > Alapan
> > > > > On Mon, 2006-01-30 at 01:32 +0100, Susanne Guth wrote:
> > > > > > Hi everybody,
> > > > > >
> > > > > > as you can see from my various emails this was an ODRL weekend
> for
> > > me :)
> > > > > >
> > > > > > >From reading through the discussions I found the following:
> > > > > >
> > > > > > 1.) we need containers
> > > > > > 2.) we need prohibitions
> > > > > > 3.) we need contractual details and negotition elements
> > > > > > 4.) the model has simplification potential
> > > > > >
> > > > > > I worked a little bit on the model that you can see attached.
> This
> > > is -
> > > > > of
> > > > > > course - only a draft and no new v2 model.
> > > > > >
> > > > > > 1.) Containers
> > > > > >
> > > > > > I added a container element which is not properly related to the
> > > other
> > > > > > elements. Container have the attributes
> > > > > >
> > > > > > BIND containing e.g. OR, AND
> > > > > > TYPE containing e.g. "Container of Constraints"
> > > > > > RELATEDTO containing the element that includes the container.
> > > > > >
> > > > > > I think that we would have to carefully describe in our
> semantics
> > > what
> > > > > each
> > > > > > container type means, so that we provide a chance to implement
> the
> > > > > language.
> > > > > >
> > > > > > Container Example
> > > > > >
> > > > > >
> > > > > > 20
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > 31-12-2004
> > > > > >
> > > > > >
> > > > > >
> > > > > > container">
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > 2.)
> > > > > >
> > > > > > I kept prohibitions as they were. However, this issue need
> further
> > > > > > discussion. The important question is if we can formalise the
> model
> > > with
> > > > > > prohibitions in it... vicky I count on you here :)
> > > > > >
> > > > > > 3.)
> > > > > >
> > > > > > I added the negotiation and communication elements. Details
> > > (attributes
> > > > > must
> > > > > > be discussed.
> > > > > >
> > > > > > 4.)
> > > > > >
> > > > > > What do you guys think of removing the rights-expression-type
> level
> > > and
> > > > > > instead using an attribute "TYPE" in rights to specify the
> semantics
> > > of
> > > > > the
> > > > > > actual rights expression?
> > > > > >
> > > > > > I have a problem with different hierarchies of RE elements, like
> in
> > > > > alapans
> > > > > > approach - simply for negotiation. If somebody wants to use ODRL
> > > without
> > > > > the
> > > > > > negotiation part, then the hierarchies do not make sense at all.
> An
> > > aim
> > > > > > should really be to keep the negotiation part independent of the
> > > > > remaining
> > > > > > model.
> > > > > >
> > > > > > If a RE grants next rights, for example, then these nextrights
> have
> > > to
> > > > > be
> > > > > > defined in a new rights expressed. RE ids would have to link the
> > > various
> > > > > > rights expressions. This would have the advantage that a
> "nextRight"
> > > > > could
> > > > > > more easily become part of a new agreement (I think).
> > > > > >
> > > > > > Comments?
> > > > > >
> > > > > > --
> > > > > > Susanne Guth
> > > > > > susanne@odrl.net
> > > > > > ODRL Initiative
> > > > > > http://odrl.net/
> > > > > >
> > > > > > DSL-Aktion wegen groer Nachfrage bis 28.2.2006 verlngert:
> > > > > > GMX DSL-Flatrate 1 Jahr kostenlos* http://www.gmx.net/de/go/dsl
> > > > > > _______________________________________________ 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
> > > > >
> > > >
> > > --
> > > 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
> > >
> >
> --
> 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
susanne@odrl.net
ODRL Initiative
http://odrl.net/
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner
From fengwenjie at huawei.com Tue Feb 28 17:16:54 2006
From: fengwenjie at huawei.com (fengwenjie)
Date: Sat Jun 2 13:28:05 2007
Subject: [Odrl-version2] The difference between offer and ticket
Message-ID: <001801c63c2e$9240a4b0$420aa40a@china.huawei.com>
Hello, all
I am a little confused about the definition of rights type 'offer' and 'ticket'. In the V2 Model, it says:
"Offer. The Offer entity supports rights expressions that are proposing content under various terms and conditions to any consuming party from the owner party. The Offer entity must contain an Asset entity, one or both Permission and Prohibition entities, and a Party entity with Assigner (rights holder) role. The Offer entity must not contain a Party entity with Assignee or Assignees (consumer/s) roles."
"Ticket. The Ticket entity supports rights expressions that are contracts stipulating the content, terms and conditions of usage, and the owning parties involved. The consuming party is not known at the time the ticket is issued and is redeemable by anyone who currently holds the ticket in their possession. The Ticket entity must contain an Asset entity, one or both Permission and Prohibition entities, and at least one Party entity with Assigner role. The Ticket entity must not contain a Party entity with Assignee or Assignees roles. "
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?
Thanks in advance,
Jessica
*****************************************************************************************************************************************
This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
******************************************************************************************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.odrl.net/pipermail/odrl-version2/attachments/20060228/9fbfd413/attachment.html
From aarnab at cs.uct.ac.za Tue Feb 28 23:45:10 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
Message-ID: <1141130710.20376.37.camel@iduna>
Hi Susanne and others,
I had a discussion with a law professor (Prof Julien Hofman) in my
university with regards to ODRL v2.0, and you were right with regards to
contracts and form. Currently ODRL is a language to express licensing
agreements, and in most countries (all the countries he is aware of),
licensing agreements are formless, and sometimes would not even require
signatures. However, in most legal systems it is often recommended that
licensing agreements have some elements to remove legal ambiguities
should disputes arise. So,, there is obviously a need to refine my
section 2; but here is a short summary of the recommended elements:
1. Jurisdiction and Dispute Resolution
These elements go together and are very useful in resolving contract
disputes speedily. In dispute resolution, the parties resolve to go to a
mutually agreed party to arbitrate their dispute and is often a cheaper
avenue to pursue. Should this fail, or if a party does not wish to take
this route, they can choose to sue the other party. Jurisdiction
determines where a party can be sued.
2. Choice of law
Because of the international nature, it should be possible to choose
which law governs the licensing agreement. This is potentially very
important in DRM. For example, in EU copyright directive, the rights
holder does not have to provide for fair use clauses while copyright law
in most countries do not have such restrictions. Thus, it would be
advantageous for music labels to base their licensing agreements under
EU law rather than, say South African law.
3. Time of Contract
For licensing agreements, time of contract is often necessary although
not mandatory.
4. Place of contract
Licensing agreements should not have a place of contract. A court needs
to decide the place of contract when deciding whether it has
jurisdiction.
5. Signatures
As I mentioned previously, signatures are not mandatory but recommended.
In any case digital signatures are a security mechanism.
6. Liabilities
This is probably the most important part for most contracts. It could be
interesting to provide different pricing models according to the
liability risk carried by the supplier. For example, if the ODRL license
covers software, the rights holder could provide the software at a very
low price but with no guarantees on performance while at a much higher
price with guarantees on performance or number of bugs.
7. Lifetime
In an electronic medium, the lifetime of a contract (or offers etc) is
important as there are very few precedents (if any) that can be used in
case of disputes.
8. Offer, Counter-Offer and Requests
Although the text in my section is correct, there are some problems
encountered in a scenario where a client makes a counter offer.
Specifically, electronic transaction law in some countries insist on
certain regulation regarding consumer protection from the party that
makes the offer. Thus, when a client makes a counter offer, (s)he would
be required to abide by such regulation removing the potential for
anonymous negotiations (from the client). Thus, it is suggested that we
only use the terms Offer (from the rights holder) and Request (from the
client).
9. Country of residence (for client)
Depending on the country of residence for the client, the rights holder
has to abide by certain consumer protection legislation etc. For
example, in the case of a EU citizen, a rights holder outside the EU
cannot store personal information unless they have signed a safe harbour
agreement.
10. Tax
I am not sure if the payment model takes care of tax issues, but this
could be an element under legal section.
11. Fair Use policy
In my ACM-DRM paper last year (which is an evolution from my ODRL
workshop paper) I detailed using negotiations as a mechanism to enable
fair use.
The professor suggested that we have an element in the license that
details the rights holders position on fair use and how to approach for
fair use. Thus, if the license agreement is based in Europe, (s)he can
state that fair use is not offered etc.
--------------------------------
Ok, I hope that all made sense and I didn't make any typos etc.
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