Support for language tags in literal values

[MiltosD]

We have been exploring the use of the ECD connector for the data space we are developing, and in our trials we noticed that the data transformation from json-ld to the internal data structure before saving to the relational database, does not handle properly language tags in literal values. Specifically, it ignores them completely. For example, we tried the following sample in asset { "dcterms:description": [{ "@language": "en", "@value": "my description" }] } and the resulted column in db was just ["my description"]. By looking into the code, we believe the problem lies in line 48 org.eclipse.edc.jsonld.transformer.to.JsonValueToGenericTypeTransformer#transform (link :: https://github.com/eclipse-edc/Connector/blob/main/core/common/transform-core/src/main/java/org/eclipse/edc/core/transform/transformer/to/JsonValueToGenericTypeTransformer.java#L48 ) and how literal values are handled. Is there any plans within the EDC connector to properly handle literal values with language tatags? If yes, when should we expect such release? PS. Note we performed the test with version 0.1.0, but the above mentioned line has not changed in the recent releases.

[jimmarino]

This is probably not something we will support given the complexity it would introduce into the runtime.

[MiltosD]

Wish you would. However, is there something you would suggest for us to do in order to facilitate this functionality which is crucial for our case?

[jimmarino]

Use separate properties with a naming convention, e.g., foo_en, foo_it, or property values with a lookup table.

[arnoweiss]

I was looking for a design decision on why there isn't a triplestore in the backend to begin with. Didn't find anything - does anyone have context on this?

[jimmarino]

While Decision Records can be used to convey why a particular technology was not selected, this is not practical in most cases, particularly for niche technologies such as triplestores.

If someone wants to use a triplestore, they can use one by implementing the store runtime extension points.

Similar to the DSP protocols, EDC's goal is not to be a runtime that is aware of semantic processing models. We are using Json-Ld for one primary purpose: as a way to handle namespaces for data extensibility (e.g., the ability for users to add custom properties to data entities with name clashes).

Namespacing has the side-effect of allowing semantic models to be associated with data conveyed through the EDC runtime for people who want to do so. However, the EDC is explicitly not designed to be a semantic data processing engine.

[arnoweiss]

Thanks for the reply!