[Odrl-version2] Common Vocabulary - Constraints on Duties

[Alapan]

Hi Francis,

You raise some interesting points. But, surely this will be handled as
per the DRM controller specification's precedence rules (as opposed to
ODRL precedence rules)?

Regards,
Alapan

On Sunday, 12 June 2011, Francis Cave <francis at franciscave.com> wrote:
> New text in the latest Draft Specification of the ODRL V2.0 Core Model states: “A Duty entity does not, by itself, specify any conditions on when the Duty Action must or should be performed, such as to pay before viewing the movie. Such conditions should be expressed through Constraint entities.” Let us suppose that the Duty Action must be performed before the Permission Action may be performed. This can be expressed by a “dateTime” Constraint.  Setting aside the issue of how to express a Constraint where the time of the Permission Action is not known (the ACAP Profile achieves this by using a category identifier, or a variable if you prefer), there is also the question of how many times the Duty must be performed. The obvious answer is “once”. This can be expressed using a “count” Constraint with operator “eq” and right operand “1”. But what does this mean? Does it mean one time only, or one time for every time that the Permission Action is to be performed, once a year, once every time the Action is to be performed in a new place,…? One answer is that it depends upon the Duty. Maybe one might argue that if the Duty is “obtainConsent”, one might assume that this only needs to be performed one time only, while a Duty to “pay” (as in pay-per-view) might have to be performed afresh for the Permission to apply. However, I think that a more flexible approach would be to define a new Constraint called something like “countDenominator”, which would take values such as “only”, “perAction”, “perRecipient”, “perYear”. An alternative would be to have an expression as the rightOperand value of the “count” Constraint, that incorporates both numerator and denominator, but this seems to me to be inappropriate, when the goal is not to wrap up important rights expression semantics in some unspecified syntax. Given the statement in the Core Model specification that I quote above, I don’t think that this is an issue that should be left to be resolved in different ways by different Profiles. However, I would accept that only a limited range of options are likely to be widely applicable and therefore suitable for inclusion in the Common Vocabulary. Francis Cave

-- 
Blog: http://idiots-mind.blogspot.com/
-------------------------------------------------------------
Life's a gamble - take a chance