How/where to author the structure of a viewer / editor

[jsheunis]

With work being done on https://github.com/psychoinformatics-de/shacl-vue/issues/11, it's becoming clearer (to me) that a mechanism is necessary for providing structure to the rendering of a viewer or editor of metadata, such that users will find it intuitive to interact with. So far, the use of SHACL's PropertyGroups and sh:order (on the level of property groups, and on the level of properties themselves, whether they are associated with a group or not) has proved to be a practical way to achieve such intuitive structure. See for example this screenshot of a local prototype:

Properties of a Distribution are grouped into topical categories (Basic, Data, Parts, Provenance, etc) which are ordered, and in turn specific Distribution properties are associated with these categories and ordered within categories. This already provides more structure than a flat list of unordered Distribution properties.

The question is, though, where and how should this structure be provided?

In the example, the relevant PropertyGroups and their linkage (via sh:group) to specific property shapes have been injected into the turtle file that contains all SHACL node shapes for the LinkML authored Distribution schema, exported using gen-shacl. But this doesn't seem like a portable way to author a form structure.

Some thoughts:

• could this all be done via LinkML? i.e. creating a class to represent a PropertyGroup and then a slot annotation representing sh:group that is added for each slot that one wants to add to a specific group? I haven't thought this through well enough...
• If the first point is possible, it becomes even more important to add a patch to LinkML code that allows annotations (and any other missing yet important info) to flow through to the resulting SHACL (ping https://github.com/psychoinformatics-de/shacl-vue/issues/9).
• It seems sensible to account for the case where different implementers/providers might want to give a different structure to a viewer/editor generated from the same schema. This would mean authoring different property groups associated with different properties. So it would make sense in such scenarios to separate the structure provisioning completely from the schema itself. How would/could this be done? Also in LinkML, by creating a new schema that subclasses from the original one? I can't think of any immediate alternatives...
• Remember that a specific schema (e.g. Distribution) will have properties and relationships to other classes that are imported into said schema, and also exported to e.g. SHACL. Therefore a form based on e.g. the Distribution schema will necessarily also be a form for imported classes, e.g. a Resource or an Entity. It would be suboptimal if structure were only provided to the root-level schema, and not to others. OTOH, this would imply a lot of work to provide structure to all classes that are imported into and referenced by a specific schema and therefore present in a SHACL export.

[jsheunis]

could this all be done via LinkML? i.e. creating a class to represent a PropertyGroup and then a slot annotation representing sh:group that is added for each slot that one wants to add to a specific group? I haven't thought this through well enough...

In its current state, shaclgen.py exports a ttl file with only sh:nodeShapes and associated sh:propertyShapes. It would not currently be able to export sh:PropertyGroups. It would be possible to change the code to do that, e.g. also include a list of sh:PropertyGroups from some source (tbd if that would also be linkml schemas or a sidecar ttl file for example).

Note: I am not sure whether this would be a general enough feature for a merge into upstream. It pertains mainly (only?) to schemas that are used to generate user interfaces, and would have no benefit (that I can think of) for validation e.g..

[jsheunis]

An idea could be to have a separate LinkML schema for the property groups. Then someone authoring a schema for the auto-generation of a UI should also provide a yaml data file with the property groups. A wrapping script, e.g. gen-shacl-ui could be called with arguments:

• main schema for generating shacl for a UI
• the property group data file

which will then:

• run LinkML's gen-shacl on the main schema
• run linkml-validate on the property shape data, using the new schema
• run linkml-convert on the property shape data to get it into rdf
• inject the rdf into the shacl exported from the main schema
• export a single ttl file