odrl:action "use" vs. "USE"

[eschrewe]

Describe the bug

According to the recently updated documentation it is now recommended to use lowercase letters when defining the "odrl:action" field within the request body of a policy definition.
https://github.com/eclipse-tractusx/tractusx-edc/blob/main/docs/usage/management-api-walkthrough/02_policies.md

I.e.

"odrl:action" : "use"

instead of

"odrl:action" : "USE"

As far as I know, the previous way (using capital letters) was not in line with the odrl standard.

I am currently using the TractusX EDC Version 0.5.3. Until recently, I was creating Policy Definitions in with "USE" in capital letters.
Example:

{
    "@context": {
        "odrl": "http://www.w3.org/ns/odrl/2/"
    },
    "@type": "PolicyDefinitionRequestDto",
    "@id": "Framework_Agreement_Policy",
    "policy": {
        "@type": "Policy",
        "odrl:permission": [
            {
                "odrl:action": "USE",
                "odrl:constraint": {
                    "@type": "LogicalConstraint",
                    "odrl:leftOperand": "FrameworkAgreement.traceability",
                    "odrl:operator": {
                        "@id": "odrl:eq"
                    },
                    "odrl:rightOperand": "active"
                }
            }
        ]
    }
}

Everything worked as expected, when "USE" was written in upper case letters.

Now I tried to switch to the lowercase syntax. But this change seems to cause troubles on the control plane.

Below, you can see the catalog item of an asset, that was registered and that references a contract policy, which was defined with the "use" keyword in lowercase:

{
  "@id" : "request-api-asset",
  "@type" : "dcat:Dataset",
  "odrl:hasPolicy" : [ {
    "@id" : "QlBOTDEyMzQ1Njc4OTBaWl9jb250cmFjdGRlZmluaXRpb25fZm9yX1JFUVVFU1Q=:cmVxdWVzdC1hcGktYXNzZXQ=:ZmM3M2E0N2UtMTlmZS00OTA4LWI0YTUtMjg0OTBlMzYxYjlk",
    "@type" : "odrl:Set",
    "odrl:permission" : {
      "odrl:target" : "request-api-asset",
      "odrl:action" : {
        "odrl:type" : "use"
      },
      "odrl:constraint" : {
        "odrl:leftOperand" : "FrameworkAgreement.traceability",
        "odrl:operator" : {
          "@id" : "odrl:eq"
        },
        "odrl:rightOperand" : "active"
      }
    },
    "odrl:prohibition" : [ ],
    "odrl:obligation" : [ ],
    "odrl:target" : "request-api-asset"
  }, {
    "@id" : "QlBOTDQ0NDQ0NDQ0NDRYWF9jb250cmFjdGRlZmluaXRpb25fZm9yX1JFUVVFU1Q=:cmVxdWVzdC1hcGktYXNzZXQ=:M2NjNGM1MTItMjFiZi00NDZmLWFiOTctZDA4N2MzNGRkZTdh",
    "@type" : "odrl:Set",
    "odrl:permission" : {
      "odrl:target" : "request-api-asset",
      "odrl:action" : {
        "odrl:type" : "use"
      },
      "odrl:constraint" : {
        "odrl:leftOperand" : "FrameworkAgreement.traceability",
        "odrl:operator" : {
          "@id" : "odrl:eq"
        },
        "odrl:rightOperand" : "active"
      }
    },
    "odrl:prohibition" : [ ],
    "odrl:obligation" : [ ],
    "odrl:target" : "request-api-asset"
  } ],
  "dcat:distribution" : [ {
    "@type" : "dcat:Distribution",
    "dct:format" : {
      "@id" : "HttpProxy"
    },
    "dcat:accessService" : "f1979a49-aba3-40bb-9232-ca9d152d514b"
  }, {
    "@type" : "dcat:Distribution",
    "dct:format" : {
      "@id" : "HttpData"
    },
    "dcat:accessService" : "f1979a49-aba3-40bb-9232-ca9d152d514b"
  } ],
  "edc:description" : "Item Stock Request Status API Endpoint",
  "asset:prop:type" : "data.res.itemStockRequestApi",
  "https://w3id.org/catenax/ontology/common#version" : "1.0",
  "edc:id" : "request-api-asset",
  "dct:type" : {
    "@id" : "https://w3id.org/catenax/taxonomy#ItemStockRequestApi"
  }
}

You will notice, that the catalog entry contains the same policy definition twice. This does not happen, when my policy definition still was containing "USE" in upper case letter.

To Reproduce

Clone this project to your local system.
Then, please run

git switch feat/testUse

This branch is basically identical to the current main branch. It only contains some additional logging output.

Now, please follow the steps described in the https://github.com/eclipse-tractusx/puris/blob/main/local/INSTALL.md file
Please note that the docker build for the puris backend might take around 5 minutes, when running it for the very first time. Consecutive docker build should run considerably faster.

When you have completed all those steps, please visit http://localhost:3000 and trigger a data transfer. I.e. please select the "Stocks" tab on the left side. Then you shoud see a table named "Your Stocks" in the middle of the screen. Please click on the row containing the word "Semiconductor". It should be highlighted with orange color now. Then, please click on the "Update Partner Stocks" - button slightly below on the right.

Now please observe the logging output of the terminal window, where you exectuted the "docker compose up" command. When you scroll up, you should see an entry of a catalog item, containing a single policy.

Now, please use your favourite Java-IDE, open the puris project, you just cloned, and visit this file in the backend folder:

org.eclipse.tractusx.puris.backend.common.edc.logic.util.EdcRquestBodyBuilder.java

Now, please visit the buildFrameworkAgreementPolicy() - method. There is a line

permissionsObject.put("odrl:action", "USE");

Replace this line with

permissionsObject.put("odrl:action", "use");

Repeat this for the buildBpnRestrictedPolicy(Partner partner) - method. I. e. replace "USE" with "use" there, too. (BTW: This is the policy defintion template, we are using as our access policy.)

Then, please

• save this file
• stop your docker containers ("docker compose down -v")
• do a new build of your puris backend docker image
• do a docker compose up again

Now, if you repeat the steps described above for triggering "Update Partner Stocks", you should see in the logs, that the catalog entry contains a doubled policy.

Expected behavior

The control plane should not insert doubled policy data into the catalog entry.

Screenshots/Error Messages

See above

Context Information

See above

Possible Implementation

See above

[ndr-brt]

question: could you try to test out 0.6.0 and verify if there's the same behavior?

I tried to replicate it but I wasn't able, still getting a single hasPolicy entry. Could you try with a cleaned up database?

(nit: the policy json is missing the "@vocab": "https://w3id.org/edc/v0.0.1/ns/" entry in the catalog block)

[eschrewe]

Our project is planning to move on to the TractusX-EDC version 0.6.0 in a few weeks. When this has happened, I will this test again.

And thx for hinting at the missing "@vocab" field. I will try that as well then.
Though, I would like to add, that this is not specified in the current documentation

[mhellmeier]

And thx for hinting at the missing "@vocab" field. I will try that as well then. Though, I would like to add, that this is not specified in the current documentation

Maybe the author of the documentation (@arnoweiss) can help here.

[ndr-brt]

there's some ongoing work in that specific doc piece in #856

[github-actions]

This issue is stale because it has been open for 4 weeks with no activity.

[arnoweiss]

The docs' payloads work. If you omit the @vocab field in the context, the Management API will imply it and persist the data correctly anyways. I'll double-check the payloads to not rely on this behavior.

About the issue itself: only odrl:use is correct as noted here [1]. I'm unsure if the EDC enforces that. @eschrewe - is the issue resolved with eclipse-edc 0.5.1 (tractusx-edc 0.6.0)?

[1] eclipse-edc/Connector#3927

[eschrewe]

The docs' payloads work. If you omit the @vocab field in the context, the Management API will imply it and persist the data correctly anyways. I'll double-check the payloads to not rely on this behavior.

About the issue itself: only odrl:use is correct as noted here [1]. I'm unsure if the EDC enforces that. @eschrewe - is the issue resolved with eclipse-edc 0.5.1 (tractusx-edc 0.6.0)?

[1] eclipse-edc/Connector#3927

Hi @arnoweiss ,
I still could not properly test it on a tractusX EDC version > 0.5.3. Unfortunately, our project had to make the decision to skip the tractusX EDC version 0.6.0, because it had introduced another bug, which made it impossible to make use of the "proxyMethod" feature.

See here

[github-actions]

This issue is stale because it has been open for 4 weeks with no activity.

[github-actions]

This issue was closed because it has been inactive for 14 days since being marked as stale.

[eschrewe]

The docs' payloads work. If you omit the @vocab field in the context, the Management API will imply it and persist the data correctly anyways. I'll double-check the payloads to not rely on this behavior.

About the issue itself: only odrl:use is correct as noted here [1]. I'm unsure if the EDC enforces that. @eschrewe - is the issue resolved with eclipse-edc 0.5.1 (tractusx-edc 0.6.0)?

[1] eclipse-edc/Connector#3927

I can now officially confirm that on TX-EDC version 0.7.1, this is no longer an issue :)