Assigner/Assignee at the policy level

[vroddon]

As I understand from previous conversations and from the current spec., the odrl:assigner and odrl:assignee cannot be longer used at the policy level, only at the rule level. The current ontology defined their domain as:

    rdfs:domain [
        a owl:Class ;
        owl:unionOf ( :Rule :Policy ) ;
    ] ;

but it should be: rdfs:domain :Rule ; As I am reasonably sure, I have implemented the change (see 843c4732d7ebc08e66e3c4df7edce6fc9794522f)

[nitmws]

I'm afraid this comes from defining the use of "shared properties" in 2.7.1 Compact Policy and leaving this definition as an orphan in the spec of Policy sub-classes:

An ODRL Policy of subclass Offer ... must have one assigner property value (of type Party) to indicate the functional role in the same Rules.

An ODRL Policy of subclass Agreement ... must have one assigner property value (of type Party) to indicate the functional role in the same Rules. must have one assignee property value (of type Party) to indicate the functional role in the same Rules.

The wording "to indicate the functional role in the same Rules." lets me assume this is related to Compact Policy which defines:

Properties that may be shared include: One or many action properties. One or many sub-properties of relation (such as target). One or many sub-properties of function (such as assigner and assignee).

My suggestion: remove these property definitions of Offer and Agreement listed above.

[riannella]

@vroddon Section 2.7.1 explains why: https://w3c.github.io/poe/model/#composition-compact

To support these "short cuts" we allow "shared" properties (at the Policy level) - and they are interpreted to mean they apply to all Rules in the Policy.

[nitmws]

@riannella that raises an issue of consistent specifications:

Option 1: all the "shared properties" of 2.7.1 are NOT defined as properties of the Policy and its sub-classes. OR Option 2: they are defined. In this case the IM is missing definitions in the Policy Class:

• action property (0..unbounded) type: Action
• abstract relation property (0..unbounded) type: Asset
• abstract function property (0..unbounded) type: Party
• (Note on the abstract properties: they must be there else it would not be possible to use sub-properties defined by a Profile!)
• and ALL of them SHOULD have an explanation under which conditions these properties may be used, like "This property may be used only for the Compact Policy format as defined in 2.7.1."
• specific sub-properties of relation or function in sub-classes of Policy: they should also have this explanation.

[vroddon]

Option 2 is the more powerful, but it complicates the validator (the processing will be easy, though). In any case, there is something wrong/imprecise in the spec (2.1.2) now:

[Offer Class] must have one assigner property value (of type Party) to indicate the functional role in the same Rules.

I would write it as:

[Offer Class] must have one assigner property value (of type Party) to indicate the functional role in the same Rules.

[Offer Class] must have either one assigner property value (of type Party) to indicate the functional role in the Rules, or have the assigner in each of their Rules.

Wouldn't it suffice this change? (the same applies in more points of the spec)

[vroddon]

The validation becomes more and more complex, by the way. If you think of an Offer...

POLICY A
- Rule1, assigner1
- Rule2, assinger2

I believe this should be validated as wrong, but we haven't declared this constraint anywhere. Second example:

POLICY B, assigner 1
- Rule1, assigner2

Again, this should be validated as wrong. Or rather, lift our "validation standard" and make it more tolerant. (I vote for the latter).

[vroddon]

For the moment I restored the previous state of the ontology. But I am afraid we cannot avoid the changes in the text. 3b98c5442f2c859acb4cec0a9847cac3c80056ba

[nitmws]

@vroddon have a look at 2.7.1, it defines "An ODRL Policy may hold properties, declared at the Policy-level, which are shared and common to all its Rules. " Conclusion from that: if e.g. an assigner is defined at the Policy-level, any Rule MUST NOT have an assigner, that's why PolicyB is invalid. Don't know how easy or hard this is for SHACL to validate.

[riannella]

I have updated the Policy class section.

I don't think we change the rest of the spec, as we say "It is recommended that compact ODRL Policies be expanded to atomic Policies when being processed for conformance"

Also:

Conclusion from that: if e.g. an assigner is defined at the Policy-level, any Rule MUST NOT have an assigner, that's why PolicyB is invalid.

No, this is not correct. You can have both. The assigner at the Policy-level will be replicated into all the Rules (and join existing assigners)

[vroddon]

@nitmws

Don't know how easy or hard this is for SHACL to validate.

I have identified some constraints not possible (at least easily) to be represented in SHACL; so having one more does not really matter.

[nitmws]

@riannella sorry, but I think your "merging assigners" violates the IM. 2.6.1, 2.6.2 and 2.6.3 define:

A Permission/Prohibition/Duty may have none or one assigner and/or assignee property values (of type Party) for functional roles. (Other function sub-properties may be used.)

... there must be no second or third assigner!

[riannella]

Whoops...I was thinking "actions".... The spec is correct as is now ;-)