35 lines
No EOL
3.2 KiB
Markdown
35 lines
No EOL
3.2 KiB
Markdown
---
|
|
layout: doc
|
|
---
|
|
|
|
# App design
|
|
|
|
## The big picture
|
|
|
|
A pertinent goal of `shacl-vue` is to make scientific datasets interoperable with the wider ecosystem of linked and machine-actionable metadata, in other words: the semantic web. Linked data, [RDF](https://en.wikipedia.org/wiki/Resource_Description_Framework), ontologies, graphs, triples, semantic metadata, the list goes on. These terms might be ubiquitous in the world wide web, but are comparatively underexplored in the world of scientific data.
|
|
|
|
One linked-data tool, the Shapes Constraint Language (SHACL), provides a means to validate RDF graphs against a set of specified conditions. It is essentially a schema language for RDF data. By building a tool that can interpret and repurpose these conditions, you end up with an app that could render schema-based data entry forms, or data viewers, automatically. This is what `shacl-vue` aims to be. And also, free and open source, of course.
|
|
|
|
## The toolset
|
|
|
|
`shacl-vue` is programmed with [VueJS 3](https://vuejs.org/), and uses [Vuetify](https://vuetifyjs.com) UI components and [Vite](https://vitejs.dev/) for the build process.
|
|
|
|
Under the hood, `shacl-vue` uses libraries compatible with the [RDF/JS](https://rdf.js.org/) specifications for reading, manipulating, storing, and writing RDF data (including SHACL), in particular [N3.js](https://github.com/rdfjs/N3.js) and [`shacl-tulip`](https://github.com/psychoinformatics-de/shacl-tulip).
|
|
|
|
|
|
## The main concept
|
|
|
|
`shacl-vue` was heavily inspired by the WC3 Draft: [Form Generation using SHACL and DASH](https://datashapes.org/forms.html).
|
|
|
|
The idea is that if enough details are included in the node shapes and/or property shapes of a SHACL graph (as SHACL-native terms or as additional annotations), these details can feed the form generation process in order to create a user friendly data entry experience. Details like:
|
|
- in which order should fields be displayed in a form?
|
|
- can certain fields be grouped together physically in the form if they belong together thematically?
|
|
- what is the human-readable name of a field with an otherwise obscure identifier?
|
|
- does a field have a clarifying description that would help readers understand its importance or relevance?
|
|
- what type of data format does the field require the user to enter? a date, or a sentence, or a link to another resource?
|
|
- is there a minimum or maximum amount of values that a field can have?
|
|
|
|
With standard knowledge about such details in a SHACL graph, a knowledgeable application can act on this machine-readable information to create user-friendly interfaces rather than flat and uninterpretable forms. The W3C Draft provides a framework for interpreting such properties in a SHACL graph, and specifically provided comceptual `Editor` and `Viewer` components which would be automatically selected by the application based on the interpreted SHACL details. `shacl-vue` extends this into an implementation.
|
|
|
|
|
|
Since the incoming schema is in an RDF-compatible language, and the entered data are all captured as RDF, one could view a form generated by `shacl-vue` as a type of graph editor, but rather one that hides the complexity of graph data from the user by emulating the more standard hierarchical representation of a form that users would typically expect. |