[Odrl-version2] Common Vocabulary - Constraints on Duties

[Alapan]

Hi Francis,

The interpretation comment holds regardless of the position of the rights
consumer in the value chain - in your case, the intermediary.

There are two places to build the precedence rules - as part of the rule
specification language or as part of the interpretation engine. If it is
part of the rule specification language, there is a lot of standardisation -
but there is a reduction in flexibility. ACAP may want ver 1 of the
precedence rules, OMA may want another version. If the the precedence rules
are built as part of the interpretation engine (or in the case of ACAP, as
part of the profile) then there is standardisation within the framework or
profile - but does not guarantee the same functionional output between
different implementations.

Personally, I favour the second approach, but there may be a case to define
certain precedence rules etc. as part of the core language.

Regards,
Alapan

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


On 13 June 2011 10:57, Francis Cave <francis at franciscave.com> wrote:

> Hi Alapan
>
> In cases where the ODRL expression is being interpreted on an end-user
> reading device, you are probably right, but where do the precedence rules
> come from? Don't these rules have to be built on the basis of the usage
> terms provided by the rights holder? The ACAP Profile is concerned with
> communicating usage rules within a supply chain, i.e. from rights holder to
> intermediary, who will be distributing the content on to end-users. We are
> not much concerned with communicating direct with end-users.
>
> Regards,
>
> Francis
>
>
>
> > -----Original Message-----
> > From: Alapan [mailto:alapan at gmail.com]
> > Sent: 13 June 2011 07:56
> > To: francis at franciscave.com; ODRL-Version2
> > Subject: Re: [Odrl-version2] Common Vocabulary - Constraints on Duties
> >
> > 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
>
>
> _______________________________________________
> Odrl-version2 mailing list
> Odrl-version2 at odrl.net
> http://odrl.net/mailman/listinfo/odrl-version2_odrl.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://odrl.net/pipermail/odrl-version2_odrl.net/attachments/20110613/6b2adcc1/attachment.html>