Re: shapes, forms, and footprints for building Linked Data apps

Ruben,

With respect to forms, SHACL already has some pre-built support for forms. For example, there is sh:order. There could have been more and the charter of the working group did cover this topic, but the working group ran out of time. 

Majority of participants were interested in data validation only or primarily. Some were also interested in rules. Some were also interested in the UI support. The deliverables of the WG were focused on satisfying majority of the participants within the constraints of the chartered work period.

Today, TopQuadrant uses SHACL and extensions to SHACL (the extension mechanism is part of the standard) to render forms in TopBraid EDG https://www.topquadrant.com/products/topbraid-enterprise-data-governance/ <https://www.topquadrant.com/products/topbraid-enterprise-data-governance/>. In doing this, we needed to address a few requirements that required some extensions.

Not only different application may need to have different forms for the same underlying data, but different people using the same application may require different forms. To that end, we have extended SHACL to support role-specific views. The extensions is quite simple - a NodeShape can have an additional property with a value corresponding to user’s role. Then, this shape is selected (among all applicable shapes) for presenting information to a user in that role. 

We use a shape that is also a class to define all properties for a given group of resources (implicitly targeting them) and then use, potentially many, alternative node shapes that explicitly target these resources. To simplify creation of these forms, there is a wizard that lets users create a role-specific shape (form) by selecting from all the properties defined for the class/shape.

TopBraid EDG has extensive support and infrastructure for roles which ca be specified at a resource level, a graph level and a hierarchy of graphs. These roles, in addition to determining form display, also drive workflows and access privileges. I am mentioning this to explain the role aspect, but this is somewhat of a digestion from the topic.

We heavily use sh:order, sh:group and sh:name (for cases when a name of the field to be displayed to a user should differ from the the name of a property or when the field represents a property path). Sh:description is also used to provide helpful guidance to the users of a form.

Other extensions address the fact that a view presentation of data may need to be different from the edit presentation, provide  instructions for embedding and creating “related” resources (e.g., a person may have multiple addresses with people and addresses being separate related resource, from a form perspective, a user will want to see and create addresses as part of a person’s form), etc.

Since UI applications today use JSON, we are using SHACL to dynamically generate enhanced GraphQL Schemas. This is described in detail at https://www.topquadrant.com/technology/graphql/ <https://www.topquadrant.com/technology/graphql/>.

Regards,

Irene



> On Jun 17, 2019, at 10:45 AM, Ruben Verborgh <ruben.verborgh@ugent.be> wrote:
> 
> Dear all,
> 
> The Solid ecosystem (https://solid.inrupt.com/)
> is a way of building decentralized Linked Data apps,
> where people store their data in their own data pod
> and can interact with it using different apps.
> 
> To realize this kind of interoperability,
> we will likely heavily rely on shapes,
> extended with forms (UIs for people)
> and footprints (rules on where to store data).
> 
> We’ve written down some of our thinking
> in a Design Issue (status: draft) at
> https://www.w3.org/DesignIssues/Footprints.html
> and I have written the longer story,
> including thoughts about future use cases, at
> https://ruben.verborgh.org/blog/2019/06/17/shaping-linked-data-apps/
> 
> Your feedback as shape experts is very welcome.
> I’m particularly interested in related technologies and use cases
> that we might have missed when writing this down.
> 
> Best,
> 
> Ruben