International-Data-Spaces-Association/InformationModel

Reuse further terms from ODRL

clange opened this issue · 2 comments

clange commented

In a review post #504 and #543, I noticed that still a few terms are around that IDS redefines from ODRL but where IDS does not add value. These should also be stripped and replaced by plain ODRL.

Overall, let's keep this discussion in sync with https://github.com/International-Data-Spaces-Association/ODRL-profile-for-IDS/.

  • target
  • anything in "codes" was not subject of the review done in #504 / #543 but should also be reviewed. At a first glance, the following terms are redundant:
    • idsc:USE → odrl:use
    • idsc:COMPENSATE → odrl:compensate
    • idsc:PAY_AMOUNT → odrl:payAmount
    • idsc:EQ → odrl:eq (OK, maybe here there is a (small) added value in IDS = explicitly stating that this is a binary operator. However, I'd suggest we check this with the Usage Control experts around @hosseinzadeha, whether the information that an operator is binary is really needed. In any case I do not see operators that are not binary.)

This will be helpful for the further alignment with Gaia-X, where plain ODRL shall be used as much as possible, and thus in scope of the FDS T72 project.

For the Gaia-X perspective, note https://gitlab.com/gaia-x/technical-committee/federation-services/data-exchange/-/merge_requests/19.

  • Furthermore, evaluation_external/README.md says that rightOperand is "pending". Is the "why" documented somewhere? If not, could you please document it?

  • Additionally, why is ids:actionRefinement needed in addition to odrl:refinement, and why is it not a subproperty of odrl:refinement? actionRefinement seems to be covered by the domain of odrl:refinement including odrl:Action; participantRefinement might be covered by the domain of odrl:refinement including PartyCollection, which is a subclass of Party, which could be (or is already?) aligned with ids:Participant.

  • idsc:WRITE might be obsolete, as ODRL deprecated it in favour of odrl:modify.

  • Could it actually be that ids:contractOffer is redundant and can be replaced by odrl:policy?

besteves4 commented

Hi!

It is nice to see the usage of plain ODRL for alignment between data spaces initiatives.

A few comments:

  • Regarding the operators, I understand you are defining idsc:EQ in the Information Model instead of using odrl:eq as you want to make explicit that it is a binary operator. I'm not sure if this is necessary as I think ODRL operators should always be binary. However, as I'm an active member of ODRL's CG and am involved on the ODRL's formal semantics specification (which should be the first step to hopefully have an ODRL 3.0), might I make a suggestion that you bring this issue to the CG for discussion? I would be very happy to discuss this in one of our meetings as it is something that can be used to improve at least the description of the operator concept.
  • Same thing for other ODRL concepts you feel need a tweak in their description -- if they are not data spaces-specific then now is a good time to suggest changes to the ODRL CG.
  • Unless you have a good reason to have different types of refinements, I would stick to the usage of odrl:refinement.
  • Instead of ids:contractOffer, you could stick with plain ODRL and model the policy as an odrl:Offer and use odrl:contractingParty and odrl:contractedParty to express the party who is offering the contract and the party who is being contracted, respectively.
  • odrl:hasPolicy can be used to connect resources with policies.

Happy to discuss any other alignments :)

lcomet commented

I proceeded to make the following changes:

Note: All the changes are also reflected in our document here: https://docs.google.com/spreadsheets/d/17RjLl6wkL_V2_jbf_vBfJ_77NgmENnf_tIfWZsNhr_Y/edit#gid=0