Closed clange closed 7 months ago
Hi!
It is nice to see the usage of plain ODRL for alignment between data spaces initiatives.
A few comments:
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.odrl:refinement
.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 :)
I proceeded to make the following changes:
idsc:USE → odrl:use
(commit: 2567bde2): aligned with the proposal in https://github.com/International-Data-Spaces-Association/ODRL-profile-for-IDS/issues/12dsc:WRITE→ odrl:modify
(commit: cfde3134): aligned with the proposal in https://github.com/International-Data-Spaces-Association/ODRL-profile-for-IDS/issues/16idsc:COMPENSATE → odrl:compensate
(commit: 441e91db): aligned with the proposal in https://github.com/International-Data-Spaces-Association/ODRL-profile-for-IDS/issues/15idsc:PAY_AMOUNT → odrl:payAmount
(commit: c7b660d2): aligned with the proposal in https://github.com/International-Data-Spaces-Association/ODRL-profile-for-IDS/issues/28idsc:PAYMENT
, added a note as suggested in https://github.com/International-Data-Spaces-Association/ODRL-profile-for-IDS/issues/28 (commit: 40222f64)idsc:TARGET_POLICY
removed this property, as it is suggested here https://github.com/International-Data-Spaces-Association/ODRL-profile-for-IDS/issues/23 to directly use odrl:hasPolicy as the target policy (commit: cc4c1974)idsc:EQ → odrl:eq
(commit: ab882a3b) After evaluating the definition of the idsc:EQ, and considering the comment from @besteves4, I removed the idsc:EQ and replaced it with odrl:eqids:rightOperand
was replaced byodrl:rightOperand
by commit https://github.com/International-Data-Spaces-Association/InformationModel/commit/18371369eb0ca7c92ce7c8a6ab4176a46f037d1c. Moreover, changes in the documentation and README file corresponding to the evaluation (commit:77b91ce8)ids:actionRefinement
and ids:participantRefinement
are removed and replaced by odrl:refinement
(commit: 9adc4f43)ids:contractOffer
will be consider in https://github.com/International-Data-Spaces-Association/InformationModel/issues/608 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
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
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.
[x] Furthermore,
evaluation_external/README.md
says thatrightOperand
is "pending". Is the "why" documented somewhere? If not, could you please document it?[x] Additionally, why is
ids:actionRefinement
needed in addition toodrl:refinement
, and why is it not a subproperty ofodrl:refinement
?actionRefinement
seems to be covered by the domain ofodrl:refinement
includingodrl:Action
;participantRefinement
might be covered by the domain ofodrl:refinement
includingPartyCollection
, which is a subclass ofParty
, which could be (or is already?) aligned withids:Participant
.[x]
idsc:WRITE
might be obsolete, as ODRL deprecated it in favour ofodrl:modify
.[ ] Could it actually be that
ids:contractOffer
is redundant and can be replaced byodrl:policy
?