Forms in the ecosystem

The User Interface ontology at http://www.w3.org/ns/ui defines RDF terms for describing forms. The solid-ui project provides functions to use these forms within your web application to create a quick user interface solution. An introduction basically describes how forms work. This document describes how forms fit into the ecosystem of apps, views/panes, and data browsers and stuff.

How to forms end up getting used? How do form end up getting created, copied, and modified?

The simplest way is for a developer of a web app to included the mashlib, and then insert a form into the web page as a control, specifying the form and the subject, and the place he data is to be stored. This is a good way of building workflow quickly. It also separates out the logic of the form from the presentation details of style. A solid-ui form is not just a set of components, it is a binding to the underlying linked data. So no more code is needed by the developer.

Now look at other ways in which forms can be used within connected data system like the mashlib and the databrowser.

Forms and classes

Forms create graphs of information starting off a root node, a seed node, if you like. They are made for recording information about things of particular types, in particular RFDS Classes. There are two relationships:

A creation form must have enough in it to make a record which makes sense. Just having height and weight, for example, produces a node with nothing to identify what the thing is. A creation form may have say name, address, phone number so that the record is useful in apps. Once you have made something using a creation form, then you can later add more data with an annotation form. You can also use any creation form as an annotation form later to edit the data.

So in the form ecosystem, when a user wants to create something new, it is reasonable to give them a list of creation forms, for whatever classes they may be interested in. But then when they are looking in the UI at an object of a particular class, then it is reasonable to offer them those forms (of either type) relate to that Class of the object, if they want to record more things.

Using RDFS inference is useful here. If there are forms declared as being for Person class, and the user is looking at something which is of class Student, then it follows that the subject is also of type Person, and can so those forms may be used. One trick is to present first the forms of the most specific type (Student) before the ones for the more generic type (Person) as they may at a guess be more relevant.

How to find out forms for a given class? A simple way is to include the link to the form in the ontology. This obviously gives it a pretty definitive status.

Many existing ontologies

Communities, projects, organizations and groups may want to share sets of forms they use, and so community-based indexes of these are interesting.

Forms from shapes

Forms are very simpler to shapes, as noted elsewhere. Forms can be generated from shapes.

Creating forms

Filling in forms should be something which is easy for any user to do. It will be conceptually complicated, should be as easy as possible also for them to make a new form. How does the work flow work? This one is easy to implement but not very easy.

• A user navigates from an object to its class. Then the "builder" view of the class prompts them to make a new form, a creation form or an annotation form. They have to chose where to put the form.

Maybe they want to edit an existing form.

• A user is looking at a form someone else has made. They find a way in the UI to look at the form itself. (A "See this form" button etc, or a peeling-back-the corner icon, say). This takes them to the form itself.
• They then edit it if they have permission
• They clone it into their own project to make their own version

There are many ways of creating and editing forms, but because there is a form for editing forms, one way is with that.

Forms and Ontologies

If you are using the form form to create a form, then for each field you will have to supply a predicate. The solid-ui system will give you a selector to chose from all the predicates it knows about. For this reason it is good to load in ontologies you want to use before you start editing. The form playground has tools to do that.

Some days, the user finds that the good old vocabularies the Solid project has been using provide all the concepts they need. Some days, they will have to look further afield and find an existing ontology just new to them. Some days they will find one almost perfect and want to imagine of suggest friendly amendment to it. Some days they will decide to just create a new ontology, for speed, for control, or for fun. Some days they will find the ad hoc ontology they created at one point is now one they want to get people to adopt or link to from their own ontologies.

So one way or another users will become ontology users, and then will become ontology editors and creators. We need tools to enable these workflows, particularly the social collaborative parts. These tools are not covered here. It is worth saying that the power of systems in a big world depends on wide interop, and you get interop from shared vocabularies, and you get shared vocabularies from hard work, where there is much glory but no free lunch.

So if ontology editing becomes a practical part of these workflows, can we use forms as one way of editing an ontology? It seems reasonable, though a custom engineered UI may be much nicer.

Filling in a bit of this table seems like it may by a good move.

Conclusion

A worthy goal is to build a platform where collaborative systems can be build by their users without having to write code. Forms can contribute to that quest.