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

I also have some thoughts on ordering in relationship to the following part of comparison:

SHACL

Can be used to generate forms, but the designer has to add order.

ShEx

Can be used to generate forms directly.

The issues I see with this comparison are:

1. Absence of order information should not prevent form generation. 

For example, UI code could then order properties alphabetically. This is what we do if there is no order information.

2. In my experience, and I have done quite a lot of data modeling, defining the order of presentation of properties in the UI is always a subsequent step to defining what properties exist and what values they should have. 

In case of SHACL, the subsequent step is about adding sh:order values. In case of SheX it is about reordering information in the shape. In either case, it is a separate step. I believe that adding sh:order values is a simpler and less disruptive approach as it only adds to the shape and does not involve modifying the rest of the information that already exists..

I am saying this because the order in which properties are though of during the data modeling is often not the order in which they should be rendered on a form. Until all properties are enumerated and defined, a designer typically can not make proper decisions about their presentation order. This makes any early commitment to the field order temporary and preliminary. Only after all properties are identified, the order could be decided on. 

Regards,

Irene

> On Jun 24, 2019, at 12:45 AM, Holger Knublauch <holger@topquadrant.com> wrote:
> 
> Hi Ruben, others,
> 
> I have meanwhile written up some more technical background on how we use SHACL for form generation:
> 
> http://datashapes.org/forms.html
> 
> As Irene already elaborated, we do believe that SHACL is well suited not only for validation but also to describe the expected shape of data from different viewpoints. The combination of constraints (sh:datatype, sh:maxCount etc) with UI layout info (sh:order, sh:group, sh:name, dash:viewer, dash:editor, dash:singleLine etc) makes the approach quite powerful and neatly integrated. The fact that these are published RDF vocabularies, tools from different vendors could compare notes and ideally support the same URIs to represent form layouts and widgets. Maybe there are chances to collaborate and fine tune this in the future?
> 
> FWIW we were a bit puzzled by the table comparing SHACL and ShEx in TimBL's document https://www.w3.org/DesignIssues/Footprints.html. That table feels a bit biased.
> - There is no reason why SHACL couldn't be used to generate arrays or trees of bindings. Several of our algorithms "walk" a shape in parallel to the data and then build up visited nodes. GraphQL is one such example.
> - SHACL is only unordered as long as you don't use sh:order. The use of rdf:Lists in ShEx's RDF syntax makes it awkward to use (e.g. try to SPARQL it). And just using the Compact Syntax leaves you with an inconsistent and very limiting syntax, e.g. what about sh:group, sh:name, sh:description and other properties that are typically needed to describe forms, and why introduce another language that requires custom tooling compared to Turtle or JSON-LD.
> 
> Cheers,
> Holger
> 
> 
> On 18/06/2019 00:45, Ruben Verborgh 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
>