docs: decision record about dynamic JSON-LD context inference

[wolf4ood]

What this PR changes/adds

decision record about dynamic JSON-LD context inference

Why it does that

Briefly state why the change was necessary.

Further notes

List other areas of code that have changed but are not necessarily linked to the main feature. This could be method
signature changes, package declarations, bugs that were encountered and were fixed inline, etc.

Who will sponsor this feature?

Please @-mention the committer that will sponsor your feature.

Linked Issue(s)

Closes # <-- insert Issue number if one exists

Please be sure to take a look at the contributing guidelines and our etiquette for pull requests.

[ndr-brt]

It looks good generally speaking.

I was wondering if we're putting too much complexity in the json-ld service and if this feature could implemented somewhere else
e.g. could the custom context be set on the ParticipantContext, so that all its interactions on the Management API will use a particular context url, or maybe on the entities directly (the context url is saved along with the asset/policy definition data and used for compaction as well).

[wolf4ood]

Storing the @context in entities could be another approach, but that's a ton of work and it will make the entities/store to be json-ld aware. Having this in the json-ld service is the easiest way. We could also achieve this without additional configuration and inspecting the configured JSON-LD context and do the reverse mapping. It might be tricky but doable.

For the ParticipantContext not sure we need that for every participant. That would be more
a DataspaceContext configured with JSON-LD context and having an association between ParticipantContext and DataspaceContext for choosing which contexts to use in each dataspace context when compacting. But that means that we have to store for each entity which dataspace context they belong to

[ndr-brt]

For the ParticipantContext not sure we need that for every participant. That would be more a DataspaceContext configured with JSON-LD context and having an association between ParticipantContext and DataspaceContext for choosing which contexts to use in each dataspace context when compacting. But that means that we have to store for each entity which dataspace context they belong to

In fact we do have DataspaceProfileContext that represent this exact situation.
To me it makes total sense that when an entity is created, the dataspace (profile) is explicitly mentioned, the same way we're expecting the protocol (that's the legacy name, as it should be called profile) to be explicitly mentioned in the DSP request objects as ContractRequest and TransferRequest.

[ndr-brt]

EDIT: in that case it wouldn't be a "dataspace profile" because likely the same Assets and the Policies could be offered on different dataspaces, that's a ContractDefinition choice.
It's a sort of "semantic profile" that we're discussing here: as asset/policy is assigned to it and the related context is used for compaction when requested from the management api and added for catalog serialization.

It could look more complicated design-wise, but I think it will set stronger boundaries and avoid potentially ambiguous situations.

[wolf4ood]

EDIT: in that case it wouldn't be a "dataspace profile" because likely the same Assets and the Policies could be offered on different dataspaces, that's a ContractDefinition choice. It's a sort of "semantic profile" that we're discussing here: as asset/policy is assigned to it and the related context is used for compaction when requested from the management api and added for catalog serialization.

It could look more complicated design-wise, but I think it will set stronger boundaries and avoid potentially ambiguous situations.

Yeah that's why the offered assets and policy is a CD choices so we cannot assign profile or something to policies.
That's why having a dynamic JSON-LD context help here. Based on the "found" namespaces it construct a JSON-LD context which is consistent.

The semantic profile can be easily inferred on input when creating the asset or policies by the users using the right @context the issue is when giving that entity back. Which in this DR is automatically inferred by the entities namespaces found in properties.

The other approach would be storing that along with the entity or having a "semantic profile" in the management API
to associate manually

[ndr-brt]

Yeah that's why the offered assets and policy is a CD choices so we cannot assign profile or something to policies. That's why having a dynamic JSON-LD context help here. Based on the "found" namespaces it construct a JSON-LD context which is consistent.

The semantic profile can be easily inferred on input when creating the asset or policies by the users using the right @context the issue is when giving that entity back. Which in this DR is automatically inferred by the entities namespaces found in properties.

The other approach would be storing that along with the entity or having a "semantic profile" in the management API to associate manually

Maybe it's simple as it is: given that an ingested asset/policy can only be interpreted correctly with a specific context, it's necessary for the control-plane to store these contexts as well along with the entity, there's nothing wrong with it, as the entities will need that context in egestion phase.
Not by accident, there's an issue that reports this exact need for another entity: #5462

[wolf4ood]

That's probably the cleaner solution, but it will require major refactoring, on entities, store,
and in compaction/expansion strategy where we do that in the interceptor and controllers
only receive/return expanded objects. I could do a spike on this.

[wolf4ood]

I did a little spike on this. Storing the @context is doable but it's a bit work:

We'd have to change all the entities that can be customized by storing the @context at least

• Asset
• Policy Definition
• Contract Negotiation
• Contract Agreement

We'd have to change how we manage JSON-LD on those controller. I think we cannot use a generic interceptor that expand and compact but rather going back to managing within the single controller

On ingress we'd have to extract the @context, run the validation, expand it and transforming to Java entities associating the extracted context.

On Egress we'd have to load the entity/entities transform to JsonObject and then compact by calling a variant of JsonLd#compact which supports additional context likely in a List of Object/String to be passed in stored in the entity.

It's a major refactor but we can do it in step and only for new controllers v5 for example.

Let's discuss if we want to go with this solution

[wolf4ood]

I would put this on hold for now, Since it might require more work and investigation.
I have raise this that just extend the current compaction service to accept additional JSON-LD context, which we need anyway for both scenario mentioned here.
I will do more investigation on the EDC-V first then in case be back on the topic later