About a more strict definition of Constraint

Hi all,

the recent discussion about Complex Constraints let me look into the current definition of Constraint [1].

I interpret this definition as:

-          A constraint applies to the Permission, Prohibition or Duty as a whole. In RDF terminology one of these is the subject of the triple. And this definition is implicit – the subject is always the Permission (, Prohibition) or Duty including the constraint.

-          The constraint data  are “mathematical terms with two operands and one operator” = a mathematical, or better a Boolean, condition which has to be met.

-          If multiple constraints with the same subject exist then all of them have to be met.

 

>From that I see two main open issues:

 

A) To make the use of the subject of the constraint more flexible – and have an RDF triple in mind:

1) I suggest to add an entity to Constraint expressing the subject explicitly. This entity could express that the whole Permission/Prohibition/Duty is the subject  or a specific part of it – or an entity outside it, e.g. an event. In the latter case an identifier for this external entity should be added to the structure.

That a constraint is included into a Permission or Duty still defines which constraints have to be met to show a thumbs up for Permission or Duty.

 

2) I suggest to consider the current “name” of a constraint as the predicate of the triple.

E.g. Absolute Position -> “has absolute position constraint”, Resolution -> “has resolution constraint”

 

3) I suggest to consider the “mathematical terms” as the object of the triple.

 

This could result in triples like (taken from discussions and use cases)

“The asset with id=’abc123’” “has resolution restriction” “operator=lowerThan rightOperand=300 unit=dpi”

“The assignee party” “has age restriction” “operator:higherThan rightOperand=18 unit=year”

“The assignee party” “has affiliation restriction” “operator:equal rightOperand= https://www.wikidata.org/entity/Q48282 “ (help: “student” entity of WikiData)

“The event with id=’http://sporteventregistry.com/abc9883’” “has temporal-after-terminated constraint” “operator=higherThan rightOperand=30 unit=minutes”

“This Duty” “has payment constraint” “operator=equal rightOperator=200 unit=EUR”

 

 

B) Clarification of processing multiple constraints

The current specs define that all constraints have to be met.

First clarification: is that sufficient – or not. If not: what are requirements going beyond that?

Note: I recall it was raised that some constraints may apply in temporal order – but why is this relevant? Again: all constraints have to be met, in this case the e.g. Permission is only given after the last constraint has been met. And if the permission may change after some time (or other fulfilled constraints) ODRL provides the nextPolicy.

 

My approach is: it may help to have a more strict definition of constraint to solve some pending issues. Let’s consider that before digging into complexity.

 

Best,

Michael

 

[1] http://w3c.github.io/poe/model/#constraint 

 

 

Michael Steidl

Managing Director of the IPTC [mdirector@iptc.org]

International Press Telecommunications Council 
Web:  <http://www.iptc.org/> www.iptc.org - on Twitter  <http://www.twitter.com/IPTC> @IPTC

Business office address: 

25 Southampton Buildings, London WC2A 1AL, United Kingdom

Registered in England, company no 101096