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

Hi Irene,

> 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.

Thanks, this is very useful information!

And we didn’t make firm technology choices yet,
so this can definitely influence our approach.

> 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/. In doing this, we needed to address a few requirements that required some extensions.

Does that include specific UI controls for rendering certain fields?

> 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.

This one-to-many relationship between shapes and forms
is indeed very crucial to us as well, for the same reasons.

However, this is what prompted us to separate shapes from forms;
clearly delineating between shapes for machines,
and forms that are UI for people.

I wonder how such a separation is realized with SHACL and extensions.
For instance, the sh:order predicate you mention;
to what parent object is it attached?

Are there examples we can compare?

> 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. 

So, a form is considered a specialization of a shape?

> 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.

These might probably go into what we call “footprints”.

> 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/.

Super, this is of great interest to me as well,
and there seems to be some correspondence to
https://ruben.verborgh.org/blog/2019/06/17/shaping-linked-data-apps/#shapes-APIs



In general, it seems that TopQuadrant has chosen to stay close to shapes,
whereas we thought that we would restrict the scope of shapes to just structure,
and then deliberately using separate concepts for forms and footprints.
The idea being that they are different things edited by different people.
Will be very interesting to compare these angles.

Thanks,

Ruben

Received on Monday, 17 June 2019 16:16:19 UTC