Closed phochste closed 1 year ago
@phochste Could you add a use case (or a set of use cases), so we can put bounds to this challenge? Because forms can be very wide (think Doodle for instance with a calendar form component). Basically, when I see a certain solution, I need to be able to make a yes/no decision based on the scope, and there should be no feature creep.
@RubenVerborgh ok added a use-case
See : https://github.com/phochste/FormViewer for implementation
Pitch
Create a Form render application that can render an RDF form definition that is possible build with the Form builder tool as specified by https://github.com/SolidLabResearch/Challenges/issues/64.
In this app users can in a declarative way point to the RDF definition, RDF data and Solid storage location where data should be serialized.
The app provides a generic rendere of RDF forms. It can be used as a stand-alone app or can be the basis of an application to provide more domain specific layout features.
Use case
An end user has created in some way an RDF Form definition for a book review. The result of this process was https://github.com/phochste/solidui2rdfform/blob/main/data/rdfform/book_review.ttl
See https://github.com/SolidLabResearch/Challenges/issues/64 for a sample application that should do that in an intuitive way.
She wants to see a working RDF Form as a web application . "Working" means, it can actually be used to fill out the data fields and store the resulting RDF in a Solid pof location of choice.
At a later point in time she decides that she wants to update an existing book review with fresh data:
Desired solution
Acceptance criteria
Pointers
Scenarios