fix: Fixed the ODRL policy type to the Set value

[leandro-cavalcante]

Description

Fixed the type 'Offer' to 'Set'

Why

Currently the type 'Offer' is not supported.

Issue

N/a

Checklist

Please delete options that are not relevant.

• I have performed a self-review of my own code
• I have successfully tested my changes locally
• I have fixed tests that prove my changes work
• I have checked that new and existing tests pass locally with my changes

[Phil91]

code wise looks good and is ready to merge. where does this requirement come from?

@MaximilianHauer do you know something about why the change is necessary?

[MaximilianHauer]

not aware of it @leandro-cavalcante can you provide some feedback ?

[leandro-cavalcante]

code wise looks good and is ready to merge. where does this requirement come from?

@MaximilianHauer do you know something about why the change is necessary?

When trying to use the policies created by PolicyHub within EDCs this issue was detected. In our analysis we discover the type Offer is not supported yet. We have made this changes to make Policy Hub to be compatible to the actual EDC implementation and to cause less confusion when the customer uses Policy Hub as a guide to apply policies.

[MaximilianHauer]

currently under clarification if this change is allowed/wanted.

[MaximilianHauer]

@leandro-cavalcante based on the oldr rules from catena-x both Set and Offer should be valid.
Therefor the replacement is not understandable for me.

https://github.com/catenax-eV/cx-odrl-profile/blob/main/profile.ttl

[leandro-cavalcante]

@leandro-cavalcante based on the oldr rules from catena-x both Set and Offer should be valid. Therefor the replacement is not understandable for me.

https://github.com/catenax-eV/cx-odrl-profile/blob/main/profile.ttl

That is correct "Offer" type should be valid. The problem comes when the customer generates the template and try to apply it to an EDC. The current implementation of tractusx-edc is running to an error, working only when the type "Set" is used. Takes time to the customer to debug and understand the issue. We can remove the current PR but It is important to open an issue to analyze it from the EDC source side.

[MaximilianHauer]

@leandro-cavalcante ill pick up the topic for the data sovereignty group on friday to discuss how to proceed here.

[lgblaumeiser]

@MaximilianHauer I have discussed that with my EDC experts. The background of this is that the profile defines three types:

## Policy Subclasses
skos:member odrl:Agreement ;
skos:member odrl:Offer ;
skos:member odrl:Set ;

but they have different meaning during the lifecycle of the policy. At least, that is how it is semantically implemented in the EDC. If defined, the policy is a technical thing, so the type 'Set' is the one to be used in the definition. As soon as it is connected to an asset to build an offer, the type changes to 'Offer' as observable in a catalog received from an EDC. If there is an contract agreed on such an offer, the type changes to 'Agreement'. So this pull request here is right, as it reflects the semantic implemented in the EDC.

The question is, whether this should be reflected somehow in the profile and if ODRL allows enough flexibility to express this transition. If there are other opinions, we need to discuss but this would need the involvement of the experts from the EDC upstream team, as what is implemented expresses the original intention.