Testing `shacl-vue` as a schema editor #6

New issue

Open

opened 2024-10-10 13:30:52 +00:00 by jsheunis · 0 comments

jsheunis commented

2024-10-10 13:30:52 +00:00

(Migrated from hub.datalad.org)

Since shacl-vue works from arbitrary shacl, and since the LinkML language itself is modeled in linkml (see https://github.com/linkml/linkml-model/blob/main/linkml_model/model/schema/meta.yaml, and the shacl export of that schema: https://github.com/linkml/linkml-model/blob/main/linkml_model/shacl/meta.shacl.ttl), it follows that shacl-vue can be used to generate forms from the shacl schema of linkml. This in turn means that the resulting forms can be used to generate/author a Linkml schema.

The goal here is to test this out and document the results of the process.

Some initial notes:

the latest shacl export is from Feb 2024, and gen-shacl has seen several updates since then, so it would be good to test the export with the latest export code.
Trying gen-shacl (from linkml v1.8.4) on the main meta schema (here) gives an error that needs to be investigated:

>> gen-shacl linkml_model/model/schema/meta.yaml > schema_shacl.ttl

ValueError: The ifabsent value `default_range` of the `range` slot could not be processed

Using the existing latest shacl export of the meta schema, as well as using our custom code/gen_owl_minimal.py script on the meta YAML schema, gives sufficient input for shacl-vue to use.
The initial launch of shacl-vue with this input takes substantially longer than any test cases up to this point. It loads about 5k lines of TTL. But everything loads and the forms, a.k.a. schemas, can be selected and edited.
Many fields (i.e. property shapes) do not match with any available editors because these property shapes have minimal content. Many specifically do not contain sh:datatype nor sh:NodeKind, which means there is not enough information in the property shape to match with any editor. I hope this is an insufficiency of the older version of the shaclgen code that has since been improved. Even if it gets updated, though, I think it probably still makes sense to have a default rendering component, e.g. a free text field, that gets matched if nothing else matches, and then to see the entered content as a literal node with datatype string.

Since `shacl-vue` works from arbitrary shacl, and since the LinkML language itself is modeled in linkml (see https://github.com/linkml/linkml-model/blob/main/linkml_model/model/schema/meta.yaml, and the shacl export of that schema: https://github.com/linkml/linkml-model/blob/main/linkml_model/shacl/meta.shacl.ttl), it follows that shacl-vue can be used to generate forms from the shacl schema of linkml. This in turn means that the resulting forms can be used to generate/author a Linkml schema. The goal here is to test this out and document the results of the process. Some initial notes: - the [latest shacl export](https://github.com/linkml/linkml-model/commit/ea6a2a0230d705379cd6406ad1434da58976a15c) is from Feb 2024, and `gen-shacl` has seen several updates since then, so it would be good to test the export with the latest export code. - Trying `gen-shacl` (from linkml `v1.8.4`) on the main meta schema ([here](https://github.com/linkml/linkml-model/blob/main/linkml_model/model/schema/meta.yaml)) gives an error that needs to be investigated: ``` >> gen-shacl linkml_model/model/schema/meta.yaml > schema_shacl.ttl ValueError: The ifabsent value `default_range` of the `range` slot could not be processed ``` - Using the existing latest shacl export of the meta schema, as well as using our custom `code/gen_owl_minimal.py` script on the meta YAML schema, gives sufficient input for shacl-vue to use. - The initial launch of shacl-vue with this input takes substantially longer than any test cases up to this point. It loads about 5k lines of TTL. But everything loads and the forms, a.k.a. schemas, can be selected and edited. - Many fields (i.e. property shapes) do not match with any available editors because these property shapes have minimal content. Many specifically do not contain `sh:datatype` nor `sh:NodeKind`, which means there is not enough information in the property shape to match with any editor. I hope this is an insufficiency of the older version of the shaclgen code that has since been improved. Even if it gets updated, though, I think it probably still makes sense to have a default rendering component, e.g. a free text field, that gets matched if nothing else matches, and then to see the entered content as a literal node with datatype string.