[Odrl-version2] resumption of containers & model update
Alapan Arnab
aarnab at cs.uct.ac.za
Mon Feb 27 20:18:19 EST 2006
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
> > > > > <o-ex20:constraint id="c01">
> > > > > <o-ex20:count>
> > > > > <o-ex20:max>20</o-ex20:max>
> > > > > </o-ex20:count>
> > > > > </o-ex20:constraint>
> > > > >
> > > > > <o-ex20:constraint id="c02">
> > > > > <o-ex20:datetime>
> > > > > <o-ex20:notLaterThan>31-12-2004</o-ex20:notLaterThan>
> > > > > </o-ex20:datetime>
> > > > > </o-ex20:constraint>
> > > > >
> > > > > <o-ex20:container id="cont01" bind="or" type"constraint container">
> > > > > <o-ex20:includes constraint="c02"/>
> > > > > <o-ex20:includes constraint="c01"/>
> > > > > </o-ex20: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 at 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 at 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 at 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
More information about the Odrl-version2
mailing list