Automatic generation of user interfaces from SHACL https://shacl-vue.psychoinformatics.de/
  • Vue 74.1%
  • JavaScript 24.4%
  • Python 1.1%
  • Shell 0.3%
Find a file
Stephan Heunis 3c091c324f New wizard editor component
This feature allows custom form dialog construction via config, as well as TTL template
specification, which is then string-serialized using the user inputs upon form save, followed
by adding the parsed quads to the graph store. This is a powerful feature that allows
arbitrarily complex user input and metadata linkage via relatively simple primitive form
input configuration. These wizard editors can be configured to appear for any class.
These are the working principles:

- a new wizard is declared and configured via the new 'wizard_editors' option, which allows
  several standard options along with the important: an array of 'inputs' and the 'template'
- 'inputs' have to specify the 'type', among other rendering options; currently supported
  'type's include 'text', 'text-paragraph', and 'boolean'. The plan is to extend these
  substantially, possibly driven by LinkML types provided by a specific schema, but also
  allowing already supported 'shacl-vue' editors. Each 'input' configures the associated
  input component in the wizard form, and they will render in the order provided via
  configuration.
- 'input's also have to specify a unique 'prop', which becomes the field name through which
  this input is referenced, both in 'shacl-vue' internals and inside the TTL template.
- the 'template' should be a TTL string, with to-be-populated field names inside
  'curly brackets'. Field names include all 'prop's configured for 'input's, as well as
  'pid', which refers to the identifty of the current record being edited and from which
  the wizard is launched. TTL can either be supplied directly as a string, or as a URL via
  the existing 'content' option.
- declared wizards are configured for rendering for specific classes via the new option
  'wizard_editor_selection'.
- wizards can be supplied with icons via configuration; these can come in different formats:
  - an 'mdi-' string which will render any of the standard free 'mdi' icons
  - an svg string, which will be rendered as is
  - a 'content:' pointer to an SVG file, which will be loaded and rendered as is
  Importantly, any SVG used in this context should have a viewport or width/height of 24x24 px

This commit includes a documentation update that covers all details related to the wizard
editor feature, extensively.

To achieve the above, the following major code changes were done:
- The 'NodeShapeEditor', which renders for a given record when it is being created or edited
  inside the 'FormEditor', will check the 'wizard_editor_selection' to see if any wizards need
  to be made available for the current record type (a.k.a. class). If yes, it will render those
  as buttons at the top of the form below the 'All fields' button. The wizards render as clickable
  buttons, with customizable tooltips and icons, which will open a dialog when clicked, passing
  along all config options related to the selected wizard
- The new 'WizardEditor' will render inside the dialog. It will display all general config
  options of the wizard, and will then render a row per input. Inputs have their own descriptions
  and validation rules embedded (taken from config). Reset and Cancel buttons are self-explanatory.
  The save button will run validation on all inputs, and on successful validation will emit a 'save'
  event to the parent component ('NodeShapeEditor'), also passing along all entered input values.
- On detecting a 'save' event from a wizard, the 'NodeShapeEditor' will:
   - receive the input values and declare them as 'wizardData'
   - add the node ID of the current record to the 'wizardData' under the 'pid' field, which is how
     the record can be referenced inside the TTL template
   - pass 'wizardData' to the existing 'fillStringTemplate' utility function to render valid TTL
     output
   - pass the TTL to 'rdfDS.parseTTLandDedup(newTTL)' that outputs quads and adds them to the graph
     store
- 'rdfDS.parseTTLandDedup(newTTL)' returns all the quads that were parsed and added to the graph
  store. These are now process individually. Importantly, if an added quad has a subject value that
  is identical
  to the current node ID, we delete it from the graph store, because it uses a nonsense named node
  (the node ID of the record, which is not reproducibly identical to the record PID). However, we
  also add the quad's object to the 'formData' under the index of the current node and the quad's
  predicate, in order to keep linkage to the TTL-parsed quads. Importantly, the existing standard
  functionality that runs when saving a form (for record creation or editing) will then take care
  of adding the correct quads to the graph store to replace those that were deleted.
- Continuing with the individual processing of quads that were parsed from TTL and added to the graph
  store, if an added quad has a subject value that is NOT identical to the current node ID, AND it
  is a named node, this means that a new record has been added to the graph store and it is therefore
  eligible for submission. This is added to 'savedNodes' and 'nodesToSubmit', as well as a separate
  'NodeShapeEditor'-specific tracker of all wizard-added quads.
- Garbage cleanup is also necessary in the case where quads were added to the graph store by a wizard
  but the form was then subsequently cancelled. To deal with this, 'NodeShapeEditor' registers a form
  cancel handler via the existing 'registerHandler' functionality, which will delete all the relevant
  quads.

Lastly, for improved UI the headings of 'property groups' in the 'NodeShapeEditor' have been
removed. This is in anticipation of the complete removal of parent-class-based grouping of
properties inside the 'NodeShapeEditor'.
2026-02-04 18:40:17 +01:00
.forgejo/workflows correct directory paths for cp command 2026-01-15 21:39:56 +01:00
.github/workflows Add github action to codespell main on push and PRs 2025-02-24 14:30:02 -05:00
docs New wizard editor component 2026-02-04 18:40:17 +01:00
public Add update_shapes option to config template 2026-01-23 16:17:42 +01:00
src New wizard editor component 2026-02-04 18:40:17 +01:00
tests Reformat all files with prettier 2025-06-08 23:57:26 +02:00
tools Helpers for getting default schemas and data 2025-04-22 18:35:36 +02:00
.browserslistrc Basic scaffolding of vite-powered vuejs+vuetify project for rendering/viewing shacl shapes 2024-03-26 15:07:32 +01:00
.codespellrc Add rudimentary codespell config 2025-02-24 14:30:02 -05:00
.editorconfig Basic scaffolding of vite-powered vuejs+vuetify project for rendering/viewing shacl shapes 2024-03-26 15:07:32 +01:00
.gitignore First basic setup of docs using vitepress, includes updating github action to deploy docs to '/docs' location in web app 2024-09-05 14:32:34 +02:00
.npmignore update npmignore to deal with recent updates to build process 2025-02-28 23:30:09 +01:00
.prettierignore Add prettier, indentation set at 4 spaces, add npm script 2025-06-08 23:56:38 +02:00
.prettierrc Add prettier, indentation set at 4 spaces, add npm script 2025-06-08 23:56:38 +02:00
index.html Reformat all files with prettier 2025-06-08 23:57:26 +02:00
index.js Reformat all files with prettier 2025-06-08 23:57:26 +02:00
jsconfig.json Reformat all files with prettier 2025-06-08 23:57:26 +02:00
LICENSE Initial commit 2024-03-21 11:11:07 +01:00
package-lock.json Add new markdown editor components 2026-01-28 23:37:44 +01:00
package.json Add new markdown editor components 2026-01-28 23:37:44 +01:00
README.md Refer to new docs and dev repo links 2026-01-15 21:32:45 +01:00
vite.config.app.mjs Support including front page html 2025-09-02 18:27:46 +02:00
vite.config.lib.mjs Reformat all files with prettier 2025-06-08 23:57:26 +02:00

shacl-vue

THIS REPOSITORY IS UNDER CONTINUOUS DEVELOPMENT

Overview

shacl-vue is a web-based user interface for entering, editing, and viewing linked (meta)data using a VueJS application driven by the Shapes Constraint Language (SHACL).

Think of it as an automatic builder that you just have to feed with a model of your data. If you have a SHACL schema, or a schema in a format that can be exported to SHACL, then you're good to go. No need to build custom forms for data entry, no need to struggle with post-entry data validation, no need to create a catalog application that renders all the entered data. shacl-vue does all of this automatically.

shacl-vue is built with VueJS 3, Vuetify frontend components, and Vite build tools, and was heavily inspired by the WC3 Draft: Form Generation using SHACL and DASH. For reading, manipulating, and writing RDF data (including SHACL), the package uses libraries compatible with the RDF/JS specifications (see also: https://github.com/rdfjs-base)

Installation and usage

shacl-vue can be installed from npm:

npm install shacl-vue

Use as a library

The npm package currently provides the named export ShaclVue:

import { ShaclVue } from 'shacl-vue'

This is the main configurable VueJS component that is used to render all functionality of shacl-vue. It can be instantiated inside a VueJS application as follows:

<template>
    <ShaclVue :configUrl="myconfig"></ShaclVue>
</template>
<script setup>
const myconfig = 'config.json';
</script>

Here, config.json is used to configure the properties of the specific shacl-vue deployment. See examples here, and here.

For the above to work, the VueJS application will have to install Vuetify and the ShaclVue might need to be registered explicitly.

Use as a standalone site

The build steps of shacl-vue produce both the library as well as a set of static files that can be served as a standalone site. The abovementioned metadata annotation tool of the TRR379 Research Consortium deploys shacl-vue in this manner, and its source code can be viewed here.

To use shacl-vue to deploy a standalone site, follow the build steps below. In addition, a deployment-specific confi file should be provided.

Local development and building

The shacl-vue source code can be cloned for local development, testing, or building. First clone the repository:

git clone https://hub.psychoinformatics.de/datalink/shacl-vue.git
cd shacl-vue

Then create a local NodeJS virtual environment, e.g with micromamba:

micromamba create -n <my-env-name> nodejs
micromamba activate <my-env-name>

Then install the application:

npm install .

Local rendering during development

To serve the application locally in order to test it in the browser, run:

npm run dev

Build steps

To build the library (output at /dist/lib):

npm run build:lib

To build the standalone site, i.e. VueJS application (output at /dist/app):

npm run build:app

To build both the library and the standalone site:

npm run build

Testing

Testing remains a primary TODO for this package, although a minimal test is in place to check whether the named exports can be imported into a new project. Testing is done with Vitest.

npm run test

Dependency on shacl-tulip

In an effort to generalize shacl-vue for improved use by and interoperability with other applications, the underlying functionality was factored out and packaged as the shacl-tulip library (like "shacl-vue-lib"). shacl-tulip provides the main (derived) classes for handling RDF data and related form data. It is completely independent of VueJS, yet class constructors allow passing reactive objects as arguments, which shacl-tulip handles seamlessly. It also focuses purely on library-level functionality (including utilities that were previously part of shacl-vue), and contains no frontend code. shacl-vue imports shacl-tulip classes and uses them mainly in its composable code.

Access to external webservices

Unless configured to connect to specific API endpoints (see Service API integration docs), a client accessing a bundled shacl-vue deployment does not load any external resources. All required resources are loaded from the server where the bundled application is hosted.

Acknowledgements

This work was funded, in part, by

  • Deutsche Forschungsgemeinschaft (DFG, German Research Foundation) under grant TRR 379 (546006540, Q02 project)
  • Deutsche Forschungsgemeinschaft (DFG, German Research Foundation) under grant SFB 1451 (431549029, INF project)
  • MKW-NRW: Ministerium für Kultur und Wissenschaft des Landes Nordrhein-Westfalen under the Kooperationsplattformen 2022 program, grant number: KP22-106A