Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Schema/model mapping solution #35

Open
rob-metalinkage opened this issue Jul 10, 2024 · 0 comments
Open

Schema/model mapping solution #35

rob-metalinkage opened this issue Jul 10, 2024 · 0 comments
Assignees

Comments

@rob-metalinkage
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants