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
Within Catena-X we have the requirement to support the specification of a (probably non-enforceable) custom usage condition (specific to the ecosystem and independent of ODRL) as a free text string (e.g., english text paragraph). This generic constraint is intended to be used whenever the left operands (i.e., enums specified by the IDSA) are not suitable to express the terms imposed by the data provider.
One obvious approach could be the specification of a USE action, having a constraint, which in turn consists of a custom left operand, an STRING_EQ or DEFINES_AS as operator, and a string as right operand. However, this option is not supported by the Information Model.
Based on the current implementation of the IDS Information Model (regardless of connector implementation), the following fallback alternatives were identified:
Contract object referencing an ids:contractDocument (TextResource), which represents the equivalent human-readable encoding of the machine-interpretable contract. This approach is not suitable for the project requirements, as the referenced document content is not embedded in the contract (agreement) and can, therefore, be regarded as mutable.
A semantically less expressive approach could be attaching the free text paragraph as comment to the action object. This approach needs to be tested and might require an enhancement of connector.
Is there another alternative? Which alternative would be feasible and semantically correct.
Regards
Alexandru
The text was updated successfully, but these errors were encountered:
Hi Alexandru,
thanks for raising this issue. Actually, rather than an issue (i.e., bug report or feature request), this is a discussion item. It would therefore also have been suitable for the discussion forum.
This generic constraint is intended to be used whenever the left operands (i.e., enums specified by the IDSA) are not suitable to express the terms imposed by the data provider.
No one stops you from defining additional operands specific to your ecosystem, or even specific to individual use cases or even providers. At least not when you work with the Information Model on the RDF level.
Things may be different when you use the Java library generated from the Information Model. But you don't do that, do you?
One obvious approach could be the specification of a USE action, having a constraint, which in turn consists of a custom left operand, an STRING_EQ or DEFINES_AS as operator, and a string as right operand. However, this option is not supported by the Information Model.
Could you please clarify in what sense this is not supported by the Information Model? Did you try it, and then the validation against the SHACL shapes failed? Or did you encounter a Java issue? (See above.)
A semantically less expressive approach could be attaching the free text paragraph as comment to the action object. This approach needs to be tested and might require an enhancement of connector.
Attaching an arbitrary non-IDS comment property (e.g., rdfs:comment) is always possible from the RDF perspective. Adding such additional properties should even be possible with the Java library.
Hi,
Within Catena-X we have the requirement to support the specification of a (probably non-enforceable) custom usage condition (specific to the ecosystem and independent of ODRL) as a free text string (e.g., english text paragraph). This generic constraint is intended to be used whenever the left operands (i.e., enums specified by the IDSA) are not suitable to express the terms imposed by the data provider.
One obvious approach could be the specification of a USE action, having a constraint, which in turn consists of a custom left operand, an STRING_EQ or DEFINES_AS as operator, and a string as right operand. However, this option is not supported by the Information Model.
Based on the current implementation of the IDS Information Model (regardless of connector implementation), the following fallback alternatives were identified:
Is there another alternative? Which alternative would be feasible and semantically correct.
Regards
Alexandru
The text was updated successfully, but these errors were encountered: