Generate UIs from Schemas. Is there a representation/interaction vocabulary?

[jmatsushita]

Hi there,

@elf-pavlik pointed me to a few conversations that seems to confirm that there's some gap in a Data UI (i.e. Forms) generation schema for RDF/JSON-LD and components for using them in HTML.

Sure there's a good amount of things already discussed elsewhere, but I thought it would be useful to summarise my thoughts about this.

I've been trying to reproduce the XRX idea with JSON (or "JRJ" as @JeniT nicknamed it - which would stand for JSON-Schema/Forms-REST-JSONDB) and it works pretty well and looks like this:

• Use a document database (I used CouchDB) that allows to GET/POST JSON over REST.
• Use JSON-Schema (which can be in the document database too) to describe forms. Note that this needs non-standard extensions of JSON Schema. (Cf. stacks/form-editors.md just committed), which allow to separate the concerns of data structure and data representation/edition.
• Use a javascript form component to render HTML Forms from the JSON-Schema (and populate them directly with the JSON data). I used AlpacaJS but any other JSON Schema based form editor should do the trick (with the caveat of the non standard extensions to describe the form specific parameters).

Now what you get from this is pretty significant DRY:

• You don't write model code (for simple "entity" CRUD). You just need your JSON-Schema
• You don't have to write view code, since the form component generates views from your schema (with the non-standard representation extensions thingies).
• Your database is happy to store anything (JSON document database) if you don't need a lot of validity/integration rules.
• You can still get validation "for free" which you can do on the client side with the form components (most already also provide custom validation hooks) or in the database if you like.
• You can have a sort of schema versioning which is impossible with relational databases, like having data with different versions of your schema coexist in the same database (and if you tag your document with the version of the schema you can still open/edit it with the previous schema).

Of course for applications that are more than editing records it will get more complicated than just doing the stuff above, but not having to do that part is a huge win in my book (note that I've only done this in one project so far https://github.com/iilab/ltfhc-next , so I don't know how solid and maintainable that really is in the real world).

There's probably more benefits that can be found by getting more inspiration from the XRX model.

Now one of the big problem with "JRJ" is that there is no XForms. This results in the different javascript form editors using different "proprietary" ways to describe the graphical elements that need to be added to the schema in order to display it within an HTML page. I have only tried AlpacaJS which uses an options object for that. The JSON-Editor way seems quite attractive because it uses the HTML5 keywords for its format keys, as well as offer a "template" approach for more complex rendering which seems open and compatible with a lot of templating languages that web developers are familiar with. But there's not standard... That's a gap.

All that's cool, but what would be cooler? Well "JRJ-LD" so to speak of course! So the same thing with a triple store (are there any that support GET/POST of JSON-LD? I think that's what the Linked Data Platform approach aims at?), JSON-LD as the schema, and some standard for representing Form UIs with javascript components.

So lots more gaps there, but it would be great to see:

• In-browser TripleStore efforts like LevelGraphDB implement LDP. See current status of implementations and note the node LDP.js.
• A standard for representing web forms/interactions that can be used as a representation/interaction vocabulary. If that's something that would also help standardise the non-LD aspect of representing JSON in forms, that would be an added bonus. Does this exist? JSON-LD Forms?
• Web components and javascript implementations that can take the GET output from LDP servers, use it to populate forms rendered via the JSON-LD + JSON-LD Forms, client side or server side validation via JSON-LD and submit JSON-LD back to servers.

Do others feel the need for this?

[jmatsushita]

Thanks to @steffen-l and @blankdots for pointing me towards the VISO ontology: http://www-st.inf.tu-dresden.de/smtvis/blog/?page_id=93 wondering what @janpolowinski would think about the above and more specifically:

• Can VISO describe Forms?
• Do you know of Ontologies that describe Forms and would play well with VISO?

It seems that RVL https://github.com/janpolowinski/rvl aims to generate representations (using d3.js) from VISO data!

Relates to #9

[janpolowinski]

Hello, deriving UIs from schemas is definetely a good idea and could save a lot of time, I welcome any discussion in that direction. While I cannot say much on the JSON part, I'd like to point you to a blogpost where I recentely described my thoughts on defining a "schema" for my RVL (RDFS/OWL visualization) language. The ability to derive a UI was one of the motivations behind this. While, for the moment, I ended up using SPIN (vor vailidation via SPARQL) and the forms vocabulary suggested by TopBraid (for manual form setting manipulation), there are very recent and promising standardization efforts (see links at the end of the blogpost). I'm not sure how far these standards will get in the direction of actual form / UI settings. You may also want to trigger the discussion at https://www.w3.org/community/swisig/ if you should take the LD/RDF way.

VISO itself is not directly meant to describe forms, but offers a formal description of the graphic concepts that we require (as a "target") of our RVL mappings. While even a form's input elements could be described using VISO evtl. I'd prefer using a forms vocabulary for that, if possible a standard one.

What I'd consider important when deriving interfaces from a schema, is that the derived interfaces can still be easily adapted to the local requirements, not only concerning style, but also structure. Otherwise local changes will be lost after regeneration (or reinterpretation).

[jpmckinney]

See also https://github.com/darobin/couth