Over the past few months we have been working to make SOLID PODs an archive repository for online forms to submit to.
Using a FormRouter Account, it is now possible to setup an online form that can route directly into a SOLID POD Inbox. This allows any person with a SOLID POD to get a copy of the form data they filled out. The submission may include a copy of the form as a PDF. In addition, we have built a File Extraction Utility to open PDFs and attachments directly out of your POD Inbox.
We are looking for people to try a form, review what we have done and comment on the data written to their POD inbox.
The Goal:
To make PODs an archive for all form submitted by a specific POD user.
For example: you fill out a government form. FormRouter passes the data to the government agency database, and a copy of the form is written to your POD so you have a record of what you sent. Because you have a record, you can reference it, share it or tell the agency that you no longer want them to use it to meet GDPR regulations etc.
Questions for Testers:
Is there a better way to write data into the POD?
What could we add to the data to make it of more value?
What would you like to see the app do next?
This is a Killer App! Thank you for posting the link to your site. I am sure it will be well received. I like this app because I can use it to send an invitation via form, news article, a link, or a random message to any Solid users Inbox without being signed in to my pod, or the pod receiving the form. In fact, you don’t need to be signed into Solid at all to send someone a message/form with Form Router.
I like the idea of users being able to store and retrieve copies of the forms they submit. This is indeed a selling point for Solid. A couple of things that would make this easier to use for POD owners: allow the user to select the location for file-saving; allow users to name forms; include information about the original web location of the form; have a standard set of RDF metadata that encloses each form - this would mean that software tools could access the forms consistently even if the form fields themselves are not consistent.
The original web location of the form should be machine-discoverable, not just in a comment. Ideally you would be encouraging your clients to themselves use ontologies so that the forms themselves were in usable RDF format. But even without that, capture everything generalizable as RDF so that POD owners could use the data and interoperate with other RDF resources. As for specific ontologies, I would start with DOAP (Description Of A Project) and other ontologies which describe web documents. At a minimum it should be capable of saying in RDF “This is a document containing the results of a form named A, submitted by B at web location C, submitted to formProvider D, remailed by FormRouter, at date/time E .” You might also think about supporting a taxonomy of form purposes e.g. “purchase”, “survey-response”, “records update” … Just thinking off the top of my head here.
Adding the ability for our clients to specify ontologies would be a feature we would consider, in the future, if we gain enough traction.
I will definitely look into DOAP. I was more concerned with the data capture piece at first, so I was most concerned with just translating our format into something generic and I kept the metadata as comments so that it wasn’t part of the data document itself. In the case of copies going to an inbox however, I definitely see how it would make sense to not worry about the purity of that translation.
Does the form have to be a PDF? If not, then I could imagine a simple browser extension to add this backup capability to any form - I would love to have that.