opengeospatial / opengeospatial/bblocks-postprocess
Schema/model mapping solution
@avillar is already working on this.
Since Jul 10, 2024.
- Dominant language
- Python
- Stars
- 1
- Forks
- 6
- Avg merge
- 5d 10h
- Merged PRs (30d)
- 3
Description
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.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.