-
Notifications
You must be signed in to change notification settings - Fork 10
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
Comments
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 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. |
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. |
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 👯 |
BTW - MQTT is for Telemetry, I would think AMQP suits better? |
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) |
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.
The text was updated successfully, but these errors were encountered: