[Odrl-version2] Followup on Legal stuff about contracts

[Alapan Arnab]

Hi,
Sorry for the late response! Luckily, I got Susanne's last email in
time ... I will respond according to the latest version
(ODRL-Model-20060310).

General Comments:
-----------------
Africa is spelt with a C and not a K ;)
My surname is spelt wrong
Can we have a date for the changelog?

Model Notes:
------------
In my opinion, the relationship constraints for Signature, Legal,
Negotiation, Party and Encryption are incorrect. 

1) Signature: The model currently reads "A rights expression will have 1
signature while a signature can belong to one or more rights
expressions". Since, signatures here do refer to digital signatures, and
a license should be able to have multiple (or even no) signatures I
think it should rather read "A rights expression will have 0 or more
signatures, while a signature is unique to the rights expression"

2) Legal: The model currently reads "A rights element will have 1 legal
element while a legal element can belong to one or more rights
elements". While I am a proposer for legal elements in a REL, I am not
sure if it should be compulsory. It would probably be better to make it
an optional element.

3) Negotiation: The model currently reads "A rights element will have 1
or more negotiation elements while the negotiation element is unique to
the rights element". I think that there should be only one negotiation
element and it should be optional (to cater for the systems that do not
support negotiations). I have further comments on this element later.

4) Party: The model currently reads "A rights element will have 0 or 1
party while a party is unique to a rights element". Conceptually, surely
a party can belong to 1 or more rights elements? Also, a rights element
will often have more than 1 party and never have no parties. I think it
should read "A rights element will have 1 or more parties while a party
can belong to one or more rights elements"

5) Encryption: The model currently reads "An asset will have 1
encryption key, while the encryption key can belong to 0 or more
assets". The later part does not make any sense - surely a key for an
asset must belong to an asset. Also, this does not take unencrypted
assets into account or assets with multiple keys. I think it should
rather read "An asset can have 0 or more encryption keys, while the
encryption key can belong to one or more assets"

Element Comments
-----------------
1) Rights:
- Surely the attributes should be required and not optional (will as
opposed to may)?
- Is there a need for NextRights as an attribute. I think it should be
possible to cater for downstream rights without resorting to an extra
attribute because the downstream portion of the rights will be catered
for by TransferRights action.
- Description should also include the new elements added

2) Legal:
- jurisdiction and dispute resolution should be separate elements. It
should be possible to provide both sets of information in a license.
Text: jurisdiction details the courts that will have the jurisdiction in
connection with all legal proceedings arising from the agreement.
Dispute resolution details the arbitration process in the case of a
contract dispute arising after the conclusion of the contract.
- liabilities: The licensor details the extent of the liabilities
incurred by the licensor in case the product does not meet the
licensee's expectations or causes damages etc. (or something like that) 
- expiration/date issued: date should read date & time

3) Negotiation
Personally I think it should read communication instead of negotiation.
After all, negotiation is effectively carried on with the the Rights
element (request/offer/agreement etc)

Other than acceptance and rejection, it should also have a general info
element. This would not only allow for simple messages that would not
normally fit in, but also metadata that needs to be communicated before
an agreement is signed (for example in a Music store, it could be used
to detail the bit rate, the encoding format etc of the digital asset
before the license is bought).

Thanks for the great work Susanne!
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