[Odrl-version2] Questions and comments for ODRL v2

[Susanne Guth]

Hyvä aamu Eetu!

Greeting from very hot, sunny Brisbane!
> Greetings from snowy Central Finland,

Thanks for all your comments.
 
> - From requirements management point of view, should there be an
> indication whether certain requirements are mandatory (version 2 SHALL
> have..) or discretionary (version 2 SHOULD have..)?

I'm afraid, I don't know if I understand this comment. Do you mean to design
certain constellation within the ODRL data model. Please give us a short
example where/why we would use mandatory requirements.
 
> - Since it seems that ODRL is concentrating in describing the semantics of
contracts, I would promote inclusion of additional context elements, which
> will help in the interpretation of ODRL rights expressions and supported
> data dictionary: 1) Geopolitical context or as Milosevic and Bond (1995)
> define it, the Contract Domain, 2) Content Type/Industry context
> (interpretation of ODRL elements with e.g. different content types).

Very helpful comment. We will definately need that in our contracts. Do you
know whether there is a set of commonly used attributes for contracts or
even an XML namespace that we could reuse in ODRL. Otherwise we will think
about just adding the two attributes that you recommended.

> - To Requirement 1.3 concerning status information: I believe the versio
> 1.1 already implements this requirement. Since the status of an attribute
> (i.e. attribute value) cannot be stated in the license as Jaime Delgado
> argumented, it needs to be maintained in the server side where it can be
> retrieved. Therefore, an external reference needs to be included to an
> ODRL document. Such mechanism already exists in the ODRL context model. I
> find the requirement 1.22. to be rather similar.

We are trying to get rid of the context element within constraints.
Therefore, we will probably add a status attribute within the constraint
elements,  <count status="3">. Changing the status attribute requires
editing of the license, which is a crucial operation. We assume that only
trusted parties of the DRM environment may use this attribute. Please follow
the discussions on this requirement and comment again. We will soon publish
some working documents that enclude issues lists on each requirement.
 
> 
> - Requirement 1.5. additional contract parties is interesting an needed.
> However, my concern is that can you bound a third party to certain
> obligation by contract made by another party (?). I believe this should
> not
> be possible.
That is of course an important issue, although my view is that is has to be
insured by the protocol and the processing DRM system (not by the expression
language), that e.g. a contract like this requires the digital signature of
ALL three/affected parties.

> - I would additionally promote providing semantics for the "abstract"
> elements in the permission model, namely, ALL usage, reuse, transfer and
> asset management rights. It would be helpful in streamlining ODRL
> documents in cases where contract assigns e.g. ALL reuse rights to a party
> or where contract does not explicitly say which reuse rights are assigned.

Good idea. Will will add it to the issues list.

> - Is it currently possible to express in ODRL document whether a party is
> allowed to publicly present (e.g. in educational context) a piece of
> content, otherwise than using user or target constraints? I'd find more
> simplified way of expressing extremely useful.

Good point again. Such a permission is probably needed all the time to
express the legal context/copyright issues of certain works. Are there other
permissions that might be needed in the legal context? Is there a vocabulary
for uses in the copyright context, yet?

Thanks again for your effort. Enjoy your advent.
Susanne

-- 
Susanne Guth
susanne at odrl.net
ODRL Initiative
http://odrl.net/

NEU +++ DSL Komplett von GMX +++ http://www.gmx.net/de/go/dsl
GMX DSL-Netzanschluss + Tarif zum supergünstigen Komplett-Preis!