mathiasrichter / shapiro Goto Github PK

see https://github.com/mathiasrichter/shapiro/blob/main/test/ontologies/com/example/org/duplicate_constraint_sample_jsonschema.ttl

Enums just don't work!

Currently the JSON SCHEMA rendering ignores rdfs:subPropertyOf declarations (ie. does not bind constraints of the super-property of a triple <sub-property, rdfs:subPropertyOf, super-property> to the sub-property).

There's issues with relative file references if Shapiro is not started from within the Shapiro directory.

When the shacl:in constraint for an enum is defined on the rdfs:property rather than in the nodeshape , HTML rendering does not work properly.

Scalar properties appear twice in nodeshapes when rendering the full model.

The example model for multiple conflicting nodeshapes and inheritance still displays the NodeShapes and the OWL ontology as data instances. While it is generally true, we don't want to see those necessarily...

HTML rendering always shows "n/a" because the shacl properties are represented by blank nodes in the graph. Need to change this to consider rdfs:label if the rdfs:label is declared on the shacl property.

Need to use lifecycle event handlers. https://fastapi.tiangolo.com/advanced/events/

If we add custom values describing things like lineage or data ownership for a class, a property or any other model element, this information is ignored in the HTML rendering.

Need to amend the rendering to consider such custom values.

The functions for resolving the request for a schema directly reference global vars (CONTENT_DIR, SUPPORTED_SUFFIXES, etc.). Need to remove these reference by providing these inputs in the function signature.

Once done, it should be easy to refactor the collection of functions in the current implementation into a small set of classes.

Models can contain actual instance data (e.g. a model defines a currency class and a closed list of instances to reflect the collection of accept currencies).

Sometimes, the list of instances can become quite large. The fact that Shapiro parse the serialized model from a file in the file system every time a model or a model element is requested, can negatively impact performance.

Need to think about a way to cache the graphs for larger models in memory to increase response time...

in practice, people better understand models if there is some notion of a UML-style class diagram. For practical examples, see the documentation for standard ontologies like DCAT, Time or Organization. They all comprise UML-style diagrams as overview of the model.

Need to amend the HMTL rendering to include such class diagrams.

Add support for converting the nodeshapes defined in a model into JSON-schema so models/model elements can directly be referenced in OpenAPI/Swagger definitions without breaking the OpenAPI tooling.

Currently, the JSON-SCHEMA renderer of Shapiro does not properly consider inheritance (as per RDFS reasoning).

This means in essence that Shapiro needs to traverse the inheritance hierarchy of the shacl:targetClass and include all NodeShapes with their SHACL property definitions.