opengeospatial / opengeospatial/bblocks-postprocess

Schema/model mapping solution

Open
#35 1 comment 0 reactions 1 assignee View on GitHub

@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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.