w3c
Representation of request for the ODRL Evaluator
The ODRL Evaluator takes a request as input.
Whereas ODRL declares a odrl:Request policy in the context of negotiation (official definition reads "A Policy that proposes a Rule over an Asset from an assignee"), the need to represent a request in the context of evaluation is clearly different --in no case "a request" should be a type of "policy". Therefore, for the sole purpose of representing a request to the ODRL Evaluator, it is proposed to adopt the
openId style. See this example (related to E13-1):
{
"subject": {
"id": "http://example.com/party/1"
},
"resource": {
"id": "http://example.com/document/1234"
},
"action": {
"name": "http://www.w3.org/ns/odrl/2/distribute",
},
"context": {
"time": "2024-12-20T12:22-07:00"
}
}
It is worth observing that this proposal is only relevant in relation to the Formal Semantics (e.g. description of an ODRL Evaluator). Unless there is an objection, we will describe this in the Formal Semantics document. (@riannella @besteves4 @AndreaCimminoArriaga @all)
This issue is open in the context of the ODRL Formal Semantics meeting held in Madrid, with the agreement of @fornaran @YassirSellami @vroddon and @joshcornejo.
Rfc 9396 nor AuthZen have a formal class, but I would recommend any of the following:
odrl:Examination
odrl:Inquiry
odrl:Solicitation
With Inquiry or Examination being the most decisive semantic matches.
Hi!
A couple of questions:
the need to represent a request in the context of evaluation is clearly different --in no case "a request" should be a type of "policy".
And what is the reasoning behind this? In the context of Web negotiation for a particular data exchange, I think it does make absolute sense to use a policy. We are using it in our implementation and other implementations are doing it as well, e.g., International Data Spaces Association, Gaia-X, Fiware, ...
Moreover, when entering into the realm of personal data spaces, this will absolutely be needed. I will further comment on this later on.
Therefore, for the sole purpose of representing a request to the ODRL Evaluator, it is proposed to adopt the openId style.
I understand why, for simple use-cases, people would want to go in this direction, although I have objections:
- It's not RDF based, even though you can transform it in JSON-LD, but then wouldn't this mean looser semantics when we are moving towards having a formal semantics ?
- Context information should already modelled in the state of the world and I also believe should be modelled using standardized RDF vocabularies
- Reducing requests to (subject, resource,action) is too reductive and will have a huge impact on ecosystems that are regulated, e.g., personal data-based ecosystems. In this cases, a request should always contain a purpose, a legal basis and possibly more. Even for non-personal data, for example in cases regulated by the Data Act, a purpose is a must. So, I firmly believe that we should use a solution to represent requests that allows us to represent simple and complex use cases.
odrl:Examination odrl:Inquiry odrl:Solicitation
What are the semantics of these policies and how do they differ from an odrl:Request ?
odrl:Request has the following definition "A Policy that proposes a Rule over an Asset from an assignee."
Since this is not the definition of a class for evaluation/testing/etc, it looks like we need something that reflects "a request without using the word request" ... and in English this are probably the 3 closest matches.
I can't comment on the use cases for IDS/Gaia/Fiware - if they are using odrl:Request as the definition, then it is a good use, if they are using it for other purposes then (a) they can't do policy negotiation and (b) they are non-compliant with the definitions and not interoperable.
On your objections:
- The idea is to work backwards (the reasoning being interoperability with other standards rather than implement from scratch) from JSON to RDF, authZen and RFC 9396 are extensible by default. In practice, JSON is the lingua franca of API exchanges.
- Context in the example above is for demonstration purposes, it can be represented in RDF, etc, etc.
- That is the baseline, it is not the end, just like an odrl:Policy specifies the minimum amount of attributes and names, this is promoting that same principle, you can build complex requests:
{
"subject": {
"id": "http://example.com/party/1",
"other": "http://example.com/attribute/1"
"more": {
"another": "http://example.com/another"
},
},
"my other component specific to my implementation": {
},
}
Not sure where the RDF argument comes from as all examples in the pages are in JSON, as you can also see there are 4 components - just a Quad with property names that are compatible with other standards.
During our meeting on December regarding Formal Semantics. We discussed that the policy negotiation (i.e: two or more parties willing to create a contract) is out of scope of the formal semantics document. This really restricts the possibilities for the use cases, such as the one you described @besteves4, which usually depend on either legally binding contracts, or observability/monitoring.
That's why in my humble opinion, there should be (at least) 2 possible roles for the Evaluator and for each, different possible inputs:
- An atomic "simple" access on a resource that is usually repeated, automated and needs to be fast, such as a call to an API: in this case, something with AuthZen seems more fitting
- A more complicated request to establish a contract either expicitly or at least provide a more complete context (purpose, actors), such as the usual cookies popup from a website, or a data exchange between 2 legal entities: in this case a Request policy is more fitting, especially for regulated industries or sensitive personal data.
Practically speaking, the requirements (like response time or users) would be different for these 2 cases. Therefore, it's unlikely that an Evaluator would handle both.
According to the definition,odrl:Request sits somewhere in the space of "contract or agreement negotiations" (you offer X, but I request also Y), which sits significantly earlier in any supply chain process: it is likely that an odrl:Offer interacting with a Party proposing an odrl:Request will generate a different odrl:Agreement (and maybe a new odrl:Offer).
Also, it is good to align semantics in this conversation: purpose implies a transitivity in the verb to attain an object, action also implies transitivity in a verb, hence why you already have the triples <actor, action, asset> (and context in a practical sense), otherwise you could express rules with constructs like <actor, action> or <action, asset> (intransitivity appears to work in duties but only because one of the triples is implicit, e.g. "assignee payAmount", but there is an implicit linked to the asset unless you use odrl:rightOperandReference and now it doesn't look intransitive).
purpose - have as one's intention or objective. action - a thing done; an act.