Re: ODRL Evaluator Rules

On 02/06/2017 03:31, Renato Iannella wrote:
>
>> On 31 May 2017, at 01:58, Phil Archer <phila@w3.org> wrote:
>>
>> Proposed Initial statement:
>>
>> If the WG agrees with this then for any operation, the OE has a minimum of two input parameters:
>> - the IRI of the specific Asset;
>> - the IRI of the Policy.
>
> I assumed that we need to look at Constraints only for OE.
> That is, if all Constraints are “evaluated” and the responses (from the “black box”) is “true” then you can say the Rule is in “effect”.

Well, yes and no. If there's an assignee then the OE needs to know that 
and pass it on to the black box. In effect, the definition of an 
assignee is a constraint since it constrains to whom the Policy applies. 
So I think an OE has to do more than handle constraints that are 
actually called constraints.

>
>
>> The simplest output would be a binary in effect|not in effect. Do we want to go further and say that the OE should return what the rule is? i.e. taking the first three examples from the IM, support an output like:
>>
>> Example 1. You are permitted to play http://example.com/asset:9898.movie
>> Example 2. http://example.com/party:org:abc gives you permission to play http://example.com/asset:9898.movie
>> Example 3.  http://example.com/party:org:abc gives http://example.com/party:person:billie permission to play http://example.com/asset:9898.movie <http://example.com/asset:9898.movie>
>
> These examples would only require Validation (not Evaluation) as there are no constraints to check?

The Policy applies to the specific target so, as a minimum, the OE needs 
to know what the target is to know whether or not the Policy is in effect.


>
> (Also: we need to ensure that Validation includes the Policy Type, so for Example 2, this is an “offer for the permission” not the actual granted permission - which is what Example 3 does.)

OK, we'll need to add that to the validation steps.

>
>
>> 2.2.1 Relation
>> ==============
>>
>> So you might say, OK, so the OE only accepts Assets that meet any Asset constraints, but then you'd need your supporting software to be able to read the ODRL to find out what the constraints on the Asset were. That seems brittle to me.
>
> There seems to be two approaches to Evaluate Constraints on Asset and Party collections:
>
> If you look at Example 18:
> 1 - I have asset X - Is it part of the “set of 50” in the media-catalogue? Yes, then I can print it.

To assess that, you need a black box to tell you:
1. whether X is part of the collection;
2. whether the number of assets in that collection that have been 
printed is less than 50.

You don't need to know how many assets are in the collection or what 
they all are. This is good since the number might easily be ~10^6.



> or
> 2 - Tell me the actual assets in the set-of-50 that I can print from the media-catalogue

You can't know that since what's important in that specific case is how 
many have been printed already. So, for this case, I'd definitely go 
with the first approach.

>
> If you look at Example 19:
> 1 - I am user X - am I a “over 17 year old friend”? Yes, then let me display the asset.

The black box needs to know whether X is a member of the PartyCollection 
http://example.com/user44/friends and their age. On their own, neither 
piece of info is sufficient to decide whether the Policy is in effect or 
not.

> or
> 2 - tell me the identity of the friends over 17 years old

Again, that's enumerating all the members of the PartyCollection which I 
think is unnecessary. You might as well list them all in the Policy 
which would make it huge and unmanageable.

>
> Option 2) is the more “atomic” approach - it gets all the uids and, in effect, you could create a new Rule per uid.
>
> Option 1) is more query-based, and assumes you have the source uid you want to Evaluate against the Asset/Party constraint.
>
> Support both approaches?

Just the first IMO.

Phil



-- 


Phil Archer
Data Strategist, W3C
http://www.w3.org/

http://philarcher.org
+44 (0)7887 767755
@philarcher1

Received on Friday, 2 June 2017 11:23:10 UTC