[Odrl-version2] Common Vocabulary - Constraints on Duties

[Francis Cave]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://odrl.net/pipermail/odrl-version2_odrl.net/attachments/20110612/5bd937fc/attachment.html>