[Odrl-version2] resumption of containers & model update
Susanne Guth
Susanne.Guth at gmx.net
Sat Feb 25 03:53:16 EST 2006
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
> > > > <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
>
--
Susanne Guth
susanne at 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
More information about the Odrl-version2
mailing list