Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ODRL service/implementation #67

Open
AndreaCimminoArriaga opened this issue Oct 22, 2024 · 5 comments
Open

ODRL service/implementation #67

AndreaCimminoArriaga opened this issue Oct 22, 2024 · 5 comments

Comments

@AndreaCimminoArriaga
Copy link

AndreaCimminoArriaga commented Oct 22, 2024

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.

@joshcornejo
Copy link
Collaborator

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.

@AndreaCimminoArriaga
Copy link
Author

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.

@joshcornejo
Copy link
Collaborator

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
Copy link
Collaborator

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

@AndreaCimminoArriaga
Copy link
Author

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants