Evaluation of Constraints of a Rule inconsistent

[nitmws]

I refer to the Information Model document of 13 June - http://w3c.github.io/poe/model

• A Rule defines: "A Rule MAY have one or more Constraints via the constraint property. The Rule becomes effective if all of the Constraints are satisfied."
• The Compound Constraint section defines "Compound Constraints refer to two existing Atomic Constraints as the left and right operand. For example, Atomic Constraint UCR Skeleton documents #1 (leftOperand) must be satisfied or (operator) Atomic Constraint Setting up IPR link #2 (rightOperand) must be satisfied."
• Conclusion 1: to satisfy the Compound Constraint CC1 the Atomic Constraint AC1 can be satisfied and the Atomic Constraint AC2 does not have to be satisfied.
• Conclusion 2 : and CC1, AC1 and AC2 may all be Constraints associated with a single Rule by its constraint properties.
• An example like the one above raises a contradiction:
  • AC1 is satisfied
  • AC2 is not satisfied
  • by the or operand CC1 is satisfied
  • by the generic constraint evaluation of a Rule all its constraints (AC1, AC2 and CC1) must be satisfied - which is not the case in this example but our human eye tells us: "This Rule should become effective". More troubles would be caused by using the xor operand for CC1.

How to solve that:
A logically ok approach would be: "The Rule becomes effective if all of its Constraints are satisfied, excluded are Constraints being an operand of a Compound Constraint of this Rule." But such a design would be hard to process: first all constraints are listed, then iterated and by evaluating Compound Constraints all Constraints being an operand are removed from the list. Then all the remaining Constraints are finally evaluated.
A helper would be a new boolean property "isCompoundOperand" of Constraint, default value false. It should be set to true for Constraints which are a leftOperand or rightOperand of a Compound Constraint only. The definition used for Rule could be: "The Rule becomes effective if all of its Constraints are satisfied, excluded are Constraints being a Compound Operand".

Footnote: currently the specification of Compound Constraint doesn't tell anything about to which Rule the Compound Constraint and its Atomic Constraints must/should be applied. It would be valid if CC1 is a constraint of Rule1, AC1 of Rule2 and AC2 of Rule3.
First: do we really support such a wide flexibility?
And: if yes I see the use of isCompoundOperand as a MUST, a processor having to find out if a constraint of a Rule is an operand of a Compound Constraint anywhere in the ODRL universe would be impossible.

[riannella]

If a Rule has a Compound Constraint, then the two Atomic constraints (in the left/right operand) are not considered constraints of the Rule (but of the Compound constraint itself.).

An ODRL Evaluator will know (from the type of the left/right operands) if they are dealing with a Compound Constraint or not.

RE: Footnote: If you look at Example 16: http://w3c.github.io/poe/model/#constraint-compound
you can see the two atomic constraints do not apply to any Rule.
Only the Compound Constraint does...

Does that make sense?

[nitmws]

@riannella I have a serialization-driven view on that issue.
What is the conclusion from your statement:

• A Constraint instance is independent from any Rule
• This instance has its unique identifier, e.g. from example 16: http://example.com/policy:88/C1
• But what serialization of data will one get when accessing this URL? There is not definition in the XML Schema for such a standalone Constraint and I'm not sure if the current JSON serialization supports that.

If we fix the serialization issue a statement about such "standalone Rule"s should be made and we must defined that Rules of a leftOperand or a rightOperand MUST NOT be associated with a Rule by a constraint relationship. Else the contradiction outlined above applies.

[simonstey]

But what serialization of data will one get when accessing this URL? There is not definition in the XML Schema for such a standalone Constraint and I'm not sure if the current JSON serialization supports that.

if "standalone" constraints would cause issues with ODRL's legacy XML/JSON serializations, so would any other ODRL concept.

[nitmws]

The ODRL 2.0/.1 XML and JSON reflected a user's view on the model design: a policy is a wrapper/container of one to many rules. Permissions, prohibitions, duties, constraints - they all have their specific structure inside the container.
And it is a wide expectation and need to have all Things relevant for a Policy inside the serialization of a Policy. Having to hand over the data of a policy to an assignee as a crowd of standalone entities will not be accepted.

