You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For improving the usability of management API we should draft a JSON-LD context for the management API that will be used in ingress/egress for all the requests/responses (catalog response excluded).
Currently we did improved the "usability" of JSON-LD (removing the need of prefixed properties) by using the @vocab in ingress and egress bound to the edc namespace (https://w3id.org/edc/v0.0.1/ns/). That works for removing the all edc relevant properties (even custom one) but it has some limitations.
For example if we want to enforce at JSON-LD level that a property should be an @id or that @container of the property is always a @set, that is not possible only with @vocab.
Also at the current state when dealing with the odrl policies we can use the odrl context in ingress but when reading out the policy definition the odrl policy contains always odrl prefixes.
Which Areas Would Be Affected?
management api
Why Is the Feature Desired?
dev experience
Are there any requirements?
Solution Proposal
Draft an experimental JSON-LD context of management api in a separated experimental extension that will register a new context url and cached file for the edc management api.
The text was updated successfully, but these errors were encountered:
Feature Request
For improving the usability of management API we should draft a JSON-LD context for the management API that will be used in ingress/egress for all the requests/responses (catalog response excluded).
Currently we did improved the "usability" of JSON-LD (removing the need of prefixed properties) by using the
@vocab
in ingress and egress bound to theedc
namespace (https://w3id.org/edc/v0.0.1/ns/
). That works for removing the all edc relevant properties (even custom one) but it has some limitations.For example if we want to enforce at JSON-LD level that a property should be an
@id
or that@container
of the property is always a@set
, that is not possible only with@vocab
.Also at the current state when dealing with the
odrl
policies we can use theodrl
context in ingress but when reading out the policy definition theodrl
policy contains alwaysodrl
prefixes.Which Areas Would Be Affected?
management api
Why Is the Feature Desired?
dev experience
Are there any requirements?
Solution Proposal
Draft an experimental JSON-LD context of management api in a separated experimental extension that will register a new context url and cached file for the edc management api.
The text was updated successfully, but these errors were encountered: