Types of policies that can be evaluated

[AndreaCimminoArriaga]

The formal semantics document specifies that an evaluator should consider only odrl:Set. Nevertheless, specifying this would entail a retrocompatibility to any policy defined until now with the ODRL semantics SHOULD be evaluable. I think, IMHO, it would be interesting to have a sub-type, something like odrl:EnforceablePolicy or odrl:EvaluableSet, etc. to mark the policies that MUST be enforceable from now on if they use such type.

[joshcornejo]

I don't agree with odrl:Set being the only one to be evaluated, IMHO it is the least likely candidate.

At its simplest, evaluations are "can party Adam, perform Action Use over asset Car", without a party in the odrl:assignee role, you are not evaluating a complete policy.

The only tangible/actionable policies (those that have actions that are performed by assignees), are of the class odrl:Agreement.

An odrl:Set doesn't need to make sense (read "any" below):

• odrl:Set = "An ODRL Policy of subclass Set(An ODRL Policy of subclass Agreement represents Rules that have been granted from assigner to assignee Parties.) represents any combination of Rules." A placeholder for rules, sort of catalogue;
• odrl:Offer = "An ODRL Policy of subclass Offer represents Rules that are being offered from assigner Parties.";
• odrl:Request = a request to match an odrl:Offer
• odrl:Agreement = "An ODRL Policy of subclass Agreement represents Rules that have been granted from assigner to assignee Parties"

[AndreaCimminoArriaga]

I missed to add also odrl:Agreement as evaluable policy. I just edited the issue

I don't agree with odrl:Set being the only one to be evaluated, IMHO it is the least likely candidate.
This is written in the formal semantics document, I'm just citing it.

In any case, I think that your comment is somehow aligned with the fact that maybe a new type to specify policies that an evaluator must be able to understand can be an interesting ad-on to have.