Improved Usability of SHACL Play diagrams.

[psiotwo]

Thanks for SHACL Play, it is a useful tool! This is more a question/teasing comment - and maybe you will find some of the following out of scope for SHACL Play, or find that solutions for this already exist (just could not find them):

While SHACL is meant for validation it is reused as a data schema definition language. For example, some node shapes are purely technical and don't deserve to appear in the graph depiction if they increase its complexity (a complicated graph is of no use). Also, as the SHACL data model tries to pose constraints on the RDF vocabulary it would be more useful to visualize the datamodel in terms of their sh:targetClasses/sh:paths, rather than the shape themselves,

Here are a few points to things that would heavily improve the readability of the generated diagram:

• allow filtering out some nodes (being too technical)
• allow switching between edge/field view for a property (e.g. ... sh:class skos:Concept)
• allow configuring whether to visualize the shapes themselves, or their targetClasses

Thanks for reading!

[tfrancart]

Thank you for your constructive comments.

allow filtering out some nodes (being too technical)

I think this could be misleading and I don't think this is the role of the diagram generator. If you want to "tell a story about your model" with the diagrams, then you need to design the diagram(s) yourself. The best SHACL Play can do is to split large diagrams into smaller ones with foaf:depiction : https://shacl-play.sparna.fr/play/draw#custom-nodeShapes. Actually, even with a single disgram, this way you can select which shapes you want to have in your diagram.

allow switching between edge/field view for a property (e.g. ... sh:class skos:Concept)

I would definitely consider this. Actually we already do that in some situations: https://shacl-play.sparna.fr/play/draw#simplification So adding an extra annotation on property shapes to control this, and/or relying on sh:class skos:Concept would make sense. Any suggestion on the annotation to use ?

allow configuring whether to visualize the shapes themselves, or their targetClasses

I actually had the same thinking a few weeks ago, and actually implemented this, but then rollback. In some situations I found multiple node shapes targeting the same class, so displaying the class instead of the shape didn't make any sense. But adding an option to control this behavior would probably be the way to go.