PREFIX : <http://hl7.org/fhir/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
start = @<TensionShape>
<TensionShape> { # An Observation has:
:status ["preliminary" "final"]; # status in this value set
:subject @<UserShape> # a subject matching <UserShape>.
}
<UserShape> { # A Patient has:
:name xsd:string*; # one or more names
:birthdate xsd:date? # and an optional birthdate.
}
Great post. I’ve been interested in this topic for a while and haven’t done much about it. But I really think what you’re talking about is a critical point for a phase change in the number and quality of apps for Solid. It probably would be good if you could start a Solid panel on these questions.
Should an instance of the ui-ontology be generated from a shape, and then different user interfaces be generated from there?
Is an ontology needed to describe how the UI should be generated (to UI onto instance, directly to plain js/HTML/csd, or to one or another component lib, or to something else)?
I’m a bit more partial to ShEx, though both are great for data modeling. I find the compact formatting of ShEx easier to read and alter, particularly when I’m just trying to model something out. I find ShexJ a lot easier to use on the front end as well, though it’s extremely verbose.
The thoughts on things like shape -> form, which @anon36056958 asked about, is that we would have a “form model” based on the UI ontology, which would be documented somewhere (based on the footprints Ruben and Tim have been writing). We were thinking the workflow would be something like Shape -> Form Model -> Form Renderer -> Form where the Form Renderer can take ANY form model and render it, without caring where it came from. The Shape -> Form Model step might output a form model ttl file, or just as an object to be passed into the form renderer directly. Haven’t quite figured that part out yet.
Thanks for the update! I may be pushing my luck here, and I don’t know quite how this would work, but I think it would be great to have like a modular form renderer that you could plug in with npm or something so that you could use different component libraries to render forms.
One of the core concepts proposed in Linked Data Shapes, Forms and Footprints is the translation of the Shape (ShEx, SHACL, other) to a Form Model described using Form Language. Developers/designers will then be able to edit the Form Model to adjust the layout of the form, labels, widget types, etc. A standard Form Renderer would take a Form Model as input and render the Form. As such, the renderer is a little divorced from the Shape language.
Based on experience gained implementing a prototype that rendered a form directly from a ShEx shape, the approach proposed by Tim is currently being worked into the React Solid SDK roadmap to provide the Shape -> Form Model -> Form Renderer -> Form workflow.
We’ve been chatting about having some of the more service-like features added to a generic JS library instead of the React Components, but so far that’s still in the planning stages.