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
It is not possible to directly uplift many JSON schema constructs directly to a target model - GeoJSON geometry to GeoSPARQL being a classic example.
Accordingly the mapping to a target model has to be a two (or three) step process of (pre-process) - uplift - entail target.
Leaving aside pre-process for now, SHACL validation rules should be inherited from target models - and apply the final entailed version if an entailment is specified.
Should >1 entailment be considered? For now dependency driven rules suggests only the set of targets in the model heirarchy matter.
Possibly multiple transforms could be defined - but each would need to be bound to a separate model to inherit all tests. It may be better to have examples from the model point to the transform outputs - thus each model would know how to handle tranformation outputs, not the schema BB itself. This may lead to circular dependencies however - unless each BB could visit the validators for a target model.
In summary - the proposed initial task is support a post-uplift entailment step and defer SHACL validation to the output of this step if present.
The text was updated successfully, but these errors were encountered:
It is not possible to directly uplift many JSON schema constructs directly to a target model - GeoJSON geometry to GeoSPARQL being a classic example.
Accordingly the mapping to a target model has to be a two (or three) step process of (pre-process) - uplift - entail target.
Leaving aside pre-process for now, SHACL validation rules should be inherited from target models - and apply the final entailed version if an entailment is specified.
Should >1 entailment be considered? For now dependency driven rules suggests only the set of targets in the model heirarchy matter.
Possibly multiple transforms could be defined - but each would need to be bound to a separate model to inherit all tests. It may be better to have examples from the model point to the transform outputs - thus each model would know how to handle tranformation outputs, not the schema BB itself. This may lead to circular dependencies however - unless each BB could visit the validators for a target model.
In summary - the proposed initial task is support a post-uplift entailment step and defer SHACL validation to the output of this step if present.
The text was updated successfully, but these errors were encountered: