Define Atomic and Compound Constraint as subclasses

[nitmws]

The IM defines for the 2.6 Constraint Class an Atomic Constraint and a Compound Constraint.
Each of them has different sets of usable properties and properties have different rules for their use - but they are not defined as subclasses of the Constraint Class.
As e.g. the Policy Class has the sub-classes of Set, Offer and Agreement (and possibly more) providing different sets of properties with different cardinalities and also the subclasses of the Rule Class have different sets of properties I suggest to define also for this context

• the Constraint Class with a shared set of properties (leftOperand, operator, rightOperand)
• Atomic Constraint Class as subclass, with a specific set of additional properties (rightOperandReference, dataType, unit, status)
• Compound Constraint Class as subclass, with a limitation of the use of the operands and specific set of applicable operator values (as listed in 2.6.2)

Note: the definition of the constraint property of the Rule Class does not require a change as it allows the Constraint Class (and its subclasses) as object.

[riannella]

I contemplated this...then asked what was the overall benefit....
Lets decide at the next call

[riannella]

Updated model would look like this...

[benedictws]

Sub-classing constraints will likely be of use to any evaluation engine testing these constraints.

I also think we have the opportunity here to significantly enhance the expressiveness of ODRL.

I notice that three of the four operators allowable in a compound constraint have no sensitivity to order - i.e there's no distinction between a left and a right operand.

This suggest two things: both left and right operands are sub-classes of operand, which should be used in compound constraints when the order of the operands is irrelevant.

While we must have a minimum of two operands in a compound constraint there is no reason why we could not have more - linking a set of constraints with the specified operator.

This satisfies several scenarios I've come across while translating licenses.

[nitmws]

To clarify: the leftOperand and the rightOperand are properties and may become sub-properties of a operand property.
But how could this help? An Atomic Constraint has the properties leftOperand, operator and rightOperand, a Compound Constraint has in case of the operator andSequence the properties leftOperand, operator and rightOperand; in the case of or OR xor OR and the properties operand and operator?
The result in design would be the Constraint Class has Atomic Constraint and Compound Constraint as subclasses and the Compound Constraint Class has the Ordered Compound Constraint and the Unordered Compound Constraint as subclasses as they have different properties and a different processing model.
Further a (n Unordered) Compound Constraint with multiple operands and a single operator has tripwires:

• logical operators in the ODRL processor currently match only two operands, therefore a constraint with the operator "and" or "or" and 5 operands (O1...O5) would have to be built differently - increasing its number of variants.
• Boolean processing of "xor" has a special truth table, known by everybody using ODRL? Will this work as expected in practice ...
• ... or should xor be restricted back to two operand properties?

Note: such a "many operands and 1 operator" Constraint subclass may look interesting in terms of a simplified/compact syntax but in the end all compactness has to be expanded to the atomic level.

[nitmws]

My view on the change of the Constraint design as discussed at the call on 2017-07-03 - https://www.w3.org/2017/07/03-poe-minutes

1. Create a subclass Binary Constraint (close to the previous Atomic Constraint) and a subclass Multi Constraint of the Constraint Class
2. Binary Constraint class properties:

• leftOperand, cardinality 1, range: LeftOperand class instance or Constraint class instance
• rightOperand, cardinality 1, range: literal value or Constraint class instance
  OR rightOperandReference, same cardinality, range: anyURI
• operator, cardinality 1, range: (Binary?)Operator class instance
• datatype ... as currently in the IM
• unit ... as currently in the IM
• status ... as currently in the IM - or not? See next bullet.

3. Binary Constraint definition: Binary Constraints are expressions for comparing two operands by one operator. If the expression evaluates to true the Constraint is satisfied. Binary Constraints may use relational operators {see not all contraint operators are logical operators #194} or sequential logical operators. In the case of a sequential logical operator the leftOperand and the rightOperand must be a Constraint.
   {My question: does it make sense to allow a status property in case of a sequential logical operator?}
4. New definition of Sequential Logical Operator: the operator requires that first the leftOperand must be processed and only when it is satisfied the rightOperand can be logically compared as defined by the operand.

• andSequence: a Sequential Logical Operator, the Boolean operation AND is applied.

5. Multi Constraint class properties:

• operator, cardinality 1, range: ODRL Logical Operator
• operand, cardinality 1, range: list of 2 or more Binary Class instances

6. Multi Constraint definition: Multi Constraints are expressions for comparing two and more Binary Constraints as operands by one operator. If the expression evaluates to true the Constraint is satisfied. Multi Constraints may use only an ODRL Logical Operator.
7. New definition of ODRL Logical Operator: a Boolean Operator optionally with ODRL-specific limitations.

• and: same as Boolean AND
• or: same as Boolean OR
• xor1: out of a set of operands only one is satisfied to make the expression satisfied. If none of if more than 1 operands are satisfied the expression is not satisfied.

[riannella]

I question the "sequential logical operator" in the Binary Constraint - just to support the logical andSequence

All logical constraints should be in the "Multi Constraint".

Perhaps we should then support rdf:Seq for this purpose:

o:constraint [
  o:and [
    a rdf:Seq;
        rdf:_1 C1;
        rdf:_2 C2.
    ].

And we then don't even need o:andSequence any more ?

[nitmws]

I've raised where should andSequence reside at the call on Monday and heard it should be moved to the Binary Constraint as it should process only two Constraint results. That's why I've put it there in my suggestion.

Re @riannella suggestion:

• re the facts:
  • how to deal with the types of collections of object values: using rdf:Seq for sequences requires to use rdf:List for a simple set of values - right? (I see no alternative.)
  • I think using the operator odrl:and and a rdf:Seq as type of the object needs more to define the same as currently odrl:andSequence defines. I miss the definition that only after the first Constraint (leftOperand) in the sequence has been satisfied the next operand (rightOperand) in the sequence can be evaluated. Using a Boolean "and" with a sequence only sidelines the commutativity of the and operation, nothing else.
  • what about the Boolean or and the xor1 with rdf:Seq?
• the emotional facet: I recall from Monday that having to use explicitly rdf:Seq was not liked

[riannella]

RDF brings up lots of emotions ;-))

