ODRL Evaluator Rules

Parallel to the thread concerning validation requirements, that Simon 
has done a lot of work to create an evolving Test Suite based on SHACL 
[1], in this mail I am collecting instances where the IM defines what an 
ODRL Evaluator must do.

I use OE as shorthand for 'ODRL Evaluator.'


Proposed Initial statement:

An ODRL Evaluator determines whether an ODRL Rule is in effect for a 
given asset. It MAY assume that the given ODRL Policy has been validated 
by an ODRL Validator.


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.

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

The latter example implies that an OE must also be able to accept a 
third parameter: the assignee. So you can ask it questions like, "is 
Policy X in effect for Asset Y for Assignee Z?"


2.1.4 Has A Policy
==================
This is the one where metadata links to a Policy through the 
odrl:hasPolicy predicate. The Policy therefore need have no knowledge of 
the actual Assets to which it applies, but one of the black boxes might 
need it (payment received for asset X? etc). It seems sensible to me 
that where odrl:hasPolicy is used - which we expect to be a lot of the 
time - then the input should still include the Asset IRI. Actually, 
should that be SHOULD? If you are building a performant system, and you 
know you don't need the asset IRI, then we shouldn't force it. That is, 
the input to an OE

- MUST include the IRI of the Policy
- SHOULD include the IRI of the specific Asset.


2.2.1 Relation
==============

This is the first section in the IM that may require us to invoke a 
black box as it contains an example of an odrl:AssetCollection. To 
process Example 6 the OE needs to know that the Asset IRI is a member of 
the AssetCollection http://example.com/archive1011

The alternative approach is to allow an OE to take the IRI of an 
AssetCollection and assume that the specific asset in question has been 
confirmed satisfying the constraint. But that seems dangerous to me. 
Take Example 18 which says that you can print up to 50 Assets in the 
Asset Collection.

So it's tempting to just let the OE take the AssetCollection IRI and 
then hand off to a black box that counts up to 50. So far so simple, 
BUT, if the constraint were along the lines of the example we had for 
scope, i.e. 'only applies to JPEG images', now the black box has to know 
exactly which asset is being looked at and then that has to go off to 
the black box to tell it whether the constraint is or is not satisfied.

So in the counting case, it's enough to know that the Asset is in the 
collection. In the JPEG case, it's not - the black box needs to know the 
identity of the individual Asset.

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.

Better, in my view, to stick with: a query
- SHOULD include the IRI of the individual Asset in question;
- MUST include the IRI of the Policy;
- MAY include the IRI of an individual (Party);

If the individual Asset is part of a collection, the input SHOULD 
include the IRI of that collection.

Likewise, if the individual is part of a group, the input SHOULD include 
the IRI of the group.

I need to go through more issues concerning constraints and black boxes, 
but what are people's thoughts on this so far?

Phil




[1] 
https://github.com/simonstey/ODRL-SHACL-Shapes/wiki/SHACL-Shapes-for-validating-ODRL-Policies
-- 


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

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

Received on Tuesday, 30 May 2017 15:58:17 UTC