This raises the questions:

• will POE/ODRL have serialization formats which support including all Things relevant for a Policy?
• if yes: where to put instances of Atomic Constraints which are xOperands of a Compound Constraint?

[riannella]

We have documented how XML serialisations deal with compound constraints here:
https://w3c.github.io/poe/vocab/#constraint-relations

(Yes, I know, we need to s/Constraint Relations/Compound Constraints/)

Is there more we can add there?

[nitmws]

Well, the #constraint-relations section shows s as children of policy, but the definition of (below 5.1) does not list constraint as supported element.
And the XML encoding definitely needs a mapping from the Information Model to the encoding. What are and elements at the policy level good for? The Policy class doesn't know them.

[riannella]

I've updated the xml section.

The XML Schema already supported constraint at the policy level.

commit c56da6d
9972af2

[nitmws]

@riannella the /parts/xml.html was updated but not the index.html!

Having a look at the commits:
The statement "The Policy element MAY also contain the constraint element to support Compound Constraints" is not clear enough:

• the asset & co are named as plural "... MAY contain ... element_s_ ...". As also multiple s may be used they need a plural too.
• "... to support Compound Constraints ..." in which way??

I suggest:
The Policy element MAY also contain constraint elements which are Atomic Constraints referenced by Compound Constraints; but these Atomic Constraints are not a direct constraint of a Rule and therefore not a child element of it.

[nitmws]

For XML it looks like we have a solution - but not for JSON(-LD):

Examples 17 and 18 in the Information Model document's https://w3c.github.io/poe/model/#constraint-compound section show a "constraint" at the top level of the object. The object claims by its "@type": "Offer" to be a subclass of odrl:Policy.
But in the ODRL ontology we have this specification of the constraint property:

:constraint
	a rdf:Property , owl:ObjectProperty, skos:Concept ;
	rdfs:isDefinedBy odrl: ;
....
	rdfs:domain [
		a owl:Class ;
		owl:unionOf ( :Rule :AssetCollection :PartyCollection ) ;
	] ;
	rdfs:range :Constraint .

This shows no :Policy (and no :Offer etc) in the rdfs:Domain, therefore Examples 17 and 18 are unfortunately invalid.

So we could do something similar like for XML, it would even be better to have a definition that only a constraint referenced by a Compound Constraints may be a property of Policy - may be possible by some tricky RDF/OWL.

[riannella]

Updated xml narrative (and index.html now)

We do also support an Atomic Constraint at the policy-level that is there only to be referenced by an (atomic) constraint in a Rule. Eg the same atomic constraint in 2 rules.

commit: dc4065d

[nitmws]

@riannella by which feature of ODRL may an Atomic Constraint of a Rule reference an Atomic Constraint?
Should it look like this reformulated example 15?

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Offer",
    "uid": "http://example.com/policy:6161",
    "permission": [{
        "target": "http://example.com/wallpaper:1234",
        "assigner": "http://example.com/myPix:6161",
        "action": "distribute",
        "constraint": [{
            "leftOperand": "spatial",
            "operator": "eq",
            "rightOperand": "https://www.iso.org/obp/ui/#iso:code:3166:IT"
        }],
        "duty": [
            {
                "action": "compensate",
                "constraint": [ "http://example.com/policy:6161/C1" ]
            },
            {
                "action": "nextPolicy",
                "target": "http://example.com/policy:7171"
            }
        ]
    }],
    "constraint": [{
        "uid": "http://example.com/policy:6161/C1",
        "leftOperand": "spatial",
        "operator": "eq",
        "rightOperand": "https://www.iso.org/obp/ui/#iso:code:3166:IT"
    }]
}

If yes: how to make this work in XML?

[riannella]

Yes. A Rule (ie Duty) can have a uid, which is then referenced as above.
(In fact, the first constraint can also be a ref to C1)

In XML, you can use the id/idref attributes