My main point was that we should have the same solution for all logical constraints.

Proposal: for logical constraints, we need to define a new (abstract) operand property with sub-properties: and, or, xor, andSequence

And the object of these properties is a list (referring to 2 or more binary Constraints)

[riannella]

This is what the updated Model would look like...

The (abstract) operand property would be sub-typed into or, and, xor, andSequence (etc)
(technically, leftOperand and rightOperand would also be subtypes of operand ??)

[nitmws]

To sort out things:

• a rdf:list is an RDF Collection: a closed set of items, like an enumaration as used by programming languages. An rdf:list has no order of its members.
• the operator andSequence needs a definition of the operand which must be processed first and only after it is satisfied the second operand may be processed.
• a sequence of members can be defined by RDF:

...
"constraint": [{
    "operator": "odrl:andSequence" ;
    "operand": [ 
        rdf:first <http://example.com/policy:88/C1> ;
        rdf:rest [
            rdf:first <http://example.com/policy:88/C2>;
            rdf:rest rdf:nil ]. 
        ] .
    }],
....

... which is doable but not any easy syntax.

• an example of a Logical Constraint with an odrl:and operand would look like

...
"constraint": [{
    "operator": "odrl:and" ;
    "operand":  ( <http://example.com/policy:88/C1> <http://example.com/policy:88/C2>  ) .
    }],
....

[riannella]

Yes, agree, scratch the idea of rdf:Seq ;-)

Also, I think that @simonstey wants to use odrl:and as the property:

"constraint": [{
    "odrl:and":  ( <http://example.com/policy:88/C1> <http://example.com/policy:88/C2>  ) .
    }],

[riannella]

The updated model for Constraints is probably less inheritance and more whole/part.
So this could be more aligned:

[nitmws]

May I infer from the diagram above that there are two Constraint classes: Constraint and Logical Constraint?

... and what happens to odrl:andSequence? I suggest:

• to set its Range to Constraint
• to define it as: "Both the leftOperand and the rightOperand must refer to a Constraint. The relation is satisfied when the left operand Constraint delivers a satisfied result before the right operand Constraint is evaluated. The right operand Constraint may build on the satisfaction of the left operand Constraint.

[simonstey]

Also, I think that @simonstey wants to use odrl:and as the property

yes, like in SHACL

... and what happens to odrl:andSequence?

didn't we agree to have it as one of the operators of "normal" constraints?

to set its Range to Constraint

the range of what?

[nitmws]

@simonstey I've been talking about odrl:andSequence above: it's Range should be Constraint.

If we create two constraint classed also the Domains of all operators in the Core and the Common Vocabulary must be set according to our split up above - currently the Domain is not shown in the HTML page of the Vocabulary but in exists in the Turtle.

[simonstey]

I've been talking about odrl:andSequence above: it's Range should be Constraint.

If we create two constraint classed also the Domains of all operators in the Core and the Common Vocabulary must be set according to our split up above - currently the Domain is not shown in the HTML page of the Vocabulary but in exists in the Turtle.

if odrl:andSequence is used as value of odrl:operator as in:

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Offer",
    "uid": "http://example.com/policy:88",
    "permission": [{
        "target": "http://example.com/photo.jpg",
        "assigner": "http://example.com/org/fifa",
        "action": "distribute",
        "constraint": [{
                "leftOperand": "http://example.com/policy:88/C1",
                "operator": "andSequence",
                "rightOperand": "http://example.com/policy:88/C2"
            }],
    }]
}

it has neither a rdfs:range nor rdfs:domain

we could state, however, that if the operator is odrl:andSequence, values of both odrl:leftOperand and odrl:rightOperand must be constraints.

[vroddon]

If it helps, I would just say that in MPEG-21 Media Contract Ontology, we opted for a very similar approach. Instead of contraints, I suggested speaking in terms of "facts" Consequently, we defined:
:FactIntersection, :FactNegation, :FactUnion. The concept of "atomic constraints" and "compound constraint" was purely implicit.

Union and Intersection had two operands, negation only one.
See informally here: http://vroddon.sdf-eu.org/mco/mco-core/#FactComposition
See also here: http://www.semantic-web-journal.net/system/files/swj1218.pdf (Overview of the MPEG-21 Media Contract Ontology).

[riannella]

WG agreed to the above updated model for constraints: https://www.w3.org/2017/07/10-poe-minutes

[riannella]

Updated the IM with the constraint/logical model

Commit: bee8032

(note: the vocab is next...)

[riannella]

Updated the Vocab (and encodings)

commit: effcc01

[riannella]

Hmmm...turtle (and JSON-LD) shortcuts for collections:
https://www.w3.org/TR/turtle/#collections
https://www.w3.org/TR/json-ld/#sets-and-lists
are ordered sequences?

Hence, we could use these for the andSequence logical operand as well?

[riannella]

Updated the Logical Constraints to support an ordered list for operands (such as andSequence)