odrl icon indicating copy to clipboard operation
odrl copied to clipboard

ODRL service/implementation

Open AndreaCimminoArriaga opened this issue 1 year ago • 5 comments

In the document formal semantics, there is the following paragraph

```By using a machine-readable language to represent policies, ODRL implementations can provide useful functionalities such as those of a policy search engine, a policy compatibility checker, an access control system, a monitoring system, or a policy planning system, among others.````

It denotes that there is an ODRL implementation that can perform endless number of operations (among those, it should be the evaluation). It could be a good idea to propose a standardized ODRL service/directory and list the capabilities it may have and their interface (HTTP?) taking the use cases as input. For instance, should ODRL service allow SPARQL queries and enable always an endpoint to this end? should exist an MQTT ODRL service and another for HTTP? etc. Note that defining how this service should behave and work is related also on the way policies can be evaluated.

AndreaCimminoArriaga avatar Oct 22 '24 10:10 AndreaCimminoArriaga

Yes, I have this view in the long term. I have API endpoint that produce JSON-LD or TTL, those should (at some point) resolve to any "over the public" internet taxonomy/ontology and resolve things like specificParty:SpecificAsset or specificParty:SpecificPolicy (specific being a prefix with a URI and an engine to generate appropriately).

In my vision, it can serve as a distributed marketplace "backend" (SPARQL will never be widespread).

But IMHO that's a future requirement for when there is adoption/traction and sufficient elements to see the functionality required.

joshcornejo avatar Oct 22 '24 11:10 joshcornejo

I agree, having an API specification (if this goes in that direction, maybe MQTT as well?) will help the adoption. I think SPARQL will help to unlock new distributed scenarios that are not even on the table right now, let's see....

I think this should go in parallel with the adoption, if no API is provided how people is going to adopt it? providing the specification of what must be implement (not how) will ease people adoption and foster new implementations since it narrows down been compliant with ODRL to just implement a set of operations.

AndreaCimminoArriaga avatar Oct 22 '24 12:10 AndreaCimminoArriaga

From what Joaquin mentioned during a call with him a couple of weeks ago - and aligned with what I think - first comes "how will people with 'content' expertise build & manage policies - this happens months or years before you can start enforcing them - and then you can think of distributed scenarios 👯

joshcornejo avatar Oct 22 '24 12:10 joshcornejo

BTW - MQTT is for Telemetry, I would think AMQP suits better?

joshcornejo avatar Oct 22 '24 12:10 joshcornejo

Well, in the last meetings we are discussing a lot on the enforcement and several implementations exist. We are not that far I think. About MQTT, yes, just citing a standard AMQP is better. In any case, use cases will tell which users need (probably new protocols will appear)

AndreaCimminoArriaga avatar Oct 22 '24 12:10 AndreaCimminoArriaga