[Odrl-version2] Formalising ODRL

[Alapan Arnab]

Hi,
I think there is a need to formalise ODRL v2.0, both using UML modelling
and using logic constructs like Vicky's paper on ODRL 1.1, before it can
be "stabilised". Unfortunately, I am not very experienced with logic
structures and thus I am not too confident on the correctness of my
work; but I hope it is correct.

So, I will kick off first, and I have based the initial work on how
Vicky and Ricardo Pucella's paper. I have revised (again) the ODRL v2
model (attached), so first a few notes:

PROHIBITION MODEL and INTERPRETATION
---------------------------------------
The latest prohibition model brings a question of interpretation, and I
think there is a need to introduce the idea of strict and relaxed
interpretation.

In a relaxed interpretation, permissions are either granted or denied.
If there is an unlisted permission, the interpretation is that the
rights holder does not care whether it is granted or not.

A strict interpretation could have two sub cases - strict permission or
strict prohibition. In strict permission, only the rights listed are
granted. In such a case, prohibition is meaningless. In strict
prohibition, only rights that are listed are denied ("All rights but").
In this case, a permission is meaningless.

STATEMENT, TICKET AND CONTRACTS
-------------------------------
Like Vicky, I do not think there is a need for these distinctions. This
model is further complicated as there it will be very difficult to
enforce the restrictions in XML schemas alone, and will need separate
XSLT stylesheets. It would be best that ODRL offers a few templates that
can be used to demonstrate these different license types - eg offer a
ticket template. 

CONTAINERS
----------
I am still unsure of how to express containers in UML. I think the loop
idea as expressed in the Asset element, is a good way. In the formalised
semantic below, a container is expressed with the keyword CONTAINER and
can be one of "and, or, xor"

FORMAL Step 1
-------------
This is the first step, and I have taken direction from Figure 1 in the
previously mentioned paper. This would probably be a good place to
start.

License :=
       involving P                         (Parties)
       regarding A*                        (Assets)
       with PS                             (Permission Sets)

P :=
       Assigner*.Assignee*
       Assigner*                           (Ticket case)

Assigner :=
       ar
       !ar
       Assigner.Duty*
       CONTAINER(Assigner)

Assignee :=
       ae
       !ae
       Assignee.Duty*
       CONTAINER(Assignee)

Duty :=
       d
       d.Constraint*
       CONTAINER(Duty)

A element of Assets

PS :=
       Permission
       Permission*
       CONTAINER(PS)

Permission :=
       p
       !p
       p.Constraint*

Constraint :=
       c
       CONTAINER(Constraint)

---------------------------------------------------

Hope this all makes sense ;)

Kind regards
Alapan

PS. I am still without a regular Internet connection, so apologies in
advance if I do not reply quickly. I should have a regular Internet
connection from 7 Feb.

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ODRL_2_revised.png
Type: image/png
Size: 77838 bytes
Desc: 
Url : http://lists.odrl.net/pipermail/odrl-version2/attachments/20060130/f332cbd3/ODRL_2_revised.png