[Odrl-version2] resumption of containers & model update
Susanne Guth
Susanne.Guth at gmx.net
Tue Feb 28 04:01:39 EST 2006
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
> > > > > > <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
>
> _______________________________________________
> ODRL-Version2 mailing list
> ODRL-Version2 at odrl.net
> http://lists.odrl.net/mailman/listinfo/odrl-version2
>
--
Susanne Guth
susanne at 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
More information about the Odrl-version2
mailing list