RE: Constraint call 15 November - MS' input

Sadly, I don’t think I will be able to join this phone call.

However, I echo Michael’s appeal for a clearer definition of how constraints are due to be handled. I attempted to generally clarify the evaluation of ODRL statements when I documented the RightsML Processing Model:

http://dev.iptc.org/RIghtsML-Processing-Model


So, for example in http://dev.iptc.org/RightsML-Processing-Model-Evaluating-the-Permissions-in-a-Policy I talk about how to evaluate constraints for permissions (steps 3.3, 3.4, 3.5 and 3.7). And I talk about how to evaluate constraints on a restriction in http://dev.iptc.org/RightsML-Processing-Model-Evaluating-the-Restrictions-in-a-Policy. I also mention (with much less detail) the role of duties, but don’t attempt to explain how to evaluate duty constraints.

As I said in a previous email, I think that a lot of the conceptual knots around evaluating constraints (e.g. count, datetime, industry) are resolved if you introduce the idea of “context” for evaluating whether a particular use is permitted or restricted. And, as I’ve said in other emails, I think that the introduction of constraints to somehow modify targets or assignees introduces additional evaluation problems.

Regards,

Stuart





From: Michael Steidl (IPTC) [mailto:mdirector@iptc.org]
Sent: Monday, November 14, 2016 10:56 AM
To: 'W3C POE WG'
Subject: Constraint call 15 November - MS' input

Hi all who want to join the conference call about the Constraint on 15 November,

I suggest as goal of this call and further work on constraints: keep constraints simple.

From a practical point of view I want to share some considerations regarding what a processor of constraints must do – and what its creator needs to know to design and program it properly. If a constraint is not evaluated as the policy assignee expects it the result could be legal troubles.

Let’s to look at the current specifications relevant for a constraint and at where I see tripwires for processing constraints properly.

========== Specification
- used specification document data model: [1]
- used specification document vocabulary: [2]

** Specification of Constraint, in [1]
(http://w3c.github.io/poe/model/#constraint<http://w3c.github.io/poe/model/#constraint>)
Summary from the specs

-          Constraints may apply to Permission, Prohibition or Duty

-          The expression of a constraint is a “mathematical” operation made of 3 parts:
{left operand} {operator} {right operand}

-          Multiple constraints may be applied, in this case the final result is generated by a Boolean ANDing of all constraints.
From my understanding of the specs

-          The left operand is a thing which is linked to the context of a specific evaluation of the constraint = its value may change over time, spatial use, and other parameters.

** Specification of a Permission with a constraint, in [1]
(http://w3c.github.io/poe/model/#permission<http://w3c.github.io/poe/model/#permission>)
Summary from the specs:

-          One or more constraints applied to the Permission affect the validity of it.
My assumption: if the Boolean result of the (combined) constraint(s) is TRUE then the Permission is valid

** Specification of a Prohibition with a constraint, in [1]
(http://w3c.github.io/poe/model/#prohibition<http://w3c.github.io/poe/model/#prohibition>)
Summary from the specs:

-          A Prohibition MAY refer to one or more constraints …
My concern: the impact of constraints on a prohibition is not written down – will depend on assumptions of a person.

** Specification of a Duty with a constraint in [1]
(http://w3c.github.io/poe/model/#duty<http://w3c.github.io/poe/model/#duty>)
Summary from the specs:

-          A Duty MAY link to one or more constraints … --> my comment: impact unclear, see Prohibition above.

Example 7 about a Duty is the only example out of Permission, Prohibition and Duty which includes a constraint.
My comment: I’m not sure if everybody seeing only the policy document comes to exactly the same constraint as expressed in the natural language of the specs. We at IPTC had a not so nice experience with that.

============= Open Issues

** How to evaluate “is {left operand} {operator} {right operand} TRUE”?
… simply said: the value of the values of leftOperand and rightOperand have to match as defined by operator.

* in all the examples and guidelines operator and rightOperand are explicit values --> the variable leftOperand has to match this limiting expression to make the result TRUE.
* currently the leftOperand is the “name” of a constraint.
* Conclusion: this Name must define what has to be matched against the rightOperand by using the operator.
* Such Names are currently defined in [2] under Names for Constraints:
- it has a Definition which should tell how to use it as leftOperand.

* Examples of Names and Definitions – **with my issues**

a) Absolute Position: A point defined with absolute coordinates ** How does such a point constrain a Permission/Prohibition/Duty? Is that a specific point of a 2D-asset on a canvas in the context of executing the action – this is my vague assumption, it’s not written down. **

b) Count: The numeric count indicating the number of times the corresponding entity may be exercised. ** What is “the corresponding entity” (could be: an asset, a party …) and isn’t the Action addressed by “exercised” ? **

c) Datetime: The date (and optional time and timezone) representing a point in time or period. ** In fact the same as with Absolute Position: what thing has to meet the comparison by operator and rightOperand?

d) Industry: The defined industry sector applicable to the asset usage. ** As an industry sector as whole cannot use an asset: has the Assignee to be from this sector OR may the Action only be executed inside something which at least strongly relates to this sector (e.g. a sector-specific publication).**

>> My conclusion: it is an implicit requirement of this design that the Definition of a Name of a Constraint includes:

-          What is the thing which should be matched in this operation

-          If a thing outside the ODRL policy is required for the expression of the left operand we need a (new) property for holding its identifier. (Example: if a picture may be published only after a specific event: we need an id for the event.)

-          It should be made clear how the context of an evaluation of this constraint impacts the left operand.

-          Use for the Definition a simple and clear wording – abstract terminology does not help, it even confuses.

** Which thing(s) should be matched in the constraint operation?
The specs are quite vague about that, the one of Constraint tells “these Constraint names MAY be directly linked to a procedure that can determine the outcome of the operations, such as the number of already performed usages and the current date.”
This “outsources” the definition of the operation to the Names – but the current Names are not specific, see above.

Including some POE requirements these things could be part of the left operand:

-          The permitted or prohibited Action or the Action of a Duty. That means: the execution of the action “in this context” must not exceed the constraint expressed by operator and rightOperand.

-          The Assigner or the Assignee. Natural text example: “the Assignee of this Permission must be a student”
By my understanding of the flexibility of Names of Constraints this could be included into a Definition.
But: couldn’t this be defined by the definition of the Assigner or Assignee? E.g. using the definition of a group of persons which are students – could include all students worldwide.

-          The Asset. Natural text example: “The height of the 3D-asset must not exceed 0.2 metres”
Same as above: could be expressed in the Definition of a constraint – or by using an identifier for a subgroup of this kind of asset which are not higher than 0.2 metres.

>> My conclusion: constraints applicable already at the time of creating a policy should be applied by defining constrained sets of Assigners, Assignees, Assets …
Only things which are a variable value at the time of evaluating a constraint (as this may depend on how exactly the Action is exercised) should be covered by a constraint.

Best,
Michael

[1] http://w3c.github.io/poe/model/<http://w3c.github.io/poe/model/>
[2] http://w3c.github.io/poe/vocab/<http://w3c.github.io/poe/vocab/>

Michael Steidl
IPTC [mdirector@iptc.org]