Constraint specs currently do not cover logic operation on constraints

[nitmws]

This is about what was discussed as Extended Relations topic.

The current specifications regarding Constraints read (http://w3c.github.io/poe/model/#constraint):

• Constraint: Constraints express a Rule for comparing two operands by one operator. If the two operands match the result of the Constraint is true.
• leftOperand: The leftOperand identifies the left operand of the logic operation for the Constraint, it SHOULD include the entity it constrains and how its value for a comparison has to be retrieved/generated."
• rightOperand: The rightOperand represents the literal value (such as "10" or "http://example.com/c100") and rightOperandReference represents a URI that MUST be dereferenced to obtain the actual value. Only one of these MUST appear in the Constraint.
• operator: The operator identifies the comparative operation such as “greater than” or “equal to”.

That does match well the design of the Extended Relations: each the leftOperand and the rightOperand of a Constraint are a constraint and they are compared by a login operator (AND, OR, XOR):

• leftOperand: a processed constraint only delivers a boolean value of true or false - no definition of an entity it constrains.
• where to put the constraint being the right operand: in rightOperand (no, its not a literal value) or in rightOperandReference?
• AND, OR and XOR operators do not match the specification

How to solve that:

• opening up the specification to two options using an "in case of ..." wording: one covering the "old" constraint and another one this new logic combination of two constraints?
• OR to create a new class and a new property of Permission (quick outline): -- new class CombinedConstraints: Parent = owl:Thing, Properties: constraint1, constraint2, operator -- new property hasCombinedConstraints: Domain = Permission, Range = CombinedConstraints

[riannella]

@nitmws I think the "opening up" option is better. I have updated the Constraint section.

[nitmws]

@riannella Frankly I'm not happy with this "opening up" language as I tried to make it clear what each of these attributes stands for, now it got ambiguous.

I think we must use a strict divide by "in case of a Constraint expression" and "in case of Constraint Relations expression" else any reader who is not familiar with the thinking of this group will not be able to sort out the difference ... so I propose for http://w3c.github.io/poe/model/#constraint:

• As inserted 3rd paragraph: A Constraint can also be used for a Constraint Relations expression to combine the results of two Constraints.
• • leftOperand: the left operand of the operation (REQUIRED)
• (below the bullets) In case of a Constraint expression the leftOperand identifies the left operand of the logic operation for the Constraint, it SHOULD include the entity it constrains and how its value for a comparison has to be retrieved/generated. The leftOperand MAY be one of the Constraint Left Operands defined in the ODRL Vocabulary [vocab-odrl] or from an ODRL Profile. In case of a Constraint Relations expression the leftOperand MUST refer to a complete Constraint object.
• In case of a Constraint expression the operator identifies the logical operation such as “greater than” or “equal to” between the left and right operand. In case of a Constraint Relations expression the operator identifiers the logic relationship of two constraints using operators like 'and', 'or' or 'xor'.
• In case of a Constraint expression the rightOperand identifiers ... In case of a Constraint Relations expression the rightOperand MUST refer to an complete Constraint object.
• In case of a Constraint expression the dataType indicates ... {{appended}} In case of a Constraint Relations expression these attributes MUST NOT be used.
• In case of a Constraint expression the status provides .... {{appended}} In case of a Constraint Relations expression status MUST NOT be used.

And we need a clarification in http://w3c.github.io/poe/model/#constraint-relations which constraints can be used for Constraint Relations: from the discussions I infer using only constraints of the Permission/Prohibition/Duty the Constraint Relations is applied to is sufficient, relationships "across the boarder" are not needed.

A practical issue I see: How can a receiver of a policy easily parse out that the leftOperand and the rightOperand are a constraint? In RDF this might be easier than in XML. I guess an implicit selector for "is Constraint" or "is Constraint Relations" could be the value of the operator: AND, OR or XOR makes it a Constraint Relations.

Note: I don't understand the specification of the status attribute ... it provides "the current value of leftOperand" - could the value of leftOperand change over time??

[riannella]

1 - I have applied all these change...

2 - I did not include "it SHOULD include the entity it constrains and how its value for a comparison has to be retrieved/generated." as we have no way of actually supporting that now. We once discussed "subjectOf" but the consensus seemed to be to have better constraint definitions.

3 - Updated vocab with "This operator MUST only be used for Constraint relations".

4 - I can't see us defining which constraints are valid for Constraint Relations. I think that is a business decision for communities. (or I missed your point ;-)

5 - In XML, you will see a "#" id and, or course, the operator will tell you too.

6 - Yes, status can change anytime. It is useful if you transfer a license between systems and need to indicate past history. (eg you have used 50 of your 100 counts)

[nitmws]

re 1: thanks

re 2: my proposed definition might need a slight adjustment (in bold): "its free-text definition SHOULD include the entity it constrains and how its value for a comparison has to be retrieved/generated." This sentence was explicitly a goal for the revisions of the existing Names of Constrant/Left Operands in the ODRL vocabulary: to explicity say if this constraint applies to the asset or the action or ... etc

re 3: Would the spelling Constraint Relations (= both uppercase) help the reader to keep track?

re 4: to clarify by an example: permission P1 has the "old" constraints C1, C2 and C3, Duty D1 has the "old" constraints C11 and C12. And permission P2 has a Constraint Relation combining C3 and C12 - is this referencing across the boader of a Rule ok or do things get too complex? And as constraints may have GUIDS it would be possible to refer a constraint in a different policy ...

re 5: as you have limited some operands to be used with Constraints Relations only the XML processing becomes easier.

re 6: I understand the intention. But is the wording "the current value of the left operand" clear? If a constraint has "leftOperand": "odrl:spatial" then I guess many would interpret "odrl:spatial" as the value of left operand.

[riannella]

Re 2: added a new 3rd paragraph to the section.

Re 3: Done

re 4: I see now. I think we allow this as the reuse of constraints is good thing.

re:5 : yes, you would have to use SHACL to do the same in OWL (and we won't ;-)

re 6: Hmm...you are right...its the rightOperand! Updated ;-)

[nitmws]

re 2: looks good, thanks.

re 3: currently (Mon, 30 Jan, 8:15 GMT) we can't see that in the Vocab document as it is still the 27 January verson.

re 4: after a conversation with @simonstey I understand the approach "in RDF a constraint is an entity with an identifier, this way it can be referrenced from anywhere". This formal approach is ok. But leaning towards a practical use, see my example above, I consider: C3 may constrain the use of asset A1, while C12 constrains the use of asset B99 - can these constraints be combined flawlessly, will a party have access to them if the permissions P1 and P2 are in different policies ? I suggest that at least in a Best Practice document such constraint references across rules and across policies should be discussed.

re 6: hmm, I'm afraid this may be a wrong change: can the value of the right operand change over time? At least for the "hard wired" rightOperand variant with in fact literal values (and not the rightOperandReference variant) this cannot be the case. So why shouldn't people look at the value of the status and not of right operand? I think the issue with my extracted wording "the current value of the left operand" is that it should tell "the current value generated from the definition of the left operand". E.g. the current count of actions, the current position or size of an asset. Isn't that what should be provided by status? And as a result I think the last paragraph before the examples should tell this: In case of a Constraint expression, the status provides the current value generated from the definition of the leftOperand. For example, a count constraint could have a rightOperand value of 10, and a status of 5 as the constrained action has been exercised currently 5 times. In case of a Constraint Relations expression, the status attribute MUST NOT be used.

[riannella]

re: 3 - updated the spelling in Vocab now

re: 4 - agree - the Best Practices document is a good place for this.

re: 6 - fixed - but left out "definition of" as that is more semantics