[Odrl-version2] resumption of containers & model update

Alapan Arnab aarnab at cs.uct.ac.za
Sat Feb 25 01:28:26 EST 2006


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



More information about the Odrl-version2 mailing list