[Odrl-version2] New ODRL v2.0 Model

[Alapan Arnab]

Hi Susanne,
Thanks for your comments. I will try to reply to each email - should
make tracking a bit easier.
> 4.5.1 Containers
> 
> We kicked out the containers because it is extremely complex to define
the
> semantics and implement containers. (That showed the implementation
> experiences). On the other hand we did not come up with a better
solution
> for expressing XOR/OR/AND relations. In ODRL v1.1 containers are
allowed for
> a bunch of things; maybe in v2.0 Containers should only be allowed for
> permissions, prohibitions and duties. What do you guy think?
> 
I have the exact same problem - containers are very useful but dificult
to define and implement. I have an idea - maybe not a generic container,
but something that might do the job - I will use constraint as an
example:

        Define a container type for each type that we wish to be 
        in a container eg. ConstraintContainer. This can be defined
        as:
                ConstraintContainer = <container><Constraint>*
                ConstraintContainer = <container><ConstraintContainer>*
        where container is one of "and","or","xor" and "not"

This allows for a nested list of constraints, and then instead of
linking to a constraint, it links to a constraint or a container.

> 4.5.2 "NOT"
> 
> By allowing to express "Prohibitions" we have our means to express
"NOT".
> Originally the NOT was requested to express things like: "Everything
is
> allowed, except 'thisandthat'. The odrl-v2.0-"prohibition" offers such
a
> means.
> 
The way I have defined prohibition does make that work - but not could
be useful for parties (something not catered for). 
> 4.5.3 Next Rights
> 
> I kind of like the idea to eliminate one level in the ODRLv2.0 and
instead
> use a variable to express different types of rights expressions. We
might
> want to think about adding your "Type" attribute of License to the
"Rights"
> element. By that however we reduce our flexibility to but e.g. an
offer an
> "next rights" into one "rights" node tree? 
> 
> In your current proposal a ticket could be part of a license which
could
> have the Type="Offer". That would not really make sense to me. We
should
> keep ticket, offer, request, agreement, etc. on one level respectively
with
> the same type of element. In your proposal, offer is an attribute and
ticket
> is an element.
> 
Yeah, I am not totally happy with how I have done the current
implementation. The improvement in my view is to have three elements at
that level: communication, license and nextRights. License and
nextRights can then be either tickets, statements or contracts.
> 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.

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