Replies: 1 comment
-
To emphasize: once the in-memory model is constructed from the SHACL graph, its API will be independent from SHACL. Once we've interpreted the SHACL, we're done with it. This provides nice decoupling. In particular it means the mapping will not be from SHACL to target schemas, but from our internal model to target schemas. This probably affects documentation as well. Think this through, since it entails mapping tables no longer showing how the SHACL semantics relate to those of the target schema. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Many more people would be able and willing to contribute if they didn't have to write Clojure code. It would be nice to devise an architecture that supports contributions in other languages. JVM language interoperability is an obvious path to explore, but compilers like GraalVM and architectural patterns such as microservices, or simple IPC provide a much wider range of options.
Basically, Metamorph behaves likes a pure function that takes a logical model as input, and returns a schema as output. These logical models could be modeled in all sorts of languages, serialized in many different ways as well. The same goes for the output schema.
In between is the heart of the application: the in-memory representation of the model, including API (querying, transformation, ...). This allows for decoupling on both sides, input and output. It serves as a contract that enables any contributor to write readers of specific logical model languages/serializations, in a way that Metamorph understands. The same holds for the output side.
Questions:
Beta Was this translation helpful? Give feedback.
All reactions